5 ms·

Making an RPG in Clojure (2010)

191 points by arm 10y ago

Morgawr 10y ago
Reading this article is like reading something I might have written myself. I, too, just like the author, have been toying around the idea of Clojure games for a long time. I've made small games (Ludum Dare entries mostly) and started (and subsequently killed) a lot of Clojure game engine projects. I tried the threading approach using agents (which later evolved into agents inside atoms or was it atoms inside agents? It's been a long time) and came to the same conclusion as the author. I tried to move to a more centralized CES approach, which didn't work out. It's interesting to see how some people can come down to the same path and achieve the same results (for the good or for the bad). I think my experience with Clojure has been overall positive as far as game development goes, although definitely not empty of woes. Currently what I'm (very on and off) working on is a Visual Novel/Interactive storytelling engine on ClojureScript, at http://novelette.moe http://novelette.moe and Clojure is great for it. Feel free to trawl through my github profile (link in my profile) if you're curious about some of my (failed? abandoned?) Clojure gamedev projects (among other things).
- priyankt 10y ago
  Nice work with - http://morg.systems/ld31/ http://morg.systems/ld31/ Not a lot of graphics & interaction, but the story telling was good. I finished the game :-)
- vanderZwan 10y ago
  Nice, for some reason I have a soft spot for interactive fiction engines! How does it compare to Twine?
  - Morgawr 10y ago
    I had never heard of Twine before, I just had a quick superficial look at it and wow it looks really nice! To be honest I don't know how it compares, my engine is closer to something like Ren'Py but I plan to provide more freedom to the writers thanks to the power of functional programming and the DSL-like implementation of Lisp. I haven't formalized on a proper syntax for the scripts yet (although a rough example can be seen on my demo game: https://github.com/Morgawr/ld31/blob/master/src/cljs/game/script.cljs https://github.com/Morgawr/ld31/blob/master/src/cljs/game/sc... ), but the idea is to have something like the script of an actual novel. The author can define acts and chapters and have actors enter the scene, interact, define the state of the scene (add/remove sprites, backgrounds, music) and define the transitions from chapter to chapter within the novel.
PaulHoule 10y ago
The article also shows up that there is snake oil in the actors, stm and many other concepts to make concurrency easy and fun. Often you fall back on doing it all in 1 thread because you get better performance that way but then what is the poll of multicore? Lmax disruptor is different from the others because it is based on engineering (what works on actual hardware) opposed to 'science' (how you imagine it ought to work)
- meric 10y ago
  >> poll of multicore Intended pun involving threads?
  - dr_zoidberg 10y ago
    I'd guess the keyboard (from a mobile device?) got "poll" instead of "pool". Or maybe a little typo from the use of writing one and not the other. On the subject of pools of threads, a few days ago there was a post about the Naughty Dog Engine using fibers (inside threads) for cooperative multiprocessing. They made it so it'd have a cleaner API and be easier to use, but at the end of the talk they said it had also improved performance (because of less context switches). Also having very little knowledge in games programming (a few experiments in QBasic 4.5 something like 20 years ago, when I was still a child :D ), the most I can get out of this is: multithreading/multiprocessing in games is hard.
- vvanders 10y ago
  I remember seeing games doing actor-like things with message passing on a single thread way back in '02. You could "broadcast" a "damage" message and all the actors that were in the hit region would handle it in however they saw fit. Great way to force decoupling. Concurrency is somewhat orthogonal(although a nice-to-have), it's more about not doing things that run counter to your hardware. Over in the games space we don't have the advantage of scaling wide on multiple machines so a couple things that sound heretical are there for good reason.
  - Morgawr 10y ago
andrewclunn 10y ago
Article is from 2010. Was there ever a follow up?
- dr_zoidberg 10y ago
  That seems to be his last post on gaming/games: http://briancarper.net/tag/66.html http://briancarper.net/tag/66.html
- arm 10y ago
  Unfortunately not, it seems like many factors in his life led to him burning out. He does have a new blog¹ now though. ―――――― ¹ — http://carper.ca/ http://carper.ca/
