Tag: computer games

Revisiting Collectible Card Game RPGs

I remember playing the Pokemon Trading Card Game for Gameboy Color as a child. It is a game where you walk around to different gyms and battle trainers and gym leaders using pokemon trading cards. Opponents give you booster packs when you defeat them, and you use the new cards from those packs to build and improve your decks. There is a storyline, but it is very thin; the game is mostly focused on battles.

These days, there are plenty of digital Collectible Card Games (CCGs) out there. CCGs are not the same as the deckbuilding games that are popular nowadays; in a CCG, you can freely assemble and modify any number of custom decks from your ever-growing collection, whereas deckbuilders incorporate deckbuilding into the game and greatly restrict your ability to modify your deck.

Most digital CCGs are built around an online PvP structure, supplemented by a limited challenge mode where you compete against an AI. Microtransactions to buy new cards or booster packs are also common. Presumably the thought is that players will compete against their friends and be driven to improve their decks, occasionally shelling out some money for better cards.

This is a terrible idea.

CCGs that rely on PvP inherently suffer from the problem of network effects, the same as any other multiplayer game. If many people play the game then the game is fun. If few people play the game, then it isn’t fun, even if the basic mechanics are sound. Having a thriving PvP scene is a nice bonus, but it absolutely cannot carry the game.

Why don’t we see more digital CCGs like the old Pokemon game? Because of the (weak) RPG structure, it was a lot of fun even if you didn’t play against other human players (though that was also supported using a gameboy link cable). CCGs actually form a very strong basis for an RPG. Both opponents are playing with the same ruleset, so it is easy to understand what your opponent might do. Booster packs work as natural loot for winning a battle, and it is easy to draw a connection between the opponent and the loot; just brand the booster pack accordingly. The player can also expect to find some of the cards that the opponent used against them in the booster pack, which is a very effective incentive to challenge the same foe again and again.

RPG combat, at least from traditional JRPGs can also often feel repetitive and stale, with the player just finding the optimal attack and hammering it. Even looking at the pokemon games, I find that the RPG combat is much less interesting than the CCG combat – there are so many moves like leer and growl that there is no point in using because the more powerful moves will take out the opponent instantly. Whereas the card game is structured so that almost every move is useful in some instances, often because the player lacks the energy for the move they really want to use.

I think CCG RPGs have a lot of unexplored potential. The CCG elements fix the problem of stale combat and progression mechanics, and the RPG elements ensure that you don’t need a vibrant online player base to enjoy the game. I’m definitely considering trying my hand at one at some point.

Designer Diary: Corrupted by Ruin #2

I spent the last week at a game design retreat, and among other things, one game I tested was “Corrupted by Ruin.” I don’t have a digital prototype yet, so I printed out some tetrominoes and monster cards and had people play it as though it were a board game.

There are some pretty significant differences between digital games and board games. Some games that work great in the digital realm fall flat in the real world, and some things don’t make the transition in the other way very well either. Still, paper prototyping is a great way to validate an idea, and it is a good sign if something works well even without a machine.

While playtesting, I realized that the triggering mechanism for an incursion makes a big difference in how it feels. Traditionally in tower defense games, the player alternates between constructing defenses and operating them (actively or passively) against regularly scheduled waves of intruders. For example, in “The Last Spell,” the player builds structures and upgrades their heroes during the day and then deploys them against the monsters that attack every night. I initially approached my design this way since it is about defending a dungeon against heroes.

The problem is that this leaves the player very little control over where the heroes enter the dungeon. A big part of the game is engineering encounters to maximize the effectiveness of the monster and room combinations. If the heroes can enter the dungeon anywhere, the player has little control over their path. Seeing where the heroes enter ahead of time doesn’t help much either because the player can’t rearrange their rooms to account for it.

So instead, I tried letting players trigger the incursions. I added “staircase” tiles around the map, and whenever a player would connect to a staircase tile, heroes would invade. The player’s incentive to go after staircases was that defeating heroes was necessary to win. The resulting game felt much more interesting to me. The player is still playing defense, but now they control when and where they fight the heroes.

Roguelike games tend to have a proactive aesthetic, where the player is constantly advancing spatially towards a goal. Reactive gameplay clashes with this. I tried out “Tower Tactics: Liberation,” a tower defense roguelike, and found this contradiction to stand out. You move from place to place, and in each location, you set up towers and defend against waves of enemies, but the contrast between the map movement and the lane defense is a little jarring. By flipping the script so that the heroes react to the player’s incursion, I hope to align the high-level gameplay aesthetic of conquering land after land with the lower-level conquest of a single kingdom.

Giving the players complete control of hero incursions also has implications for what happens when the heroes invade. Deterministic combat allows players to calculate the exact results of triggering a battle rather than relying on their heuristics. I want to avoid this because it is tedious for the player. Also, with more control over the path the heroes take comes the obligation to make the associated decisions more interesting. I think my current combat system is too plain to justify this, so I am starting to think about more interesting mechanics for combat. I will most likely want a puzzle of some sort.

Another problem that I solved through paper playtesting was how to handle monster recruitment. My previous system involved buying monsters from a pool of available ones, with new monsters unlocked by building specific types of rooms. That has three problems: First, it obligates the design of a matching room or monster even when it doesn’t necessarily make sense. Second, players already draft rooms, and doing the same for monsters feels repetitive. Third, it doesn’t interact very much with the tile-placement mechanics that are central to the game.

The solution turned out to be very simple – monsters, like gold, start each level embedded in the map. When you cover them with a tile, they join your dungeon. Now I can design monsters independently from rooms and even associate them with map types, and monster drafting interacts with room placement to enhance both.

To “mine” monsters out of the ground implies that monsters are a finite resource. Limited upgrades for monsters also make sense since they feel less generic than they would under a drafting system.

Granularity and Combat Mechanics in Tactical CCGs

I have never played Hearthstone, but I have played some of the games it inspired. Back when its servers were still active, I remember enjoying Duelyst a lot, in particular. Duelyst was an online CCG where players drew creatures, items, and spells and played them to a grid. Essentially, Hearthstone but with spatial positioning. While I don’t often care much about graphics, I found its pixel art style one of its most compelling features.

Recently, partially out of nostalgia for Duelyst, I tried out a similar game called Cards and Castles 2. I stopped playing after only a few minutes because I found the granularity of the combat mechanics to be unbearably high. Just as with Duelyst, each creature has an attack number and a health number. Attacking lowers your target’s health number and also prompts them to counterattack. However, the range of numbers used commonly goes into the forties and fifties. Worse, to see the current attack and health, you have to mouse over a unit, making it very difficult to understand each creature on the board at a glance.

Funnily enough, Battle for Wesnoth has similar combat mechanics and granularity, but I don’t mind it in that game. I think this is due to expectations. Battle for Wesnoth is a turn-based strategy game often played against the computer, so you expect to consider each move carefully. Cards and Castles 2 presents as a CCG suitable for quick matches against other people, so the amount of processing required to understand each unit is more noticeable. Duelyst, by contrast, keeps most numbers under ten and displays them clearly beneath the creatures.

The moral of the story is that large numbers make it harder for players to grasp the game state because they make the arithmetic harder and less automatic. Another related issue with Cards and Castles 2 is that the abilities of the cards use percentages; “this unit gets 20% damage resistance” or “this unit takes 70% less damage when attacked from the front.” A percent value works for probabilities but serves as a barrier to understanding when it requires actual multiplication. The only percentages that most players can multiply without effort are 50%, multiples of 100%, and (to a lesser degree) 10%. Abilities phrased in terms of small integers are a lot easier to grasp.

In contrast to board game design, I think it is tempting when making computer games to assume that complex calculations carry no cost because the computer is performing them. But this isn’t entirely true – even though the computer can crunch the numbers, the player may still want to understand what they mean.

After my disappointment with Cards and Castles 2, I still felt nostalgic for Duelyst, so I tried another similar game; Stormbound. I was pleasantly surprised. The game takes place on a four-by-five grid where the objective is to damage your opponent by marching a certain number of units to their side of the board. Unlike other tactical CCGs, it is an auto-battler – you cannot issue commands to your pieces once placed; they move forward by themselves every turn.

Another unusual feature of Stormbound is the deck size – 12 cards. Most CCGs have decks of 30-45 cards, but Stormbound instead recycles cards so that you have no discard pile. You can have exactly one copy of each card in your deck and see all of them several times each game. Lucid works the same way, so I am well acquainted with its advantages. Among other things, this makes constructing a deck much less daunting since you only have twelve choices to make and don’t have to worry about how many copies of each card to include.

