Results 1 to 6 of 6

Thread: Game: Current design document

  1. #1

    Game: Current design document

    Hi folks,

    here I have the current design document.

    Michael
    Attached Files Attached Files

  2. #2

    Re: Game: Current design document

    Ups, sorry. I didn't change the sound effects list. Version 1.01 is up.

  3. #3
    Super Moderator Petr Schreiber's Avatar
    Join Date
    Aug 2005
    Location
    Brno - Czech Republic
    Posts
    7,128
    Rep Power
    732

    Re: Game: Current design document

    Thanks Mike,

    very good to have it all in one place.


    Petr
    Learn 3D graphics with ThinBASIC, learn TBGL!
    Windows 10 64bit - Intel Core i5-3350P @ 3.1GHz - 16 GB RAM - NVIDIA GeForce GTX 1050 Ti 4GB

  4. #4
    thinBasic MVPs kryton9's Avatar
    Join Date
    Nov 2006
    Location
    Naples, Florida & Duluth, Georgia
    Age
    67
    Posts
    3,869
    Rep Power
    404

    Re: Game: Current design document

    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.

    Acer Notebook: Win 10 Home 64 Bit, Core i7-4702MQ @ 2.2Ghz, 12 GB RAM, nVidia GTX 760M and Intel HD 4600
    Raspberry Pi 3: Raspbian OS use for Home Samba Server and Test HTTP Server

  5. #5

    Re: Game: Current design document

    Quote 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.)
    Attached Images Attached Images

  6. #6
    thinBasic MVPs kryton9's Avatar
    Join Date
    Nov 2006
    Location
    Naples, Florida & Duluth, Georgia
    Age
    67
    Posts
    3,869
    Rep Power
    404

    Re: Game: Current design document

    I am not on the coding team, but I like what I saw Mike!
    Acer Notebook: Win 10 Home 64 Bit, Core i7-4702MQ @ 2.2Ghz, 12 GB RAM, nVidia GTX 760M and Intel HD 4600
    Raspberry Pi 3: Raspbian OS use for Home Samba Server and Test HTTP Server

Similar Threads

  1. Design document, anyone?
    By Michael Hartlef in forum CM contest 2009
    Replies: 22
    Last Post: 14-10-2008, 09:04

Members who have read this thread: 0

There are no members to list at the moment.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •