Scene Development

Today I'm finally sitting down, after some long procrastination and a lot of lack of time, and also having to get the server back up after it went down, to get to work on the Scene class and file structure for the engine.

Scenes are but one parts of four file formats that the editor uses to build a final binary file that the engine will use. The four file types work together and combine all the the data and resources and as such are intermediary files.

The different file types are:

.TOF = Troglodyte Object File, used for storing Data specifically for Objects. This file format is specific to any one type of sprite object that can be used in the system. This type of isolation allows objects to easily be used across different scenes in any level or project. .TOF files can also hold purely audible data and can act as sound effects or music ques around a scene.

.TSF = Troglodyte Scene File, holds the data for a specific scene. Here is where game scripting, keeping track of objects, and object interaction begin to take place. This file knows how many objects are in a scene, keeps track of where the object data is stored on disk, and is responsible for resolving script and and object data at project compile time. Scenes can be a platformer level, and scripted animation scene, or even a menu, for example. Scenes are not limited to these types.

.TLF = Troglodyte Level File, this file is somewhat redundant in that it serves the same type of functionality for scenes that the scenes perform for the objects. Each level is limited to 25 scenes simply for simplicity, but does not have to make use of the full 25. If a developer feels that 25 scenes aren't enough, it's up to them to structure their data so that it works, or they can edit the source for the engine and recompile to suite their needs as long as they follow the EULA set forth.

.TPF = Troglodyte Project File, this is the all encompassing file that organizes all the other files types into a working structure to be used in the engine.

Once compiled these create a .TBF = Troglodyte Binary File. This file has all the video, audio, and script resources compiled into one file per level. If a project is named Quest, the files would be saved as Quest_L1.TBF, Quest_L2.TBF, and so on. L1 files will always be the starting point of any game. The editor will spit out compressed files into a structure such as specified directory/Quest/Bin

After a brief introduction into the file types, now onto the design for the .TSF files and classes.

All of the serialization work for the files are handled by a class called the hidden management layer. The Game State Hidden Management Layer is responsible for sending a message to start or stop a Scene and handles any errors that may arise during Scene and Level initialization and clean up. So, what this means for our Scene class, is that we can keep it fairly simple.

Things the scene class will need:

1. Know the number of Objects it has.
2. Know the number of Scripts the scene has.
3. Know which Script corresponds to which Object.
4. Know when an Object should be following a specific script.
5. Know when it needs to initialize and load data.
6. Know when scene execution should begin.
7. Be able to update the scene data each frame.
8. Know when to stop scene execution and updates.
9. Know when to clean up and release memory back to the heap.
10. Access to Objects interfaces to be to manipulate Objects.
11. The ability to add and remove Objects from the Scene at runtime.
12. A Scene Name. (Not to be Confused with state Name).
13. A unique numeric identifier for the Scene in order for the Level to keep track of it. This should range from 1 to 25. (Not to be confused with State_ID, which is used by the GS_HML.)
14. Area size. The size for one block on the area grid is 32X32 pixels. Area sizes of grids use multiples of 2 starting with 8X8 and the largest Area being 1024X1024. Which equates to up to a gig of background data being available in memory at any given time.

All Grid Sizes: 8X8, 16X16, 32X32, 64X64, 128X128, 256X256, 512X512, 1024X1024

15.Scene Orientation data. If the developer wants to use a platform type view for a scene, or if they wish to use an isometric or top down view, it must be specified using the Scene_Orientation variable. This is one of the variables that must be selected when creating a new scene.

16. Layers. Regardless of camera direction and placement, developers can make use of up to 32 layers. Depending upon the orientation of the camera however, the layers can either be used in only the z or y planes. Objects must be on the same layer in order for them to interact with one another, however, using scripts, changing an objects layer during game execution can be performed at run time. This can allow Objects to move from a background layer into the fore-front for example, or vice versa.



Things like pausing and swapping scenes and levels is once again handled by the Hidden Management Layer.

*Note: When adding Objects to a scene, a unique identifier for faster parsing of objects is going to be needed. This should be a numeric value.
No limit of Objects is implemented in the design per scene. This approach will require an increment to the identifier to made for each object added to each scene. This approach means however that if an object is removed from a scene, that the numeric value added to that object is no longer valid in that project.

For example, I add an Object called Apple. At the time of adding Apple to the scene it is assigned the Scene_ID of 25. I then remove apple from the scene because I decide that I want to use a different type of Object in its place. If I were to simply edit the Apple in the Object editor and update it in the scene, then it would retain the same Scene_ID. However, since I deleted the object, even if I later decide to add that same object back into the scene, it will be assigned a new Scene_ID at that time. 25 will become lost from the ID pool, but this shouldn't really matter to the developer as Scene_IDs are used internally simply for data management.


17. Error Messaging. When the GS HML loads or saves a scene any errors that may arise should be displayed to the developer in order for the developer to choose a course of action. Error logs should be generated in the Project folder for a project. The folder should be Error Logs and
inside there should be logs for problems with the overall project and then sub folders for each additional file format. This should handle:

17.A) Object Creation Errors - (Loading data from disk.)

Non-Critical Errors - The developer can be prompted to skip the object and continue Loading the Scene.
17.A.1) Resource Not Found. (A Texture, Sound File, or Script Associated with the Object can not be located.)
17.A.2) Corrupted Object File. ( The file has been corrupt and cannot be loaded.)
17.A.3) Missing Object File. ( The Specified Object File Cannot Be found.)

Critical Errors - The Scene will not be able to continue to be loaded.
17.A.4) Memory Out of Bounds (Buffer Overflow - Causes system to be corrupt. Engine/Editor must be restarted.)- This should generate
an error report pinpointing the Object that caused the error so that the developer can look at the Object and remove it from the scene if necessary.

17.B) Scene Creation Errors - (Loading data from disk.)

Critical Errors- The Scene will not be able to continue to load.
17.B.1) Corrupted Scene File. (The file has been corrupted and cannot be loaded.)
17.B.2) Memory Out of Bounds (Buffer Overflow - Causes system to be corrupt. Engine/Editor must be restarted.)-An error report needs to
be generated to show the developer which scene caused the error so that it can be removed from the project.
17.B.3) Mismatched File Type. ( The file attempting to be loaded does not have the .TSF file extension.)
17.B.4) Old file version.( The file being loaded is built with a previous version of the editor and the file format is out of date.) - Adding
support for some legacy file formats and being able to update them to the new format once loaded is a possible work around for this issue. This could potentially be a non-critical prompt message.)

17.C) Scene Serialization Errors - (Saving data to disk.)

Save Failure - If any of these errors occur the program will simply exit the saving method.
17.C.1) Scene File in Use. ( The file is an open stream being used else where.)
17.C.2) Minimum Data requirements not set. ( Some how the user by passed filling out the appropriate minimum data needed to create
a scene, therefore the file is not valid.)
17.C.3) Memory Corruption. ( The memory attempting to be read for serialization is corrupt.)

Save Prompt - If any of these errors occur the developer is prompted for action.
17.C.4) File already exists. ( User is prompted for to overwrite file.)

17. Followup Note - It will also be beneficial to allow the developer to set a flag that enables all non-critical errors to be ignored during in editor
testing. These messages should still be logged so the developer can fix them, but prompting the developer should be removed from the
process if that flag is set.

18. Scenes should inherit from the inheritance line of the class GAMESTATE in order to actually make use of the messages from the GS HML.