Archive | November 2014

Latest Project

It’s been a while since my latest post, and I’d like to chalk that up to being unbelievably busy, with a side of deep-rooted laziness. Since my last post, I’ve worked as part of a group to create a brand new project – a prototype of a game that I pitched, and we built as a team.

It was the first real team work I’d had in game design, outside of working in pairs. Sure, I’ve done plenty of work with one other person, as well as plenty of work related to game design in groups, but this was the first time I’d sat down with more than one other person and used Unity to create something.

And, it was great! Our team worked well together throughout, without any real hiccups. I was happy with our end product, and with how we performed. This post is going to server as a kind of post-mortem, which probably isn’t so exciting for you readers, since you didn’t know this existed until now. Sorry! My next game is nearly completed as well, but I promise I’ll post about it before it’s finished (maybe).

So, as a brief intro, the game was always pitched as “a reverse stealth game”. The idea was that you played as a security guard in some kind of ambiguous complex and had to guard certain areas from sneaky infiltrators. I wanted to play on the tropes of typical stealth games like Splinter Cell or Metal Gear Solid, while putting a new spin on them – in the strictest of senses, I don’t think we quite succeeded here, but I think that was because we were only prototyping at this point. Anyway, more on that later.

The game was shown from an isometric point of view, with the entire map visible at once. However, most of the map was covered in complete darkness, preventing the player from spotting the infiltrator. There were lights facing certain directions, and these could be manipulated – thus, the idea was to manipulate lights in order to guard areas that you couldn’t guard physically. Beyond that, the player also had some traps to help out, such as a motion detector.

The player would win if they could catch the “thief” and tase them (bro), whereas the thief would win if they reach the treasure and then get back to the exit. The thief could also escape from air vents scattered about the rooms and would then reappear from a random one, adding a great level of chaos to the game.

The following is a list of what I feel went right, what I feel went wrong, and how I think we could have done certain things differently.

What Went Right

The Idea

This idea was unintentionally great. I mean, sure, I obviously tried to make it a good idea – but the reason I was so happy with it was unexpected.

Essentially, I tried to design a game that could be functional extremely quickly, with everything else being optional. This would allow us to develop the game quickly in our given time frame, while also allowing us to improve in areas where we felt it was needed.

What I wasn’t prepared for was how efficient our team was, basically. On the second day, our game was completely functional. Lights were working, controls were working, AI was working (though rudimentary, at that point) and traps were working. Our game was playable, and we had two and a half weeks to polish and iterate.

It’s definitely a type of design I plan to use in the future. I’m sorry if this doesn’t go into too much detail on how it was designed that way, but I feel like that could be a whole blog post in itself (and very well may be), and this post is already going to be a fairly big one.

The Team

Our team worked together extremely well – everybody was working hard and promoting ideas, while not being afraid to express concern at ideas they didn’t feel worked well. I’ve always felt that it’s absolutely paramount that people express their concern – as long as they can provide valid reasoning. If people sit on their problems, it not only prevents that problem from changing, but often leads to intra-group conflict.

In this project, we had none of those problems, and all worked well together. We were organised and efficient, and I’m glad it turned out that way.

Unity Lighting

The biggest issue with my initial design document was that it totally relied on real-time lighting, which I’d never actually used before. Luckily, the lighting in Unity (Pro) is great. Shining a flashlight around a corner looked fantastic, and throughout development I’d frequently find myself just playing with the lighting for no reason other than enjoying how it looked.

I consider this ‘something that went right’ because the entire project hinged on it, and it was a complete and utter success, though I’ll concede that it wasn’t due to the hard work of the team or our cleverness (that stuff just helped).

What Went Wrong

The Documentation

I actually have several things I’d like to add to “What Went Right”, but this post is already fairly lengthy, so I’ve tried to keep it short.

Here, we definitely suffered a problem with our documentation. I don’t feel the project suffered as a result, but we only had very rudimentary documentation throughout the project – just a very simple three page design doc.

Sure, we were only creating a prototype and it was honestly enough to get us by. However, if we don’t practice proper documentation while we’re at university, we’ll never get a chance to (until our jobs are on the line). So, in the future, I definitely plan to put more time and effort into documentation.

And, uh…That’s it. I sat here for a while trying to think of something I wish we’d improved on, but it wouldn’t come. Sure, the game could certainly be better – but for a three week prototype, I’m very happy with how it turned out.

What I’ve Learned

I’ll just keep this to a single section, with no sub headings.

One major thing I learned was how important core design is to the scope of a game. I know most people would read that, sit back in their chair, and say something eloquent like “yeah, no shit?”. But, having heard that and having experienced it are very different. Because of how the game was designed, we were able to create functionality and spend the bulk of our time on iteration and polish, which is the reason I believe our game turned out as well as it did.

That, and our awesome team work. I actually haven’t been able to pin down why we worked so well as a team, but it was very easy to stay in touch with everyone, and we were all working hard. It’s very possible it was something as simple as just getting into a group with good designers, so I’m not sure that really taught me anything – don’t get into groups with bad designers? That’ll do.

That’s about it, for now. I know, I know – it isn’t the best or most detailed post-mortem, but I wasn’t even initially writing this post to turn out this way, it just kind of happened. Also, I’m sorry I couldn’t provide any screenshots of the game – I don’t actually have access to the project from the computer I’m writing on.

On this coming weekend, I’ll provide more details on my latest project (with screenshots!) and how it’s going along. since I’ve been so slack on these posts, I’ll also be able to provide a post-mortem for it a couple of days later. Look forward to it!