At one point in Umbra Via’s development I had to figure out the scoring system, and I realised I had run into a math problem. It ended up being the most frustrating problem I ran into for the entire development of the game.

Just a quick overview of the game to give some context. In Umbra Via you are trying to control different sized regions on the board. The key thing is that you are also building up those regions with tiles and then trying to close them off in order to get points for controlling them. Here’s a picture of what the game looked like when I ran into my little existential scoring crisis.

In this version, players placed tiles in one of four columns that built up sort of like Tetris. People were having fun with most of the game, but there wasn’t much satisfaction when it came to actually trying to win. This was mostly due to the fact that the tactics that the scoring encouraged you to use just didn’t lead to anything interesting for the players. Since Umbra Via is an area control game, the higher you ranked in a region, the more points you had to get. That was a requirement. How many points you got for each rank was what I had to figure out.

The obvious thing at first was to just give a flat amount of points for having the most in a region. So 3 points to first place, 2 points to second, etc. The problem though was that most efficient way to get points was with the smallest region. The game just turned into “who can make the most size one regions”. It wasn’t very fun because players were actively avoiding having tiles interact with each other. If they won the bid for a tile, they would place it so it would close straight away and that was all there was to it. There were also no cool shapes being created, which was honestly my biggest issue. Imagine Carcassone but with only those little two tile cities.

After the flat scoring system didn’t work, I went in the opposite direction and gave points based on how big the region was in addition to your rank in the region. That way players would try to fit the tiles together and maybe “interesting” shapes would form. However, this also had an issue. Once a large region started to build up, players couldn’t afford to not fight for that region. There were just too many points at stake. This meant that everyone kept adding on to the same region hoping to win it. When the giant mono-region finally somehow closed, the player who won the region had way too many points for anyone else to be able to possibly catch up. So the whole game was just an arms race with a sad conclusion. Also, a mono-region isn’t very exciting to look at either.

I then spent the next two months trying out every different possible scoring system I could think of. At one point I made this spreadsheet. I think I went a bit too far.

Each different scoring system I tried was supposed to have different incentives based on their mathematical properties, but they all ran into the same issues. There was only one strategy to win the game and the layout of tiles never looked interesting. I could not make the math work such that it wasn’t just either build the biggest or build the smallest size region possible.

I nearly gave up on the game, thinking I’d hit some “mathematical truth” about how it just couldn’t be done. That there was just no way to make the scoring work and have the tile layout be fun and interesting at the same time given the basic facts of the game.

Ultimately that was true and that was actually the key. I had a look at my game and decided that the flat scoring would never work. I wanted to encourage people to build and flat scoring would always encourage the opposite. This left scaling scoring. But no amount of different types of scaling scoring could fix its main issue of one giant region forming. If I just accepted that fact though, I could instead focus on working with that scoring system rather than trying to bash it into shape. The issue with scaling scoring had been that players would just build one giant region. The fix to that was to make it so that building a bigger region was a fun challenge instead of just a boring, obvious move. To do this, I went back to a very early iteration of the game and added in a board that restricted where tiles could go.

The game worked so much better. I did need to change some other things to make this work, like removing completed regions to make way for new ones, but all those changes flowed naturally from the new board rules. How the scoring system scaled didn’t even matter too much in the end. The random one I picked to test out the board out worked just fine enough. There was now a challenge to try and fit a large region into the smaller board, and sometimes it was too much effort to be efficient anymore so people went off and started new regions. Since then I’ve made a couple tweaks to the scoring system to smooth things out, but the mechanical change of restricting tile placement to an enclosed board did so much more than any scoring system change could have.

What I learned after all of this is that playing with the math and the formulas can only get you so far. I had fallen into the trap of thinking that math could fix my issues. That there was some mathematical solution that would make it work, and if I couldn’t find it then it just wasn’t mathematically meant to be. The issue was that I was trying to fine tune my game. Working out the math is good for fine tuning your game, but the fun has to be there in the first place.

I think this all lines up with some advice I’ve heard somewhere (if anyone knows the origin of this, let me know!) about how when balancing numbers, you should either double or half them to see how they really affect things. Small changes aren’t always helpful and you’re going to need to see the extremes of what you’re working with before you can figure out what direction to take.

Whenever I hit a road block like this in the future, I’ll be making sure to reexamine the mechanics in my game first, before I get sucked down the mathematical rabbit hole. Try changing mechanics so that they play off of each other, rather than trying to make one small part of the game work in isolation.

Looking back on what I wrote, I’m definitely missing some things, and I already want to revisit this topic of “debugging game design”. I’ll leave it like this for now though so it can be something I can reflect on and add to as I go. This blog is definitely more of my journey of figuring these things out rather than any sort of authoritative “Here’s how to do game design”. There’ll be things that are wrong or not quite right, but I want to write it all down as part of my process. I hope you find that interesting at least and maybe there’ll be some good stuff in here! Thanks for reading!