|
So, as I continue working on learning various web languages and working on continuing to learn Qt, I begin to notice a continuing trend of getting away from game development. This is something that I have to keep in mind in the future, but for now, current paths must be continued until the current journeys come to an end.
So, Ajax, Mysql, and php are the newest members to the arsenal of development tools in my tool box. I'm having quite a bit of fun getting to know them, working on the decipherone website. I'm also getting to know web standards in the process, which has been interesting. Although I've been using websites, I never really noticed how much the development process has changed for them over the last decade. It just goes to show my lack of education in the area prior to the last few months that I've been preparing to tackle the GoG tournament connection tool and building the community website to promote Troglodyte and indie games in general.
While it's interesting and practical , and I could see myself doing it for a living, I just don't have the time to continue to do web development, work on a game engine, design games, make games, work a full time job, and fit the other hats in my life on my head. As stated currently, I've had to set aside the game development aspect, and it's something that I really want to get back to. So as I finally come to the forks in the road, I need to get back to the initial cause.
It looks like April will be the month where I actually get time to port the current code base of the engine over to using Qt. As I do that I'm thinking that I am going to need to finish the game state management that still isn't complete at this time, before starting to build the next edition of Scribe, the editor. By that time the official release of Qt creator should be out as well, which should be awesome. Qt will also be releasing version 4.5 in march, which will add a LGPL license, which should help with marketability for Troglodyte.
At this point in time I'd like to say this. The main reason of this game engine and editing suite is to provide a tool for myself and fellow companions to make games, do it well , and fast. I'm choosing to release it to the public after an agreed upon time in between myself and the guys of Phyersoft. In doing so, my hope is not to become rich from the endeavor, although if that happens it would be welcomed. Instead, it's my hope to provide a very affordable tool that is easy enough for a complete newb to use, while still having enough power to entice seasoned developers.
By having it be open source as well, I'm hoping that it give those who are interested in coding a good place to begin to learn about programming games. That is also the purpose of the website. Also, I hope to grow as a programmer because for the most part I'm self taught and I'd love for those who would be interested in looking at the code base to be able to offer and make suggestions.
In addition, I'd love to see people become passionate about the project and for it to grow into a robust development tool owned by the global community. Only time will tell if these hopes and dreams will be attained, but it should be an interesting journey to get to cultivation of the ideas.
Yay! Server is back online and so am I, with a dedicated connection. This will be a good thing heading into the new year and should allow for things to continue to move forward. I was thinking of doing a year end review but I'm not sure if it'd really be all that beneficial for anyone. I mean, I reflect enough as it is and it seems like everyone is talking about year end wrap ups or recaps and, well good for them.
I've started work back on Barricade currently. I'm working to finish some of the game mechanics that I did not finish during work on the proto-type. I worked on it a couple of days last week and some decent headway.
I switched back to this for two reasons. One, I decided to port my existing code base over to Qt in order to get things independent of a specific OS. This will allow for the editor to be cross platform as well as the engine itself and will hopefully open up a wider user base.
I've never used to Qt before, but I'm getting the supposed manual and am going to start learning sometime in the next month. In the meantime, I decided to work on the Barricade demo some more. The second reason being, I have not been able to make a solid decision on the next iteration of the engines state management. I've gone through at least 3 redesigns this year, with the core system staying some what the same, but the implementations being very different. I need to buckle down and just make a decision for this as it's been holding back progress from other areas for quite sometime now.
On a more personal note, I usually find it hard to focus around this time of year, and this year is no exception. It's almost tormenting to simply want to put everything off until the new year and just go out and live it up with everyone, but there's times and places for those things, not every day.
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.
|
|
