Programmer Joe

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.

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:

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.

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.

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!

Another in my ongoing series of ideas I’ll probably never act on. Do whatever you like with this. If you actually make the game and it runs on Android, let me know. I’d love to try it out.

The High Concept

Play through a role-playing game adventure on your mobile phone while moving around your local park, hiking through the woods, or wandering the streets of your home town. Participate in simple quests solo, or play with friends. Or if you prefer, develop your own adventures and share them online for other people to play.

The Inspiration

In the 1980s and 90s there were a series of books called Fighting Fantasy that let players play through an RPG-like adventure without a gamemaster. Combine a mobile implementation of those books with geocaching and then let the users create all the actual content and you have GPS Quest.

The Technology

Building GPS Quest would be straightforward:

1. Develop a simple RPG engine with monsters, loot, stats, and leveling up. Leave as many hooks as possible for user-generated content to modify things. Combat will probably want to be turn-based. Write a mobile app to resolve combats in the system.  This is by far the hardest step. Probably do this with just one player for the first version.
2. Build a back end that can track a player’s RPG stats over time. Include a quest system that can unroll an adventure in front of the player as they move around the world. This would probably be waypoint-based so the user can look at the next place to go on a map on their phone.
3. Build quest creation tools that let a user (you) write new quests in the actual physical world.
4. Publish all this to the world.
5. Iterate until massively popular

There are many hundreds of features that could be added once the basic system is up and running. Some ideas include:

• Multiplayer. First for small parties of 2-5 people and them maybe for raids of 20-40 people.
• Audio for monsters, navigation,  and quests. You could download it all before starting the quest so it could play quickly.
• Custom art for quests. Might want to download this ahead of time too.
• A builder-maintained bestiary
• A builder-maintained loot catalog
• Tools to remap existing quests onto new locations
• Matchmaking tools to help players find each other
• The sci-fi, zombie, pirate, superhero, spy, vampire, giant robot, caveman, and not-at-all-fantasy-medieval versions of the same game. That last one is so some SCA people can feel comfortable playing your game.
• Leaderboards for quest builders, quest remappers, and players to give all of those people bragging rights.
• More simple geocaching features like buried treasure and traps that players can leave for each other.
• Ports to whichever platform you didn’t launch for in the first place.
• Trading systems, auction systems, crafting systems

What do you think? Would you play?