davexunit 10y ago
For those that are interested in what the current state of Lisp game development is, check out the latest installment of the Lisp Game Jam. The jam page includes lots of information about game development tools for many different Lisps, and the submissions include games written in Common Lisp, Scheme, Clojure, and Emacs Lisp. https://itch.io/jam/spring-2016-lisp-game-jam https://itch.io/jam/spring-2016-lisp-game-jam
alexkehayias 10y ago
I've been working on a project to create 2D sprite based game engine in ClojureScript. My goal was to represent the game completely with data and let the engine figure out how to interpret and render it (declaratively). In the end I implemented an entity component system (as other comments have suggested) and used existing javascript rendering libraries to handle rendering (not writing a wrapper for webgl...). You can check it out here: https://github.com/alexkehayias/chocolatier https://github.com/alexkehayias/chocolatier It's been a ton of fun bringing a functional approach to games using Clojure and I gave a talk about it at ClojureWest this year. https://www.youtube.com/watch?v=TW1ie0pIO_E https://www.youtube.com/watch?v=TW1ie0pIO_E hope this helps others looking to build games!
sdegutis 10y ago
This is great. I've also tried my hand at making video games in Clojure. For me though, it was a weak attempt at a simple Bomberman clone that would be playable over the network, so that my kids could play it across our different family computers. It was even kid friendly, being about planting timed water balloons, and avoiding getting wet! It seemed like Clojure would be ideal for this, because the JVM has excellent networking libs and GUI libs for simple 2d graphics. But I severely underestimated how much time it would take though, so it never really even got to a playable single player state. The main part I got stuck on was trying to settle on a data format, how to represent tiles and players and items and everything, in a form of immutable data that was easy to both analyze and transform. The author's idea of mapping a giant 2d string to actual data is genius, although I suspect it wouldn't scale well for an RPG, and for my game it wouldn't have been very helpful since the terrain would be auto-generated (since needing to be somewhat randomized). It's surprising to see the author here mention using Agents as the original primary building block of the game engine. I've never directly used Agents or found them helpful. To this day I really don't know what they're good for.
sbov 10y ago
> due to multiple threads trying to edit the world ref 50+ times per second. Of course you get no benefit if you serialize the game through a single ref. Just because you have a fancy feature like agents doesn't mean you don't have to think about how your concurrent code is behaving. I chose Clojure for the server side code of my MUD. It wasn't for the agents or STM, it was for immutability. Immutability gives me the ability to easily have a consistent snapshot of the world which I can use to perform some operation, such as saving, event propagation, or some AI calculations.
- corecoder 10y ago
  Which MUD?
- lgas 10y ago
  If you don't serialize the game through a single ref (or the equivalent) how do you get the consistent snapshot of the world to perform an operation on?
  - glhaynes 10y ago
    Event loops are heavily used — basically process input, process physics, process NPCs, render, repeat. (Likely not in that order — I'm not much of a game developer.) This is what the author lands on in the "Success" section. Speaking of event loops, I feel like they weren't discussed very much at all at my school, despite being at the core of not just most game engines, but most GUIs. I think if I'd embarked on writing a GUI system when I was fresh out of school, I'd probably have done it in a massively threaded way like the developer in the article started their game. An event loop would have somehow seemed too … primitive.
  - sbov 10y ago
    Architecture can heavily affect how serial your process is. By randomly throwing agents at a single ref you can easily turn parts of the process that can be done in parallel into a serial process. Beyond that, throwing massive concurrency at an inherently serial process tends to give you worse performance vs just recognizing that it's a serial process and not trying to throw concurrency at the problem. This isn't just about fancy concurrency primitives like agents or STM, I've seen plenty of hobby games that ran terribly because they threw concurrency at the problem without analyzing it first, but ended up completely serial because of critical sections in the form of Java synchronization blocks. As an example of concurrency that you would probably have in every single player game: game logic feeds into render logic, but render logic shouldn't be changing the state of the world. So you can be performing the game logic of game loop #N+1 while the render logic of game loop #N is running. Also, usually, when saving the state of the game all you need is a consistent snapshot at the time. Immutability makes both of these easy. The rest depends upon the features and design of your game though. If you aren't going to actually try to analyze where you can benefit from concurrency, you're better off not just randomly throwing concurrency at the problem.
xiaoma 10y ago
This reminds me of Realm of Racket.
Elrac 10y ago
I love that the author takes us on a tour of all his blunders, so we can learn from them the way he did. Far too many "making of" articles present you with a finely polished end product and pretend that its evolution was child's play. That leaves us readers disheartened and reluctant to try similar things.
resatori 10y ago
A few years ago I created a fully small RPG game in clojure: https://github.com/damn/cdq https://github.com/damn/cdq Including procedurally generated maps, items and 3 small levels.

191 points by arm 10y ago

Reading this article is like reading something I might have written myself. I, too, just like the author, have been toying around the idea of Clojure games for a long time. I've made small games (Ludum Dare entries mostly) and started (and subsequently killed) a lot of Clojure game engine projects. I tried the threading approach using agents (which later evolved into agents inside atoms or was it atoms inside agents? It's been a long time) and came to the same conclusion as the author. I tried to move to a more centralized CES approach, which didn't work out. It's interesting to see how some people can come down to the same path and achieve the same results (for the good or for the bad). I think my experience with Clojure has been overall positive as far as game development goes, although definitely not empty of woes. Currently what I'm (very on and off) working on is a Visual Novel/Interactive storytelling engine on ClojureScript, at http://novelette.moe http://novelette.moe and Clojure is great for it. Feel free to trawl through my github profile (link in my profile) if you're curious about some of my (failed? abandoned?) Clojure gamedev projects (among other things).

priyankt 10y ago
Nice work with - http://morg.systems/ld31/ http://morg.systems/ld31/ Not a lot of graphics & interaction, but the story telling was good. I finished the game :-)
vanderZwan 10y ago
Nice, for some reason I have a soft spot for interactive fiction engines! How does it compare to Twine?
- Morgawr 10y ago
  I had never heard of Twine before, I just had a quick superficial look at it and wow it looks really nice! To be honest I don't know how it compares, my engine is closer to something like Ren'Py but I plan to provide more freedom to the writers thanks to the power of functional programming and the DSL-like implementation of Lisp. I haven't formalized on a proper syntax for the scripts yet (although a rough example can be seen on my demo game: https://github.com/Morgawr/ld31/blob/master/src/cljs/game/script.cljs https://github.com/Morgawr/ld31/blob/master/src/cljs/game/sc... ), but the idea is to have something like the script of an actual novel. The author can define acts and chapters and have actors enter the scene, interact, define the state of the scene (add/remove sprites, backgrounds, music) and define the transitions from chapter to chapter within the novel.

PaulHoule 10y ago

The article also shows up that there is snake oil in the actors, stm and many other concepts to make concurrency easy and fun. Often you fall back on doing it all in 1 thread because you get better performance that way but then what is the poll of multicore? Lmax disruptor is different from the others because it is based on engineering (what works on actual hardware) opposed to 'science' (how you imagine it ought to work)

meric 10y ago
>> poll of multicore Intended pun involving threads?
- dr_zoidberg 10y ago
  I'd guess the keyboard (from a mobile device?) got "poll" instead of "pool". Or maybe a little typo from the use of writing one and not the other. On the subject of pools of threads, a few days ago there was a post about the Naughty Dog Engine using fibers (inside threads) for cooperative multiprocessing. They made it so it'd have a cleaner API and be easier to use, but at the end of the talk they said it had also improved performance (because of less context switches). Also having very little knowledge in games programming (a few experiments in QBasic 4.5 something like 20 years ago, when I was still a child :D ), the most I can get out of this is: multithreading/multiprocessing in games is hard.
vvanders 10y ago
I remember seeing games doing actor-like things with message passing on a single thread way back in '02. You could "broadcast" a "damage" message and all the actors that were in the hit region would handle it in however they saw fit. Great way to force decoupling. Concurrency is somewhat orthogonal(although a nice-to-have), it's more about not doing things that run counter to your hardware. Over in the games space we don't have the advantage of scaling wide on multiple machines so a couple things that sound heretical are there for good reason.
- Morgawr 10y ago

andrewclunn 10y ago

Article is from 2010. Was there ever a follow up?

dr_zoidberg 10y ago
That seems to be his last post on gaming/games: http://briancarper.net/tag/66.html http://briancarper.net/tag/66.html
arm 10y ago
Unfortunately not, it seems like many factors in his life led to him burning out. He does have a new blog¹ now though. ―――――― ¹ — http://carper.ca/ http://carper.ca/

davexunit 10y ago

For those that are interested in what the current state of Lisp game development is, check out the latest installment of the Lisp Game Jam. The jam page includes lots of information about game development tools for many different Lisps, and the submissions include games written in Common Lisp, Scheme, Clojure, and Emacs Lisp. https://itch.io/jam/spring-2016-lisp-game-jam https://itch.io/jam/spring-2016-lisp-game-jam

alexkehayias 10y ago

I've been working on a project to create 2D sprite based game engine in ClojureScript. My goal was to represent the game completely with data and let the engine figure out how to interpret and render it (declaratively). In the end I implemented an entity component system (as other comments have suggested) and used existing javascript rendering libraries to handle rendering (not writing a wrapper for webgl...). You can check it out here: https://github.com/alexkehayias/chocolatier https://github.com/alexkehayias/chocolatier It's been a ton of fun bringing a functional approach to games using Clojure and I gave a talk about it at ClojureWest this year. https://www.youtube.com/watch?v=TW1ie0pIO_E https://www.youtube.com/watch?v=TW1ie0pIO_E hope this helps others looking to build games!

sdegutis 10y ago

This is great. I've also tried my hand at making video games in Clojure. For me though, it was a weak attempt at a simple Bomberman clone that would be playable over the network, so that my kids could play it across our different family computers. It was even kid friendly, being about planting timed water balloons, and avoiding getting wet! It seemed like Clojure would be ideal for this, because the JVM has excellent networking libs and GUI libs for simple 2d graphics. But I severely underestimated how much time it would take though, so it never really even got to a playable single player state. The main part I got stuck on was trying to settle on a data format, how to represent tiles and players and items and everything, in a form of immutable data that was easy to both analyze and transform. The author's idea of mapping a giant 2d string to actual data is genius, although I suspect it wouldn't scale well for an RPG, and for my game it wouldn't have been very helpful since the terrain would be auto-generated (since needing to be somewhat randomized). It's surprising to see the author here mention using Agents as the original primary building block of the game engine. I've never directly used Agents or found them helpful. To this day I really don't know what they're good for.

sbov 10y ago

> due to multiple threads trying to edit the world ref 50+ times per second. Of course you get no benefit if you serialize the game through a single ref. Just because you have a fancy feature like agents doesn't mean you don't have to think about how your concurrent code is behaving. I chose Clojure for the server side code of my MUD. It wasn't for the agents or STM, it was for immutability. Immutability gives me the ability to easily have a consistent snapshot of the world which I can use to perform some operation, such as saving, event propagation, or some AI calculations.

corecoder 10y ago
Which MUD?
lgas 10y ago
If you don't serialize the game through a single ref (or the equivalent) how do you get the consistent snapshot of the world to perform an operation on?
- glhaynes 10y ago
  Event loops are heavily used — basically process input, process physics, process NPCs, render, repeat. (Likely not in that order — I'm not much of a game developer.) This is what the author lands on in the "Success" section. Speaking of event loops, I feel like they weren't discussed very much at all at my school, despite being at the core of not just most game engines, but most GUIs. I think if I'd embarked on writing a GUI system when I was fresh out of school, I'd probably have done it in a massively threaded way like the developer in the article started their game. An event loop would have somehow seemed too … primitive.
- sbov 10y ago
  Architecture can heavily affect how serial your process is. By randomly throwing agents at a single ref you can easily turn parts of the process that can be done in parallel into a serial process. Beyond that, throwing massive concurrency at an inherently serial process tends to give you worse performance vs just recognizing that it's a serial process and not trying to throw concurrency at the problem. This isn't just about fancy concurrency primitives like agents or STM, I've seen plenty of hobby games that ran terribly because they threw concurrency at the problem without analyzing it first, but ended up completely serial because of critical sections in the form of Java synchronization blocks. As an example of concurrency that you would probably have in every single player game: game logic feeds into render logic, but render logic shouldn't be changing the state of the world. So you can be performing the game logic of game loop #N+1 while the render logic of game loop #N is running. Also, usually, when saving the state of the game all you need is a consistent snapshot at the time. Immutability makes both of these easy. The rest depends upon the features and design of your game though. If you aren't going to actually try to analyze where you can benefit from concurrency, you're better off not just randomly throwing concurrency at the problem.

xiaoma 10y ago

This reminds me of Realm of Racket.

Elrac 10y ago

I love that the author takes us on a tour of all his blunders, so we can learn from them the way he did. Far too many "making of" articles present you with a finely polished end product and pretend that its evolution was child's play. That leaves us readers disheartened and reluctant to try similar things.

resatori 10y ago

A few years ago I created a fully small RPG game in clojure: https://github.com/damn/cdq https://github.com/damn/cdq Including procedurally generated maps, items and 3 small levels.