NOD ou GDI ? Electronic Arts, détenteur des droits associés à la série Command & Conquer, vient de publier, sous licence GPL, le code source de plusieurs des jeux qui la composent, afin de faciliter le travail des moddeurs. L'éditeur annonce dans le même temps l'intégration du Steam Workshop à plusieurs de ces titres.
En pratique, EA a publié sur son espace GitHub le code source des jeux de stratégie en temps réel (STR) Command and Conquer Tiberian_Dawn et Red_Alert, de l'extension Generals_Zero_Hour et du FPS dérivé Renegade.
Jim Vessella, producteur en charge de la série, indique que ce travail de libération a été confié aux bons soins de Luke Feenan (dit « CCHyper »), un vétéran de la communauté des moddeurs. Il avait déjà contribué avec les équipes d'EA pour la sortie de la C&C Ultimate Collection publiée sur Steam en 2024.
« Je sais que ça permettra à ceux qui, dans la communauté, continuent à créer du contenu pour ces classiques de continuer à s'impliquer, et j'espère que cela aidera des communautés comme CnCNet à prolonger le support de ces jeux, et à les garder jouables pour les générations futures », se réjouit ce dernier.
Plus qu'une simple mise à disposition, la publication du code a d'après lui entraîné un véritable travail de restauration, indispensable pour rendre les archives Perforce de la fin des années 90 utilisables et modifiables sur des plateformes modernes. Le code source révèle d'ailleurs par endroit quelques remarques bien senties !
Cette première annonce s'accompagne de la mise à disposition d'un pack baptisé C&C Modding Support, qui contient les fichiers XML, les scripts, les shaders et les maps de tous les jeux basés sur le moteur SAGE.
Ce dernier accompagne la prise en charge du Steam Workshop pour les jeux ou extensions suivants : C&C Renegade, C&C Generals & Zero Hour, C&C 3 Tiberium Wars et Kane’s Wrath, C&C Red Alert 3 et Uprising ainsi que C&C 4 Tiberian Twilight. Une mise à jour des outils Mission Editor et World Builder permet désormais de partager directement mods et créations sur la plateforme de Valve.
Commentaires (27)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 28/02/2025 à 08h13
Le 28/02/2025 à 08h15
Vive la GLA !
Modifié le 28/02/2025 à 08h21
Par contre, je suis curieux de savoir si les extensions d'Alerte Rouge vont suivre.
Et la libération concerne que le premier AR ?
Le 28/02/2025 à 08h35
J'ai implémenté ça dans divers programmes, ça n'a jamais posé de problème. La description de l'API est correcte, et c'est presque un union, sauf qu'un union alloue la mémoire pour stocker sa plus grosse partie, ici, on allou que le minimum. Il pourrait aussi utilser direct DEV_BROADCAST_VOLUME, à condition de ne pas toucher aux champs pas définis par DEV_BROADCAST_HDR avant d'avoir vérifié le champ type.
Bref, y'a des remarques bien senties, sont-elles justifiées ?
Le 28/02/2025 à 10h04
Le lecteur se met en état IDLE automatiquement pour réduire ce délicieux bruit de turbine.
(souvenir, souvenir)
C'est un état géré par le hardware/firmware du lecteur, et dans cet état le lecteur ne communique plus avec windows tant qu'il ne reçoit pas une requête du driver. Donc si on éjecte le CD alors que le lecteur est IDLE, il ne communique pas cet action à windows. :/
Le 28/02/2025 à 10h11
Modifié le 28/02/2025 à 10h39
Je trouve assez cavalier de devoir caster un pointeur sur une structure de 12 octets (DEV_BROADCAST_HDR) en pointeur sur une structure de 18 octets (DEV_BROADCAST_VOLUME) pour récupérer les 6 octets qui manquent.
On voudrait faire un "buffer over-read" qu'on ne ferait pas mieux.
Modifié le 28/02/2025 à 14h43
(au passage, le pointeur est bien sûr dès le départ sur une structure de 18 octets pour le type DBT_DEVTYP_VOLUME)
Le 28/02/2025 à 16h56
A voir le compilo utilisé mais y'a de grande chances pour que le code de EA ou la version qui caste direct dans le bon type produise le même code machine.
Je pense que l'auteur du code n'a pas fait beaucoup de développement système.
Je serais curieux de connaître une technique "meilleure" (et qui n'utilise pas plus de RAM... de mémoire ce message est arrivé avec Windows 95, donc beaucoup de machines avec 8 Mo de RAM).
Le 28/02/2025 à 17h06
Le 01/03/2025 à 12h21
Modifié le 01/03/2025 à 13h42
Donc généralement c'est une entête qui précède une zone de data.
Ca me fait bizarre de recast ce header en une structure "hdr+data".
"Ah ah... vous pensiez que j'étais un header de 12 octets ? En fait non ! Je cachais 6 octets de data après."
Je trouve plus propre que le header déclare explicitement comme dernier champ un pointeur vers zone de data (void*), et de cast uniquement cette zone suivant le type.
typedef struct _DEV_BROADCAST_HDR {
DWORD dbch_size;
DWORD dbch_devicetype; // <--- type of data
DWORD dbch_reserved;
void* data; // <-------------- value of data
} DEV_BROADCAST_HDR;
typedef struct _DATA_VOLUME { // only the data part
DWORD dbcv_unitmask;
WORD dbcv_flags;
} DATA_VOLUME;
DEV_BROADCAST_HDR hdr = (DEV_BROADCAST_HDR) lParam;
if (hdr->dbch_devicetype == DBT_DEVTYP_VOLUME) {
DATA_VOLUME vol = (DATA_VOLUME) (hdr->data);
...
}
Modifié le 02/03/2025 à 15h24
Ta version marche, elle utilise un poil plus de mémoire et un poil plus de CPU (je suppose que le pointeur pointe sur la mémoire juste après, sinon y'a d'autres effets potentiels).
Du côté du code qui créé la structure, leur façon de faire me semble tout à fait adaptée.
Si tu prends tout ce qui est réseau, c'est pareil (forcément, pas de pointeur dans le paquet). Donc perso ça ne me choque pas du tout, et comme dit, le code qui caste ne coûte rien.
Je vois ça comme un union, sans le coût de l'allocation du truc le plus gros.
Et le nom des autres structures n'est pas hdr, les autres contiennent tout. Le hdr, c'est le header, les données suivent...
Le 02/03/2025 à 16h06
Mais en vieillissant je trouve qu'il vaut mieux faire des API moins optimisées mais plus 'rigoureuses' en terme de conception.
Le 28/02/2025 à 10h22
Le 28/02/2025 à 10h46
Le 28/02/2025 à 09h25
Le 28/02/2025 à 09h30
Le 28/02/2025 à 10h19
Le 28/02/2025 à 10h46
C'est justement bien plus simple de se reposer sur des assets déjà connu (pas besoin de direction artistique etc)
Le 28/02/2025 à 09h30
Bientôt un fork 4k?
Les fans ayant grandit, il y a certainement de quoi ajouter une API et organiser des compétitions de bots :)
Les écoles et team events vont adorer ^^
Le 28/02/2025 à 09h39
Le 28/02/2025 à 11h37
Le 28/02/2025 à 10h48
Le 28/02/2025 à 12h00
Modifié le 28/02/2025 à 12h25
Je ne dis pas que ce n'est pas bien, il y a des choses à y prendre en particulier niveau Generals/Zero Hour ou la question du Workshop.
Mais cela fait un moment que la communauté a recrée entièrement certains des jeux Westwood.
OpenRA pour jouer à C&C, C&C Red Alert et Dune 2000, fonctionne sur tout OS, multijoueur et tout.
Dune Legacy pour refaire un bon vieux Dune 2, sur tout OS aussi (bien que la dernière version n'a pas été compilé pour Linux).
Et sûrement d'autres.
Le 04/03/2025 à 16h46
Hate de voir la suite du projet :)