Reboot d'ECLERD sorti (beta)
#11
Hum, pas sûr pour l'histoire de "je ne fais rien car j'ai peur". A mon sens, oui, on aura toujours tendance à garder 6 mois de temps en réserve, au cas où, mais ce n'est pas fondamentalement un problème (il faudra bien équilibrer les choses pour que le mécontentement de la population pousse suffisamment les joueurs à dépenser leur temps et à ne pas en garder "trop" en réserve)

Pas sûr que cela complexifie franchement le gameplay (je pense que tu te prends trop la tête en fait 16 ) car tu vas aussi pouvoir lancer tes actions (chantiers, lois, recherches, etc) et faire avancer le temps d'un coup pour en voir directement les résultats (plutôt que de devoir attendre 1 semaine IRL que les choses se passent, oublier quel était ton plan, et subir les perturbations inattendues du reste du jeu).

Le code n'est pas complexifié, ça, je te le garantie car l'avancement du temps "en continue" sera une bien plus grosse ch*asse à gérer: il ne faut pas locker le jeu pendant la simulation, simuler toute la planète d'un coup (et y'en a de la complexité!), s'assurer que les joueurs aient des pages intègres (aka que tous les éléments qui la composent soient à la même date). Ca, c'est franchement une chiée à gérer (d'autant que je n'ai pas vu beaucoup de "si" dans mon message qui concerne le code? ils concernent surtout les situations réelles qui peuvent s'enchainer, mais toutes ces situations sont gérées par les 3 seules règles citées en bas de message).

Oui, ECLERD avait un soucis, mais il est plus proche de celui amené par une simulation globale continue que par l'attribution d'une timeline propre à chaque région: comme la planète entière n'est pas simulable dans un temps acceptable (et encore moins simulable en continue, jour ingame par jour ingame), j'ai dû tenter de tricher, de simuler des trucs par morceaux, et de faire de grosses "simplification" du modèle de données. Résultat, le jeu ne correspond pas à ce qui est annoncé, et les simplifications entraîne de gros impacts sur l'évolution de la planète...
Si j'intègre de base le fait que chaque région a sa propre timeline, j'obtiens un jeu bien plus "scalable" (si j'ai besoin de plus ou de moins de région, ce sera facilement gérable car il n'y a pas de "simulation de tout") et si je le présente comme tel aux joueurs, alors ce qui se passe dans le code collera à ce que je présente aux joueurs.

C'est vrai que ça va faire une originalité majeure, à expliquer et faire passer auprès des joueurs et oui, certains n'essayeront peut-être pas le jeu à cause de ça. Mais j'ai bon espoir que, arrivant à présenter ça de façon simple et claire, j'aurai peut-être plus d'impact "émotionnel" auprès des joueurs qui tenteront le coup. Dis autrement, si je n'implémente pas ça, j'ai un banal jeu comme les autres, aux règles hyper classiques, et passé les 2 premières semaines, tout le monde aura oublié ce jeu. Si j'implémente une règle originale comme celle-là, j'aurai peut-être une place de "premier" plus marquante, quitte à ce que d'autres derrières reprennent le concept, l'améliore et aient, eux et non moi, du succès.

Bref, je garde ce que tu me dis en tête, mais je tente le coup (d'autant, au fait, que le jeu original 3e Millénaire fonctionne aussi ainsi: on a un calendrier qui certes avance tout seul, mais on peut là aussi passer au jour suivant, au mois suivant ou à l'année suivante, et c'est intuitif; l'intérêt étant de ne pas poireauter des heures pour voir évoluer sa pyramide des âges, ses chantiers, ou sa production).

PS: au pire du pire, si cela ne marche pas (auprès des joueurs ou dans le code), je pourrais toujours supprimer l'action d'avancer le temps aux joueurs, et la refiler à un CRON ou assimilé, qui avancera le temps de toutes les régions d'un coup 16

PS2: Je pense que tu te prends la tête (comme je me la suis un peu prise en réfléchissant à l'idée) car tu restes sur l'optique de "le jeu doit être réaliste" et là, oui, les timeline par région peuvent donner lieu à des "incohérences" temporelles. Mais au fond, osef, c'est un jeu: s'il est simple à comprendre et à jouer, et qu'il est fun d'y passer du temps, c'est gagné 2
Répondre
#12
(03-27-2019, 09:25 PM)Xenos a écrit : Le code n'est pas complexifié, ça, je te le garantie
oki 2

(03-27-2019, 09:25 PM)Xenos a écrit : C'est vrai que ça va faire une originalité majeure, à expliquer et faire passer auprès des joueurs et oui, certains n'essayeront peut-être pas le jeu à cause de ça. Mais j'ai bon espoir que, arrivant à présenter ça de façon simple et claire, j'aurai peut-être plus d'impact "émotionnel" auprès des joueurs qui tenteront le coup. Dis autrement, si je n'implémente pas ça, j'ai un banal jeu comme les autres, aux règles hyper classiques, et passé les 2 premières semaines, tout le monde aura oublié ce jeu. Si j'implémente une règle originale comme celle-là, j'aurai peut-être une place de "premier" plus marquante, quitte à ce que d'autres derrières reprennent le concept, l'améliore et aient, eux et non moi, du succès.
sur le principe de "nouveauté" je suis complètement d'accord avec toi

(03-27-2019, 09:25 PM)Xenos a écrit : Bref, je garde ce que tu me dis en tête, mais je tente le coup
tu as raison il faut toujours garder en tête ce que je dis :p

(03-27-2019, 09:25 PM)Xenos a écrit : PS2: Je pense que tu te prends la tête (comme je me la suis un peu prise en réfléchissant à l'idée) car tu restes sur l'optique de "le jeu doit être réaliste" et là, oui, les timeline par région peuvent donner lieu à des "incohérences" temporelles. Mais au fond, osef, c'est un jeu: s'il est simple à comprendre et à jouer, et qu'il est fun d'y passer du temps, c'est gagné 2

non monsieur je ne réagissais pas sur l'optique réaliste, mais réellement sur les biais potentiels concernant les interactions entre joueurs (d'où ma question, si tu avais dit 0 interaction ou uniquement échange sur un "hôtel des ventes en fonction du niveau technologique, etc..." j'aurais dit vas y fonce)

Là je le sens pas (ca vient des tripes, j ai pas de démonstration forte) mais tu peux tenter je ne me sens pas vexé 34

Après tout si c est vraiment simple à implémenter dans ton code, pourquoi se priver du test en condition réelle mais je te conseille d'organiser des cas tests dédiés à chercher toutes les manières qu'à un / n joueurs à planter un autre joueur grâce à ce système

bises
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#13
Ouep, il faudra que je check quelques cas.

Mais ça m'a fait penser à une autre approche possible: vu que les litiges ont lieu dans les interactions entre régions (que ce soit d'un joueur à l'autre ou entre les régions d'un même joueur), je pourrai considérer que les durées de ces interactions ne sont pas des durées in-game, mais réelles?! Par exemple, l'armée de la région A part attaquer la région B. Elle va mettre 2H IRL à s'y rendre, faire sa mission (instantanée), et revenir (2H de temps de retour). Et ce, peu importe les changements de date des différentes régions? Ca peut être une autre piste potentielle, qui a l'avantage de décorréler les deux lignes de temps et de permettre éventuellement de les équilibrer.

Et si la mission n'est pas instantanée, il faudra que j'ajuste la règle (mais le plus simple serait alors probablement de rendre toutes les missions militaires instantanées).
Répondre
#14
pour moi c est pareil

il faut attendre deux heures soit
mais en deux heures irl, je peux accélérer le temps pour produire des troupes pour me défendre (ou pour lancer une deuxieme attaque ou, ou ou, ...)

toujours le même biais intuitif, même si moins impactant, certainement
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#15
Oui, cela va dé-inciter les joueurs à attaquer les faibles qui ont du "temps d'avance"... mais avoir trop de temps d'avance = être en retard par rapport à la date du serveur, ce qui implique que la population n'est pas satisfaite (parce que laisse notre pays "à la traine") alors on prend un autre risque (politique). L'intérêt est de balancer les deux. Après, ça reste un grand classique que de prendre un gros gros risque en attaquant les joueurs actifs plutôt que les inactifs. C'est plutôt une bonne chose IMO: les joueurs iront plutôt frapper des absents, et non des joueurs présents, ce qui devrait limiter la rage de ceux qui se sont fait pétés (ils sont de toute façon inactifs donc bon).

En revanche, un "soucis" qui me semble plus problématique et auquel je viens de penser est le suivant: le temps n'avançant pas sans que le joueur ne soit là, les stocks/production n'avancent pas non plus, donc, il y aura probablement moins d'intérêt à piller les ressources ennemies.... Le schéma-type de jeu étant "Joueur B vient, avance le temps, produit et consomme ses stocks dans la foulée vu qu'il est là", quand joueur A sera là et voudra l'attaquer, joueur B n'aura déjà plus de stocks...
Donc, il me faudra des missions militaires plus variées que juste le pillage. Cela justifiera donc bien les missions "Génocide" (je défonce la population du joueur B, qui sera bien emmer*é quand il reviendra jouer même s'il a plein de temps à dépenser), "Capture" (je prend le contrôle de sa région par la force), "Destruction" (je défonce ses bâtiments et il ne produira plus rien, même s'il a plein de temps en stock). Si vous avez d'autres idées, je suis preneur.
Répondre
#16
je viens de penser une autre solution (que, en écrivant, je me rappelle avoir déjà vu, mais où ?) ce serait de créer des " instances d'univers " à échelle de temps différentes

aka, ce n'est pas le joueur qui accélère / décélére

c est l'univers qui a sa propre vitesse et les joueurs qui s'installent dans cet univers le choisissent en fonction de son temps ?

après ca peut etre des vitesses non uniques (?!?) genre pour les noctures (ou les ricains, ou les ...) de 6h (Lille) à 21h (Toulouse) 1h irl = 1an in game, de 21h(Menton) à 24h(Strasbourg) 1h irl = 5an in game et de 24h (Brest) à 6h(Clermont Ferrand) 1h irl = 2ans ig

éventuellement même tu peux permettre (payant ?) des transferts d'un univers à l'autre si le temps in game est commun (genre on en est à 3256712 ans dans les deux univers : nocturne et ultrarapide

mais tu as trouvé toi même une nouvelle dissonance avec ces histoires de stock. Je pense pas que ce soit le plus grave tu pourrais aussi imaginer un truc du genre : t as le droit d'accélérer / décélérer une fois toutes les 6 heures. Ca voudrait dire que quand tu déco, le temps est toujours accéléré, et du coup le stock consommé pendant la session du joueur se refait en son absence.
Après via des recherches scientifiques, ou des consommations / sacrifices / etc.. tu peux imaginer d'avoir des "points de temps" qui permettent d'avoir l'action de gestion du temps
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#17
Ogame en avait fait (des univers x2, x4 x10 etc), mais je trouve que le concept n'est pas intéressant: un gameplay adapté à un x1 ne le sera probablement pas à un x10 IMO

Gérer des échelles de temps variables dans la journée, c'est intéressant, mais ça me semble très compliqué tant à mettre en place qu'à expliquer. Mieux vaut faire alors un système de "tours" et en mettre moins la nuit (aka, le jeu est en tour par tour, et on avance d'un tour à 8h, à 12h, à 16h, à 18h, à 19h, à 21h, à 23h et à 4h du mat', en heure française: ça permet d'avoir plus de tours dans la journée, quand on est dispo, tout en gardant un tour "joker" à un horaire improbable pour les plus assidus).

Transférer des choses entre univers étanches, je n'aime pas perso, c'est un risque à totalement défoncer son équilibre de gameplay :/

Attention hein, on "n'accélère" pas le temps ici: on passe juste des tours (des jours) à sa guise. Il n'y a, en un sens, pas de notion de temps continue, ce sont des tours qu'on passe comme on veut, exactement comme des points d'action (c'est juste un nom fançy que je leur donne). Faut vraiment le voir ainsi: un nom sympa aux sempiternels points d'action 16
Répondre
#18
Je viens de penser à une autre idée supplémentaire au sujet du temps: je pourrai le faire avancer automatiquement, à la vitesse du jeu, lorsque le joueur est présent ?! En d'autres mots, par une requête ajax en arrière-plan qui ferais avancer le temps d'1 journée toutes les X minutes, à la même vitesse que le serveur du jeu. Ainsi, on aura l'illusion du temps qui avance quand même tout seul quand on joue (mais on garderait le contrôle de l'écoulement du temps pour ne pas poireauter des plombes pour rien, et pour ne pas perdre son pays quand on est en vacances).

Ca me semble sympa comme concept, non? 2
Répondre
#19
Pour moi c était par défaut ?
Par contre je dirais pas de requête dédiée
Js côté client + contrôle du temps lors des appels serveurs (lancer des actions etc...)
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#20
En fait, j'hésite car c'est assez chiant d'avoir le temps qui avance tout seul pendant qu'on essaie de gérer son pays... Donc je pense que je vais faire au plus simple, et laisser le joueur faire avancer de lui-même le temps, de son propre chef (sans compter qu'en dev, c'est pratique de ne pas avoir tout qui bouge et change tout le temps!)

Je n'ai en revanche pas compris ta réponse: "pas de requête dédiée + js côté client", c'est incompatible?! Que trigg ton JS client dnas ce cas là?!
Et impossible de faire un "controle (check?) du temps" lors des appels serveurs: je ne sais pas pendant combien de temps le joueur était là sur sa page
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)