“Nobody is going to be using this stuff in 30 years.”

That’s what would tell ourselves every time we added wrote another one of these date/time bugs. Storage was still slightly precious, and it was slightly more work to do the right things, so we didn’t bother. I mean, what were the odds of any of that stuff still being in use thirty years later? We were writing code that kept track of which players owned which virtual items in which video games. Was anyone going to be playing those games that far in the future? And even if they were, will they care if the system was confused about when they got their items?

Well sometimes old software ends up getting used for some shiny new purpose. Turn that crank a few times, and the same code that was written to keep track of imaginary video game hats is used to keep track of when you bought your house. Or whether or not you’d been paid for your work. Or when your contract ended. Turns out people really do care about those things. Oops.

We should have known better. After all, we had just lived through “Y2K” and watched as a legion of retired COBOL programmers were called up to fix all the date-related bugs they wrote in the 1970s and 1980s. To say that we “watched” isn’t really accurate, though. I personally never met anybody who did that work. And when the clock ticked over on New Years Eve, it was a non-event. Nothing was broken that anyone can see. Maybe that was because the Y2K emergency repair effort was successful, or maybe it was because the whole thing was overblown to begin with. Either way nobody paid much attention and it had zero impact on my coding habits.

In a way it was all Gordon Moore’s fault. Before Moore’s Law crapped out in the 20s there was a constant churn of new tech disrupting old tech. Every five or ten years the whole stack would turn over and we’d replace all the old, buggy code-bases with brand new buggy code-bases. We were able to do that because every couple years we had twice as much CPU power, and RAM, and storage to play with, so we could actually take new approaches to things. What would have been impossibly slow in 2000 was standard practice in 2010. That was sure handy for us lazy programmers.

Once the computation gravy train ended so did the technology turnover. Upgrade cycles kept getting longer and eventually they took so long that they couldn’t be reasonably called “cycles” anymore. Tech that was supposed to have a short shelf life got picked back up and reused for all sorts of new things.

Computers were still getting cheaper, of course. It used to be that companies would spend a few billion on a chip fab and it would be obsolete a few years later. When the same fab can keep cranking out chips for a few decades, that investment gets spread out a lot more. The capabilities of the machines people were buying just weren’t improving like they used to. Next year’s code had to expect the same amount of horsepower as this year’s code.

I guess I share some of the blame too. Not for the shoddy code; that’s obviously all my fault. I mean blame for the fact that I have to be here to deal with it. My grand plan to go from being kinda rich to being really, really rich didn’t exactly work out. In hindsight that’s how real estate speculation usually goes. I just thought I was smarter than all those other people.

It sounded so good on paper. Obviously all the low-lying areas in Florida were doomed. Sure, there are some people still trying to save bits of Miami, but apart from those little islands only fish and alligators live down there now. So I figured I would buy a bunch of land further inland where sea level wasn’t expected to reach.  All the people from the coast would move inland and drive up the prices and I would make a killing. So I sank most of my money into a few thousand acres of prime farmland west of Orlando. It was pretty cheap too because nobody wanted to live in the middle of Florida when they could live near the ocean.

What I didn’t expect were the hurricanes. So many hurricanes. And the big ones were so big. After ten years of getting pounded by hurricanes most people decided they liked not having their house blow away more than they liked living in Florida, and they all moved further north. I think Hurricane Britney was the last straw. My property spent almost two years inside a federal disaster area and it wasn’t all that nice to begin with. I rented the land to a FEMA refugee camp for a while, and eventually ended up selling it all for pennies on the dollar. Easy come, easy go, I guess.

So now I’m sitting here digging through code I forgot about twenty years ago. Meanwhile most of my old game industry buddies are goofing around in their workshops trying to build robot butlers or flying cars. A couple of them are even getting ready to move to Mars. I’m supposed to be digging through code anyway. I guess I should get back to it.

At least I have my health. Gordon Moore and K. Erik Drexler didn’t come through for me, but Aubrey de Grey sure did. Maybe I’ll even still be around in 2106 when we get to do this all over again. Whee!

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.


  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.


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.


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.