0

L’environnement où s’exécute réellement le jeu est appelé “production”. L’environnement où il est développé est appelé “local”. Il faut que ces deux environnements soient séparés. Quels outils vous permettent de faire cette séparation?

Le besoin de deux environnements

A vous tous débuts de créateurs (ou peut-être encore maintenant?) vous avez loué un serveur web (ou utilisé un serveur gratuit), mis des fichiers PHP dessus, et vous les avez directement édités pour voir le résultat. Cette approche est à bannir. En effet, elle mélange deux notions capitales en informatique: l’environnement de production et l’environnement de . Pour éviter ce mélange, voici des outils qu’il vous faudra installer sur votre poste pour développer tranquillement votre jeu, avant de pouvoir le mettre en ligne.

La “prod” et le “local” doivent toujours être séparés. L’action de basculer des fichiers du local vers la “prod” s’appelle un déploiement (ou “mise en production”).

Les risques de mélanger “prod” et “local”

Si vous persistez à mélanger ces deux environnements, alors vous prenez le risque de flinguer votre jeu: vos modifications affectent immédiatement tous les joueurs du jeu, vous risquez donc de planter votre jeu si vous faites une mauvaise manip’ ou si votre code n’est pas bon. Les joueurs seront alors bloqués, et ils s’en iront. Pire, si vos modifications prennent du temps, votre jeu sera dans un état “inconsistant”, qui peut déboucher sur des comptes de jeu corrompus (quantités de ressource négatives par exemple) ou sur des cheats involontaires (un joueur gagnera 4 fois de suite la même bataille et touchera 4 récompenses).

La stack d’exécution

EasyPHP, WAMP, XAMP…

Bundles qui embarquent Apache, MySQL et PHP (parfois aussi Perl, ou MariaDB). Ils s’installent sur Windows très facilement, et permettent de disposer d’une stack web complète en quelques secondes (et de la mettre à jour facilement). XAMPP a abandonné MySQL récemment (pour MariaDB). Je me suis donc rabattu sur WAMP, car je trouve EasyPHP un peu moins pratique.

D’autres stacks existent, orientées plutôt temps réel ou communication bi-canal avec le client, mais elles ne seront pas trop abordées dans ce blog.

FakeSMTP

Un faux-serveur SMTP à faire tourner en local et à utiliser pour les envois de mail. FakeSMTP se comportera alors comme un serveur SMTP, et votre jeu croira que son email est bien parti. En pratique, FakeSMTP va juste stocker l’email sur votre disque dur, et vous pourrez alors l’ouvrir (dans ThunderBird par exemple). Cela s’avère donc très pratique pour s’assurer que les emails que le jeu envoie sont bien formatés et partiront bien une fois le jeu en ligne.

Vue de FakeSMTP
FakeSMTP liste les mails reçus par le serveur SMTP

Il est très pratique de pouvoir tester le rendu de ses emails en local, sur votre poste de développement, via ce faux-serveur SMTP et Thunderbird.

Coder

Développer

Notepad++

Ce n’est pas un IDE, mais c’est un éditeur suffisant pour de tout petits projets de jeux, ou pour éditer un fichier rapidement. Pour un projet plus important (MMORPG), préférez un IDE.

NetBeans

Un IDE qui vous permettra de développer rapidement, facilement, et de façon fiable votre jeu web?

Voir l’article détaillé sur NetBeans et ses astuces

HeidiSQL

Un client MySQL (entre autres, car il prend aussi en charge PostGre et MsSQL) similaire à phpMyAdmin, mais en tant que logiciel dédié, et non en tant que page web du navigateur. Cela lui confère plus d’options de connexion (comme le tunnel SSH), et, je trouve, plus de praticité à l’usage (cela n’ajoute pas un n-ieme onglet de plus, et il a donc sa propre icône dans la barre des tâches). Il est aussi bien plus stable que MySQL WorkBench.

HeidiSQL peut vous permettre de gérer votre base de données locale (sur votre poste de dev) ou distante (en prod).

Déboguer

XDebug

