Après les éditeurs Borland et Quickbasic, voici probablement l'écran que j'ai le plus vu pendant mon époque "MS-DOS". L'éditeur de blocs du Récréational Game Maker. Une de mes références (en particulier du point de vue de ce qu'il ne faut pas faire) pour SEDS et les autres éléments de mon "game maker pour DS" à venir ...Premier reproche: la palette. Avec un pixel de large par couleur, c'est quasiment impossible de prendre la couleur recherchée du premier coup. Il faudra peaufiner avec les touches [+] et [-] le plus souvent. On aura droit à deux couleurs (bouton gauche et bouton droit) comme sur la plupart des éditeur graphiquesde l'époque ... et il faudra aller cliquer sur la case avec la couleur en question qui se mettra alors à passer toutes les couleurs en revue jusqu'à ce que vous cliquiez quelque-part sur l'écran ... tu parles d'un truc intuitif !
I've been spending *hours* on those screens ... Recreational Game Maker has been both a way to experiment more games than i could program myself, but also the program that made me realising that i wish to run my own (ultimate) game maker at the end of the nineties. Most of the user interface was absolutely horrible to use, left very little room for mistakes (e.g. no undo feature except re-loading a tilesheet and saving often) and led to fairly blocky object design. Somehow, it is my reference on "what not to do in [SGL]EDS".
L'outil que l'on retrouvera sans doute le plus, c'est cette liste déroulante de blocs dans laquelle il faut aller pêcher le bloc qui nous intéresse. Assez pratique quand vous avez les blocs de plusieurs niveaux dans un seul "bloc set", dès que l'on complique un peu les niveaux, en revanche, ça devient rapidement une horreur absolue ... On passe plus de temps à regarder défiler ses blocs qu'à véritablement construire son niveau, si vous voulez mon avis!
Autre défaut à mon avis, l'omniprésence du glisser-déplacer. Vous voulez choisir un bloc à éditer? déplacez-le vers la grille. Vous voulez le 'déplacer' dans la liste des blocs ... de nouveau, copier/déplacer. Même l'écran de réglage des paramètres fonctionne entièrement ainsi. Ecran qui en-dehors de ça n'était pas mal fait, d'ailleurs, donnant assez bien de flexibilité avec ses "special counters" (en fait, des clés), les hit points, les blocs générateurs de monstres ou animés ... Croyez-y ou pas, mais quand il s'agissait de créer un boss, c'est le plus souvent ici que tout se jouait, grâce au fait que le contact bloc/perso était géré indépendamment de l'animation du bloc ...My #1 rant on that software was about monsters management. Basically, a monster had a single animation sequence and a single movement pattern (though it could have a separate "attack pattern" when player comes close enough). The only way to build more sophisticated monsters was to "chain" them once killed. That meant that they could not change their behaviour on their own without being indestructible and (vice-versa) that they couldn't require several hits without having their state reset while switching to their new animation/pattern.
They couldn't shoot either (though i managed to have bosses transforming harmless, almost-invisible dots into deathly fireballs later on, but only at the expense of complicated monster/room inter-dependencies), nor could they detect when they were stopped by a wall (but they stopped nonetheless) or that they were walking in the sky. Most of my "state machine scripts" in the current GEDS engine are designed to work around those limitations and still allow graphical edition... yet i have no graphical editor so far :P
Là où j'ai plus galéré, c'est avec l'éditeur de monstres. Au départ, les blocs sont créés tout à fait normalement (mais avec une couleur de transparence quand-même). Il faudra alors construire des séquences pour animer tout ce petit monde (heureusement, l'éditeur de blocs nous avait déjà permis de tester des animations, mais il faudra les reconstruire ici. Pas de chance.
Le "comportement" de ces monstres sera définit d'abord par "quand il est touché, il se transforme en ...", ce qui permet explosions et compagnie (le plus simple) mais aussi des effets plus intéressants, comme de rendre le monstre "furieux" et de le faire courir droit devant lui s'il est touché. Le joueur aura alors intérêt à être rapide pour tirer encore. A noter aussi que ce sera le seul moyen d'avoir un monstre qui nécessite plusieurs coups pour être éliminé définitivement.L'autre point-clé, c'est cet espèce de "radar" dans lequel on va définir la succession des mouvements (genre trois blocs en avant, trois blocs en arrière, trois blocs sur le côté, trois blocs de l'autre côté ... Il était une bergèèère qui allait auuu ... euh ... pardon, je m'égare). Le hic, c'est que tout celà se détermine de manière complètement indépendante des maps. Il faudra donc être particulièrement vigilant à la longueur que l'on donne à nos plateformes si l'on ne veut pas qu'un monstre se mette à marcher dans les airs, car s'il sont capables de ne pas rentrer dans les murs, rien n'a été prévu pour les obliger à rester au sol, ni à faire demi-tour dès qu'un mur les arrète (on se retrouve alors avec un monstre occupé à faire du sur-place pendant deux secondes avant de se retourner).
Voilà. Il y aurait beaucoup d'autres choses à en dire, j'imagine, mais j'ai d'autres projets pour le week-end. Je vous laisse donc avec ce petit screenshot de Twinbee Land, collaboration de Pascal Deiting et moi-même à l'époque ... Un tileset de base que j'avais dessiné pour Badman II et qui a eu la vie dure, vu le nombre de jeux dans lequel on l'a retrouvé :P
Que de souvenir... ca me parait si loin... certes, j'ai peut-être moins passé de temps à approfondir son sujet... mais pourtant j'en ai crée des jeux sur ce programme !!! :)
ReplyDeleteLa "belle" époque de PPP Team... tout le monde s'y mettait : nous 2, Pierrick, Pascal, François, Valentin, Simon.... et même la petite soeur !