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.
Engine Update
- New Scene Format
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.
- Save System
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:
{
[NXSaveElement]
public float Health { get; set; }
[NXSaveElement]
public Vector3 Position { get; set; }
[NXSaveElement]
public Vector3 Rotation { get; set; }
public PlayerSave(){}
public PlayerSave(NXPlayer player)
{
Health = player.Health;
Position = player.Position;
Rotation = player.Rotation;
}
}
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.
Game Update
- New Loading Screen
I've redesigned the loading screen:
- Optimization
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! :)
Kam, have you tried deleting the mesh data after putting it into a vertex buffer? I tried and somehow that also cleared the vertexbuffer, even though the vbuffer had already been setup and filled with the data
Hey! Yep, that is currently what I am doing and it seems to be working fine. I just realized that this is an older version of what was supposed to be posted for part one, lol. I was in a rush and pasted the wrong HTML code that I had saved into the article. -_- lolol :D