This post is a wrap up of the development process of our game for the GMTK Game Jam 2019. If you want to see the finished game go here!

That being said, “Let’s get to it!

‘Only One’

Each year, the GMTK Game Jam has a theme. Last year the theme was ‘Genre without Mechanic’ to which our response was Fresh Merchandise. The theme for this year was ‘Only One’. This is probably the most broad theme for a GMTK Jam yet!

As this is a game design competition, it’s best to try and work the theme directly into the design of your project. So we were looking for ideas which really required the incorporation of only one to work.

So when we came up with a mini-golf game where you have to finish every course with one putt, but you can influence the outcome in distinctly non-golf ways – we were happy to get started!

Implementation Goals

As can be seen in our upcoming VR game Virtual Ricochet, as a team, we are out our best (and fastest) when working on a combination of modeled 3D assets with custom materials and shaders, along with other technical art effects to bring our games to life. We wanted to see if we could cram some of these skills into just 48 hours of development time.

Also, we wanted to make use of some of the new (in some cases experimental) features shipping with the Lightweight Render Pipeline and Unity 2019.1. Lastly, we decided to target web browsers as our platform to reach the widest audience possible.

So keeping this in mind our goals were as follows:


Physics and Game Feel

To make our game controllable and feel enjoyable to play, we weren’t going to be able to get away with normal, physically accurate ball rolling. The underlying problem is that the ball will spend a very short amount of time near its top speed, and a very long amount of time at it’s very slowest speeds.

To solve this problem, we took manual control of the deceleration of the ball.

With this setup, we get a much longer stretch of a more consistent speed, and we don’t have to watch the ball progressively slowing down. This makes the game feel a lot snappier than it would otherwise be.

Rotating the World and Jumping Physics Objects

A key component of our design was the ability to tilt the world to influence the direction of the ball. This presents its own challenges.

In Unity, if you make elements of your level static (as in they will never move) you gain performance improvements graphically and in the physics engine. With static objects, Unity can bake all the geometry and lighting for rendering as well as perform simpler physics calculations in general as the velocity of the static elements will always be zero.

However, we wanted to be able to tilt our level around, which would make every single element in our courses a dynamic one.

If we were to implement this in a very simple manner, by simply rotating the world geometry together with our ball, the ball would bounce around the course all the time as the relative velocities of everything would always be changing. Even if we compensated for this, the result would look very jittery and cause unusual looking collisions with the floor.

The solution to the bouncing and jitter would be to use rotational velocities instead, but synchronizing those would be quite difficult mathematics for a 48 Game Jam project.

So instead we left all our level geometry static and instead rotated the camera view and global gravity vector. I bet you didn’t even notice ;).

Time Limitations and Staying Awake

The final challenge is staying awake long enough to putt put this all together.

Make sure you get a long rest the night before and don’t be afraid to get a long rest before day two as well. While you’re at it, eat a good breakfast, lunch and dinner on both days. Better to work more efficiently for less time.

When working on features, it’s best to add each new feature in as a self-contained element adding to the previous work than to try and build up everything at once. Also, avoid feature creep at all costs!

What To Do About Graphics

GMTK is entirely a game design jam, this should be where you focus; however, graphics are nice to look at and are valuable in communicating how your game works.

When considering graphics as a communication tool it becomes clear that it’s important to get the most basic implementation of each element made and into your game as fast as possible. So this is what we did.

Our artists workflow was to make very simple models in Blender (almost all of which remained so all the way through to the final product), unwrap the UVs and texture in Substance Painter.

As a procedural tool, Substance Painter allows texturing to be done incredibly quickly and facilitates extremely rapid iterating on your work.

Special mention and thanks goes to Oscar who came on board this year to help us Mystics by creating the vast majority of the 2D artwork you see in the game. We loved their contribution and it really helped make the game look great!

In lieu of in progress screenshots (we were too focused on getting the game done to take any) our artist wants to leave you with some closeups of what is definitely way too much detail to be seen. While you are advised not to do this, Chootin has no regrets.

previous arrow
next arrow
previous arrownext arrow