Blog - Design Via Fantasy, and Player Expectation
Tuesday, July 15, 2008Brenda recently wrote an entry about designing a game based on a player fantasy. In other words, you think "who might a player want to be?" and build a game that lets them be that person. For example, a common fantasy is to be a rock star. Design a game with that fantasy in mind and you have Guitar Hero and Rock Band. Another fantasy is to be a hero, and save the world.
Lots of games fulfill that fantasy for you. Combine the rock star fantasy with the save-the-world fantasy and you have something like Fret Nice. ;)
I have made a few recent observations about the games I've been playing lately and how they relate to player fantasy.
The first observation was that even though it's a somewhat negative fantasy, it's that player-fantasy element that kept me playing the online flash game Motherload.
There's something about that game's player fantasy (you're the last "living" thing left on an abandoned colony on Mars, sent to continue their mining business) that keeps drawing me in. In real life would I like to be that guy (er, robot)? Hell no. But in terms of a game fantasy role, I find it strangely engaging.
We had talked in one of Brenda's classes about making games tie in to elements from your childhood memories. I think the premise of Motherload seems very close to one of those childhood memories of mine, hence why I find it so compelling. When I was younger, on nights where I was too cold to sleep I would make my comforter and blankets into a small igloo shape and hide inside, huddling for warmth, pretending I was an arctic explorer that had been separated from my team during a blizzard. Even though I wasn't actively doing anything but trying to sleep, it was fantasy play, pretending that I was just trying to survive the cold for the night. So, if I "played" with that fantasy, the fantasy of Motherload as the lone mining robot on Mars isn't too far of a stretch from that.
(As I haven't mentioned yet but fully intend to one of these days, mere survival is my favorite motivation in games.)
My other observation on player-fantasy stems from when I was recently playing Evil Genius. Something in me, I think the game designer part actually, loves the fantasy of being an evil madman, devising devious traps for my lair of villainy. I think part of the reason I wanted to become a game designer is because back when I was a kid playing the Megaman series of games I always thought the evil genius villain Dr. Wiley was having all the fun. He was making crazy levels filled with traps and enemies that Megaman had to fight and escape. I would even draw elaborate levels out on paper, pretending I was Dr. Wiley designing a new hideout. It turns out that all those devious traps and enemy placement were actually the work of game designers... ;)
In any case, that player fantasy caused me to pick up Evil Genius. Don't get me wrong, it's a fun game. The problem with it is that it takes way too long to deliver the parts of the game I associate most strongly with that fantasy!
It's a problem of player expectation.
When picking up that game I wanted to make death traps and crazy science laboratories where I'd make man eating plants or new death traps, etc.
The game lets you eventually do both. The key word there was eventually.
The traps they give you at the beginning of the game, however, are fairly boring. You can unlock more by researching with evil laboratories but it takes far, FAR too long into the game to get to the point where you can build evil laboratories!
My (player) expectations were not met until after several DAYS of playing the game.
I wanted evil labs from day one. When I think "Evil Genius" I think of evil laboratories and mad scientists. Thanks for hooking me in the first 5 minutes, game.
So, there's the main observation on designing by player fantasy: you must very carefully think about what the player expectation of that fantasy is before you proceed. Designing by player fantasy means your game hinges on player expectations. You need to deliver that fantasy.
Evil Genius did, but takes hours of frustration to get there.
Motherload, however, sold me the fantasy from the instant the game began.
Evil Genius, however, picked what I can probably safely say is a much more common and popular fantasy.
When working on a recent student game project at SCAD (a tabletop RPG) our team did an early exercise on player expectations before writing any actual rules. We established at least an early framework for our game's world and its inhabitants and then made up characters of our own for it. We then proceeded to play a quick adventure with our characters, making up rules when needed. This exercise was to explore what we as at least a few early playtesters expected to be able to do in this particular game world. If a player wanted to do something that wasn't yet addressed, we could then actually write it into the final game. It was an interesting way to deal with the problem of player expectation.
Labels: design, player expectation, player fantasy
posted by Brian Shurtleff @ 2:14 PM 0 Comments Links to this post
Blog - "There IS no ahead-of-schedule!"
Thursday, July 10, 2008A few days back some of my students claimed to be ahead of schedule because they had completed already by the day before all their milestones we had set for the day.
One of my fellow instructors pointed out to him "In game development, there is no ahead-of-schedule. Go and finish it, or polish the hell out of it if it's content complete."
In any case, it is surprising how well the students are doing this session. There is one exception: a team with multiple producers and leads who fought and argued constantly (they apparently each had their own, different, design documents they had made...) was one we were concerned would not finish. Apparently it's 'nearly complete' according to their team, although I can't imagine it has any kind of polish on it at all as was pretty rough (to put it kindly) when we last saw a build just two days ago.
But other than that, the teams barely had to crunch on their provided "crunch-night" last night. Even with the fact that most of the instructors weren't around (It fell on the same evening as the Boston Postmortem).
One team was (and this is unprecedented) content complete several days ago, and they have just been tweaking and polishing for a while now. That team contained several of those students I mentioned in my last entry: every opportunity for free time available to them, they still worked on their game anyway, rather than LAN gaming with the rest of the kids. Their game was already better by day 2 than the final product of any 1-week session of camp yet.
Even more average teams, however, are surprisingly close. Before crunch officially started, one team only had a few things to add (loading screens, eliminating critical bugs from one of their weapons...) A third team only had a problem with one cutscene not loading correctly. We usually have at least one team working until 5am on crunch night, but last night we packed up and had left by 2am.
Perhaps this batch is just more hard-core about game development. Maybe they were just driven to make better games than those we showed them from the students they came before them. Or maybe we've just gotten better at scaring them into actually finishing their games early so they can work on polish. ;) posted by Brian Shurtleff @ 2:20 PM 0 Comments Links to this post
Blog - Designers vs Gamers
Tuesday, July 1, 2008Game designers find making games more enjoyable than playing them.
I'm sure that by this point this is true at least for me. Keeping up on my game playing almost seems like more work to me than my game design projects.
This dynamic of being a game designer first and a gamer second, however, is something I notice is lacking in most of my students in the EGD camp sessions I've taught.
Most of them can't wait for our lectures on how to use the tools to be over so they can have more free time to play games on the LAN with each other. In fact, a few of them are probably playing games during our lectures.
On one hand, this doesn't bother me as much as you might expect. We see our program as a great way for high school students to determine if a career in game development is right for them before they start college.
This is certainly valuable, if true, as I see a lot of people enter the game development major at SCAD who just don't make it once realizing early on that it's not what they expected. Lots of students like games, and think making them would be fun. It is, if you're into it, and don't mind how much work it is. Neither is necessarily true for most people.
So if these kids come to this camp and realize that they'd rather play games than make them, then I suppose we've done our job. The price tag for this camp is rather expensive for a camper to decide they'd rather spend it all playing LAN games, but then again the price their parents are paying is still nothing compared to the cost of finding out the same thing as a University student.
So, it shouldn't bother me. For the most part it does not. Even so, there's a part of me that finds it a little disheartening. For one thing, even if they find out they don't like it, they still are stuck making a game with other students. They all have to work on a game which gets judged by industry folks. That means that when my students put as little work as possible into their game, just so they can get back to playing, I'm pretty embarrassed and angry when it gets presented to game developers I respect and admire.
On top of that though, I just feel a little sad that the kids don't see the same magic I've found, where making games IS more fun than playing them.
So, it makes me happy when a few of them do find that magic.
This session we have one camper who spends all his free lab time just playing with the level design tool we have, once we showed him how to use it. Especially after lectures where I show them more on that tool, a few keep playing around in it, exploring the possibilities. One called me over to test out the level he'd made, using a few of the tricks and techniques I had taught.
I love that. posted by Brian Shurtleff @ 11:17 PM 0 Comments Links to this post
Blog - Business-Sim Makes Everything More Interesting...
Wednesday, June 18, 2008Well, it's official: I'm addicted to playing with the Spore Creature Creator.
My students are a little alarmed with how many creatures I've made already just today.
What can I say? My designer mind means I have to play with, explore, and test every possibility ...
Plus I'm a sucker for any game with a good character creation system.
However, prior to that, one game I was picking up again under a perhaps false claim of 'research' was Evil Genius.
(I'm also a sucker for Dungeon Keeper style games, playing the villain and setting devious traps... after all, the game play of those kinds of games is strangely like the more fun parts of level design...)
How is it research? Well, I've been toying with (in my head only, so far) a very similar game. The major difference being that my idea is about superheroes rather than supervillans.
See, I've determined I like to freshen up any genre by blending it with the business-sim game genre (or "tycoon game," if you will). Since supervillain business-sim was basically already taken, I decided to snatch up the next best thing and try for the superhero angle.
Even cliché styles and genres (like, well, superheros) can be given a little bit of unique interest if you consider doing an economics simulation out of the topic rather than the obvious. For example, there's tons of zombie-shooters out there, but nothing as wacky and quirky as a game where you manage a company that hunts zombies for profit or something. (My mind was kind of stretching there in an attempt to combine "zombies" with business-sim...)
In short, I find the business-sim is my go-to game genre when I want a little more originality and quirkiness when thinking through a game concept.
Labels: business-sims, design
posted by Brian Shurtleff @ 6:45 PM 0 Comments Links to this post
Blog - Frustrations in Hapland
Monday, June 16, 2008Getting some gaming done here at camp can be a bit tricky, as while I'm watching over my students I can't exactly be playing on a console. There's also a lack of television sets to plug one into here anyway. However, as was suggested in a comment at Brenda's blog not long back, all the various online flash based-games are very available to me. I do spend all day at a computer lab with this job, and flash games are generally 'casual' enough that I can take frequent breaks for answering questions and patrolling the lab to ensure the students aren't lost in their work (or playing games when they shouldn't be, etc.)
Interestingly, right on cue for that observation, one of my coworkers directed me to a site with some flash puzzle-based games he liked: the farcade at foon.co.uk.
He in particular directed me to the Hapland puzzle series there.
Having played them, I think it's a case of the game designer having more fun than the player. The first one I had at least mostly figured out on my own. The only reason I didn't solve it was I didn't understand that certain parts of the puzzle required the timing of simultaneous events. It eventually drove me insane enough that I just looked up the solution. I can't say if I would have figured it out eventually or not, but on seeing the solution to the first game I didn't feel cheated except for one small part that seems to defy my expectations of physics a little bit. Some of the parts I was stuck on involved phenomena I had observed, which made me feel in retrospect like I should have figured it out had I thought about it in a different way. That, I feel, is a great place to be in puzzle design. I don't mind being horribly confused, as long as I don't feel cheated, and instead feel dumb that I didn't think of something that in retrospect seems logical or obvious.
I started the next one however and it was even harder and more frustrating. Eventually I fell to using a walkthrough for that one as well. That one contained a few portions I don't think I would have figured out on my own at all. There are some problems with communication to the player in that one, in my opinion.
From reading the walkthrough though and completing the game just through a walkthrough, I realized that sadly I had more fun doing that than actually racking my brain to solve the puzzle. Maybe I'm just not the puzzle type, but I found the puzzles of this particular game just too frustrating.
Going through it in the walkthrough I got to see the pieces all fit together cleverly and the 'story' advance to its conclusion. That would make for a great thriller movie, perhaps, but as a game I just wish I could have been able to experience that without cheating. I got to see the fun the designer must have had, crafting such an intricate puzzle, with hilarious animations, that all follows a sort of story... but I didn't have fun playing it.
Labels: design
posted by Brian Shurtleff @ 8:50 AM 0 Comments Links to this post
Blog - Design Challenges: Unusual Materials
Tuesday, June 3, 2008Sorry for the lack of posting lately. Technical difficulties continue to plague me.
However, in a few days I'll be working at Emagination again, and will have enough free time around computer labs there to post nearly every day again.
In any case, one thing that's come up since I last wrote here (and has been rattling around inside my head again today) was finals. One team's final presentation on their game in one of my classes (Brenda's "Abstract Systems Simulation" course) has me thinking about an interesting thing to play with in my game design experimentation.
The team realized that due to one of their game's player classes (which 'moved' by merely multiplying itself to fill more squares of the game board) that the number of tokens they'd need for that class alone was astronomical. So, they devised a really cunning solution: they constructed a mold, and the game materials in the box consist of a couple of these molds plus various colors of clay.
Players use these to make their own tokens for the game by ripping off a tiny portion of their blob of clay and pressing it into the appropriate part of the mold to mark it as whatever kind of token they may need.
Not only is it clever solution to their problem, our class thought about it and realized clay is rarely used in games, which seems almost odd given as it is a staple of playtime in children. Smooshing clay around is itself strangely fun, and board games in particular almost demand a high degree of tactile stimulation for the players.
Playing with clay is a very tactile sort of fun, so it would seem to fit naturally.
And yet, the only commercial game we could think of that involved it at the time was The Grape Escape. A peek further into boardgamegeek reveals a few more games that involve clay, but not many. (I found less than 10...)
So, I think I might invest in some Play-Doh and experiment with some clay-based mechanics.
A few were predictably just a sort of sculptural charades game: sculpt an object or whatever instead of drawing it or acting it out while people guess what it is.
However, a fun twist on that mechanic was the mechanics used in Barbarossa and Cluzzle, where you have to make a sculpture that is just ambiguous enough as to what the hell it is. Too easy to guess and you lose points, but if NOBODY gets what it is, you also lose points.
Clay-O-Rama and its expansion set have some fun clay mechanics as well, what with the way you sculpt your character affecting how it acts in the game, and then the fun of getting to literally squish your opponents.
All of this, however, reminds me of an earlier note I had scribbled down for myself: "Design Challenge: Make a game using tape."
I have no idea what was in my head when I wrote that, but I bet there are quite a lot of neat game ideas one can invent using all the properties of tape.
Plus, everyone usually has tape laying around the house...
One term that's come up in my game studies that I hear is more academic in nature and not actually used in industry is the concept of affordances, which are the properties of an object or material. For example, present the player with glass and he's going to assume he can look through it, and shatter it in a giant crash of shards.
Affordances seem to be a great starting point for random design challenges.
Last summer at Emagination, in order to teach myself the FPS-making package our students use, I enjoyed playing with the physics engine and designed a puzzle game based entirely around the affordances of hand grenades. No enemies to blow up, instead you used your infinite number of grenades to solve puzzles: blowing open doors, tossing grenades to places you couldn't reach to activate/move objects to a place where you could, etc.
Of course, that was a case of virtual materials. Thanks to all the non-digital prototyping done in my design classes at SCAD I think I'll play around with the affordances of some real-world materials and how they can be used in games.
Labels: affordances, challenges, design
posted by Brian Shurtleff @ 11:23 AM 0 Comments Links to this post
Blog - Design Tips: Mercy Killing
Monday, May 19, 2008Sorry for a lack of posting here.
My cable (internet and television) has been down for a week now at my house and my cable provider fails to show up any time I set up an appointment for them to come figure out what's wrong.
I'm currently posting from a computer lab at SCAD.
Anyway, it's time for another design tip:
"Mercy Killing is the Law (Don't put band-aids over crap)"
If something isn't working in your prototype/design, and attempts to fix it are going nowhere, then get rid of what's not working before you waste any more time. This is also known as the mercy-kill: just let it die, as it's for the best.
Brenda often uses the great line "don't put band-aids over crap" to put another metaphorical spin on the mercy-killing concept. You can try to fix it all you want, but everyone will still be able to know that underneath all your fixes: it's still crap. It's especially bad as often fixes will throw other dynamics out of whack, and trying to fix that will require more fixes which break something else, etc. etc.
Now, throughout my time as a game design student here at SCAD I've had a handful of projects where I took this mercy-killing 'law' to the extreme: what I will, for a lack of a better term, refer to as the total systems implosion. Where you kill so much of the game you basically start over.
A great example was Artificial Evolution, where we recognized that our alpha milestone was basically upon us already and the game's core system wasn't working.
It technically worked, or we wouldn't have gone that far along, but the process of writing it into the design document let us see how bloated and clunky the system was.
So we decided to kill it, our core system, and redo it in a newer, smoother, intuitive way. It nearly killed us, but the effort (and loss of sleep) was worth it: the game was much better once the core was rehashed into something that wouldn't take an engineering degree to play. That game was the one from our class picked by industry designers as the best project produced, so we must have done something right!
Well, the same thing just happened in a current project of mine: We switched our tabletop RPG's combat system from one that involved dice rolls and a bidding system to one that involves a CCG. The best part of it all is that the old system worked great and was even pretty fun: fairly innovative, involved plenty of strategy, and worked smoothly enough.
It was just, as we all felt, a little more complicated that it should have been (particularly for our target market) and plus we liked the novelty of a CCG-based tabletop RPG and the initial prototype of it seemed just slightly more fun (just as strategic but more intuitive and fast-paced.)
Unfortunately, switching to cards basically meant throwing out our entire game and starting over: our old player stats didn't fit neatly with card-based mechanics.
We basically tossed our past month-and-a-half's worth of effort and did it over again (differently, better) in the span of only two very crunch-y evenings.
Because we rock. ;)
As terrifying as it is each time (apparently I've caused total systems implosions on 3 different projects now...) the mercy killing has always proven valuable and in the end rewarding.
Especially so on the student level, as it lets me try out variations in design and encourages me to push my limits, designing with more speed and efficiency.
In this way it is similar to giving oneself regular 30-minute/1-hour "design challenges", which are great exercises for aspiring designers.
So remember kids, in game design mercy-killing is the law, and don't put band-aids on crap.
Labels: design, design tips, mercy-killing
posted by Brian Shurtleff @ 5:06 PM 0 Comments Links to this post
Blog - Wonderful Imbalance
Tuesday, May 6, 2008Today our class discussion was on balance. In particular, it was on not making games so balanced to the point that they aren't fun.
(Someone in class provided the useful example of tic-tac-toe to explain how a game can be so balanced as to be boring.)
We were asked to experiment with a small game design challenge, expected to push past our desire to balance a game completely.
My team made a neat little pseudo-educational game about sub-atomic particles forming into atoms ("I use my protons to steal your electrons!") which could be interesting given more development time.
In any case, the gist of Brenda's point with the experiment was along the lines of the design tip I hijacked from her and wrote about in an earlier entry.
In brief: players want to have noticeably powerful effects over a game. It's fun to achieve godly powers in a game and completely obliterate everyone. Equally powerful are times when you overcome seemingly impossible odds stacked against you (beating the Dragonforce song on expert level, for example…)
Now, just a few minutes ago I was recounting to someone a gaming story I'm particularly proud of: the time I beat Fallout without ever entering combat or killing anything (as far as the game was concerned...)
This game session didn't have anything to do with balance issues.
However, it did have to do with how broken the game's combat system was: I achieved my feat of a perfect pacifist/stealth run through the game only thanks to heavy exploitation of flaws with the combat system.
I'm wondering, then, to what degree these two examples/phenomena are similar?
In the former example, a game is made more fun by being a little broken in the balance department (fun BECAUSE of its imbalances!)
In the latter example, I had a blast with a game that had a broken system (specifically having a blast with that system's very brokenness!)
---
In a related note of both design challenges and big guns, I submitted an entry to this week's James Portnow's Game Design Challenge, which asks participants to design, well... a new gun.
Results will be made available in a week.
Labels: design
posted by Brian Shurtleff @ 9:45 PM 0 Comments Links to this post
Blog - Constructing The Sample Adventure:
Friday, May 2, 2008I'm currently tasked with the job of making a sample module for my team's tabletop RPG.
My lead gave me some pointers on how to construct the module in such a way as to actually teach the players how the game works, easing them into the systems in increasing complexity.
I noted, along with Brenda, how closely his advice rang true to the Valve model of game design.
[Here's my brief summary of the Valve model, for those unfamiliar: 1.) Show the player something new they'll need, often letting them see it used by someone/something else. 2.) Let them use it in a no pressure, sandbox-like situation 3.) Have them use it under light pressure 4.) Expect mastery of the new technique/tool.]
I guess I had never thought of the Valve model as being relevant for use in a tabletop RPG, but it is indeed brilliant.
Especially so, as at least currently our game is on the over-complicated side.
The system is still quite elegant, but decidedly over-complicated, particularly given the target market for our design goals.
Having the sample mission that comes with the game designed in a way that cleverly, subtly, gets players comfortable with their character sheets, then role-playing, rolling for skills, and finally upping the ante with some light combat...
...well, that'll be a very useful tool indeed in getting our potentially tabletop-n00b players comfortable with the game.
This is, for the record, another instance where writing and design collide in a particularly fascinating way. I'm tasked with writing the events of the story in such a way that its organization eases the player gently into increasingly more complex systems. Ah, narrative design...
Labels: design, tabletop RPG, valve model, writing
posted by Brian Shurtleff @ 8:03 PM 0 Comments Links to this post
Blog - "The Artist's Wound" and Games
Thursday, May 1, 2008Prior to transferring to SCAD, I attended the University of Wisconsin, Oshkosh for a few years as a film student. For both of those two years, I lived in a special art community in the dorms: a special floor of one building at least partially reserved for self-professed artists of all varieties, so like-minded folks could live together and collaborate.
In order to be in the program, however, you had to take a special class which was on being an artist.
Strange topic for a class, but it was filled with some very interesting content I keep finding coming up again and again.
Particularly since switching into game development, it seems.
For example, that course first introduced me to Csíkszentmihályi's concept of "flow", and the different types of intelligence. Both of which I've seen come up again on many occasions in my game design studies.
One concept I learned in that class, though, that has been most enlightening to me and that I've used by far the most is the concept of "The artist's wound".
(Perhaps it's not a widely used term, or I'm accidentally using the wrong one, as a quick google/Wikipedia search for it didn't turn up anything. Hmm...)
In any case (name aside) it is an unresolved issue in an artist's life that they turn to in their art to try and figure out, time and time again.
Each time it comes up in their art it is a different iteration of trying to sort out their feelings about this "wound".
Not every artist has one, mind you, and ones that do sometimes don't recognize it, although do notice they seem to keep redoing the same themes over and over again.
After learning about it, I began to notice reoccurring themes running throughout my writing, visual art, and music. I actually have written down a whole list of all the common iconography that pops up in my work, and what I think it means. I've since turned that which was unconscious into something I can consciously use.
I don't want to get into what those themes are, or what my wound is, here. That's rather personal and not the point.
The point, as this is my game development blog, is that I've noticed that my wound never makes its way into my game designs, like it does with all the other kinds of art I do.
I find that a bit odd. Perhaps troubling.
My current theory as to why is rather positive, however: because, perhaps, game design is still so new to me, there's still so much for me to explore with systems and mechanics themselves. I'm still far more interested in exploring them in their general, basic forms than I am with having to explore them relative to my personal demons.
Of course, maybe it is also because making a game about ones demons implies making a game that isn't fun, and generally one makes games that are meant to be fun.
My wound deals in some ways with the idea of never finding satisfaction, and never reaching one's goals. Certainly feasible to pull off with game mechanics, but it wouldn't make for a very fun game.
However, I'm at an art school. We can get away with, and are sometimes encouraged to, make art games that "aren't fun" while we still can.
As I said above, earlier, once I began to analyze the unconscious iconography of my own wound, I was able to then use them deliberately as symbols. I always love when I start to notice the trademarks of an artist, following the patterns in their body of work. It's like finding the underlying patterns in a game: the very "fun" of gameplay.
By employing this iconography I can leave traces of just such a pattern of my own.
However, that brings up a troubling issue: being collaboratively created, games make it difficult for any one designer or artist to employ their wounds or any kind of signature trademark. They can be subtle, and slip them in there now and then, sure. When something needs to be changed or cut, however, and people start asking why you used that particular imagery...
...well, it could be hard to explain to the rest of the team why your wound should stay.
So wounds are, perhaps, too personal for the realities of game development.
There are very few designers who have been allowed to have noticeable "trademarks" running throughout the body of their work, and I'm not sure if I recognize any as a wound even then.
I find this curious, and even a little sad, as knowing my wound and playing with it has taken my art in a lot of interesting new places, and produced some of my most powerful work. I'd like to be able to utilize some of that power in my medium of choice, without having to feel guilty about disguising it, hiding it from the rest of my team. posted by Brian Shurtleff @ 2:26 AM 0 Comments Links to this post
Blog - My friend's experimental SHMUPS
Monday, April 28, 2008One of my coworkers from Emagination sent me an interesting little simple game prototype he's working on.
It's a SHMUP with a unique twist: while flying around, shooting enemies and dodging their massive storm of bullets as in SHMUP tradition... the player can also draw on the screen (a string of pixels that almost forms a solid line) where each pixel is a little miniature shield that can block attacks. In other words, it's a SHMUP where you draw shields wherever and in whatever shape you need at that moment. (They don't last very long, so you're almost constantly drawing.)
As one could predict, the difficulty curve is quite steep as your focus is trapped having to shift between traditional SHMUP play of moving/shooting and the new drawing mechanic - or, in control terms, between WASD keyboard commands and the mouse.
It's currently only a very early prototype, though, so we'll see if he can eventually eliminate or at least reduce this problem.
In any case, this "combine keyboard with mouse play" idea was his starting thought experiment behind the project, so hopefully it works out.
Along similar lines (SHMUP that includes mouse as well as WASD play), another idea he had for a future game is a SHMUP where instead of shooting, players create portals to teleport the enemy's own attacks into themselves.
Basically, Portal meets a SHMUP. That also would seem to benefit from less split-focus problems if the player didn't have to worry about shooting in the traditional sense, and only playing with the new portal mechanic on top of movement.
On an only vaguely related topic, I have decided that the game I would most like to see a Portal-like mechanic implemented in is the GTA series. Think of the all new brands of mischief you could cause... *eg*
Labels: design
posted by Brian Shurtleff @ 12:01 AM 0 Comments Links to this post
Blog - The Art of Game Design...
Tuesday, April 22, 2008I just thought of this now, so perhaps it is still a bit ill-conceived yet given I just thought of it, and its late, and my work has been sapping sleep from me all this quarter so I'm somewhat mentally exhausted...
...but I devised an interesting formula to define art:
Art reveals, via some means, truth that it takes an artist to "see".
This formula came about as a result from trying to explain to someone what I've learned in drawing classes before, so I'll start with drawing as a model:
the art of drawing reveals, via rendering, the truth of how something actually looks (or would look, if real), that it takes a trained artist to see instead of how the mind actually perceives it visually (which is, for the record, distorted in order to process the visual data more easily...)
As another example, the art of music reveals, via performance, emotional truths it takes a musician to "hear" as composition of musical sound.
(I don't mean to imply, by the way, that a drawing can't reveal emotional truths too...)
Storytelling reveals, via a narrative, universal human truths, etc.
But now to try a fun experiment: Let's put the art of game design into the formula!
First, how do games reveal their "truth"? That's the easy part:
Games reveal their "truth" through the dynamics created when the players interact with mechanics.
The last part of the equation (the artist) is also not hard to find: the game designer is the artist in question here.
But what "truth" does game design reveal?
That's a trickier matter.
At the smallest level, I'd reckon things like: mathematical patterns, cause and effect relationships, etc.
However, those things are rarely used so abstractly and are given some sort of dressing. For example, those relationships and patterns of a game about the battle of Waterloo can express a sort of truth about why the battle went the way it did.
That is how things get kind of muddy, it seems.
It gets muddier particularly in context of the last part of the formula: how the artist (game designer) has the talent to perceive said truth. Is the talent in the ability to first find and devise such mathematical patterns and relationships, finding them as "fun" ones to give to players to explore and discover...
or is the talent in seeing a truth and applying a mathematical pattern/relationship to it?
I'll have to ponder this later, when I'm not so mentally exhausted... posted by Brian Shurtleff @ 1:51 AM 1 Comments Links to this post
Blog - On Constraints:
Sunday, April 13, 2008Another thought that popped into my head during a lecture at GDX is on the subject of constraints.
Although, in retrospect, I think Brenda might have mentioned this observation I'm about to make in class before, and at the very least it is suggested in her article: "The Game Design Game".
The observation is this: game designers create mechanics, which are rules. These rules constrain the player, but it is those constraints which inspire creative, spontaneous play. They play within the rules and in reaction to them, exploring.
But the same is true of game development: all games have some kind of constraints on them during development: deadlines, budget, platform, etc.
As a game development student you are given even further constraints in order to experiment, and you begin to learn that the more constraints on you, the easier it becomes to design.
The constraints demand creativity and inspire.
If you look at some of the design challenges designers give themselves in order to stay sharp or experiment or learn, they often give themselves bizarre and arbitrary constraints, like randomly generating the subject matter for a game and giving themselves only 30 minutes to punch out a design. In Brenda's Game Criticism class we were given tons of these little design challenges, with all kinds of constraints:
-Make a game using 100 cards.
-Make a game with a random selection of items from a box of junk.
(Our group got a stopwatch, a toy train, a doll and a pen, and had 10 minutes to invent a game with them...)
-Make a game based on a randomly selected topic.
(Our group got Canada! We made a game about the lumber industry there...)
-Make a game that makes a player feel a specific emotion.
(How Rats came to be...)
etc.
It's telling that my weakest game project from that class (besides maybe Lumber Wars, our Canada game, only because it never actually got finished...)
was our final game project which had no constraints on it other than the deadline (and well, student projects inherently have a pretty restrictive budget as well.)
We were invited to create our own restraints.
And because I'm in my kick of analyzing improvisational games for theater in my game design studies, I can note a recent observation a member of my improv club made. He said our group was the strongest at the games that challenged us the most.
It was at those moments where we were most spontaneous and therefore the most funny.
Again, the constraints inspired creative, spontaneous play.
Some improv games have some real doozies when it comes to constraints:
-in "Two Line Vocabulary" some of the actors can only speak using a choice of one of two lines, forced to make those lines make sense in any given context.
-in "Number of Words" the actors are each assigned a number, and all of their lines must contain only that number of words. Again, you have to try to follow that while still making sense in context.
And perhaps the most insidious:
-"Three Rules", where the audience comes up with three rules the actors have to follow at all times during the scene. The audience is malicious, however, and occasionally comes up with some pretty diabolical rules...
not being able to use certain letters or the word "the" is pretty popular and particularly evil, for example.
Labels: constraints, design, improv
posted by Brian Shurtleff @ 12:06 PM 0 Comments Links to this post
Blog - Improv and Games: Scaling Issues
Wednesday, April 9, 2008As I mentioned before, I like to think about how improvisational acting and games are related, as, well, I do both at school. I've been running SCAD's Improv Club for a couple years now and was involved with a touring improv troupe long before that.
In any case, I think improvisational performance is a good resource for people interested in game design. After all, it does deal with how participants, both actors and to a lesser degree the audience, can interact with a dynamic story.
Not to mention that improvisational performances are games in their own right, which is a topic I plan on discussing eventually.
In any case, given as I have a lot to say on improv and games, it will become another sort of series for this blog: 'Improv and Games' (just follow the label "improv").
This one is on what improvisational theater can teach about scaling.
You'll note I did talk about scaling issues involved with using improv in digital games in the blog post of mine I linked to above, and also in its follow-up post.
However, this post is more about the scaling issues in improv games themselves.
It was brought to light in my mind as today in my Digital Art and Culture class we had a discussion on an excerpt we had read from Brenda Laurel's Computers as Theatre. The discussion at one point lead to how, if audience is to interact with a story, to keep everything from falling apart (a question tackled by game writer/designers all the time). You know, with those damn players and their agency screwing up our beautiful works of art. ;)
I mentioned in the discussion my experience with improv and how improv handles such problems.
My professor made a very good point though in response where he said that he found when he has worked with actors or those in theater on a performance that involved improvisation, that the more people added into the mix, the more difficult it got to coordinate.
This should not be a foreign concept to anyone in game development, as it is not only true for the development team itself, but in game design there is the concept of scaling: How well the game can support different numbers of players.
It is a phenomenon I experience in many of my games, during testing, but has been most powerfully true with Project Loyola, being as that one is massively multiplayer. That's a whole different and rather scary animal.
Now, most game designers know that games can teach.
Improv games are indeed used as teaching tools (if not directly constructed for that purpose, although I'd assume they are), so the participants can learn the craft of acting (often just to learn to become better at improv itself, ironically.)
One game that it interesting to look at in regards to scaling is the improv game "Superheroes", which is a great tool for teaching improv performers how to deal with keeping control, especially in the face of scaling issues.
I've picked that game to discuss here, as many of you might already be familiar with that one as it is often used in the popular show Whose Line is it Anyway?.
For those unfamiliar: One actor starts, and the audience provides the fictional superhero identity for that actor (let's say Cheese Man for our example) as well as the crisis that Cheese Man and the other heroes will have to solve. The scene begins and the actor will first improvise a bit to introduce the audience to his own personal clever interpretation of what a superhero called Cheese Man might be, and then quickly discovers the crisis (the inciting incident, so to speak.)
At that point, another actor will jump into the scene. Actor 1 (Cheese Man, in our example) will announce some variation of "Thank God you're here ___!" with the blank being filled by a spontaneous superhero identity for actor 2 (like "Sir Cries-a-lot", or something). This pattern is followed for a while, where the previous actor gives a spontaneous new identity to each new actor as they join the scene, until the last actor's spontaneously generated superhero character (traditionally) devises a solution to the problem (that often involves all the bizarre characters in the scene.)
With crisis solved, one by one all the actors make their exit, in the reverse-order by which they appeared, until the original actor (Cheese Man, in our example) wraps up the scene.
Now, having run this game enough times as the host of a club of amateur improv enthusiasts, it is interesting to see what happens with the final actor who enters the scene.
This is, although few people realize it until they have plenty of experience with the game, because that actor is the central peg upon which the game succeeds or fails -not the first actor.
(Ironically, it is usually the least experienced player who gets the part of this critical final actor, because they're less confident about their abilities so they wait to jump into the scene until they're the only one left...)
The reason the last player in this game is critical is, as you may have guessed, a matter of scaling. They not only have to fight more for their audience attention amidst the chaos of all the other actors in the scene, but also have to coordinate all those other actors towards a solution, advancing the story, allowing the scene to end.
Time and time again, I've seen this actor fail at herding the other actors to a solution, making for a game which drags on at this point, and falls apart.
It is also telling just see the dynamics of how improv games succeed and fail (and where they succeeded or failed) compared to how many players play in that particular game. Games with two actors "play" differently than those with three, four, etc. More than four and less than two (solo/monologue scenes) actors are the most difficult scenes to maintain.
That, however, is why "Superheroes" is interesting as it is one of the few games (although not the only one) that runs the entire range of scaling. It starts as the ever difficult one-actor scene, adds another actor for a "two player" scene, then three, then four, then up to the again difficult five, etc. Then, it works its way one by one back down into a one-actor scene. All the while, the dynamics of scaling are shifting, throbbing and changing.
As an outside observer or participant you can witness how these dynamics effect the game for better (for example at two/three actors how they play off one another to build the scene or comedy) or for the worse (the struggle for the final actor to tug the scene towards its conclusion).
"Superheroes" and the nature of the final actor in the scene may even present a kind of law: the more players in the game, the more powerful a facilitator is needed to manage those players.
The final actor in a game of "Superheroes" is intended to be the facilitator, although if ineffective, another actor must step up and take on the role.
Most improv games, however, don't have any one facilitator, and ask all players to collaboratively manage the game. (Coincidentally, that is what a game like "Superheroes" is used to teach: how to bring or maintain order in a scene)
For one other great example, look at the improv game "Entrances and Exits", which I choose as a specific example here because the entire core of that game is about how players enter and leave the game, shifting the dynamics as they shift the number of players in the game.
The players themselves are in charge of how many players are in the game at any one point, particularly when an actor chooses to leave the game on their own. (Interestingly, the mechanics of the game dictate that an actor can't return to the game on their own: another actor has to bring them in. This causes some of the weirder dynamics of that particular game.)
So yeah, there's some food for thought for you, fellow game designers.
Just one of many examples to come where I'll talk about what improvisational theater can teach about designing games.
Labels: design, dynamics, improv
posted by Brian Shurtleff @ 5:24 PM 0 Comments Links to this post
Blog - Experimenting on Our Beloved Mario...
Thursday, April 3, 2008Shortly after finding the Super Mario Movie (see previous entry) or maybe while looking for it, I stumbled upon an interesting youtube video:
A Super Mario Bros. clone controlled with a camera vision interface.
A camera records the position of your hand and projects its image into the came world, which you can use to push objects around. I've used such a system once where all you did was push a ball around...
But I loved how this completely reinvented the game of Mario.
Making him jump by actually physically flicking him into the air, etc.
Also interesting is the second portion of the video where in whatever system they're using, they spawn dozens and dozens of Marios into the game and try to play by all herding them using the hand. This wildly warps how the game is played even more than before.
Even more interesting, was while trying to find that video on youtube again, so I could link to it like above, I found another video with an entirely different way to play Super Mario Bros. - WITH SOUND!!!
Again, it completely changes the game, making it play in a very new, and fresh way.
It turns playing the classic game into a collaborative musical experience - How cool is that?
I especially like it because it basically puts an entirely different twist on the Fret Nice aesthetic I've mentioned earlier.
It might be harder to use than that... but the fact that you can use any instrument, explore what sounds do what, and multiple players can control Mario as one token...
all interesting.
And, unlike Fret Nice you can actually play the game as a real musical piece!
It might be a rather strange piece of music, admittedly, as the timing would be no doubt rather odd... (although the groove they have going on at the end sounds pretty good to me!)
It will, on the other hand, fit the game like a perfect soundtrack, which is pretty exceptional in of itself, particularly as its an entirely optional way to play. It might be the most open ended controller I've ever seen.
I find it interesting that both games have used Super Mario Bros. as the base game: it is, it seems, the quintessential video game. A system everyone is familiar with. Particularly with that first iconic level of the game.
These projects work because even though they're controlled in extremely alien ways, it's still Mario, we know what to do. Jump on the goombas. Don't fall down holes, etc. While we're stuck figuring out how to use the new control system, we still have familiar signs to latch onto so we're not lost.
That's a lesson taken from games themselves: designers must walk the fine line between innovating just enough that the game seems fresh and original, but not so much that the players are lost (or the people who have to market the game, for that matter...)
Labels: controllers, design
posted by Brian Shurtleff @ 12:29 AM 1 Comments Links to this post
Blog - On Player Movement
Tuesday, March 25, 2008As mentioned yesterday, one of my classes that started today is one where along with a group we do systems design for an RPG.
Today there was a brief exercise where we were shown a picture and had to say what systems we'd need for a game based off the image (however we chose to interpret the picture as a game.)
While the representative of our team was presenting, I noticed that the movement system was the last system he thought to mention.
Hmm.
When learning in a prior class how to write a design document, it was suggested that the movement system be the first system listed in the doc.
(Well, technically I was taught to do the controls first, which I guess I'm equating to movement here for the purposes of my argument.)
In any case, this advice I remembered again just a while back, while reading through what Perko has to say about movement in games. He points out that just moving in a game should be a kind of fun.
When reading that, I connected that to being taught to do the movement system first. Both stress the importance of player movement. After all, the player is generally going to have to be able to move before he can do anything else. Only a game which has no space can avoid this problem, and there are almost no games that have a complete lack of space.
Movement throughout the virtual world of a game is often the player's primary means of interaction.
It becomes the foundation for the core mechanic, if not the core itself.
So it makes sense to consider it early and list it first, placing it as the foundation it will inevitably be.
However, I had a strange thought: in this class our end product is to be a tabletop RPG.
How does one make an especially "fun" movement system in a tabletop RPG?
I've never found moving in a tabletop RPG especially fun. Admittedly, I haven't played as many tabletop RPGs as perhaps I should have, but I've certainly played a few, and none have had you move your characters in any way that stood out as "fun".
This is not to say that they were unpleasant, or badly designed. They take my characters from point A to point B just fine and I don't even think about it, which makes them well designed, I suppose.
However, Perko praises game movement systems where just getting from point A to point B is a pleasure in of itself, which does seem like a goal worth striving for in design.
So, how does one design "fun" movement in a tabletop RPG?
I suppose that is a problem for me and my team to try to tackle, and soon. posted by Brian Shurtleff @ 10:30 PM 2 Comments Links to this post
Blog - Theme Vs Core
Monday, March 24, 2008Spring break is over for me, and it is the start of a new quarter.
Today I had an art history class (being at an art school does require one to take quite a lot of art history courses) called "Digital Art and Culture" which looks to be very thought-provoking.
It may well influence much of what I write here!
It did in fact nearly inspire a post I was going to write for today, but I'll save it for later until that idea becomes more unified in my mind.
Tomorrow, however, I will have the first day of my other two classes: Advanced Screenwriting, and Abstract Systems Simulations.
The former will be what is likely my final screenwriting class of my academic career, and I believe its emphasis is on the feature length screenplay. That is something that I will bet is much more applicable to games than my past writing classes in television and short screenplays, as games tend to be a longer-form medium.
in Abstract Systems Simulations, from what I gather, we make a tabletop RPG.
In any case, the writing class has got me thinking on the subject of theme.
I know from past experience that it really helps going into the class with an idea for what I'm going to write already fairly formed, so the bulk of the class time can be spent actually getting it down and more importantly refining it, rather than flailing around for far too long grasping for an idea of what to write.
This idea is also encouraged in my game development classes. My development team for Abstract Systems Simulations, for example, has already been formed.
In any case, for my screenplay, I wouldn't say I don't have an idea yet... but it's not as ready as I would have liked by this point.
Like everyone, I have plenty of stories in my head, and the capability to pump out more when necessary.
My problem has been in selecting which idea to go with. This requires finding one I've already slightly formed that has the ingredients necessary to make it to a longer-form work like a feature film.
None of my story ideas at the moment have anything more than the suggestion of a B or C plot yet, which becomes of much greater importance in a longer-form work.
The one that seems ready to form side plots the most, however, is a sort of frantic jumble of ideas at the moment. To fix that, I need a theme. A theme could be used to unify this jumble of story ideas into a unified story.
This got me thinking about core game design, and how it is used in a similar fashion to how a writer can use theme.
Much like defining the core for a game, I need to decide what this story is to be about.
Then, as writing is the art of rewriting more so than writing, the theme can be used to determine what to cut, what to add, and what to change.
In a similar fashion, game design is a process of iteration (rewriting is crafting new iterations of a written work, after-all) and having a well defined core can help define what to refine in upcoming iterations.
Of course, games can have a theme as well which is usually separate from their core.
The core is the "theme" of the game's mechanics, but if the game has a story, that story can have its own theme.
It is important to note that this theme is then expressed through the core.
For example, whatever you might want to argue is the theme of what little narrative Super Mario Bros. has, it is told through having the player jump.
Granted, I don't know how well jumping, as a core, is at expressing a theme, which might be why Super Mario Bros. has so little in the way of narrative content.
This is not a fault of the game, certainly. Jumping made for a great core for an absolutely classic game.
I just find it kind of strange in retrospect that so many games feature an odd lack of unity between their core and their theme.
Can you think of instances where the core and the theme of a game were ever the same?
Or if not directly the same thing, then a game where the core and theme compliment each other in a logical and artful way?
Labels: core, design, theme, writing
posted by Brian Shurtleff @ 5:55 PM 0 Comments Links to this post
Blog - Freetar and Frets on Fire
Wednesday, March 19, 2008As a big fan of the Guitar Hero games and an internet junkie, I inevitably discovered the homebrew GH clones out there on the web: Freetar and Frets on Fire.
Both allow the user to make new levels for the game based off music in their collection.
(An idea that perhaps inspired current titles like Phase and Audiosurf?)
Of course, both Phase and Audiosurf do the work of translating your music into game levels for you.
With Freetar and FoF, you have to do it manually, which takes some time and skill.
However, you have more control over the final result, which I enjoy.
I like to make tracks for these games, as it provides some experience working with unique tool sets and adjusting difficulty levels.
I've talked before to some people behind some of the Guitar Hero games about how they establish their difficulty curve between songs and try to implement them into my track designs.
I've been twiddling with this stuff again as I've got time now that it's spring break, so it's been on my mind.
Now, one thing I mentioned in the above paragraph is tools.
Between Freetar and FoF there is an interesting contrast in tools.
Freetar has an amazingly well crafted track editing tool that is a real pleasure to work with. There's only one thing that I wish I could do in it that I can't: you can't click and drag out a selection rectangle to select notes, which would speed up editing quite a bit. That, however, is a pretty minor thing to be the only thing wrong with the tools that the creator (Anton Struyk) built.
Ironically though, Mr. Struyk never actually got to finish building the game itself, before getting hired by Vicarious Visions, which caused him to stop developing the project. So, the game itself remains as a semi-playable prototype, but with an absolutely beautiful track creation tool.
Frets on Fire, on the other hand, has a much more playable, more finalized game.
However, I find their tools completely unusable.
Fortunately, someone out there created a solution I've found nigh-perfect: A tool that lets you convert Freetar tracks and port them over to FoF.
The only problems are that you usually have to override the default bpm and put in your own value, and also FoF doesn't handle hammer-ons and pull-offs nearly as elegantly as Freetar does.
In Freetar and its tools, the track creator manually sets which notes have to be strummed and which can be played with a hammer-on/pull-off technique.
FoF just detects how close a non-identical note is to the previous note, and if they're close enough, automatically makes it into a note that does not have to be strummed.
I can't find a good way to control how large this threshold is either. There are parts I definitely intend the user to have to strum but have no control over it when porting to FoF and I don't get my way. Alas.
So, if anyone is especially good at programming tools, hey, there's a project for you. ;)
Also, I mentioned above that I use my tracks for these games as an experiment in difficulty curve creation, trying to make the perfect build up of challenge between all four levels of difficulty for that track.
It's a tricky thing.
I find it easiest to start with the expert version, transcribing every note of the source song faithfully into the track data, and then as I descend down to easier difficulty levels I slowly whittle the notes away down to their core. In other words, reduce the songs into the bare minimum of notes where one can play it and still feel like they're playing the song. So even though half the notes are gone, the essence of that song is still there.
The problem with this is that this constantly makes you as the track designer want to overestimate the easy player's skills, as you have to constantly make the call as to whether a newbie to the game could actually be able to hit any given note before you decide to delete it or leave it.
From talking to people who worked on Guitar Hero I was told that they kept finding that even when they thought they had dumbed down the easy level songs all they could, testers still complained they were too hard and they had to dumb them down even more.
As such, if there's ever a doubt whether or not I should cut a note that might be too hard for an easy/medium level track, I usually air on the side of cutting it, and of dumbing the song down.
It's just a hard thing to keep in mind when you've seen every note before in the expert version, and seem to be whittling the song into nothing.
Hmm, I still have to get around to fixing up my design page and finally putting the tracks I've done up there...
Labels: design, Freetar/FoF
posted by Brian Shurtleff @ 2:01 PM 0 Comments Links to this post
Blog - Games: Life with the boring bits still in it?!
Tuesday, March 18, 2008In most narrative forms, you cut out all that is irrelevant and tedious. 3 Years of a person's life can be cut to 2 sentences in a novel.
Hell, most of my student writing was done for the medium of television which by necessity of only having thirty minutes to an hour to tell a story requires the writer to cut out pretty much everything but the most crucial "spine" elements.
Stories usually jump right in to the important stuff, and cut down on the back story.
Games are often fine at this part of the concept.
Games, however, also let you do fantastic amounts of tedious actions that would never fly in any other story form. Sometimes, I wonder why this is true.
It's one of the huge problems when considering constructing narratives for games: games are paced really oddly.
Now, I can in some sense see why. First of all, we must consider that just because something is tedious relative to plot doesn't mean it's not fun.
As Craig Perko mentions in numerous articles on his site, just moving in a game should be fun.
Okay, yes, a good plot should be active, but although movement is active by definition, a film where people just ran around and jumped and nothing else would have to be considered an "art piece" or be booed out of theaters for an appalling lack of a storyline. Action films have a lot of running around and jumping, but they thread that into at least an attempt at a story, usually. Running around and jumping provides the obstacles and the character's means of overcoming said obstacles, which make them an element of the story, sure, but the story of an action film is never about running and jumping, though. Even films about a famous runner aren't about running, exactly.
In games, however, sometimes just running around and jumping works fine. As every child knows, running around and jumping can be really fun, and fun is generally all we ask of games.
In the GTA series players tend not to give a hoot about the actual story mission mode. The fun of that game is generally in just driving around and blowing things up without consequence. Although in some sense, these moments can be considered story as you can certainly recount, in the form of a story, some of the crazy stuff you've done in this fashion in GTA, like intense car chases, crazy stunts you pulled, etc. When telling people about a play session you had of GTA these are usually the stories you tell.
But on the other hand:
1.) This kind of story is completely hit-or-miss. Sure, you'll occasionally have moments of extreme tension, or something thematically interesting will happen randomly and accidentally, but there's also a lot of dull bits in the meantime.
2.) Being as there are basically no consequences of any importance involved, this kind of "story" doesn't make for any sort of overall narrative. Narratives require character actions to matter, which means consequences.
Is making movement fun a gimmick used to make the game fun, or a gimmick used to just make the act of moving not suck as much?
That, I think, is a valid question.
As one of my favorite books points out: moving sucks. Space sucks. People like to go to and experience new places, but the act of actually traveling from one place to another is something we humans think is a tremendous bother.
That's why those "go here and fetch me this thing" Hub-and-spoke quests suck.
Does making how the player moves into a more fun activity solve the problem, or just hide its odor better?
And that's just physical travel. Pacing is a matter of temporal travel. Admittedly, yes, when you travel through physical space you tend to travel through time as well, so they're nearly the same thing. In any case, temporal pacing is the real root of the overall problem of pacing.
As I see it, the main reason games leave as many moments available to the player - as uninteresting as they may be - is because it's the easiest way to not rob them of potential choice. As game designers we're reluctant to rob a player of choice. Of course, games always inevitably do to some degree anyway. Until we have a game that can procedurally generate any content and can respond to any insane whim of the player, there will always be some limitations of choice for the player. We place barriers for where they can't go, for example. How many games are set on islands, with the player fresh out of boats? A lot. Does that rob the player of, say, the choice to escape the game's setting and go to Australia and start a kangaroo farm? Well, sure, but who cares? It might sadden you a little if that's what you really wanted to do in the game. Most players just accept that that's not possible and move on. Limitation on player choice can be handled elegantly enough that players won't mind, within reason.
But then again, I look at the phenomenal success of The Sims - a game which is life with almost nothing but the dull bits - and it leads me to believe that there's something here I'm missing.
If the best selling game involves you largely making your character sleep, pay her bills, and use the toilet, then maybe there's something to those dull bits after all that I just haven't figured out yet. posted by Brian Shurtleff @ 12:25 PM 0 Comments Links to this post
Blog - Harmonizing Narrative Depth with Episodic Play
Tuesday, March 4, 2008This starts off as almost a tangent, but eventually I ramble my way around to my point:
Thanks to Brenda and Sheri Graner Ray, I've enjoyed being involved with (volunteering for) WIGI at several conferences I've been to. Making our industry more diverse and welcoming has interested me for a while and it's great to work with some people also devoted to those goals.
So, at SIEGE I saw Ernest Adams' presentation on women in games. In his lecture, he mentioned that women, at least generally speaking, prefer more character depth than most games are able to provide. Hollywood can much more easily tie us emotionally into a character, whereas only a good handful of games seem to ever manage that.
In order for the depth of a character to properly manifest, it should follow that they're placed in a narrative of some kind. Ergo, story-heavy games attract deep characters, and deep characters should attract more female players.
I, however, also know that casual games are doing wonders for drawing women into gaming, to the degree where the industry is even targeting them.
So, I asked what was nearly the only question asked at the end of his presentation. I asked how those two forces can be reconciled. Casual games attract women, but by their very nature cannot realistically support a heavy enough narrative to support deep characters. Conversely, games with enough story to support deep characters have trouble being anywhere near "casual".
Adams didn't have an answer that satisfied me, instead merely agreeing that both were great forces at work in the issue.
Sheri's Book Gender Inclusive Game Design, however, addressed this issue at one point, as I discovered.
When discussing puzzles in chapter 8, she says that players -particularly female players- like having an emotional tie to characters, yes. In particular to their avatar.
However, she says this is not true in casual games.
The argument is that people will not want to invest time in a character of a game they already don't want to invest that much time in.
I can see that. I'll agree that that's true in most cases.
I have to wonder if there are exceptions, however.
What about episodic games?
Each particular episode is not much of a time investment, yet you still get the benefit of an overarching narrative and characters. For example, Telltale Games' Sam and Max episodes are great little games that come across to me as fairly casual. They only take about as long to play as watching an episode of your favorite television show, and the game play is pretty accessible I feel. Back to characters: Sam and Max are fantastic characters! Okay, maybe they're not that deep... but I don't see why a similar game couldn't be made that did have more depth to it.
The biggest problem I see as standing in the way is that the player would have to keep the ongoing story in their memory. Craig Perko had a pretty interesting little entry on that problem a while back.
The Sam and Max episodic games might only work because they have little in the way of depth: you don't actually ever have to remember what happened in a previous episode. If you do, great. You'll get more out of what little overarching plot to the series there is. But it's not critical.
Have deeper characters, however, and it might come up. It might be critical for a player to remember that, in an episode they played two months ago, they rejected a character, crushed someone's spirit, offended another, etc, if the lingering emotional aftermath from that erupts back up to the surface. Depth is all about what is bubbling underneath the surface of a character, and players will have to remember and track that, somehow.
However, television dramas manage this well enough. Why can't we?
Of course, on the one hand television has the benefit of being on a schedule, usually a weekly one.
That's much less downtime in between episodes, less time for the audience to forget.
But television dramas also tackle the problem with a "Previously, on..." pre-teaser montage at the start of each episode. This was suggested in Perko's player memory entry; however he used it in the context of a more traditional style of game. The thing about 'Previously on..." segments is that they don't just recap what has happened (or at least, they shouldn't), they recap specifically only what the audience needs to remember for that particular episode.
To put in a "Previously, in your game of Civ..." segment wouldn't be nearly as effective by that logic. There's little way to tell upon loading a player's game what he/she is going to do in that play session, so you can't find the particular elements to say "remember these specific details about the previous play session, as they'll become important during this one."
You can't, because you have no idea how long the player is going to play in that sitting.
But in an episodic game, this kind of "Previously, on..." segment is more possible.
Because it is broken down into episodes, you know exactly what occurs (or rather, can occur) in that particular episode, and thus can point out to the player specific past events in the overarching plot that they'll want to know for this episode.
Add in a system that keeps track of game-to-game data, building ever larger databases of what happened in the player's episodes so they can affect the plot and characters of future episodes, and you might have something really fascinating there.
Labels: design, episodic games, women in games, writing
posted by Brian Shurtleff @ 3:32 PM 0 Comments Links to this post
Blog - ARG Launch Excitement
The ARG project I'm working on is set to launch soon, and we're preparing our launch plan.
Very exciting stuff.
Particularly as we're to be one of the (at least to my understanding) first open-documentation ARG projects ever created, allowing others to learn from the design choices we make. I've heard we've got a lot of industry folks interested in this, for exactly that reason.
Of course, the open-documentation part will come later. First, people need to actually play it!
As soon as I can, I'll point people in the direction of where they can find and play our game.
Nobody on the team has ever developed a project like this before, so we're looking for all the feedback we can on the early stages of the game.
Keep your eyes peeled! posted by Brian Shurtleff @ 12:09 AM 0 Comments Links to this post
Blog - Pronouns and the Female Protagonist
Sunday, March 2, 2008I met Sheri Graner Ray, author of Gender Inclusive Game Design, at the first game development conference I ever attended. I figure as I am pursuing a career in design, checking out her book was a must.
One point mentioned in it is that most men are willing to play as a female avatar, but most women are not inclined to play as a male one. Therefore, to potentially get more women playing your game, it should feature a female protagonist if not the option to chose either gender.
Knowing that for one of my projects this quarter that I'd have to make a very story-heavy (and therefore fairly character-focused) game, I knew I wanted to try and put these ideas into practice, and experiment with using a female protagonist.
First of all, this created a really unexpected and refreshing main character for my game which was praised by people who have been privy to the game's development. People knew I was doing a game set in the Paleolithic era, but when I revealed my protagonist wasn't at all the stereotypical "cave-man" they were expecting, but instead a thirteen year old girl... well, it got some recognition from my peers.
However in having this female protagonist, I've found it solves another problem in creating games designed to be open to a larger female market: it makes me more likely to consider pronoun use in the docs! When designers default to male pronouns in the design documents (i.e. "If the player does X he may then..." etc.) it may make one lose sight of potential female players. It could also turn away any women who'd happen to read the doc, as it subconsciously signals "this game isn't for me" to them.
Well, having a female protagonist makes it that much more natural to write in female pronouns, because that's what the character is.
Of course, whenever possible I also try to refer to the character as "the player", in order to ensure I'm always thinking about the player and what they can/want to do.
Labels: design, women in games, writing
posted by Brian Shurtleff @ 3:11 PM 0 Comments Links to this post
Blog - Keeping Faith in the Face of Play Testers
Saturday, March 1, 2008"Nothing feels worse than giving people the game you've poured all this work and love into, only to find they hate it, and don't think it's fun."
That was (at least approximately) said by my professor/mentor while observing a play testing session of a board game me and a group of other students had been working on. The game is a sort of museum-heist simulation. It was developed by me, David McDonough, Dan Wilkins, and James Caskey.
Our group of play testers had, the day before, been unsure about the rules, and didn't get far into playing the game. Their feedback then on what to clarify in the rule-set was very useful. The criticism was more welcome, somehow.
But this second day of testing with them? Now they knew how to play our game at least as far as one could from only the rules, and their early response was not good. They weren't having fun with our game. Indeed, that is somehow a much harder blow to take.
Our game featured a traitor-mechanic, where one player is secretly a traitor trying to sabotage the group. A player was determined to be the traitor too early in the game, and was upset at being continually excluded from rounds. The other players seemed to be pulling ahead to an easy victory. The game seemed... well, stupid.
But I kept the faith.
When they were complaining that it was way too easy for the loyal players to win vs. the traitor, I warned them that during our personal play testing the traitor won more games than the players did.
The testers didn't yet see how that was possible. I kept up the faith.
The testers kept playing and eventually the game clicked right in their heads. They got it.
I knew from past testing sessions with the other guys on the project that the "loyal" players always seem like they're going to win at first. That's how the traitor spins his web of treachery.
The fact that traitor got found too quickly ended up not mattering as the other players discovered too late that they had used up all their allowed opportunities to stop him already. They wasted all their counter-attacks on him at the beginning of the game, when the traitor is meant to lay low anyway, as his 'attacks' are only more useful at the end of the game when the stakes grow higher.
So, after some initial terror of thinking our game sucked, the play testers ended up really enjoying our game.
Despite earlier in the game where he was found out and frustrated by being excluded from so many turns, the traitor ended up winning the game. Sweet revenge.
They said there wasn't anything our game needed to change. I'll call that a success.
I'm still awaiting Brenda's feedback, when she has played the game.
Edit- the game's title is under construction again after having been declared "weak". Also, expect a postmortem article on this project to appear in the near future... posted by Brian Shurtleff @ 7:09 PM 0 Comments Links to this post
Blog - Drawing from Nature
Wednesday, February 27, 2008Play is in our nature. In fact, as many of you likely know, animals play too. It's part of our survival instincts.
I saw some videos on youtube recently of dolphins at play, making bubble rings, much like in the way some people can blow smoke rings. The dolphins seemed to have some kind of game involving these rings of air/bubble, where they'd blow one, chase it, hook their snout through the middle, and then break the bubble in such a way that although most of the bubble was destroyed - it somehow created a new, smaller bubble ring.
They'd repeat this process over and over, until the ring was small enough that when they could catch up to it, they'd eat it.
The dolphin seemed to enjoy doing this over and over again.
And I have to admit, that it looked much more fun than any other examples I've seen of animals at play. It made me wish I was dolphin and could play that game.
Given Ecco the Dolphin, or Pajitnov's dolphin game at this years Game Design Challenge at GDC, I think I'd rather take the game dolphins themselves invented.
Looking at nature for inspiration for games has been on my mind lately.
As I'll post about one of these days, I prefer designing games where the player's chief motivation is not to commit violence but to survive, as I feel that is more emotionally powerful as well as resonates with more human beings.
So, not long after finding the videos of the dolphins at play, I found a link to a youtube video of a colony of European honey bees being completely massacred by giant Japanese hornets. Although the video went for some real cheeziness in the way they handled the documenting of the event, the scene still had a lot of emotional power to me. It was like the beach-storming scene from Saving Private Ryan, only for bees. There's footage of bees being dragged away by the giant hornet monsters, clawing the ground in desperation before being ultimately torn in half. A hornet will swoop down and slice off the head of another bee, sending it spiraling through the air in slow motion. A deep pile of bee corpses litters the ground.
I watched and thought to myself "Oh man, that would be an intense situation for a game!"
Most players would probably want to play as the Japanese hornets, and rip the bloody hell out of everything. It'd be like the Dynasty Warriors series, where you delight in your all-powerful ability to slaughter the nearly-helpless swarms of enemies before you.
But those games bore me quickly, and as I said, I find survival more compelling than committing violence. So, I identified with the bees.
I imagined being one of thousands in the living wall of bee-combatants guarding the hive, watching my sisters literally ripped in half by the hundreds in a systematic fashion by giant flying monsters, waiting for the time when one would come for me.
That would be absolutely terrifying, and powerful.
And even though they're helpless against the hornets, there's a certain nobleness there that I'd still find admirable in playing them. Unlike most humans, every bee in the hive will literally fight to the death to save their larvae. That's right, every single bee will fight to the death.
That's just awesome.
I've thought about these two things recently as I'm now actually working on a game based on elements drawn from nature: I'm designing a game with mechanics entirely based on real ways bioluminescent creatures of the deep sea fight and defend themselves.
And again, remember that just in my last entry I was talking about my interests in using artificial life technology in games? Again, that's drawing from nature.
Game design ideas are everywhere: in history, science, mathematics, etc. Look anywhere long enough, and you can find a game. Nature is just a nice, easy one to start with.
Labels: design, inspiration
posted by Brian Shurtleff @ 1:22 PM 0 Comments Links to this post
Blog - Fret Nice
Thursday, February 21, 2008I've been working through play sessions of some of the 2008 IGF games.
One that had caught my attention from the moment I heard of it was Fret Nice, a 2d platformer that uses guitar controllers.
This caught my attention because I had already started working on a game essentially fitting that same description!
So, they beat me to the punch. I admittedly didn't get very far at all in mine: only got how the game worked down in my head and was starting to experiment with how the audio would work. It's tough to get guitar samples to sound right, and must say that that team deserves their nomination in "Excellence in Audio" for the pretty seamless guitar play audio.
In any case, I had already been playing around with the Guitar Hero controllers for other applications (I programmed an interface so I could use the Guitar Hero controller as a MIDI instrument!) so I thought it'd be fun to do something crazy with the controller in a game.
It turns out, I wasn't the only one with the same idea.
Well, I finally had some time to play their game today, and beat the three levels at least once each.
Their game doesn't work all that much like how mine (hopefully) would have, but it was pretty well done indeed