En quoi le développement de jeux est-il différent des autres développements de logiciels? [fermé]

Pour un développeur de logiciels polyvalent solide, qu'est-ce qui est spécifiquement différent dans le développement de jeux, fondamentalement ou simplement des différences de degré?

J'ai fait des jeux jouets comme Tic-tac-toe, Tetris et un solveur de sudoku à force brute (avec interface utilisateur) et je me lance maintenant dans un projet de taille moyenne (de taille moyenne pour être un développeur unique et ne pas avoir fait beaucoup de jeux) et une chose que j'ai trouvée avec ce projet particulier est que la séparation des préoccupations est beaucoup plus difficile car tout affecte l'état, et chaque objet peut interagir avec tous les autres objets d'une multitude de façons.

Jusqu'à présent, j'ai réussi à garder le code raisonnablement propre pour ma satisfaction, mais je trouve que garder le code propre dans les jeux non triviaux est beaucoup plus difficile que pour mon travail de jour.

Le jeu sur lequel je travaille est au tour par tour et les graphismes vont être assez simples (basés sur le Web, principalement par manipulation DOM), donc le travail en temps réel et en 3D ne me sont pas vraiment applicables, mais je le serais quand même intéressé par les réponses concernant celles-ci si elles sont intéressantes. Mais surtout intéressé par la logique générale du jeu.

PS N'hésitez pas à redéfinir cela, je ne sais pas vraiment quelles balises sont applicables.

Il y a une différence majeure. À mon avis, c'est la seule différence qui compte vraiment.

Nous pouvons passer en revue les détails techniques de la raison pour laquelle c'est différent, bien sûr. Les moteurs 3D, la physique des particules, beaucoup de choses différentes entrent en jeu.

Mais de nombreuses formes de logiciels différentes ont des chaînes attachées. Le logiciel de modélisation doit faire la même chose. Chaque logiciel important possède une bibliothèque spécialisée qu'il doit utiliser.

Alors qu'est-ce qui rend les JEUX différents?

La voici: le logiciel est conçu pour répondre à un besoin professionnel. Vous souhaitez un système d'inventaire? Vous pouvez définir les types d'éléments que vous devez gérer. Vous pouvez définir ce que vous voulez pour votre planification de production. Vous pouvez faire tout ça. Ou si vous voulez un logiciel bancaire, vous pouvez définir ce que vous voulez en faire.

Avec les jeux, votre besoin professionnel est "amusant". Essayez d'écrire une spécification technique pour "fun".

C'est, à mon humble avis en tant que développeur, ce qui rend les jeux différents des logiciels classiques. Vous ne pouvez tout simplement pas dire "Génial! Ce logiciel est désormais complet selon les demandes du client!" parce que tout ce qu'ils veulent, c'est s'amuser.

Cela étant dit, vous n'avez pas besoin de graphismes 3D et de physique extravagante pour que quelque chose soit amusant. Pourquoi les gens jouent-ils toujours à Tetris? Sa physique consiste à "déplacer le bloc vers le bas" "à ne pas laisser le bloc sortir des limites" et à "arrêter le bloc quand il frappe quelque chose", et bien qu'au fil des ans il y ait eu de nombreuses versions, certaines avec des graphismes plus sophistiqués que d'autres, mais le le résultat est - c'est amusant !!

Donc, si vous voulez être un excellent développeur de jeux, ne jetez pas ce que vous avez appris en tant que développeur de logiciels ordinaire. C'est toujours des trucs très utiles. Et @Sion a raison de séparer vos composants, comme vous le feriez dans un logiciel classique. Mais la fonctionnalité la plus importante que vous pouvez ajouter à votre jeu est amusante. Fun fun fun fun fun. C'est pourquoi le développement de jeux existe, c'est ce dont vous avez besoin pour réussir votre jeu. Et croyez-moi, même si c'est amusant de jouer, c'est au moins 10 fois plus amusant à faire !!

Bonne chance avec votre jeu! :RÉ

Je suis principalement un développeur de jeux et non un développeur de logiciels traditionnel, mais je pense qu'il existe plusieurs différences clés.

Ce sont évidemment plusieurs généralisations et non exhaustives: des
équipes plus grandes. Milieux plus variés (artistes, programmeurs, producteurs, avec chacun il y a encore plus de variation). Cycles de développement plus longs. Des normes de performance plus élevées. Échelle de projets plus grande. Risque de défaillance plus grand et plus coûteux. Environnement plus stressant.

En ce qui concerne les interactions d'objets et la présentation de votre architecture, vous pouvez toujours découpler correctement les systèmes. Vos objets de jeu et votre comportement auront clairement des dépendances les uns des autres et de ces systèmes. C'est la nature du jeu (jeu de mots), il combine tous ces systèmes en une seule unité cohérente, et il n'y a rien de mal à cela. Cela peut sembler ainsi parce que l'échelle de tout cela est plus grande que ce à quoi vous êtes habitué.

Certains systèmes facilement identifiés et séparés?

• Détection de collision
• Réponse à une collision
• La physique
• Animation
• Graphiques (2D et 3D)
• Intelligence artificielle
• Entrée utilisateur
• Entrée / sortie de fichier
• La mise en réseau

Je ne pense pas que la programmation de jeux soit différente des autres domaines d'application du point de vue qu'il est plus difficile de choisir la bonne séparation des préoccupations. Chaque fois que vous apportez vos compétences à un type de domaine d'application différent, vous constaterez que la transition n'est pas aussi fluide que vous l'auriez espéré car il y a toujours des différences. Ce qui a fonctionné dans votre application de base de données a de nombreux modèles / idiomes qui ne fonctionnent pas si bien dans votre application intégrée, qui a de nombreux modèles / idiomes qui ne fonctionnent pas si bien dans ce système en temps réel qui a également de nombreux modèles / idiomes qui ne fonctionne pas dans la programmation de jeux. Cependant, les programmeurs de jeux ont les mêmes problèmes lorsqu'ils quittent leur domaine de programmation de jeux. C'est juste une question de ce à quoi vous êtes habitué.

Cela dit, je pense que la programmation de jeux semble plus difficile pour beaucoup de gens car elle vous oblige à travailler avec des parties de l'ordinateur que la plupart des programmeurs n'ont jamais à gérer dans leur travail réel (graphiques et sons de bas niveau) et plus de mathématiques appliquées que beaucoup les gens sont à l'aise et non à cause de la séparation des préoccupations. Bien qu'il y ait toujours des difficultés à déterminer le bon choix pour la séparation des préoccupations, je pense que la difficulté avec la séparation des préoccupations que vous rencontrez se déplace simplement vers un nouveau domaine problématique. Une fois que vous aurez créé quelques applications, ce sera comme n'importe quoi d'autre, vous apprendrez ce que vous aimez et n'utiliserez pas ce que vous n'aimez pas.

et une chose que j'ai trouvée avec ce projet particulier, c'est que la séparation des préoccupations est beaucoup plus difficile car tout affecte l'état, et chaque objet peut interagir avec tous les autres objets d'une myriade de façons.

Je pense que vous avez une réponse là-bas, il y a beaucoup d'interactions. J'ai fait quelques jeux avec XNA (C #), maintenant je fais un jeu de taille moyenne comme vous le dites, un jeu de simulation de stratégie, je travaille dessus depuis presque 2 mois maintenant, et je le fais seul sans aide, donc je doit garder mon code simple. Une énorme différence, je pense, est de comprendre et de concevoir certaines classes pour la fonctionnalité, et d'autres pour le dessin, cela aide et rend votre programme plus propre. Bien sûr, si vous faites un jeu, vous devez avoir plus de ressources, comme des images (2d ou 3d) et de la musique (ou des sons). Il y a donc des différences, je pense que c'est plus difficile, mais c'est très drôle.

Je pense que la programmation de jeux est plus amusante. Vous pouvez constamment tester votre jeu, vous implémentez une physique différente, ce qui entraîne un comportement différent.

D'après mon expérience, la programmation de jeux est en fait beaucoup plus amusante que le développement de logiciels. Dans le développement de logiciels, vous devez respecter certaines règles métier, cela devient peu ennuyeux. Vous créez un logiciel, ce n'est pas amusant. Utiliser un logiciel est génial, utile, utile, mais pas amusant.

Les jeux sont amusants. C'est peut-être juste moi, mais je trouve le développement de jeux beaucoup plus intrigant et passionnant que le développement de logiciels traditionnels, quels que soient les outils utilisés.

PS: J'utilise les derniers outils de développement logiciel, HTML5, Asp.Net, C #, etc. Je trouve toujours plus amusant de coder DirectX, UDK, XNA, Unity.