[Reboot] Cités Myrmécéennes

[Trapez]

Quel avantage / inconvénient au joueur défenseur d(e ne pas) envoyer toutes ses fourmis ?

se référait à :

Le joueur B ne connaît pas le nombre de fourmis qui attaquent, il doit donc définir un nombre de fourmis de défense qui seront envoyés pour combattre.

Le système de pression avec la voix d'ogre baveux est sympa, il faudrait préciser avec combien d'unités il me met la pression.

Je ne penses pas que ce soit une "bonne" chose de mon point de vue: si tu envoie une seule fourmis faire l'ogre pour demander une ressource très rare en coup de bluff, le joueur défenseur n'aura qu'à dire non, tuer la fourmi, et on en parle plus.

Je pense qu'on est d'accord, ou je n'ai pas compris :p Pour moi l'attaquant dans ce cas doit dire combien de fourmis il a envoyé pour réclamer une ressource. Sinon le défenseur pourrai dire oui alors qu'il a une seule fourmi à ses portes.

D'ailleurs tu pourrai peut-être mettre un système non-exacte sur le nombre d'attaquant de manière générale : exemple > il y a 235 attaquants, tu dis au défenseur qu'il y entre 235 - random(0;0.5)*235 et 235 + random(0;0.5)*235 d'attaquants. Cette valeur de 50% pouvant être diminuée grâce à la construction de tours de guets ou autre.

[niahoo]

Je ne trouve pas ça super au final de se dire "tiens je vais passer sur le jeu voir où en est la construction de ma nouvelle ligne de transport inter-arbres" et pouf, ça déclenche une attaque et tu te retrouves à devoir gérer ça alors que tu avais juste sorti ton smartphone aux chiottes.

Je trouverais mieux de décoreller la présence en ligne et le déclenchement des attaques. Par exemple, tu te connectes, tu vois qu'il va y avoir une attaque, tu peux choisir de l'activer mais tu vois aussi le délai maximum après lequel l'attaque sera automatiquement déclenchée et tu peux laisser comme ça.

[Xenos]

