Foom – Devlog #4

It’s been three years since the last Foom Devlog (and since the last major revision to Foom). In that time I helped build and ship the HTC Vive and SteamVR, so I guess being distracted from this side project isn’t the end of the world.

Last week on JoCoCruiseCrazy 2017 I had the chance to playtest and revise the game again. This post will be about where it was before the cruise. The next post will be about the revisions I made as a result of the on-board playtests. Here are the cards I started out the cruise with.

Learning to play again

One of the big problems with taking three years off from your unpublished game is that if you don’t write down the rules, you can forget exactly what they are. That is exactly what happened to me. There was a major revision after devlog #3 and I didn’t write any of it down. I’m going to rectify that “didn’t write the rules down” problem going forward. In the meantime, here’s my attempt to record the rules I started out the cruise playing with.

Setup

  1. Shuffle the project deck and deal four projects face-up in the center of the table in the “in-progress projects” area. Players will work together to complete these projects and gain the power listed on the project.
  2. Each player takes a rule card and the matching worker deck for their color, along with a pile of worker cubes to match that color.
  3. Each player shuffles their deck and deals themselves 2 cards.
  4. Each player draws one Upgrade card from each phase. These are kept secret so the other player don’t know exactly what their competition is going for.
  5. Choose a player at random to start.

The unclaimed worker decks and rule cards won’t be used. Set them aside for the duration of the game.

Turn Order

Each player takes these steps and then play passes to the player on their left:

  1. Player takes a number of coins equal to their Income. This includes the income from their base rule card, any completed upgrades, and any projects owned by the player.
  2. Player draws a number of cards equal to their Draw. This includes the draw count from their base rule card, any completed upgrades, and any projects owned by the player.
  3. Play a number of workers from their hand up to the number specified by their Play. This includes the play count from their base rule card, any completed upgrades, and any projects owned by the player.
  4. Pay coins to activate any number of powers. This includes the three powers listed on the base rule card, powers on completed upgrades, and powers on any projects owned by the player. A single power can be used any number of times per turn.
  5. Discard down to the Hand limit as specified on their base rule card, upgrades, and owned projects.

Playing workers

Each worker card has an icon that indicates what kind of worker that card represents. Workers are played on projects to move that project closer to completion. When a player wants to play a worker on a project, they discard a worker card from their hand and put one of their worker cubes over a matching worker icon on any in-progress project. Worker cards with a question mark in a square are wild cards, and allow the player to place a worker cube on an open icon of any type.

When the last worker icon on a project is covered, that project is completed. The player with the most worker cubes on the project gains ownership of the project and access to any powers or stat bonuses on the project. If one or more players is tied for having the most cubes, the player who placed the last cube decides the owner among the tied players.

At the end of the player’s turn, replace any completed projects with new projects from the project deck.

Upgrades and Winning the Game

Each player has three upgrades to complete. A player immediate wins the game by finishing their third upgrade.

To complete an upgrade, the player needs to acquire projects to match the requirements listed on the upgrade card. When a player gains control of a project that satisfies an upgrade, they immediately complete that upgrade.

Problems encountered on the cruise

These rules worked pretty well, but they exposed a number of problems:

  • Players didn’t want to play on projects they weren’t likely to win. My first attempt to solve this was to give non-winning players one coin at project completion for each worker cube on the project. This helped, but wasn’t really enough. In the later playtest when I eliminated money, I tried “draw one card” for this, but that didn’t work well at all.
  • Player contributions to projects were too diffuse. My solution here was to reduce the number of projects to be the same as the number of players. (I had three players in each of the three playtests I managed to have on-board.) That definitely helped during the early game. It may be necessary to increase that number as the game progresses.
  • Four worker types was too many. Players often went through turns where they couldn’t play a worker because there were no matching open spots. I ran a test with all the gear workers removed from the worker decks, and gear icons on the project cards acting as wild spot that would accept any kind of worker. That seemed to help quite a bit, so I’m going to test more with that rule.
  • Once a player got ahead in upgrades it was hard to catch them. I tried to deal with this by giving any player who hadn’t already upgraded to that level some money, which helped but wasn’t quite enough.
  • Powers that remove cubes (and projects full of cubes) slow the game down. The whole point of escalating capabilities on projects with fixed costs is that the game is supposed to accelerate. The fix here is to change “remove cube” to “move cube to another project”, which means that progress is inexorable.
  • The last phase took way too long to finish. One game took almost two hours, and I’d like the game to be under an hour. I have some ideas here that I’ll test out in future versions.
  • A bunch of the powers were useless. And a bunch of others were stupidly over-powered. And because of the rules we were playing under they could be used multiple times in a turn. The powers definitely need a balance pass, but the bigger fix I want to do here is more fundamental. The third on-board playtest eliminated the money mechanic from the game entirely. This was a promising direction that I’m going to explore in the next revision. It was roughly:
    • Upgrades that gave extra income were converted to extra draws.
    • All upgrades and powers on projects where ignored
    • A new deck was added (by hand-modifying the purple worker deck) that contained powers.
    • These power cards were added to a player’s worker deck, which introduces something of a deck-building mechanic.
    • A player could play any power in their hand instead of a worker when they made a play.
  • It’s hard to tell what worker type is under a cube, and often powers require knowing that. This is probably going to drive a visual design change in future versions.

By the end of the cruise, the cards where covered with scribbles, which is a definite sign of progress being made. Now I just have to go back and turn all that feedback into a new card revision.

Foom – Devlog #3

Too Many Resources

The most obvious issue out of the most recent playtest is that 6 types of resources is far too many to keep track of. For each card the player wants to buy they have to calculate the differences of three different numbers. Then they add the results of each of those sums to their bitcoin number. If the card is Space or Medical and they have some of those resources they add whatever is left to the appropriate type. If the result of all that is negative the player can’t afford a card.

It’s just about possible to do all of that in your head, but it is error prone. It’s also quite a lot of work to do every time and wasn’t very fun. The resource tracks from V2 helped but weren’t nearly enough.

The first order of business was to reduce that load. That involved a few changes:

  • The Medical and Space resource types are gone. They were there as an attempt to encourage specialization in certain kinds of cards, but I’m going to try to handle that a different way.
  • When a bitcoin is acquired it becomes a type of resource of the player’s choice, but that choice is permanent.
  • There are no longer any resource conversion trades possible between the remaining three resource types.

Awkward Game Endings

Another significant issue was with the leveling up process in the game. The way it worked in V2 was that players bought the next level from one of four level stacks. The level stacks were themed and had a high cost and a large reward. The final card in each stack was “you win”, so whoever hit level 4 first won the game.

The only thing I didn’t like about this system was pretty much everything. Having four extra stacks of cards was strange when everything else in the game was in the main deck. The stacks themselves were themed poorly and two of them ended up being pretty broken. Only having three steps to victory also seemed to take away from the drama of the end of the game a bit. And it was tough to tell if a player could even buy a victory on their next turn because of the difficulty determining if anybody could buy anything that I mentioned above.

The fix here is to replace the level up cards with “Advance” cards that represent permanent upgrades to a player’s capabilities. These are in the main deck and are dealt with just like all the other cards. The other change that will hopefully help these issues is that now the rule is that a player wins when they are the first to hit 10 resources in two types. There is more work to do here, but I think these will be a step in the right direction.

Events

The approach to event cards I added in V2 worked well. It was a little awkward to have events come out in the initial draws and the events themselves need work, but I like the direction things are headed.

Attacks

Between V1 and V2 all of the Attack cards were removed from the deck.  These are added back in V3 with a twist: Attack cards now cause a permanent resource cost to the player doing the attacking (and probably to the player being attacked.) I think these will need a bunch of tuning, but I think they’ll also work better than the “steal a card” attacks of earlier versions of the game.

Here is the latest version of the game if you want to see all the changes. Now I just have to rope some people into playtesting.

Foom – Devlog #2

You may have noticed the biggest change: The game has been renamed from Hard Takeoff to Foom. In my head they were equally as good because they’re basically synonyms. Once I started saying them out loud, though it was clear that Hard Takeoff is a terrible name for a game. And Foom is tremendously fun to say, so Foom it is.

