Discussion :

[quentinh]

J'avais dit que je serai de retour dans moins de 2 mois, donc me revoilà avec une nouvelle version estampillée 0.2.svn61.

Au programme, un nouveau gestionnaire d'images plus rapide (l'ancien fonctionnait bien donc le changement n'est pas bien visible en jouant...), la possibilité pour les ennemis d'avoir un inventaire laissé sur le sol lorsqu'ils meurent (pour le moment, certains monstres peuvent lâcher des potions de soin), et une nouvelle gestion de l'énergie (qui avant ne servait pas à grand chose).

Le personnage perd de l'énergie lorsqu'il se bat ou lorsqu'il se blesse, mais aussi lorsqu'il se régénère. L'énergie doit être récupérée en se reposant, mais on ne peut se reposer que dans un camp ou un refuge bien évidemment...
Le personnage perd également de l'énergie lorsqu'il ne s'est pas reposé depuis un certain temps. En d'autres termes, l'énergie telle que je l'ai définie est l'opposé de la "fatigue".

Encore quelques ajustements pour la prochaine version, et l'ajout d'objets plus intéressants que les monstres vont pouvoir nous donner. Je vais finir un jour ou l'autre par ajouter des musiques aussi...

Code source
Compilé pour Windows

[Darkyl]

Salut,

J'ai téléchargé ton jeu et l'ai essayé un petit moment, il marche bien. Vraiment bravo.

C'est cool de voir un projet en bonne fois.

Je vais faire le tatillon : le principal avantage d'un RPG sont les phases de combats. Travailel les bien, rends les le plus interactif possible. Je pense qu'avant de continuer dans le codage en dur de ton jeu (les mondes, les persos, l'histoire, les objets etc), tu devrais amélioré cela le plus possible (pas qu'un boutton pour taper bref)...

Mais, à part cela, bon courage et encore bravo

[quentinh]

Merci pour le conseil, j'en prend bonne note ^^ C'est un peu le "gros morceau" qu'il me reste, mais une petite partie est déjà faite via les balistes qui peuvent tirer des javelots sur les monstres. Il faut que je généralise ça pour que le personnage et les monstres puissent eux aussi tirer des projectiles.

Mais c'est vrai que ça peut-être intéressant aussi d'avoir des phases de combat rapproché à plusieurs touches... Je n'y avait pas pensé, c'est une piste de réflexion intéressante...

[Darkyl]

Re,

Rendre un combat interactif :
- Fais une sorte de sélection de la cible, puis les coups, sorts et actions seront portés vers la cible (le héros se dirige tout seul vers la cible, ou se tourne tout seul vers elle).(bouton qui sélectionne le plus proche ennemi)
- s'il le joueur se fait attaquer par plusieurs monstres en même temps, il peut en téléporter un pas loin, le temps de taper l'autre...
- Moi je verrai des sorts de magie (car cela renforce le côté stratégie) avec vol de la santé des monstres, boucliers magiques etc...
- Bref un peu un combat à la action-RPG... La vue que tu propose est super bien pour cela.

Enfin, tout cela est facile à dire, moins à implémenter.

Dommage que je ne connaisse pas le c++, je t'aurais bien aidé

Comme le combat à mon avis est très important, tu peux demander des idées aux forumeurs,peut-être...

[Dabou Master]

Bonjour,

Ben Darkyl toi en fait tu vois l'évolution du jeu vers un pseudo "hack & slash" à ce que je vois (je dis pseudo parce que le "ciblage" n'existe pas logiquement dans ce cas là). Oui pour étoffer à partir de maintenant il s'agit juste de soit se lancer vers une progression de personnage très étudiée et des règles à la dungeons & dragons pour se retrouver vers un RPG très classique ou alors se lancer dans une progression bien moins complexe avec tout un tas de sorts/techniques et une jouabilité aussi dynamique que possible pour tendre cette fois vers le hack & slash.

