Puis-je utiliser le fluage des fonctionnalités à mon avantage? [fermé]

Puis-je utiliser le fluage des fonctionnalités à mon avantage?

Chaque fois que je crée un prototype, des fonctionnalités sont ajoutées par inadvertance. Cela se produit soit par coïncidence, soit il est facile à ajouter en fonction du contenu existant.

Si je connais le genre du jeu, puis-je commencer à créer les mécanismes de base et ajouter des fonctionnalités à mesure qu'elles deviennent apparentes?

Par exemple, si je veux créer un jeu de plateforme 2D en 6 mois, puis-je commencer à faire de la course, du saut, du tir, etc. et ajouter les mécanismes de base comme je les trouve par inadvertance? Ou est-ce trop risqué d'un investissement en temps sans un plan prédéterminé?

Ma logique derrière cela est que le design en sera plus pour son argent. Les choix de conception seront plus facilement construits autour de ce qui est facile à faire (temporellement).

En résumé, y a-t-il quelque chose de mal à créer un jeu avant de le concevoir?

Voilà une question intéressante. Principalement parce que répondre à cela soulève le dilemme des nuances de gris contre le noir contre le blanc.

y a-t-il quelque chose de mal à créer un jeu avant de le concevoir?

Si vous considérez cette question comme un type oui ou non, la réponse ne peut être que: oui, il y en a. Si la réponse peut être plus nuancée, elle change. Raison: vous ne devriez jamais construire un jeu avant une certaine conception. Mais vous pouvez certainement enregistrer des parties de la conception pour plus tard.

Cela signifie que je ne pense pas que vous devriez considérer le problème comme un problème ou non. C'est plutôt quelque chose que vous devriez penser en termes de degrés. La fonctionnalité rampante est peut-être la toute deuxième racine de tout mal en ce qui concerne le développement de jeux (la première, comme Donald Knuth nous l'a dit, est que "l'optimisation prématurée est la racine de tout mal" ). Cependant, d'après mon expérience, ne penser à aucune des principales caractéristiques, c'est-à-dire ne pas avoir au moins une conception de base de l'endroit où vous voulez aller avec votre mécanique de base, n'est pas non plus une bonne idée.

La première raison principale est qu'il est utile, en termes de ressources (y compris le temps en tant que ressource), d'avoir une certaine planification pour vous guider à travers - car atteindre des impasses tout le temps en raison d'essais et d'erreurs excessifs peut être tout aussi gaspillage de ressources comme devant inclure des éléments imprévus.

La deuxième raison principale, au niveau de la conception du jeu, est la cohérence. Une bonne conception de jeu a une cohérence conceptuelle, ou une cohérence si vous le souhaitez. Cela signifie que le jeu global, l'historique, la mise en œuvre, même les graphismes, devraient s'emboîter le plus harmonieusement possible. Il est très peu probable qu'une conception de jeu atteigne quelque chose comme ça si les principales fonctionnalités sont découvertes en déplacement. Sinon pour autre chose, car en déplacement, il y a beaucoup d'aléatoire: les choses sur lesquelles vous allez marcher peuvent avoir des impacts très différents selon le moment où vous les avez trouvées lors du processus de développement .

Je ne veux pas dire que vous ne devriez pas du tout faire ce que vous avez dit. Je prétends simplement qu'il faut trouver un équilibre.

Par exemple, si je veux créer un jeu de plateforme 2D en 6 mois, puis-je commencer à faire de la course, du saut, du tir, etc. et ajouter les mécanismes de base comme je les trouve par inadvertance? Ou est-ce trop risqué d'un investissement en temps sans un plan prédéterminé?

Je commencerais par introduire une légère modification dans votre phrase. En effectuant la course, le saut, le tir et etc., vous implémentez déjà la mécanique de base. Ce que vous ajouteriez sur le pouce dans votre exemple, ce sont les fonctionnalités de jeu spécifiques.

Ce n'est pas parce que vous savez que le jeu sera une plate-forme 2D que la course, le saut ou le tir ne peuvent pas varier selon la conception du jeu. Votre joueur peut-il courir sur les murs? Votre joueur peut-il flotter dans les airs en sautant? Même, votre joueur peut-il tirer en courant? Votre joueur tire-t-il uniquement dans une direction linéaire ou via une parabole? Ces décisions peuvent être très dépendantes des fonctionnalités du jeu.

Mais je vois votre point: ces mécaniciens ont souvent des pièces qui varient très peu. Donc, si vous faites une game-design et de décider sur les caractéristiques de base autant que pour être un peu sûr de savoir comment courir, sauter, tir, etc fonctionnera, c'est un début. Ensuite, vous pouvez opter pour ces mécaniques et continuer à les développer.

