18

Today, I've read about FRP (functional reactive programming). However, I don't know how much this fits in the engine itself.

After reading Gerold Meisinger's article, my question is, if it's worth it to use FRP instead of a component-based architecture. Is this the near future of game engine architecture design? It's just a simple approach on solving small problems component-based architectures do? I'd appreciate any article, explanation, personal opinion, etc.

Think about an engine for a commercial game, specially shooters or racing genres (3D games). Don't think about a 2D platformer or other simpler (talking about engine complexity) ones. I'd use C/C++ (I noticed people using FRP rely on Haskell, due to its nature. However, I saw this document and prefer to stand on C++, as the "industry standard").

frarees
  • 2,034
  • 3
  • 17
  • 22

2 Answers2

19

C++ isn't naturally suited for FRP; any libraries you use (Boost.Phoenix is a good one) will carry some overhead that you most likely don't want to deal with in a commercial 3D game.

Not only that, but FRP isn't a very well developed technique for games, not even in Haskell, afaik; do you want to make a game or do you want to develop a technique for making games?

Component-based entity systems have been around for quite a while and are a proven concept. They do have their limitations, most notably, how do components communicate with each other? — one solution is to have two types of components, attributes and behaviours; the latter can access any attribute, but they cannot access each other.

If you want to make a game, go with CBS. If you want to help develop FRP in games, then do that.

Btw, you're so very wrong to say that 2D games have simple engines. :)

2014 Update

A new language has since appeared that make extensive use of functional reactive techniques and is aimed at web development, called Elm. It is very similar to Haskell and is supported by Prezi, afaik. The language designer had a pretty good presentation in which he made a small game using FRP. Anyone interested in how FRP should be handled might want to look at that video.

Paul Manta
  • 27,853
  • 27
  • 109
  • 192
  • Oh I see. Thanks for your help. I want to develop a 3D game, but also want to get into core engine "mechanics" (or whatever name you give to it), analyzing all the possible solutions when it comes to architecture design. About 2D engines, I've said that they are simpler not simple, but yeah still not a proper affirmation ;) Btw, do you know any book, article, etc. talking about proper construction of a CBS, in terms of performance? I read sending messages over components is expensive, and in some cases it's "better" (when it comes to overhead cost) to pass pointers to those components. – frarees Nov 30 '11 at 23:05
  • 2
    @frarees Messaging systems are for things that happen 'rarely' (like a key being pressed, someone dying) ('rarely' means not every frame). Components communicate with each other a few time per frame, so messaging systems are not good. How would you efficiently notify each interested component of the entity's position every single frame, by using messages? • One thing you could do is establish dependencies between components when they are constructed (pass the other components they communicate with to the constructor). – Paul Manta Nov 30 '11 at 23:36
  • 2
    @frarees [cont'd] But then the problem is, how can you ensure that when you create a new component, all the components it needs have already been created? What if two components need each other? This is where the attribute/behavior separation becomes useful: you first create all needed attributes, then you create behaviors and pass them (in the constructor) the attributes they need. Behaviors never interact directly with one another, they only modify the attributes' values. And attributes do nothing; they are just containers for data. – Paul Manta Nov 30 '11 at 23:43
  • Great. Attributes & behaviors makes sense. Thanks for your help :) – frarees Nov 30 '11 at 23:50
  • My CBS is a bit different. I create interfaces that my components implement. I also have custom RTTI that keeps track of these implementations. So once I create Entity and fill it up with components I call linking method that makes each component query the entity for components implementing specific interfaces and store pointers to them. For example a rendering component will need to know the transformation but it doesn't need to know if the object is static or attached to some animated entity all it needs is ITransformable* that is used during Update of the component. – Aleks Dec 03 '11 at 02:01
  • @Aleks Of course, are's more that one way to implement CBS. :) Custom RTTI is something I've been having problems myself; I posted [this question](http://stackoverflow.com/questions/7943854/custom-rtti-for-use-in-script-defined-types), but didn't get any satisfying answers. Care to help me out? :) – Paul Manta Dec 03 '11 at 08:37
  • Don't you guys see the fundamental flaw of the CBS approach? :) If I only could get a research project approved for this topic I could spent more time dissecting it... but in the meantime "Argh!" >_ – Gerold Meisinger Mar 11 '12 at 22:02
  • @lambdor No one said it's perfect, but why are you so much against it? :) – Paul Manta Mar 11 '12 at 22:24
  • My impression in talking with a few programmers is that they are so dazzled by the fact they can win back a little more re-usability with game-object components, they don't spent time analyzing what's wrong in the first place. For example your attribute approach appears to me that there is a lot of dynamic functionality where it shouldn't be and no clear initialization sequence, so you need to invite some kind of dependency resolving. – Gerold Meisinger Mar 11 '12 at 23:02
  • @lambdor I don't use any of dependency resolving mechanisms. As a kind of "proof", my entity system has no managers. You create the attributes, then you create the behaviors, there's no extra steps you need to take in resolving the dependencies. I go into a bit more detail here: http://gamedev.stackexchange.com/a/23759/6188 – Paul Manta Mar 12 '12 at 06:19
3

Short answer: probably none of them!

However, I don't know how much this fits in the engine itself.

I don't understand what you mean by that but every piece code that involves time (i.e. uses update( float elapsedTime )) usually fits for FRP - in theory. About "fit in engine", maybe HaskellWiki Yampa - Game Engine helps to answer your question (a trimmed-down and english translated version of my thesis which explains the overall architecture). From the discussions about FRP and from reading some FRP papers, it appears that there are still some unresolved issues with the overall theoretical concept, thus I'd recommend doing some thorough testing before using any FRP library in a commercial project (especially performance and memory issues). Take a look at the Frag video. It's an shooter written in FRP and the most advanced example today.

Think about an engine for a commercial game, specially shooters or racing genres (3D games).

Hm, what is your focus? Are you developing a commercial game? Then use an existing engine and don't worry about it! Are you developing an engine? Then FRP might be an interesting concept. Varying game objects with components shouldn't be necessary for shooters and racing games as they only use very few different game objects and focusing too much on the architecture might be over-engineering. Don't have a focus? Get a focus! You can't develop the next IdTech engine AND the next Doom game on your own.

I saw this document and prefer to stand on C++, as the "industry standard"

There are some libraries for C++ too. Search for "reactive or temporal programming".

Gerold Meisinger
  • 4,411
  • 5
  • 22
  • 33
  • As of this comment, Starbound is written in a proprietary game engine called Cove written in Haskell with FRP. – Daniel Sun Yang Feb 20 '15 at 21:02
  • Could you provide a cite please. The only info I could find is that the developers of "Wayward Tide" use Haskell who happen to work under same publisher "Chuckle Fish". http://blog.chucklefish.org/?p=154 – Gerold Meisinger Feb 23 '15 at 11:03