![]() Right after that occurs, the player’s score is submitted to the backend. ![]() The next FixedUpdate, it does it all over again.įinally, when the player receives their final death, the replay encoder writes an EndOfStream message and flushes the buffer. At the end of every FixedUpdate, the replay encoder writes a special message type, the FrameBarrier. ![]() When an event that it cares about occurs - for example, when the player is damaged - it immediately records the event to an in-memory buffer. The replay encoder is always listening for events while the game is running. However, this allows us to save a lot of overhead which would otherwise be used for padding. Once we become misaligned with the replay messages there’s no marker from which to recover - it’s just a bunch of bits. This does mean that one bug in replay reading is catastrophic. If that means a message is 7 bits and doesn’t end at a byte barrier, oh well - just use the next bit for the beginning of the next message. For instance, we pack enums with four values or less into two bits, and flags into just one bit. These two properties allow us to very tightly pack the messages. Replay messages are not byte-aligned, and they are fixed in size (though that size may differ based on the replay version). For instance, PlayerDamaged only has one piece of information, the entity ID of the enemy which damaged the player, so that we can highlight that enemy during the death slo-mo. Other message types contain other data, depending on the type. ![]() Data for the EntityMoved message includes an identifier indicating which entity moved, along with its new position and rotation: The replay data is simply an array of replay messages consisting of (1) a message type, and (2) the message data.Įxample message types include EntityMoved, PlayerDamaged, and PowerupPickup. Immediately after the metadata, replay data begins. The only things in this metadata are a 4-byte magic string, followed by a 4-byte version number so we can keep backwards compatibility with old versions. High-level Details The Replay FormatĮvery replay file begins with a metadata header describing the contents of the file. So, now that I’ve covered they why, let’s get into the interesting part - the how. Of course, I need to credit to Dustforce and Devil Daggers, the games which gave me the inspiration to implement this feature into our own game. These two benefits - serving as an anti-cheat and getting players un-stuck - provide a huge benefit to Breakpoint. It changes “How the hell did that player get eleven million points? I can never get there!” into “Oh, okay, so that’s how they did it, let me give it another try!” Players can also learn new strategies from others using the replay system, too, turning negativity to positivity at the end of a run. Simply by clicking on another player’s name, they can instantly start watching the replay of that player’s high score run. Replays ensure fairness by allowing any player to check the validity of another player’s scores. The in-game replay system is our solution to this problem. If cheaters begin showing up on the leaderboard, confidence erodes, and players feel that there’s no point in chasing high scores of their own. The sanctity of the leaderboards is critical to ensuring that players feel that the game is fair. The leaderboard is centrally important, providing players the reason to play the game - to better their own scores, and to surpass others. It released pretty recently, so go check it out!īreakpoint is an arcade game centered around chasing high scores. Since November of 2019, Nick Amlag and I formed a video game studio and shipped Breakpoint, a twin-stick action game with exploding melee weapons. (), but your browser doesn't support mp4s! Breakpoint Replays - Technical Deep Dive Oct 21, 2020
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |