J'ai commencé la programmation C #, afin de développer plus tard des jeux avec XNA. J'ai lu un bon livre de développement de jeux pour C #. Comme je connaissais déjà d'autres langages, j'ai pu rapidement apprendre les fonctionnalités C # et le code de syntaxe. Je suis ensuite entré dans XNA. Comme le livre que je lisais était un peu vieux, je l'ai mis de côté et j'ai commencé à regarder des tutoriels de développement de jeux sur XNA sur Internet. Je pourrais accomplir et comprendre la plupart d'entre eux, en utilisant des graphiques 2D. J'ai créé des sprites animés, fait bouger mes personnages dans toutes les directions, fait défiler mon arrière-plan avec le mouvement de mes personnages, etc. Tout a été fait avec du XNA "brut".
J'ai trouvé certaines de ces choses difficiles à comprendre, et j'ai trouvé que certaines choses devaient déjà être intégrées dans le cadre. J'ai trouvé d'autres moteurs de jeu, que je pouvais clairement comprendre au moins les codes de ligne simples, tels que " FlatRedBall " , " Axiom " et " Quick Start Engine " . Je connaissais déjà les célèbres, comme "OGRE" , "Unreal" et "Unity" . En même temps, j'ai été tenté de tout jeter et de commencer à apprendre une programmation de moteur de jeu célèbre. Je voulais rester avec XNA, car il m'a fallu du temps pour apprendre; fois je ne voudrais pas le perdre.
Cette fois, je laisse le soin aux expérimentés. Puis-je passer par un moteur de jeu et utiliser ce qu'il a à offrir, même si je commence par développer un jeu? Certaines personnes pourraient penser qu'il est bon de s'habituer aux routines ennuyeuses d'un cadre nu. Dans l'affirmative, quelle serait la recommandation pour commencer? J'ai entendu dire que cela varie d'un marché à l'autre. Nous pourrions peut-être considérer que je veux un RPG spécifique.
Réponses:
Cela dépend de ce que vous voulez apprendre. Si vous voulez "simplement créer un jeu", vous pouvez être bon avec un moteur. Personnellement, je ne le recommande pas.
Si vous voulez vraiment comprendre comment fonctionne l'infographie, vous devez aller plus loin et apprendre toutes les choses. De l'actualisation de votre algèbre linéaire (au moins matrices, vecteurs et espaces linéaires) à la compréhension du fonctionnement des pipelines graphiques. XNA est le meilleur framework pour commencer. Mon premier jeu était dedans (je veux dire du vrai jeu, la première application 3D était des chars de combat en openGL). Si vous voulez commencer la programmation 3D, n'avez pas de plans aussi ambitieux, vous ne pouvez pas faire de RPG maintenant. Vous devriez essayer de faire un jeu où vous volez dans un espace plein de cubes et essayer de tirer sur les rouges, pour apprendre les bases. Cela vous prendra probablement plus de temps que vous ne le pensez :). Mais cela vous apprendra beaucoup.
Et foncez! La programmation graphique 3D est la meilleure chose que vous puissiez faire pour vivre. C'est dur, amusant et créatif dans un seul paquet.
la source
Il n'y a rien de mal à utiliser un moteur existant, tout se résume à vos objectifs.
Si vous êtes le plus intéressé par la création de jeux ou la conception de jeux, plus vous obtenez rapidement le code de gameplay, mieux c'est. Quelque chose comme Unity est génial ici, car vous pouvez utiliser vos connaissances C # et commencer à attacher des scripts aux objets et exécuter immédiatement quelque chose.
Si vous voulez devenir programmeur de jeux, vous devez comprendre les choses à un niveau inférieur. Un framework comme XNA est un bon point de départ. Vous pouvez compter sur le framework pour mettre les choses en place et commencer à remplacer des parties du framework par votre propre code à mesure que vous apprenez à construire chaque composant de votre jeu.
la source
CONSEILS D'UN AMATEUR
// De zéro à amateur au fil des années d'apprentissage
Je resterais certainement à l'écart des moteurs de haut niveau comme Unity ou Torque2D MIT. Ils sont parfaits pour les petits prototypes, mais je ne les prendrais jamais au sérieux pour développer mon propre jeu vidéo. Pourquoi aurais-je? Quel est l'intérêt à moins qu'il ne s'agisse que d'un simple remake SideScroller ou Arcade?
La plupart des moteurs de jeu, des bibliothèques ou des frameworks ne font rien de plus que les tâches les plus simples avec beaucoup de code gonflé avec des fonctions et des fonctionnalités que vous n'utiliserez jamais.
Quand j'étais nouveau dans le développement de jeux il y a des années, j'ai commencé au sommet. Moteurs de très haut niveau. Pas quelque chose de trop élevé comme RPG MAKER, mais définitivement là-haut comme Unity et Torque. Ensuite, je suis allé plus bas, vers XNA et C #, car il y avait tellement de ressources et de tutoriels. Mon projet principal avait besoin de la performance, ou peut-être suis-je simplement obsédé par le fait de vouloir des performances incroyables dans mon logiciel, même si ce n'est pas un grand projet. XNA ne l'a tout simplement pas coupé, et j'ai eu beaucoup de problèmes avec le moteur que j'ai lu nécessitant un mal de tête pour le réparer. Quel est l'intérêt d'utiliser quelque chose de "niveau supérieur" comme XNA / C # lorsque vous faites le même travail (correction de bugs et problèmes XNA) que si vous rouliez votre propre moteur en C ++?
Après un certain temps d'apprentissage, j'ai finalement appris comment les moteurs de jeu sont conçus et j'ai commencé à examiner le code des moteurs eux-mêmes. En lisant ce que la plupart des professionnels ont à dire et les plaintes des critiques des moteurs de jeu, je me suis rendu compte: «Pourquoi même utiliser un moteur?
Se familiariser avec mon C ++ et vraiment entrer dans certaines philosophies utilisées dans ce langage m'a beaucoup aidé. Cependant, j'avais passé tellement de temps à apprendre tellement de choses que je voulais juste commencer à créer un jeu.
Je me suis donc retrouvé avec quelque chose avec beaucoup d'éloges, était C ++, et très bas niveau: SDL. Malheureusement, c'était un mal de tête. Il est si bas niveau, je ne vois presque aucune raison d'utiliser même cette bibliothèque. Je préfère simplement apprendre OpenGL et le faire moi-même à partir de zéro. Honnêtement, c'est surtout le fait que j'avais besoin d'implémenter mon propre code pour faire quelque chose d'aussi basique que de retourner une image (et l'implémentation des autres ne fonctionnait pas à cause de la façon dont je traitais les sprites) qui m'a conduit à supprimer définitivement SDL. C'est génial si vous voulez un logiciel de rendu, mais IMO je préfère le jeter pour aller plus bas avec le matériel (OpenGL) ou plus haut (SFML).
Ne voulant pas acheter un autre livre sur Amazon et apprendre encore une autre API, je suis allé plus haut. SFML est tout simplement merveilleux, sans parler des éloges sur Internet. J'ai lu presque un nombre infini de critiques positives, avec presque aucun négatif. Je ne peux pas en dire autant de SDL. Il gère toutes les bases extrêmes, mais laisse le reste à moi et aux autres bibliothèques de mon choix. Je suis resté avec ça depuis.
IMO, un moteur de jeu est tout simplement stupide. Les bibliothèques de bas niveau sont de bien meilleurs choix pour les programmeurs experts et débutants.
À noter également, j'ai appris plus sur les concepts de programmation et j'ai affiné mes compétences en développement logiciel lorsque je suis forcé de gérer des choses à un niveau inférieur à ce que j'ai jamais appris avec des moteurs de jeu WYSIWYG de haut niveau.
Que vous apporte quelque chose comme Unity sur XNA? Montage visuel et une béquille. Les débutants finiront par apprendre que vous devrez toujours coder à peu près tout le jeu comme vous le feriez si vous aviez du C ++ nu, et les éditeurs visuels sont inefficaces pour quelque chose que vous pourriez créer vous-même.
Que vous apporte quelque chose comme XNA sur SFML ou votre propre implémentation d'OpenGL et d'autres bibliothèques utiles? OMI, absolument rien de bon. Pire performance, C # au lieu de C ++, une pléthore de tutoriels pour débutants mais beaucoup moins de professionnalisme, et certains épargnants de maux de tête que IMO ne sont à nouveau qu'une béquille pour ce que vous devriez simplement apprendre avec C ++. J'ai d'abord été intimidé par le C ++ et j'ai adoré le C #, principalement à cause des rumeurs et des opinions des imbéciles qui avaient les mêmes problèmes qu'au départ avec le C ++: je voulais juste un programmeur assez bon. J'ai réalisé que je devais apprendre plus de fondamentaux et aiguiser mes faiblesses afin de surmonter les problèmes que j'avais avec C ++, que C # "rendait facile". Dois-je jamais manquer la simplicité de certaines choses en C #? Pas même! Je sais comment le faire en C ++ sans tracas.
Si les bibliothèques de bas niveau ou l'apprentissage de DirectX / OpenGL vous intimident, alors attendez jusqu'à ce que vous commenciez à entrer dans la complexité de la création d'un jeu vidéo complet.
Ma philosophie sur les moteurs de jeu peut se résumer en deux exemples expliquant la redondance et l'inutilité des moteurs, sauf dans des circonstances isolées.
Les débutants qui sont intimidés par les bibliothèques de bas niveau auront une crise lorsqu'ils découvriront que même avec un moteur de haut niveau comme Unity, (en plus du rendu graphique, de la lecture audio, du chargement de contenu; de vrais trucs de base), il sera presque identique à la création d'un jeu de zéro. La complexité réside dans l'ingénierie d'un jeu, la compréhension de l'API ou le développement des classes à rendre à l'affichage.
Les experts qui ne sont pas intimidés par la complexité de la création d'un jeu complet dans quelque chose comme Unity, n'ont aucune utilité pour Unity, car le temps nécessaire pour apprendre en toute confiance l'API et les exigences d'un moteur spécifique est probablement plus un casse-tête et plus de temps qu'il n'en faudrait pour coder les quelques classes nécessaires pour faire les bases.
Les moteurs sont donc inutiles pour les débutants, car les débutants ne peuvent rien faire avec eux parce qu'ils n'ont pas les compétences en ingénierie. De même, les moteurs sont inutiles pour les vétérans, car ils ont déjà les compétences en ingénierie pour le faire sans moteur, et pourraient tout aussi bien lancer leur propre `` moteur '' plus efficace et spécifique que de passer par le mal de tête d'apprendre à la fois l'API du moteur de jeu, fonctions et bizarreries de performance. Sans parler du cauchemar massif de travailler avec des moteurs que vous ne pouvez parfois pas toucher parce qu'ils ne sont pas open source (ou même s'ils le sont, lire le code des autres peut parfois être un cauchemar).
Heck, même certains "cadres de jeu" de "bas niveau" ne sont rien de plus que quelques classes pour créer une fenêtre, effectuer un rendu à l'écran et lire de l'audio. C'est quelque chose qu'un professionnel pourrait faire lui-même à partir de zéro en utilisant d'autres bibliothèques comme SDL / SFML ou leur propre implémentation d'OpenGL / DirectX / OpenAL, en une fraction du temps qu'il faut pour terminer un jeu vidéo complet.
TLDR;
Si vous voulez programmer, apprenez à être programmeur .
Évitez d'utiliser des moteurs , mais ne soyez pas dupe et ignorez les bibliothèques incroyablement utiles.
Si vous voulez être un Game Designer , essayez un moteur WYSIWYG et pompez ces jeux!
Si vous voulez être un programmeur de jeu , évitez les moteurs comme la béquille qu'ils sont.
Pour MOI , l'utilisation de moteurs de jeu de niveau supérieur a paralysé ma capacité à devenir programmeur. Au moment où j'ai commencé à utiliser des bibliothèques de niveau inférieur à la place ou à ne pas utiliser de bibliothèque du tout, j'ai commencé à apprendre tellement que je suis rapidement passé d'un débutant total à quelqu'un qui peut maintenant créer des jeux vidéo sans aucune référence, tutoriels ou réserver à mes côtés. Juste mon compilateur et beaucoup d'ingénierie et de pratique.
La quantité d'apprentissage que j'ai acquise à partir de bibliothèques de bas niveau en peu de temps était beaucoup plus grande que la quantité que j'ai acquise en très peu de temps avec des MOTEURS de niveau supérieur. **
la source