Version imprimable
Bonjour,
Je viens de publier un article sur mon retour d'expérience sur la création du jeu amateur : Simerion.
J'ai travaillé 5 ans sur ce jeu vidéo amateur par navigateur web. J'ai pu tirer énormément d'enseignements de cette expérience qui m'a été très bénéfique par la suite. Je profite de cet article pour partager cela avec vous :
http://yoannsculo.developpez.com/tut...t-jeu-amateur/
Bonne lecture.
Un bien beau retour d'expérience. On communique trop souvent sur les réussites et pas assez sur les échecs; ils sont pourtant majoritaires. M'étant moi même lancé dans l'aventure du développement d'un jeu en ligne sans y avoir vraiment été préparé (Projet Foutu d'Avance comme tu les appelles ^^), je te tire mon chapeau pour avoir tenu le coup aussi longtemps.
Tu ne parles pas beaucoup de l'aspect financier. Vous vous êtes versés des salaires ? D'où venait l'argent le cas échéant ?
Merci ithel :)
Aucuns revenus d'argent de notre côté. Vu que nous n'avons pas dépassé la centaine de joueurs, nous n'avons pas eu grand chose niveau revenus publicitaires.Citation:
Envoyé par thierryler
Tout passait par notre association et par les autres jeux qui équilibraient le tout. L'association était (est) hébergée à titre gratuit dans un gros datacenter. Du coup les rentrées d'argent c'est la publicité sur les autres jeux, les cotisations et les dons. Certains jeux étaient rentables, d'autres comme Simerion, ne l'étaient pas du tout. Donc tout était supporté par Nainwak.
Une des conditions pour rentrer dans l'associations est (car l'asso existe toujours) de reverser toutes les rentrées d'argent à l'association.
Et comment avez-vous payé vos repas, loyers, etc.
Bravo pour ce billet fort interessant Aquanum.
J'aime beaucoup ta partie sur la communauté (vu que j'en ai l'expérience) : les betas permettant de disposer d'utilisateurs motivés, etc.
Dans le cadre d'un jeu, il est clair aussi qu'il est important d'avoir un jeu de base même imparfait à montrer, faire utiliser pour que l'aspect communauté permette de garder la motivation.
Cependant je rajouterais qu'il faut aussi bien avoir conscience que les gens sont ingrats de nature et que donc il y a aussi sa part de raleurs, chieurs, tricheurs etc à gérer.
Et merci pour la phrase sur l'association (au vu de sa création et de son passé, on aurait jamais pensé qu'elle serait encore là).
David
C'était un jeu amateur fait sur notre temps libre (j'éais étudiant). Le jeu n'a jamais été conçu pour faire de l'argent en fait. Même si une entreprise m'a proposé de monétiser le jeu, j'ai préféré continuer sur un jeu amateur et conçu pour le plaisir.Citation:
Envoyé par thierryler
Ah ok, ce n'était pas clair que ça n'était pas du full time.
Bonjour,
je voudrais juste relativisé ton article avec un exemple bien connu de développement amateur qui rivalise largement (côté popularité) avec les développements pro : MineCraft.
ceci dit ce jeu a en effet commencé très tôt a présenter des versions jouables et "pas finies", comme la version actuelle sous Androïd :)
ceci dit le travail en équipe est très difficile sur des projets amateurs; des gens partent en cours de route, les investissements ne sont pas les mêmes pour tous (on a chacun sa vie) et il est difficile de critiquer le travail des autres quand leur contribution est bénévole...mais pas à la auteur des espérances :)
Merci pour ton retour d'expérience, c'est tres bien rédigé et formateur.
En tout cas c'est courageux de votre par de se lancer dans un tel projet et de durer aussi longtemps. Je vous tire mon chapeau.
Par contre je ne comprend pas trop les raisons de ton désamour pour la POO. Je maitrise les bases de PHP et au quotidiens je développe en ASP.Net / C#. En ASP je n'ai jamais eu de probleme d'engorgement du serveur a cause d'un nombre trop important de requetes SQL, il y a des techniques comme le lazy-loading et l'utilisation du cache qui prennent bien soins de la performance et ce, tres facilement implémentable pour le développeur.
Apres pour un jeu les cartes sont redistribuées car c'est une tout autre approche (aucun rechargement de page, usage de AJAX et JSON), mais meme j'ai du mal a comprendre comprendre comment éviter l'approche objet et tous ses avantages.
d'après ce que je comprend de l'article, le code instancie un objet Appartement qui va lire ses caractéristiques dans la base, puis instancier un objet bâtiment qui fait de même...etc jusque la planète. Si c'est pour afficher le nom de l'appartement ça fait 4 ou 5 requêtes pour faire un appt->getNom() alors qu'un simple "SELECT nom FROM appartements WHERE id = $id" aurait suffit :)Citation:
Envoyé par alex_vino
Autant j'utilise la POO pour mes développements Windows, autant je la réserve en PHP a des fonctions complexes qui donnerait un code procédural difficile à maintenir. ça permet notamment d'éviter les "global" ou les paramètres à rallonge.
Car la grosse différence entre PHP et un développement Windows, c'est qu'on travaille par requête, du coup tous les objets sont recréés à chaque requête du navigateur. Ce n'est pas forcément perceptible sur une application de gestion (et encore) mais sur un jeu ou les temps de réponse sont importants on va au plus vite.
Oui c'est vrai, mais je suis tout de meme encore perplexe.Citation:
Envoyé par Paul TOTH
En POO tu peux aussi charger seulement ton objet sans les dépendances, tu fait une classe statique qui te retourne seulement ton objet avec seulement l'ID des relations. Ainsi la POO te permet de faire du code bien plus maintenable, debugable et surtout sure (tu peux ajouter des validations sur ton objet avant de le sauvegarder, tu es ainsi certains d'avoir ton objet dans un état valide et cohérant).
En effet, j'aurais tendance à revoir mon analyse sur la POO et sa liaison avec la BDD.
Etant donné que lorsque nous nous sommes lancé, nous avons tout refait nous même, nous nous sommes heurtés à cette problématique sans pour autant avoir cherché des solutions clé en main.
Donc je suppose qu'il existe aujourd'hui des outils qui permettent de travailler en POO de façon transparente et sans pour autant mettre à genou la BDD.
Donc je suis d'accord que pour un projet d'ampleur comme celui-ci la POO reste très intéressante. Sans vouloir partir dans un troll sur la POO, je pense que de la POO ou du procédural, c'est du pareil au même. Pour moi tout dépend de la qualité du développeur qu'il y a derrière. Enfin si j'avais à le refaire, je pense que j'hésiterais assez longtemps entre les deux modèles.
Très bon article... Je suis impressionné par le travail accompli à l’époque.
S’agit-il d’un projet open source ? J’ai vu que tu avais libéré les images, mais qu’en est-il du code source ?
Je suis surpris de ne lire nulle part qu’un des problèmes n'ait pas été de de ne pas avoir disposé de tests automatisés (tests unitaires, de fonction ou autre). En aviez-vous ?
Il me semble que c’est une grande aide pour:
- s’assurer que l’on ne casse rien lors d’un refactoring.
- avoir une sorte de documentation: permettre aux autres de comprendre le fonctionnement d’un petit ensemble.
Dans le même ordre d’idée, je me pose la question de la gestion de vos sources et de l’usine logicielle (intégration continue...) dont vous disposiez (si vous en aviez une). Ce sont des choses dont j’ai pris conscience dans mon premier gros projet (un stage dans une très petite entreprise). Quelle que soit la technologie, il me semble que ne pas en disposer, c’est se compliquer la vie.
Je viens de contribué à un projet open source disposant de git, gerrit et hudson. C’est vraiment génial.
Merci :)
J'ai été contacté suite à la publication de cet article pour passer le code en licence libre :p
J'avais également bien réfléchi à la chose, et j'ai choisi de ne publier que les images du jeu en Creative Commons. Et j'en étais arrivé à la conclusion qu'il y avait peu d'intérêt de publier le code source du projet. Et pour différentes raisons :
- Le code est en français / franglais
- Il est particulièrement crade
- Il n'a pas du tout été pensé pour être passé open source
- Il n'est pas documenté
- tous les outils utilisés sont maison et ne s'appuient sur rien de libre. On a réinventé la roue, et ce n'était pas réellement très pertinent d'avoir fait ça.
- La BDD est pas réellement bien conçue et nécessiterait une refonte.
- une telle publication implique de se replonger dans le code pas touché depuis 2009... Pas envie...
Et comme je considère que la fin/mort d'un projet ne justifie pas une publication sous licence libre si la qualité n'est pas au rendez-vous, j'ai préféré garder ça pour nous. J'ai déjà eu à ouvrir le code d'un ancien projet (en français, crade et pas documenté). Ça donnait ça, une horreur.
Je préfère publier du code de qualité.
Concernant les tests unitaires. Non nous n'en avions pas. J'ai appris leur intérêt que bien après :)
Par contre niveau forge et outils de gestion de versions, nous avions SVN et Trac. Outils bien pratique, et puis qui m'ont permis d'apprendre beaucoup.
Aujourd'hui je prendrais le package git/Jira/Jenkins (anciennement Hudson) pour tout nouveau projet un peu gros.
Tu as bien raison... A titre personnel je n'en aurais rien fait...Citation:
Envoyé par Aquanum
Jenkins est un fork d'Hudson* dont le développement continue. Hudson 3.0 sera proposé sous licence EPL.Citation:
Envoyé par Aquanum
Côté review des sources:
Je dois dire que je suis devenu fan de gerrit. Ce mode de fonctionnement me semble encore plus pertinent que github et ses pull request.
Coté gestion de ticket:
JIRA est souvent cité, mais je ne suis pas si persuadé que le prix (dans le cas d'un projet non open source) vaut le coup.
Enfin c'est clair que ces outils aident beaucoup....
* J'ai conscience que cette phrase est un tout petit peu réductrice: la branche historique d'Hudson a été renommé Jenkins et le nouveau Hudson est devenu un projet de la fondation Eclipse (soutenu par Oracle, Sonatype, Tasktop, WMware...). L'ambition est de donner une dimension plus "entreprise" au projet (changement de licence, changement du mode du rythme de version, réécriture de certaines parties...). A mon avis il y a de la place pour les deux projets.
Héhé idem. Mais ce n'était pas ma décision. Plutôt que maintenir un produit, mon ancien employeur avait choisi de libérer les sources pour se dédouaner du service qui ne fonctionnait plus bien. C'était vraiment sale comme technique. Maintenant je fais gaffe à ce que je mets en open source.Citation:
Envoyé par jmini
Super retour d'expérience et comme le dit si bien ithel:
Je m'étais moi-même lancé dans un projet d'envergure en 1985 (en tout cas, il l'était pour moi, je savais à peu près rien en programmation). Je trouvais que les environnements de développement en Assembleur était hyper compliqué. Je venais de découvrir Turbo-Pascal 1.0 qui a été toute une révélation pour moi. J'avais donc décidé de faire l'équivalent pour tous les micros 8 bits de l'époque et à venir. J'ai donc fait EMAT (Environnement Multi Assembleurs Tesg) qui fut tout un échec (Fonctionnel mais très distribution très confidentielle, 10 copies vendues à 29,95$!). Ciel que j'ai bossé là-dessus. Deux ans.Citation:
Envoyé par ithel
J'ai quand même appris beaucoup en programmation. En fait, ce fut le début du passage du Guyt, prof d'électronique à Guyt, prof de programmation. Est-ce que je le regrette? OUI!!!
Enseigner l'électronique, c'est bien parce que c'est basé sur du solide. Tu fais pas de la conception de circuits à la "Va comme je te pousse", en improvisant sur une plaquette blanche avec des composants, jusqu'à ce que ça finisse par marcher, comme le font mes étudiants en programmation.
J'aurais dont dû rester prof d'électronique-ique-ique. Quand tu donnes un cours sur les circuits intégrés linéaires, c'est pas des opinions que t'émets. ;)
Au moins, Aquanum ne semble pas être sortir amer de son expérience, tout au plus cela l'aura éloigner de la programmation web pour l'amener vers les systèmes embarqués. Vers le monde réel, quoi. ;)
Héhé c'est l'idée :aie: Finalement je me suis dit que je pourrais faire des trucs encore plus awesome en construisant des produits physiques. Et du coup Simerion a eu un réel effet dans mon choix de carrière.Citation:
Envoyé par Guyt54