ShimStar : l'aventure est dans les étoiles

Un sérieux concurrent Black Prophecy.

Aie Aie Aie

BOnjour,

juste un petit mot pour dire que j'ai mis en place un petit forum, pour les questions sur le game design que vous auriez :Shimstar Forum.

Quelques premières questions sont apparus sur l'évolution du personnage, la gestion de la mort...

Maintenant que les problématiques réseau sont résolues (enfin j'espère, il va falloir pousser un peu plus les tests), il faut que je réembarque pas mal de code au niveau du serveur. Code initialement mis au niveau du client pour des facilités de test, et aussi en espérant pouvoir décharger le serveur. Il est clair maintenant que le serveur doit demeurer le garant des données.

Il faut donc que je rapatrie toute la partie collision côté serveur. Pour faciliter le tri, et le travail du serveur, je vais tenter de déclarer un gestionnaire de collision par zone, pour que les collisions au sein d'une zone (asteroide, vaisseau, tir,...) soit géré localement à la zone. Cela permettrait éventuellement de pouvoir dispatcher le travail sur plusieurs serveurs dans le futur... qui sait?

En même temps je suis tombé sur un article, et apparemment CEGUI, cette librairie permettant de faire des gui un peu sympas, a été rebuildé, pour permettre le bind avec du code Python. Ce qui veut dire que je peux potentiellement l'appeler depuis mon jeu python, et proposer probablement un GUI plus sympa qu'aujourd'hui. Il est clair que je galère pour positionner les objets, et réussir à les aligner est toujours une galère monumentale. Malgré tout, je ne partirai pas sur la partie GUI tant qu'une première version ne sera pas jouable. Si je repars dans la refonte des fenêtres, cela va me prendre un temps considérable, juste pour avoir du "plus beau". A voir si les joueurs sont reboutés par la finition....

Ca y est, j'ai repris les rennes de la chose. Une grosse problématique dans les jeux réseaux et de réussir à envoyer toutes les informations aux joueurs, et que chaque client ait des données à jour par rapport au serveur. Si les données sont envoyées de manière séquentielle et permanentes, le réseau est saturé, et le client n'a pas le temps de traiter tous les messages. Le client se met à ramer.

Dans un premier temps, j'avais déporté le calcul des IA sur le client, afin d'obtenir quelque chose de fluide. Mais malheureusement, on se retrouvait avec des décalages importants entre le client et le serveur. Du coup, une fois par seconde, j'envoyais la position de référence calculée et stockée sur le serveur. Conséquence : les vaisseaux faisaient des bonds en arrière.

J'ai donc lu un certain nombre d'articles sur le sujet pour affiner ma compréhension de la chose. Par exemple, j'envoie désormais les positions des ennemis une fois tous les 1/6e de seconde. Mais ce n'est pas sans conséquence. En une fraction de seconde, le rafraîchissement de l'écran se fait un grand nombre de fois, et cela a pour conséquence qu'on voit le vaisseau ennemi bondir d'un point à un autre. Sans compter sa rotation qui se fait de manière saccadée également.

Un mot magique m'a été glissé à ce moment là : interpolation. Il faut que j'ajoute un calcul savant, pour qu'entre 2 envois de position, je calcule les positions intermédiaires pour donner un mouvement fluide. Ce n'est pas très compliqué à mon sens, mais cela demande un peu de travail. Une fois ce travail effectué, je pense que la partie réseau sera en grande partie résolue. Il me restera à retester le lancement de plusieurs clients.

Pour l'instant, pour me divertir, je me suis lancé dans la création d'une petite interface de chat. Petit supplément qui rendra le jeu plus convivial.

Il me reste une todo list (), somme toute importante avant de rendre la chose disponible pour une première alpha test fermée.

Voilà bien longtemps que je n'ai touché à ce beau projet. Il faut dire que mon temps est franchement partagé. Ma petite famille est fort gourmande:p

J'ai de nouveau envie de mettre la main dans du code. Bonne nouvelle!!!

Par contre, il est vrai que projet est titanesque et je me demande toujours quand je m'y remet par où commencer. Une chance, c'est que le code m'a l'air pas trop mal écrit, car j'arrive facilement, et ce malgré des mois d'interruptions, à remettre les mains dans le cambouis.

En fait, l'une des parties, et qui va être essentielle, va être de créer et développer des Intelligences Artificielles. Je pense que ce seront des scripts semi intelligents dans un premier temps, vu mes compétences en IA. Mais c'est vrai que je rechigne à m'y mettre, car je n'ai pas du tout d'expérience, et que cela me parait énorme comme travail vu de loin. D'autant que c'est vraiment une pierre angulaire, car finalement avec un vaisserau on aime friter de nouveaux ennemis qui réagissent un minimum. D'ailleurs à ce sujet, je pense qu'il va falloir trouver un moyen de les rendre difficile mais pas trop, pour garder une jouabilité pour les plus novices.

J'ai encore pas mal de petits points à revoir, corriger, améliorer également avant de m'attaquer à de nouveaux gros chantiers. J'ai commencé à revoir des petits bugs, à améliorer la gestion de certaines fenêtres. En fait, je vais essayer de finaliser tous les points en cours, pour qu'il soit, non pas parfait, mais d'une jouabilité certaine. Si les fonctions existantes fonctionnent, cela permettra d'avoir un socle sur lequel je pourrai agréger de nouvelles fonctionnalités, sans me dire à chaque fois, zut, il me manque ceci cela, et devoir à chaque fois repartir sur d'autres éléments, et m'écarter des fonctionnalités prévues au départ.

Voilà, tout cela pour dire que cela repart peu à peu.

Si vous avez de bonnes idées...

Bonjour,

Voilà de longs moments que je n'ai pas fait une petite bafouille. Le projet continue de vivre. J'ai un fils qui me prend beaucoup de temps en ce moment et avec plaisir.

Bref. En tout cas, cela continue d'avancer. Les fonctionnalités sont de plus en plus longues à développer, et sont moins rapidement démonstratives qu'au début. Autant pour faire une petite maquette, cela a été rapide, autant maintenant pour implémenter les règles du jeu, il faut faire du code, et du côté serveur et du côté client.

Quoi de neuf donc? J'ai commencé l'arbre des compétences. L'idée est qu'une compétence s'apprend le long du temps. Chaque compétence a une durée d'apprentissage selon le niveau. C'est un apprentissage temps réel. Pour les compétences bas niveau, il faudra par exemple 3h pour apprendre une compétence au premier niveau. Je vais voir si cela est viable et intéressant. Cela change des XPs, et du bashage de monstre à gogos. En tout cas, l'interface est faite, de choix de compétences, l'arbre des compétences, la validation au niveau serveur, la sauvegarde de la progression. Ce fut un gros chantier et il manque encore quelques règles de gestion. Néanmoins, le fond est là. La prochaine étape sera d'utiliser ces compétences lors des actions, ou l'utilisation d'équipement, afin d'obtenir des bonus, ou au contraire ne pas pouvoir effectuer l'action.

A côté de cela, je refonds pas mal l'interface, afin qu'elle soit moins brouillonne et plus "pro".

La prochaine fois j'essayerai d'apporter quelques screens

Nombre de lignes:

client: 3969

Server:1923

Oh yeah... J'ai dépassé la barre psychologique des 5000 lignes!

Quoi de neuf, cette fois ci?

Désormais les fenêtres d'infos, les petites fenêtres sont déplaçables. Cela a l'air bête, mais je n'avais pas trouvé de moyen technique facile pour le faire. Grâce au forum de Panda, j'ai pu trouver des exemples, où des gens ont tenté de créer des GUI un peu plus sexy que ce qui est proposé en natif. Donc voilà, peut être que si le besoin s'en trouve, je les rendrai également redimensionnable.

Quoi d'autre? J'ai ajouté la gestion de marchand dans la base. Ils proposent des items par catégorie, pas toutes, cela dépend du marchand, et vous pouvez désormais acheter de nouveaux items pour équiper votre vaisseau. Je vais ajouter rapidement la possibilité de revendre également.

Désormais, quand on détruit un vaisseau, cela laisse des détritus. Ces détritus seront "recyclable". Il faut que j'établisse quelques règles de gestion sur ce qu'on peut récupérer sur un vaisseau détruit : Composants directement, ou matériaux. Pour cela, il va falloir équiper le vaisseau d'un équipement spécialisé dans le recyclage. Ensuite, le marchand prendra tout son intérêt :p hey hey.

Je vais faire un peu de refactoring également sur le code, car je me rends compte que certaines parties ne sont pas assez évolutives. Typiquement, quand je modifie le template d'un vaisseau, il n'est pas répercuté dans le profil du joueur qui le possède.

Un ami à moi m'a donné de riches idées sur l'établissement de l'IA. Apparemment il existe des algorithmes "génétiques" qui donnent des résultats incroyables, et très performant. De ce que j'ai compris, c'est que chaque élément de contexte est valorisé (puissance, rapidité, situation, nombre de vaisseaux dans l'espace,...). La somme de ces éléments de contexte donne une valeur, et cette valeur ensuite est comparé à une attitude, et à des objectifs. En fonction de tout cela, l'IA réagit dans une certaine direction. Mais ce n'est pas figé. Chaque nouvel élément de contexte revalorise son attitude et ses décisions. Cela permet de gérer des situations complexes et inattendues, et permet également de gérer des intelligences de groupe.

J'étais partie dans le scriptage de tous comportements possibles avec des gros "if" imbriqués pour gérer informatiquement chaque situation en fonction de chaque attitude. Cela aurait donné des pages et des pages de scripting très laborieuse, et mécanique, pour donner des résultats invariants, et peu réalistes.

La création d'une IA par algo génétique, introduit une part d'aléatoire, et de variation importante dans le comportement, qui peut éviter d'avoir toujours les mêmes comportements, et surtout d'avoir des comportements subtilement différents quand une situation différente apparaît. Cela paraît assez confus comme cela, mais je pense que le résultat sera probant. Par contre, il va me falloir un peu de temps pour assimiler ces concepts, et les mettre en oeuvre, et ensuite du temps pour paramétriser toutes les variables inhérentes au jeu.

Un exemple concret, serait un groupe d'IA qui patrouille. Le premier repère un joueur dans son radar. Il vérifie son contexte, et comme il est en mode aggressif, il va directement en direction du joueur. Les autres, voyant un un contre un, enverront un 2e vaisseau en renfort. Si la situation dégènére ils pourront éventuellement tous y aller, ou plutôt battre en retraite, pour aller chercher de l'aide ou se mettre à couvert d'une base. Tous ne pourront pas réagir de la même manière en fonction d'un rôle. Mais l'important, est que même lors du combat, ils pourront changer de cible, pour atteindre des cibles plus critiques, ou plus faciles, ou fuir.

C'est important, ce système de réévaluation, car il permet de ne pas avoir un acharnement thérapeutique contre toute attente, ou raison logique. Si l'IA se trouve isolée, elle va essayer de retrouver ses camarades, pour être couverte, ou va fuir par exemple, et pas s'acharner sur le joueur.

BOn voilà beaucoup de travail en perspective en tout cas

Décompte:

client : 3497

Server : 1843

Je prends quelques instants pour vous dire que mon activité s'est sensiblement réduit. Je passe pas mal de temps entre le boulot et mon fils, et j'ai un peu moins de temps pour ShimStar que lorsque j'étais en vacances. Etrange? non?

Bon en tout cas, cela continue d'avancer. Comme promis j'équipe un vaisseau (bientôt les images!). Pour un vaisseau donné, dans la station, j'affiche sa "photo" stylisée en arrière plan, et selon la définition du vaisseau, j'affiche des petits carrés aux différents endroits du vaisseau (haut, bas, milieu, gauche et droite), indiquant les "lieux" d'équipement.

Chaque slot d'équipement selon sa définition ne pourra être équipé que par un type ou plusieurs types d'équipement. A l'arrière on retrouve pour ce premier type de vaisseau que la possibilité de mettre un moteur. Au centre, plutôt des réacteurs d'énergie, et de l'électronique (radar, ...).

Aujourd'hui j'affiche donc ce plan de vaisseau et l'équipement qu'il contient à un instant T. Bon vous verrez les icones d'équipement ne sont pas belles (carré monochrome avec une lettre dessus). Malheureusement autant mes compétences de développement sont au top, autant mes talents de graphistes n'ont jamais existé.

S'il y a des volontaires, je suis preneur.

Prochaine étape, pouvoir remplir ces slots avec un équipement se trouvant dans l'inventaire, suivant les règles de gestion présentées plus haut. Pour cela, il faut donc que je définisse le concept d'inventaire et l'implémente. Suite à cela, il faudra bien entendu sauvegarder au niveau du server cet inventaire, et l'équipement effectué sur le vaisseau.

