Community Garden is out on Early Access

The first persistent VR world built on Improbable's SpatialOS is here. Community Garden is available to any one with a HTC Vive or Oculus Rift. Just download on Steam and playing. Be sure to check out the Steam discussion boards and leave a review to tell me what you think. This is just the beginning so stay tuned for more updates.

The inspector view of Community Garden running on SpatialOS

The inspector view of Community Garden running on SpatialOS

Community Garden Alpha Release

Community Garden is getting an Alpha release. This is an early build of the game that you can sign up for by going to the Community Garden site and signing up. My goal is to get people in world testing both the social and simulation aspects of the game. I'm hoping that by getting people interested in a VR game running on Improbable's SpatialOS, Improbable will be interested in supporting VR once again.

Blog Post:

My Personal Status Working on MetaWorld

Last year, I began the journey to create MetaWorld. Being one of the first developers to use SpatialOS and being the first using it for VR was a huge challenge. Documentation was sparse and Improbable was tied up growing their company. After a 3-4 months we had something to show to the world. The response was good, people who tried MetaWorld really connected with the world.

Unfortunately, after the press showing, I ran into a number of issues with SpatialOS due to required version upgrades and bugs with SpatialOS itself. Improbable was busy with other things so they were unable to help. I slowly worked through some of the problems but progress was slow. I started to feel that making a massive VR experience wasn't going to be possible. At our current trajectory it would just take too long.

I still wanted to create something that allowed people to be able to visit a living world together from around the globe. To get there we would need more support from Improbable and a much bigger team. Funding efforts weren't going well because investors wanted to see more before investing. The time required for one developer/game designer and a designer to create what we need would just take too long, we needed more help which costs money. This became a contention point between me and my business partner. Eventually I just didn't see a future in continuing the way we were. I decided to stop working on MetaWorld and focus on a new title called Community Garden. Community Garden would start small to prove the viability of building persistent VR worlds in SpatialOS.

I was surprised when I found out my partner had started an IndieGoGo fund. To avoid confusion, I wanted to make it clear that I'm not currently working on MetaWorld and I don't know how my partner plans to deliver on the promise of the fund. If you plan on donating to the IndieGoGo fund, please note that none of the work I produced for the MetaWorld you see in videos like the one above is what will be delivered.

Wordsum Is Now Completely Free

ue to Soomla no longer supporting their plugin for IAP I decided to make the original Wordsum free with no IAP and no Ads. I thought this would be better then spending my time trying to find a new IAP system for a now 2 year old game. I also just don't have the time since I'm only one person. Another plus is that I could now port the game to Windows, Linux and Mac. opefully more people get to play and enjoy the game now.

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.

The Secret to Picking Up the Gnome in Community Garden

Being able to interact with objects is a key component to VR. Common player interactions include the ability to pick up objects, move objects around and set them back down. With previous versions of SpatialOS, implementing this was pretty easy. Unfortunately, with the latest version (V9) implementing these player actions isn't as straightforward. The code has become more flexible internally, but the documentation does not expose these new changes.

In previous versions, if a player wanted to pick up the gnome, a message would be sent from the player's entity to the gnome's entity to request ownership. The gnome would receive that message and handle the transfer of ownership to the player, allowing the player to move the gnome. I could not get this to work in Version 9 of Spatial OS, so I created a forum post to try to get some of my questions answered. 

After some back and forth with Improbable, I learned that I needed to modify the Entity's ACL when the player wanted control of the gnome. I tried to do this by building a new ACL which set the Player as the authority of the gnome using SetAcl(). Unfortunately, SetAcl() didn't seem to change the gnome's ACL. I tried to communicate this within my forum post and decided to create a simple fork of Improbable's PiratesTutorial Repo. I created a new branch and wrote some code with my current implementation. Check out my version of the PiratesTutorial.

Progress was still slow on the SpatialOS forums, so I tried a different approach. Instead of attempting to gain control of the gnome, I had the player send coordinates to the gnome's entity telling it where it wanted the gnome to move to. This worked but was not perfect and had one major issue with collision which you can read more about here.

Example of collision issue from alternative solution. Dropping the sphere in the planter should create a new plant but does not consistently.

Silly collision issues and still blank stares on my forum post...I was getting desperate at this point. I decided to make new post where I tried to explain my problem differently.

Eventually, the Improbable support team cloned my git repo and made some modifications. These changes revealed one major component I was missing. In SpatialOS, there is a concept of Readers and Writers in regards to an entity's state. With this new version of SpatialOS, it is required to use the new EntityAcl.Writer to make updates to the Entity's ACL. This allowed me to make the write access updates. Once I changed this, the player was able to take control of the gnome in the world.

Player can now pick up the the gnome.

I'm really glad this pesky gnome problem is out of the way. Not being able to interact with Community Garden's world would have really hurt player immersion. 

Update: I noticed this morning that Improbable forked my repo to help others work through similar problems. I happy to see the example being put to good use :) I think SpatialOS is easiest to under via example.

Spatial 9 on VR

I've been using SpatialOS for quite some time now and there have been some ups and downs along the way. Major changes to the API have required me to rethink how I develop with the technology. The latest version Spatial 9 was no different. This version had some of the biggest changes yet.

After taking the time to learn the new version, I was pleasantly surprised by all the improvements that were made. The team at Improbable really has done a great job. 

To celebrate getting Spatial 9 working in VR, I wanted to share the first rough screenshot of my friend hanging out and waving to me in the Community Garden I'm building. Unfortunately the plants we had growing in here died due to lack of watering...


Wordsum Blitz Coming Out Finally! November 6th to be exact.