The most novel feature of Stormbound for me was the stats of its armies. Instead of the typical Attack/Health, each card has Strength/Movement. The first number is how many units you gain when playing the card; the second is their number of immediate moves.

When two opposing armies fight, they both lose an equal number of units such that only one remains. I have not seen combat mechanics of this mutually-destructive sort before; the closest thing I can think of is combat in Neptune’s Pride. My natural inclination before seeing Stormbound was that it wouldn’t work because it eliminates the possibility of one side gaining an advantage through combat – for each unit you destroy, you have to sacrifice one of your own, so what is the point?

I think I understand how Stormbound makes it work, however. Most units created are just a byproduct of effects that occur when you play cards. For example, playing a card might deal one damage to every unit in a line AND create a two-strength army at the origin of the line. Some units do have persistent special effects, but most do not. It doesn’t matter that your units mutually annihilate in combat because the game is all about where you play your cards.

The idea of having one number combine attack and health doesn’t seem quite so radical to me anymore. In Duelyst, combat hurts both parties as well; the only difference is that both might survive. It might be different in a multiplayer game where both suffer to the benefit of the other players; then again, this is already what happens with more than two players.

I don’t recommend Stormbound as a game. It allows players to level up their cards to make them stronger, which means that a player who has spent more money might have a better deck than a new player even with the same cards. But it has does have some unusual mechanics worth checking out that challenge the orthodoxy on digital CCGs.

SWIM – My first PICO-8 Game

Click the play button below to try out the game. (You may want to go fullscreen)

I recently got into designing games for the PICO-8 fantasy console. PICO-8 lets you create and share small games – so small that you can encode the logic, graphics, and music in a single png image! It does this through steganography, storing the game information in the least significant bits of each pixel. You can take a screenshot while playing, and PICO-8 takes care of encoding everything in that one screenshot, which serves as the cover for the game.

Making games in PICO-8 feels different than making games in Godot, my default engine. It has no built-in physics, so you have to write functions to handle collisions, motion, and so forth. And there are no objects – the closest you can get is creating a table with attributes to pass into a function. Drawing things to the screen is also much lower-level than I am used to, although PICO-8 at least has a decent suite of useful commands for drawing with pixels.

It is possible to create sprites in PICO-8, but there is no built-in way to rotate them. Because of this, I decided to eschew sprites altogether and draw everything from scratch using just code. Everything in SWIM is made up of circles and individually drawn pixels, which allows for rotatable graphics. Something I like a lot is that PICO-8 measures angles such that a full circle is equal to 1 unit. For example, if you want to rotate 180 degrees you add 0.5 to your angle. I wish more engines did this; reasoning in radians or degrees is ugly, annoying, and unnecessary; now that I have experienced trigonometry in normalized units, I never want to go back!

The fact that an entire PICO-8 game can be represented as a png image immediately made me think of NFTs since they are typically just images or GIFS. That means that PICO-8 games are uniquely suited to be collectible items on a blockchain. I’ve never done anything with NFTs before, but I decided to try making some games and minting them on the Tezos blockchain. I chose Tezos because it is significantly more eco-friendly than Ethereum and has much lower gas costs. I plan to make several more collectible minigames after this one. My next one will be about cooking hamburgers.

You can view the NFT for SWIM here.

What I Learned from Slipways

Slipways is an excellent take on the 4x genre, streamlining the formula to create a game that you can play in 1-2 hours. I used to like games like Civilization, Master of Orion, and Alpha Centauri, but I no longer enjoy them because they take too long and require too much micromanagement. After dozens and dozens of playthroughs, these are my biggest takeaways as a game designer.

Debt creates goals

The most innovative mechanic in Slipways for me is the way it handles converters. “Converters” are things that accept resource inputs and produce other resources for the player. The brilliant thing about converters (colonies) in Slipways is that they yield their first outputs as soon as you build them before receiving any inputs. If you urgently need a resource, you can set up a colony to produce it immediately.

While a colony will produce resources without receiving its inputs, it does so at an escalating cost to happiness, an important part of the scoring formula. Furthermore, while satisfying its needs eliminates the unrest, taking too long to fix it results in a penalty that stays forever.

