Michael Hartlef
11-10-2008, 19:22
Hi folks,
here I have the current design document.
Michael
Michael Hartlef
11-10-2008, 19:30
Ups, sorry. I didn't change the sound effects list. Version 1.01 is up. ;)
Petr Schreiber
11-10-2008, 19:39
Thanks Mike,
very good to have it all in one place.
Petr
Thanks Mike nice to see all the current info in one place.
I will get started on some sound effects this week to get things rolling.
I guess the sound tracks can wait to match the feel of the racing levels when they are near completion.
About Modeling, I will wait for the core team to decide on more info for it to give direction, the same with artwork, and models for terrain etc.
Perhaps as the core team finalizes ideas you can assign tasks in the design document to various members as to what is needed when.
Michael Hartlef
14-10-2008, 09:06
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.)
I am not on the coding team, but I like what I saw Mike!