making a game...

Blah... Just trying to start thinking and working in a better way that helps me to be more productive and actually get things done. Plus, Im trying to get my friends to work on a game with me, so im hoping that once we do all get together one day to start, Ill have a decent grasp on what to do.

hehe. yeah yeah, vague questions

you can split your document into several parts. One which is the overall design, a ''design'' document. another which is more the technical document, and a third for the artist section, the art requirements.

you''ll also need a schedule, make up tasks for each and every one of you, brake it up into small fragments of say, one to two days work. Assign goals, milestones, that everyone has to reach.

you can see the design documents as answers to questions such as "What", "who", "where", "how", "When", ... The design document is the "What", and the story elements "where", "who", "When"). What platform, target audience, competition, what do we like from the competition, don''t like, Then you have a quick recap on the general gameplay (fps, 3rd person adventure, RPG, puzzle, shoot''em up beat''em up, or whatever combinations), a quick view of the environments, the overall graphics style, the characters, the places, the levels, throw in some concept art. How the story is implemented in the game, cutscenes, FMVs, interactive scripts as the game progresses (half-life).

the "How" is more like the technical document. Language and tools, coding conventions and standards, OOP design, general Game flow and individual state machines required, how to implement environments graphicaly and for physics, can the two be merged into one or will it require two diffenrent formats, physics, animation, scripting, controls, view ands cameras, cutscenes, multiplayer and networking, character animations, weapons, A.I. vehicles and usable objects, interactivity (environment, NPCs, objects, ...),input formats from tools, and for tools, then the tool chain, what tools are required, how is it gonna be done (plugins, editors, command line execs, multi-platform exporters, batch processes), ect...

art-wise, I''m not sure, I''d guess it has to do with the look of the game, colouring and texturing, model size, naming conventions, project directory structure, importers / exporters, texture formats, level size, restriction on the level design (draw distance), scaling, mip-mapping and LOD, animation, what the code and tool chain require as for file formats and naming conventions...

the "who" and "when" has to do with scheduling, assigning tasks to the team, discussing the jobs to be done, very roughly how long it''s gonna take. You can fix some milestones in the meanwhile, what as to be achieved for it, then each coder will then try to break down his tasks, and refine his schedule, which then can be finalised. It will still be quite rough, but should be a good approximation, and the milestones can then be met. if someone falls behind, or as problems, then it will become very evident, and you can all work into fixing that problem.

well, that''s my take on this. There should be plenty of design docs, examples, and tutorials around.

awsome, thanks a bunch oliii!