Spatial Delivery: New Cards in the Works

Recent changes to my boardgame design-in-progress "Spatial Delivery" seem to be working out. Last Thursday, over at Rainy Day Games, three kind people gave it a near-blind playtest. They had a good time (I was watching) and they "got" the game, making the right kind of plays and doing the right kind of thinking. Most of their feedback had to do with ways to make the game more accessible on the first play: quicker setup, better player aids, improvements to the rulebook, and so on. (I screwed up and brought a somewhat out-of-date rulebook, so I had to intercede occasionally to answer questions and make corrections.) The actual rules and gameplay went over well.

Given that, Helen and I decided that it's time to re-think the physical bits, with an eye toward first-time players. We may eventually rework the hex tiles, perhaps eliminating them in favor of an actual board; we're still discussing that. But the urgent priority is a new card deck.

Older versions of the game had very simple cards. Artwork aside, each card just had a color: red, yellow, green, or blue. But when I added the new Card Powers feature (see A Bit of Game Design), the cards became more complex. Each card now has one of nine different Card Powers, each of which can be used only at certain times in the game. Initially I'd hand-scribbled some rough icons for the various powers on my old cards, with explanations in the rulebook. That got us through our recent playtests; but the players always had trouble learning what the powers were and exactly when each one could be used.

So Helen and I are now brainstorming iconography and card layouts, trying to make the cards and their effects as easy to understand as possible.

In general I like to avoid text on cards if possible, because it makes international editions of a game more expensive to produce. But the various card powers are complex enough to need one to three sentences of explanation each. We want new players to be able to understand each power without having to constantly look them up in the rulebook. A separate player aid would be a reasonable compromise, but for our prototypes we've decided to put some text on each card, in addition to the iconography. If the game is ever published, the publisher can decide whether to keep the text or not: the icons are sufficient for players who are already familiar with the game.

We've decided to try a smaller card size, to reduce the area needed for the game on the table. While the card displays aren't the biggest offender, the game does take up a lot of table space so we're trying to minimize that without impacting ease of play.

Even though the cards are smaller, some elements of the card design still have to be reasonably large, because they must be visible from a couple of feet away when the card is lying face-up on the table. At the same time, compact iconography is needed along the left edge of each card (the "index column"), so that players can fan their hands and easily see what they've got. I was originally fixated on point symmetry, which would mean an index column along both sides; but that was taking up too much space. Helen broke my fixation by showing me that an asymmetrical design gave us enough room for a nice layout.

Here's a mockup of the new design. The actual size is a bit bigger than shown here, and of course the printed cards will have finer resolution. We've printed some proofs to be certain that the text will be readable.

The new card layout

Anybody got any suggestions for improvements?

A Bit of Game Design

It seems ages since I've spent any serious time on any of my own game designs. What with the day job (followed, after retirement, by the exigencies of moving to another state), the two expansions I helped design for Railways of the World, my musical activities, and the need to work hard on Solitaire Till Dawn, my own designs have been given short shrift for the past few years.

But I'm retired now, and we finished moving in a while back, so that's over with. Solitaire Till Dawn isn't done yet and is still getting most of my alert-and-working attention; but all work and no play makes Jack want to stay in bed instead of getting up in the morning. So I've given myself a few evenings and weekends off recently, and put some time in on one of my oldest and best designs.

I started work on Spatial Delivery in 2007, and it won the Game Design Contest at KublaCon in May 2008. At that time I thought it was pretty much done, but it wasn't. Experienced game designers know that you have to playtest a game a lot to discover its warts and inadequacies. Like a software product, a game design must be tested, evaluated, fixed, and refined many times before you can be sure it's done. (Just the other day I saw a major, successful game designer apologizing for a "bug" in one of his new games: he and his testers hadn't found it, but the people who bought the game did. He's working on a fix.)

In the years since that KublaCon, I've revisited Spatial Delivery a number of times. I've been aware of a number of flaws in the design, and searching for ways to fix them. I think I've made some solid progress. I hope to take the game out of the house and have some strangers play it in the next few weeks, after a bit more in-house polish and maybe the making of a revised card deck.

To reach this state I had to make a painful decision: I had to throw out the one really original mechanism in the design. That mechanism wasn't a completely awful idea and I may be able to use it in some other design; but it wasn't a good fit in Spatial Delivery. It had to do with how players acquired cards ("Goods") for delivery to worlds in outer space, and that phase of the game was plagued with a variety of problems. I can't count how many solutions I've looked at for that process; but I'm hoping my new design will stand up.

Without going into too much detail, there had been four different types of Goods (red, green, blue, yellow—they have thematic names and icons, but never mind that). No form of random and semi-random distribution or drafting was working: it was always too easy for a player to get screwed over by an unfortunate shuffle, and there was little challenge or interest in choosing which cards to draft. My nifty mechanism that let players challenge each other over card selections didn't make it any better. I had to throw out the whole notion of shuffling all the Goods cards together.

Instead, I separated them into decks by type, and I invented a bunch of "Card Powers" and gave one power to each card. So now you shuffle just the red Goods cards together in one deck, and the blues in another, and so on. When players draft cards, they can always see one face-up card in each color, and choose any one of them. That way, every player gets the color mix he wants. But the Card Powers come up randomly, because they're scattered evenly among the Goods types.

This gives the players more to think about, even while allowing them easy access to the colors they want. The Card Powers give them new options during the next phase of the game, when they play the cards they've drafted.

This opened the door to a good solution for another of the game's nagging problems: turn order. Turn order is fairly important; it's an advantage to be able to play before anyone else. That means that the turn order needs to change, every round. But the game only lasts for a small and odd number of rounds (too bad, but otherwise the game is too short or too long) so simply rotating the turn order every round isn't really fair. I solved this (I hope) by inventing a Card Power that affects the turn order for the next round. Players can now decide for themselves how important it is to go first rather than last, and do something about it if they're willing to pay the price by grabbing and playing a Turn Order card instead of a different one.

It's surprising how hard it can be to let go of an old design feature. Another change I made recently was to make it cheaper to travel longer distances as your spaceship goes to visit planets in outer space. Originally I felt that it was important to keep travel distances short; I can't even remember why. I had a somewhat cumbersome rule that allowed long-distance travel at a nearly-ruinous price. I've now realized that this was dumb. The price of travel is high enough anyway, and the incentive to make frequent stops is strong. The fancy rule wasn't needed and I threw it out. The game is now easier to understand and more interesting, because long-range travel is now easier to do when a player has good reason to do it.

There's a wonderful company called The Game Crafter that can print and ship single copies of games on demand. It allows new designers to self-publish pretty easily, and it can be a great way to manufacture just a few copies of a game under development. When they started out their offerings were fairly limited, but they've been expanding. I see that I could now self-publish Spatial Delivery there, if I ever decide that it's ready for that. I'd like to license the design to a real game publisher someday, but in the meantime The Game Crafter is a good solution for turning out a few copies for playtests and publisher submissions. I won't do this until the design is a lot more finalized, though, and I'll have to drum up a few bits of artwork that I can legally use for symbols and icons on the cards and such.

Code Name Rottweiler!

It's not much of a code name if everybody knows what it means, but I've taken to thinking of my expansion for RotW (the abbreviation of "Railways of the World") as "rottweiler". This comes purely from the letters; for the record, I see no particular parallels between the dog breed (or any dog breed!) and the game system. And I wouldn't have bothered mentioning it here, but I couldn't resist the hyper-dramatic "Code Name Rottweiler!" title for the post. Sounds like a bad spy movie!

I should make up for the preceding blather with some meaningful news, so here's the current status of... Code Name Rottweiler! (Okay, I'll stop now, I promise.)

I have a first cut at the map nearly complete. I just need to add starting cube counts to the towns and cities, and make sure it will print okay in black and white. (Why? See below.)

I have a first cut at the Railroad Ops cards designed. I still need to make the deck, either by laying out some mocked-up cards on the computer and printing them out, or by just scribbling on paper. Either way, I'll stick the EUS deck into card sleeves, then slip in the paper cards over the real ones. I've also finished the first cut at the Rail Baron cards. I have a good selection of Barons and (I hope) a good set of bonuses.

I'll need to tune a VP/income track for the game, but I can start with the one from the main game. I can use the modular scoring track boards that Helen made for our copy of the original Railroad Tycoon until I decide what tweaks I want to make. (If you play RRT on the big board and hate that scoring track, you can download Helen's modular scoring track from BoardGameGeek. Be sure to give her a thumb if you like it!)

Acting on a tip from an experienced developer, I discovered that I can print out a full-size board on a single sheet of paper at Kinko's, for just $0.75 per square foot! That comes to all of $6 for one copy, which is dirt cheap. I'd always looked at the color prices which are significantly higher, and I had never realized that black and white is so inexpensive. A RotW board doesn't need much color; what little it needs can be added in five minutes with a set of felt pens.

The bottom line: I plan to print my first board tomorrow and be doing my first solo playtests this weekend! That's an exciting thought.

JavaFX: Looking even better

I was surprised to get a quick response to my forum post, on a Sunday afternoon yet. The response contained a solution for my unresponsive-objects problem (see below), and almost completely fixed it. I've seen the symptom recur now just once or twice in a 90-minute session, and it never persisted for more than a minute. I suspect that these remaining minor glitches have a different cause, and quite possibly are just due to my system being busy doing something else for a moment.

My virtual gameboard is now actually usable, and I played a complete game of Hammer and Spike with it in just 90 minutes. I am very pleased.

I still have more work to do: adding features, cleaning up minor bugs, and finishing the documentation. But one of these days, hopefully soon, I will make it available for others to use.

JavaFX: Looking better, but...

