First Dev Post

Published August 30, 2017 Imported
Advertisement

Thought I would post some info about the dev side of our game.

Its written in Unity3D and C#.

This is our first real project with Unity and C#, although I’ve been playing with Unity for 3 or so years on and off, but this is the first time I’ve really gone for it, so I had lots of learn, and still do.

We decided to split the game into 2 projects, the ‘Editor’ and the ‘Game’.

The Editor

Something Ate My Alien - DevBlog1 - 1

The first one is an ‘dev-editor’ for us to design the game in.

This is where Kat builds the levels, and tests out graphics etc.

This project doesn’t need to be fancy and performant, but it gives the greatest flexibility for designing our levels.

The game is made up of tiled levels, currently at 150×80 tiles.

In the editor project, each tile is a GameObject, but this obviously quickly becomes a problem with performance for a game as its just too much to process. But it makes it easy to design with at this stage.

I’ve written editor tools that place tiles and help us build the levels.

Once we have a level how we like in the editor, we then ‘build’ the tiles into a dataset, which is currently just written to a SQLite DB, but I will be removing SQLite at some point and just create my own dataset file so that we don’t need the added problems that could occur with SQLite.

As well as building the dataset, it processes all the tiles and sprites into Atlases. In the game I create Meshes that hold 8×8 tiles, so that we get good performance and less Draw Calls. As Meshes come and go out of visibility they are put to sleep and culled by the cameras, so this helps greatly.

It also creates atlases for all the other sprites, like Enemy animations, Items, and other animations.

It does some rudimentary checks on the data, to make sure we haven’t created problems in the world, like placing blocks in strange positions or on top of each other.

The Game

Something Ate My Alien - DevBlog1 - 2

Everything is prefabs and only a small amount is designed within this project.

It reads the dataset created by the editor and Instantiates all the meshes and tiles at run time.

As the player progresses through the levels, mined tiles, positions etc are all just stored back in the dataset when they ‘save’, so that it can be loaded back up again.

After doing extensive testing for performance, I found this the best way to go about trying to create such a large play area and giving the player the ability to mine anywhere.

I keep track of ‘mined’ blocks etc in a 3D array for each tile, based on the X,Y position.

One thing I had to also overcome was colliders. After testing, it looked like a major problem with performance was going to be colliders, because I just needed so many, since they could ‘mine’ a block from anywhere.

I looked into EdgeColliders and decided the best for performance was to create colliders ‘on the fly’. So the player and other important entities like ‘Enemies’ are continuously checking a 1 block square around them using the tile array, and create their own EdgeColliders within the 1 block square.

Something Ate My Alien - DevBlog1 - 3

I found this was more performant, than creating colliders all over the place for each block, or one big collider that would then need splitting and re-creating every time a block was mined.

Probably one of my biggest problems to start with and using Unity and C# was garbage. Having written many business back end systems on huge Linux machines with 4GLs, I had never had to worry about this as it wasn’t a ‘thing’.

After seeing so much written about it, I started off with trying to create ‘zero’ garbage, and that probably took a toll on my coding times, as it was hard for me to see what was creating garbage, even with the profiler. And then it was another thing to try to understand if that was actually going to cause problems or not.

I suppose now, its good, because I’m mostly garbage free with the exception of a few things like colliders and such, that I really cant do anything about because of Unity design. But hopefully the Unity devs will get around to giving us more control soon.

When coding and debugging, I normally test with VSYNC off so I can use the FPS that I display on screen all the time as an easy notification if I have some problems with performance. Currently I’m on about 500-600 fps, and that’s on a fairly old PC (8 year old CoreI7 920 @ 2.67GHz) and running at 2K (2560×1440) resolution. It used to be up at 700 or so, but I’ve since added alot.

Something Ate My Alien - DevBlog1 - 4

I know of a few things I could tweak more, that could save me performance if/when I start getting too low, but currently it does not warrent the time as I have no foreseeable problems.

I do a lot of pooling of GameObjects, so that I don’t have to create and destroy objects, and that has helped a lot with performance. Everything I need gets created on load, and then reused if/when they become redundant.

I’ve not really used any 3rd party assets, in fact the only one currently is the water that I use. But, I’m going to write my own version of that at some point to make it better and more performant. I had a bad performance problem with it to start with, but I hacked it about a bit to get more out of it, and now it behaves quite well.

I generally don’t like 3rd party products, as I normally have more problems with 3rd party code than if I just code it myself.

One area I thought I was going to have problems with was lighting. Initially Unity projects have lights limited to 4 per object, which just was not working for me. I was worried about increasing this, but with all the tiles grouped up into joint meshes, my draw calls were low enough that it didn’t seem to cause any problems with upping the number to 20. Of course, it has an effect, but it was one I could get away with, at least FPS wise.

Since our 2D animations are fairly basic, and I wanted full control of it, I wrote my own class to do our animations. Just a simple flip through the atlases that are created from the editor project. Animations are probably the area I might look into for any performance gains, as they are up on the top of the list in the profiler, but I’m not sure there is much I can do, as all they are doing at the moment is just flipping UVs.

Unity 2017

We’re currently on version 5.6.1f1 of Unity, and I will be upgrading to the new 2017.1 soon, as I think there are some improvements to the 2D system that I could make use of. Over the last year I’ve been trying to keep up with regular updates, so that I don’t get into a situation where I need to take a long time out to upgrade. I’ve had little to no problems upgrading so far, so I don’t think it will be much, if any work.

We will initially be releasing on Windows PC. We have quickly looked into Mac & Linux releases since Unity supports this easily. However, we don’t want to promise Mac & Linux to be released initially just in case there are any problems which could delay us. But we currently don’t foresee any problems here.

We’ve been working on this now since Nov 2016, and back then we thought we would be finished by now, but as usual, IT projects just keep going. I think we need another 6 months now, until we will be finished, but we have just release a Dev Trailer video of the game, and a commentary, and you can find them here.

Next week after spending time doing all this video editing and vlogging, I will be spending time on implementing the bigger enemy that you see at the end of the Dev Trailer, as currently its not really in the game. Then its on to more work on the UI and interacting with the pirate.

If you have any questions, ideas or thoughts, then please contact us here as we would love to hear from you.

 

View the full article

 

 
Previous Entry Meet The Enemies
Next Entry Game Art 1
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement