Discussion :

[dstar]

Tusteria Tales (nom non définitif) est un jeu de type MMORPG.

Il met en scène un monde de type heroic fantasy où l'ensemble des personnages représentant les joueurs connectés peuvent intéragir.

Le but du jeu est de réussir un certain nombre de quêtes. Le jeu est résolument orienté PvE, le combat entre les joueurs et un certain nombre d'ennemis en constituant son coeur.
Le joueur incarne un personnage qui se déplace en temps réel de case en case sur différentes cartes du jeu. L'ensemble de ces cartes forment le monde. La représentation de ces cartes sur l'écran de jeu permet aux joueurs de visualiser et d'intéragir avec les décors, leur personnage et ceux des autres joueurs, les personnages non-joueurs (PNJ), les ennemis et les objets qui sont posés sur le sol.
Le monde dans lequel évoluent les personnage des joueurs est inspiré des univers de type héroïc fantasy habituels. On y croisera des races classiques: humains, elfes, nains, ainsi que des ennemis: insectes géants, orcs, trolls, dragons...
Comme dans tout bon RPG, les joueurs ont la capacité de faire évoluer leur personnage. Ceux-ci accumulent des points d'expérience lorsqu'ils réussissent une quête ou lorsqu'ils vainquent un ennemi. Ces points peuvent alors être utilisés pour acquérir ou améliorer une compétence, ou pour incrémenter le niveau d'expérience. Un nouveau niveau d'expérience permet au personnage d'améliorer ses caractéristiques et et lui donne la capacité d'acquérir un nouveau panel de compétences.

Les quêtes représentent le coeur du jeu. Elles confrontent les joueurs à différentes situations. Ceux-ci doivent alors utiliser au mieux les ressources de leur personnage, trouver une tactique ou une stratégie en coopération avec les autres joueurs pour la résoudre.
Les joueurs doivent se grouper pour pouvoir participer à une quête. Ils sont alors transportés sur un ensemble de cartes spécifiques à la quête. Seuls les personnages du groupe de joueurs a accès à ces cartes. Ils doivent alors remplir la quête en atteignant un certain nombre d'objectifs communs au groupe.

Le jeu a une fin: lorsqu'un joueur a réussi l'ensemble des quêtes, le jeu se finit pour lui, bien qu'il lui soit permis de continuer à arpenter le monde afin de refaire certaines quêtes pour aider d'autres joueurs ou pour son propre plaisir.

Pour résumer, le gameplay repose sur un équilibre entre la réalisation de quêtes dont la réussite permet de faire évoluer le personnage, et ces évolutions qui donnent accès à de nouvelles quêtes. Ceci dure jusqu'à ce que l'ensemble des quêtes aient été réussies.

Au niveau de l'affichage graphique, le jeu est représenté en 2D. Le monde est divisé en cartes, elles-mêmes organisées en cases. Les différents personnages (joueurs, non joueurs et ennemis) se déplacent de case en case à l'intérieur des cartes, ainsi que de carte en carte pour les personnages joueurs.
La représentation graphique du monde se veut plus schématique que réaliste. Les décors sont affichés selon une vue aérienne, les personnages, autres PNJ et ennemis sont représentés de face sur les décors.
D'une manière générale, l'aspect graphique ne représente pas un aspect important du jeu, et c'est un choix délibéré que de le traiter de façon minimaliste afin de se concentrer sur le contenu.

En terme d'architecture, le jeu est divisé en 2 modules:

• le serveur est la partie centrale, il contient l'état de l'ensemble du monde, exécute les différentes commandes émises par les joueurs, fait fonctionner l'intelligence artificielle (IA) des ennemis et des personnages non joueur, ...
• le client est la partie qui fonctionne chez chacun des joueurs, elle représente en 2D le monde qui entoure le personnage du joueur, son état (caractéristiques, inventaire, équipement) et qui permet au joueur d'envoyer des commandes du serveur.

Le serveur fonctionne en temps réel, à savoir que les différents personnages et le monde évoluent de façon régulière au cours du temps (par opposition au système de jeu tour par tour).

Au niveau technique, la technologie Java est utilisée aussi bien pour implémenter le serveur que le client. Les 2 types de modules dialoguent via une connexion TCP/IP.

Les commentaires, constructifs ou non, sont évidemment les bienvenus.

dstar

[divxdede]

Le premier M de MMORPG a quelle ampleur dans ton concept ?
Combien de joueurs en ligne ? Y a t'il un découpage en serveur / parties , etc... ?

Sinon, d'un point de vue technique, ta communication Client / Serveur se fait avec nio ou io ? tu utilises une bibliothèque particulière (genre Mina) ?

En tout cas, bonne chance à toi car ce n'est pas une mince affaire.

[dstar]

Le premier M de MMORPG a quelle ampleur dans ton concept ?
Combien de joueurs en ligne ? Y a t'il un découpage en serveur / parties , etc... ?

Sinon, d'un point de vue technique, ta communication Client / Serveur se fait avec nio ou io ? tu utilises une bibliothèque particulière (genre Mina) ?

En tout cas, bonne chance à toi car ce n'est pas une mince affaire.

Bonjour et merci pour ton intérêt pour ce projet.

En terme d'audience, j'avoue que je m'estimerai satisfait si un jour j'avais au moins 100 joueurs connectés simultanément sur mon serveur
Plus sérieusement, j'espère que le serveur pourra gérer au moins 500 joueurs connectés en simultané.

J'avoue ne pas trop comprendre ta question sur le découpage en serveur / partie... il n'y a qu'un seul serveur (coupé en 2, c'est vrai, mais j'en parlerai dans de futurs posts) et l'ensemble des personnages représentant les joueurs évoluent dans le même monde, et ont donc la capacité d'intéragir.

Concernant la gestion réseau côté serveur, après avoir commencé par développé un serveur de type bloquant (une thread différente pour gérer chaque connexion avec les clients), j'ai décidé de changer mon fusil d'épaule et d'implémenter un serveur non bloquant (une seule thread pour gérer l'ensemble des connexions clientes). Ceci se fait en Java en utilisant un Selector que l'on trouve effectivement dans le package standard java.nio.

Je ne connais pas la bibliothèque Mina, je n'utilise que les bibliothèques standard du Java 1.4.2, aussi bien pour implémenter le client que le serveur.

Je te remercie pour tes encouragements,
dstar

[nicØB]

Salut,

Ayant moi aussi fait un serveur en Java, je peux te dire que Mina est génial pour la partie I/O. Mine de rien, ça demande beaucoup de travail, et c'est pratique d'avoir une couche aussi important maintenue par quelqu'un d'autre.

Bon courage pour la suite.

[dstar]

Bonjour nicOb,

J'avoue que je ne connaissais pas du tout ce framework réseau de chez Apache. Je suis allé voir et, en effet, ça n'a pas l'air mal du tout.Si j'avais su ça plus tôt, j'aurais sans doute testé pour vérifier si ça faisait l'affaire.

Maintenant, ma couche réseau est bien en place et fonctionne parfaitement, je n'ai donc pas de raison d'aller la modifier, je préfère me concentrer sur ma tâche du moment: l'IA des ennemis, et je commence à obtenir des résultats intéressants de ce côté.

En tout cas, merci pour le renseignement,
dstar

[dstar]

Bonjour,

Voici quelques nouvelles concernant l'avancement de Tusteria Tales, MMORPG qui n'a toujours pas changé de nom.

L'IA des ennemis est maintenant implémentée. Elle a été testée avec différents types de créatures. Elle intègre un certain nombre de comportements de base pour les ennemis lorsque ceux-ci ne détectent pas d'opposants (tour de garde, standby, déplacement hasardeux) ainsi que d'autres comportements lorsque des opposants se manifestent. Ces comportements dépendent du type d'attaque que les ennemis sont capables d'opérer (attaque au corps-à-corps ou à distance).
Les ennemis intègrent une capacité de détection d'opposants, cette capacité prenant en compte le niveau de perception pour détermnier le rayon dans lequel les ennemis peuvent détecter un opposant, et les obstacles du terrain (un ennemi ne peut pas détecter un personnage caché derrière un mur).
Les ennemis qui détectent un personnage ont également la possibilité d'alerter d'autres ennemis qui se trouvent proche d'eux. Ceci permet des réactions de groupe. Enfin, un ennemi qui se fait tirer dessus par un personnage qui n'est pas dans son rayon de détection n'attend pas bêtement de se faire tuer sans réagir. Il se dirige vers sa cible pour essayer de la détecter.
Il y a quelques autres fonctions sur lesquelles je passe rapidement: fuite lorsque le niveau de vie atteint un seuil dépendant de la caractéristique en volonté de l'ennemi, recul lorsqu'un ennemi est trop proche de sa cible pour effectuer une attaque à distance.
L'IA est extensible et il sera possible d'ajouter de nouveaux comportements au besoin. Ceci permettra d'enrichir ce système lorsque de nouveaux types de créatures seront introduits dans le jeu.

