Resources on structuring games

There are some articles here on Gamedev that show program design. I think that they are in the software engineering section.

[Edit]
Here is a link to the section I was speaking of: http://www.gamedev.net/reference/list.asp?categoryid=66#237

[Edited by - KodeNerd on October 14, 2008 9:44:05 PM]

I feel your pain gameXcore.

I registered here specifically to bump this thread in the hopes that there is in fact a decent resource out there somewhere that can help.

It seems this problem becomes even more pronounced when you think about coding something MMP. I've read tons of articles here and elsewhere on the various subsystems that a game requires and why they need to be there, but it seems like no one has a good general overview of the communication between subsystems. I understand blitters, rendering, network communication, binary file I/O, etc, but these things alone do not make a game.

I'd like to have a gut-level understanding of a general game system. How it's engineered and what the developer had in mind when making the choices they did. Trying to fit everything together makes my head spin.

To put more vividly...

Each subsystem of a game(sound, AI, graphics, physics, etc) is like a puzzle piece , and I'm holding a bucket full of them. What does the puzzle look like when completed?

Aoi

Depends. Do you want a procedural design based on global subsystems that interact with each other? A functional design where non-mutable state propagates across function calls? An object-oriented design where objects are manipulate without knowledge of their implementation?

I personally would prefer a procedural design as that seems to be less obfuscated by the nature of the code. It seems it would be easier to get a firm grasp of whats happening, when and why.

Though truthfully I would be happy with some reading material on subsystem interaction regardless of it's method of implementation.

Quote:

Original post by WickedAoi I personally would prefer a procedural design as that seems to be less obfuscated by the nature of the code. It seems it would be easier to get a firm grasp of whats happening, when and why.

Yes. Procedural design increases the readability and maintenability of global interaction, at the cost of extensibility and code reuse.

The core idea is that your subsystems should have a cleanly defined public interface that other parts of your code can use to interact with that subsystem. The public interface should explain what the global state of the subsystem is, and how every function call depends on that global state or modifies it.

Once this interface is done, you can have a subsystem call the methods of another subsystem (GET) or provide the other subsystem at initialization time with callbacks (PUSH) which will be called when certain events happen. Avoid circular references at all costs, otherwise you will have initialization and dependency issues.

Quote:

Though truthfully I would be happy with some reading material on subsystem interaction regardless of it's method of implementation.

It could be summed up as "Subsystems interact." since how subsystems interact is the method of implementation.