[Discussion] Game Structure

[Plazmotech]

Basically - I'm looking for the best game structure. Here's the idea that I have

IDEA

Class - GUI - Can be customised to contain buttons and to do specific things. This can simply have an event handler function that returns the index of which button was pressed.

Class - Game Section(s) [Must be inherited] - This should be used theoretically for each part of the game that has a different menu. For example one for title screen, for normal exploring, one for the shop, etc. Each would contain maybe a few GUI's and and all the functions specific to that section. Sections may contain other sections (for example a main exploring section might contain a shop section. If the presence of a shop is detected a section.isOn variable switches on, hereby forwarding the game to the section event handlers.)

Class - Main game engine - Contains main loop and game sections. Has variables saying which game section is currently playing – This is essentially a master game section (it might even inherit a game section if you wanted to) Every loop the engine gets the currently played section, and asks for items that must be rendered (in reality, this should only be one surface) to stick onto the renderer. These sections might in turn ask their sections for render queue]

Class - Renderer - Contains a screen surface and a render function and a clear screen function. The render function takes one surface and adds it to the current screen. A clear screen function would effectively clear the screen (however, this should not nessisarily be done - as clear screen should be done manually by adding background images and throwing it into the render function).

Class - Save - Contains all information needed in the current section. When each section exits it should return its data and add it to the parent section. (This could theoretically create "save" buttons on customization benches or whatever - while providing simple access to saved material in a flexible, decentralized manner)

NOTES

However - This would not be my preffered configuration - as I prefer a more centralized approach. However, efficiency and flexability must be put into mind. Thoughts?

Use a gaming framework.

[mike_2000_17]

My thoughts are that this framework you are describing is probably not going to take you very far, you will quickly hit a wall (or a number of walls). For one, it is obviously much too simplistic, as a typical game engine / framework would contain quite a lot more stuff. Also, you are not considering some of the most important aspects of a game engine, such as resource management (manage all the "content" like models, textures, sounds, etc..), physical realism (getting the "physics" to look naturally), and managing the rendering pipeline, just to name a few.

In the most basic setups, a typical game framework would have five main parts: Renderer, Physics Engine, Game Logic (often as a script interpreter), Resource Management, and GUI. Each of these are usually implemented separately, and should be, because they don't really interact all that much. The important thing is, each of these parts are mammoths, i.e., they are a complete and complex programming task by themselves. And also note that most of these parts can be found on the internet either as separate things and/or combined in one "game engine". You should seriously evaluate your options in that department because doing all those things from scratch is going to be monumental.

Class - GUI - Can be customised to contain buttons and to do specific things. This can simply have an event handler function that returns the index of which button was pressed.

That sounds horrible, sorry. You should explore existing GUI frameworks (WinForms, MFC, VCL, WxWidgets, and Qt) and understand how they generally work (they all work in similar ways). You might even want to just use one of those GUI frameworks instead of making your own (I recommend Qt). A solution like "event handler function that returns the index of which button was pressed" is really far from being a practical solution, see how they solve that problem in most GUI frameworks (with polymorphic event-handlers, and things like signals/slots patterns).

Class - Game Section(s) [Must be inherited] - This should be used theoretically for each part of the game that has a different menu. For example one for title screen, for normal exploring, one for the shop, etc.

Sounds to me like a finite state machine (FSM). That's actually a good idea in my opinion. I have used state machines before for this kind of purpose and it works well. I would suggest that they be hierarchical, i.e., one "section" (or state) could have multiple sections within it, and so on. This will be useful.

Class - Main game engine - Contains main loop and game sections.

I see no purpose for this, this is just one of the main "sections". When you write a state machine, there is a choice to make between having them invoked in a loop or having them executed. In other words, either you have some external while-loop that calls "update" on the state machine to execute one iteration, or you just call "execute" on the state machine and each state is responsible for running its own while-loop, if it needs to. The latter is the traditional view of state machines, but for game frameworks, I tend to favor the former, and in that respect, you might need a "master" class that runs that loop, but it should not include any "game logic", that should all be in the "sections" (or states).

Class - Renderer - Contains a screen surface and a render function and a clear screen function.

Well, that sounds really really overly simplistic. A renderer, especially a 3D renderer, is quite a massive beast. And you would not have a separate "clear screen" function, that's just not the way it works. The screen is cleared about 60 times per second, and new stuff is drawn on it. Writing a good 3D renderer is a huge endeavour.

Class - Save - Contains all information needed in the current section. When each section exits it should return its data and add it to the parent section.

You are sort of touching on the problem of resource management. First thing's first, you need to have a reliable way to save and load everything you need. Generally, we call that a serialization library, there are many of those available and it is not too hard to make your own.

As for passing on data between sections and things like that, this is really an issue of, what I call, resource brokerage. Different parts of your game might need different resources (models, images, sound effects, etc.) which need to be loaded when entering a new "stage" and released when leaving it. The problem is, the same image might be needed repeatidly, or you might not want to release it because the next "stage" will need it too, and so on. What you need to solve this is to have a kind of global entity ("broker") that can deliver resources on demand and release them, and handle the loading and unloading of those resources depending on their use, independently of current "sections". So, it sort of acts as a one-stop-shop for all resources and ensures that there is no redundant loading / saving. This is what is typically called a resource manager, and is one of those crucial parts of any game engine.

However - This would not be my preffered configuration - as I prefer a more centralized approach.

Why do you prefer centralized approaches? They're the worst thing, IMO. The key to good software design is small and clear contracts, and independence. You want every part to have a small, clear and self-contained contract (or "purpose") which has as little to do with any other part of the software as possible.

For example, take the resource manager. Its job is to take a file-name and deliver the corresponding object, and ensure it is alive for as long as the same caller does not "release" it. That's a small and clear contract to be fulfilled, and in order to fulfill that contract, the resource manager has no reason whatsoever to be even aware that it is part of a game engine (or whatever else). It can be implemented as a completely independent entity. And that's awesome from a software engineering point of view, because it means you can use it anywhere and without any trouble. You should want every part of your software to be like that. Any time you introduce a dependency between two classes, ask yourself if you really need it, and if you can't separate them somehow.