Les Cahiers du programmeur Flash MX

Transcription

1 Les Cahiers du programmeur Flash MX Jeu en réseau avec ActionScript et XML Guillaume Guine Alain Moraes Groupe Eyrolles, 2002 ISBN :

2 Descriptif et cahier des charges 1 Flash MX Description fonctionnalités plan SOMMAIRE B Définitions des fonctionnalités C Le jeu C Communication entre les deux joueurs C Le stockage de l information B Structure de l application C Comment répartir les traitements C Vue générale B Choix et contraintes techniques C Environnement C La partie communication côté serveur C Déploiement C La partie sauvegarde MOTS-CLÉS B Description B Fonctionnalités B Plan F Joueur Blanc Joueur Noir Joue Joue Jeu Coup Coup Action des joueurs Affichage Lecture du jeu Contrôle du coup Stockage en base Envoi au serveur Tâches de l'application Vérification des déplacements Gestion des prises Gestion de l'échec Gestion des coups spéciaux Chargement de partie Ce premier chapitre va nous permettre de définir, d une part, la structure générale de notre jeu et, d autre part, les solutions mises en œuvre. Pour cela, nous devons d abord définir les contraintes tant fonctionnelles que structurelles, puis ordonner les multiples développements nécessaires au bon fonctionnement de notre application. Enfin, dans la mesure du possible, nous diviserons le travail au travers de chapitres représentant des ensembles fonctionnels finis. Une application est la réunion d une série de fonctionnalités et de choix techniques. Ce chapitre permettra de délimiter la réalisation du jeu d échecs en mettant en rapport les fonctionnalités définies et les solutions techniques retenues. La décomposition du travail par chapitre est également abordée.

3 Les Cahiers du programmeur Flash MX Pour plus de détails concernant les règles, voir les sites : B B echecs.bridge.online.fr Définitions des fonctionnalités La délimitation des fonctionnalités permet de définir et d obtenir la séquence du travail à effectuer. Cet ensemble fonctionnel est à confronter aux capacités d ActionScript. Afin de cerner au mieux le jeu que nous allons développer, un bref rappel des règles est utile. Le jeu Concrètement, le jeu d échecs est défini par un échiquier de huit cases sur huit, alternativement noires et blanches, la première case en bas à droite étant toujours blanche. Sur cet échiquier chaque joueur dispose de seize pièces : huit pions, deux tours, deux fous, deux cavaliers, une dame et un roi. Le tableau 1-1 résume pour chaque pièce les déplacements et les règles spécifiques. Tableau 1 1 Déplacement des pièces Pièce Déplacement Règles Roi Une case à la fois, dans toutes les directions. Ne peut être côte à côte avec un autre roi. Ne peut se mettre en échec. Si en échec, alors doit «sauver» son échec. Peut roquer. Si le roi est la seule pièce à pouvoir bouger et que ce mouvement le place en échec, le roi est déclaré «pat». Reine Verticalement, horizontalement et en diagonale. d autant de cases que possible. Tour Verticalement et horizontalement d autant de cases que possible. Fou En diagonale d autant de cases que possible. Cavalier Deux cases verticalement ou horizontalement, puis une case en diagonale sans retour en arrière par rapport à la direction initiale (voir figure 5 4, page 50). Peut sauter des pièces. Pion Une case en avant. Si sur case de départ, alors peut avancer de deux cases. Prend sur une case en diagonale avant. Ne peut reculer. Prise en passant. Si arrivé sur l extrémité de l échiquier, se transforme en n importe quelle pièce (promotion), excepté le roi ou un autre pion. Enfin, rappelons que la partie est terminée lorsque l un des rois est en situation d être pris et qu il n existe aucune solution à l échec. 2

4 Du tableau précédent, on peut déduire un certain nombre de vérifications à effectuer à la fin de chaque coup : Le déplacement de la pièce est-il correct? Une situation d échec est-elle créée? Une situation de pat est-elle créée? Une pièce est-elle prise? Une situation de «coup spécial» est-elle créée (roque, prise en passant, promotion...)? Le résultat de ces tests pourra être : Poursuite de la partie par le second joueur. Affichage d un message annonçant une situation d échec. Annulation du coup joué et affichage d un message précisant la cause de l annulation. Communication entre les deux joueurs La possibilité d établir une communication synchrone entre deux navigateurs est sans doute un des apports les plus remarquables des versions 5 et suivantes de Flash. Elle s obtient au travers de l objet ActionScript XMLSocket, qui permet d établir une connexion permanente entre Flash Player et un serveur ; une fois celle-ci établie, il est possible de faire transiter entre le client et le serveur autant de messages (au format XMLObject.) que nécessaire. L usage de l objet XMLSocket nécessite, d une part un serveur écrit en Java dans notre cas et, d autre part, l emploi de l objet ActionScript XML pour encoder les messages. SWF et Flash Player Que ce soit sous forme de fichiers au format SWF ou sous forme d exécutable autonome, la technologie Flash est en constante progression. Initialement conçu comme un format d animation vectorielle pour le Web, le format SWF a vu ses capacités augmenter, que ce soit en termes de contrôle de l interaction ou en capacités multimédias. Les ambitions de ce format sont grandes et la société Macromédia mène une politique soutenue pour promouvoir son format. On signalera par exemple la possibilité de porter du contenu Flash sur des supports tels que des PDA ou des téléphones mobiles. Une abondante documentation est disponible au format SWF, sous forme de notes techniques, de livre blanc ou même de «CDK» (kit de développement de contenu) adapté aux projets de télévision interactive. FAQ et documentation B open/faq/ B flashplayer/resources/devices/itv/devkit/ Les versions de Flash Player Le tableau suivant résume la disponibilité de Flash Player, dans ses différentes versions pour différents systèmes d exploitation. (source Macromédia). 1 Descriptif et cahier des charges Serveur Java Messages au format XML SWF client Échange synchrone SWF client Figure 1 1 Les échanges serveur/client Nous aurions pu réaliser notre jeu d échecs en usant uniquement de la fonction LoadVariablesNum, en conjonction avec un langage côté serveur tel que PHP, ASP ou JSP. En utilisant ces langages pour stocker l information relative au mouvement des pièces et en interrogeant périodiquement une base de données ou un fichier XML voire un fichier texte, il était envisageable de simuler un fonctionnement au fil de l eau. Pourtant cette méthode ne permet pas de réaliser le «push» nécessaire à la synchronisation du mouvement des pièces sur chaque écran et multiplie, de manière peu adaptée, les requêtes sur le serveur. OS Win 95, Win 98, Me, NT 4.0, W2K, XP MacOS X 6 MacOS - PowerPC 6 Linux x86 5 Pocket PC 5 Sun Solaris 5 OS/2 4 SGI IRIX 4 Version disponible Pour plus d informations sur les versions disponibles, voir l URL : B download/alternates/ 6 3

5 Les Cahiers du programmeur Flash MX Les «tubes/flux» grâce à XML Socket vs GET/POST Lorsqu on établit un tube de communication entre deux entités, on dispose en quelque sorte d un câble coaxial dont les informations en écriture et en lecture emprunteraient, suivant l extrémité où l on se trouve, soit le centre, soit la nappe. La communication est directe de programme à programme via les couches basses du réseau, alors qu un GET ou un POST requièrent un encapsulation dans un en-tête HTTP, ainsi qu une lecture effective sans gestion d événement de réception, par exemple, ce qui ralentit d autant les performances. B.A.-BA Moteur de bases de données (SGBD) Un système de gestion de bases de données a entre autres avantages celui de permettre des accès concurrents aux données. Les plus répandus actuellement sont les systèmes basés sur l algèbre relationnelle, appelés bases de données relationnelles. Quant aux bases de données objet, telles O2 ou GemStone, elles sont en devenir et permettent de mêler les schémas classiques d une base de données relationnelles et les avantages des concepts objets. PHP PHP, langage de script interprété, permet de réaliser des pages dynamiques tout comme ASP ou JSP. Ce langage non propriétaire est disponible sur la plupart des hébergeurs, notamment les «gratuits» basés sur Linux. Nous recommandons la lecture de : R Les Cahiers du programmeur PHP/MYSQL (1) R Les Cahiers du programmeur PHP (2) B.A.-BA Langage interprété/compilé On notera encore que, du point de vue des performances, l utilisation d un «tube» (Socket) de communication est supérieure à l envoi de données dans un en-tête HTTP, que ce soit par la méthode GET ou POST. Dans notre application, XMLSocket sert à transmettre les déplacements de pièces en temps réel. La mise en place d un «tube» avec XMLSocket permet l échange de toute information, pourvu qu elle soit au format XMLObject. Le stockage de l information Du point de vue d un jeu d échecs, le stockage d informations sur un serveur n est pas un impératif, cependant il est judicieux de l aborder, dans la mesure où il s agit là d une lacune importante d ActionScript et que ce cahier se situe résolument dans la famille des applications en ligne. Sans le truchement d un langage côté serveur, il est impossible de stocker des données, que ce soit dans un fichier ou dans une base de données. Une partie d échecs doit pouvoir durer un certain temps : notre application doit donc offrir la possibilité de sauvegarder et de charger une partie. Nous verrons au chapitre 8 comment utiliser une base de données à des fins de paramétrage de SWF (sauvegarde et restauration d une partie). L écriture de ces informations se fera dans une base de données de type MySQL. La transmission des données vers cette base sera assurée par PHP. En résumé À ce stade, nous savons que notre application doit comporter trois ensembles de fonctionnalités : gestion de la partie et contrôle des coups ; échange de données en temps réel ; stockage de données. Structure de l application Le développement de ce jeu est suffisamment complexe pour que sa réalisation soit planifiée. Un langage interprété est un langage analysé lors de sa lecture tandis qu un langage compilé est un langage lu une fois puis transformé dans un autre langage plus rapide (en langage machine la plupart du temps). Comment répartir les traitements? Le tableau 1-2 place les ensembles fonctionnels définis précédemment face aux possibilités d ActionScript, d après diverses contraintes. 4

6 Tableau 1 2 Premier découpage Fonctionnalité Rôle dans un jeux d échecs Commande/fonctionnalité utilisée Contraintes Gestion de la souris Traitement Gérer la position des pièces sur un échiquier Gestion des règles : prises, roque, prise en passant, échec, échec et mat On Drag Positionnement de movie-clip Matrice Test de condition Recentrage des pièces dans les cases Implémentation des règles 1 Descriptif et cahier des charges Communication ou réseau Échanger les informations relatives au déplacement des pièces en mode synchrone Objet XMLSocket serveur Java XMLObject Codage et encodage Passage d une information structurée sous forme de tableau à une information codée en XML Synchronisation Authentification Notre application, pour fonctionner correctement, doit voir ses différents composants travailler ensemble. Comme nous l avons indiqué plus haut, nous allons construire le jeu d échecs autour de la séquence/prise de pièce/déplacement/pose de pièce. En distribuant la liste des fonctionnalités à implémenter autour de ces trois points, nous allons pouvoir définir une répartition des traitements. Avant que la partie ne débute, une phase de paramétrage est nécessaire. Notre application est donc composée de deux écrans : le premier est consacré à la connexion des deux joueurs, à l initialisation du contexte (création des objets, initialisation des variables), le second comprend l échiquier et l interface de jeu proprement dite. Vue générale L application est scindée en ensembles divers, de nature et d importance variées. On peut distinguer : la collecte et le stockage en mémoire des informations liées au jeu ; l affichage du jeu ; les traitements liés au contrôle du jeu ; la préparation de données et leur envoi au serveur ; la réception des données, leur décodage et les traitements qui en découlent ; le stockage des coups joués sur une base de type MySQL. La figure 1 2 présente d une part, la répartition des traitements, d autre part, leur regroupement au sein des différents chapitres. On notera que le contrôle du coup fournit un bon support pour explorer les capacités objet d ActionScript. 5

7 Les Cahiers du programmeur Flash MX Collecte des informations Représentation et stockage mémoire Affichage Chapitre 3 Découpage de l'application en movie-clips Gestion de la souris Construction de la matrice Chapitre 4 Définition d'une structure permettant de gérer le déroulement des coups Traitements de contrôle du jeu Chapitre 5 Traitements liés au déplacement Chapitre 6 Les coups spéciaux Chapitre 7 POO avancée avec Flash MX Stockage sur disque (MySQL) Chapitre 8 Utilisation de MySQL pour stocker une partie Chapitre 9 Création du serveur Java Chapitre 10 Flash-XML Envoi Chapitre 11 Le client ActionScript XMLSocket Chapitre 12 Composants et applicatifs Flash Figure 1 2 Répartition par chapitre 6

8 Choix et contraintes techniques Cette partie définit les choix techniques retenus pour cette application. Environnement Notre jeu d échecs est destiné à être affiché dans une page Web. Il répond donc aux contraintes suivantes : faible bande passante nécessaire mais accès permanent obligatoire durant la partie ; le poids maximum est fixé 100 ko pour l ensemble du jeu ; plates-formes supportées : Macintosh ou Windows ; plug-in Flash 5 installé ; matériel minimum requis : PII 300, 64 Mo ou G Mo. Matériel requis La puissance des PowerPC est supérieure, à vitesse égale, à celle des Pentium. En revanche, l OS d Apple gère différemment de Windows la mémoire virtuelle. C est pourquoi la mémoire nécessaire sur Macintosh est double de celle nécessaire sur PC, avec un processeur plus rapide sur PC que sur Macintosh. 1 Descriptif et cahier des charges La partie communication côté serveur Pour gérer l envoi et la réception des informations d un joueur à l autre, il faut un serveur capable de comprendre l objet XMLSocket. Nous avons choisi de créer notre propre serveur, car il nous faut un langage supportant les sockets, qui soit aussi proche que possible d ActionScript : nous choisissons donc Java. Nous devons disposer d un éditeur et d un compilateur Java : UltraEdit sur PC et BBEdit sur Mac pour l édition, ainsi que le JDK de Sun pour la compilation et l interprétation. Réalisation La réalisation du serveur est résumée à la figure 1 3. Étapes Téléchargement du JDK Installation Rédaction du Fichier Compilation du fichier source Exécution du programme (lancement du serveur en ligne de commande) Outils UltraEdit/BBEdit JDK Figure 1 3 Les étapes de la réalisation du serveur Synchrone/asynchrone : définition et exemple Il existe deux sortes de modes de communication : synchrone et asynchrone. Si l on peut assimiler le mode synchrone à celui du téléphone, le mode asynchrone ressemble davantage à celui de la boîte postale. En effet, en mode synchrone, chaque intervenant peut parler quand bon lui semble et tous ses interlocuteurs reçoivent l information immédiatement. En mode asynchrone par contre, une personne qui a un message à faire passer doit le déposer dans une boîte que les autres relèvent. Un temps de latence variable, parfois important, peut donc s écouler entre l envoi du message et sa récupération. La communication par Socket (XMLSocket) s inscrit dans le premier cadre tandis que le stockage dans une base de données correspond au second. 7

9 Les Cahiers du programmeur Flash MX B.A.BA L adresse IP est l adresse unique correspondant à l adresse de la carte réseau de l ordinateur sur Internet. Elle est formée de quatre trigrammes de chiffres. L adresse locale d une machine est C est-à-dire que si vous saisissez dans la barre d adresse de votre navigateur, vous verrez le serveur de votre machine si celui-ci est présent. Cette adresse peut être suivie d un port. Exemple : :8080 indique le port 8080 de la machine contenant le navigateur. Les ports 80 et 8080 sont généralement utilisés pour les serveurs Web (HTTP). IP Déploiement Pour une utilisation personnelle, les clients SWF peuvent se connecter sur le serveur présent sur le poste de travail en indiquant son adresse IP. Pour un déploiement professionnel, vous pourriez envisager de placer le serveur chez un fournisseur d accès Internet (FAI) sur une machine mutualisée. Cependant, outre les problèmes de charge (chaque client se connectant crée un processus fils, la mémoire nécessaire croît avec le nombre de connexions), les FAI refuseront d héberger un tel serveur sur une machine mutualisée car ils ne souhaitent pas, pour des raisons de sécurité, modifier les configurations de leurs machines en vue d accepter des serveurs autres que leur serveur Web et ce, même sous forme de module externe (CGI, servlets, etc.). Si vous souhaitez faire fonctionner en permanence une application Flash en réseau, nous vous conseillons d héberger votre propre machine chez un FAI, car l installation et la configuration de cette machine sont exactement les mêmes que pour une utilisation «privée» sur votre poste de travail. De plus, dans le cas d un serveur «public», vous devez pouvoir gérer plusieurs parties. À des fins de simplification, l exemple proposé ne traite pas la gestion de plusieurs parties simultanément ; nous vous indiquerons néanmoins les changements à réaliser. La partie sauvegarde La sauvegarde (enregistrement permanent sur disque) en vue de la restauration d une partie est réalisée dans une base MySQL, via le langage PHP : nous avons choisi le couple PHP/MySQL car il est gratuit, performant et facile à mettre en œuvre sur nos deux plates-formes. Déploiement Le déploiement en «local» consistera en l installation, la configuration du serveur Web, de PHP et de MySql ainsi qu en la création de la base et la rédaction des scripts PHP, tandis que le déploiement chez un hébergeur se cantonnera à la création de la base et au dépôt des fichiers PHP. En résumé Le cas du jeu d échecs est un bon sujet dans la mesure où il permet d aborder la gestion de multiples conditions liées au contrôle du jeu ainsi que les échanges réseaux : communication en temps réel via XMLSocket ; enregistrement dans une base de données. Avant de commencer la réalisation de notre application, il nous faut mettre en place les outils de développement : ce point est traité dans le chapitre 2. 8