How to make an application architecture a global strategy game?

Question

I am doing a global libgdx strategy, how can I properly design the architecture? So far, I'm in some kind of chaos, because there are different events that need to be shown to the player in the form of widgets.

For example, one problem is that I need to understand how the Province class will display a message that there is a hunger problem. Should it:

• immediately inside itself display a message?
• send event data to the main class of the game, which processes the data and, depending on the event, display the message or take some other action?
• do something else entirely?

I had the idea to make a separate class of events and so that all game objects create this object and pass it to the main class of the game, which handles them and decides what to do with it, and if necessary, pass it to the players.

And I read about the fact that there is a class java.util.EventObject. Is it worth implementing it with the help of it, or should it be implemented like that yourself? Or maybe it should be done in a completely different way?

The game is turn-based. There are separate provinces and the units move from one province to the neighboring one in 1 turn.

At the beginning of each turn, a series of windows appear in turn, notifying of certain events, for example, famine in a province or enemy troops attacked a province, etc.

There are classes of the province, the player, various UI - windows, which display information about events.

Answer 1

There are many ways to get to this, and you might need several iterations over the architecture before getting it right. Because of this, this answer will be quite broad.

You could consider your game from three different points of view:

• the simulation, i.e. what happens in the game
• the 3d render of the game, i.e. the display of how is your world organized
• the UI, i.e. the actual information about what happens in the game

As such, you might want to split those three aspects of the game, and create precise communication channels between those. Let a single entry point handle the events and treat them all once per frame. This way, your UI is homogeneous (e.g. you don't want Province A concern itself to decide if it should display a non-important UI element over Province B's important UI element; you don't want to have two UI pop-ups over each other requesting user input, etc..). This way you can separate the concerns and reduce the WTFs and spaghetti code.

Using events to communicate between those layers is a good idea. The exact way you'll do this is up to you, whatever works the best for your style and your game.

So in your specific case, during the simulation step, the Province "decides" it has "hunger", then raises an event and queues it for the UI to ask it to display it to the player, and queues it to the 3d rendering to ask it to display a specific icon, or change the texture over the province. Then the UI can decide to not display the hunger message yet because an invasion has just happened the frame before and the Player is still being notified about it.