Discussion :

[b Oo]

Bonjour à tous,
je voudrais réaliser un jeu de tennis en "2D" dans le style des jeux de tennis qui se faisaient avant.
Je pense à Sampras 96 et à Final Match Tennis qui est un très bon jeu pour l'époque.
Je maîtrise le C++, connaît quelque patterns comme :
singleton, stratégie, adaptateur, prototype, fabrique
Le problème est qu'il me faut un moteur de jeu et là que je ne sais pas comment m'y prendre.
J'aimerais qu'il soit bien décomposé et avoir un "beau design".
Que doit faire mon moteur ?

• gerer les déplacements de mes joueurs et de la balle ?
• gerer les sprites ?
• gerer le son ? (si c'est le cas, je verrais plutôt une classe qui s'en occupe et le moteur appelle les méthodes qu'il a besoin
• c'est lui qui re/dessine la scène à chaque itération ?
• l'IA ?

Il va falloir que je gère de la pseudo-3D (je ne sais pas quel est le terme exact) pour avoir l'impression que la balle flotte dans les airs.
Il faut rajouter une variable z pour la "hauteur" non ?
J'aimerais pouvoir régler le comportement de la balle, cela est-il faisable ? (moteur physique ? meme si c'est lourd ca me fera un exemple)
Sinon je compte le faire avec SDL et multi-plateformes (Linux-Windows). Le choix de SDL est-il le bon ?

Je voudrais lui apporter également un mode multijoueur, je le ferais plus tard mais je veux que mon design le prenne en compte.

Merci d'avance pour les réponses.

[Ti-R]

Oui SDL est un bon choix, surtout pour un début.

Et il est largement possible de faire ce que tu souhaites faire avec.

Donc bon départ à première vue, bonne chance et ne perd pas courage

[Sivrît]

J'aimerais pouvoir régler le comportement de la balle, cela est-il faisable ? (moteur physique ? meme si c'est lourd ca me fera un exemple)

Le moteur physique est quand même plutôt overkill. Et je ne sais pas s'il sera capable de gérer les effets (ce que ne devaient pas faire les vieux jeux), parce que sans ça tout ce qu'il faut c'est l'équation de la chute libre.

Dans tous les cas en insérant quelques paramètres (gravité, énergie perdue lors des rebonds) dans la formule il sera possible de jouer avec. Et en codant bien une fonction qui met à jour l'état de la balle la formule pourra être altérée assez facilement pour les modifications extrèmes.


En règle générale, pour refaire tous les vieux jeux 2d sans dépendre d'un OS SDL est LE bon choix. Faudrait mettre ça en entête du forum


Le multijoueur, c'est réseau ou local ? Le second cas est simple, le premier moins (et mieux vaut savoir où on va lors de la conception).

[b Oo]

Ben les 2, mais ma question portait sur le réseau.
Je voudrais pouvoir coder mon jeu sans faire le réseau, et avoir une version jouable à 1-4 en local. Après je coderais le réseau donc je veux qu'il vienne se greffer à mon jeu sans modifier le code actuel.

Il va falloir que je prenne en compte donc comment réaliser le réseau mais je ne suis pas énormément de compétences dans ce domaine.

Je devrais utiliser les sockets, non ?
Il faut que le jeu envoie des informations au différents joueur lorsque ceux-ci bougent et lorsque la balle change. Pour la balle, par exemple, je pensais que comme je peux connaitre la trajectoire je n'ai qu'à envoyer ses coordonnées de départ et d'arrivée ainsi que sa vitesse.
Pour les joueurs dès qu'il se déplace dans une direction j'envvoie la direction et je le fais déplacer tant qu'il n'y a pas eu de nouveaux évènements (touche relachée, ...).
Cette approche va t-elle donner des problèmes de décalage (ie on va avoir l'impression qu'un joueur se téléporte) ?

Je voudrais savoir comment vous feriez pour afficher à l'écran.
Je dois diviser le terrain en petite cases où je peux travailler par zone ?
Pour les graphismes, je donne un carré à mon moteur et il me donne le carré en perspective où je fais déjà des images avec la perspective ?

[Sivrît]

Il va falloir que je prenne en compte donc comment réaliser le réseau mais je ne suis pas énormément de compétences dans ce domaine.

C'est à dire que, hum, moi non plus

Je devrais utiliser les sockets, non ?

Ouaip. Après il faut voir s'il y a des API (je crois que SDL a qqc dans ce domaine) qui peuvent décharger d'une partie du travail.

Il faut que le jeu envoie des informations au différents joueur lorsque ceux-ci bougent et lorsque la balle change. Pour la balle, par exemple, je pensais que comme je peux connaitre la trajectoire je n'ai qu'à envoyer ses coordonnées de départ et d'arrivée ainsi que sa vitesse.

Effectivement comme c'est très déterministe ça va simplifier. Par contre il faudra gérer le temps avec soin (la trajectoire va dépendre de la finesse des calculs, donc il faut s'abstraire du nombre de fps ou le fixer).

Pour les joueurs dès qu'il se déplace dans une direction j'envvoie la direction et je le fais déplacer tant qu'il n'y a pas eu de nouveaux évènements (touche relachée, ...).
Cette approche va t-elle donner des problèmes de décalage (ie on va avoir l'impression qu'un joueur se téléporte) ?

Le problème va se poser quel que soit le mode de gestion des déplacements. En LAN ça va à peu près mais sur le net un PING de 200ms est normal. Donc si les machines des joueurs doivent être totalement synchro ça fait 5 images par seconde. Si le jeu en fait plus on se retrouve dans des cas où une machine distante dit "A l'instant T le joueur 2 part vers la gauche"... hors ce message arrive à T+200ms par exemple. C'est la gestion de ce genre de cas qui est délicate si on veut éviter de multiplier les téléportations.
Une idée serait peut-être de faire aller plus vite le joueur pour qu'il rattrape sa position réelle. Ca serait plus délicat mais plus discret, la téléportation servant dans les cas désespérés. En tout cas ça rajoute au moteur le concept de personnages avec dédoublement de personnalité : "Je suis là mais on me voit là bas". Et ça ne résoud pas l'arrêt... on le fait courrir dans l'autre sens ?

Je voudrais savoir comment vous feriez pour afficher à l'écran.
Je dois diviser le terrain en petite cases où je peux travailler par zone ?
Pour les graphismes, je donne un carré à mon moteur et il me donne le carré en perspective où je fais déjà des images avec la perspective ?

Perso, si c'est pour refaire un truc comme sur mon Amiga, le terrain de tennis serait une image que j'afficherais en arrière plan au début de chaque frame. La seule contrainte étant que le 'terrain' lui même (là où peut rebondir légalement la balle) ait une forme qui respecte la perspective pour éviter les migraines avec la pseudo 3d de la balle. Et aussi le filet doit être à part pour être affiché au dessus des joueurs du fond.


J'espère que ça aide.

[b Oo]

Merci pour toutes les réponses Sivrît.
Je vais partir dans cette optique et si j'ai de nouveaux problèmes je viendrais en faire part.

Merci encore.