Microsoft publie le code source de Zork, véritable monument de l’histoire du jeu vidéo. Cette mise à disposition ouvre un accès inédit aux entrailles d’un titre pour le moins fondateur.
Il faut remercier Microsoft pour ce geste.
J’en profite pour souligner que la loi devrait être mieux adapté pour la préservation des logiciels.
D’une part, la durée de protection est trop longue, il faudrait revenir aux 25 ans qui était la durée choisie initialement en France.
D’autre part, pour prétendre préserver un logiciel, il parait évident que le code source doit également être préservé et pouvoir être divulgué à l’échéance des droits.
Pour finir, il existe aujourd’hui un besoin de préservation des intérêts des utilisateurs en cas de faillite d’un éditeur ou de fin de commercialisation d’un produit ou d’un service : utiliser un logiciel, c’est devenir dépendant.
Le problème devient évident pour le logiciel d’aujourd’hui qui repose de plus en plus sur des parties tournant « en ligne » et qui pourraient disparaître totalement sans préservation possible puisque ni le code source, ni le code exécutable ne sont jamais divulgués. Ou pas dans leur totalité.
Il faut comprendre que l’idée du droit d’auteur, c’est d’être une concession provisoire limitée dans le temps. Mais que l’oeuvre doit tôt ou tard revenir au domaine public. Ce n’est pas juste une éventualité, mais une obligation.
Pour ces raisons, il faudrait :
(1) Obliger à un dépot légal du logiciel AVEC son code source pour toute diffusion en France.
(2) Ramener la durée des droits d’auteur sur le logiciel à 25 ans à partir de la date de dépot (durée qui est plus que suffisante).
(3) Pouvoir procéder à une déchéance de droit anticipé en cas de fin de commercialisation ou de support s’il s’avère que des utilisateurs sont bloqués pour continuer son usage ou lui apporter des évolutions nécessaires. Cette déchéance devrait être automatique dans le cas ou ils sont nécessaire à l’opération de machines industrielles, pour éviter leur mise au rebut prématuré.
2 « J'aime »
Starfield un jeu mythique ? c’est du mauvais trollage , du très mauvais
2 « J'aime »
Tu devrais relire le titre 
1 « J'aime »
C’est clair qu’ils auraient pu prendre un jeu un peu plus primé comme point de comparaison. Starfield n’a reçu aucun prix et très peu de nomination, si je ne m’abuse. Il n’a pas non plus soulevé l’enthousiasme général.
Pour rester dans le thème aventure solo narrative de Zork, ils auraient pu choisir Zelda : Breath of the Wild ou Witcher 3.
Et concernant l’offre de Microsoft, sauf pour des raisons d’archéologie vidéoludique, je ne vois pas bien l’intérêt de mettre à disposition le code source d’un jeu d’aventure textuelle de 1980.
Ce qui est dommage justement c’est que finalement ce n’est pas tout le code mais les scripts du jeu et pas le moteur actuel. Il indique des moteurs existant pour compiler ce code, mais ne donne pas l’original ce qui est dommage.
Il y a bien des jeux dont je serai curieux de voir le code source. Par exemple Hunter un jeu Atari/Amiga qui avait réussi à être un peu ce que GTA fait aujourd’hui, de la 3D non texturée, une map assez grande de la conduite de véhicule (bateau, hélico, vélo, voiture, tank,…), cycle jour/nuit, une belle liste d’item utilisable. Tout ca avec les pauvres capacitées d’une machine de cette époque.
Bah les ressources étaient exploités au max tout simplement. Avec de l’assembleur pure souche. Sans compter la gestion des parallaxes et autre dégradés gérés au poil par le hardware. Ces machines étaient bien pensées et les développeurs souvent hyper consciencieux. Je ne suis pas sur que de choper ces codes aujourd’hui seraient pertinents. Pour les collectionneurs peut être.
« Tout simplement ». Ah oui, quand-même.
Il y a eu de véritables trésors de développement / programmation pour justement exploiter toutes les capacités des machines, parfois au-delà de ce qui était mis en avant par les fabricants.
Et 40 / 50 ans plus tard, on se retrouve avec ce genre de commentaires …
C’est vrai que c’est tellement bien aujourd’hui, quand on se tape des logiciels qui font des centaines de MO avec des frameworks imbitables et dont le dev va utiliser à peine trois fonctions.
Juste pour remettre le contexte, une Atari 2600 c’était 128 Octets de mémoire vive.
Pas KO, je ne me suis pas trompé dans l’unité.
Sans compter le fait de devoir faire faire des opérations au hardware en tenant compte du temps de balayage du canon à électrons (parce que tubes cathodique).
Mais c’était « simple » à priori. Ah.
1 « J'aime »
Houla du calme, ce n’était pas du tout péjoratif.
J’ai fait parti de cette époque et je suis tout à fait conscient et admiratif des codes de cette époque. J’ai fait parti d’un groupe de demomaker sur Amiga (apocalypse bay) et notre coder (varso) arrivait à faire des trucs de zinzin. Moi j’étais dans les modules ou il fallait aussi être très ingénieux pour ne pas bouffer trop de mémoire et se contenter des 4 pistes sur protracker/noisetracker. On faisait ça par passion, inspiré par RedSector et autres.
J’ai eu la chance de côtoyer Moby, Mindfuck et autres zikos de fou lors d’une ‹ garden party › informatique. Enfin, je fais depuis des années des exe petits programmes et mon but est qu’ils soient :
1 : portable. 2 : de petite taille.
Et le plus drôle est que comme ils ne sont pas signé Microsoft, ils passent la plus par du temps pour des veroles (faux positif hein).
Les logiciels ne font plus la même taille et n’ont pas la même durée de vie 
.
C’est vrai que c’est tellement bien aujourd’hui, quand on se tape des logiciels qui font des centaines de MO avec des frameworks imbitables et dont le dev va utiliser à peine trois fonctions.
Fort heureusement pour le développeur, il aura changé de boite avant d’avoir a faire la maintenance de cet ensemble immonde construit sur des dépendances nombreuses, volumineuses… et changeantes.
Le suivant, s’il veut préserver sa santé mentale aura tout intérêt à convaincre le management de tout jeter et recommencer… avec les mêmes méthodes.
Et ainsi de suite 
juste pour remettre le contexte, une Atari 2600 c’était 128 Octets de mémoire vive.
Pas KO, je ne me suis pas trompé dans l’unité.
Sans compter le fait de devoir faire faire des opérations au hardware en tenant compte du temps de balayage du canon à électrons (parce que tubes cathodique).
Oui, la 2600 était l’une des machine les plus complexe à programmer ayant existé.
Le détail, c’est que pour économiser, elle n’avait pas été pourvue de circuit assurant le « DMA graphique », c’est à dire la collecte en mémoire des données pour l’affichage. Sans compter qu’il n’y aurait pas eu assez de RAM pour les stocker.
Du coup, il fallait envoyer les données en « software » au circuit d’affichage, de façon synchronisée. Et le processeur était occupée en grande partie à cela, il ne restait plus grand chose pour gérer la logique du jeu.
Les programmeurs ont fait des miracles de programmation avec cette console, mais les limitations matérielles vraiment trop importantes les ont quand même beaucoup bridé. Si vous voulez voir les meilleures adaptations des classiques de l’époque, ce n’est pas sur la 2600 que vous les trouverez. Pour ça, allez plutôt voir sur la gamme 8 bits d’ordinateurs personnels d’Atari qui a l’inverse de la 2600 avait un jeu de circuit très complet et puissant(c’est l’ancêtre de l’Amiga).
@arsworld J’ai mal interprété ta réponse, désolé.
J’étais trop jeune à cette époque pour en faire partie. 
Ah, c’est clair que les ressources matérielles étaient limitées. 
Ca fait un petit moment que j’ai envie de me mettre sérieusement au C et clairement l’un de mes objectifs est aussi de faire du portable et du pas trop gros.
Mais il faudrait surtout que j’arrive à trouver du temps.
Ne font plus la même taille, certes, mais quand tu vois par exemple Balena Etcher, qui sert à transférer des images ISO sur clé USB.
Le soft dépasse les 100MO.
Et utilise des technos telles que Node.JS, Electron, etc …
Alors, oui, ça fonctionne et c’est plutôt chouettos niveau interface, mais bon, Rufus, qui rend les mêmes services et avec plus d’options pèse moins de 2MO.
1 « J'aime »
Ce qui est dommage justement c’est que finalement ce n’est pas tout le code mais les scripts du jeu et pas le moteur actuel. Il indique des moteurs existant pour compiler ce code, mais ne donne pas l’original ce qui est dommage.
Effectivement, c’est dommage. Mais on peut imaginer que peut être, il y a des raisons contractuelles à cela. Par expérience, le fait qu’une « brique » ne puisse être libérée est un problème qui arrive souvent quand on veut mettre des logiciels dans le libre.
La communauté va certainement s’employer à résoudre ce souci.
Il y a bien des jeux dont je serai curieux de voir le code source. Par exemple Hunter un jeu Atari/Amiga qui avait réussi à être un peu ce que GTA fait aujourd’hui, de la 3D non texturée, une map assez grande de la conduite de véhicule (bateau, hélico, vélo, voiture, tank,…), cycle jour/nuit, une belle liste d’item utilisable. Tout ca avec les pauvres capacitées d’une machine de cette époque.
Oui, ce jeu était une petite révolution à l’époque. Autant d’un point de vue technique que conceptuel.
Mais comme la plupart des jeux de l’époque, il a vraisemblablement été codé directement en Assembleur. Et le desassemblage te donnera quelque chose d’assez proche de ce qu’a écrit l’auteur.
Cela dit, les codes « sources » assembleur contiennent souvent des commentaires utiles.
Peut être pourrait tu contacter l’auteur du jeu pour le convaincre de libérer son code. S’il n’y a pas d’obstacle contractuel, il sera peut être sensible à l’intéret que suscite son jeu encore aujourd’hui. D’autant qu’il y a peu de chance qu’il puisse encore gagner de l’argent encore avec.
On peut dire qu’effectivement, l’intéret académique est aussi un bon argument pour dire que la loi devrait obliger à la libération des code sources après un certain temps.
Ca fait un petit moment que j’ai envie de me mettre sérieusement au C
Je te le conseille vraiment.
Non seulement ça permet de faire plein de choses, mais il y a aussi tout ce que ça permet de comprendre.
Je te conseille aussi de faire un peu de langage machine(Assembleur) et d’électronique.
Beaucoup de gens racontent que programmer en assembleur ne sers plus à rien… et ils se trompent.
On peut certes faire d’innombrables choses en informatique de nos jours sans devoir recourir à l’assembleur. Pour tout dire, presque tout… mais il existe un petit nombre de choses indispensables qui ne peuvent pas se faire sans.