L'intérêt de ce que tu as fait, quentinh, c'est que tu peux visiblement choisir maintenant le style vers lequel tu vas tendre à partir de maintenant. Après je dis ça mais je ne suis pas bien sûr non plus, j'ai suivi la progression de ce projet un peu tardivement (enfin j'ai tout lu depuis le début) et je ne suis pas sûr d'avoir tout bien compris, je suis po concepteur de jeu moi ^^.
En tout cas bravo quand même (j'en profite que j'aie un commentaire à faire pour te le dire) parce que t'as quand même sacrément bossé depuis le début pour en arriver là, félicitations !

[quentinh]

Merci pour tous ces compliments, je suis flatté ^^

En fait je ne sais pas vraiment vers quel style je tends, ma méthode c'est plutôt de faire ce qui me plaît et ensuite d'essayer de caser ça dans la bonne catégorie… (En plus j'y connais pas grand chose à tous ces genres de jeux…)

Le principal problème que j'ai est que j'utilise pour le personnage des images de Reiner's Tileset, et je n'ai donc pas d'autre set d'images où le personnage lancerait des sorts ou attaquerait différemment…
Cela m'empêche aussi de changer l'apparence du personnage lorsqu'il change d'équipement. Il faut que je trouve une solution à tout ça, sachant que je ne suis pas vraiment expert ès Blender…

J'en profite pour publier une petite révision (0.2.svn63) dans laquelle j'ai refait tous les menus et corrigé plusieurs bogues, et tout ça avec un code plus joli…
Les sauvegardes de la révision précédente sont toujours compatibles.

→ Code source
→ Compilé pour Windows

[Darkyl]

Pour l'apparence du hero, tu t'en fiche, ne la change pas pour l'instant (même quand on change son équipement).

Par contre, trouvais des images de sorts, d'armes etc, ça oui. Tu peux peut-être trouver des sprites sur le net (ton jeu est en 2d classique, il y a plein de sprites dispo, moi je fais un jeu en 3d iso et je galère à trouver des images).

Si les images que tu trouves ne respectent pas la charte graphique, tu t'en fiche. A mon avis, quand tu auras un peu plus avancé le code, tu devrais intéresser un infographiste en deux deux...

Je crois que je vais me mettre au c++ (pour te filer un coup de main)

Sinon, tu compte faire des quêtes ?
Tu vas faire une mini map?

Perso, je trouve qu'un action rpg (fàçon fable) en 2d serait géniale. Si la fluidité est au rendez-vous et que tu peux éviter les coups en sautant, plongeant , paradant, jeter un sort,... bref tu l'auras compris, un jeu où l'action est rapide (mais c'est mon point de vue).

Et une idée saugraunue: utiliser le décors? genre, déplacer un rocher par la magie et le faire attérir sur le monstre, utiliser un buisson comme bouclier...
Je ne parle pas du taf de programmation derrière, qui je sais (en tant que programmeur amateur) peut-être vite énorme pour toute fonctionnalité...

[quentinh]

Ce n'est pas le codage qui me pose problème, pour ça j'ai plus vraiment de soucis, j'ai déjà assez codé il me semble pour ne plus avoir trop de problèmes à ce niveau ^^ C'est surtout la conception le problème, et là ça devient plus ardu…

Au niveau des quêtes, il y en a déjà quelques-unes quand même, et mon système de quêtes marche plutôt pas trop mal, même si il n'est pas facile à utiliser… pour ça, le problème est encore ailleurs : c'est qu'il faut dessiner les cartes, adapter les caractéristiques des monstres, écrire les fichiers qui données qui définissent les quêtes, etc… en plus d'avoir de bonnes idées de quêtes ^^

J'ai programmé un éditeur de cartes il y a un certain temps, mais il est un peu médiocre, très mal codé et pas à jour, donc il ne sait pas faire les nouvelles choses que j'ai ajoutées depuis… Si jamais tu veux te faire les dents dessus, je te laisse volontiers ^^

