Open soupi opened 9 years ago
For game programming it might also be worth mentioning Elise Huard's work. She gave a recent talk at eurucamp 2015 and has published the book Game programming in Haskell.
reflex-dom
was also mentioned by somebody else and I added that to the post.
I think it would probably be worth mentioning sdl2
and linking to Chucklefish's post. The other libraries seem a bit too experimental to mention at this point; I'd prefer to stick to things that are closer to complete.
Somebody else also mentioned helm
which I'm also checking out to see how complete it is.
@passy I just watched Elise Huard's talk and it seemed like it would be difficult for a non-Haskell-programmer to follow. There are too many new concepts, unexplained syntax, and lots of code dumps that are not walked through in sufficient detail. I've seen clearer talks using Elm as the teaching language for game programming.
I also checked out the Game programming book in Haskell and it's not freely available (and also is incomplete from what I've heard from people who have bought the book).
@Gabriel439 sure. though I would keep an eye on Luminance and LambdaCube3d, especially LambdaCube3d. It has been developed for a few years and recently has been developed full time. There is already an online editor and plans 1 2 for making it stable.
@Gabriel439 That's fair enough. :)
@soupi I was really impressed by the online editor. How different is the LambdaCube3D DSL from Haskell? The syntax seems remarkably similar to Haskell so it seems like it would be easy for a Haskell programmer to pick up
@Gabriel439 I have to say that I don't have experience with it, but on the site there is a short language specification page stating that "LambdaCube 3D is specified as Haskell98 plus various language extensions.". There is also information on this FAQ page about why they chose to develop a compiler instead of writing an EDSL.
Also, from this slide it looks like the idea is to be able to write the game logic in Haskell (or a different language), write the graphics code in LambdaCube3D and then combine those into an application. So even if it is a somewhat different language, it is still very relevant for Haskellers.
So I decided not to add LambdaCube3D for now mainly because it's not complete yet (and I want to stick to things that are ready for use), but I will keep this issue open to keep track of LambdaCube's progress and add it when it's ready
@Gabriel439 fair enough. thanks!
It might be a good idea to add gpipe to the game programming list to increase discoverability. It also has a tutorial series and an interesting example.
Alright, I overhauled the game programming section a bit. The main changes were:
gloss
GPipe
helm
(since it seems abandoned)@Gabriel439 Your comments about Elise's talk is interesting - it reminds me that it's very unclear what the purpose of this document is. Is it only for complete beginners, or is it state of the union? Elise's talk and book are not for Haskell beginners.
Also, by the way, not too sure why you say Keera studios has become inactive. Their twitter was posted to a month ago.
The document is supposed to be opinionated, but not necessarily for beginners
@Gabriel439 That's what I'd thought... however, Elise's talk is good for intermediate Haskeller's wanting to do Game stuff, isn't it? My experience was that it was high quality. I guess this is up to your opinion ;-) (which is the point).
Perhaps it needs to be clearer that this document is primarily your opinion. As it stands, it reads a little like it has no bias and is simply an objective community agreed-upon set of "all the things". :)
Out of curiosity, on what data is the list of what sort of games are easy and which are hard in Haskell based? The list of genres that are supposedly difficult or easy appears to be slightly peculiar (primarily that RTS is judged as hard while FPS as easy).
Further is there any evidence to Haskell's GC being a problem? Considering that the very popular Unity Game Engine has the complete game specific code written in C# (and that GHC's GC is atleast as good as C#'s) I'd intuitively disagree with the GC necessarily being bothersome. (Note that Unity does basically use FFI to handle the builtin drawing and physics code in C++)
Areas of improvement that I do see is that most of the general wisdom of game devs is about solving things via highly stateful (and infact a good amount of global state), highly imperative and mutablity using solutions - while this is also possible in Haskell, it is, of course, not exactly idiomatic.
On a closing note I'm currently working on an online card game for eventual commercial release in Haskell and am making good progress via simple DSLs.
Some of those I do have data on and others I don't and just made an educated guess. The ones I know for sure are:
The other games I don't have data on but for some I could easily extrapolate:
For RTS and MMORPG I have no data. The main reason that I judged them difficult is due to the fact that they'll usually have a large number of objects that need to be updated so I was concerned about how Haskell heap sizes might grow for these types of games.
Graphics was the least of my concerns because Haskell actually has pretty good 3D graphics performance and wherever it falls down you can outsource to a high performance engine written in C++ or Rust, like you said.
I've written a blog post which links to a talk about a game I made in Haskell (Nyx), a blog post by Joe Vargas about a game he made (Dino Rush) and a get started guide to sdl2 + snake example. Might be nice to have some of the links in this document!
@soupi: I added a mention of it here: https://github.com/Gabriel439/post-rfc/commit/81495209e68a94c83f9835c075c16542cc25dc86
Thanks!
@soupi: You're welcome! 🙂
Did you look at Haskell Sprite Kit
?
Its implementation is unique and made by a Haskell senior (Manuel Chakravarty).
@lulucca12: No, I haven't had a chance to look at that, yet
It is the most complete Haskell game bindings I've ever seen, the only problem is that it only works in macOS, as it is based in Sprite Kit.
Hi! first, I wanted to say thanks for making this document!
I would like to share a few points about Game and GUI programming in Haskell:
Regarding GUI programming in Haskell: One front that seems to be actively developed is reflex-dom which targets both ghcjs and ghc. when targeting ghc it uses webkitgtk3, so hopefully we'll be able to build nice desktop GUI application in Haskell soon :)
Regarding Game development in Haskell, there are also a few fronts:
Also, I definitely felt as I had a success story with Haskell in my B.sc. final project. Building an interpreter for a purely functional, implicitly parallel language was a breeze because of the book Parallel and Concurrent Programming in Haskell that you mentioned, the threadscope tool for analyzing parallel programs and the parallel library. This is almost all the code I needed! I would also add Write Yourself a Scheme In 48 Hours as a good, beginner friendly, project based tutorial on the subject.
Thanks again! Gil