En ce moment, je m'attaque à la refonte du système d'affichage de la partie cliente. Il s'agit d'afficher l'écran de jeu en "vrai" plein écran.
Jusqu'à présent, le jeu s'affichait dans une fenêtre standard à laquelle les décorations étaient retirées (bordures, icônes, titre) et qui était ensuite agrandie de façon à avoir la même taille que l'écran. Ceci donnait l'impression d'avoir un jeu en plein écran. Malheureusement, ce système ne permettait pas de paramétrer la résolution de l'écran, celle-ci était celle de l'écran courant et pouvait être mal adaptée au jeu.
J'ai donc changé le système pour utiliser le véritable mode plein écran offert par les bibliothèques Java et qui permet de fixer la résolution. Malheureusement, ce mode est assez incompatible avec les composants graphiques standard du Java que j'utilisais auparavant, et le système de rafraichissement de l'écran est également différent. La migration vers le nouveau système plein écran est donc en cours.

La prochaine étape de développement consistera à implémenter le système de quête du jeu.

dstar

[divxdede]

Peut t'on voir des screenshots ?
La description de ton IA semble assez complète et pique mon interet ^^

[dstar]

Peut t'on voir des screenshots ?
La description de ton IA semble assez complète et pique mon interet ^^

Merci pour ton intérêt, mais malheureusement, je préfère éviter de mettre des screenshots du jeu pour le moment.
La raison est que le design graphique du jeu n'est pas vraiment commencé, pour l'instant, j'utilise des graphismes de test aseez simples que je ne juge pas attrayants. Je préfère ne rien montrer et donc éviter de faire fuir tout le monde

dstar

[Ubiquité]

Le jeu sera gratuit ? Open-Source ?
Merci

[dstar]

Bonsoir,

Le jeu sera entièrement gratuit, à savoir:
- Le client sera chargeable gratuitement,
- Le serveur sera accessible gratuitement (pas d'abonnement),
- L'ensemble des cartes, des classes, des niveaux, des compétences et des options seront disponibles à tout joueur gratuitement.

Par contre, le client comme le serveur ne sont pas open source.

dstar

[Etanne]

Par contre, le client comme le serveur ne sont pas open source.

Pourquoi le client ne sera t-il pas OpenSource ?

[dstar]

Quelques news et une petite question.

Le système graphique plein écran est maintenant fonctionnel. Le souci que j'ai eu est qu'il m'est alors impossible de faire fonctionner plusieurs clients sur ma machine, vu que le mode plein écran est exclusif (c.a.d qu'une seule application peut l'utiliser à la fois). Du coup, j'ai dû rendre le mode en fenêtre activable par option, afin de pouvoir tester les actions et les situations faisant intervenir plusieurs joueurs en même temps. Vous avez le droit de vous moquer

Avant de m'attaquer au système de quête, j'ai rajouté une commande de repos pour les joueurs. Celle-ci permet aux personnages de regagner leurs points de vie et de magie plus rapidement. Seulement, lorsque le personnage d'un joueur se repose, il ne voit plus rien: ni les décors, ni les créatures autour de lui. Il a donc toutes les chances de se faire réveiller par surprise par un ennemi qui se sera approché sans qu'il ne puisse s'en rendre compte.
J'ai également ajouté la capacité à un joueur de réveiller le personnage d'un autre joueur entrain de se reposer. On peut imaginer un groupe de joueurs entrain de se reposer mais dont l'un reste éveillé afin de monter la garde et pouvant réveiller les autres en cas de danger.
Bon, je sais, ce n'est pas grand chose, mais moi ça m'amuse bien. Et je me demandais: quelqu'un connaît-il un autre jeu où un système similaire a été implémenté ?

dstar

[Ubiquité]

Bon, je sais, ce n'est pas grand chose, mais moi ça m'amuse bien. Et je me demandais: quelqu'un connaît-il un autre jeu où un système similaire a été implémenté ?

Je connais pas, et je trouve que c'est une excellente idée.

[dstar]

Un point d'avancement avant mon départ en vacances.

Le système de gestion des quêtes est enfin fonctionnel. Ca a pris pas mal de temps, aussi bien pour l'implémentation que pour les tests.
Il est enfin possible pour un joueur d'initialiser l'instance d'une quête, de spécifier le niveau de difficulté souhaité, puis d'accepter ou de refuser les autres joueurs désirant participer à l'instance. Il est donc possible pour les autres joueurs de s'enregistrer pour participer à l'instance d'une quête initialisée par un joueur.
Un concept d'objet de quête a été également introduit. Les objets acquis par un joueur durant une quête sont labélisés "objets de quête". Ceux-ci ne sont définitivement acquis que si le joueur sort vivant de la quête (qu'elle soit réussie ou non). En cas de mort ou de déconnexion, les objets de quête acquis par le joueur sont déposés sur le sol à l'endroit de sa mort ou de sa déconnexion. Ce concept a 2 buts:

