Viadeo Twitter Google Bookmarks ! Facebook Digg MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Toutes les fonctions  ·  Vues d'ensemble  · 

Rogue Example


The Rogue example shows how to use the Qt state machine for event handling.

This example implements a simple text based game. Do you see the @ in the screenshot? That's you, the rogue. The # characters are walls, and the dots represent floor. In a real game, other ASCII characters would represent all kinds of objects and creatures, for instance, ancient dragons (Ds) or food rations (%s). But let's not get carried away. In this game, the rogue is simply running around in an empty room.

The rogue is moved with the keypad (2, 4, 8, 6). That aside, we have implemented a quit command that triggers if the player types q. The player is then asked if he/she really wants to quit.

Most games have commands that need more than one key press (we think of consecutive presses, i.e., not of several keys being pressed at the same time). In this game, only the quit command falls under this category, but for the sake of argument, let's imagine a fully-fledged game with a rich set of commands. If we were to implement these by catching key events in keyPressEvent(), we would have to keep a lot of class member variables to track the sequence of keys already typed (or find some other way of deducing the current state of a command). This can easily lead to spaghetti, which is--as we all well know, I'm sure--unpleasant. With a state machine, on the other hand, separate states can wait for a single key press, and that makes our lives a lot simpler.

The example consists of two classes:

  • Window draws the text display of the game and sets up the state machine. The window also has a status bar above the area in which the rouge moves.
  • MovementTransition is a transition that carries out a single move of the rogue.

Before we embark on a code walkthrough, it is necessary to take a closer look at the design of the machine. Here is a state chart that shows what we want to achieve:

The input state waits for a key press to start a new command. When receiving a key it recognizes, it transitions to one of the two commands of the game; though, as we will see, movement is handled by the transition itself. The quit state waits for the player to answer yes or no (by typing y or n) when asked whether he/she really wants to quit the game.

The chart demonstrates how we use one state to wait for a single key press. The press received may trigger one of the transitions connected to the state.

Window Class Definition

The Window class is a widget that draws the text display of the game. It also sets up the state machine, i.e., creates and connects the states in the machine. It is the key events from this widget that are used by the machine.

 class Window : public QWidget
     Q_PROPERTY(QString status READ status WRITE setStatus)

     enum Direction { Up, Down, Left, Right };


     void movePlayer(Direction direction);
     void setStatus(const QString &status);
     QString status() const;

     QSize sizeHint() const;

     void paintEvent(QPaintEvent *event);

Direction specifies the direction in which the rogue is to move. We use this in movePlayer(), which moves the rogue and repaints the window. The game has a status line above the area in which the rogue moves. The status property contains the text of this line. We use a property because the QState class allows setting any Qt property when entered. More on this later.

     void buildMachine();
     void setupMap();

     QChar map[WIDTH][HEIGHT];
     int pX, pY;

     QStateMachine *machine;
     QString myStatus;

The map is an array with the characters that are currently displayed. We set up the array in setupMap(), and update it when the rogue is moved. pX and pY is the current position of the rogue. WIDTH and HEIGHT are macros specifying the dimensions of the map.

The paintEvent() function is left out of this walkthrough. We also do not discuss other code that does not concern the state machine (the setupMap(), status(), setStatus(), movePlayer(), and sizeHint() functions). If you wish to take a look at the code, click on the link for the window.cpp file at the top of this page.

Window Class Implementation

Here is the constructor of Window:

     pX = 5;
     pY = 5;

The player starts off at position (5, 5). We then set up the map and statemachine. Let's proceed with the buildMachine() function:

 void Window::buildMachine()
     machine = new QStateMachine;

     QState *inputState = new QState(machine);
     inputState->assignProperty(this, "status", "Move the rogue with 2, 4, 6, and 8");

     MovementTransition *transition = new MovementTransition(this);

We enter inputState when the machine is started and from the quitState if the user wants to continue playing. We then set the status to a helpful reminder of how to play the game.

