Comment décidez-vous quand votre liste de fonctionnalités est suffisamment longue?

Je connais un peu cette question mais je trouve qu'il y a pas mal d'opinions diverses sur le sujet?

Du point de vue des joueurs, je sais que plus d'options sont presque toujours bonnes. Mais d'un autre côté, s'il a plus de joueurs, cela signifie une complexité plus élevée (méta-jeu) aussi bien pour les développeurs que pour les joueurs.

Sur la complexité du développement et les contraintes de temps vont toujours de pair. Un autre serait les contraintes de ressources et de plate-forme. Les ramifications économiques possibles de la retenue pour plus tard sont parfois aussi une raison.

Donc, d'après l'expérience des gens ici en dehors de ce qui précède, quand les fonctionnalités devraient-elles être supprimées ou être publiées ultérieurement?

Je dirais que c'est un processus en deux étapes pour nous:

• Établissez les objectifs du jeu.
• Déterminez quelles fonctionnalités nous aident à atteindre ces objectifs.

La liste des fonctionnalités est suffisamment longue lorsque ces deux points correspondent. Alors:

1. Établissez nos objectifs - Déterminez toutes les choses que nous voulons que le jeu fasse pour le joueur / relecteur / qui que ce soit, puis énoncez-les de façon mesurable. Par exemple, avec notre dernière ( voir la vidéo de test alpha ici ), nous voulons faire ceci:

• Visuels: Nous voulons que chaque critique mentionne que les visuels sont inhabituels et sexy, surtout pour un titre indépendant. C'est important pour nous, car les joueurs utilisent souvent leurs yeux comme une mesure rapide de la qualité (bien que, bien sûr, ce ne soit que l'un des nombreux!), Et nous voulons que cela les attire.
• Exploration: Nous voulons également récompenser les gens qui ont exploré le jeu. Pour dire les choses de manière mesurable, nous voulons que quelque chose sur un cinquième du temps de jeu du joueur soit consacré à faire de petites choses bien en dehors du gameplay de base. C'est important pour nous parce que (IMO), une grande partie du plaisir d'un jeu sort des zones centrales attendues (nous pensons à la façon dont le fait de cliquer sur des pièces dans Starcraft nous amuse).
• Communauté: Nous voulons que tout le monde parle à au moins un ami du jeu.

2. Déterminez les caractéristiques qui nous aident à atteindre ces objectifs - Celles-ci relèvent presque naturellement de ce qui précède. Ainsi, les fonctionnalités qui correspondent aux exemples ci-dessus peuvent ressembler à ceci:

• Visuels: En tant que petit studio, si nous voulons des visuels sexy, nous ne pouvons pas affronter EA ou Sony sur le réalisme. Donc, pour atteindre l'objectif de visuels remarquables, l'une des caractéristiques du jeu est une esthétique surréaliste. (À partir de là, nous pouvons déterminer les outils dont nous avons besoin, etc.)
• Exploration: des petits morceaux corollaires à l'action du jeu en découlent. Dans notre titre le plus récent , nous avons laissé une référence rapide à la recherche douteuse de Ryo pour les marins à Shenmue . C'était un jetable idiot, mais les gens ont aimé et en ont parlé!
• Communauté: Nous nous demandons toutes les façons de faire un jeu qui mérite d'être mentionné à un ami. Bien sûr, c'est amusant. Mais nous pourrions également récompenser les joueurs avec un objet ou un niveau spécial s'ils tweetent à ce sujet. Pokemon a valu la peine d'avoir des amis pour prendre le jeu - il y a des créatures que vous ne pourriez obtenir qu'en interagissant avec d'autres personnes.

Lorsque nous passons par ce processus, cela nous aide à déterminer:

• Combien nous devons mettre en œuvre pour un produit minimum viable ( MVP ).
• Ce qui est le plus important, ce qui peut attendre et ce que nous pouvons abandonner.
• Quand nous aurons enfin toutes les fonctionnalités dont nous avons besoin.

Il convient de noter que nous ne respectons pas servilement ces règles! Plus souvent qu'autrement, certaines choses incroyablement intéressantes se produisent à la suite du prototypage à mi-projet et de la simple futzing générale. Surtout pour les petits jeux comme le nôtre.

La complexité ne rend pas votre jeu amusant.

La bonne combinaison et l'équilibre des éléments de gameplay le font. Le joueur doit être poussé dans la mesure de son niveau de compétence et ressentir la maîtrise des défis à relever.

Votre liste de fonctionnalités devrait changer chaque fois que vous estimez que le gameplay actuel n'est pas amusant. Ces modifications doivent être effectuées dans les limites de votre budget / temps. Assurez-vous que toutes les modifications que vous apportez apportent une valeur ajoutée à votre jeu.

De plus, prototypez tôt, ne vous contentez pas d'écrire une énorme liste de fonctionnalités et supposez que tout sera amusant une fois assemblé.

La perfection est atteinte, non pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à emporter.

-- Antoine de Saint-Exupéry

Lorsque le temps et les efforts nécessaires pour les inclure sont supérieurs à la valeur qu'ils ajoutent au jeu .

Par exemple, si vous créez un jeu sportif ou quelque chose où les joueurs voudront probablement montrer leurs compétences, le multijoueur est un must. Guitar Hero ne serait pas le même sans lui. Cependant, un jeu uniquement individuel, où vous atteignez du début à la fin par vous-même, suivant une histoire ou un complot n'a pas besoin de multijoueur. Le système multijoueur de mauvaise qualité de Grand Theft Auto San Andreas en témoigne (même si cette société n'a probablement pas trouvé le multijoueur trop difficile).

