Design document, anyone?

[Michael Hartlef]

As the decision for our game is approaching soon, I would like to ask if anyone here has experience to create a design document and would like to work on it? If noone screams then I will try to come up with something. I think we should plan as much as we can before we start really working as it will keep us on track.

[kryton9]

Mike the work you did on the 2 game types before shows that you are the right man for this job. You have my vote!

[Michael Hartlef]

Mike the work you did on the 2 game types before shows that you are the right man for this job. You have my vote!


Thanks :) But you realize that this is a shitload of work :-\

[Michael Hartlef]

Question to all:

What would you guys prefer. A design document as a word file/PDF or a wiki.site where everyone can add stuff to it?

[Lionheart008]

Hi Mike:), hi all..

-
What would you guys prefer. A design document as a word file/PDF or a wiki.site where everyone can add stuff to it?

hmh... I personal prefer a design document as word/pdf file... The wiki.site idea is very good, but how should fill it in a continous way with game progress and knowledge infos? three, four guys here? ;)

- if there were more than five people they are working and creating things about the game with it I will agree to a wiki.site...:)
- the wiki.site is free for all to see?

best regards, Lionheart

[kryton9]

Mike, good question about pdf or wiki?

I personally think that wiki sites are great for projects like this. Everything is organized and there is no confusion about what is the latest of anything.

[Michael Clease]

Why not just have a sticky thread (that just sounds wrong) and people add posts and if mikes in charge of design perhaps he could update the first post to reflect the current information.

[Michael Hartlef]

As it seems that this will be a kinda "Let's play and see" project, there is no need for a design document or a wiki.

[Lionheart008]

dear michael,

I am helping you to create a structured 1) "design document" and a new 2) "wiki"...

here's such a lot of stuff it's just screaming after it :)

see you, come back soon;) lionheart

[Michael Clease]

So can a wiki be locked so only certain people can see it?

if not then it is a waste of time.

[Petr Schreiber]

I have no problem with updated sticky post,

question is if it would not be too long in the end to hold all the information.
So here comes compromise - sticky post containing PDF which would summary all we agreed on.


Petr

[Michael Hartlef]

dear michael,

I am helping you to create a structured 1) "design document" and a new 2) "wiki"...

here's such a lot of stuff it's just screaming after it :)

see you, come back soon;) lionheart


Thanks Frank. It's not about to much work. It is about how. I allready had started a document. Doing both would be overkill. Anyway, we will do the sticky topic then. It should be enough for a "let's see what happen" project.

[Lionheart008]

hi michael:)

yes, it sounds good!

I allready had started a document. Doing both would be overkill. Anyway, we will do the sticky topic then. It should be enough for a "let's see what happen" project.

- if you have some document ready send it to me PM (if you like) and I can read and check it... or send it to here;)

wish you a nice day, lionheart

[Michael Hartlef]

Thse were the both documents started even before I knew which game we would do. It is not finished nor are the topic all there. But I think you could get the structure out of this.

[Petr Schreiber]

Hi Mike,

thanks a lot for your design document, now I can see it more clearly.
I did not thought the hovercrafts will shoot for example ( but I like the idea, heh ).
You did good job on it.

Very wise decision was 512x512 texture limit, Intels would cough at higher res.


Petr

[Michael Hartlef]

Petr, it was just fillings, the actually content would have came from our discussions. In WipeOUt you can collect powerups and weapons, like bombs and stuff liek that. Gives the game a nice element.

[Lionheart008]

hi mike, dear petr:) hi all...

@mike
thanks! I have downloaded the pdf document... very good overview and content! :) this is the right way for a structured design document for the game, bravo! :D

- for "3d model tools" you can add "Cinema 4D and Lightwave" ;)
a) Cinema 4d: www.maxon.net,
b) Lightwave: www.newtek.com, newtek-europe.com

I am working with both 3d apps... and perhaps anybody knows the 2d application:

- "Photoline" ?, www.pl32.de, a very good and small 2d image manipulator... I like it...

more soon, I am out of order now, week-end..., bye, best wishes, Lionheart

[Michael Hartlef]

Thanks Frank. My intention was only to add tools that a freely available and could be a help for the team members. If you know any good freeware tools, then please let me know and I add them. If I add all the commercial tools that I own, man this list would be long.
Hexagon, Truespace, Poser, Photoshop, ZBrush, Silo, Carrara, DazStudio, SnagIt, UltimateUnwrap3D, Ulead Photoshop, Cakewalk Sonar, FLStudio, RiffWorks, Cubase, Amapi, Animation Master, Anime Studio Pro, Bryce, LogoCreator, Manga Studio Ex, Campaign Cartographer.
I'm sure I forgot something.

[kryton9]

Michael great job on the document so far!

I see that the way you are seeing this is that not only will there be a game, but also tools for the game.

