That leads to another thing I was wondering about - being that global variables and function were mentioned. With DX (especially games), is it generally accepted that you can use lots of globals? I heard it was, but geese, what a mess!

I think general planning and tighter function/file interaction is what I really need to work on. Previously, I''d just sit down and start writing a new program as it came. For example, in my game, I have a lot of objects flying around - spaceships, asteroids, bullets, etc. What I would''ve seen had I planned was that they all have a lot in common - position, velocity, physical properties, size, etc. So now I have about 10 different classes, each of which is about 50% identical to the other classes. There''s obvious room for improvement there!

Thanks for all the advice - will be much heeded!

Get yerself some teammates.

Funny anecdote about how never to comment, from one of Ultima Underworld''s developers:
http://www.dfan.org/writing/comment.html
And another anecdote on a similar topic:
http://www.dfan.org/writing/coding.html

quote:

---

Original post by Verso
That leads to another thing I was wondering about - being that global variables and function were mentioned. With DX (especially games), is it generally accepted that you can use lots of globals? I heard it was, but geese, what a mess!

---

No, it''s not generally accepted Sometimes examples use globals just to show more easily how something works. But you never need globals really. My current game has just 1 global: and that is ''int main()''.

The fewer globals you have, the cleaner your code gets. The extra effort you spend in putting things in neat little modules and sections is repaid several times over when your code is so much easier to read.

quote:

---

I think general planning and tighter function/file interaction is what I really need to work on. Previously, I''d just sit down and start writing a new program as it came.

---

I''ll be honest with you: that''s how I go along too. At least to begin with. I start with 1 file, often with the main() function doing everything... initialising the graphics, drawing the map, and shutting it all down. Then, I clean it up as I go along, before it has a chance to get unwieldy. If I find myself doing something twice, I make it into a function. If I find 2 things having similar properties, I invent a class to contain those properties. If I find 2 classes being similar, but not exactly, I move information into a single base class. If a function operates mainly on a class, I make it into a class member function. If I find myself using a number more than once in the same context, I make it into a constant. And so on.

The benefit of my approach is that I start off with something working, and keep refining it as I go along. This is a nice compromise between the "Everything is a global variable and the code is a repetitive mess" and the "I have 100 classes in my hierarchy, but I''ll never finish implementing them" camps. Of course, my method doesn''t escape the need to learn good design habits: I have to be able to recognise what makes a good class, what features are good candidates to go into the base classes, and so on. And this recognition has to happen early, or you lose the benefits.

For example, if I was doing your game, I might have started off with a Spaceship class, and tweaked that until I got it working, moving across the screen, and so on. Then when it came to adding an Asteroid class, I would think "hmm, lots of stuff shared here with Spaceships. Maybe I can factor it out into a base class." So I''d make a SpaceObject class or something, and move the position, velocity, size etc from SpaceShip and into SpaceObject. Then I just make sure that SpaceShip and Asteroid both derive from SpaceObject. This way, I''ve implemented 90% of Asteroid using existing working code, SpaceShip still works just as before, and I''ve drastically cut down the time it will take for me to develop a Bullet or Projectile class in the future. Rather than a ''top-down'' or ''bottom-up'' approach, this is more of an ''outside-in'' design! I start with bottom-up, then shift to top-down whenever possible. For me personally, it provides a good compromise between quick prototyping of technology and effective design considerations and frameworks.

Good luck with the game, anyway!

quote:

---

Original post by GayleSaver
Funny anecdote about how never to comment, from one of Ultima Underworld''s developers:
http://www.dfan.org/writing/comment.html
And another anecdote on a similar topic:
http://www.dfan.org/writing/coding.html

---

LOL!!! Oh, those were great, especially the second one. I can never get enough funny coding stories.

My favorite piece of code (that I didn''t write) in a multi-threaded windows MFC app, the "OnClose" message handler:

// exit gracefullyexit (1);

I think just having lots of "modules" in files like graphics.c, input.c keeps it managable. Currently I''m on about 10,000 lines.

What I''ve found though is that most of making a game seems to be just loads of list managment, like textures, entities, sounds, bla bla... and it''s all pretty much the same for each.

Am I missing out here or is this what it really is?

Yea, coding stories are the best^^
I need to make my engine less boring. I always use error messages like "Function() failed". Here''s one (sorta) funny clip I wrote a long time ago though:
switch(dxType)
{
case ''d'':
MessageBox(hwnd, "Direct Draw init screwed up.", TITLE, MB_OK);
case ''i'':
MessageBox(hwnd, "Direct Input init went to hell.", TITLE, MB_OK);

And another (even less funny) one (both of there are from when I was first learning DirectX from the MSDNtutorials):

char szFrontMsg[] = "Front buffer: I''m better than you. (F12 to exit)";
char szBackMsg[] = "Back buffer: I ''da bak buffa'' (F12 to exit)";


And on the original topic, I just checked and my current project is at 5094 lines (including blank ones), and now it seems insignificant. Especially cause about 1000 of those are ASM, which, if I didn''t have multiple copies of functions to do slightly different things, would probably be more like 200, which written in C++ would probably fit into 100. Oh well. Basically the way I keep it under control is to make a bunch of files, and group related classes into them (like, tiles, layers, and maps all have to have eachother to work, so they go together). Then give each class a bunch of functions (usually an Init, UpdateFrame, Cleanup and whatever else is needed), only use globals for things like setting up the program, the main UpdateFrame function, the active map (it''s easier than passing a pointer all the time), and the video/input/sound control objects.
I don''t think it''s really that great of a style though, especially since I rarely comment, and do things the fastest way I can, not the easiest to read.

Anyway, good luck on getting your project in order. If it gets too confusing, try to reorganize everything into seperate files, but don''t actually do anything until you''ve though about it first or you''ll end up going around in circles trying to decide where to put something^_^

---

-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

Just to quickly fill in to DekuTree64''s reply, I played Dune 2000 with my brother over DCC. Then suddenly the thing bombed out showing "xxxxxxx.cpp" at the title and the error message states "Error ### - Unit doesn''t know it''s a unit". Man I cracked myself for 10 minutes. Well you''ve got to admit, it was funny.

Actually that hierarchy stuff, when you draw it on paper (or write, whatever), does it look like a tree (You know, the main node with the branch nodes, etc.) or do you just write the code descriptions?

I''m just a bit interrested in what you guys said about all those lines of code and all that confusement. Well will some one please explain it to me some time (just for the interresting fact of hierarchies. Who knows if I''ll be living on it to use it.)

------------------------------
-Last Attacker
ICQ: 120585863
E-mail: laextr@icqmail.com

Well you want to draw your heirarchy as a tree, and probably have class descriptions seperate. Just use the name of the class in your heirarchy and show which are your base classes and which classes are derived from them. If it provides no other benefit to you, atleast you have all of your classes listed in one place so you don''t have to knock your head to remember what you named that class that you haven''t used in a couple of weeks, they are all in one document.

Then you can create the individual class documents. Here you list the public data and methods and show which classes interact with which other classes and which methods they use.

If you have groups of classes which are designed primarily to interact with each other, then you can draw them all on the same document and use line-arrows from class to class to show the relationship. You can break this down to multiple levels.

If you want to get really into it, you can then create a class dictionary for each class. This will describe everything about the class. You will have a seperate page for each member variable and method. You will describe it''s purpose in life, what it does exactly (if it''s a method), the data type, min-max values, how often you expect to use the member, etc...

In my experience this is mostly only done religiously on large mission-critical applications. Just mix and match whatever works best for you Despite Booch and everything else, OOD is still in it''s infancy and nobody can say what is the ''best method''.

But any design documents are better than no design documents

Seeya
Krippy

I actually wrote a console application that allowed me to enter in all my project source files and it counted the number of lines and gave the option to exclude comments and space. It also gave line percentages of comments used, function calls, etc. Don''t know why I made it, just got bored one night. Pretty cool to see the exact size of my projects though.