The making of StarTrail

I hear this all the time from people (who don’t make games): “I’ve got a great story for a game!”. This supposes that the story (or theme or fiction, as you will) is central to a video game. It’s usually not. In most Agon/Alea dominant games the fiction of the game world is secondary to the gameplay and strong, interesting mechanics.


The first name we thought up for StarTrail was actually StarMiner. Actually, it was Shape Shifter, which was kind of a working title. Once we saw that the prototype was reasonably compelling, we started thinking of the fiction/game world. This was important because we had to start creating art assets. For 2D art, I managed to rope in Sanjay, who used to work with me at Gameloft (and still did!) I didn’t know him well back then, and I remembered that he was the guy always looking at pictures of semi-naked women on the Internet. It turns out that was a study of female anatomy – he’s not like that at all.

In case you missed it, here’s the release trailer of StarTrail:


In this post, I will try to reflect upon a few design choices that were made while making the game.



Here’s a mockup of the screen that I made during the Pre-production:


And here’s a screenshot from the actual finished game:

2012-10-28 11.19.09

To illustrate the iterative design process, I’m going to focus on one example where we changed our Power-Up system during early production. In the mockup screen above, you will see a HUD to the right with “Power UP” on top, with a vertical series of symbols. This was the initial system of activating the Power-Up (during the Power-Up, the spaceship would speed up to twice the speed and be able to pick up all objects irrespective of shape or color).

This system required the player to look at the sequence of objects and colors indicated on the HUD and pick up the exact same sequence to activate the Power-Up. As soon as one object in the sequence was picked up, it would be greyed out indicating the remaining ones that were needed to complete the sequence. If the player picked up anything out of sequence, the sequence would reset.

This did not work, for reasons that now seem obvious. Playing the game (well) required the player to keep her eyes glued to the scene, picking up objects that got larger with time. There was not even a split second to spare, to divert one’s eyes to another part of the screen and actually memorize a sequence of objects and colors. Doing so meant….well, death. During play-testing, players simply ignored the bar to the right and continued picking up objects in sequence. The Power-Up had become an unused accessory.

Here’s an early in-game screenshot with the “Power-Up Combo” visible to the right. The left sequence shows the current sequence of objects picked up.


Once I realized that this was not working well (at all!!), I needed to come up with an alternative way to activate the Power-Up without taking ones eyes off the screen. After some brainstorming with the team, I figured that one way would be to make a particular object the ‘fuel’ for the Power-Up, and that would logically be the ‘Energy Spheres’. We implemented the present system of charging up the Power Bar using the energy spheres, and that worked quite well!!

Powerup full

Above, the Power-Up bar is ‘full’ and the round button at the bottom is ‘flashing’, inviting the player to tap it and unleash the Power Up.

I wanted some degree of depth and replay ability to the game, and as that’s not easy to achieve in an endless runner (or flyer!). This was done by:

1. The PowerUp, which is activated by filling the PowerUp bar, which in turn needs energy spheres.

2. An upgrade purchase system for the spaceship that rewards extended play…

Upgrade system

3. A Pickup that temporarily enhances the abilities/performance of the spaceship….

I introduced a ‘Mystery Box’ that spawned every 1200 points or so, which gave the player some or the other temporary ability like a shield, or instant PowerUp.

We also went through a few iterations of our HUD. I now knew that the player would almost never look away from the trail of objects on the screen towards another element like the score or fuel gauge. I therefore decided to group together as much information as possible in one place-the top-right hand corner of the screen. Here are some options that we were offered by Sanjay:

  HUD options

HUD option

A Game is born

So, brushing aside past failures, I embarked on a new project. I announced to my diploma class (consisting of all of four students) at BSP that we would be making a game.

The scope of the project:

1. A small, simple game that we would release for free on iOS and maybe Android as well.

2. The environment would be 3D and be art-light. I had realized from past experience that making a game with 2D art (sprites) was quite difficult with the resources I had.

3. We were looking at a production cycle of approximately three-four months, apart from pre-production and marketing.

4. We would be using Unity 3D.

After this, we spent a week or so pitching various game ideas, and we narrowed it down to three that we liked best. I promised to make concept documents for all three and we dispersed for the weekend.

