Maintaining a Remote Team on a Revenue Share Project

So around a few weeks back as of the writing of this, the awesome folks at Extra Credits posted an video about remote development. They talked a lot about the tools and the protocls needed to run a remote team, the software to use when doing management, and how to establish and maintain oben communication channels. After watching it I though "Holy cow, I actually have a lot of thoughts and experience on this!" A lot of the stuff mentioned in the video seems to pertain to more experienced professionals who have had a history of working contracts or even more so, just making games. I'm going to take the conversation in another direction and talk about something I've seen over the years that I've been doing this.Let me set up a scenario for you. You're browsing "r/GameDevClassifieds" or some other board one lazy night looking for potential positions to take; Among them you come accross something like this:

"[Rev-Share]Some amazing and talented developer needed to help with a project",

or this:

"[Hobby] Looking to start a team of awesome devs for a project",

or something similar. These types of posts tend to get frowned upon by the general subscriber base due to a collective experience with the style of work. It's usually a high risk with little to no reward ordeal due to the project falling apart at some point. The volatile nature of a rev-share project-- especially for the the indie sector, renders them very unpopular for this reason.

My whole "claim to fame" for lack of a better term is that I've worked on remote rev-share teams before (where projects have fallen apart) and am working on a small project with friends as of now. We're an entirely remote team working on a rev-share project. What seperates this from most other rev-share teams as far as I've seen, is that we've mostly been together for 3 solid years working on this game together. I'll explain the "mostly" part in a little bit. Over those 3 years, we've picked up a lot of good lessons on how to best prepare and deal with the perils of remote development when you don't have a budget, you don't have experience and yet you still have the desire to create something.

1.Take Your Work Seriously

The most important thing I'm going to pass on to anyone interested is to take your work seriously. If you don't take your work seriously then I or any other teammate don't have to take your work seriously. I believe this is one of the top reasons smaller hobby and rev-share projects fail.

2.Learn Basic Project Management

If Waterfall, AGILE, SCRUM, Kanban, Scrumban and Lean are all terms you've never heard before, consider researching basic project management principles and styles before you begin constructing your team. In software design and development, understanding what those terms are and what they mean is essential to maintaining and even functioning as part of a team.

3. A Demo is Better than a Document is Better than an Idea

In the early 2000s, having a well written and articulated document that details your concept and how you intend to build it was a viable way of assembling a team together. As of 2016, we live in an industry where game engines that have no significant programming requirements exist like Game Maker or Construct 2 or Unreal Engine 4, solo developers can seriously shake up expectations of what can and can't be a high quality game (see Braid, Undertale, Fez, Cave Story) and anyone can become a game developer with effort. In this day and age when trying to assemble a team, it's a better and preferred idea to have a demo or a small build of the concept you're trying to make. Better yet it would save you a lot of time and money if you developed your concept as much as possible on your own before bringing in someone else. The more polished and coherent your demo build is, the higher the chances that someone will take interest in your project.

4.Set Concrete Milestones

Extra Credits touches on this in a great way. When you do get that team assembled and informed of how the team is going to function, who reports to whom and so on, you need to look into setting good milestones. In my experience I've found that setting milestones that are close to conventions you intend to show at are effective in getting the team going because of the exposure of their hard work and the chance to get some feedback from others outside of the team. To further the point, when you don't have any physical money to give to your team, then team morale becomes your currency. If you don't show a return on the invested time your team mates have put into making your project become a reality you'll end up in situations where people lose morale and become disinterested, which reminds me...

5. Prepare Counter-Measures for Everything!

If you don't have anyway to pay people for their time, like in a rev-share or even a hobby project, expect them to become disinterested at some point- but not so much that you yourself give up working on your own project. When you're not paying someone, they're giving you their valuable time generously. No matter how good you think you are, you need to be thankful of this because to them from an objective standpoint, it's easy to drop your project and move on to something else more interesting or that pays them for their valuable time. It wouldn't effect them at all but it would devestate you in terms of resources and human power.

