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
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.
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.
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.
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.
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.
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.