Discussion :

[Lynix]

Salut,
Avec une équipe je bosse actuellement sur un jeu de type MMO, et actuellement je cherche à réaliser le launcher, soit le code qui se chargera de vérifier si les fichiers sont à jours, et dans le cas contraire, de les retélécharger.

Je précise que nous travaillons avec Qt 4.5 pour cette tâche.

Ce launcher devrait être capable également de télécharger tous les fichiers manquants, ce fichier sera le seul à être distribué (Avec les dll?) au public.

Cependant ceci pose quelques problèmes, par exemple j'aimerais savoir si je peux compiler les dll de Qt dans l'exécutable légalement, sachant que le jeu sera gratuit mais propriétaire (On ne distribuera pas le code source).

Ce serait plus esthétique et plus facile avec cette technique, mais elle ne pose pas de problème dans le cas contraire.

Un autre problème c'est pour modifier les fichiers, je sais comment faire mais je sais également que les fichiers comme l'exécutable lui-même, ou les dll de Qt (Dans le cas d'une mise à jour de Qt), ne seront pas autorisés en écriture pendant que le programme est lancé (Et difficile de le couper puis de le faire modifier des fichiers )

J'avais pensé à une architecture un peu à la World of Warcraft, c'est-à-dire que pour les mises à jour, ce serait un fichier d'installation qui serait téléchargé, puis exécuté afin de modifier le programme librement (après la fermeture de celui-ci).

Cette architecture pose plusieurs problèmes, par exemple le fait que les mises à jours devront être téléchargées dans l'ordre, et donc il faut imaginer un nouveau joueur acquérir le launcher et ne pas pouvoir jouer le temps que toutes les mises à jours soient effectuées, ce qui peut être très long sur certaines connections.

De plus, imaginons que un fichier soit endommagé, corrompu ou supprimé (délibérément ou non).
On ne peut évidemment pas passer par les mises à jours, car une mise à jour ne modifie pas tous les fichiers (Sinon ça équivaudrait à retélécharger tout le jeu à chaque fois) et il faudrait donc retrouver la dernière mise à jour qui touche le fichier en question, puis appliquer toutes les suivantes.

Cependant si le fichier est endommagé et que l'exécutable à pu se lancer quand même, c'est probablement un fichier auquel nous pouvons toucher, à ce moment là nous pourrions le retélécharger.
Mais imaginons que ça ne soit pas possible.

Enfin bref, que nous conseillez-vous pour mettre à jour notre jeu quand c'est nécessaire?

Merci d'avance

[IrmatDen]

Salut,

Ce launcher devrait être capable également de télécharger tous les fichiers manquants, ce fichier sera le seul à être distribué (Avec les dll?) au public.

Cependant ceci pose quelques problèmes, par exemple j'aimerais savoir si je peux compiler les dll de Qt dans l'exécutable légalement, sachant que le jeu sera gratuit mais propriétaire (On ne distribuera pas le code source).

La liaison statique n'est pas vraiment permise par la LGPL, donc tu devras livrer les dlls Qt (et c'est le Bien, imagines le jour où tu mettras à jour ton installeur: tu téléchargeras 300 kB au lieu de 6 ou 8 MB ).
D'ailleurs, pour mettre à jour le launcher, tu peux appliquer une méthode à la filezilla (et autres): le launcher télécharge le setup du nouveau launcher, l'exécute puis se ferme immédiatement après, et le setup relance le launcher à la fin de l'installation.

J'avais pensé à une architecture un peu à la World of Warcraft, c'est-à-dire que pour les mises à jour, ce serait un fichier d'installation qui serait téléchargé, puis exécuté afin de modifier le programme librement (après la fermeture de celui-ci).

Cette architecture pose plusieurs problèmes, par exemple le fait que les mises à jours devront être téléchargées dans l'ordre, et donc il faut imaginer un nouveau joueur acquérir le launcher et ne pas pouvoir jouer le temps que toutes les mises à jours soient effectuées, ce qui peut être très long sur certaines connections.

C'est pourtant la meilleure solution en terme de maintenance et espace disque sur le serveur.
Tu pourrais très bien stocker tout les diffs de versions, mais en admettant que ton jeu ait 5 MAJ (1.0 -> 1.5), ça te ferait stocker 15 mises à jour, dont seulement 5 sont réellement nécessaire. Tout les autres fichiers sont des parasites vu qu'ils cumulent les mises à jour précédentes (n'oublie pas qu'une MAJ est incrémentale par principe).
Donc dans tout les cas, tu dois installer toutes les mises à jour, autant que ça se fasse de façon incrémentale; de plus tu peux aussi penser à la coupure de connexion à 95% de ta grosse mise a jour (1.0 -> 1.5 direct), la MAJ doit être reprise depuis le début. Alors qu'avec une approche incrémentale, la MAJ ne se fera que pour la 1.4 -> 1.5 (par exemple), et ce sera nettement plus léger à refaire.

De plus, imaginons que un fichier soit endommagé, corrompu ou supprimé (délibérément ou non).
On ne peut évidemment pas passer par les mises à jours, car une mise à jour ne modifie pas tous les fichiers (Sinon ça équivaudrait à retélécharger tout le jeu à chaque fois) et il faudrait donc retrouver la dernière mise à jour qui touche le fichier en question, puis appliquer toutes les suivantes.

Ce ne serait pas à faire à chaque lancement pour commencer, mais tu peux mettre une option dans le launcher, genre "Sanity check", qui si activée va vérifier tout les fichiers du jeu et les comparer à la dernière version de chacun sur le serveur. Tu peux générer un crc pour chacun et t'en servir pour la comparaison, ce sera plus rapide.

Pourquoi pas le faire à chaque fois ? Le temps d'exécution risque d'être long, sauf si vous n'avez que 3 fichiers

Mais imaginons que ça ne soit pas possible.

Pourquoi ?!

[Lynix]

Après mure réflexion, j'ai pu décider d'utiliser une autre architecture qui est selon moi la meilleure approche.

Je m'explique :
Il y aurait 2 programmes, le launcher (Qui lui est le jeu et le launcher) et l'updater (Dont le rôle va être décrit après).

Lorsque le launcher est lancé, il établit une communication avec le serveur et ensuite lui envoie la version du logiciel (en cas de modification des protocoles, pour que le serveur puisse toujours communiquer sans problème de compréhension).

Puis il vérifie l'existence du fichier de la table des hachages (En gros le fichier qui dit que tel fichier vaut telle somme de contrôle).


Si le fichier existe, on demande au serveur un hash de cette table, afin de vérifier si une mise à jour à eu lieu (Ou si l'utilisateur n'a pas bêtement modifié le fichier).
Si le hash correspond, on utilise la table des hashs pour vérifier chaque fichier individuellement, pour que l'utilisateur ne puisse pas les modifier


Si le fichier n'existe pas (ou que le hash ne correspond pas si le fichier existe), on télécharge une nouvelle table des hashs et on vérifie les fichiers individuellement.


