I read an article that said a game engine could be broken down into componets. Display Subsystem - for displaying everything Sound Subsystem - for sound Networking Subsystem - For network stuff Input Subsystem - For game input Update Subsystem - Keeps track of game events, Is this correct? If it is, what would the main features of the display subsystem/engine be in a 2D game (something like zelda on the nes). What should it do? And any ideas where I can find more information/details about the design of the renderinng subsystem/engine

Well it would do stuff such as drawing things in the correct order (back to front), deciding what to draw and what not to (stuff that are outside of the screen), handle animations, and more.

Ok, and would it use some sort of data structure to manage all the objects in the game, and use that information to draw on the screen, or would that be some other part of the system.

For example say I wanted to render the level of a small zelda like game on screen. Would all the information about the level, what tiles and enimies be stored in a data structure and then some sort of fucntion in the display system would iterate through the structure drawing it?

In the simplest of systems you'd usually break the game up like so:

Logic System
Video System
Sound System

I call it a "logic" system, because thats where the game is played out and the player inputs are taken into account. When you get into framerates and stuff, this would be called the "Fixed Logic Framerate." Now, I'm assuming SDL, the exact programming is fodder for another forum, but the design aspects can be discussed here.

Lets say you have a UI element for the player, we'll call it "Score". The way you'd handle score is there'd be two hooks on it. One in the logic, where its increased or decreased or reset, and then one in the video where its displayed. Sounds simple enough, now lets consider a menu screen with "Save" "Restart" and "Exit". First off, you'd need to know what state the game is in, Play, or Menu (just what I'd call them, under normal programming, GAMESTATE_CONTROLMENU maybe). So, during Play, we show the highscore and the on screen action, and during Menu, we show this menu, and the three options. In the Logic system, we're no longer updating the game action, we're just watching the inputs for Up, Down, and Enter, and changing things appropriately so the Video system can draw it.

Most of game programming works this way, translating playable states into blocks of code, managed by variables. Now that you know what Systems you have, try breaking the systems up into states, so that you don't have to invent this stuff all on the fly, you'll have a clear "Design Document" to work from.

siliconsurfer, don't get too attached to the naming of these subsystems. The divisions are purely conceptual and not only are there rarely clear divisions between subsystems, but there is absolutely no standard or consensus on what each part does. Different games will have very different rendering models and you will find more details in the programming forums and the various graphics articles.

Cheers for the response guys.

Yes it's becoming apparent that there aren't really very many standards, apart from within companies. So I guess as you've said I shouldn't get too attached to the naming of these subsystems.

Cheers