Welcome to the third edition of Sid Makes Games! This newsletter is where I’ll be talking about learning game development and my progress.

If you’re new here, I’m building an Assassins-inspired top down multiplayer game. Over the past week, I’ve been working on an item/inventory system for the game, and I’ve finally gotten to the point where a player can pick up an item from a chest:

This was an interesting exercise and is the first tasks that I’ve done so far that really forced me to understand Unity at a deeper level. It also exposed me to a taste of the software engineering problems that game developers face.

Learning game dev has made me reflect a lot on my experience learning web development. When I started learning web dev in college, I started learning Ruby on Rails. A useful thing about Rails is that it is opinionated about how your code is organized.

Now, while any Rails project will eventually run into problems related to code organization, you aren’t likely to experience these issues in the first few weeks of working on a project. As a result, most new projects don’t require a lot of upfront thinking about design patterns that are going to be used. Technical debt is unlikely to bite in the very early days.

That has not been the case with my game development experience. Despite being pretty early on in this project, the code that I’ve written so far is really getting in the way. Here’s a practical example of how:

Right now, testing out changes to my game are pretty painful. In order to test a change to, say, a character’s movement, I have to go through the whole lobby & game hosting process:

Only after that can I actually test the character movement change that I made!

This makes debugging a very painful process–any code change at all requires going through this process.

The solution that I’ve seen to this is to make a separate “Scene” in Unity (think of it as a smaller, fake version of your game) that contains just the objects you want to test. However, that doesn’t work because of how I’ve factored my code. Here’s the movement code for the character:

Without getting into the weeds of the details here, the gist of this is that I’m using a hasAuthority check in the movement code to determine whether a particular character game should move. This is to prevent a situation where you hit the right arrow key, and then somebody else’s character moves in addition to your own.

The implications of this are that I cannot independently test the movement of the character, because the logic for movement now involves networking code!

So even though I haven’t been working on this game for super long yet, the shortcuts that I’ve taken to get things working are proving a real impediment to being able to test & iterate quickly.

Getting out of the current slow test loop I’m in is going to require some more thoughtfulness about how I’ve organized my code. While it’s going to feel unsatisfying to go back and redo some of the stuff I’ve already done, relieving the current pain in having to go through the lobby every time I make a change will be nice. The main things I’m going to look into are:

Time for our bug of the week! In this edition, I try to claim an item from the chest…and it seems to not work?

This issue was quite a pain to debug, but at least taught me a lot about about the key multiplayer concepts in the Mirror library I’ve been using.

So, from a high-level, open the chest, claim an item. The item does appear in my inventory, but is also still in the chest. Why?

The steps for claiming an item are pretty straightforward:

The wrinkle here is that I want both of these computations to happen on the Server-Side. If it was possible via some client action to perform either of these actions, it would pose a cheating risk. On the server, I can do checks for if the player is actually next to the chest, etc.

Why was one of these actions working and the other not? Well, it turns out that all network objects in Mirror (such as a character, or an item chest) can grant “authority” to a player on a network connection. If a player has authority over an object (like a player character, for instance), the player has the ability to perform actions on the behalf of the player, for instance, moving it. If an action is attempted on an object on behalf of a player who has no authority, the action just doesn’t happen. This was a little surprising to me, I would have expected an error of some kind.

The treasure chest, in fact, had no authority. It is not associated with any particular player, so this makes sense. If that’s the case, how can a player ever mutate the state of that object? This is quite a complicated issue, with several possible solutions, depending on what you need exactly. In our case, because we want any player to be able to act on the Chest, we simply disable the authority check for the particular action of removing items, resolving this bug!

I’m not done with Celeste yet (I’m on chapter 4 still), but I’ve picked up a new game, the indie puzzler Baba is You. It’s a game where the puzzles are all based around manipulating the rules of the world you’re in. The mechanism for this is that you, as the little white critter depicted below, can push around text on the screen, where the text can specify a rule, like “Wall Is Stop” (you cannot go through the wall).

Pushing the text blocks around allow you to change the rules, often in surprising ways!

I haven’t finished the game yet, but the two main things that I think the game does exceptionally well are:

I’m excited to continue playing and seeing what new concepts the game has in store.

Thanks for reading and following along so far!