Ars Tactica est un jeu de stratégie au tour par tour qui oppose deux ou plusieurs joueurs dont l’objectif est de détruire la base de leur adversaire(s).

Ce projet nécessite deux aspects de conception : Gameplay et Technique.

Le jeu oppose deux camps (1v1 ou 2v2) dans un match à mort pour la destruction de tous les bâtiments affectés à une équipe, ceci en tour par tour. Chaque joueur contrôle un bâtiment principal qui lui sert de point de départ pour produire des unités de combat ainsi que des bâtiments collecteurs de ressources qui lui permettent d’augmenter sa production d’unités. Le joueur devra aussi investir des ressources dans des technologies qui lui débloqueront l’accès à des différents types d’unité.

Chaque joueur commence la partie avec un bâtiment principal permettant de créer des unités. Un joueur est éliminé de la partie lorsque tous ses bâtiments sont détruits. L'ordre de passage des joueurs des déterminé aléatoirement lors du début de la partie.

Au début du tour d'un joueur, toute les unités en cours de production dont le temps de production restant arrive à zero sont placés sur la carte le plus proche possible de leur bâtiment producteur. Le joueur peut ensuite déplacer controller ses unités sur la carte. Chaque unité peut être déplacée une fois par tour et peut attaquer une autre unité/bâtiment un nombre de fois par tour correspondant à sa valeur Spd (Vitesse). Un joueur peut aussi demander la production d'unités par ses bâtiments (chaque bâtiment possède un certain nombre de modules de production parallèles spécifiés par sa valeur Prod). Lorsque le joueur à terminé ses actions, il passe alors sont tour au joueur suivant dans l'ordre de passage.

Une unité est un type d'entité possédant les archétypes Actor, Movable et Attacker. Il leur est aussi possible de posséder l'archétype Caster, Carrier ou Spawner.

Un bâtiment est un type d'acteur possédant l'archétypes Actor. Il ne peut pas être déplacé mais peut posséder les archétypes Spawner, Carrier et Attacker.

Le jeu fonctionne selon une architecture client-serveur avec le serveur servant d’autorité pour la connexion, le matchmaking et le déroulement des parties. Les deux parties utilisent la libraire Netty pour faciliter l’échange des données sur le réseau. Une interface d'administration externe permet aux administateurs de gérer les joueurs.

Le serveur de jeu permet au client d'établir une session ce qui leur permet d'entrer dans la file d'attente pour participer à une partie de jeu. Lorsque suffisament de joueurs sont prêt, le serveur notifie les clients qu'ils sont placés dans un Lobby. Chaque joueur doit alors éventuellement sélectionner ses paramètres de jeu (future proofing). Lorsqu'ils sont prêts, les clients le signalent alors au serveur. Le Lobby possède aussi un timer interne qui empêche un client malveillant d'empêcher le départ de la partie. Une fois que tous les clients ont déclaré qu’ils sont près à démarrer la partie le serveur crée alors une session de jeu (partie) avec les paramètres spécifiés dans le lobby et notifie les clients du début de la partie. La création d'une session de jeu consiste à construire l’ECS représentant l’état de jeu et tirer au sort l’ordre de passage des joueurs. Lorsqu’un client demande d’effectuer une action, le serveur tente de l’appliquer à l’ECS. Si l’action est un succès tous les joueurs sont notifiés des changements à l’état de jeu, dans le cas contraire, seul le joueur ayant initié l’action est notifié.

Le client est composé d’un écran de login, d’un menu ainsi que d’une interface de jeu. Lorsqu’il est démarré, le client affiche l’interface de login, qui donne accès au Lobby sur le serveur. Une fois connecté, une interface menu permet de se déconnecter ou d’indiquer que l’on est prêt à commencer la partie. Le client entre alors en phase d’attente d’une partie de la part du serveur. Une fois la partie reçue, l’interface de jeu est alors affichée, la carte, la base et les unités éventuelles sont présentes (voir annexe 1). Chaque action faite par le client est vérifiée par le serveur. Une réponse de la part du serveur est reçue dans tous les cas (valide ou non-valide).

La base de données de l'application peut être gérée à l'aide d'une interface web par les administrateurs.

• Standalone (central)
• Lobby
  • 1 seule instance
  • Gère les connexions des joueurs
  • White liste DB
  • Dès que 2 joueurs sont prêts, lance une partie (envoi du signal start)
• Play
  • Multiples instances (1 par partie)
  • Gère les données de la partie
  • Notifie les clients de tout changement d’un côté ou de l’autre.

• Application Web (Django)
• Gestion des comptes utilisateurs

Standalone