The everyday blog of Richard Bartle.
RSS feeds: v0.91; v1.0 (RDF); v2.0; Atom.
4:09pm on Wednesday, 6th July, 2011:
Comment
I got an email after my talk in Barcelona last week thanking me for stating the obvious. I think it was probably meant well. It's often a surprise, though, just how much something that is obvious to a person who's been designing games for decades is not obvious to someone who doesn't design games at all.
Another email I received thanked me for pointing out that games evolve. I'd taken it for granted that everyone in the audience knew that games evolve, but apparently no, not all of them did. I was asked if I could supply any references to books about the evolution of games, and was a little alarmed to realise that there were very few of them. There are some that cover the history of games (especially ones important to the wider culture, such as Chess) but all they describe is what changes have been made, not why they've been made. David Parlett's seminal The Oxford History of Board Games does, I believe, have some discussion of why some particular games evolved the way they did, but I don't have a copy and it's out of print. Raph Koster's tour de force A Theory of Fun for Game Design has a section on it towards the end of chapter 4, but makes the same kind of assumption I did (namely that how it happens doesn't need any explanation). I could only think of Jesper Juul's A Casual Revolution as a stand-out book that tracks the why behind changes as well as the what (for casual games, anyway).
OK, so this basically gives me permission to ramble on a bit about how games evolve over time. Designers can stop reading now, there's nothing here you don't already know...
I suppose, as I'm stating the obvious, I should begin by pointing out that there are four kinds of changes that happen to games.
Firstly, there are incremental version changes made within a single game. In the old days of videogames, this meant patches based on user feedback (or bug-fixes); nowadays, it means A/B testing and other metrics-driven approaches that gradually shine and polish a game, buffing out the dents and making it more attractive to its current users. This is a hill-climbing exercise, though, which will find a local maximum experience but not necessarily a global one. It also assumes that all players have similar tastes and reasons for playing. While it's useful a tool, it's not something a designer should follow slavishly; it's input into the design process, but it's not instruction.
Secondly, there are larger incremental changes made between iterations of a game within a series. Civilisation V is different to Civilisation IV, but in some sense they remain the same game; the latter is an evolution of the former (and its predecessors in the series). The changes made for these games usually involve an adjustment to gameplay based on player or designer ideas, but they can also include updates to the presentation (better graphics) or a new marketing opportunity (Patrician III was more of a patch to Patrician II than a true "next game in the series", but I bought it anyway). In design terms, they serve to shake things up a bit so that a new hill-climbing exercise can begin that will find a different, hopefully higher, hill.
Thirdly, there are incremental changes so large that they lead to new, separate games. These take ideas from another game (or perhaps several games) and put them together to make a new game. Often, there's only one major gameplay change, such as the switch to swoop patterns in Galaxian (which I was good at) from the relentless linear advance of Space Invaders (which I sucked at). This is what we normally mean by "game evolution": the creation of new games from ideas established in older games. As it happens, game designers are as likely to take an idea from somewhere else entirely ("ant nests!" — although that's more a programmer thing than a designer thing). However, they do know a good mechanic when they see one, and they're not afraid to repurpose it. Better, you can't patent game mechanics so there's nothing to stop them.
Finally, there are changes so radical that they're revolutionary, not evolutionary. These don't come from other games, they come from the designer's imagination. There were no god games before Populous; there were no real-time strategy games before Dune II; there were no first-person shooters before Wolfenstein 3D. Well, there may have been, but they fell by the wayside and had zero affect on the future development of the genre. Roy Trubshaw's and my MUD falls into this type 4 category: we did have influences from other games — the interface is straight out of Colossal Cave (ADVENT to us), for example — but the "virtual worldliness" was original and new. "Original" is only relative, though — as I've said many times, other people also invented virtual worlds independently of us, it's just luck that ours is the one that took off. Anyway, following a revolutions you'll then get a series of evolutions as in the third point (above), which allows for a family tree to be constructed (one for text MUDs is here). Such family trees can only tell you what descended from what, though, not how or why a child differs from its parent(s).
So, to explain the kind of thing that goes on in a designer's mind when they're creating a new game from old (ie. type 3 above), I'll discuss one of my own: Spymaster. This is an old JavaScript game I wrote about 10 years ago — so long ago, in fact, that it only runs under Internet Explorer. If you want to try it, it's here: http://www.youhaventlived.com/spymaster/index.html (written in full so you can cut and paste it into IE's URL bar if you like) (oh, and the pop-up that gets blocked is to play the music). Ah yes, and if you do really well and get over 100 points, your score will screw up. I really ought to fix that...
The idea with Spymaster is that you have a circus of 16 spies numbered 0 to 15. A mission comes up which has a value between 1 and 16; there's only one of each value, but they appear in a random order. You and your opponent send a spy from your circus to try to complete the mission. The higher-rated of the two agents succeeds in the mission for your side and the mission's value is added to your score. If it's a draw, no-one gets the point. After each mission, both the spies are out of play for the remainder of the game.
For example, suppose mission 14 comes up. I may have agents 1, 8 and 15 left; my opponent may have agents 6, 9 and 10 left. My opponent knows I can guarantee to win with my 15, so plays the 6; I, second-guessing that this would happen, play my 8. My score goes up by 14. I now have 1 and 15 left and my opponent has 9 and 10 left.
Agent 0 is an assassin. Whenever agent 0 is selected, the mission value is ignored. Instead, the player who played the assassin wins points equal to the value of the opposing agent. If mission 12 comes up and you play your agent 15 against my agent 0, my score will go up by 15 and yours will stay the same. My agent, your agent and mission 12 then go out of play.
A change to the look of a game without any change to the mechanics is a reskinning. I reskinned Spymaster as MinionHack to demonstrate this — functionally it's identical, but it's set in the world of the Knights of the Dinner Table comic book. A reskinning is not a new game, it's the same game but with a potentially different emotional impact. If I were to fix the bug with the two-number date field, that would be a type 1 incremental change from above, although barely so. If I wrote a new Spymaster from scratch with more bells and whistles such as multi-play or more opponents or extra spy abilities, that would be a type 2 incremental change.
Spymaster is, however, a type 3 incremental change from a card game I've mentioned occasionally in QBlog before, Besikovitch's Game. This is named after its inventor, Abram Besikovitch (or Besicovitch). The rules of Besikovitch's Game are as follows:
Take a pack of cards and split it into suits. One player takes one suit, the other (it's a two-player game) takes a second, and a third is the bid pile. Discard the fourth suit. Shuffle the bid pile face-down. The game consists of 13 rounds. Each round, the top card of the bid pile is revealed. Both players take a card from their hand to use to try to win the bid card, and they reveal these simultaneously. The higher of the two cards (if there is one) wins, and the bid card goes in that player's winnings pile. Ace is low. The played cards (and, if they were the same, the bid card) are then discarded. After all rounds have been played, the player with the highest total of card values (ace=1 to king=13) in their winnings pile is the overall winner.
So, Spymaster is basically Besikovitch's Game but with three more cards and an assassin mechanic. I ripped off Besikovitch?
Yes, that's right, I did. I love the purity of the mechanic of Besikovitch's Game. It's perfectly balanced. Playing it, it's all about bluff and double bluff. It felt to me like a Cold War, Smiley's People kind of spy game. I therefore determined to reskin it as such. However, when you play it a few times you'll get a feeling of crampedness; it needs more cards. It has 13 because there are 13 in a suit, not because 13 is some ideal number arrived at through extensive play-testing. I added three cards, which felt to me as if it would be enough to allow room to breathe without making the bluffing too unconstrained (imagine it with 100 cards — you'd basically choose one in the right kind of area but it would be pot luck whether it beat your opponent's or not).
Another thing I felt uneasy about with Besikovitch's Game is the way that the king is unbeatable. If the bid card is a king, your basic choice is: do I make this a draw by playing my king, or do I give it away and hope to win the other high cards in compensation? If your opponent doesn't want you to win it, you don't get to win it. I didn't like that, because it makes play for high end cards tedious. I wanted something to open it up, so there wasn't always a guaranteed win for a king and there was more of a reason to play your king on an earlier, lower bid card.
I recalled a game I'd read about in a magazine called Games & Puzzles that we used to take when I was a kid. This game — its name was something like The Office Game — was played with pieces on like a chessboard except with a few squares blocked off to act as walls. The pieces all moved like a rook in Chess and had different heights (it was a make-your-own game, you were supposed to cut up a broom handle to do this but I used Lego). Taller pieces could take shorter pieces. It went something like chairman beat vice-chairman beat director beat manager beat clerk beat secretary beat typist beat office boy. However, as a neat twist in the mechanic (although it made no sense in the fiction), the office boy could beat the chairman.
The above game was rubbish, because for the office boy to take the chairman the chairman had to move into the office boy's line of fire (if it happened the other way round, the chairman would simply take the office boy). There was no earthly reason ever to do this, so the game got very boring very quickly. However, that wrap-round mechanic stayed with me, and it occurred to me that it did just what I wanted in Spymaster to counter Besikovitch's Game's high-end card problem. Sticking with the spy theme, I made one of my new cards represent an assassin. The assassin could beat any other card. To stop this from merely replacing the king as the one card that can beat all the rest, I made it that what it won would depend on the rank of the victim. This meant that the reason you played an assassin was not to win a big bid card, but rather because you thought your opponent might play a big card to win the bid card. This added much a more interesting gameplay element and really opened up the play around high-end bid cards.
I did consider having more individual cards with special abilities (agent 1 can beat any even-numbered agent, that kind of thing), but it detracted from the purity. I'd maybe add it to a hypothetical Spymaster II (a type 2 increment as described earlier), but I don't think it would be a better game for it. I didn't change anything for the physical card version I had made up a couple of years ago.
Having thought this through in my head (I didn't bother writing anything down, it's quite a simple game), I implemented Spymaster in Javascript. I made some interface changes from playtesting (you can bring up the next mission by clicking on any agent, played or otherwise, as that's where your cursor is likely to be when asked), but I didn't make any changes to the gameplay. The gameplay is exactly how I planned it to be.
So that's how Spymaster came about.
Hopefully, this example of how I created a new game that re-used mechanics from two earlier games (one of which was badly flawed) will give some insight not only into how games evolve into new games, but why they evolve the way they do. I saw a mechanic I liked, it had some minor issues, I saw a setting that fitted it, I reskinned it for the setting, I made one improvement to uncramp it and another to better the gameplay for the high-end cards, and that was pretty much that. Yes, the new game is based on Besikovitch's Game, but it's not Besikovitch's Game: it's Spymaster.
Oh, and before I finish up, I suppose you might want to know whether or not I feel guilty about ripping off Besikovitch? Well I don't. My reason: Besikovitch himself ripped the idea off from a traditional Russian card game called Svoi Kozyri.
Games evolve. They always have and they always will.
Latest entries.
Archived entries.
About this blog.
Copyright © 2011 Richard Bartle (richard@mud.co.uk).