Tower Defense sur Ti89 - Page 1

Bonjour à tous,

Il y a quelques mois, en vacances, je me baladais sur le forum internettablettalk. J'ai vu un sujet dans lequel les membres testaient des jeux flash pour dire s'ils fonctionnaient bien ou pas ; et parmi eux, un jeu de tower defense. Je me mis donc à chercher d'autre jeu du type ; et aujourd'hui, dès que je veux perdre une demi-heure, je me fais un petit Vector TD. Pour ceux qui ne connaissent pas le principe de base du Tower Defense, il s'agit d'empêcher des monstres de se rendre d'un point A à un point B en achetant et en plaçant des tours qui vont leur tirer dessus.

Je me suis donc dit qu'un tel jeu serait sympa sur Ti89 et j'ai cherché. Sur ticalc.org, il y a bien un jeu de ce type, mais pour Ti-83, ce qui est plutôt gênant pour moi qui n'ait pas ce satané câble. Ayant quelques rudiments de C, je me suis donc lancé dans la programmation d'un Tower Defense il y a quelques semaines. Plusieurs amis de mon entourage l'ont essayé et m'ont bien aidé à l'améliorer. Ça reste toujours assez rudimentaire (tous les sprites sont "XORés" : pas de gestion avancée de l'écran, des ROMCalls et du sprintf à gogo, tableaux multi-dimensionnels (j'avais lu que c'était pas bien pour les performances)...), mais ça marche plutôt bien :-)

EDIT : J'ai oublié de préciser que quand vous jouez sans cartes, les ennemis ne tolèrent pas la moindre petite bidouille et ont tendance à voler au dessus des tours si vous les forcez à faire marche arrière à gauche. Avec une carte, les déplacements des ennemis sont stricts, mais si la carte comporte une boucle ou de grands espaces vides, les ennemis auront un comportement très désagréable pour celui qui fait la carte (avec une boucle, la moitié des ennemis refait un tour et peut même faire marche arrière, avec un espace vide le déplacement est totalement aléatoire).


L'accueil (sans blagues...)


Des ennemis tout gentils


Beaucoup d'ennemis peu espacés d'où une impression de "chenille"


Des ennemis volants !


Un boss tous les quatre niveaux. Pas spécialement dur, mais frustrant quand il passe au travers de notre belle défense. La vie des boss est affichée en temps réel.


Le jeu qui nous félicite de notre parcours


Téléchargement (sources incluses) : http://yannbng.free.fr/Divers/td.zip

Le fichier td.89z est le programme en lui-même, tdmap.89g contient toutes les cartes (ce sont des fichiers textes tout bête, pour créer une carte il suffit de recopier tdmap23 sur un fichier du type tdmapxx où xx et un entier compris entre 1 et 22 et de changer les 0 par des 1 là où on veut des emplacements avec des tours ; un fichier qui ne suit pas exactement ce à quoi le programme s'attend (10 colonnes et 16 lignes de '0' ou de '1') le plantera lamentablement) et le fichier tdtuto.89z contient le tutoriel pour comprendre l'interface du jeu un peu abrégée.

En plus des problèmes de code, l'affichage des chiffres se voit vite amputé quand on dépasse les trois chiffres sur la droite de l'écran, mais je vois pas comment régler ça...

Attention : les tours des touches '+' et '-' ralentissent. Elles sont très pratiques, mais ne font pas mal du tout ;-) À partir du niveau 22, vous avez fini tous les niveaux codés en dur. Le jeu crée donc des niveaux aléatoirement pour vous occuper.


Note importante : pour commencer chaque niveau, appuyez sur Enter. Le jeu n'enchaîne pas directement pour permettre au joueur de dépenser l'argent restant s'il le souhaite sans être stressés par les nouveaux ennemis.

Ca a l'air sympa mais je n'ai pas bien pigé comment fonctionne le jeu ...

Désolé, j'ai oublié le principal ; pour lancer les monstres, il faut appuyer sur Enter, ainsi qu'à chaque changement de niveau.
Sinon, le principe est simple : tu choisis une carte, avec ton argent tu achètes des tours en appuyant sur 1, 2, 3, 4, 5, 6, 7, 8, 9, + ou - (Seconde + la touche de la tour pour l'aide) qui tireront sur les ennemis. Je te conseille de suivre le tutoriel avant de commencer à jouer ;-)

Martial : merci :-)

