|
2006: first ever SEDS build |
C'était il y a 10 ans, déjà. Mes p'tits n'veux étaient plus petits que moi, et pas des grands costauds apprenti-DJs qui râlent parce que "le théorème de Pythagore, ça sert à rien" (faux!). J'en étais aux toutes premières versions de SEDS, mon éditeur de sprites pour la (relativement) nouvelle console de Nintendo: la DS.
J'avoue que j'espérais rassembler une communauté d'enthousiastes utilisateurs autour de ce qui ne sera finalement que "mon éditeur à moi, par moi, que j'utilise, mais vous pouvez vous en servir, hein, si vous voulez". Je ne peux en blâmer personne: en 200x, soit les gens ont appris à se servir des "vrais" programmes de dessins sans avoir besoin d'une petite grille sur écran tactile, soit ils savent où trouver
des graphismes "Creative Common" et ça leur va ... soit ils ne s'intéressent pas à tout ça.
Tenez, même le gamin d'en face au barbecue de l'école qui fait aussi des p'tits jeux sur DS va à la chasse au pixel sur Internet plutôt que de s'entrainer au pixel art (il a au max 8 ans) et retouche éventuellement un peu ce qu'il a trouvé avant de l'intégrer dans DsGameMaker.
I started my collection of game tools for DS 10 years ago with some 16x16 grid and a simple "page" system to save/restore/update content. I had dream by then than giving the Internet some tools to intuitively draw pixel art on a handheld system would make the homebrewer community produce more original and nice pixels for their games. By then, they were shamelessly embedding ripped, copyrighted characters even for the most creative one.
It never really took off, and I can't really blame anyone for that: kids doing game making will more easily find creative common art that they can integrate even when targetting the NintendoDS. Pixel artists will likely have grown skills and workflow on their preferred tool that doesn't exist in SEDS. With paypal-powered (?) platforms to sell your pixel art as "assets pack" and guys agreeing to have somewhat generic graphics in their game, the once-mandatory coder + gfx duet of the eighties is no longer a must to make a game.
|
2016. dsgametools cover almost everything but scripts. |
J'espérais que tous mes potes autour de moi (p'tits n'veux, frangin, vieux'd'la vieille et collègues) sauteraient sur l'occasion pour faire des niveaux comme au bon vieux temps des mercredi après-midi sur RSD Game-Maker. Ça non plus, ça n'aura pas marché. Mon éditeur de niveau reste trop rigide pour le non-initié et les graphismes que j'ai créés demandent des ajustements que les gamins ne prendront pas la peine de faire.
I also had hope that creating a level editor for DS would encourage my relatives (nephews, brother, old-time-friends and co-worker), all enthusiasts about game development in general, to make their own level and I would simply need to integrate what they crafted. It didn't worked either. The map editor never became user-friendly to the point it felt attractive to anybody, I'm afraid.
Et puis il y a le scripting lui-même. Les "machines d'état", cette partie du développement qui -- encore 10 ans après le lancement des "dsgametools" se passe toujours sur le PC. Celle-là est de loin la plus rébarbative. Même si le langage colle assez bien à ce qu'on veut faire, avec ses concepts de zones de collision, d'états, de transitions, d'effets spéciaux, de contrôleurs etc. il est terriblement difficile à apprendre.
|
but there is *so much* I miss to make it a comfortable development environment for hobbyist gamedev'ers |
Je suis sous le charme de l'idée de "
Learnable Programming" et de cet environnement de développement idyllique où l'on pourrait voyager dans le temps et dans l'espace d'état d'un bloc de code pour comprendre ce qui se passe, où, pourquoi et comment. J'ai mon "Inspector Widget" qui me permet de suivre d'un peu plus près ce qui se passe du point de vue des "objets/personnages" mobiles du jeu. C'est loin d'être suffisant.
There is one thing left I haven't tackled within those 10 years. The state machines, describing how characters and monsters behave, still require text editing on PC. This is a bit of a pity because a text editor is far from being the most learnable-friendly environment for the task. Collision areas are obfuscated behind numbers, compilation cycles are mandatory to check whether a new move is working or not.
I'd love to have it on the DS too. You would see what the actual objects you manipulate are. You'd be able to track state changes and variable effects with much better integration than with Inspector Widget.
Je n'ai peut-être pas réalisé à quel point la présence d'Internet a transformé le développement de jeux amateurs, non plus. En 1986, si tu voulais faire un jeu vidéo, il fallait soit que tu sois bon en graphisme et en programmation, soit que tu connaisses un bon graphiste et un bon programmeur (après, il reste à inventer un bon jeu, avec de bonnes idées et à bien doser la difficulté, mais ça, ça n'a pas franchement changé).
En '96, c'était presque la même chose sauf qu'on a pu commencer à remplacer "un bon programmeur" par "quelqu'un qui comprend comment se servir de RSD Game-Maker", à condition de ne pas être trop difficile sur le gameplay espéré.
Maintenant, celui qui aime faire des graphismes "comme dans les jeux" peut juste faire ça et mettre ses graphismes comme des "assets pack" sur un forum. Ou alors, il passe une semaine à apprendre un outil intégré à un moteur de jeu. Celui qui a envie de montrer qu'il programme tellement bien qu'il peut s'attaquer a des jeux n'a pas besoin de connaître quelqu'un qui fait des graphismes, pourvu qu'il connaisse
un endroit où le premier a mis ses graphismes.