Discussion :

[leghola]

Bonjour,

Je me nomme Nico, j'ai 34 ans et je suis professionnel dans le domaine de l'informatique. Si je viens aujourd'hui c'est que je suis relativement avancé dans un projet que j'ai commencé on va dire réellement fin Aout, début Septembre de cette année.

Tout d'abord, ce projet devait initialement n'etre qu'un "simple" générateur de donjons 3d mais au fur et a mesure du temps, je me suis mis dans l'idée d'en faire un jeu a part entière.

Je développe sous VB.net 2010 Framework 4.0 et le moteur 3d Truevision (Dx9c). J'ai aussi développé une couche réseau personnelle et un compresseur/gestionnaire de médias dans la même veine que Zlib pour ne citer que lui. LA gestion du son est aussi complètement personnelle et directement codé via DxSound qui prends parfaitement en charge mes besoins (son 3d spatial)

Seul sur le projet, je code donc seul et j'ai acheté des packs de ressources 3d, en fait la totalité du site www.arteria3d.com.

Mon projet est composé de deux parties distinctes :
1. une DLL principale nommée actuellement EYEngine, moteur de jeu a part entière.
2. Les applications qui gravitent autour de l'EYEngine.

Voici un rapide graphique expliquant les différentes parties :



Maintenant venons en au fait....

DunGen est un projet Réseau donc la particularité va être de confronter des équipes de joueurs de 1 contre 5... Oui 1 contre 5 !

Le joueur seul sera le maître de son donjon qu'il devra défendre face aux 5 héros venus pour le conquérir.
Le maître du donjon aura une vue RTS et aura un gameplay s'approchant d'un Défense Tower plus élaboré alors que les héros, en vue FPS, auront un gameplay croisé entre MORPG et MOFPS.

Le maitre du donjon aura aussi la possibilité de créer lui même son propre donjon de A à Z avec des outils de création simples mais élaborés et une panoplie d'objets et de salles a disposition.

Voici un aperçu de l'éditeur de salles (augmentez le son, je parle mais la prise est très faible) :

[ame="http://www.youtube.com/watch?v=rHcjMkf8qMc"]DunGen Room Editor - YouTube[/ame]

L'éditeur possède de plus un générateur de donjons paramétrable et des fonctions d'édition avancées.



Mais je l'avais dit, le projet est un projet réseau et cette partie éprouvante fonctionne parfaitement :

[ame="http://www.youtube.com/watch?v=N-JW5hHBRaQ"]Dunggen Project - YouTube[/ame]

Bon c'est vrai ca manque de charme... Donc depuis j'ai ajouté des effets ombres, lumières, intéractions et animations...

[ame="http://www.youtube.com/watch?v=G8WzU7pxhx8"]Dungen - 12-2011 - YouTube[/ame]


J'espère vous avoir titillé les neurones et je répondrai aux questions bien sur !

A+
Nico

[Pat_AfterMoon]

J'espère vous avoir titillé les neurones

Carrément titillé !

Le principe a l'air vraiment sympa. Le fait que tu ais choisi un middleware comme Truevision3D devrait te permettre de te concentrer sur ce qui est spécifique à ton jeu, j'espère que ce projet aboutira.

En tout cas je suis volontaire si tu cherches des beta testeurs

Remarque : pour un jeu multi comme ça, surtout au début, le temps que la communauté grossisse, il vaut mieux prévoir un fonctionnement des parties en continue, plutôt qu'un système ou tous les joueurs doivent être présent du début à la fin de la partie.

Je m'explique, s'il faut réunir un maitre de donjon et 5 assaillants avant de pouvoir créer une partie, beaucoup de joueur vont se connecter, attendre et partir avant que la partie commence, et comme c'est un cercle vicieux, ça risque de plomber le jeu.

Alors que si le maitre de donjon peut lancer sa partie et attendre les assaillant tout en commençant à s'organiser, il y aura plus de chances pour que ça démarre. Un 1er assaillant pourra venir, puis un autre ...etc.
Si le browser de partie est bien fait, cela peut faire une sacré différence.

Par contre ce genre de chose doit se prévoir très tôt au niveau du gameplay, notamment pour mettre en place les éventuels systèmes d'upgrade, expérience et autres.

Bon courage en tout cas, je vais suivre ce projet avec intérêt.

[NevilClavain]

'lut

-> Dans l'archi de ton moteur de jeu DLL (EYEngine), je ne vois pas clairement où se trouve la partie couche réseau ? Est ce le bloc 'Area System' qui prend ça en charge ?

-> Avec TrueVision tu tournes sous Dx9.0. Comptes-tu évoluer vers Dx11 ? (Si TrueVision le permet)

Intéressant en tout cas...

[leghola]

