Comment le faire ou une conception logicielle solide?


17

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?

Réponses:


20

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.). ).


7
+1, bon conseil. Ne vous laissez pas prendre par la tristement célèbre paralysie de l'analyse, car cela ne vous mène nulle part. Alors que le refactoring est un outil puissant pour corriger les défauts passés, alors n'ayez pas peur de faire des erreurs.
Michael Klement

1
Ahh. Analyse Paralysie . Mon plus grand ennemi! Je devrais construire un jeu où Analysis Paralysis est servi comme End-Boss. Je commence par concevoir l'architecture du jeu en premier ... Noooo! Blague à part: Excellente réponse et bon commentaire!
bummzack

12

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.


8

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

Pouvez-vous élaborer sur le développement piloté par les tests dans un cadre de jeu? Mis à part une logique de base, je n'ai jamais trouvé de programmes hautement interactifs très bien adaptés à ce genre de chose. En outre, vous
créez un

2
@Ranieri Si vous tracez une ligne entre les pièces qui s'interfacent avec le matériel graphique et les entrées utilisateur, le test est simple.
Jonathan Fischoff

@Ranier Merci, corrigé le lien. Je suis d'accord que proposer des tests d'abord pour des simulations interactives ou des jeux client-serveur peut être délicat. En plus de vos tests unitaires, vous voudrez probablement avoir des tests de fonctionnalité de niveau supérieur et éventuellement des sessions de lecture qui s'exécutent à certains intervalles. Dans tous les cas, penser aux tests en premier est susceptible de porter ses fruits dans de nombreux scénarios. Trouvez des vues intéressantes sur gamedev.stackexchange.com/questions/1905/…
jmp97

5

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.


1
C'est un très bon conseil, bien que je recommanderais un temps ou un autre type de ressource lié à la boucle, après quoi vous quittez simplement (0) et essayez un autre prototype.

@Joe Wreschnig - Les plans de temps peuvent être inclus dans AnalysingResults (), mais je pense que vous pouvez utiliser RapidPrototype pendant un certain temps et le terminer plus tard ou le mettre dans les plans. Mieux vaut donc rester coincé pour toujours :). Dans RapidPrototype, vous pouvez également simuler des fonctionnalités. C'est prety utile à bien des égards.
samboush

1

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).


2
Je ne pense pas qu'il existe une méthodologie de développement qui ne prétend pas "faire avancer les choses et avoir un concepteur de logiciels solide".

@Joe Je pense que de nombreuses méthodologies "lourdes" ont tendance à préférer CYA à un logiciel solide. En effet, une grande partie de mon expérience non agile a tendance à être "il n'est pas nécessaire d'avoir raison, elle doit être en ce moment", alors que "agile" vise à dire "elle doit être en ce moment, mais faites tout ce que vous peut faire les choses au fur et à mesure. "
dash-tom-bang

Je dirais que le développement agile a très peu d'influence sur la solidité ou non du code. L'essence de l'agilité est de consacrer tout votre temps de développement à des choses importantes. Le code peut toujours être un gâchis à la livraison, car la qualité du code (ou le manque de dette technique) est rarement une mesure du succès d'une livraison.
Magnus Wolffelt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.