After working on a number of titles for various clients, I've decided to launch into releasing my own game. The current working title is Maze Rover, and I've just set up a page here to show how the prototype is developing and get some feedback on the gameplay.
There is more info about what I'm trying to achieve on the other page, but I thought I'd talk a little here about what new and cool things I've learnt in the process.
Super fast serialization/deserialization
Maze rover is, as the title suggests, a maze game. Each level is a different maze. Alongside my Unity project, I've also had to make a level editor in order to draw the mazes. For this, I used pure C#, WPF, nothing to do with Unity.
Here is a screenshot of the, incredibly ugly, level edit in action.
I created a C# library, that both the level editor and the game would use, that contained my maze classes. Square, Bonus, Dimensions etc. The next question is how to get the info out of the editor and into the game.
What I'm talking about here is serialization/deserialization. I've already done a post on my final solution, protobuf-net, but it's interesting to document what extra technology I had to learn to get this to work properly.
The max size of my levels at the moment is 48 x 32 squares, or 1536 square. The way I've set it up, there is a maze container with a 2 dimensional array containing all the squares. My initial use of XML serialization wasn't very promising, with it taking hundreds of ms to deserialize in the game. With protobuf I think I'm averaging 10-15ms. Great improvement.
Dynamic Mesh Creation
After reading in the maze for a particular level, the next step is to create the maze. I initially started with creating pre-fabs of each type of 'square' and instantiating them one after another. But, as I suspected and is pretty obvious, this is not very performance friendly. Even if they are just simple squares, having 1000+ objects in a scene is just scary.
So, meshes. I didn't know much are creating meshes before I started this. But I looked at a few examples and realised that with a bit of maths, they are not too hard to create.
Here is a screenshot of the maze mesh.
Pretty simple, but dramatically more efficient that previously. Although I create the meshes using squares, they only contain the faces I need and each face is UV mapped as appropriate. In the pic above that is not shadows making the sides seem darker than the tops, it's just a darker texture. In fact, I'm not using any lights at all at the moment.
For an in-game HUD solution I was initially going to use GUISpriteUI, which was created some time ago by Prime31, but when I went to check on progress he had released a whole new solution, UIToolkit.
Users of GUISpriteUI will understand how much better the new system is. No more mucking around with UvRects and ruining everything when your atlas is changed. UIToolkit uses TexturePackerGUI to do the work for you and, most importantly, now supports fonts.
So, long story short, 1 draw call now does all my HUD. In the pic below there are 13 HUD elements (not counting the FPS counter) that are all done in the one call. FYI - Crappy graphics are placeholder, don't freak out ;-)
If you've previously used GUISpriteUI and got frustrated by certain aspect, I highly recommend checking out UIToolkit. Things are so much easier and bug fixes and improvements are being added regularly. It's (kinda) open source, with Prime31 giving out GIT access to certain posters on Unity forums.
I will hopefully get some good feedback from releasing this prototype and it will all go in to making the game even better. Once I get the theme nailed down, I'll be looking around for artists to create the assets I need.
Hopefully we're looking at a release in the next few months.