Do you follow the development of SpyParty? If not, you should! It’s a really cool asymmetrical multiplayer game focused on deception and getting into the opponent’s head. The lead developer has some good thoughts about how to develop games, so there are some really interesting posts to read on his blog. Balancing a 1-on-1 game with completely different gameplay for each player is no easy task, but he’s doing a great job of it.
The other day, he posted an article about tracking down a persistent bug in SpyParty, one that popped up every now and then and caused real problems, but was not easily reproduced. The article does a great job of explaining the difficulties involved in debugging – a task that most players never really think about. Most player-submitted bug reports are along the lines of “I was playing the game and it crashed. Fix it.” Obviously, this is useless to the developers, since they have no way of figuring out what the player was doing when the game crashed. A good bug report should at least try to explain what the player was doing when the bug happened. Even if the player doesn’t know the exact cause, some level of description is needed.
I really like the author’s mantra: “assume it’s a bug”. I’ve had issues in my own work when I made the (incorrect) assumption that the problem I was seeing was the result of some physics engine weirdness or something else outside of my control. But that’s a dangerous mistake to make, and the underlying bug can bloom out into far worse problems when things get more complicated, especially when dealing with a complicated system like a physics engine. Always assume it’s a bug, try to fix it, and keep an eye on it, otherwise you’ll wind up shipping your game with persistent and impossible-to-find bugs.
I’m a fan of being modular with my code, so I’ve been breaking up every game object in Roadtrip into a collection of components: the player object has a component to gather input, another to apply walking movement, another to handle flashlight position and state, and so on. Unity seems to be built around the idea of the GameObject as a collection of components, so this works very well for the most part.
The problem with this setup is that you often run into the need for components to communicate – the flashlight component needs to know that the player pressed the key that turns the flashlight on, for example. So you start creating references to the other components, and pretty soon everything is dependent on everything else and you might as well have written it all as one script in the first place.
Thankfully, Unity has a GameObject method called SendMessage() that helps to solve this issue, and I’ve been using it all over the place in Roadtrip. SendMessage() lets you call a method on all components attached to an object, and it ignores components that don’t have a definition of that method, without causing an error. For example, when the player enters a vehicle, a message is sent out to all components in the player GameObject called “OnEnterVehicle”. The component that handles movement on foot responds by shutting itself off, and the component responsible for flashlight control automatically turns off the light.
After building this system into the core design of the player GameObject, it becomes very easy and straightforward to add new functionality to the player without having to go around changing a bunch of different scripts. It also means far fewer dependencies, which keeps the part of me that insists on modular design very happy. Want to add a radio to the truck that turns on automatically when a player gets in? It’s a simple matter of creating a new component for the radio and having it respond to the OnPlayerEnter message. There’s no need to have the main Truck script hold a reference to the radio. In fact, the radio doesn’t even need a reference to the truck, meaning we could potentially reuse the same script for a standalone radio in the world! How’s that for modular design!