Thread: Program Too Big

> 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/

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.