designing a cellular automata boardgame
i yap a lot here. this is basically my entire thought process going into designing a board game, and there aren't friendly pictures, though i might add them in laterlike most board games i design, this one stemmed (in part) from me sitting down and being like "i should design a board game". i've long enjoyed cellular automata and have wanted to do something with it. what really got my gears turning was when i was playing a board game i've been designing, tyō (post to come soon), with my friend anna. the game features a mechanic where if a piece is surrounded by three other pieces, it gets captured and removed from the board. i posited the idea of a mod where, instead, if there were three surrounding an empty space, you could spawn in one of your pieces. anna quickly realized by spawning in and moving out, you could create an infinite piece generator, which eventually led to the first prototype of the game, which functioned as so:
two (or more) players would begin the game in an empty 20ish by 20ish board, and set up by putting five of their pieces in a custom orientation. then, every turn, per player, you would find all the squares where three or more of your pieces were touching (diagonals included), and spawn in a piece there. then, if doable, you must move one of those pieces all the way in a direction they can move, until they hit a wall or another piece. if the piece couldnt move in any direction, it just stayed where it was. the game ended when neither player could move, and the player with the most area won.
this idea ended up being fun for a few rounds, but we quickly ran into a couple major issues. the first was relatively easy to deal with. since so called "factories" that generated pieces could send out pieces in a straight line every turn, and with rapid acceleration, the straight lines grew faster and faster. the thing about straight lines is, if you have three pieces in a row, there is technically a square on either side of the middle piece that is touched by all three pieces. this led to enormous growth really fast, that clogged up the board and required a lot of counting. this was easily fixable: simply disclude straight lines when figuring out if a square is touched by three pieces. a little bit of a 'quick hack', but it worked.
however, there were two big issues at hand. number one, as the game got later on, there would be so many different spawn points for pieces, and keeping track of all of them was a pain. number two, after the initial setup and maybe the first few turns, you had less and less options as to which directions to move your pieces, and the game felt more and more like at some point you were just doing the actions you were required to do, and not actually playing the game. it would have been fun if an AI did it, and you could see how your decisions in the start affected the overall cancerous growth, but it wasn't that appealing as a board game.
so thus came the problem. how does a cellular automaton game, (emphasis automaton), be interesting and decision/strategy driven? sure, in the original game you could send pieces over to block your opponent's factories, at least in the early-mid game, but that was about it. i sat down with my trusty grid paper and decided to work out the game, though as i brainstormed, some conflicting ideas got in the way
in the original game we had tried out, the player effectively had infinite pieces. again, would be cool for an online version, but then the game effectively became conway's game of life. so the question becomes: how do i make an infinitely growing game (or at least board size) with finite pieces. even on a 10x10, 100 pieces per color is excessive. i still want to remain true to the idea of building little factories through sheer automation, but while still giving the player some choice, and i started to think the way to do this is to use two different types of pieces. However, i try to keep my games very minimalistic - few rules, one type of piece.
my next idea sort of defied some of the rules i had set for myself. i wanted finite resources to still feel infinite, so i added a caveat. i started with the concept that pieces had a time limit. after a certain number of turns, they would be removed from the board. this instantly made the game a lot harder to manage: all pieces have to be meticulously kept track of. this led me to a different idea: you start with all available pieces on the board, and the game ends when one person loses all their pieces. i wasn't sure how to turn this into a cellular automaton however, but i still wanted to try the design.
the guiding principal through designing this game would be two beings in the same ecosystem, fighting for resources, and trying to stay alive the longest. this could probably be adapted to more than two players, but i started with this principal in mind. like all games, i started with a chess board, as i would have access to a small grid to play with ideas until i decided to scale up, and 32 pieces.
- - -
now, take a breather. i've talked a lot about "design principles" and used many big words. but kind of everything i was thinking about fell apart when i started to mess with the pieces. i ended up designing an entirely different game. it was definitely in part inspired by earlier ideas and while this game would not necessarily go on to play a part in the final product that is the cellular automata board game, i think it's still interesting and fun to play.
the way this game works is each player starts with 12 pieces. at the start of the game, each player sets up their half of the 8x8 board in a custom configuration. every turn, the player must move five of their pieces (exactly five unique pieces in five moves, unless they don't have five moveable pieces in which case all moveeable pieces.). Pieces can move in a cardinal direction, and must move all the way until hitting a wall or another piece. Now, the gimmick is: if a piece hits a piece of the opposite color, one of two things can happen. If the piece were to hit the opposite color *and* there are no pieces in that same line nor a wall touching the piece of the opposite color, the opposite color piece gets removed from the board. otherwise, if there is, the piece that was moved gets removed. the game ends when either one player has no more moveable pieces (and thus loses), or another player gets all their pieces onto the opposite side of the board while having more pieces on the board than their opponent.
hopefully that made sense written out with no pictures
anyways!! after playtesting a couple variations of the original idea played by anna and i, i still needed a game that was not entirely dependent on starting set up, had moveability, and most importantly, was actually a cellular automata game. i liked the rules i had put in place surrounding spawning and movement, so i wanted to create some way to modify the game so that it could use finite pieces and be more decision based. on top of that, with finite pieces, the area model wouldn't work. we (anna and i) had talked about possibly instead of counting area after nothing else could happen, counting area after a pre-determined number of rounds. i decided to start to attack this problem by dealing with two issues. limiting how much work you have to do searching for every single space, and amount of decision making.
the former was easy: every turn you can only spawn in up to one piece (does not auto travel). this curbed the acceleration rate as well. as for the second, i decided to implement a rule where all your pieces must move after your spawn phase if possible, one square in a cardinal direction. this kept your organism of sorts moving. with 16 pieces each, and a starting set up of five pieces in a 8 by 8 board, the game ended after the first player brought in all 16 of their pieces, or a player could not make any valid moves (in which case they lose).
got all that? great. thats my final cellular automata game, for now. it's really not amazing, and hasn't been playtested at all. it's built off of other concepts, and mostly exists in my head - the point of this blog post was mostly to get a peek inside my head when designing a game. i'll probably playtest this game, then write up an actually formal rules and post it on my blog. theres a lot to be analyzed in a game like this and ill probably write up an analysis of game states and moveset in conjunction with the rules. it exists mostly inside my head right now, and thats okay! i'm still enjoying designing games, and will probably write about it more on this blog occasionally.
thanks for sitting through all of this lmao.
back to top