mardi 26 mai 2009

Cargo

Une petite capture pour se remettre de l'updator.

lundi 25 mai 2009

Une update de l'updator

Je me suis concentré ce week-end sur la vérification et le téléchargement des fichiers, et l'ensemble commence à ressembler à quelque chose.

Au moment où l'utilisateur tente de se connecter à un serveur, l'updator télécharge un fichier XML dont l'adresse lui a été indiquée par le serveur. Ce fichier XML contient la liste des ressources, et leur signature SHA1.

L'updator regarde alors les fichiers présents localement.

- Si le fichier est présent en distant, mais pas en local, il le télécharge.
- Si le fichier est présent en distant et en local, il calcule le SHA1 du fichier local et la compare avec la signature du fichier qu'il est censé recevoir. Si les signatures diffèrent, il télécharge le fichier distant et écrase le fichier local.
- Enfin, si le fichier est présent en local mais pas en distant, il le supprime.

Voilà par exemple ce que pourrait voir l'utilisateur lors de la première connexion:



L'utilisateur se connecte pour la deuxième fois, et tous les fichiers étant déjà là, le processus est beaucoup plus rapide, il suffit de vérifier les signatures.



Allons donc bidouiller le fichier cannon.obj, par exemple en supprimant une ligne. A la prochaine mise à jour, l'updator détecte que les signatures sont différentes, et télécharge à nouveau le fichier.



Le tout est fait dans un petit thread d'arrière plan, qui envoie régulièrement des messages à la GUI pour mettre à jour les logs et la barre de progression, avec l'aide des "custom events" de wxWidgets.

A priori, il est possible d'obtenir la taille du fichier avant téléchargement, ce qui me permettra d'ajouter une autre barre de progression pour chaque fichier, avec pourquoi pas la vitesse de téléchargement.

Il faudra probablement se battre un peu pour que tout cela tourne gentiment à la fois sous Linux et sous Windows, mais une fois que ce sera fait, il deviendra possible de faire une vraie release d'AdH!

dimanche 17 mai 2009

Updator - Graphismes et fonctionnalités

Dites bonjour à l'updator! Tyrion avait bien commencé le back-end, chargé d'aller télécharger les ressources sur un serveur afin que le client soit toujours à jour, et aujourd'hui, comme mes tentatives de donner une GUI digne de ce nom au client ont lamentablement échouées, je me suis dit que j'allais lui donner une petite GUI multi-serveurs et connecter la chose. Maintenant, l'updator peut donc obtenir les informations du serveur, incluant celles visibles sur la capture, mais aussi par exemple l'URL pour la mise à jour.



En jouant un peu avec les threads, j'ai obtenu une GUI répondant comme je le souhaite, avec des informations qui se mettent à jour rapidement. L'on voit très vite si des joueurs sont en train de se connecter, et si la connexion tombe, l'updator va réessayer jusqu'à ce que ça marche.

Maintenant que tous les bouts sont disponibles, il ne s'agit plus que de brancher la partie qui retrouve les informations du serveur avec la partie qui met à jour les données, et l'updator première version sera prêt!

dimanche 10 mai 2009

Ça bouge!

Grâce aux efforts redoublés de Tyrion, le build Win32 est bien avancé, et en dehors de petits soucis avec les fontes et certains formats d'images, utilisable. Entre temps, nous sommes passés à SFML, ce qui m'a forcé à débloquer le taux de rafraîchissement. Ceci dit, c'est probablement mieux pour nos tests de savoir à quelle vitesse on tourne!

Bien sûr, envoyer sa nouvelle position à chaque image a fait exploser la bande passante, chaque client mangeant 120 kB/s. Un petit changement pour envoyer sa nouvelle position seulement 10 fois par secondes, et nous sommes revenus à un 3 kB/s beaucoup plus raisonnable. Le mouvement des autres entités devient un petit peu saccadé, mais ce n'est que partie remise, un poil d'interpolation et il n'y paraîtra plus!


Tyrion barbote

jeudi 7 mai 2009

SFML

SFML, c'est la petite bibliothèque multimédia façon SDL, mais en C++, et dont la version 1.4 vient enfin d'atterrir dans Debian Testing (ce qui veut donc dire que je peux commencer à l'utiliser!). Ce que j'aime bien:

- La propreté du design, en bon C++ moderne
- Des modules bien séparés, dont on prend juste ce dont on a besoin
- Un support de l'Unicode nettement plus poussé que SDL
- Le son basé sur OpenAL, avec le support d'un nombre invraisemblable de format, et le support de la spatialisation des sons

En plus, toute la doc et les tutos sont en français, ce qui est sympa.

Voilà, peut-être bientôt dans AdH!

lundi 4 mai 2009

Un coffre

Puisqu'il va bien falloir un jour penser à l'inventaire, voilà un petit coffre fait à partir de Blender. Je pars d'un cylindre, en vire la partie inférieure, extrude, et rajoute deux surfaces pour faire le fond du coffre. Un petit UV unwrap, et il ne reste qu'à exprimer mon talent d'artiste dans mon Gimp préféré :)



Bon, la texture n'est pas top, mais vu de loin, ça passera.

Et maintenant?

Je suis assailli par le doute.

Jusqu'à présent, le but était clair: faire un chat 3D (je parle du canal de discussion, pas du félin). Bon, bah ça y est, on peut causer, bouger, et voir les autres bouger.

Et maintenant, il y a tellement de directions à prendre que je ne suis pas sûr de laquelle choisir!

- Développer le combat? PvP ou PvE?
- Ajouter des fonctionnalités d'artisanat, de commerce?
- En rester là pour l'instant sur le code, et créer un monde plus étendu, avec plus de décors, que le joueur va avoir envie d'explorer?

Mhh!

dimanche 3 mai 2009

Les avatars

Aujourd'hui, étape importante: il est enfin possible de voir les autres avatars se balader dans le monde! Il a fallu gérer une quantité importante de concepts:

- Le client doit tout d'abord demander au serveur quelle est son identité, afin de ne pas s'afficher lui-même lorsqu'il reçoit les mises à jour des positions
- Une fois l'identité reçue, le client indique au serveur qu'il est prêt à démarrer
- Le serveur enregistre la position du client, et lui envoie les informations de tous les avatars dans la zone. En même temps, le serveur envoie à tous les avatars de la zone les informations du nouveau client
- Quand le client se déplace, tous les avatars de la zone sont notifiés
- Enfin, si le client quitte la zone (par exemple en se déconnectant), les avatars de la zone sont notifiés que le client a disparu



Sur la capture, 3 autres avatars sont représentés par des ULM (le quatrième ULM, c'est juste de la déco). Lorsqu'un ULM se déplace, les autres clients le voient se déplacer. L'on envoie la matrice de position, donc l'orientation de l'avatar est correctement représentée.

Maintenant, il reste à correctement gérer l'identité des avatars, afin d'afficher leur nom. Enfin viendra la gestion des actions, mais ce ne sera pas pour tout de suite!