Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I would like to create a simple game fire and shoot game using Component Entity System (CES). This game has two game modes(1): play mode and settings mode. The play mode is the actual game itself whereas the setting mode is where the player updates his sprite's settings, like type of weapon, inventories, etc.

Now, how does one implement game modes in CES? How would one switch to different game modes?

(1) The game mode i refer is something like the one implemented in Final Fantasy I, where it has four game modes (http://en.wikipedia.org/wiki/Final_Fantasy_(video_game)#Gameplay)

share|improve this question
1  
Create container for your entities, lets call it World. Now when you are playing a game with entities from your World world1 and want to swich, just create new World world2 create whatever new entities you want (probably based on existing entities from world1) and thats it. This would be useful for something that has totally different rules (like walking on map vs battle in FF games) for something like menu or inventory, i would go with user interface. –  Kikaimaru Feb 4 '13 at 12:05
    
@Kikaimaru, well the containers representing different worlds, and I assume the same goes with battle mode, is perfect. However, for the setting mode, how does the use of UI fits into CES? How do they relate? –  OnesimusUnbound Feb 4 '13 at 12:17
    
I dont know what you mean by settings mode. In my game I have UI on top of component system, GameWindow creates world1 and fills it with stuff like player entity and camera entity - then something takes camera entity, and fills one of its variable with what camera sees (its RenderTarget in directx or Canvas in javascript), then gamewindow draws what camera sees as its background. Well and then there is InventoryWindow, that takes player entity from world1 and adds some buttons depending on what player entity has in its inventory component. –  Kikaimaru Feb 4 '13 at 12:27
    
For my case, when in play mode, I'm controlling my sprite. When I press a button, I open a setting window and pauses the game while to make changes. After I made the changes and revert to game mode, the game resumes. For your case I think the game progress while you can access the inventory window. –  OnesimusUnbound Feb 4 '13 at 12:37
1  
Yes, but "game progress" means only that something is calling methods on some specific Components/Systems - like on physics component, or that component that handles sprite movement for you. So you can just stop calling it when you have different window opened or different game mode active or whatever. –  Kikaimaru Feb 4 '13 at 12:39

1 Answer 1

up vote 3 down vote accepted

Not everything must be components. If its easier fit you to build your Settings mode more traditionally, do that. Make a fun game, not a "perfect" architecture.

If you do want to make all your UI elements as components, consider using Spaces. Spaces are containers of game objects and systems. They're a very useful concept. Put your actual game in one space, your Setttings mode in another, your Pause screen in yet another, MainMenu in one, etc. Your objects stay separated, you can clear or reset a single Space at a time, and selectively update/render only the active Soace.

You can even have more than one Space running at once. Say you want some background action but don't want it interacting in any way with the main action. Spaces make that easy.

Each Space gets its own instance of any relevant systems. Given two spaces that both have physics, for example, there are two PhysicsSystems, one for each Space, managing the physics bodies in their respective Space independent of the other. With a third party physics library, this likely means creating a physics World for each space.

This is also useful for UI, since each space can remember its "global" properties like active element independently. You can switch between menus without the player losing his place each time.

share|improve this answer
    
thanks for bring up the concept of Space. However, how would these spaces interact with one another? For example I'm in settings mode, which is one space, and I made changes with my avatar. Once I return to play mode, which is another space, my avatar should have all the changes applied in the settings mode. –  OnesimusUnbound Feb 5 '13 at 3:13
    
They don't interact with each other. Kinda the point. SHared data goes somewhere else, eg a GameManager singleton or engine component. Not all data belongs in a game object component. Some is shared by multiple GOs in a space, some is shared by multiple parts of the game. Its fine to stuff said data where most convenient. –  Sean Middleditch Feb 5 '13 at 4:41
    
Ok, thanks for the answer. –  OnesimusUnbound Feb 5 '13 at 4:53
    
You can also implement the EventAggregator pattern to decouple your spaces, so when a graphics setting gets changed, an event gets pushed to the EventAggregator which is then broadcast to all listeners, which would include your graphics system. The graphics system can then update itself. –  Alex G Feb 7 '13 at 13:36
    
@AFG thanks for the suggestion, but I think it's applicable when dealing with many spaces to decouple them. –  OnesimusUnbound Feb 8 '13 at 10:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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