Pour ce qui est de la mini-carte, c'est une idée qui est déjà dans les cartons, mais un peu loin, parce que au niveau Conception, j'ai pas encore eu l'idée de génie qui fera que ça marche bien…
Et pour ton « idée saugrenue », tu as été devancé par un certain Nyarlatotep qui voulait qu'on puisse déplacer les balistes ^^

Pour les images : ça m'embête un peu de ne pas avoir un truc bien propre pour celui qui joue, parce que les meilleures améliorations qu'on peut faire sont celles proposées par les joueurs eux-mêmes, mais il faut déjà qu'il y ait des joueurs qui apprécient le jeu ! C'est pour ça que j'ai préféré commencer par un truc jouable et agréable à jouer, avec de moindres fonctionnalités, plutôt que d'avoir un super-moteur qui sait tout faire mais sans rien derrière pour pouvoir l'utiliser.
Mais c'est vrai que pour le moment, on peut changer l'équipement du perso sans que cela soit visible sur le perso lui-même…

Après, mon « problème graphique » c'est tout ce qui est du niveau de l'animation sur la carte ; toutes les images « non mouvantes » comme celles qui représentent les objets dans l'équipement ou les décors, je les dessine moi-même quand j'en ai besoin, et j'en ai d'ailleurs en réserve que j'ai pas encore utilisé ^^ Je parlais dans un post précédent de nouveaux objets que j'allais intégrer, ils sont presques prêts ! (entre autres : on pourra récupérer la masse d'armes et le bouclier que portent les orques)

L'idée de départ du jeu était effectivement de pouvoir faire des combats « en live » et non pas au tour par tour ou avec des cases (en général je n'aime pas trop ces jeux-là…) donc pour ce qui est de sauter, esquiver, etc… bien sûr que cela m'intéresse mais cela me paraît quand même très bizarre de le faire sans images adéquates…

[Darkyl]

Concernant la map, tu la génère pas déjà avec un éditeur de carte? Elle est crée en dur? Si tu as déjà défini un type d'encodage de carte, il n'y a plus qu'a mettre à jour ton éditeur. D'ailleurs, oui cela m'intéresserai de me faire les dents dessus , mais tu code avec quel EDI c++ ? Il faudra que je l'ai et que j'ai ton éditeur de carte...

Par contre, je te promet rien en terme timing car à mon avis, même si je connais pas mal de langages dont les langages procédurié et objets, il va me falloir un petit temps avant de comprendre le c++, ton éditeur et arrivé à y bosser dessus... D'autant que j'ai des projets en cours mais cela m'intéresse grandement.

