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

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

0

Share this post

Link to post

Share on other sites

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.

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.

0

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)