What kind of code should I NOT type when making games?
Author
When programming games, pc or otherwise, are there methodologies or programming styles I should avoid? For example, are there benefits to using blackboxing in code? Another example: how much weight does ASSERTS() have, or pre/postconditions, when designing a game?
Is some of this stuff optional? Or should time really be spent figuring out the best algorithm for a tetris engine - before sweating hours over a keyboard, trying to figure out why pieces keep falling on the side of the screen, and not randomly like you wanted them to?
In the interest and pursuit of optimizing coding and compile time, these questions are appealing to me, and perhaps they are questions that many budding programmers might want to know about. On the other side of the coin, what methodologies are absolutely indispensable when writing a game?
I believe in commenting. The more comments you have, the more chance that someone who does not know your code will understand it. Almost all of my programming to date has been academic, so issues with the cleanliness of my code are legion - global variables, ugly variable names, and other things that would make a coding exec cringe.
What''s your take? The forum is listening...
Thanks for your time...
-slippers2k
Attack life''s problems like a Subaru... with all four wheels
I''m not a pro in any sense but from experience I have learnt that the key to a quickly coded and working product is beforehand design. The more the better. Designtime can be as much as twice the time to code the thing or even more to ensure that everything is planned and no or very few unexpected problems come up.
About asserts I have never used them, I trace by logging important situations.
I have not spent much time on optimizing right now even tho I have it in mind when coding.
In order to have a clean code I think abstraction or blackboxing as you call it is another key element in game development. Making independent modules for each important object is very nice and eases bugfixing and reading the code back.
I must admit I am very bad at commenting but I want short code that is easily overviewed and comments everywhere is just in the way. It is a good thing to explain especially hard-readable parts and have function descriptions but I do not like commenting every code segment or every line as some people do.
Well, that was it for now.. hope I helped a bit at least
About asserts I have never used them, I trace by logging important situations.
I have not spent much time on optimizing right now even tho I have it in mind when coding.
In order to have a clean code I think abstraction or blackboxing as you call it is another key element in game development. Making independent modules for each important object is very nice and eases bugfixing and reading the code back.
I must admit I am very bad at commenting but I want short code that is easily overviewed and comments everywhere is just in the way. It is a good thing to explain especially hard-readable parts and have function descriptions but I do not like commenting every code segment or every line as some people do.
Well, that was it for now.. hope I helped a bit at least
ASSERT is nothing more than a compile time macro that is expanded by the pre-processor. In a final build, ie without the DEBUG compiler symbol defined, asserts expand to nothing so there is no overhead.
As for design, I agree that design the heart of almost any software product. In fact, other than quick and dirty prototyping of new ideas, there should be no code written at all until the design is finalized and detailed. You will save many hours of debug hell this way, and you will have a very nice, self documenting system as a result.
Code commenting is important too, although one has to be carefull not go overboard. I have seen code where every line has a comment to it. This not only makes things harder to read, but is largely cluttering and redundant.
For style, I highly recommend Code Complete, by Steve McConnell. There is some great perls of wisdom to be gained from this book in terms of style and such.
Just my 2 cents.
As for design, I agree that design the heart of almost any software product. In fact, other than quick and dirty prototyping of new ideas, there should be no code written at all until the design is finalized and detailed. You will save many hours of debug hell this way, and you will have a very nice, self documenting system as a result.
Code commenting is important too, although one has to be carefull not go overboard. I have seen code where every line has a comment to it. This not only makes things harder to read, but is largely cluttering and redundant.
For style, I highly recommend Code Complete, by Steve McConnell. There is some great perls of wisdom to be gained from this book in terms of style and such.
Just my 2 cents.
quote:Original post by Lightstrike
I''m not a pro in any sense but from experience I have learnt that the key to a quickly coded and working product is beforehand design. The more the better. Designtime can be as much as twice the time to code the thing or even more to ensure that everything is planned and no or very few unexpected problems come up.
Do you really believe this yourself?
"If there is a God, he is a malign thug."
-- Mark Twain
before i code anything, big or small, i almost instinctually scribble down notes, drawings, diagrams, on a notepad. Go to a coffeeshop, do that for about an hour or two, just to get the basic framework down. It is in no way a formal design, but it does help solve problems that could arise down the line had i not taken a few hours to work things out. I highly recommend at least doing that.
You should go with what you are comfortable with.
Each artist has their own style and that also goes with programming as well. There is an accepted "standard" to programming style, but if you are just learning then go with whatever you want and adapt your code to the "standard" after your project is done and functioning.
good luck
Each artist has their own style and that also goes with programming as well. There is an accepted "standard" to programming style, but if you are just learning then go with whatever you want and adapt your code to the "standard" after your project is done and functioning.
good luck
I don''t use asserts, overhead or no. I prefer exceptions (*gasp*!) because they allow me to separate execution from error handling in a clean and logical way. A key to using them effectively is mastering exception specifications, which are a complex topic (I''m still learning).
Another thing I do is to prototype in a dynamically typed language, allowing me to test algorithms for correctness and even benchmark in some cases. My current prototyping tool of choice is Python.
Was it yesterday I was reading about a technique for defining functions in Python that had pre- and postconditions? Very interesting for testing and "non-performance" code (I advocate embedding Python or Lua or another dynamically-typed, "scripting" language in C++ and using it for much of the logic, delegating workhorse routines alone to C++).
Commenting, documentation and good design are obvious necessities. What goes contrary to conventional wisdom is that you shouldn''t overdesign; prototyping is actually the most important design tool you have because it lets you try out designs and discard those that don''t work before you over-invest yourself in them.
Reuse is another much-overlooked principle in the hobbyist community. You don''t have to write everything yourself. Find good libraries and use them so that you spend your time on the actual application or game. I avoid writing technology as much as possible, spending time evaluating various tools and toolkits.
Another thing I do is to prototype in a dynamically typed language, allowing me to test algorithms for correctness and even benchmark in some cases. My current prototyping tool of choice is Python.
Was it yesterday I was reading about a technique for defining functions in Python that had pre- and postconditions? Very interesting for testing and "non-performance" code (I advocate embedding Python or Lua or another dynamically-typed, "scripting" language in C++ and using it for much of the logic, delegating workhorse routines alone to C++).
Commenting, documentation and good design are obvious necessities. What goes contrary to conventional wisdom is that you shouldn''t overdesign; prototyping is actually the most important design tool you have because it lets you try out designs and discard those that don''t work before you over-invest yourself in them.
Reuse is another much-overlooked principle in the hobbyist community. You don''t have to write everything yourself. Find good libraries and use them so that you spend your time on the actual application or game. I avoid writing technology as much as possible, spending time evaluating various tools and toolkits.
quote:Original post by Oluseyi
Was it yesterday I was reading about a technique for defining functions in Python that had pre- and postconditions? Very interesting for testing and "non-performance" code (I advocate embedding Python or Lua or another dynamically-typed, "scripting" language in C++ and using it for much of the logic, delegating workhorse routines alone to C++).
Before Arild points it out, this is a standard feature of the Eiffel programming language.
quote:
Do you really believe this yourself?
I do!
I have only two game projects to my credit, and only one of them I completed to any degree of usable-ness.
You can see them on my website,GBGames, but keep in mind that they are QBasic games.
My Pac-man clone was made in 1998. It was hacked out over the course of a week, before I had a connection to the Internet.
Try to read the code and make sense of it.
Very spaghetti like.
A couple of years ago, I decided to make a Pong/Warlords clone.
That code is much better designed. I wrote down quite a few of the functions/subroutines. I should have designed a little more. I figured that if I had the subroutines, I could just code each one, since the main parts are all connected anyway. It didn't work too well. I bet you could read it though, and at least get started trying to get it to work yourself if you tried.
The point is that in my first project, planning came after I got stuck coding. The second project, planning was done beforehand, but I could definitely have done more. I would probably have a finished game.
I can't understand what I did in the first project years later. I can look at the second project though and try and finish it if I had the time.
My next project might be a reattempt at that second project, or I might go ahead and try to make another Pac-man clone for the GNU/Linux platform.
But in the end, designing and planning are the best things you can do.
Besides "Code Complete", which I am reading right now, check out "Game Architecture and Design" as it is one of the best (maybe THE best) game development books I have read.
[edited by - GBGames on March 7, 2003 1:29:17 PM]
quote:Original post by GBGames
Do you really believe this yourself?
quote:
I do!
I don''t.
All the planning you do up front is done with a very limited understanding of the problem domain. You cannot make intelligent design decisions if you don''t understand the problem.
I''d say most of my intelligent decisions are done about halfway through the programming process. The trick is to make it easy for yourself to make even radical design changes at this point.
quote:
I don''t use asserts, overhead or no. I prefer exceptions (*gasp*!) because they allow me to separate execution from error handling in a clean and logical way. A key to using them effectively is mastering exception specifications, which are a complex topic (I''m still learning).
An assertion is semantically very different from an exception - an assertion is never used for error handling. An assertion signals a condition that should always be true, no matter what - a breach of this contract means the programmer has made a mistake at some point.
Most languages with built in support for assertions implement them using exceptions, btw.
quote:
Was it yesterday I was reading about a technique for defining functions in Python that had pre- and postconditions?
You can do that with metaclasses, I believe. However, reading about metaclasses gave me a headache, so I didn''t.
"If there is a God, he is a malign thug."
-- Mark Twain
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
