Some thoughts about designing for VR

As the Leap Motion 3DJam is coming to an end, I’m going to take a short break to reflect on the things I learned while making In Space, No One Can Hear You Dance. Josh Rose from Robot Sea Monster Games said in a recent talk that VR is still in its infancy. Like the early days of film making, game developers need to experiment to find what works and what doesn’t. These discoveries should be shared so we can all grow together and learn. This blog post is my attempt to follow that advice.

Input Disconnects

Current Oculus Rift HMDs only provides the hardware to put players inside a 3D world. This will change with the up coming release of the consumer version of Oculus Rift. Most of the content for the Oculus has been more of an experience or tech demo rather than a game. This is mostly because games at their core require some sort of player interaction. Leap Motion and Intel RealSense provides a way to reach into a VR world. Standard controllers are another option that’s more familiar to gamers. What ever your input method is, you want to avoid doing things that break the players immersion. Once it becomes to difficult to provide basic inputs, player will get frustrated and probably turn your game off.

Since I’ve been working with Leap Motion, let’s focus on that. Grabbing things or touching physical objects in 3D using Leap feels odd because there is no tactical feedback. Simple interactions can be very challenging and just not fun. For example, the video below shows a prototype I was working on. You can see the player (me in this case) has difficultly with pinching and rotating the object. I’m not new to using the Leap by this point, other people I had try this prototype who never used Leap found interacting this way to be impossible. I could lock the object to the players hand when pinching is detected but it creates an odd felling because for a stationary object like this, the players hand will move less in game then in real life.

For In Space, No One Can Hear You Dance, I decided to have the player follow instructions with their hands, swiping  up/down/left/right, based on a screen inside the VR world. The result felt more natural because the interaction was a 1 to 1 match. The game did nothing different then what the player expected.

Simple Is Fun In VR

Most game developers love games (hopefully all but I have met some that don’t play games O.o). When we dream up games, they are often pie in the sky ideas with deep systems and huge scope. Making complex games that are fun in VR is actually pretty hard. Gameplay mechanic’s in conventional games are strange and can sometimes make you sick. For the near future, creating simple games (but complete, not just tech demos) is enough for players to enjoy their time in VR. If indies want a chance to make a meaningful impact in this space, we need to think small but polished. People who have never experienced VR find simple games to be fun and exciting. VR has transported us to time when the concept of just playing a video game was an amazing thing. Once we get a solid base of usable VR game mechanics, we can build off of that just like games have in the past. It’s hard to have the Call of Duty of VR when we haven’t had the Pong of VR.

FPS is very important

Low frame rate in any video game is annoying and can make a game unplayable. Low frame rate in VR game makes you want to throw up and never return. Current VR technology requires the screen to be drawn twice, once for each eye. To avoid the stutter that causes nausea, your game needs to run around 90 frames per second or more at all times. Any drop in fps below that can be enough to make a player sick. Once they get sick, that’s it for a few hours or the entire day. 

Since we are drawing the screen twice, the requirement of 90 fps becomes 180 fps when not running in VR mode. Getting this sort of frame rate can be hard if your game has complex scenes with realistic graphics. There are a number of ways to get better performance in your game but the three items below are what I found easiest to implement and gave me the biggest improvements.


Use baked lighting instead of real time lighting. This is not an ideal solution but it does provide a significant amount of processing relief. Many game engines provide great tools for baking your lights without much effort. If this is something your game can’t live without then you may need to hold off until technology improves. For right now, we are limited by the hardware we have. It’s a lot like the early days of video games where the limitations of the available technology could drastically alter the design of a game.


Your 3D models should be as simple as possible. If you can’t get something to look just right with a lower poly count then you need to think about that objects importance in your game. Can you remove that object or use something else in it’s place to get the point across.


Be careful with the code that makes up the logic for your game. In Unity, it’s easy to forget that invoking GetComponent(), FindObjectByType() and Instantiate() is very slow. Use simple solutions rather than complex ones to make it easier to tune and troubleshoot. Don’t be sloppy and program smart. I know this tip may be sort of a no brainier but I found that taking a critical eye to my game code helped a lot with my overall performance. I had gotten use to being able to make mistakes and not paying so dearly for them.

VR Space Dancing

Virtual reality has intrigued me since Oculus Rift made it a reality for general consumers. After trying it I wanted to see what I could do with the tech. When the Leap Motion 3D Jam was announced I thought it was a great chance. The result of my efforts is my newest VR game “In space, no one can hear you dance”. The goal of In Space is simple, you are on a spaceship and you are trying to get home to earth. Your warp drive is drained of power and dancing is the only way to refuel it. I had gone through a lot of different ideas to get to this one and I had my doubts about how I was progressing 

I decided to bring my game to the GDAT Meetup in San Francisco to see what people thought. The results was great. I got to see people try my game out and have fun. 

I was really struggling before coming to the meetup. I didn’t really know if what I had was fun or if the idea was even worth pursuing. Seeing people I didn’t know having a blast playing my early prototype gave me a renewed sense of direction.

The feedback I got helped me figure out what I should focus next. I’m very fortunate to live in a city that has these events available to indie developers. Everyone should take the time to attend events like this and let their local indie devs know they are wanted.

Wordsum Postmortem – The 10 year journey of a solo game developer

Working on Wordsum was a personal test for me. I had been attempting to make games for around 10 years. Most of my time was spent learning the basics, building prototypes and completing lots of tutorials. All of this effort amounted in 0 games completed. My projects were either too ambitious or required a knowledge I didn’t have. I continued to pursue my passion at night while working as a software developer during the day. It wasn’t until I ported my most complete game called Flax to Unity that I felt like I had a chance. It also didn’t hurt that I had quit my full time job to take a much needed break. From a tiny sketch in a note book, Wordsum was born.

What went right

1. Play testing from prototype

One thing web development had taught me was the sooner you involve your users, the closer your final product will be to a user’s expectations. I found games to be no different. From the moment I had something that resembled playable, I installed it on my phone and asked friends to try it. Play sessions were informal and I asked simple questions like “how do the controls feel?” and “what do think about the concept?”. I observed their body language and any audible clues to what they were feeling. It’s pretty easy to spot when someone is or isn’t having fun.

 Very early prototype of Wordsum
Very early prototype of Wordsum

The feedback helped me uncover problems with the game that seem so obvious now. For example, I found players really wanted a sense of progression. Having a single game board with no real win state provided no reason to return. Adding worlds and levels for players to complete provided an end goal. Players could beat as many levels as they wanted in a session and then return later to complete more.

I continued to have people test the game when I reached new milestones. In the end, play testing often was essential part in turning Wordsum from a rough idea to a finished game.

2. Starting simple and knowing my limitations

For years, I would dream up game ideas that sounded great but ended up being too ambitious and required skills I didn’t have. For Wordsum, I thought of a game what I could make without any help. In the past, I had ran into road block when it came time to create the art for the game or add more complicated systems like multiplayer. For this game, any feature I added had to be something I actually thought I could do and not something I hoped I could do. Also, Each new thing I added must be absolutely core to the game’s experience. This thought process contributed to why the game was 2D instead of 3D.


For years, I would dream up game ideas that sounded great but were too ambitious and required skills I didn’t have. Some ideas required me to be a great artist or to complete the workload of 10 people. For Wordsum, I wanted to create a game with a feature set that I could complete on my own.  Every feature I added had to be absolutely core to the game’s experience.  This thought process contributed to why the game was 2D instead of 3D and why I used game assets.

 Design drawings for the game
Design drawings for the game

Each new idea I wanted to add had to pass a series of questions. How long will this take me? Can I do something easier? How sure am I that this will be fun? What will I have to learn to complete this? The answers to these questions would determine if my idea was worth implementing. This saved me time by avoiding big changes that I would eventually throw away.

3. Agile Development

When I started working on Wordsum, I created a version of the game with only the core elements. This was a single screen that created a new row of letters every N number of seconds until it filled a grid and informed the player the game was over. There was no input or any real game mechanics. It was a start and a milestone I had reached.

The first iteration of my game only had these core elements:

  • a single screen
  • rows of letters
  • a timer

The screen filled with new rows of letters every N seconds based on the timer.  Once the grid was filled a message displayed to the player that the game was over.  It was simple: no input, no real game mechanics.  It was my first milestone and I had reached it.  Even though it wasn’t a playable game, I showed it to people (even though it was lame) and explained what it would evolve into.

