5 ms·

The complexity of their game engine must be staggering...

jerf 18y ago
Not necessarily. While playing Braid, in the back of my head I was reverse-engineering the engine. It's a programmer thing. I'm sure you can all relate. :) Anyhow, if you come at this sort of program in the imperative mindset, it looks impossibly complicated. Imperative programs live in the now, constantly fiddling with their state with no ability to go back. But if you come at this from a functional viewpoint, suddenly it's not so hard; functional programs naturally live in a timeless way and the challenge there is to actually hook them up to reality in a meaningful way! Instead of recording the state and constantly mutating it, you record the inputs and replay them as needed. The engine will be entirely deterministic, so the game state can be freely rolled back and forth. And, here's the key: While retrofitting an imperative program to do this would be a nightmare, if you know what you are doing and you start with the understanding you need this, it's not so hard. You build a small test engine with the ability to do just one thing (maybe move units around), work out the necessary primitives, then start expanding the engine, maintaining the necessary properties as you go. You grow it from a small, maintainable seed. This is where, even though you can't go to school and take "mutatable chronology mathematics", it really helps if you have a lot of math under your belt, because you need to be thinking in terms of invariants and maintaining properties and other such mathematical things. Sitting down to just hack this out Will. Not. Work. Oh, I don't want to trivialize the accomplishment. This is the basic structure, but you're still going to encounter fundamental contradictions you need to work out how to resolve, and there will be tricky interactions that don't work quite right, and slight violations of some relevant property (that you may not even have fully understood or articulated) may manifest as some of the subtlest bugs you've ever seen (with their only saving grace being that they should be fully replicatable, in a system that basically has a time-traveling debugger). My point here is that while it is complicated and possibly the subtlest real-time strategy engine ever built, it is not as complicated as your imperative intuition is telling you. It's just fiendishly complicated, not impossibly complicated.
- stcredzero 18y ago
  It doesn't even have to be fiendishly complicated. Each "time wave" is simply a different run of the simulation engine, with a differing set of inputs. The videos also explain how seemingly paradoxical situations, like units fighting alongside time-shifted selves are handled. The JWARS simulation engines built by the US Department of Defense (in Smalltalk, BTW) could handle theater-wide simulations down to the individual soldier level at 10,000X speed, and this was implemented in Smalltalk many years ago. Handling a dozen or two dozen "time waves" in parallel shouldn't be too much of a burden.
  - jerf 18y ago
    I called it "fiendishly complicated" in this case because even if the code is simple when written out, the underlying mathematics is tricky. A programmer off the street couldn't just wander up and modify it meaningfully in the way that a programmer can hack on the Quake III engine without breaking it; the slightest change could cause massive bugs, if you're not maintaining the invariants. The word "fiend" is chosen carefully :) The chronoporter is underspecified by the demo (which is not surprising and I do not mean as a criticism, buy the game to find out more). I can come up with several possibilities for how that works in game terms that match what we see in the demo, each with their own problems and benefits for the player.
    - stcredzero 18y ago
      What I'm talking about doesn't take any fancy mathematics. Earlier in this thread, someone else was talking about functional programming. You could do the same thing with OO, deterministic pseudo-random generators, and a few patterns like Action. All you have to do is support multiple time-shifted simulations in parallel, and you are mostly there. The complicated part is displaying "overlaps" but that is also not "fiendish." (And the game dynamics discussed in the videos would make that much easier.) What is truly clever is the introduction of the propagating "Time Waves" in the first place! Once you have that insight, such a game becomes easier to envision implementing.
      - 18y ago

jerf 18y ago

Not necessarily. While playing Braid, in the back of my head I was reverse-engineering the engine. It's a programmer thing. I'm sure you can all relate. :) Anyhow, if you come at this sort of program in the imperative mindset, it looks impossibly complicated. Imperative programs live in the now, constantly fiddling with their state with no ability to go back. But if you come at this from a functional viewpoint, suddenly it's not so hard; functional programs naturally live in a timeless way and the challenge there is to actually hook them up to reality in a meaningful way! Instead of recording the state and constantly mutating it, you record the inputs and replay them as needed. The engine will be entirely deterministic, so the game state can be freely rolled back and forth. And, here's the key: While retrofitting an imperative program to do this would be a nightmare, if you know what you are doing and you start with the understanding you need this, it's not so hard. You build a small test engine with the ability to do just one thing (maybe move units around), work out the necessary primitives, then start expanding the engine, maintaining the necessary properties as you go. You grow it from a small, maintainable seed. This is where, even though you can't go to school and take "mutatable chronology mathematics", it really helps if you have a lot of math under your belt, because you need to be thinking in terms of invariants and maintaining properties and other such mathematical things. Sitting down to just hack this out Will. Not. Work. Oh, I don't want to trivialize the accomplishment. This is the basic structure, but you're still going to encounter fundamental contradictions you need to work out how to resolve, and there will be tricky interactions that don't work quite right, and slight violations of some relevant property (that you may not even have fully understood or articulated) may manifest as some of the subtlest bugs you've ever seen (with their only saving grace being that they should be fully replicatable, in a system that basically has a time-traveling debugger). My point here is that while it is complicated and possibly the subtlest real-time strategy engine ever built, it is not as complicated as your imperative intuition is telling you. It's just fiendishly complicated, not impossibly complicated.

stcredzero 18y ago
It doesn't even have to be fiendishly complicated. Each "time wave" is simply a different run of the simulation engine, with a differing set of inputs. The videos also explain how seemingly paradoxical situations, like units fighting alongside time-shifted selves are handled. The JWARS simulation engines built by the US Department of Defense (in Smalltalk, BTW) could handle theater-wide simulations down to the individual soldier level at 10,000X speed, and this was implemented in Smalltalk many years ago. Handling a dozen or two dozen "time waves" in parallel shouldn't be too much of a burden.
- jerf 18y ago
  I called it "fiendishly complicated" in this case because even if the code is simple when written out, the underlying mathematics is tricky. A programmer off the street couldn't just wander up and modify it meaningfully in the way that a programmer can hack on the Quake III engine without breaking it; the slightest change could cause massive bugs, if you're not maintaining the invariants. The word "fiend" is chosen carefully :) The chronoporter is underspecified by the demo (which is not surprising and I do not mean as a criticism, buy the game to find out more). I can come up with several possibilities for how that works in game terms that match what we see in the demo, each with their own problems and benefits for the player.
  - stcredzero 18y ago
    What I'm talking about doesn't take any fancy mathematics. Earlier in this thread, someone else was talking about functional programming. You could do the same thing with OO, deterministic pseudo-random generators, and a few patterns like Action. All you have to do is support multiple time-shifted simulations in parallel, and you are mostly there. The complicated part is displaying "overlaps" but that is also not "fiendish." (And the game dynamics discussed in the videos would make that much easier.) What is truly clever is the introduction of the propagating "Time Waves" in the first place! Once you have that insight, such a game becomes easier to envision implementing.
    - 18y ago