Quoi qu'il en soit, si je vous en parle, ce n'est pas parce que les 3 épisodes de Xargon sont disponibles sur classicdosgames.com. Non, c'est parce que le code source de Allen Pilgrim est également disponible. C'est du code C, mode réel pour le DOS, mais suffisamment propre pour que tous les aspects "hardware" soient extrait de la logique du jeu -- et croyez moi, sur PC, c'est un exploit majeur.
Ce n'est pas la bibliothèque d'abstraction du hardware qui m'intéresse, bien sûr. Même si c'était impressionnant à l'époque, le scrolling des jeux de plate-forme Epic ne pouvait concurrencer celui du moteur de John Carmack (commander Keen & autres), le player de fichiers CMF (adlib/midi) était bien connu, mais je n'ai jamais vu d'éditeur correspondant, et si l'on se laissait impressionner par un "yeeaaah" en ramassant un gros bonus, le mixage des effets sonores était en réalité peu convaincant (voire absent).
I'm currently studying the game logic of Xargon from Allen Pilgrim's sources. I hope that giving a look on someone else job will help me to overcome that "analysis paralysis" in my own game engine. I know i tend to overcomplicate things ... The management of objects-to-world collision has already shown enlightening... more to come. And, by the way, if anyone of you is interested into porting Xargon to the DS (or whatever other system), you may want to give a look to information gathered on the game modding wiki at shikadi.net in addition to the source code. Personnally, it's not in my to-do list :P
Non, ce qui m'intéresse c'est la logique du jeu. Et quelque-part, cette logique me crie le maître-mot de Mollusk: "ne vous posez pas de question: codez". C'est vrai quoi. Je me prends la tête avec mes test-points alors qu'en fait, ce n'est qu'une optimisation bancale que je traîne depuis l'age du BASIC, renforcée par l'étude d'un jeu NES. La gestion des collisions perso-monde dans Xargon est bien plus simplement basée sur les possibilités de l'ensemble des tiles recouverts et l'affectation de propriétés sur chacune de ces tiles.
int cando (int n, int newx, int newy, int ourflags) { int x,y,temp; int flagor, result; int startx, endx, starty, splity, endy; startx=newx/16; starty=newy/16; endx=(newx+objs[n].xl+15)/16; endy=(newy+objs[n].yl+15)/16; splity=(objs[n].y+kindyl[objs[n].objkind]+15)/16; flagor=f_notstair; result=0xffff; for (y=starty; y<endy; y++) { if (y>=splity) flagor=0; for (x=startx; x<endx; x++) { temp=(info[board(x,y)].flags|flagor)&ourflags; result&=temp; }; };return (result); };
Comme disait Colomb en quittant le Portugal "Il suffisait d'y penser": le tout est de concevoir les propriétés des tiles de manières à ce qu'elles "s'additionnent" bien. Un personnage ne peut se déplacer vers un nouvel endroit que si tous les tiles possèdent les bonnes propriétés ("pas un bloc", ce que Allen appelle f_passthru. Celà demande parfois un peu de jonglage mental. f_water est évident, f_climbable aussi. f_not_stairs un peu moins...
int trymove (int n, int newx, int newy) { int ourflags; ourflags=f_playerthru; if (newy>objs[n].y) ourflags|=f_notstair; if (cando (n,newx,newy,ourflags)==ourflags) { moveobj (n,newx,newy); return (1); // successfully made it to new location. } else if (cando (n,objs[n].x,newy,ourflags)==ourflags) { moveobj (n,objs[n].x,newy); return (2); // could only move vertically } else if (cando (n,newx,objs[n].y,ourflags)==ourflags) { moveobj (n,newx,objs[n].y); return (4); // could only move horizontally }; return (0); // couldn't move at all. };
J'aime bien aussi la manière dont il a réussi à capturer les comportements de déplacement simples Il faudra que je tente d'en faire autant. Bion. Je vous en dirai sans doute plus. Malgré tout, la routine de gestion du personnage principal fait quand-même 7 pages, et je n'ai pas encore tout lu.
héhé Xargon ressort des cartons hein ;)
ReplyDelete