Moi, quand je programme, je défini direct les types (ou class) avec leurs caractéristiques (le max dont j'aurais besoins une fois le jeu fini): c-a-d par exemple, le type monstre avec toutes ces capacités différentes, le types perso avec toutes ces capacités diff puis je crée des objet (var) unique pour chaque monstres, perso, qui adaptent ce type à sa spécification.

Les fonctions qui gèrent ces spécifications gèrent le type générale donc pas de soucis pour les cas particuliers. Enfin, je sais pas si je suis clair mais je pense que tu fais déjà comme cela.

Donc, je comprend pas tes remarques sur les quêtes, les monstres...

Pour la mini carte, je sais pas trop, cela dépend de l'encodage de ta map, mais moi généralement, ma map est en case par case, donc la mini map aussi et elle est crée à la volée, en lisant le tableau_map [x,y]...

Mais, pareil, je comprend pas trop...

Pour les images, là je comprend la frustration de coder une fonctionnalité qui ne sera pas visible à l'écran ou alors pas avec les bonnes images:
- re : post un recrutement pour un graphiste...

Ceci étant dit, il faut que tu intéresses des graphistes et/(ou pas) programmeurs c++, donc un max de fonctionnalité même sans images ou avec images non conformes, tant qu'on se rend compte de l'action, montre l'étendu des possibilités de ton moteur de gameplay et graphique, donc n'essaye pas d'intéresser les joueurs mais plutôt les informaticiens (au sens large). A mon avis.

[quentinh]

Ma façon de programmer, c'est de n'inclure absolument aucune donnée dans le code, mais d'utiliser des fichiers de données. Toutes les cartes, quêtes, monstres, objets, etc… sont dans des fichiers de données. Le programme en lui-même ne fait que lire des fichiers de données qui lui disent de charger d'autres données etc… afin de reconstituer tout. Ainsi on peut ajouter des monstres, des quêtes, des objets et dessiner de nouvelles cartes sans rien changer au code (sauf si les objets doivent avoir des fonctionnalités que le programme ne connaît pas encore, évidemment, dans quel cas il faut coder le comportement à avoir).

Je vais essayer d'expliquer comment mes données sont organisées : (tu peux retrouver cet agencement dans le dossier 'data')
→ carte : les cartes ne sont qu'une série d'éléments avec leur type et leur position initiale. Plus, pour les éléments un peu spéciaux, comme les coffres ou leur éléments qui permettent d'afficher le fait qu'on entre dans une nouvelle zone, etc…, leur définition. Chez moi, la carte n'est donc pas un tableau avec à chaque case un élément, mais une liste d'éléments ! Ceci permet de ne pas avoir un horrible jeu à cases, mais forcément ça complique et ça ralentit la gestion… en offrant tout un tas de nouvelles possibilités !
→ chapitre : petit fichier texte qui décrit les cartes et les missions à charger au début de chaque "grosse partie" du jeu
→ img : toutes les images
→ individu : il y a deux types d'individus, ceux qui sont uniques comme le personnage ou les PNJ ou le démon Stolas (pour ceux qui sont allés jusque là dans le jeu), et ceux qui font partie d'une classe et ont donc tous les mêmes caractéristiques. Il y a donc un fichier pour chaque individu unique, et un fichier pour chaque classe d'individus que j'appelle "communs". En plus des individus, il y a un fichier pour chaque élément sur la carte (buissons etc)
→ mission : contient toute la trame du scénario, par missions très élémentaires, une mission par fichier.
→ objet : chaque type d'objet a un fichier associé.

Typement, ce qui se passe pendant le chargement d'un nouveau jeu :
→ Le programme sait qu'il doit interpréter le fichier de chapitre 1.chp
→ Celui-ci contient la liste des cartes à charger, le programme va les chercher.
→ Le fichier carte que le programme a ouvert contient la liste des éléments. Le programme va aller ouvrir le fichier correspondant dans le dossier individu pour chacun de ces éléments (mais une seule suffit pour les éléments communs et les décors !).
→ Cet individu a des objets dans son inventaire, il faut aller les charger. Il a aussi des images qu'il faut également aller charger. Au passage, le fichier décrit ses caractéristiques et ses comportements.
→ Tous les éléments de toutes les cartes sont chargés, il reste dans le fichier de chapitre, les missions !
→ Les missions sont des missions « élémentaires » dans le sens où elle ont pour but une unique petite chose, par exemple « entrer en collision avec un élément qui porte le numéro XXX ». Par contre les missions ont plusieurs "fins" c'est-à-dire une liste des choses à faire lorsque la mission a été remplie :
→ Charger la mission suivante
→ Charger telle carte en plus, supprimer telle autre
→ Afficher tel texte à l'écran
→ …

Mon éditeur de carte ne fait que les fichiers cartes. Tout le reste je l'écris à la main dans des fichiers textes. C'est vrai, il suffit de le mettre à jour, mais les éléments que l'éditeur ne gère pas (encore), ce sont ces éléments un peu spéciaux comme les coffres etc… et avec mon code super-crade ça donne pas envie d'implémenter.
Je peux te donner ce que j'ai fait pour l'éditeur si tu veux, mais je te préviens que j'ai codé ça vraiment très mal (je regrette un peu de n'y avoir pas passé plus de temps). C'est peut-être presque mieux de recommencer à zéro…
Perso, je code sur Anjuta, sous Fedora, mais tu peux coder avec l'EDI qu'il te plaîra, pas besoin de prendre le même que moi… (d'ailleurs si je me souviens bien, j'ai même pas créé de projet sur Anjuta pour mon éditeur, je crois que je l'ai codé avec gedit et compilé en ligne de commande…)
Par contre t'auras besoin de SFML2… pas forcément facile à installer…
En terme de timing, je m'en fiche un peu, j'avais pas vraiment l'intention de retravailler cet éditeur avant un bon bout de temps…

Et puis, mon but c'était (et c'est toujours) de m'amuser et si possible d'en faire profiter les autres. C'était pas de monter un projet informatique avec une équipe. Bien sûr je suis pas contre de l'aide, et ça devient difficile de gérer tout tout seul au fur et à mesure que le jeu grandit, mais les informaticiens sont vraiment pas ma cible prioritaire. Je fais mon propre projet pour le fun, je compte pas faire carrière dans l'informatique, j'ai pas envie de faire le projet de quelqu'un d'autre, je ne fais que m'amuser ^^ Le but premier de ce fil de discussion c'était de faire partager mon expérience et de trouver quelques bons conseils, j'avais pas pour but de recruter pour faire le prochain super-jeu-vidéo ^^

