Étude de cas - eyrolles.com · Nous souhaitons concevoir un jeu original et novateur, basé sur un concept qui a fait ses preuves. Ce jeu est un ... Jeux vidéo avec Director 8.5

CH

AP

ITR

EÉtude de cas :jeu multijoueur

chap12.fm Page 279 Vendredi, 29. mars 2002 4:55 16

Jeux vidéo avec Director 8.5

280

CH

AP

ITR

E 12Nous allons maintenant réaliser notre premier jeu multijoueur avec Director, Lingo et l’Xtra MultiUser 3.0 étu-dié dans le chapitre précédent. Ce jeu est relativement complexe à mettre en œuvre, car il faut réaliser à la foisun moteur pour toutes les fonctions liées à la gestion du jeu, comme le déplacement des sprites et les tests decollision, et un moteur de fonctions en ligne qui permettront la connexion à un serveur et l’échange d’informa-tions en temps réel entre les joueurs.

Concept du jeu « Escape from the Lost Pyramids »Nous souhaitons concevoir un jeu original et novateur, basé sur un concept qui a fait ses preuves. Ce jeu est unBomberman like, comme disent les puristes. Bomberman a plus de dix ans maintenant. Il a fait son apparitionen 1990 sur la console de jeux PC Engine de NEC, console plutôt rare en France. Rapidement élevé au rang dejeu culte, Bomberman a connu d’innombrables versions sur toutes les plates-formes existantes. Il doit son suc-cès à son concept, simple et multijoueur. Le but était de déposer des bombes, de se frayer un chemin en faisantexploser des obstacles et d’éviter les bombes des adversaires en ramassant des bonus augmentant le potentiel dedestruction.

Perspective du jeuPour notre étude de cas, nous avons repris ce concept en le modifiant et en augmentant sa complexité, notam-ment dans la perspective. Nous avons en effet longuement étudié quelle serait la meilleure perspective pour cetype de jeu, car nous n’étions pas convaincu par la perspective trop simpliste du jeu original. Nous avons finale-ment opté pour une vue isométrique (voir l’esquisse numéro 2 de la figure 12.1) qui propose un angle de visionplutôt réaliste mais plus complexe à concevoir en termes de développement et de programmation.

FIGURE 12.1 – Études des différentes perspectives possibles.


Étude de cas : jeu multijoueur

281

CH

AP

ITR

E 12Perspective des spritesLe jeu est complexifié par le choix de la perspective isométrique. En effet, cette vue impose l’utilisation d’unetechnique appelée « clipping », technique très utilisée dans la programmation des jeux vidéo. Le clipping permeten partie de simuler un effet de perspective en cachant partiellement (ou intégralement) des sprites avecd’autres sprites ou des éléments du décor. Cette technique permet d’obtenir une vision plus réaliste de la scènedu jeu (voir la figure 12.2).

Avec Director, nous allons rencontrer plusieurs problèmes si nous appliquons directement cette technique. Eneffet, le langage Lingo est bien moins performant que le langage C ou le langage Assembleur pour l’exécution deprocessus rapide et le clipping nécessite un minimum de célérité. Nous allons donc simuler le clipping avecDirector en utilisant plusieurs pistes du scénario. Nous verrons plus loin comment procéder pour obtenir lerésultat le plus réaliste possible.

But du jeuLe but du jeu est très simple : il faut parcourir plusieurs niveaux dans lesquels le joueur trouve une clé, une sor-tie et des bonus. Le joueur doit prendre le plus rapidement possible la clé et trouver la sortie du jeu. Pour sedéplacer, il doit se frayer un chemin en détruisant un certain nombre d’obstacles (voir la figure 12.3). Les obsta-cles peuvent être détruits en déposant un bâton de dynamite (pression sur la barre Espace du clavier) à proxi-mité. Le déplacement des joueurs se fait avec les flèches du clavier (Haut, Bas, Droite et Gauche).

La scène du jeu est quadrillée, comme le montre la figure 12.3, avec un système de dalles isométriques. Nousavons ainsi un quadrillage sous forme de tableau avec douze lignes et douze colonnes. Certaines zones serontinaccessibles comme les zones contenant de la lave en fusion.

Les bâtons de dynamite peuvent faire exploser les obstacles mais aussi neutraliser le joueur adverse pendantquelques secondes. Attention de ne pas se brûler soi-même !

Le jeu original permet de connecter plus de quatre joueurs ensemble. Une fois les fonctions de communicationréseau créées, il n’est pas très difficile de concevoir ce mode multijoueur avec Director et le serveur MultiUser3.0. Notre jeu permet même une connexion simultanée (mais théorique) de 2000 joueurs (avec une licence de

FIGURE 12.2 – Clipping.Le contexte n° 2 montre une situation où le sprite du deuxième plan est partiellement caché par le sprite du premier plan. Cette technique donne l’impression que le personnage est plus loin que l’objet.



282

CH

AP

ITR

E 12Director 8.5 Shockwave Studio). Nous laisserons cette possibilité pendant la phase de connexion au jeu maisnous limiterons, pour cette version, le nombre de joueurs effectifs à deux pour ne pas complexifier à l’excèsl’algorithme du jeu.

Modes de jeuLa partie droite de la scène représente un tableau pour l’affichage du chronomètre et d’autres informationscomme les meilleurs scores. Le bas de ce tableau affiche deux boutons, « Discuter » et « Jouer », qui permettentde basculer d’un mode de jeu normal, avec déplacement des joueurs (flèches du clavier), à un mode de jeu dit« mode de discussion », qui permet de discuter en temps réel avec le joueur adverse (voir la figure 12.4).

FIGURE 12.3 – Premier niveau du jeu.

FIGURE 12.4 – Second niveau du jeu en mode de discussion.



283

CH

AP

ITR

E 12Connexion au jeuLa première phase du jeu consiste à saisir le nom du joueur. Un champ de saisie est prévu avec un bouton per-mettant de lancer la connexion au serveur (voir figure 12.5). Une petite animation du personnage principal(avatar du joueur) est visible dans la fenêtre de jeu.

Le joueur est connecté. Il accède à la deuxième phase du jeu, qui permet de discuter en temps réel avec les autresjoueurs connectés au serveur (voir figure 12.6). Un premier acteur texte affiche le nom de tous les joueurs pré-sents (rappelons que le nombre de joueurs possible est limité à 50 pour la version d’évaluation de Director 8.5et à 2 000 pour une version avec licence).

Un deuxième acteur texte affiche tous les messages envoyés par les joueurs au serveur. Pour finir, nous avonsdisposé un champ de saisie permettant d’écrire le message à envoyer et deux boutons-poussoirs pour envoyer lemessage ou pour quitter le jeu.

FIGURE 12.5 – Première phase : saisie du nom du joueur.

FIGURE 12.6 – Deuxième phase : module dediscussion en temps réel avec les autres joueurs.



284

CH

AP

ITR

E 12Vient ensuite la troisième et dernière phase qui précède le début d’une partie. Par un simple clic de la souris surle nom d’un joueur, il est possible de lui proposer une partie. Un message d’attente s’affiche alors (voir figure12.7). Le joueur qui est sollicité doit répondre par oui ou par non pour accepter ou refuser la partie.

La partie commence si le joueur n° 2 répond par oui. S’il répond par non, les deux joueurs reviennent aumodule de discussion en temps réel.

Programmation de l’étude de casLaissons provisoirement de côté la gestion des processus de communication réseau et concentrons-nous sur laprogrammation intrinsèque du jeu. Étant donné la perspective isométrique de la fenêtre de jeu, nous avons uti-lisé une méthode simple mais efficace et fiable pour gérer le déplacement des joueurs sur la scène.

FIGURE 12.7 – Propositionde partie.



285

CH

AP

ITR