Si un fichier ne correspond pas (Quel qu'il soit), on le télécharge depuis le serveur et nous tentons de l'écrire (à l'endroit où il devrait être).
Si nous ne pouvons pas l'écrire (C'est que il est utilisé par le programme en cours), on créé le fichier au même endroit, avec le même nom, excepté que nous rajoutons .upd à la fin (mingwm10.dll -> mingwm10.dll.upd), qui est la contraction de update.


Dans le cas où un fichier update a été créé, on ferme le programme et on lance l'updater.

Vous l'aurez deviné, le rôle de l'updater est de rechercher les .upd et de remplacer les fichiers par ces fichiers d'updates.

Je précise que l'updater n'utiliserait que la librairie standard et ne demanderait donc aucune .dll

De cette façon, tous les fichiers peuvent être mis à jour sans problème.
Nous utilisons un minimum de place, et la version la plus ancienne peut updater directement avec la plus récente, sans passer par les anciennes mises à jours.

Nous évitons également les problèmes de coupure de courant, de fermeture de processus, etc... vu que l'utilisateur n'aura qu'a relancer l'updater ou le launcher selon le moment où le plantage eut lieu.

Bon ça demande aussi de faire en sorte que le launcher puisse empêcher le lancement par l'utilisateur de l'updater, et inversement.
Je pense pour cela passer par le registre système, maintenant si l'utilisateur veut planter l'application en allant les modifier jusque la, c'est pas mon problème.

Dans le pire des cas il n'aura qu'a retélécharger l'application minimale (dll Qt + launcher) et ça suffira pour tout retélécharger.

Si vous avez une question, ou si vous voyez un inconvénient, ou une amélioration à cette méthode, n'hésitez pas.

[IrmatDen]

Tu interdis donc à l'utilisateur de faire le choix d'utiliser une version en particulier ?
(Note qu'il n'y a pas de bonne ou mauvaise réponse, juste une réponse qui est déduite du fonctionnement et de l'archi de votre jeu XOR une réponse qui induira des contraintes sur le fonctionnement et l'archi de votre jeu)

Pour exemple de laisser la possibilité à l'utilisateur d'exécuter telle ou telle famille de versions, il y a le support de plugins externes: nouvelle version => possibilité de casser la compat' et le joueur peut préférer rester sur la version la plus récente supportée par le plugin.

En plus pour supporter les addons, il te faudra une table de versionning par addon développé (ou famille d'addons, en bref il peut y avoir des dépendances entre addon).


Si tu comprends ces contraintes et qu'elle ne concerne pas votre projet, ta solution est correcte (bien qu'un peu lente puisqu'une vérification est effectuée à chaque lancement si j'ai bien compris).

[Lynix]

J'ai pas compris ta réponse désolé

[IrmatDen]

Le gros souci potentiel que je vois se résume à cette question:

Comptez-vous permettre le développement de plugins pour customiser le jeu ? (les plugins ne sont pas nécessairement tiers ; ça peut aussi être les votres)

[Fabllot]

Bonjour !

Dans l'ensemble ça m'a l'air d'être pas mal. Mais juste un détail :

Vous l'aurez deviné, le rôle de l'updater est de rechercher les .upd et de remplacer les fichiers par ces fichiers d'updates

C'est un peu limiter le rôle de l'installeur... En fait, si jamais vous souhaitez mettre à jour votre programme de mise à jour, vous devrez d'abord faire une mise à jour pour changer le "Launcher" (qui contient le code de maj) puis de relancer ce Launcher qui pourra se mettre à jour correctement avec le nouveau code...
Le fait que le launcher n'est qu'à télécharger l'updater et le lancer, laisse une plus grande flexibilité au niveau de la mise à jour...

Autre petit détail, pour avoir aussi fait des programmes de mise à jour, fait très attention à Vista & à l'UAC...

[Lynix]

Le gros souci potentiel que je vois se résume à cette question:

Comptez-vous permettre le développement de plugins pour customiser le jeu ? (les plugins ne sont pas nécessairement tiers ; ça peut aussi être les votres)

Les plugins seront eux sous forme de fichier Lua additionnel, et ils ne seront pas vérifiés par l'updater.

Pour répondre à fabllot :

Dans le cas où le launcher est mis à jour, il créé un fichier .upd portant son nom, et une fois que il a fait ça pour tous les fichiers (dans le cas où c'est nécessaire), il lance l'updater, qui lui s'occupera de repasser les .upd en leurs fichiers originaux.

Dans le cas d'une update de l'updater, c'est le launcher qui le modifiera directement.

Je ne vois pas où est le problème

[IrmatDen]

Les plugins seront eux sous forme de fichier Lua additionnel, et ils ne seront pas vérifiés par l'updater.

Dans ce cas, il y a toutes les chances pour qu'une update du code et/ou des données du jeu casse un ou plusieurs plugins existants.
Donc, s'il n'y a pas possibilité pour l'utilisateur de choisir sa version, ça peut faire des mécontents. Ils y en a souvent qui restent sur une ancienne version du jeu parce qu'ils utilisent des plugins incompatibles avec une version plus récente (le temps que le plugin soit fixé).

[Lynix]

Il s'agit d'un MMO je le rappelle, donc si un joueur veut garder une ancienne version, il ne pourra tout simplement pas jouer.

[IrmatDen]

C'est vous qui voyiez, mais ce n'est pas une vérité absolue.
Un changement cosmétique dans une MaJ n'est pas critique à l'utilisation du jeu mais peut briser le layouting utilisé par un plugins.

[Lynix]

Jouer a un MMO avec plusieurs versions différentes sur un même serveur, désolé mais je n'ai jamais vu une telle chose :/

Ce serait ingérable assez souvent, et il n'y a aucune raison de permettre ça.

Sinon j'ai pensé à une amélioration pour l'updater, au lieu d'avoir un programme qui irait rechercher les .upd, pouquoi le launcher n'écrirait-il pas un script bash avec les commandes pour renommer les fichiers?

Ce serait bien plus simple, plus rapide sans aucun désagrément apparent.

Cet updater attendrait 5 secondes (le temps que le launcher soit complètement fermé sur tous les ordinateurs), ensuite exécuterait une série de "Supprimer fichier original, renommer .upd", et puis relancerait le launcher avant de se supprimer lui-même.

Cette amélioration pose-t-elle problème? Est-ce qu'un tel procédé fonctionnerait sur Mac? (Je connais les batch sous windows, et ils sont au coeur de Linux, mais j'avoue n'avoir jamais utilisé de Mac)

Merci de votre réponse

[IrmatDen]

Mac OSX est une surcouche à BSD ; des scripts y sont utilisables et tu peux y utiliser une syntaxe bash. Par contre, je n'ai pas de mac pour tester, et je ne connais pas le degré de compatibilité ; à priori, tu ne devrais pas avoir trop de problèmes pour un script qui ferait simplement du renommage/effacer

[Lynix]

J'aurais maintenant besoin de vous pour écrire le fameux fichier.

Sous windows ce serait ça j'imagine :

-Création d'un fichier update.bat
Contenu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
(Emplacement pour un sleep)
 
del fichier.dll
ren fichier.dll.upd fichier.dll
 
del update.bat
start utopia.exe

Ensuite, on exécute ce fichier juste avant la fermeture du programme avec system("update.bat");.
Par contre il faudrait que le batch fasse une pause d'environ 5 secondes, et ça je ne sais pas comment faire (Apparemment la commande choice ne marche pas)


Sous linux, j'imagine la situation comme ça :

-Création d'un fichier update.? (Quelle exension? .sh?)
Contenu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#!/bin/bash
sleep 5
rm fichier.dll
mv fichier.dll.upd fichier.dll
 
rm update.(sh?)
(Lancement du launcher)

(Quelle commande pour lancer un exécutable, et quelle extension pour un exécutable?)

(Comment lancer ce script avec le C++?)

Par contre sous Mac je vois vraiment pas comment faire

Merci d'avance

[IrmatDen]

On dérive vraiment du sujet du forum là...

Pour émuler un sleep en batch windows, tu peux utiliser ping:
ping 127.0.0.1 -n X > NUL
avec X == le nombre de secondes à attendre.

Ou bien tu peux passer des années 80 aux années 2000 et utiliser du vbs (où le sleep s'effectue par WScript.Sleep nbMs, avec nbMs le nombre de millisecondes à attendre)

Pour lancer le programme à partir de ton script *nix, c'est comme tu le ferais pour lancer un programme:
./utopia (en supposant que utopia est dans le même répertoire que ton script)

Pour Mac OSX, comme je te l'ai dit, ce sera sensiblement la même chose. Avec d'éventuels affinements lorsque le script sera plus compliqué.

[Lynix]

Merci pour ton aide, comme ce topic devient vraiment hors-sujet, je vais le mettre en résolu