Plugin indispensable de PHP, il vous permettra de déboguer votre jeu web en visualisant son exécution pas à pas, et en consultant la valeur des différents variables au fil de cette exécution. Netbeans peut s’interfacer avec cette DLL (fournie par défaut dans WAMP) pour vous proposer ces features de débogage. XDebug possède aussi un profiler, qui génèrera un fichier cachegrind que QCacheGrind pourra ouvrir (cf plus bas).

Les echo et autres var_dump peuvent parfois suffire, mais les bogues plus complexes appellent des outils plus avancés comme XDebug.

The easiest XDebug (plugin Firefox)

Permet d’activer et de désactiver une session XDebug d’un seul clic, pour lancer le débogueur ou le profileur ou le traceur à la demande.

Configuration du plugin (IDE Key):
netbeans-xdebug
Configuration PHP (php.ini):
xdebug.remote_enable=true
xdebug.remote_autostart=0
xdebug.idekey=netbeans-xdebug
Configuration pour lier ce plugin à XDebug+NetBeans

QCacheGrind

Logiciel de visualisation capable d’ouvrir les fichiers issus du profiler de XDebug (sur votre poste local donc, surtout pas en production). Vous verrez ainsi où le serveur passe le plus clair de son temps, et vous serez ce qu’il vous faut optimiser dans votre jeu. Ce seront ces fichiers/fonctions qu’il vous faudra optimiser pour accélérer sensiblement votre jeu.

La vue de QCachegrind une fois le fichier ouvert

QCacheGrind peut également analyser d’autres profiles, mais nous ne les aborderont pas dans ce blog.

Versionner

Mercurial

Un outil de versionning utilisable pour les jeux web. Il permet de suivre les modifications faites dans le temps sur chaque fichier. Vous saurez alors pourquoi vous (ou vos équipiers) avez fait telle ou telle modification, quand elle a été faite, par qui, et quels fichiers ont été modifiés (cela s’appelle un “commit”) sans recourir à des commentaires partout dans le code. Vous pourrez ainsi gérer les développement en parallèle (en équipe) mais également leur évolution dans le temps (vous pourrez revenir en arrière sur une modification foireuse).

Git est une autre possibilité, plus répandue grâce à la prédominance de GitHub, mais je trouve Mercurial bien plus simple à utiliser, surtout grâce à TortoiseHg, une interface graphique intuitive.

Déployer

Evitez de copier/coller dans votre FTP ou pire, d’aller directement éditer les fichiers du serveur car vous risquez de commettre des erreurs qui peuvent planter votre jeu, ou faire fuiter des informations. De plus, vous passerez à côté du versionning (voir section précédente). Privilégiez un vrai process de déploiement, qu’il soit fait maison (un simple script PHP peut suffire) ou non (Magallanes, Jenkins, etc). Inutile toutefois de vous plonger dans une solution trop compliquée si vous n’avez pas de tâches complexes à faire lorsque vous mettez votre jeu à jour.

L’édition directe sur le serveur ou le copier-coller par FTP ne sont acceptables que pour votre zone de test, ou pour d’éventuels minis-jeux (la mise en place d’un déploiement lourd ne sera alors pas justifiée).

Magallanes

L’outil de déploiement que j’utilisais au début. Son passage à Composer et plusieurs problèmes de liens symboliques me l’ont fait abandonner depuis. Dans les grandes lignes, il s’agit d’un script PHP qui va créer un .tar.gz de votre projet, l’envoyer sur le serveur, l’y décompresser dans un dossier dédié, puis créer un lien symbolique vers ce dossier (et vous êtes censé avoir réglé votre serveur Apache pour qu’il pointe sur ce lien symbolique). On peut faire la même chose en se passant de Magallanes, via un script Shell.

Un simple script bash/batch peut être suffisant pour automatiser son déploiement. Dans tous les cas, n’écrasez pas les source existantes: créez un nouveau dossier sur le serveur, déployer votre jeu dedans, et faites pointer le serveur web sur cette nouvelle version. Vous pourrez ainsi revenir à l’ancienne si besoin.

0