E 12Scène du jeuLa scène est quadrillée par douze lignes et douze colonnes composant 144 cases distinctes et indépendantes. Ilest donc aisé d’imaginer une matrice à deux dimensions (autrement dit un tableau) avec douze lignes et douzecolonnes. En Lingo, nous pouvons créer une liste de 144 éléments pour simuler ce tableau. Nous avonsd’ailleurs utilisé une méthode équivalente lors du développement du jeu Memory (voir chapitre 6).

Reprenons à titre d’exemple le niveau 1 du jeu (voir figure 12.3). Nous pouvons découper le quadrillage en qua-tre catégories distinctes. La première représente toutes les dalles vides, libres d’accès. La deuxième constitue lesdalles encombrées par des obstacles et temporairement inaccessibles. La troisième rassemble les cases rempliesde lave en fusion et la dernière les zones invisibles et inaccessibles (la perspective isométrique masque partielle-ment la partie droite de la scène).

Si nous affectons un numéro à chaque catégorie, nous pouvons représenter virtuellement la scène sous la formede la liste gArray[] :

-- Cette liste de 12x12 éléments numériques

-- représente un tableau virtuel de 12 lignes et de 12 colonnes.

-- Les numéros 0 correspondent à des espaces libres.

-- Les numéros 2 représentent des obstacles.

-- Les numéros 1 correspondent à des zones de lave

-- Les numéros 3 représentent des zones d'accès impossibles.

gArray = []

gArray = [0,2,0,0,2,2,0,2,0,3,3,3,\

2,1,0,1,1,1,0,1,2,3,3,3,\

0,2,0,2,1,0,0,2,0,1,3,3,\

0,0,0,2,1,1,2,1,0,0,3,3,\

2,0,2,0,2,2,0,1,1,0,1,3,\

1,1,2,0,1,2,0,0,1,2,1,3,\

0,0,2,1,1,2,1,2,1,0,0,3,\

0,2,0,0,0,0,1,2,2,0,1,1,\

2,1,0,0,1,0,0,0,1,0,0,0,\

0,2,2,1,0,2,1,1,1,1,0,0,\

0,0,2,1,2,0,2,0,0,1,0,0,\

0,0,0,0,0,1,2,0,0,0,0,0]

Nous avons ainsi une représentation modulable de la scène au niveau 1. On peut à tout moment modifier lesvaleurs de cette liste en affectant de nouvelles valeurs à un ou plusieurs éléments. Par exemple, si nous avonsbesoin de rendre toutes les zones du niveau 1 accessibles et libres, il suffit d’affecter la valeur 0 à tous les élé-ments de la liste, comme dans le script suivant :

repeat with n = 1 to 144

gArray[n] = 0

end repeat

Cette représentation nous permettra ensuite, en vérifiant la position des joueurs dans ce tableau virtuel, dedéplacer les joueurs sur la scène et de vérifier instantanément la présence d’obstacles ou de lave.



286

CH

AP

ITR

E 12Génération d’un masque de couleursLe déplacement des joueurs s’effectue au moyen de pressions sur les touches directionnelles du clavier (flèchesHaut, Bas, Droite et Gauche). De gauche à droite, le sprite du joueur se déplacera horizontalement mais de hauten bas, et du fait de la représentation isométrique, le joueur suivra une trajectoire rectiligne et oblique, parallèleaux colonnes du quadrillage de la scène.

Pour vérifier la présence d’obstacles, de zones libres ou non, nous avons mis en œuvre une astuce qui utilise deszones de couleur, invisibles pour le joueur, mais « visibles » par le programme. Ces zones de couleur nous per-mettent de segmenter la scène en quatre catégories distinctes (verte, bleue, rouge et noire). Nous avons créé unefonction qui permet de générer, à partir d’éléments de base sous formes de blocs élémentaires de couleur (voirla figure 12.8), la scène complète avec une perspective isométrique (voir la figure 12.9).

Cette scène est générée à partir des valeurs de la liste gArray[].

Voici le code source de cette procédure que vous retrouverez dans le programme d’exemple ex12_01.dir sur leCD-Rom :

-- ************************************************

-- Fonction generation_color1()

-- Cette fonction permet de créer l'arrière-plan

