IPhone game development tutorial game engine (1)

IPhone gamesDevelopment tutorialGame EngineIs the content to be introduced in this article. First, let's take a look at the details. To solve the problemIPHONECreateGamesWe need to solve a series of small problems first, such as "how to display images" and "how to play sound. Issues related to CreationGame Engine. Just like the human body,Game EngineEach part is different, but it is indispensable. ThereforeGame EngineThis chapter begins with profiling. We will discussGame EngineAll main parts of the image, including the application framework, state machine, and imageEngine, PhysicalEngine, SoundEnginePlayer input andGamesLogic.

Writing a fun game involves a lot of code. It is very necessary to have a good, organized design for the project from the very beginning, rather than adding code everywhere as the progress progresses. Just like building a house, architects draw a blueprint for the whole House and construction workers build it. However, many programmers who are not familiar with game programming will build a part of the house based on the guidance and add room as they learn, which will undoubtedly lead to bad results.

Figure 2-1 functional structure of the Game Engine

Figure 2-1 shows a game engine structure suitable for most games. To understand how all parts of a game engine work together, we can first design the entire game and then create our applications. In the following sections, we will explain each part in Figure 2-1.

Application Framework

Game status Manager

Image Engine

Application Framework

The application framework contains the Code required to make the application work, including creating an application instance and other subsystems in the initial stage. When an application is running, it first creates a framework class and takes over the creation and destruction of state machines, image engines, and sound engines. If our game is so complex that it needs a physical engine, the framework will also manage it.

The framework must adapt to the uniqueness of the platform we choose, including any system events such as shutdown and sleep ), and manage the loading and loading of resources so that other code only needs to be centralized with the game.

Main cycle

The framework provides the main loop, which is the driving force behind all interactive programs. During each iteration of the loop, the program checks and processes the events it receives, runs updates in the game logic, and draws content on the screen as necessary. See Figure 2-2)

Figure 2-2 main cyclic Sequence

The implementation of the main loop depends on the system you use. For a basic console program, it may be a simple while loop that calls various functions:

 
 

  
  
while( !finished ) {     
  
  
    handle_events();     
  
  
    update();     
  
  
    render();     
  
  
    sleep(20);     
  
  
}    
 
 

Note the sleep function here. It allows the code to sleep for a short period of time without occupying all the CPU.

Some systems do not want to write user code at all. They use a callback system to force programmers to release their CPU normally. In this way, after the application is executed, the programmer registers some functions for the system to callback in each loop:

 
 

  
  
void main(void) {     
  
  
    OS_register_event_handler( myEventHandler );     
  
  
    OS_register_update_function( myUpdate );     
  
  
    OS_register_render_function( myRender );     
  
  
}  
 
 

Once the program is executed, the functions are called at intervals as needed. The IPHONE is the closest to the following example. You can see it in the next chapter and the iphone sdk.

Game status Manager

A good video game not only has a set of actions to maintain the game: it provides a main menu that allows players to set options and start a new game or continue the previous game; the Group screen displays the names of all the people who work hard to make the game. If your game has no user guide, A help area will prompt users about what they should do.

Any of the above is a game and represents a piece of independent application code snippet. For example, the function and navigation that a user calls on the main menu are completely different from those called on the Group screen, so the program logic is also different. In particular, you may put an image and some menus on the main menu, and wait for the option to be selected, you will describe the name of the game maker on the screen, and wait for the user to enter, change the game status from the production group screen to the main menu. Finally, the status in the game will render the actual game and wait for user input to interact with the game logic.

All the above game statuses are responsible for the tasks of entering the corresponding user, rendering the content to the screen, and providing the corresponding application logic for the game status. You may notice that these tasks come from the main loop discussed earlier, because they are the same task. However, each State implements these tasks in their own way, which is why they should be kept independent. You do not have to look for code in the main menu code to handle events in the game.

State Machine

Status manager is a state machine, which means it tracks the current game status. After the application is executed, the basic status information is created. It then creates information required for various states and destroys the information temporarily stored when it leaves each State.

The state machine maintains the state of a large number of different objects. An obvious status is the main menu of the user's screen status, medium game ). However, if you have an object with artificial intelligence on the screen, the state machine can also be used to manage its "Sleep", "attack", and "death" status.

What is the correct game status manager structure? Let's look at some state machines and decide which one is best for us.

There are many ways to implement the state machine. The most basic is a simple switch statement:

 
 

  
  
class StateManager {     
  
  
    void main_loop() {     
  
  
        switch(myState) {     
  
  
        case STATE_01:     
  
  
            state01_handle_event();     
  
  
            state01_update();     
  
  
            state01_render;     
  
  
            break;     
  
  
        case STATE_02:     
  
  
            state02_handle_event();     
  
  
            state02_update();     
  
  
            state02_render;     
  
  
            break;     
  
  
        case STATE_03:     
  
  
            state03_handle_event();     
  
  
            state03_update();     
  
  
            state03_render;     
  
  
            break;     
  
  
        }     
  
  
    }     
  
  
}; 
 
 

All you need to do when changing the state is to change the value of the myState variable and return it to the beginning of the loop. However, as you can see, when we add more and more States, the code block will become larger and larger. What's worse, in order to make the program run as expected, we need to execute the entire task block when the program enters or leaves a certain State to initialize specific variables in this state, load new resources) and release the resources loaded in the previous state. In this simple switch statement, we need to add more blocks and ensure that no one is missed.

The above are some simple repetitive work, but our status manager needs a better solution. The following is a better implementation method:

 
 

  
  
class StateManager {     
  
  
    //the function pointer:     
  
  
    void (*m_stateHandleEventFPTR) (void);     
  
  
    void (*m_stateUpdateFPTR)(void);     
  
  
    void (*m_stateRenderFPTR)(void);     
  
  
    void main_loop() {     
  
  
        stateHandleEventFPTR();     
  
  
        m_stateUpdateFPTR();     
  
  
        m_stateRenderFPTR();     
  
  
    }     
  
  
    void change_state(  void (*newHandleEventFPTR)(void),     
  
  
                    void (*newUpdateFPTR)(void),     
  
  
                    void (*newRenderFPTR)(void)     
  
  
    ) {     
  
  
        m_stateHandleEventFPTR = newHandleEventFPTR;     
  
  
        m_stateUpdateFPTR = newUpdateFPTR;     
  
  
        m_stateRenderFPTR = newRenderFPTR     
  
  
    }     
  
  
};    
 
 

Now, even if we process more states, the main loop is small enough and simple. However, this solution still does not help us solve the initialization and release status. Because each game status not only contains code but also its own resources, it is more appropriate to consider the game status as the attribute of the object. Therefore, we will look at the implementation of object-oriented OOP.

First, we create a class that represents the game status:

 
 

  
  
class GameState     
  
  
{     
  
  
    GameState();        //constructor     
  
  
    virtual ~GameState();    //destructor     
  
  
    virtual void Handle_Event();     
  
  
    virtual void Update();     
  
  
    virtual void Render();     
  
  
};  
 
 

Next, we change our status manager to use this class:

 
 

  
  
class StateManager {     
  
  
    GameState* m_state;     
  
  
    void main_loop() {     
  
  
        m_state->Handle_Event();     
  
  
        m_state->Update();     
  
  
        m_state->Render();     
  
  
    }     
  
  
    void change_state( GameState* newState ) {     
  
  
        delete m_state;     
  
  
        m_state = newState;     
  
  
    }     
  
  
};    
 
 

Finally, we create a class that specifies the specific game status:

 
 

  
  
class State_MainMenu : public GameState     
  
  
{     
  
  
    int m_currMenuOption;     
  
  
    State_MainMenu();     
  
  
    ~State_MainMenu();     
  
  
    void Handle_Event();     
  
  
    void Update();     
  
  
    void Render();     
  
  
};    
 
 

WhenGamesWhen the status is expressed as a classGamesState can store its unique variables in this class. This class can also load any resources in its constructor and release these resources in the destructor.

Moreover, this system maintains a good organizational structure for our code, because we needGamesThe status code is placed in each file. If you are looking for the main menu code, you only need to open the State_MainMenu class. In addition, the OOP solution makes code easier to reuse. This seems to be the most suitable for our needs, so we decided to use it as our status manager.

Summary:IPhone gamesDevelopment tutorialGame EngineI hope this article will help you. Want to learn moreGame EngineFor more information, see the following articles:

IPhone game development tutorial Game Engine 2)

IPhone game development tutorial Game Engine 3)

IPhone game development tutorial game engine 4)

IPhone game development tutorial game engine 5)

IPhone game development tutorial Game Engine 6)