Postmortem: Reverie

Roughly nine weeks ago, three other design students and I got together and planned out a game to make for the rest of the trimester (eventually, we were also joined by two audio designers and a programmer). After much deliberation, we decided on a first-person exploration game with a heavy focus on narrative, utilising the Oculus Rift. We decided to build this in Unreal Engine 4.7.2 - at the time, Unity 5 had only just been released, and we decided to go with UE 4 because of the improved visuals and easy Oculus implementation (as well as a few other reasons, mentioned below).

Reverie - the name of our game - tells the story of a woman who's been a serious car crash, and allows the player to explore an abstract imagining of the events leading up to this collision. The following is a relatively brief list of what I feel went right, what went wrong, and how things could be improved in the future.

What Went Right

Despite some (honestly, quite serious) technical hiccups, I think a lot went right, and our final product is something I'm proud of. Our team of attractive stock photo models (pictured above) all worked well together and collectively we've all put a lot of hard work into Reverie, which I believe shows. I'll detail what I felt went right during development in this section.

The Idea

This is kind of an easy one - everyone thinks their ideas are good, but honestly, I think Reverie really is a good idea. The idea of exploring surreal landscapes to get clues about what happened and led to this point is something I've always loved, especially in that it's an experience unique to games as a medium (that is, environmental storytelling). Reverie was an idea that was both interesting to play and develop, while being reasonable in our time frame and skillset, and I consider it a big win.

It was easy to develop because it was very light mechanically, meaning we focused mostly on level design and asset creation, allowing us to make a relatively large game quite quickly (again, about nine weeks). Developing a game with a focus on narrative without any written words and only a handful of voiced lines was also a great experience, and I think it's safe to say that each member of the team learned a lot during the course of development.

The Engine

While we did have some technical issues with UE4, most seemed to stem from us, rather than the engine itself - and the game couldn't have turned out this well on another engine. The easy Oculus Rift implementation cut down on programming time (because there's literally none, UE4 supports "plug'n'play") and the engine is simply beautiful, which is a great help for a project like this one. We've also learned a lot about the engine, and since most of the team was more experienced in Unity, I think this was a big win all round. Learning a lot about a new engine and having the product look better was worth the pain caused in the final hour of development (which I'll stop alluding to and let you read about below).

It was because of our inexperience with the engine that ultimately pushed us to choose it. We were initially blown away by the visuals and ease of some features, but having used UDK previously, we were well aware of some potential issues. It was because we wanted to gain experience with new engines that we settled on Unreal, as we would have potentially learned much less if we'd gone with Unity 5.

The Team

As a team, we worked well together. All the designers and the programmer were in constant communication throughout the project, and without such a level of communication this project wouldn't have been possible. Any potential issues were brought up and discussed immediately, and ideas were thrown about freely. Nobody had any issues with other teammates, or if they did, they didn't bring it up or let it affect their work. It was said from the beginning that if someone were to have issues, they should bring it up, and the fact that nobody did is (mostly) encouraging. Amongst the designers and programmer, there were no hiccups in communication or teamwork.

The Scope