[Darkyl]

Merci d'avoir pris le temps d'expliquer ta façon de coder et tes outils.

Merci aussi d'avoir été claire sur tes envies et ambitions.

Je t'avoue qu'au delà d'un projet informatique x ou y, je recherche surtout à m'investir dans un projet où une réelle volonté de travailler avec d'autres se fait sentir.

Le projet informatique et ces spécifications sont moins important que cela.
Aussi, d'aprés ce que tu me dis, (et encore merci d'être clair), ce n'est pas ce que tu recherche. j'ai besoins de projet dans un but de reconversion professionnel dans l'informatique, et donc de personnes dans la même optique que moi.

Je me suis emballé sur ton projet car il me plaît beaucoup .
Et en plus, il me permettait d'apprendre un langage que je ne connais pas bbeaucoup, à savoir le c++, mais je ne peut me permettre de prendre du temps sur un projet dont le but réel et confirmé n'est pas d'aller au bout.

Je te souhaite bien du courage, j'aime ta vision de voir les choses (tu as de la chance d'avoir le temps et les moyens de faire cela uniquement pour le plaisir) et continuerai à suivre l'évolution de ton projet de prés.

Mise à part cela, concernant ton codage, je sais pas si l'accés au fichier texte ainsi que leur lecture , prend de la ressources (en temps) mais tu peux tout à fait séparer tes données brut de ton code sans passer par des fichier texte.
Tu met tes données brut (genre map, objet, etc... les var, pas les type) dans des fichiers sources c++ (je ne connais pas le type de fichier créer par c++), mais dans un dossier à part, pour la maintenance. Je pense que l'accés à ces fichiers sources sera beaucoup plus rapide qu'un fichier texte que tu dois lire, interprété selon ta norme d'écriture etc. Mais si la performance ne te pose pas de problème, tu as raison de pas te prendre la tête.

Concernant le case par case, ce n'est pas pour rien que tous (ou l'immense majorité) des jeux font comme cela. Au niveau des calculs, cela facilite énormément les choses. Le fait de ne pas vouloir de case par case pour un point de vue graphique n'est limité que par ......le graphisme. Rien ne t'empèche d'avoir plein d'images différentes pour un même type de texture (par ex herbe) et d'avoir des textures qui fassent plus d'une case sur une case. Comme cela, tu ne verras pas le case par case.

Apprendre à gérer un moteur graphique en case par case , au niveau ressource, optimisation, astuce graphique, etc, est une trés bonne chose.

Mais tu as raison de vouloir t'amuser, c'est l'objectif principal d'un codeur amateur.

Pour les sprites, difficile d'intéresser un graphiste si ton projet n'a aucun but réel et difficile d'avancer ton projet sans sprite, je vois le serpent qui se mord la queue là

