1

Le alloué à la réalisation de votre jeu web vous est souvent compté, que vous soyez professionnel (vous devez être rentable) ou amateur (vous n’avez que quelques heures de loisir à consacrer à votre jeu). Toute feature (= nouvelle fonctionnalité) doit donc être analysée pour savoir s’il vous faut vraiment l’ajouter à votre jeu.

Est-ce réalisable?

La première question à vous poser avant de penser à rajouter une feature est sa “réalisabilité”. En effet, pour réussir un jeu web (ou pour ne pas le faire capoter s’il est déjà en ligne, vous devez vous fixer des objectifs à votre mesure. Si vous n’avez pas une grosse équipe, visez un petit jeu et laissez tomber les features “compliquées” ou avancées. C’est d’ailleurs le travail principal de tout ingénieur: diminuer le plus possible la complexité du projet, pour qu’il soit réalisable et maîtrisable. Donc, pour savoir si une feature doit être rajoutée à votre jeu, il vous faudra mettre en balance les moyens nécessaires pour la réaliser avec les bénéfices qu’elle apporterait.

Si A vaincre sans péril on triomphe sans gloire (Pierre Corneille, Le Cid), gardez à l’esprit que A se lancer des défis impossibles, on ne peut qu’échouer (moi, ici).

Classer sa feature

Avant d’ajouter une fonctionnalité dans un jeu web, il faut se poser la question de son utilité et de son impact. Pour cela, j’essaie de catégoriser la feature suivant ce qu’elle amène:

Nouveaux choix

Une fonctionnalité ajoute des choix aux joueurs quand elle leur présente quelque chose qui leur permet d’emprunter des chemins différents, chacun ayant ses propres caractéristiques, aucun n’étant l’absolu-meilleur. Par exemple, une feature qui ajoute une nouvelle race d’ennemis offre de nouveaux choix aux joueurs, et de nouvelles perspectives de jeu. En revanche, une feature qui change l’apparence d’une race existante n’amène pas de nouveaux choix. Une feature amenant une nouvelle façon de perdre n’amène pas non plus de nouveaux choix (cette nouvelle façon de perdre sera évidemment évitée par les joueurs).

Attention aux features ajoutant de “faux choix”, c’est à dire des options de jeu qui n’offrent pas de gain véritable. Par exemple, si une ressource est indispensable pour progresser dans le jeu, proposer au joueur un territoire sans cette ressource devra être compensé par d’autres avantages, sinon, les joueurs ne choisiront jamais ce territoire (que vous avez passé du temps à créer) car il n’est pas viable.

Attention aussi aux features qui détruisent les choix existants: si vous rajoutez un nouveau choix aux joueurs qui est nettement plus puissant que ceux existants, alors ce nouveau choix “effacera” les anciens, et le temps passé à les avoir développés sera perdu.

Accessibilité, ergonomie

Une telle feature modifie l’interface des joueurs avec le jeu, leur permettant de faire faire au jeu ce qu’ils ont en tête. Cette catégorie regroupe donc toutes les features qui permettent d’améliorer l’accessibilité d’un jeu (portabilité sur de nouveaux supports, ouverture d’une API/REST, etc) ou son ergonomie (design, réagencement des boutons et de l’interface, etc).

Graphismes, immersion

La feature peut également favoriser l’immersion du joueur dans le jeu ou l’esthétisme général du jeu: graphismes plus réalistes, background story, cohérence dans la charte graphique, etc.

Bugfix

Cette catégorie regroupe les corrections de bug en tous genres. Par bug, j’entends un défaut qui nuit à la jouabilité du jeu: des ressources qui disparaissent lors d’un échange commercial, une flotte de vaisseaux qui a été perdue, un bouton qui ne marche pas, etc.

Optimisation

Cette dernière catégorie regroupe tout ce qui permet au jeu d’être plus rapidement exécuté par la machine, que ce soit par le serveur (amélioration de la vitesse de génération des pages, optimisation des requêtes SQL, etc) ou par le client (réduction du code javascript, allègement du DOM, etc).

Souvent, l’optimisation se fait bien mieux en essayant de supprimer le mauvais code/la mauvaise architecture existante plutôt qu’en rajoutant du code censé “faire aller plus vite”.

Bien classer la feature

La feature doit donc être rangée dans une et une seule catégorie. Si la feature peut s’étaler entre deux catégories, alors il faut la subdiviser, et faire deux features indépendantes. Il ne s’agit pas juste de séparer la feature en deux pour la forme (et dans les fait, n’en faire qu’une), mais de véritablement la séparer en plusieurs features élémentaires, chacune allant dans une et une seule catégorie. Pour bien vérifier la qualité de cette subdivision, on peut développer l’une de ces features, et releaser le jeu sans faire l’autre. Ensuite, on fait l’autre feature, et on release à nouveau le jeu.

Pourquoi découper ainsi en catégories? Pour éviter de modifier trop de choses à la fois, et de casser trop de trucs. Avec cette approche, on ne se focalise que sur une seule tâche, et on la fait bien, plutôt que de se disperser sur 3 tâches différentes, de faire des “ponts” entre elles, et de se retrouver avec un plat de spaghettis PHP impossible à faire survivre (façon Eclerdv0 !).

Que faire des features hors catégorie?

Si une feature ne peut pas être rangée dans aucune de ces catégories, c’est une feature inutile. De telles features ont alors tendance à alourdir inutilement le gameplay et le code: elles ne doivent pas être développées.

1