I had a read through of the Clojure website today while thinking about how I would move forward in making a game using ClojureScript. Keeping in the functional model, roughly what we’d be doing in this game is running a loop that effectively takes the current state, applies a transform and stores the new state; while we’re at it we can add or remove
The problem here is that this update is a big process. The whole game is all about keeping state and updating state. And it’s not something that you can simply break down into tiny pieces – all of the parts of the state update need to happen in the right order. This still fits into a functional language; we’d, for example, update buildings, update minions, process events, update interface.
The problem here is this is not a transaction. We can’t just apply the whole game update, then discover that the game state changed, so re-apply the game state update. For one thing this is wasteful, but there may be more serious issues since I can delay the gameplay loop by, for example, buying a building during the update, causing at least the game to be less quick, but at worst adding exploits into the game.
This is fixable – for example I could make the game loop into a series of small updates rather than a big update…but this introduces a timing issue – I could for example build a building with a resource that is about to be consumed by another building. I could also delay user interaction during a gameplay update.
But I feel like I’m going in the wrong direction. I’m looking at a language type that I’m not familiar with, where there is no focus at all on rendering a UI, which is specifically focused away from the idea of a linear game loop. I don’t think I’m going to be able to make good progress, which will be demoralising. So while it might have been interesting to try ClojureScript, I think I will move on and look elsewhere.
Some useful takeaways though:
- There will be a value to keeping the data structures neat. Effectively this game is a transformation that is applied repeatedly, and that is a simple model to use for the main game state. Thinking this way might also make serialisation (saving the game) easier.
- I need to think about concurrency even if initially I’ll be in single-threaded JavaScript. What happens if someone harvests herbs in the middle of a game update?
Next, then, I shall look at one of the other languages.