Ensuite, il faudra que je fasse en sorte, que lors du jeu, ces notions d'équipement soient bien prise en compte. Certaines choses sont en dur actuellement, telle la distance du radar.

A bientot

Que de soucis!

Quel expérience étonnante ce jeu. Il est vrai que la librairie Panda assiste tellement sur des points techniques qui m'ont fait hérissés les cheveux sur la tête dans d'autres contextes, qu'on arrive vite à des réels problèmes de conception, et non pas à des soucis de second ordre.

Mon gros problème à ce jour est vraiment le calibrage du réseau. Il est évident que les joueurs et le serveur doivent partager un ensemble de données (position des uns des autres, déplacement, actions, ...).

Le problème concerne les données en temps réel. Je me rends bien compte qu'il n'est pas possible de donner à chacun en temps réel toutes les informations concernant les uns les autres. Le flux de données devient énorme, et continu.

En une seconde, chaque joueur va recevoir entre 10 et 20 positions pour un vaisseau. Imaginons que vous avez 10 vaisseaux dans la zone, vous êtes alors en train de traiter 100 informations secondes.

Le problème n'est pas tant la quantité, bien que cette quantité soit non négligeable, car le jeu en lui même n'est pas juste une machine à traiter des flux réseaux, mais à résoudre énormément de choses de manière synchrones (gestion des collisions, souris, ...).

Le problème est aussi la synchronisation de ces informations. Le serveur peut très bien être capable d'envoyer un flux de 20 messages secondes pour une même entité, alors que le client lui n'est capable de traiter que 5 de ces messages secondes.

Nous nous retrouvons donc dans une situation, où les messages vont s'accumuler et seront traités avec un retard cumulé de plus en plus important. La conséquence est que les vaisseaux seront affichés en décalage temporel d'autant. Une simple rotation peut être affichée avec 5 sec de retard. Imaginons alors les manoeuvres d'évitement, où les engagements sur des positions périmées.

Une solution pourrait être de donner un temps de péremption au message, et de ne traiter que les messages non périmés. L'expérience pourrait être menée, mais le problème reste qu'il faut quand même parser chaque message pour sortir cette date de péremption, et qu'il faut quand même itérer sur chacun des messages.

Une solution préconisée, et connue est l'extrapolation. Au lieu d'envoyer un flux de données continu, le server envoie par fréquence plus espacée, cette même information, afin de ne pas noyer le client sous l'information qu'il n'est pas capable de traiter de toute façon.

Par contre, le server fournit plus d'informations, que simplement la position et la direction. La vitesse par exemple, ou la cible.

Ainsi le client, pourra calculer les prochains mouvements comme le fait le server. Ces calculs sont plus rapides que le traitement d'un message réseau. Pour être sûr d'être en phase avec le server, le server envoie la position réelle et les quelques informations de comportement, au client toutes les secondes par exemple.

C'est une sorte de synchronisation, et d'arbitrage.

Le flux réseau est très largement réduit, et on obtient quelque chose de plus fluide, même si ce n'est pas l'exact réalité. C'est pour cela que dans certains jeux en ligne (MMO par ex), on a parfois des "lags" ou des personnages qui subitement changent d'emplacement. Le calcul de la trajectoire, et l'emplacement réel étaient désynchronisés.

Dans la conception, il faut ensuite être clair sur qui possède la référence, et à qui est dévolu certains calculs?

Ce petit "lag" peut être perçu comme injuste par les joueurs mais sont la conséquences des limites d'un traitement déjà lourd.

Je pense qu'il faut sacrifier le "réalisme", et une modélisation informatique "parfaite" pour une fluidité beaucoup plus agréable pour le joueur.

Je me rends compte qu'il est utopique de mettre côté serveur l'ensemble des calculs et de faire profiter des résultats aux joueurs.

Chaque client devra effectuer ses propres calculs de déplacement, collision en doublon avec les autres, et le server, afin de limiter le flux réseau.

L'aventure continue néanmoins.

Je suis désolé pour l'instant tout cela est très informatique. J'espère dans la semaine qui arrive mettre un terme à ce gros problème, et pouvoir passer à des éléments de game design, et pouvoir parler de problèmes plus parlant.

lignes de code :

Client : 2446

server : 997