‹— back

2020-06-30

Today was another day where a large chunk was taken up by trying to get some stupid collision resolution stuff set up again. I need to stop. Not going to touch that again tomorrow. Promise. ... right?

So it's time to play catch-up with the things I've been missing out on. First on the list is one I like, making little configuration files that can be used by collaborators. Before having properly prototyped anything for a project and deciding to invest lots of time/energy into advanced tooling, one of the quickest returns on investment is providing some way for people you're working with to be able to independently make adjustments to things.

Here's how a game config file might look with the data language in place. Top level values are objects, and children can be strings, numbers, arrays, or other objects.

I prefer to load up two of these files at launch. The first is the main config file, which gets versioned and holds the canonical values for the current build. That should always be present, but if not values will default to whatever is written in the struct in the code.

The second file is a "local" config file, an optional file through which a person can override values in the main config. This is where other collaborators make their changes. They can start by copy and pasting the main config.

You could just edit the main config file, but I find it's better to have that file so that it can be left untouched and serve as reference. If you mess something up in the second file and lose your last change or just want to revert to something familiar, the first file is right there. It also gives you the ability to have multiple versions of the second file; keep some copies with different sizes, speeds, or whatever other gameplay values you want to test and flick between.

In-game tools are better for everything other than the initial launch options, but they're expensive. The setup for a config file is similar for every project, and relatively simple.