Code et documentation du projet Odyssée
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
milang 9dc2a1eb42
mettre les sprite dans le bon ordre correspondant à la direction
2 weeks ago
Code gitignore, dernière tentative 2 weeks ago
Dessins mettre les sprite dans le bon ordre correspondant à la direction 2 weeks ago
ViewImg ignorer les dossiers de compilation 2 weeks ago
.gitignore Optimisation du gitignore 2 weeks ago
README.md Mise à jour de 'README.md' 2 weeks ago

README.md

Odyssée

Odyssée est un jeu de rôle collaboratif regroupant une petite dizaine de personnes pour bâtir ce qui sera un des plus grand jeu de rôle jamais fait… Entre maps géante et gestion du gris, nous essayons de construire un jeu complet et propre.

Avant de vous lancer dans la lecture attentive de cette petite bible du projet Odyssée, quelques notes… Ce document contient la documentation nécessaire à l’élaboration de ce projet commun, il doit donc être exhaustif. D’où l’interêt de modifier ce document au fur et à mesure de nos avancées.

N’hésitez donc pas à modifier des parties entières si elles sont obsolètes ou erronées.

Merci d’avance !

Le Framapad de l’équipe sert à éditer des textes à plusieurs et en temps réel. Utile pour mener des débats autour du projet, mais aussi dans l’élaboration des articles pour la RdP.

Intrigue

Vous êtes aubergiste, comme votre père avant vous. Votre mère est morte à votre naissance et votre père vient de s’éteindre dans sa gargote à Cirtes… Sur le chemin de la capitale d’Erb-Hugoul, l’hypothèse d’une mort naturelle s’évade pour laisser place à des choses plus sombrese encore… Vous devrez remonter les indices laissés par feu votre père pour décourvrir la vérité, quitte à faire remonter des démons que tous croyaient enfouis depuis longtemps… Saurez vous déjouer les pièges que vous tendront vos ennemis invisibles ? A faire face à des êtres oubliés et pourtant jamais aussi omniprésent ? A mettre au jour une vérité niée ?

L’équipe

L’équipe doit être constitué d’un nombre réduit de personnes avec des tâches définies qui conviennent à tous le monde. Les différentes fonctions sont cumulables, mais il faut veiller à ce que chacun ait quelque chose à faire qui lui plait et que personne ne fasse tout.

Répartition de l’équipe

Il y a besoin de :

  • 1 Programmeur
  • Graphiste (pas pour l’instant)
  • Scénariste (pas pour l’instant)

Rôles des membres de l’équipe

Les programmeurs

Les programmeurs sont chargés du gitea et du code du projet, ceux-ci doivent rester à l’écoute des scénaristes et des graphistes de manière à rester dans l’esprit du jeu. Ils sont chargés de programmer le jeu et ses moteurs. Ils seront amené à coder les moteurs proposés par les scénaristes ainsi que les moteurs physiques des graphistes. Ces moteurs seront élaborés par l’équipe pour le jeu et devront s’adapter aux contraintes.

Les graphistes

Les graphistes sont à la recherches du design du jeu, avoir des objets petits, qui évoquent des choses au joueur. Ils doivent pouvoir communiquer avec les scénaristes et les programmeurs pour permettre une meilleur expérience de jeu, quitte à modifier le scénario pour que les graphismes soit le mieux possible. Il seront également en charge de faire des animations notamment lors des cinématiques du jeu, déterminées avec les scénaristes et les programmeurs. Les graphistes doivent être en mesure de se servir du git et d’être capable de modifier les sources qui touchent aux images pour avancer rapidement dans le projet. Les graphistes seront à même de concevoir le moteur de physique du jeu en théorie et de l’expliquer.

Les scénaristes

Les scénaristes doivent créer le scénario. Ils géreront également l’avancée du scénario et choisiront les points clés. Les dialogues seront élaborés par eux ainsi que les rencontres (combat, PnJ,…). Les quêtes du jeu seront planifiées par eux. Ils devront rester en contact avec les dessinateurs et les programmeurs de manière à rester dans les limites du jeu et de l’équipe.

Les membres de l’équipe

  • KikooDX ( ? )
  • Shadow15510 (Scénariste)
  • Rader (Graphiste)
  • Massena (Graphiste, Scénariste)
  • Leno (Graphiste)
  • Milang (Programmeur)

Le cahier des charges et tâches

Se trouve ici toutes les indications pour la réalisation du projet. Ce document servira donc de référence.

Les sprites

  • Taille des tiles : 8x8
  • Taille du personnage : 8x12
  • Couleurs : Monochrome (à voir pour la nuance de gris)

Le code

  • Taille maximale : ∞
  • Langage utilisé : C
  • Compatiblité : Graph 75+E (SH3, SH4), (Graph 90+E)
  • Outil : Gint

TODO list

