[RFC] Slime Volley 3.0
Publié: 18 Juin 2009, 20:26
Petite intro avant d'entrer dans le vif du sujet :
Je ne pourrais pas recommencer à coder Slime Volley avant un certain temps, mais cela ne m'a pas empêcher de réfléchir au futur de ce jeu
RFC signifie Request For Comments. Cela veut dire que si ce que je dis n'est pas clair, ne semble pas faisable ou ne vous plaît pas, ou que vous avez des idées supplémentaires n'hésitez pas à le dire : ça sera plus facile à changer maintenant que quand la moitié du programme sera écrite
J'ajoute que les images sont juste là pour illustrer mon propos, dans la réalité ce sera sans doute plus joli
Design général du programme
Jeu
Ressources externes
Pistes à étudier
Je ne pourrais pas recommencer à coder Slime Volley avant un certain temps, mais cela ne m'a pas empêcher de réfléchir au futur de ce jeu
RFC signifie Request For Comments. Cela veut dire que si ce que je dis n'est pas clair, ne semble pas faisable ou ne vous plaît pas, ou que vous avez des idées supplémentaires n'hésitez pas à le dire : ça sera plus facile à changer maintenant que quand la moitié du programme sera écrite
J'ajoute que les images sont juste là pour illustrer mon propos, dans la réalité ce sera sans doute plus joli
Design général du programme
- Pour améliorer la lisibilité et la modularisabilité du code, certaines sections du code (si ce n'est la totalité) seront réécrites en C++.
- Les valeurs de retour des appels systèmes comme malloc et realloc seront systématiquement vérifiées (sachant qu'ils peuvent échouer sur des systèmes qui utilisent une allocation mémoire statique, comme Mac OS 9)
- Les dépendances aux bibliothèques sdl_image et sdl_net seront supprimées : utilisation de la libpng et des sockets UNIX à la place (peut-être également utilisation directe de la libfreetype au lieu de sdl_ttf)
- Une fonction d'affichage de message d'erreurs, spécifique à l'OS, sera utilisée.
Jeu
- Deux modes principaux : le mode solo et le mode libre. Le mode solo se fera contre IA, et permettra de "débloquer" des graphismes supplémentaires qui pourront être utilisées dans le mode libre. Ce dernier fera s'affronter un certain nombre d'équipes, définies à l'avance. Les joueurs pourront entrer à l'avance leur pseudonyme (et leur configuration clavier préférée) pour rendre la constitution des équipes facile :
- Le mode réseau évoluera : il permettra la découverte automatique des serveurs, au choix soit sur le réseau local, soit sur Internet (via une liste sur le site Web, téléchargée et mise à jour automatiquement).
- Une fois le mode réseau activé, les clients pourront se connecter à tout moment sur le serveur, qui affichera le nombre de connectés dans le menu principal, notamment.
- Lorsqu'un joueur réseau sera placé dans une équipe, il recevra son image de slime (qu'il pourra éventuellement modifier pendant la partie), ainsi que sa position. Le jeu essayera d'utiliser les mêmes graphismes que sur le serveur (quitte à les télécharger - voir plus bas)
- Une fois le mode réseau activé, les clients pourront se connecter à tout moment sur le serveur, qui affichera le nombre de connectés dans le menu principal, notamment.
Ressources externes
- Les fichiers de données utilisés par le jeu seront "aplatis" dans un seul fichier. Le format global de ces fichiers reste déterminer, mais il est probable que 1) les données (images, sons, polices), soient enregistrées telles qu’elles et que 2) les valeurs numériques de l'en-tête soient stockées en big endian, pour éviter les problèmes d'endianness.
- Le mécanisme de chargement de ces données sera modularisé : Il y aura un "chargeur" qui cherchera des fichiers de données dans divers dossiers prédéfinis de l'ordinateur (dans le dossier d'installation, dans celui de l'utilisateur...), un autre qui lira les ressources Mac OS/BeOS, un autre pour télécharger les thèmes lors d'un jeu en réseau... A noter qu'il y aura en général deux phases de chargement : Dans une première phase, on construira la liste des ressources disponibles, et celles-ci seront effectivement chargées plus tard, quand elles seront utiles. Durant l'énumération des ressources (au démarrage), le jeu affichera de quoi faire patienter l'utilisateur (sachant que l'on ne pourra pas afficher de textes ou d'images à ce stade, on se contentera probablement d'une barre de chargement).
- Il y aura deux types principaux de ressources :
- Les thèmes : ils définiront l'apparence de l'interface du jeu (menus, éléments d'interface, éventuellement sons...)
- Les “niveaux” : contiennent les fonds de jeu et les images des slimes (FIXME : musiques de fond ?). Le designer choisira à quel "niveau" seront associées ces ressources.
A ce propos, il y aura trois réglages pour les images des slimes : uniquement à gauche, uniquement à droite, ou les deux (image de slime pouvant être "renversée" et placée de n'importe quel côté). De plus, les designers pourront utiliser des images de slimes plus grandes que 50x100, et spécifier la position d'affichage (en d'autres termes, on pourra faire des slimes avec des antennes qui dépassent)
Pistes à étudier
- Utilisation d'un moteur 2D pour la physique du jeu : Chipmunk pourrait convenir mais en fait peut-être un peu trop...
- SVG : La bibliothèque SDL_svg permet d'utiliser de graphismes vectoriel au format SVG dans un programme qui utilise SDL. Ceci pourrait être très intéressant, notamment pour pouvoir gérer des résolutions plus grandes que 800x600 sans pixellisation. En revanche, celà rajouterai une dépendance à Slime Volley (et cette biblothèque est rarement présente dans les distributions Linux — en revanche, il serait envisageable d'intégrer directement le code). Si les designers de thèmes sont motivés à passer au SVG…