Making Wordsum Blitz has been a very long journey considering the small size of the game. I really wanted to make something special based on the original idea of Wordsum. Along with the artistic help of my friend Jennifer Reyes aka InkByJeng, we managed to create a beautiful and fun game. I'm actually pretty terrible at playing the game so my top score is around 30,000 or so. Tweet me @pixelshotgames and let me know how awesome your score is.

Pro Tip: Just in case people are wondering, you tap the white panel at the top to pause the game. 

Remembering what it means to be indie

I've been creating games independently now for more than a year. It hasn't been easy to do everything myself but it has been rewarding. Somewhere along the way I feel like I lost track of why I became indie. I even started to regret making games in the first place. I'm not sure if this post will amount to anything more than me rambling but I feel reflecting on my past might help myself as well as others remember why we all chose to do this in the first place. 

After finishing my first game Wordsum, I wasn't sure what was next for me. The game didn't take off like I had hoped for. Don't get me wrong, the amount of people who played my game was more than I could have originally thought possible. Even better was the people that played the game seemed to really enjoy it. But even with this, I was baffled that it took me over a year to get 1,000 downloads. The game also didn't make much money (I found I do like to eat on occasion). I was spending all my time figuring out how to maximize the IAP for my game. What had I become?

Original Wordsum screenshots

Original Wordsum screenshots

When I look back, it made sense why the game didn't become the next Crossy Roads or Monument Valley. It didn't look or sounds unique so it didn't standout from the crowd. Where did the game lose it's identity? It started during early development of the game when I got caught up in what would sell well and what would attract people to download the game. In summary:

  • I made the game cartoonish and flashy instead of beautiful and unique.
  • I made it Free to Play instead of believing people would buy the game.
  • I changed the core structure of the game to make it more of a value proposition.

The game I set out to make became a watered down version of the original. After the release, I became obsessed with marketing and IAP. I was miserable. The whole point of this change in my life was to make games I was proud of. I had quit my full time programming job to do it (I still contract to support myself). Yes, I can be proud this game exists and that it's fun but there are too many what ifs.

Over the next year, I've done a few other things. I made a VR game for the Leap Motion Game Jam, In Space, No One Can Hear You Dance. I started other games like Donut for the Gods and my current focus, MetaWorld. In the back of my mind I never felt like Wordsum was done. Little by little I began recreating the game as I originally envisioned. A fun, fast and beautiful word game that took the spirit of a game by Shintaro Sato, Blocksum, and shook it up with words.

Screenshot of Blocksum the inspiration for Wordsum

Screenshot of Blocksum the inspiration for Wordsum

I asked an artist who happened to be my friend to help with the art. Make it her own. I refined the gameplay to the core mechanics and improved the 'feel' of the game. Most important of all, I took my time and I didn't compromise my vision. This new game Wordsum Blitz, was something I wouldn't say what if to once it's released. It's the game I wanted to make.

The new and improved Wordsum Blitz

The new and improved Wordsum Blitz

I hope people do buy the game and enjoy it just like I would. I want them to look at it like I've looked back at Blocksum all these years and say "that was a really fun game". In the end, that's all the really matters to me. If you want see the change for yourself, download Wordsum for free for iOS or Android and check out Wordsum Blitz when it is release on iOS App Store on November 6, 2016. 

It's Been Awhile

My posts have become infrequent but I haven't given up on game dev. Too many things going on so blogging was put on hold. To get me back in the habit I decided to at least provide an update on what's been going on.


After completing In Space, No One Can Hear You Dance, I started working on a much bigger, more ambitious project. MetaWorld is an open world VR experience where players can explore a huge world with others. This project has been super challenging for many reasons. The first being I'm the only developer. This is made even harder by the fact that VR is so new that I often need to rewrite entire systems when something doesn't work. On top of that, being an early adopter of SpatialOS has presented many challenges. The Improbable has been working hard to create better documentation and a more stable API but the journey has tested my resolve. Also, building on top of SpatialOS requires a much different approach then commonly found in game development. The results though have been great. Creating something new that hasn't really been done before is very satisfying. An awesome moment for me was talking to Rachel Webb from She really captured why this project is so special.

There is more to come for MetaWorld as well as more challenges but nothing great is every easy.


Wordsum reached a big milestone with 1,000 downloads. I never honestly thought I would make a game that this many people played. I still want more downloads but I'm also very happy with this number. Being my first complete game, Wordsum is special to me so I don't see myself letting it die.

Wordsum Blitz

This game has been a long time coming. The original Wordsum opted for a level based design to give the player a sense of progress. Originally, I wanted to make Wordsum a score based game that never ended much like Tetris. You simply just try to get the best score and compete against friends. Instead of adding this to Wordsum, I wanted to make a new game that was lighter, without ads, without IAP, with better art and that was straight to the point. Over the past year, I've slowly made updates and changes but only recently has it been looking like a finished game. The last little bit that I had to overcome was performance. With that finally conquered you can expect Wordsum Blitz very soon.

Donut For The Gods

Oh this poor game. Unfortunately Donut for the Gods has received the least of my attention. It's not abandoned though. Once Wordsum Blitz is released I will begin the slow struggle make progress. The gods will get their donuts!

Wordsum Blitz, Full Steam Ahead

After finishing Wordsum I took a trip into the work of VR with In Space, No One Can Hear You Dance. During this detour, I never quite stopped playing around with the design of Wordsum. The game was fun but I felt like I had strayed away from the main point of the game. I removed everything but the core gameplay and made it score based. The result was a game that was even more addicting with endless replay value. Wordsum Blitz was born. 

With the gameplay fixed I turned my attention to the art. The art for the original Wordsum was fine but it wasn't original and lacked something. Lucky for me, I know a talented artist. Jennifer Reyes joined the team (ok a bit of an over statement since it was just me) and crafted this beautiful mockup.


This is just a mock up but I have already started integrating this into the game. I will post more updates once there is a working demo. 

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.