The Captain Took Your Ducky: A Gear VR Jam Post Mortem

The Captain Took Your Ducky is a virtual reality puzzle game taking place in a hexagonal water world. It was developed as part of the Oculus Mobile VR Jam in one month. It is highly optimized for Samsungs Gear VR headset and is known to run smooth on the Samsung Note 4 as well as the newer Samsung S6.

The Goals

We focused on creating a fun and easy to learn, but hard to master, experience. The goal of the game is simple: create a way of water to your ducky, so it is happy. The only mechanic given to you is simple also: you rotate valves, which in turn rotate the hexagonal platforms. The true complexity comes through the levels and the way the platforms are mechanically connected.

There are no text tutorials, instead, everything is learned by doing - just the two basic gestures (clicking and swiping with the touchpad) are indicated as some tooltip bubbles. We really want to give the player the feeling that he has the possibility to find out how the game works by himself.

The hints in the game are displayed when the user first needs to use them
or executes a wrong gesture

Another main goal was to create an experience enjoyable for everyone. For us that means no inducting of unnecessary motion sickness while still adding some nice motions and effects. Inside the levels there is no camera movement at all, only a 1:1 natural head tracking rotation is used. To keep things interesting and give the player a little reward for solving a puzzle, we introduced a level changing effect with a moving camera which does look and feel nice, while having a negligible impact on motion sickness.

To prevent motion sickness, the level change effect is always applied into
the facing direction of the player and uses 2 distinct speeds without any acceleration at all.

A third goal was to give the whole world a meaning. The idea is, that the Captain has a jetpack and steals your ducky. You, the strong super hero with superpowers, fly after him, but he drops the ducky at some new dry place and flies away - that’s the start of the next level. This is also a reason for the kind of level transition we made, however we couldn’t finish the whole animation in time.

What Went Right

1. Testing on the real hardware right from the start

I must admit, spending $ 800 for the equipment for a game jam might sound crazy (especially for a hobbyist), but it was the right decision to test right from the beginning. We continuously tested our build on the real hardware at least every two days, so we could tackle the issues as soon as they popped up. We faced lots of performance issues, partly because our generated water meshes created to many draw calls in the beginning and partly due to some current performance problems on the Android Lollipop Snapdragon Note 4 combination. And also many other issues, like for example graphical glitches that currently occur when devleoping for the Gear VR on Unity 5. But since we continuously tested we ended up having a very solid and fluently running build in the end.

2. Knowing our Limits

It was our first 3D game and we did not have much time to prepare for the jam, as we both got regular jobs outside the game industry. But due to the many other game jams we attempted in the past we had some very good feeling upfront what we possibly could achieve in this small amount of time and what features we could possibly add. Especially creating a paper prototype upfront helped in the very early phases to get a common understanding, figure out problems and finding new ideas.

3. Communication

Once the base mechanic was established, finding ideas for the game went pretty well. We had regular Skype meetings and chatted about almost everything we did. Once one of us had a cool idea, the other person picked that up and improved on it. Unfortunately many of the ideas didn’t make it in the game, but we now have a lot in our backlog to extend the game on.

4. Discipline

What we learned from past projects is that working together on a Unity project and a VCS like Git requires lots of discipline, as merge conflicts happen very often in and are hard to fix, especially in scenes and prefabs. However, we came up with some simple rules, which helped mitigating those conflicts:

5. Playtesting

This might sound obvious, but we never did as extensive playtesting than this time. We started playtesting right after the second week and took the feedback back into the project. We never told the people what they have to do unless they really couldn’t find out and playtested never twice on the same person. This was very important for improving the game.

That's me, playing the game ;-)

What Went Wrong

1. Playtesting

I know, I already listed this in the What Went Right section, but there were also many things that went wrong at playtesting.

For instance, I couldn’t set up the OVRMonitor to mirror the display of the player on my laptop without making the game unplayably slow, so I never saw what the players really did. To address that issue, I told the playtesters they should talk to me while playing and say to me when they got into troubles - this worked sometimes, but more often it did not.

Also, we should have isolated the current playtester from others waiting in the queue. Maybe this way they would have talked a bit more, but more importantly: The others wouldn’t see how they game is played. I thought this is no big deal as the others wouldn’t see the screen of the playtester, but even observing how the playtester looks around and is using the touchpad is helping them to know how the game is played before even testing it by themselves.

Another big mistake that we made was not putting them headphones on! The sound in the submitted build is mixed up very badly (especially the water is sounding not really good) and also the overall volume is way too quiet. I guess when we would have put them headphones on, those issues would have popped up way earlier.

2. Technical Risks

When we started, we really wanted all those Unity Pro features we get with Unity 5 for free, but we didn’t know enough about what we were up to and that Unity 4 would have provided everything we needed also. In the end, we didn’t even use one of the fancy post processing effects, but had only troubles. There are lots of issues right now running Unity 5 builds on the Note 4 with the Gear VR. We’re not sure where exactly the problems come from, but for instance if you use transparent materials, the whole scene gets very glitchy. At the end of the day we didn’t use any transparent materials, only one custom written shader uses transparency, which works for some reason. Other people reported lightmapping issues, but we don’t have any static geometry and don’t use any baked lightmaps.

3. Wrong Priorization

As already mentioned in the introduction, we couldn’t achieve to get the story part into the game. Would we have skipped out that part completely how much more time would have had? We had just endless discussions talking only about story and how we could aesthetically carry that story to the player. Then we spend around one men-week, only trying to model the captain, giving him some cool realtime hair animations and animate them right in the scene, but we just couldn’t get his whole animations right in that time - so we kept him out of the game. Of course we could not know this upfront as we just couldn’t know how hard animation in 3D  might be, but would we have set clearer priorities upfront maybe the modelling and the meeting time would have been better spent at other parts of the game.

4. Underestimation of Puzzle Level Design

We got 13 levels and I think this is ok for a game jam, but I thought that we would have way more after one month! Making puzzles, especially 3D puzzles is hard, and I should have known as this is not my first puzzle game, but next time I will not make that mistake again.

5. Ignoring Marketing

Probably the biggest mistake we made was to ignore marketing nearly completely. We should have put a WIP (Work In Progress)-thread into Oculus’ Forum right from the start and should have cared more about our description and screenshot quality. We had pretty much stress at the end of the jam, because we priorized a flawless running build over high quality marketing assets and nearly ran out of time taking some screenshots. The description was lacking detailed information about the main game mechanics, the innovation and controls - we just didn’t think that’s so important. A bug is fixable, but underestimating the importance of marketing can cost you being noticed at all ...

This is our Trailer we made for the last milestone

Conclusion

All in all the jam was a success for us, even though we didn’t win a prize. I cannot remember when in the past I learned so much in just one month. We proved we are capable of doing a 3D and VR game in this young technology without any previous experience and defeated so many performance problems and bugs, that we ended up with a pretty solid game. The biggest success for me is finally learning that the product itself is not enough - the marketing around it is at least as important.

Thanks to Oculus, Samsung and Unity for this game jam, we had a great time.

Further information about our game can be found at http://artwaretists.com/ducky