Skip to main content

Pac-Man pour Smartphone

Publié le 9 novembre 2006 

Cet article explique comment écrire le jeu Pac-Man pour la plateforme Smartphone Windows Mobile 5.0

Auteur : Bryan Dougherty

Consulter l’article en anglais

Niveau de difficulté : Intermédiaire

Temps requis : 3 à 6 heures

Coût : 40 à 80 €

Logiciels : Visual Basic ou Visual C# Express

Matériel : Motorola MPX220

Téléchargements : Télécharger

Introduction

J’ai toujours aimé la technologie mobile et je voulais donc m’essayer au développement mobile. Il y a quelque temps, j’ai acheté un Smartphone, Motorola MPX220, qui fonctionne sous le système d'exploitation Windows Mobile 2003. J’espère acheter un nouveau Smartphone d’ici peu. Ainsi, cet article concerne la création d’une application pour la plateforme Smartphone Windows Mobile 5.0.

J’ai réfléchi aux différentes applications utiles que je pouvais développer. Mais finalement, j’ai décidé qu’un jeu serait plus amusant. J’ai donc opté pour un classique : Pac-Man.

Figure 1 : Pac-Man dans l’émulateur Smartphone Windows Mobile 5.0.

Figure 1 :Pac-Man dans l’émulateur Smartphone Windows Mobile 5.0.

Pour démarrer

Avant de se plonger dans le code, voici quelques-uns des éléments que j’ai utilisés lors du développement pour le Smartphone.

Environnement de développement

Afin de créer des applications pour la plateforme Smartphone Windows Mobile 5.0, vous devez installer les applications ci-dessous :

  • Visual Studio .NET 2005 Professional
  • Kit de développement logiciel Smartphone Windows Mobile 5.0
  • ActiveSync Version 4.1.0

Nouveau projet

Une fois que l’environnement de développement est en place, les nouveaux modèles Smartphone Windows Mobile 5.0 apparaissent dans la boîte de dialogue Nouveau projet de Visual Studio.

Notez que vous choisissez la version du Compact Framework que vous ciblez lorsque vous sélectionnez le modèle de projet. La mention « 1.0 » figure après le nom de ceux qui ciblent CF1.0, tandis que les autres ciblent le 2.0 Framework.

En général, le développement est semblable à celui de toute application WinForm. Par contre, n’oubliez pas que certaines fonctionnalités prises en charge par le .NET Framework standard ne le sont pas avec le Compact Framework. Pour davantage d’informations sur la prise en charge des classes, consultez la bibliothèque MSDN Library.

L’émulateur

Lors du développement, inutile de déployer votre application sur un téléphone réel pour la tester. Vous pouvez utiliser un émulateur intégré (figure 1) à la place. En un clic, vous déployez l’émulateur et vous testez votre application avec des fonctions complètes de débogage, comme pour une application WinForm. Normalement, le comportement et la vitesse de l’émulateur offrent un aperçu raisonnable sur la performance de l’application sur un téléphone réel.

Développement

Au lieu de me précipiter et d’essayer de trouver le code pour Pac-Man, j’ai adopté une approche plus structurée. Avec quelques contrôles du concept sous le coude, j’ai décidé de créer une infrastructure qui fournirait les blocs de construction communs nécessaires à la création de jeux 2D pour un Smartphone. Je cherchais à développer les fonctionnalités suivantes :

  • Un plateau de jeu (GameBoard) qui contrôle de façon efficace le dessin et le flux du jeu.
  • Une base pour définir les personnages du jeu pris en charge par le plateau de jeu.
  • Une prise en charge intégrée pour les interactions communes entre les personnages.

Un test décisif de réussite consisterait à déterminer si une personne (comme vous) peut utiliser cette infrastructure pour créer un jeu vidéo 2D classique, comme Frogger, simplement en écrivant le nouveau code qui gère les interactions entre les personnages du jeu.

Dans la suite de cet article, je décris quelques-uns des concepts clés que j’ai intégrés à l’infrastructure.

Les sprites

La classe Sprite sert de base à tous les personnages du jeu. Dans Pac-Man, cela concerne les fantômes, les points, les murs, et Pac-Man lui-même. Cette classe est abstraite, ce qui force toutes les classes dérivées à implémenter deux méthodes :

public abstract void Update();

public abstract void Draw(Graphics gameSurface);

Bien entendu, ces méthodes attendent respectivement de la classe dérivée qu’elle mette à jour leur état et les dessinent sur le plateau de jeu. Les méthodes sont fournies pour obtenir l’instance du GameBoard à laquelle le sprite a été ajouté, et pour détecter les collisions entre un sprite et une liste d’autres sprites. Par ailleurs, une instance de Sprite doit gérer plusieurs propriétés d’état :

  • ID – Doit être unique par GameBoard.
  • Bounds – Un rectangle qui définit le périmètre de l’objet. Une version prochaine pourrait utiliser une Région ou une autre construction pour suivre de façon plus précise la zone occupée par le sprite. Cette propriété est utilisée pour détecter les collisions et pour le dessin.
  • Invalid – Une valeur booléenne qui indique au GameBoard si un sprite doit être redessiné.
  • Visible – Une valeur booléenne qui décide si un sprite doit être dessiné ou non.

GameBoard

La classe GameBoard contrôle le flux du jeu. Elle est dérivée de System.Windows.Forms.Form et, comme la classe Sprite, ne peut pas être créée. Cette structure d’héritage permet au développeur de gérer tous les événements de formulaire nécessaires à son jeu. Voici un exemple dans lequel la classe GameBoard de l’application Pac-Man écoute la saisie de l’utilisateur en remplaçant la méthode OnKeyDown.

    _KeyPressed = true;

    base.OnKeyDown (e);

    if(e.KeyCode == Keys.Right || e.KeyCode == Keys.Left || e.KeyCode == Keys.Up || e.KeyCode == Keys.Down)

    {

        switch(e.KeyCode)

        {

            case Keys.Right:

            {

                _Pacman.MovementDirection = MovementDirections.Right;

                break;

            }

            case Keys.Left:

            {

                _Pacman.MovementDirection = MovementDirections.Left;

                break;

            }

            case Keys.Down:

            {

                _Pacman.MovementDirection = MovementDirections.Down;

                break;

            }

            case Keys.Up:

            {

                _Pacman.MovementDirection = MovementDirections.Up;

                break;

            }

        }

    }

}

Chaque application de jeu doit créer sa propre classe de plateau de jeu, dérivée de GameBoard. Il faut alors créer les sprites des personnages et les ajouter à la liste des sprites du GameBoard. Puis, une fois que le GameBoard a été chargé, une minuterie (Timer) est utilisée pour appeler les méthodes Update et Draw sur les sprites, comme indiqué ci-dessus.

Dessin

Alors, comment fonctionne exactement le dessin des sprites ? Du point de vue d’un sprite, c’est simple. Un sprite a uniquement besoin de savoir comment se dessiner. Un sprite de point, par exemple, dessine simplement un rectangle dans l’objet graphique du plateau de jeu.

 

publicoverride void Draw(Graphics gameBoard)

{

    if(!_IsEaten)

    {

        gameBoard.FillRectangle(new SolidBrush(Color.LightBlue), _Bounds);

    }

}

 

Les méthodes Draw pour les sprites de Pac-Man et des fantômes sont plus compliquées et dessinent l’une des séries d’images bitmap sur le plateau de jeu. Les images variables, ainsi que les Bounds mis à jour, créent l’animation. Lors du dessin, un couleur est choisie (magenta dans la figure 3 ci-dessous) pour indiquer quelles portions de l’image doivent être considérées comme étant transparentes.

Figure 3 :Image agrandie d’un sprite de fantôme.

Figure 3 : Image agrandie d’un sprite de fantôme.

La classe GameBoard rend le dessin sur l’écran aussi opérationnel que possible. Elle remplace les méthodes OnPaint et OnPaintBackground de formulaire puisqu’elle contrôle l’ensemble de la mise à jour de l’écran. La méthode OnPaint vérifie que seules les portions de l’écran qui ont changé sont redessinées. Par ailleurs, elle utilise un tampon d’arrière-plan pour minimiser tout scintillement.

protected override void OnPaint(PaintEventArgs e)