Early on in the development of Alicorn Princess Blast, we had a team of 6 people - a designer, a developer, a sound engineer, a writer, a concept artist and a sprite artist. You can see by the nature of our game that having high quality pixel art is important to its appeal. So what happens when youre sprite artist leaves and decides to work on something else? You're not paying them and there may or may not be a rev-share contract in place so they're free to do as they please. You legally can't stop them. 

Well for us, this lead to an exhaustive search for another pixel artist who was interested enough to join our project which cost us effectively 6-8 months of development time. Point number two helped us immensely however because by that time we had a demo level with a little bit of polish which is far better that a polished design document. This also taught us the aformentioned lesson about preparing counter-measures in case something like this happens. While it took us considerable time to find another pixel artist it could have been much longer had we have not spent the time before we had polishing the little demo we released in addition to working on other parts of the game.

6. Communication is Important

You need to understand the barriers that communication must overcome in order to pass information from one person to another. You need to take into account cultural, emotional, mental and in some cases physical and physiological conditions that effect how the information you are passing on may be percieved by the recipient. A concrete example of this is that an artist might not understand how Git works. If you plan on having your artist interact with your repository in any way, it's important that they have a good foundation of knowledge on the subject so that any important information passed to them won't be cut off by the any of the barriers. Failure to consider any of these things leads to a phenomena loosely known as "communication falloff" where information is simply "lost in translation" from one mind to the other.

Sooner or later you're going to have an artist that's angry with your head programmer whose angry at you for what is essentially a miscommunicated piece of information that happened months ago. By that time however the reasons will seem completely non-sensical and petty because of when the conflict started to arise. In order to rectify those types of situations you have to stop the project- all of it, sit the team down and resolve the conflict. This can cost development time relative to how big the conflict is, so it's better to have prevention methods in place to avoid this type of scenario. I also suspect this to be a prime reason for projects that are hobby or rev-share failing.

If you take video into account  along with these points when trying to assemble a team then one of a few things might happen. You may get your team purely based on the prototype you've assembled being a good concept. You could also reasonbly assemble a team by having all of these things in place, which can show others just how serious you are about making your project.

7. Factor in Luck

As a person with an Aspergian mind who has a rather audible hatred of unregulated chance variables and "grey areas" when it comes to big life changing decisions, I'm loathe to admit this. However it goes without saying that you need to factor in luck when it comes to something like this. The Alicorn Princess Blast team is incredibly lucky to last this long with the type of situation we have and we know it. Remember when I said that we've mostly been together for three years? Well over those years we've had people leave and people join in their place at different points in the development. The first few times this happened to us we didn't really factor in luck to our plan but have found afterwards that preparing for these things while factoring in that annoyingly unregulated variable has helped in the long run.

If you do decide to put forth the effort required to have this type of setup when developing your game, go forward knowing that this entire thing could blow up in your face at any point in time for the smallest of reasons. If you want to to avoid that and you do, take the steps to make sure everyone is on the same page at the same time. As of this writing, Alicorn Princess Blast has reached an alpha phase so theres still so much to learn and do for the team, but little tid bits like these have helped us maintain a team based almost purely off passion and dedication. I must express however that this should never serve as an excuse to not pay someone for their hard work. If you have a budget, then use it! Only pursue this scenario if:

Heres hoping that I've given some perspective on how to manage a project like this. It's volatile, it's dirty and it's also risky. Theres a reason why it's unpopular among the masses but just because it's unpopular doesn't mean it isn't useful. If you ever find your self in a similar situation to us and want to put someting together. The more effort you put into the project itself and into maintaining the team, the better you're chances may be of getting to a finished game or a highly polished demo.

Edit: If anyone is interested in chacking out Alicorn Princess Blast, you can find it at alicornprincessblast.com