* interdire aux joueurs d'entrer dans l'instance d'une quête avec comme seul but l'acquisition d'objets, et se laisser mourir ou se déconnecter une fois ceux-ci récupérés,

* certains objets seront de quête seront indispensables pour réussir celles-ci, un personnage transportant un tel objet qui meurt ou se déconnecte en emportant un tel objet laisserait les autres joueurs participant à la quête bien désemparés.

Un screenshot de la quête de test:



L'étape suivante sera l'intégration d'une base de données pour stocker les données persistantes du jeu. Actuellement, celles-ci sont stockées dans des fichiers côté serveur. Les membres d'un autre forum m'ont convaincu de passer à une base de données afin de faciliter l'évolution des structures de données qui sont stockées.
J'ai choisi le SGBD MySQL, qui est gratuit et connu pour être stable. De plus, il existe un connecteur JDBC qui permet de s'y connecter à partir d'une application Java.

N'hésitez pas à poster des commentaires,
dstar

[dstar]

Un petit point d'avancement sur Tusteria Tales qui, ne vous en faîtes pas, n'est pas mort.

Tout d'abord, j'ai fait mis à jour de la présentation du jeu (premier post de ce sujet) afin d'essayer de mieux décrire les concepts implémentés par le jeu.

Ensuite, quelques informations sur les derniers travaux réalisés:

L'intégration de la base de données MySQL n'a pas posé de problème particulier, cette fonction est déjà en place depuis le mois de Juin dernier.

