«Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.
Dans l'épisode 01, on a parlé d'un nouveau paradigme utilisé dans les jeux vidéo et appelé système à entités. Ce deuxième opus sera consacré à la description du jeu que j'aimerais faire, et aux divers challenges associés. On ne parlera pas encore des technologies et bibliothèques diverses choisies pour implémenter tout ça (il faut bien garder quelques sujets sous le coude pour les prochains épisodes).
D'ailleurs, depuis le premier épisode, on a vu plein de projets liés au jeux vidéos sur LinuxFr :
- Mon petit jeu pour navigateur et plus ;
- Mon petit jeu pour navigateur et (pas grand chose de) plus ;
- Petit Framework de jeu 2d en C++ ;
- Gobelins cherchent geeks pour koala masqué.
Sommaire
Le concept du jeu
Type du jeu
Rentrons tout de suite dans le vif du sujet : le jeu que je compte faire est un RPG en vue de haut dans un monde ouvert.
Et là, j'en vois déjà plusieurs qui me prennent pour un fou. Ils ont sans doute raison. Il est vrai que je cumule trois difficultés d'un seul coup :
- les RPG sont sans doute les jeux les plus casse-gueule à faire, en particulier quand on est tout seul, en particulier quand c'est le premier jeu ;
- la vue de haut (la vraie, celle à la verticale) est une des vues les plus difficiles parce que ce n'est pas très habituel d'avoir ce point de vue ;
- le monde ouvert implique des dimensions hors norme qui dépassent mes capacités horaires de production de contenu.
Mais ces difficultés ne me font pas peur ! Je vais expliquer les raisons qui me poussent dans cette direction.
Les raisons
Première raison : c'est un genre de jeu qui me plaît. Ancien rôliste, j'ai toujours aimé les RPG (même avec leurs limites), j'adore m'évader dans ces univers à part. Je peux passer des heures juste à explorer des endroits qui me sont encore inconnus sur une carte. Ce sont les jeux auxquels j'ai le plus joué en nombre d'heures : Final Fantasy, Xenoblade Chronicles, The Elder Scrolls (il paraît que je suis un realife) sont mes références du genre. Donc à un moment donné, ça devait arriver, je devais me confronter au genre.
Deuxième raison : je ne suis pas pressé. J'ai le temps, j'aime bien prendre le temps de faire les choses, de m'intéresser, d'approfondir (et c'est la raison même de ces articles, partager ce que je vais trouver). Donc me lancer dans une telle aventure, longue et semée d'embûches, ça me va bien. J'ai bien conscience de tout ce qui m'attend, j'ai bien conscience que ce ne sera pas toujours facile. On s'en fout, on avance !
Troisième raison : finalement, la conception du jeu n'est qu'un prétexte pour apprendre et s'amuser. Si j'arrive à un résultat à la fin (et c'est quand même le but), c'est parfait. Mais le chemin pour y parvenir compte autant que le point d'arrivée. Partager cette expérience est aussi un moyen de «rentabiliser» l'affaire : si je ne parviens pas au bout, il restera tout de même cette série d'articles qui aura permis à d'autres de se lancer.
Thème du jeu
Ceci étant posé, il est temps de parler du thème du jeu. Mon idée est de changer un peu des habitudes et de ne pas faire jouer un héros propre sur lui mais de faire jouer un méchant, une sorcière plus précisément, le tout avec une grosse dose d'humour (noir forcément) et d'auto-dérision. Le pitch, c'est une sorcière qui sort de sa geôle après tellement d'années que tout le monde l'a oubliée, elle a perdu tous ses pouvoirs et part dans une quête pour les retrouver. L'idée, c'est donc de détourner les codes du genre pour jouer les méchants. Par exemple, il n'y aura pas de mission pour sauver un chaton, mais plutôt pour empoisonner un chaton. Je vais rester dans un univers médiéval fantastique avec son bestiaire, ses items et ses personnages classiques, mais détournés un peu pour que ce soit drôle.
Les challenges
Les challenges que je vais lister ne sont sans doute pas exhaustifs (je compte sur vos commentaires pour compléter au cas où) mais ce sont les sujets que j'ai déjà identifié et pour lesquels j'ai un intérêt certain (et qui feront sans doute l'objet d'un ou plusieurs articles chacun).
Dimension
Premier challenge de taille (huhu), les dimensions du jeu. Dans un monde ouvert, on part forcément sur une carte énorme. Sans aller jusqu'à créer une des plus grandes cartes du jeu vidéo, il va falloir un territoire assez vaste. Si on prend Skyrim comme référence, l'univers fait entre 21km² et 37km² (la version officielle dit 41km², plus précisément 16 square miles). C'est grand, très grand. Ça va poser des problèmes techniques à n'en pas douter, juste par ces dimensions. Si je devais me fixer un ordre de grandeur dès maintenant, je dirais que je serais content avec une carte entre 10 et 20km².
Parce que, qui dit grande carte, dit nombreuses entités de toutes sortes sur la carte : végétation, animaux, habitations, routes, etc. Et donc autant de sprites à créer. Oui, parce que la difficulté avec le jeu vu de haut, c'est qu'il n'y a pas beaucoup de sprites prêts à l'emploi, contrairement à beaucoup d'autres types de vues.
Une solution dans ce genre de cas, c'est la génération procédurale, c'est-à-dire qu'on génère du contenu à l'aide d'une procédure et de l'aléa. C'était autrefois utilisé à cause du manque de mémoire des ordinateurs, c'est encore utilisé pour générer tout un tas d'objet, l'exemple le plus célèbre étant SpeedTree pour générer des arbres. Bref, ça ne s'applique pas à tout mais ça peut aider dans certains cas.
Ombre et lumière
La vue de haut a un énorme inconvénient, elle ne permet pas de bien distinguer les objets. Ajouter des ombres sur les objets peut aider à se rendre compte de leur taille ou de leur forme. C'est donc un deuxième challenge, jouer sur les ombres et les lumières pour, d'une part, mieux rendre l'univers de jeu, d'autre part, créer une vraie ambiance pour le jeu et contribuer à l'immersion.
Dans les commentaires du premier épisode, devnewton a donné quelques liens sur la lumière dynamique dans les jeux 2D. Ils offrent des pistes de réflexion très intéressantes, même si je doute arriver à ce niveau de détail et de rendu. Déjà, si je pouvais avoir des cycles jour/nuit qui soient bien rendus, je serais très heureux. C'est une fonctionnalité que je considère comme une obligation pour l'aspect «réaliste» du jeu. Sans compter qu'un cycle jour/nuit offre tout un tas de possibilités amusantes au-delà du rendu.
Et la technique alors ?
Oui, il va y avoir plein de problèmes techniques. Mais ce n'est que de la technique ! Le principal dans un jeu, c'est le contenu. La technique n'est là que pour soutenir le contenu. Il y aura des articles sur la technique (le premier de la série est un bon exemple), mais souvent, la technique ne sera là que pour régler un problème de contenu.
Conclusion
Voilà, ce n'est que le début de l'aventure et les idées fusent (c'est bien normal). Certaines disparaîtront sans doute en cours de route, d'autres apparaîtront.
Aller plus loin
- Le tag gamedev (163 clics)
# Je suis pas le seul
Posté par alpha_one_x86 (site web personnel) . Évalué à 3. Dernière modification le 26 septembre 2013 à 12:03.
Salut,
Je suis pas le seul dans un cas similaire avec mon projet… merci pour ces articles.
Sauf que une particularité c'est le départ multiple, les chemins multiples (on peu être méchant, gentil, …).
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Je suis pas le seul
Posté par rewind (Mastodon) . Évalué à 2.
Dans mon cas, je trouve qu'il y a déjà suffisamment de difficultés, inutile d'en ajouter plus. Un bon petit scénario linéaire, avec quelques quêtes annexes, ça ira très bien.
# Scénario et génération procédurale
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Le plus difficile va être de générer des quêtes cohérentes. Une source intéressante sur le sujet: http://www.squidi.net/three/index.php
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Scénario et génération procédurale
Posté par rewind (Mastodon) . Évalué à 5.
Tu veux vraiment être cité à chaque épisode, hein, avoue :P
En tout cas, merci pour ce lien que je vais ajouter à ma liste et que je ressortirai le moment venu.
[^] # Re: Scénario et génération procédurale
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Depuis le temps, j'ai un stock de liens pertinents!
Je poste régulièrement mes trouvailles sur
mon twitterma tribune: http://devnewton.bci.im/chat/Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Trop gros, passera pas.
Posté par GaMa (site web personnel) . Évalué à 10.
Je vais être franc : Tu vises trop gros !
Vu que t'as pris les devants sur cette remarque, je suppose que tu es déjà au courant que tu va te planter. Et que je pourrait dire beaucoup de choses, tu ne changera pas d'avis :)
À défaut de te faire changer d'avis :
Ce que tu décris, c'est ta version finale (1.0). Je vais être clair tout de suite: Tout seul, sans expérience dans le dev de jeux vidéo, tu n'atteindra jamais cette version avant de longues années.
Dans 6 mois, quand tu n'auras que du code, qui n'est pas capable d'afficher trois sprites correctement parce que t'auras tout voulu faire en même temps, ben ta motivation et ton courage à faire bouger les montagnes ne seront plus là… (Crois en mon expérience et celles de nombreux autres)
Si tu veux une chance de t'en sortir fait des jalons. Commence avec une version 0.1:
Une carte qui tient dans une fenêtre (donc pas de scrolling), trois sprites différents pour le terrain, une sorcière, une fiole de poison et un chat. Pas de menu, pas de dialogue, pas de notion de RPG (niveau, inventaires, ..)
Et fait tes jalons à l'avance. Il faut qu'à chaque instant tu ais devant toi un but atteignable. Ne part pas dans des dev en te disant "le jour ou j'ai un truc un peu bien ça deviendra la version 0.1".
Fait toi un gros doc qui décrit tes 10 versions (ou plus) avec précision (ce qu'elle doit avoir, ce qu'elle doit pas avoir) et tiens-toi-z'y. Ça doit être ta ligne rouge, ta bouée de survie.
Et quand tu codes, ne pense qu'à la version à venir, pas aux suivantes (t'y a déjà pensé en écrivant le doc).
Et si ça veut dire réécrire tout une partie du code entre deux versions, c'est pas grave.
(Typiquement, pour la version 0.1 n'écrit pas un code d'affichage qui prend en compte le scrolling si c'est prévu pour la version 0.2. Et tant pis si tu dois réécrire cette partie pour rajouter le scrolling après)
Matthieu Gautier|irc:starmad
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 3.
Merci pour ces précieux conseils que j'avais déjà lus sur plein de sites et que j'avais bien notés. L'un des sites disait (et je trouvais ça fort pertinent) que la qualité première d'un développeur de jeu, c'était de finir le jeu. Et comme je me connais, j'ai lu tout ce qu'il y avait autour (et qui recoupe complètement ce que tu dis).
Ça tombe bien, j'ai pas prévu de finir en quelques mois. Je me donne deux à trois ans. Et pas pour faire un truc super, juste un truc de base à peu près jouable. Du coup, je me prépare pour un effort de moyen terme, pas pour un sprint. Je connais mes capacités, mon temps libre, ma motivation. J'ai bien pesé tout ça avant de me lancer sinon, je n'aurais pas commencé.
En fait, ça je l'ai déjà (sauf la fiole de poison et le chat mais j'ai le scrolling). Et je compte bien le montrer dans un prochain article (et donc le mettre sur un dépôt accessible). Et ça sera effectivement une version 0.1. C'est aussi l'idée de ces articles, ne pas montrer le jeu une fois fini mais aussi les étapes intermédiaires et toute la conception (y compris les échecs). Et pouvoir lire les commentaires pour éventuellement mieux définir les étapes suivantes.
Il y avait d'ailleurs un des articles que j'ai lu et qui disait : au début, notez tout ce que vous voulez mettre dans le jeu, puis rayez 90% des choses et ça ira. Donc, on va considérer que les quelques idées qui sont dans cet article sont les 10% restants. Pour le reste, on verra.
Pour l'instant, si rien n'est sorti, c'est que j'ai un problème fondamental : je n'arrive pas à trouver un nom pour ce jeu :D
[^] # Re: Trop gros, passera pas.
Posté par Julien Jorge (site web personnel) . Évalué à 4.
Je pense aussi que tu as tout à gagner à écrire une bible qui détaille chaque élément du jeu. J'ai eu l'expérience d'un jeu commencé en 2005 qui devait aussi être terminé en 3 ans, j'étais aussi très motivé et il n'est toujours pas fini. Le bilan est clair, à chaque fois que j'ajoutais du contenu au jeu, je rajoutais des fonctionnalités parce que « ça sera mieux ! ».
Tout a changé quand j'ai commencé à poser sur papier tout le contenu attendu. Maintenant je fais des estimations de temps correctes et je ne dérive pas durant la production.
Donc je pense que ça vaut le coup de le faire. Ça prend une demie-journée pour un petit jeu et ça fait gagner un temps infini.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
Ça peut faire l'objet du prochain épisode.
Tu fais ça comment ? Tu indiques juste le contenu ? Tu indiques aussi le temps estimé ? Tu peux montrer un exemple ?
[^] # Re: Trop gros, passera pas.
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Tu définit les objectif de chaque version:
- 0.1: map mini, déplacement, inventaire
- 0.2: boutique, combat basic
- …
- 1.0: super effet 3D, shader, version Linux, Windows, Mac, annonce officiel de la sortie, …
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Trop gros, passera pas.
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu devrais commencer par faire une maquette sous la forme d'un storyboard (avec un logiciel de dessin simple ou même du papier/crayon). Le but est de définir le cœur du jeu.
Avec ce premier jet, tu pourras en déduire les "histoires" (vocabulaire scrum désolé) obligatoires pour une version jouable et les autres.
Découpent les histoires obligatoires en tâches en indiquant leurs durées.
Voilà tu as ton planning!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
Le cœur du jeu ici, ça va être le scénario (dont j'ai pour l'instant une vague idée), mêlé à l'ambiance humoristique. Ou alors, je ne comprends pas bien ce que tu appelles le cœur du jeu.
Qu'appelles-tu des "histoires" ? Ce sont des sortes de chapitres du déroulé du jeu, c'est ça ?
[^] # Re: Trop gros, passera pas.
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Par "coeur" je veux dire le strict minimum pour considérer le jeu comme jouable.
Quand je parle des "histoires", c'est dans le sens de Scrum, cad une demande de fonctionnalité.
Par exemple, tu auras une histoire "Pouvoir déplacer la sorcière" découpée en plusieurs tâches "détecter l'appui sur les touches du clavier", "faire bouger le sprite de la sorcière", "bloquer les déplacements dans les objets et les bâtiments"…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
OK, je comprends mieux. Il s'agit de définir un ensemble de fonctionnalités minimales et les tâches (et éventuellement sous-tâches) qui y sont associées.
[^] # Re: Trop gros, passera pas.
Posté par Julien Jorge (site web personnel) . Évalué à 6.
Pour l'exemple voici la bible de Plee the Bear (qui n'est pas fini). Pour Andy's Super Great Park (qui est fini) nous étions partis sur plus petit : nous nous en sommes sortis avec une feuille et un tableur listant les trucs à faire.
Dans les deux cas l'approche est la même : nous commençons par poser les concepts du jeu et nous notons quoi fait quoi à chaque moment du jeu.
Ensuite nous nous servons de cela pour poser nos jalons, en commençant par décider d'un horizon de livraison (deux fois 3 mois pour Andy's Super Great Park). Toutes les deux semaines nous nous posons la question « que voulons-nous voir dans le jeu dans deux semaines ? ». Nous notons toutes les réponses dans des tickets de Trac et nous nous mettons au boulot.
Il nous arrive de revenir sur des décisions de la bible au fur et à mesure de l'avancement, voire d'ajouter des nouveaux trucs, mais grâce au rythme imposé nous avons une bonne vision de ce que cela coutera. Du coup nous pouvons trancher sur l'inclusion, le report ou l'exclusion assez facilement.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 3.
C'est super complet et super détaillé. Je ne sais pas si je suis capable à l'heure actuelle d'avoir ce niveau de détail.
Je pense avoir moins de vision à long terme sur mon temps de dev que toi, malheureusement. Je peux avoir des semaines très chargées où je n'aurai le temps de rien faire. Et d'autres où je vais pouvoir avancer beaucoup. Disons que par période de deux semaines, c'est jouable et encore.
[^] # Re: Trop gros, passera pas.
Posté par barmic . Évalué à 3.
J'appelle ça une spécification détaillée :) Juste pour dire que ce n'est pas spécifique aux jeux vidéo, mais que ça devrait toujours exister, pour poser les idées avant de coder.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 3.
Je trouvais ça super détaillé aussi mais en fait, on arrive vite à ce résultat. Au fur et à mesure qu'on écrit, même si comme moi on veut rester assez vague parce qu'il manque des éléments, on finit par décrire le projet de manière assez complète. Et puis on ajoute un truc par ci qui implique qu'on ajoute un truc par là, et au final pouf, on a quelques pages.
[^] # Re: Trop gros, passera pas.
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Attention il ne faut pas néglier les tâches communes à tous les jeux:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 3.
J'y pense. Est-ce que ça n'est pas mieux géré par une GUI plus classique, genre en Qt. Via un launcher qui sert aussi à la configuration par exemple. L'inconvénient, c'est que ça devient difficile de modifier dans le jeu mais c'est peut-être plus simple non ?
On peut décider de tout faire au clavier ? ;)
Alors ça, j'y ai pensé tout de suite et j'ai immédiatement mis les flèches pour bouger.
De ce côté, je crois que je suis assez mauvais. Fournir un CMakeLists.txt et des instructions de build, ça je sais faire. Mais pour releaser des binaires, je dois avouer que je ne sais pas faire. En plus, à partir de quel niveau de finition tu conseilles de releaser ? Est-ce que releaser des versions primitives ne risquent pas de faire fuir les potentiels joueurs qui croiront que c'est un jeu fini ?
[^] # Re: Trop gros, passera pas.
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 27 septembre 2013 à 00:47.
J'aime bien brancher mon PC sur un grand écran et jouer à la manette. Bref je joue sur une playnewton!
Pour les releases, je dirais dès que tu as une démo jouable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 3.
Bon, d'accord, je vais gérer les manettes.
[^] # Re: Trop gros, passera pas.
Posté par GaMa (site web personnel) . Évalué à 5.
Il y ce que j'appelle la règle du "80/20" (qu'on retrouve un peu partout) :
80% du jeu sera fait en 20% du temps. Les derniers 20% du jeu prendront 80% du temps à faire.
Tu auras très facilement (et rapidement) un jeu "complet". Tu auras un système de tiling, du scrolling, de quoi afficher des dialogues, un inventaire, un système de combat et de quêtes.
Tu te diras que c'est bientôt terminer, encore deux trois trucs et c'est bon. En fait, le boulot ne fait que commencer. Il te faudra :
Tout ça prend du temps, énormément de temps. Pris individuellement ça ne change pas fondamentalement le jeu mais c'est ça qui fait que l'on passe d'un jeu amateur à un jeu pro.
Et je choisi mes mots. Ces tâches sont chiantes à réaliser, on a l’impression de ne pas avancer et de ne plus faire évoluer le jeu. C'est pour ces raisons qu'un amateur aura moins tendance à faire ces tâches et que le jeu restera amateur. Un pro lui est payé, c'est toujours chiant mais ça fait parti du boulot. Et c'est à mon avis la première cause des jeux pas fini. Ça n'est pas la difficulté en elle même mais la longueur de la tache et la lassitude qui s'ensuit. Ce n'est pas pour rien qu'on conseil de commencer avec des petits jeux simples, c'est déjà beaucoup plus de boulot qu'on le pense.
Matthieu Gautier|irc:starmad
[^] # Re: Trop gros, passera pas.
Posté par Julien Jorge (site web personnel) . Évalué à 3.
Pour Plee the Bear et Andy's Super Great Park, une fois la bible écrite, nous avions fait un tableur reprenant les trucs à faire et une estimation du temps nécessaire. Nous avions choisi de compter en demies journées et à la louche. L'idée n'est pas d'être précis mais plutôt d'avoir une valeur pour comparer les éléments. Il s'agit aussi de discuter de chaque point pour lever rapidement les problèmes éventuels.
Les estimations pour Plee the Bear sont en ligne.
[^] # Re: Trop gros, passera pas.
Posté par barmic . Évalué à 2.
Pourquoi ne pas utiliser une gestionnaire de bug ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trop gros, passera pas.
Posté par Julien Jorge (site web personnel) . Évalué à 4.
Nous utilisons un gestionnaire de bugs (Trac) pour poser les tâches toutes les deux semaines et pour lister les problèmes et améliorations désirées au fur et à mesure que nous les rencontrons.
Je n'imagine pas mettre toutes les spécifications dans le gestionnaire dès le départ, tout d'abord parce que nous faisons une relecture des tickets toutes les deux semaines, ce qui nous impose de garder une liste courte pour éviter d'y passer la journée. Ensuite parce que beaucoup de tâches ne sont pas pertinentes tant que d'autres ne sont pas faites, ou alors elles risquent de changer en fonction de l'avancement. Dans ce cas nous nous retrouverions avec beaucoup de bruit dans le gestionnaire.
[^] # Re: Trop gros, passera pas.
Posté par barmic . Évalué à 2.
Il est possible de définir des échelons avec une date buttoir ou une version de logiciel. Il est possible de limiter la relecture à un ensemble de tickets donné (le même que l'actuel en fait).
C'est à mon avis tout l'intérêt d'un gestionnaire de bug, tu peux mettre des bugs en dépendance d'autres bug, indiquer qu'un ticket est annulé ou remplacé par un autre.
(je ne cherche pas à dire que ce que vous faites est mauvais juste à discuter des besoins)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trop gros, passera pas.
Posté par alpha_one_x86 (site web personnel) . Évalué à 4.
Je ne serai pas si catégorique. Cela dépends de son organisation. Mais surtout plus lui dire: si tu commence, soit sur de finir.
Je suis d'accords sur le coté: définir chaque versions, les trucs à faire. Et faire des releases régulières, pour qu'il se dise: mon jeu avance. Au début un truc (très/trop) simple, ensuite plus complet. Mais qu'il puisse y jouer.
Bon, j'ai fait Ultracopier/Supercopier 4 avant, mais un MMORPG/RPG simple peu ce faire en quelques mois avec de la motivation, un temps plein si la personne est déjà expérimenté en dev. C'est ce que j'ai fait avec mon MMORPG:
http://catchchallenger.first-world.info/
La démotivation viens surtout du faite que les gens pensent que c'est facile, et se rendent compte qu’après de la difficulté de la tache (surtout chez les kikoulol). Si il en est conscients, alors go!
Après tu dit que le dev prendra des années, mais c'est ça maintenir et dev un projet. C'est pas 1mois de dev et ont y touche plus (surtout pour un jeu). C'est une fois que c'est fait, continuer à le faire évoluer. Donc que la 1ere version sorte dans 1 mois ou 1ans, il sera toujours en train de dev pendant des années.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Trop gros, passera pas.
Posté par Azrou . Évalué à 2.
Autant réussir à tenir des milestone longue pour la partie programmation, c'est faisable avec un peu de méthodologie (modulo la motivation).
Autant c'est une très mauvaise idée de partir sur des milestones longue pour les problèmes de game-design.
Parfois (particulièrement quand on débute en game-design, mais même les meilleurs s'y font prendre…), le gameplay qu'on a prévu pour le jeu ne fonctionne tout simplement pas : pas amusant, pas intuitif, trop compliqué, pas ergonomique, lassant… Tant de choses qui peuvent entraîner une désillusion monumentale par rapport aux objectifs de départ.
Parfois, il suffit d'une retouche par ici, d'une rustine par là et on redresse le cap. Et parfois, c'est l'idée de base du jeu qui n'est pas bonne et les rustines parviendront alors tout juste à en faire un jeu médiocre.
C'est pour ça qu'il est important de prototyper son jeu très tôt, à grand coup de carrés, de cercles et de code crade s'il le faut. Et continuer à pouvoir tester régulièrement toute les améliorations, parce que tant qu'une feature du jeu n'a pas été joué, on a jamais vraiment moyen de savoir si cette feature respectera vraiment son rôle de rendre le jeu plus amusant.
Pour ma part, pour les projets persos, je me fixe des objectifs sur une ou deux semaines maximum. Je note soigneusement mes grands projets d'avenir qui en feront un jeu parfait, mais j'évite d'y réfléchir trop profondément, parce qu'il est de toutes façons absolument certain que le gameplay ne sera pas dans la pratique tel que je l'avais prévu, et que 1 mois plus tard mes prévisions devront être complètement revu pour coller avec ce que le jeu est devenu.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
Ha ben ça, c'est fait, et ça sera bientôt public ! Ils sont tellement beaux mes carrés :)
[^] # Re: Trop gros, passera pas.
Posté par Gabbro . Évalué à 3.
Puisqu'on parle de RPG et de jeu pas fini, j'en profite.
Il y a 6 mois, je me suis retrouvé en convalescence ; histoire de m'occuper, je me suis mis à coder un moteur de jeu vidéos pour RPG. Sans cahier des charges, sans scenario. Aujourd'hui, ça marchote, on peut bouger, parler, combattre (à peu-près), équiper des objets et fouiller des coffres. Les performance sont lamentables (même pour du Python), et comme je suis un peu perfectionniste, je n'ai jamais voulu diffuser le code.
Aujourd'hui, le code est affreux (pas de cahier des charges, je disais !). Si bien que j'envisage d'en réécrire une partie non négligeable. J'ai zieuté du coté de Flare, mais j'ai pas accroché (ça m'a l'air très orienté "Diablo", j'ai pas réussi à l'installer et le doc est pas génial (sur leur site, t'as une liste de 300 éléments, dans les fichiers de jeu, t'as quasiment rien… J'ai pas pigé comment ça marchait)). Alors forcement, je suis assez intéressé par des conseils, du code ou rejoindre un projet dans le genre.
Sinon, en vrac:
Je ne sais plus qui parlait des scenegraphes des bibliothèque graphiques dans les commentaires de je-ne-sais plus quel journal. Je confirme, SDL c'est bien pour pouvoir afficher ses images en 30 minutes, mais on gagne rapidement du temps à passer par une bibliothèque généraliste (Qt…).
Réutiliser les briques des autres. Je pense particulièrement à Tiled qui est quand même vachement bien fait.
Les traductions, c'est assez infernal. Il vaut mieux y penser très tôt.
J'ai perdu le fil de ce que je voulais dire, donc je m'arrête là.
Quoiqu'il en soit, je suis potentiellement très intéressé (bien que, ayant repris les études, j'ai moins de temps qu'avant).
[^] # Re: Trop gros, passera pas.
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
+1 pour ceux qui dise qu'il y as un moteur par jeu, et des fois comme toi, un moteur sans le jeu. Donc autant contribuer à un moteur existant, et quitte à prendre un moteur de FPS et de l'adapter pour le RPG.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 3.
J'avais lu je ne sais plus où que c'était un piège à éviter : faire un moteur de jeu. Et qu'en fait, il fallait faire un jeu plutôt qu'un moteur en pensant qu'on fera le jeu plus tard. Parce qu'au final, on faisait le moteur sans jamais faire le jeu.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
Oui, clairement, Tiled est un très bon logiciel et le format est pas mal du tout.
Tu as des conseils à ce sujet ? Je me suis toujours dit que ça devait être un peu galère, parce qu'on ne doit pas pouvoir utiliser ce bon vieux gettext.
Si tu veux contribuer (une fois qu'il y aura un code auquel contribuer), ce sera avec plaisir. Sinon, vu que tu as déjà fait ce genre de jeu, tu peux aussi partager ton expérience, dire ce qui a marché, ce qui n'a pas marché, etc. En tout cas, moi ça m'intéresse ;)
[^] # Re: Trop gros, passera pas.
Posté par ariasuni . Évalué à 3. Dernière modification le 26 septembre 2013 à 23:32.
Je me suis aussi posé la question: comment est-on censé utiliser gettext en C++? Il y a plein de moments où on est obligé d’utiliser printf pour inclure une variable en plein milieu du texte.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Trop gros, passera pas.
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Perso j'utilise Qt, donc avec cette lib (comme toute lib évolué), tu as:
QString("toto: %1").arg(nombre);
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Trop gros, passera pas.
Posté par ariasuni . Évalué à 3.
Ouais je sais que Qt a un super système pour ça, mais justement je voulais savoir comment ça se passait pour les autres projets.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Trop gros, passera pas.
Posté par Troy McClure (site web personnel) . Évalué à 3.
Je trouve que le plus propre c'est juste de faire une substitution de chaine, un truc genre
parce qu'au fond les spécifications de formattage à-la printf n'ont aucune raison de leaker dans les chaines envoyées aux traducteurs, et qu'un marqueur explicite genre %{NOM_DU_FILM} est plus clair, donne plus d'indices sur le sens et le contexte de la phrase, qu'un simple %1
[^] # Re: Trop gros, passera pas.
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Mais, %{MaPhrase} est lier à un langue (fr, en, …), c'est plus lourd à remplacer qu'un simple %1. Et que Qt supporte les traductions singulier/pluriel, une belle application simple pour le traducteur avec les notes pour le contexte, et l'affichage dans le code ou l'interface du contexte…
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Trop gros, passera pas.
Posté par ariasuni . Évalué à 2.
Ah je connaissais pas, ça a l'air pas mal du tout!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Trop gros, passera pas.
Posté par Gabbro . Évalué à 1.
Pour ma part, j'ai implémenté les traductions avant l'affichage du texte. Comme ça, j'étais sur que le code serait adapté. Le jour où j'ai dû reprendre le code en question parce que ça marchait pas comme il fallait, ça c'est fait sans soucis. Mais clairement, si je ne m'était « forcé » de la sorte, je n'aurais pas fait les traductions ! Quand à Gettext, je me suis servi de python-polib, qui permet de lire des .po.
L'inventaire, le système de manufacture (bien qu'encore trèèèès incomplet), la définitions des « règles du jeu », ça a été plus simple que ce que je croyais.
Le champs de vision. Entre la distance et les obstacle, j'ai pas encore réussi à gérer correctement ce truc. D'ailleurs, dans mon code, y'a ça :
Les quêtes, c'est la merde. L'affichage du texte est vite très lourd (sauf si tu utilises Qt, où là ce devrait être vraiment simple). Les dialogues (si tu dis ça, ça donne ceci, sinon… Si t'es une femme, on te dit ça… Tu as tué tel personne… …) sont merdiques à gérer et infâmes à écrire. Je ressens bien mes lacunes en algorithmique dans ce genre de cas !
Sinon, comme conseil : prévois les mods. Ça risque de venir bousculer ta hiérarchie de fichier si tu le fais un peu tard. Je pense de plus que c'est assez indispensable, car ça permet de permettre à d'autre d'utiliser facilement ton moteur, à toi de le réutiliser. Ça permet aussi d'inclure un tutoriel sans trop se prendre la tête.
De manière général, à quel point compte tu faire un moteur extensible : seulement pour ton jeu ou plus personnalisable ?
[^] # Re: Trop gros, passera pas.
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Perso j'ai fait la traduction dynamique. Attention, il faut prévoir la traduction de l'application comme du contenu.
J'ai vu qu'il été possible d'intégré un widget de rendu 3D (SDL2, SMLF2, …) dans Qt.
Et un formulaire Qt (.ui ou à la main) avec layout pour placement auto des widgets, zone de texte, … dans un rendu en 3D.
Je vous laisse recherche sur internet, j'ai plus les liens. Qt reste trés pratique pour faire les interfaces, et peu être facilement skinner.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
Qu'est-ce que tu entends par là ?
Qu'est-ce qui a été difficile dans les quêtes ?
Seulement pour mon jeu (si on peut dire que j'implémente un moteur, j'implémente un jeu surtout).
[^] # Re: Trop gros, passera pas.
Posté par Gabbro . Évalué à 1.
Mon programme créait un dictionnaire qui transformait les chaines de caractère en anglais en chaines traduite en fonction de la langue avant d'être capable d'afficher les dites chaine à l'écran.
Faire un système qui soit souple sans planter tout le temps. S'activer/se mettre à jour facilement sans bouffer le processeur. Ça fait partie des modules que j'ai pas tester à fond, je suis pas vraiment sur que ça marche vraiment.
Sinon, je repense à deux trucs :
- Diffuse ton code assez vite (pas comme moi ;)). Ça a déjà été dit, mais j'abonde dans ce sens.
- Les données ne seront jamais écrite correctement du premier coup. Prévois ou des tests pour ça ne plante pas pendant le jeu, ou un système tolérant aux erreurs.
Voilà. Et bonne chance !
[^] # Re: Trop gros, passera pas.
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 01 octobre 2013 à 09:57.
Ne l'écoute pas rewind il ne faut jamais faire confiance à quelqu'un à peine capable de conjuguer la deuxième personne du singulier (même si je partage sa vision du cycle itératif fonctionnel des versions).
Moi je crois que tu y arriveras d'ailleurs ton projet m'intéresse aussi (pour moult raisons), en plus si j'ai bien suivi tu vas utiliser la SFML et le C++, une techno que j'aimerais apprendre à maîtriser et un langage qui faut que je perfectionne. Donc si une aide (pas forcément régulière) t'intéresses dis le moi…
kentoc'h mervel eget bezan saotred
[^] # Re: Trop gros, passera pas.
Posté par GaMa (site web personnel) . Évalué à 3.
Ne l'écoute pas rewind quelqu'un à peine capable de trouver le sujet de ses phrases ne peut t'apporter aucune aide digne de ce nom :)
Plus sérieusement, j'espère vraiment me tromper et que tu vas réussir. (Mais vraiment ! Je souhaite sincèrement avoir tort)
Mais voilà, quand je vois arriver quelqu'un qui annonce qu'il va faire un nouveau RPG avec une carte très très grande, de la génération procédurale, un monde ouvert, plein de quêtes et les derniers effets visuels à la mode et qu'en plus, il a pas d'expérience dans le jeu vidéo … ben moi je lui dit qu'il va se planter, au risque de faire un pronostic foireux.
Quand on veut apprendre à être maçon, on commence par construire un mur, pas une cathédrale (ça n’empêche pas qu'on finira peut-être par construire cette cathédrale)
C'est en substance ce que je lui dit dans le reste du message : Fait d'abord la version 0.1 avant de faire la 1.0.
Matthieu Gautier|irc:starmad
[^] # Re: Trop gros, passera pas.
Posté par reynum (site web personnel) . Évalué à 2.
Raaa moi et ma manie de mettre des 's' à la suite d'un verbe précédé de tu.
Même si je suis d'accord avec ta vision des choses (faire des itérations fonctionnelles pour ne pas se décourager), je le suis moins avec des assertions comme Je vais être franc : Tu vises trop gros ! car c'est décourageant et je pense que ce genre d'initiatives méritent d'être encouragées, mais cela n'empêche pas les conseils.
Bref +1 pour toi. Mais rewind y arrivera (en tout cas j'y crois).
kentoc'h mervel eget bezan saotred
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
Je comprends ta prudence, mais… soyons fou et prenons des risques ! Pour l'instant, rien n'est fait encore donc c'est vrai que c'est dur de juger (même pour moi). On verra au fur et à mesure.
Ça, tu l'auras ta version 0.1 ;) Bientôt, bientôt… J'ai trouvé un titre au jeu, donc je vais pouvoir faire les dépôts toussa et mettre du code dessus toussa.
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 4.
Toute aide m'intéresse, même si elle est ponctuelle et/ou que ce n'est pas sur du code. Cette série d'article n'est que ça : un appel à l'aide :P Ou plutôt un appel à commentaires qui permettent d'avoir une bonne documentation au final étant donné la qualité des intervenants.
[^] # Re: Trop gros, passera pas.
Posté par reynum (site web personnel) . Évalué à 1.
Du coup je ne sais pas comment envoyer de MP sur LinuxFR je ne sais même pas si c'est possible. As tu une forge en place ? ou un quelconque moyen de communiquer ?
kentoc'h mervel eget bezan saotred
[^] # Re: Trop gros, passera pas.
Posté par rewind (Mastodon) . Évalué à 2.
Pour l'instant, il y a le dépôt pour le système à entité mais pas encore de dépôt pour le projet global (ça va se faire dans les jours qui viennent). Je vais faire un canal IRC sur freenode également pour faciliter les échanges interactifs.
# Un petit lien
Posté par rewind (Mastodon) . Évalué à 3.
J'ai retrouvé cet excellent lien (il était dans mes bookmarks en plus) qui dit plein de choses bien sur la création de son premier jeu vidéo. Ça rejoint plein de choses dites ici par les différents commentaires. Si un Gentil Modérateur pouvait l'ajouter dans les liens de l'article, ce serait parfait !
[^] # Re: Un petit lien
Posté par reynum (site web personnel) . Évalué à 2.
j'aime beaucoup la phrase :
kentoc'h mervel eget bezan saotred
# Autre petit lien
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Je parle énormément de mon travail, jeu (coté technique surtout, asynchronisme pour les communications MMORPG, …) et Ultracopier dans mon blog:
http://www.first-world.info/
Oui, c'est plain de fautes, mais le contenu en reste instructif. C'est sous licence libre ;)
Si certain veulent prendre contacte avec moi, peu être que la rédaction d'article commun serai intéressant, car en français il n'y as rien. (Voir page contact sur le site d'Ultracopier)
Pour revenir au traduction, pour faire simple, le traduction ne sont prise en compte qu'au chargement (chargement d'un dictionnaire de traduction, hélas ça fait pas les pluriel dynamique comme Qt, pour traduire: %n book(s)). Le changement de langue en temps réel (appliquer sur Ultracopier), demande beaucoup plus de travail, et doit être prévu dés le début.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Autre petit lien
Posté par rewind (Mastodon) . Évalué à 3.
Je retiens l'idée. Il est vrai que c'est difficile d'avoir des ressources en français (surtout pour les trucs assez techniques), et que cette série d'articles que j'ai commencés est aussi là pour combler ce manque. Si tu as des idées, n'hésite pas à en discuter ici, ou ailleurs (quand le jeu sera lancé, je ferai une section spéciale sur le dépôt où je mettrai ces articles, et une section spéciale dans les bugs pour pouvoir proposer des idées).
[^] # Re: Autre petit lien
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
J'ai parler sur mon blog de la compression des données, sur le synchronisme des données transmises, la résolution du mapping 2D, les dangers de l'affichage des autre joueurs, et les erreurs les plus courantes:
https://www.first-world.info/protocole-pour-mmorpg.html
https://www.first-world.info/compression-de-donnees-pour-envoi-en-ligne.html
https://www.first-world.info/creation-de-mmorpg.html
Soit je parle aussi d'algorithmique plus générale:
https://www.first-world.info/profiling-et-optimisation-generale.html
C'est des idées que j'ai essayer d'organiser, certaines assez approfondies.
Mais c'est vrai que communiquer sur messagerie instantané serai mieux. Pour voir ce qu'on garde et ce qu'on publie.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Autre petit lien
Posté par rewind (Mastodon) . Évalué à 2.
De la lecture, chouette ! :)
Tu préfères pas un canal IRC ?
[^] # Re: Autre petit lien
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Ou irc, mais je t'est pas vu sur #linuxfr sur freenode. Si non je suis souvent sur #qt-fr sur freenode.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.