[reactive] Using Reactive in a commercial video game - thoughts?

[Ryan Trinkle]

I'm a co-founder of a game studio that will be writing in (primarily) Haskell.  We're currently assembling the technology stack for our first game, and I'm very interested in FRP (Reactive in particular) as a way of making video game programming easier and less error-prone.  However, from reading this list and discussing it with people in #haskell on irc.freenode.net, it seems that there may be issues blocking us from using it within our timeframe (we plan to release our first game around November).

What known issues would prevent Reactive from being used today in a commercial video game?  Would you anticipate the discovery of many critical issues in the future?  What would it take to overcome these issues?


Thanks,
Ryan Trinkle

[Thomas Davie]

On 16 Jun 2009, at 08:45, Ryan Trinkle wrote:

I'm a co-founder of a game studio that will be writing in (primarily) Haskell.  We're currently assembling the technology stack for our first game, and I'm very interested in FRP (Reactive in particular) as a way of making video game programming easier and less error-prone.  However, from reading this list and discussing it with people in #haskell on irc.freenode.net, it seems that there may be issues blocking us from using it within our timeframe (we plan to release our first game around November).

What known issues would prevent Reactive from being used today in a commercial video game?  Would you anticipate the discovery of many critical issues in the future?  What would it take to overcome these issues?

At the moment there are a couple (maybe more) of issues with reactive that make it basically unusable for this kind of project:

1) The way that unambiguous choice works is still not settled, every time someone thinks they have it right, some other little sneaky git of a detail comes up and shows it to be incorrect.  There's been some progress recently on getting this right.

2) The snapshot, mappend and join functions on events currently block in inconvenient ways with certain inputs.  This doesn't sound like a major problem, until you discover it's the *useful* inputs that they block on.  This issue is just a matter of getting lazyness right, unfortunately, various people have tried to get the lazyness right over the past year or so, and no one has yet succeeded.  If you were to get it right, I would be extremely happy.

A final note:

From past conversations with conal, I believe he's in the process of migrating reactive to a different license because he wants to make sure that while it remains open he still gets paid for its use in industry.  You'll have to check this with conal though.

Bob

[Conal Elliott]

Thanks, Bob, for the summary.  Reactive has appeared to be tauntingly close to working for about a year now, and it's still unclear what it will take.  Debugging/diagnosing has been difficult, termination/laziness issues have been subtle, and in some cases unamb turned up ghc rts bugs.

And, yes, I'm exploring licensing alternatives.  None of the standard licenses capture what I want.  I switched to GPL-dual as an invitation to dialog and collaboratively explore possible arrangements.  I'm not attached to keeping it that way, as the coercive aspects of GPL leave a bad taste in my mouth.  I'm looking for a sustainable model for myself and others to create and fun & useful software and share it with each other.  Reactive is a handy test case for the exploration.

  - Conal

_______________________________________________
Reactive mailing list
Reac...@haskell.org
http://www.haskell.org/mailman/listinfo/reactive