Say, for example, that in my game I have a splash screen, a title screen, an options screen, then there's the actual game mode and in-game menus that pause the game mode. What's the best way to handle the communication between these, and possibly other, different game states?.

Currently, I'm using ALLEGRO_USER_EVENT to emit custom events into the game's event queue, so I do something like:

ALLEGRO_EVENT event;
event.type = OPEN_TITLE_SCREEN;
...
al_emit_user_event(&user_event_source, &event, NULL);

And then every object in the game contains a section in their logic to respond to each possible event. This approach works but I feel like there might be better ways to do it.

Any ideas?

Thanks.

The approach I prefer (if I have my codebase setup correctly in that project) is to have a global pointer that points to the current_screen. A "screen" is a type of object that is fed allegro events like mouse movements, keyboard inputs and the like, and dispatches them to do certain sub-objects and manages that coordination internally.

When a new screen is created (title screen goes to gameplay screen), that pointer is deleted, a new different screen object is created, and assigned to the pointer. All the dependencies are injected into the newly created screen.

Here's an example of how it gets switched out:

https://github.com/MarkOates/DragonWrath/blob/master/src/DragonWrath/ScreenManager.cpp#L135-L199

(note that index_of_level_to_start should be named something different, enum_val_of_screen_to_start or something like that.)

Overall, what I've really found is how you do it really depends on the complexity of game, the programmers on you team, the standards of your codebase, blah blah. Each codebase has different priorities, so I think you should be flexible with how you approach it and use that to judge your architecture's goals.

Thanks for your replies, these are some interesting ideas; definitely could help in making the game state/screen/scene changes to be handled by a single object rather than my current method where every object in the game has to respond to these changes.

Thanks a lot, will surely be useful.

Interesting. So all of your states are created in memory at the beginning of the game? Have you run into any complicated scenarios with this approach (timers, sound/music, etc?)

One mistake people often make:

There's nothing wrong with pre-allocating the max memory instead of using dynamic allocations.

"But it's a waste"

... and?

If someone's computer can't run the game with an array of MAX_OBJECTS, congrats, it was going to crash when they hit MAX_OBJECTS anyway. And with memory fragmentation, dynamic allocations are going to take more space for the same maximum. Unless you're making a game like Factorio which can have literally millions of objects and increases CPU requirements the more you do, there's no need. Paper Mario knows exactly how many enemies can be on the screen at a time by design.

Nowadays you can get away with allocating every frame. It's just wasteful if you're using POD (plain-old-data) objects because you're invoking the entire operating system for checking page permissions. It's like storing all your files in a folder, verses in a single archive. The reason files in a folder is so insanely slow (see Factorio, KSP, other games with modding) is because it's invoking the entire operating system permissions checks for every single access. Reading 20,000 files is 20,000 permissions checks. Reading 1 archive with 20,000 files, is 1 check.

If using new and delete makes it easier to conceptualize your program and get it out the door, by all means do it. Just keep in mind that it "could" become a bottleneck.

Tons of people were/are worried that because D uses a garbage collector, the GC may cause stuttering or slowdowns. I was afraid too, and then I got wise and actually bothered to test it--in the worst case. I used the garbage collector to allocate every. single. particle. for a particle engine (bullets, explosions and smoke) for a 2d plane game. I still held 60 FPS on my humble netbook. Now I still prefer static arrays where possible, but it's good to know the GC isn't really the bottleneck people are afraid of.

On the otherhand, there's other benefits to static allocation. You can nuke the entire thing with a single memset because it's contiguous. So you can have a block for menu related data, a block for round data, and a block for credits. And when you switch rounds, you delete the main one with a single memset (instead of remembering every single possible object and subobject). You can also have two "game" datasets and switch between them ala page flipping, to do level transitions where the first one is still running while the second one fades in. (*watch out for dangling pointers!!!)

Also, if you have dead objects and live objects sharing an array (because it's a static buffer), you could theoretically have a helper thread that runs along every frame, scans a few dozen objects, and sorts them into two buckets of dead vs alive. (ala alive come first in the array then dead.) Even if they're not completely organized, the reduced "switching" of if(alive) means the CPU cache is going to go from "always take this branch" to "never take this branch" instead of flipping back and forth.

Chris Katko, that actually makes a lot of sense. Thanks, will keep that in mind.

Currently, I use dynamic allocation in my project but, hopefully, it is structured enough to allow for adapting it with little effort to use static allocation instead.

[EDIT:] On topic, I'm implementing a basic scene manager. Right now, I've decided that every object in the game communicates with the scene manager only by setting some flags in the current scene. If an action is to be performed, the scene manager is the one in charge of the action and it can manipulate all the objects in the current scene, this minimizes the need for every object to know about other objects in the scene as I was doing it before.

This seems to work fine and every object only needs to set the current scene with an ACTION_REQUIRED flag and set a pointer to the object that originated the action. There are two ways to set this flag, either to manipulate the current scene directly or to generate an ALLEGRO_EVENT to be consumed by the scene manager. Both have effectively the same effect so I guess it's just a matter of what method I like more?.