Archive | December 2014

Trebuchete: Post Mortem

Trebuchete is a game developed by four students in Unreal Engine 4, which we decided to use in order to learn more about the engine. The game was pegged as a hotseat multiplayer physics-based shooter, and in this regard, we succeeded entirely. It wasn’t all such smooth sailing, however.

The following is a list of what went wrong, what went right, and what we’ve learned as a result.

What Went Wrong

Inexperience

Nobody on the team had any experience with the engine (Unreal Engine 4), and as such, we were expecting to hit all sorts of unexpected problems. Despite having planned for our inexperience, it was still a significant hurdle for each of us.

While we’d all used the Unreal Development Kit, Unreal Engine 4 was different in many ways, such as how objects are placed and how the in-engine programming worked.

The team encountered difficulty with implementing a smooth camera system, something which is relatively easy to do in other engines. Similarly, creating a large and good looking map was actually significantly easier than in other engines, so it wasn’t all negative.

However,  it certainly slowed the team down. We’d estimated the camera system to be quick and easy to implement, but it ended up taking two entire days. We also had some trouble with the AI, which didn’t work how we’d thought it did.

Finally, our inexperience with the engine also caused some issues with physics-based collisions. We never actually pinned down what the issue is, but managed to get around the problem with “hacks”, by putting lots of invisible walls behind objects that weren’t colliding properly.

So in the end, inexperience did cause certain features to be cut, despite our having planned for it.

Models

While we ended up having enough models to get our initial ideas across quite well, outside influences meant that we didn’t have as many as we’d planned for. This wasn’t a serious issue, but it’s certainly one worth mentioning – we hadn’t done enough planning in case something happened to one of our team members.

As such, nobody was able to step in once we realised the models weren’t going to be finished on time. We still had enough to for the prototype to be successful, but as a result, we didnt’ meet our initial concept.

Lack of Documentation

Our lack of proper documentation didn’t hurt the game itself, but documentation is actually part of the whole project, so improving it should have been a higher priority. In the end, our combined documentation was only about seven pages long, which simply isn’t enough.

We could have allocated more time to documentation, which would have improved both the length and quality. The team was more worried about a completed product, where the actual assessment included documentation, which means that we should have given it a higher priority.

Map Redesign

While this didn’t hurt the game in the end, it certainly wasted some time – halfway through the project, the terrain was rebuilt from the ground up.

This was a decision made in order to improve the final quality, but is also a decision that could have been earlier in order to save time. The map was redesigned in order to improve visual fidelity and world-building, as the previous map made little sense in-game. So while it was certainly an improvement in the end, work on the final map could have begun earlier.

What Went Right

Preparation for Inexperience

As mentioned above, the entire team was inexperienced with UE4. While this was a bad thing in many ways, we were aware of it from the beginning of the project, and took steps to mitigate the issues that would almost certainly arise.

These steps included making many features out of scope, in order to create them only if we had time. The initial design of the game was built in such a way that we could create many additional features while getting the core concept built quite quickly.

While this didn’t work perfectly, this sort of planning helped the game immensely. Had we not prepared at all for our own inexperience, there’s a very good chance that Trebuchete would not have been completed at all.

Graphics

Trebuchete is easily the best looking game anybody in the team has produced, thanks to the graphical power of UE4. While this wasn’t a high priority, the engine allowed us to create a great-looking game without spending extra time on doing so.

Task Delegation

Since we only had two weeks to create this project from beginning to end, task delegation was especially important. Realistically the team could only meet up two or three times throughout the entire project, which we knew immediately – as such, we decided to delegate tasks and minimise essential cooperation.

We were communicating throughout, but each of our tasks were self-contained, meaning that individually our work wouldn’t be compromised if a team member fell behind.

This worked extremely well, as we all worked throughout the entire project, and nobody was ever in a position where they couldn’t create content because they were waiting on somebody else.

The only exception to this was audio, which couldn’t be implemented until everything else was in place – and, as such, didn’t make it into the final build.

Conceptualisation Time

On our first meeting, the team spent about four and a half hours discussing the idea and drafting the initial design. While this is actually an incredibly small amount of time an industry-level project, it’s a long time to draft the idea for a two-week prototype.

It paid off, however. While we spent valuable meeting time on the design, we never had to reiterate, as everything fell nicely into place throughout the project. It also meant that each team member was on the same page, as we spent the time to eliminate all ambiguity and confusion.

What We Learned

Unreal Engine 4 Experience

Each of us gained invaluable experience with one of the best engines that are currently publicly available – Unreal Engine 4.

We all learned different parts, but everyone on the team is significantly more skilled with the engine than before we began this project. Fortunately, this was the entire reason we decided to make the game in UE4 rather than something we were more experienced with – such as Unity – and it paid off.

It’s hard to go into specific details here, but essentially, we all learned useful skills in every facet of the engine. While none of us are advanced users as of yet, we’ve all improved a great deal in the two weeks since we started.

Value of Planning

This is something that comes up in every project, but is also easy to forget. Planning is incredibly important to a successful project, and time spent planning is time saved later.

For every hour spent planning, we’d save about two hours on work.

The problem is that it’s hard to find a good balance when there’s such a small timeframe – it’s easy to think that in a two week project, spending too much time planning can be a bad thing. And it’s true – if we spent an entire week planning, we simply wouldn’t have the time to implement half of what we did.

However, we underestimated the value of planning, and if we had spent more time on figuring out how to implement certain features it may have improved the project.

This is something that is harder to get right on smaller projects, but is incredibly important regardless of size and scope.

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.

tumblr_inline_ndkcrnyReP1r1namd

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

Happy business people

* 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

Angry Businessman Yelling into Phone

* 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!

( http://www.brilliantlyepic.com )