EDIT : Ce sujet est-il dans la bonne section ? Après réflexion, la partie "Projets" semble mieux convenir, non ?

oh, excellente idée d'avoir porté ce jeu oncalc ; par contre avant de tester, un petit point noir : c'est vraiment très laid

Pas mal ton jeu Yann B. C'est ton premier jeu sur TI ??

Sinon Martial Demolins comme projet ( assez gros projet quand même ) tu connais le jeu Bubble Ghost sur Game Boy ?? C'est un jeu où tu est un petit fantôme et
tu dois souffler sur une bulle en évitant les pièges (bougies à éteindre, ventilateurs,... ) et parcourant ainsi les niveaux.
http://artofwar.free.fr/jeux/gb/bubble_ghost_gb.php

Et sinon (encore des projets plus conséquents) y'aurait des jeux comme WindJammers ou alors Metal Gear Solid sur GameBoyColor .... bon là j'avoue c'est ptet un peu trop demander : genre 1 an à développer chaque jeu .

Désolé, j'avais pas vu les réponses (le forum affichait toujours 3 réponses) ;-)

Pour la beauté des graphismes en eux-même, c'est hyper moche on est d'accord, mais je n'ai vraiment aucune imagination à ce niveau. Par contre, au niveau des XOR, j'ai essayé rapidement la combinaison OR/AND, et on dirait que ça pourrait marcher à condition de trouver un moyen d'épargner les tours après le passage des ennemis... Et pour compenser les pertes de vitesses, faudra bien un jour que je passe à fastitoa.h et drawline ; mais pour DrawText y a t'il quelque chose ?
Plus précisément, en dehors des sprites et du XOR, qu'est-ce qui est le plus critique ?
Sinon, rapidement je viens de penser que passer à une grille de 8 pixels permettrait d'unifier les graphismes avec/sans carte tout en gagnant en performances (congruences & divisions modulo 2^3 me voilà :-)), et aussi de gagner un peu de place sur la droite pour éviter d'avoir des textes qui dépassent.

Par contre, avec le BAC qui arrive, j'aurais moins de temps, mais la géographie me forcera à prendre des pauses sans quoi je risque de tomber dans la folie...

Pour les graphismes, je te suggère de te tourner vers des librairies graphiques qui font bien les choses, les deux les plus intéressantes et complètes sont, à mon avis, genlib et extgraph.

En matière de texte, le premier truc à faire, c'est de n'afficher que les trucs qui changent.
Après, tu peux gagner un peu de temps en faisant ton propre "sprintf" spécialisé.

Certains sprintf spécialisés sont disponibles à http://tict.ticalc.org/downloads/fastitoah.zip .

Pour ExtGraph, je rajouterai le lien vers la version supportée d'ExtGraph, qui a beaucoup de bugfixes et améliorations depuis la Beta 4: http://opensvn.csie.org/ExtGraph .
Les fichiers les plus intéressants sont dans lib/: headers + archives contenant le code compilé. src/demos contient les demos / exemples d'utilisation; src/lib contient les sources des fonctions de la lib.
(Tout peut être récupéré avec un client SVN, mais ce n'est pas obligatoire)

Merci beaucoup :-)
J'avais déjà essayé fastitoa, mais à l'époque les performances n'étaient pas trop améliorées ; mais étant donné que maintenant j'utilise beaucoup plus l'affichage de textes, ça pourrait être sympa. J'ai aussi regardé du côté extlib, je vais essayer :-)

Il y a aussi des routines plus rapides d'affichage des textes. Parmi les programmes de TICT (je parle de ce que je connais le mieux, mais il y en a d'autres ): ebook, TICT-Explorer et TI-Chess en utilisent.
Je ne sais pas trop lequel a les routines les plus à jour (= SetupCharSet en assembleur + routines de dessin en assembleur).

