• un identifiant : nom, race, origine et source visuelle
• trois énergies : hp (énergie vitale), ip (initiative, énergie d'action) et bp (respiration, énergie de dépendance influant sur tout le reste)
• un équipement : l'outil principal, le complément et l'habit
• quatre objets : utilisables en tant qu'actions

Il correspond à l'identifiant selon le premier prototype.

Elles correspondent les trois au premier prototype si ce n'est que la troisième énergie aura une influence plus importante sur les deux autres.

Pour l'instant, la seule énergie précisément définie est celle vitale (hp). L'énergie d'initiative est un principe intéressant et novateur mais doit être remise en question relativement à la troisième énergie, qui n'est par contre pas définitive - peut-être n'est-elle que superflue et disparaîtra-t-elle.

Il correspond exactement à celui du premier prototype.

Il aura une importance cruciale en ce qu'il sera conditionnement des actions du personnage (voir actions).

Le mémoire vient supprimer la notion de compétences.

Il s'agit du 4ème objet après les trois pièces d'équipements et donc de la 4ème action accessible à tout instant. Il s'agit d'un livre que possèdera le joueur et dans lequel seront stockées des pages informatives au fur et à mesure du scénario. Ces pages seront de plusieurs types :

• pages informatives officielles : des pages enregistrées automatiquement lors de découvertes d'éléments majeurs, par exemple l'apprentissage des paroles d'incantation d'une magie
• lettres et textes retrouvés
• feuilles de notes prises par le joueur dans le livre : ce dernier pourra y placer toutes les informations qu'il souhaite pour se souvenir d'indices ou autres informations utiles

Il remplace la notion de compétences en ce qu'il n'y aura pas de compétences. A la place de devoir obtenir une compétence et donc accumuler des données, on aura accès à tout dès le départ mis à part les données conditionnées par l'équipement.

Pour utiliser une incantation, il suffira de la réciter textuellement. Les incantations apprises seront inscrites dans le mémoire et pourront être attribuées à des touches ou des raccourcis pour être récitées de tête sans avoir à être écrites.

Les objets de soutien suppriment la notion d'inventaire qui est trop cumulative.

Les objets de soutien seront limités volontairement à quatre. Ainsi ce seront les quatre dernières actions du client.

Il existera plusieurs types d'objets selon les actions possibles :

• les objets utilisables
• les objets équipables
• les objets intégrables (sortes de plugins visuels)
• les objets visionnables

Les deux derniers types d'objets ne sont pas des objets de soutien.

Ces objets sont des plugins visuels. Il s'agit par exemple d'ajouter un élément à un habit, changer sa couleur, etc.

Cette fonctionnalité est tout à fait secondaire et donc sera implémentée par la suite.

Ces objets sont des composants du mémoire. On peut les récupérer en tant qu'objets, mais dès qu'ils sont acquis, ils s'intègrent au mémoire et n'ont donc plus valeur réelle d'objet.

Les objets de soutien sont les objets utilisables ou équipables, ou les deux. Il s'agira d'actions spécifiques à chaque objet telles que :

• une potion : à boire, mais il restera ensuite un flacon vide que l'on pourra remplir
• une graine : à placer dans la terre, elle ne sera alors plus disponible
• un grimoire : contient une incantation à lire permettant l'utilisation d'une action spécifique sans besoin initial de la connaître, son utilisation crée une page du mémoire et détruit le grimoire
• …

Les équipements auront des actions spécifiques selon leur utilisation en tant qu'outil principal, complément ou habit. A noter qu'un objet peut ne pas pouvoir être utilisé dans certains cas ou en tant qu'habit ou outil spécifique.

Toujours les mêmes du premier prototype, elles prendront désormais une valeur supplémentaire car elles définiront complètement le développement scénarique alors que l'inventaire n'existe plus.

Toutes les clés et pass y seront notés. S'il y a une accumulation, ce n'est plus d'objets, mais d'événements scénariques.

La position est une variable temporaire. Lorsque le client se déconnecte, sa dernière position sauvegardée est stockée comme futur point de départ.

De manière à rendre l'environnement sain, des zones de sauvegarde seront mises en place. Ces zones seront des zones de non-conflit. Personne ne pourra y utiliser de capacité si ce n'est en sortir ou sauvegarder.

La sauvegarde d'une session se fera obligatoirement dans une de ces zones.

Note : ce sont des zones “saintes”

Le client sera composé principalement de la map en plein écran et d'une interface minimaliste :

• une zone de saisie de texte
• une zone d'affichage du texte (ce dernier étant en plus affiché dans des bulles au-dessus des personnages parlant)
• un encadré informatif à propos du statut du personnage client (nom et énergies)

Les menus seront autant restreints :

• le menu contextuel lors d'un clic gauche sur un objet à contexte spécifique (implémentation ultérieure vu que les contextes spécifiques n'interviendront qu'avec le système événementiel)
• le menu d'actions lors d'un clic droit (cercle contenant les huit actions disponibles ainsi que l'action par défaut de déplacement)

Les huit actions :

1. outil principal
2. complément (outil secondaire)
3. habit (équiper ou non, fonctionnalité supplémentaire selon l'objet)
4. accès au mémoire
5. objet de soutien 1
6. objet de soutien 2
7. objet de soutien 3
8. objet de soutien 4

Le problème a été soulevé par les problèmes d'optimisation et la fréquence de modification de l'affichage lors des déplacements. Soit le déplacement est retardé pour la caméra selon la disposition relative du personnage vis à vis du centre de l'écran, soit on insère une action supplémentaire permettant le déplacement de la caméra indépendamment de la position du personnage client.

Note : on peut aussi gérer les deux en même temps avec possibilité de switcher de l'un à l'autre… mais cette partie du développement ne sera soulevée que dès qu'une première version sera en cours d'optimisation.

Note : le développement 3d rend obsolète le problème de déplacement et caméra étant donné que la caméra sera maniable à volonté autant que la gestion des déplacements qui sera effectuée au clavier en temps réel sans retard direct (mais retard indirect)