Cet été a vu l'implémentation des fonctions d'administration et de modération du serveur. Celles-ci sont activées à distance à partir d'une console d'administration (sous forme d'IHM).
Les principales fonctions disponibles:

• Vision de la configuration du serveur,
• Accès aux logs,
• Arrêt du serveur,
• Programmation d'un arrêt différé du serveur,
• Fonctions relatives à l'activation et désactivation des personnages joueurs,
• Accès et modifications des données d'enregistrement des joueurs (email, mot de passe, date de création, nombre de connexions),
• Vision et fonctions relatives aux joueurs connectés (déconnexion, suivi à travers la fonction de supervision),
• Liste noire d'adresses IP,
• Supervision: vue en temps réel de n'importe carte du jeu, capacité de suivre les déplacements d'un joueur.

Il manque encore la possibilité d'enregistrer les dialogues de certains joueurs, et la capacité d'un modérateur de dialoguer en temps réel avec les joueurs.

En ce moment, les travaux se focalisent sur les fonctions de dialogue en temps réel entre joueurs (le chat).

N'hésitez pas à faire part de vos commentaires,

dstar

[nouknouk]

Très intéressant de voir un projet qui se concrétise. Il y a d'innombrables "grandes idées" de "grands projets" style MMORPG qui sont postées sur ce forum. Au final, quasiment aucun projet n'aboutit.

Toi tu avances petit à petit, étape par étape.
Et le résultat est là. Félicitations

Parsonellement, j'aurais juste une petite question d'ordre technique à propos de la notion de 'quêtes'. Un exemple précis:

Imaginons une quête "trouve la coffre rempli d'or".
* le joueur arrive dans un premier temps jusqu'à un PNJ qui lui dira "j'ai soif".
* Le joueur partira à la recherche d'eau.
* Une fois l'eau récupérée, si le joueur la ramène au PNJ, celui-ci le remerciera puis lui donnera la clef du coffre.

C'est un exemple à la c.. mais c'est pour illustrer ma question: les événements que tu gères pour le PNJ (if [joueur a eau] then [donner clef] else [dire 'j'ai besoin d'eau']) ne font pas partie à proprement parler du code du serveur et du client, mais sont plutôt des 'données' propres à la quête.

Si tu as effectivement ce genre d'éléments scriptables, comment as-tu géré cette partie, côté serveur comme côté client ?

PS question subsidiaire: pourquoi n'as-tu pas encore mis de version 'alpha' en ligne ?
AMHA, cela te permettrait de susciter d'autant plus d'intérêt pour ton projet, et surtout d'avoir de nombreux retours sur les bugs éventuels.

[dstar]

Très intéressant de voir un projet qui se concrétise. Il y a d'innombrables "grandes idées" de "grands projets" style MMORPG qui sont postées sur ce forum. Au final, quasiment aucun projet n'aboutit.

Toi tu avances petit à petit, étape par étape.
Et le résultat est là. Félicitations

Merci pour tes encouragements !

Parsonellement, j'aurais juste une petite question d'ordre technique à propos de la notion de 'quêtes'. Un exemple précis:

Imaginons une quête "trouve la coffre rempli d'or".
* le joueur arrive dans un premier temps jusqu'à un PNJ qui lui dira "j'ai soif".
* Le joueur partira à la recherche d'eau.
* Une fois l'eau récupérée, si le joueur la ramène au PNJ, celui-ci le remerciera puis lui donnera la clef du coffre.

C'est un exemple à la c.. mais c'est pour illustrer ma question: les événements que tu gères pour le PNJ (if [joueur a eau] then [donner clef] else [dire 'j'ai besoin d'eau']) ne font pas partie à proprement parler du code du serveur et du client, mais sont plutôt des 'données' propres à la quête.

Si tu as effectivement ce genre d'éléments scriptables, comment as-tu géré cette partie, côté serveur comme côté client ?

C'est une question très technique, car, en gros, tu me demandes de décrire l'architecture du serveur et du client.

Pour résumer, le serveur peut être vu comme un gros framework qui implémente un comportement de base. Celui-ci est ensuite enrichi par un certain nombre d'éléments qui implémentent les particularités du jeu: commandes client, actions atomiques du serveur, commandes d'administration, gestionnaires de cartes et gestionnaires de quête.
Pour les personnages non joueurs, il y a aussi un petit framework pour gérer leurs intéractions avec les joueurs: les dialogues "statiques" sont décrits dans des fichiers de configuration du serveur, et il est possible, via ses mêmes fichiers de configuration, d'associer du code (classes Java) à certaines parties des dialogues pour obtenir des dialogues plus dynamiques.

Le client implémente un peu le même type de principes, les icônes d'action que peut faire le joueur sont affichés dépendamment de l'élément avec lequel il intéragit, de ses compétances et de son équipement. Tout ceci est décrit dans des fichiers de configuration également. Il est donc facile de rajouter de nouvelles actions selon les besoins des quêtes.

Ensuite, le protocole qui lie les 2 éléments est assez générique. Il transporte les commandes du client vers le serveur de façon transparente (sans qu'il n'y ait besoin de l'enrichir à chaque nouvelle commande), et les réponses à ces commandes de la même façon. Le serveur a également la possibilité d'émettre des notifications vers un client.

Je n'en suis pas sûr, mais j'espère que ça répond à ta question.

PS question subsidiaire: pourquoi n'as-tu pas encore mis de version 'alpha' en ligne ?
AMHA, cela te permettrait de susciter d'autant plus d'intérêt pour ton projet, et surtout d'avoir de nombreux retours sur les bugs éventuels.

Il y a 2 raisons à celà: tout d'abord, je n'ai pour l'instant pas défini de contenu qui puisse susciter l'intérêt des joueurs, pour l'instant, le jeu se passe sur des cartes de test qui offrent peu d'intérêt en terme de jouabilité.
La seconde est que pour l'instant, je n'ai pas de solution pour héberger le serveur.

Merci pour tes remarques et questions,
dstar

[dstar]

Bonjour,

Je réfléchis au problème qui a été posé vis-à-vis du système de quête, et je viens proposer une solution, j'aimerais avoir votre avis.

Le problème: pour pouvoir participer à un certain nombre de quêtes, les joueurs doivent se regrouper, car il y a un nombre minimum de joueurs requis pour chacune des quêtes. De plus, selon le niveau de difficulté choisi, seuls les joueurs possédant un personnage avec un niveau d'expérience compatible peuvent participer.
D'où le problème: que faire si il est difficile de trouver d'autres joueurs pour participer à une quête donnée.

La solution proposée: un système de bots. Les joueurs peuvent créer plusieurs personnages, et laisser contrôler certains d'entre eux par un programme bot paramétrable. Ces personnages seront liés au personnage principal du joueur. Ces personnages bots suivraient les déplacements du personnage principal, et pourraient attaquer automatiquement les ennemis lorsque ceux-ci s'approcheraient. Le joueur pourrait donner des ordres à ses bots via son personnage principal en leur en envoyant des messages privés.
Il est à noter qu'un personnage n'est pas lié éternellement à un bot, et que c'est au joueur, lorsqu'il se connecte, de décider si tel personnage est contrôlé par le système de bot, ou si il est contrôlé directement par lui-même.

Qu'en pensez-vous ?

dstar

[dstar]

Un point d'avancement sur Tusteria Tales avant la nouvelle année.

Les dernières réalisations:

Le système de dialogue en temps réel entre les différents personnages joueurs est en place. Il est possible aux joueurs de dialoguer selon 2 modes.
En mode publique, tous les personnages joueurs qui sont à portée de voix entendent le personnage qui parle. Ce mode possède un défaut: les joueurs situés derrière un mur entendent comme si le mur n'existait pas.
En mode privé, 2 personnages joueurs peuvent dialoguer sans que les autres ne les entendent. Ceci n'est possible que si les 2 personnages sont proches l'un de l'autre.
De plus, il est impossible à un personnage entrain de se reposer de parler ou d'écouter.

Une première version du système de BOT est en place. Celui-ci permet à un personnage joueur d'être contrôlé automatiquement par un programme. Celui-ci agit selon un personnage principal qui lui, est contrôlé par un joueur.
Par défaut, le BOT suit le déplacement du personnage principal. Il est possible de lui envoyer des ordres via le système de dialogue privé. Les ordres disponibles concernent l'obtention de l'état du personnage contrôlé par le BOT (contenu de l'inventaire, objets équipés, points de vie et de magie), gestion des objets (déposer, ramasser, équiper, retirer), repos, surplace, déplacement, échange d'objets avec le personnage principal, enregistrement à une quête.
Il manque encore tout ce qui concerne les combats (pour le moment, le BOT se laisse bêtement tuer par le premier ennemi venu).


Les travaux en cours:

Les travaux en cours concernent le support du multi-langue pour les joueurs. Le jeu est en anglais à la base. Le système multi-langue permettra au joueur de choisir sa langue. En plus de l'anglais, une version en français est en cours d'élaboration.


Le futur:

Pas mal de petits systèmes doivent être ajoutés.
L'année 2009 devrait voir l'apparition d'un site web dédié au jeu (environ à la mi-année). Celui-ci donnera accès à l'avancement du jeu. Il décrira également les règles et traitera de son contenu.
Enfin, une version alpha ou beta sera en ligne (croisons les doigts) pour l'automne 2009.

En vous souhaitant, par avance, une bonne année 2009,
dstar

[dstar]

Et bien non, le projet n'est pas mort. Il a même avancé pendant cette longue période de silence qui prend fin aujourd'hui.
Certes, il n'a pas atteint le point qui avait été prévu initialement pour la date d'aujourd'hui: aucun site web n'a été mis en place, et aucune session de test publique n'a eu lieu. Quelques longues périodes d'inactivité et un temps disponible moindre par rapport à l'année dernière expliquent en partie ce retard. Une certaine sous-estimation de la charge de travail nécessaire à obtenir une version de test montrable complète cette explication.
La session de test ne sera sans doute pas lancée avant 2010 selon mes dernières estimations.

Les news

Le périmètre de la version de démonstration

Les éléments présents dans la version de démonstration sont à présent à peu près définis.

On débutera et visitera le village de Milegreen et ses alentours.
4 quêtes seront disponibles:
- Les caves du roi Fedmore
- La chasse au loup blanc
- La défense du village de Stonehaven
- La prison de Pristal

Les personnages joueurs pourront évoluer jusqu'au niveau d'expérience de niveau 8 (sur un total de 32 disponibles dans la version finale). Au moins 2 des 3 classes de base pourront être jouées: le combattant et le forestier. La troisième (le lettré) sera peut-être disponible, mais ceci est soumis à la condition que son d'arbre d'évolution soit défini en temps et en heure (pas évident, c'est l'arbre le plus complexe à élaborer parmi les 3 classes).
L'ensemble des compétences pouvant être acquises par les personnages de niveau 8 et les différents objets nécessaires à l'utilisation de ces compétences seront disponibles.


Avancées en terme de game design

L'arbre d'évolution des combattants est entièrement défini. Celui des forestiers en est aux 3/4. Celui des lettrés est à peine débuté.

Les compétences relatives aux combattants sont toutes définies. Celles pour les forestiers sont en bonne voie. Certaines relatives aux lettrés ont également été définies. Il en existe aujourd'hui une soixantaine, elles concernent essentiellement les points suivants:
- l'utilisation d'armes variées et autres compétences de combat,
- l'utilisation des armures et de différentes protections,
- l'utilisation de langages particuliers,
- les compétences relatives aux soins et à la résistance physique,
- la détection et la désactivation de pièges,
- tout un ensemble de compétences liées à la magie.

En terme de quêtes, une vingtaine sont définies, leur description sont plus ou moins avancées. La plupart seront disponibles avec plusieurs niveaux de difficultés.

Les règles régissant les blessures causées par le feu et le poison sont maintenant décrites, en plus de celles causées par les armes physiques. Les règles relatives aux coups assommants, précis et puissants sont également disponibles.


Avancées en terme de développement

Beaucoup de nouveaux éléments ont été développés depuis ma dernière interventions. La gestion des décors a été revue, ceci afin de prendre en compte des décors de taille plus grande que prévu dans le moteur de jeu, cette gestion permet de clarifier quels décors sont susceptibles d'interagir avec les personnages joueurs, et quels types d'interactions sont possibles.

Un certain nombre de compétences sont fonctionnelles:
- utilisation d'armes pour le corps-à-corps,
- utilisation d'un bouclier,
- utilisation de kits de soin,
- la gestion des coups assommants et précis,
- l'esquive,
- l'utilisation d'armures...

La capacité des ennemis à transporter un objet qu'ils laissent tomber sur le sol lorsqu'ils meurent est implémentée.

La gestion de l'empoisonnement est en place.

L'éditeur de carte a été amélioré afin de prendre en compte la nouvelle gestion des décors et afin d'être capable d'éditer des cartes de grande taille.

Enfin, les 2/3 de la première quête sont fonctionnelles. Ceci a permis de corriger de nombreux bugs relatifs à la gestion des quêtes et des ennemis.
Le fonctionnement de l'IA des ennemis est maintenant stable, il a permis de vérifier sa capacité à gérer le comportement des ennemis de façon cohérente et contrôlable dynamiquement par les gestionnaires de quête. Il est donc possible d'affecter des comportements par défaut, et de les modifier en temps réel selon la situation.


Les travaux suivants et en cours

L'achèvement de la première quête est la priorité.
Elle sera suivie de la mise en place des éléments manquants nécessaires à la version de démonstration: les 3 autres quêtes, les compétences manquantes pour les 8 premiers niveaux d'expérience, les objets, le village de Milegreen et ses alentours.

Il est très difficile pour l'instant d'évaluer le temps nécessaire à l'aboutissement de ces travaux, et donc impossible de déterminer une date pour la disponibilité de la version de test.

Comme d'habitude, n'hésitez pas à faire état de vos commentaires et de vos questions.

dstar