Retour d'experience : mon jeu

Tout ce qui ne concerne pas les autres forums se retrouve ici.

Retour d'experience : mon jeu

Messagepar shimrod » 03 Juil 2012, 13:20

Bonjour,

J'avais envie de faire un petit retour d'expérience sur le developpement de mon jeu.
J'espere que cette contribution permettra à ceux qui aiment le developpement de jeu à se poser les bonnes questions et à poursuivre leur effort.

Après quelques premières expériences, sur des petits jeux (snake, asteroid, bomberman, shoot'hem up), je me suis tourné vers l'élaboration d'un jeu 3D.
Mon but est de reproduire un morceau du jeu Eve Online, un mmorpg bien connu. Pourquoi ce choix, d'abord, car j'aime les jeux spatiaux. Ensuite, car c'est un créneau où il y a encore de la place pour s'exprimer.
Enfin, car le nombre de modèle 3D pour produire un jeu, peut être relativement faible par rapport à un jeu med fan par exemple. Un vaisseau, 2 asteroids... et on est parti.
Mon ambition n'est pas de sortir un jeu complet, car le travail est titanesque pour une seule personne, mais c'est surtout d'apprendre, et me faire une expérience sur ce type de jeu.
Si cela abouti à un jeu, et que des joueurs peuvent venir y jouer, cela sera gratifiant évidemment.

Ayant une vie privée et un travail, cela pose quelques contraintes dans mon projet:
-- temps alloué à cette activité : faible.
-- ressource disponible : faible.
De ce constat, des décisions sont à prendre. Je ne peux pas prendre d'engagement auprès d'une équipe, et leur imposer un rythme de travail, que je ne pourrai pas suivre moi même.
Je ne peux que tenter d'intéresser des gens qui souhaitent participer à l'aventure de manière ponctuelle, apportant une pierre à la fois.
Je m'entoure surtout de personne avec qui je peux discuter de gameplay, de gamedesign, pour élaborer les 1eres pierre du jeu (but du jeu, quels sont les mécanismes principaux, les choses qu'on aimerait voir).
Tout est bon à prendre, on triera au fur et à mesure. Avoir de l'ambition.
J'essaye également d'avoir une personne technique avec qui je peux discuter des manières de faire en terme d'algo, ou d'implémentation.

Le second choix est la technologie. Ayant de bonnes compétences en Java, C++ et python, le choix est vaste. Ce qui m'intéresse est de trouver un moteur graphique répondant à mes besoins, et si possible gratuit.
Deux choix s'offrent à moi (parmi tant d'autres) : Ogre (C++) / Panda3d (python).
Comme j'apprécie le python, car la productivité en terme de coding est plus élevé (syntaxe allégé, pas de compilation), j'opte pour un moteur permettant de coder en python.

Sur ce point, après mon retour d'expérience, il est clair que d'autres critères doivent venir alimenter le choix:
-- possibilité de créer un executable joueur facilement (pour pouvoir distribuer votre jeu)
-- technologie qui puisse être hébergé facilement (pour la partie serveur) sur un serveur commercial
-- possibilité d'intégrer facilement des third party (gui, moteur physique, son, réseau,...)
-- vie du moteur (communauté active o/n, release régulière avec patch, ...)

Première étape : montée en compétence sur la partie moteur graphique.
Je passe un peu de temps à tester les fonctionnalités du moteur graphique, et de m'imprégner de ces mécanismes et de ces contraintes.
La conception est fortement marquée par les contraintes du moteur.

Rapidement, je passe à l'étape de la mise en place de la partie réseau. Il est utopique de monter un jeu, et de greffer la partie réseau par dessus.
La conception des classes, et du coding en général doit embarquer la partie réseau comme une contrainte, et donc doit être prise en compte au plus tôt.

Je commence à créer mon premier modèle de classe, avec les classes essentielles (user, character, ...). Je ne m'embête pas pour l'instant avec la persistance. Des fichiers xml me suffisent pour stocker de l'information.
Mon but est d'aller vite est de monter un premier proove of concept.