First, the Movement transition is added to the input state. This will enable the rogue to be moved with the keypad. Notice that we don't set a target state for the movement transition. This will cause the transition to be triggered (and the onTransition() function to be invoked), but the machine will not leave the inputState. If we had set inputState as the target state, we would first have left and then entered the inputState again.

     QState *quitState = new QState(machine);
     quitState->assignProperty(this, "status", "Really quit(y/n)?");

     QKeyEventTransition *yesTransition = new
         QKeyEventTransition(this, QEvent::KeyPress, Qt::Key_Y);
     yesTransition->setTargetState(new QFinalState(machine));

     QKeyEventTransition *noTransition =
         new QKeyEventTransition(this, QEvent::KeyPress, Qt::Key_N);

When we enter quitState, we update the status bar of the window.

QKeyEventTransition is a utility class that removes the hassle of implementing transitions for QKeyEvents. We simply need to specify the key on which the transition should trigger and the target state of the transition.

     QKeyEventTransition *quitTransition =
         new QKeyEventTransition(this, QEvent::KeyPress, Qt::Key_Q);

The transition from inputState allows triggering the quit state when the player types q.


     connect(machine, SIGNAL(finished()), qApp, SLOT(quit()));


The machine is set up, so it's time to start it.

The MovementTransition Class

MovementTransition is triggered when the player request the rogue to be moved (by typing 2, 4, 6, or 8) when the machine is in the inputState.

 class MovementTransition : public QEventTransition

     MovementTransition(Window *window) :
         QEventTransition(window, QEvent::KeyPress) {
         this->window = window;

In the constructor, we tell QEventTransition to only send KeyPress events to the eventTest() function:

     bool eventTest(QEvent *event) {
         if (event->type() == QEvent::StateMachineWrapped &&
             static_cast<QStateMachine::WrappedEvent *>(event)->event()->type() == QEvent::KeyPress) {
             QEvent *wrappedEvent = static_cast<QStateMachine::WrappedEvent *>(event)->event();

             QKeyEvent *keyEvent = static_cast<QKeyEvent *>(wrappedEvent);
             int key = keyEvent->key();

             return key == Qt::Key_2 || key == Qt::Key_8 || key == Qt::Key_6 ||
                    key == Qt::Key_4;
         return false;

The KeyPress events come wrapped in QStateMachine::WrappedEvents. event must be confirmed to be a wrapped event because Qt uses other events internally. After that, it is simply a matter of checking which key has been pressed.

Let's move on to the onTransition() function:

     void onTransition(QEvent *event) {
         QKeyEvent *keyEvent = static_cast<QKeyEvent *>(
             static_cast<QStateMachine::WrappedEvent *>(event)->event());

         int key = keyEvent->key();
         switch (key) {
             case Qt::Key_4:
             case Qt::Key_8:
             case Qt::Key_6:
             case Qt::Key_2:

When onTransition() is invoked, we know that we have a KeyPress event with 2, 4, 6, or 8, and can ask Window to move the player.

The Roguelike Tradition

You might have been wondering why the game features a rogue. Well, these kinds of text based dungeon exploration games date back to a game called, yes, "Rogue". Although outflanked by the technology of modern 3D computer games, roguelikes have a solid community of hard-core, devoted followers.

Playing these games can be surprisingly addictive (despite the lack of graphics). Angband, the perhaps most well-known rougelike, is found here:


Best Of

Actualités les plus lues

  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 94
  2. Apercevoir la troisième dimension ou l'utilisation multithreadée d'OpenGL dans Qt, un article des Qt Quarterly traduit par Guillaume Belz 0
  3. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  4. Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programmes ? Manquent-ils de pouvoir de négociation ? 42
  5. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  6. Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt 17
  7. 2017 : un quinquennat pour une nouvelle version du C++ ? Possible, selon Herb Sutter 8
Page suivante

Le Qt Labs au hasard


Utiliser OpenCL avec Qt

Les Qt Labs sont les laboratoires des développeurs de Qt, où ils peuvent partager des impressions sur le framework, son utilisation, ce que pourrait être son futur. Lire l'article.



Liens utiles


  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt 4.7
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !

Hébergement Web