There are more advertisements (2) than articles and games (0 and 0, respectively) on the site.
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.
Regarding monetization, I have no intentions of making any money off this site - ever. The advertisements were there because wikidot adds them to free accounts. They should be gone though, since I paid for a "no adverts" account.
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.
There should not be any advertisements.. nor do I see any. If you can check again in a few hours and let me know if you see any? I will complain to wikidot if you see advertisements, since I specifically paid for the "no adverts" option.
I'm looking forward to see some actual games on there.
Last time I tried game dev in Clojure it wasn't fun at all. I'm curious to see if it was me or if Clojure/functional languages in general just aren't well-suited for games.
I've written a game in Clojure (http://github.com/ShardPhoenix/SAGame) and it wasn't that hard, despite it being my first serious Clojure (or Lisp in general) project (also note that this means that the code isn't ideally concise or idiomatic). The main datastructure is all immutable. It wasn't always immediately obvious how to update everything but by using a tree of update functions that mirrored the data itself, it wasn't a big problem. I probably should have used a mutable set for sounds though, and perhaps things might have been trickier if I'd had more complex interactions.
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.
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:
I like that talk. I saved the video a while ago and have watched it several times. His disambiguation of identity, state and value makes a lot of sense.
As a game developer, the treatment of perception vs. presumed authority about the state of a system resonated with me. Trying to infer a state of a system, given observations that are already in the past, is something networked game developers are especially familiar with.
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.
But the use of an existing game engine or other substantial middleware might impose certain idioms on you. I worked on an MMO myself, though not on game logic. Anyway, I agree that Clojure's strengths being used in gamedev is an exciting prospect!
Very true, and ultimately why I think Clojure is a lot more ripe for nontraditional markets than expecting it to break into mainstream game development. There may be quirky and clever developers who put Clojure into mainstream game technology, but I think new platforms are where it can achieve the greatest leverage.
Speaking of that, my interest in big movie-wannabe games is dwindling rapidly, both as a player and career. Simple focused games and playthings are what I find myself admiring.
I've tried to write games in a pure FP style in Scheme, and, like Hague, found that the difficulty is in keeping track of state in a sane and efficient way.
I suspect that Haskell's monads are a solution. Can someone with Haskell experience attest to this?
My favorite style, which I think maps well to functional use, is to have the entirety of game state (including random number seeds, etc.) be in one "world" data structure, call it W. Then, you collect all your input (say, controller axis values) into another structure, I.
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.
FWIW, this is exactly the model that Penumbra adopts. I'm curious to see how this scales with more complex games. I think there's a lot of awesome research / experimentation /documentation to be done here.
I guess it wouldn't be much more code in C.
Functional programming is a great tool to have in your programming language (that's why I really enjoy writing Python, Lua or C#), but from my point of view it's just not practical as the main paradigm for a game dev language.
Penumbra itself was awesome (your examples are proof for that), it's just that I didn't really enjoy writing the game logic itself. My approach was basically manipulating huge hashmaps each frame. When I started out that was really manageable but I ended up with one monolithic hashmap for my game state (storing other huge hashmaps for the game objects) that was just not fun to work with anymore.
I'm by no means an experienced Clojure programmer, so maybe I did miss something. Maybe I'm also too deeply rooted in object-oriented programming to fully embrace FP for architecting a game - my high-level architecture was very similar to what I would have created in an object-oriented language (methods, polymorphy, ...).
Anyways (as I said in a comment above) I really enjoy having functional tools at hand, but at least for game dev my favorite paradigm is still OOP.
Maybe you can give me any pointers about writing more advanced games in Clojure?
Well, for some definition of 'advanced' you can look at the Asteroids example. It has multiple lists of entities in the big game state hash, and has functions which pull them out and operate on them. The full hash is only used in a single, small function.
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.
It would be useful to either have your code up somewhere or to write up a blog post about your experiences and frustrations. Otherwise two missed opportunities here: a) Getting feedback from more experience Clojure developers b) documentation on pain points so the paradigm can be improved / altered to better suit real world use.
You're right, but there's not much to show really. Should I ever pick it up again I'll put my code on github for sure.
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.
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.