Bien sûr, vous pouvez toujours trouver plus tard une nouvelle fonctionnalité qui vous oblige à modifier ces mécanismes - peu importe leur niveau de base. Mais la clé ici est la probabilité. La probabilité que cela se produise trop souvent sera plus faible si vous avez au moins réfléchi aux conséquences de la course, du tir, du saut, etc. pour les idées de base que vous aviez pour le jeu.

Enfin, si vous voulez emprunter cette voie, je vous suggère ce qui suit. Considérez-le comme un processus itératif. Vous effectuez une réflexion de conception initiale à grande échelle. Vous implémentez ce qui semble basique et plus "universel" au sein de votre jeu, pour qu'il réussisse. Ensuite, vous réfléchissez davantage à la conception, réévaluez ce que vous avez mis en œuvre et optez pour une mise en œuvre supplémentaire.

Lorsque vous effectuez des projets complexes comme des jeux, vous ne pouvez souvent pas créer toutes les fonctionnalités que vous souhaitez, car vous manquez de temps / d'argent ou parce qu'elles ne se sont pas avérées aussi bonnes que prévu. C'est ce qu'on appelle le fluage des fonctionnalités. Mais il y a un revers à cela; vous trouverez également des fonctionnalités dont vous ne pensiez pas avoir besoin, mais au fur et à mesure que le projet prend forme, leur besoin devient apparent.

C'est pourquoi les gens construisent des prototypes - afin qu'ils puissent apprendre ce qui fonctionne et ce qui ne fonctionne pas, afin qu'ils puissent couper des fonctionnalités qui ne fonctionnent pas , mais aussi pour trouver de nouvelles fonctionnalités qui seraient géniales . Si vous ne faites rien de ce que vous n'apprenez pas , vous le faites mal.

C'est essentiellement le sentiment exprimé dans une conférence intitulée Advanced Prototyping , par Chris Hecker et Chaim Gingold, qui comprend de nombreux exemples de leurs travaux sur Spore, où ils étaient souvent surpris par ce qui fonctionnait et ce qui ne fonctionnait pas, allant jusqu'à la refonte complète systèmes basés sur des prototypes de rétroaction.

Un autre exemple est le processus de conception de Left 4 Dead ; au début, le jeu n'avait que des zombies de base, mais à partir de tests de jeu avec des joueurs expérimentés, les concepteurs ont constaté que les joueurs se collaient efficacement et que le jeu était trop facile, ils ont donc ajouté des zombies spéciaux pour briser l'équipe et garder le jeu excitant.

Bien sûr, cela ne signifie pas que vous devez créer votre jeu sans aucune conception préalable . Vous devez vous assurer que le cœur de votre jeu est amusant avant de continuer, car c'est souvent la partie la plus difficile de faire un jeu.

Je dirais que oui, allez-y. Mais prévoyez à l'avance des fonctionnalités / classes communes pour avoir une certaine cohésion entre chaque nouveau composant.

Unity est connu pour son approche composante du développement de jeux, et permettrait facilement cette forme de développement. Si vous n'utilisez pas Unity, vous pouvez répliquer une approche semi-composante. Je ne connais pas les autres moteurs de jeu.

Les objets de jeu Unity ont tous un composant de transformation. Cela indique la position, la rotation et l'échelle de l'objet. Faites donc une classe générique de «transformation» pour contenir ces valeurs, plus une référence à l'objet de jeu réel peut-être.

Prenez un composant «Jump», par exemple. Faites travailler toute la logique avec la classe de transformation d'un objet de jeu pour effectuer la manipulation de la position. (Ou votre moteur aura déjà une classe intégrée similaire.) Vous pouvez attacher cette classe `` Jump '' à n'importe quel objet, et la classe animera la position de transformation lorsqu'une action est déclenchée (Jump.PerformJump () ou autre). La classe Jump n'a rien à savoir sur son propriétaire (ou, au moins, des informations minimales).

Vous pouvez maintenant vous amuser à créer une tonne de composants, puis à les attacher à des objets de jeu, à les combiner sur un seul objet, etc. un composant générique), etc.

Rendez chaque composant aussi générique que possible pour permettre plusieurs utilisations / variations. Pour FireWeapon, vous pouvez spécifier le sprite de balle, la vitesse, les dégâts, etc. De cette façon, vous ne vous souciez que des différences relatives entre les armes. De plus, cela s'adapte aux paramètres globaux tels que la difficulté où une difficulté plus élevée a un maximum de dégâts plus élevé, etc.

Avant de vous en rendre compte, vous disposez d'un arsenal de composants à brancher, et vous pouvez désormais développer rapidement pour n'importe quel type de jeu.

