Discussion :

[CodeurPlusPlus]

Bonjour,

je présente mon jeu pour le Week-end "développez un jeu en 48 heures".

Nullotron sera un clone de Llamatron en moins bien et, notamment, en atrocement plus mal dessiné (d'où son nom).

Llamatron était un jeu d'arcade vue de haut, dans lequel on tirait sur tout ce qui bouge. Il y avait des couleurs clignotantes qui faisaient joyeusement mal aux yeux et un grand nombre de sprites... vraiment, ça pétait de partout !

L'originalité de la version arcade (personnellement je n'ai pu y jouer que sur Atari ST) était qu'il y avait deux joysticks, l'un pour contrôler les déplacements du personnage, l'autre pour contrôler la direction des tirs. On pouvait donc avancer dans une direction tout en tirant dans une autre direction.

Cette nuit j'ai plus ou moins terminé un petit framework ainsi que les premiers dessins... et demain j'attaque la programmation du jeu lui-même.

EDIT : en pièce jointe une nouvelle version du jeu avec un gros bug en moins.

[Cirrus Minor]

L'originalité de la version arcade (personnellement je n'ai pu y jouer que sur Atari ST) était qu'il y avait deux joysticks, l'un pour contrôler les déplacements du personnage, l'autre pour contrôler la direction des tirs. On pouvait donc avancer dans une direction tout en tirant dans une autre direction.

Héhé C'est sur cette particularité qu'est basé le gameplay de mon jeu - mais en limitant à 4 directions les tirs (donc pas de diagonales).

Bonne chance avec ton projet !

[CodeurPlusPlus]

Le mien aussi n'aura des tirs que dans quatre directions... parce que pour faire tout en huit directions il me faudrait dessiner deux fois plus de sprites, et, pour moi, dessiner, c'est pas vraiment un plaisir

En plus j'ai écrit une bêtise dans la présentation de mon jeu. Llamatron n'a jamais existé en borne d'arcade, mais était un clone sur ordinateur du jeu Robotron : 2084, qui, lui, avait une version arcade présentant la particularité des deux manettes.

[Dabou Master]

Bon courage dans ton projet CodeurPlusPlus !
(oui je fais le tour des sujets du 48h et je dispense mes encouragements, inutile mais hey ça prouve que j'ai lu ton sujet ! ^^)

[CodeurPlusPlus]

NULLOTRON.zip

J'ai terminé !

[CodeurPlusPlus]

MODE D'EMPLOI DU .ZIP du post précédent :

il contient les sources du jeu (et d'un petit framework)

Pour le compiler il vous faut la SDL 1.2.

J'ai écrit et testé le jeu avec Cygwin. On devrait pouvoir le compiler aussi sous Linux mais je n'ai pas testé.

Dans le sous-répertoire gll/nulltron se trouvent :

- NULLOCYG.exe

l'exécutable compilé chez moi, c'est à dire sous Windows XP + Cygwin

- un makefile

Il suffit de lancer la commande make pour compiler (si vous avez SDL 1.2). L'exécutable généré se nomme nullotron.exe

Si vous lancez le programme en ligne de commande, vous pouvez ajouter un entier facultatif qui sert de random seed.


Une petite vidéo arrive...

Mais elle ne sera pas prête avant la deadline.

[SylvainPV]

Oula il faudrait une version exécutable Windows parce que je me sens pas le courage de compiler le bazar moi

[CodeurPlusPlus]

Votre souhait est exaucé !

[CodeurPlusPlus]

J'ai supprimé un méga-bug qui restait dans la version que j'ai rendue pour le week end de programmation d'un jeu vidéo en 48 heures. La nouvelle version (exécutable pour windows) est dans la partie "EDIT" du premier message du topic.

On déplace le personnage avec les flèches. On choisit la direction de tir avec d, x, c et v.

Amusez-vous bien !

[CodeurPlusPlus]

Et une vidéo de démo (et de blabla sur tout le bien que j'ai pensé du WE-JV 4) :

Rendez-vous dans un an pour le WE-JV 5. Je sais déjà que j'y participerai.

[yetimothee]

Salut,
tu utilises un timer pour fixer le nombre d'images par seconde de ton jeu ? Pour moi tes ralentissements c'est un problème de performances, et peut-être justement parce que tu n'utilises pas ce genre de techs... Du coup tu calcules bien plus que 60 images par seconde (pour un tel jeu 30 devraient suffire) et le pc tiens pas le coup...

[CodeurPlusPlus]

Bien vu yetimothee !

Dans mon jeu il y a des délais fixes pour à peu près tout... sauf pour les mises à jour de l'affichage.

Ma stratégie consistait à calculer la durée de chaque mise à jour de l'affichage et de choisir en fonction de cette durée la date de la mise à jour suivante... ce qui semble effectivement poser le problème que tu soulèves.

Je viens de tester un truc tout simple : je fais le même calcul... mais avec une borne inférieure de 16ms (si le calcul d'un frame a duré moins de 16 ms, je fais comme s'il avait duré 16ms) et là, tout de suite, le frame rate semble bien plus régulier !

Mais du coup ceci, ainsi que d'autres idées qui me sont venues à l'esprit cet après-midi, me donnent envie de faire plein d'autres trucs, qui se trouveront peut-être dans Nullotron II, et sûrement dans d'autres jeux. Parce que depuis le week-end jeu vidéo, j'ai eu une sorte de révélation : je veux passer une grosse partie de mon temps libre à programmer des jeux, ce que j'avais commencé à faire très timidement, mais là maintenant j'ai envie de tout apprendre et, à moyen terme, de tout défoncer !

Bon, c'est pas encore ça mais ça m'éclate de me frotter à un domaine dans lequel je suis encore pas au point du tout... j'ai l'impression de revenir quelques années en arrière mais avec une excitation bien plus grande.

[LittleWhite]

Mais du coup ceci, ainsi que d'autres idées qui me sont venues à l'esprit cet après-midi, me donnent envie de faire plein d'autres trucs, qui se trouveront peut-être dans Nullotron II, et sûrement dans d'autres jeux. Parce que depuis le week-end jeu vidéo, j'ai eu une sorte de révélation : je veux passer une grosse partie de mon temps libre à programmer des jeux, ce que j'avais commencé à faire très timidement, mais là maintenant j'ai envie de tout apprendre et, à moyen terme, de tout défoncer !

Ah ! La classe

Pour les updates, je vais vous expliquer une histoire autour de TetrisCommand.
Au début, je faisais l'update du jeu et son affichage autant que je pouvais. C'est cool, ça dépote, on atteint genre du 200 FPS. Par contre, vous avez vu, la chute des blocs ne se fait pas par a coup, il n'y a pas de tour par tour, ni rien. Par contre, dès que l'on modifie le FPS, alors là ... la cata.
En effet, sur un PC, à 60 FPS, il fera 60 "+1" sur la position du bloc par seconde. Sur un autre, à 200 FPS, il fait 200 "+1" sur le bloc et cela en une seconde aussi. La catastrophe, surtout qu'aucun PC, dans ce mode, n'est capable de tenir un nombre stable de FPS.
La solution ultra classique, c'est de dire : ok, je sais que 60 FPS équivaut à un temps de 15,6ms par passage dans ma boucle. Donc je calcule le temps passé dans ma boucle et j'attends les N millisecondes qui reste. Ouep, c'est ok, ça marche, disons, ça marchouille. Lorsqu'un PC est faiblard, il va tourner à 40 FPS, et on aura le même soucis (un jeu plus lent et toujours pas fluide). De plus, les fonctions de mesure du temps sont un peu bancales (pas toujours précise), mais généralement, sur ce point, on va dire que ça va).

Une autre astuce, c'est de dire, ok, on repars sur une update sans limitation (on ne fera pas de sleep). On calcul toujours le temps entre deux appels à update. Ce temps, va être pris en compte dans la fonction update pour déterminer la vitesse de chaque élément. Ainsi, si un PC va ultra vite, le temps entre deux appels sera ultra court, du coup, la vitesse de l'élément sera très faible. Un PC qui va lentement, aura moins d'update, mais la vitesse à chaque update sera plus grande. Au final, on obtient un résultat où, chaque PC possède la même vitesse. Chaque seconde, vaut bien une seconde, sur tous les PCs.

Par contre, à cette théorie, il manque une dernière partie, que je ne gère pas . Mais pour mon jeu c'était suffisant.

Il y a un article sur ces histoires, ici : http://dewitters.koonsolo.com/gameloop.html

[Kannagi]

Pour les FPS un simple SDL_Delay(tempsrestant) peut suffire (si on calcul bien le temps ).
Je déconseille les autres technique pour gérer les FPS , pour la précision du SDL_Delay/GetTicks j'ai jamais vu qu'elle manquait de précision au point d'avoir de gros écart de FPS.

Sinon pour ton jeu , je le trouve pas mal il est fini et fonctionnel ^^

[yetimothee]

Avec sleep il faut faire attention à bien calculer le temps de traitement de ta boucle. Ça donne (en pseudo pseudo code, et bon, c'est évident) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
while(le jeu tourne) {
    temps_avant = getTime();
    Traitement;
    Affichage;
    temps_de_traitement = getTime() - temps_avant;
    sleep(1000 / 60 - temps_de_traitement); // Si on considère que tu veux 60 ips et que le temps est en ms.
}

J'ai un ami qui gère le temps en activant la synchronisation verticale... Tant que tu fais pas ça t'es sauvé !