{

    if(_BackBuffer == null)

    {

        return;

    }

 

    Graphics g = Graphics.FromImage(_BackBuffer);

 

    ArrayList changedSprites = new ArrayList();

    // blank out any invalid Sprites previous position in the back buffer

    foreach(Sprite sprite in _SpritesByZIndex)

    {

        if(sprite.Invalid)

        {

            g.FillRectangle(new SolidBrush(_BackgroundColor), sprite.PreviousBounds);

            changedSprites.Add(sprite);

        }

    }

 

    // now draw them to the back buffer

    foreach(Sprite sprite in changedSprites)

    {

        if(sprite.Visible)

        {

            sprite.Draw(g);

        }

    }

 

    if(_FullRepaint)

    {

        // draw the entire back buffer

        e.Graphics.DrawImage(_BackBuffer, 0, 0);

        _FullRepaint = false;

 

        foreach(Sprite sprite in _SpritesByZIndex)

        {

            // reset Invalid flag

            sprite.Invalid = false;

        }

    }

    else

    {

        // only draw the parts that have changed

        foreach(Sprite sprite in changedSprites)

        {

            e.Graphics.DrawImage(_BackBuffer, sprite.Bounds, sprite.Bounds, GraphicsUnit.Pixel);

            e.Graphics.DrawImage(_BackBuffer, sprite.PreviousBounds, sprite.PreviousBounds, GraphicsUnit.Pixel);

 

            // reset Invalid flag

            sprite.Invalid = false;

        }

    }

}

Observations en matière de développement mobile

Comme je l’ai dit précédemment, du point de vue du code, le développement d’applications mobiles dans .NET est très semblable à la création d’applications WinForm standards. Cependant, ce petit projet a révélé plusieurs facteurs qu’il faut prendre en compte avec les applications mobiles, la plupart liés au mot « petit ».

Le facteur le plus évident est que le matériel a un petit écran. Cela signifie que vous devez créer une interface utilisateur qui soit simple d’emploi avec peu de décors. En d’autres mots, les choses doivent rester simples. Un autre facteur à prendre en compte en matière d’écran est que la taille et la résolution des écrans varient d’un téléphone à un autre. Je n’ai pas géré cet aspect avec ma première ébauche de Pac-Man, mais il figure sur ma liste de tâches. Lors des tests, j’ai visé une résolution plus basse qui fonctionnerait sur mon téléphone.

Avec tout type d’application, mais en particulier avec un jeu, vous devez penser à l’interaction de l’utilisateur avec les petites touches de son téléphone, parfois juste avec le pouce ! J’ai sciemment légèrement modifié les contrôles de Pac-Man par rapport au jeu classique pour compenser la difficulté liée à l’utilisation d’un pavé directionnel. Cette modification a reçu des commentaires mitigés de la part des utilisateurs qui ont essayé le jeu. Mais c’est bien là l’intérêt des tests, non ?

Un autre « petit » facteur concerne la puissance du téléphone. Même si un Smartphone est bien plus puissant que mon vieil ordinateur couleur Tandy 64K, le premier ordinateur que j’ai utilisé pour les jeux vidéo, j’ai été obligé de modifier légèrement le code pour des raisons de performance. Je savais bien avant de le faire que le jeu nécessiterait une logique de dessin extrêmement efficace. Cependant, j’étais étonné de constater que le temps de traitement du code qui prépare les chemins possibles pour les fantômes est extrêmement long. Ainsi, j’ai veillé à ce que cette logique soit uniquement traitée lors du premier affichage de l’écran de démarrage. Elle est alors mise en cache pour une réutilisation ultérieure.

Conclusion

La voici…enfin, la première version du jeu en tout cas. Je vais régulièrement mettre à jour le jeu pour le rendre plus efficace et plus amusant, avec des fantômes plus réduits pour commencer. Peut-être même que j’irais jusqu’à développer Frogger pour voir si la petite infrastructure que j’ai assemblée tient la route. Par ailleurs, je veux vraiment ajouter une fonction qui transmette les meilleurs scores à un site Web. Après tout, qu’est-ce qu’un jeu sans un peu de compétition ?

J’ai récemment commencé un blog à ce sujet et sur d’autres sujets liés au développement logiciel sur le site blog de mon entreprise. Le code et le jeu compilé pour toutes les plateformes seront également fournis sur ce site. N’hésitez pas à le consulter pour des mises à jour, et à donner votre avis.

Microsoft réalise une enquête en ligne pour comprendre votre opinion sur le site Web de. Si vous choisissez de participer, l’enquête en ligne vous sera présentée lorsque vous quitterez le site Web de.

Souhaitez-vous y participer ?