IMO, le random sur le nb d'ennemis n'a aucun intérêt, d'autant plus si cela ne coûte rien de "voir" l'ennemi. Si le nb d'ennemi est 235+/-50%, alors je peux statistiquement converger vers la valeur réelle simplement en regardant 50x le nb d'ennemi, et en prenant la moyenne (c'est valable quelque soit le %, et même si le % est déséquilibré, ie -20%/+50% il faut juste faire une moyenne pondérée).
Je préfère, perso, un système type "j'ai plus ou moins de renseignements sur l'ennemi en fonction de [truc de gameplay à rajouter]". Ie, je connais tjrs le nb d'ennemis, mais si je ne suis pas assez fort en "espionnage", alors je ne connais pas le type de ces ennemis, ni leur position, ni leurs PV. Mais si je suis fort en "espionnage", je connais ces infos de manière exacte.

Je suis d'accord avec niahoo, devoir se dire "si je regarde mon compte/me connecte, ça va déclancher des trucs que je ne connais pas", c'est bof attrayant... J'aime beaucoup l'idée de pouvoir "activer" l'attaque : )

Perso, je compte faire quelque chose de similaire pour Variispace. Dans l'idée, je ferai bien un système où les deux armées se font face, sans s'attaquer. Chaque joueur peut alors préparer son plan de bataille (ou se tirer vite fait), et la bataille a lieu quand l'un des deux joueurs valide son plan d'attaque (ça peut donner un effet de "concurrence" en temps réel entre les joueurs: je valide rapidement mon plan d'attaque même s'il n'est pas parfait pour éviter que l'autre ne valide le sien, ce qui me mettrait certainement en position inférieure)
Edit: bon, ok, pas sûr que ça ait de rapport en fait, tant pis, oublis cette dernière partie

[Trapez]

je peux statistiquement converger vers la valeur réelle simplement en regardant 50x le nb d'ennemi, et en prenant la moyenne

Il ne faut pas que cette valeur soit générée à chaque fois, juste lors de la première observation des troupes.

C'est vrai que ça peut être embêtant de se dire : j'ai 2 minutes, et qu'au final tu doives gérer un truc qui t'en prends 10. Mais qui a dit que ça prendrai beaucoup de temps à gérer une défense ?

[niahoo]

" Mais qui a dit que ça prendrai beaucoup de temps à gérer une défense ? "

On sait pas trop, mais il n'y a pas que le fait de cliquer sur "Défendre" qui compte. Il faudra peut-être mobiliser des troupes, et aussi changer les priorités de productions, notamment si on prévoit de perdre.

[Chbig]

A un collègue Fan de fourmis également

Je te souhaite plein de réussite et de courage pour le développement de ton projet !

[Maz]

D'ailleurs tu pourrai peut-être mettre un système non-exacte sur le nombre d'attaquant de manière générale : exemple > il y a 235 attaquants, tu dis au défenseur qu'il y entre 235 - random(0;0.5)*235 et 235 + random(0;0.5)*235 d'attaquants. Cette valeur de 50% pouvant être diminuée grâce à la construction de tours de guets ou autre.

Une éventualité envisageable :programme:

Je préfère, perso, un système type "j'ai plus ou moins de renseignements sur l'ennemi en fonction de [truc de gameplay à rajouter]".

Un mix des deux est peut-être une bonne solution: la connaissance d'une fourchette du nombre de fourmis, genre - de 50, 50-150, 150-500, etc...
+ des données sur l'attaquant: niveau, nombre de combats, gagné/perdu, nombre d'attaque, etc... Tout ça pouvant être amélioré par des améliorations.

Je suis d'accord avec niahoo, devoir se dire "si je regarde mon compte/me connecte, ça va déclancher des trucs que je ne connais pas", c'est bof attrayant... J'aime beaucoup l'idée de pouvoir "activer" l'attaque : )

Pas pensé au chiottes! Désolé!

Perso, je compte faire quelque chose de similaire pour Variispace. Dans l'idée, je ferai bien un système où les deux armées se font face, sans s'attaquer. Chaque joueur peut alors préparer son plan de bataille (ou se tirer vite fait)

J'ai aussi pensé à faire un "pierre<feuille<ciseau" avec un peu de gamedesign en optant pour trois positions. À l'époque j'avai joué à un jeu EleveTonPGM(Pro-gamer) qui opérait dans un univers Counter-Strike. Lors des défis: tu choisissais entre trois posture à adopter: Le campeur se fait buter par le Snipper, Le Snipper par le Rusher, et le Rusher par le campeur: campeur<sniper<rusher.

Cela ne détermine pas à lui seul l'issue du combat mais améliores grandement les chances. Dans un jeu de fourmis par exemple ça pourrais donner +30% d'attaque par exemple. Ainsi un nombre inférieur de fourmis pourrait gagner.

A un collègue Fan de fourmis également

Bernard Werber as fait des merveilles pour la protection des fourmis

[Maz]

Salut.

Pour en informer les personnes non-présentes sur Discord: je reviens à l'attaque!

J'ai repris le développement de mon jeu. Non sans motivation mais mon principal but est de développer mes compétences en TDD et récupérer celles perdu en SQL à force d'utiliser les ORM.

Le projet est donc repris de zéro (pour dire vrai : là où je l'avais laissé à j tests et premières requêtes, je vais mettre à jour le premier message de ce post dans la journée pour afficher mes milestones sur je cocherais au fur et à mesure de l'avancement du projet niveau TDD.

À l'heure actuel la partie Nursery est quasiment clôturé : je peut faire naître des oeufs, suivre leur évolution durant les 3 stades(oeuf/larve/nymphe) et enfin les sacrifier pour générer de la nourriture pour la cité.

[Maz]

Hello!
Le projet suis son cours jusque là, je trouve beaucoup de motivation avec le TDD/MySQL comme je m'y attendais.

Mes tests sont réalisés/validés déjà sur plusieurs blocks du jeu comme vous pouvoir le voir sur la photo, certains totalement inutiles (AntsCreation) car très court et sur des fonctions très simples, mais c'était mes premiers pour comprendre le TDD.

J'ai aussi pu entrevoir les avantages du TDD lors d'une refacto-bazooka qui a fait foiré de l'autre côté certains tests.

Quelques-uns de mes tests: testUserCanGetAllAchievements, testSacrifyEggsIncreaseFood, testOldReadMessagesAreDeletedFromDatabase

Et niveau SQL j'ai pondu deux requêtes sympa.
La première remplies automatiquement les achèvements en récupérant les stats du joueur directement sur la table cities_stats et en les comparant avec la listes des achèvements enregistré sur la table, je n'ai pas besoin de lui préciser qu

Code PHP :

<?php 

protected function checkForAchievementsValidation($achievement_type): void

{

    // Sécurisation de la variable $achievement_type supprimé dans ce message

    $select = DB::insert(

        "INSERT INTO achievements_cities(city_uuid, achievement_uuid, date_earned)

        SELECT

            stats.city_uuid city_uuid,

            achievements.uuid achievement_uuid,

            NOW() date_earned

        FROM achievements_cities pivot



        RIGHT JOIN achievements ON pivot.achievement_uuid = achievements.uuid

        LEFT JOIN cities_stats stats ON stats.city_uuid = ?



        WHERE achievements.achievement_type = ? AND achievements.amount <= stats.${achievement_type}

        AND pivot.city_uuid IS NULL", [$this->uuid, $achievement_type]);

} 

[Maz]

Système de déplacement des groupes de chasses sur la carte: ok!
Les fourmis se déplaces et engagent les combats avec les mobs présent, et les mobs se font dérouillé à coup de fusil (j'avais pas d'idée pour l'instant)
L'avancée de mes tests:


Et une requête SQL sur laquelle j'ai passé un peu de temps, je sens déjà beaucoup de bienfait à revenir au source et coder mes requêtes sans ORM

WITH hunts_updated AS (

    UPDATE hunts SET

        updated_at = NOW(),

        position = ST_POINTN(path, step+1),

        step = (step+1)

    WHERE

        (created_at < NOW() - CONCAT(:hunt_speed::INT, ' minutes')::INTERVAL)

      AND

        (updated_at IS NULL OR updated_at < NOW() - CONCAT(:hunt_speed::INT, ' minutes')::INTERVAL)

    RETURNING position, city_uuid, ST_X(position), ST_Y(position), uuid

)

SELECT hunts_updated.*, mobs.uuid as mob_uuid

FROM hunts_updated

LEFT JOIN mobs ON mobs.position = hunts_updated.position;