Dev Diary: making of “Downhill Fox” through the Unreal Fellowship: Games
Hej! I’m Oscar Rickett, and this is the story of how I made a mini-game called “Downhill Fox” during the Unreal Fellowship: Games. It was three weeks of structured chaos, and I came out the other end sleep-deprived, proud, with new friends and very aware of how spaghetti my Blueprints were.
I’ve been messing around with Unreal Engine for a while, mostly through trial and error and lots of googling. This was the first time I had actual training in Unreal, and being surrounded by other devs, with real support and answers just a message away, was honestly kind of magical. Im very grateful for the opportunity.
The Setup
I’ve been working on a side project called Foxo (foxogame.com) for nearly two years. For the Fellowship, I wanted to create a standalone mini-game that could live in that world. I mostly do the art on Foxo, so the chance to build everything myself, from mechanics to UI, was both terrifying and exciting.
Choosing the Idea
I started with three game ideas:
- A room decorator sim
- A flood-fill tile puzzle
- A downhill racing game
I went with the racer. I knew I would find the fun faster. And I liked the idea of it being visual, fast to prototype, but also with lots of challenges that I have never tackled before.
One of the inspirations behind Downhill Fox was actually an old Club Penguin minigame. I have a lot of fun memories playing it with my brother growing up. Since Club Penguin no longer exists (RIP), I thought it would be fun to give that kind of chaotic downhill racing a new life. It felt like a nice mix of nostalgia and something fresh.
Lesson 1: Choose an idea that gets you to “playable” as soon as possible. Even if it’s not the most original concept, you’ll learn more from testing something that exists.
Prototyping Fast
By the end of week one, I had a basic version of the game working. It looked rough, but the core loop was there: generate a snowy track, slide downhill, dodge obstacles, win at the bottom.
I showed it to my Fellowship group. Some of them were surprised it was already playable. I didnt start with a game design doc like some others which this time I think was a good idea as it bought me time later on to polish instead.
I didn’t do any fancy pre-production. I just wrote a big messy to-do list in a notebook and tackled one thing at a time, top to bottom. Game loop first, then everything else.
Lesson 2: Don’t underestimate how good a scrappy prototype can be for morale. If it runs and you can press buttons, you’re winning.
Mechanics and Mayhem
The game is two-player, same screen, no split screen. That decision caused some pain, players drifting apart meant one player could easily end up off screen. In the end, I locked the forward speed and made the game about dodging left and right instead. The camera follows whoever’s in the lead. Harsh but fair. I did also experiment with the motion being completly physics driven, but that made the motion even more choatic and the players drifted apart even faster.
I added some more art and a basic scoring system and a few more textures and it really looked closer to the final game.
I’m not much of an animator, so all the animations were done within Blueprints, the left and right tilting, matching the ground rotation, and even the flip when you hit an obstacle. No fancy rigs, just logic. My good friend and incredibly talented animator friend Anna Sanders did make a little win animation for me though, which added a perfect bit of charm to the end of the race.
AI in the Shower
I had a failed attempt at making an AI opponent using the dynamically generated NavMesh, but because my characters are always moving forward with special movement logic, I just couldn’t get it working. I gave up on it for a couple of days… then had a breakthrough in the shower. I realised I could just place a bunch of waypoints down the hill, and have the AI check whether it’s to the left or right of the next one, and steer accordingly. The red markers that are hidden in game show the way. This is also an example of a single race part.
It sounds so simple now, but it worked, and took less than a day to set up. What I originally thought was a stretch goal ended up becoming one of my favourite features in the final game. The AI isnt perfect and when its gets fast can still mess up which I like as its still beatable by a human player.
Lesson 3: If something’s too complicated, you might be solving the wrong problem. Take a step back, a deep breath, or a shower. 
Snow Decals and Sparkly Shaders
One of my favourite things is the fake snow trail behind the player. I thought about using render targets to deform geometry, but with the number of individual blueprint parts, that was too much of a potential performance nighmare than I was willing to take. So I made a decal system that drops a normal map behind the player…much simpler.
I first tried it with a circle, but you could see the dots dotting behind the player, so a halfpipe that orients to where the player last was, looked best in the end. Feel free to use my textures if you are tackling something silimar.
Crunch Time Polish
By the end of week two, I had the full gameplay loop in place and already a few nice to haves. That gave me one week for polish:
- Finish up the AI opponent waypoints
- UI and Start Menu
- Start and finish animations
- Better obstacles
- Camera effects
- More VFX
- Difficulty settings
Did I plan to have all this from the start? Nope. But having a working prototype early meant I had time to go wild with the extras.
Blueprint Chaos
Let’s talk about the code. Or more accurately: the tangled mess of logic spaghetti I put in my player Blueprint.
I wanted to keep things modular and clean. I didn’t. I wish I had more time to split things out into better systems but with the deadline looming, everything just… lived in the player.
It works. But it’s not pretty.
Lesson 5: Blueprint organisation matters if the project is bigger than a few weeks. Spaghetti is not really fine even when working alone and cleaning up later will hurt.
Playtesting and Course-Correcting
With a couple of days left, I let friends and family try it out. Most of them couldn’t get past the first couple of sections on the first tries. I’d made it way too hard.
So I slowed the game down, added difficulty options, and capped the top speed. The game became way more fun instantly.
Lesson 6: Playtesting is brutal and necessary. Watch people struggle and be willing to change things.
Final Thoughts
Doing this while also working full-time was… intense. I was on Swedish time by day, Fellowship time by night. Social battery: zero. But I’m really grateful to my friends, partner, and colleagues for their patience while I was a zombie fox for three weeks.
Huge thanks to Ivan and Andrew, my coaches, and to everyone in the Fellowship group who gave feedback, encouragement, or just said “cool snow effect.” It meant a lot.
I’m taking everything I learned back into Foxo, especially the stuff about not overengineering things. Oh, and organizing my Blueprints…
Lesson 7: If its not fun for you, its definetly not fun for the player.
Thanks for reading.
