View profile

Sid Makes Games #3: Items!

Sid Makes Games #3: Items!
By Sid Shanker • Issue #3 • View online
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:

Picking up an item and seeing it in your inventory
Picking up an item and seeing it in your inventory
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.
Software Engineer Problems
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:
The Lobby screen
The Lobby screen
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:
Some bad code
Some bad code
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.
Next Steps
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:
  1. The new Unity Input System. I’m currently getting input to move characters and whatnot in a fairly brittle way, and hopefully this will help solve the next problem:
  2. Separating networking from other game behavior. This is the example I keep harping on, I’d love to be able to use my Characters outside the context of a multiplayer game so I can test things more quickly and not have to go through the lobby every time I make a change.
  3. Rucksack - this is a library for managing items and inventory that seems like it addresses a lot of the problems that I have. I’m curious to dig into how the library authors designed the interface, as well as what assumptions they make about how a game is set up. While I’ve learned a lot about Unity doing things without a lot of external libraries, I’m interested in seeing what other kinds of game interactions can be abstracted out.
The Buggy Chest
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?
Why won't it go away?
Why won't it go away?
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 what’s going on here?
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:
  1. Remove the item from the chest
  2. Add the item from the player’s inventory
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!
What I've Been Playing: Baba is You
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!
An early Baba is You level
An early Baba is You level
I haven’t finished the game yet, but the two main things that I think the game does exceptionally well are:
  1. When a new concept is introduced, like a “Wall” for instance, the game provides a puzzle that is designed to teach you how to use that element. The game tells you nothing about what to do–it’s up to the player to figure it out. All of this explanation is done via players attempting levels.
  2. The difficulty is calibrated well. While the game gets more difficult as you go through it, the early levels are very doable, and still feel satisfying.
I’m excited to continue playing and seeing what new concepts the game has in store.
Thanks for reading and following along so far!
Did you enjoy this issue?
Sid Shanker

Sid makes games! Follow along for fun content about games & game development!

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue