Results tagged “game design” from The Gameshelf
The only thing worse than a flawed expansion to a good tabletop game is listening to some know-it-all groan about it. Complaints about expansions, after all, suggest their own unbeatable counterargument: So, don’t play with the expansions, then! It’s not like eschewing an expansion makes the basic vanilla game suddenly stop working, right? Perhaps we don’t enjoy Knightmare Chess, but we don’t therefore conclude that the original game is forever spoiled.
So, in an attempt to turn such grumbling into an essay worth reading, let me turn it around: I hereby declare that it is not just desirable but possible to design an expansion set for a good game in such a way that actually improves the game as a whole, rather than simply making it larger. So this fact makes it that much more disappointing when a solid game releases an expansion that adds stuff, but fails to add an equal-or-greater amount of fun. Fair enough?
As it happens, I can find one example of each between two often-compared games of recent vintage. Dominion (Donald X. Vaccarino) and Race for the Galaxy (Tom Lehmann) are both quick-playing card games that have earned tremendous cachet from tabletop gamers in the last two or three years. (The Gameshelf has itself ruminated about both games, via Kevin and Zarf, respectively.) Both proved successful enough to spawn several expansions apiece; Race got its third such set into print earlier this year, and Dominion — despite being a slightly younger game — will see its fourth in stores by the holidays.
Let’s look at Race for the Galaxy’s general expansion philosophy. What comes in each of its little boxes?
Jon Blow, author of the hit indie videogame Braid, gave a talk about game design in January 2010. The talk is short, about 20 minutes, but the Q&A that followed was about an hour, and I found it to be even more interesting than the talk. In particular, he answered a question about the stars in Braid, which is a part of the game that he is usually silent about. So I thought it was worth excerpting the question and his answer (about 9 minutes total). But, if you have time to listen to the full talk and Q&A, it's got other interesting stuff too. (He initially blows off the question and takes another question, which I edited out; that question, by the way, was about Wulfram, a team-based first-person tank shooter game with some pretty cool strategic elements that he co-wrote in the mid-90s.)
Wadjet Eye Games is giving away its game The Shivah (normally $5) in honor of Yom Kippur:
his weekend is the Jewish holiday of Yom Kippur! It's a special time of year when Jewish folk reflect on the past year. So, on reflection, we're giving away The Shviah for free.From now until Tuesday, simply use the coupon code "FreeShivah" when purchasing and you can nab the game absolutely free of charge.
Greg Costikyan posted his talk from Austin GDC about randomness in games. Definitely worth checking out.
Nick Montfort posted his updated list of interactive fiction suggestions, games he suggests for people who have some interest in IF but who haven't played much.
Ian Schreiber posted his last blog entry for the Game Design Concepts course today. My Russia trip followed by actually working derailed my plans to work along with the whole course, but I plan to go back and finish it some time soon. And you can too! He's leaving the course up, and there is a lot of valuable information in the 20 posts. In his last post, he says that he plans to do a class with a similar structure next summer, but this time on game balance.
I just won my second free game from Out of the Box. They have a contest in each monthly newsletter (you can have it emailed to you or you can grab it from their website), where you usually have to solve some kind of puzzle associated with a game. They have 25 winners each month, either the 25 best answers or randomly selected from all the correct answers. I won a copy of Letter Roll a few months ago, and I was just informed that I won a copy of Super Circle Stacking. I'm not sure how fun either game is yet, but, hey, free games!
I'm not necessarily planning on doing a post for every lesson (twice a week for ten weeks), but I thought I'd post today since I made two games.
Today's lesson talked about what game design is, the iterative process, and the benefits of paper prototyping. The readings were the second chapter in Ian and Brenda's book and an article by Doug Church.
At the end of Chapter 2 of the book are five challenges. The first challenge is basically the same as the challenge from Monday, so I decided not to repeat that. Challenge 2 is to make a territorial acquisition game, and Challenge 3 is to make an exploration game. I did both of those, and I'll present them next. Challenge 4 is to make a game with the mechanic of picking up things by passing over them, like you would in many video games. I have the germ of an idea, but I want to think about it a bit more, since this is a bit tougher than the previous challenges. Challenge 5 is an "Iron Designer Challenge", similar to Iron Chef, where two teams are supposed to work on the same design. I may or may not get to this, as it is fairly specific (make a game about a Civil War battle without using territorial acquisition or destruction of the enemy as the primary mechanic), and I think this kind of specificity would make the resulting game interesting only if there were others to compare it to. Of course, there are 1400 people taking this course, so I may end up doing it.
Now, on to the games I made today. I welcome any feedback on the games.
The first game is a territorial acquisition game. I couldn't come up with a good name, so I'm just calling it Outgrow.
(Pictured above: The endgame of Outgrow. The four players were blue/purple, green/yellow, red/orange, and white/clear.)
Game: Outgrow
Players: Two to four
Theme: Each player represents a fungal colony, trying to outgrow the other colonies in the limited space available.
Materials: chess board, two Icehouse stashes for each player (10 each of small, medium, and large pieces)
Setup: Each player places a medium piece from his stash in a corner of the chess board. Randomly determine the first player.
Gameplay: A player may make one action per turn. There are four allowable actions:
- Grow a small piece into a medium piece.
- Grow a medium piece into a large piece.
- Make a medium piece spawn. Place two small pieces orthogonally adjacent to the medium piece, then replace the medium piece with a small piece (if you run out of small pieces, use a medium on its side to represent a small).
- Shoot off a spore from a large piece. Place a small piece up to three spaces away from the large piece in a straight line, either orthogonally or diagonally, then replace the large piece with a medium piece.
Game end and winning: The game ends when there are no more empty spaces on the chess board. The winner is the player occupying the most squares. If there is a tie, then the winner is the tied player who has the larger pip count (small = 1, medium = 2, large = 3). If there is still a tie, then the winner is the tied player who had the fewest number of turns.
Analysis:I played one test game with four sides, and the final scores ended at 17, 17, 16, and 14, with one of the 17s having a medium while the other one had all smalls. Interestingly, the tied players started out by spawning their medium, and the other players started out by growing the medium to a large.
The next game is an exploration game. I've been interested in games that use a tarot deck where each major arcana has a different special ability (and this is now the second time that I'm mentioning that I intend to post about that here at some point, and maybe this will actually inspire me to do so), so I decided to make this game with a tarot deck. I didn't manage to get a special ability for each major arcana, but I think I got a decent selection of abilities. I may come back to this game idea and flesh out more powers (feel free to suggest some!).
Game: Tarot Dungeon (I couldn't come up with a decent name for this game, either)
Players: Two to four
Theme: Each player is a representative of one of four major powers who are working together to explore a dungeon and loot its treasure. Of course, each player has received secret instructions to get out first and seal the rest of the players inside.
Materials: tarot deck (can use a regular deck plus counters in seven different colors)
Setup: Separate the tarot deck into the major arcana and the minor arcana. Shuffle them separately. Put the minor deck in the middle of the table and set the major deck off to the side. Each player should choose a different suit (cups, disks, wands, swords, or whatever your deck uses). Randomly determine the starting player.
Gameplay: There are two phases to the game, going into the dungeon and leaving the dungeon. In the first phase, the starting player flips over the top card of the minor deck. If it matches his suit, he sets it in front of him and draws the top card from the major deck (he's found a treasure!); otherwise, he puts the card in the discard pile. Play continues clockwise until the minor deck is exhausted. (In the unlikely event that the major deck is exhausted, then play continues as normal, but new treasures are not drawn.)
This is the end of the first phase. All of the treasure has been found, and so players must race to the exit.
The first player of the second phase is the player with the least number of treasures. If there is the tie, then the first player is the tied player who went closest to last in the first phase. Reshuffle the minor discards (but not the ones that the players have kept) to form a new minor draw deck. The first player flips over the top card of the minor deck. If it matches his suit, he keeps it (separate from the cards drawn in the first phase); otherwise, he discards it. Play continues clockwise.
Game end and winning: The game ends when one player has collected five cards in the second phase. That player is the first to escape the dungeon, and he triggers a collapse, sealing the other players in the dungeon.
Treasures: Each treasure has a special ability. On a player's turn after he has flipped over a card (or sometimes before; see the list of abilities), that player may discard a single treasure card in order to activate its special ability. Once the active player has played a treasure card or passed on the opportunity to do so, each player in turn order has the option of playing a treasure card or passing. This continues until every player has passed in turn (i.e., there have been four passes in a row). A player may play more than one treasure card (assuming he plays one, then someone else plays one), and a player may pass but play a treasure card later in the round (assuming someone else plays a treasure card).
There are seven abilities, as follows:
- Flip 2 - The player flips two cards instead of one. This is played before flipping. (Assign to major arcana 0-3.)
- Denial - This is played when the active player flips a card that matches the active player's suit. That card is discarded. (Assign to major arcana 4-6.)
- Leavings - This is played when the active player flips a card that matches your suit. You get that card. (Assign to major arcana 7-9.)
- Counter - Nullifies the effect of the last-played treasure card. Note that a counter can be countered, which would let the original treasure card stand. Also note that Flip 2 can be countered (you go around playing or passing after a Flip 2 just as you would after a card is flipped). (Assign to major arcana 10-12.)
- Double - If the card flipped is the same suit as the last card flipped, take the card that was just flipped. (Assign to major arcana 13-15.)
- Weak Force - Take a card that you just flipped, even if it does not match your suit. (Assign to major arcana 16-18.)
- Strong Force - Instead of flipping a card, simply take the top card. This may not be countered (but you might end up taking a card of your suit, thus wasting this treasure). (Assign to major arcana 19-21.)
Analysis: The idea is that the player with the most treasures will be bogged down the most, so they will be slower in getting out. For the second phase, in the minor deck, there will be the most cards matching the suit of the player with the fewest treasures. So theoretically, that player's lack of power will be balanced by their being more likely to flip a card that matches their suit. In the two test games that I played with four sides, one game was won by the player with the most treasures, and one game was won by the player with the fewest treasures. It's unclear whether the players in the middle are at a disadvantage.
Ian Schreiber has started his free online game design course. The first post discussed what a game is, then he asked people to actually make a game (using Brenda Brathwaite's "The Easiest Game Design Exercise Ever (Really)"). When I read Brenda's post, I didn't end up making a game, but signing up for this class made me actually make a game. It took about 15 minutes (which included doing a little Wikipedia research). It's not a good game, but it's a game. The point of the exercise is simply to get people over the hump of actually making their first game. The homework (or "homeplay" as Ian calls it) is to read the first chapter of his and Brenda's book, read Greg Costikyan's I Have No Words & I Must Design, and play the series Understanding Games, which was all interesting reading/playing.
And now I will share my little game with you. We were just supposed to draw a path and make a simple race-to-the-end game. I decided on a jagged path, which made me decide to do a game about lightning. I did a bit of Wikipedia research, but I mostly didn't use it (although I might in a future game). Here is a poor picture of the game, which I drew with pencil in a notebook:
Here's the text, which is probably too hard to read at this size:
LIGHTNING!The two-player version is very heavily slanted towards the first player, but the four-player version seems to be a little more balanced. Like I said above, it's not a good game, but it's a game. I'm definitely looking forward to keeping up with this class.Each player is a negative charge, starting in the cloud.
Each turn, roll two six-sided dice. Pick one of the dice and move that many spaces.
If you land on a lightning bolt, send an opponent back three spaces. Being sent back to a lightning bolt does not trigger it.
The first player to the last space hits the church steeple and wins.
Ian Schreiber is doing a free online game design course this summer. It's open to everyone, and you can either just follow along on the blog or actually sign up and get some additional material by email. He doesn't specifically mention the title in his post, but I'm sure the book he's using is the one he wrote recently with Brenda Brathwaite, Challenges for Game Designers: Non-Digital Exercises for Video Game Designers.
So, if you've played many games and want to get an idea of what goes into designing them, check out the blog or sign up for the course.
This week's topic of "hey, look at that" among IF fans is Legends of Zork -- a browser-based "casual MMO" being developed by Jolt. (Licensed from Activision, of course. For those of you who missed the 90s, Activision owns all the old Infocom titles; it was Activision who published the three Zork graphical adventures after Infocom dissolved.)
The Great Underground Empire has recently fallen and the land is in disarray. The Royal Treasury has been sacked. The stock market has collapsed, leading even mighty FrobozzCo International to fire employees from throughout its subsidiaries. A craze of treasure-hunting has swept through the remnants of the Great Underground Empire. The New Zork Times reports that trolls, kobolds and other dangerous creatures are venturing far from their lairs. Adventurers and monsters are increasingly coming into conflict over areas rich with loot. It's a dangerous time to be a newly-unemployed traveling salesman, but it's also a great time to try a bit of adventuring.
(-- from Jolt's press release.)
A lot of people -- both active IF fans and long-ago IF fans who remember Zork fondly -- immediately started talking about this LoZ thing as "multiplayer IF", as a game that would be "like Zork" in some sense.
Yeah, no. Let's look at the first post on the official LoZ blog:
Gain experience and wealth as you battle creatures, dodge traps and solve puzzles. The game is designed to be played at your own pace, so you can log in and do some exploring whenever you feel like it. Achieve fame by challenging other players in the arena or form a group to take on some of the more difficult quests.
The card game Double Fanucci also makes an appearance, in the form of a full deck of 174 Fanucci cards that you can collect and use to improve your skills. [...]
(-- from the Legends of Zork blog.)
Experience points, money, combat, skills, buffs. This is an online CRPG. That's what they're announcing, that's what it is. I immediately said "Oh, Kingdom of Loathing with Zork monsters," and I wasn't the first one to say it, either.
So that's fine; I played a lot of KoL for a year or two. The question which I wish to tromp on today is, what kind of CRPG should a Zork CRPG be?
I am, of course, being arrogant and probably irrelevant here. LoZ is in beta-testing now; Jolt has done their design work. It's too late for me to be making suggestions, even if they had a mind to pay attention to suggestions from random IF amateurs out on the Web.
But it's such a cool question.
The default CRPG used to be rat-clubbing for gold pieces; you could be a fighter, a cleric, a mage, or a thief. That's what "CRPG" meant. D&D did it, so Ultima did it and Wizardry did it. Then there were variations (you need bards for the Bard's Tale) but that was the setup.
(Kids these days will tell you that the classes are tank, damage-dealer, buffer, healer, and controller... or something like that... I'm not a kid these days, so I'll leave it to them to explain.)
It's hard to argue that the Zork tradition is unrelated to the fighter-cleric-mage-thief quadrangle. I wrote a whole post about Gary Gygax and his fundamental interconnectedness to all things, including Colossal Cave and Zork.
But D&D style combat has never meshed well with IF. Zork 1 starts off with a swordfight, straight-up dice rolling and hit points -- and then that mechanic essentially vanishes from the Infocom tradition for seven years. The other combat in Zork 1 is so heavily plot-biased that it's essentially a deterministic puzzle: nearly impossible if you plunge straight into it, but easily winnable at the right place and time.
And that's how Infocom set up their subsequent games -- up until Beyond Zork, which had several interludes of typical RPG combat. I, like nearly everybody, "solved" those scenes by saving and restoring the game. It wasn't fun, it wasn't immersive, and it didn't fit in with the rest of the game. I don't think I'm far off the concensus if I say that those elements of BZ were a failed experiment.
So am I saying that a Zork CRPG should eschew combat entirely? Heck no. There are plenty of battles in Infocom games. You defeat enemies. But they're not D&D, CRPG, wear-down-stat-X-using-stat-Y battles. (I have another whole design screed about a combatless RPG, but I feel like I should implement it rather than blogging about it... maybe next year.)
But yet, we're talking about a CRPG here! I'd love to go off and say "Jolt should have implemented true multiplayer narrative IF," but they didn't -- as far as they've announced.
Let's stipulate that the design problem is "a CRPG with the flavor of Zork". We will have stats, treasure, and skills. The game will be about burning time on repetitive actions that crank up some numbers until you can succeed at tougher actions.
But -- it doesn't have to be arranged the same way as Ultima 1 and Wizardry. I want to see how far I can break down the traditional concepts.
Treasure. When you win fights, you get treasure. Treasure buys stuff. Okay, that's good. But what is treasure? Nearly all games have currency -- a simple scalar of how rich you are. D&D had gold pieces (and a table of other coins, roundly ignored). CRPGs followed suit, although some call them "credits" or "meat".
Zork doesn't have money. Treasure, yes. Coins, sure. Barter, sometimes. Money, no. You collect and use items, distinct and distinctive. (Even the stack of zorkmid bills is a unique item -- you never cash it in for face value.)
What if we built our hypothetical Zork game (let me stress that I'm not talking about Legends of Zork here, I'm making stuff up) on a "monetary" basis of unique treasures? We could randomly generate their names and descriptions -- that's not hard. Succeed in a quest, find an antique Dwarvish black opal. Do it again, discover a handful of silver-inlaid knucklebones. Or a rare blue faience brooch. These don't auto-convert into gold; they retain their identity.
The point is to trade these in for useful tools and items -- I'm not throwing that idea away. So there will still be an underlying monetary value. Maybe it'll say "...rank-3 treasure" on the back of the brooch. But you would still have the experience of finding something, something new and interesting. (Even if it's really generated from a template algorithm.) The game designers could throw new adjectives and templates into the database occasionally. Find a treasure that takes your fancy? Don't sell it -- put it in your trophy case to display!
And you can open a market for players to swap for treasures they want.
There are design consequences, of course. You can't pile up treasures as a reward, the way you can with gold pieces. Eighty treasures are not eighty times as cool as one; they blur together and spoil the point. So rewards become much more granular -- you might get one or two per hour. That affects the rhythm of buying (or bartering) tools for further play. That affects the way you design those tools, and the challenges that the tools resolve.
Doesn't this start to sound more interesting than yet another Wizardry knockoff?
Algorithmically generating instances of things is a good trick. Let's run with it. How about locations? Kingdom of Loathing has lots of locations, but you visit each one over and over again, and the descriptions never change. (Well, rarely.) Let's set up our game so that you enter the forest, and find a unique, freshly-generated forest clearing.
(Again, the template and random-table work for this is pretty easy. You aren't trying to fool the player into thinking that there's a human being writing this stuff. It just has to read well. As long as the game doesn't lead you past a hundred of them in quick succession, players will buy into the descriptions. My own experiments with this tool are in Hunter in Darkness, and the cave section of my web site.)
If you explore out from the clearing, you find more forest locations. New room names, new descriptions. These are just "instances", in the usual MMO sense -- but you're going to visit them frequently, first to "solve" a location, and then passing through to more distant ones. You'll remember the descriptions; they'll feel like a real environment. And if you can invite other players into your instances, they'll find your part of the forest to be different from theirs.
(Maybe draw all this out on the traditional IF box-and-line grid... Oh, I'm not against graphics here. But if you have a generic forest illustration that appears above varying textual descriptions, I guarantee that the players will read and be interested in the text.) (If you can procedurally generate interesting forest illustrations too, you're really in clover...)
I did promise to get back around to combat. The burning-stats-against-enemy-stats model is a rich and well-explored mechanic, and I'm not going to try to discard it. (Today...) But who says that a "combat" must be a blow-by-blow struggle against a monster?
The fundamental act of Zork is exploration. What if the basic quest of our Zork CRPG was exploring a dungeon? (Or forest copse, or temple...) An "attack" would be the entire act of entering a room and facing its challenge -- by stealth, or trickery, or courage, or willpower. You'd still find monsters in the dungeon -- but the rhythm of the game would not be fighting blow-by-blow-by-blow, but rather exploring trap-by-monster-by-maze.
Of course you'd have to have a rich set of "combat" (exploration) mechanics. You'd have options on each move; you'd have tools and resources to use up. Ink and map parchment? Bread crumbs? Arrows? (I smell a Wumpus...) Maybe willpower and courage and steath and cunning are your solvent stats, expended against the dungeon -- just as the traditional CRPG hero expends his hit points frugally, trying to reach the orc's last hit point before the orc reaches his. Reach the end of the dungeon, and you find a treasure.
Ooh, treasures! They come in lots of varieties, right? (Since we're randomly generating them.) So they can have properties. There's the depth we want for the exploration "combat". Treasures can bribe monsters, treasures can jam traps, treasures can be left behind to mark your path through a maze. (Very Zork, that idea.) I know, I said treasures would be rare -- but you're bartering some of them for tools, and tools can be randomly generated too. Ropes, spikes, torches. Oil and batteries, food and water, all usable as "hit points" against the dungeon.
Clues! Use up clues to solve puzzles. I'm not talking about actual IF-style puzzles. Tell the player "There is a mysterious altar here, covered with Gnomic runes." To pass, he has to expend some of the Gnomic lore or rune lore in his inventory. Instead of healing potions, you find more lore. Instead of strength potions, you find a book of Gnomish history, which enables you to understand all Gnomish puzzles better...
You see where I'm going? Starting to go? Sketching a path in the direction of going? It isn't Zork-the-text-adventure -- as stipulated. But it tells the same kind of story.
EDIT-ADD:
I see I completely forgot to talk about character classes, you know, the fighter and the mage...
Well, I don't know if I want them, in the traditional sense. The adventure-game experience rather assumes that you, the adventurer, go everywhere and do everything. You cast the spells and defeat the monsters and solve the puzzles. Then you go back and find all the alternate solutions too.
But there are different approaches, and maybe specialization is okay. (Sneaking, courage, etc, etc.) Or maybe those specialties should be per adventure? That might be fun. Gear up as a thief and go after that dungeon -- but if you're defeated by a surfeit of mazes, you'd try again from the riddle-master's point of view. Or the warrior hero, for monsters. "Healer" is not a concept that makes sense, given the model, but there just might be room for the dungeon master to make a few key changes for his own benefit...
Another in our series of game design documents. Jeff Howard, author of Quests: Design, Theory, and History in Games and Narratives (standard disclaimer: this book was published by the company I work for, and I acquired it, but I have no direct financial stake in the book), recently started blogging on the topics associated with his book. He just posted a game design document for a game that he's going to start building, called Arcana Manor, a "3D, first-person action-adventure/platforming game about leaping, swinging, and crawling through a surreal funhouse while battling demons." You can also check out his post where he talks about his initial idea for the game, and I find it interesting to see the modifications and refinements that take place just in the two weeks between the posts. I'm particularly interested in the fact that he's going to use tarot symbolism, with the possibility of wandering through rooms based on the major arcana. (I've had this minor fascination with card games that use a tarot deck where each major arcana has a different ability, and I've been meaning to post here about that.)
Another in our series of historic game development trivia! (This is completely coincidental, stuff just keeps popping up.)
Tim Schafer at Double Fine has posted the puzzle design spec for his classic adventure game, Grim Fandango. It is that game's tenth anniversary; it was released on the Day of the Dead, 1998.
Read the Grim Fandango document (2.4 meg PDF).
This document is a first draft, dated April 30, 1996. It has lots of puzzles which didn't make it into the final game. Schafer also notes:
We didn’t have the last puzzle designed when I wrote that document, so I wrote two nonsense paragraphs and then overlapped them in the file so it would look like the final puzzle description was in there, but obscured by a print formatting error. That way I could turn the document in by the deadline.
Bonus: Grim Fandango cake.
EDIT-ADD (11/13): Schafer has taken down his blog post and the document, with no direct comment, but a very indirect hint that it wasn't his to post. Since we at the Gameshelf believe in historic preservation, I have put a copy on our own web site. So the link above works again.
Disclaimer:I am an editor at A K Peters, the publisher of this book. Sales of this book help my company; thus, I benefit from the sale of this book. However, I don't get any kind of commission or bonus based on sales of this book, so the benefit is not a direct one. Besides being an employee of the company, I also worked on this book, so I am not necessarily unbiased about it.
A K Peters is publishing a book called Creating Games: Mechanics, Content, and Technology by Morgan McGuire and Odest Chadwicke Jenkins. From the authors' website for the book (which contains a full TOC):
"This book is a comprehensive introduction to the process and theories of game development. It is written for academic games courses, professionals new to the games industry, and indie development teams. The book includes worksheets and exercises that cumulate in a game design document."Basically, it talks about each area of video game development (much of which can be, and explicitly is in parts of the book, applied to board games), in enough detail so that you know what's going on in that area and are able to talk to the people who do work in that area. There's a lot of good stuff in there (I've read the whole book word-for-word, which, contrary to what might be generally believed, is not something an editor in technical publishing does for every book he or she works on), and I think it's something that might be interesting to people who read this blog, even if they never intend to develop a video game.
So, I wanted to put an excerpt up here, and I debated putting one of the meaty chapters of the book up, but I decided that the games canon that appears as an appendix of the book might actually be more interesting for the blog. So, here's the canon. I'll just note that this book is copyrighted by A K Peters, 2008, and used by permission (I asked the publisher). All rights reserved. The book should be out around Thanksgiving, and you can preorder it from the A K Peters website or from Amazon.
The Games Canon
(Appendix F from Creating Games: Mechanics, Content, and Technology by Morgan McGuire and Odest Chadwicke Jenkins)
Famous, infamous, radically innovative, critically acclaimed, or blockbuster successes, these are games everyone in the field should know about. They form the base of prior art. In any field, professionals work within a mainstream culture that references important previous work. These form the critical jargon (e.g., "this painting references Van Gogh's Starry Night") and the cultural context for new ideas.
Research is important in any field. It is how we build on the successes of the past and avoid their failures. You wouldn't try to write a book or create a car without first learning about the ones that preceded yours. When creating a game, you should research previous games. This list summarizes some of the most important games. It is intended as a jumping-off point for further research if a game sounds like one you'd like to make. Read through it to familiarize yourself with the previous work. No game designer would be taken seriously without at least passing familiarity with these titles, and most designers have studied several of them in depth.
For brevity, only the most critically acclaimed (or derided) and popular games are listed. In many cases, a previous game introduced a concept (e.g., Crystal Caverns predated Wolfenstein) but had a minor impact. These also include the games that designers often list as their major influences.
For additional cannon lists, see Lowder's book for an excellent recent review of major board games by famous game designers, boardgamegeek.com for up-to-date Internet ratings, and Wikipedia's best-selling (if not best) video game list at http://en.wikipedia.org/wiki/List_of_best-selling_video_games.
Minicanon
The minicanon contains the bare minimum set of games that you should be familiar with to appreciate the examples in this book and start making your own games. A games course should offer these or equivalents to students at a minimum, and anyone serious about games should own them. Most of these games are explained in more depth in the following sections and referenced throughout the text (see the index for references). Note that these aren't necessarily the absolute best games in their class, according to one specific design criterion, but they are likely the most widely acclaimed, easiest to acquire, and successful.
- Carcassonne by Klaus-Juergen Wrede is a board game that features tile-laying and semicooperative mechanics. It has multiple ways of earning points, relatively low variance, and deep strategy and is supported by a series of expansions and alternative rule sets.
- Settlers of Catan by Klaus Teuber is a board game with trading and building mechanics. Settlers and Carcassonne cover most of the mechanics found in modern strategic German board games and clarify the differences in mechanics and business models that distinguish them from ancient games and twentieth-century American games. They have also both successfully been converted to Xbox 360 video games. Puerto Rico is a good substitute for Settlers and features similar mechanics and theme but more advanced play and better balance.
- Chess is representative of ancient strategy games. It is played internationally from casual to tournament levels and features rich emergent play. Almost everyone is immediately familiar with the basics of the game, and the knight and king playing pieces are challenged only by the six-sided die for the iconic status as the symbol of gaming in general.
- Go beats chess in complexity (due to the large board), age, and elegance (there are only two rules to the game!). Although less popular in America than chess, many classic mechanics and strategies arise directly from the rules of go, including encirclement, flanking, captures, and variable board size.
- Poker is a gambling card game that rivals all other games in terms of tournament popularity and purse size. It is exemplary as a classic card game and relies almost exclusively on bidding mechanics, which can be studied in depth through the many variants on this game. Poker is familiar to most gamers and requires only a standard deck of cards to play.
- StarCraft, or any other major RTS/TBS video game (e.g., Warcraft, Civilization, Populous, Master of Orion, Empire Earth), is a requirement for any game developer. We have a slight preference for the Age of Empires series, which combines some modern RTS UI conventions and elements of casual gameplay to make the games more accessible to new players (and also has a free demo of the latest version). These play like a board game but with mechanics so complex that you need a computer to resolve them, nicely showing the transition from strategy to tabletop wargame to computer game. The character-building RPG mechanics made famous by Diablo and Dungeons & Dragons all appear in RTS games, but the "character" is the army or civilization. Mechanics are at the forefront of RTS games, and these are a celebration of complexity.
- Half-Life 2 stands out among FPS games. It is exemplary as a shooter, and the engine supports the other popular shooters Counter-Strike and Team Fortress, but HL2 also pushes farther toward storytelling than any other FPS and is among the most technically sophisticated of its time in terms of technology and Internet distribution business model. We believe that the original Half-Life had a better quality balance (HL2's graphics and physics advanced substantially, but the puzzles, mechanics, and story were at the same level as HL1) but believe that new gamers would appreciate HL2 more because they are accustomed to modern graphics and audio.
- Tetris is iconic as a puzzle and casual game, and decades after its introduction is still considered the standard to meet. The elegant gameplay, tremendous commercial success, and geometric twist on dominoes meets Connect Four make this game a classic. Bejeweled, Hexen, Maki, and other popular arcade puzzle games are directly inspired by Tetris.
- Guitar Hero and its sequels were neither the first rhythm games nor the first guitar games, but they took the genre to perhaps its natural acme. Guitar Hero 2 and Rock Band (by the same developer, Harmonix, and the moral sequel to GH2) are the best of the series. By combining a physical prop with popular music, these games offer broad casual gamer appeal and have consistently been among the best sellers every year since their introduction. Reasonable substitutes are Dance Dance Revolution (DDR), Karaoke Revolution, PaRappa the Rapper, and Guitar Freaks, although these do not have the same mass appeal.
- Super Mario Bros. and its many sequels (e.g., Mario 64, Super Mario 3, Super Mario Galaxy) stand out as best-of-breed platformers. These have tight arcade controls for hardcore gamers combined with cartoony content for casual players. They are polished to a shine by Nintendo's development team and feature a Japanese experiential aesthetic that is still grounded enough for mainstream Western audiences. The Mario games are consistently among the best-selling games of all time, and Mario is probably the most recognizable (and longest lived) video game character—the video game equivalent of Mickey Mouse. As with most of Nintendo's most popular games, the Mario games were designed by Shigeru Miyamoto.
- The Sims 2 and its sequels and expansions are the best of breed (and best-selling) of the god game/pet-raising genre games. These feature most of the mechanical complexity of an RTS, but that complexity is buried behind fiction so compelling that the player's mental model invariably aligns with the artificial characters and not the mechanics. The Sims series is often considered the best-selling video game of all time, taking sequels and expansion packs into account. The game was designed by industry veteran Will Wright, who dedicated it to the memory of Dan Bunten, author of M.U.L.E.
- Indigo Prophecy is deeply flawed in its action sequences, and the plot goes haywire halfway through the game, yet it is one of the best examples of the potential for interactive fiction. This arcane mystery game features characters that the player will really empathize with and scenes that inspire true anxiety, fear, desire, and awe. Although few narrative games can touch Indigo Prophecy, some other well-respected narrative games include Dreamfall and Jade Empire. The older Lucas Arts games (many by Tim Schafer and with writing by Orson Scott Card) feature rich characterization, humor, and fantastic scenes but only occasionally gripping narratives: The Secret of Monkey Island, Grim Fandango, Full Throttle, and The Dig.
(Read the rest of the games canon, which lists games by category.)
Blog regulars will be familiar with my attitude towards the New Hotness in games (of any sort). I hear about something cool, wonder vaguely if I should try it, hear about it some more, get told in strenuous voice that I must play it, avoid spoilers, hear spoilers anyway, procrastinate, and eventually -- after several months, perhaps -- I try it.
It's a secret blogging strategy. By the time I post about something, all the obvious things have been said by everyone else, so I am forced to come up with clever and original observations. (Witness my post about Portal. Hint: I am lying about the secret blogging strategy.)
There are of course exceptions; I have my fanboy obsessions. You will hear Myst news here still sizzling off the griddle. Text adventure technology, I'm pretty good about. (Text adventure games, I'm years behind on.)
Nonetheless, I sat around for weeks while all my friends learned Race for the Galaxy, a card game designed by Thomas Lehmann. By the time I went looking for it, it was out of print. Then it reappeared, and all my friends bought it (except the ones who fanboy-obsessively had bought it on day one). But I still didn't play it with my friends. Why? Because I was on vacation at Worldcon, where, as it happens, my other friends all showed up with Race for the Galaxy, and so I played it a bunch.
Clever and original observation: it's good!
Okay, skip that. How about this: Race for the Galaxy is better than any other game I know at being Interstellar Pig.
Interstellar Pig is, of course, the imaginary game in William Sleator's eponymous science fiction novel. If you spent your teenage years having the crap scared out of you by Sleator novels, you know it. If not, go read it. (Although House of Stairs is more brutal and The Green Futures of Tycho is better.)
The game is described pretty well in the book. Each player is a member of a different alien race, travelling around the galaxy. Each player has the advantages and weaknesses of his species, plus an array of tools, technologies, and weapons -- some in hand, most hidden on various planets. One player owns (or has hidden) the goal object: the Piggy. Whoever holds the Piggy when the timer goes off is the winner. The hunt is on; duke it out.
As given, Interstellar Pig is a lousy game. (No criticism; it serves its role in the story, and Sleator is a writer, not a game designer.) One player starts out ahead, knowing where the Piggy is hidden. Or one player starts with the Piggy, which should be a good strategy -- all you have to do is run away from everyone else. Several card combinations, and at least one single card, are described as unbeatable: if you have the deadly virus and its antidote, you can sit on the Piggy and watch everyone else die.
The use of a timer is all wrong for a strategy board game. Even if you convert it to a more reasonable mechanism -- a fixed number of turns, or some sequence of game events -- the games described are too short. The most a player can do is run to one or two planets to retrieve tools, and then try to get to where another player is heading (if you can guess who knows where the Piggy is). You may not get there in time -- unless you hit a wormhole, which is pure luck, or unless you have the (rare, overpowered) teleport card. If you do get there, you may find the environment unsurvivable with the tools you've got. If the factors do not align, all your play and planning are irrelevant. You just lose.
On the other hand, it's a great fictional game. And it has elements which are undeniably awesome. You get to be an alien, with powers and vulnerabilities which influence your strategy, and make each game a distinct experience. The game has lots of Stuff -- poisons, antidotes, weapons, protective gear, teleporters. The Stuff and the alien powers interact in interesting ways. Also, of course, it's set in outer space.
So if Interstellar Pig, itself, is not the ideal real Interstellar Pig game, what is?
Cosmic Encounter is an excellent choice. You are an alien race with an alien power! You're trying to conquer the universe! There's -- well, there isn't any Stuff per se, unless you count Flares. But I remember wandering through game stores when I was ten or twelve, staring with enormous eyes at the wonderful expansion sets full of alien powers and planets and moons. Now that was Stuff, in real life.
It's a wargame with rule quirks, but the rule quirks -- the alien powers -- are so pervasive that you are constantly thinking in their terms. Your game identity determines how you see every move and skirmish. That's the heart of Cosmic; that's why I played it every weekend during college.
This doesn't mean that other games can't be Interstellar Pig too. The Awful Green Things from Outer Space (as seen on The Gameshelf) is set in outer space; it has alien races; it has Stuff. (Pool cues and fire extinguishers!) It's a wargame clobberfest, rather than a hunt-the-prize game; but then Cosmic is clobbertastic as well.
The Awful Green Things from Outer Space is, most importantly, awesome. Particularly when you're twelve. It's not a particularly awesome game -- lots of room-by-room fighting; I could reasonably describe it as Risk with Stuff. But the theme is so delightfully done, with little cartoon aliens and critters and a three-eyed blue chicken. It glows with personality. It's impossible to pick it up without imagining you're there, pelting aliens in the Ward Room with canisters of zgwortz. It has a comic-book prologue and a CYOA epilogue! Nothing about this is less than awesome, and that's why it is Interstellar Pig.
And that brings me around to Race for the Galaxy. (Which I keep mispronouncing as "Rails Across the Galaxy", because Analog magazine was awesome too when I was twelve. But never mind.)
It's quick. It's in space. There are alien planets; there are technologies to develop, which are Stuff, close enough. It's neither an egg-hunt nor a wargame, but a civ-building resource race, the favoritest genre of discerning modern strategy gamers. And Race is a discerning modern game, designed with a careful eye to balance and strategy. Which makes it entirely unlike Cosmic or Green Things, those gleeful triumphs of the "heave your every idea at the wall and insist they stuck evenly" school of game design.
Why is it Interstellar Pig?
For all the care and finickiness of Race's rules, they all support the theme. Take an bonus card for your brown planets. Reduce the cost of yellow planets by two. Keep an extra card when you draw. Each of these, as you combine them with other powers, evolves into a game strategy. And as you play, each game strategy evokes a story: you are the mining combine, you are the interstellar explorer fleet, you are the technological hothouse, you are the fearless archaeologists amid the Forerunner ruins.
These roles aren't just labels for various suits of cards. Each has a different set of mechanics, and takes advantage of different rules. Theme emerging from gameplay, rather than painted on as "color", do you see? Nor are the roles assigned to you -- you figure them out. Select one, or part of one, or a mix of several; whichever fits your hand and your luck. That has always been the real root of interactive fiction: complicity. You care most about what you do.
Which is why, as someone who hasn't been twelve for a few years now, I think Race for the Galaxy is awesome. Just like Interstellar Pig.
(Although, I admit, not quite. To really be Interstellar Pig, you'd have to imagine that if you don't wind up with the most victory points, then all your planets explode at the end of the game. Now that's awesome.)
I have many clever and creative friends who like games. One or another of them will regularly host game-playing gatherings at their homes, where we sink a few hours or more into various tabletop contests. But sometimes, some of these clever and creative people will find themselves a little tired of the well-worn titles, and that's when the combinatory experimentation starts.
I took this photo last weekend, during one such event. The card-based word game Quiddler (published by Set Enterprises) is an old favorite of many-perhaps-most of my gamer friends. My pal Marc, one of the weekend-long game-gathering's hosts, led a groggy Sunday-morning group in inventing the mashup of Quiddler and Texas Hold Em depicted here. Players each held two of Quiddler's letter-cards, and as community cards appeared according to the standard flop-turn-river pattern, players bet on wether they held the highest-scoring Quiddler hand. This photo shows the final round's winning hand in the lower left; it allowed Marc to spell ZITHERS.
One especially memorable mashup I enjoyed several years ago, via the same group of friends, was "Apples to Ideas", a collision of the increasingly well-known party game Apples to Apples (Out of the Box Publishing) with the rather more obscure party game The Big Idea (Cheapass Games). It essentially involved pitching pairs of the green and red apple cards instead of using the standard Big Idea cards, and otherwise playing according to the The Big Idea's rules, which involves rapid-fire pitching of cockamamie startup-company ideas based on the cards you play. We found that this not only led to a much larger pool of cards, but players had to get more creative coming up with (at least vaguely) legitimate-sounding business models based on cards not tuned for this purpose. During this one game, I scored big by playing the card pair [Industrious] [Industrial Revolution], selling it with the slogan The socioeconomic paradigm shift so nice, we named it twice!™
Have you seen, pondered, or even invented and playtested any game-mashup ideas, yourself?
The iPhone App Store has opened, and it is time for all game-bloggers of good will to talk about iPhone games.
(The ones of ill will are doing it too, as are those of ill mind, of weak will, and of bad wind. I won't fuss about which of these categories I'm in. Zog knows I can't climb that many flights of stairs without going all anaerobic on my mitochondria.)
I see there are... 219 games as I write this. I haven't found a good way to browse them; the in-phone browser doesn't do subcategories, and iTunes doesn't seem to have complete lists in any category. (At least, this doesn't look like it adds up to 219.) But never mind. I've skimmed through the lists, and seen the expected variety: shoot-up games, tilt-marble games, rhythm-tapping games, and the entire continent of casual puzzle games. (Which consists of the Republic of Rule Mazes, the Sodality of Sudoku, the Mahjongg Concord, the Other Sodality of Solitaire, and so on. All of which are pinched corners around the Grand Imperium of Click On Three Identical Cute Animals. Or jewels or what have you. But usually animals.)
Really, the only reason I post stuff on the Internet is to use the word "sodality" as often as possible. Thank you, Brannon Braga.
But I'm interested in adventure games. Adventures are a gaping hole in the iPhone lineup. Can this be? Surely adventures are common casual gaming fodder! Really -- do any web search on "room escape". Each of these games differs from Myst only in that it is small, indoors, and (usually) visually stylized rather than photorealistic.
It is true that every one of these tiny adventurelets is written in Flash. And the iPhone has no Flash player. But heck -- every shooting, tapping, marbling, mazing, three-animal-clicking games on the Web is in Flash too, and developers had no trouble porting those to Mr. Shiny.
The graphical adventure form needs few changes to run on a touch interface. You don't have the ability to click on tiny details -- but "hunt-the-pixel" was always the reductive failure of graphical adventures (as "guess-the-verb" is for text adventures). It's what happens when the game isn't working. So design your scenes for big hotspots. You don't have a cursor to change to indicate hotspots, either. Maybe dragging your finger around a scene should cause hotspots to flash, to indicate their existence that way. Or maybe you just need really good visual focus.
This is important because graphical adventures normally have two levels of response: one indicates that you can use an item (cursor change), the other is for when you decide to use it (click). And so puzzles can involve a certain amount of "What do I want to do first?" If tapping something activates it, most of your game interactions are going to be accidental. ("Hey, I guess that was a lever!") That's a big rethink of the form.
(Sure, you want to adhere to the "no death, no mistakes" rule -- casual adventuring demands that. But even a benign irreversible action is irritating, if you hit it accidentally. And room escape games have lots of irreversible actions. It's a design convention: when you push the button it stays pushed, when you solve the puzzle it stays solved. Keeps the player's momentum forward.)
Maybe we should roll with the dragging idea: design most of the game elements to require motion rather than tapping. Tapping just causes a quick bounce or jiggle reaction. So if you tap on a cabinet door, it jiggles; that tells you that you can drag it open. I like this idea, actually. Levers everywhere instead of buttons. Drag the carpet back to look under it. Drag found items to your inventory, then drag them back to target hotspots.
I'm not sure whether edge buttons or flick-scrolling is better for turning left and right -- that will require some testing. (If finger dragging gets coopted for one of the above ideas, I guess you're forced to use edge buttons.) Pinch-zoom seems like a clever idea for close inspection of scenes, but I suspect it will work best in moderation -- closeups only.
Text adventures! My character sheet says I'm supposed to talk about text adventures. (In fact I already have; this bit of bloggery is adapted from a couple of posts I made on rec.arts.int-fiction.)
The App Store already has a text adventure -- the text adventure.
This is a freeware application being distributed by "Pi-Soft Consulting" (which looks like it's the same as Shawn P. Stanley).
A bit of historic neepery which will be of interest to practically nobody: the splash text shown above is misleading. It is taken from Graham Nelson's Inform port of Adventure -- which, as the note says, is adapted from Dave Baggett's TADS version of Don Ekman's Fortran source code.
Which is fine, except that Shawn P. Stanley didn't use Graham Nelson's port. He adapted Jim Gillogly's C source code. This also descends from the Fortran version.
The two versions feel rather different. Were one to play Graham Nelson's version of the game, one would find a refined parser supporting features such as "get all", more synonyms, abbreviations like "x" for "examine", and a long historical introduction. Gillogly's port uses the original, simplistic parser. There are a few gameplay differences as well.
On the other hand, it's the same game. Both versions cover the classic "350-point" Crowther&Woods edition of Adventure, as opposed to any of several extended remixes. I just don't get why Stanley chose to write his credits this way.
(I'm not accusing him of misconduct. Adventure has always been, in hacker tradition, been considered free software. Jim Gillogly's port is explicitly licensed as open-source under the BSD license. And Stanley is distributing iPhone Advent for free.)
On both hands, the dedication to Stephen Bishop is appropriate to any version of Adventure.
Let's take a look at the game itself.
The interface is straightforward. You have an input line. When you tap on it, the usual iPhone tap keyboard appears, and you type your command. Hit Return and see what happens.
Well, perhaps not so straightforward. This implementation only shows the response to your most recent command. There is no scrolling game history, such as IF players are used to. If you type "get lamp" at the prompt above, the visible text changes to the single word "OK" -- poor context at best.
The obvious fix is to move the input line to the bottom of the screen, and show the game history above it. Right?
Wrong. The iPhone really wants the input line near the top of the screen, because the keyboard is always at the bottom. If the input line is at the bottom edge, it'll just slide uphill when the keyboard pops up, and that wouldn't be great.
So I want the input line at the top but a standard IF scrolling pane below it, with commands interspersed in the usual way. (You'd have to ensure that finger-scrolling only affected the text pane, not the entire screen. This is possible -- in fact Advent does it, with long responses such as the "help" output.)
(That model obviates the need for the input line to keep showing the last command, which is confusingly out-of-order.)
What else does the perfect iPhone IF application have? I'll move away from criticizing iPhone Advent, and talk about general features.
I'd like a special button to the right of the input line, which brings up a menu of one-touch common IF commands. A compass rose of movement commands, "look" and "inventory", maybe "undo". (iPhone Advent doesn't support "undo", but modern IF does.)
The splash page should have a "how to play" button. The mainframe-style "Do you want instructions?" when you start is all wrong.
PDA IF traditionally has some kind of "tap a word to paste it" interface. I want that but it's hard to do with a touch-screen, because words are tiny. The ideal solution might be to invisibly mark up the output text with "this word is important" spans. That opens up a certain amount of blind hunt-the-pixel exploration, but if brute force is tedious and generally useless -- ie, if only the obviously important words are marked -- I don't think it would sidetrack players.
Finally, the backgrounds. I rather like Advent's low-contrast cave photos. (Emily Short disagrees.)
However, what would be even keener would be a map. (I like drawing my own maps, but mobile IF players probably don't have a sheaf of blank paper handy.) Not a complete map, but one that's filled in as you play. You can see the nearby rooms that's you've already explored.
You wouldn't want text on it -- it is, after all, behind the game text, and text on text is hard to read. But a dynamic room map in unlabelled, simple shapes and low-contrast color would be cool. Highlight the current room (or keep it centered). This image is my quick sketch of the concept. Maybe it works? Maybe I'm nuts? Too bright yellow, for sure, but it's late so that's what you get.
You have read many posts in which I dissect games, extract what makes them good, distill what makes them bad. I have made reference to common principles, familiar gaming history, and the Eternal Verities of Aristotle.
(It is not widely known that The Frogs was originally designed as a first-person shooter. It was adapted for the Greek stage only after vigorous debate by leading citizens, who insisted that violent games would corrupt the youth of Athens, and also that guns hadn't been invented yet.)
Anyway, this post is different. This is the post in which I insist that some games are bad because I Don't Like Them Dammit. And That's All That Matters.
I bring you this enlightened and irrefutable opinion after looking at my favorite casual-game linkfarm and seeing a Flash RPG of which it is said:
The first time you enter battle, make sure you drag your team members to appropriate positions.
Right. Team members. Coordinating team members. How about I go read blogs instead? Or cut my fingernails? Or watch my fingernails grow so that I can cut them someday?
Here's my problem with multi-character games: I have to pay attention to all the characters. If I don't, some of them get slaughtered and then I'm not playing the game well.
No, wait, let me tell it with math. In a game with one character, I decide what to do and then stuff happens. That's fun. In a game with N characters, I decide what to do N times, and then something finally happens. That's fun but it's more work and it takes longer. How do I maximize the amount of fun for the amount of effort? By setting N equal to 1, that's how.
(Smartarses will now ask me about N=0. The answer is, yes, I do enjoy a movie now and again. I also read a lot of books. Now we're going to talk about games again.)
I did a lot of this kind of squad organization when I was a kid. Wizardry, Ultima (3 and up), Bard's Tale... I also drew square-by-square maps in colored pencil. I did these things because I had no money and had already read everything decent in the library. Time is shorter these days, and we've invented something called "casual gaming" which we do when we don't want to spend all that damn time.
You have extensive options for customizing your party, with a decent variety of skills for each of 7 different character classes.
Yeah, customizing my party. Also in the category of "things I have to do before I can start having fun." What happened to "here's a sword and an onrushing tidal bore of level-1 monsters"?
This is not a problem limited to the casual gaming sphere. A few years ago, I played Clive Barker's Undying, an uninspired but decently-executed magic-shooter, heavy on the storyline. I had some fun. It had alternate worlds and puzzley boss-fights, which are the two things I demand out of an action game. Then last year I saw ads for Clive Barker's Jericho, and I think "Yay, a brand which I know is decently-executed... oh. Squad of seven characters to control. Screw that." And so I went off to play American McGee's Scrapland instead, which was an endless series of uninspired and storyline-light hovercraft racing missions, but at least it drops you into the patootie and doesn't expect you to micromanage a bunch of wingmen while fighting and racing your way out.
No, I am not an absolutist about this. Single-character control is not an iron law of nature (unlike "avoid third-person adventure games unless they are written by God", God being Telltale in this case). But the last squaddie action game I really enjoyed was Project Eden -- a game in which your four distinctively identical team members respawn every time they die. So you really can ignore two or three of them at any given time. It's not good tactics, but it lets you get your footing so that you can treat the squad tactical options as a bonus, rather than a crippling responsibility.
"Crippling responsibility" sums up everything in my life that I play computer games to forget.
Plus, Project Eden switches over to puzzle gaming in between fights, dropping the time pressure in favor of exploring clever environmental interactions. I don't mind coordination planning when I have time to think, and when the penalties don't involve being razzed and kicked back to an old save point.
Okay, and I played the PS2-era Bard's Tale game. I have no explanation for that. It wasn't the best thing ever, but I was able to cope for the sake of the absurd sense of humor. Aristophanes would have approved.
Screenwriter Todd Alcott looks at the difference between Doom and Half-Life, two first-person shooters from the 1990s with nearly identical plot setups, and yet one tells a so much more compelling story than the other. He argues, basically, that while the former game contains a series of thematically consistent levels, the latter game uses the tried-and-true three-act narrative structure that's supported countless films and television episodes - applying it with great success to a series of thematically consistent game levels. Recommended reading to all interested in writing interactive adventures of any sort.
Kynn Bartlett alerted me to Game Chef, an annual role-playing game deign competition. (Kynn's one of the entrants, with his game Awesome Women Kicking Ass.) As its name suggests, it's inspired by the TV show "Iron Chef", insofar as each year's competition stipulates a "secret ingredient"-style restriction on its entrants, who then have only have a week or so to create an entire, playable game.
This year, the contest was split into two parts; artist-entrants had a week to sumbit sets of black-and-white illustrations for RPGs that didn't exist, and the following week the designer-entrants picked up those sets and designed games around them. The competition closed a few days ago, and is currently in a judging phase - I look forward to reviewing the entries myself!
I know about the existence of indie RPG design culture from listening to the Ogre Cave Audio Report, a podcast involving Gameshelf friend Mike Sugarbaker. It's turned me on to fascinating games I'd really like to try playing sometime, including Dogs in the Vineyard (which puts players in the role of heavily armed clerics in alt-universe frontier America) and the Shab-al-Hiri Roach (where academic politicking and the schemes of ancient insect gods collide in an early-1900s New England university).
I'd love to put a short session on the show somehow, but even a short one would probably be too long to film with a full crew. Which isn't to say we can't do it anyway...
David McDonough recently posted his 20th "Simple Sunday" Game Design. Every week, he posts a design for a new game that adheres to the following rules:
- The entire description and ruleset must fit on one page (more or less).
- No extravagant or custom objects, including cards, tokens, boards, or other devices.
- Try to be original; keep it simple.
Uru Live is scheduled to be shut down in a bit over two weeks, as I write this. Cyan has not made any public pronouncement about what they will do next. They haven't said if the online version of Uru will remain available in any form.
(We know that Gametap will return Uru: Ages Beyond Myst to their rental service. That's the original single-player Uru game -- without even the expansion packs -- and you can't hack Gametap downloads to add new content. The news is therefore irrelevant to me. I'm interested in Uru as a shared, extendable universe.)
My last post worked around to the idea of a fan-created Uru game. Not an extension of the existing Uru, not managed by Cyan; a completely new system, open-source and run by the players. This post contains my sketch of how to do it.
In other words, this post will be too technical for the game nerds, and too handywavy for the programmers. I have no code to back it up. I have experience running a multiplayer gaming service... which has never had more than a dozen people online at a time. So -- dismiss away, if you want.
On the up side, the technical issues here are not specific to Uru or to the Myst universe. Want to run a graphical MMO adventure? Here's a plan. Go to town with it.
So...
How would I design a fan-run Uru-inspired game?
This post is speculative -- in fact, completely hypothetical. If:
- Cyan shuts down the Uru servers on April 10th, and
- they do not offer any future plans for Uru, and
- a group of Uru players want to begin operating a new multiplayer adventure environment for the Uru community, and
- I were making all the decisions,
...then what would I build?
This post does not rise to the level of a proposal. It's a sketch; it's my answers to a bunch of hypothetical questions. I'll argue the merits of each point separately; you don't have to accept my ideas on one point just because you buy another.
This is a conservative proposal; it's a system I think I could build. However, I am not volunteering to build it. Planning is the fun part. I have too many unfinished projects already to pick up a new one. But I can gab about ideas all day. Lucky you, eh?
Assumptions
I want a multiplayer, graphical, 3D environment that approximates what people did in Uru Live.
I will rely entirely on open-source software. Cyan's Plasma engine will not be used.
I do not want to infringe on Cyan's ownership of the Myst series, or their ability to bring back Uru Live someday. (It will always be true that Cyan might bring back Uru Live.)
The plan will be implemented by a small group of part-time programmers. (Not crazy genius programmers; just programmers.) (Maybe I am a crazy genius programmer, but I'm not volunteering to build this, right?)
The result does not have to be as impressive as Uru Live. (See previous point!) We can tolerate shakier graphics, less scalability, and so on, because we have no budget and nobody's doing this full-time.
The game world consists of a set of small areas -- Ages, in Myst parlance. Each Age is replicated in many instances. Any player or group can get an instance of their own; instances are cheap to create on the fly.
The goal is for players to hang out in the environments and chat.
The goal (also!) is for players to contribute new Ages, and explore each others' Ages.
Socializing happens in medium-sized groups -- perhaps twenty or thirty. That's the size of a conversation. Getting a hundred people together in one place would be neat, but it's not a design goal.
Exploring is done alone, or in small groups. Interactive environments stop being fun when a bunch of strangers are jumping in front of you and messing with your stuff. Adventure-style game logic -- with specific, discrete actions and unique results -- tends to have a small number of actor roles. When you have a hundred people cooperating on a task, that's CRPG design, not adventure design.
In other words: while I want a game world that encompasses hundreds or thousands of people, I'm not worried about rendering them on the a single screen or managing their simultaneous access to a single real-time puzzle.
Overall Architecture
The plan in short:
- many independent shards
- but probably one shard is the "main" or common shard
- each shard can contain many Ages, at the shard owner's discretion
- anyone can run a shard, if you have a server with Python and MySQL
- Jabber is the communication layer
- an Age instance is a Jabber MUC (chat room)
- Ogre3D is the client 3D engine
- scripting is in Python (both client-side and server-side)
- limited character animation
- no physics
- storyline is not my problem
The Shards
A "shard" is a stand-alone, fully functional server running the game system. (It might actually be several machines, but imagine it as one host.) Uru Live has a single public shard -- when you log into Uru, you're in the Uru world, and you can (potentially) meet anyone else logged in at the same time. Other MMO games run many shards, but they're all managed by the same company. (Actually, in the 2004 Uru Prologue, Cyan put up two or three shards for load-balancing reasons.)
I envision my game system being much more heterogenous. I don't like the idea of enforcing one server for everybody, or one player database. I don't even want a single group of people operating the game. This should be an open system. That means anybody can run a shard. Download the software and set it up; you're on.
Shards should be completely independent. We don't want one badly-maintained shard to corrupt others. We also don't want the whole system to die because one person went on vacation. By keeping shards separate, we can keep problems contained. We can also address scaling issues -- crudely but effectively -- by setting up more shards.
Anyhow, there won't be any notion of global avatar progress, because there is no global set of goals or achievements imposed. So there's no real reason to share avatar information between shards.
Naturally, I expect one shard to be the common place where people hang out. There could also be a development shard for the Writers, a testing shard for the Maintainers (or maybe several), and private shards for small groups or for the hell of it.
When you decide to run a shard, you decide what Ages it will contain. This will be a plugin system; you download an Age plugin (Python code) from whoever wrote it, stick it into your server directory, and presto. Some Ages may be used in all shards, others might be featured by a single shard.
There can be a published list of public shards -- I'll accept that much centralization. (It could be as simple as a wiki page.)
Scenario
(This section is, of course, specific to the Uru mythology.)
The Called, exiled from the Cavern, gather on the surface to discuss their future. Their Relto books no longer work; Yeesha has apparently abandoned them. But the Guild of Writers announces a breakthrough: intensive computer analysis has found some of the underlying structure of the D'ni linking symbols. Surface dwellers are beginning to create effective Linking Books.
While the Guild cannot replicate all of Yeesha's techniques, they have discovered some useful tricks. Instancing is one. More important is the ability to replicate linking pages -- literally print them out on an inkjet printer. (This only applies to modern-made Books, not to Relto or D'ni Ages.)
This means you can carry around a sheaf of link-home pages on your belt. When you use one, it remains behind (and disintegrates -- biodegradable!) but you still have the rest of the sheaf. Similarly, if you come across a Book that you want permanent access to, you can lift out a linking page and take it home to your library. As long as the Book's creator included a whole sheaf of pages, the Book won't be damaged, and there will be plenty for future explorers.
Your "home" in this scenario is not a beautiful island Age. It's just a small room in your house or apartment -- a closet that you've converted to an office for your Uru work. Very plain. (You might get to customize the color of the walls.) You have a desk, a bookshelf and a stack of linking sheets. This is your entry point to the shard, but its game function is more like the Nexus than like Relto.
You have a book for a community Age (Ahra Pahts or something like it). You have, or will gather, more books and pages as the shard provides them.
Since all these Ages are written by surface dwellers, we have no access to any D'ni Age we are familiar with. Nor will you find any links to the Cavern, or any other place on Earth besides your home. There may, however, be traces of the D'ni out there in the Ages we explore -- perhaps even other civilizations with linking technology. The Tree has many leaves, and no one knows what the next one might hold.
(This scenario takes a deliberately conservative approach to Cyan's intellectual property. I assume that the people running this game would want Cyan's permission, but would not want Cyan to take an interest in controlling the game world. To get that, I take a long, ostentatious, good-faith step away from their financial interests. Cyan has always hinted that their outlook on player-created Uru content would be "No D'ni history, no D'ni Ages." I can live with that.)
(Of course, if Cyan is cool with us using their toys, that's great. I'd want to at least use the familiar Linking sound effect!)
Storyline: Not Mine
Uru Live wanted to be very story-oriented; much more so than most MMO-RPGs. And Cyan wanted to have firm control over Uru's story. They did not, most people agree, get the balance right. Control versus flexibility versus coherency versus player involvement is a long argument, which I will not reiterate here.
In a fan-run game, I don't think one group should be in control of all the story. That model doesn't even start to work without a lot of community trust of the game-masters -- a different kind of trust than mere technical adequacy. Cyan held that trust tentatively, and (for a lot of players) squandered it. I do not propose to re-vest that trust in another cabal.
Rather, I'll let everyone do their thing. (The Myst logic of many separate Ages encourages this.) If something good emerges, it'll have to emerge on its own. So this section of the plan is up to everybody. Yes, including you.
Architecture Details
Language: Python
Obvious choice. I like Python. Uru's client scripting is Python, so anyone who's played with Age creation so far has at least seen it.
(Security is a weak spot. I will address this later.)
Communication: Jabber
Jabber is a widely-used IM and chat system. Google Talk and Livejournal's chat system are both Jabber.
Using Jabber as the transport layer for a game is a compromise. I'm using it because I'm used to it. I've implemented a board-game system (Volity) using Jabber, and I am writing this plan to work very much the same way.
Basically, the shard server is a Jabber bot. Each Age instance is a Jabber chat room, managed by an instance server, which is also a Jabber bot. Your client is a Jabber client with a fancy graphical display; when you enter an instance, you join that chat room.
Pros:
- Open source. Jabber libraries exist for lots of languages, including Python.
- Supports Unicode from the ground up.
- The Jabber server handles authentication and encryption for us.
- Jabber is firewall-friendly; it only needs an outgoing network connection (to the Jabber server).
- It's a chat system, so game chat is covered. (And it interoperates with every other Jabber chat server. Someone running iChat on a Mac, or Google Talk, could send you a message in-game, same as they talk to anyone else.)
- Jabber is extendable. Sending movement or emote messages through Jabber isn't a gross hack; the format is designed to let people design new message types.
Cons:
- Not as fast as a raw TCP connection. (All messages go through the Jabber server; all messages are XML snippets. Message encoding, transport, and decoding take time.)
- We'd probably want to run our own Jabber server, which is a bit harder to set up than (say) a wiki or an IRC server. (The architecture I'm planning doesn't require customizing a Jabber server; but things are faster if the game servers and the Jabber server are on the same machine.)
A Jabber-based system would not be as speedy as Uru Live. My experience from Volity says that game actions would take a small fraction of a second -- say, 1/4 to 1/2 second. That's fine for board games; it's fine for chat and emotes. But it's a bit slow for a 3D game. (Imagine that fractional delay every time you push a puzzle button.)
More importantly, Jabber is not optimized for many tiny messages. When you walk around in Uru Live, you are sending a constant stream of avatar position updates. My Jabber-based system can't do that. (The XML snippets aren't huge but they're bulkier than a typical MMO walk packet.) So it would send those updates much less frequently. Maybe once every ten seconds, or less often than that. In a crowded instance, the server might have to filter that down even further. Chat, emotes, and action messages would have priority.
Basically, movement of other avatars would look like occasional jumps. You wouldn't get the walking-around that you're used to. You might fail to see someone who just arrived, or see somebody present who really walked away thirty seconds ago. A static conversation -- several people standing in one place talking -- would be fine, though.
As I said, it's a compromise. I think of chat and puzzle-solving as being more important to Uru than smooth animation.
(By the way, when I say movement is jumpy, I'm talking not talking about your movement. Your viewpoint will move smoothly, like in any 3D game.)
(An alternative: you could treat movement updates as a very special case. Don't send them via Jabber; have a separate stream, binary-encoded and UDP. You'd need to treat the UDP data as unreliable, superseded by any Jabber data about that avatar. But I was planning to do something like that anyway. See the "Synchronization" section, below.)
Display: Ogre3D
I typed "open source 3d engine" into Google and Ogre was at the top of the list. It's portable and it supports Python scripting, and that's all I was looking for. If some other package turns out to be better, that's fine too.
Other possibilities: Irrlicht; NeoEngine; Crystal Space.
Note that I have listed 3D graphics engines. I am not considering game engines, MMO engines, or online virtual world systems. I don't want a software package that comes with communication or server code; I'd just have to rip it out.
It may sound stupid to plan to write MMO communications code "from scratch". But it's not really from scratch. Jabber is a complete, working, scalable message system. And the game server code needed for adventure gaming is really not complicated. Jabber bots that talk to a database, and write a limited amount of instance state, should be easier to maintain than a third-party virtual-world system.
(Of course it's perfectly reasonable to plan an Uru game using an existing MMO client-server solution. It's just not this plan. For the sake of completeness, here are some open-source virtual-world projects: Uni-Verse; Croquet; Project Darkstar.)
Age Distribution
An Age consists of two parts: a server module (Python), and an Age package (ZIP file containing textures, 3D models, and Python).
By the way, the Age is identified by a URI (a string), rather than by a sequence number. (URIs are great. Anybody can invent a URI without worrying about collision -- just pick one based on your home domain or email address.)
The server module is downloaded once by the shard admin and installed into his shard config. The module contains the URL of its Age package. (Or the shard admin can specify a mirror URL, I guess, if he doesn't want to rely on the original author's web server.) The URL can be any web address.
There's also a general UI package associated with the shard. This contains clothing, menu images and scripts -- the stuff that the player can see in any Age and instance of the shard. (But note that different shards can offer different UIs. So you might have a standard Uru KI interface on one shard, and an enhanced KI on another.)
When a client logs into a shard, it downloads the UI package; when it links to an Age, it downloads the Age package. These are simple HTTP downloads, using the URLs that the server provides. We use an HTTP HEAD request (or If-Modified-Since) to skip the download if the client already has the package cached.
(Since downloads will be slow, we might offer the player a "download in background" button on the download screen. That effectively cancels the link, and lets him wander around the original Age or go somewhere else while his client finishes the download. We don't really want a "download all Ages" option, because there's no upper limit to the number of Ages on a shard.)
The client caches packages. So it will have to offer a way to clear the cache. Probably just a list, showing the last time each one was loaded, and a button to delete the older ones.
Note that this system is very modular: an Age package must contain every resource used in that Age. This is simple, but not efficient. (If a texture appears in three Ages, you'll download it three times.) I think simplicity is more important to begin with. If resource sharing becomes important, I'd do it by wrapping the shared resources up as a separate package; then the server module requests a list of packages (instead of just one).
Age Upgrades
Ages will change over time. But it's likely that different shards will update them at different times. This means we need a system for tracking different versions.
There are several upgrade scenarios:
- A server module is updated, but it doesn't require any changes to the Age package. (Bug fixes, for example.)
- An Age package is upgraded, but it doesn't require any changes to the server module. (Models or textures are improved with no change to the scripting.)
- A major update requires both the server module and the Age package to change.
The first two cases are pretty simple.
- Distribute a new server module. Shard admins will install it (or not bother) at their leisure. (For simplicity's sake, you have to take down your shard to install new Age modules. Cyan did it, you can do it.)
- Post a new Age package at your distribution URL. The next time a player links in, his client will download it. A player who is currently in your Age won't see the new models right away, but that's okay.
The third case is the tricky one.
- The rule is, if your Age update requires a new Age package, you must change the package URL. And you must leave the original package available -- because some shards might still be running the old version. You should only take down an Age package when you're sure that no shards out there are running the code that requires it.
(The server module and Age packages will each contain embedded version numbers which ensure that this matching is correct. I have a standard scheme for doing this, which I won't get into here. See version matching on the Volity wiki if you really care.)
Logging In and Out
The shard has a shard server, which handles new arrivals, and also shard-wide services such as personal messaging. The shard server, as I said earlier, is a Jabber bot (written in Python). It is always logged into Jabber, and can talk to a MySQL database (the vault).
When you start your client and select an avatar, the client contacts the shard server. The server notes that your avatar has no active game session, so it tells you to link to your "home" instance.
(By the way, Jabber lets you log in with multiple clients at the same time. My game architecture is fine with that. You can drive two avatars around on different shards, or even on the same shard, as long as they're different avatar records.)
When you enter a new instance, the shard server starts up an instance server, which is also a Jabber bot. The instance server creates a Jabber chat room and sends the address back to your client. The client joins the chat room, the instance server sends you the local state (including other avatars), and then you are officially in the instance.
When your client disconnects, your instance server is notified (Jabber handles this automatically). It can then notify other players (in that instance) that you've vanished. (The shard server doesn't have to care that you've logged out.)
Chat and Friends
We rely on the basic Jabber facilities for chat and friends-list. When you speak in an instance, the message goes out to the chat room, and everyone else's client sees it. The instance server isn't involved at all. Similarly, when you send private chat, it's a regular Jabber chat message.
(Emotes are regular Jabber chat messages with a special tag naming the emote. Jabber lets you add special tags to any message. Other clients, like iChat or Google Talk, will just ignore the tags.)
Jabber gives you a friends-list. Whenever you log on, Jabber automatically notifies your friends; again, the instance server (and the shard server) don't have to be involved. Your client will add special tags to your presence notification to indicate which Age you're in.
(This won't work identically to Uru Live. For example, when you friend someone, they have to accept it -- that's a Jabber policy. And we can have a "recent" list, but it won't include the player's Age location, because you only get presence notifications from friends and people in your chat room.)
No Physics
The Uru physics engine is a big old pain in the butt. Way too much of Age development is "find the collision holes; find the improperly climbable walls." Coordinating a rolling object between many players is a significant load on both CPU and network. The heck with all that. No physics. You won't be able to implement Jalak or Eder Gira, exactly. Big deal.
Certain polygons will be marked in the Age file as "floor". Your avatar can move around a floor polygon (strictly two-dimensional movement, no jumping). When you reach the edge of a floor polygon, if there's an adjacent floor polygon in the mesh, you can continue on to it. If not, you stop.
Ladders are "floor" polygons with a vertical orientation. The client doesn't have to treat them specially, except to change your movement animation. Same goes for water. You can't fall through the world because there's no falling. You can't get flung through the ceiling by a misaligned ladder. Everybody is relieved.
(Yes, that ladder flinging thing really does happen with Uru's Plasma engine. Take a look at the Guild of Writers' instructions for ladder placement. Not pleasant.)
Some "floor" polygons trigger scripts. We will get more into this later, but this is how you do a falling or jumping action if you want one in your Age. You mark a specific polygon with a script saying "When the player walks here, move him down to that floor polygon there." (Or panic-link him with a falling animation.)
Limited Avatar Animation
I'm leery of animation because it's unexplored territory. The current Writers group has people working on textures, models, sounds, and scripts, but nobody has touched character animation (as far as I know). So this plan includes only minimal animation work. Stiff walking/running, stiff ladder-climbing, maybe a stiff panic-link move.
I'm assuming that simple animations -- a door opening, a globe rotating, an avatar falling straight down -- will be easy. However, Uru Live currently has a huge palette of fluid avatar animations, for emotes and story actions. I don't think we're going to replicate those, not right off the bat. We're certainly not going to have the perfect finger-on-button, hand-on-rung precision that Uru Live offers.
But I've already conceded that avatar position updates will be slow and jumpy. So weak animations don't really make things worse. You're just going to have to get used to avatars standing around and being stiff.
If someone then comes along and offers better animations, that's great.
Synchronization
This is the hard part of the MMO problem. (It's certainly the part that Uru Live had the most trouble with.) Keeping everybody's world-state in sync is easy, if you don't mind lag; avoiding lag is easy, if you don't mind client inconsistencies. Then your database bogs down, and you have the lag and the inconsistencies.
This scheme is optimized for Myst-style adventure gaming. That means small Ages, with a relatively small amount of persistent data. (Kadish Tolesa has maybe fifty stored values for all its puzzles.) And not too many people interacting with one instance's puzzles at a time.
(If you want gigantic Ages with lots of players interacting with lots of objects, I can't help you. That's a hard problem. Go talk to the people who run Second Life or OpenCroquet.)
The general rule is: the outcome of game actions will be decided by the server. (This is in contrast to Uru Live, which left a lot of decisions to client scripting.) Jabber messages are reliable and in-order, so as long as the server processes commands sequentially, consistency is assured.
This costs. Reliable, in-order messages can be slow; they can bottleneck. So we have to be careful to make server-side decisions quickly.
Therefore, our other general rule is: the instance server keeps all the instance state in memory. It shouldn't hit the vault database every time a door opens or closes. For transient events (like the Delin/Tsogal door opening), it won't hit the database at all. Permanent state changes (like the Bevin book room door opening) will have to be written to the vault, but that can happen as a periodic checkpoint. As much as possible, we want to avoid a player action blocking on server database work.
Nonetheless, when you push a button, there will be a brief pause before you see a result. If the server is stressed, this may be a long brief pause. In general, you will be "stuck" to the button until that server reply comes back. (Although in some cases this won't be necessary.)
This brings up the flip side of game actions: moving around. I've said that this system is pretty sloppy about player location. The client knows where you are, but the server (and other players) aren't updated that often.
"Great," you say, "leave location up to the client." But in many cases, game actions are triggered by location. (For example, the Cleft bridge that breaks when you step on it. Or the Gahreesen auto-doors. Or the Teledahn prison.)
It's easy to mark some "floor" polygons as having (client) scripts, so that stepping on them has an effect. But I just said that game actions suffer a brief pause, while the server replies with the result. Should you be beset by these pauses while you walk around an Age? I think not. Free movement is a big part of the immersive experience, and it's worth making an exception to keep it smooth.
The problem is, if you don't freeze when you enter a script region, you run the risk of "outrunning the script". (You start to run across the Cleft bridge. The server is running slow, and by the time it reacts, you've already reached the other side. Whoops! Now you're somewhere impossible. Not a big deal in the Cleft, but it could be a plot bug in another Age.)
To prevent this, we give these regions a "sticky" attribute. When you enter or leave a sticky region, the client sends a location update to the server. (The client does this regularly, of course, but it is careful to send one when it crosses a sticky boundary.)
Until the server acknowledges this update, you are logically stuck to the region. As far as the client is concerned, you're frozen. You can still move your avatar around, but you can't push buttons or trigger any other scripts.
Hopefully, this hidden freeze will be brief (a quarter second, just like being stuck on a button). Then the server reply comes back, and everything continues on; you never ever notice it's happened.
But say the server replies "Hey! The bridge just broke!" As far as the server is concerned, you were on the bridge when it broke. Game logic decrees that you must fall. So the client runs the "break and fall" event -- regardless of where you were. You teleport back to where you're "supposed" to be (the break-point of the bridge).
Again, in the normal case, it's only been a quarter second since you hit the bridge. Falling makes sense. But if the server is slow? Well, you might be teleported back several steps. Maybe even from the far side of the bridge. Too bad. Adventure game design needs reliable plot logic.
(Mind you, not every script region requires this kind of rigid control. If a room's lights brighten as you enter, that's just cosmetic; it's no big deal if it's out of sync with your "real" entering time. So that region wouldn't be marked sticky.)
There are more details to this plan. (What if you enter another sticky region while logically frozen? What if you fall off a cliff? What if you log out?) I won't go into them, because this section is already way too long.
Potential Problems
Scaling Issues
I've said that I'm willing to accept less scalability than Uru Live had. That doesn't mean I want to ignore the issue entirely. There are several walls that Uru Live ran into, and we should at least think about them.
Really large Ages: We'd like to support areas which are very large, but are divided into sections. The client doesn't render distant sections, thus saving polygons. (UL does this in Aegura. If you haven't noticed, it's because it does it well.) The 3D engine should support this out of the box; it's an old trick. Hopefully, it'll be easier than the Plasma engine's "multiple page" trick -- I understand that's kind of a hack.
Too many avatars: Even in a simple Age, if enough avatars show up, the 3D engine will eventually choke. The crude solution is avatar pop-in: the client only renders the fifty closest avatars to you. (Once again, we shovel all the graphical problems onto avatars.) A less crude solution (which UL employed) is levels-of-detail on the avatar models.
Client threading: Uru Live had a lot of problems where the client's Python scripting would hold up the Plasma rendering. (That is, some network traffic would arrive and cause a frame-rate glitch.) I haven't looked at the Python-Ogre interface, but I really hope we can avoid that. It will require careful implementation of the interface. I expect this to be the hardest part of the whole system, really.
Instance server overload: The biggest traffic load on the instance server is avatar movement updates. (Recall that chat, emotes, and Age-location are handled by Jabber directly.) In a crowded Age, the server will have to start ignoring movement updates. (Not the important scripted ones, but the normal step-by-step updates.) Jumpiness will get worse. We might even need a signal to tell the client to send fewer movement updates.
Vault database overload: All persistent updates in a shard are going to a single SQL database. (I am not smart enough to design a distributed database cluster. I can install MySQL.) My only plan is: don't create Ages which require lots of data written frequently. Keep everything in memory. Checkpoint occasionally; if possible, checkpoint only the state which has changed. (But you have to be careful to keep the in-DB state of an instance consistent.) If problem remains, bring up another shard somewhere.
Not Being MMO Enough
When I posted the first draft of this essay, the most common response was: "Jabber? Slow? XML? You can't run an online game like that! You have to compress movement updates into individual bits!"
Well, small UDP packets, anyway.
As I've said, this is a compromise strategy. Jabber buys you a lot: good authentication and encryption is not easy! And it costs a lot. But I'm not just making a quid-pro-quo argument. I'm trying to pick out what's actually vital to an MMO adventure game, and what people are simply used to.
Free-ranging, real-time movement is a recent addition to the adventure world. Myst 1 through 4 used discrete movement -- click on a location to jump there. Most adventures still work that way, although a handful (including Myst 5) have followed the Uru model.
Adventure interactions require you to be in particular locations at particular times -- the times when you interact. (With puzzles or with other players, it's the same constraint. Although other players are more flexible, since you can generally interact with them anywhere.) In between interactions is essentially gravy. Important, immersive gravy; it's when you absorb the game world. But in terms of what you do, the game doesn't care whether you're looking around at fixed angles, or turning in place, or moving freely. (Not until you enter one of those scripted regions!)
Uru players are used to the MMO model, where every avatar in view seems to move freely. (With occasional glitches; but then, Uru has much better movement animation than most MMOs.) But I'll note that not all adventure gamers are convinced. One of my friends tried Uru and then told me that he wanted a "click to jump" interface. The 3D movement repelled him; he hated maneuvering towards the button or lever or whatever he had his eye on. He just wanted to decide to be there.
That's not how I feel; I like free navigation, and so I've written this proposal to have it. But we should remember that there is no unassailable requirement for this stuff. You could take my plan and drop the free movement entirely; build the game engine to render a series of still views, with other avatars clustered in nice natural-looking groups around their respective location points. It would still be an MMO adventure game. (And you'd be able to drop the section about the sticky regions. I mean, eww. And I wrote it.)
Security Issues
Python is great in many ways, but one thing it's bad at is secure operation of downloaded scripts. That is, when you're getting arbitrary Python code off the Net -- like in an Age package -- you're trusting it completely. There's no way to run that code in a secure sandbox. A malicious Age script can very easily erase your hard drive, or install a virus.
(Old versions of Python contained a "rexec" module which was supposed to offer sandboxing. This is now deprecated, because it doesn't work -- Python actually got too powerful for it. There is also a secure-Python project I've seen, but I don't know if it's been verified or tested at all. I'm keeping an eye on it for possible future use.)
We can't ignore this issue. Anyone who downloads a free game and runs it is trusting the programmer; but this system is an extendable game, and it's intentionally as open as possible. We want a flood of new Ages -- we can't ask the user to trust everybody who contributes to that flood.
We're going to have to start by manually inspecting Age scripts as they are contributed. Ideally, we'd have one "safe" shard -- the common one, to which new players are directed first -- whose admin guarantees:
- that the Age packages that it links to have been inspected for booby-traps;
- that these Age packages are stored on the shard's own web server. (If the Age package is stored on the original author's server, a malicious author could "upgrade" the file at that URL at any time, adding a booby-trap.)
(The admin will also want to inspect the Python server module, but that's for his own protection, not for the players.)
This is additional headache and bureaucracy, which sucks. Development shards, testing shards, and private shards will certainly take a more freewheeling approach, which means we'll have to educate users about the dangers. That sucks too.
The up side is that inspecting Age packages should not be slow or difficult. Normal Age script code will be simple; it will call almost nothing except standard game APIs. If a script calls open(), socket(), or most general Python library APIs, something is wrong. If a script is obfuscated, something is wrong.
Conclusion
It's possible.
I keep meaning to post a long post all about how cool Strange Synergy is, but here's just a little post right now.
One of the things I really like about Strange Synergy is the game-design aspect. In the beginning, you are randomly dealt a number of power cards (things like "Zorch Ball" and "Mental Crush" and "Smoke Bombs" and "Rubber Body"), and you have to assign those powers to your team of three characters. The rules say that you get nine cards and give three to each character, but I've found that I like giving each player fifteen cards, of which they get to give three to each character. This has a few benefits, one of which is evening things out a little bit, as you can sometimes get stuck with a really crappy set of cards and get completely dominated by another player with better cards.
The other benefit is that you actually get to feel like you're doing a bit of game design before you play the game. You get to decide what your characters' powers are, figure out which combinations will work best, how each character will complement the rest of the team, etc. And then you get to test out your design by actually playing the game.
I would like to find more of these kinds of games, where there is a design element incorporated into the game. If there are enough interesting ones, I kind of hope that I can suggest that these all be pulled together as a theme for a future Gameshelf episode.
So, anyone have suggestions for other games to add to this list?
