@Avi Dessauer last time I said briefly that in my experience writing a few games that I liked FRP and didn't like ECS (they fill different roles, but that's beside the point). I didn't have a clear thought of why I felt the way I felt, but now I do. The reason I like FRP, but don't like ECS or OOP for games and UIs, is because
most of the difficult things in programming games and UIs are not
declarative. Things happen temporally, and a large number of bugs are due to
incorrect ordering. I want to write a function that acts on ALL of state in an
ordered manner, and it can be made up of helper functions that can be zoomed in
when possible (by limiting scope). In OOP and ECS you are limited to certain
scope (in OOP this is the class) and but often you have to contain a reference to
a larger scope thereby defeating the purpose of scoping, to begin with (yes there
are mitigation techniques for these problems, but without ECS, and OOP these
problems never existed). This is related to my issue with Objects referencing
their parents. In OOP/ECS you have functions accessing global state with
nonsense type annotations ordered confusingly. In an imperative style, you
have "global function" that processes all of state made up of smaller functions
that are made up of smaller functions. FRP is the same, but FRP has a greater
vocabulary for composition (in the imperative style we mostly just have function
composition and sequencing). So I don't like the model of Objects with
callbacks, but that doesn't mean I hate declarative style. I think declarative
things should be declarative. I think having sum types + pattern matching >
control flow every day of the week. My level layout shouldn't worry about time or
ordering since it isn't relevant to the problem. Data/info should be
declarative, but game logic can be temporal.
please let me know if I can clarify further
imo it's a pretty natural decomposition of the problem; implement each small piece of functionality as an ECS transformation and you get the composition "for free"
I have to agree with Sandy.
The order of each systems execution is determined by data dependence, and each system is run once per global step. So long as systems are pure ordering is simple.
I have gotten FRP to work for toy examples, but I feel like there needs to be a library tailored towards games for it to really work, and be worthwhile for a larger project. I hope I can talk to someone who has written an FRP library, so I could get some insight as to how one might go about writing this library. To be fair to ECS I haven't used it for a large project before. My Game Dev timeline goes OOP -> OOP + Unity -> OOP -> mostly imperative with many functional ideas/ experimentation with many different patterns (briefly touching ECS). I have only a few games I've spent more than a month on, and most large recent endeavors have involved net code so that's an extra layer of complexity. Generally I feel like most ECS functionality could be just a function, and by doing that you get to be really clear about what it has access to, and when it's being called. I also have an aesthetic distaste for the kind of world modeling that goes into pattern goes into these patterns so I might be biased. Anyway I think people should use what they like at the end of the day, so I won't push my opinion too much more. The original thought was as someone who does imperative game dev stuff sometimes FRP appeals to me while other patterns don't, and I could see how on paper someone could think FRP is a closer cousin to something like ECS, especially since they are at a higher level of abstraction.
yeah frp works in the small for me, but as soon as i want to add a menu screen or something it goes off the rail --- unless you have monadic frp, which is its own can of worms
I have the impression dunai is the modern FRP lib currently suited for games - because it has Yampa in its lineage, and Yampa has been used to make actual games.
Or perhaps Yampa itself is still best, since it has a debugging tool ?
Is continuous semantics of frp useful for games? Maybe discrete semantics is enough?
In the past I've used the signals api in elm and purescript to make games and it was decent. I also used a simple iterative loop (in Haskell) and it was decent as well.
I have used Yampa, and liked it. I don't understand how to works under the hood at all which I imagine would become an issue if I wanted performance on a larger project. I'd be curious to see how I like an ECS in Haskell with our purity and whatnot so I might end up trying out @Sandy Maguire's ECS.
@Avi Dessauer last time I said briefly that in my experience writing a few games that I liked FRP and didn't like ECS (they fill different roles, but that's beside the point). I didn't have a clear thought of why I felt the way I felt, but now I do. The reason I like FRP, but don't like ECS or OOP for games and UIs, is because
most of the difficult things in programming games and UIs are not
declarative. Things happen temporally, and a large number of bugs are due to
incorrect ordering. I want to write a function that acts on ALL of state in an
ordered manner, and it can be made up of helper functions that can be zoomed in
when possible (by limiting scope). In OOP and ECS you are limited to certain
scope (in OOP this is the class) and but often you have to contain a reference to
a larger scope thereby defeating the purpose of scoping, to begin with (yes there
are mitigation techniques for these problems, but without ECS, and OOP these
problems never existed). This is related to my issue with Objects referencing
their parents. In OOP/ECS you have functions accessing global state with
nonsense type annotations ordered confusingly. In an imperative style, you
have "global function" that processes all of state made up of smaller functions
that are made up of smaller functions. FRP is the same, but FRP has a greater
vocabulary for composition (in the imperative style we mostly just have function
composition and sequencing). So I don't like the model of Objects with
callbacks, but that doesn't mean I hate declarative style. I think declarative
things should be declarative. I think having sum types + pattern matching >
control flow every day of the week. My level layout shouldn't worry about time or
ordering since it isn't relevant to the problem. Data/info should be
declarative, but game logic can be temporal.
please let me know if I can clarify further
I dunno how much I agree with this. At the end of the day a game is just a pair of functions
Input -> State -> StateandState -> Imagei view ECS as a way of driving complicated transformations inside the state that are too finicky to describe operationally
imo it's a pretty natural decomposition of the problem; implement each small piece of functionality as an ECS transformation and you get the composition "for free"
although i'll grant you that the ordering in which they run can be important, and when it is, weird bugs do occur
though the exact same problem happens in more procedural approaches
personally i haven't had much work getting FRP to work for me in games. i've been trying for about six years and never once had the "aha!" moment
though i am not convinced this is a failure in frp; maybe i'm just dumb
I have to agree with Sandy.
The order of each systems execution is determined by data dependence, and each system is run once per global step. So long as systems are pure ordering is simple.
(also i have no idea what the context is here)
I have gotten FRP to work for toy examples, but I feel like there needs to be a library tailored towards games for it to really work, and be worthwhile for a larger project. I hope I can talk to someone who has written an FRP library, so I could get some insight as to how one might go about writing this library. To be fair to ECS I haven't used it for a large project before. My Game Dev timeline goes OOP -> OOP + Unity -> OOP -> mostly imperative with many functional ideas/ experimentation with many different patterns (briefly touching ECS). I have only a few games I've spent more than a month on, and most large recent endeavors have involved net code so that's an extra layer of complexity. Generally I feel like most ECS functionality could be just a function, and by doing that you get to be really clear about what it has access to, and when it's being called. I also have an aesthetic distaste for the kind of world modeling that goes into pattern goes into these patterns so I might be biased. Anyway I think people should use what they like at the end of the day, so I won't push my opinion too much more. The original thought was as someone who does imperative game dev stuff sometimes FRP appeals to me while other patterns don't, and I could see how on paper someone could think FRP is a closer cousin to something like ECS, especially since they are at a higher level of abstraction.
absolutely fair.
yeah frp works in the small for me, but as soon as i want to add a menu screen or something it goes off the rail --- unless you have monadic frp, which is its own can of worms
though my experience there was mostly as a babby haskell programmer, so i was probably not modeling very well
i'm actively designing an ECS library, which is maybe why i bristled earlier!
I have the impression dunai is the modern FRP lib currently suited for games - because it has Yampa in its lineage, and Yampa has been used to make actual games.
Or perhaps Yampa itself is still best, since it has a debugging tool ?
Perhaps reflex also works for games.
Is continuous semantics of frp useful for games? Maybe discrete semantics is enough?
In the past I've used the signals api in elm and purescript to make games and it was decent. I also used a simple iterative loop (in Haskell) and it was decent as well.
I'd be curious to see. I've never seen an FRP game engine before. :)
Was this directed at me?
My games are very simple and aren't really using "engines" but I can link them if you want.
I have used Yampa, and liked it. I don't understand how to works under the hood at all which I imagine would become an issue if I wanted performance on a larger project. I'd be curious to see how I like an ECS in Haskell with our purity and whatnot so I might end up trying out @Sandy Maguire's ECS.