How I Learned to Love Remote Workers

Office Space

In this day and age, making games is more accessible than ever. Top notch tools are available cheaply (or free!) to just about anyone who wants them. That said, it takes significantly more than just tools to make great games. It takes talent, money, and time. What we don’t need is offices. Even big AAA game studios could improve their bottom line with this concept. Here is a proposition for why game builders, big and small, should seriously consider making games with remote workers as a deliberate choice.

The most obvious difference is cost. When you are already paying for a safe place to sleep, why let that space go to waste while you are away at work eight or nine hours a day? While it is still true that a dedicated space for work is required, the additional square footage cost is far below the cost of a completely separate space. This also takes into account the shared space of multiple people in one office.

My Old Office
My Old Office

Even the concept of a typical modern office is difficult to understand for a creative person. At some point in the the last decade someone suggested that the “open office” plan promoted collaboration. While us game makers are all about trying new ideas, it has been proven through multiple studies that open offices only end up creating more distraction. While distraction can be an issue at home as well, there are ways to minimize it. Home offices are not a good strategy for parents of young children, for example. However, once they are school-age you will have a house that is quiet and filled with the love of your family, ready for creativity to flow.

This suggests another point about our office environment. At places like IBM in the late 70’s, They had a job to do, and wanted to look good doing it. So it was no concern at all to put on a suit and a tie. Therefore the dress code was less about a form of control by the corporation, and more of a concession to what the people working in that company wanted. Why should that be any different today? And this extends to decorating our working space to any degree we like, without fear of offending anyone.

Game developers typically have two modes: they are at the keyboard making stuff happen, or they are thinking about what they will do the next time they are at the keyboard. Working at home allows us to make things happen when we think of them, not have to wait until the next morning. By then, we’ve already forgotten the idea!

This is one of the many myths about working at home: that it reduces productivity. It is true that it takes a certain kind of mindset to not take advantage of the situation. But one of the things that defines us as developers is that this is what we want to be doing, more than anything else. This isn’t “work” to us. It is freedom, a kind that is so much more rewarding when you get to escape to that place any time we like.

Setec Astronomy

In the interest of full disclosure, let me tell you a little about myself. In the five years I’ve worked for my last company, I have walked into the office twice. Technically I was based out of the San Francisco office, but I live and work from my home in Kansas City, Missouri. Before that, I worked remotely for people all over the world including New York and London since 2003.

For most of my last project, I was the sole programmer creating the entire user interface experience outside of the core gameplay itself. Clearly I was a necessary and valued member of the team. Unfortunately me and the other two remote workers in the company in other cities were recently laid off. At the time of the layoff, all of us were working on critical path features of a newly released game. Less than a month ago our company entered into an agreement with a company well-known for extreme secrecy.

It is my opinion that this is a direct result of one of the myths of remote workers: that they are more likely to reveal company or investor secrets, that we are somehow less secure because our computers are allowed to leave the office for extended periods of time. Yet the three of us worked for the last 12 months on a project owned by very big name intellectual property owners, without a single incident of leaked information or stolen equipment.

It could be argued that houses are more secure than an office. Every person in a household knows every other person, intimately. Every unusual face sticks out like a sore thumb. In an office’s business hours, who can pay attention to all the people who must come and go in a normal day? Sure, you could hire guards or install cameras. But all of that is quite expensive compared to the built-in security of a household. And if something ever does happen, you’ve lost only one machine, instead of having twenty machines available to a thief all in one place.

Make it Work

For those of you who have never attempted such an adventure, here are a few easy guidelines that have proven extremely useful over the years.

Treat every email, every instant message, every phone call as though you were standing in front of that person. Be respectful, don’t interrupt, and remember that this isn’t like the internet: these people do know who you are.

Team gatherings are just as important for remote workers as it is in an office. When starting a major milestone on a project, we gather the team to hash things out. Start projects by bringing everyone to a central location for a week to get as much on paper as you can. That way as we follow up with weekly online meetings there is a basis of understanding. Not to mention it breeds the camaraderie needed to get through the hard times.

Video conferencing is not as necessary as it used to be, with the advent of things like Google’s online presentation and document editing software. It’s not perfect, but it is a huge step in the right direction. On the other hand, quality audio conferencing is a must. Do not underestimate the importance of being able to interrupt someone to make a supporting comment. Unfortunately there is not much good software that can both keep a solid connection and also allow people to interrupt each other. Whatever you do, use headsets. The built-in computer microphones and speakers add a lot of unnecessary noise.