En tout cas, bon courage pour ton projet, et merci d'avoir pris le temps de répondre.

[quentinh]

Même si je n'ai pas envie de me prendre la tête, je compte bien continuer le projet ^^ Je l'ai commencé il y a déjà plus de deux ans, je vais pas abandonner du jour au lendemain ^^

En fait, si ma méthode c'est de faire ça pour le fun, c'est surtout que mes études me prennent trop de temps pour qu'il me soit possible de planifier quoi que ce soit dans ce projet. C'est pour ça que je ne peux pas vraiment chercher à faire une équipe, parce qu'il me serait impossible de planifier. Je mène ce projet dans mon temps libre, donc je peux le laisser 2 mois sans y toucher parce que je suis trop pris puis coder énormément pendant 2 semaines parce que mon emploi du temps est plus léger.
C'est pour ça que je ne vise pas les informaticiens ; une équipe mal menée c'est synonyme de projet abandonné.
Tout au moins pour une équipe de codeurs ; au niveau des données, de la musique, mais aussi d'un éditeur de carte ou de tout autre programme «annexe», il me semble qu'il y a moins besoin de cohésion que dans une équipe de codeurs, car chacun peut faire son truc dans son coin sans dépendre des autres. C'est ça que je veux absolument garder dans mon projet, sinon c'est la fin. Il n'y a pas à chercher loin pour en voir des exemples.

Du coup, je comprends bien ton point de vue ; c'est sûr que mon projet n'est pas l'idéal pour apprendre le travail en équipe. Mais si tu veux tenter le coup ou que tu ne trouves pas de projet plus intéressant et plus instructif pour toi, il y a toujours des choses à faire ici ^^ Et l'éditeur, je t'assure, n'est pas une mince affaire ^^ (Surtout qu'il faut déjà comprendre comment mon système de cartes fonctionne, et c'est pas très simple…)

Concernant les données, je crois que c'est beaucoup plus intéressant de les séparer du programme. Si on les mettait dans des fichiers sources c++, les données seraient compilées dans le programme. Plus possible de les modifier. Impossible d'ajouter de nouvelles choses sans tout recompiler. C'est sûr ce serait un peu plus rapide ; mais c'est aussi beaucoup moins flexible (et puis les sauvegardes, elles, sont obligatoirement dans des fichiers de données…). Enfin, ça dépend certainement aussi du projet, mais je ne connaît pas beaucoup de jeux pour lesquels les données sont compilées avec le programme… même si c'est tout à fait faisable (mais très lourd !).

Pour le case par case, je ne suis pas si certain que cela que cela soit une immense majorité… J'ai déjà fait d'autres jeux en case par case, et ça limite beaucoup de choses. Ce n'est pas seulement un point de vue graphique qui m'a fait choisir ce système, c'est que je ne vois pas vraiment comment faire un jeu fluide avec du case par case. Avec mon système, tout objet pour avoir toute position, peut se déplacer dans toutes les directions, etc… ce qui est impossible autrement. Je ne suis pas un grand fan de jeux vidéos, alors je préfère m'inspirer du réel que de la façon dont les autres font… C'est dur à coder, mais c'est pas marrant quand c'est trop facile ^^

[quentinh]

De retour de vacances, avec une nouvelle version !

Le personnage a désormais ce que j'appelle des « compétences » et qui vont permettre de lui faire faire plein de nouvelles choses… Il est désormais capable de lancer des pseudo-boules de feu (le graphisme est un peu moche mais ça marche), et ça sera assez facile par la suite d'ajouter d'autres sorts intéressants. Il y a quatre touches qui permettent d'exécuter les compétences (Ctrl Gauche, pour l'attaque, Shift Gauche pour les boules de feu, Tab pour boire une potion de soin, et Espace qui ne sert à rien pour le moment).

J'ajouterais plus tard un écran qui permet de gérer les compétences (quelle touche fait quoi, etc…)

J'ai aussi ajouté deux nouvelles quêtes facultatives et une nouvelle zone ainsi qu'une grotte (graphismes à refaire plus tard…)

J'ai aussi ajusté la gestion des stats du joueur, et pas mal d'autres petites choses…

→ Code Source
→ Compilé pour Windows

[Darkyl]

Salut,

Ha enfin des nouvelles...

Je vais m'empresser de tester ça. Content de voir que tu n'as pas abandonné.

[quentinh]

Voici la version 0.2.svn66 avec au programme, pour les points les plus importants :
- Plusieurs résolutions d'écran possibles : 800x600, 1024x768 et 1280x800 avec une réorganisation des différents éléments affichés
- Ajout d'un didacticiel qui introduit le fonctionnement du jeu ainsi que le scénario
- Inventaire augmenté à 24 cases
- Plusieurs nouveaux personnages
Beaucoup de changements et d'améliorations mineurs accompagnent ces derniers points. Entre autres, les objets générés aléatoirement le sont de façon plus «intelligente», avec des améliorations qui dépendent du type d'objet. J'ai ajouté une classe qui s'occupe de l'affichage des textes des missions, en découpant là où il faut, etc…
L'ajout du didacticiel m'a aussi fait ajouter pas mal de type de missions qui permettent de faire des petites cinématiques.
Et puis enfin, y'a un début de scénario !

Faut bien avouer que ça n'avance pas bien vite, mais je fais ce que je peux c'est promis ^^

→ Code source
→ Compilé pour Windows

[quentinh]

J'ai sorti il y a quelques jours déjà la première version de la gamme 0.3. C'est le moment pour donner quelques perspectives.

D'abord, la liste des quelques changements depuis la precédente version. Il s'agit surtout de la correction des derniers bogues que j'ai pu trouver, mais j'ai aussi ajouté une traduction complète du jeu en anglais. Et plus intéressant pour les joueurs, j'ai ajouté de nouvelles potions. Il y a désormais une potion de soin, une potion d'attaque, une potion de défense, et une potion de vitesse.

Et pour la suite ?
Je travaille actuellement sur une extension des objets qui permettra d'avoir de nouveaux effets intéressants. On aura toujours les objets «classiques» commes les épées, les boucliers, etc…, et les objets «temporaires» comme actuellement les potions. Ces objets temporaires vont pouvoir avoir une seconde utilité ; il va désormais pouvoir s'agir d'attaques ennemis (poison par exemple), et le même système que les potions peut être utilisé. Je vais essayer d'ajouter ainsi différents effets classiques comme l'empoisonnement, les brulûres, le froid, etc… et chaque effet pourra modifier les caractéristiques de la personne visée. J'ajoute également des objets qui peuvent améliorer, temporairement ou non, d'autres objets.
Par exemple, lorsqu'on tue une araignée, on peut en récupérer le venin, le déposer sur une épée, et à chaque blessure faite avec cette épée, l'ennemi est empoisonné.

Une fois ces nouveaux objets terminés, je souhaite améliorer le système des «compétences», d'abord en ajoutant de nouvelles, ensuite en créant une interface de gestion des compétences. Notamment, ces compétences pourront être améliorées pour augmenter les dégâts de l'attaque à l'épée, la vitesse de course, etc…

J'aimerais aussi qu'il soit possible au joueur de choisir le profil de son personnage. Il faudra donc décider des profils de personnage à scripter, et certainement ajouter de nouvelles choses qui vont différencier les profils, par exemple l'impossibilité pour un profil d'utiliser tel ou tel objet, la maîtrise de telle ou telle compétence, etc.

Enfin j'aimerais continuer un peu le scénario, puisque ça fait un petit moment qu'il n'y a pas eu de nouvelles cartes, de nouveaux monstres et de nouvelles quêtes.

Voilà les pistes futures du développement, qui risquent de durer pas mal de temps étant donné que je code peu ces derniers temps…

→ Version 0.3.svn67 compilée pour Windows
→Code source version 0.3.svn67