6 ms·

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

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.

prospero 16y ago
What libraries did you use?
- mkilling 16y ago
  just Penumbra
  - prospero 16y ago
    Can you expand on why using Penumbra wasn't fun? If I can, I'd like to fix that.
    - bhickey 16y ago
      Could you document the pixel shader DSL?
      - prospero 16y ago
        Yes, I will. I've been holding off until I got the type inference to be less hacky, but that's not really necessary for it to be useful.
    - mkilling 16y ago
      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?
      - swannodette 16y ago
        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.
        mkilling 16y ago
        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.
      - prospero 16y ago
        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.
angrycoder 16y ago
http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html 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/ http://landoflisp.com/
- jcw 16y ago
  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?
  - zach 16y ago
    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.
    - swannodette 16y ago
      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.
      - 16y ago
swannodette 16y ago
prospero's work: https://github.com/ztellman/penumbra/tree/master/test/example/game/ 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! :)
- mkilling 16y ago
  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.
  - eru 16y ago
    Functional reactive programming may be better suited.
ShardPhoenix 16y ago
I've written a game in Clojure (http://github.com/ShardPhoenix/SAGame 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 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.

prospero 16y ago

What libraries did you use?

mkilling 16y ago
just Penumbra
- prospero 16y ago
  Can you expand on why using Penumbra wasn't fun? If I can, I'd like to fix that.
  - bhickey 16y ago
    Could you document the pixel shader DSL?
    - prospero 16y ago
      Yes, I will. I've been holding off until I got the type inference to be less hacky, but that's not really necessary for it to be useful.
  - mkilling 16y ago
    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?
    - swannodette 16y ago
      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.
      - mkilling 16y ago
        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.
    - prospero 16y ago
      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.

angrycoder 16y ago

http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html 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/ http://landoflisp.com/

jcw 16y ago
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?
- zach 16y ago
  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.
  - swannodette 16y ago
    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.
    - 16y ago

swannodette 16y ago

prospero's work: https://github.com/ztellman/penumbra/tree/master/test/example/game/ 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! :)

mkilling 16y ago
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.
- eru 16y ago
  Functional reactive programming may be better suited.

ShardPhoenix 16y ago

I've written a game in Clojure (http://github.com/ShardPhoenix/SAGame 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 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.