Discussion :

[MoDDiB]

Chibis Bomba est un bomberman-like nouvelle génération crée par l’équipe Blu-pix dont je suis le lead programmer.

Le jeu étant désormais jouable,
je vous propose de suivre les derniers mois de développement via ce sujet du forum qui sera une sorte de journal de bord.

Voici une vidéo récente, afin de vous faire une idée de l’avancement du projet.
[ame="http://www.youtube.com/watch?v=2pzdBBQuLsk"]QuickVideoDemo.wmv - YouTube[/ame]



Informations techniques :
XNA/C#
Moteur en développement depuis novembre 2009.
Un projet d’une durée d’un an a été réalisé avec le moteur ( http://www.developpez.net/forums/d10...chibis-escape/ )

Voici le changelog depuis le 30 janvier 2012 pour les personnes intéressées :
https://docs.google.com/document/pub...Zf01dMmfMP0CGU

Voici un extrait de documentation du projet, si ça peut intéresser des gens :
https://docs.google.com/document/pub...QMUx5G1tex0EGo

PS : le jeu est ici présenté majoritairement sous sa facette technique,
mais il est le résultat d'une incroyable équipe, artistique notamment,
qui essait de concrétiser un rêve depuis 2007 : si la genèse du projet vous intéresse voici 50 pages de forums :
http://www.3dvf.com/forum/3dvf/WorkI...jet_1044_1.htm

Recrutement :
Ce post n’a pas pour but de recruter,
toutefois si vous avez de l’expérience dans le domaine du jeux vidéo,
que vous avez déjà réussi à bosser au moins 5 heures par semaines sur un projet amateur,
il est possible d’en discuter mais les perles sont rares et occupées de nos jours

[fearyourself]

Le jeu a l'air très bien. En plus, il a l'air assez bien fini ce qui est pas mal.

Bon courage,
Jc

[saturn1]

Cool j'aime bien les graphismes.


Allez donnes nous ton secret pour trouver des graphistes qui lachent pas le morceau^^?

[MoDDiB]

Allez donnes nous ton secret pour trouver des graphistes qui lachent pas le morceau^^?

Le secret c'est la persévérance :
j'ai passé 7 ans à chercher des graphistes :/

[Dabou Master]

ça c'est amusant, moi je suis un graphiste (certes amateur, donc non reconnu) qui cherche un projet sérieux depuis un petit moment déjà ^^. Comme quoi personne ne trouve son compte ici screugneugneu !

(Après avoir farfouillé dans le lien vers 3dvf : ah oui ! quand même ! Deevad c'est pas n'importe qui en même temps, je ne fais pas le poids ^^, pas fini de galérer moi tiens).

[nouknouk]

Juste excellent !

Le développement semble en être à un stade relativement avancé et donne envie d'en apprendre plus. Malheureusement je n'ai ni le temps (ni trop l'envie, j'avoue) de me taper 50 pages de forum ; penses-tu que tu pourrais nous en faire un rapide résumé en quelques lignes (fait / en cours / à faire) ? Après tout, t'a commencé à poster, faut assumer maintenant


[petit HS] Ca me rappelle en creux les posts d'un concept similaire, Galaxy Batlle Arena, qui avait beaucoup communiqué, et semblait prometteur avec ses visuels sympas. Mais il n'a apparemment débouché sur rien, faute de développement concret. [/petit HS]

Heureux de voir qu'ici les deux aspects, développement & graphismes sont menés de front et que l'ensemble a toutes les chances d'aboutir

[MoDDiB]

Malheureusement je n'ai ni le temps (ni trop l'envie, j'avoue) de me taper 50 pages de forum

Oui, je me doute, j'ai surtout mis ce lien à titre informatif.
Je vais essayer de lister ce qui a été fait mais je vais en oublier forcément :
- Material batching
- Deferred shading
- Shadow
- Octree
- Moteur physique
- Préchargement des assets
- Export/import binaire
- Pooling afin d'éviter toute allocation durant la boucle update ( vital sur Xbox en XNA )
- Optimisation binaire du chargement des modèles animés
- Particules
- Wrapping des inputs
- Triggers
- Gestion d’acteurs : états + actions ( une action = conditions/animation/effets associés )
- Scripting en C# ( avec possibilité de mise en pause d’un script )
- Editeur de niveaux
- Editeur d’acteurs
- Editeur de particules

Ce qu'il reste à faire :
- Divers éléments du gameplay à ajouter ( nouvelles bombes et bonus )
- Gestion de victoire d'un joueur
- Ajout d'une IA
- Ajout de multijoueurs en ligne ( rien dans le moteur n'est prévu pour : je me laisse un mois pour tester si l'on garde cette feature ou non )
- Travailler le mode aventure pour le rendre plus intéressant.

[MoDDiB]

Voici une vidéo illustrant les bugs relevés durant la dernière session de jeu:
[ame="http://www.youtube.com/watch?v=cI_gwJ_1GAo&feature=player_embedded"]Bugs en série 1 - YouTube[/ame]

La plupart sont/seront corrigés ce soir.

[saturn1]

Pour le mode reseau UDP?(enfin ca semble assez obvious mais bon..)

Il y a une surcouche sympa a faire avec UDP si je me souviens bien...

[MoDDiB]

Pour le mode reseau UDP?(enfin ca semble assez obvious mais bon..)

Il y a une surcouche sympa a faire avec UDP si je me souviens bien...

Oui, je vais utiliser lidgren !

[saturn1]

ca a l'air cool je ne connaissais pas....

En faite je me disais unity 3.5 font beaucoup de pub en ce moment pour la concurrence notamment cryengine 3.

Mais en faite tout le monde fear le moteur de MoDDiB^^

[MoDDiB]

ca a l'air cool je ne connaissais pas....
En faite je me disais unity 3.5 font beaucoup de pub en ce moment pour la concurrence notamment cryengine 3.
Mais en faite tout le monde fear le moteur de MoDDiB^^

Faire son propre moteur maison est une décision "idiote" que j'ai prise uniquement par défi technique ; si le but est de finir un jeu, c'est à éviter.

[nouknouk]

- Ajout de multijoueurs en ligne ( rien dans le moteur n'est prévu pour : je me laisse un mois pour tester si l'on garde cette feature ou non )

C'est plutôt complexe et ça doit normalement être pensé dès le départ car ça implique des choix dans l'archi de pas mal de code dans le moteur de jeu. Donc dans ton cas, c'est pas idéal.

Amha, le bon point de départ serait de voir comment s'arranger pour que le déroulement des actions dans le jeu soient en quelque sorte 'historisées' sur une courte période (passée et à venir). Ainsi, au lieu d'avoir uniquement l'instant présent, on stocke ce qu'on a eu au cours des dernières secondes, et éventuellement ce qu'on sait qui devra arriver dans les prochaines secondes.

Cela te permettra notamment de pouvoir revenir en arrière quand tu recevras un peu trop en retard une action d'un autre joueur et 'corriger le tir' pour réconcilier entre les différents joueurs.

Pour le mode reseau UDP?(enfin ca semble assez obvious mais bon..)

Pas si obvious que ça.

D'un côté UDP a le don de beaucoup, beaucoup, beaucoup complexifier les choses ; ça peut éventuellement être aténué si on utilise une lib déjà toute faite (qui est en elle-mêmpe bien plus complexe à faire qu'un bomberman entier amha). Or ce ne sera pas ton cas si j'ai bien compris puisque tu veux du 'home made'.

A contrario, TCP est loin d'être aussi inadapté que ça pour un Bomberman like, où les besoins en temps réel sont certes présents mais pas à un degré aussi extrême qu'un FPS ou autre truc dans le genre. Le meilleur argument est un exemple concret, sous Flash qui - bien que manifestement pas tip top implémenté au niveau de la couche réseau (oui, j'ai un peu fouiné avec Ethereal), se débrouille déjà plutôt très bien. Et encore mieux quand on comprend que les comms passent par des serveurs éliogné (USA si mes souvenirs sont bons).

Voilà pour mon demi HS du jour ; en espérant que tu pourras piocher dedans quelques petit trucs qui t'aideront à avancer.

[MoDDiB]

C'est plutôt complexe et ça doit normalement être pensé dès le départ car ça implique des choix dans l'archi de pas mal de code dans le moteur de jeu. Donc dans ton cas, c'est pas idéal.

Oui ça va être véritablement un casse-tête mais je vais utiliser lidgren qui fait de l'udp reliable.

J'avais prévu aussi d'aller au plus simple ce qui devrait donner de bons résultats si le ping est correct :
un des joueurs est le serveur et calcule TOUT : les clients ne font qu'envoyer leurs inputs et reçoivent les positions du serveur ( même la leur ) sensiblement en retard avec une petite interpolation pour les valeurs intermédiaires.
Pour le moment je me fiche de la sécurité, du changement d'hosting et la gestion des latences élevées : ma simple méthode semble-t-elle viable ?

[nouknouk]

Pour le moment je me fiche de la sécurité, du changement d'hosting et la gestion des latences élevées : ma simple méthode semble-t-elle viable ?

Je le pense, surtout si tes joueurs ne sont pas à l'autre bout de la planète.

J'avais envisagé exactement ce mécanisme sur du TCP pour un système de jeu genre Micromachines like et les premiers tests étaient concluants (alors même que je faisais passer les paquets par un serveur intermédiaire en plus, alors que dans ton cas, si j'ai bien compris, tu fais tout en P2P).

Une petite astuce à deux balles, mais qui peut changer pas mal de choses: plutôt que prendre en compte les actions du joueur sur le périphérique d'input (joystick/clavier) et les appliquer immédiatement dans le jeu, bufferise très légèrement ces actions pour les jouer avec un petit retard, même en local.

Concrètement: au temps T joueur 1 appuie sur la touche 'haut' ; ordi 1 stocke cette action et ne commencera à faire réellement bouger le perso 1 que à (T + 50ms). Pendant ce temps, l'ordre 'aller vers le haut' sera envoyé dès (T) vers Ordi 2.

50ms, ce sera quasi imperceptible pour Joueur 1 (ça représente trois images sur un écran classique à 60 Hz), mais ces 50ms représentent à elles-seules plus que la latence moyenne entre deux joueurs situés sur le même continent. Donc au moment où on commencera réellement à bouger Perso 1, on l'aura déjà reçu sur Ordi 2 qui pourra donc le faire exactement en même temps que Ordi 1.

Après, les 50ms ne sont qu'un exemple, il faut bien sûr faire quelques tests pratiques pour trouver la valeur qui représente le meilleur compromis entre le confort du joueur et le gain en latence.

PS: si tu fais une recherche dans mon historique de posts sur DVP avec des mots clefs comme 'TCP', 'latency', 'reckoning', ... tu devrais déterrer quelques posts plus étayés à ce sujet et des liens très instructifs (genre celui qui décrit le fonctionnement du moteur réseau de Counter Strike, ...) (exemple).

PS2: un excellent moyen pour simuler les conditions d'un réseau 'dégradé' et tester ainsi la robustesse de son moteur réseau est d'utiliser linux et un module qui permet énormément de choses en deux lignes de commande: NETEM. Ca te permet par exemple d'ajouter artificiellement de la latence, de la gigue (ie. variation de la latence dans le temps), de la perte de paquets, etc... et de tout paramétrer à ta guise.
Et pas besoin d'avoir forcément ta machine de dév/test qui tourne sous linux, ou même une machine physique supplémentaire. Une simple machine virtuelle qui sert de passerelle entre les deux instances de clients testés suffit.

[nouknouk]

un des joueurs est le serveur et calcule TOUT : les clients ne font qu'envoyer leurs inputs et reçoivent les positions du serveur ( même la leur )

Désolé, en fait j'avais lu un peu trop vite ton post ; en fait, je ne suis pas d'accord avec ce point là.
Que chacun se partage ses inputs, ok (c'est le même principe que le miens dont je parlais dans mon post précédent). Mais inutile de faire calculer tout au serveur ; chaque client aura les infos pour les calculer de son côté de façon déterministe (si tu utilises un lien réseau 'reliable').

D'où l'intérêt de garder un historique des moments précédents: si un souci réseau est survenu et que à T tu reçoit seulement les infos de ce que faisait l'adversaire à T-200ms, tu pourras 'rejouer' ses actions de [T-200ms jusqu'à T] quand tu les recevras et donc 'réconcilier' pour retrouver le vrai état définitif de T, calculer le delta avec ce que tu avais prédit et compenser.

Ca a l'avantage que pendant les 200ms où tu as eu un souci réseau, le joueur reste maître de son propre perso et n'ai pas l'impression que son clavier ait 'freezé', ce qui est très pénalisant et agaçant pour le gameplay.

[MoDDiB]

Je suis totalement d'accord avec toi sur la manière idéale de procéder.

Maintenant le fait de calculer les choses des 2 côtés me fait très peur notamment au niveau de la synchronisation de la physique.

Je suis aussi quasiment seul pour tout le travail qu'il reste à accomplir : mon fidèle bras droit à qui je dois notamment la physique et le deferred shading ( entre autre, c'est une des rares personnes capables de toucher à tout ) n'est plus trop disponible pour une période de 2 ans.

Je me donne donc un mois ( environ 80 heures ) pour mettre en place le multijoueur en ligne ( et ce avec un seul pc chez moi....).
Il me faut donc aller au plus simple.
Par contre une fois ce simple fonctionnement en place il devrait être possible d'activer la physique uniquement sur le joueur lui même et de tenter des synchronisations avec le serveur, ou alors je me fourre le doigt dans l'oeil ?

