Basic Design

The first step for building successful software is Design. A good design doesn't need to be the ultimate expression of the program, and it can always be redesigned in the future, but without an overarching structure it is difficult to know in which direction to start off.

For this project, I started with the basic loop structure every game has. This refers to the fact that in games, you initialize the game state (load resources, etc), then until the player closes the game you check for input, work on the input, and render to the screen. Then when the game is over you clean up and exit.

But that refers to the superstructure. The interesting stuff happens in between the lines. What I have been working on is the infrastructure that allows all that to happen.

After some thinking, I came to the conclusion that there are two main problems a game has to deal with. One is managing the game's resources; keeping track of entities, loading and removing models, textures, shaders, etc. The other issue is running the engines that use those resources to display the game, run collision detection, manage the game logic, etc.

Something like this:

From this initial design, some general needs become evident. We can't have all our resources jumbled up in a big pile. We need to organize them, and be able to provide them when required. Likewise, we must organize the different engines in some way as to be able to call each when it's their turn to act.

Additionally, there is another level we must consider, an Application Layer, that would be in charge of managing the interaction between the Game and the host machine. Fetching files and loading them in memory and the like. This could be a sort of resource, but we want to avoid giving any part of the program too broad a definition.

There is one further element of the program I haven't yet fit into my design, however, referring to the creation of resources. The backbone of my program is to eventually procedurally generate many of the resources. This wouldn't belong in any of the previous three layers, implying the need for another, a 'procedural layer' of some kind.

The Engine Layer should be completely decoupled from either the procedural or application layers, however the resources should be generated by either one of them. I'll have a look at each layer, as well as the communication between them, in the coming posts.