My thoughts about Brian Carpers’ RPG post

Brian Carper wrote a very interesting blog post about his RPG written in Clojure. I’m hoping to write a game in Clojure myself (once I feel confident enough with Lispy functional programming) so I will keep a close eye on what will hopefully become a series of blog posts.

Here’s the comment I posted on his blog:

Thank you for writing this post! It’s interesting to see a game developed in a functional language, as at their core games are all about updating a huge blob of global state—the virtual world. Trying to break a game into (purely) functional pieces seems to be quite a challenge for programmers used to thinking in Object-Oriented terms. To make the culture shock even worse, many game concepts map very naturally to OO: you have a Player collecting Items into an Inventory and so on, so the temptation to write Java in Clojure is great for newbies like me.

Here are a few thoughts I had while reading this post (don’t take them as criticism—they just popped in my mind and I thought I’d share them):

  • Sleeping 10 ms each frame makes the game run slower, but the duration of each frame, and thus the timestep of your simulation, is unpredictable. If you sleep just enough to make each frame take 1/60 s (capping your framerate to 60 FPS), many things become slightly cheaper and easier; for example, your characters can move at the fixed speed of n pixels per frame, you can advance the animations by a fixed amount of frames per update, etc.

  • The term “map” has quite a lot of meanings in your codebase: the function, the data structure, and the set of tiles in the world. And I assume that at some point your player might even find a map of a dungeon. To avoid confusion, it might be good to distinguish between the meanings by using names like “hash maps”, “tile maps” and “map items” in comments and documents.

  • I don’t think that threading the whole world through your functions is a good idea. It’s almost equivalent to storing everything in global variables that any function can modify. I think it would be better to only give each function just enough of the world as several explicit arguments, and then explicitly merge the result with the previous state of the world with assoc-in or update-in.

  • Even though it’s still WIP, and written for C++, you might find the book Game Programming Patterns interesting. If nothing else, it gives you a glimpse into the way pros think about game development (AFAIK, the author works for EA).

Good luck with the project, and please do keep us updated as your game progresses!

—
Timo