functional programming game engines

Started by
4 comments, last by JuNC 18 years, 9 months ago
Yes, it's another game engine thread, but perhaps this one has a twist. What special considerations are there, if any, for game engines/frameworks written in functional programming languages(Lisp, ML, Haskell, etc.)?
Advertisement
That idea hurts my brain! I did some work in Haskell at uni but can't help you. We did do a mail-server app in it so you can do such things - but why would you?
Theres quite a few examples around, but none well known, some searching through the OCaml mailing lists might turn up a few hits (e.g. a doom engine was written in OCaml) but there aren't too many stable projects. Clean has a nice game library for it, but I haven't tried it out (can't get my head around the IDE!). Haskell is likely quite hard to build a predictable engine in (no mutable state and lazy evalutation) but I've no doubt it's possible.

The main consideration I've found trying to build OCaml engines is finding people actually willing to help you :) You've also got to consider that since functional languages tend to favour immutable state, you've got a deep reaching design choice to make (at least in impure languages like Lisp or OCaml) - do you go for referential transparency throughout or admit that passing and copying the state is going to hurt performance too much (I don't take either side, depends on your design).

You're also going to need some way to interface with lower level libraries, the FFI of the language is going to influence this so you need to be familiar with it and the performance costs of transferring data across the boundary.

You'll also find that some of the error messages from certain compilers can be extremely cryptic so be prepared to spend some time deciphering them :)

Also, you may well need to use OS level threads so you might need to ensure the language supports them (e.g. OCaml doesn't, various other MLs or Haskell variants might). Whether you need (OS) threads or not is of course dependent on the engine.

The benefits of strong static typing, algebraic types, first class functions, a real module system and a fast garbage collector make me really really want to build an engine in OCaml (at least for 2D games), but right now I'm forced to use C++ since the rest of the team doesn't want to learn a new language at the moment (which is fair enough).
Fungen seems to be right up your alley. I haven't worked much with haskell or at all with fungen, but I remember coming across this link and thinking I should check it out.

Quote:Original post by JuNC
You'll also find that some of the error messages from certain compilers can be extremely cryptic so be prepared to spend some time deciphering them :)

I've noticed this.
Quote:The benefits of strong static typing, algebraic types, first class functions, a real module system and a fast garbage collector make me really really want to build an engine in OCaml (at least for 2D games), but right now I'm forced to use C++ since the rest of the team doesn't want to learn a new language at the moment (which is fair enough).

In that case, do you know of Felix, http://felix.sourceforge.net/ ?
It's similar to OCaml but produces C++ code. I have no idea if the resulting C++ will be readable enough since it's generated but I believe the goal is to allow seamless integration.
Yeah I've been subscribed to the Felix mailing list for about a year. It's a very interesting language, but doesn't appear as elegant as OCaml and solves a different set of problems (could be a very good starting point for a game engine though).

EDIT: interestingly enough theres a recent discussion on caml-list about large scale functional programming and this post: http://caml.inria.fr/pub/ml-archives/caml-list/2005/07/a78bdc8b2e96036e4cc2c473469b0245.en.html might be of relevance to this thread.

[Edited by - JuNC on July 19, 2005 10:47:12 AM]

This topic is closed to new replies.

Advertisement