2
\$\begingroup\$

I can't understand what design pattern I can take advantage to build an intro screen, help screen, level select screen, game screen, game over screen, altogether.

I can make one in AS3, but the code becomes hugely messy.

That's what I sort of do. I would create a different class for each one but all classes don't share nothing in common, I just separate the classes to short the code in each file. The only parameter I pass on is stage as reference for all of them so that I can place the sprites and assets on the screen. I instantiate the game itself in a separated file and when the player reset the level that class would be re-instantiate or overwrite again. I run garbage collector in each class because there are some events I can't use reference.

Only I understand what I do, but as you can see it's certainly the wrong way since it has became messy and hard to maintain. I learned by trial and error because I couldn't find examples showing how to code with OOP these layers or states(play, select, send score, play again and so on) of the game.

\$\endgroup\$
5
\$\begingroup\$

Here's what I normally do with my states. It might not be the best way, or even the second best (but remember, the thing that matters is not the architecture of your game code, but the actual end result.). I start with a basic State-class (all code in Pseudo-C++):

class State
{
    virtual void Event(Event e);
    virtual void Update(float deltaTime);
    virtual void Render(Renderer renderer); // It's not a good practice to let things render themselves, but that's another thing.
};

Then I store the states in somewhere. This might be your game-class, a state manager or something else. I like to use "stacks" for my states, to allow easy transitions to the previous state. So maybe something like this:

class StateManager
{
    State GetCurrentState();
    void PushState(State state);
    State PopState();
};

Then, code your states (something like this):

class IntroState : public State
{
    StateManager Manager;

    IntroState(StateManager manager)
    {
        Manager = manager;
    }

    void Event(Event e)
    {
        if (e.key == START_KEY)
        {
            // Move to the next state.
            Manager.PushState(MainMenuState(Manager));
        }
    }

    void Update(float deltaTime);
    void Render(Renderer renderer);
};

Finally in your game loop you would perform something like this:

while (Run)
{
    for (Event e : GetEvents())
    {
        Manager.GetCurrentState().Event(e);
    }

    Manager.GetCurrentState().Update(deltaTime);
    Manager.GetCurrentState().Render(renderer);
}

The pattern is called The State Pattern (Duh?). Your states might need some reference to the manager, and that can be implemented like I did above, or with the usage of the evil singleton or maybe like a service class. The state pattern sometimes might be used with just a simple enum and a switch statement, but it's much easier to maintain classes instead of messy switch and if statements.

\$\endgroup\$
  • \$\begingroup\$ I don't really know the limitations of ActionScript3, but I'm in a belief that it supports the basic OOP principles. AS3 is basically Adobe's copycat Java (very much like C# in that sense.) Just don't get ActionScript 3 confused with ActionScript 2... \$\endgroup\$ – jhocking Aug 15 '14 at 11:52
  • 1
    \$\begingroup\$ I'd proxy the Update() and Render() calls through the StateManager (so it's Manager.Update(deltaTime); Manager.Render(renderer); and that calls the corresponding methods on the current state if there is any (!), but otherwise that's work just fine. \$\endgroup\$ – Martin Sojka Sep 14 '15 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.