An action/adventure stealth game mixed with parkour being developed for PC & PlayStation Certified Devices (including the PlayStation Vita) via PlayStation Mobile.
The first part of the sixth progress update.
Posted by KamRandle on Nov 20th, 2013
Hello! Welcome to the first part of Progress Update 6. I've made this the first part because I have to go through and re-write my combat code as I was experiencing weird bugs, so I didn't want to keep you guys waiting as it has already been a long time since the last update. I am working hard to get it up and running so the second part of this update, which is about combat, will be coming soon! :) Since Progress Update 5, I've implemented many new features as well as made the code more efficient. I've still got ways to go, but it seems to be coming along fine.
In Progress Update 5, I mentioned that I was thinking about creating my own scene/level format, and as you read in my last post, I have decided that doing so would be the right way to go, so I made it happen! I even created an editor. The editor I created makes creating levels so easy, I am happy I decided to do it. Since the last post about the editor, I've added many new zones and fixed some bugs as well. This makes everything much easier. Rather than defining zones and markers programmatically, I can setup everything visually. There are many features that need to be added to the editor to make it complete, but what I currently have does the trick for now. I've updated the format as well. The format now contains mesh data along with zone and marker data.
Another new feature that I have added to my engine is an awesome save system. How it works is pretty cool. Creating a new type of save is so easy:
1. Create a struct or class derived from NXSave and attach the NXSaveElement attribute to anything that needs to be saved:
2. Create an instance of that save anywhere and call the save method:
Boom! The file is then saved. Reading the save is even easier than that:
The save system uses System.Reflections to check every property/field in the class/struct that is derived from NXSave, check if the property/field has the NXSaveElement attribute attached to it, and if so, get the value of the property/field and write it to the save file. How the data is written totally depends on the structure of the class/struct. And because of that, reading the data back works in the same way. When we save our "PlayerSave" struct above, the save system writes the data based on the order of the fields and properties. So because the Health float is first, Health will be the first thing written to the file, while Position will be second, and Rotation will be last. When we read the save back, once again because of how the struct is setup, it will read the data based on the order of the fields and properties. So Health will be read first, Position second, and Rotation last. Because my system is setup like this, I don't have to write any code that writes and reads the save data. This system seems to be working flawlessly so far.
I've redesigned the loading screen:
I have optimized the game a lot since Progress Update 5. I've also rewritten many things.
One of the reasons I was using so much managed memory was that I had 3 copies of the level's base mesh's vertices: one vertex array from when the level was loaded, another when I loaded those vertices into a vertex buffer, and another after creating a static mesh from the mesh vertices. I now only have two: the vertex buffer and static mesh. I've added a new feature to my editor to help out with this. I can choose whether or not a model's mesh data is deleted after it is loaded into the vertex buffer and if the game should create a static mesh from the model. Progress Update 6 | Part 2: Combat, will be coming soon. Thanks! :)