Hello, and welcome to the first of what is planned to be a monthly series of devlogs chronicling the development of my new game, Grippy Golf! Today, I’ll be taking you on a longer journey than normal, all the way from my first lines of code to the creation of my shiny new store page. There’s a lot to cover, so I won’t go into too much detail on any one subject, but maybe there will be some future posts that break things down further, who knows.
So first off, what is Grippy Golf? Well, the initial concept is like golf, except that everything the ball hits, sticks. I first came up with the idea over a year ago, when I challenged myself to make 10 games over the course of just 10 weeks. Grippy Golf, or as it was known back then, Sticky Golf, was my first entry into the challenge, and probably one of the best, or at least the funniest. So, after wrapping up my previous game, I decided to take the concept and expand it into a full release.
It was nice to already have a prototype available, but there were a number of significant changes I wanted to make. For one, the pure chaos of the prototype is fine for a game meant to last 10 – 20 minutes, but I worried that it would lose its appeal in a game meant to last 10 – 20 hours. It needed something more, but at the time, I wasn’t sure exactly what. Don’t worry though, we’ll come back to that.
The other major mechanical change is that I decided to include a multiplayer mode, for both local and online play. Now, as any game dev will tell you, this is not trivial. Online multiplayer in particular fundamentally changes how you have to think about your code. I’ve also never done it before, though that’s true of a lot of things I do as a solo dev. So, after rewatching Alex Forsythe’s excellent video on multiplayer in Unreal for the 5th or 6th time, I got to coding.
I spent the first several weeks creating the basic framework of the game in C++: the character controls, the behavior of stickable objects, etc. It’s generally nitty-gritty details that are kind of boring, so I’ll mostly skip discussing it. At the end, I had a functional, albeit ugly game, where you could hit the ball, have it stick to objects, and reach a goal.
On to the next step: aesthetics.
Now, that might seem strange. There are lots of resources about game dev that will tell you that you shouldn’t worry about the look of your game at first, and should instead work on refining your mechanics and making sure they’re crisp. Mario 64 is the classic example here, and there’s undeniably truth to that statement.
However, it’s also true that as an indie dev, you need to attract customers, and you need to start doing so as early as possible. And if your game plays well but looks bad, it’s going to be hard to generate interest.
A balance is needed, where your game looks pretty enough to show off, without the visuals taking up too much of your time, at least initially. So, to beautify things up a bit, I first needed to determine the game’s art direction.
One of the main limitations I face as a solo dev is that I am not particularly good at art, especially 2D art. As a result, any art style I come up with has to avoid using anything hand-drawn or painted, which sadly locks me out of a lot of my favorite styles. Still, there’s a lot you can do within those limitations.
Here’s the process that I settled on for Grippy Golf. First, I download realistic textures for the material I want, typically from amazing Creative Commons 0 websites like AmbientCG. Then, I open them up in Gimp (yes, I use Gimp) and mess around with the Waterpixel and Oilify filters to achieve a softer, painted look. The next step is to desaturate the resulting image, and increase the contrast so it stretches all the way from black to white. I know that sounds weird, but bear with me.
Now, I add the modified texture to my model over in Blender. I prefer to have just one material per model for performance reasons, so I bake all the different materials to a single texture. However, there’s a lot more here than just the black and white image. There’s the normal map, of course, and other basics like metallic, roughness, and ambient occlusion. Then there’s a black and white vertical gradient that runs up the model, and an index value that is different for each material.
Baking all these different maps and consolidating them is annoying, so I also wrote a python script to automate it, which is probably my single biggest time saving decision so far. If you haven’t messed with scripting in Blender, I highly recommend it.
Anyway, Unreal is where everything starts to come together. Here, I use that black and white image to interpolate between two colors, which lets me change the color of my materials in Unreal, without having to rebake the texture. The vertical gradient is used similarly, and keeps things from looking too flat or static. The material index that I mentioned earlier lets me apply different settings to different parts of the model, even though they all use just one material. The end result is that I have lots of ability to fine-tune the look of the game without leaving the editor.
After making several example models using this approach, I also spent some time working on so-called “game feel”, things like particles, camera shake, and so on. In my experience, prioritizing these is a great way for your visuals to stand out, even if the rest of your game still uses placeholders. I ended up redoing all of these later, but even the preliminary versions were very well received.
In the process of testing these FX, I stumbled across the “something more” that I had been looking for in the gameplay. Namely, I realized that it was super fun to chain together a bunch of arrow boosters to get a “hole in one”. That, coupled with Mark Brown’s video on Neon White completely changed my conception of the game. Now, rather than the player being at the mercy of the wacky physics, I realized I could give the player tools to work with and around that wackiness, with an emphasis on fast, frenetic combos.
To that end, I created a flurry of new systems and powerups. The most notable is the dash, a one-time burst of speed in the direction of the player camera. This increase in player control over the ball completely changes the feel of the game, especially once I made it so that the arrows refresh the dash ability, like in Celeste.
I also added fans that blow you around, a magnet powerup that draws objects towards you, barriers that only break if you have enough objects stuck to you, and my personal favorite, the firework.
I could have kept going, but I deemed it was time to start working towards the next landmark: a store page. Having a store page is really important, as it gives you something to point people towards and lets you start gathering wishlists, i.e. potential sales. My personal prerequisite for a store page was to fill in all my current placeholder assets, namely the player character, the walls, and the floor.
Up until now, the player character had used models and animations from Mixamo, and they worked just fine. For the final product though, I wanted a character that was fun and appealing, something that could serve as a mascot for the game. I chose a robot so that I didn’t have to deal with human facial animations, which intimidate me. I also decided that they would fly, so that I didn’t have to figure out where the ground was every time I moved them. The noodley arms are a massive pain to animate, but I really like the way they look so I’ll probably keep it.
For the walls, I created a bunch of houses, largely inspired by the architecture around Capitol Hill, DC. There’s not as much variety as I would like, but for now it’s fine. Of course, this is a game about a ball that sticks to things, so I made sure each separate part of the building can be individually detached. I did the same thing with some trees as well, with each branch being a separate object.
For the floor, I didn’t want to be constrained by square tiles anymore, so I used Unreal’s Geometry Scripting system to make a custom landscape editor. It lets me trace out an outline with one spline, while setting the height of the resulting landscape with another. On top of that, a barrier is automatically generated around the level, so the ball can’t fall into the void. The more flexible terrain also needed more flexible roads, so I made a road tool using spline meshes.
With everything together, I made an example level or two, took some screenshots, and sent the page for review! Everything’s approved, and you can check out the page right now if you’re interested.
That brings us to the present! There’s a number of smaller topics I didn’t have a chance to discuss (creating an options menu, implementing controller remapping, fiddling with splitscreen for online multiplayer, various physics shenanigans, etc.) but this post is already long enough, and I’m itching to get back to work. I hope you found it interesting to see how I progressed from a basic prototype to something that at least resembles a full game. Again, if there’s anything you want to hear more about, let me know.
Cheers!
Switchback Studio 