Concevoir un jeu - Par où commencer? [fermé]

Un de mes amis et moi planifions un jeu ensemble pour travailler pendant notre temps libre. Ce n'est pas un jeu extensif, mais ce n'est pas simple non plus.

Il travaille sur l'histoire derrière le jeu pendant que je travaille sur les graphiques et le code.

Je ne sais pas vraiment par où commencer avec le jeu. Nous savons quel sera le type de jeu de base et comment il sera joué, mais j'ai du mal à savoir par où commencer.

J'ai Xcode ouvert mais je ne sais même pas vraiment ce que je devrais concevoir en premier.

Quel conseil pour le bloc de cet écrivain? Où est un bon endroit pour commencer un jeu? Dois-je concevoir tous les graphiques et la mise en page avant même de toucher Xcode? Dois-je programmer les choses dont je sais que je vais avoir du mal avant de passer aux choses faciles?

Commencez par obtenir quelque chose et jouable. Ne passez pas plus d'une heure sur les graphiques, rendez simplement le jeu avec des espaces réservés. Les jeux n'ont pas d'exigences objectives pour construire: l'exigence clé est qu'il soit amusant, et évaluer si un jeu est amusant ou non nécessite de le jouer; par conséquent, la conception du jeu doit suivre une approche itérative . (Je recommande Tom Wujec sur le défi de la guimauve comme orientation sur la conception itérative.

Créez quelque chose sur papier et j'entends par là faire une maquette et des découpes. Établissez des règles et jouez à votre jeu sur la maquette en papier. Utilisez-le pour décomposer votre conception de code en ensembles de fonctionnalités et modules sur lesquels vous pouvez travailler. Ce processus aidera également votre ami à concevoir l'histoire et le fonctionnement du jeu.

Vous pourriez être tenté d'écrire des fonctionnalités supplémentaires dans votre code, évitez cela. Vous prototypez pour voir ce qui fonctionnera.

Une fois que vous avez un petit morceau en place et en cours d'exécution, vous devez travailler de manière itérative et à chaque itération, une seule fonctionnalité supplémentaire est en cours d'exécution. Lorsque quelque chose ne fonctionne pas bien, revenez en arrière et changez les fonctionnalités. Continuez à itérer et à changer.

L'idée de base est d'avoir une vision à long terme basée sur votre maquette papier, et à partir de là, une série d'objectifs à court terme sur lesquels travailler vous amènera où vous voulez aller un morceau à la fois et sans le stress de " omg que dois-je faire ensuite? "

Évaluez d'abord vos besoins. Le codage sans plan crée beaucoup de déchets plus tard.

Que doit faire le jeu sur le plan fonctionnel? De quels cadres avez-vous besoin pour que cela fonctionne? Quels sont les éléments qui peuvent être empruntés aux cadres existants et de quoi avez-vous besoin pour vous écrire?

Avant d'ouvrir Xcode, il peut être utile de faire des découpes de papier et de parcourir d'abord toutes les interfaces et boîtes de dialogue du jeu. Cela vous donnera une idée de ce que vous devez créer dans Interface Builder.

Ensuite, comment les choses interagissent-elles? Quels sont les différents styles d'interaction requis? Cela devrait vous donner une idée de la façon dont les contrôleurs doivent être divisés, démarrés et arrêtés.

Ne le planifiez pas à mort, mais définissez clairement vos besoins, et dès que vous pouvez diviser le projet en morceaux de la taille d'une bouchée (30 min-1 heure), vous êtes prêt à commencer à coder.

En regardant 2 jours, 2 semaines ou pire, 2 mois de tâches déclenchent une réaction de combat ou de fuite. Brisez-le en petits morceaux suffisamment gros pour pouvoir les mordre chacun de façon séquentielle sans vous étouffer, et je suppose que vous saurez exactement quelle morsure commencer et laquelle continuer ensuite.

Si le jeu est censé s'insérer dans un genre existant, ou s'il est en quelque sorte similaire à un autre jeu, essayez simplement de faire une imitation grossière et simple de ce jeu, ou faites un exemple "typique" du genre. Si vous n'êtes pas un bon codeur, suivez un tutoriel qui vous expliquera comment créer un jeu similaire au vôtre.

Après un certain temps, vous devriez naturellement ressentir le besoin de "diverger" de votre modèle et commencer à prendre le jeu dans votre propre direction. À partir de là, c'est une route descendante d'ajouter une fonctionnalité là-bas, de corriger un bug ici et de s'améliorer généralement par petites étapes.

S'il existe un certain concept unique à votre jeu, vous pouvez également commencer par créer la démonstration la plus simple de ce concept. Il y a aussi la possibilité de simplement construire votre jeu autour de ce concept.

Faites les choses qui vous donnent un prototype jouable dès que possible.

Les 1-2 premières semaines, vous ne pouvez probablement pas faire de bonnes estimations, car vous êtes nouveau dans le moteur. Donc, au cours des premières semaines, c'est probablement une perte de temps pour faire des estimations. Mais notez le temps que vous avez passé pour les choses, donc vous avez une certaine expérience sur laquelle vous pouvez baser vos premières estimations. Après ce temps, commencez à planifier, à estimer et à fixer des priorités!

Trois choses que j'ai apprises au cours des 6 derniers mois où je faisais partie d'un projet de jeu non réussi (j'ai été payé pour être le développeur implémentant la logique du jeu):

1. Ne changez pas votre plan tous les jours! C'est évidemment une bonne chose de suivre une voie agile, mais si vous finissez par changer vos objectifs chaque jour, il est clair que quelque chose ne va pas.
2. Gardez une trace du temps que vous passez sur votre travail. Comparez les durées estimées et effectives. Au début, vous remarquerez probablement une grande différence, mais avec le temps, vous devriez être en mesure de faire de meilleures estimations.
3. Tenez compte des estimations lors de la définition des priorités.

Important: De temps en temps, jetez un œil sur le projet et voyez ce qui s'est bien passé et ce qui s'est mal passé. Je suppose que vous pouvez identifier les parties où vous avez passé trop de temps sur quelque chose de non nécessaire. Essayez de laisser de telles choses la prochaine fois. (Par exemple: si vous travaillez sur un gadget que votre joueur peut utiliser 1 ou 2 fois dans le jeu pendant 2 secondes, ne passez pas un mois entier à l'implémentation.)

Si vous ne savez pas comment concevoir correctement un projet, je vous suggère de lire le chapitre 1 de la réflexion de Bruce Eckel en C ++ (le livre est gratuit), il y a une section intitulée "Analyse et conception". C'est une bonne introduction.

Assurez-vous de vérifier la pensée de Bruce Eckel dans C ++ Volume 2 .