Une fois que je me sens capable d'aller plus loin, je commence à travailler les concepts du jeu, et j'utilise un wiki pour structurer les différents éléments du jeu.
Il est important de figer quelque part les idées principales, les principaux mécanismes de jeu.
Parmi ceux là, je recommande ces axes de réflexion:
-- Quels sont les buts du jeu atteignable?
-- Quels sont les mécanismes de jeu que vous voulez proposer au joueur (PvP, crafting, trading, ...)
-- Instance de jeu, ou monde global à tout le monde
-- Quelles sont les incidences d'être tué? Qu'est ce que cela implique? Pour moi la gestion de la mort est un élément clef de réflexion.
-- Quels sont les principes d'évolution (histoire, xp, personnelle) que vous souhaitez voir dans votre jeu, et comment se traduisent-ils concrétement?

Clairement, ces questions donnent une orientation forte au jeu, ainsi qu'à la conception des classes de code, et à l'interaction entre celles ci.
Il est indispensable de s'arrêter dans le code, pour répondre à ces questions, et détailler les réponses.

Ensuite, je repars sur le développement, et je commets un grand nombre d'erreurs, et tombe confronté à un grand nombre de difficultés techniques.
J'ai bien avancé sur le maniement du vaisseau et de quelques concepts de base.
Je me rends compte que certains comportements sont durs à gérer à la main, je me dis qu'il me faut intégrer un moteur physique pour gérer les collisions, rebonds, mouvements liés à la gravitation.
Je choisis donc ODE, qui est gratuit et bien connu. Ce fut ma 1ere erreur. Après avoir passé beaucoup de temps à l'appréhender et à le mettre en oeuvre, je me rends compte qu'il est extrémement lourd, mais aussi buggé.
En discutant avec une autre équipe de dev, il me préconise bullet, qui est beaucoup plus léger et plus adapté au jeu. En effet ODE, a vraiment été développé pour de la simulation physique poussée.
Mes besoins correspondent à 10% des fonctionnalités de ODE.
Je passe un temps important en refactoring, pour passer à bullet. 3 mois pour passer à ODE, 2 mois pour passer à bullet. Mauvais choix.

Concernant le gui, mes 1eres fenetres utilisent la librairie native de panda. Les fenêtres sont approximatives. Je choisis de partir sur une librairie spécialisée bien connue : CEGUI.
La prise en main de CEGUI, et la définition d'un thème (très lourd en CEGUI), et mes 1eres fenetre me prend 3 mois environ.
Je me rends compte lors d'une itération, que je ne suis pas capable de générer un executable pour les joueurs avec Cegui en dépendances.
Je tombe sur une autre libraire qui s'appelle librocket, plus légére, et surtout qui s'appuye sur des définitions html, et des classes css. 3 mois pour passer à cegui, 2 mois pour passer à librocket.

Depuis mon vaisseau qui avance dans l'espace et quelques fenêtres, j'ai passé plus de temps à réécrire du code, qu'à en écrire à proprement parler :(
Il est difficile de garder la motivation dans ces cas là. Mais par chance j'y arrive.

Je décide de commencer à implémenter de réels concepts de jeu (multi connexion, mini PvP,...).

En parallèle je développe un updater de jeu. Je me rends compte que le jeu peut être très lourd, et que si à chaque patch les joueurs doivent télécharger un fichier de plusieurs centaines de mo, cela ne va pas le faire.
Je crée donc un updater, avec un site hébergeant les fichiers, et leur version, pour ne télécharger que les fichiers updatés.

Je n'avais jamais vraiment été dans un jeu réseau. Premier problème technique : algo de nagle. Mes paquets s'entassent et ne sont pas envoyés au fil de l'eau mais en paquet. Du coup, le jeu rame. Beaucoup de sueur pour régler ces problèmes de performance.
Après moults itérations, j'arrivent à un jeu avec de premiers résultats, et peu de fonctionnalités. Je me propose de l'essayer avec des joueurs par Internet (alors que toujours en réseau local).
Premier constat: trouver un serveur pour héberger un jeu fait maison, autre que Php, c'est un peu l'enfer. Bon, je trouve une solution. Je lance le test. Une horreur, un lag monumental.
-- ma BP ne permet qu'un upload limité.
-- linux de base active l'algo de nagle.
-- mes paquets ne sont pas optimisés. J'envoie de longues chaines de caractères au lieu des types concernés (un float converti en string peut faire 20/30 caractères, alors qu'envoyé en tant que float fera 4 octets.
Effectivement dans un jeu réseau, l'optimisation des envois de paquet doit être très rigoureux. Le flux réseau dans un jeu en temps réel est très important, et le taux d'envoi est réglé chez moi à tous 1/4 de secondes, avec l'envoi de position de tous les joueurs et ennemis.
Cela représente un traffic très important. D'où le choix pour certains de jeu, d'instancier, afin de limiter le flux réseau à une instance, qui peut être hébergé par un serveur dédié par exemple.

Grosse itération à optimiser le traffic réseau, et à trouver un serveur avec de la BP.

A ce jour, je redémarre avec des bases saines, et pour reprendre de la motivation, je m'attarde sur des concepts joueurs.
Néanmoins, face à moi se dresse quelques grosses montagnes:
-- Gestion du réseau à grand nombre (>10 joueurs)
-- jeu sans thread, et je pense qu'il faudrait pouvoir séparer les différentes zones du jeu en terme de thread pour pouvoir assurer une continuité de réseau acceptable
-- Contenu graphique assez limité, il va falloir trouver une bonne âme pour me préparer quelques éléments de jeu (vaisseau au minimum)
-- Contenu de jeu limité (quêtes, items, zones, ...) C'est un travail énorme que de travailler sur le contenu même du jeu.

En parallèle, j'ai commencé à travailler sur un éditeur de contenu visuel, plutôt que de m'échiner à remplir la base de données à la main. C'est un travail encore supplémentaire, et le temps passé sur cet éditeur n'est pas un temps passé sur le jeu.

J'ai lu entre deux également, un bon article sur les 10 règles à suivre pour faire un jeu vidéo indie.
Il y a par exemple, beaucoup d'équipes qui se battent et passent du temps sur des choses futiles, et qui ne sont que des éléments superficiels à mon sens (nom du jeu, histoire, ...), et cela me fait rire.

Ce que je conserve comme conseils:
-- une histoire n'est pas même le commencement du jeu, mais un élément d'appui pour le joueur
-- commencer par mettre en forme les concepts du jeu (mécanismes du jeu + buts)
-- choisissez la technologie/moteur qui vous permettront d'arriver à ce but en prenant en compte les différents éléments (réseau, gui, base de données,...) même si tout n'est pas pensé parfaitement au départ, donnez vous une 1ere base qui vous lancera
-- soyez respectueux du travail des autres et des contraintes des autres. Vous êtes amateurs. Prenez en compte ce facteur (compétences, résultats, timing, ...).
-- prenez du temps à discuter avec d'autres groupes. Ils ont leur expérience, et la partageront.
-- trouvez vous de quoi maintenir la motivation. C'est le nerf de la guerre. Faites des itérations pendant lesquelles vous avez un but à atteindre qui soit tangible
-- soyez conscients des limites de votre exercice et donnez vous le bon objectif : faire un jeu consomme du temps, du talent, et beaucoup de ressources.
-- attention de ne pas tomber dans le cercle de création de librairie interne, mais rester bien dans le but de créer un jeu. Pas trop de librairie générique, cela consomme un temps fou. Estimer le gain réel.

Merci pour votre lecture
--
Shimrod
Shimstar
shimrod
Hello World, I'm new !
 
Messages: 196
Inscription: 10 Mai 2006, 20:11
Localisation: Paris

Messagepar MoDDiB » 03 Juil 2012, 14:23

Un excellent retour ; il manque juste un timing global et quelques screens pour égayer le pavé ;)
MoDDiB
Hello World, I'm new !
 
Messages: 133
Inscription: 13 Juin 2007, 11:12

Messagepar shimrod » 03 Juil 2012, 16:01

Sur le timing global : cela fait 2 ans et demi que le projet a commencé.
J'ai dépassé les 15000 lignes de code de jeu (je ne compte pas les third party et les fichiers de conf, mais uniquement le code pur).

Concernant des screenshots, voici quelques fenêtres, je n'ai pas de screens du jeu "inspace". Je reste discret sur cela pour l'instant, étant la phase la moins aboutie:
Image
Image
Image
Image
--
Shimrod
Shimstar
shimrod
Hello World, I'm new !
 
Messages: 196
Inscription: 10 Mai 2006, 20:11
Localisation: Paris

Salut Shimrod est Bravo, pour les screenshots

Messagepar absolutbry » 03 Juil 2012, 16:48

Salut Shimrod,

Déjà Bravo pour avoir des screenshots c'est vraiment dur de commencer avant d'arriver à montrer un truc.

C'est le plus dur dans pour faire un jeu, c'est déjà d'avoir une bonne, voir une très idée des contraintes du jeu.

Pour la partie réseau, il faut vraiment Thread sinon tu n'auras jamais la capacité à tenir la charge, et c'est tellement plus facile.

Dans un jeu comme le tien, je pense qu'il faut au minimum 4 ou 5 threads qui tourne en permanence, je connais assez bien le problème.

Un Thread de Chargement des ressources
Un Thread pour Moteur 3D
Un Thread pour les réseaux, voir 2 threads un pour TCP (Ordre), un pour UDP (Environnement du jeu ,notification ou chat)

Un Thread Controlleur. (Très important pour la mise à jour des données)

Si tu as besoin de conseils sur le réseau, je peux d'aider mais je ne suis pas expert.

Si tu utilises php et des webservices pour mettre à jour, tu auras des problèmes de charges. Car même en utilisant APC Cache, tu ne pourras pas maintenir tout le contexte de jeu. Sinon tu feras trop de requête à ta base de données.

Si tu veux utiliser PHP, d'utiliser une lib pour avoir juste a déclarer des méthodes et la lib crée le webservice pour toi. Utilise un lib sur dans ton jeu pour créer ton le client pour appeler les services.

Pour courage, j'ai hâte de voir ton jeu.

Bonne journée
absolutbry
Hello World, I'm new !
 
Messages: 30
Inscription: 24 Juin 2012, 14:14

Messagepar shimrod » 04 Juil 2012, 07:43

Je te rassure, il y a quelques threads principaux (reseau, moteur 3d, ...).
Ce que je pense c'est qu'il faudrait que je crée un thread par zone de jeu, pour être encore plus efficient, et d'avoir un thread world pour les infos générales.
JE sais que sur Eve, ils font pas mal de micro threading.

Pour information, je code en python, pas du tout en php, et pas du tout une application web, mais bien un jeu en client lourd et serveur. Et pas de webservices, pas assez efficace.
--
Shimrod
Shimstar
shimrod
Hello World, I'm new !
 
Messages: 196
Inscription: 10 Mai 2006, 20:11
Localisation: Paris

Messagepar atebas » 04 Juil 2012, 09:36

Un retour très agréable à lire :)

Les screens sont très sympa en plus. Pour ta recherche de gens qui te ferait des modèles 3D de façon ponctuel tu peux peut être présenter ton projet et mettre des missions sur gamescreat.org , le site a ouvert récemment mais il commence à y avoir du monde.

Bon courage pour la suite !
atebas
Hello World, I'm new !
 
Messages: 14
Inscription: 29 Mai 2012, 17:59

Messagepar iliak » 09 Juil 2012, 08:26

absolutbry a écrit:Pour la partie réseau, il faut vraiment Thread sinon tu n'auras jamais la capacité à tenir la charge, et c'est tellement plus facile.

Dans un jeu comme le tien, je pense qu'il faut au minimum 4 ou 5 threads qui tourne en permanence, je connais assez bien le problème.

Un Thread de Chargement des ressources
Un Thread pour Moteur 3D
Un Thread pour les réseaux, voir 2 threads un pour TCP (Ordre), un pour UDP (Environnement du jeu ,notification ou chat)

