[Haskell-cafe] [reactive] A pong and integrate

[Sam Martin]

I work in the games industry and I'm also not convinced of the Haskell+FRP path for games, but for different reasons. I am very fond of Haskell for games however, and think it is achievable. 

 

Regarding FRP, I don't think it is the right framework to base a game on. It's great for some stuff, particularly the kind of problem Peter demonstrated, but games are a lot more varied than that and efficiency concerns aside, it's just not the right approach for everything. I see it more as a useful tool for some elements than a framework that should form the backbone of a game.

 

Functional programming on the other hand is a big thing. Games look a lot more functional now days than they ever did before, and C++ doesn't have the right vocabulary to allow you to scratch this itch properly. EDSLs, parallelism, composability, higher order functions, and static typing are really where it's at, and Haskell excels at this. There's a lot of missed opportunities for more elegant and powerful architectures going by at the moment simple because it's not realistic to attempt them in C/C++. 

 

One area where Haskell is not so hot and needs a bit of TLC is it's 'embedability'. A large cross-platform 100% Haskell game is not on the cards at the moment, but Haskell could start getting its hands dirty, if only it could be sensibly embedded within an otherwise C++ app. This would allow people to start to take advantage of it, without some wholesale switch over. However, to do this, Haskell implementations at least need to be more compiler and platform agnostic, and we would probably need a lot more control over the Haskell runtime itself, particularly wrt memory handling. Lua (which is very popular in the games industry) and ATS (which isn't used to my knowledge, but has excellent interaction with C) are good examples of languages where this kind of thing is considerably easier. Haskell would have to fit in differently to this, but that's the kind of idea.

 

Interesting things to note are that in this scenario, you could probably ditch IO altogether and just embed 'pure' Haskell. Games have very limited IO which would likely be best handed in C++ anyway.

 

Laziness/space leaks, garbage collection and general performance concerns are obviously also issues, but that's for another day J

 

Cheers,

Sam

 

From: haskell-cafe-bounces at haskell.org [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Limestraël
Sent: 26 May 2010 08:52
To: Peter Verswyvelen
Cc: haskell-cafe at haskell.org; Patai Gergely
Subject: Re: [Haskell-cafe] [reactive] A pong and integrate

 

> The GHC bugs are now fixed, so it might be stable enough for
> another adventure like that, but I don't think I would bet on it
> again.

GHC bugs are corrected, but Reactive still have some. (See my previous posts)

> IMO Haskell is great for writing small clean prototypes, doing
> interesting research, and maybe making some fun little games, but I
> wouldn't use it for production reactive game coding, not yet at least.

Tim Sweeney (from Epic Games) has another perspective about that [1].
Besides, FRP is not mandatory. You can always make games in Haskell by using a more regular style (more "imperative", would some say).
For now, the main problem is the small number of Haskell libraries for games when compared to the huge numbers of those which exist in C++, which prevents, for now, Haskell to be used as the main language for big commercial games.
But for smaller scale games (like indie), which have less needs, I think it's worth it.


[1] http://www.scribd.com/doc/5687/The-Next-Mainstream-Programming-Language-A-Game-Developers-Perspective-by-Tim-Sweeney

2010/5/25 Peter Verswyvelen <bugfact at gmail.com>

Well, first of all, I did not make these PS3 visualization, my former
colleagues and I just made the editor, language and runtime that
allowed video game artists to do the job for us in a couple of weeks
time :-)

I wouldn't use Yampa, for performance reasons, and difficulty to get
it running on alien platforms (it is well known it performs relatively
badly, although the work done by Paul Liu and co on Causal Commutative
Arrows looks very promising, but does not support dynamic switching
yet). After all, Yampa models a synchronous dataflow language, and
compilers for these languages are relatively easy to make IMO.

My previous - now defunct -  company Anygma spent a lot of money on
trying to use Haskell and Reactive for game programming, which
unfortunately ended in some nasty GHC bugs popping up (see
http://www.haskell.org/haskellwiki/Unamb), and not all problems with
Reactive got fixed; it is amazing how difficult this all turned out to
be. The GHC bugs are now fixed, so it might be stable enough for
another adventure like that, but I don't think I would bet on it
again.

IMO Haskell is great for writing small clean prototypes, doing
interesting research, and maybe making some fun little games, but I
wouldn't use it for production reactive game coding, not yet at least.



On Tue, May 25, 2010 at 10:49 AM, Limestraël <limestrael at gmail.com> wrote:
> Wow... impressive...
>
> And now, with your experience, if you'd have to do this again, would you use
> Yampa or stick up with C#/C++ ?
>
> 2010/5/24 Peter Verswyvelen <bugfact at gmail.com>
>>
>> Yeah. Funny that we're still writing games in C++, while mission
>> critical and hard real time systems are written in much nicer
>> languages :)
>>
>> I made something similar to Lucid Synchrone for a game company I used
>> to work, but with the purpose of making reactive programming
>> accessible to computer artists. The integrated development environment
>> provided the typical boxes-and-links user interface, where the boxes
>> were signal functions. Signals itself were not exposed, like Yampa.
>> The system did type inference so artists never really had to deal with
>> types. Special nodes like feedback and delay where provided to allow
>> transferring values to the next frame. This actually was a great
>> success, digital artists could literally create little interactive
>> applications with it, without much  help from programmers. This
>> resulted in a Playstation 3 visual experience "Mesmerize"
>> (http://www.youtube.com/watch?v=rW7qGhBjwhY). This was before I knew
>> Haskell or functional programming, so it was hacked together in C# and
>> C++...
>>
>> I still believe that the reason why computers artists could work with
>> this environment and were not able to learn imperative programming is
>> functional programming itself: the system had all the goodies of FP:
>> type inference, referential transparancy, etc... But is also provided
>> the possibility to edit literals while the simulation was running,
>> providing zero turnaround times, which was equally important for quick
>> adoption of the software.
>>
>> So IMO Haskell and FRP systems have a huge potential for education of
>> a much broader audience than just computer scientists...
>>
>>
>>
>>
>>
>> On Mon, May 24, 2010 at 6:13 PM, Limestraël <limestrael at gmail.com> wrote:
>> > I assumed also that it was a field which was still under research,
>> > however,
>> > Lustre, again, is used "for critical control software in aircraft,
>> > helicopters, and nuclear power plants", according to wikipedia.
>
>

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100526/73601f69/attachment-0001.html