In 2010 and 2011, I was part of two consecutive game projects that didn’t make it.

The first was a project that I started while still at Gameloft- a TF2-esque team-based online multiplayer game that I still have salted away for when I have a million or two to put into it. The reason it failed? One and only one-Scope. It was (is) a truly awesome game, but way too big for a team of three working part-time. We had put a decent amount of work into it before we went our separate ways. That was…

Lesson #1. The importance of Scope.

The most common mistake, apparently, and one that I repeatedly make. I think that at the root of this mistake lies an ego that refuses to understand that like any other discipline, making video games needs to be learned gradually. You can study about it, you can hear about it, but you’re never going to figure it out ’til you do it. And you have to start small, if you’re doing it on your own or as part of a small team. There is a (subconscious) assumption that “I know how to play it, so I know how to make it”. The scope of the project has to match the resources (time, money, team) and that is easier said than estimated. A thorough risk analysis of any project based on what you know, is always a good idea.

The second project was one that I started with my students. It struck me (and this was by no means an original idea) that I could fulfill my game-making ambitions by involving my students in a project. I would have creative control, a willing and enthusiastic team and I wouldn’t have to pay any salaries or rent or bills. They, in return, would graduate with a live title at the top of their resume- if the game did well I’d even pay them! Win-win for everybody! Right?

Lesson #2: Motivation and Vision.

The concept we came up with was interesting enough. A side-scrolling 2D game with a hot-air balloon that would surf air currents, collecting objects and avoiding enemies. It needed prototyping and proving, but it had the germ of a really good game. We had two good programmers who delivered the prototype on time, but by that time the rest of the team was falling apart. We had six artists with creative differences among them, with the result that there was zero output. Design-wise, we were at a standstill. I would have had to pretty much do all the level design and everything else myself, and also hire somebody to do all the artwork. By the time I got around to deciding to do this, the programmers (also students) had moved on to other jobs. It was 6 months and all we had was a very un-fun prototype on the iPad. I decided to pull the plug.


I hold myself responsible- I wasn’t able to motivate my team or ‘Hold the Vision’, and had delayed some crucial project-saving decisions like hiring a 2D artist to complete the work. There was also too much democracy at work within the team, where I let some crucial (design and otherwise) decisions be made by committee that I should have made on my own. If a team member is showing a lack of commitment, give him/her a chance to improve, even two chances. If there’s still no improvement, fire him/her and either do it yourself or get someone else.

There is a initial euphoric phase in every project cycle when everyone is simultaneously motivated and enthusiastic, and there are phases when this enthusiasm starts to flag. Team members quit or fall sick, a few realize that it’s turning out to be harder or taking longer than they expected, and then the question raises it’s head-“Am I wasting my time?” In my experience, every self-motivated project needs at least one team member to be unreasonably optimistic, or at least seem to be- that guy is usually me, but this time that wasn’t enough.