So we modelers should perhaps make things in parts that could be put together for the final vehicles with the vehicle making tool?

I guess being made in parts could also lead to cool crashes and replacing parts with damaged parts and in the end
nice parts flying everywhere in a critical crash.

[Michael Hartlef]

Michael great job on the document so far!

I see that the way you are seeing this is that not only will there be a game, but also tools for the game.

So we modelers should perhaps make things in parts that could be put together for the final vehicles with the vehicle making tool?

I guess being made in parts could also lead to cool crashes and replacing parts with damaged parts and in the end
nice parts flying everywhere in a critical crash.


Yes, that could be a feature if we have time for this. Right now we ahve to collect all the ideas, the art department has to think about how to create these things and the coders have to think which tools we need and how it can be used in a game.

[Michael Hartlef]

I will lock this topic as I open a new one with the current document and so you guys can comment on it.

[ISAWHIM]

I would like this file and the content that it contains, considered for possible inclusion, (With discussion first.), as part of the design document. (Or something similar.)

The attached image outlines some structure for us to build off of. I have collected a good size chunk of scattered data, based on the individual work we are doing, and based on the ideas suggested as being a potential "Possibility" for inclusion.

The outline also uses some of the worded data from the design document, so as to help keep it consistent.

Specifically, it outlines the "GUI/GAME" flow. To help place it into a better perspective. Additionally, I also suggest certain elements which this "GUI" and "GAME" may require. Since we are creating separate code that should interact with other code, and segregating areas of code based on the "Flow"... I have come-up with a general standard. (Which is the part that I would like input on, or argument in aide of an alternative.)

The point behind the shortness of this individual submission, is for simplicity.

The concept is that we use these standard "Scenes", to create each element of the game, as a whole. They allow for some mobility between stages, and allow for user-options or auto-detected-options to be specific to areas.

When you move from an "Intro" (Which would have no user settings.), to the select area... New items will be loaded, and old "Intro items" will be dropped/flushed. Same as you move into the actual game. Options are set for those supporting scenes and loaded, while the other scenes become MUTE and/or dropped/flushed.

The all scenes will be a parent of %sMAIN, but each scene has a specific purpose. The main scene view-ports will use those scenes for creating the "GUI" look, and provide the required space for independent control within the game as a whole.

For example, the "Single Race" setup might display a ship-select area, as well as a track-preview, and may have info to display about both. There may also be a customization display, to add things to your ship that you selected. You may have more info to display about those... (Recycled screen, since you would not see both at the same time, but may still share the ship-view.)

ETC...

The "%sPLAYER" scene would have the support of the skybox and effects scenes... That is the game, not just the player ship. That would be the player-view, which holds all ships, objects, the map, effects, sounds, etc...

Any include files should use these same values, where possible, no matter who makes it. If data from a scene is needed, or needs to be altered, it can be handled directly in an include, if desired. (Thus my other reason for wanting a standard outlined in the design document.)

Scenes are the first element encountered in the setup, so I figured that I would start there. Those who are contributing to design in those "Scenes", can further discus the next element shared by the game as a whole. (To me, this would be cameras, images, models, and scale/dimensions as constants.)

We should also think about assigning an "Include" prefix, for each desired include. This prefix ID should be on all GLOBAL or NON-LOCAL/NON-FUNCTION/NON-SUB values. The Include should include this prefix ID to the name of the include file also. So... For those of us who need to use the "Included GLOBALS"... can easily use them by the prefix to the value.

This also makes for easy identification in code, if an include is not used, or has been re-assigned a new ID due to a merge of includes. We can just search in the main code for the old prefix, and REPLACE, or hand edit.

NOTE: Do not read the stuff below... it is half off-topic, and just here for someone to help offer a better solution.

(In most events, in my files, I add an x to all values to "Mark" them as "Mine" or "Self"... It is a habit I developed from working with includes in the past. It works well, but should not be needed. Any values in an include should be auto-prefixed by the program that merges them into one file. MyVal inside MyInclude, turns into MyInclude_MyVal, while all the values in the main file that includes the include... which is called "MainFile", and contains "MyVal" also... becomes MainFile_MyVal... Since an include can not include itself... there is never any variable conflict, and it is easy to tell people to use %MyInclude%MyFile for values that need to be pulled from an include. The main program substitutes the %MyInclude% with the ID that is actually assigned to each variable, or it just "REPLACE"s "%MyInclude%" with "MyInclude_", works both ways... if the include wants to use your main files values. But that is another topic. I only mentioned it, because you guys may know a better way to handle that situation. Same as a LOCAL in a FUNCTION becomes a unique value to the function. Which is why functions in an include do not need the prefix added, only globals. "x" in function "test" becomes "test_x", or more correctly, "test.x" in PHP and other object oriented languages.)

[Michael Hartlef]

Shit, I forgot to lock it. I would put your post into the other topic.