I played v1 for the first time yesterday and learned a few things:

  • Keeping track of all those resources is difficult. Each turn each player had to count up their total in six different resources. Then they did a bunch of additional calculation to figure out what they could buy.
  • When players stack up the cards they buy they eventually end up with a huge stack and the deck shrinks to almost nothing.
  • The attack cards in v1 were half-assed and kind of all identical.
  • Players were unable to form any kind of consistent strategy with the only thing that persisted between turns being the shared river. It quickly filled up with crap nobody wanted and stayed that way for the rest of the game.
  • There was no consistency between any of the cards’ cost and what you get out of them.

Preliminary balancing

I attacked that last issue first. I wrote another script to process the same card source data and produce a CSV file of the cost and production of each card. It uses some estimated values for the benefits to reduce all production to one number.

  • Bitcoin = 1.0
  • Eyes = 0.85
  • CPU/Hands = 0.75
  • Medical/Space = 0.50

I also generated a curve of what I wanted each level of production to cost. Because more expensive cards are so much more efficient in terms of player actions, I wanted them to be less efficient in terms of resources provided. The numbers I settled on were:

  • 3 cost -> 1 benefit
  • 7 cost -> 2 benefit
  • 12 cost -> 3 benefit
  • 18 cost -> 4 benefit

All of that turned into a spreadsheet:

Card count cost output target cost target output
Mesh Networks 1 5 1.5 5 1.5
Behavioral Surgery 1 8 2.25 8.25 2.2
Quantum Computing 1 8 2.25 8.25 2.2
Resurrect Ray’s Dad 1 4 1.5 5 1.25
Cure for Cancer 1 12 3 12 3
Augmented Reality Contacts 1 6 1.7 5.8 1.75

Target Cost is how much the specified output should cost according to the curves above. Target Output is how much output the specified cost should result in. Once I had this data to look at I went through and tweaked each card up or down in cost or benefit to even them all out. This eliminated a bunch of cases where there were two cards with the same cost and wildly varied benefit levels.

Other tweaks for V2

The rest of the tweaks I made based on the play test were pretty straightforward. I added a scoring track so player could keep track of their current level of each resource. Then because they didn’t need the cards anymore, the rules changed to discard each card after it was played and replenish the deck.

For the attack cards, I was biting off quite a bit already, so I just removed them from the game for now. They will almost certainly return in some form in a future version.

To help with the difficulty with forming a strategy, I gave each player a three-card hand that persisted. That way player could keep cards they wanted to save up for.

Something I felt was missing from V1 was a representation of the mood of the human population. This took the form of event cards that affect the costs and benefits of other cards and persist for several turns. There are a dozen or so events in the main deck now and whenever a player draws one of these they replace the current event and then draw another card before proceeding with their turn. Thanks to everybody on Twitter for suggestions on how to accomplish this random scheduling of events with much complexity.

I also wanted to represent more of the different strategies an AI could take more explicitly in the game. I did this by having four different upgrade sequences instead of four copies of one sequence. The four sequences help with one of four things: taking multiple actions, drawing multiple cards, effectiveness of space cards, and effectiveness of medical cards. The rule was that you could buy off any stack, but only if the top card was your level plus one.

You can find the new cards here. I’ve actually played a game with V2 as of this writing, but I think I’ll save the results of that test for the next devlog.

Hard Takeoff – Devlog #1

This weekend’s work on the game happened in three phases. First was some brainstorming about what resources might be involved and how those would be represented on cards. Then I tried to actually “play” two AIs against each other with some proto-rules and proto-cards. After that I had a much better idea what a playable game would be and codified the hand-written changes on the brainstormed cards onto the first thing that could actually be called a “game”.

Brainstorming and Bootstrapping

Something I’d forgotten about the first week or two of Calvinball is how hard it is to get a game off the ground when all you have is a vague idea.  Once you have a game that has rules and an end condition you can follow a pretty simple pattern to make it better:

  1. Trick or cajole  3-4 victims into playing with you.
  2. Play and tweak the most egregious problems as you go.
  3. Revise the game to account for the biggest of the problems you found on step 2
  4. Go to step 1

If your game is sufficiently horrible and stays that way for a long time you might run into problems with step 1, but as long as you’re willing to laugh at how far it has to go that’s not likely to be a problem.

The real problem comes with being able to do step 2. If you don’t have a game yet you are going to have a hard time learning anything from sitting down with other people. You’re just inviting some of your friends to brainstorm game ideas with you which may or may not be productive. This is the part of building a new game that I wanted to get through this weekend.

I started in Word. I wrote down half a dozen or so resources that I wanted players to manage in the game:

  • Brainpower or CPU – Controls the complexity of what players can do
  • Hands – Represents ability to take actions in the real world
  • Money – Represents financial capability in the economy

From there I came up with a quick design for cards that looked like this:

Then I printed a bunch of blank cards and started writing down singularity-inspired names that might be useful concepts in the game.

Playtest #0

The game still wasn’t playable at this point, but that didn’t stop me from trying. I went through the cards I’d scribbled on and starting writing down some rough stats on each one. It was during this process that I started to think it might be useful to have a state that represents the AI’s awareness of the world. So I started drawing little eyes on the cards and include that as one of the stats.

The resulting cards all looked something like this:

Then it was time to play.  The basic rules went something like:

  1. Three cards form a “river” that any player can purchase cards from
  2. Player draws cards equal to their total Eye rating.
  3. Player can do one of two things each turn:
    • Buy a card from their hand or the river
    • Put the card face-down in front of them. These cards can be “spent” on subsequent turns for a value of three bitcoins.
  4. To buy a card the player must have stats equal to all three (CPU, hand, and eye) requirements. If the player doesn’t meet a requirement they can spend bitcoin 1:1 to make up the difference. If they don’t have enough coin but have other stats to spare they can spend those stats 2:1 for whatever they need.
  5. At the end of each turn the player discards whatever is left in their hand.

This kinda worked. It didn’t have any kind of win condition, so the game went on until I felt like I had enough to make another revision.

Hard Takeoff V1

Here are the cards that resulted from that first sort-of playtest. Significant changes from the hand-scribbled cards include:

  • Bitcoin is no longer a “cost” on any card. It’s just used to make up the difference. I started out with a bunch of cards about renting machine time or hiring temp workers but abstracted all that away into exchanging one resource for another.
  • The AI cards come in a stack that lets you level up over time. The first player to hit level 5 wins.
  • The primary way to gain additional CPU is to level up. Most of the other ways seemed a little silly when I actually tried to play them.
  • There are three bitcoin symbols on the backs of the cards to indicate that they count as temporary bitcoin when played that way.
  • All the numbers on the resource counts turned into icons.

The PDF is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives license. Feel free to download it and give it a try.  I haven’t actually tried to play it myself yet, so I make no guarantees about fun.

Hard Takeoff – Devlog #0

About a year ago I started working on a board game (code named “Calvinball” because at first I changed the rules often during the game.) That was an interesting process to go through and one I enjoyed. For the past couple of months I’ve had a new game bouncing around in my head that I’m going to try to make real. This time around I thought I would try to document the process a bit more.

This is the first in what will hopefully become a series of posts on Hard Takeoff, which is the working title for the new game. So far all I have are some vague ideas rattling around in my head:

  • Each player in the game plays a roughly human-equivalent AI.
  • A player wins the game by being the first AI to acquire the resources required to trigger an intelligence explosion.
  • Each player has a slightly different set of requirements to trigger that explosion. Each player also starts with a slightly different set of resources and abilities.
  • The game is about accumulating resources and capabilities as quickly as possible without being so obvious that the pesky humans take notice and try to stop the player.
  • The AIs in question are self-interested, but don’t particularly hate humans. At worst they are indifferent to the goals of humans. (That means they’re more like ELOPe than Skynet.)

In addition to these thematic and gameplay goals, there are also a couple of more practical limitations I’m going to try to impose on the game:

  • The game should be easily portable. I’m going to try to build it with only cards and no other pieces.
  • Game sessions should take about an hour.
  • This should not be a worker placement game because that’s what Calvinball is and I want to try something different.

And with that I’m going to go prototype some cards.  Here goes!