View profile

Sid Makes Games #4: And..it plays!

Sid Makes Games #4: And..it plays!
By Sid Shanker • Issue #4 • View online
Hello again!
I’ve managed to make some good progress on the Assassins game over the last couple weeks. Some exciting announcements to show off before I dive in:
  1. There is a live game that you can play now! Check it out at https://squidarth.com/assasssins!
  2. The code is now live on Github. It’s not documented at all right now, but hoping to do more of that as I make more progress. I’ve also got a project board.
There’s a lot of jankiness with the game right now, but what’s playable now covers the core mechanic of each player being assigned another player to kill.

Assassins -- Rough First Cut
Assassins -- Rough First Cut
Committing the Cardinal Sin of Side Projects
Soon after my last update, I started getting anxious that the game was not really on track to being playable.
Specifically, I was using a multiplayer library called Mirror. While I made some good progress with it, I had not yet deployed a server for my game. I’d been able to test things locally on my computer, but didn’t have a set up for testing the game over an actual network.
Looking through the Mirror Server Hosting doc, it seemed like a lot of work to get the game hosted. My plan was to do this at some point. At the same time, after doing some research, it looked like there were some multiplayer game frameworks that supported easier hosting.
So – in the interest of getting something playable earlier in the project lifecycle, I committed the cardinal sin of any side project…starting over.
When Starting Over is Worth It
As you could imagine, a lot of the components in my game were very entangled with the networking code. For instance, Character Movement was coupled to network code, as character locations need to be synced between different clients. Similar story with game events, like a player dying, or a player picking up an item.
So, switching Multiplayer frameworks is a pretty drastic switch. Given the amount of rewriting required, this pretty much amounted to starting from scratch.
In my experience, starting a side project over is pretty much a death sentence for the project. It usually ends up requiring you to implement a bunch of stuff you’ve already done, with make staying motivated hard . Also, in the course of any project like this, you learn a lot in the early days! And it’s easy to feel like “If I just started over, I won’t fall into all these traps!”. While this thinking is really easy to fall prey to, trucking through, and incrementally fixing your mistakes is usually the way to go.
In this case though, I was going to get two big wins from starting over:
  1. Being able to have something that was playable over the network on day 1. Since Photon, the framework I’m using now, has a hosted product, it was very easy to get two clients to connect, where with Mirror I was possibly months away.
  2. Making the game browser-first. When developing in Unity, developing for the desktop is the easiest thing to do – you’re already at your computer. Starting from scratch, I was able to configure the game to run as a WebGL game. This is going to make distribution way easier for the initial players of this game!
It’s pretty awesome to have a game that I can play on my browser (I still have yet to give it test-run with real humans), and I feel pretty vindicated in my decision.
Quality of Life Improvements?
In the last issue, I talked a lot about my development environment was very painful. Testing interactions between players requires starting development versions of multiple clients, which resulted in a very slow loop between changes.
After asking around, it seems like developers of multiplayer games generally have this problem. That being said, I did make a few changes that have made things a little bit better:
  1. Making it really easy to go from the starting screen to playing game. Previously you to have a lobby, have more than one player, have everyone click “ready”, and then join. Now, a single player can jump into a game easily.
  2. Adding version control!
Adding version control was a huge win. Setting up git with Unity is not super straightforward, although thankfully this Thoughtbot article covered most of that complexity. Specifically, there are just a lot of files that have to be ignored. Also, a lot of the configuration of Unity projects happens in the UI, not in files. So, for instance, when I added my secret Photon key, I had to dig around for the file that contained it and specifically add to .gitignore so that I wouldn’t commit it (Note to self: if ever writing tutorial that involves adding secrets to a project, makes sure to mention adding the file to .gitignore, and expect readers to commit it to version control!)
Finally, I’m getting more comfortable coding in Windows (I never thought I’d be here…but here I am!) as well. Learning that you can run bash in Windows was huge for this.
Game Code is Complicated
I’m going to go into more detail about this in the next issue of this newsletter, but in writing the code for this game, I’m getting a good sense for the complexity that goes into game programming:
  1. State management is the name of the game. There is state everywhere in the game, and it’s pretty easy to get into a spaghetti situation where you have a bunch of different classes, each containing some subset of data for the game.
  2. UI updates, for say, indicating whether a player is dead or alive have to be done manually, which given the amount of information that needs to be displayed in any game, seems like a really bug-prone approach. I’m going to look into if there are approaches to modeling game state and UI that don’t require manual updates.
  3. Connections between game objects can be hard to manage. For instance, I have a “Game Manager” object with a lot of information about the Game State that needs to be passed around all over the place. This becomes especially difficult when the connections are set up in the Unity Editor. I’m curious if a Dependency Injection library like Zenject might make it easier to manage connections between game objects.
Next up: Making it Fun
Back to the game itself – now that the core game loop is playable, and now that I have a firmer grasp of Unity, the next step will be making an experience that’s actually fun. The main things I’m going to focus on are:
  1. Items. I really like the idea of players running around the space, and discovering cool items that give you special powers. Maybe you might find an invisibility cloak! I also think that weapons might vary in strength, which different weapon types having different probabilities of killing your target. This could introduce interesting tradeoffs around immediately going after your target, or holding off for something better.
  2. Combat. Currently, you basically just walk up to your target and hit “F”. I’m wondering if there’s something better we can do here!
  3. Needs. A dynamic I’d love to play around with too is the idea that characters have “needs”, like “hunger”, or “entertainment” that they need to fulfill. The natural way to achieve that here is through items that you can discover in various chests around the space.
Once I’ve ironed out some of the bugs, I’m going to start playing this with some friends, and see what hits!
That’s all for now, thanks for reading!
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