nadawoo/invazion

InvaZion, collaborative game based on Hordes/Die2nite

invazion's Issues

"Il y a déjà une ville sur cette case..."

Sur certaines cases, un message interdit de fouiller ou construire une tente au motif qu'il y a "déjà une ville sur la case", alors qu'il n'y en a pas.

=> Cause possible : l'attaque de la horde détruit la ville mais ne met pas à zéro le compteur correspondant ?

Infos à ajouter sur la carte

Améliorations à faire sur la carte pour motiver les joueurs :

• Indiquer le pourcentage de carte explorée
• Montrer les cases explorées aujourd'hui (soit par des marqueurs comme pour les objets, soit par des cases colorées)
• Indiquer le nombre total de zombies sur la carte

Rendre cliquables les noms des objets

Rendre cliquables les noms des objets (dans le sac, au sol, au dépôt). Ouvrira une infobulle proposant :

• Utiliser l’objet (plusieurs possibles selon l'objet)
• Déposer l’objet (s'il est dans le sac)
• Ramasser l’objet (s'il est au sol ou au dépôt)

Notifier les événements personnels (blessure...)

Une fois les mentions @pseudo implémentées, notifier les événements qui concernent le joueur (agression par un autre citoyen...). Il suffira de réutiliser la table notifications créée dans la BDD (pour la structure de la table, voir issue #18).

Chantiers personnels

Afin de varier les actions possibles sur l'habitation personnelle, en plus de l'amélioration classique de maison (tente, maison, bunker...), chaque joueur disposera de chantiers spécifiques pour augmenter ses points de défense personnels.
Comme dans Hordes, chaque point de défense personnel apporte également 1/2 point de défense à la ville.
Seul le propriétaire de la maison peut travailler sur ses chantiers.

Liste des chantiers :

• Renforcer les fenêtres
• Consolider les murs
• Blinder la porte
• Piéger la cheminée
• Daller le sol
• Doubler le toit

Chaque chantier terminé peut être ensuite amélioré (niveau 2, niveau 3...), coûtant de plus en plus de ressources.

ZombLib - Supprimer les actions spécifiques

Suite du ticket #6 (ZombLib - Améliorations pour la V2) : supprimer les anciennes méthodes spécifiques de la ZombLib, désormais remplacées par la méthode générique call_api() (voir #6).

Attention : cela ne pourra être fait qu'avec une V2 de la ZombLib car ce n'est pas rétrocompatible.

Les méthodes à supprimer sont celles qui se content d'appeler call_api() sans autre action particulière :

• add_stuff_on_map()
• attack_citizen()
• attack_city()
• build_city()
• close_city_door()
• construct()
• craft_item()
• create_citizen()
• dig()
• drop()
• fight()
• get_cities()
• get_city()
• get_citizens()
• get_config()
• get_discuss_threads()
• get_map()
• get_me()
• go_inout_city()
• heal_citizen()
• kill_zombies()
• move()
• open_city_door()
• pickup()
• reveal_zones()

Missions (solo ou en groupe)

Le joueur ne doit pas s'ennuyer si les autres joueurs sont inactifs (problème récurrent des jeux multijoueurs). Pour dynamiser le jeu, des missions sont proposées régulièrement au joueur. Elles se passent sur une carte spéciale, les zombies tués et le matériel utilisé n’ont pas d’effet sur la « vraie » carte. Le joueur peut toutefois consommer des « vraies » ressources pour enrichir le « faux » équipement fourni pour la mission.

[Ebauche à affiner]

Types de missions

• Atteindre une zone en expé (échec si groupe bloqué)
  Matériel à prévoir : armes, stock eau, boosts, compo métiers…

• Tuer X zombies
  Fin de la mission quand le joueur est bloqué.

• Sauvetage : débloquer un joueur bloqué virtuel (ou un vrai joueur s’il est réellement bloqué)

• Construire suffisamment de défenses dans une ville virtuelle

• Câliner un zombie : mission piège, elle ne rapporte rien et coûte juste le prix d’activation de la mission. Un message indique : « Vous avez cru aux bisounours ? C’était un piège, vous êtes dans un monde impitoyable. »

Récompenses

• Si mission réussie :
  Jauge de PA agrandie : +1PA/jour
  et regain immédiat de tous les PA
  et +10 pts d’expérience

• Si mission échouée :
  Jauge de PA agrandie : +1PA/jour
  et regain immédiat de 1 PA seulement
  Et +2 pts d’expérience

L'agrandissement de la jauge de PA (points d'action) n'est valable que pour la partie en cours. Une fois mort, le joueur redémarre aux caractéristiques de base (6 PA/jour) afin que tout le monde soit à égalité.

Les points d’expérience servent à conserver une trace des succès du joueur.

Modalités spéciales

Option « quitte ou double » :

• Si échec, le joueur aura une blessure dans la vraie partie et aucune récompense (sauf +1 pt d’expérience pour avoir joué).

• Si succès, sa récompense est doublée.

Discussions : Lister les mentions @pseudo

Ajouter la possibilité, dans l'espace de discussions, de notifier un joueur en utilisant la syntaxe « @pseudo ».

=> Créer un nouvel onglet « Perso » dans le volet « communications ». Il listera toutes les mentions @pseudo qui concernent le joueur.

Cela implique de créer une nouvelle table dans la base de données. Champs à prévoir :

• citizen_id (int) => L’id du citoyen cité dans le @pseudo
• event_type (enum) => le type d'événement. Valeurs possibles :
  • "mention" : le joueur a été cité dans un message
  • "log" : événement du jeu (ex : le joueur a été blessé)
• event_id (int) => L'id qui permet de lier à l'événement en question. Dépend du type :
  • Si événement de type "mention" : l’id du message, dans la table des discussions, qui contient la mention @pseudo
  • si événement de type "log" : l'id de l'entrée dans la table de log des événements du jeu
• read (bool) => 0 si non lu, 1 si lu

Liens morts en ville

Bug : à l'intérieur de la ville, les liens en tête de certains blocs n'amènent plus nulle part car la fonction javascript switchCityTab a été supprimée :

Liste d'objectifs (bouton)

Ajouter un bouton "Objectifs" en haut de la carte, à côté de "Notifications". Intérêt :

• Le joueur aura toujours au moins une chose à faire, même très générale (ex : construire des défenses)
• Permet de découvrir le jeu sans noyer le joueur dans un long tuto et sans trop le diriger
• Communication entre joueurs plus efficace (affichage bien visible des appels à l'aide...)
• Incite à la communication en intégrant les discussions aux endroits adaptés de l'interface (voir plus bas)

NB : on parle ici de guider le joueur dans les tâches à accomplir pour construire la ville (sortir en expédition, construire les chantiers...). Pour de vraies missions (= événements donnant des bonus quand réussies), voir le ticket #43.

Liste des objectifs à prévoir

Objectifs ajoutés automatiquement par le jeu :

• Construire XX défenses avant minuit (un clic sur l'objectif ouvrira la pop-up expliquant l'attaque)
• Boire (si le joueur est en voie de déshydratation)
• Rentrer avant minuit (si le joueur est dehors)
• Aider le joueur XX bloqué en X:Y, à xx km (cet objectif sera déclenché quand le joueur bloqué cliquera sur un bouton de demande d'aide)

Objectifs ajoutables manuellement par les joueurs :

• Construire le chantier XXX
• Ramener une catégorie d'objets :
  • Boosts (nourriture/drogue/alcool)
  • Eau (distinct des boosts car concerne surtout l'hydratation)
  • Objets de défense
  • Armes
• Ramener des objets précis (à lister manuellement par le joueur)
• Fouiller le bâtiment XX en X:Y (à xx km de la ville)
• "J'ai besoin de X personnes pour une expédition"
  => le mettre en haut de la liste pour le rendre bien visible
  => permettre au joueur de préciser une heure ou immédiatement

Modalités

Lien étroit avec l'espace de discussion :

• L'ajout d'un objectif créé automatiquement un sujet sur l'espace de discussion. Techniquement, il sera stocké dans la base de données de l'espace de discussion avec un tag #objectif. Il suffira d'extraire les massages portant ce tag pour reconstituer la liste des objectifs.
• Chaque objectif pourra être commenté (en réponse). Peu importe qu'il soit commenté à partir du bouton "objectifs" ou à partir de l'espace de discussion, les réponses seront visibles aux deux endoits.

La gestion des objectifs devra être la plus ergonomique possible :

• Afficher en temps réel l'ajout d'objectifs (nombre dans une pastille rouge à côté du bouton)
• Nettoyer automatiquement les objectifs périmés si c'est détectable automatiquement (ex : si le chantier est terminé)
• Faciliter l'ajout avec des messages préremplis (mais modifiables)
• Chaque chantier doit proposer un bouton "Marquer comme prioritaire"
• L'infobulle d'un objet doit proposer un bouton "Ramener en priorité"

Périmètre de visibilité des objectifs :

• objectifs de la ville, visibles par tous les habitants de la ville (icône : ville)
• objectifs de la carte, visibles par tout le monde sur la carte (icône : globe ?)
• objectifs personnels, visibles uniquement par le joueur (icône : capuche de l'éclaireur)

Sauvetage et escortes

Si joueur est bloqué par les zombies, il peut cliquer sur un bouton spécial « Appel à l’aide ». Deux effets :

• Les autres joueurs reçoivent une notification. L'auteur de l'appel peut joindre un message personnalisé.
• Le mode « escorte » est activé : un joueur sauveteur peut prendre le contrôle du joueur bloqué pour le ramener en ville.

Intérêt : contrairement aux expéditions, les demandes d’aide ne sont pas planifiées, ce qui rend la synchronisation des joueurs particulièrement difficile (envoi de l'appel à l'aide => réception par un joueur connecté => demande de confirmation que le sauvé est connecté aussi => confirmation par le sauvé => le sauveteur se met en chemin => le sauveteur et le sauvé rentrent ensemble). Le mode escorte réduit ces contraintes, sans pour autant rendre le jeu trop facile car il n'est pas sûr qu'un joueur soit à proximité ou dispose de suffisamment de points d'action pour aller le chercher.

L’escorte n’existe pas en dehors des demandes de sauvetages. Elle existait en tant que mode d'expédition dans Hordes et n'était pas très intéressante.
Le sauveteur ne peut pas éloigner le sauvé de la ville, pour empêcher le détournement de cet outil de sauvetage en outil d’expédition.

Spécialité non sélectionnable

(Signalé par Garufo) Lorsque notre zone est affichée en grand, il est impossible de choisir sa spécialité, pas de clic possible.

Croix pour fermer l'interface de ville

Lorsqu'on est en ville, devoir cliquer sur le bouton "Porte" n'est pas évident pour les joueurs débutants. De plus, l'interface de ville empêche de regarder la carte cachée en dessous.

=> Ajouter une croix classique de fermeture en haut à droite de l'interface de ville.

=> Dans le bloc "Se déplacer", remplacer le contenu du bloc par une ligne explicative ("Vous êtes en ville") un bouton "Sortir de la ville".
Si les portes de la ville sont fermées, prévoir un bouton différent "Ouvrir les portes et sortir" (avec une pop-up de confirmation expliquant qu'ouvrir les portes annule les défenses).

Gestion des versions des API par la ZombLib

Les API du jeu seront à l'avenir versionnées indépendamment les unes des autres (voir #7). La ZombLib devra pouvoir savoir quelles versions appeler.

• Les numéros de version des API appelées par la ZombLib devront être définissables indépendamment pour chaque API (ex : maps/v1 mais citizens/v2).
• Les numéros choisis devront être enregistrés dans un fichier de config externe et non dans directement la ZombLib. Sinon, un utilisateur qui fait une mise à jour de la lib perdra ses réglages de version.
• Si aucun fichier de configuration n'est défini (1re installation), la ZombLib devra être en mesure d'en générer un avec les numéros de version les plus récentes.
  => Créer une nouvelle API "apiinfos" qui listera toutes les API disponibles, avec pour chacune tous ses numéros de version disponibles. La lib appellera cette API pour récupérer les numéros les plus récents et génèrera le fichier de config.
• Ne pas permettre à la lib de prendre d'office la version la plus récente, car on perdrait tout le bénéfice du versionning (à chaque publication d'une nouvelle version majeure d'une API, l'appli utilisateur serait cassée).

Amélioration infobulles carte

L'infobulle qui s'affiche au survol d'une case devrait se décaler automatiquement de manière à ne jamais déborder de la carte.
=> Requiert du javascript

Ceci permettrait de rétablir le overflow:scroll sur de la carte, afin que celle-ci ne déborde pas lorsqu'on joue sur téléphone.

Plantes et toxicité

Idée de gameplay de Skaen : les plantes
https://invazion.nadazone.fr/discuss/topic?topic=3&p=#post39

---

Reproduction du message de Skaen

---

Les plantes qui se rebellent ça me plait bien.

Imaginons:

L'homme a foutu le bordel sur sa planète et des vents toxiques la balaient désormais.
-> ce serait la progression de la horde zombie du Nord au Sud tous les jours.
-> pas d'abri ou de combinaison un minimum étanche ? Pas de résistance à la toxicité développée* ? Mort.

Ces vents transforment les plantes, les arbres etc en organismes mutants hostiles à l'humain.
-> permet d'avoir des menaces statiques
-> différents types d'organismes avec des effets différents ?

On pourrait imaginer tout un tas de chantiers/objets pour préserver les villes/notre propre corps face à la toxicité de ce nouvel Outre-Monde.

Cela impliquerait un nouvel attribut pour les cases, que ce soit ville ou non: la toxicité.

Elle pourrait augmenter à cause des vents ou baisser "naturellement" (car sur telle ou telle case le vent n'était pas chargé en particules toxiques et a chassé les autres, par exemple).

---

Voici un exemple concret:

Chantier_

Serre d'OGM: Vous êtes parvenu à créer un OGM qui résiste plus ou moins aux particules toxiques. La serre est construire et vous avez maintenant une source de nourriture. Mais peut-être est-ce elle qui finira par vous manger...

-> Au delà d'un certain taux de toxicité, le chantier peut-être détruit par quelques citoyens.

-> S'il ne l'est pas et que la toxicité augmente encore, ces OGM se transforment malgré tout et attaquent la ville.

Dans ce cas-là le chantier perd en perf si la ville se toxicifie. En revanche on pourrait avoir l'inverse, des chantiers qui mise sur la hausse de la toxicité.

Ca ferait déjà 2 camps:

• Ceux qui luttent contre ce nouveau monde.
• Ceux qui l'embrassent.

On pourrait alors imaginer des petites guerres de territoire pro-tox (*des mecs qui jouent avec leur propre toxicité pour pouvoir mieux survivre) et anti-tox (des mecs en combinaisons, des laborantins).

---

De cette façon la partie pourrait aussi avoir un camp gagnant:

-> La région est devenue trop toxique pour lutter.
_ Défaite des anti-tox qui ne s'y sont pas adaptés à temps.

-> La région respire enfin, l'air s'est purifié ! Tous les organismes toxiques périssent.
_ Défaite des pro-tox qui ont développé une dépendance à la toxicité.

Il faudrait alors un état global de la région.(cumul de la toxicité des cases et définir des scores à atteindre pour chaque camp ? Un chantier ou une chaine de chantiers qui fait gagner ?)

---

J'espère que mon message est pas trop bordélique !

Ce genre d'univers m'inspire pas mal, au besoin ce serait un plaisir de développer d'autres idées de chantiers/objets/tout et n'importe quoi qui irait dans ce sens.

PWA (progressive web app)

Transformer l'interface en PWA (Progressive web app) pour permettre :

• L'ajout en page d'accueil sur mobile
• L'affichage sans barre de navigateur/onglet
• Les notifications mobiles
• ...

Documentation :

• Doc complète (en) : https://web.dev/progressive-web-apps/
• Plus synthétique (fr) : https://www.technologies-ebusiness.com/plateformes/developpement-pwa

Utiliser aussi Google Lighthouse pour analyser la page du jeu :
ouvrir le jeu dans Chrome > touche F12 > onglet Lighthouse
cliquer sur le bouton "Generate report"

Infobulles manquantes sur mobile

Sur écran étroit, les infobulles ne s'affichent plus sur les zones les plus en haut de la carte. Semble dû au fait que < div id="column_right" > (qui contient notamment le bloc des actions) passe par-dessus la carte (comportement attendu) mais crée une zone invisible qui bloque l'accès à la couche de la carte.

=> Solution possible : réduire à 0 la hauteur du div "column_right" quand il n'a rien à afficher.

Placer le smartphone dans le bloc "Me déplacer"

Le smartphone à côté de la carte n'est pas bien intégré dans l'interface : peu visible car relégué sous les blocs d'action, et carrément masqué sur les petits écrans par manque de place.

=> Solution : le mettre dans le bloc d'action "Me déplacer", à la place de l'actuel compteur de points d'action.
=> Le compteur étant indispensable, il doit auparavant être intégré dans le smartphone du jeu, dans une nouvelle appli "PA". Elle affichera les mêmes infos que le compteur actuel (nombre de PA disponibles/total, et phrase expliquant pourquoi le déplacement est gratuit ou non).
=> Ne pas oublier d'intégrer le lien ouvrant la pop-up d'aide sur les déplacements (actuellement activée en cliquant sur le compteur de PA).

Fuseau horaire du compte à rebours

Le compte à rebours avant l'attaque zombie (en haut de la carte) se base actuellement sur l'heure courante du navigateur. Le compteur sera donc erroné si le joueur ne se trouve pas sur le même fuseau horaire, ou si son appareil n'est pas à l'heure exacte.

Solution en plusieurs étapes :

1. L'API du jeu doit retourner l'heure actuelle du serveur, au format ISO pour préciser son fuseau.
2. Calculer en Javascript la différence entre cette heure du serveur et l'heure actuelle de l'appareil du joueur.
   Attention à prendre en compte le fuseau du joueur.
3. Afficher et actualiser l'heure de l'attaque en Javascript avec cette formule :
   Temps restant avant attaque = Heure de l'attaque - (Heure actuelle du joueur + Décalage)

Cette solution permet d'afficher l'heure exacte même si l'horloge de l'appareil du joueur est déréglée.

Non authentifié sur le forum

A propos du forum : https://invazion.nadazone.fr/discuss/
=> Impossible d'envoyer des messages en tant que membre inscrit, même après s'être identifié sur le jeu.

Rendre cliquables les noms des autres joueurs

Rendre cliquables les noms des autres joueurs. Ouvrira une infobulle proposant :

• Agresser/soigner
• Ecrire au joueur. Prérequis : implémenter les notifications @pseudo dans l’espace de discussions

Ordre des superpositions / z-index

Les superpositions "z-index" en CSS doivent être organisées pour éviter les erreurs entre les différentes couches. Changer le z-index de dizaine à chaque changement de type d'élément, et utiliser les numéros intermédiaires pour les éventuels sous-éléments de même type :

• 0 : la carte
  • 1 : la horde mobile (triangles rouges)
  • 2 : les infobulles au survol des zones
• 10 : zoom sur la zone (par clic sur le bouton « Afficher ma zone »)
  • 10 : le fond hexagonal
  • 11 : les blocs (citoyens, zombies, objets, ville...)
  • 12 : les boutons "afficher les objets / afficher ma zone"
• 20 : les blocs d’action (affichés/masqués par les boutons bouger/fouiller/zombies…)
• 30 : le volet "Communications"
• 40 : la liste des notifications (cloche en haut) et la future barre du haut qui affichera les actions de profil dans un menu déroulant (modifier mon profil, me déconnecter...)
• 50 : la pop-up

Les modes de marche (en expédition)

Des modes de déplacement spéciaux sont activables avant de partir en expédition. Le principe ressemble aux métiers/spécialités de héros, à la différence qu'ici l'avantage s'accompagne d'un malus :

• Mode normal : rien de particulier.

• Mode "Marche prudente" : le joueur a 2 points de contrôle en plus. Un joueur isolé peut ainsi aller plus loin dans le désert.
  En contrepartie, certains objets (à déterminer) ne sont jamais trouvables en fouille dans ce mode.
  Intérêt : ce mode est confortable mais le joueur devra en sortir s'il veut débloquer certains chantiers.
  Explication RP : fouiller avec la pointe de sa pelle ne permet pas de découvrir les trésors les plus enfouis.

• Mode "Marche lourde" : le joueur a 1 point de contrôle en moins mais 1 place de sac en plus.
  Utile pour les expéditions à plusieurs bien organisées.
  Explication RP : le joueur chargé est moins mobile et moins discret contre les zombies.

• Mode "Marche forcée" : chaque déplacement dans le désert coûtera 2 PA au joueur (au lieu d'un), mais il aura plus de chances de trouver des objets rares (au moins 1 toutes les X fouilles).
  Ce mode est davantage destiné aux joueurs bien organisés car il est coûteux. Intérêt aussi en fin de ville, pour des fouilles de la dernière chance si un composant manque pour un chantier.
  Explication RP : le joueur se fatigue davantage en faisant des fouilles profondes mais cela lui permet de meilleures découvertes.

La combinaison métier du joueur / mode d'expédition rend le jeu plus riche qu'un simple ajout de métiers. Par exemple, un joueur "gardien" voit son bonus de métier (+2 points de contrôle) annulé s'il est en mode "marche prudente".

Modalités particulières

Le mode d'expédition est sélectionnable sur la page de la porte de la ville. Il est modifiable à volonté tant qu'on est en ville, mais une fois dehors il ne peut plus être changé jusqu'au retour en ville (sinon trop facile).

Les joueurs d'une même expédition peuvent choisir des modes de marche différent, les bonus/malus ne s'appliquent qu'au joueur concerné et non au groupe entier.

Niveaux d'autorisation pour les API du forum

Les futures API du forum devront proposer aux joueurs des réglages de sécurité, sur le même modèle que les autorisations d'accès des applications mobiles.

Principe

Les forums et la messagerie peuvent contenir des informations sensibles.
=> Tant qu'un joueur n'a pas activé explicitement une autorisation, l'API ne fournira pas les informations aux sites tiers.
=> Dans un premier temps, les autorisations/refus s'appliqueront à tous les sites tiers. A long terme, prévoir des réglages différenciés par site (nécessitera un système de clés d'authentification pour chaque site).

Autorisations à prévoir

Autorisation du joueur requise pour :

• Poster ou modifier des messages à partir d'une interface tierce (autre que le serveur officiel d'InvaZion)
  => Car risque : le site tiers pourrait poster des messages au nom de l'utilisateur

• Lire les messages privés du joueur
  => Car risque : divulgation de leur contenu par le site tiers
  Il faudra que l'auteur de chaque message de la conversation ait donné son autorisation. L'autorisation du destinataire pour les lire sur un site tiers ne peut pas suffire (sinon un joueur A pourrait autoriser un site à accéder aux messages du joueur B).

• Lire les messages postés dans des sections privées du forum
  => Car risque : divulgation de leur contenu par le site tiers. Dans ces sujets, chaque message d'un joueur n'ayant pas activé l'autorisation seront remplacés par un message :
  "[Un joueur a posté un message ici mais n'a pas autorisé son affichage sur ce site.]"
  Ne pas afficher le pseudo du joueur car divulguer qu'il a accès à une section privée pourrait être une information sensible.

Pas d'autorisation particulière pour ;

• Accès aux messages publics du forum
  => Pas de risque car ils sont déjà publics.

Forme des autorisations

Le joueur pourra cocher/décocher les cases adéquates dans son profil sur le serveur central d'InvaZion.
Ces options ne devront en aucun cas pouvoir être modifiées à partir d'un site tiers (il pourrait les modifier à sa guise).

API - Améliorations pour la V2 (structure générale)

Idées d'améliorations pour une future V2 des API :

Dans la clé [métas], regrouper les données dans 2 sous-clés [api] et [error] :

metas : {
    api: {
        status: ...
        version: ...
        newest_version: ...
    }
    error: {
        code: ...
        class: ...
        message: ...
        details: ...
    }
}

Ne plus distinguer des API pluriel et singulier (ex : cities/city), les différences sont trop subtiles.
=> Tout grouper dans la version au pluriel.

Versionner chaque API indépendamment des autres car toutes n'évoluent pas à la même vitesse.
Ex : http://invazion.localhost/api/maps/v2
et non pas
http://invazion.localhost/api/v2/maps

Connexion : adresse mail non reconnue si majuscules

Les identifiants ne sont pas reconnus si on tente de se connecter à son compte avec une ou plusieurs majuscules dans l'adresse mail.

=> Pour la connexion, vérifier qu'un strtolower() est appliqué à l'adresse mail avant de la hasher.

=> Faire la même chose pour la création du compte. Des majuscules au moment de la création rendraient impossible la correspondance lors de la connexion.

Les postes avancés (bonus de PdC)

Les postes avancés seraient des bâtiments à différents endroits de la carte. Ils donneraient un bonus de points de contrôle dans toutes les zones alentour. Par exemple, si un groupe de joueurs dispose de 6 points de contrôle et qu'un poste avancé à proximité donne un bonus de x1,5, ils auront 9 points de contrôle.

Chantiers dans les postes avancés

Les postes étant des villes minimalistes, ils n'auront pas de chantiers de défense. Ils ne pourront servir qu'à stocker des objets de défense. Les joueurs pourront répartir ces OD entre 3 emplacements à l'intérieur du poste :

• 1 emplacement pour augmenter le nombre de points de contrôle fourni par le poste
  (coefficient multiplicateur, par exemple : PdC x 1,5)
• 1 emplacement pour augmenter son rayon d'action du poste (le nombre de zones alentour qui bénéficient du bonus de points)
• 1 emplacement pour augmenter les défenses du poste contre les attaques zombies (voir plus bas)

Emplacement des postes avancés

Deux possibilités, à trancher :

• Soit les postes peuvent être construits n'importe où par les joueurs (comme les villes actuelles)
• Soit ils sont placés d'office sur la carte en début de partie (comme les bâtiments dans hordes)
  J'ai une préférence pour la 2e option car elle inciterait à explorer le désert pour les trouver.

Défense et état des postes avancés

• Comme la ville, chaque poste subit une attaque quotidienne. Comme ils sont moins puissants, il s'agit d'un pourcentage (10% ?) de l'attaque subie par la ville. Ce nombre devra être affiché clairement (ne pas imposer aux joueurs de le calculer)
• Chaque poste a un nombre de points de vie. Chaque débordement d'attaque lui fait perdre des points.
  Points de vie perdus = Défenses du poste - Nombre de zombies de l'attaque
• Les points de vie perdus ne sont pas réparables.
• Quand un poste est détruit (0 point de vie), son avantage de points de contrôle est perdu dans toute la zone. Les objets de défense qu'ils contenaient sont également détruits.

Aspects stratégiques

La répartition des objets de défenses (OD) entre les 3 chantiers (points de contrôle / rayon d'action / défenses du poste) peut donner lieu à des débats stratégiques :
=> Ce poste est menacé, on augmente sa défense pour le sauver ?
=> Non, il est fichu, il faut au contraire le vider au maximum pour sauver les OD !
=> C'est la fin, on enlève tous les OD placés dans la défense du poste et on les investit dans le rayon d'action pour avoir un super bonus de points de contrôle avant sa destruction !

Ce que les postes avancés ne permettront pas

Les fonctionnalités des postes doivent rester limitées afin qu'ils ne deviennent pas des "villes de secours" ruinant le côté dangereux du désert.

• On ne peut pas passer la nuit dans un poste. La ville doit rester le seul havre de sécurité.
  Prévoir dans l'interface une porte toujours ouverte pour faire comprendre ce point au joueur.
• Éventuellement cependant, les postes pourraient permettre le camping, avec des risques similaires à ceux de Hordes. Il serait impossible de camper sur d'autres zones (contrairement à Hordes).
• Pas du puits, atelier, chantiers.
• Impossible d'y déposer des objets autres que les objets de défense.

Affichage dans l'interface

Ajouter dans le volet "Communications" un onglet "Postes". Il listera l'état de tous les postes de la carte (points de vie, défenses, points de contrôle fournis, nombre de zones couvertes).

Améliorer la visibilité de la ville en arrivant sur la case

En arrivant sur une case contenant une ville ou un autre bâtiment, un simple bouton "Entrer en ville" s'affiche sous la flèche de déplacement. Il manque de visibilité.

=> Solution : à l'arrivée sur la case, remplacer le contenu habituel du bloc "Se déplacer" (la croix et le compteur de points d'actions) par un gros bouton "Entrer en ville" (carré avec une icône), accompagné de 2 phrases explicatives/RP.
En dessous, ajouter un lien "Passer mon chemin" qui rétablira l'affichage habituel du paddle (en javascript) et permettra de quitter la case.

Notre pseudo affiché comme un autre joueur

(signalé par Alexis) La case affiche notre pseudo comme si c'était un autre joueur :

Mini-carte pour connecter sa maison

Actuellement, pour connecter la maison à une ville, la manip n'est pas très intuitive :

1. Le joueur à l'intérieur de la ville voit qu'il peut connecter sa maison
2. Le joueur doit ressortir de la ville, aller sur une case voisine et planter sa tente
3. Puis entrer dans sa tente, aller dans l'onglet "Ville" et cliquer sur le bouton "connecter ma maison"

=> Amélioration à faire : depuis la ville, dans l'onglet "Chez moi", supprimer le message disant qu'on peut connecter sa maison et le remplacer par une mini carte montrant la ville au centre et les 6 cases alentour. En cliquant sur une des zones, le joueur peut directement planter sa tente. La connexion tente/ville se fait alors automatiquement.

Déplacements non affichés pour les visiteurs

Les déplacements en temps réel des joueurs sur la carte ne fonctionne pas si le visiteur n'est pas connecté.

Cause : dans scripts.js, la fonction UpdateMapRealtime() plante, à cause de l'absence de ces balises dans le HTML :

let citizenPseudo = document.getElementById("citizenPseudo").innerHTML,
    citizenId     = document.getElementById("citizenId").innerHTML;

Solution à appliquer : générer toujours ces balises, y compris lorsque le visiteur n'est pas connecté, ou est connecté mais n'a pas créé de citoyen.
Vérifier ensuite les effets de bord car ces balises seront vides.

Fusée de détresse (incitation aux interactions)

Quand un joueur est bloqué par les zombies, ajouter un bouton « Fusée de détresse » qui va alerter les autres joueurs.
Le joueur bloqué est invité à rédiger un message en accompagnement (via un champ texte dépliable sous le bouton, ne pas le renvoyer à l'espace de discussion : trop compliqué).

Les autres joueurs recevront alors une notification : « X est bloqué par les zombies en zone 0:0. Voulez-vous le rejoindre afin de sécuriser la zone et le débloquer ? » + l'éventuel message personnalisé de l'auteur de l'appel.

Les joueurs qui viennent le secourir seront récompensés par un objet aléatoire ou un regain de PA.
Prévoir cependant des anti-abus pour ceux qui se bloqueraient volontairement pour générer des récompenses...

Discussions : Notifier les mentions @pseudo

Une fois que les mentions @pseudo auront été implémentées, il faudra ajouter une notification pour que le joueur voie quand une nouvelle mention est faite :

• ajouter une notification (chiffre) sur la barre « communications »
• ajouter une notification (chiffre) à côté de l’onglet « Perso » du volet des communications

Coût des chantiers par nombre de citoyens

Le nombre de citoyens d'une ville n'étant pas connu à l'avance, les ressources nécessaires pour un chantier ne peuvent pas être calibrées dans l'absolu.

=> Solution : prévoir plusieurs chantiers, calibrés en fonction des différents nombres possibles de citoyens (chantiers pour 1 habitant, pour 2, etc.).

Ne pas interdire à des citoyens de construire des chantiers « supérieurs » (ex : 1 citoyen doit pouvoir tenter de construire un chantier prévu pour 3 citoyens). Cela crée un challenge intéressant. Le niveau est juste un moyen de calibrer les ressources sans subir un entre-deux (chantier trop coûteux ou pas assez).

Les Points-relais (bonus)

Les points-relais sont des zones distribuées aléatoirement sur la carte qui donnent un bonus quand on en atteint un. Ne pas confondre avec les postes avancés (#25). Chaque point-relais donne un bonus parmi :

• Regain de PA
• Furtivité : le joueur gagne 4 points de contrôle jusqu'à son retour en ville

Chaque point-relais donne toujours le même type de bonus. Pas d'aléa ni de choix du joueur.

Intérêt : place les joueurs face à des dilemmes : nous voulons explorer telle région de la carte, mais faire un crochet par le point-relais nous donne un bonus...

Les points-relais sont placés aléatoirement au début de la partie et ne peuvent pas être construits par les joueurs (ils perdraient leur intérêt).

Tuto de démarrage dans le désert

L'interface comporte beaucoup d'éléments pour un nouveau joueur.
=> Il faudrait qu'ils ne soient affichés que progressivement aux nouveaux joueurs, au fur et à mesure de leur avancement dans un tuto.
=> A chaque étape, une très courte bulle (1 ou 2 phrases) explique l'intérêt de l'action qui vient d'être faite. Ne pas faire de long texte, il ne serait pas lu.

1. Au début, aucun des boutons d’action (bouger/zombies/humains…) n’est visible, sauf « Fouiller »

2. Le joueur lance une fouille et trouve un objet
   => Une bulle explique l'importance de fouiller pour trouver des objets
   => Faire apparaître le bouton d'action "Bouger"

3. Le joueur se déplace. Un zombie est sur la zone.
   => Faire apparaître le bouton d’action « zombies »
   => Une bulle explique que le déplacement est gratuit s'il n'y a aucun zombie sur la case mais coûte 1 PA sinon.

4. Demander au joueur de quitter la zone. La case suivante contient + de 5 zombies => le joueur est bloqué
   => Une bulle explique le principe des points de contrôle

5. Demander au joueur de tuer un zombie. Il se débloque.
   => Une bulle explicative explique qu’il vaut mieux appeler quelqu’un à l'aide pour se débloquer sans gaspiller de points d'action

6. Sur la case suivante, le joueur est à nouveau bloqué par des zombies trop nombreux pour être tués à coup de PA
   => Apparition du bouton d'action "Humains"
   => Une bulle lui conseille de demander de l’aide sur l'espace de discussion.
   => Un citoyen-bot le rejoint et le débloque.
   => Une bulle lui rappelle l'importance de sortir en groupe + Le fait que les autres joueurs sont (normalement) des humains.

7. Le joueur trouve une ville (ou bien, lui faire planter sa tente ?)
   => Apparition du bouton « Bâtiments »

8. Le joueur entre en ville.

A faire ensuite : tuto similaire à l'intérieur de la ville, pour faire découvrir la ville progressivement
=> Tuto à rédiger

"Il n'y a plus de place dans cette ville"

On peut rencontrer le message "Il n'y a plus de place dans cette ville, vous ne pouvez pas y entrer" en tentant d'entrer dans une ville alors qu'elle n'est pas pleine.

=> Raison probable : le compteur du nombre de citoyens présents dans la ville n'est pas décrémenté lorsqu'un citoyen meurt en ville.

ZombLib - Méthode générique d'appel des API

Idées d'améliorations pour une future V2 de la ZombLib :

Faire une fonction générique unique pour appeler les API :
call_api(string $api_name, string $action, array $parameters)
Ex : get_map($map_id) devient call_api('maps', 'get', $map_id)

Et supprimer toutes les méthodes spécifiques appelables par call_api() (get_city(), move()...)
(casse la compatibilité mais normal pour une version majeure)

=> Avantages :

Lib plus légère de plusieurs dizaines de lignes => plus lisible et plus simple à porter dans d'autres langages
Plus besoin de mettre la lib à jour chaque fois qu'une nouvelle action est ajoutée dans le jeu
Evite toute divergence entre le nom de la fonction et le nom de l'action dans l'API
Simplifie le code côté utilisateur

=> Inconvénient : syntaxe un peu plus lourde de call_api

API "maps" V2

Dans la future V2 de l'API, l'API "maps" ne devrait pas retourner la liste des objets (économiserait une jointure et une boucle).
=> L'API maps devrait juste retourner le nombre d'objets sur la case (clé "items_amount" par exemple)
=> La liste complète des objets ne devrait être disponible que dans l'API "me" (v. point suivant)

Inviter des joueurs à rejoindre la ville

Dans l'interface de la ville > menu "Habitants", prévoir un moyen d'appeler des joueurs supplémentaires à rejoindre la ville.

=> Dans le premier emplacement vide de joueur (dans la section "Habitants"), ajouter un gros bouton "+". Cliquer dessus affiche un champ texte dans lequel le joueur peut écrire un message appelant les autres joueurs à rejoindre sa ville.

=> Le champ peut être prérempli par un message tout prêt (mais modifiable) afin de faciliter l'envoi. Les messages personnalisés garderont l'avantage car ils attireront davantage l'attention des autres joueurs.

=> Le message s'affichera dans l'espace de discussions + envoi d'une notification à tous les joueurs.

=> Après l'envoi, le message restera affiché dans l'emplacement vide (section "Habitants") afin que les occupants de la ville le voient et le retrouvent facilement. Possibilité de répondre à ce message comme dans un fil de discussion classique.

=> Prévoir la possibilité d'inviter spécifiquement un joueur.

Présentation plus claire des zombies sur la carte

Au lieu d'afficher le nombre de zombies sur chaque zone, nouvel affichage :

• Point 1 : Sur une case où se trouve un joueur : entourer le joueur de X petits ronds vides. Chaque rond représente 1 point de contrôle.
  Chaque zombie sur la case remplit un rond, le rendant rouge.
  Si tous les points sont remplis, cela signifie que le contrôle de la zone est perdu.
  => Intérêt : le principe des points de contrôle devient plus simple à comprendre pour le joueur (similaire à une jauge).

• Point 2 : Pour les cases où aucun joueur ne se trouve : afficher 1 point rouge par zombie, disposé aléatoirement. Pas de cercles à remplir ici puisqu'il n'y a pas de points de contrôle humains.

Plantage du temps réel pour l'utilisateur non connecté

Quand le visiteur n'est pas connecté à son compte, la requête pour l'actualisation de la carte en temps réel plante (voir dans la console d'erreur du navigateur).

Cause : le visiteur n'étant pas connecté, les paramètres passés dans l'url concernant son compte sont vides. En conséquence, plantage au niveau de la méthode HtmlMap->is_player in zone() (dans /view/HtmlMap.php).

Onglet "Défenses totales de la ville"

A l'intérieur de la ville, ajouter un onglet "Défenses" dans la partie "Grande porte". Il détaillera la répartition des points de défense de la ville :

• Chantiers de la ville : X pts [Points de défense apportées par les chantiers communs]
• Défenses des habitations : X pts [La ville bénéficie de 50% des points de défense des maisons individuelles des joueurs]
• Objets de défense : X pts [Chaque objet de défense placé dans le dépôt de la ville augmente les défenses de 2 points]

• Ajouter un avertissement tant que la porte de la ville est ouverte (0 points)

Le clic sur chaque élément affiche une explication + un bouton pour amener à la partie correspondante (chantiers, maison personnelle...).

Chantier replié à chaque ajout de PA

(signalé par Endy sur le Discord)

Mettre plusieurs points d'action dans un chantier n'est pas pratique à cause des chantiers dépliables. Quand on ajoute 1 PA dans un chantier, la page se recharge et il faut à nouveau re-déplier le chantier pour mettre le PA suivant.

=> Solution à appliquer : le clic sur le bouton "Ajouter un PA" ne devrait pas recharger toute la page. Faire la requête en Ajax.

Compatibilité interface PC/mobile

Idées par rapport à l'adaptation de l'interface sur PC et sur mobile :

• Le jeu doit être jouable sur PC et sur smartphone
  • Le smartphone ne peut pas être négligé, ce serait se couper d'entrée de jeu d'un grand nombre d'utilisateurs.
  • Mais le PC doit avoir son ergonomie propre : bien qu'il représente moins de connexions en volume, il reste plus confortable à utiliser.

Sur PC :

• L'interface du jeu doit exploiter la grande taille de l'écran. Les sites qui négligent le support PC, sous prétexte que la majorité des connexions se font sur mobile, s'y affichent comme sur un mobile et sont pénibles à utiliser (polices énormes, place gaspillée à l'écran, obligation d'utiliser l'ascenseur en permanence, etc.). Cependant, plus l'interface PC sera pensée "mobile" et plus le responsive design sera facile à implémenter (moins d'éléments à déplacer).

Sur smartphone

• Le smartphone à droite de la carte peut servir de "laboratoire" pour une interface mobile. sur mobile, l'interface du jeu pourrait d'ailleurs imiter l'ergonomie des smartphones : un écran d'accueil avec des icônes amenant aux différentes parties du jeu comme si c'était des applications.

• Sur mobile, il faudra sans doute renoncer à afficher la carte complète, même tronquée, car il n'y aura jamais assez de place. Juste afficher la zone où est le joueur.

Changer la couleur du compte à rebours

La barre de compte à rebours avant l'attaque (en haut de la carte) est actuellement mauve. Cette couleur ne s'accorde pas bien avec celles des autres éléments du jeu.

=> La passer dans une teinte bleu foncé comme le cadre de connexion ?

API "me" V2

Dans la future V2 de l'API, ajouter dans l'API "me" un nœud "myzone"** qui contiendrait :

• la liste complète des objets au sol sur la case
• la liste des autres joueurs sur la même case, avec leurs caractéristiques complètes :
  - objets dans leurs sacs (utile pour une éventuelle fonction "voler un objet")
  - leur santé, points d'action, etc. (évitera de devoir naviguer entre les API "me" et "citizens")

API "citizens" V2

Dans la future V2 de l'API, l'API "citizens" ne devrait pas retourner les récompenses (pictos) des joueurs : cela alourdit la requête côté serveur et n'est pas utile la plupart du temps.
=> Recycler l'actuelle API "pictos" (actuellement dépréciée) et la renommer en "profile" pour être plus générique

API "cities" V2

Dans la future V2 de l'API, l'API "cities" devrait être allégée pour de meilleures performances :

• Quand on récupère toutes les villes d'une carte (&map_id=..."), supprimer les nœuds lourds et superflus :
  - Supprimer le nœud "citizens_ids" (économisera une jointure + une liste)
  - Supprimer le nœud "constructions" (économisera une jointure + une liste)
  - Supprimer le nœud "well_current_water" (pas spécialement gourmand mais inutile pour afficher la carte)
• Mais quand on récupère une ville en particulier (&city_id=...), il faut évidemment conserver ces nœuds (ils sont indispensables pour afficher l'intérieur d'une ville).