Bonjour et merci pour les retours,

Je suis actuellement en train de définir le "game browser" justement. même si ton idée est séduisante elle va demander un gros travail d'équilibrage pour qu'un maître de donjon qui a du temps devant lui ne fasse pas une forteresse imprenable mais en contre partie qu'il ne se fasse pas dézinguer si des héros arrivent trop vite.
Je pense que dans un premier temps, une partie ne pourra se lancer que quand une partie sera "pleine" (4 héros + 1 maître)

Niveau du réseau, la couche réseau est directement intégrée dans le "Core" mais il est vrai qu'au moment de la conceptualisation de ce graphique, la couche réseau n'était pas encore écrite et donc n'apparait pas dessus.

Mon moteur s'initialise et s'utilise très facilement (possible distribution par la suite ??), par exemple :

INITIALISATION DU MOTEUR :

Code :

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

EYEngine = New EYEngine.CCore(Me.PictureBox1.Handle, Global.EYEngine.CSettings.Enum_LvlOfDetail.Low, MediaPath, True)

INITIALISATION DU RESEAU :

Code :

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

EYEngine.ConnectNetwork(Global.EYEngine.CSettings.E_TypeOfConnection.Local, "", "", Me, Nothing)

Le E_TypeOfConnection possède 3 valeurs :
- Local
- Client
- Server
Et la méthode d'initialisation ne change pas...

Ajouter un objet dans le moteur se fait comme ceci :

Code :

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

1
2
NewInstance = New AREA.Instances3D(C3DObjets.EnumObjets3D.Static3DObject, MeshName, FileName, Coord3D, Rot, Scale, 0, 0, 0, 999)
EYEngine.ClsSpooler.Add(New CSpooler(NewInstance, CSpooler.EnumTypeOfActions.Add))

J'ai évidement une liste d'actions disponibles dans mon spooler :

Add
Delete
UpdatePosition
UpdateRotation
UpdateScale
UpdateAll
ShowBoundingBox
HideBoundingBox

Les méthodes sont elle aussi très simplifiées et j'ai développé une liste de fonctions assez conséquente. Tout ca pour dire que j'essaie vraiment d'optimiser et de construire un moteur de JEU complet et solide afin de me permettre de gagner en rapidité par la suite.

A+
Nico

[NevilClavain]

J'ai évidement une liste d'actions disponibles dans mon spooler :
Citation:
Add
Delete
UpdatePosition
UpdateRotation
UpdateScale
UpdateAll
ShowBoundingBox
HideBoundingBox

Quid de la gestion de la physique ? Est-ce prévu ?

[leghola]

Re,

La physique.... alors Truevision intègre en natif le Newton Engine pour la physique et j'ai déjà fait des projets avec.
Le problème est bien évidement de gérer la physique en réseau et la c'est une autre paire de manches !

J'ai effectivement essayé dans le passé de créer un moteur réseau avec prise en charge de Newton mais cela demande une précision d'orfèvre dans la gesiton réseau et synchronisation des clients. Donc, pour l'instant je dois répondre par la négative sur la prise en charge de la physique (même si une fois en place ca aide vraiment sur bcp de points du gameplay - ne serait ce que la gestion des collisions !)

A+
Nico

[chezboris]

je trouve l idee de base tres sympa..vraiment.. Projet assez ambitieux...

[leghola]

Bonjour,

Cela fait longtemps que je n'ai pas posté car j'ai travaillé sur un gros morceau... Je viens aujourd'hui car les résultats sont assez satisfaisants pour en parler.

En fait j'ai repensé a un précédent message :

Quid de la gestion de la physique ? Est-ce prévu ?

Je me suis dit qu'il fallait tenter de repenser ce système et apres 2 semaines de travail, le server de monde est désormais géré par le moteur physique Newton.

Le server est en charge de calculer toute la physique du monde et de le renvoyer aux clients, cela décharge complètement les clients de possibles gestions de collisions et permets un calcul bcp plus précis.

La conception du système est donc celle ci :

1. Le client envoie une information en cas de modification de son état sous la forme : NouveauStatus ou ce nouveau status peut etre marcher, courir, tourner a gauche, tourner a droite, sauter, etc.

2. A la reception de ce nouveau status, le server mets a jour l'objet ainsi que les forces nécessaires (velocity, etc).

3. Toutes les 330msec le server envoie un état du monde aux joueurs (donc 3 Frames/Sec)

4. Avec les nouvelles informations, le client mets a jour sa base allegée et extrapole les mouvements entre la position "actuelle" et la position "finale" afin de redécouper les changements suivant le FPS de la machine et créer un mouvement "fluide"

Voila le schéma global de fonctionnement qui fut, il faut l'avouer complexe a régler !

A+
Nicolas