• Advertisement

Archived

This topic is now archived and is closed to further replies.

Game Programming Philosophies

This topic is 5556 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''d like to know more on this topic, but my own methods of research are quite limited. I tried googling this up, but failed. I believe game programming philosophies are closely related to GUI programming. I need something general, like the theory thought in CS classes. What I DON''T need is party trick quides that some people on this site are quite fond of. 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. If you feel like flaming on the party trick issue please go die.

Share this post


Link to post
Share on other sites
Advertisement
If your code compiles *flawlessly* on the very first try, delete everything. Something is wrong, very, very wrong with your source and you DON''T want to run that program to find out what it is.

If your morning coffee is bitter, your day will suck.

If you ever hear the letters C, O, B and L assembled together to form the name of a programming language, run, run little man, run for your life and don''t look back. Ever.

Share this post


Link to post
Share on other sites
If anyone ever asks you to "go quickly explain something technical to marketing", feign death.

Read Design Patterns

When someone says, "you should have plenty of time to finish this", laugh and punch them in the face.

i dunno, be more specific in your questions. though i''d actually like to see this turn into a joke thread. but are you talking about coding conventions, software architecture philosophies like what components to break you engine into, etc?

-me

Share this post


Link to post
Share on other sites
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.



Captain Goatse, I am not exactly sure what you mean by "philosophy", but from what you talk about it seems that what you want it to learn about the underlying theory of game programming and not just the "party tricks". To do this I would recommend reading some of theoretical computer science books out there that give you a good solid founding.

For this purpose I think you will find my book list at amazon usable. Give it a look - I think it is what you might be looking for.

http://www.amazon.com/exec/obidos/tg/guides/guide-display/-/2FRIQOWB2THR/ref=cm_aya_av.sylt_sylt/103-3001788-4142219

Jacob Marner, M.Sc.
Console Programmer
Deadline Games

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

game programming philosophy 101.

step 1 -- hack everything till something works or everything breaks.

step 2 -- build a working system with what youve learned and created
from your hacks.

step 3 -- if project is finished goto step 4 otherwise goto step 1

step 4 -- relax, play some games, drink some beer.

step 5 -- brainstorm new ideas. goto step 1.

note that the step 4 drinking of beer can be intermingled into the other steps.

Share this post


Link to post
Share on other sites
quote:
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.

Share this post


Link to post
Share on other sites
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

I prefer not to use this though, it is fairly unstructured obviously. But I am happy with the results - I currently have an RTS which has no known issues and runs pretty well too. Also, if I was in a team, I would have to take a different approach - I don''t think many other people would like to have variable names changing seemingly at random . Good planning will usually avoid this type of thing. I had some pretty terrible planning for my RTS - I even managed to leave out the "radius of sight" from the unit filetype which was a bit stupid. Still, just go back and fix things up properly (I''ve seen people who in that position would just create a new filetype which just describes the radius of sight for a specific unit and has the file treated differently to the other file describing the unit)

Trying is the first step towards failure.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
step 1 -- hack everything till something works or everything breaks.

step 2 -- build a working system with what youve learned and created
from your hacks.

step 3 -- if project is finished goto...
At this point, I stopped reading.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:

Read Design Patterns



Read that. Much of it applies to aspects of game design, but what about game design patterns? 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

But can any in-depth general patterns be revealed without having to use a specific API? What about general architecture patterns/designs for different genres?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
[quote]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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • Advertisement