Je m'y suis un peu remis, le hic c'est que je sais pas dans quelle direction aller. J'ai modifié le code pour utiliser les fonctions d'extgraph, ce qui permet de gagner quelques ressources processeurs. J'ai essayé le double-buffering avec gray et le résultat est qu'avec ça, ça clignote, ce qui est le contraire du but recherché ;-)
Enfin, j'ai essayé d'arrêter le XOR au moins pour les ennemis, ça marche, sauf que faudra que je trouve un moyen de redessiner automatiquement les tours qui sont effacées par le passage des ennemis.
En fait, au niveau des graphismes en eux-même, je ne vois absolument pas que faire sur du 8x8, ou je tente un truc en forme de tour mais dans ce cas toutes les tours se ressembleront, ou je fais dans l'abstrait et à ce moment là, c'est laid. Idem pour les monstres...

En fait, plus précisément, qu'est ce qui est laid ? Un peu tout, évidemment, mais précisément, quel est le gros hic où il est possible de bien agir ?

J'ai essayé le double-buffering avec gray et le résultat est qu'avec ça, ça clignote, ce qui est le contraire du but recherché ;-)

Certes
Tu attends bien le bon nombre de plane switches ?

Il y a des fonctions dans ExtGraph qui permettent de sauvegarder et redessiner seulement certaines portions de l'écran... le problème est qu'elles sont peu documentées (il n'y a, en gros, que l'exemple d'utilisation demo22)

Yann B (./14) :
En fait, plus précisément, qu'est ce qui est laid ? Un peu tout, évidemment, mais précisément, quel est le gros hic où il est possible de bien agir ?

À mon avis ça tient à beaucoup de choses. En vrac, ce qui me vient à l'esprit :

- Tes sprites sont très basiques (des carrés, des croix, etc), limite au niveau de ce que tu aurais pu avoir avec un jeu en mode texte :/
- Le jeu est en noir et blanc là où tu pourrais utiliser des niveaux de gris, mais visiblement tu es en train de remédier à ce problème
- Les sprites font 8x8 pixels, difficile d'avoir quelque chose de joli avec cette taille-là (même si on peut quand même avoir beaucoup mieux que tes sprites actuels je pense); peut-être qu'il serait une bonne idée de faire tenir certains sprites comme les tours sur 2 ou 4 sprites, pour les détailler un peu plus
- Tu utilises des techniques dignes d'un programme en basic (afficher les sprites en XOR pour les effacer lors d'un déplacement, etc), alors que tout effacer et tout redessiner à chaque frame te permettrait tellement plus de liberté au niveau de l'affichage...

Tout effacer et tout redessiner n'est pas toujours efficace

si on utilise une bonne lib si (et ça permet d'avoir des animations, et c'est plus facile à programmer sans bug graphique)

c'est plus facile à programmer sans bug graphique

Ca, c'est clair.

et ça permet d'avoir des animations

