About 6 weeks ago, another designer and myself sat down to plan out a relatively quick project. After a bit of discussion, we knew we wanted to make an Oculus rift game in Unreal 4, if only because it’s an area we both take interest in. We ran through a few ideas before looking to “Keep Talking and Nobody Explodes”, which is where we got the basic idea for our game.
The idea of using an Oculus to blind a player was really interesting, but we wanted to do enough to separate our game from Keep Talking. Whether or not we did is ultimately up to you, but I’m very happy with the end result of our game.
Sol Solutions is a cooperative multiplayer puzzle game, where one player (the “Overseer”) has a set of physically printed instructions, and player 2 (the “Engineer”) sits inside the Oculus Rift and tries to fix the overheating engine of a spaceship before it explodes. They do this by moving a set of blocks into the right locations – locations only known to the Overseer, who has to navigate the poor IKEA-like instructions to find the solution and then communicate it to the Engineer.
The following is a list of what went wrong, what went right and what we could do improve our development cycle in the future.
What Went Wrong
Increased Team Size
Initially, Sol Solutions was designed with the knowledge that we were working with a relatively small team of about 4 people. Afterwards, more people joined us – eventually, three new team members came aboard. This isn’t ordinarily a problem, but our design never changed to account for the extra hands, and a lot of us ended up having little or nothing to do throughout the project.
On one hand, this is great, because it meant we were on top of the project throughout. On the other hand if we’d increased the scope of the game we may have had a bigger game with the same level of polish, or even just a more polished version of what we actually ended up with.
The bulk of our gameplay comes down to interacting with an in-game grid, where the player inside the Oculus has to build lay out a series of Tetris-like objects in a certain order; the trick is that the exact order is only known to Player 2, who can’t see what the other player is seeing. This hectic miscommunication is absolutely key to the gameplay and actually works really well. Where we went wrong wasn’t with the design of the grid-based system, but that we underestimated the complexity of implementing one.
It turns out that creating a grid system like ours takes much longer than initially predicted, and in the end it wasn’t at the level of polish we wanted. To be clear, this wasn’t brought about by unskilled programmers or lazy designers, but the underestimation of the sheer amount of time the grid took to implement. Luckily, this was mitigated in the project planning, so we had the extra time necessary to get it to a working state; it’s just that more time would’ve been optimal.
The Win / Loss Rate
Typically, games tend to try for a very positive win / loss ratio – people enjoying winning, and if you want to make money, you want people to enjoy your game. This is obviously a generalization and doesn’t apply to all games (say, Dark Souls), but I still think ours could have been improved – at the moment, no team has ever successfully completed our game.
Or, rather, nobody has successfully completed the latest iteration. In earlier versions our instructions were much more straight-forward, and we had the opposite problem where everybody was winning with ease – since then, we reduced the time limit by a minute (to 4 minutes, down from 5) and made the instructions much more annoying to navigate.
I’m not sure this is necessarily a problem, though. In testing we’ve found that the teams that perform better were actually having less fun, or at least having less obvious fun. The appeal of Sol Solutions lies in the chaos of miscommunication and the pressure of a time limit – people that manage to stay calm tend to have less interest in the game, but it would be nice if we’d managed to strike that fine line between people feeling the pressure but pulling a last-minute win.
Either way, a (very) negative win / loss ratio isn’t a problem – it’s just ours is perhaps leaning too heavily to one side.
What Went Right
Sol Solutions looks great, thanks in no small part to Unreal 4. The models, lighting and particle systems are beautiful, and the game looks much better than typical student projects, or even some successful modern games. Having such a small environment helped tremendously, as did locking down the level design to a single designer, rather than splitting it among the team. This is a real strength of Unreal as an engine, but seeing these lights on motion (and the insane amount of lens flare) is fantastic.
Sol Solutions is a genuinely fun game to play. The core gameplay loop is simple enough for anyone to understand, while being chaotic enough for anyone to have fun. It’s hard to imagine a game about reading badly-written instructions could be fun, but hearing a robotic voice announce your imminent demise as metal creaks and your friend starts to panic is way more enjoyable than it has any right to be.
At it’s core, the gameplay is extremely simple, in that both players have one simple objective – the Overseer has to organise and read instructions to the Engineer, who just has to follow them. But have you ever tried to explain an idea to someone? Have you tried doing it when you have no idea what your idea is? It’s not so fun in the real world, but in Sol Solutions, it’s a blast (pun intended).
The scope on our project was small – as mentioned above, probably smaller than it could have been. However, this meant we managed to get the game to a high level of polish, as well as do some testing and tweaking. The easiest mistake to make is thinking you have more time than you do, and history has shown that we do this often enough. Having the scope of our game be too small was as much a blessing as a curse, though many of us would like to spend more time on the game all the same.
It’s Easy to Tweak
Because the difficulty of the game essentially comes down to the complexity of the instructions, it’s extremely easy and quick to alter the balance of our game. Too easy? Add more instructions, or make the existing instructions more vague. Too hard? Remove some pages, or clarify some things. All of our balance boils down to quickly changing photoshop files at worst, or moving some sheets of paper around at best. This allowed us to quickly alter the difficulty of the game until it was at a nice point, though some more fine tuning would be nice, it’ll be extremely easy to do.
What We Learned
Designs Can Change
It’s important to realise that games are a living, fluid entity in all stages of creation – mechanics and features can’t be locked down too early or too late. In this case, it seems as though we locked down the design of the game too early, where we could have made some alterations to accommodate the increased team size. There’s every chance that this would have actually hurt the game rather than helped it, but there wouldn’t have been any harm in considering our options more than we did.
Overestimate Every Possible Problem
As mentioned, the grid was a nightmare to implement, and took much more time than we’d anticipated. If we’d planned to get this feature implemented earlier, we would have been able to work around the problem more than we did. We were lucky that everything else went smoothly or we could have found ourselves in serious trouble, and probably wouldn’t have had a working game to show at the due date.
Package Early, Package Often
This is one that come up during our last project, Reverie, and we clearly didn’t learn our lesson the first time. The project almost wasn’t packaged in time for our presentation – luckily, Reverie taught us that Unreal hates plugins and drivers, so deleting the ones we were using for our Razer Hydra (an idea we scrapped part-way through development) was enough to scrape us by.
A lot of people probably read that and wonder why we don’t package a week in advance and prepare a presentation – the rest of you have experience in game design, and know that every project is a horrible last-minute affair, no matter how much effort you put into the project throughout.
However, this doesn’t excuse the fact that we weren’t properly building our project throughout our timeline. Moving forward, I imagine we’ll have several builds, or at least one a week to fall back on (rather than our early attempt of maybe 3 builds per project).
In the end, Sol Solutions turned out really well. It looks and sounds great, it’s great fun to play and it can be enjoyed quickly by almost anyone. While many of us have expressed interest in polishing the game further, the build we presented was solid, functional and well-polished.
If you have any questions, comments, criticisms or even if you want to play Sol Solutions, get in touch with me via the contact page or let me know the comments.
Thanks for reading!