Type de jeu: Jeu à installer sur PC
Principe:
Prise de territoire et confrontation armée.
Description complète:
Dans l'esprit d'un Advance Wars, on achète des unités pour aller attaquer son adversaire.
Mots-clef:
Époque Moderne, Gestion, Stratégie, Jeu de plateau, Combats, 1vs1, Tour par tour
| Durée d'une session de jeu | 20 minutes |
|---|---|
| Fréquence de jeu | 1vs1 |
| Financement | Personnel |
| Technologies utilisées | Le client est codé en Lua avec le moteur LÖVE, et le serveur en Elixir |
| L'équipe de création | Moi |
Comment jouer?:
Précisions finales: Me revoilà avec un jeu de game jam ! Cette fois on se rapproche de JeuWeb puisque c'est un jeu multijoueur en ligne... Il s'agit de Not So Advance Wars, un clone du jeu Advance Wars sur Game Boy Advance.
Comme d'habitude, tout est sur GitHub : le client et le serveur.
Je n'avais jamais travaillé avec les sockets (en l'occurrence TCP) et ça n'a donc pas été facile de mettre le pied à l'étrier. Le processus de développement était assez laborieux puisque je testais avec deux ordinateurs. Je n'ai pu travailler que la dernière semaine de la jam : il y a donc 7 jours de travail acharnés derrière tout ça, à environ 10 heures par jour. Vive les vacances scolaires pour les enseignants !
La mise en production du serveur a été triviale grâce à Distillery. Cet outil crée des exécutables à partir des sources Elixir et qui permettent de lancer le jeu en background, en foreground ou bien en foreground avec une console interactive (pour pouvoir surveiller ce qui se passe, intervenir, se rajouter de l'argent).
Le jeu fonctionne sans base de données : tout est stocké en mémoire le temps de la partie, et la liste des joueurs connectés et des lobbies ouverts est stockée en mémoire pour toute la durée d'exécution du serveur. Elixir permet de lancer des "processus" qui tournent simultanément et attendent des messages. En l'occurrence ici j'en ai 3 : un qui gère les joueurs connectés (il maintient une liste au gré des connexions/déconnexions), un qui gère les lobbies (pareil, il maintient une liste des lobbies ouverts, les ferme quand un joueur quitte ou que la partie pour ce lobby démarre) et enfin un process pour chaque partie lancée, qui reste ouvert jusqu'à la fin de cette partie.
Côté Lua, j'aime toujours la simplicité du langage mais je m'exaspère de la pauvreté de sa librairie standard et de son écosystème. Je pense changer bientôt de techno, sans doute au profit du langage Haxe et de l'un de ses nombreux moteurs.
Le jeu fonctionne essentiellement avec des machine à état : l'app est une machine à états avec un état par écran : l'écran principal avec les joueurs connectés et les parties, l'écran qui affiche la partie en cours et l'écran de cinématique de combat. Chacun de ces écrans est également une machine à états. Et enfin dans la cinématique de combat, le background et chaque unité affichée est une machine à états également ! Cela m'a permis d'organiser assez facilement le déroulement d'un combat (et donc son animation).
