Which brings me to the central thesis of this post: More is Less. I am hazy as to whether the bugs were actually fixed before launch, but suffice to say the change never ended up being included in any beta patch notes. This was further exacerbated by the fact that the change was purposely left out of patch notes (there were 3 more beta releases after the feature was added), explicitly because there were some unfixed bugs in the initial implementation. This was obviously too close to launch to do sufficient testing, or even to properly consider the ramifications of this change. (Meanwhile I was coming down with an extremely bad cold, made worse due to the stress and crunch time of launch.) Then, about 4 days before we shipped, Daniel decided that this feature – in the form of the second option – was important enough for us to add at the last minute. But we did keep the second option in the back of our minds, to perhaps implement when development time became available. For the vast majority of development, we went with the first option – as it required zero extra implementation effort. This left two other options: Simply use the unlock list of the host (the same as couch play) or allow the joining player to bring one of their characters into the game with them. And having four full unlock lists in game would have exceeded it.) (Additionally, there is a limit on the total size of the “live” game state. And, even with substantial data packing work, impossible to fit inside the 64-byte warning limit I had set much earlier in development. Unfortunately, the amount of data required by the unlock list was significantly more than was safe to transmit when joining (kilobytes). The further intention was that players could keep those changes across different network games, as well as carry them into single player. The reason this “player-join-data” feature was added to the netcode was specifically so we could allow players to bring their list of unlocked characters into network games, play as them, upgrade their stats, and unlock new characters. This starts to become an issue if multiple join and leave events happen in quick succession, particularly across a host-migration.) This means that player join data can be buffered, replayed, and re-transmitted almost arbitrarily. (Details: Our game is P2P and supports drop-in-drop-out at any time, including support for host-migration. When I wrote that part of the netcode, I inserted a warning when the size exceeded 64 bytes. This post is to explain how such a difficult-to-fix bug ended up being shipped in the first place.įirst we need to start with a small piece of technical information: In a networked game, the amount of data we can add to the game state with a joining player is tiny. This represents about 1% of our total source code (and close to 2 weeks of my time). If you follow me ( or the game ( on Twitter, you’ll know that the change set for this clocked in at around 3.5 thousand lines of code. It’s now been two weeks, and we’ve just rolled out the much larger fix for the infamous “ multiplayer save bug”. We had a few nasty bugs crop up on day 1, and we fixed the worst of them right away. The launch of River City Ransom: Underground went pretty well, all things considered.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |