Quelle vision à long terme pour le développement du jeu

[niahoo]

Hello,

Hier soir je lisais un article qui expliquait que pour créer un jeu il fallait tout concevoir de A à Z et qu'ensuite, le développement était la partie facile puisqu'il suffisait de suivre nos précédent choix.

Je me suis dit que le type qui écrivait ça n'avait jamais écrit de code de sa vie ... Mais ça m'a quand même fait réfléchir : j'ai écrit des milliers de lignes en français décrivant des mécanismes, mais pour autant je n'ai jamais fait de release en disant "tel document décrit au poil prés le jeu que je vais maintenant implémenter". Au lieu de ça, je change d'avis, je change des mécanismes voire le background même du jeu du tout au tout, et au fur et à mesure j'implémente les composants que l'on retrouve dans toutes les versions conceptuelles du jeu, ou du moins ceux qui survivent plus d'un an (oui car ça fait un moment maintenant).

Je pourrais écrire des diagrammes, des documents encore plus précis sur l'implémentation, mais ça serait simplement du temps supplémentaire pour changer d'avis. Quand des choses sont déjà implémentées, je suis moins enclin à les modifier en profondeur.

Mais maintenant j'aimerais un peu accélérer le processus, implémenter plus rapidement pour pouvoir avoir des éléments de gameplay jouables afin de voir si c'est fun ou juste relou.

Alors, pour ceux qui ont déjà un jeu, ou qui pensent réellement sortir celui qu'ils sont en train de coder, comment vous faites, vous ? Je me suis fait un fichier ROADMAP très succinct mais bon, ça fait vite peur quand on commence à détailler. Mon problème c'est que j'avance un peu la tête dans le guidon, faute de spec totale. Et du coup c'est pas facile de rester motiver.

[MadMass]

Personnellement je me force à me tenir à ce que j'ai écrit, sinon je fais n'importe quoi. Je pense que l'important est de se dire qu'un jeu ça s'entretient, et qu'il vaut mieux partir sur ce qui est défini puis faire une maj, que changer en cours de route alors que l'interdépendance entre modules est grande et susceptible de transformer le code en cauchemar.
Et ce que je fais donc, c'est que j'imprime mon CdC pour pas être tenté de le modifier, et si j'ai des idées en cours de route (notamment sur des trucs pas encore programmés) je fais une nouvelle page word. Comme ça je progresse par additivité de fonctionnalité, et non pas par refonte en plein milieu, à mon avis une base solide et simple est nécessaire :p

[Sephi-Chan]

Je vais répondre, même si ma légitimité sur la question est ridicule tant le développement de Seelies est une blague : j'ai commencé à travailler dessus en 2006.

Comme toi, je gratte beaucoup de papier et je modifie le projet, le plus souvent par petites touches car je pense que les gros pans sont là.

Il y a peu, je bossais en parallèle sur le backend et le frontend en parallèle : je développais le code serveur dont j'avais besoin (en TDD, donc déjà ça n'aide pas à raccourcir les cycles) puis j'implémentais la partie cliente (avec Backbone, ce qui n'aide pas non plus à prototyper rapidement).

Alors c'était génial, ce qui marchait fonctionnait bien et était vraiment classe techniquement : mais c'était très (trop) long à développer (aucun rechargement : les infos étaient pushées entre les joueurs et l'interface entièrement client-side réagissait instantanément, l'application Web déléguait toutes les écritures en base en tâche de fond, etc.), surtout quand on n'y consacre qu'une poignée d'heures de temps en temps.

Et puis j'ai perdu un peu de code côté client (je m'entends encore gueuler "mais j'étais sûr d'avoir pushé ça !"). Ça a été la goutte de trop dans le vase de la contre-productivité et j'ai décidé de changer de méthode : ne plus s'occuper de la partie cliente. Je ne développe maintenant que le moteur du jeu.

Quand j'aurais atteint un moteur jouable (une V1, un MVP, peu importe comment on l'appelle), je développerais l'interface pour celui-ci. Je pense que ne plus jongler entre backend et frontend va me permettre de gagner du temps en me concentrant sur le fonctionnement de l'application.

C'est tombé en parallèle d'une décision qu'on a prise avec Argorate de nous voir régulièrement pour faire le point sur l'avancement de nos projets (j'ai bien besoin d'une personne qui a cette capacité à garder le cap), pour lequel j'ai pondu un petit document pour expliquer la démarche et mes objectifs des mois à venir. Un pas supplémentaire serait de se mettre des deadlines, mais je ne suis pas encore prêt pour ça.

Quand un point particulier arrive dans cette liste, je rédige sa documentation (ou plutôt à spécification) à partir de mes écrits (ou la plupart du temps de ma mémoire).

[niahoo]

Personnellement je me force à me tenir à ce que j'ai écrit, sinon je fais n'importe quoi. Je pense que l'important est de se dire qu'un jeu ça s'entretient, et qu'il vaut mieux partir sur ce qui est défini puis faire une maj, que changer en cours de route alors que l'interdépendance entre modules est grande et susceptible de transformer le code en cauchemar.
Et ce que je fais donc, c'est que j'imprime mon CdC pour pas être tenté de le modifier, et si j'ai des idées en cours de route (notamment sur des trucs pas encore programmés) je fais une nouvelle page word. Comme ça je progresse par additivité de fonctionnalité, et non pas par refonte en plein milieu, à mon avis une base solide et simple est nécessaire :p

Hum, mais moi j'ai besoin de pouvoir modifier mon CDC (ou plutot mes notes), quand on trouve une idée encore meilleure qui vient remplacer une précédente idée moins évidente, j'aime pouvoir rester dynamique. C'est vrai qu'il faudrait que je fasse le tri dans toutes les fonctionnalités que j'ai en tête. En garder un minimum qui forme un jeu cohérent. Actuellement j'ai trop de possibilités, certaines contradictoires. ça me semble un bon début pour l'écriture d'une bonne roadmap.

Je vais répondre, même si ma légitimité sur la question est ridicule tant le développement de Seelies est une blague : j'ai commencé à travailler dessus en 2006.

Non mais pareil hein, je compte plus les années, mais j'ai beaucoup appris, ce n'est pas du temps perdu.

Il y a peu, je bossais en parallèle sur le backend et le frontend en parallèle : je développais le code serveur dont j'avais besoin (en TDD, donc déjà ça n'aide pas à raccourcir les cycles) puis j'implémentais la partie cliente (avec Backbone, ce qui n'aide pas non plus à prototyper rapidement). [...] j'ai décidé de changer de méthode : ne plus s'occuper de la partie cliente. Je ne développe maintenant que le moteur du jeu.

Haha, exactement pareil. Sauf que je n'ai pas perdu de code (je l'ai toujours dans un coin en totalité, mais je sais pas si ça resservira), mais je me rendais bien compte que ça n'avançait pas, que passer d'un langage à l'autre en permanence ce n'est pas génial pour la productivité, du moins sur une course de fond. Je fais donc mon moteur de jeu serveur, headless comme tu dis, et en TDD (mais plutot laxiste).

Ton document ressemble à peu près à ma roadmap : même niveau de détail très large, description des actions joueur. Quand tu arrives à un nouvel élement dans ta roadmap, tu le documentes comment ? tu écris les algos en français ou tu te contentes de décrire des use cases ?

[Akhyra]

Pour ma part, j'ai abandonné l'idée de mettre l'ensemble du jeu sur un papier pour la raison simple qu'on y travail pas 35 heures par semaine.

J'ai opté pour un document plus généraliste qui décrit les grands mécanismes du jeu ainsi que ceux qui sont clé pour le joueur, sans rentrer dans des valeurs ou équilibrage.
Ce document est ma base de travail pour concevoir la base de donnée en sachant que rien n'est définitif mais qu'il faut bien commencer par quelque chose.

