quote:
1. gather input from user and/or network
2. update internal state based on gathered input
3. draw current state based on internal state
4. repeat

This is a little too superficial I think

This "pattern" pretty much describes any computer program.
i.e.
1. Get input
2. Process input
3. Output result
4. If not done, repeat

Which is hardly a useful pattern to recognize.

I would say the the Design Patterns book is good if you are interested in learning about software design, which is only a small part of game design. As games become larger and larger, they are less and less software and more and more content driven.

A good example of this would be Quake 3, or more specifically the games based on the Quake 3 engine (Wolfenstein, etc). A great deal of programming went into Quake 3, where as the derivatives most of the work went into level design, gameplay and graphics.

To get back on topic: Game programming really isn''t any different than another other type of user-driver software. So in that sense it is related to GUI programming, rather than say, OS programming.

quote:Original post by ragonastick
One of my favourite methods of implimenting a new feature in my game is to just add support for it somewhere without doing it anywhere else. At the same time, I change a couple of variable names which relate to the feature being added. (Eg, from PositionSquare to PositionAtSquare). The code then won't compile, and I just go through the code for each compile problem and fix it, reviewing each change which is taking place. If there is extra stuff which will need to be done to get the feature to work, then it is done here. Finally, when all the changes have been made (most are just changing variable names), then the code compiles and the feature is there and working

You need to be careful about virtual functions. If you change the name and don't change it in the derived classes it will compile fine but be completely wrong. If you change a dervived one it will no longer be called through the base class.

You also need to be careful of name hiding. A locally declared variable with the same name as a member variable will hide it. The local variable will be used. This can obviously lead to confusing bugs.

Relying on the compiler is dangerous. I know what you're talking about and I've done it myself many times. In a large project it's difficult. Getting back to a state where it will compile again can take a long time (ie more than 30 minutes, sometimes more than a day).

The refactoring method will serve you well. Build tests, migrate functions, names, inheritances and so on, in a rigorous way. Recompile and re-test often. Implement changes first, away from where those changes are needed. Then bring them in with delegation. Then remove the call completely and have the new code called instead. It's actually back-to-front to what you were suggesting.

edit: fixed link

[edited by - petewood on December 6, 2002 4:21:44 AM]

quote:Original post by Oluseyi

Original post by Captain Goatse
I believe game programming philosophies are closely related to GUI programming.

Nope.

quote:I''m just generally interested in philosophy and would just like to know for my own good. As you probably got the idea, i''d like to get some book suggestions that are not based on certain code, but are generally usable in any environment. 3d, 2d, design, structure, oop, anything.

Games are software. Good software design and implementation philosophies are thus good game programming philosophies. Try to find The UNIX Philosophy by Mike Gancarz (a new favorite of mine). It''s principles of rapid prototyping and cyclical development lead to more robust software overall in a shorter amount of time. An insightful read.



Arguably of course. What I''m going to do in my current project is to store current *reusable* code and start from scracth. I have done some basic UML design how I''m going create the library for all the objects in the game that can have inheritable background.


What usually happens to me though, when I get stuck my project turns into a big construction yard and at the point when I''m finished everything has changed so much from the original design that I want to start from beginning. I know this is thought in all CS classes and repeated over and over again, but its just bad habit of mine.

My goal is to make as much reusable code as possible and through inheritation make this code very advanced.

quote:Original post by Captain Goatse
My goal is to make as much reusable code as possible and through inheritation make this code very advanced.

Ah-hahahahahaha!

quote:Original post by Anonymous Poster
Much of it applies to aspects of game design, but what about game design patterns?

What about this?

quote:
I know all real-time games are basically:

1. gather input from user and/or network
2. update internal state based on gathered input
3. draw current state based on internal state
4. repeat

That''s not an Alexandrian Pattern.