Statistiquement et un peu à la louche, 1 ligne de code au boulot, c'est entre 3 et 5 commits. Donc en gros, 1 ligne de code coûtera 2x plus cher à maintenir qu'à créer (faudrait de vraies stats, mais c'est l'ordre d'idée). Là, tu vas déboguer ton truc (ça va te bouffer quelques jours). Après, tu auras des nouvelles features à rajouter plus tard (souvent pour rattraper ce que les autres font déjà, genre déplacement en drag & drop, et boum, tu rajoutes plus tard le déplacement avec les flèches puis avec la souris en bord d'écran, puis des préférences pour choisir ce qu'on veut). Au final, tu vas finir par recoder des bibliothèques qui existent déjà (et il n'y a pas besoin d'aller loin pour en trouver: Prélude en a fait une me semble-t-il).
Je comprends très bien la notion d'aimer le faire soi-même pour voir ce qu'on vaut. Ce n'est pas un problème en soi. C'est l'exacte même raison qui me pousse à faire un Sudoku quand j'ai quelques minutes à perdre (alors que j'ai déjà un Sudoku solver qui saurait le faire directement; et ce Sudoku-solver je l'ai fais pour m'amuser à passer du temps puisqu'il en existe déjà des tas).
Le problème risque d'apparaitre si tu veux véritablement "industrialiser" le jeu. J'entends par là le sortir un jour, le rendre jouable, le faire connaître, gérer la communauté qui va avec, etc. Tu vas en effet passer du temps sur tout un tas de problématiques déjà résolues, venir avec ta solution (qui sera peut-être aussi bien que celle d'un FW ou d'un standard, mais elle sera spécifique et incapable de causer directement avec les autres solutions existantes des FW/standards) et finir par passer tout ton temps sur de la maintenance de code plutôt que de l'évolution de jeu.
Ce n'est pas un mal d'utiliser des Framework (même si c'est ce qu'on peut penser en m'entendant). Industriellement (pour l'efficacité), la sauce maison est le pire. Le Framework est mieux. Le standard est top (et par standard, j'entends "ce qu'il offre directement", pas "ce qu'il offre après avoir passé 6 mois à refaire mon Framework dessus").
Je pense (mais cela n'engage que moi) que la meilleure solution est de bien distinguer le code à loisir (c'est en gros tout ce que j'ai foutu sur mon Tests & Tries) et le code au service d'un projet (le code du jeu, le code d'un plugin Wordpress, peu importe). Le premier est un code dont on n'attend rien de plus que le simple plaisir de l'avoir fait, alors que le second est un code dont on attend un résultat.
Ce sont deux optiques différentes, l'une n'est pas meilleure que l'autre, mais prendre l'une (son codage à loisir pour le plaisir de voir ce qu'on veut) pour l'autre (le code dont le résultat importe) est une mauvaise stratégie (stratégie que j'appelle "j'ai des grosses couilles alors je refais tout").
PS: Ca rejoint l'un de mes articles sur temps métiers, temps système: l'implémentation (le code) est une toute petite partie d'un jeu. Comme tu n'as pas du temps libre extensible, il vaut mieux équilibrer les choses et éviter de passer trop de temps dedans -sauf, là encore, si t'aimes juste coder et que le jeu n'est qu'une excuse bidon pour le faire (auquel cas je t'invite plutôt à participer à des projets open source, que ce soit Firefox, PHP, un framework ou peu importe: t'auras le plaisir de coder des trucs, qui seront rendus utiles par les autres).
Je comprends très bien la notion d'aimer le faire soi-même pour voir ce qu'on vaut. Ce n'est pas un problème en soi. C'est l'exacte même raison qui me pousse à faire un Sudoku quand j'ai quelques minutes à perdre (alors que j'ai déjà un Sudoku solver qui saurait le faire directement; et ce Sudoku-solver je l'ai fais pour m'amuser à passer du temps puisqu'il en existe déjà des tas).
Le problème risque d'apparaitre si tu veux véritablement "industrialiser" le jeu. J'entends par là le sortir un jour, le rendre jouable, le faire connaître, gérer la communauté qui va avec, etc. Tu vas en effet passer du temps sur tout un tas de problématiques déjà résolues, venir avec ta solution (qui sera peut-être aussi bien que celle d'un FW ou d'un standard, mais elle sera spécifique et incapable de causer directement avec les autres solutions existantes des FW/standards) et finir par passer tout ton temps sur de la maintenance de code plutôt que de l'évolution de jeu.
Ce n'est pas un mal d'utiliser des Framework (même si c'est ce qu'on peut penser en m'entendant). Industriellement (pour l'efficacité), la sauce maison est le pire. Le Framework est mieux. Le standard est top (et par standard, j'entends "ce qu'il offre directement", pas "ce qu'il offre après avoir passé 6 mois à refaire mon Framework dessus").
Je pense (mais cela n'engage que moi) que la meilleure solution est de bien distinguer le code à loisir (c'est en gros tout ce que j'ai foutu sur mon Tests & Tries) et le code au service d'un projet (le code du jeu, le code d'un plugin Wordpress, peu importe). Le premier est un code dont on n'attend rien de plus que le simple plaisir de l'avoir fait, alors que le second est un code dont on attend un résultat.
Ce sont deux optiques différentes, l'une n'est pas meilleure que l'autre, mais prendre l'une (son codage à loisir pour le plaisir de voir ce qu'on veut) pour l'autre (le code dont le résultat importe) est une mauvaise stratégie (stratégie que j'appelle "j'ai des grosses couilles alors je refais tout").
PS: Ca rejoint l'un de mes articles sur temps métiers, temps système: l'implémentation (le code) est une toute petite partie d'un jeu. Comme tu n'as pas du temps libre extensible, il vaut mieux équilibrer les choses et éviter de passer trop de temps dedans -sauf, là encore, si t'aimes juste coder et que le jeu n'est qu'une excuse bidon pour le faire (auquel cas je t'invite plutôt à participer à des projets open source, que ce soit Firefox, PHP, un framework ou peu importe: t'auras le plaisir de coder des trucs, qui seront rendus utiles par les autres).