Une fois la base de donnée dégrossi j'ai commencé à mettre sur papier un découpage des mécanismes / fonctions du jeu, par exemple: une page 'hello word' (permet de mettre en place la base de ton espace connexion base de donnée, template, etc.), module joueur (inscription/connexion/profil), module backend, etc.

Ca te permet d'avoir une idée globale de ce que tu dois faire et dans quel ordre, par la suite ça te donnera une idée de l'avancé de ton projet ainsi que de voir que tu avances (motivation).

J'ai codé chaque mécanisme dans ses grandes lignes, sans optimisation de code juste la fonctionnalité et ainsi de suite.

Quand j'ai commencé à avoir plusieurs mécanismes jouables, j'ai fais testé et récupéré les retours puis reprit le document initial et commencé à rédiger une 'documentation' (pas un descriptif complet) en prévision qu'une personne extérieur au projet puisse comprendre ce que j'ai codé.

Aujourd'hui nous en sommes presque à une version alpha complète du jeu, avec une documentation pour toute nouvelle personne dans l'équipe.

J'en suis persuadé maintenant, si j'avais commencé par écrire tout sur papier avant de coder je n'aurai jamais commencé le projet.

[niahoo]

Un pas supplémentaire serait de se mettre des deadlines, mais je ne suis pas encore prêt pour ça.

J'aimerais bien aussi, je vois mal comment je pourrais les définir sachant que c'est sur mon temps libre, qui varie en fonction d'autres activités ... C'est le meilleur moyen pour être constamment en retard et se décourager. Faire un projet sur son temps libre c'est aussi ne pas avoir de pression.

D'un autre côté, je remarque que quand j'ai un peu de pression au boulot, j'avance beaucoup plus vite, et c'est pas désagréable tant que ça reste humainement réalisable.


@Akhyra Merci pour ta réponse. J'ai remarqué également que j'essayais trop de faire du beau code, optimiser trop tôt ou refactorer ce qui vient à peine d'être "factoré"

Maintenant, je me force dans une certaine limite de faire du code pas optimisé du tout, en essayant d'être le plus simple possible (toutefois, j'essaie au maximum de respecter aussi les principes DRY et "Ne jamais copier-coller du code"). J'ai remarqué aussi que YAGNI est une bonne solution pour lutter contre l'optimisation prématurée et pour garder un code simple. On a beau connaître ces principes, on s'en éloigne parfois. Se remettre en question n'est pas chose aisée surtout car simplement on n'a pas tendance à le faire naturellement.

Bon, faut que j'aille écrire une roadmap un peu plus détaillée et surtout complète.

[Sephi-Chan]

Je vais répondre, même si ma légitimité sur la question est ridicule tant le développement de Seelies est une blague : j'ai commencé à travailler dessus en 2006.

Non mais pareil hein, je compte plus les années, mais j'ai beaucoup appris, ce n'est pas du temps perdu.

Pour moi aussi, les projets ont toujours été des prétextes pour apprendre. Donc je ne considère pas ça comme du temps perdu non plus.

Ton document ressemble à peu près à ma roadmap : même niveau de détail très large, description des actions joueur. Quand tu arrives à un nouvel élement dans ta roadmap, tu le documentes comment ? tu écris les algos en français ou tu te contentes de décrire des use cases ?

Souvent c'est assez léger : je rassemble les notes d'une page de cahier, des schémas, quelques algorithmes dégrossis en français, des exemples, etc. dans un document Markdown assez clairement rédigé et organisé.

Pour ma part, j'ai abandonné l'idée de mettre l'ensemble du jeu sur un papier pour la raison simple qu'on y travail pas 35 heures par semaine.

Puis ça a un petit côté "gravé dans le marbre" qu'on n'aime pas forcément.

J'ai codé chaque mécanisme dans ses grandes lignes, sans optimisation de code juste la fonctionnalité et ainsi de suite.

1. Make it work
   
2. Make it right
   
3. Make it fast
   

[Sephi-Chan]

Un pas supplémentaire serait de se mettre des deadlines, mais je ne suis pas encore prêt pour ça.

J'aimerais bien aussi, je vois mal comment je pourrais les définir sachant que c'est sur mon temps libre, qui varie en fonction d'autres activités ... C'est le meilleur moyen pour être constamment en retard et se décourager. Faire un projet sur son temps libre c'est aussi ne pas avoir de pression.

D'un autre côté, je remarque que quand j'ai un peu de pression au boulot, j'avance beaucoup plus vite, et c'est pas désagréable tant que ça reste humainement réalisable.

De mon côté, je vois plus ça comme un inconfort que comme une pression. L'inconfort de constater qu'on n'a rien fait peu agir comme un moteur, surtout quand on fait le point régulièrement avec quelqu'un d'autre.

@Akhyra Merci pour ta réponse. J'ai remarqué également que j'essayais trop de faire du beau code, optimiser trop tôt ou refactorer ce qui vient à peine d'être "factoré"

Maintenant, je me force dans une certaine limite de faire du code pas optimisé du tout, en essayant d'être le plus simple possible (toutefois, j'essaie au maximum de respecter aussi les principes DRY et "Ne jamais copier-coller du code"). J'ai remarqué aussi que YAGNI est une bonne solution pour lutter contre l'optimisation prématurée et pour garder un code simple. On a beau connaître ces principes, on s'en éloigne parfois. Se remettre en question n'est pas chose aisée surtout car simplement on n'a pas tendance à le faire naturellement.

Bon, faut que j'aille écrire une roadmap un peu plus détaillée et surtout complète.

J'essaye aussi de me forcer un peu sur le YAGNI en évitant de trop extrapoler mes besoins, mais sans non plus trop me verrouiller de manière débile sur ce dont je suis sûr d'avoir besoin un peu plus tard.

Par contre j'essaye toujours de coder impeccablement.

[MadMass]

Vos documents descriptifs font combien de page environ ? En ce qui me concerne je me base sur une description assez généraliste, pour mon jeu j'en suis à une vingtaine de pages
A votre avis, est-il nécessaire de prévoir l'équilibrage avant le code ?

[Ter Rowan]

mouarf je sais pas si je sortirais quelque chose un jour mais...

j'ai testé l'approche "je fais que le back office et on verra après pour l'expérience utilisateur" (à l'époque je ne savais pas si html 5, flex, etc...)
au début très motivant (tu t'embêtes pas avec l'aspect présentation ni rien, tu avances vite)
puis vient le moment du refactoring (eh mais oh non mais he) *3
puis vient l'épuisement


maintenant je suis une approche sur trois axes :

- je définis des modules plus ou moins indépendants avec deux objectifs :
1) une fois développé je n'y toucherai plus
2) ils pourront être réutilisés (j'ai une dizaine d'idées de jeux, je ne me concentre pas dessus, je reste sur mon chemin principal, mais voilà gain à long terme si quelque chose sort)

- je fais des POC, indépendamment du jeu. Une fois que le poc est bon, je réutilise le code, si le poc est mauvais je repense la fonctionnalité, ou je teste autre chose. Du coup t'avances sur des petits sujets (exemple de poc : ihm pour modifier un dessin svg, utile pour les modules de création d'avatar, de blason, de maillot, etc...)

- je repars sur l'utilisateur : j'ai fais ma page de jeu, j'y ai mis toutes les options (en texte simple) et je les développe une par une. Là j'en chie pour visualiser le terrain, faire des perspectives a partir d'hexagone alors que j'ai toujours été mauvais en géométrie, mais une fois réalisé j'aurais fait un grand pas en avant.

C'est quand même plus motivant de pouvoir "jouer" un minimum (bon là je ne peux que créer des terrains autour de la case ou je suis.... question expérience ludique c'est assez bof)mais bon une fois fait je pourrais, comme un jeune dieu fringant, me promener sur la carte et construire à la frontière de mon empire de nouveaux lieux sur le chaos qui entoure le monde