What makes this work so well is that each planet both solves an existing problem and provides the player with a new goal to pursue (and a time limit to complete that goal). Each colony you build is a loan that you will need to pay back, and the neverending quest to pay them all back is the primary driver of the gameplay.

The summary of this game design pattern is: 

  • To provide a goal, give players an immediate reward tied to a penalty. Allow them to eliminate the penalty later by accomplishing some specific (but optional) task.

Upgrade converters when used to encourage interaction

Providing input to a colony does more than just removing the happiness penalty; it also upgrades the planet, creating new needs. Each level results in both more outputs and new challenges, ranging from finding markets for the exports to improving nearby planets. In this way, the player receives a natural-feeling stream of goals.

A big problem that converters often have is that they feel too one-dimensional. In many games, it is common to see converters sitting idle when their outputs are not needed. Upgrading a converter when used is a brilliant side effect that gives the player a sense of progression. Maybe you don’t need any wood right now, but wouldn’t you rather have a logging camp instead of that pitiful little forester?

The summary of this game design pattern is: 

  • To provide player progression and encourage players to use converters, include a side effect in your converter designs. After using a converter a certain number of times, it upgrades.

Discourage completionism by gating off low-level options

Slipways does something interesting with its tech trees that I haven’t seen before. At any given time, you may research technologies from your current tech tier or the previous one. Completing research causes your tech level to advance, providing access to new technologies while also cutting off access to old ones that you never got around to researching. Thematically, the justification is that your scientists have moved on to more exciting projects.

The effect of this design decision is that players must think carefully about which techs they need from each tier because they can’t take them all. This discourages degenerate tendencies towards buying obsolete tech simply because it is cheap relative to the player’s current science production.

For the game designer, this makes balancing technologies a lot easier. Even early game tech can be impactful because you don’t have to worry about the player picking it up at no opportunity cost later. It also improves replayability because the player can’t just always take all of the early technologies.

I think this principle applies to any system where the player chooses from options across several tiers with escalating costs. By locking early options as you unlock later options, each item the player chooses becomes more meaningful.

The summary of this game design pattern is:

  • To enhance replayability in games where the player buys new abilities from a tiered list, lock earlier tiers as the player advances.

Use marginal increases in upkeep rates

The most jarring and unpleasant part of Slipways for me relates to administrative upkeep costs. As you add more planets to your network, there are thresholds at which your empire “size” increases. Each time this happens, the number of credits you pay per planet in upkeep increases by 1. I am often shocked when this happens because building a single new colony causes a massive drop in income.

I found that such abrupt changes in income felt artificial because it didn’t make sense that adding one planet would suddenly make the rest of them cost more. This led to situations where I didn’t want to build a colony because it would drastically change my costs. I prefer marginal upkeep systems like the one in Eclipse where each colony costs progressively more to maintain than the last one.

My main takeaway from this aspect of Slipways is to avoid springing massive upkeep changes on players just because they crossed some threshold. There’s no design pattern here, just a cautionary tale.

4X games don’t need combat

Slipways has no combat, a departure from the genre (the fourth X stands for “exhale” instead of “exterminate”). While it is a single-player game, its focus on trade would work very well in a multiplayer board game, trade providing healthier player interaction than war. The emphasis on commerce over combat is one of the things I like a lot about Sidereal Confluence, and Slipways demonstrates that you don’t need to abstract everything else away to get it.

What Loop Hero Does Well

I beat Loop Hero recently. It is an excellent game with a core gameplay loop that is addictive and engaging. You play as – or perhaps, manage – a hero in a world that has been forgotten (literally) and walk around a circular path placing tiles. Each tile provides both opportunity and danger, often in the form of enemies to fight. The hero automatically battles monsters (with no input from the player) and receives equippable loot that modifies their stats. Once you die or retreat, you return to your camp and use resources acquired during the expedition to improve your base. Then you embark on another journey.

The best part of the game for me was tile placement. What makes tile placement engaging is the interactions between tiles. Some tiles transform others; if you put a meadow next to something else, it will become a blooming meadow, increasing its healing by 50%. Other tiles complement each other very well; swamps make healing lethal, and vampires heal their allies, so it makes sense to place vampires by the swamp. With over fifty different tiles, exploring the rich heuristic tree of tile placement and synergies was what kept me returning to the game.

