Ok, j'ai fini par écrire mon propre moteur de jeu basé sur XNA, et je me demande ce dont j'ai besoin d'autre pour faire un moteur complet.
C'est ce qu'il y a dans le moteur :
Est-ce que je rate quelque chose qui pourrait être crucial pour un moteur de jeu ?
Vous l'abordez de manière inversée.
Ce qui devrait se trouver dans votre moteur est le suivant :
Tout le code qui s'est avéré être commun entre votre premier et votre second jeu.
D'abord, écrivez un jeu. N'écrivez pas un moteur, car, comme vous l'avez constaté, vous ne savez pas ce qu'il doit contenir, ni comment il doit être conçu. Écrivez plutôt un jeu.
Une fois que vous avez ce jeu, écrivez un autre jeu. Ensuite, lorsque vous avez fait cela, examinez le code du deuxième jeu. Dans quelle mesure a-t-il été réutilisé à partir du premier jeu ?
Tout ce qui a été réutilisé doit ensuite être refactorisé dans un projet distinct. Ce projet est maintenant votre moteur de jeu.
Cela ne signifie pas qu'il ne faut pas planifier, ni essayer d'écrire du bon code. Mais assurez-vous de travailler sur quelque chose de concret, quelque chose qui vous permettra de distinguer une bonne implémentation d'une mauvaise. Une bonne implémentation d'un jeu est une implémentation qui fonctionne, qui est amusante et qui ne plante pas. Écrivez votre code pour réaliser ces choses en premier.
Une bonne implémentation d'un moteur ? C'est plus délicat. Quelle est la bonne implémentation d'un moteur de rendu ? D'un cadre d'IA ? D'un système de particules ? En fin de compte, le seul moyen de déterminer si vous avez un bon moteur est de voir comment il fonctionne dans un jeu réel . Donc, si vous n'avez pas de jeu, vous n'avez aucun moyen d'évaluer votre moteur. Et si vous n'avez aucun moyen d'évaluer votre moteur, vous n'avez aucun moyen de juger si le code que vous écrivez est réellement utile.
Quelle belle et simple façon de voir les choses, jalf (+1) ! Cela dit, je suis sûr que vous voudriez une liste de "caractéristiques fondamentales" (selon le type de jeu que vous faites) pour commencer, lorsque vous commencez à créer le premier des deux jeux.
@Leif : pourquoi ? Si ces fonctionnalités sont fondamentales, alors vous allez devoir les ajouter à un moment donné de toute façon, donc il n'y a aucun mal à attendre jusqu'à ce que vous en ayez besoin. Et qui sait, peut-être qu'elles ne sont pas si fondamentales après tout. Peut-être que vous vous retrouverez avec un jeu complet sans ces fonctionnalités.
Je vois comment cela peut avoir du sens dans certaines situations, mais il pourrait être difficile d'avoir une idée assez fiable de "l'exhaustivité globale", du travail à accomplir et de vos progrès, sans définir d'une manière ou d'une autre le travail nécessaire pour atteindre votre/vos objectif(s). Je pense qu'essayer de faire un plan est toujours une bonne chose, ensuite, on peut établir des priorités et diviser le travail en portions délimitées. S'il est fait correctement, je pense que "le plan" peut servir de point de référence important et de facteur de motivation, même si vous apportez des modifications au fur et à mesure que les exigences du produit changent. La "planification implicite", selon mon expérience, s'est avérée très contre-productive.
Un thème ou un marché pour votre moteur. Si vous faites autre chose que votre moteur graphique de base, vous voudrez vous concentrer sur un marché pour votre moteur, comme RPG, stratégie, puzzle, plateforme, action ou FPS (ok, pas FPS).
Cela vous aidera à vous orienter dans la direction où vous devez aller pour apporter d'autres améliorations au moteur sans nous demander notre avis. Un moteur comme l'Unreal Engine, par exemple, peut faire plusieurs choses, mais ce qu'il fait le mieux, c'est ce pour quoi il a été conçu, à savoir les jeux FPS. De même, vous devriez adapter votre moteur de manière à ce qu'il convienne à un domaine d'intérêt particulier et qu'il soit donc choisi pour ce type de jeu.
Vous pouvez le rendre général jusqu'à un certain point, mais sachez que plus votre moteur est généralisé, plus il est difficile à programmer, tant en termes de temps que de compétences. Les autres programmeurs sont également moins susceptibles de choisir un moteur général (à moins que ce soit tout ce qu'il y a) si une plateforme plus spécifique est disponible. Ou d'écrire leur propre moteur puisque modifier un moteur généralisé est aussi difficile que de créer le sien.
+1 Cas concret avec l'Unreal Engine : The Last Remnant. Un excellent jeu (RPG), mais les graphismes étaient si pauvres à certains moments que vous ne pourriez pas le croire. Tout cela vient du fait que les RPG ont tendance à avoir beaucoup plus d'effets jolis à la fois par rapport à un FPS, et donc besoin d'avoir une meilleure dégradation dans le moteur de particules quand il y a de multiples effets en même temps !
Connaissez-vous de bonnes bibliothèques XNA/C# pour la recherche de chemins ? Ou recommandez-vous simplement de lire les algorithmes impliqués et de créer une solution qui fonctionne pour le jeu en question ?
Je n'ai jamais utilisé XNA, donc je ne connais pas vraiment de bonnes bibliothèques. Je suis sûr qu'il en existe déjà beaucoup d'excellentes, mais parfois, il est bon de lire sur les algorithmes et de les mettre en œuvre soi-même.
@Venesectrix : Le pathfinding (A* est l'algorithme le plus populaire) est très simple à mettre en œuvre et il y a beaucoup de ressources pour cela. Voir ziggyware.com/readarticle.php?article_id=162 pour un autre lié à XNA.
Quelques idées :
L'IA pour un moteur de jeu générique est un peu difficile. L'IA est trop spécifique au jeu lui-même, donc je ne suis pas sûr qu'il soit utile d'essayer d'en créer une générique qui fasse partie du moteur lui-même.
Je pensais plutôt à des algorithmes d'IA simples (comme un ennemi qui se dirige toujours vers vous) ainsi qu'à des utilitaires (par exemple, des algorithmes de recherche de chemin).
Je pense que vous avez couvert les exigences générales d'un moteur 2D. La seule chose qui me manquerait dans cette liste serait :
Également pour faciliter les processus de développement :
Vous pourriez également ajouter une autre couche par-dessus les éléments existants de XNA :
Enfin, vous pouvez ajouter quelques shaders "prêts à l'emploi". Peut-être s'inspirer de la version discontinue FaceWound (du développeur de "Garry's Mod").
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Je n'ai rien contre SO, mais vous feriez probablement mieux de poster ceci sur les forums de gamedev.net.
0 votes
Bonne (et flexible) détection des collisions.
1 votes
La détection des collisions est située dans le moteur Farseer Phsyics
5 votes
Voulez-vous écrire un jeu ou un moteur ? (voir : scientificninja.com/advice/écrire-des-jeux-pas-de-moteur )
3 votes
@clintp - et les commentaires ne sont pas l'endroit pour poster une réponse à la question.