Code

  1. Compléter les headers des sprites
  2. Faire les moteurs de jeu
  3. Commencer ou continuer le code
  4. Prendre des renseignements sur la gestion du clavier par timer et l’appliquer
  5. Architecture du code à préciser

Graphismes

  1. Faire les tiles de base du jeu
  2. Faire le personnage principal
  3. Dessiner le mobilier
  4. Faire les monstres animés
  5. Continuer les artéfacts
  6. Constituer les designs des maps
  7. Faire la carte du monde du jeu (esquisse à la main dispo dans le second dépôt archivé)
  8. Faire des PnJ (animés ou pas)
  9. Concevoir les interfaces utilisateurs et l’écran d’accueil

Scénario

  1. Faire le scénario
  2. Isoler les points-clés
  3. Revoir ou créer les dialogues
  4. Continuer à accumuler des idées diverses

Général

  1. Décider des cinématiques : endroit, actions,… etc
  2. Constituer une équipe
  3. Continuer la doc

Architecture du code

Auto-chargement du dossier de sauvegarde (sinon, nouvelle partie)
 |
 |
Lancement du jeu
  |
  +-- Ecran d'accueil (on attend une touche pressée, Si [EXIT] on quitte le jeu) 
  |
  +-+
  | |-+ timer et gestion du clavier (et si il y a un input :)
  | | |
  | | +-- Test de la map (voire interaction s'il y a)
  | | |
  | | +-- Mise à jour de la map en cas de sortie de l'écran
  | |
  | +-- Déplacement des IAs (Adversaires)
  | |
  | +-- Rafraichissement de l'écran
  | |
  | +-+ Touches spéciales
  | | |
  | | +-- Ecran statistique (quête en cours, capacité du joueur, nom, argent,…)
  | | |
  | | +-- Sortie du jeu : sauvegarde et retour à l'écran d'accueil
  | | 
  | +-- On retourne au timer
  |
  +-- Fin du jeu

La gestion du timer pour le clavier est extrêmement importante ! Elle va permettre un système de combat en temps réel proche des RpG classiques.

Gestions des maps

Le principe de ‘matrice virtuelle’

Théorie

Lorsque vous êtes dans une map, une matrice représente l’écran et affiche les éléments du décors avec cette matrice.

Lorsque vous quittez cette map, vous arrivez en toute logique dans… une autre map ! (Si si ça marche !!) Et c’est cette gestion qui m’intéresse.

Représentation

Vous avez ci-dessous une matrice qui représente toutes le maps du jeu et l’aggrandissment montre une map du jeu :

   +--Matrice de toutes les map du jeu
   |
   v
+-+-+-+-+-+   +-+-+-+-+-+-+-+
| | | | | | / | | | | | | | | <-- Matrice d'une map du jeu
+-+-+-+-+-+/  +-+-+-+-+-+-+-+
| | | | |X|   | | | | | | | |
+-+-+-+-+-+\  +-+-+-+-+-+-+-+
| | | | | | \ | | | | | | | |
+-+-+-+-+-+   +-+-+-+-+-+-+-+

La matrice qui contient toutes les map du jeu sait dans quelle map on est grâce au couple (x ; y) unique de la map en cours. Mais les cases de la matrice ne servent à rien. Donc on peut enlever la matrice et garder uniquement le couple x y pour savoir dans quelle map on est. Par un emboîtement de switch on retrouve quelle map il faut afficher.

À partir de là on remplit la matrice qui contient l’écran et on l’affiche par deux for imbriqués.

Le moteur physique du jeu

Principe

Code commenté sur un exemple

Tiles du jeu

Il existe trois type de dessins :

  • Le joueur (8x12): 8 dessins de marche normale animée (deux pour chaque direction), 4 dessins avec épée (un par direction)

  • Les éléments du décors (8x8): murs, fenêtres, portes, toits, plante, poteaux, pancarte et autres dessins qui serviront à créer les décors du jeu.

  • Les objets (8x8): petits dessins qui seront utilisés lors de récompense de combat, d’achat ou autre interaction rapportant des objets ou autre chose.

Les capacités

Du joueur

Le joueurs a trois capacités distinctes :

  • Les points de Vie
  • Les points de Force
  • Les points d’Expérience

Les points de Vie caractérisent la santé physique du joueurs ainsi, si cette capacité est à 0, le joueur perd 1 point de Force et récupère 3 points de Vie. Si il est à 0 point de Vie et 0 point de Force, il a perdu. Les points de Vie peuvent chuter à la suite d’un combat et augmenter suite à la découverte de cœurs (coffre, achat)

Les points de force peuvent augmenter grâce à des potions trouvées ou achetées.

Les points d’Xp permettent de débloquer des parties du jeu ou des dialogues, le joueur peut consulter son Xp à titre d’indice sur son avancé dans le jeu. Cette capacité peut augmenter suite à un combat, un dialogue, une action, … etc

Des Adversaires

Les Adversaires ont des Points de Vie et de Force. Ces points symbolisent les mêmes choses, mais les capacités des Adversaires ne peuvent pas augmenter. Seulement diminuer lors d’un combat.

Les bornes

Les capacités doivent avoir des bornes, Pour la vie [0 ; 20] semble être fonctionnel. Les points de Forces sont plus flous pour l’instant.

L’expérience maximale dépendra de l’usage que l’on en fera dans le jeu, ce nombre sera donc fixé à la fin.

Les monstres ! Les capacités aléatoire des monstres c’est pas top, donc je propose d’avoir plusieurs monstres différents et en fonction de l’image affichée (donc du n° contenu dans la matrice) on affecte certaines capacités au monstre en présence. Après quelques tests, je trouve 4 schémas de monstres, du plus gentil au plus dur avec la récompense entre parenthèse en rubis :

Niveau 1 : 4 Pv / 2 Pf (+2 rubis) -> 2

Niveau 2 : 6 Pv / 6Pf (+4 rubis) -> 2 dés

Niveau 3 : 7 Pv / 10 Pf (+6 rubis) -> 3 dés

Niveau 4 : 12 Pv / 14 pf (+6 rubis) -> 3 dés

le nombre de dé est indiqué ici mais peut être calculé par la formule donnée dans Les combats :

Exemple :

4 Pv 

2 + int(Pv / 7)
2 + int(4 / 7)
= 2 + 0
= 2 dés

Les combats

C’est un peu complexe car je mélange des techniques de moteurs de combat qui tiennent et du RpG en temps réel et du combat au tour par tour.

Comment les combats se déclenchent ?

Les Adversaires se déplacent avec le timer, si aucune touche n’est pressée. Si la case où veut aller l’Adversaire est occupée par le joueur, cela déclenche un combat.

À l’inverse, si le joueurs frappe un case occupée par un Adversaire ou essaie de se rendre sur une case déjà occupée par un Adversaire, cela déclenche également un combat.

Ça c’est pour la partie ‘temps réel’.

Comment se fait le combat d’un point de vue du code ?

À chaque combat, le programme récupère les points de Vie et de Force du joueur et de l’Adversaire, et il fait une somme S pour chacun des deux protagonistes telle que :

S = Pts de Force + dé

Où ‘dé’ est une variable qui contient le plus haut résultat obtenu au lancer de dé. Ce lancer est simulé par le programme qui prend un nombre au hasard entre 1 et 6 un nombre déterminé de fois. Ce nombre de lancer dépend directement du niveau de vie du joueur (ou de l’Adversaire qui est soumis aux même règles).

Donc, les deux combattants ont chacun une somme qui leurs est attribuée. Par convention et par soucis de simplicité, on notera Sj la somme du joueur et Sa la somme de l’Adversaire. On calcule ensuite la différence D entre ces deux sommes :

D = Sj - S

Si D < 0 l’Adversaire est plus fort donc le joueur perd D Points de Vie. A l’inverse, si D > 0 l’Adversaire perd la différence.

Ses calculs se font dans le dos du joueur qui ne voit rien sinon qu’il frappe un ennemis qui le frappe aussi. Les combats peuvent donc se retourner contre le joueur : il peut attaque mais perdre des points de Vie.

L’avantage de ce système somme toute relativement simple est qu’il prend en compte l’état de santé du joueur ce qui poussera celui-ci à la prudence : ne pas faire de combat avec peu de vie. En effet du point de vue du code, avoir peu de Vie équivaut à peu de simulation de lancer de dés, donc il y a moins de chance d’avoir le dessus.

Subtilité des combats

On peut par exemple prévoir une potion ou un sort qui permettrait de multiplier par deux le score du dé.

Cette partie du jeu (sorts et potions) n’est pas encore ébauchée.

Vu que le nombre le lancer dépend de la vie une vie extrêmement élevée donnera beaucoup de dé. Cela pourrait rendre les combats rébarbatif par une victoire certaine. C’est pourquoi, il faut maintenir un faible niveau de vie en se détachant des ‘100 Pv’ traditionnel. On pourrait opter pour un nombre compris entre 0 et 20.

Le problème du nombre de dé

En supposant que le nombre de dé soit égal au points de Vie divisé par 5. Si le joueur a 4 points de Vie, il ne peut plus gagner de combats ce qui serait très vite rageant. D’où l’interêt de rajouter un (ou deux) dé(s) gratuit et indépendant des points de Vie de manière à garantir un succès minimum même avec très peu de points de vie. Des premiers tests ont été satisfaisants avec cette formule :

Nbr de lancer de dé = 2 + int (Pts de vie / 7) avec la vie comprise dans l'intervalle [0 ; 20]

L’écran des statistiques affiche les points de Force, de Vie, et d’Xp sur une barre. Il est donc indispensable d’avoir un maximum dans ces 3 capacités.