Clojure game development wiki
clojure-games.org
clojure-games.org
I hope HN helps out and adds to the page, but I think the creator should worry about having some content first, any at all, before they worry about things like monetization. Otherwise it just feels skeezy.
As for games and articles, I am working on it and hopefully others will contribute the odd bit of code or link too. In the meantime, I have linked whatever clojure game dev related libraries, articles and blog posts I could find on google, so at least the wiki can act as a place to collect them all in one place - until I get more content, at least.
The reason I put it on HN at all with so little content is exactly because I'm not doing this for money - I'm doing it because I would like to promote clojure, game development and, most importantly, game development in clojure and have received a few emails about the site over the past few weeks. This proved to me that there is interest in such a thing, now I'd like to see if theres enough interest for people to contribute, since it would take me a long time if I'm the only one creating content.
tl;dr: The site is for the community, so I wanted to get the community involved as early as possible. Apologies for the adverts, they should be gone now.
It even supports LaTeX-style math
Yeah, it does, I saw it mentioned in the markup docs. Its pretty nice.
As those old Head & Shoulders commercials so wisely profess - you never get a second chance to make a first impression.
Would you say that FP has should be altered to better suit game development? I for my part am pretty happy with the functional features that made it into mainstream languages so far.
But honestly, I think the Asteroids example may still be the most complex real-time game written in Clojure so far. I think the approach described above should scale pretty well, but that's an unproven theory. Hopefully this site will encourage people to find out.
I think trying make traditional computer games in functional languages is using the wrong tool for the job, the author reached the same conclusion.
Thats not to say that games aren't possible, they just need to be different kinds of games that are grown from the strengths of functional languages.
There's also: http://landoflisp.com/
I suspect that Haskell's monads are a solution. Can someone with Haskell experience attest to this?
So each simulation step takes you from W + I => W' which you hand off to the pre-renderer and the next simulation step. The pre-renderer will combine the game world state with static data (i.e. models and shaders) and produce game-state-free data that a renderer can display to the user.
This is the basic framework I've used for twelve years when I've been able to implement it (i.e. not often at my day job). It's worked really well, but I actually have not applied it in a language that supports purely functional programming. So you can guess why I'm in this thread.
1. The author has had second thoughts about his original conclusions: http://prog21.dadgum.com/37.html
2. The author is constrained by the Erlang feature set. The author rejects out of hand the idea of using "structs", but Clojure's maps and records are easy to use, share data and would perform admirably.
3. The author is constrained by his retrogame and microsystem domain. No modern gaming platform has issues with game state using too much memory or generating too much garbage (exception: complex physics). In fact, data duplication is now a common game performance technique. But if your tastes run toward ultralean programming, this is a distasteful state of affairs.
4. Much of modern game development has moved to an increasingly functional dataflow model already because of the necessities of multiprocessing and network gaming. It's rarely elegant and never done in a functional language, but it's the current reality.
5. Games are one of the places where a sophisticated view of time, as Rich Hickey advocates in his fantastic JVM Languages Summit keynote, offers a lot of value. It's a problem that thoughtful programmers and designers in the game industry have often considered, but have been unable to innovate much in the current technological regime. I just rewatched the talk last week, in fact, and highly recommend it for game programmers who read Hacker News:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
Actually, Clojure would be a great host for a library that makes deriving a valid and consistent state from multiple observations in the past, something every networked game needs to do, more regular and predictable. That's often one of those "scary" parts of a game's code base. Things get pretty hairy, there is a lot of ad-hoc code, bugs are hard to track down and nobody wants to mess with it so it tends to get even cruftier and scarier.
https://github.com/ztellman/penumbra/tree/master/test/exampl...
Pong in 140 < LOC, Tetris in < 260 LOC, Asteroids in < 400 LOC
Looks like plenty o' fun to me! :)
I also converted the project to Java for Android (http://github.com/ShardPhoenix/Minotaur), retaining mostly the same structure. Apart from being about 3x more verbose, it was interesting in that mutability made some parts easier to implement, but also led to bugs that I'd never had in the original.