Seelies, un jeu de stratégie persistant

[Sephi-Chan]

Hm, ça n'apporte pas grand chose, du coup : ce n'est ni plus sexy, ni plus pratique.

Ça y est : j'ai terminé les fonction de la première itération ! Comme souvent, j'ai posté le code sur GitHub.


La seule gestion des convois a été un gros morceau avec 30 cas de test !

ConvoysTest
  * test Nonexistent convoy can't be disbanded (33.3ms)
  * test Unit can't join a nonexistent convoy (3.4ms)
  * test Convoy ID must be unique (3.4ms)
  * test Convoy can only start to neighbour territories (3.4ms)
  * test Unit can't join a convoy twice (1.1ms)
  * test Convoy starts at the speed of its slowest unit and can't be started anymore (9.7ms)
  * test Nonexistent convoy can't be unloaded (0.7ms)
  * test Unit leaves the convoy and becomes available again (6.6ms)
  * test Convoy is prepared on a territory (1.3ms)
  * test Nonexistent unit can't leave the convoy (0.7ms)
  * test Convoy is unloaded upon arrival and convoy is disbanded (9.3ms)
  * test Convoy can't go to nonexistent territory (1.0ms)
  * test Departed convoys can't be disbanded (1.8ms)
  * test Unit can't leave a nonexistent convoy (0.9ms)
  * test Convoy need at least one unit to start (0.7ms)
  * test Loaded resources are moved from the territory to the convoy (1.0ms)
  * test Unit can't join a convoy from another territory (1.2ms)
  * test Resources of a disbanded are unloaded and units are returned (4.5ms)
  * test Nonexistent unit can't join a convoy (0.7ms)
  * test Only loaded resources can be unloaded from the convoy (0.8ms)
  * test Unit can only leave the convoy if it belongs to it (0.9ms)
  * test Nonexistent convoy can't start (0.6ms)
  * test Unit can't join convoy while exploiting (1.0ms)
  * test Nonexistent convoy can't be loaded with resources (0.5ms)
  * test Unit joins the convoy and is no longer available for exploitation (1.6ms)
  * test Convoy can't be prepared on a nonexistent territory (0.8ms)
  * test Convoy can't be loaded if resources are missing (0.7ms)
  * test Unloaded resources are moved from the convoy to the territory (4.3ms)

DepositsExploitationTest
  * test Unit can't be sent again if already exploiting (1.0ms)
  * test Unit can't exploit a nonexistent deposit (0.7ms)
  * test Nonexistent unit can't exploit a deposit (0.8ms)
  * test Unit starts exploiting the deposit (1.4ms)
  * test Unit can't exploit a deposit from a distant area (0.7ms)
  * test Stopping exploitation bring some resources back to the territory (4.5ms)
  * test Exploitation ticks make units bring some resources back to their territory (5.2ms)

ResourcesQuantityTest
  * test Resources quantities can be added (0.01ms)
  * test Resources quantities can be substracted (0.01ms)
  * test Resources comparision (0.03ms)

UnitsDeploymentTest
  * test Unit can't be deployed on a nonexistent territory (0.7ms)
  * test Unit ID must be unique (0.7ms)
  * test Deploys a starting unit to a territory (0.9ms)

SeeliesTest
  * test Game can be started (0.5ms)
  * test Resources can be added to a territory (0.7ms)


Finished in 0.5 seconds
43 tests, 0 failures

Les fonctionnalités sont là et testées, mais il y a quand même encore un peu de travail pour se servir du code en dehors de tests, notamment sur l'arrivée des convois à destination, et les ticks de récolte des ressources.

Pour ces deux fonctionnalités, je vais utiliser un outil de tâches différées/récurrentes : il se trouve que Commanded en propose un (Commanded Scheduler), qui s'intègre bien dans son architecture event sourcée. Il faut donc que je l'intègre, lui et sa dépendance… PostgreSQL. On ne peut pas dire que ce soit une petite dépendance, mais une base de données relationnelle sera de toute façon précieuse pour implémenter les read models.

[Sephi-Chan]

La première itération étant terminée, et il est temps de définir le cadre de la suivante.

A ce jour, on peut :

• Collecter des ressources ;
  
• Déplacer ces ressources et unités ;
  

Ces fonctionnalités très brutes permettent déjà de mettre en place l'économie du jeu.

Voici quelques pistes pour enrichir ces fonctionnalités basiques :

• Attribuer une quantité finie aux gisements et prévoir leur régénération ;
  
• Payer un coût d'entretien pour les unités pour éviter de les perdre ;
  
• Limiter la capacité de transport des convois selon le nombre/espèce des unités convoyeuses ;
  
• Permettre aux convois d'effectuer une boucle sur plusieurs territoires (avec dépôt/ramassage sur chaque territoire) ;
  

Cependant, avant d'améliorer, je préfère rester "lean" et rester concentrer à fournir une première version jouable. Pour cela, il faut :

• Permettre de recruter de nouvelles unités ;
  
• Permettre aux équipes de prendre le contrôle d'un territoire ;
  
• Permettre à des joueurs de rejoindre la partie dans une équipe avant qu'elle ne démarre ;
  
• Permettre aux joueurs de visualiser et piloter le jeu ;
  

La première version n'a même pas besoin d'un mécanisme de combats : une simple comparaison de la puissance militaire de chaque équipe suffit.

Avec cette deuxième vague de fonctionnalités, le jeu deviendrait jouable. Les itérations suivantes devront apporter les combats, les bâtiments, les équipements, la diplomatie, le commerce…

Pour la deuxième itérations, je conserve l'approche headless : le but est d'avoir les fonctionnalités sous forme de code testable. L'interface viendra après.

• Les unités apparaissent sur les zones à intervalles plus ou moins réguliers ;
  
• Chaque zone peut faire apparaître certaines espèces seulement ;
  
• Les territoires peuvent poser des appâts de ressources sur les zones adjacentes ;
  
• Une unité qui apparaît rejoint le territoire le plus offrant.
  
• Les territoires sont possédés par une équipe ou bien sont neutres.
  
• Les commandes de jeux sont émises par une équipe : un ordre concernant un territoire (ou une unité affectée à ce territoire) ne peut être donné que par cette équipe.
  

Je note déjà les enrichissements possible pour ces fonctionnalités, même si elles seront implémentées bien plus tard :

• Renouveller automatiquement les appâts (indéfiniment ou un certain nombre de fois, jusqu'à capture de X de l'espèce A et Y unités de l'espèce B) ;
  
• Pondérer le tirage aléatoire de l'espèce de l'unité qui apparaît.
  

[Sephi-Chan]

Contenu de la deuxième itération

Pour rappel, voici les fonctionnalités choisies pour cette deuxième itération:

• Les territoires sont possédés par une équipe ou bien sont neutres.
  
• Les commandes de jeux sont émises par une équipe : un ordre concernant un territoire (ou une unité affectée à ce territoire) ne peut être donné que par cette équipe.
  
• Les territoires peuvent poser des appâts de ressources sur les zones adjacentes ;
  
• Chaque zone peut faire apparaître certaines espèces seulement ;
  
• Les unités apparaissent sur les zones à intervalles plus ou moins réguliers ;
  
• Une unité qui apparaît rejoint le territoire le plus offrant.
  

Les équipes

Les prémices du système d'équipes. A la création de la partie, on définit un nombre d'équipes (deux pour commencer). Deux territoires sont distribués aléatoirement à chaque équipe et le dernier reste neutre.
Il faut également modifier chaque commande qui concerne un territoire et vérifier que la commande est bien autorisée à cibler ce territoire. Les tests doivent être modifiés en conséquence.


Poser des appâts

C'est le point clé du recrutement des nouvelles unités : chaque territoire doit pouvoir poser à l'orée de chacune de ses zones adjacentes un appât pour chaque espèce présente dans cette zone.

Pour déposer un appât, on dispatch une action SetBait pour un couple territoire/zone, une espèce et une certaine quantité de ressources.
L'action contrôle que la zone est valide, que les ressources sont bien disponibles sur le territoire, etc. puis émet l'événement BaitSet.
Celui-ci transfère les ressources de la structure territoire à la zone.


Apparition des unités à destination des meilleurs appâts

Commençons par le plus simple : lorsque l'on définit le plateau de jeu (avec le module Board), on peut ajouter des espèces à chaque zone.
La suite directe de la fonctionnalité précédente. Notre but est d'avoir pour chaque territoire un "timer" qui va créer une unité aléatoire selon les espèces définies plus haut, puis une autre, puis une autre, etc.
A chaque fois que l'unité apparait, on l'envoie sur le territoire qui offrait le meilleur appât, puis on lance la production d'une nouvelle unité aléatoire.

[niahoo]

Du coup pour chaque partie, as-tu un processus associé qui contrôle les timers ?

[Sephi-Chan]

[Meraxes]

Ah d'accord ; il y en a qui bossent à 3h du mat.  :baille:  :langue2:

Sympa l'idée des appâts !

Si l'appât n'a pas fonctionné il disparait ?

[Thêta Tau Tau]

J'aime bien aussi cette histoire d’appâts, ça permet de mettre de l'interaction entre les joueurs dans le recrutement des unités.

Ça pourrais facilement se porter à d'autres univers d'ailleurs, genre un système d'enchères pour recruter des mercenaires.

[Sephi-Chan]

Ah d'accord ; il y en a qui bossent à 3h du mat.  :baille:  :langue2:

Sympa l'idée des appâts !

Si l'appât n'a pas fonctionné il disparait ?

Non il reste en place. En mode forain : « Allez allez messieurs dames, qui n’a pas gagné va gagner ! ».

[Sephi-Chan]

J'aime bien aussi cette histoire d’appâts, ça permet de mettre de l'interaction entre les joueurs dans le recrutement des unités.

Ça pourrais facilement se porter à d'autres univers d'ailleurs, genre un système d'enchères pour recruter des mercenaires.

Il y aura avec le volet diplomatie/commerce un genre d'hôtel des ventes des ressources.

[niahoo]

Au fait l'illustration de Harparine est vraiment cool