#### Archived

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

# What kind of code should I NOT type when making games?

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

## Recommended Posts

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

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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]

##### Share on other sites
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

##### Share on other sites
Don''t just sit down and start coding. For the love of God. Careful planning of the algorithms and data structures your program will use before even sitting down at a computer will make your program run many times faster than a poorly designed program. In the software industry, there are programmers and software engineers. The latter designs a program, including objects, algorithms, etc. and does very little coding. The former gets instructions from the SE and puts them into code. For example, the software engineer would determine that the program needs an object that holds X data which you can perform Y operations on. The programmer writes the class. No matter how good the programmers are, the program won''t work without good SE''s and vice versa. A huge percentage of commercial software projects over the years have ended in failure due to bad design in the early stages (don''t believe me? type software enginnering blunder into google). When you write a program yourself, you are filling both roles. Don''t crap out on SE because you can''t make up for it with good programming. Granted there might still be low level design decisions that don''t come completely clear until you''re hacking away. But make sure the top level design is efficient and logically sound. Do this on pencil and paper. Don''t start coding until you know exactly what you want to do.

##### Share on other sites
commentations wtf

i only comment code when i hack something to make it compatible with other peoples code

instead of adding tons of nerving comments i give my functions and variables certain names that describe the job as good as possible without using too long monster like name

int m_iIamtheintegerthatcountsthenumberofobjects

##### Share on other sites
Commenting is easier if you comment before you code.

If you write high level sentences describing each function, you will define the logic without code.
Then anyone can take those sentences and write code that does just that in any language.

For instance, if I want to create a routine that prints a message every second based on the state:

if timer= old_time + 1     old_time = timer     state = State.current     print state->message

is not good since it is obviously based in programming. You aren''t designing so much as coding.

for each second     determine current state     get message based on current state     print message

Is much better. I believe "Code Complete" refers to this as PDL or something. In any case, you reduce the high level ideas until it become silly to write the lines instead of coding them.

##### Share on other sites
quote:
Original post by kdogg
... In the software industry, there are programmers and software engineers. The latter designs a program, including objects, algorithms, etc. and does very little coding. The former gets instructions from the SE and puts them into code. For example, the software engineer would determine that the program needs an object that holds X data which you can perform Y operations on. The programmer writes the class. ....

Really? I really like both. I can''t see enjoying just doing one or the other.... And I do have plans to work in the software industry. Not games, but hopefully some kind of visualization applications.

Sorry, I guess this is off topic, but I really do want to make a living doing both.

thanx

##### Share on other sites
i hate commenting it makes it harder to overview the code in my opinion

it something i don t need

##### Share on other sites
Well, I usually put a comment above every function (in the style of the Quake source code with short horizontal lines of ''='' signs, but that''s just personal taste) which contains information about what some would call "contracts", i.e. what the parameters are (ownership of pointers and stuff like that) and what the function returns (return codes, exception situations, etc..). If the function alters any global (or object) state that''s not immediately obvious from the function name, I mention it in the comment as well. If there are any other interesting details about the function (such as when it''s usually called), I put it there as well.
Those are the kind of comments that are necessary when you want to grasp how different modules connect to each other quickly. Apart from that, the horizontal lines in the comments help to give the source code visual structure.

Also, always separate modules, classes, etc.. as much as possible. Blackboxing is the key here. It may be a little more work initially, but it''ll save you so much time later if you need to modify one of the modules or even if you need to alter the interfaces slightly.

cu,
Prefect

##### Share on other sites
id say you don t need comments unless a function does something insane complex which you can t read without a small hints

and perfect "..don t mention quake source code :D.."

quake src is overcommented

##### Share on other sites
I usually only use comments for TODO''s. If I have to leave my computer, I write a TODO on the last source file I edited saying what to do next. Otherwise I usually forget.