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!

The 10 Commandments of Android Development

In developing Android, I've found a bunch of common mistakes that people often make. I've made more than one of these myself. While I can, and probably will talk about how to avoid each of these at some point in time, I wanted to at least point out some of the common pitfalls that people often encounter when beginning Android development.

 

 The 10 Commandments of Android Development

 

1. Thou Shalt Have no other SDK Version Targeted, except for the latest released!

2. Thou Shalt Not make unto thee any Network Connection on the Main Thread!

3. Thou Shalt Not make unto thee any Toast without .show()ing it to the world!

4. Thou Thou shalt remember thy variables, to recycle them. Neither thy Bitmaps, nor thy TypedArrays, nor thy Parcels, nor even a reference to thy MotionEvents outside of thine functions shall escape without being .recycle()d!

5. Thou Shalt never create an anonymous inner OnSharedPreferenceChangeListener class, so that thy OnSharedPreferenceChangeListener's days may be long, and not be Garbage Collected. 

6. Thou Shalt Not have any local variables inside a onDraw statement!

7. Thou shalt Not programmatically define a View, but instead shall define it via XML code!

8. Thou Shalt Not ignore the convertView of an ArrayAdapter, but shall always use it to reduce thy memory footprint!

9. Thou Shalt not forget to add <use-preferences> when thou addest new features requiring new permissions.

10. Thou Shalt Not use absolute positions, nor use Scaled Pixels incorrectly, but rather use Density Independent Pixels for thy Views, and Scaled Pixels for thy fonts!.