+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Débuter et gérer son projet (https://jeuweb.org/forumdisplay.php?fid=60)
+--- Sujet : Quelle vision à long terme pour le développement du jeu (/showthread.php?tid=6801)
RE: Quelle vision à long terme pour le développement du jeu - niahoo - 03-02-2014
"Gravé dans la roche" tu veux dire. Attention, je ne dis pas que je code crado, mais simplement parfois au lieu d'utiliser un itérateur particulier, une structure de données mûrement réfléchie, je n'hésite pas à préférer une boucle un peu con con et un simple dictionnaire. C'est plus de lignes de codes, mais c'est trivial à lire, donc facile à refactorer par la suite. (et en Erlang ça reste quand même au moins 2 fois moins de lignes que dans mes autres langages)
Pour yagni je ne trouve pas que ça te verrouille, le principe de base est d'ailleurs justement d'éviter les verrous, non ? Mais effectivement, quand on sait qu'on a besoin de quelque chose, autant lui réserver sa place dès le départ. J'essaie simplement d'être sûr à 100% que ça sera utilisé.
Le markdown c'est cool oui. Avec Jekyll je commence à avoir une doc sympa à parcourir.
Faire le point avec quelqu'un ce serait pas mal oui, mais le forum est fait pour ça. Je vais peut-être devoir me décider à présenter mon projet.
RE: Quelle vision à long terme pour le développement du jeu - Akhyra - 03-02-2014
Citation :Par contre j'essaye toujours de coder impeccablement.
Je fais une grande différence entre "l'architecture" et le code en lui même. Quand je parle de coder rapidement c'est coder l'architecture proprement avec un maximum de fonctions, de réutilisation, etc. mais quand j'écris l'intérieur des fonctions / classes je ne cherche pas le code parfait (temps d'exécution, boucle, requêtes, mémoire, etc.)
S'apercevoir que son architecture fichiers, classes, orm, etc. est bancale ou codée trop vite au beau milieu du projet est souvent signe d'un arrêt de motivation alors qu'un code un peu 'sale' c'est moins gênant juste un @todo à faire
Quand j'ai pas assez de temps pour lancer un chantier ou une idée je repasse sur le code d'une fonction pour l'optimiser mais sans changer le 'autour' (règle d'or).
@MadMass, déjà qu'écrire un document c'est dur, penser l'équilibrage avant le développement c'est inhumain :p
RE: Quelle vision à long terme pour le développement du jeu - niahoo - 03-02-2014
(03-02-2014, 11:28 AM)Ter Rowan a écrit : - 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...)
J'ai fait la gestion de l'inventaire et un petit ORM maison comme ça (il n'existe pas d'ORM en erlang, enfin pas comme j'en avais besoin). C'est vrai que le bénéfice est double car développé séparément : ça fait un petit projet en soi dont on sort une release, (enfin quelque chose qui sort !) et ça fait quand même avancer le développement du jeu. (Et bonus, c'est réutilisable.)
Pour la partie IHM je pense que là pour le coup je ferai appel à quelqu'un pour m'aider. Si le moteur de jeu est fini ça donnera confiance dans le projet puisque "yaka" implémenter les appels vers le moteur.
RE: Quelle vision à long terme pour le développement du jeu - Sephi-Chan - 03-02-2014
Par code impeccable, je veux dire que je ne m'autorise pas à dire : c'est pas top mais je nettoierai plus tard. Car on sait tous comment ça finit.
(03-02-2014, 11:36 AM)niahoo a écrit : Faire le point avec quelqu'un ce serait pas mal oui, mais le forum est fait pour ça. Je vais peut-être devoir me décider à présenter mon projet.
Oui, fait ça. :p
RE: Quelle vision à long terme pour le développement du jeu - yceos - 04-02-2014
D'une maniere generale, je "griffonne" les grandes lignes (que ca soit du jeu complet, ou a chaque fois d'une nouvelle fonctionnalite). Une fois que je sais a peu pres ou je veux aller, je stock (ou l'inverse) les donnees dont je vais avoir besoin (petit MPD rapide). Apres je code la (ou le groupe de) fonctionnalite(s), pas trop crado, mais sans chercher l'optim ultime. Je test, je re-test, je re-re-test, je fais tester (ca aide d'avoir quelques potes sur une "alpha"). Quand ca marche, j'optimise tout de suite.
J'ai pas vraiment de doc centralisee, plutot plein de feuilles papier / quelques fichiers texte/markdown qui mis bout a bout seraient probablement incomprehensibles ! Mais qui m'ont bien aide sur le moment. Ah oui, et je commente mon code (meme tout seul dessus ca aide 3 mois plus tard quand un tester tombe sur LE cas qui bug !).
Pour ce qui est de l'ordre back/front, en general je fais le back et une ebauche "moche" du front, quand le back fonctionne correctement je fais le front propre (c'est cette version qui est testee par les joueurs). Ensuite a moins d'un besoin ergonomique profond ou quelques menus changement de virgule je touche plus au front.
(En fait on retrouve le make it work / make it right / make it fast de Sephi)
Sinon, je jongle pas dans une meme heure avec plusieurs langages (enfin pas trop), mais etant seul sur le projet, et utilisant PHP, MySQL (y compris des grosses procedures stockees) & du NodeJS j'ai pas vraiment le choix. Et finir un element sans avancer les autres au fur et a mesure est absolument hors de question, trop ennuyeux a mon gout. J'ai besoin du "renouveau" constant de passer d'un gros bout de php a l'ecriture d'un morceau pur SQL, pour le Node je debute encore... mais ca m'amuse bien !
Le drame c'est quand mes testers viennent me voir avec une phrase du genre : "ton truc la c'est nul" (avec des arguments pertinents pour soutenir la chose!). En general, c'est 2/3 jours de reflexion avec eux, et pour etre sur de pas refaire la meme chose: delete de tout le code associe. C'est d'ailleur une methode que j'emploi assez souvent: si apres avoir cherche pendant un certain temps je trouve pas la solution a un probleme dans le code, j'efface et recommence ... J'ai de la chance, j'ai pas encore trouve un probleme fondamental dans le jeu complet !!
Pour ce qui est de la "pression" ou des deadlines: c'est en general a la pause cafe du matin: bon les gars, semaine prochaine je vous livre tel ou tel truc (souvent un truc nouveau, pas encore commence !). Pas d'engagement contractuel, mais un peu une sorte de promesse quand meme.
Dans l'ensemble je m'eloigne pas trop des idees originales, par contre je ne respecte pas forcement un ordre hierarchique. Il est tres courant que je refactor/re-oriente un morceau qui me turlupine plutot que d'avanceer sur une nouvelle fonction prevue. En general c'est motive par un probleme de gameplay, et parfois, quand je me suis rate, un probleme de perf. Je considere que le web est quelquechose d'instantane, donc attendre le lancement de telle action 1.5 sec est potentiellement inadmissible: quand je clic je veux une reponse tout de suite. Qu'une flotte mette N heures a arriver a destination ok, mais que le lancement de la dire flotte prenne 1.5/2sec PAS ok ! Et comme j'ai un tout petit serveur pour l'hebergement (ovh KS2G 2013 pour ceux qui connaissent) l'optim se voit tres rapidement. C'est d'ailleurs a cause de ca que je switch progressivement certain morceaux vers du NodeJS: optim des traitements.
Donc je n'hesite pas a remettre en question certains choix technique initiaux quand j'en atteints les limites. Mais comme naturellement je decompose chaque "gros" probleme en plusieurs "petits" je code naturellement modulaire (trop meme parfois !) du coup je change un bout sans reel impact profond sur le reste. Au final, je reste dans l'idee initiale: le plus de "temps reel" possible, le moins d'"estimations" possible.
RE: Quelle vision à long terme pour le développement du jeu - niahoo - 04-02-2014
(03-02-2014, 09:39 PM)Sephi-Chan a écrit : Par code impeccable, je veux dire que je ne m'autorise pas à dire : c'est pas top mais je nettoierai plus tard. Car on sait tous comment ça finit.
Oui ... perso quand l'implémentation est correcte (du moins correctement testée) je m'autorise à passer à autre chose. Sauf évidemment si cela saute aux yeux que l'algo est inutilement bourrin. Je réserve la partie make it fast pour plus tard.
(03-02-2014, 09:39 PM)Sephi-Chan a écrit :(03-02-2014, 11:36 AM)niahoo a écrit : Faire le point avec quelqu'un ce serait pas mal oui, mais le forum est fait pour ça. Je vais peut-être devoir me décider à présenter mon projet.
Oui, fait ça. :p
Ouais je vais m'y mettre très prochainement. Je finis de concevoir la structure de base des arbres de skills pour les persos d'abord.
Merci pour ta réponse yceos, c'est vrai que c'est cool d'avoir une équipe. Bon je me sens bien seul à mon rythme aussi.
Concernant Node ou PHP je n'utilise ni l'un ni l'autre pour mon projet (je ferai peut être le module d'inscription en PHP vu que j'en ai déjà un prêt), mais bon ça m'étonne quand même des temps de réponse de 1.5s. En local tu as quoi comme temps de réponse ?
RE: Quelle vision à long terme pour le développement du jeu - yceos - 04-02-2014
(04-02-2014, 12:42 AM)niahoo a écrit : Merci pour ta réponse yceos, c'est vrai que c'est cool d'avoir une équipe. Bon je me sens bien seul à mon rythme aussi.ca motive surtout a avancer, a faire "mieux".
(04-02-2014, 12:42 AM)niahoo a écrit : ais bon ça m'étonne quand même des temps de réponse de 1.5s. En local tu as quoi comme temps de réponse ?Triple execution d'une procedure stockee qui verifiait et calculait enormement de choses ... (un SGBD c'est fait pour faire de l'ensemble, pas de l'unitaire !) en local quasi instantane, mais meme monothread (mysql utilise un seul thread pour un traitement donne) il n'y a pas de comparaison possible entre un atom N2800 et un Core i5 Sandy, la puissance brute n'est pas LA solution !
RE: Quelle vision à long terme pour le développement du jeu - Argorate - 04-02-2014
C'est le problème de beaucoup de gens qui m'ont parlé de leur parcours dans la création de jeu, ils commencent avec une idée, puis il commence a coder et change en cours de route, voir recommence tout car cela ne leur plait plus.
La clé selon moi c'est de ne pas trop se détourner du chemin. Il faut tracer une voie, bien y réfléchir, mais une fois qu'on commence à l'emprunter, faut y aller jusqu'au bout, même si plein d'idée génial de jeux autres nous viennent en tête (personnellement je note ces idées pour de potentiel futur jeux), mais j’essaie de poursuivre le projet en cours.
Après il faut se forcer un peu à persévérer, c'est souvent là le plus dur. Je pense qu'il faut effectivement se faire une todo list et avancé pas à pas. il est parfois important d'avoir des résultats tangible pour que le moral suive. Il est donc conseillé de parfois coder quelques chose qui aura un impact visuel, ou un résultat facilement visible sur l'application pour être content de son avancement.
Bref, c'est là que le vrai travail commence...
RE: Quelle vision à long terme pour le développement du jeu - MadMass - 04-02-2014
Moi je garde vraiment à l'esprit que quand je programme une feature, je pourrais la modifier derrière. Parce quand on code c'est bien on a trouzmille idées géniales auxquelles ont avait pas pensé, et au final on arrive à rien. Je pense qu'il est mieux de se tenir à ce qu'on voulait faire et garder l'idée de côté pour l'implémenter plus tard, que de tout implémenter à l'arrache et au final ne même pas arriver à faire ce qui était prévu au départ.
RE: Quelle vision à long terme pour le développement du jeu - MarcusS - 05-02-2014
Je vais donner mon avis, même si j'ai pas encore réussit à prendre le temps de réellement programmer.
D'abord je pense que lorsque l'on code seul, on peu être plus laxiste que lorsque l'on travail en groupe. En contre partie, c'est plus difficile de rester motivé.
Ensuite j'aurais tendance à :
- Dicter une ligne de conduite moyennement définit dès le départ.
- Découper en module réutilisable pour divers jeu (personnage, carte, inventaires, objets, combat ...) et "évolluable" (ajout d'une nouvelle compétence personnage, nouvelle fonctionnalité sur un objet ...).
- Établir le cahier des charge d'un module.
- Programmer le module et le valider (voilà, j'ai avancé parce que ce module marche yyyeesss).
- Lui faire une IHM (back et front) sommaire (design) mais complet (fonctionnalités).
- Documenter mon module (fonctions, paramètres, points d'entrées).
Enfin comme je l'ai dit, c'est ma vision utopique que je n'ai pas mis en oeuvre.