Dev Blog- Sea Trading Game- Threading the world creation process

For some time, my game has taken about 10 seconds to load, and it has been left as a blank screen while that was happening. I’ve long wanted to do something about that, and this week, I was able to start tackling the problem.

There were a few different ways that I thought to try to make this happen. The first that I tried was using the Asynchronous loading for scene management. This works great if you have a large number of objects that needed to be loaded, that each object doesn’t take a long time to load. That didn’t mix well with my game’s system, where the loading time essentially happens with one slow object being created.

The next system I tried was using a coroutine. This didn’t work, as the UI thread was still locked. There was a somewhat related option left, although it proved to be quite difficult in the end. The solution was to thread the world creation process.

I should note that the entire process is a single thread. This made a few things easier. The largest difficulty was that Unity’s random number generator only supports the creation of random numbers on the UI thread. I managed to work around this by using the System.Random engine, but it took quite a bit of work to get it all to work properly.

Having this system in place is somewhat meaningless if I’m not giving the player an idea of what the system is actually doing. In order to make that happen, I added debug code to my logs to start to test the system before I start to work on the UI. While so doing, I effectively profiled the world creation process, and I noticed that one particular part was taking 90% of the time. I was able to speed up this process considerably, and now the time takes only 3 seconds, at least on my computer.

This week I’m planning on working on the UI part of the loading system. I am hoping to also get a better game over screen in place, which I was also able to start working on in this week.

If you haven’t yet, feel free to like me on Facebook, join my Google Group, subscribe to my Sub Reddit, or follow me on Twitter, where you are likely to get frequent updates!  

Ludum Dare 37- “Jewel Defender” Post Mordem

I recently participated in my first Ludum Dare, making the game “Jewel Defender” over a 48 hour period (I spent about 10 hours of actual work on it). In this article I want to document the process of making it, I will probably do a separate article on what I plan to do post-Ludum Dare as a result of feedback. You can download it at the link on the Ludum Dare page.

Jewel Defender is a tower defense style game, but purely using melee traps. I had the time to include two traps, one that is a swinging sword, the other a block drop.

The theme was “One Room”. I went in to this Ludum Dare either wanting to do a prototype of a game I had previously had in mind, or a prototype of something that I could use for my Sea Trading Game that I’ve been working on for some time. I decided to try out an idea that I had long had of making a game where you set traps to defend a few high value artifacts, namely gems.

Friday I was able to spend an hour on the project, which was enough for me to test navigation meshes. I had not previously done any work with the Unity AI system, and learned a lot in that process. Early versions were problematic, as can be seen below.

The major obstacle I faced was getting collisions to work correctly. I often had traps that wouldn’t trigger, or objects wouldn’t be placed that were supposed to, as can be seen below. I finally found that certain objects needed RigidBodies, while others didn’t need them. With the right combinations of rigidbodies, I was able to make everything work right!

I slept Saturday evening with a single trap, decent looking graphics, but objects still weren’t being placed as they should be.

My time on Sunday was quite limited, but I spent most of it just getting my traps to be placed right. I made an actual score, and got the building cost of making traps set. I ran in to what at first appeared to be a Unity bug, but ended up being me accidentally placing an animator on my walls, which moved my collider for some reason!

I also added the ability to destroy traps, otherwise one could simply set up a massive wall of traps and keep anything from practically winning. I threw in a few sound effects, and overall was happy with the game, although I really wanted to have more traps set up, along with more robots trying to take the gems.

I wasn’t able to spend as much time on this as I would have liked, because I was sick for the entire duration of the event. Not really sick, but enough that I wasn’t at 100%, and had to take frequent brakes. Sunday evening I had finally worked out the bugs in the simple version, and initially submitted to Ludum Dare with only a single trap type, but 4 hours to spare. I slept for a few hours, and then realized I still had motivation to do one more trap type, which ended up being the swinging sword.

I can tell from my play through of the game that it isn’t very balanced, it is very difficult early on, and surprisingly easy later on, if you can make it that far. If I had more time, I would have improved that balance some.

What I would really like to know is if I should persue this as a game, particularly in comparison with my much further advanced Sea Trading Game that I have been working on for the entire year. What do you think? Leave a comment to let me know!

If you haven’t yet, feel free to like me on Facebook, join my Google Group, subscribe to my Sub Reddit, or follow me on Twitter, where you are likely to get frequent updates!