Having some fun with retro and government contracting

I’ve worked for a number of companies over the years as a programmer. My time at government contractor was particularly interesting. It was like working in a different parallel universe where everything looked the same but was strange. Unlike the commercial sector, we didn’t worry much about deadlines or being first to market with an idea. Our struggles revolved around protecting the funding for our contracts. We had fought against bad Project Managers that would mismanage team resources. We fought to keep bad programmers from ruining code. At the end of the day, there was the threat of the government swooping in to take away our funding. No funding meant no job.

We joked that all of this sounded like a old video game. Something like Missile Command for the Atari 2600. The evils of the world trying to destroy our project while the lowly employee fought to defend it.

It sounded like a good idea but my skills as a video game developer were lacking and Unity hadn’t become the giant it is today for indies. Fast forward 10+ years and I decided why not try to see what I can do in a week. I busted out my notebook and sketched a rough idea of what I envisioned.

 Design notes for game. This was my first time really trying to make pixel art so I tried to keep it simple. I also kept track of issue discovered during play testing.
Design notes for game. This was my first time really trying to make pixel art so I tried to keep it simple. I also kept track of issue discovered during play testing.

I faced some interested challenges along the way but after a week, I had something that was pretty fun.

 Final screenshot of Project Defender. Bad Programmers and the Gov weren't originally in the game but I added them to solve issues that came up during play testing.
Final screenshot of Project Defender. Bad Programmers and the Gov weren’t originally in the game but I added them to solve issues that came up during play testing.

I really enjoyed taking a break from working on big projects to make this game. It was very helpful showing me some holes in my game design knowledge. Give the game a try and let me know what you think.

https://itch.io/embed/119937

Confusion with Unity Social API

I’ve been working on integrating features like a leaderboard and achievements into Wordsum. Instead of building my own systems or using third party services, I decided to use native services like Game Center for iOS and Google Play Services for Android. Unity provides a nice abstraction for these layers in the form of the Social (http://docs.unity3d.com/ScriptReference/Social.html) API. The main purpose of this post isn’t for me to talk about how great the Social API is but to share a misunderstanding I had with it’s implementation.

After integrating Game Center into my game, I noticed some weird behavior. When I suspended the game and resumed on iOS the game would go back to the main menu. After much debugging I realized two things were happening.

Game Center re-authenticates on resume

If the users suspends your game and then loads the game from the multitasking tray, Game Center re-authenticates. This would be find if the following wasn’t true.

Callback provided when authenticating is resused

When you authenticate with Game Center you call the following:

Social.localUser.Authenticate(success => {
 //Doing some stuff
 Application.LoadLevel("MainMenu");
});

You provide a callback you want to invoke after the user has authenticates. I’m my case, I was attempting to load the Main Menu scene. The idea was to wait until the player authenticated or did not to load the main menu. This didn’t work so when when the player resumed their game, authenticated automatically and loaded the main menu. Once I changed this my problem disappeared.

Summary

My writeup isn’t meant to discourage you from using the Social API. It provides a great abstracted layer to work with. Unfortunately for me, I assumed that the callback I provided was going to be used once and then discarded. In my opinion, using C# Delegates would have been a clearer choice to store an action to run every time a player authenticates.

Use Texture Atlases to Improve Performance

Performance is always on the top of every game developers Todo list. It can be the make or break for how player’s respond to your game. Wordsum was a mobile game so that meant I had less power to work with if I wanted to reach the mass market.

Lowering draw calls are a simple way to improve the performance of your game. It’s simple, if the game performs less draw calls, it has less to do. So your first question might be, “How do I know how many draw calls my game is making”. Unity provides a great tool for this called the Rendering Statistics Window. The best part is it’s available in the free version of Unity. To open the window, click the tab in the editor viewport.

 Click the Stats tab/button to show the Rendering Statistics Window
Click the Stats tab/button to show the Rendering Statistics Window

When you run your game you will get live statistics. The thing we are interested in is the Set Pass Call number.

 The Draw Call number is highlighted in red. Fyi, SetPass calls is Draw Calls.
The Draw Call number is highlighted in red. Fyi, SetPass calls is Draw Calls.

Getting this number as low as possible helps save of CPU/GPU cycles. We will be using Texture Atlases to accomplish this.

There are some good paid tools out there to help us create the Texture Atlas. One of these is the highly regarded 2D Toolkit. Since I had a tight budget I ended up going with Simple Sprite Packer which gets the job done.

First thing you will need to do is import the Simple Sprite Packer package into your project. This adds a new context menu to the Unity editor. Find a place where you want to create your Atlas. Right (or command click for mac users) and select  Create -> Sprite Packer.

 Select Sprite Packer from the menu
Select Sprite Packer from the menu

Name it something appropriate and save. This will create two objects in your folder. The first is the Simple Sprite Packer object you will use to create the Atlas. The second is the image file that will be the actual Atlas.

 On the left is the Sprite Packer object. On the right is the Texture Atlas
On the left is the Sprite Packer object. On the right is the Texture Atlas

Select the Sprite Packer object. The inspector will display the options you have for creating the Atlas. You can leave most of these unchanged for now and start creating your Atlas. You can either drag your images one by one into the green area or for speed use the Sprite Packer -> Drag and Drop Window located in the Unity toolbar.

Note: Make sure the sprites you are adding to the atlas are uncompressed or Simple Sprite Packer will complain.

Once you have added all your sprites, select Rebuild Atlas. You have now created a Texture Atlas. Congrats! The only thing left is to swap out references to the individual sprites to your Atlas. Once your done, rerun your game and you should see a big drop in draw calls and hopefully improved FPS. 

Circle Colliders For Better 2D Game Touch Controlls

Making Wordsum was a great learning experience for me. I had never done a 2D game before and found the challenges much different than working in 3D. One of the most important issues I ran into was the feel of the game in regards to selecting the letter blocks. At first, I only supported tapping each letter to create a word. I found through much play testing that people expected to be able to slide their finger to select multiple letters.

It was easy enough to add slide selection to the game but something was not right. People were having a really hard time selecting letter blocks diagonally. The problem ended up being my use of colliders. Each letter block had a 2D Box Collider which handled both collision with other letter blocks and the player’s touch input.

 The green boxes are the Box Colliders. Notice how there is no room in between each collider. 
The green boxes are the Box Colliders. Notice how there is no room in between each collider. 

The problem with this approach is when the player tries to slide their finger in between two letter blocks to make a diagonally selection. For example, in the picture above this would be word C-A-T. Most of the time, the player would end up selecting C-L-A or C-T-A instead of what they wanted. This was due to the box colliders being so close together. Player’s got easily frustrated during play sessions and only used tap selection instead.

I was able to fix this by doing two things. The first was using a collider for collision detection between letter blocks and another collider for the player’s touch input. The second thing was creating a child Game Object of the letter block prefab and using a Circle Collider instead of the 2D Box Collider. This allowed the player’s finger to slide in between two letter blocks much easier.

 The Circle Colliders allow for more space in between letter blocks
The Circle Colliders allow for more space in between letter blocks

The results were very positive. After more play testing, there was less irritation with selecting letters. Players said the game “felt” better. The best part was this fix didn’t take long to implement. Moral of the story, don’t use 2D Box Colliders for everything. A simple concept which seems so obvious to me now.

 

Unity GUI Woes

Todays challenge isn’t some crazy null pointer bug but the ever elusive responsive GUI. When you thought that everything is cool, that brand new GUI element you tested over and over just doesn’t work on one device. I went to test on iPhone 4s and this is what I got.

Don’t get me wrong I do love Unity’s new GUI system much more then the previous one. I just feel like I spend more time on my GUI then my actual game…