Tile design in Loop Hero follows the principle that every choice should provide both risk and reward. There are very few tiles that are pure upside; nearly all of them pose some threat to the hero, and the challenge is finding ways to mitigate the danger so you can enjoy the reward. This is a tried and true principle of game design, and it is executed very well here. I think my favorite example is the smithy, a building that consumes unused items to give you a defensive buff, spawning a golem after the sixth. The cleverest part is that killing the golem gives you six items that are often more valuable than the ones you lost, so you are punished for your greed but rewarded for facing the punishment.

The game also features three types of heroes to choose from, each with radically different mechanics. When I realized that the third hero was the final one, I was disappointed that there weren’t more. But as I kept playing, I came to appreciate the stark differences between them. Each hero has a central, unique mechanic, and the same tile might have very different implications for different heroes. For example, the first hero gets stronger the longer the battle takes, so a tile that reduces everybody’s attack speed is better for him than for the other heroes. The different hero-tile interactions added another dimension to the tile placement subgame, which kept things fresh even when I used the same tiles in each game.

Four Quarters made an excellent decision in using idle-style combat with no player inputs. Players will often fight dozens of monsters in a given loop, and having to make combat decisions would slow the game down to unbearable levels. Removing choices from battles leaves more time for tile placement. This is a useful general principle- whenever you have two subgames, and the first is much less engaging than the second, paring down the former gives players more time to focus on the latter.

I wish that inventory management had received the same treatment as combat, though. The hero has several item slots and the loot that you equip buffs different stats. You have to ask yourself questions like, “is 20% evasion better than 5% vampirism and 8 defense?” Each item has a numerical level as a rough guide to its strength, but sometimes your strategy may require a lower-level item with the buffs you want over a higher-level one irrelevant to your build. One benefit of the system is that it helps the player identify with the hero. Eventually, however, the constant need to compare item stats begins to feel math-y and tedious. I found inventory management to be the least compelling part of the game.

The other main subgame involves building your camp between runs. Much like expeditions, building your camp involves placing tiles on a square grid with placement mattering for certain tiles. For example, the Farm produces one food resource for each of its surrounding tiles that is empty. Constructing buildings is the primary way you spend resources gained during an expedition. Base-building is fun, but only in the same way that incremental improvements between games are satisfying in any roguelite. Players like progression and like seeing numbers go up. Letting them build a base to increase their numbers is difficult to get wrong.

Within the base-building subgame is another subgame where you can craft and equip special non-inventory “camp items” between expeditions. Initially, these confused me because the effects of each item were so weak. For example, the Loaf of Bread only gives you +10 HP (for reference, the total HP for the hero rises from the low hundreds to over a thousand by the end of an expedition). However, as you upgrade your camp you gain more and more camp item slots, so you might eventually equip 30 Loaves of Bread for a respectable boost of 300 HP. This is fun in the late game where it provides highly granular customizability to your hero but is less relevant early on when you can’t equip enough camp items to make a difference. Overall, I would prefer stronger items and fewer slots. I didn’t feel that I needed the level of control that the game gave me, and redoing my build was tedious.

Foreshadowing is important in single-player games, and Loop Hero does a great job of foreshadowing everything. Since players create the obstacles, they are very aware of what they will be facing. Progress bars provide clear reminders of how close the player is to facing the boss or reaching the next day, and the loop-based structure of the environment allows them to predict that the next loop will be similar in many ways to the last.

There is something powerful about loops in games. There is a great article about the roguelike game Unexplored that sums up why they work so well:

Interconnecting spaces are a good thing because they naturally bring you back to where you started, helping you to feel your character developing. When you return to familiar surroundings with a new item or weapon you tend to realize the difference between how you were before and how you are now, and get a handle on your hero’s journey.

Alex Wiltshire, How Unexplored generates great roguelike dungeons

In Loop Hero, each new turn around the map sees you facing the same challenges as before, but with new gear and new tiles to shake things up, providing a strong feeling of progression.

Overall, I found Loop Hero to be both rewarding and educational as an example of good game design. After beating the game and seeing almost all of the content, I don’t feel much of an urge to keep playing, but I am sure I will want to return if Four Corners releases any more content.