Ca, c'est moins clair. Il n'est pas absolument interdit de faire des animations quand il y a save&restore: quand il y a eu une animation (il _suffit_ de programmer le moteur de jeu pour - j'ai pas écrit que c'était _toujours_ facile, cf. le premier point ^^), il ne faut pas restaurer les anciens sprites et il faut réinitialiser les sprites sauvegardés.
(En même temps, quelle est la proportion de jeux utilisant des fonctions d'animation du fond ?)

si on utilise une bonne lib si

Ca, c'est faux
J'ai créé demo22 d'ExtGraph SVN exprès pour être un contre-exemple flagrant à cette quote. demo22 met en perspective:
* un bourrinage de redessin intégral (utilisant le tilemap engine);
* un bourrinage de save&restore tant que le fond ne bouge pas (il bouge tous les deux ticks d'AI5, donc à un peu moins de 10 Hz avec les réglages par défaut).
Je veux dire par "bourrinage" qu'il n'y a aucune synchro avec l'écran (écriture directe dans les planes), et qu'il n'y a pas non plus un gaspillage de CPU pour simuler le moteur du jeu.

Evidemment, le mode intelligent, comprenant save&restore, fait plus de frames en 15s. Même si comme je viens de l'écrire, dans un programme réel, l'écart serait moindre.
Si j'avais utilisé des sprites préshiftés pour le mode bête, le mode intelligent serait quand même plus rapide. Ce n'est pourtant pas que les fonctions d'ExtGraph, que ce soit le tilemap engine ou les sprites préshiftés, sont lentes

Lionel Debroux (./19) :
Ca, c'est moins clair. Il n'est pas absolument interdit de faire des animations quand il y a save&restore: quand il y a eu une animation (il _suffit_ de programmer le moteur de jeu pour - j'ai pas écrit que c'était _toujours_ facile, cf. le premier point ^^), il ne faut pas restaurer les anciens sprites et il faut réinitialiser les sprites sauvegardés.

Mais du coup à cause de ces sauvegardes/restaurations c'est plus lent quand il faut mettre à jour les animations : tu échanges de la performance dans le meilleur cas au détriment de la performance dans le pire des cas, c'est une mauvaise idée pour la fluidité.

si on utilise une bonne lib si

Ca, c'est faux
J'ai créé demo22 d'ExtGraph SVN exprès pour être un contre-exemple flagrant à cette quote. demo22 met en perspective:
* un bourrinage de redessin intégral (utilisant le tilemap engine);
* un bourrinage de save&restore tant que le fond ne bouge pas (il bouge tous les deux ticks d'AI5, donc à un peu moins de 10 Hz avec les réglages par défaut).
Je veux dire par "bourrinage" qu'il n'y a aucune synchro avec l'écran (écriture directe dans les planes), et qu'il n'y a pas non plus un gaspillage de CPU pour simuler le moteur du jeu.

Evidemment, le mode intelligent, comprenant save&restore, fait plus de frames en 15s. Même si comme je viens de l'écrire, dans un programme réel, l'écart serait moindre.
Si j'avais utilisé des sprites préshiftés pour le mode bête, le mode intelligent serait quand même plus rapide. Ce n'est pourtant pas que les fonctions d'ExtGraph, que ce soit le tilemap engine ou les sprites préshiftés, sont lentes

J'ai pas essayé, mais je crois comprendre que tu cherches juste à optimiser pour le cas moyen : si oui c'est un peu bête, à moins d'avoir un jeu extrêmement gourmand en AI ça n'avance à rien d'afficher 3x plus rapidement quand il n'y a pas grand chose qui change. Il faut concentrer ses efforts sur le pire cas, c'est lui qui va déterminer si c'est fluide ou saccadé ; si la lib est performante et que les graphismes sont pas hyper compliqués, ça donnera aussi une solution 100% satisfaisante pour le meilleur cas, donc s'embêter avec des restaurations partielles ça ne vaut pas le coup.

Si je peux me permettre:
Le jeu fonctionne sur V200, si ce n'est les touches. Remplacez les codes de touches par les constantes:
KEY_LEFT
KEY_UP
KEY_DOWN
KEY_RIGHT
et le programme marchera sur V200.

Sinon, j'aime également jouer à Vector TD et Vector TDX (la version 2), et je trouve ce jeu très réussit.

Cordialement,
ProgVal

En fait, j'ai essayé ces constantes, mais je ne sais pas comment les utiliser dans un switch : si je mets case KEY_UP, le compilateur me répond : "error: case label does not reduce to an integer constant"....

Sinon, merci pour les conseils :-)

Il faut utiliser if, switch n'accepte pas les pseudo-constantes.

Ca c'est une super bonne idée de jeu

Tiens tu existes encore toi

Yann B : Pour les fonctions d'affichage de chaînes, il existe une fonction assez rapide dans GraphX, mais il faudra que tu la compares aux autres pour choisir quelle bibliothèque adopter. Je ne sais pas ce qu'elle vaut précisément, mis à part qu'elle défonce les fonctions d'AMS.

Sauf que GraphX est totalement inutilisable de nos jours car incompatible Titanium et comme tu as perdu les sources, bah impossible de corriger ça.

Plusieurs softs de TICT (dont ebook, TI-Chess, TICT-Explorer 1.40 Beta) contiennent des routines rapides qui fonctionnent sur tous modèles, y compris PedroM.