Originally Posted by
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.)
Reply With Quote
Members who have read this thread: 0
Bookmarks