4 ms·

This talk kind of alludes to the data driven stuff at the end: https://youtu.be/vK1DazRK_a0?t=774 https://youtu.be/vK1DazRK_a0?t=774 It's a shame the code exa

• joshlemer 6y ago
  In his refactoring of the JS game, I was with him until about 80% through his refactor, but in the change he describes from about 50:50 - 51:00, he's actually changing the meaning of the game. Instead of printing after each turn, he's running all turns, then printing them all out at once. This is a very different behaviour and I think it's glossing over / copping out from the difficulties of applying FP in side-effectful codebases. I mean in this case, he's transformed the program from running with a constant amount of memory (only need as much memory as it takes to run a turn) to having to store the entire history in memory. So this would be really bad if there were many turns, or if the program was going to run indefinitely, responding to user input, etc.
  • hunterloftis 6y ago
    ...or simulating the world every 16 ms as is typical in a "real" game. You can bridge that gap by taking periodic snapshots of the reduced state, which is a useful pattern in distributed game development where you sometimes have to back-track and re-simulate when input arrives over the network.