17.3 Scene Implementation

17.3 Scene Implementation

The previous sections demonstrated how a computer game is composed of scenes, and a scene is a collection of objects in the same coordinate space. The objects will often have relationships to one another, and this influences how objects move and are positioned. To manage these relationships and behaviors, a scene manager should be created. However, in a 2D game, there are further issues to consider in a scene manager in addition to simply position and orientation. We will address all these issues and more as we now turn our attention to actually creating a scene manager. This class will be called CL_SceneManager. In the course of designing this class, a number of others will also need to be designed to work collaboratively with the scene manager.

Note 

At the time of publication, there is no class that is part of ClanLib called CL_SceneManager. This chapter focuses on actually creating such a class to use in whatever projects may require it.

So, we begin with a blank class declaration as shown below. This will be added to as the chapter progresses.

      Class CL_SceneManager : public CL_Sprite      {         private:         protected:         public:      }; 

17.3.1 Scene Manager-Core Properties

The scene manager to be created has the following core properties:

• The scene manager class will contain and manage a whole collection of different scene objects, and it will be responsible for drawing them to the display, for ensuring their relationships are maintained, and for creating and deleting the objects where appropriate.

• The scene manager will be a 2D scene manager, meaning the objects and scenes to be presented on the display will be in 2D. The coordinate space therefore will have two dimensions, an x-axis and a y-axis, and ClanLib can represent 2D positions using the CL_Vector2 class. This means each object in the scene will have a position expressed as a 2D coordinate in the form of (x, y).

• Conceptually, the scene manager will consider itself as one large surface upon which the scene is drawn. It will do this by inheriting from the CL_Surface class. This means, as the scene manager surface is drawn it will composite all the scene objects it contains and draw them upon its own surface. Later sections in this chapter demonstrate how one surface or sprite can be drawn onto another surface. By representing the whole of the scene on one surface, the programmer can then subsequently manipulate and control the drawn scene like any other surface by scaling, positioning, rotating, and so on.

• The scene manager will be able to load and save scene files from XML. In other words, an XML file defining all the scene objects and their properties and relationships can be loaded into a scene manager. This data can also be saved.

17.3.2 Scene Manager-Scene Objects

A scene manager was defined in the previous section as being a collection of scene objects; thus, the first objects to create for the scene manager class are scene objects. As mentioned, scene objects are the actual items that are part of the scene coordinate space. In the visual sense, scene objects are all the game objects such as spaceships, fairies, goblins, and so on. Anything that has a position in the scene coordinate space is considered a scene object. Each object has an (x, y) position and a visible property that determines whether or not the object is currently visible in the game world. If visible, then the item will be drawn when the scene is painted; otherwise, drawing is omitted. The (x, y) position of the scene object is a relative measurement, not from the top-left corner of the screen necessarily, but possibly from other objects. Finally, in addition to the position and visible properties, a scene object will also have a name property-a user-defined name to uniquely identify it from other scene objects. So, a scene object class can be created that includes the three properties: name, position, and visible. Furthermore, since each scene object will be shown on screen (as a sprite or surface), the scene object class can be derived from CL_Sprite. Therefore, the scene object can be transformed in the same way any sprite class can. The class declaration for CL_SceneObject can be seen below.

      class CL_SceneObject : public CL_Sprite      {      private:         CL_Vector2 m_Position;         bool m_bVisible;         std::string m_Name;         void *m_Data; //Custom Associated Data      protected:      public:         CL_SceneObject(const std::string& resource_id, CL_ResourceManager* manager,                        float x = 0, float y = 0, bool visible = true);         CL_Vector2* getPosition() {return &m_Position;}         float getX() {return m_Position.x;}         float getY() {return m_Position.y;}         void setPosition(CL_Vector2 Position) {m_Position = Position;}         void setPosition(float x, float y) {m_Position.x = x, m_Position.y = y;}         bool getVisible() {return m_bVisible;}         void setVisible(bool Visible) {m_bVisible = Visible;}         std::string getName() {return m_Name;}         void* getData() {return m_Data;}         void setData(void* Data) {m_Data = Data;}      }; 

17.3.3 Scene Manager-Object Relationships

As discussed earlier, scene objects exist inside the same coordinate space. Specifically, each scene object has its own position anywhere within the coordinate system, a visible property, and a unique name.

Beyond this, however, scene objects must also have relationships with one another. Previously, an example of a boy with his lantern riding on a magic carpet was used. Each of those items-boy, lantern, and carpet-has its own position, but both the boy and lantern are expected to move along with the carpet. As the position of the carpet changes, so does the position of the other objects. There is, then, a dependency. The boy and lantern are linked and dependent upon the carpet; the carpet, however, is not dependent on the boy or the lantern. This dependency is known as a one-way relationship.

Figure 17.1

Another problem in 2D games is the subject of z-ordering. If a game includes three goblins, a background, and some foreground objects like trees, wreckage, and buildings, then there is the issue of which items should be drawn to the display first because objects closer to the camera appear in front of objects farther away. The answer is to order the objects the same as you would if painting a picture. The background objects should be drawn first, and then the next set of objects in front of those, and then the next set, and so on. In short, the farther something is from the camera, the higher its z-order should be. Thus, lower z-orders represent objects nearer to the camera, and higher z-orders refer to objects farther away. If an object is a moving object, then it has the potential to change its z-order as it moves in front of or behind other objects in the scene.

In light of these two problems there are numerous solutions for modeling relationships between scene objects and for ensuring their z-order is maintained. One of the most ideal methods for ordering objects in 2D games is the layer system, or painter's algorithm. Readers familiar with photo applications such as Adobe Photoshop or GIMP will probably already understand the layer system. This is discussed in the next section.