Presentation..and Oh Yeah, System and Data
Not much to say currently as the Summer wears on, and other are pressing. The time away from design-work around the 4th of July, which included numerous family birthdays and some craziness at work, made me reposition various hobby projects. I've slowed things down around here, too, mostly for this reason.
Firstly, I've put off KitchenTable for a while. It was starting to drag me down, even though it's really close to a first free-range beta.
Secondly, I've had enough PocketCiv questions and comments that it wanted to start moving on updating that game.
Thirdly, getting KT away from me has led me into working on updating the fixes for Minsterpool for later Hippodice submission in the year.
Anyway, on with my mindless rambling on the topic.
I break games down into having three main components: Systems, Data, and Presentation. A more simpler view of this would be that the System of a game is the rules, the Data is the various elements that can be altered by the System and how they interact with each other with regards to the System, and the Presentation would be the look and feel and theming of the game. Ultimately, a game winds up being an typical Venn diagram of these three main elements.
I've never really spent that much time thinking about this really, until a BGDF post caused me to ponder it. The link to it is right here. For those who don't want to be bothered to click to it, basically someone is talking about a game idea revolving around the player being an Evil Villain, doing evil things in a Trading Card Game format.
And as I read most of his outline, I was left with the impending sense of doom that I usually get from these things. Usually, all I get out of these are Presentation and some Data (obviously a full Data set is pretty much impossible with a quick description), and no System design. Which to me means: There's really nothing new here. It's just new names and faces (Presentation) on cards (Data) that could be easily swapped out from a pre-existing game ruleset (System).
Of course, it always tough to understand the genius of someone else idea without seeing and touching what they are trying to do.
And maybe it's really not so much this game, but a lot of the game overviews on BGDF feel that way to me. Everyone wants to play and create a cool universe (again Presentation and some Data), without much regard about how the laws of the universe work (the System).
"This game is going to be cool because it's set in the Matrix universe."
And maybe that's why I don't post much to the forum anymore.
Everyone gets so hot and bothered by the Presentation and Data, that very few seem to worry about designing the System. It's EASY and FUN to design the Data, I guess. It’s a little bit tougher to design the Presentation (usually the artwork being the biggest thing, but also flavor text and background story). The real hard work for the most part is in the System. Granted, the Data needs to be balanced, so one piece of data doesn't completely overwhelm any other piece of data within the System; but early on, that isn't and shouldn't be the main issue. All that gets worked on in playtesting, or at least, it should.
Ultimately, I personally feel that the initial design flow chart pretty much works like this:
One of the more amusing things regarding this point would be the buildings in Puerto Rico, which look like this:
What happens when you effectively strip away the Presentation, and show you just the Data for each building? It looks like this:
(And, yes, it's meant to be the same picture. The buildings in PR are notably devoid of Presentation).
I know a lot of people complain about it, and others have tried to embellish the small cardboard counters with art to make the game "more immersive":
But it all seems to counter the ease of use. While the addition of the building in the upper right tile does add something without distracting from what the building tile does, the tile on the left adds nothing to the game except for some dark murky picture of a guy, who I presume, runs the indigo plant.
Forcing Presentation on to a game that doesn't need it, or worse, that really needs help in other areas simply doesn't work. It just hides the problem. Most games with a humorous bent fall prey to this trap; that their witty flavor text and absurb Data names will cover up the fact that the game has a weak System to begin with. Well, it sometimes works, until you know the jokes. And then you see what the game is really doing. The Munchkin games are a notable exception to this; while the game parts are funny, the actual game System works well, and is fairly amusing in it's own right.
For examples on the worst kind, where the humor just can't carry the game, many Cheapass Games puddle around in these waters. However, many more of the Cheapass-clone companies are much, MUCH worse.
Games where the Presentation seems to blend effortlessly within the Venn diagram; and in fact, where the Presentation is just as important as the System fairly few and far between in terms of the actual game play and how well it works. But there are exceptions, such as Wallenstein. It's cube tower being a very neat combination of Presentation and System (as opposed to the typical Presentation/Data combination). The Cube Tower IS the combat System.
Pillars of the Earth has a fairly unusual presentation element on the other end of this spectrum that bugs me. Ultimately, the game is supposedly about building a Cathedral in the middle of the board, and it sure does look cool in the pictures.
But as I read over the rules, the Cathedral really is just a simple timer. At the end of each round place a Cathedral piece on the board. I've talked to people who don't even take the Cathedral pieces out of the box.
Unlike Princes of Florence, where you are building various houses for artists in you compound, which is played with simple flat cardboard cutouts where the placement of the "houses" matter, the Cathedral is just saying "Hey, you are on round 2." The presentation of the houses in PoF matter in regards to very important elements of Data and System. The cool presentation of the Cathedral seems to be mostly a reflection of an overall boring (but important) System rule, which saddens me, instead of being more dynamic, and a true point of Data within itself.
And now, a story...
In my previous life working at Williams/Bally/Midway, I was around during the Mortal Kombat explosion. While I wasn't working in the video-game department, it was still fun to watch an enormous hit of a game steamroller itself into the public consciousness.
And with any big hit into a culture, the Fan-Boys grew. And what somewhat interesting, with the birth of the internet and widespread video game magazines, was that it was fairly easy to call up Midway, and ask for one of the designers of the game at phone central (the little old lady who sat in the booth in the plywood decorated waiting "room" (last updated in 1965) at the front door.
And she would just forward them on.
And at some point, the designer got a little fed up with wasting his time dealing with the Fan-Boys. He's a nice guy, and really tried to be nice to everyone, but he had work to do. And so he would forward these calls occasionally up to where I was at the time to a guy named Jeff. And I listened in on one of the calls.
Anyway, the caller was all set to be a co-designer on the next version of Mortal Kombat. He had all these great exciting ideas for the game; back-stories, characters, special moves, etc.
But he didn't understand how all this ties together within a system. Sure, pressing a punch button that rips of a guy head, that flies up into the air, with the "camera" following it, then it comes back down through the opening in his neck, and then explodes, is all cool I guess. But, at that time, the game system couldn't handle that kind of thing IN THE MIDDLE OF THE GAME graphically. Plus, an in-game fatality would pretty much severely un-balance the game structure that had been created at that point. Not that you couldn't add it in somehow with a balancing mechanism; but the desired structure of how the system worked was there, it worked, and didn't need a complete overhaul.
(Actually, I think there was a game where you could deliver "fatal blows" in the middle of the game; it was Time Killers.)
And of course, a lot of his presentation revolved around Animalities (where the characters would turn into animals for a fatal kill), and other "fluff" things that, while interesting and add to the package, aren't really a part of the game and how it works itself. But these were all the FUN things he had cooked up; and the design team had plenty of fun things on their own minds. All the fun Data that you want to work on while you are toiling away to figure out how to make a balanced system regarding the use of "juggles" (a feature where you can do multiple timed hits on your opponent keeping him up in the air like a hackey-sack), without having it become abusive.
Anyway, we convinced him that the next Mortal Kombat game was going to include Furnituralities, where the characters would turn into office furniture for a final blow.
"Look! I just made Johnny Cage turn into a file cabinet, and then it fell on the other guy. THAT ROCKS!"
I think that this is why people on BGDF that I talk with and have a lot of respect with, seemingly never start on their dream project: you sort of know what the final project is and the Data you want to use (that rockin' Role Playing Game in the NASCAR universe or something), but there is no thought on the system to incorporate all the Data into a useful, thoughtful process.
In other words, "Where do I begin?"
And my response to this is (as I've told some amount of designers), "Just start designing." Make a rough board layout, try to figure out your stats, whatever. But I think the important part here is that you don't go around and design 500 different car specs for that ZOMBIE NASCAR RPG. Design 1 or 2 with the stats that you want to deal with; design a rough world. Get a rough System in place that can manipulate that Data.
And then refine the System. Add a few more cars, and see if these cars break the System. Fix the Data if it doesn't work, and refine the System further.
And pretty soon you'll be at the fun part, where it's all about creating the Data and Presentation. If the System works.
It's more important that the System works without the Presentation. And this is why it's important to build a game with as little regard to things like flavor text and wacky names as possible initially. There's nothing wrong with including this kind of stuff in the design as you go to keep you interested; but don't focus on it exclusively.
Firstly, I've put off KitchenTable for a while. It was starting to drag me down, even though it's really close to a first free-range beta.
Secondly, I've had enough PocketCiv questions and comments that it wanted to start moving on updating that game.
Thirdly, getting KT away from me has led me into working on updating the fixes for Minsterpool for later Hippodice submission in the year.
Anyway, on with my mindless rambling on the topic.
I break games down into having three main components: Systems, Data, and Presentation. A more simpler view of this would be that the System of a game is the rules, the Data is the various elements that can be altered by the System and how they interact with each other with regards to the System, and the Presentation would be the look and feel and theming of the game. Ultimately, a game winds up being an typical Venn diagram of these three main elements.I've never really spent that much time thinking about this really, until a BGDF post caused me to ponder it. The link to it is right here. For those who don't want to be bothered to click to it, basically someone is talking about a game idea revolving around the player being an Evil Villain, doing evil things in a Trading Card Game format.
And as I read most of his outline, I was left with the impending sense of doom that I usually get from these things. Usually, all I get out of these are Presentation and some Data (obviously a full Data set is pretty much impossible with a quick description), and no System design. Which to me means: There's really nothing new here. It's just new names and faces (Presentation) on cards (Data) that could be easily swapped out from a pre-existing game ruleset (System).
Of course, it always tough to understand the genius of someone else idea without seeing and touching what they are trying to do.
And maybe it's really not so much this game, but a lot of the game overviews on BGDF feel that way to me. Everyone wants to play and create a cool universe (again Presentation and some Data), without much regard about how the laws of the universe work (the System).
"This game is going to be cool because it's set in the Matrix universe."
And maybe that's why I don't post much to the forum anymore.
Everyone gets so hot and bothered by the Presentation and Data, that very few seem to worry about designing the System. It's EASY and FUN to design the Data, I guess. It’s a little bit tougher to design the Presentation (usually the artwork being the biggest thing, but also flavor text and background story). The real hard work for the most part is in the System. Granted, the Data needs to be balanced, so one piece of data doesn't completely overwhelm any other piece of data within the System; but early on, that isn't and shouldn't be the main issue. All that gets worked on in playtesting, or at least, it should.
Ultimately, I personally feel that the initial design flow chart pretty much works like this:
A) Develop brainstorm of the world you want to have the game in (Presentation)
B) Develop basic rules structure (System), with small amount of Data to test it.
C) Tweak System and add more Data as various Systems are refined.
D) Finally go back and flush out the Presentation. Add mucho Data. Make sure additional Data doesn’t break the System.
It typically scares me when chatting online with the geeks on BGDF, especially cases where people have developed 500 different card types without ever testing the System yet. That just seems like a lot of wasted effort there. And, I would guess, a big “falling in love” with the theme (and the elements it brings), which is a common trap in designs.
Sometimes, the game tells you where to go. Other times, you tell the game where you want it to go. Usually, the latter is a mistake. Trying to force stuff into a game System that doesn’t want it or require it usually makes a mess of game. You are much better starting with the System first, plug holes in areas where the System needs it.
Hence, DON’T design 500 cards first before you even try to play a game.
One of the more amusing things regarding this point would be the buildings in Puerto Rico, which look like this:
What happens when you effectively strip away the Presentation, and show you just the Data for each building? It looks like this:(And, yes, it's meant to be the same picture. The buildings in PR are notably devoid of Presentation).I know a lot of people complain about it, and others have tried to embellish the small cardboard counters with art to make the game "more immersive":
But it all seems to counter the ease of use. While the addition of the building in the upper right tile does add something without distracting from what the building tile does, the tile on the left adds nothing to the game except for some dark murky picture of a guy, who I presume, runs the indigo plant.
Forcing Presentation on to a game that doesn't need it, or worse, that really needs help in other areas simply doesn't work. It just hides the problem. Most games with a humorous bent fall prey to this trap; that their witty flavor text and absurb Data names will cover up the fact that the game has a weak System to begin with. Well, it sometimes works, until you know the jokes. And then you see what the game is really doing. The Munchkin games are a notable exception to this; while the game parts are funny, the actual game System works well, and is fairly amusing in it's own right.
For examples on the worst kind, where the humor just can't carry the game, many Cheapass Games puddle around in these waters. However, many more of the Cheapass-clone companies are much, MUCH worse.
Games where the Presentation seems to blend effortlessly within the Venn diagram; and in fact, where the Presentation is just as important as the System fairly few and far between in terms of the actual game play and how well it works. But there are exceptions, such as Wallenstein. It's cube tower being a very neat combination of Presentation and System (as opposed to the typical Presentation/Data combination). The Cube Tower IS the combat System.Pillars of the Earth has a fairly unusual presentation element on the other end of this spectrum that bugs me. Ultimately, the game is supposedly about building a Cathedral in the middle of the board, and it sure does look cool in the pictures.
But as I read over the rules, the Cathedral really is just a simple timer. At the end of each round place a Cathedral piece on the board. I've talked to people who don't even take the Cathedral pieces out of the box.
Unlike Princes of Florence, where you are building various houses for artists in you compound, which is played with simple flat cardboard cutouts where the placement of the "houses" matter, the Cathedral is just saying "Hey, you are on round 2." The presentation of the houses in PoF matter in regards to very important elements of Data and System. The cool presentation of the Cathedral seems to be mostly a reflection of an overall boring (but important) System rule, which saddens me, instead of being more dynamic, and a true point of Data within itself.
And now, a story...
In my previous life working at Williams/Bally/Midway, I was around during the Mortal Kombat explosion. While I wasn't working in the video-game department, it was still fun to watch an enormous hit of a game steamroller itself into the public consciousness.
And with any big hit into a culture, the Fan-Boys grew. And what somewhat interesting, with the birth of the internet and widespread video game magazines, was that it was fairly easy to call up Midway, and ask for one of the designers of the game at phone central (the little old lady who sat in the booth in the plywood decorated waiting "room" (last updated in 1965) at the front door.
And she would just forward them on.
And at some point, the designer got a little fed up with wasting his time dealing with the Fan-Boys. He's a nice guy, and really tried to be nice to everyone, but he had work to do. And so he would forward these calls occasionally up to where I was at the time to a guy named Jeff. And I listened in on one of the calls.
Anyway, the caller was all set to be a co-designer on the next version of Mortal Kombat. He had all these great exciting ideas for the game; back-stories, characters, special moves, etc.
But he didn't understand how all this ties together within a system. Sure, pressing a punch button that rips of a guy head, that flies up into the air, with the "camera" following it, then it comes back down through the opening in his neck, and then explodes, is all cool I guess. But, at that time, the game system couldn't handle that kind of thing IN THE MIDDLE OF THE GAME graphically. Plus, an in-game fatality would pretty much severely un-balance the game structure that had been created at that point. Not that you couldn't add it in somehow with a balancing mechanism; but the desired structure of how the system worked was there, it worked, and didn't need a complete overhaul.
(Actually, I think there was a game where you could deliver "fatal blows" in the middle of the game; it was Time Killers.)
And of course, a lot of his presentation revolved around Animalities (where the characters would turn into animals for a fatal kill), and other "fluff" things that, while interesting and add to the package, aren't really a part of the game and how it works itself. But these were all the FUN things he had cooked up; and the design team had plenty of fun things on their own minds. All the fun Data that you want to work on while you are toiling away to figure out how to make a balanced system regarding the use of "juggles" (a feature where you can do multiple timed hits on your opponent keeping him up in the air like a hackey-sack), without having it become abusive.
Anyway, we convinced him that the next Mortal Kombat game was going to include Furnituralities, where the characters would turn into office furniture for a final blow.
"Look! I just made Johnny Cage turn into a file cabinet, and then it fell on the other guy. THAT ROCKS!"
I think that this is why people on BGDF that I talk with and have a lot of respect with, seemingly never start on their dream project: you sort of know what the final project is and the Data you want to use (that rockin' Role Playing Game in the NASCAR universe or something), but there is no thought on the system to incorporate all the Data into a useful, thoughtful process.
In other words, "Where do I begin?"
And my response to this is (as I've told some amount of designers), "Just start designing." Make a rough board layout, try to figure out your stats, whatever. But I think the important part here is that you don't go around and design 500 different car specs for that ZOMBIE NASCAR RPG. Design 1 or 2 with the stats that you want to deal with; design a rough world. Get a rough System in place that can manipulate that Data.
And then refine the System. Add a few more cars, and see if these cars break the System. Fix the Data if it doesn't work, and refine the System further.
And pretty soon you'll be at the fun part, where it's all about creating the Data and Presentation. If the System works.
It's more important that the System works without the Presentation. And this is why it's important to build a game with as little regard to things like flavor text and wacky names as possible initially. There's nothing wrong with including this kind of stuff in the design as you go to keep you interested; but don't focus on it exclusively.
Labels: Data, Design, Presentation, System
posted by Unknown at 10:49 AM
0 comments