I took vacation last week, and spent some of it working on my JavaFX virtual gameboard app (still inadequately named "Placer"). I've resolved some of the problems that were worrying me at the time of my last post: the exceptions are gone, the design and code are cleaner, the feature set and UI of the app itself have improved. I've figured out how it can be deployed, too, although unhappily it must use Java Web Start and requires the user to have a fast Internet connection (at every launch! Why won't Sun give us a better option?).

But my biggest problem remains unsolved. Sometimes, some of the objects in the window (cubes, banks, other clickable or draggable things) simply stop responding to mouse clicks for a while. This is mystifying because of the apparent inconsistency of the behavior. For example other objects in the same window remain perfectly responsive and well-behaved while the frozen ones continue to ignore the mouse. And a frozen object will often spontaneously unfreeze later on; but the period during which it remains frozen can be anywhere from a few seconds to many minutes. I have circumstantial evidence suggesting that a frozen object is more likely to unfreeze soon if I drag some other (and obviously more responsive) object over the frozen one; but this certainly does not always work, so it may be coincidence.

Until this issue is cleared up, the app is not viable. When objects freeze up like that, the app becomes effectively unusable. (It's okay if objects freeze up when you don't want to manipulate them. But you only notice that they're frozen when you do want to manipulate them, which means that your game is stopped until you can unfreeze the things you need to move.)

I've joined Sun's developer network, and posted in their JavaFX forum about my problem. And now I have yet another thing to wait for. I'm spending a lot of time sitting by my virtual phone these days, waiting to hear from game publishers, CD makers, and now helpful JavaFX gurus. It's getting old.

JavaFX FTW?

JavaFX is yet-another-scripting-language. It promises that you can quickly create Java applets and applications with fancy visual effects by writing simple little scripts instead of miserably complex Java code. Does it deliver?

I was sic'ed onto JavaFX at my day job, charged with whipping up some cool new UI mockups. I quickly became fascinated. You can accomplish a lot with a little, using JavaFX. But that's not enough; I need to find out whether it can create industrial-strength applications, and if so, whether the code is readable and maintainable, and whether the UI it produces runs quickly and is responsive to the user.

I won't go into my day-job's proprietary stuff here. But (just in order to learn, you understand) one of the first things I did was start building a virtual gameboard. It went so well and so quickly that I've kept working on the project at home on my own time.

What is a virtual gameboard? I wanted a tool to quickly prototype a new game idea on the computer, without having to spend time and money assembling physical pieces. I wanted to be able to play the game (by myself, as I always do with new game ideas), change the rules and pieces, then play again, with rapid turn-around time on the changes. I also wanted play to go at least as quick as it would with real materials. I called the tool "Placer" because it will let me place things on a virtual gameboard. (A lame name, but it doesn't need a better one at the moment.)

Placer lets you specify an image file for the gameboard, which it displays in a window. A tool-palette area is automatically provided to the left of the board. In the palette are templates: If you see a red cube in the palette, for example, you can click-and-drag on it. It will produce a copy of itself (another red cube) that gets dragged away under your mouse. You drop the copy (called a "token") anywhere you like on the board. The template stays put, in the palette, and can be used again and again to make more tokens. A template is therefore a sort of virtual, limitless pile of its particular kind of token.

Placer is configured from a text file, in which you can specify a wide variety of templates for the palette: squares and rectangles, circles and ovals, cubes, disks, and more. Each one can be given a color, so you can have (say) four templates for the cube supply of four different players: one template each in red, yellow, green, and blue.

Tokens on the board can be moved around as much as you like. They can also be rotated, and each has a little popup menu that lets you delete the token or get a little information about it.

There are a couple of fancier kinds of tokens. One is the Bank, which displays an amount of money. Click on it to make a withdrawal: a small text box appears, you type in the amount to withdraw, and the Bank creates a new Cash token under your mouse. The Cash token displays the amount of money that you withdrew, and you can drag the Cash off to wherever you want it to go. The Bank stays behind, now displaying the balance that remains after your withdrawal. If a game uses money, you can create a master bank for the game, and then give each player a bank of their own. When you drop a Cash token onto a Bank, the Cash disappears and its value is added to the Bank's balance, making it easy to transfer money among the players. (The image shows a $13 bill ready to be dropped onto the Red player's bank, which currently contains $42.)

So has it been all kittens and rainbows? Nope, it hasn't. As is always the case with Java or anything Java-related, layout (that is, getting everything to be in the right place) is a major pain. JavaFX features coordinate-system manipulations that you must use to get anything significant done; no doubt they are very powerful and carefully thought out, but it gets very difficult to keep it all straight in your head (and your code) when you're writing something complex. Event handling is a bit tricky, and seems not always to work as advertised: sometimes my tokens simply ignore clicks and drags, with no clue as to why. (I suspect the garbage collector, at the moment.) And then sometimes JavaFX just throws a huge exception, stopping my app cold. It seems to be because I've coded something wrong, but I don't (yet) understand why I can play half a game of Hammer and Spike before it suddenly decides it doesn't like me.

Another issue is deployment. Suppose I finish up Placer, and want you to use it: how do I give it to you, and how do you install it? JavaFX isn't really designed for building stand-alone apps. You're supposed to access JavaFX programs via the Internet: as browser applets, or mobile device apps. It does provide a way to use WebStart files to deliver a desktop app, but these may have Java sandbox problems, which would be a killer for Placer: it has to be able to read your config file and board art.

But we'll see. I'm not done playing with it yet!

Adventures in Prototyping

My game design blogging has a split personality; much of it goes here, but some also goes up at the Board Game Designers Forum. This weekend I made a more durable board for the Nameless Rail Game, and chronicled the effort in some detail in my journal there. I felt that the content was of more interest to hard-core designers than to the more general crowd that reads this site, but if you're interested, follow the link.

I made the board because a flat, stiff, foldable board is a lot easier to transport than the taped-together big sheets of paper I've been making for home use. Helen and I are about to head up to Oregon to visit family and attend GameStorm, where I hope to get more playtesting done.

And the beast may finally have a name. The new board is labeled Hammer and Spike, which may not be great but is not in use by any other games. It will serve until and unless I hear a distinctly better suggestion. My thanks to all those who suggested alternate names, but I have to live with Helen and she didn't like some of them, so Hammer and Spike it is.