Friday, October 17, 2008
Rails Across America
After another playtest this evening, with new components and scoring, I've decided the rail-game design is showing enough promise to make it more official. I've given it a name—Rails Across America—and begun a Game Journal for it here, at the Board Game Designers Forum. Further details about the game's rules and components will appear there. I'll post here also if and when any more "milestones" occur.
Labels:
design,
hammer and spike,
rail,
rails across america
Thursday, October 16, 2008
Wait, I Did That Already...
In my recent post I Wanna Design Railroad Tycoon! I expressed my desire to (a) build a rail game, and (b) build one where ownership or development of the junctions was a primary goal. I had the notion that (b) hadn't been done before, or at least not often.
The other day I had a penny-dropped moment: I have already designed such a game. It's Spatial Delivery, in which players build trade routes ("rails in space") to reach prime locations for trade stations.
So now I feel kind of stupid for characterizing the new design's goal in that way. Fortunately, I can add a little verbiage and perhaps make it plain why the new design really isn't Spatial Delivery warmed over.
In SD, players build routes, but once built the routes are held in common. There is no ownership of the routes, and no reward is given for building them, beyond the fact that the route-builder gets to build a station at the end of each new route. Players do own the stations they build, receive substantial rewards for building them, and may receive further rewards if other players use them.
But in the more traditional rail game I'm now trying to design, the rails will be owned by the players who build them. As in SD, there may be no immediate reward simply for building rail. But there will likely be rewards for building a given strategic route before other players can do so, because by doing so you can get some rewards from late-comers who want to share the route, and you can block others from using the route altogether. The race for connectivity, for expanding your network strategically, will be an integral part of the game. This isn't the case in SD, where connectivity isn't much of an issue (because if anybody can get from point A to point B, so can everybody else).
Another difference is that in SD, making deliveries gets you Victory Points. In the new design, I think that deliveries will get you cash, which you will then spend to build more rails and to build train stations. (I say I think because the design is still up in the air.) There's nothing new about this mechanism, of course; it's just different from SD.
Reiner Knizia was the first person who told me (at a seminar, not face-to-face) that the victory conditions have a huge effect on gameplay. It's a fairly obvious point, yet before that I was thinking in terms of coming up with a bunch of nifty mechanisms, and then just slapping a win condition onto the end of the rules. But of course, the goal of the game informs all of the players' decisions. In my rail game, I have a set of reasonable mechanisms that might contribute to a good game. But I won't be able to tell until I've tuned the scoring system correctly (or given it up as a bad job). I want connectivity to be important, but I also want the stations to be significant. I want the famous "multiple paths to victory", so that a player might win by building stations, or by building the best network, or by making the most money from deliveries. To do that will require some careful tuning and balancing.
And that's my next goal for this design: to come up with a reasonably well-tuned scoring system. If I can do that, I'll have a game. After that, it'll just be playtest, tune, and repeat until it's good enough.
Well, that's the plan, anyway. Nothing ever goes that smoothly!
Later: I tried a solo playtest of the latest rules (including scoring) this evening. It worked fairly well. The biggest problem may simply be the lack of anything very new or different from other rail games. It's a mix of familiar mechanisms, with nothing in it you haven't seen before. But while originality is nice, few games offer anything really new. I won't worry about it too much.
The other day I had a penny-dropped moment: I have already designed such a game. It's Spatial Delivery, in which players build trade routes ("rails in space") to reach prime locations for trade stations.
So now I feel kind of stupid for characterizing the new design's goal in that way. Fortunately, I can add a little verbiage and perhaps make it plain why the new design really isn't Spatial Delivery warmed over.
In SD, players build routes, but once built the routes are held in common. There is no ownership of the routes, and no reward is given for building them, beyond the fact that the route-builder gets to build a station at the end of each new route. Players do own the stations they build, receive substantial rewards for building them, and may receive further rewards if other players use them.
But in the more traditional rail game I'm now trying to design, the rails will be owned by the players who build them. As in SD, there may be no immediate reward simply for building rail. But there will likely be rewards for building a given strategic route before other players can do so, because by doing so you can get some rewards from late-comers who want to share the route, and you can block others from using the route altogether. The race for connectivity, for expanding your network strategically, will be an integral part of the game. This isn't the case in SD, where connectivity isn't much of an issue (because if anybody can get from point A to point B, so can everybody else).
Another difference is that in SD, making deliveries gets you Victory Points. In the new design, I think that deliveries will get you cash, which you will then spend to build more rails and to build train stations. (I say I think because the design is still up in the air.) There's nothing new about this mechanism, of course; it's just different from SD.
Reiner Knizia was the first person who told me (at a seminar, not face-to-face) that the victory conditions have a huge effect on gameplay. It's a fairly obvious point, yet before that I was thinking in terms of coming up with a bunch of nifty mechanisms, and then just slapping a win condition onto the end of the rules. But of course, the goal of the game informs all of the players' decisions. In my rail game, I have a set of reasonable mechanisms that might contribute to a good game. But I won't be able to tell until I've tuned the scoring system correctly (or given it up as a bad job). I want connectivity to be important, but I also want the stations to be significant. I want the famous "multiple paths to victory", so that a player might win by building stations, or by building the best network, or by making the most money from deliveries. To do that will require some careful tuning and balancing.
And that's my next goal for this design: to come up with a reasonably well-tuned scoring system. If I can do that, I'll have a game. After that, it'll just be playtest, tune, and repeat until it's good enough.
Well, that's the plan, anyway. Nothing ever goes that smoothly!
Later: I tried a solo playtest of the latest rules (including scoring) this evening. It worked fairly well. The biggest problem may simply be the lack of anything very new or different from other rail games. It's a mix of familiar mechanisms, with nothing in it you haven't seen before. But while originality is nice, few games offer anything really new. I won't worry about it too much.
Labels:
design,
hammer and spike,
rail,
rails across america
Tuesday, October 14, 2008
California Academy of Sciences
Helen and I visited the California Academy of Sciences in Golden Gate Park in San Francisco last weekend. This museum-and-research institution was founded over 150 years ago, and recently re-opened in new digs following its partial destruction in the 1989 Loma Prieta earthquake.
The new Academy is amazing. I don't know any better word to use to describe it. Check out the Web site (see link above) and see for yourself a little about what it's like—but you won't really understand until you can visit.
I could ramble on for pages. To avoid that, I'll just briefly describe the most amazing feature. This is the Rain Forest, contained inside a glass sphere 90 feet in diameter. The sphere contains maybe 10 feet of water at the bottom, in which hundreds of fish swim (and some of them are huge). From ground level, trees go up four stories, and are filled with birds and butterflies. Side exhibits include a bat cave (we watched a curator hand-feeding little bits of fruit to the hanging bats) and a large leaf-cutter ant farm. You enter at ground level, and follow a ramp that spirals up the inside of the dome. At each level there's something different to see: the fish, the plants, the birds, and the omnipresent butterflies that float around you. From the top, a glass elevator takes you down under the water for a close-up view of the underwater life. It is stunning; I think I could spend all day there, just in that one dome.
And there's more: the Morrison Planetarium (which we missed, for lack of time), the Steinhart Aquarium (still reigned over by the resident albino alligator), and even the roof which is covered with earth and planted with low-maintenance native groundcover.
Go, see it, it's wonderful. But don't drive there. We had an absolutely terrible time finding parking, and the traffic jams were horrific. Take BART to the city, then grab one of the buses that will take you straight to the Academy's door. Oh, and buy your tickets ahead of time on the Web, it will save you time getting in.
The new Academy is amazing. I don't know any better word to use to describe it. Check out the Web site (see link above) and see for yourself a little about what it's like—but you won't really understand until you can visit.
I could ramble on for pages. To avoid that, I'll just briefly describe the most amazing feature. This is the Rain Forest, contained inside a glass sphere 90 feet in diameter. The sphere contains maybe 10 feet of water at the bottom, in which hundreds of fish swim (and some of them are huge). From ground level, trees go up four stories, and are filled with birds and butterflies. Side exhibits include a bat cave (we watched a curator hand-feeding little bits of fruit to the hanging bats) and a large leaf-cutter ant farm. You enter at ground level, and follow a ramp that spirals up the inside of the dome. At each level there's something different to see: the fish, the plants, the birds, and the omnipresent butterflies that float around you. From the top, a glass elevator takes you down under the water for a close-up view of the underwater life. It is stunning; I think I could spend all day there, just in that one dome.
And there's more: the Morrison Planetarium (which we missed, for lack of time), the Steinhart Aquarium (still reigned over by the resident albino alligator), and even the roof which is covered with earth and planted with low-maintenance native groundcover.
Go, see it, it's wonderful. But don't drive there. We had an absolutely terrible time finding parking, and the traffic jams were horrific. Take BART to the city, then grab one of the buses that will take you straight to the Academy's door. Oh, and buy your tickets ahead of time on the Web, it will save you time getting in.
Sunday, October 5, 2008
I Wanna Design Railroad Tycoon!
It's my favorite game, is Railroad Tycoon. And I like most rail games in general. They offer a type of competitive problem that I particularly enjoy. Every design is different, but often you are competing with other players for real estate and scarce resources, while constrained by connectivity and budgeting. In Railroad Tycoon, the real estate is the rail you lay between cities, and the connection points to those cities. The scarce resources are the goods to be delivered. Laying rail costs money; to raise money you can issue shares or make deliveries to increase your income.
Games like this offer the player a rich matrix of decisions. With a limited number of actions to complete your goals, every action is a significant choice. You need to build as early as possible, to grab scarce real estate before someone else does. But you need money to do that. Make deliveries first, to raise money? Or issue shares to get instant money? But shares will cost you more money, and penalty points, later; and if you delay the deliveries, someone else may "steal" them from you. No wonder rail games are fascinating!
This isn't a new or original pattern. There are dozens, if not hundreds, of rail games. Many form easily-extensible systems: the 18XX series, Age of Steam and its many expansions, the crayon rail games. Rail games are easy to extend because once you have a good basic game, you can vary it with new maps and minor rule tweaks to keep it fresh.
So with all these excellent rail games already available, why would I want to design another? The real answer is that I like rail games, so I'd like to have the experience of designing one myself, hopefully a good one. But I could also reply that new rail games come out every year, and if they're good, they get bought and played. There's clearly room for a few more yet.
Of course, I can't design Railroad Tycoon. (As Helen told me: "You know it's been done, right?") So I needed a new idea. Seth Jaffee has a nice design called Reading Railroad, which has a new twist: he's melded a word game with a rail game. The result is much more rail game than word game; it's fresh and different and it works well. But I wasn't looking for anything quite that radical.
What I came up with is this. In most rail games, you compete for the connections between locations. The locations themselves are usually not owned or monopolized by the players. I decided to try a design in which the rail network is built as a means to the end of "owning" the junctions: you are building stations and switchyards. (I'd be surprised if this actually hasn't been done before; but I haven't seen it and it doesn't seem to be common.)
I followed my usual design procedure: did a lot of thinking, wrote it up on the computer, refined it until it looked good. Then I made a quick-and-dirty mockup and tried a solo game, pretending to be four players at once. As usual, the initial design didn't work very well. I took the lessons learned, rethought things for another couple of days, and came up with a different variation, and tried that one. And it was better, but still flawed... I'll spare you the details, but I'm still trying out different ideas. I may wander away from the original notion altogether; I've learned not to be too wedded to my original notions.
What surprises me, again and again, is how difficult it is to design a truly interesting, playable game. More than once I've started with a successful but complex game (someone else's, of course) and tried to trim it down into something similar but simpler. And every time, it's failed. Yesterday I played a Railroad Tycoon variant, designed by a fan of the game. It's pretty much the same rules as the base game, just a few variations for interest's sake, and (the main difference) a new map. And it was... lackluster. It worked, but money wasn't tight and there wasn't as much interaction between the players as there should have been. I don't want to damn the variant on the basis of one play; maybe the map was designed for more than the four players we had, for example. Still, either of the two official versions (the original Railroad Tycoon and the Rails of Europe expansion) offer much superior play experiences.
And there's my own design. I borrowed some notions from RRT, some from other rail games, added a notion of my own... as I said, there are bazillions of good rail games. How hard can it be to come up with another one?
Apparently it can be pretty tough. So far I'm not impressed with my own design. But... at least it's not a complete heap of trash. Used to be, all my new designs turned out to be steaming heaps. Lately they've been almost-playable, with a strong sense that there might be a real game lurking in there somewhere, if I can only find it. I guess I'm getting better at this game design stuff, but I clearly have a long way to go.
Labels:
design,
hammer and spike,
rail,
rails across america
Friday, October 3, 2008
Rick and the Beanstalk
It seems to be called a "space elevator" these days, but I prefer the term beanstalk. In the fairy tale Jack climbed a magic beanstalk up to the giant's castle in the sky, but there are serious people today who think we could build a stalk that would ascend all the way from the ground to geosynchronous orbit.
This would be tremendous. Space travel today is dangerous, inefficient and hideously expensive, because chemical rockets are the only way we have to get off of Earth. But a beanstalk would let us ride an elevator into orbit. Properly built, it could be much safer and orders of magnitude cheaper, pound for pound, to put payloads into space. (Well, it would be cheaper once you'd recovered the cost of building it. It won't be cheap.)
We don't have the technology for a beanstalk yet. But I just read an article that says we might have it soon, and that's incredibly exciting news. Here's the full article:
I did find the article a bit amusing at a couple of places.
"Indeed, if successfully built, the space elevator would be an unprecedented feat of human engineering."
...ya think? It's only a tower that's over 22,000 miles tall.
"It is thought that inertia ... will cause the cable to stay stretched taut..."
Well, yes. It is also thought that if you drop a heavy rock onto your bare toes, it will hurt. This isn't some new, untested theory. Isaac Newton would have understood the space elevator perfectly 300 years ago, had he thought of it. Certainly there are plenty of engineering problems to be solved. But the basics, while unintuitive to us ground-dwellers, are simple and certain. If you make a cable long and strong enough and put it in place: yes, it will stay stretched taut.
I'm not going to start celebrating yet, but some experts think there's a chance that I could see a beanstalk actually built, or at least begun, in my lifetime. I'll have to take care of myself, and hope I inherited the longevity of my mother's family, but hey--it could happen!
Wednesday, September 24, 2008
Email Grail
Warning: Lengthy rant ahead.
Yesterday I went through a dozen and a half email clients for Mac OS X, and found not one that met all my needs.
I used to use Eudora, and I was happy. But Eudora has become decrepit: it is unsupported, and unreliable on Mac OS X Leopard. (It even lost some mail once. I used Eudora for over a decade and never lost a byte, but under Leopard it can lose mail. Unacceptable!)
So a while back I switched to Apple Mail, and groused about it because I lost some of Eudora's niftier features. But it mostly does what I want, and has its own virtues including really excellent search capabilities, tied into Spotlight. But...
Apple Mail has some bizarre problem in talking to my ISP's SMTP server. It takes forever to send outgoing mail, and most of the time it fails. Other folks on the Web have reported similar troubles, but none of their suggestions have helped. In despair I have had to go hunting for yet another email client.
I found 17 candidates, and every one of them is lacking in some fashion. My requirements are fairly simple—or so I thought:
- Keep messages in individual files (this is a standard, RFC 822)
- Handle large amounts of mail and multiple accounts gracefully
- Good search capability
- Good filtering capability
- Supported product
There are three reasons I wanted one-file-per-message. First and foremost, I do not trust proprietary database formats. If the database gets damaged, I've lost everything. If the product stops working, I've lost everything. Yes, most of them have an export-to-standard-format ability, but I have to know that I'm about to lose everything before it actually happens, or else the capability is useless. Database storage is a deal-breaker for me.
Second, on rare occasions I need to actually edit received mail. (Usually this is because some misguided customer has sent me their credit card number, which is information I don't want and shouldn't have. I edit it out of the email immediately when that happens.) Mail should be stored in an editable format, even if the mail client itself doesn't overtly support such editing.
Third, monolithic mailbox files have to be backed up every time a message is added or deleted. This is inefficient and wastes space on my backup media.
During my research, I discovered several more requirements, stuff I'd been taking for granted:
- Rich text (aka HTML mail) - Maybe the world would be better without it, but my customers use it. A lot.
- Folder/subfolder organization for saved mail - Other paradigms exist, but I have tens of thousands of messages organized in folders, and I'm not about to reorganize them now.
- Import from Apple Mail - Right. Duh. Almost forgot about that detail.
- Decent spam filtering - I get about a thousand spams a day.
So how did all the candidates stack up? Here they are, each with their primary deal-breaker:
- Balzac - Can't organize in folders.
- Correo - Somebody's hobby. Too new, too feature-poor, too little support.
- Entourage - Database. (Also, Microsoft. Feh!)
- Eudora - Unsupported, crashy.
- GNUMail - Unsupported since early 2007; home Web site is offline. OS X info sketchy.
- GyazMail - No outgoing HTML mail. (Man, that was disappointing. This one looked good otherwise.)
- Magellan Pro - Unsupported since 2004.
- Mailsmith - Database, and no HTML mail.
- Mulberry - Poor spam filtering, poor import capabilities.
- Musashi - Old. Documentation is thin and in poor English.
- Nisus Email - Irritating UI: no built-in text editor, omnipresent floating window even in other apps.
- Odysseus - Supposed to be a Eudora clone, but it's still in beta.
- Opera Mail - Integrated with Web browser, feh.
- PowerMail - Database.
- SeaMonkey - Integrated with Web browser, feh.
- Thunderbird - Ah, Thunderbird...
I finally decided it would have to be Thunderbird. It's open source, vigorously supported, mature, and feature-rich. It keeps mail in mbox format like Eudora: not ideal for backups, but at least it's standard, editable, and recoverable. Its ability to import from Apple Mail was poor and clumsy, but the Web site explained how to do it and it works. (As of this writing, I've imported less than half my mail. It's a multi-step operation for each mail folder.)
Just when I was starting to relax, I hit a near-deal-breaker: Thunderbird has no ability to redirect mail! Redirecting is sending a piece of received mail on to another address, without altering the message body. Thunderbird only has forwarding, which does alter the message body. Redirection is crucial to our home business, where I receive customer purchase notifications and have them auto-redirected to Helen, who imports them into our customer database. Her importer relies on the format of the messages, which is why we need redirection and not just forwarding.
I was stunned. Every mail client I've ever used has had redirection. It never occurred to me that a mature, feature-rich product like Thunderbird would lack it!
Well, Thunderbird is extensible, and there are hundreds of extensions. After some searching, I found two that add a redirection capability. But one doesn't work well with recent Thunderbird releases, and neither allows redirection as a filtering action. It took me probably an hour to get all that figured out.
Finally I had to get Helen's attention (she wasn't pleased, she was busy with aggro of her own) and have her investigate her parser to see whether it could handle a forwarded purchase notification. And we dodged the bullet: her parser handles a Thunderbird-forwarded message just fine. Whew!
I think Thunderbird will work out. If I get really upset about some lack or other, I might be able to write an extension of my own to fix the problem. Hope I won't have to, though. Email ought to just work.
Monday, September 22, 2008
The Need for Speed
I fence foil, and I've been at it for several years now. Most people enjoy doing things they're good at, and often don't enjoy things they're bad at, and I'm usually no exception. But, but, but... I love fencing, and I'm not good at it. Oh, I'm not hopeless: I look pretty good during drill because I pay attention and practice hard at correct form and technique. But when it's time to actually fence, it's a different story.
Let me explain. There's no such thing as an unstoppable attack, nor an impenetrable defense. Any attack can be foiled (literally) with the right parry. The trick is to use the right move at the right time, and that's been my bête noir. You can't know what the right move is until you see what your opponent is doing, and that means you have to observe and react very quickly.
Recently I had a bout with a relative beginner. At one point she launched an attack. Since she expected me to parry, her attack included a circling movement intended to evade my parry. And I expected that, so I executed a viciously fast, perfectly precise parry-four-counter-four: a simple parry followed by a circular parry. The circular parry was to pick up her blade in case she succeeded in evading the first parry.
And it didn't work. She hit me, poink, right on target. While I was showing off with my fast, precise parries, she was still executing her circular attack, so wide and so slow that it went all the way around my fancy tight maneuvers, and hit me well after I was done.
Had I actually responded to her attack, I could have stopped her easily. There was plenty of time. But instead I just chose a defense I hoped would work, and it was completely wrong. Even with that slllloooooowwww attack, I was unable to respond appropriately.
So now I'm wishing I hadn't so thoroughly ignored my kids' video games all these years. Maybe my reflexes would be better if I'd had more practice! But I'm working on it--it's never too late to learn. Someday, I might even be good enough to handle a complete noob!
Subscribe to:
Posts (Atom)
