First Snow: Post Mortem
So, again, I haven’t been updating as I’ve been developing, though this time I’ve been swamped with other work, and as such the project suffered. I don’t regret it – I was just busy, not negligent, but I’m a bit disappointed all the same.
The latest project was called First Snow, and in a nutshell it was a Hotline Miami-esque game with heavy overtones about violence in video games. It wasn’t meant to be preachy – the game wasn’t criticizing or glorifying violence in games, but was designed to generate discussion.
I thought of the idea after I saw the (reaction to) trailer for Hatred, an upcoming game from Destructive Creations, due in 2015. Hatred is an isometric twin-stick shooter, about a man murdering strangers for no real reason. As expected, this triggered a huge outcry (and generated loads of publicity for the game); what got me thinking was that this outcry was magnitudes higher than when Grand Theft Auto 5 was released.
Yeah, yeah, I know – GTA has always had some bad publicity, and you can do some truly awful things in the game. But when I asked people why they thought Hatred was so bad and GTA was (relatively) innocent, they all answered with a similar response – the narrative of GTA isn’t about mass murdering civilians, and if players do so, it’s entirely at their discretion.
This totally baffled me, because the way I see it, that’s so much worse. If the narrative of a game is compelling players to kill people (as in Call of Duty’s famous No Russian level) people seem to be upset by it – but when they can do it of their own free will, suddenly it’s okay.
I don’t want to go too much into this (and I don’t want to mention where I stand on this subject), but essentially this whole experience was extremely interesting for me, and I wanted to get more opinions on it. As such, First Snow was designed as a game that wasn’t inherently violent in the narrative, but had some extremely violent subject matter.
What Went Right
* The basic gameplay. Originally, the game was designed to be very much like Hotline Miami, albeit on a much smaller scale, in order to be quicker to develop. This actually turned out pretty well, and frenetic trial’n’error shooting was genuinely fun to play. Losing wasn’t too painful, and you could make another attempt again immediately. There were some polish issues, but more on that later.
* The first week. This one probably gives you a good idea of what went wrong, but the first week was really solid. The game was functional extremely quickly, and it looked like we’d not only get the game finished in time, but manage to make it extremely polished. I can’t pin down a specific reason for this, but everyone on the team did good, quick work.
What Went Wrong
* Project File Management. This is a huge one, and it’s the first time I’ve experienced a serious issue with it. It’s something I’ve heard of and have been warned about – it’s also something I’ve taken steps to prevent – but on this project, it really hit us hard. Our project files were a mess, and our version control was terrible. As a result, we spent a huge amount of time combining files, scenes, assets and scripts, which (ideally) would have been quick and painless.
* The message. In the end, I don’t think the message made it across in any capacity. The idea was to have a game that generated violence about discussion in games – as it is, we have a game that’s “a bit violent, I guess”. Because of time constraints, we didn’t really manage to get our ideas across. This was largely due to our next issue;
* Assets. As a student group working on a student assignment, we didn’t particularly want to pump out money in order to make the game look great. As such, our game didn’t look great (I know, right?). Unfortunately, the game relied on particular animations and graphics in order to deliver the intended message. We took some neat shortcuts – enemies would lose limbs or their head when hit – but we couldn’t make it look very violent. I know how that sounds, but everyone looked more like they were made of lego, and less like they were being brutally murdered.
* Workflow. Our workflow suffered, especially during the second week. All of the team members were busy for one reason or another – I can’t speak for the others, but I was working away on another assignment that had to be completed two weeks early. This hurt the project the most, as our second week was basically non-existent, which is brutal in a three week project. We also sort of gave up during the third week when we realised that we weren’t’ going to get most of our work done in time, which was obviously not the best idea (though I’d argue also wasn’t intentional).
* Documentation. During the second and third weeks, I realised that we weren’t all on the same page about what the game was about. This was largely due to lack of (or poor) documentation – something I mentioned in my last project. As a result, the project I’ve started today already has solid documentation planned, as it’s something that I (unfortunately) don’t get to neglect, on any level.
What we’ve learned
* Do your docs! Documentation is important. On a small-scale project like this, I’ve realised that docs are every bit as important as in major projects – the difference, in my opinion, is scale. They need to be just as detailed, with everything from the narrative to the texture size in pixels, but smaller games will probably have smaller docs. To anyone who’s still in the early stages of game design, I’d recommend practicing proper documentation now – though I’d also say that if you can’t see any feasible use for certain aspects of documentation, they’re not worth doing at present. This sounds controversial, but I’m not going to go into depth about my textures if I’m entirely using textures that are built into a third-party engine – though I will mention that’s the case. In short, docs are vitally important – but so is time.
* Don’t rely on assets. This is especially true in a rushed or student environment, where time and money are extremely limited. Ideally, a game wouldn’t rely on specific assets, as this causes all sorts of problems. Unfortunately, nobody on our team was a graphic designer or 3D artist, so we had to rely on the Unity asset store. I absolutely love the asset store, but it didn’t have anything that suited our needs (at least, not for cheap). This really, really hurt the project, and I’ll rely less on assets I don’t already have in the future. It sounds obvious, but it really is something to keep in mind.
* Plan for file sharing. Our planning for file sharing basically amounted to “nah”. We noticed this as soon as we tried to share files, as you may have already guessed. I don’t want to go into details (as deeply exciting as file sharing woes are), but suffice to say it didn’t go well.
* Get on the same page! This ties back into documentation, but it’s very important to note that all team members should be on exactly the same page about where the project stands. Everybody should agree on what the game is about, what it should be like when it’s finished and how to get there.
And that’s it! I probably could’ve broken these down into specifics, but I’m long overdue for one my amazing reviews for http://www.brilliantlyepic.com. In case you weren’t sure, this is a shameless plug, and you should totally check out their website, at http://www.brilliantlyepic.com.
Thanks for reading!