functional programming languages

Started by
9 comments, last by Telastyn 12 years, 10 months ago
Hey,

I am wondering: Do 'modern' functional programming languages like F# or Scala play a role in game development or do you think they will do so in the future?

Currently, almost all major stuff seems to be coded in C++ (I'm talking about games with an own client/no browser stuff)...so I am wondering if those languages have a chance in game development.
Advertisement
I've seen haskell used in some recently developed muds. Not sure were there any reasons beside "I always wanted to do that" to support it though.
I don't want to start a language war, but even though I really do like functional programming it is hard to make it work in any application that needs to push around big blobs of semi-structured binary data (such as games, numerical code, or general graphics/physics/image processing types of stuff). The reason it ends up being so difficult is that you end up implicitly needing to make lots of copies of your data to get stuff to work without side effects. When the things that you are copying are small and don't persist for long, then this is no big deal. However with big vectors and matrices this is definitely not true, and it becomes a very expensive proposition.

Even if you are careful and use things like monads to abstract some of this away, it is still very easy to make a mistake and accidentally put a giant memcpy right in the middle of your main loop (and some languages will do this silently, even different behaviors depending on what compiler options you use!) Some languages (like Erlang) try to get around this by replacing random access arrays with binary trees. This has the advantage that local updates can be made without doing a complete copy, but the disadvantage is that random accesses are much slower, and the data structures tend to exhibit poor locality/cache performance and are typically several orders of magnitude slower.


This is really a shame, since I like the idea of using functional programming for things like organizing game logic and entity behavior, and I think that functional code is usually more elegant and readable than imperative code. However, the awkwardness of using FP for graphics is just too big a downside to make it practical. One way I could see it working out is if you use a functional backend for say a server (such as in a MMO-browser based game). In this situation, the game logic could be sufficiently abstracted away from your display that it might be feasible to use something like Erlang or Haskell. Of course if it turns out that later on you do need to do physics on the server-side, then you will probably end up getting screwed.
I've made a couple of attempts at understanding functional programming and I have to say, my brain just doesn't work that way. On the other hand, I am trying to get a machine to do something, and the machine doesn't work that way either. If both the machine and I think imperatively, I am not willing to spend much time trying to communicate with it using some other paradigm.

There are a few examples of successful applications of declarative languages (SQL is in my opinion the most clear example), so perhaps they have some role to play in game programming, but I am not going to try particularly hard to find it.
Functional languages are well suited to certain types of problems, in perticular ones where you can almost 'stream' data from one site to another with some processing in the middle. This does technically make them very good for tools work where you are effectively going [data in] ---> [process] --> [data out].

In fact they map well to any structure like; SPU processing is very functional in nature for example, as are things like compute shaders (at least for certain classes of problems as you can technically mutate non-local scope depending on where you write data).

Any processing which is double buffered is also functional in nature as it matches the processing loop shown above.

Functional does have some problems in a game enviroment, but even then for many things people are turning to functional style programming in order to make code which is easy to scale to multiple threads and multiple tasks as the style of programming is inherently safer for that model of execution.

So, I would argue that functional programming is, maybe not in the purest of senses, alive and well in the games industry already and exploiting that method can lead to higher performance code.

The langagues themselves however are not so widely adopted, although I do recall Scheme being used as a scripting language for a game. The languages mentioned in the OP suffer by being overshadowed by their well known siblings (C# and Java) and in the case of F# C# is picking up many functional aspects as well.
I really love functional programming for gameplay/AI code. Stuff that's mostly about branching, less about computation.

I've been experimenting with scripting games in Javascript using Google V8. It gives me a "component-based entity system" for free with closures and duck-typing, and then I use a functional style within and between components. So far it's pretty awesome.

We'll see how performance goes, but so far it's been fine, I can easily and seamlessly rewrite CPU-heavy components in C++. Right now that's just physics, rendering, and pathfinding.

Pure functional may not be the best fit for games, but incorporating functional elements is great for code that's not data-driven. Beats the hell out of OO, that's for sure.
Anthony Umfer

Hey,

I am wondering: Do 'modern' functional programming languages like F# or Scala play a role in game development


I remember some rumor back in the day that a fairly well known game was done in Lisp. Not exactly modern, and google indicates that Crash Bandicoot might've been what I was thinking of. Otherwise no. Though I wouldn't consider Scala to be a functional programming language.


or do you think they will do so in the future?
[/quote]

I think it's more likely to do so in the future due to 3 trends:

.NET becomes a more viable platform

I toyed around with using F# in my mostly C# game for map generation. I could see something like AI being done there as well. Having that interoperability is a real benefit so that you can have the parts of your game that make sense in a functional language, while leaving all the parts that don't out.

Android expands

There's many reasons that games are stuck in C++ mostly. Support on platforms just doesn't exist for other things, functional languages included. As android becomes more prevalent and varied, the barrier to entry is lowered so there will be more developers with more diverse backgrounds. Someone is bound to be a functional programming nutjob.

MMOs need to support tons of concurrent players

As phantom mentions, scalability is a big win with many functional approaches. It's not part of the actual game, but the caching server/db for Farmville was written (mostly?) in Erlang. As the performance demands increase for MMOs, those benefits become more and more inviting.


All of that said, I have to agree with robotichrist and alvaro. While it's likely that we'll see more functional programming for games (and not games) in the future, I can't imagine a world where they've risen to even a trivial part of overall software development. The majority of developers can't even use the 'easy' languages...
What always irritated me about Haskell is that it compiles to C code, so all of the assignments that were an unholy bitch to write in Haskell, where I couldn't print any debug information, would have been easier, and equivalent, to write in a reasonable language, even C99.

.NET becomes a more viable platform

I toyed around with using F# in my mostly C# game for map generation. I could see something like AI being done there as well. Having that interoperability is a real benefit so that you can have the parts of your game that make sense in a functional language, while leaving all the parts that don't out.



Since I wanna create my own roguelike, I have the same idea: Use F# for complex algorithm stuff, like map generation. I'd be interested in your experience concerning map generation...did you have the expression it's worth doing it in F# ...compared to C#?

Apart from this, I think since .NET gives you the freedom of choice, perhaps the following separation might be senseful, would do you think?

  • C#: for UI-related stuff and to define interfaces and the overall framework (decoupling of components)
  • F#: for solving complex algorithms, like procedural content generation, AI and game logic in general
  • IronPython: For customizing (beyond XML) and defining of content, perhaps also the create actors (but the core of the AI would be in F#)

[quote name='hawkeye_de' timestamp='1306346742' post='4815694']
Hey,

I am wondering: Do 'modern' functional programming languages like F# or Scala play a role in game development


I remember some rumor back in the day that a fairly well known game was done in Lisp. Not exactly modern, and google indicates that Crash Bandicoot might've been what I was thinking of. Otherwise no. Though I wouldn't consider Scala to be a functional programming language.
[/quote]

Naughty Dog, the initial developer for the Crash Bandicoot and Jak and Daxter franchises, has historically been a proponent of Lisp, and often uses proprietary in-house dialects of it in their games.

Their Crash Bandicoot games have lisp code driving their AI and gameplay routines, while the Jak and Daxter games are almost entirely programmed in it (specifically, their modified Game-Oriented Assembly Lisp dialect).

Note however that they ultimately switched to C++ with the shift to the PS3.

This topic is closed to new replies.

Advertisement