5 ms·
After playing around with making a simple, somewhat function programming-style engine [1], I came to the conclusion (from other people's work) that the game loo
by allenu 8y ago
After playing around with making a simple, somewhat function programming-style engine [1], I came to the conclusion (from other people's work) that the game loop is really just iterating on a pure function call that gives you the next world state given the previous world state:
next_world_state = UpdateWorld(inputs, previous_world_state)
Where inputs is all external inputs (user inputs and "time"). How the inputs is updated (and how frequently) is totally decoupled from how the game engine operates. Additionally, from the next_world_state, you can derive what to render to the screen, what audio to play, what text to render, etc. If you want to drop frames, just don't render each world state.
[1] https://github.com/allenu/YokosukaJS https://github.com/allenu/YokosukaJS
- dfischer 8y agoJust read something similar with Urbit: https://urbit.org/docs/introduction/technical-overview/ https://urbit.org/docs/introduction/technical-overview/ Taking that concept to an operating system essentially. > Your urbit is a deterministic computer in the sense that its state is a pure function of its event history. Every event in this history is a transaction; your urbit's state is effectively an ACID database. > Because each urbit is deterministic we can describe its role appropriately in purely functional terms: it maps an input event and the old urbit state to a list of output actions and the subsequent state. This is the Urbit transition function.
- platz 8y agothis appears to use the sleep method for the game loop described in the OP article, as opposed to a fixed update interval and interpolated render step.