Comment le faire ou une conception logicielle solide?

Avec à peine assez de temps pour terminer les jeux que nous concevons, comment pouvez-vous trouver un bon équilibre entre une architecture logicielle solide et faire de bons progrès pour tout faire?

Mon défi personnel: que diriez-vous d'être efficace aujourd'hui et de penser à long terme en même temps? De plus, pendant que vous le faites, vous pouvez tout aussi bien vouloir apprendre de nouvelles choses en cours de route au lieu de recourir aux mêmes schémas répétitifs que vous avez utilisés ces 5 dernières années?

Moins vous avez d'expérience, plus vous perdez de temps avec la conception à l'avant. Faire de bons dessins est quelque chose que vous apprendrez en le faisant, puis en voyant / évaluant comment cela se passe. Certaines décisions ont des implications profondes mais obscures. Après quelques jeux, vous serez probablement en mesure de rendre la conception initiale assez solide et il sera rentable d'investir un peu plus de temps dans cette étape.

Ma devise: faire avancer les choses en premier lieu, mais utilisez votre bon sens pour détecter quels composants sont plus critiques que d'autres et les conçoit plutôt bien, dans votre délai. Par exemple, si l'IA est essentielle à votre jeu, assurez-vous que vous pouvez facilement l'étendre / la modifier plus tard. Ou, si vous allez écrire un composant que vous utiliserez dans chaque jeu, concevez-le pour qu'il soit réutilisable. Suivez votre temps et ne vous déchaînez pas sur la conception. Définissez une date limite de conception et après cela, commencez à tout pirater pour obtenir votre date limite de sortie. Mais assurez-vous de noter quels points doivent être refactorisés / repensés par la suite et calculez dans un certain temps avant de commencer le prochain jeu pour améliorer ces choses, afin qu'ils ne vous mordent pas en arrière!

Un bon conseil: si vous devez choisir entre deux options, ne vous attardez pas trop sur les détails. Le plus souvent, il n'y a pas de «bon» ou de «mauvais». Dans certaines situations, A sera meilleur, dans certains, B sera, et dans l'ensemble, la différence entre les deux ne vaut pas toujours la peine.

Il y a beaucoup d'expérience à acquérir dans la conception de logiciels ou de jeux, alors assurez-vous de consacrer une partie de votre temps à la recherche (par exemple, lire un livre sur la conception, lire sur l'expérience des autres, parler avec vos collègues programmeurs de vos conceptions, etc.). ).

Les gens sont terribles à prédire l'avenir. Cela est particulièrement vrai pour les jeux, où les exigences peuvent changer quotidiennement.

Il y a un principe appelé YAGNI , alias « yagni », qui dit essentiellement que vous ne devriez pas mettre en œuvre quelque chose jusqu'à ce que vous savez que vous allez en avoir besoin.

J'ai vu tellement de systèmes s'enliser dans une rigidité architecturale qui n'en utilisait pas réellement depuis que les fonctionnalités que les gens pensaient avoir besoin n'avaient jamais été utilisées.

Ma philosophie personnelle est faire la chose la plus simple qui pourrait fonctionner . Cela étant dit, il y a une différence entre Getting It Done et Hacking Shit Together. Écrire du code avec un but ne devrait pas impliquer de faire des choses qui génèrent une "odeur de code" comme rendre tout public, d'avoir des classes d'objets blob qui font tout, ou n'importe laquelle de ces dizaines d'autres choses qui signifient un "mauvais" code.

Cela équivaut à vrai dans ma mentalité aujourd'hui:

• Pragmatisme sur l'idéologie
• (1) Faites-le fonctionner (2) puis faites-le bien - recommencez si vous oubliez l'étape 2
• Publiez-le!
• Trop de conception initiale sera une perte de temps
• TDD et Clean Code conduisent à des conceptions logicielles plus simples et plus stables

Je suis l'ami du prototypage rapide de logiciels. Surtout pendant le développement du jeu. C'est bon pour l'apprentissage rapide, les tests et l'utilisation des choses. Pour une programmation proche du matériel ou des algorithmes compliqués, c'est la meilleure méthode pour moi.

Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
 Testing();
 LotOfFixing();
 PlayingWith(); 
 bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();

Ma version de Rapid Prototype doit avoir une croûte de prototype appropriée:

• Interface d'entrée conviviale pour configurer les directives et configurer les variables ou les données.
• Exceptions stables et gestion des erreurs.
• En ligne comme la fonction de débogage mais au niveau dont vous avez besoin.
• Interface de sortie conviviale pour afficher ou capturer les résultats de toutes les manières possibles et nécessaires.

Avantages:

• Vous pouvez améliorer la croûte RapidPrototype pendant tout le développement.
• Vous pouvez voir et configurer votre code de plusieurs façons.
• Vous ne pouvez vous concentrer que sur la théorie et les problèmes que vous devez résoudre.
• Vous pouvez rapidement développer toutes les nouvelles parties du projet et l'essayer avec le reste des choses finales.
• Vous pouvez fournir de nouvelles choses à utiliser dans le remplissage de contenu plus rapidement et le finaliser plus tard (en particulier dans le cas d'un bac à sable).
• Vous pouvez facilement décrire et montrer des principes ou des solutions à quiconque. En ligne.
• Le prototype fonctionnel et transparent est la meilleure source d'informations pour le code final (n'importe qui d'autre peut le faire).

Si vous le faites bien, vous pouvez avoir une vraie version de débogage / apprentissage de votre produit à la fin.
Nous l'utilisons dans notre projet et nous en sommes satisfaits.

Jetez un œil au développement logiciel agile . Bien que ce ne soit pas une solution miracle, il vise à faire les deux (le faire et avoir une conception logicielle solide).