Hey everyone.. I''ve decided I want to get into game development and have some questions and the actual design of games. Design in this case referring to OOD concepts like classes and such.. I already know OO enough to write ''normal'' apps but are there special design considerations in games? Every book I''ve looked at that deals with OO such glosses over the issue in 2 pages and books about game dsign are only interested in things like gameplay, graphics, etc.. also is it good to use a MVC type architecture? (model-view-controller). is there a performance hit from using it? and what about using listeners ala java? I was thinking I could have a sound listener, display listener and so on so that when certain events occur the sound listener would be notified and cause the corresponding sound to be generated.. thanks n

A lot of people (here and elsewhere) scoff at OOD design, with games in particular...

But I have the same questions you do...

Most games are single threaded, and as such general do not employ listeners. You do setup up event notifications for things like audio playback completion, though.

The main loop runs balls-out and procedes through everything the game needs to do to process a given frame of animation. This includes all audio, AI, network transactions, input, physics, and rendering. Maybe a state machine or two to keep track of what we''re doing and what should be rendered.

In a single simple test that I did , using a seperate (MFC) thread from the main process to perform rendering caused about 4fps performance hit. (But the rendering no longer stalled when I clicked on a menu item )

...
There''s a book called ''Game Architecture and Design'', but it has received mixed reviews...

LaMothe suggest using multiple threads but generally ignores the OOD approach.

I just bought a book on Design Patterns, to learn more about OOD, but I do not know whether or not it considers the requirements of high performance applications like games.

Some tips that apply to game programming with C++:

1. Locking all classes/structs/unions into one "idea" of a "perfectly designed" object is ridiculous.

2. Inheritance, polymorphism, and encapsulation are good in some cases but don''t go overboard.

3. Use classes/structs/unions w/ inline functions to separate code into certain modules. For example, all math performed on points would go into the point class (located in point.h and point.cpp), and be inlined for performance reasons. Such an approach minimizes the chance for stupid-but-hard-to-find mistakes without significantly reducing performance.

4. Use public/protected/private to protect your data and control which other code can access it (which again makes it easier to track down bugs)

5. Use operator overloading sparingly, and make sure you know the performance benefits/losses or you may cripple your engine''s performance. Esp. for small classes like point, vector, rectangle, etc.

6. ALWAYS make clear goals BEFORE you write code to perform a task. Write down the requirements of the code you are about to write. If a design doesn''t meet those requirements, scrap it. WIT - Whatever It Takes.

7. Find, buy, or steal a good reference on C++. (Well, okay don''t steal, but a reference is important.)

8. Make good use of STL, but be wary that your own coding mistakes/ignorance will cause errors. On general principle, only use what you already know unless you are coding mainly for the purpose of learning. When you use other people''s code, you want to know at least _basically_ how it works under the hood. Before you use STL''s list class, you should know how a linked list works. This is because you will have several options available (vector vs. list, list vs. map, list vs. deque vs. vector, etc.) and you need to choose the right one for your coding task.


There are also excellent references in the Articles section on how to write fast code in C++ and how to prevent/eliminate bugs. The article on commenting is a must-read.

Start simple, work hard, and learn. Good Luck!


- null_pointer
Sabre Multimedia