Bref: la plupart du temps, vous ne pouvez pas avoir une seule étape de conception suivie d'une seule étape de codage. Vous devrez les alterner. En règle générale, essayez de respecter ce qui est déjà conçu (pas ce qui est déjà codé).

A propos de ne pas avoir de design initial (juste un croquis ou une image mentale): si vous n'avez pas de design, vous n'avez pas de design. Vous devez faire quelque chose pour en avoir un. Mais tant que vous commencez à en construire un, essayez de le respecter, ne venez pas avec un nouveau à chaque fois.

Faire de l'expérimentation et obtenir des fonctionnalités aléatoires peut ou non être nocif. Cela peut même être bénéfique ou inévitable. Par exemple: vous savez que vous souhaitez prendre en charge le saut (de nombreux RPG 3D / 2D ne permettent pas de sauter). Comment tu le sais? Parce que vous avez imaginé une carte de jeu nécessitant de sauter pour trier un obstacle? Ainsi, la mise en œuvre du saut est assez bonne tant qu'elle permet au joueur de trier cet obstacle ou doit-il se conformer à certaines caractéristiques comme l'altitude maximale accessible, peut-il être boosté par des objets ou des objets de jeu sur la carte, la physique doit inclure l'accélération ou le rebond ( quand Mario saute dans un ennemi, il gagne une impulsion pour s'élever à nouveau et c'est très important pour le jeu)?

Si vous pouvez déjà répondre à ces questions, vos documents de conception (imaginaires ou réels) sont très complets. Si vous ne pouvez pas y répondre, votre conception est incomplète. Dans ce cas, vous devrez recommencer à travailler dans la conception ou faire de l'expérimentation pour combler les lacunes. Les opportunités peuvent être très ouvertes ou très restrictives. Si certains de vos niveaux de jeu ont des obstacles et que vous avez juste besoin de sauter pour eux, il y a beaucoup de liberté pour décider de l'altitude ou de la vitesse maximale atteignable, peut-être que vous décidez de faire semblant qu'il existe un moteur physique pour tout commencer juste pour améliorez les visuels de l'animation de saut mais vous n'en avez pas besoin pour autre chose. (Dans de nombreux jeux RPG 2D, vous ne pouvez pas sauter quand vous le souhaitez, mais tant qu'il y a un seul trou de tuile sur une carte, essayer d'y entrer déclenche automatiquement un saut vers la tuile de sol à côté de la tuile de trou)

Je comprends que c'est OK d'aller au code sans une conception complète tant que vous respectez ce qui est déjà décidé. De plus, cela peut être inévitable dans certaines situations, car les univers de jeu peuvent être construits à partir d'une variété de processus de pensée différents. Par exemple, un jeu de cartes: je sais que je veux que les cartes aient Attaque et Défense, un certain nombre de cartes dans la table à un moment donné et que le joueur durant son tour puisse choisir avec quelle carte attaquer quelle autre carte. Il peut sembler à certains comme une conception déjà complète, mais vient ensuite l'équilibrage du jeu, uniquement possible grâce à de nombreuses simulations. Après de nombreuses simulations, je décide qu'une carte avec Attack 10 est maîtrisée, je peux simplement la supprimer du jeu mais je l'aime trop, je vais donc faire quelque chose de différent, Je vais créer une nouvelle règle qui dit que si un joueur attaque avec une telle carte, il ne peut pas attaquer avec une autre carte pendant ce tour. Maintenant, j'ai une nouvelle règle qui enrichit la mécanique du jeu, mais l'appliquer à une seule carte a l'air bizarre (comme un hack sale), je me rends compte que ça a l'air bizarre et ensuite je décide de créer un nouvel ensemble de cartes qui ont des nombres élevés mais le une nouvelle règle de limitation leur est applicable. Maintenant, j'ai un mécanisme de jeu plus complexe, construit au-dessus de l'original plus simple, à mon avis, je l'ai mis à mon avantage pour faire un meilleur jeu.

Maintenant, une chose à propos de ce dernier exemple, dans l'exemple proposé du jeu de cartes, de nouvelles cartes peuvent entraîner de nouveaux actifs (augmentation des coûts, augmentation du temps). Mais je pense que c'est un bon exemple de laisser les opportunités que vous voyez uniquement lorsque le codage influence vos décisions de conception dans le bon sens.

Je ne pense pas que la plupart des jeux auxquels nous jouons aient été entièrement conçus avant le codage, je suis sûr qu'ils ont dû prendre des décisions difficiles pour respecter les délais, etc.

Quand quelqu'un d'autre paie tout: expliquez, négociez.