Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Android Real-time Multiplayer - Latency and Anxiety

Dealing with packet loss while having a heart attack. This is my experience of being an Android game developer while dealing with severe anxiety.

Tramel Morrison

March 7, 2014

14 Min Read

          Making a game by yourself is a challenge.  It can get crazy pretty quickly, jumping from designing and programming, to sketching and animating, all the way to recording and modifying your own sounds.  If you create your own music for the game, you are a better developer than I.  I’m lucky enough to be friend with Populuxxe, who made me a song so great that I have used it in two games already.

            Screenshot from Swim Swim Online

            During the development of my game Swim Swim Online on Android, the challenge was a bit different for two reasons.

  1. It was a realtime multiplayer game on Android

  2. I suffer from severe anxiety

There are a lot of people who would be pretty surprised to hear about this.  Friends of mine were shocked after nearly a decade.  These reactions generally surprise me, because to me and probably others who deal with this on the daily basis, the anxiety seems to be written all over my face.  I never talked about it because I thought that it was extremely obvious, and to be honest, I’m pretty embarrassed about it (which only snowballs the anxiety).

I have had anxiety for long enough to become a terrific actor.  I have had full on panic attacks surrounded by joking friends at restaurants thinking I was going to pass out at any second, four an hour, two hours.  I’ve been in near panic for days at times.  I’m good at pretending, at hiding it I guess.

But you can’t hide from yourself.  So when it is 3 a.m. and you are programming a game because you cannot fall asleep, you know fully well what is going on.

I will drop one line of code, my chest will tighten.  I will drop another line of code, and man “it is getting a little difficult to breathe”.  I start another line and stop because I am feeling faint.  I finish the line, and have a few minutes of normality.  I stop suddenly, lots of pain in the middle of my chest.  Now my chest is really tight, it is really difficult to breathe and I have the phone in my hand.

Am I feeling this because I am having a heart attack?  Is there something in my chest?  Am I feeling this way because of the anxiety?  Do I really have anxiety or is something wrong?  Should I call 911?

 This was a typical night for me during the time period I was developing.  The stress of developing the game made it worse.  The stress that I needed the game to succeed or I wouldn’t have a dime to my name made it much worse.

What really set it off for me though was that I knew that I wasn’t working as well as I could have been, that my code and art was suffering because of me, or this terrible emotion inside of me (I’m feeling a pretty anxious right now thinking about other people reading this, so silly lol).

Let’s give this some format, I want to tell the story of Swim Swim Online.

A little over a month ago I was about to release a game I had been working on for since August.  I don’t want to get into the details of this game but I felt as though it would be a super hit on Android.

I began by picking up a book, “Beginning Android Games” 2nd edition by Mario Zechner and Robert Green.  This was my first venture into Android and the book helped me out quite a bit as a starting point.

After some research I found the info, while very helpful, to be slightly dated, especially in their choice to focus on OpenGL ES 1.0 over 2.0.   I came from the wonderful framework, XNA, on the Xbox and didn’t really know too much about creating my own framework over the underlying graphics library (O SpriteBatch how I loved you).

This I learned from a bunch of resources online, and after a ton of research and long nights I had my own framework to build Android games with.  Now it was time to alt-tab between Eclipse, Adobe Flash, Adobe Photoshop, and Adobe Audition.  If you enjoy these products, don’t use pirated software but still broke like me, see if you can get $30 a month for Creative Cloud.  (If you cannot, here is my suggestion: Pixel Art in Microsoft Paint using Magenta as the background.  If you want more advanced features or PNGs a bunch of developers speak highly of Gimp, which I have never used.  But I digress.)

Alt-tab, alt-tab, alt-tab, BAM a few months have passed, and you have a fully functioning single player game on Android that loads textures depending on the specs of the device and won’t crash unless it is held by a crash test dummy.

But I designed my game for multiplayer.  First mistake, plan multiplayer BEFORE you finish the game.  I began my research into mobile realtime multiplayer back in December.  My original plan of attack was to find a way to rent a server, research what I would have to do to get it up and running, research how to set up socket connections between players, research this, research that, find a way to pay for it all.

Another word of advice… find an easier way.

It would have been an uphill battle, and I didn’t have time for that (I had no money).  I definitely didn’t have the energy to deal with all of that additional stress, for the months I was learning Android development and creating my game I had been to the hospital three times, and felt as though I should head there once every other day or so.

That is when I learned about Google Play Games Services.  This API is great, it offers so much and though it isn’t without its challenges, it handles a ton of the work for you.

Once I integrated it into my project, and wrote an interface on top of it I created a small text app (unreleased) exchanging data between two clients.  You do not have access to the server, so doing things like leaderboard sanitation and choosing hosts has to be handled in creative ways, but Google Play Games Services is truly a lifesaver and saved me a ton of time.

After about a month, my game was finished!  Single player was crazy, ridiculously fun.  Multiplayer well… it sucked.  I had designed the game as a fast reaction game targeting a maximum round trip time of around 150ms.

Terrible, I know.  I don’t know how I didn’t think about the fierce mobile latencies (my testing is seeing round trip times in excess of 500ms easily), but without rethinking the majority of my game, it was going to be impossible to play online.

My panic pretty much doubled.  I had just wasted the last of my resources developing a game that I couldn’t release.  It had taken months, and I had nothing to show for it.  I played League of Legends for pretty much an entire day, just trying to take my mind off of the headaches, lightheadedness and shortness of breath that assaulted me that day.

I woke up with a mission.  I had to create a game, and get it out there.  I was going to do it in a weekend.  It had to be simple and easy.

First thought? Helicopter games - back from my “not paying attention” in middle school computer class.  It was perfect, I could make a helicopter game where you avoid the walls and small obstacles.  It would be an engaging experience online, and I knew exactly how I would do it.  But helicopters weren’t exactly what I wanted.  I had created a water simulation in my unreleased game that looked great, and I had to use it as a main feature in this new game.

Have a helicopter flying over water?  Maybe.  I mean, it could be interesting (and I will probably release it just for fun).  But the water wouldn’t be the focus, the helicopter would have to underwater.  That would be pretty dumb, you can’t fly underwater.  You swim there.

It had to be swimming, it had to be fish.  I was extremely excited about this, I would have a fish that would try to avoid the sea floor and the air above, like the old school helicopter games.  He would occasionally have to dodge a shark or something.

But the thought was gnawing at me… “Was it too simple for an Android game in 2014?”

I went to the app store to try to find other successfully helicopter games , and other successful but really simple games.  The first game that I saw was both.

Flappy Bird.

It was number 1 on the charts, I couldn’t believe that I had never heard of it.  I checked the charts often and thought that it had to be a glitch.  So I did a quick google search.  EVERYONE was talking about it.

This was very interesting to me in two ways, the first way is pretty obvious.

  1. Very simple mobile games CAN succeed in 2014

The second way, depends on how you look at things.  When most people look at Flappy Bird, I bet they see a bird flapping through pipes.  That isn’t how I saw the game.  When I saw Flappy Bird, I saw the old school helicopter games.  I saw a helicopter moving through obstacles, with one key difference.  The helicopter didn’t ‘fly’.  It jumped.

The fish in my game were originally going to swim up and down respectful to players holding their finger down.  This is all well and good, but doesn’t give you the same amount of what I call ease of control.

A game like “Super Meat Boy” offers the user an incredible amount of control because it is easy to predict what will happen based on your input.  Flappy Bird, by using tap alone, offered an ease of control that my game simply wouldn’t (for casual users).  By advancing the physics of my fish a bit, and converting from holding down to tapping, I could take this game to the next level.

Another takeaway was that there wasn’t constant stress in Flappy Bird, like there was in the old school helicopter games.  Between pipes, you had a little bit of wiggle room.  My game was going to be high stress from start to finish, with the difficulty increasing.  I changed that, now it is high stress, avoiding obstacles and low stress, space between obstacles.

But my game wasn’t complete.  There would have to be a little more action.  I mean, I made “Kube Ball” and a game would not be intense to me without some super high stress moments.  So I added some power ups (some I haven’t uploaded yet so I won’t talk about them) like anchors falling kicking up dust and blocking your view, and triple obstacles keeping stress high for longer.

