From Screen to Table: Designing Megablast Part 2

Game design

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!

A Blast from the Past: Designing Megablast Part 1

Game design

The basic idea for this game literally popped into my head a few hours before hearing about the upcoming 2020 Solo Print and Play contest on www.boardgamegeek.com. That, coupled with the theme from Xenon II buzzing in my head, was all the motivation I needed to get cracking with the design.

My goal was to design a solid, strategic solo game that had the spirit of the old shoot ‘em up games like Battle Squadron, Project X, R-Type, SWIV, and Xenon II (yeah, I used to be an Amiga geek). It was important that it ‘feel’ like those old games, as much as a boardgame can do so. So I started by thinking about the key features of what did (and didn’t) make an old school shoot ‘em up:

  1. Fast action.
  2. Waves of enemies flying across/down the screen.
  3. Ship control – this was the real skill of the game, maneuvering your ship to avoid enemies and bullets, whilst getting some of your shots on target.
  4. Loads of cool weapons and power ups.
  5. Levels and bosses.
  6. Accuracy – due to autofire being a staple of the old joysticks, a continuous stream of bullets, lasers, and missiles meant that we didn’t have to worry about making our shots count. As noted above, it was all about the maneuvering and big weapons. 

So, how to incorporate these features into a board game?

Early concept testing of main mechanics and shoot ’em up features.

1. Fast Action

The main way to get a feeling of fast action is to make the game real time. Since I don’t like real time games, this was not an option (it’s difficult to make a game you don’t like). 

So instead, I had to make sure that the gameplay itself was quick paced – simple, quick actions, coupled with an intuitive gameflow.

2. Waves of Enemies

My first thought in regard to this was one of theme. You will notice that the video game examples I mentioned at the start are nearly all sci-fi games (or have sci-fi elements). So fighting aliens was something I wanted right from the start.

In shoot ‘em ups the enemies fly towards the player’s ship from the side or top of the screen. In a boardgame format, vertical movement seemed more natural to me, so this decision happened very early on in the design process along with the theme. 

To facilitate the sort of enemy and player movement I wanted, a grid system seemed the logical choice. Each wave of aliens would be represented by a card – that card will have a number of aliens on it, so as you destroy each one their firepower diminishes. I’ll go into more detail on this below as it integrates with the next point (ship control). 

3. Ship Control

Having some sort of ship component that the player controlled was a must have. As alluded to above, this integrates with the alien movement. Allowing full player ship movement as in most shoot ‘em ups seemed impractical – it might require a larger play area and more components.

I decided to limit the movement for the player ship to left/right only, and the aliens would move down the grid towards the player – in this respect the movement became more like Galaga style games. After a bit of testing, 3 rows by 4 columns seemed to be the sweet spot – 4 columns was needed to allow for good ship movement, and 3 rows (typically with 1 alien per row) was a good amount to control at any one time.

4. Weapons & Pow Ups

This was an easy one. Gaining weapons and other abilities via collecting power ups and from a shop seemed like a perfect fit for a deck building mechanic. This also opened up some design space to create a selection of weapons, movement, and other abilities that can combo together in different ways.

I liked the idea of having some Pow Ups that moved down the grid that the player could collect. To emulate gaining a new weapon in a video game, when you collect a Pow Up you draw 3 cards from the shop deck. You then choose one and add it to the TOP of your deck (it is more thematic this way, and a bit different to most deck builders). 

I also wanted some sort of shop (a bit like in Xenon II) to avoid too much randomness (and frustration if you’re unable to collect the pow ups). Destroying a wave of aliens (killing all aliens on a wave card) awards you coins. You can spend these coins to buy specific cards from the shop.

Update: The design has evolved since first writing this blog. Pow Ups are now collectable tokens which can be spent to draw or play an extra card. The coins and shop have also been removed, instead you now simply gain a card when you defeat a card (wave of aliens), or 2 cards for defeating a boss. This put more emphasis on destroying the aliens and increased the deck building aspect of the game.

5. Levels & bosses

Most of the old shoot ‘em up games were broken down into levels. At the end of each level you had to fight a boss to continue. Breaking the game into several levels was easy to do and added a nice progression to the game (to balance out with the player’s evolving deck). To maximise card efficiency and variety, I decided to have all the aliens and bosses scale to the current level.

A level structure also fits nicely with the shop idea. At the start of each level, you visit the shop to gear up for threats you’re about to face.

6. Accuracy

As this was not something that needed to be part of the game. I wanted to eliminate the randomness of shooting. So when you use a weapon card, it simply deals damage – no random chance of it hitting (with a few exceptions of some alien defensive abilities, however these can be mitigated).

Second prototype – more graphics than I’d usually add at this stage, but I felt it important to get a better feel for the theming of the game.

Final Thoughts

I hope this has given you a little insight into Megablast and my design process. I’ll delve into more into the specifics in a later blog, as well as share how the game is developing.

I’d love to hear your thoughts so far and what shoot ‘em ups you remember from the old school days of video games.

Designing for Dyslexia: Text in Game Design

Game design

Introduction

Great strides have been made recently in making board games more accessible to players with various forms of colour blindness. It’s something often discussed by players and designers alike. However, something that isn’t talked about (in my experience anyway), is how the graphic design can create a barrier to people suffering from other vision problems and dyslexia. So, I wanted to share some thoughts on the subject.

Not all vision issues can be fixed with a pair of glasses. I suffer from an eye problem that makes it difficult to focus on small details (e.g. reading small/unclear text). One of my friends and fellow gamers, Anthony Brown, has similar issues with text; he is dyslexic. Although the cause of our problems are very different, the result is the same: if a game requires too much effort to read the text, it becomes less enjoyable and will usually be sold on, never to be played again. Furthermore, for dyslexics it’s even worse as they can misread rules or effects, which can be frustrating and contribute to a negative play experience.

If a game requires too much effort to read the text, it becomes less enjoyable and will usually be sold on, never to be played again.

With the above in mind, this article focuses on text in games. Text in games is extremely common, particularly in games that use cards with a variety of effects and abilities. So what are the potential pitfalls and how can you make your game text more accessible? I’ll discuss the main points below. You’ll be pleased to know that all text accessibility issues are easily fixed with a little thought and common sense.

Titles vs. Descriptions 

I’d like to start with a caveat. It is important to realise that many of the points I will discuss apply primarily to descriptive text (i.e. where there is more than just a few words). For titles and headings, you have more leeway but still bear the following in mind with all of the text in your design.

The Font

First up then is the font itself. Choosing the right font is essential. Don’t use fancy fonts except for titles and headings. Reading more than a few words in an unclear font is very difficult for people with vision issues. Instead, choose fonts that have a simple design and are clear to read.

Sans-serif fonts are preferred, especially if there are lengthy descriptions or the text size will be smaller than is ideal. Also make sure your font has both uppercase and lowercase letters (this will be discussed later).

Text Size

At an absolute minimum, your text size should be 8pt but the larger the better. Try and make your text 10-12pt if you can (depending on the font – some fonts are smaller than others). Similarly, don’t use tiny text in a big area – if you have a lot of space in your text box, make the text bigger and use all of the available space. If you have the odd card that has more text, you can make the text smaller for those specific cards – it is much better to have most of your cards easily readable than none of them. 

If you have a lot of space in your text box, make the text bigger and use all of the available space.

If you have a lot of descriptive text, don’t use small cards or components – scale the components to the amount of text you are using. 

Text Style & Formatting

Next up is the text formatting. Firstly, don’t use all-caps for descriptive text (it’s fine for titles and headings though). It has been well established than reading text that is all uppercase requires a lot more effort from the reader.

Similarly, don’t make all of your text bold – this has a similar effect to all-caps. Bold should be used for one or a few words to highlight them.