-- "masque" avec toutes les zones de couleur.

-- ************************************************

on generation_color1()

-- création du background "masque" à partir de l'image vide "masque1"

-- (même dimensions)

masque_tmp = "masque1"

member("masque").image.copyPixels(member(masque_tmp).image,\

rect (0,164,556,420), member(masque_tmp).rect)

FIGURE 12.8 – Les quatre blocs élémentaires de couleur.



287

CH

AP

ITR

E 12 -- dimensions d'un bloc unitaire en abscisse (blocX)

-- et en ordonnée (blocY)

blocX = 43

blocY = 21

-- dimension des espacements

tmp = 15

tmp2 = 0

-- Cette boucle génère les 144 blocs en affectant pour chaque valeur

-- issue de gArray[] la couleur adéquate

repeat with n = 1 to 144

-- Prendre la valeur correspondant au bloc.

bloc = gArray[n]

-- Déterminer la ligne du tableau [1-12]

tmp1 = n/12

-- puis la colonne [1-12]

tmp2 = tmp2 + 1

if tmp2 > 12 then tmp2 = 1

-- et intégrer sur masque, au bon endroit et en fonction

-- de la valeur affectée, le bloc de couleur

case bloc of

-- bloc vert (zone libre)

0:

member("masque").image.copyPixels(member("bloc02").image,\

rect(131-(tmp1*tmp)+(tmp2*blocX),165+(tmp1*blocY), 187+(tmp2*blocX)-(tmp1*tmp),187+(tmp1*blocY)),\

member("bloc02").rect,[#ink: 36])

-- bloc rouge (lave)

1 :


rect(131-(tmp1*tmp)+(tmp2*blocX),165+(tmp1*blocY),187+(tmp2*blocX)- (tmp1*tmp),187+(tmp1*blocY)),\


-- bloc bleu (obstacle)

2 :


rect(131-(tmp1*tmp)+(tmp2*blocX),165+(tmp1*blocY),187+(tmp2*blocX)- (tmp1*tmp),187+(tmp1*blocY)),\


-- bloc noir (zone inaccessible)

3 :




288

CH

AP

ITR

E 12 rect(131-(tmp1*tmp)+(tmp2*blocX),165+(tmp1*blocY),187+(tmp2*blocX)- (tmp1*tmp),187+(tmp1*blocY)),\


end case

end repeat

end

Cette procédure s’exécute en trois phases. La première consiste à créer un masque vide (donc de couleur verte)de la scène à l’aide des instructions :

-- création du background "masque" à partir de l'image vide "masque1"

-- (même dimensions)

masque_tmp = "masque1"

member("masque").image.copyPixels(member(masque_tmp).image,\

rect(0,164,556,420), member(masque_tmp).rect)

Vous noterez qu’une fois de plus, nous utilisons la fonction copyPixels() entre l’acteur source masque1 etl’acteur destination masque. Rien de très compliqué jusqu’ici, nous ne faisons que générer une scène vierge detout élément autre que des zones libres d’accès.

La deuxième phase consiste à définir les dimensions des blocs que nous allons copier ainsi que leurs espace-ments. Ces informations sont stockées dans des variables locales et temporaires.

Enfin la dernière phase sous forme de boucle repeat with n = 1 to 144 se charge de vérifier, une à une, lesvaleurs de la liste gArray[] et détermine, à l’aide d’une instruction conditionnelle case … of, quel élément decouleur copier à quel endroit. Le résultat final de cette opération est visible sur la figure 12.9, les 144 blocs decouleurs étant copiés sur la scène.

RemarqueL’instruction utilisée pour copier les blocs de couleur intègre le paramètre [#ink : 36], qui permet de ne pas copier le fond de l’image (option fond transparent).

FIGURE 12.9 – Scène complète générée avec les blocs de couleur.


Documents

Étude de cas - eyrolles.com · Nous souhaitons concevoir un jeu original et novateur, basé sur un concept qui a fait ses preuves. Ce jeu est un ... Jeux vidéo avec Director 8.5