Forum TI-Planet.org

Dans le jeu d'origine, les gardes calquaient leurs mouvements verticaux sur ceux du personnage tant qu'ils n'étaient pas suffisamment près. C'était probablement fait pour gagner de la vitesse (pas besoin de faire un parcours complet pour trouver un éventuel chemin...)
Ils étaient un peu plus lents que le personnage... mais là, la différence est vraiment trop grande.
Ils ressortaient des trous assez rapidement : en pratique, on pouvait creuser 3 trous dans lesquels tombaient 3 gardes puis passer par-dessus... mais pas 4 car le 1er garde se relevait avant qu'on ait franchi le 4ème trou.

On doit pouvoir retrouver le code original (en Basic) dans de vieux magazines de l'époque (Bidouille grenouille, il me semble).

Bisam a écrit:Dans le jeu d'origine, les gardes calquaient leurs mouvements verticaux sur ceux du personnage tant qu'ils n'étaient pas suffisamment près.

Peut-être un algorithme naïf tentant de minimiser les écarts en abscisse et en ordonnée ?
Avec éventuellement une priorité à la direction verticale lorsque l'on est sur une échelle, car sinon ils arriveraient rarement à monter/descendre l'échelle, le personnage n'était que rarement juste à la verticale.

La version 1.2 est en ligne
les gardiens sont maintenant moins compliqué à contrer.
Il faut faire en sorte qu'ils ne vous voient pas (en ligne droite) et ca devrai etre beaucoup plus jouable.
Mais si l'un d'eux vous vois il fait rapliquer les autres.
Il y a bien sur une petite dose de hazard dans le tout pour que quoi qu'il arrive , un niveau ne se jouera
jamais deux fois de la même maniére

Bon amusement.

Bon , pour la suite je vais prendre en compte les remarques de Bisam .... c'est pertinent et la saperlipopette à programmer
Pour le moment si quelqu'un veut des gardes plus rapide il suffit de reduire la valeur de la variable GardSpeed (ligne 134) dans main.h.
Concernant la vitesse de 'refermeture' des trous il faut reduire la valeure de la variable TrapTimer (ligne 106) dans main.h et ... recompiler

@darthvader Petite question, tu tiens absolument à utiliser des appvars ?

Parce que si il n'y a pas le projet de développer des éditeurs plus tard pour permettre de la personnalisation, il faut éviter les appvars pour des données essentielles sur TI-83 Premium CE, et migrer ces données vers le programme.
Un programme plus gros n'est plus un inconvénient sur TI-83 Premium CE depuis que TI a rajouté la possibilité d'exécuter les programmes archivés.

L'ennui avec les appvars sur TI-83 Premium CE, c'est qu'elles sont définitivement effacées à chaque activation du mode examen. Donc potentiellement chaque semaine en série S, entre les Maths et la Physique-Chimie. Et si ces appvars contenaient des données essentielles, les programmes concernés restaurés en fin de mode examen seront donc totalement inutilisables, nécessitant un nouveau transfert des appvars.

Je comprends bien que ce soit propre en théorie, mais c'est un mauvais choix du point de vue utilisateurs dans le contexte de la TI-83 Premium CE.
Après ne le prends pas personnellement. Ton jeu est loin d'être le seul à avoir ce défaut. Faire changer les habitudes c'est dur.

Portal CE est particulièrement bien pensé par rapport à ça. Car il fait une distinction entre les niveaux d'origine qui sont bien intégrés au programme, et les niveaux additionnels. Donc en fin de mode examen, certes tu perds les niveaux additionnels, mais le programme reste utilisable puisque contenant toujours ses niveaux d'origine.

Wah

Pour étre honnète ... j'ai rien compris

J'avais remarqué une limitation au niveau de la taille max des fichiers *.8xv à 64kb.
Si je voulais par example tout integrer avec un fichier Level.h dans le code source je me retrouverais avec un truc du genre :
28k pour le jeux en lui meme + 13k pour les sprites + 22k + 33k + 33k + 33k + 33k pour les 350 levels d'origine.
Ca fait quand meme dans les 195ko que je ne sais pas comment caser dans 64ko
J'avoue que je ne connais pas trop le systeme TI , mais si c'est possible que les fichiers programmes *.8xp puissent dépasser 64ko alors j'ai juste
à modifier mon editeur de niveaux pour me sortir tout les fichiers *.h necessaire des levels d'origine ....

Ma remarque ne tenait pas compte de la taille.
Si tes appvars font plus de 64K il est clair que les données ne rentreront pas, du moins pas sans compression.

Mais bref, si tu n'as rien compris alors en une seule phrase :
En l'état, un élève de série S, soit une majorité des utilisateurs de TI-83 Premium CE, aura besoin de réparer ton jeu chaque semaine (connexion à l'ordinateur + retransfert de toutes les appvars).

Nul doute qu'ils finiront tous par en avoir marre plus ou moins rapidement, ce qui limitera le succès de ton jeu. C'est dommage.

Même si je suis aussi du parti de mettre les données requises/essentielles au sein du programme principal (jeu ou autre), de toute manière tous les utilisateurs de programmes utilisant les libs C devront les retransférer, donc c'est pas si grave d'avoir un truc en plus ou en moins à faire, en fin de compte...
A la limite, ils peuvent même se faire un dossier sur leur bureau ou autre avec tout un "pack" de choses prêt à drag'n'drop sur TI-Connect.

Le mieux serait que TI désactive les appvars plutôt que de les supprimer, mais bon, bonne chance pour leur faire faire ça

Mais sinon, je doute que beaucoup d'élèves passent en PTT chaque semaine - il faudrait faire un sondage ici

Adriweb a écrit:Mais sinon, je doute que beaucoup d'élèves passent en PTT chaque semaine - il faudrait faire un sondage ici

Possible que la part concernée augmente significativement d'ici l'année prochaine.