Game Design, Programming and running a one-man games business…

Why I ‘Like’ Developing Redshirt

(Guest post by redshirt developer Mitu Khandaker)

So, Cliff asked me to blog my thoughts on developing Redshirt so far. My response as I sat down to try write this was “Gosh, where do I start in talking about this massive project that has been my life since last summer?

After all, I’d been a videogames PhD researcher, and I’d worked on smaller things before (as well as bigger, non-gamesy things), but Redshirt is my first proper commercial game project. Its origin lies in an idea I’d had – social networks govern the daily lives of so many of us now, and give rise to their own set of micropolitics and behavioural quirks, so why not make a simulation game about that? I briefly talked about the story of pitching the game to Positech in my first dev video, and how it evolved into Redshirt, so I won’t go into that here, but, as of 15th June 2011, I put cursor to code.

Making the Best of Highly Illogical Decisions
I’d opted for Unity as my development tool of choice, because I’d used it comfortably for smaller, throwaway personal projects and was definitely enamored with how it expedites things. As someone who insisted on Notepad for years when I was doing web programming, I certainly understand the impulse to shrug off fancy IDEs and editors and such, but I knew with this project, I’d have my hands full with PLENTY of challenges anyway, so, I wanted to make life easier for myself by using Unity.

Or so I thought, anyway. The thing is, Redshirt relies heavily upon its user interface; it is, by nature, a very UI-centric game – which meant that Unity’s notoriously lacking built-in GUI system wouldn’t cut it. Unfortunately, the available third-party solutions also didn’t do exactly what I needed them to do, or were otherwise incomplete in many ways. I ended up writing so much custom functionality anyway, and doing more work on fixing the UI than I’d anticipated; there was that time, for example, when I spent a whole long weekend fixing scrollbars. Scrollbars, of all things.

Of course, once they were done, I felt a massive sense of achievement – and, that’s something else this project has taught me. The motivational peaks and troughs that come with getting things working which no other sane person will even think about twice.

I’ve Got a Bad Feeling About This
While I expected plenty of challenges (and wow, did I get them!), I did not prepare for stretches of time where progress just felt so slow. This happened around months 3-6, and things felt largely like trying to run through a pool of really thick, viscous liquid.

Around this time, I’d been busy working on implementing the Spacebook (more work than I’d thought it’d be, naturally!), but a lot of the other functionality remained unfinished, and things were taking massively longer than I’d projected.

I’d drawn out a huge, elaborate, multi-faceted system in the game, a lot of which still needed to be properly implemented. But, after numerous discussions with Cliffski, we decided it simply needed to be pared down for the sake of actually finishing the game on schedule. And, y’know, for my own sanity, too. This actually turned out to be a good lesson in practicing/really thinking about subtractive game design ( (For the record, the main thing that was taken away was the currency system on board the station, because it wasn’t adding much valuable depth to the game, really. Who needs these things in a post-scarcity society, right?)

Often, things still feel fairly painfully slow to progress, but either I’m used to the feeling it now, or I’m slowly coming out the other side, and seeing things come together. Either way, the thing that gets you through those periods is really loving the concept of the game, and what it’s trying to achieve, and knowing it just needs to get made.

The View from Orbit
Of course, the perversely funny thing is that all the focus I’d been putting on worrying about systems, and how they would interact, sort of came second to the feeling of the game ‘evolving’ when things happened which I thought should be inconsequential, or secondary. Like adding sound, or avatar animations, or seeing the UI mockups from our wonderful artists. It was an odd sort of experience, which made me refocus on the fact that games are these magical things that somehow feel like more than the sum of their parts.

And, oddly, no matter how much work you put into your own project, when someone else does a good job on part of it – like with the game’s logo art, for instance – it somehow makes it feel more real!

All of this means, though, that I’m getting to a stage where I’m beginning to feel that there is an actual game amongst all the mess I’ve been staring at for months. That is a good feeling! Right now, as I write, the majority of the core functionality exists for the game already; I’m working on character creation, and adding a few things to the Spacebook feature. Next, it’ll be a matter of adding a load of content – and, at the same time, beginning to incorporate the flashy new UI designs. Then, it’ll be more art, and a whole lot of testing, no doubt.

On the whole, I’m happy with how Redshirt is shaping up, and I look forward to sharing more about the game soon!

7 thoughts on Why I ‘Like’ Developing Redshirt

  1. If Unity wasn’t exactly the best out-of-the-shelf solution due to the lack of GUI stuff, why have you still decided to use it? There are a-plenty other options around :).

    Could you elaborate more on character creation – stats\skills side a bit? What kind of detailed is planned? Are there going to be “throwaway skills” like in Kudos that are only useful for unlocking certain stuff like jobs, or are they deeply rooted in the gameplay?

    Keep up the good work!

  2. Well, I’d already put a lot of work into the project before it became entirely apparent how many shortcomings there were of the third party GUI solution I ended up using; scrapping the codebase by that point would’ve been a lot of work, so I decided to chalk that one up to experience and push on. :) I am still taking as much advantage as possible of using Unity now; for example, we were going to use 2D character art for the player avatar, but instead, we decided to go for a 3D avatar, with lots of animations and such depending on how the character is feeling, etc. It makes a big difference to how the game feels (as most of the game is UI-driven), and is obviously made much easier because of using Unity!

    As in Kudos, there are a number of personal stats/attributes (though the actual attributes are different from Kudos), and also a number of skills useful for unlocking jobs, yes – these are gained either through career stuff (going to work), or doing social activities, etc. I can be more detailed once we start posting screenshots and such!

  3. Isn’t making a 3D avatar actually more time and asset demanding task, than a 2D one?

    Could you please try to avoid the most boring design choice of the Kudos – job-only skills? One of the main joys of stats-based games is the feeling of how your character becomes better: skill increases wield a noticeable change. Limiting them to merely unlocking something (be it jobs or equipment) feels lazy and uninspired.

    Thanks for the replies :). I’m waiting eagerly for your game and hope it will be everything Kudos wasn’t… (I held high hopes for it, but was wildly disappointed in the end)

  4. Depending on the amount of animations you’ll need, a 3D character can be more effective than a 2D one. The main hurdle of a 3D character is building the model and texturing. After that, you can animate it a look quicker than having to draw X number of individual frames for the 2D character.

  5. There’s so much middleware supporting 3D characters for Unity now that creating something like a 3D avatar system is relatively trivial, especially when it comes to animations and so on. Using that stuff as a shortcut has been been a huge time-saver for my games.

Comments are currently closed.