From there, I worked on the basic gameplay loop.  I started adding the ability to select letters and a button to submit the selection.  Next I added logic to determine if the selected letters was a dictionary word.  These steps led to iterations that could be played by users.  Building the game in layers made my code better and more modular.  Each time I completed a milestone and pushed out a build, it felt good.  This progress is what kept me going and prevented me from losing sigh of my end goal.

From there I worked on the basic gameplay loop. Once I had a build that someone could actually “play”, I showed it to my friends. It looked really bad and played just as bad but being able to build the game in layers made my code better and was a big motivator. Each time I completed a milestone and created a build, it felt good. This progress is what kept me going and prevented me from losing sight of my end goal.

Things that went wrong

1. Choosing A monitzation strategy

Making money as a game developer is hard. Making money as an mobile indie game developer seemed almost impossible. I doubted whether people would buy my game. Free to play seemed like an obvious choice at first because it was easy to convince people to download the game and try it. I found that most that tried it, liked it a lot. I made some money from advertisements as well as In-App Purchases. This was great but in the end I wasn’t making a lot of money. This was partially due to my download numbers being too small. This was due to the game not being social which made it very hard to get the word out. Also, I found it hard to implement IAP in this type of game without upsetting players and just being down right shady.

If I had charged $0.99 for the game and received half the downloads, I would have made much more money. I feel like my game was much more suited as a paid game rather than a Free To Play game. I’m really glad that I got as many people as I did to play the game but I should have had more confidence in Wordsum and asked for money upfront. 

2. No artist

I’ve tried over the years to work with people on different types of projects. My results varied but most of the time, interests faded and I was left doing the work. I let this be an excuse for not finishing things. This time I wasn’t going to let that hold me back. Lucky for me, the resources available to game developers has gotten to be pretty amazing over the years. Things like Unity’s asset store provide a market place for you to purchase everything from 3D models to sound systems. While you still have to make the game, having this available helped me complete Wordsum and even make it a good game.

 First version of the game's UI
First version of the game’s UI

It might sound like this entry should be part of “what went right”. The problem was, I spent a lot of time looking for art and sound assets that looked right and followed a common theme. This was draining and caused a lot of rework. Over the course of working on Wordsum, I changed the UI 4 times before I was satisfied. After all this, I still wish the game looked “better” and all the tweaking I did took away from what really counts, the gameplay.

 2nd version of the game UI
2nd version of the game UI

I also think that using the pre-made assets prevented the game from have a unique look to it that would have drawn people in. Most reviewers and players will make quick judgement of a game just on the way it looks. Who knows if I would have gotten more downloads with a strong art direction. In the end I didn’t have much choice but I could have saved a lot of pain working with an artist.

 Almost final game in action
Almost final game in action

3. Did not start marketing early

While I was making Wordsum, I read a lot about how to get people to play my game. Everything I read said you should start marketing your game as early as possible. Unfortunately I put this off until much later in the game’s development and I think it hurt my total download numbers. I didn’t think anyone would care about the development of a word game on mobile devices. I looked at other games and thought that of course people would be interested in that game. I should have had more confidence and just shared no matter the type of game.

4. Not knowing when to let go

I think Wordsum is fun to play. After all, I made the game for me. When others played it, they had a lot of fun. If this was the case, why were my download numbers so small? This question plagued me day and night after releasing my game to the public. It could have been any number of things but at some point I need to let go. A close friend tried to help me by asking me what my original goal was. My answer to her was always to finish something that I could be proud of. If that was my goal then I reached it months ago but I didn’t stop. I kept updating and marketing the game to little success. Sure the game is better because of the extra time but I should have moved on and started something new instead.


Making Wordsum was challenging in many ways but it was worth it. The feeling of having my game played by so many people is an awesome feeling. Even if I never make another game I can at least feel that I accomplished something. If you enjoyed the post-mortem, please try the game and tell me what you think on Twitter @pixelshotgames. It’s available on Android and iOS.

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 ( 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

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.


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.

Next Game Pre-Production

As development on Wordsum winds down for its June 1st 2015 release, Pixelshot Games has been working with the talented artisit Ink By Jeng on pre-production work for our next game. 

 Concept Art For The Main Character
Concept Art For The Main Character

The game will be a 2D platformer that centers around a young girl who has discovered she can talk to the bears of the forest while wearing her bear suit. The game will focus on recreating the feel of playing inside of a children’s picture book. Stay tuned to learn more!

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.