WEEK OF 2024/03/12: the funkblog with factorio references...

welcome back everyone to another fnf weekly digest! this week is week where we hear about some fun inside behind the scenes tech at funkin crew that that help make FNF that no one knows about... it's time to dive into some fun tech goodies!

Chart Editor: Playtesting!

by Eric

Eric again with another Chart Editor feature breakdown! This time, I wanted to go over exactly how testing your chart works.

At any time while charting your song, you can press ENTER to be redirected immediately to the level with all the characters and stuff where you can playtest your song. However, if you press SHIFT-ENTER, instead of being directed to the level you are directed to a minimal play state. No characters, no stage props, faster loading times.

There are a bunch of options available to customize the playtest mode too! You can enable Practice Mode (don't lose if you have zero health), or Bot Play (the CPU plays the song for you). There is also an option to start playtesting your song at the playhead rather than at the start, so if you're charting the middle of the song, you don't have to wait to test that part!

These features come together to make previewing charts easier and more fluid than with the old editor. Quicker playtesting of specific sections means quicker iteration and improvement!

A challenger approaches

by hazel

cue 2013 dubstep intro

There’s always things happening behind the scenes when making a game. I’m one of the people building the stuff behind the curtain, and we haven’t met yet, which is a shame!

So, heya, I’m hazel (they). I’m doing subtle software & scalable server sorcery for The Funkin’ Crew since January 2023. And it’s time you get to hear about some of the things I’ve built! And also time I stop procrastinating writing a blog post. I’ve wanted to since last September!!!

Frenzy with friends

If you’ve got keen eyes you might’ve noticed one of our Kickstarter goals going unaddressed so far: Online Leaderboards

Earlier this year, I’ve built the API for that — which is the actual brains. It handles things like storing and sorting the scores you submit, returning them in the right order, filtering them by song, user, score range, …

Once we integrate the leaderboard system into the game (hopefully soon), we don’t want it to rely on the game to do any computation (like your final score). This avoids issues like a bug in the game (or the score display) completely voiding your amazing #1 run, while also helping us prevent malicious submissions by being able to audit the inputs server-side.

Integration hell

There are a lot of moving parts here, and making them all work reliably took more effort than I initially thought. Here’s a list of steps that happen when you play through a song:

1. the game records all of your inputs
2. the game turns your inputs into a package that can be easily shared between computers
3. the game sends that package to the leaderboard API
4. the API receives that data, and unpacks the inputs from it
5. the API plays through the song using those inputs (it doesn’t actually play the song, it instead does some cool math!)
6. the API calculates your score from the hits, misses, etc.
7. your score gets tagged with a bunch of metadata and stored

An issue in any one of those would change your score, and tracing back where exactly that happened can become messy quickly when it’s more than just one issue.

Fortunately, we had a lot of technical documentation already written, like how score is supposed to be calculated, or how that data package is laid out.

Unfortunately, despite that, some bugs with parity between the score shown by the game and the score returned by the API were really subtle and mischievous. For example, I had an issue with scores being consistently off by a tiny amount that took us a solid week to get to the bottom of, and in the end came down to a mistake each in both steps 2 and 4.

On the next episode of Funkin’ blog…

If that wasn’t behind-the-scenes enough for you, get ready for my collection of tools you’ll never even interact with when playing the game! Only when developing it!!

Making games is like playing cookie clicker

by hazel

A scientific breakthrough

Idea: Invest a bit of extra time now to build automations and tools, and in the long run save everyone from repetitive and overwhelming tasks.

During the last couple months I’ve done exactly that with two goals:

1. writing and testing the game should be as uninvolved as possible
2. things that run outside of the game should be easy to set up and easy to maintain

The factory must grow

With multiple people making one game, we work on lots of different versions (“branches”) in parallel. These branches each contain a small set of changes, like a fix for a problem, or a new feature.

After going through testing and review, those changes then all get merged into one main branch (sometimes still referred to as “master”). This is the version that eventually will be the one you get to play.

The goal is to, for each branch, automate:

1. getting the code
2. turning that code into a playable game (”building”)
3. getting the built game onto the computer of our testers

Doing these steps manually can easily take upwards of half an hour, and multiple people doing them over and over again is a lot of time and electricity needlessly spent.

Upgrading assembling machines

I’ve done a lot of upgrades to the automations that build the game for us. Since we now have someone dedicated to managing server shenanigans (that’s also me!), we decided to ditch paying GitHub for server power and set up a bunch of our own for way less! After doing that and then dedicating time to just cleaning up all the automation code and investigating issues caused by third party tools we use, we finally have builds that work all the time across MacOS, Windows, and Linux. Speeding them up is another thing that was desperately needed, turning this:

With caching (avoiding doing the same work twice by saving tasks that take a long time), some code cleanup, and a lot of bug fixes, into this:

Adding conveyor belts

A cool internal tool we now have is the Funkin’ Launcher (don’t worry: the final game will not ship with a launcher — we’re not a AAA studio).

This is how we can quickly get the built code to everyone who needs it to test. Here’s a screenshot:

Funkin.2160p.BluRay.REMUX.HEVC.DTS-HD.MA.TrueHD.7.1.Atmos-FGT

To make sure everyone gets access to all the files, tools, and services they need (and only the ones they need), I’ve also set up something called single sign-on (SSO) service.

It avoids having a bunch of passwords and accounts to access different tools and data. Instead, you get a single account for everything Funkin’ (except GitHub).

All the tools

One of the internal services we have is a download page for all of our tooling. It automatically figures out what tools you have access to from your SSO login, and then lists all of those for you.

All the data

Another, less pretty looking site we have is the log viewer. It allows developers to see the output of applications they put on our servers. For example, here’s the log output for when I solved an issue where one of our staff members couldn’t access game builds.

I’ve never actually played Factorio lol

PINS PROGRES

by ninjamuffin99

This week hot off the presses we have fresh news about pins, which is the packaging process for the pins has begun, and after that... should be shipments!

outro for the week

by ninjamuffin99

hazel made fun little factorio references in their blog... and that mf aint ever play it!! die! I do want to say that the factorio blog is one of the inspirations behind this blog and it's writings, I very much love reading factorio friday facts and love to dig through all of the old ones and see about what they're working on and what got implemented. As we get back into funkin bloggings, it is fun and nice to also look back at some of our old posts by now!

SONG OF THE WEEK: