27 replies to this topic

[Jabzor]

Usually, I'll have something like: title_state, menu, level1, level2, pause_menu, for example. But if each component is updating every loop (via the component managers) then surely having a state class with event/update/render functions (which mine have always had) wouldn't be needed since the component managers are being called every loop independently? The only role I can see for my game states now is just to load/remove any game entities relevant for that state. I guess it'll just take a bit of tweaking.

[jischneider]

Then surely having a state class with event/update/render functions (which mine have always had) wouldn't be needed.

Yes and no. Yes, because the game objects are renderered and updated by thyself. However, you should need to update your logic somewhere. One possibility is to associate scripts components to game objects. The scripts have custom update functions (the only component with an update method that is called by the script manager) and know the entity (the entity could be an empty entity with just the script). Another alternative is to manage the logic partial or totally in a higher level.
It’s up to you. But yes, the components are managed only by their manager, you only modified their data.

[crancran]

Usually, I'll have something like: title_state, menu, level1, level2, pause_menu, for example. But if each component is updating every loop (via the component managers) then surely having a state class with event/update/render functions (which mine have always had) wouldn't be needed since the component managers are being called every loop independently? The only role I can see for my game states now is just to load/remove any game entities relevant for that state. I guess it'll just take a bit of tweaking.

Your game states should also respond to the event system as well.

For example, you may want your Level state to shift to the Game Menu state after the player hits the ESCAPE button. Depending on the current state (avatar has a target or has no target) would drive whether you progress to the new state or not but the Level State would need to subscribe to the E_STATE_CHANGE event that gets triggered if a state change was needed.

Steps:
1. Keyboard Component receives ESC
2. Keyboard Component checks if entity has Target
3. If Target, dispatch E_TARGET_BLUR event to deselect target then end.
4. If No Target, dispatch E_STATE_CHANGE event with state id "GameMenu" then end.

[jischneider]

A keyboard Component? IMO, the input should not be managed with components. The input in games is normally managed with states (like XNA), not events.

Events are double edged weapons, an event call could generate garbage (it can be avoided of course), events are slower than states, you could forget to eliminate a reference with disposing the listener and more important, the code execution order could be lost. But it’s true that they are very useful in several scenarios; I use them like a message system in my engine.

EDIT: I forget that I am in a C++ thread. Some disadvantages are more for C# than C++.

[crancran]

So in your design you'd have the Level State receive the ESCAPE keyboard input, query the target system using the current player as a parameter to determine if that entity had a target. If it did have a target, you'd clear the target for the next game loop update. If no target existed or if the player hit ESCAPE twice (first doing the former, second falling into this scenario), you'd then instruct the Level State to push the Game Menu state onto the state stack. Does that sound appropriate?

[jischneider]

I don't know if I understand you well and I am not an expert in game logic. That said...

So in your design you'd have the Level State receive the ESCAPE keyboard input

For me the level state has to ask to the input manager what is the keyboard state.

query the target system using the current player as a parameter to determine if that entity had a target

If it is not a game object or component (states are not one of them) then it is managed/updated in your game logic update time using the technique you want. For the contrary, if it is a component or game object then the corresponded manager will update it in a very specific time and place (data oriented design).

Does that sound appropriate?

I don’t know. I just wanted to share my keyboard component and event opinion. I didn’t say that all you said was wrong, maybe was all perfectly fine (except maybe the keyboard component part). And there is other important factor. If your game is small and works fine then continue doing what you doing.

[BeerNutts]

Check out my Dev Journal (linked in my sig), where I go though steps took to turn my previous game into a Component Based Entity System. It might give you some ideas as well.

[Jabzor]

Thanks for all the feedback. The way I've been handling input currently, (going on the 'escape to quit' example) is like this:

int Arc::run()
{
    while(m_stateID != STATE_EXIT)
    {
        changeState();

        sf::Event event;
        while(m_window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed || sf::Keyboard::isKeyPressed(sf::Keyboard::Escape))
                setNextState(STATE_EXIT);

            m_pState->VEvents(&event);
        }

        m_pState->VLogic();

        m_window.clear();
        m_pState->VRender(&m_window);

        m_window.display();
    }

    shutdown();
    return m_exitStatus;
}

As of yet I don't really have a 'input manager', more so I'm simply passing the 'sf::event' (that SFML2 provides) to each component that needs it. On a side note, SFML 2.0 RC just came out and I highly recommend it for 2D game development, if anyone is interested.