De plus, les fonctionnalités qui ne correspondent pas vraiment à l'histoire du jeu, sont juste là car elles peuvent l'être. Si ce n'est pas complètement essentiel au gameplay, c'est probablement un bon signe qu'ils peuvent être poussés vers une version ultérieure si le temps est un problème.

Le fait est que les fonctionnalités supplémentaires ne sont pas l'élément par excellence d'un jeu. Un scénario passionnant combiné à un gameplay agréable est.

Bien qu'il existe un certain degré de variété dans les fonctionnalités (être capable de faire des tonnes de choses aléatoires dans un jeu GTA-ish, avoir des tonnes de variété d'armes et d'accessoires dans un RPG ou un jeu Call of Duty-ish, etc.), Je pense qu'un gameplay plus minimal axé étroitement sur quelques fonctionnalités de base peut être très efficace.

Regardez Portal, il a pris son seul mécanisme et a vraiment construit ses puzzles autour de cela sans avoir besoin de beaucoup d'encombrement supplémentaire.

Je pense qu'être strict pour garder la liste des fonctionnalités aussi minimale que possible et étoffer vraiment quelques fonctionnalités de base permet un projet plus réalisable et souvent une expérience plus agréable (si Portal ajoutait des éléments RPG et des séquences de conduite et slowmo et toutes les autres "fonctionnalités intéressantes" ", aurait-il été aussi bon? La mécanique de base aurait-elle été aussi polie?).

Maintenant, en tant que développeur indépendant, je suis sûrement biaisé, mais je pense qu'en général «moins c'est plus» dans les fonctionnalités, et même si quelque chose peut être cool ou populaire en ce moment, si cela ne rend pas l'expérience globale sensiblement meilleure, devrait être coupé.

D'après mon expérience personnelle, il est préférable d'éviter le plus rapidement possible l'ajout de nouvelles fonctionnalités imprévues.

Du point de vue de la conception, une fonctionnalité qui a été ajoutée pendant un moment donné "ne serait-il pas agréable d'avoir une fonctionnalité x" ajoutera-t-elle beaucoup de temps de développement, pourrait ne pas bien s'intégrer au code, et pourrait ne pas s'adapter parfaitement avec le reste de votre conception.

Dans le pire des cas, un projet qui a eu beaucoup de ces moments peut se sentir comme une combinaison de fonctionnalités désordonnée et piratée, qui aurait vraiment dû consacrer beaucoup plus de temps à ces étapes dans la phase de conception et avoir l'air moins professionnel en conséquence.

En règle générale, j'essaie de suivre ces règles:

• Si une nouvelle fonctionnalité apparaît au début du projet, prenez le temps de revenir à la phase de conception et voyez vraiment comment cette fonctionnalité peut fonctionner avec votre produit tout en restant cohérente avec le reste de la conception.

• Si le projet se rapproche de la version, envisagez de créer une liste de fonctionnalités à ajouter à une nouvelle version.

• Si vous constatez que de nombreuses fonctionnalités continuent à apparaître que vous souhaitez vraiment implémenter, vous devriez peut-être envisager de revenir à la conception et de comprendre pourquoi ces nouvelles fonctionnalités n'ont pas été prises en compte plus tôt, peut-être en raison d'un manque d'efforts consacrés à la phase de conception.

Évidemment, cela convient mieux à certains projets que d'autres, mais vraiment si vous avez une fonctionnalité qui arrive tard dans le projet, vous vous en sortirez probablement bien, au moins jusqu'à ce que vous commenciez à travailler sur une nouvelle version.

Gardez les listes courtes, soyez agile

Ne construisez pas du tout de listes de fonctionnalités, ou si vous le faites, construisez-les très courtes, ne valant que quelques semaines de développement.

Développez dans un style agile - commencez par les quelques fonctionnalités les plus importantes du tout, testez, en fonction de ce qui fonctionne et de ce qui ne fonctionne pas, puis réfléchissez si cela vaut la peine d'ajouter d'autres fonctionnalités (vous pourrez les juger beaucoup mieux si vous avez déjà une certaine expérience avec le gameplay de base).

Comment juger une caractéristique individuelle

À part cela, je serais d'accord avec le critère de bennybdbc, "Lorsque le temps et les efforts nécessaires pour les inclure sont supérieurs à la valeur qu'ils ajoutent au jeu.".

Cela dit, vous devez également considérer le monde "externe":

• manquez-vous d'argent ou de temps donné par un contrat?
• manquez-vous d'espace de publication (DVD plein)
• manquez-vous d'espace de performance (de nouvelles fonctionnalités rendraient le jeu trop lent)?
• un jeu concurrent va-t-il bientôt être publié?

De simples problèmes réels comme celui-ci doivent également être pris en compte, sauf si vous développez le jeu juste pour vous amuser.

Lorsque vous manquez de papier pour l'écrire.

La limite définitive sera la taille du support; vous ne pouvez pas intégrer 10 Go de fonctionnalités sur un DVD de 4,7 Go, par exemple.

Vous ne voulez pas non plus trop de fonctionnalités pour trop compliquer le jeu. La meilleure façon est de se demander «est-ce que ça va être très amusant pour le joueur? cela va-t-il trop ronger notre temps de développement? Est-ce seulement possible?'