The Implementation of Rewind in Braid

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: ▶ this 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.

> 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: ▶ this 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 clean code. I have heard "maintenance and scaling" as an excuse for poorly performing software for a long time now, yet what I'm not seeing is software that has features added on quick schedules and without bugs. So at best I'd say that it isn't accomplishing what it is supposed to and, at the same time, it is wasting our time and resources by producing slow software to boot.

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] ▶ this 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] ▶ this video