Program Too Big

This isn't a compiler or linker error. This is a me error...

My game is way too big to remember!

At first, I create the frame, and I code like a madman. I leave a few comments here and there to describe what I'm doing. Once I finish the frame, I move on to something like displaying. But when I'm done with displaying and i need to do something with the frame, I take one look at it and say "What is all this?".

I've tried making diagrams and little pictures of how my game works, just so I can fit the general idea of it into my head, but they are never specific enough.

Whenever I lose track of what the game is doing, I do a rewrite. And so this cycle repeats itself. How can I prevent this? I'm sure all of you have run into this problem at some time or another...

Thanks!

- Evan

Why don't you just leave more comments? Also, it could be the way you code. Do you throw strange stuff thinking it will optimize the code? Do you not use proper indentation? Do you add lines of code which don't serve a purpose? Etc.

> just so I can fit the general idea of it into my head, but they are never specific enough.
It's all about design (just do a board search, keyword = design, author = Salem)

You need to start refining your high level designs (a rough idea) into more detailed designs (a much clearer idea). For example, make sure that your classes make sense, that they're representing the right objects in the system, and they have the right interfaces. You don't need to worry too much about how you'll implement the insides of classes in the early stages (that's one of the points of classes, to hide the inside from the outside). If your design "doesn't work", there is no point trying to code it up, it'll never happen.

Keep refining your design (adding detail) until all aspects of it are "obvious" to implement. If possible, show your design to other people and ask them if it makes sense.

Well, all this really depends. What are you designing? What is your platform? What are your options? What are your goals? Philosophies? Expectations? User base? Other demographics?

All these questions will shape which design philosophy your documents will cater towards. If you're designing a game for embedded systems using, for instance, OpenGL ES, chances are you will be limited in your options. You won't be able to have a mass of 128-bit graphics and like 512-bit sound with 12 channels or some such improbable nonsenset that doesn't exist yet... Things like motion sensors like you would see in VR wouldn't exist, that sort of thing. What and how you're developing is really a key in how many/what entities you'll have.

You might represent your engine as certain entities, lets say these entities are 8-bit sound(or maybe it was 16 for most mobile phones....forgot), then you'll have your sprite graphics(pc and npc), collision, movement, and level maps... basically everything you can think of will be a seperate entity, or an entity within an entity.

All of these entities will comprise your design document, it is what your game will be in the end, what it will mean, it will say if it's good or not, design and playability.

Really, forgetting which entities lie in which entities, what an entity represents, or what an entity entails is nothing more than human nature. If I ever forget what I'm coding (it happens alot and it's not surprising, alot of coders get into the "zone" if you will, sometimes it's a good place sometimes it's not) I just look back to my design documents. This is even more prevalent if I've been coding for about 3-days straight running only off of apples or something of the kind(mmm Glucose).

So in summary, don't worry if you forget what you're coding, if you get lost in the code, that sort of thing. If this happens it usually means that you are unsatisfied with the entity you designed in your design document from the start. Remember, a design document isn't linear, it doesn't jump up and it doesn't jump down, it jumps everywhere your mind takes you within the limits of your hardware.

It's sort of like a book with an infinite amount of blank pages. You can edit the contents of these pages at a whim. If you edit the contents of a page, it doesn't mean that you've mangled your design or made it unworthy of being worked on, it means that you saw an opportunity to make the project better, which is always a good thing.

Don't be afraid of editing a page, if you see an opportunity that seems worthwhile, go for it, just keep in mind your hardwares limitations and your user bases limitations. Your design document is your endless reference, if you forget something or want to improve something, always go back to it.

Here's a good example of a reference for game design documents:

http://www.ihfsoft.com/

THE DETAILS

Quote:

---

I leave a few comments here and there to describe what I'm doing... never specific enough...

---

I start with the comments first. I'll start each section of code with a short "header" description of what that code is supposed to do.

Then, I'll add detailed comments (perhaps a little less formal than psudo-code). If I can't figure-out the flow, or details, I'll make a mini flow-chart for this section of code.

After I have the section of code documented, I'll start adding real code. Each line of code should relate to a comment. As I add code, I'll edit the comments to make them more like normal comments rather than psudo-code. When I'm done I usually end-up with about one comment line for every 4 lines of code.

THE BIG PICTURE
Before you start, you need a specification... A description of what the program is supposed to do. For a simple program the specification might exist in your head, or it might be an assignment in a few sentences from your instructor. For a complex game, a complete specification would be several hundred pages of text and diagrams.

Quote:

---

...little pictures of how my game works, just so I can fit the general idea of it into my head...

---

That's a good way to start. You need a "big-picture" view of what your program is supposed to do. You need to document the flow of the program... how the different parts relate to each other. For a game, it might help to make a storyboard. You could even use 3x5 cards, with different major sections of the program/game/story on each card. You can then arrange them to see how they interconnect.

In your case, I'd suggest you (at least) make a list of the things that the program must do, and another list of things that might be included. I assume that you don't have a complete spec, and that you will figure out some of the details later... this is OK for a hobby project, but a disaster for a commercial program in the "real world" of bosses, customers, budgets, schedules, and multiple programmers. :)

Comments may help, yes, but what's really gonna help you is a nice program structure. I remember the old days makiung stuff in QBasic. You wrote the entire 1000 line program in one single function. Seemed logical at the time, but the next day you looked at it you were totally lost.

Start splitting up your program in lesser modules, use abstractions, use divide n conquer. A well structured and well named program has no need for comments (not much commenting at least). As a friend once said; "code should be self-commenting".

How you structure it depends on what you do, ther is no single true way to do it.

Thank you all for the help! I'm printing this thread out. I especially like the idea about the flowcharts for each section. I always imagined a gigantic flowchart for the entire program, but a bunch of small flowcharts makes perfect sense.

Thank you all! I might actually complete the program now.