Have work accounts for email and instant messengers separate from personal ones. This way you can “tune out” work or personal life at appropriate times. A major point is reducing distractions, and having your inbox ping at you 20 times a day is the opposite of intended.

You might think there is more to it, but in truth there is not. It is as simple as ??. Therefore I bid you great game-making!


Gamasutra has been gracious enough to publish this blog entry as well! I’m so stoked!

Remoting Essentials

10:43 AM mr.ed Hey guys! How you doing?
4:39 PM mr.ed Hey! Are you guys using this thing? :) #general
4:40 PM dan Just saw this, sorry. This afternoon has been crazy.


This happens every time I start with a new team. A communication tool is only useful if it gets a response from the other end. It takes some effort on the part of the main office, not only by the remote worker. And every team I’ve had the pleasure of working with have used this simple set of rules.

Act as though the person you are talking to is right in front of you. Do you like it when the person you are talking to constantly turns away to answer the phone, or get interrupted by other people? No, you don’t. So when you are talking to someone online, don’t just step away and leave the remote person hanging. Either ignore the interruption, or at least excuse yourself from the remote person. That way they know that your attention is elsewhere. If you try to do both, it becomes very obvious that you are not paying attention.

Likewise, don’t say anything you would not say to their face. Anonymity does not apply here – these are people that you work with, respect, and will remember how you act. That said, this is a rule that should really apply to any online interaction.


There are three main channels of communication available to remote workers. If everyone on the team has the same expectations of the methods, then all requests will be handled in timely manners.

The first channel you might think of is instant messaging. This is an extremely useful tool. However, it’s often overused. It is perfect for having ongoing conversations. It is also an interruption. If the servers are on fire, or someone is stuck and can’t get their job done, the an interruption is completely appropriate.

The rest of the time, email is the proper channel to start new conversations in. Email can be ignored until there is a break in your current task. There is no expectation of an immediate response. But also don’t let the email thread get twenty replies. If a conversation needs more than a single response, it makes sense to set a time for an instant message conversation to follow up with and hash everything out.

Which brings us to the third channel: phone. Nothing will replace the ability to talk out issues. It is often much faster and easier to understand nuance than instant messaging. A particularly powerful addition is using instant messenger at the same time, to post links and references to the other participants during the conversation.

Some additional notes about phones: high quality is a must. Do not use computer built in speakers and microphones, always use a headset or headphones with built in microphones. Computer speakers often create terrible distortion. Also, do not underestimate the importance of being able to interrupt another person, to provide a supportive comment. Many phone systems only allow the loudest participant to be heard, meaning no one can interrupt.


These guidelines have served me well for many years. May they also serve you well.

The Tall Man

This is not the first time I have faced the end of my career as I knew it.


Picture it: the year is 2003. The Matrix Reloaded and Revolution are going to be coming to theaters soon. And on the fifth floor of a nondescript office building, in a tiny room with no windows, sits a tall man in a relaxed pose and a short man looking very uncomfortable.

The short man is telling the taller that he needs to read his required three career improvement books per quarter to continue being employed there. The tall man listens and smiles, laughter bounding in his mind, but only letting a smirk show on his face.

For the last six months the tall man was told to build reusable software for importing email address databases. At no point was it defined how it might be re-used. They even brought a second programmer on the project, fresh out of college with a shiny degree in a frame set against the window at an odd angle, to architect this design. This architect declared the five-tier architecture was the path to reusability. And then proceeded to create separate, duplicate copies of every structure in every tier. Every change needed to be made in five places.

When the completion deadline loomed, the tall man knew the project was doomed. Yet until that last week, he figured it could be saved. But as the day of the deadline arrived, the tall man could not even get out of bed, too sick from worrying himself over the first true failure in his career as a developer.

For four months after being let go, the tall man could not even bear to touch a computer. He was thoroughly sick of them, wanting nothing to do with them. His entire career, almost his entire life was spent around them. Tinkering with them in high school, making games on them in college. And now, he couldn’t touch one, or he would feel the stink and the fear of that last project.

He knew it was time to get serious about his next move. What was he to do? Computer programming was the only thing he ever felt he had a talent for. Grudgingly he contacted a local non-profit organization to see if they might want some help improving their online presence. He wasn’t after money. He was after a measure of making someone happy.

It wasn’t much that he did, but it did make a small difference for them. And they were grateful. The kind of gratitude that didn’t exist at that last job. The kind that he knew was required to keep his sanity if he were to ever work for any purpose ever again.

He set about re-learning the business of game making. When he was hired at that email company they were making games, but their vision had shifted. He was simply riding things out as long as he could, looking around for better opportunities. As it turned out, none came.

So with the strength of his wife’s support and tip of the hat from someone willing to take a chance on him, he began writing the game engine that would restart his career in games.


In truth, I’m hardly starting over at all. I will still be able to bring to bear the talent that God gifted me. My heart goes out to you who are forced to truly start over.

Indies are Go!

So now that I’m between gigs, I’m going to try this “relaxing” thing while I listen for what God wants me doing next. But I still gotta do something. So I’m making myself available to all you indie developers! That’s right – come talk to me so all of this great Unity3D and game development knowledge doesn’t go to waste.

You will actually be doing me a favor. Why you ask? Because if I don’t use a piece of knowledge for more than two weeks, it’s almost as though I forget it. Which incidentally is why my code is so well commented, because I know I’ll forget what I was thinking when I wrote it!

You can connect with me through this website, or if you prefer, either of the following teamup sites:

Happy coding!

Marvel Mighty Heroes (iOS and Droid)

App Icon

  • Product description: Free-to-play four player Brawler game for iOS and Android
  • Release Date: March 31, 2015
  • Website: Marvel Mighty Heroes
  • Product history/genesis: Looking for a new game genre, we attempted realtime multiplayer in full 3D and succeeded
  • Team: Varied, largest team was 20. I was one of 5 client coders for most of the project
  • Core Technologies: C# in Unity3D with a Scala-based server
  • Most proud of: New Asset Bundle system that allowed bundle sharing and downloadable scene replacement
  • Responsibilities: Sole implementor of almost all UI for most of the development time; Tool development and support for rest of team.

A month or two before I came on this project, I was given the freedom to start working on taking existing code from our Hellfire project and organizing it so that we could share that basic code across new projects. While I was successful in starting a shared technology stack, it was clear that much more needed to be done to make it solid for other projects to use in earnest. Part of that stack was the Asset Bundle system rewrite.

In Unity3D, the simplest way to publicly download additional content like models and textures is to add them to a Unity-specific container called an Asset Bundle. This feature worked, but was under documented and difficult to use at the time in Unity3D version 3. We had some strong code for working with these asset bundles that was developed by the Hellfire team before I started working in Unity. However, the code was complicated and did not support the sharing of resources between different asset bundles. My goal was to fix that.

While I was working on that shared technology, it was determined that one of our new projects was going to need more client coder help than was available. Therefore when I was brought in, I was still developing that shared technology at the same time as implementing user interface designs in this project that already had almost a year’s worth of prototype work done on it.

I would end up spending most of the project this way, doing double duty as the only user interface developer as well as adding tools to make production easier as well as creating the new asset bundle system to make this large dataset manageable for devices. It was only three months before release that I was able to complete the asset bundle system.

As it turned out, Unity themselves had the same ideas I had about asset bundles. Not a month after completing my system, I learned that Unity 5 was including a new asset bundle system which did exactly everything I had put into mine.

All that aside, this was the most complicated user interface design I had ever attempted. Early in development I made this statement to our designer: “Go crazy, dream up anything you can think of, and I’ll try it. If I can’t do it, I’ll let you know.” Sure enough, I was able to make happen a lot of complicated scrolling contexts and interactions that had not even been dreamed of for the Hellfire project.

We support both phone and tablet devices, iOS’s few resolutions and Droid’s many resolutions, all using the same scene definitions. Each scene was put together based on virtual screen dimensions that scale the interface up but not let it get too “fat” and then use the “springs & struts” style of automated item layout to fill in the differences in device aspect ratios.

Other major improvements over the previous codebase was a new scene loading system, one that no longer assumed only one scene was displayed at a time. To make that happen I also had to rework how scene transitions worked, as well as seemingly simple things that became very complicated like handling the Droid “Back” button. All of this code written from the start with the idea of adding it to the shared technology set that I started with.

This was my largest project with this company, and sadly, my last. After twelve months of my work and just a few days after releasing to the public, I was laid off along with many other people.

Despite the difficulty of this project, I am still extremely proud of the work that everyone did on it. This is one of the projects where every single member of the team knew what they were doing and worked with each other to make it happen.