Bonjour à tous !
Ce mercredi, l'équipe du projet Odyssée s'est réunie pour mettre au clair les bases du projet. Retour en détail sur ce qui a été dit et décidé…

D'abord un grand merci à tout ceux qui ont assistés à la réunion !

Les points clés du projets ont été abordés : la plateforme, l'affichage et les maps, les graphismes, les combats, et les sauvegardes.

La plateforme

Odyssée est un jeu de rôle en C. Avoir de la place en terme de mémoire, mais aussi en terme d'écran sont des atouts précieux. La Graph 90+E a donc été retenue. Après un rapide sondage il s'est avéré que la plupart des membres de l'équipe ont une Graph 90+E (voire une Graph 90 et une monochrome). On compte utiliser la totalité de l'écran soit une surface de 396 par 224 pixels.

Cependant un portage vers la Graph 35+E reste possible. Dans l'idéal on va tenter de bien coder les graphismes de manière à avoir un portage le plus simple possible. Mais pour l'instant la priorité reste la Graph 90+E.

L'affichage et les maps

On est parti sur un affichage proche des Zelda et des Pokémons avec une vue en 2D de dessus. De manière plus concrète le point de vue est situé dans l'alignement des bâtiments, légèrement au-dessus. Ça donne une légère sensation de plongée, un peu comme sur cette image :


Link's Awakening

Les maps sont fixes, sans scrolling, c'est un choix qui découle du moteur de combat. Au niveau de la taille des maps, on est encore dans le flou… Un dessin du monde à main levée est disponible est permet d'avoir une idée générale de l'agencement des forêts, montagnes, lacs…

Pour les tiles et leur taille on a un problème… Si on veut que ça tombe juste, il faudrait faire des tiles de… 4 pixels par 4 pixels… C'est un peu juste… Du coup on est encore dans le flou aussi, mais avec plusieurs choix :

- le 16 par 16 : on peut caser 14 tiles en hauteur et 24 en largeur. Le problème est la bordure de 12 pixels qui va rester sur le côté. On peut centrer les tiles, auquel cas on aurait une bordure de 6 pixels de chaque côté.

- le 24 par 24 : ça fait des grosses tiles avec seulement 9 tiles en hauteur et 16 en largeur. De plus les problèmes de bordures sont aggravées de tous les côtés avec une bordure de 12 pixels sur le côté et un autre bordure de 4 pixels en bas (ou en haut, ça dépend comment on aligne les tiles)

- le 32 par 32 : ça fait des tiles beaucoup trop grosse ce qui est dommage au vu de la taille de l'écran. Avec que 12 tiles en largeur et 7 en hauteur, ça fait des map beaucoup trop 'zoomées' et on perd en confort. De plus il reste une bordure de 12 pixel sur le côté. (comme pour le 16 par 16)

Au niveau des maps, les tailles de chaque map déprendra de la taille des tiles.

Les graphismes

Les graphismes actuels sont sous forme de tiles en 8 par 8 et nuances de gris. Donc tout est à refaire de ce côté. La taille des tiles n'étant pas fixée, il est pour l'instant impossible de s'avancer sur ce point et c'est problématique.

De manière générale les tiles seront en couleurs 16-bits R5 G6 B5. Il faut tout faire, à savoir un joueur et des PnJ animés, des monstres, des bâtiments (au moins 3-4 styles différents), des éléments de décorations divers (plante, meubles, barrières, pierres, herbe…) et des items (potions, épée… ?). Il faudrait aussi une font. Vu qu'on est sur la Graph 90+E on peut se permettre des lettres assez grandes.

En terme de calques, il y en aura 2 au minimum. Mais ça reste flou.

Les combats

L'équipe a retenue les combats en temps réel. On est donc plutôt parti sur un système de combats façon Zelda où il faut taper les monstres avec une épée. D'un point de vue du code et des mécaniques, il y a encore des points sur lesquels on est pas tous d'accord. Par exemple pour les combats, certains voudraient supprimer la part d'aléatoire tandis que d'autres voudraient la conserver.

Dans tous les cas, des simulations en python des combats seront bientôt mise sur le git.

La sauvegarde

Là aussi c'est resté flou. Les statistiques du joueurs ne sont pas encore définie, et il est complexe de savoir ce qu'il faut sauvegarder. Cependant, on peut déjà placer quelques idée :
- les points de vie
- l'XP
- les coordonnées au sein de la map
- (le numéro de la map ?)
- l'inventaire

On peut s'étendre un peu sur les points d'XP. Les points d'XP vont sans doute servir à contrôler l'avancée du joueur dans le jeu. Quand on ouvrira le premier opus et que le jeu se rendra compte que l'on a atteint la limite haute des points d'XP il affichera un message du genre : "Vous avez fini cet opus". Et inversement, même avec l'exécutable du second opus, si la limite basse des points d'XP n'est pas atteinte, on aura un message : "Vous n'avez pas fini le premier opus". Du coup ça permet au joueur un truc très intuitif : il n'a qu'a télécharger les opus sans s'occuper de rien et la continuité du jeu est gérée. (du coup le joueur conserve son épée et ses points de force de vie… etc)

Les objectifs

• Au niveau des graphismes, on a abordé le point un peu plus haut : un joueur et des PnJ animés, des monstres, des bâtiments, des éléments de décorations divers (plante, meubles, barrières, pierres, herbe…), des items, et une police.

Dans l'idéal, il faut une personne sur le joueur, les PnJ les items et la font. Et une autre personne pour les bâtiments et la déco.

• Au niveau du code, il y plusieurs points. Déjà les sources vont se diviser en deux :
- Un groupe de fichiers différents à chaque opus. Ces fichiers contiennent l'opus en quelques sorte : les dialogues, les animations, et les interactions.
- une librairie commune à tous les opus. ce fichier va donc contenir tous les moteurs : combat, affichage…

On peut donc scinder les programmeurs en deux parties : la première composée d'une (ou deux personnes) va se charger des fichiers propres à l'opus. La seconde partie, composée de deux personnes, va s'attaquer aux moteurs du jeu. Idéalement, la librairie devrait être attaquée le plus tôt possible, car c'est la base du jeu.

• Au niveau du scénario, il faut l'avancer aussi. Deux personnes suffiront, le mieux serait que le scénario ne soit pas bloquant. C'est à dire qu'il soit suffisamment avancé pour permettre l'avancée du code sans problème. Il faut donc que l'avancée du scénario soit supérieure à celle du code.


Je pense qu'on a fait le tour… Une prochaine réunion sera organisée d'ici les vacances d'été pour planifier la suite.