Line Spacing

Similar to the effect of all-caps, line spacing also affects the white space around the text. Line spacing should be at least the height of the text itself. If there is a lot of text spanning several lines, consider increasing the line spacing to make it easier to read.

Contrast

This is a trickier one and there are several problems that can occur. The most common is not having enough contrast between the text and the background. For example, your card might have a fairly dark parchment image for the textbox, and the text might also be a dark brown to make it look more thematic. This can be very difficult to read, especially if the lighting conditions are not ideal. When using backgrounds, try to make sure there is plenty of contrast – this usually means lightening the background and making the text black (or very dark).

Conversely, too much contrast (e.g. pure black on pure white) can also be difficult for dyslexics, especially light coloured text on a dark background (e.g. white on black). The best solution then, is to have black text on an off-white background, or off-black text on a white background. 

Furthermore, when using background images for your text, make sure it is a fairly ‘flat’ image. By that I mean that the lightness is fairly consistent across the background (where the text will be). This avoids the issue of varying contrast. For example, a dark patch on the background image will make the text on top of that part very difficult to read anyway, but for dyslexics the change in contrast makes it even more difficult for them as their eyes have to readjust to those changes.

The best solution then, is to have black text on an off-white background, or off-black text on a white background. 

Some dyslexics will find certain background colours more difficult to read, but unfortunately there is no rule that can be followed here. Person A might struggle with yellow backgrounds and find text easiest to read on a light blue background, but person B might be the opposite. So when it comes to colour there is no perfect solution, so all you can do is follow the above advice to minimise any contrast issues as best you can.

Rulebooks

All of the above also applies to rulebooks. If your rules are physically difficult to read, it can put people off even learning your game and it might not even hit the table. Also remember that rules are not necessarily read just once to learn the game; players refer to them during play and to refresh their memory between plays. 

Consider this, if I am choosing between two games. I need to refresh my memory of the rules for both games: do I pick the one that’s easy to read, or the one with the small text and low contrasting background? It’s not a difficult choice.

Keywords

Unlike the previous points, this one does not relate to the look and style of the text. If your game uses keywords (e.g. to make it easier for players to remember certain abilities and effects), choose words that are not too similar to each other. For example, the keywords Precise and Peirce are similar words and can be easily confused by someone with dyslexia: they could easily get them mixed up because although the text says ‘Precise’, their brain could read it as ‘Peirce’, and therefore they would be using the wrong ability/effect without even knowing it.

Icons

Of course, one way to avoid text issues is to bypass it altogether and use icons. This has the added bonus of making your game more language independent. If you choose this route, reference cards are a must to to help players learn what they mean as they play.

However, icons also come with their own set of potential problems. Obviously you need good icons that represent what they mean, and good descriptions in the rulebook. Also, too many icons can overload players with the amount of symbology they need to learn, so it’s really a judgement call as to whether this is a viable solution for your game. 

Conclusion

In short, hard-to-read text is a barrier to enjoying the game, for some people more than others. There are lots of games out there, so people who struggle with the text in your game will simply choose a different one to play.

Do you suffer from dyslexia or vision issues that can make some games difficult to play? If so, please comment below.

Finally, I would like to take this opportunity to thank Anthony Brown for his input into this article and answering my many questions on dyslexia.

Limitation Inspires Creativity: Designing Laser Bots

Game design

Laser Bots is a two-player strategy card game. Players each control a robot via an action management system: actions become more powerful depending on the amount of cards played before the effect occurs, so the order of card play is the key to victory.

Origins

Laser Bots started out life as a computer game that I created back in the 90s on my trusty old Amiga 1200. I was a student at university, and my friends and I needed some cheap (i.e. free) entertainment, so I locked myself in my room for a week and created what was then called Laser Droids (I only recently discovered that George Lucas owns the rights to the word “droid”, hence the name change).

The gameplay was simple: up to four players moved a robot around the screen (a 2D top-down view) and tried to shoot and destroy each other. There was also a ‘power droid’ that meandered around the screen dropping weapon and armour upgrades. The sound was minimal, the graphics were terrible, but boy was it fun.

What made it fun? Well, when four players mashed the fire button, the computer couldn’t cope with all those ‘bullets’ on the screen so I needed a way to limit the amount of laser fire. The solution: limit ammo to 10 shots per robot via an energy resource, and have a recharge zone in the middle where you could regain energy, but you were vulnerable whilst doing so (you had to hold down the fire button and watch your energy slowly recharge). Suddenly there was an element of strategy and tactics in this fast moving shooting game: you had to make every shot count and pick the best moment to recharge your energy.

Evolution

Fast forward about 10 years; I decided to create a simple boardgame version for a reunion with my old university friends. The game was fairly crude, but it had a hex board, standees, and lots of cards to replace the power droid. The energy and recharge zone remained as this was the essence of the game. We had fun with this first version but it was far from a great game. However, there was something there that I felt was worth pursuing, so over the next five years or so I worked on it sporadically, improving the gameplay and mechanics where needed.

Over that period, the movement mechanic and unique robot abilities were merged into program cards – these had a special ability unique to the robot, and a movement path. Program cards were chosen at the start of the round and revealed simultaneously, cutting down on play time and adding an element where you had to anticipate your opponents’ moves. There were also command cards, available to all robots, which added instant effects that could chain together.

As the game evolved it was looking like it was getting close to being a decent game, so I commissioned Gong Studios to do some artwork. I like to be immersed in my projects and having some great art really helps my creativity. I also find play testers are more engaged when it looks pretty. So, I had a new prototype printed at The Game Crafter with a new tri-fold board with improved graphics, illustrated player boards, and new standees of the robots.

However, whilst the game had improved a lot over its development and it had some nice mechanics, somehow it just didn’t all hang together in a good way. At times the game felt slow and clunky, and I wasn’t really enjoying playing it much. So I decided to shelve Laser Bots and focus my efforts elsewhere.

Less is More

Shortly after I shelved Laser Bots, I founded a small company designing and selling 3D printed gaming accessories. This swallowed up most of my time so I had an extended hiatus from game design. Eventually, the urge to make games got the better of me and I started working on a few projects in my spare time. I joined some Facebook groups and started getting more involved with the game design community, and eventually stumbled on to The Game Crafter’s Mint Tin Contest.

Now this seemed like a great way to get back into designing games – entries had to be small (to fit in a mint tin), short (under 20 minutes), and not too complex. Entries couldn’t use copyrighted artwork, and my funds were limited. So, I started by searching my archives for art assets I could use and decided I would go from there. Amongst other ideas, I wondered if I could redesign Laser Bots to the constraints of the contest. Perhaps some limitations were exactly what I needed; the original computer game was born out of limitations of technology, so maybe restrictions on game components and complexity were the key to finally making Laser Bots work.

The first thing I did was limit the game to four robots (there were six in the previous big-box version). I selected them carefully so each one had its own unique abilities and play-style: Astro is defensive and works well at long range, Henry is better at offense and manipulates cards in play, Sparky has mastery over energy, and Turbo is all about speed & movement.

The game size and length were the next thing I tackled, and it wasn’t long before making it a two-player only game seemed like the right way to go. This meant that with four robots to choose from, there would be a decent variety of robot match-ups.

Then I had to decide on the core mechanism. I’d wanted to design a game using what I call ‘action management’ for some time. It’s a not a well known mechanism – I’ve only seen it in Assault of the Giants and really liked the concept. The basic idea is that you build up a row of cards, one card per turn. When you add a card, the more cards that are already to the left, the more powerful the newly played card becomes. So the timing of when you play each card is a key factor to victory. You then have some means to return all your cards to your hand so you can start the process again.

I took the old program cards and adapted them to this new mechanism. The movement paths were no longer needed, just abilities unique to each robot. However, for action management to work you need a hand of about eight cards to choose from so you can build up the cards and still have a choice of what to play and when. With four robots to choose from, that’s a total of 32 cards, leaving no room for other cards in the tin once you factor in the other essential components.

At this point I also considered the game’s replayability which would be limited with only four fixed decks. This is why I added the advanced program cards: 12 unique cards with two dealt to each player at the start of the game – this really mixes things up, and opens up lots of card combos. I also wanted each droid to have some basic actions to increase and decrease range so I created the sets of basic program cards for this (two identical cards for each player). So with two basic program cards and two advanced, I now only needed four unique cards per robot – perfect!

For the robots’ own program cards, I balanced them by giving each a defensive card, a movement card, a normal attack, and a double damage attack. Each of these cards has their own unique twist depending on the robot’s personality and play-style. I also made some actions ‘delayed’, so they could be used later in the game, such as defensive abilities and attack rerolls.

As part of the action management mechanism, I created the Recharge action which players can perform instead of playing a card. This is a nice nod to the original recharge zone idea – when recharging, you can return any of your cards to your hand, and you gain an energy for each card returned. Again, nice and simple and it elegantly fused the energy resource with the action system. With this action I added the option for players to leave cards in their program row to give them a head-start building up their cards, and also to leave cards in play that had unused actions.

Then I moved onto the game board – I tried making a board from several cards, but they shifted around too much. I then thought to myself, what function does the board serve? Once you remove all features from the board (recharge zones, terrain), it essentially just determines how far the robots are from each other. Now the game was only two players, this function can easily be utilised by a range tracker, and so the range card was born – perfect for a mint tin game. I love it when I come up with an elegant solution like this.

I tried several variations of the range card. Initially the target number went down to 2+ but I found that it devalued defence cards – forcing a reroll when the attacker only needs 2 or more was pretty lousy odds. But with best chance at 3+ it gives a reasonable chance for a reroll to miss. Whilst making these changes I also adapted all of the ‘Shield’ cards so that if the attacker’s reroll still hit your robot, you gained some other benefit – this way it never felt like you had wasted your shield, removing any potential negative play experience resulting from bad luck.

With a lot of play testing, I made various other tweaks and changes until I arrived at the game as it stands today. It was a lot of hard work, and it was a huge learning experience in skills beyond game design – I’ll probably cover this in a later blog entry.

I’m very pleased with how the game turned out, and it’s a game that both I and my testers really enjoyed playing. Laser Bots exceeded my expectations, and I owe a lot of what makes it work to the limitations imposed on the design: from the original computer game to this mint tin version. In the evolution of this game I really have come full circle.

Further Info

For more details on Laser Bots (including a playthrough and tutorial video), and to purchase the game, please visit the shop page: https://www.thegamecrafter.com/games/laser-bots

If you like the look of Laser Bots, please consider voting for it in the Mint Tin Contest: https://www.thegamecrafter.com/contests/mint-tin-challenge

3D Printed Accessories

Our 3D printed gaming accessories are all designed in-house and can be used with many different board, card, and war games. All of our 3D printed products are available in our Etsy store.

We have accessories designed specifically for Babylon 5 CCG, Arkham Horror LCG, KeyForge, Journeys in Middle Earth, Museum, and Terraforming Mars. We also have several generic products that can be used with numerous games. Please click the images below for details.

Designer’s Blog

I have been designing games (video and board games) for over 20 years, and have written numerous RPG books. I recently released my first two board games as part of The Game Crafter’s Mint Tin Challenge, and I wanted to share my journey into the world of board game design via a blog.

To read my blog posts, please go to the blog section.

I may also write some articles on designing 3D printed products, but the main focus is on boardgame design and everything that goes with it. I hope you enjoy reading my posts as much as I enjoy writing them.

The prototype of an earlier, big-box, version of Laser Bots