Un Thread Controlleur. (Très important pour la mise à jour des données)

Si tu as besoin de conseils sur le réseau, je peux d'aider mais je ne suis pas expert.


Oula ! Tout comme toi, je ne suis ni expert en développement réseau temps réel orienté jeu, ni expert en Python, mais là, ça me parait un peu monstrueux autant de threads... L'idée est d'avoir un thread par processeur, autrement, le gain n'est pas "si bénéfique" que ça. L'autre problème est la synchronisation des données entre ces threads. Si tu ne maîtrise pas ça sur le bout des doigts tu vas te les manger à longueur de temps et pour trouver où ça coince, bon courage !

De ma petite fenêtre de connaissance, je ferai (et encore pas sûr, tout dépend du projet) :
- un thread pour la partie cliente (I/O, rendu). Peut être à la limite un thread juste pour charger les éléments du jeu mais tu peux très bien t'en passer, sauf si évidement tu fais un jeu qui ne "charge jamais" (càd du "seamless level loading").
- un thread pour la partie réseau et la logique de jeu (càd la partie serveur)

Et ça s'arrête là.

Je reste bien évidement ouvert à toute critique du moment qu'elle est constructive :)
- Iliak -
[http://www.mimicprod.net ArcEngine : a free 2D .Net gaming framework]
[http://www.dungeoneye.net Dungeon Eye : Remake open source de Eye of the beholder II]
iliak
Hello World, I'm new !
 
Messages: 141
Inscription: 25 Fév 2010, 14:53

Messagepar shimrod » 09 Juil 2012, 15:22

Oui et non. en fait, j'ai lu un document de conception sur Eve Online, qui ont opté pour du micro threading, pour déclencher des mini actions sans bloquer le flux principal.

En fait, ce qui se passe dans un jeu de cette dimension avec autant de choses à gérer, et un flux réseau permanent, c'est que si tu restes avec un ou deux threads principaux, c'est que tu travailles ensuite en séquentiel.
1. je lis le message correspondant au changement de position des ennemis
2. j'update la map
3. j'envoie mes infos.
...
99. j'envoie un ping pour vérifier que le serveur est toujours présent
100. je calcule la latence réseau.

Si tu fais toutes les étapes dans l'ordre, et qu'à chaque étape il y a un mécanisme complexe qui est lancé, tu risques d'avoir fini de traiter alors que de nouvelles infos sont déjà disponibles.

Si tu ne déclenches pas des mini threads pour les activités un peu lourdes de calcul, ou consommatrice en tout cas, tu as le risque de finir ta boucle alors qu'il aurait fallu qu'elle soit déjà relancé.

Bien entendu, ce phénomène ne peut être constaté, que sur de gros volumes d'informations, type mmo, sur des zones non instanciées.
Après c'est un choix de GameDesign. Le gameDesign peut être orienté par la technique du fait des problèmes de faisabilité, et de compétences de l'équipe.
--
Shimrod
Shimstar
shimrod
Hello World, I'm new !
 
Messages: 196
Inscription: 10 Mai 2006, 20:11
Localisation: Paris

Messagepar shimrod » 22 Nov 2012, 11:16

POur info, j'alimente un blog avec l'avancement du jeu et les réflexions :

http://shimrod.blog.free.fr/
--
Shimrod
Shimstar
shimrod
Hello World, I'm new !
 
Messages: 196
Inscription: 10 Mai 2006, 20:11
Localisation: Paris

Super le blog

Messagepar absolutbry » 23 Nov 2012, 19:47

Salut Shimrod,

Je viens de voir ton blog, il est sympa et il donne un peu d'inspiration !!

ciao !!
absolutbry
Hello World, I'm new !
 
Messages: 30
Inscription: 24 Juin 2012, 14:14

Messagepar shimrod » 26 Nov 2012, 10:03

Si cela peut servir :p
--
Shimrod
Shimstar
shimrod
Hello World, I'm new !
 
Messages: 196
Inscription: 10 Mai 2006, 20:11
Localisation: Paris


Retourner vers Bavardages

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité

cron