This is part 2 of my designer diary for Megablast (a solo, deck building, shoot ‘em up game). I want to dive into more of the specifics of the game and my design process. In this post, I’m going to talk about how I went about adapting the screen-based elements of a video game into a table-top board game, and how this in turn sparked the idea for Megablast’s event system.
To recap from part 1. From the outset, I wanted Megablast to emulate the vertical shoot ‘em up video games I played during the 80s and 90s (where the aliens fly down the screen towards the player’s ship). I wanted a heavy sci-fi theme as most of my favourite games of that era pitted the player against swarms of weird and wonderful aliens.
The Grid
In going from screen to table, I first focussed on the main elements of the game – the aliens and the player ship. How were these going to be represented in the game? And what mechanisms would I use for them to move and attack?
As this game was going to be print and play, I decided that cards could easily represent these elements, along with any relevant information (health, attacks, etc.). With that decision made, I decided that a grid system would be simple and effective.
With a little experimentation, I determined that a 4 x 4 grid was a good size. Any bigger and it gets unwieldy and unmanageable, any smaller and it would not allow for meaningful movement and positioning. At this size, the player has to plan their movement to position themselves for attack and defense, making for some interesting and tough decisions (which is what I like in a game).
To avoid complicating things too much I separated the enemy area from the player area. So, the player ship was limited to the bottom row (sideways movement only), and the enemies would be restricted to the top 3 rows (so in video game terms, more of a Galaga style system).
Initially I tried using a board to represent the grid, but I wanted to keep the component/page count as low as possible. So instead of using a board, I tried using cards to mark the outer edge of the grid. It worked really well and I found that you only really needed cards along two edges (top and side). Because the player row was separate to the enemy rows, I also decided that a card was not needed to mark that row. The result is that with just seven cards, we can now map out the play area – nice! Not only does this reduce the page count, it also makes the game easier to store. That’s a win win in my book.
Events
However, I don’t like waste. I saw those seven cards just sitting there and thought they could probably serve some additional purpose in addition to marking out the grid.
I had already wanted a Pow Up system (just like in a lot of video games) where the player could collect a Pow Up to gain some benefit. I wanted some randomness as to when and where they appeared, but I also wanted a consistent amount of them in each of the game’s three levels. Having them triggered by the enemy cards wouldn’t work as they could all clump together in a single level.
Having the column cards double as event cards seemed like an elegant solution. I could also add in some other effects too that make it more challenging for the player. Initially I had each card trigger the first time a card was deployed in that column but due to the randomness of the enemy decks, it could mean that some events won’t trigger in a given level. So instead, I added an event step at the end of each enemy turn so one event card is flipped face-up each turn, from left to right.
Because each event card is in its own column it also meant that I had a random column selector built in – perfect for the Pow Ups as it randomised which column they would appear in. I decided that two Pow Ups was a good number to have each level, so I just needed two other events.
Plenty of shoot ‘em ups have asteroids and other obstacles that the player has to avoid or shoot. This was a must have, so every time the obstacle event is revealed, a card is drawn from an obstacle deck and deployed in the grid. Obstacles don’t shoot, but they can block shots to the enemy cards and damage the player if the two collide. On the plus side, they do award bonus points when destroyed.
Finally, I wanted to add something to benefit the aliens (it’s only fair they get something too). To begin with, I had it so an extra enemy was deployed, but this messed with the cadence of the game and the boss would appear too early. I opted for a boost token which is added to the recently deployed enemy, increasing their attack and defence capability.
Now to the row cards. As there were three row cards and three levels in the game, using them as a level marker was a no brainer – all I needed to do was number the cards and create a token to mark the level. Also, because the enemy decks and upgrade decks are level based, by placing these decks alongside the row cards, it makes it clear which deck belongs to which level.
Final Thoughts
I’m happy with how the grid system has developed. It’s simple and effective, and importantly, it does a good job of emulating a video game (as much as is possible with a card game). I’m particularly proud of the dual use grid cards – the events add more variability to the game, providing more options for the player, and the row numbers track the level and allow the decks area to be better organised.
Next time I’m going to discuss the combat and enemy A.I. Until then, have a blast!
Another Dimension 