Now, I don’t want to get locked down into too many specifics, but developers if you are tuning in here only for the realtime multiplayer aspect of this article, this part is specifically for you.

  1. Find an easier way – Unless you really have your head wrapped around all of the pieces involved in managing a server and connecting clients, find an easier way to get these done.  With Google, that is Google Play Games Services, it handles the hard work for you.

  2. Dealing with latency (Part 1) – Let me be blunt.  If your game is latency dependent, and not deterministic, do not make it on mobile.  The latencies will be too high.  If your game is deterministic, create a strong interpolation method, create a physics loop that is set to a small amount of time ( < 1000ms / 60 ), and run that physics loop as many times as you can within the timestep.  Store the additional time, and add it to the next frame.  This will keep the clients running at the same speed, regardless of the power of the device (except in extremely unusual cases).  NEVER do something like this “position.add(velocity)”.  ALWAYS do something like this “position.add(velocity * timeStep)”.  EXCEPTION TO THE RULE: if your velocity already incorporates the timeStep into its calculations.

  3. Dealing with latency (Part 2) – These is how you should do it, at least the way I looked at the problem.  (There are some great articles you can find all around the web about various techniques, this is just my two cents).  Select a host, the idea is that he will not be dependent on latency, he will run the game as if he has 0 latency, with the exception that client data comes in.  At that point, get the time that the client sent the packet, rewind behind the scenes, and update to your current time.  IF anything can be undone without wrecking the experience, undo it.  Send the update to the client.

  4. Dealing with latency (Part 3) – Client side rewinds when he receives an update, then simulates the game to the current update.  In between updates, the client pretends he is a host for everything except the MOST VITAL of information.

  5. Another take on dealing with latency – Of course, that is a lot of work, and very easy to get things out of sync.  The easiest way is for the client to send input to the host, and have the host send the update.  Then the client interpolates between these updates.  The problem here is that while the host will have a fantastic experience, the client’s experience will be based on the latency.  Still, this way of handling this is worth taking a look at.

  6. If you are a beginner, read 2 – 5 again.

  7. Dealing with bandwidth – Two issues arise depending on the amount of data you are sending and receiving.  One, packet loss.  In my experience, this increases severely when you send more data than you need.  Two, while users understand that they will be using data while playing online that is not an excuse to be inconsiderate.  Send only necessary data.  In my game the waves in the water are not synced, because they do not have to be.

  8. Packet Loss – Sockets are not immune to packet loss, but they are faster than other methods of sending data.  Whenever possible (and it is with Google Play Games Services) use two methods of sending data.  One fast and unreliable for normal data, one reliable regardless of speed, for very important data.  When sending packets you can send an id, and every once in a while send packets with the number of the ids that you have received.  If a client says he is missing a packet, resend.  But be careful, as this can both increase bandwidth, and possibly add to packet loss.  What a shame.

The result?  Pretty smooth gameplay.  I will be releasing an update to make it even smoother, but the message to developers creating multiplayer games for mobile platforms is that it can be done. 

It was a tough journey creating this game, and for multiple reasons.  I think that I have made those reasons pretty clear, but I don’t know if I have made myself fully clear.  I love developing these games, regardless of the all of the additional stress that it adds being a one man game development team.

If anyone suffering from severe anxiety stumbled upon this article, especially if you are somehow also I game developer, I left out a lot of personal things in this article just to retain some privacy (I am already embarrassed about what I have written already and I haven’t even submitted the article yet).  But if I was talking to you one-to-one I would tell you that I know you think I am lying, and that no one understands what you have to deal with.  But I understand.

Listen.  You have two options, there are no others.  You will either overcome your anxiety, or you will rise to the occasion regardless of it.  Anxiety controls how you feel about what is happening, makes you think that something has a chance of being something serious.

It does not control your actions.  No matter how terrified you feel, regardless of what emotions and sensations occur, just win.  See a doctor, explain fully what the situation is, get checked and if nothing ends up being wrong then nothing is wrong.  Stand strong in these facts when you find yourself weakening, and win regardless of how you feel.

Stand up.

If you cannot stand up then you will fall, and if you can stand then you will stand.  But never sit for fear of falling, you will end up in the same place.

God bless, thanks for reading this story, keep coding!

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like