For about a month now I have been working on building a game1, tentatively titled Swarm. It’s nowhere near finished, but it has at least reached a point where I’m not embarrassed to show it off. I would love to hear feedback, and I would especially love to have others contribute! Read on for more details.
Swarm is a 2D tile-based resource gathering game, but with a twist: the only way you can interact with the world is by building and programming robots. And there’s another twist: the kinds of commands your robots can execute, and the kinds of programming language features they can interpret, depends on what devices they have installed; and you can create new devices only by gathering resources. So you start out with only very basic capabilities and have to bootstrap your way into more sophisticated forms of exploration and resource collection.
I guess you could say it’s kind of like a cross between Minecraft, Factorio, and Karel the Robot, but with a much cooler programming language (lambda calculus + polymorphism + recursion + exceptions + a command monad for first-class imperative programs + a bunch of other stuff).
The game is far from complete, and especially needs a lot more depth in terms of the kinds of devices and levels of abstraction you can build. But for me at least, it has already crossed the line into something that is actually somewhat fun to play.
If it sounds interesting to you, give it a spin! Take a look at the README and the tutorial. If you’re interested in contributing to development, check out the CONTRIBUTING file and the GitHub issue tracker, which I have populated with a plethora of tasks of varying difficulty. This could be a great project to contribute to especially if you’re relatively new to Haskell; I try to keep everything well-organized and well-commented, and am happy to help guide new contributors.
-
Can you tell I am on sabbatical?↩︎
blog :: Brent -> [String] 
Very nice, this is super exciting! I wish you could save and restore the game state.
> One could probably even derive this mechanically, by writing a recursive big-step interpreter, then converting it to CPS, then defunctionalizing the continuations.
That is indeed the case, see https://cs.au.dk/~danvy/DSc/18_ager-biernacki-danvy-midtgaard_ppdp-2003.pdf.
Thanks! Re: saving and restoring game state, absolutely, me too. It’s 100% planned (and there are no theoretical impediments) but haven’t gotten to it yet. I’ve created an issue to track it: https://github.com/byorgey/swarm/issues/50 .
Thanks for the link, I wasn’t aware of that paper! Good to know my intuition was on target.
Oh wow! This is really cool! Back in the 80’s, there was a game that ran on the Commodore 64 and Apple ][ called Chipwits that worked on a similar process. We had to program our robot to perform special problem solving activities. I can’t wait to see and try your game!
So let’s see – call for collaboration – do I need to gather resources and build up capabilities to do that?
No, see, that’s what *I’m* doing. You are the resource. ;-)
Pingback: Swarm: a lot can happen in a week | blog :: Brent -> [String]
Pingback: Swarm: status report | blog :: Brent -> [String]