Aide vocabulaire conception de jeu

[Snoody]

hello,

Je voudrais débuter un premier jeu... les idées sont la, mais la façon de procéder m'échappe un peu .. J'ai bien vu différent articles expliquant les bases, mais pourriez-vous éclairer ma lanterne sur ces points :

- que contient à peu près le cahier des charges ? en avez-vous des exemples ?
- qu'est ce que la timeline ? la définition des dates clés du projet ? les deadlines des parties ?
- qu'est qu'un roadmap ?

merci d'avance ^^

[rachids]

De mes (maigres) souvenirs d'école, le cahier des charges c'est le document du projet qui résume ce que va faire le projet (une sorte de description ainsi qu'un listing des features), comment sont réparties les tâches s'il y a une équipe, le planning du projet, le coût (en temps, en argent).

Je n'ai jamais eu à l'utiliser autant professionnellement que personnellement mais je sais qu'il peut être très très utile pour bien encadrer le développement du projet.

La timeline je dirais que c'est le découpage dans le temps du projet. Exemple pour notre projet d'études on avait une timeline (on appelait ça un planning plutôt) qui commençait par poser par écrit les fonctionnalités qui vont être nécessaires, la base de données à créer et les classes qu'on utiliserait dans notre projet. Puis intervient une phase de développement pur, une phase de test et débug puis une dernière phase de test où normalement tout doit bien se passer.

La roadmap c'est la succession des tâches à faire, souvent en fonction des priorités (il arrive souvent qu'un bug doit être réparé bien avant de commencer une nouvelle feature).

Après ça c'est très scolaire, j'en parlais avec mon DT au boulot et il me disait que de nouvelles méthodes sont sorties pour organiser et gérer une équipe de développement et que le planning notamment est beaucoup trop rigide pour s'appliquer à un projet informatique. Puisque les choses fluctuent, des bugs bloquants peuvent apparaître et retarder le développement ou bien le client te balance une nouvelle fonctionnalité ou une modif à faire et s'il rajoute des euros bah tu pourras pas négocier faudra le faire.
Je pense que ça dépend grandement des entreprises. Côté perso, j'ai jamais utilisé mais plus par flemme que par désintérêt.

[Ter Rowan]

le cahier des charges contient tout ce qu'il faut pour comprendre le besoin, quelques exemples :

qu'est ce que le produit ? (un jeu de .... qui permet de ...)

A qui s'adresse le produit ? (quel public, âge, nationalité, profil divers - supporter de foot ? rôlistes? déficient visuel ? communicants ? solitaires ? )

Quelle est la fréquence d'utilisation ? (éventuellement tu peux avoir différents publics à différents degrés d'utilisation : le solitaire jouera 10 minutes par semaine, le communicant passera ses heures sur le tchat du jeu)

Quelles sont les grandes fonctionnalités du jeu, avec une description sommaire, Exemple :

combat pvp : en temps réel / par ordre / par tour par tour les combattants doivent être connectés / par tour par tour les combattants donnent leurs ordres et le combat est résolu tous les soirs à minuit / nombre maximum de combattants dans un combat

artisanat : un personnage peut créer des objets à partir de recette détaillée (recette de sandwitch au lapin) / peut créer des objets à partir de recette générique (recette de sandwitch à la viande), le choix de la viande donnera des propriétés différentes à l'objet proiduit / peut créer des objets au hasard en mélangeant les ressources

ventes : a tous les pnj ? a des pnj particuliers ? au joueur via un hotel des ventes ? au joueur via une interface d'échange type je communique ?

type de communication entre joueurs : forum , tchat ? ...

la carte : des cases ? des lieux ? comment se déplace t on ?

etc...

plus tu préciseras ton cahier des charges plus il sera facile de se faire une idée de ce que tu veux et de comment le modéliser techniquement. Plus tu feras de fonctionnalités... moins tu auras chance que ton projet aboutisse (bon moi ça fait peut être 12 ans que je suis sur mon premier jeu ...)


la time line, c'est ton planning : a quelle date tu fournis le cahier des charges; les specs, l'alpha, la beta, etc... si tu as plusieurs lots, ca contient les dates de livraison des lots

la roadmap, c'est plus global : ok ta timeline te dit comment et quant tu arrives à ouvrir ton jeu. La roadmap te dira quand arrivera la v2 (évolution majeure) de ton jeu, et ce qu'elle est sensés contenir (en tout cas les éléments principaux, il peut y en avoir en annexe non précisés)


sinon pour le commentaire de salty sur le planning... c est vrai et faux.
Il y a des méthodes dites "agiles" qui ne définissent pas les mêmes types de jalon cependant elles ont aussi leurs inconvénients (la différence c'est que l'informaticien a alors un joker "c est pas de ma faute, je ne me suis pas engagé y a 6 mois a finir cette liste de fonctionnalité"

maintenant on peut aussi faire (et on fait) des plannings corrects : un planning qui ne tient pas compte de phases de recette (test + correction de bugs) est un mauvais planning. Et on détermine le nombre de phase de recette en fonction de la qualité des développeurs, de la complexité du besoin et du sérieux du métier)

évidemment a voir après la contrainte du planning de la concurrence (promettre quelque chose qu'on ne tiendra pas pour avoir le marché, etc...) mais dans un monde sensé et rigoureux, le planning ca marche très bien, si on a affaire à des gens sérieux

[Snoody]

merci pour vos réponses

ca pose quelques questions auxquelles je n'avais pas forcément pensé ^^

une partie reste obscure .. mais ca va me permettre de dégrossir la présentation de mon jeu