The Implementation of Rewind in Braid
GDC Festival of Gaming2 HN recommenders · 2018–2023
141K views · talk · evergreen · Uploaded 2016-12-12
Jonathan Blow's GDC talk explains how the time-rewind mechanic in Braid was designed and implemented, including the technical hurdles such as memory limits and state history. It covers both design and engineering concerns.
HN commenters cite it as the reference for how a rewind system works and as a point of comparison for undo and serialization approaches.
15:38Juice it or lose it - a talk by Martin Jonasson & Petri Purho
grapefrukt
44:10Jan Willem Nijman - Vlambeer - "The art of screenshake" at INDIGO Classes 2013
Dutch Game Garden
1:04:04Overwatch Gameplay Architecture and Netcode
GDC Festival of Gaming
1:02:42Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)
DevGAMM
42:30RustConf 2018 - Closing Keynote - Using Rust For Game Development by Catherine West
Rust Programming Language
1:10:00A Deep Dive into Nanite Virtualized Geometry
SIGGRAPH Advances in Real-Time Rendering
31:37How Crash Bandicoot Hacked The Original Playstation | War Stories | Ars Technica
Ars Technica
1:15:51Jonathan Blow - How to program independent games - CSUA Speech
Alexandre Franco
6 comments from Hacker News
Seconded. It was a great game, albeit with not so much replay value. There is a great interview with Blow on the technicalities of the warping effects in Braid: [VIDEO] In addition to Limbo and Inside, may I also recommend: Portal 1&2 Antichamber VVVVVV increpare.com In particular Stephen Lavelle (@increpare) makes games with much darker and more interesting social implications. Although, Braid accurately predicted the "nice guys" trope.
It is interesting to compare this to Jonathan Blow's talk on the rewind system in Braid [1]. This stores complete game states using a compression library to keep memory under control, whereas Braid stored a combination of keyframes, and diffs from those keyframes, to avoid using a compression library. [1] [VIDEO]
I don't really agree. Cache friendliness is almost always a relevant factor as soon as performance becomes an issue. I get what you're saying but as I see it immutability gives you architectural efficiency and in some cases space efficiency, but rarely processing speed. > Think video games like braid Braid doesn't use immutable data structures, it uses a historical record (and immutability would be incompatible with some of the mechanics).[1] The author of Braid is actually quite famous for his dislike of functional languages and immutability. He doesn't even like garbage collection because of the overhead it introduces. Interestingly, he was talking about data structures for codebase representation (in the context of a compiler) a while back, and someone mentioned HAMTs. I'm definitely curious if they would work well there. [1] [VIDEO]
Is difficulty of implementation really a reliable indicator for the complexity in players understanding the mechanic? Jonathan Blow did a talk[1] at GDC a few years ago about implementing the time rewind mechanic in his game, Braid. It ended up being a pretty complex system that required a lot of ingenuity to come up with a design and implement it, but the end result is pretty straightforward and easy to understand for players. [1] [VIDEO]
> I don't think that's an earned position. I disagree. > You say he has more credits but only one of those is programming since Braid. He did start a company after that you know. A successful one that makes money and employs people to make art . I don't imagine that running a business takes no time from his life. > But even at the time Braid could have been written in python SDL wrappers and probably had similar performance Braid did a lot more than you give it credit for. Here's a GDC talk about the rewind system in which he explains some of the hurdles he had to deal with: [VIDEO] Pay particular attention to the discussion of the background particles and how to get that to work within the RAM constraints. > On the other hand, on a software engineering level those paint by numbers Modern Warfare and FIFA games are both more technically impressive and are designed for fast iteration Hardly anything about these games change from release to release. They're not exploring new gameplay problem spaces, they're not doing anything super interesting or surprising on a technical level either and I don't get why you think they are. Of course if you keep using essentially the same engine and know exactly what you're trying to make, making another like a goddamned factory is going to happen quicker than if you're trying to make something unique and meaningful. > If clean code is about maintenance and time to market, the Blow paradigm hasn't proven that its needed or fixes the holes in cl
If you're curious how the time rewind was implemented, Blow did a GDC presentation back in 2010. [VIDEO]