Mon problème est, chaque fois que je commence à programmer un clone d'un jeu (pour la pratique) ou mon propre jeu ou un autre problème, je m'arrête quelque part au milieu du développement, parce que je m'y suis désintéressé.
Comment gardez-vous l'intérêt de développer un jeu, ou de développer en général?
Réponses:
En tant que designer, j'ai tendance à considérer les gens comme des collections de statistiques et de variables. Lorsque vous posez votre question, je peux facilement imaginer que [Pong_Dev_Interest] diminue et que [Spa_Inv_Dev_Interest] augmente. Lorsque la différence entre les deux est supérieure à [Dev_Project_Inertia] (quelque peu liée à [Dev_Completion_Desire]), l'activité sur [Pong_Dev] s'arrête et [Spa_Inv_Dev] démarre.
En anglais: vous ne parvenez pas à terminer le projet car votre désir brut de voir un produit fini est supplanté par votre manque d'intérêt pour le projet en cours. Si vous voulez vraiment en finir un, la seule solution est d'en choisir un (j'irais avec votre clone de pong) et de le terminer . Dites-vous "Moi-même, je sais que j'aurais peut-être pu affiner ce clone un peu plus mais bon sang, ça fait du bien de lancer un projet à la porte". Continuez ensuite à travailler.
Lorsque vous vous ennuyez, continuez à travailler. Quand ça va bien, continuez à travailler. Quand ça tombe en merde, continuez à travailler! Persévérer! Soyez le petit développeur qui pourrait! Je crois en vous!
Ahem. Vous avez un peu surexcité là-bas. Mais vous obtenez la dérive.
Je suis quotidiennement mes propres conseils. J'ai fait travailler mon environnement et mes acteurs, intégré mes conditions de victoire et de perte et créé les objets que le joueur utilisera. Je suis fondamentalement prêt à commencer à faire du level design et mon intérêt s'est envolé. Mais j'en fais tous les jours. Tous les jours. Un jour, j'aurai fini.
Et ce sera tellement bon.
la source
Je me pose toujours la même question et il y a quelques choses que vous pouvez faire pour vous motiver (beaucoup d'entre elles ont déjà été publiées ici). Ce qui fonctionne bien pour moi, c'est quelque chose que j'ai entendu lors d'un des Indie Talks au GDC de cette année, je pense que c'est le gars qui a fait le jeu de Monaco :-)
Tout d'abord, trouvez un projet qui correspond bien à votre expérience. C'est à dire ne commencez pas à faire un FPS si vous ne connaissez même pas les bases d'OpenGL / DirectX. (sauf si vous utilisez un moteur de jeu mais ce n'est pas le sujet ici ;-))
Ensuite, faites-vous une liste des choses à faire et des étapes que vous aimez atteindre, afin que vous sachiez toujours où aller. Les TODO est la partie importante. Définissez vos tâches de manière à ce que chaque tâche puisse être effectuée facilement en une journée ou en quelques heures . Ainsi, lorsque vous commencez à coder, concevoir, modéliser, etc., vous voyez déjà la lumière au bout du tunnel. Rien n'est plus déprimant que de concevoir et de coder votre gros moteur de jeu pendant un mois sans vous rapprocher de la ligne d'arrivée. Décomposez les grandes tâches en plus petites. Terminer une tâche rapidement est vraiment gratifiant et vous permet de continuer. Par exemple, c'était ma liste de tâches pour un petit jeu de tir spatial à un moment donné:
Toutes ces tâches étaient faciles à faire et une fois qu'elles fonctionnent dans le jeu, vous pouvez parcourir ces zones et les peaufiner.
Et bon, j'ai terminé un petit match. Ce n'est pas joli mais c'est fini, ce qui était vraiment gratifiant au final :-)
la source
Vous devez identifier le problème avant de pouvoir le résoudre. Pourquoi perdez-vous votre intérêt?
Pour moi, cela se produit généralement parce que je passe tellement de temps sur le framework, et après des semaines, je n'ai même pas pu obtenir un seul élément de gameplay.
Une façon que je trouve pour améliorer ma motivation est de faire du prototypage itératif ou une forme de développement piloté par les tests. Habituellement, cela implique d'automatiser les cas de test, mais comme les jeux sont gourmands en graphiques, vous ne pouvez pas automatiser les écrans et les animations en tant que tests, mais votre logique de jeu pourrait être automatisée.
Pour les parties qui ne peuvent pas être automatisées, je vais essentiellement planifier quelques jalons pour le jeu. Le jalon 1 serait probablement de rendre un sprite à l'écran et de faire fonctionner WASD, par exemple. Petit à petit, j'ajouterai plus de fonctionnalités, et refactoriser.
C'est une forme de division et de conquête. Divisez-vous en petits morceaux, travaillez celui avec lequel vous êtes à l'aise, puis intégrez-le. Rincez et répétez. Finalement, vous pouvez voir une meilleure façon de réorganiser les choses et vous pouvez refactoriser votre code. C'est désordonné de ne pas avoir une architecture à l'avant, mais généralement lors du démarrage de la programmation, il est difficile de visualiser l'architecture avant d'avoir quelques années d'expérience.
la source
J'essaie de trouver une partie plus facile à faire. Comme si je n'arrive pas à comprendre comment faire quelque chose ou pas, je change de vitesse et modélise ou j'écris un shader, etc.
Voir ceci et cet autre post.
la source
Si vous ne savez pas comment structurer correctement un jeu, vous devriez commencer à apprendre à résumer leurs éléments en blocs indépendants du jeu. Cela peut vous aider à bien des égards (en plus d'être intéressant), comme: l'expérience de la séparation des abstractions des implémentations, une meilleure exploitation de l'héritage et de la conception de l'interface, ou simplement comment mettre le jeu en plusieurs fichiers pour qu'il ait l'air pro (ou pour fournir une fexibilité des implémentations par l'utilisation de bibliothèques de liens dynamiques ou d'autres utilisations d'interface). Tôt ou tard, vous vous rendrez compte que tout peut être fait, puis vous vous retrouverez sans ce problème de motivation (vous le faites simplement).
J'ai eu le même problème quand je suis resté coincé au début, mais la meilleure solution est de continuer à bouger, ou vous pouvez caler pour toujours jusqu'à ce que quelque chose vous réinitialise d'une manière ou d'une autre (et cela peut prendre trop de temps). Peu importe si vous codez simplement 2 lignes certains jours, mais chaque jour, vous devez au moins ouvrir le projet et essayer d'améliorer quelque chose (c'est une tâche sans fin mais ce n'est pas le problème).
Si à un moment donné, le programme ne fonctionne pas, vous devez annuler ce que vous avez fait en dernier (conserver une sauvegarde en utilisant un svn ou au moins un .rar avec le nom de la date) jusqu'à un point où il a fonctionné et essayer de le faire à nouveau, ou travaillez sur d'autres modifications que vous devez effectuer jusqu'à ce que vous souhaitiez réessayer.
Au début, vous devriez essayer de corriger l'erreur à l'aide du débogueur, mais je ne sais pas si votre langue prend même en charge un débogueur ... mais si vous utilisez par hasard C ++ ou quelque chose comme ça (que je recommanderais si vous vous voulez faire des jeux), vous devriez mieux utiliser votre débogueur car il vous aidera beaucoup à trouver l'erreur rapidement en une seule fois.
Lire sur la programmation de jeux est également une bonne chose pour rester sur le sujet si vous ne voulez pas travailler sur quelque chose en particulier. Il existe de bons livres et articles sur les moteurs de jeu et la conception que vous pouvez trouver en ligne.
Vous ne pourrez rien faire si vous ne vous entraînez pas. Essayer de trouver un bogue peut être très frustrant au début, mais vous apprenez ensuite que c'est en fait facile si vous savez comment le faire. C'est quelque chose que vous apprenez à éviter avec le temps, en codant de manière à ce que vos modifications n'aient pas d'impact sur l'ensemble du programme, ce qui diminue le nombre de lieux où chercher l'erreur. Si chaque fois que cela devient difficile, vous abandonnez, alors chaque fois que vous pensez à créer un jeu, vous abandonnerez avant de commencer. Apprenez simplement à surmonter le mauvais moment en le surmontant: P Si vous ne passez pas par ce moment où vous perdez votre motivation, votre paresse gagnera, et vous perdrez, c'est comme ça que ça marche, jusqu'à ce que vous appreniez à retrouver votre motivation sans trop d'effort.
PS Je me demandais ... qu'est-ce que tu utilises pour faire le jeu?
la source
[Je voulais laisser un commentaire à la réponse d'Anon, qui a été supprimée lorsque je l'ai publiée. Il a mentionné qu'il avait toutes ces fonctionnalités fonctionnelles, puis a divisé le code de fichier unique en plusieurs fichiers, seulement pour que tout se désagrège]
Re: refactoring, des choses peuvent arriver, même pour les pros. Parfois, même avec de bons outils comme Git, une fusion peut échouer, alors au lieu que les fonctionnalités A et B fonctionnent, aucune ne fonctionne! Le seul choix est de revenir à A et de réessayer. Heureusement, le contrôle de version enregistrera ce code pour vous; si vous n'utilisez pas le véritable contrôle de version, faites-le au moins manuellement en zippant régulièrement votre dossier de développement - l'espace HD est bon marché! En conclusion, revenez à ce qui fonctionne et refactorisez-le en étapes plus petites, en vous assurant que le jeu fonctionne toujours à chaque étape. Il est vraiment déprimant de nettoyer le code uniquement pour voir tout s'effondrer. Revenez simplement à l'ancien code.
la source
Pour rester motivé, continuez à vous dire que vous créez un jeu, pas un moteur de jeu - enfin, sauf si c'est votre truc. Et c'est cool, les moteurs de jeu sont excellents, mais ils gênent trop souvent la création de jeux.
Pour illustrer mon propos, je peux vous dire à quel point les choses vont souvent: au début, vous créez quelques sprites, les déplacez à l'écran avec votre proto-framework et vous êtes ravis! Vous pouvez voir vos progrès et ça se passe bien; vous pouvez montrer à vos amis.
Ensuite, une fois que vous avez un peu joué avec votre concept, vous vous rendez compte que vous devez rendre votre framework (ou moteur de jeu) plus flexible. Ou que vous devez re-factoriser une classe qui ne suit pas les derniers modèles. Et à partir de là, vous vous lancez dans une spirale de la mort: vous arrêtez de travailler sur un jeu et vous commencez à travailler sur un moteur de jeu. Et les moteurs de jeux ne sont pas aussi amusants à faire. Vous pouvez passer des heures à refactoriser et n'avoir rien à prouver - dans le jeu. Et puis, vous perdez tout intérêt.
Alors, rappelez-vous: créez des jeux, pas des moteurs de jeux. Ne refactorisez que lorsque vous en avez besoin. Ne soyez pas trop flexible - juste le strict minimum. *
*: bien sûr le refactoring et la flexibilité sont importants. Mais pas aussi important que d'avoir un jeu terminé.
la source
Essayez de créer une version jouable en une journée, aussi simple soit-elle. Répétez ensuite.
la source
N'essayez pas de rendre votre jeu trop compliqué!
Divisez votre tâche en petites sous-tâches spécifiques et mesurables. Si une sous-tâche semble trop grande, subdivisez-la davantage.
Assurez-vous d'écrire "DONE" en grosses lettres sur votre liste de tâches (j'utilise un fichier .txt) lorsque votre tâche est terminée. Ne supprimez pas la tâche, car elle ne semblera pas progresser.
C'est ce que je fais. Cela a fonctionné dans le passé.
la source