While this could probably fall under "The Idea", I felt enough extra work was done on scoping the game to be worth mentioning it another section. Our game consisted of five major levels - a hotel, a museum, a garden, a barn and a lighthouse. However, only the hotel, museum and lighthouse were truly essential to the plot. Cutting any of them would have been a shame (and we didn't have to, the garden was completed way ahead of schedule and the barn made it in, though barely). We decided on a priority, with the barn at the lowest end - as a result, the barn did make it in, but it was missing half of the features we'd envisioned. Still, it's better than no barn at all, and it's thanks to this scoping and prioritising that the project made it to the level of quality that it did.

At the outset we knew we were going to be pushing it for time, and we were - but almost all of the content we wanted made it into the game, which is rare for any creative project.

What Went Wrong

The Audio

Audio is a large component of Reverie, as it encompasses all the player cues (which was a mistake we were aware of, but never had time to fix) and a decent chunk of narrative clues. We immediately realised that audio was a high priority, and went about recruiting two audio designers to the team, for both design and implementation.

Unfortunately, things went astray. They both ended up having to defer for different reasons, and weren't able to finish the audio - unfortunately, this happened relatively late into the project, meaning we had to scramble to get the audio done ourselves. We found great success in FMOD, which enabled us to quickly insert and edit audio into the game. Unfortunately, we didn't account for FMOD's weakness; when opened on another machine, Unreal requires FMOD is installed for the audio to work.

This wouldn't be an issue once the game was built, but because we had four designers and a programmer, it was a problem. We barely managed to get our audio in the game at all thanks to a last minute rush, and even then none of it was polished to a high level of quality.

Optimisation

Optimisation hasn't been at the forefront of concerns while developing games at university - in a workplace environment, it's much more important, because games need to run on multiple devices. At university, however, it only needs to run on a single fairly decent computer (maybe two or three at worst), so optimisation quickly falls to the bottom of the priority list.

At least, that was the case with Unity. Unreal 4 quickly becomes much more demanding, and the file size grew exponentially out of control. We managed to cut down on this eventually, but we could have saved ourselves a lot of time during development by keeping a closer eye on optimisation.

Glitches Galore

This was the big one, and it ended up screwing us pretty hard (excuse the non-academic language, but it's apt). At the end, just before our first exhibition, we tried to package the game - and nothing. The package failed. We ended up trying on four different machines between us, on different copies of the project, and nothing.

We're still not sure what the exact issue was - according to trust Yahoo answers, Epic Games is "aware of the issue and looking into it", which is a few miles south of reassuring. This may have been (and probably was) our fault, rather than the engines, but having no idea what could've caused it or how to fix it was a nightmare. At the time of writing, this issue hasn't been fixed, and the project is, sadly, impossible to package. Possibly in part due to our poor...

Engine Version Control

When we were writing the Game Design Document (or GDD), we knew what every game designer knows - the team should only work on a single version of whatever engine you were using. In this case, we'd all decided to work on Unreal 4.7.2, as that's what the computers on campus were at the time (at the time, it was also the latest version).

Unfortunately, some members of the team had the misfortune of having Unreal update itself, which was a problem compounded by the computers at university inexplicably being updated to a much newer version mid-trimester (if you're reading this, person-in-charge-of-updating-computers-at-university, please put a stop to that).

In the end, we all updated to the newest version, but the damage was well-and-truly done. We didn't run into any obvious or major compatibility issues (the minor #.#.X updates aren't so bad), but there's still every chance it caused some of our issues.

What We've Learned

As usual, this section essentially explains that we'll avoid doing the things listed in the "what went wrong" section while continuing to do the things in the "what went right" section, but with a bit more detail. As should be the case with every project, whether at university or otherwise, we've learned a tonne from creating Reverie.

Control The Engine Version

This was, possibly, a huge issue. It's not anyone's fault, but it's something we need to keep a much closer eye on in the future. It's partially because UE4 is a nightmare to roll back to an earlier version, meaning if something updated automatically or accidentally, we were out of luck. We'll need to see about Unreal being updated on campus, but working from home, I'm confident we've all learned how important it is, even if we haven't quite figured out the best way to go about controlling it yet. It's not as straightforward as simply never updating when we're using several machines, some of which are public - avoiding these computers altogether isn't really an option, either.

Mitigate Personnel Issues

We didn't have enough plans in place in the case of team members dropping out, and that ended up hurting the project. Since we lost two audio designers, the audio suffered - this is a bit of a no-brainer, but it suffered more than it needed to due to lack of preparation. This is a simple one that always comes up; plan more. Or rather, plan efficiently - team members leaving or being unable to work is an issue that needs mitigating immediately, so future planning needs to be prioritised with this in mind.

Package Early, Package Often

This probably wouldn't have fixed our issue, but it would've allowed us to pinpoint it. We still don't know exactly why the packaging is failing, and packaging early to have multiple builds could have helped us immensely. This goes back to the planning - package milestones should be set up, so we get a new packaged build every two weeks or so.

And, that's it! I'd like to write a more detailed post, as not everything I wanted was in here, but I'm nearly the 2000 word mark and have too much to do right now! There's a chance I'll revisit it in more detail in the future. Thanks for reading!