4 ms·

For games and other reactive systems, you should check out functional reactive programming (FRP)[1]. The basic idea is to model time explicitly, working with ti

by tikhonj 14y ago

For games and other reactive systems, you should check out functional reactive programming (FRP)[1]. The basic idea is to model time explicitly, working with time-varying values. So you would express your game logic as a network of event streams and signals. [1]: http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming http://stackoverflow.com/questions/1028250/what-is-functiona... This is a radically different from the normal imperative approach, and I've found it to be much nicer. Admittedly, I haven't tried making games per se, but I have used it successfully for several other interactive UI programs. FRP is a good approach for any system where you would normally use events and callbacks. This includes UIs and games as well as things like controllers or even music. So at least for that sort of IO-heavy and stateful domains, there is a very good declarative approach.

pacala 14y ago
FRP is super nice, but no magic. I found that it makes it natural to decompose the codebase in model/view/controller and encourages an explicit state machine for updating the model. At the same time, a time-varying value is a plain old observable. But the discipline enforced by FRP avoids the spagetti trap most event-based systems eventually fall into. No magic, therefore useable my mere mortals :)
jarrett 14y ago
Now that is really cool. You've convinced me that this could be a viable and practical approach to handling highly stageful programs in an FP context. One question though: Does memory/storage become an issue if you're keeping track of values "over time?" If I understand it correctly, you'd have a constantly growing picture of your data as it has evolved, with a complete history of prior values. (Maybe I'm wrong about this part, though.) For applications that are long-running or handle a lot of data, could this be a fatal problem?
- tikhonj 14y ago
  You're not necessarily keeping track of all the old values over time. Rather, the core idea is that you program in terms of abstractions that are explicit about time. That is, you write your program in terms of streams of events or signals. You have signals and events, but you never ask about the value right now; instead, you take these two abstractions and combine them in different ways to get a reactive network. In a way, it's similar to dataflow programming or circuit design: you connect up "wires" into a network that can constantly push through data. Depending on how you write this network, you will need to remember different amounts of past data at runtime. If you write your event/signal network carefully, you do not need to keep a history of too many prior values at runtime. This is one of the things modern FRP libraries really try to help you with: writing networks that are efficient. At least the ones I've tried are good at this--I haven't had many space problems in my programs so far. In summary, this is a potential issue, and you may have to be a little careful in how you write your FRP code. However, modern frameworks try to make it easy to avoid these pitfalls, and there is no fundamental reason you can't use memory efficiently with this model.
  - lightblade 14y ago
    I'm pretty new to FRP, but I tend to visualize FRP like an Excel spreadsheet where one value change leads to a chain reaction of many values in the spreadsheet. Would this paint the right picture?
    - flyinRyan 14y ago
      Very well. In fact, one of very first implementations I've ever heard of was done in Lisp and it was described exactly in this way. I think the library is even called "Cells".
- muraiki 14y ago
  For an example of making Pong using FRP, check out this: http://elm-lang.org/blog/games-in-elm/part-0/Making-Pong.html http://elm-lang.org/blog/games-in-elm/part-0/Making-Pong.htm... It's not a very long read, and it will help make FRP more concrete with a practical example.
  - axilmar 14y ago
    Well, if the game state is so small, then it's quite easy to combine all these functions together in FRP style. How about big games though? for example, World Of Warcraft or Eve Online. The game states of these are humongous, and the game state's data constructor would be huge.

by tikhonj 14y ago

pacala 14y ago

FRP is super nice, but no magic. I found that it makes it natural to decompose the codebase in model/view/controller and encourages an explicit state machine for updating the model. At the same time, a time-varying value is a plain old observable. But the discipline enforced by FRP avoids the spagetti trap most event-based systems eventually fall into. No magic, therefore useable my mere mortals :)

jarrett 14y ago

Now that is really cool. You've convinced me that this could be a viable and practical approach to handling highly stageful programs in an FP context. One question though: Does memory/storage become an issue if you're keeping track of values "over time?" If I understand it correctly, you'd have a constantly growing picture of your data as it has evolved, with a complete history of prior values. (Maybe I'm wrong about this part, though.) For applications that are long-running or handle a lot of data, could this be a fatal problem?

tikhonj 14y ago
You're not necessarily keeping track of all the old values over time. Rather, the core idea is that you program in terms of abstractions that are explicit about time. That is, you write your program in terms of streams of events or signals. You have signals and events, but you never ask about the value right now; instead, you take these two abstractions and combine them in different ways to get a reactive network. In a way, it's similar to dataflow programming or circuit design: you connect up "wires" into a network that can constantly push through data. Depending on how you write this network, you will need to remember different amounts of past data at runtime. If you write your event/signal network carefully, you do not need to keep a history of too many prior values at runtime. This is one of the things modern FRP libraries really try to help you with: writing networks that are efficient. At least the ones I've tried are good at this--I haven't had many space problems in my programs so far. In summary, this is a potential issue, and you may have to be a little careful in how you write your FRP code. However, modern frameworks try to make it easy to avoid these pitfalls, and there is no fundamental reason you can't use memory efficiently with this model.
- lightblade 14y ago
  I'm pretty new to FRP, but I tend to visualize FRP like an Excel spreadsheet where one value change leads to a chain reaction of many values in the spreadsheet. Would this paint the right picture?
  - flyinRyan 14y ago
    Very well. In fact, one of very first implementations I've ever heard of was done in Lisp and it was described exactly in this way. I think the library is even called "Cells".
muraiki 14y ago
For an example of making Pong using FRP, check out this: http://elm-lang.org/blog/games-in-elm/part-0/Making-Pong.html http://elm-lang.org/blog/games-in-elm/part-0/Making-Pong.htm... It's not a very long read, and it will help make FRP more concrete with a practical example.
- axilmar 14y ago
  Well, if the game state is so small, then it's quite easy to combine all these functions together in FRP style. How about big games though? for example, World Of Warcraft or Eve Online. The game states of these are humongous, and the game state's data constructor would be huge.