Aller vite et abandonner

• Quand l’automne arrive, on se met à regarder en arrière
• Tentative de récupération d’un jeu écrit il y a 35 ans sur un vieux disque dur
• Publication sur GitHub d’anciens jeux shareware rassemblés sous forme d’images disque

Des projets presque jamais terminés

• Le processus de redécouverte et de restauration d’anciennes expérimentations de jeux a apporté de nombreux enseignements
• Certaines expériences auraient peut-être pu devenir de bons jeux avec un peu plus de temps
• Par exemple, AirBikes devait devenir un jeu de course futuriste

Aller vite

• Découverte d’un jeu écrit en 1991 et d’une liste de « creator codes »
• Les creator codes étaient à l’époque un concept similaire aux identifiants de bundle actuels
• Sur 27 titres, 5 ont été publiés, les autres étant des expériences destinées à prototyper rapidement

Créer des prototypes

• Il est important de créer rapidement des prototypes pour vérifier si un jeu est amusant
• Par exemple, un prototype a été réalisé en quelques jours pour voir si un jeu où l’on pilote un cerf-volant était amusant
• Le plaisir d’un jeu vient souvent d’éléments inattendus

Abandonner

• Certains jeux avaient bien commencé, mais n’ont jamais été menés à terme
• Par exemple, Thief of Baghdad était un jeu où l’on se déplaçait sur un tapis volant magique, mais il n’a pas évolué davantage
• Développer seul l’ensemble du projet est extrêmement difficile

Pas complètement mort

• Un projet mis de côté peut toujours être repris plus tard
• Par exemple, Thief of Baghdad a été retenté 18 mois plus tard, avant d’être finalement de nouveau abandonné
• Il est possible de réutiliser du code provenant de projets mis de côté

Salarié

• À la fin des années 1990, le fait d’entrer chez Apple a mis fin aux projets personnels
• L’expérience chez Apple a permis de continuer à utiliser une approche de prototypage rapide
• Les collègues planifiaient surtout sur tableau blanc, tandis que l’auteur écrivait rapidement du code

A.B.I. (« Always Be Iterating. »)

• L’expérience chez Apple a donné le sentiment d’être un employé qui apporte une réelle contribution
• La capacité à programmer rapidement y a été reconnue
• La leçon « toujours itérer » a été transmise aux filles de l’auteur

Le résumé de GN⁺

• Cet article partage les leçons tirées d’anciennes expériences de développement de jeux
• Il met l’accent sur l’importance du prototypage rapide et de l’itération
• Il offre des perspectives utiles aux développeurs de jeux

[GN⁺]

Avis Hacker News

• Beaucoup d’entreprises lancent de nouvelles fonctionnalités puis, avec le temps, voient les bugs s’accumuler. Les développeurs d’origine passent dans d’autres équipes, et les ingénieurs restants se retrouvent à assurer la maintenance. C’est une situation très difficile
• Depuis que j’ai commencé à programmer en 1989, j’ai abandonné de nombreux projets. C’étaient surtout des jeux, écrits sur Mac Plus ou Mac LC. Je pense que le revenu universel de base pourrait fortement accroître le potentiel humain
• Je redéveloppe des logiciels pour Macintosh 68K. Il est intéressant de revoir un ancien code avec un regard neuf. J’ai un faible pour l’art en 1 bit. Programmer sur un système limité est très différent des environnements modernes où tout est possible
• Je pense qu’il est acceptable d’abandonner un projet. L’important est de commencer par de petits projets et d’apprendre à les terminer. Mes amis finissent souvent épuisés à force d’essayer de créer un moteur de jeu. Il vaut mieux commencer petit puis avancer progressivement vers des projets plus ambitieux
• Le prototype de voiture m’a rappelé les graphismes de Spy Hunter. Ça m’a donné un vrai coup de nostalgie
• Quand j’étais enfant, j’ai appris à programmer sur Mac et j’ai beaucoup joué à Glider et Pararena. J’explorais les forks de ressources des jeux dans ResEdit. J’ai terminé un petit jeu shareware et je l’ai mis en ligne sur AOL. J’ai été vraiment surpris quand j’ai reçu un chèque venu de Californie. Les débuts du Mac étaient une époque particulière
• Le pixel art de la capture d’écran est vraiment superbe
• Sortir de petites choses et itérer est la meilleure façon d’apprendre davantage et d’obtenir plus de résultats
• Je ne suis pas certain que normaliser l’abandon des projets soit une bonne idée. Aller au bout des choses est aussi important
• Écrire du mauvais code ou du code difficile à maintenir n’est pas une bonne chose. Utiliser des services d’hébergement gratuits et mettre le projet dans un dépôt public permet à d’autres de le retrouver. Rédiger une bonne documentation permet à n’importe qui d’exécuter le projet