Handling of game state changes (game over, etc)

[Szenia Zadvornykh]

Hello.

I recently finished my first project using Ash, where I ended up injecting a single callback from my root class (where the systems are created) into my main system (GameManager). When the game time reaches zero, this callback is executed, stopping the game update loop and showing a score screen.

This is very hack-ish, and I am looking for a more robust solution. Can anyone here share some thoughts on how to properly handle game state changes using an entity component framework like Ash?

On a related note, should I try to integrate menu screens (level select, pause, etc) into the entity component architecture, or keep such UI logic clearly separated?

[Abiyasa]

I use event to notify game over. The root class (where systems are created) will dispatch game over event and the GameManager (or in my case, the play screen) will listen to it. When the event is triggered, the GameManager will stops game update loop and display different screen.

I'm not sure this is the best way to do it but I like it since the root class doesn't have to care which manager/screen will process the event.

See the code at: 

https://github.com/abiyasa/Ash/blob/master/examples/no-dependencies/asteroids/net/richardlord/asteroids/Asteroids.as

https://github.com/abiyasa/Ash/blob/master/examples/no-dependencies/asteroids/net/richardlord/asteroids/screens/PlayScreen.as

[Neil Manuell]

The way I have dealt with this, subverting ash for a non game application is to create self removing systems, plus a system that monitors the number of systems currently in the game.

 I use signals for communications.

[Richard]

I favour the idea of an event bus or signal bus that is shared between your game and any external systems that may need it. So, for example, a system could dispatch a game over event or signal and some object outside of the game can receive it and respond accordingly. Equally an object outside the game can communicate into the game via this event bus. You can use this for UI too, allowing you to use existing MVC frameworks for the UI and communicating with the game via the event bus.

[Neil Manuell]

Mmm yes this is how I arrange my signals. Don't really like the self removing systems, but for the simple config I have at mo it works well.

On Dec 15, 2012 5:32 PM, "Richard" <ric...@richardlord.net> wrote:

I favour the idea of an event bus or signal bus that is shared between your game and any external systems that may need it. So, for example, a system could dispatch a game over event or signal and some object outside of the game can receive it and respond accordingly. Equally an object outside the game can communicate into the game via this event bus. You can use this for UI too, allowing you to use existing MVC frameworks for the UI and communicating with the game via the event bus.

--
You received this message because you are subscribed to the Google Groups "Ash Framework" group.
Visit this group at http://groups.google.com/group/ash-framework?hl=en.

[vladislav oleynick]

I use entities (or entities in some state) as events. The systems just listen to nodeAdded signal from nodeList. Sometimes I create temporary entities for this and remove them after handling.