   Some Basics of Game Designing
  Me and a friend just decided to make a Tank game (one tank tries to shoot the other tank and vise versa).I really do not want to hack down code like i did for a previous Space Invaders game that failed miserably so i am asking a few questions on designing (before actual code begins). Is it good to write things down on paper rather than typing up the design on a Text Editor? What exactly should be put in the design? (Functions, Classes, structures, etc...)Is it better to go through and re-code or re-comment a Graphics Engine or is it better to keep it like it is?How should i look at the game while programming it(example: Looking at it as a finished product and programming off of that or by building it with small blocks of code). I am asking these questions because i am interested in actually finishing this project and having it run with minimal erros and bugs. 
  I''m probably not qualified to answer many of those, but regarding the first one, I would say that putting your design on paper first could be immensely helpful, depending on various aspects of your personality.  I do most of my design on paper, and it helps because I can easily draw diagrams, pictures, etc., and organize things in all sorts of charts, draw arrows linking various topics, etc.  Can''t easily do that sorta stuff in a text editor.  But at the same time, I would call these two options as being largely a matter of preference.  Neither one is "wrong", or more prone producing a poor design.What to put into the design can often largely be based on the nature of the program.  But your design should probably include a lot of different things.  For example, with UML, there isn''t just one type of diagram, there are a bunch.  A program might need to model classes and their relationships, but it might also need to model the sequence of events that occur as time passes.  And it is likely to model how the program interacts with users.  A design might be considered incomplete unless is involved all of those.  But like I said before, this can be highly dependent on the nature of the program.As for recoding a graphics engine, I would say yes only if the engine is already composed of a lot of hacks and work-arounds, or if you forsee needing to implement a lot of hacks and work-arounds to get it to function with the new game.  But if it is reasonably clean, and should be able to do all that you need it to, don''t waste the effort of reinventing it.Based on my limited experience, standard traditional software engineering looks at the product as reasonably final once the design is done, whereas more recent development methods, especially in the games industry, is much more flexible with design.  You still have to be careful with how you manage a flexible methodology, but it definitely has its advantages.  But so does the more traditional method.  Pros and cons to each, as happens with many things in life. ;quote:What exactly should be put in the design? (Functions, Classes, structures, etc...)IMO you should have at least two (sets of) documents, one focusing on the *game* and the other on the *implementation*.  You can get away with just a description of the game if you have competent programmers and a reasonably simple game.The game description should pay absolutely zero attention to coding issues.  You should describe exactly how various screens work, how objects (not in a C++ sense, but a far more abstract sense) interact and so forth.  The more you describe in detail, the easier implementation becomes.You *will* find that where your design is sketchy, coding will take a *long* time.  Where you design is clear and specific, coding will proceed rapidly.How you write the documents is irrelevant. Personally I find it easier to prototype and finalize documents on a computer (easy erase), but for very abstract things I like to be able to draw boxes, arrows and other doodles with a pencil. YMMV - just get on and do it.Once you have a game design document, you can produce a technical document if you need too.  A bunch of small documents is possibly better, describing all your subsystems and so forth (although actual code is sometimes better than a formal document).Only experience can show you where you should spend effort (and my opinions are just that - opinions - although based on some experience).  My suggestion is to prototype early, get things running and see how they work and look.  Keep your team loose and motivated with small visual progress (artists/non-programmers are not impressed with things they cannot see on screen).  Design for *specifics* and not vague hand waving.  A simple concrete system is better than some airy-fairy ''perfect'' system.