( ceci dit je prends complètement note de toutes tes interventions riches d'expériences : merci )

[nouknouk]

Amha, le principe de base est: le code des clients sera commun à tous les clients, donc ce qu'on peut calculer sur le client A pourra être calculé exactement de la même façon sur le client B pourvu qu'on ait exactement les mêmes données en entrée (ce qui équivaut à "pourvu qu'on ait un canal de communication 'reliable', on envoie les seules infos nécessaires et suffisantes pour être capable de refaire le calcul sur chaque client". Les inputs sont un bon exemple).

Après, tout se joue sur les moments où il nous manque temporairement une partie de l'information (typiquement, on ne connait pas encore ce que tel joueur fait au moment T, alors qu'on doit justement afficher ce moment T). Et donc:

- que prendre comme hypothèse pour minimiser les chances de ne pas se tromper (genre si à T - 'quelques ms', le joueur allait vers le haut, il y a de grandes chances que quelques ms plus tard il continue à faire la même chose).

- si l'hypothèse s'avère juste, pas de problème on continue d'avancer.

- si l'hypothèse s'avère fausse:

(1) il nous faut un moyen de 'revenir en arrière' pour rejouer le bout de partie depuis le moment où on a fait l'hypothèse fausse jusqu'au moment actuel. D'où l'historisation des actions et états passés.

(2) une fois rejoué le bout de partie erroné, on aura un état présent différent de celui prédit. A partir de là, comment passer de l'état ancien à l'état nouveau sans provoquer un 'heurt' disgracieux et/ou handicapant au niveau du gameplay. Genre si j'avais prédit que le joueur continuait à aller vers le haut alors qu'en fait il s'est arrêté, je peux soit replacer brutalement le joueur au bon emplacement (pas très funcky, mais simple à mettre en place pour une première version), ou bien tricher un peu en faisant se redéplacer artificellement le joueur vers le base pendant la prochaine seconde pour compenser de façon moins abrupte et donc moins voyante pour le joueur.

[MoDDiB]

D'accord mais tout ceci découle d'une synchronisation exacte du temps entre les joueurs : c'est un sacré morceau non ?

[nouknouk]

La synchronisation exacte n'existe pas, le but est de minimiser l'écart autant que faire se peut.

Pour cela la technique de base consiste à envoyer régulierement des paquets de type 'ping' entre les ordinateurs. Quand un ping est reçu par un ordi, une réponse (pong) est immédiatement renvoyée, elle aussi avec son heure.

Le temps de l'aller retour ping+pong divisé par deux donne une estimation de la latence (car sauf cas exceptionnels, le chemin réseau aller est le même que celui retour, donc les temps sont proches). Avec cette estimation + l'heure contenue dans les messages, il est alors possible de se synchroniser entre ordinateurs.

Reste la gigue, qui est la variation de cette latence tout au long du déroulement de la partie. Pour celle-ci, la pratique courante est de:

1) faire des estimations de latence régulières (genre toutes les 500ms à la louche).
2) stocker les x (10, 20) dernières estimations pour garder un historique de la latence sur les quelques dizaines de secondes précédentes.
3) séparer le bon grain de l'ivraie pour éviter de synchroniser n'importe comment à cause d'un unique ping qui a été exceptionnellement rapide, ou exceptionnellement lent par rapport à la moyenne. Pour ce faire, l'approche la plus simple pour 'lisser' est de dire:

- "j'ordonne mes x derniers ping par ordre de latence croissante et je prends pour valeur de référence celui qui est au mileu".

- ou encore de dire "j'ordonne mes x derniers ping par ordre de latence et je prends la moyenne des 60% des ping situés au milieu" (dit autrement, ça revient à faire la moyenne des valeurs en excluant les 40% des extrêmes. etc...

Après, le mieux est de faire un maximum de tests en conditions réelles pour affiner la logique. Il faut trouver le bon compromis entre un estimation qui va éviter de prendre trop vite en compte une variation ponctuelle, et celle qui va éviter de mettre trop de temps à prendre en compte une variation dans la durée.


Pour revenir à la physique, j'avais évidemment oublié une chose fondamentale: tout doit se faire avec des unités de temps 'communes', et pas tel ordi qui calcule 60 étapes intermédiaires par seconde parce qu'il tourne à 60fps et l'autre ordi qui ne fait que 30 itérations parce qu'il est moins puissant. Cf. google et des mots clefs comme 'fixed time step engine' (et lien). Sinon, itération après itération et à cause de phénomènes comme l'imprécision sur le calcul des float, tu auras des résultats différents sur une période identique, avec pourtant les même données en entrées.

Cela ne t'empêcehe pas néanmoins d'interpoler pour l'affichage. Par exemple si ton time step pour la physique est toutes les 20ms, tu auras des calculs de positions à T=0, T=20, T=40, T=60, etc... Par exemple si tu veux retrouver la position de ton gugus à T=33ms, tu peux prendre ses positions à T=20ms et T=40ms et faire une interpolatino linéaire entre ces deux valeurs POS33 = (POS20 + (POS40 - POS 20) x (13/20) ).