On Monday Satish, one of my students, came up with this prototype.

It was the concept that we had liked best, and Satish had prototyped it over the weekend….! It was tentatively called ShapeShifter, and was based on collecting objects of different shapes and colors in sequence. I called it the UNO mechanic, after the popular card game. The player would move left and right across the tracks(trails?) colliding with, and avoiding objects. It would be possible to ‘levitate’ above the trails, but this would be an ability limited by time and usage.

It was essentially a high-scoring ‘Free-runner’ where the game got faster and faster till you died; the environment (pickups/objects) would be dynamically created. There would be a lack of depth in gameplay but as my wife says, “That’s what’s we have for dinner.” If we could pull this much off, it would be a miracle.

The important thing was that we had a prototype with a fun core mechanic. Now we needed to add a universe, some fiction and as much depth as possible.


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.

In the beginning

My first experience of making a game was at Vancouver Film school. I was one of a five-man team, and we took five months or so to make a wacky little side-viewing 2D game using Flash where you control two characters: Wally, the one-eyed Vampire Walrus and Joe, the seven-armed Pirate Octopus. Behold the trailer:


My primary role was level designer, but I also got to write some of the low-level code in AS3 and created most of the the 3D/2D environment assets. It was a wonderful, nerve-wracking, back-breaking yet exhilarating project, the lessons of which are still seared into my mind.Prime among these: Keep The Passion and Mind The Scope.

After graduating from VFS in June 2009, my aim was to find work in the video game industry in Vancouver, a task made very difficult by the fact that I did not have a work visa. While I looked unsuccessfully for a company that would not only be willing to hire me straight out of design school but also make the (extraordinary) effort to sponsor me for a work visa, I put my ‘other’ skills to work trying to make some cash.

First, I thought I’d making my fortune picking blueberries. It’s a thing in BC- you go to a farm and they give you a trough. Pick ripe berries all day, and you get paid by the kg. Turned out that I spent five hours and twenty dollars commuting to the farm and earned thirty dollars picking berries. I decided to seek my millions elsewhere.


I was good writing resumes, so I started by plastering these flyers all over downtown Vancouver and posting ads on Craigslist. I used to meet clients at Starbucks, get their details and make their resumes, cover letters and bios, at $30 a pop. “The Perfect Resume”, I called it.

I was starting to make half-decent money at this when a resume I had written for myself hit the spot.I was ‘hired’ as a QA Intern at Piranha Games. I worked 9 to 5 Monday to Friday, for free, testing a PS3/PC/Xbox NASCAR racing title for four months. It was a good gig, all the same. I got to participate in a live project, participate in scrums and work with some really smart developers. Also, free Coffee, Bagels and Cream Cheese!! The pantry was always well-stocked.

After this, a resume I had posted on caught the eye of some HR folks and I moved back to India to work as game designer at (the now recently deceased) Gameloft Hyderabad, where I handled the the transition from a single-screen mobile phone to the dual-screen Nintendo DSi of these two games:

Crystal Monsters (Nintendo DSi)

Date or Ditch (Nintendo DSi)

I had to re-do most of the screen layouts and figure out what to put on two screens that was previously on one, write some design documentation and make some decisions on graphics updates. Not really the forefront of creativity, but at least it said “Game Designer” on my employee ID. Right after this, the studio stopped doing creative work. After spending six months on Facebook and playing Left for Dead 2, I was shifted into Production (porting). I quit within two months.

“I’ll make my own games”, I said. 

Just before I quit, I’d started teaching game design part-time at Backstage Pass school of gaming. I would teach the Diploma class after work, from 7 to 9PM. It was great, because

(a) I got to interact with students that played waaay more games than I did.

(b) When you teach, you’re also learning- for yourself, and your students; it’s a two-way interaction, and

(c) I now had an alternate source of income. This turned out to be a crucial factor.

The other significant development was that I had decided to start a business of my own in cooperation with a family friend. It had nothing to do with games or even software- I’d supply frozen food to hotels and restaurants. At that time, I imagined that I’d do it for a while- a year or so, and then get into making games full-time. It’s been two years now, and I’m still doing it.

MNR Card-1