Blog - Design Tips: Mercy Killing

Monday, May 19, 2008

Sorry 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: , ,

posted by Brian Shurtleff @ 5:06 PM  0 Comments Links to this post



Blog - Design Tips: Don't be Afraid to Give your Players the Big Guns

Monday, March 10, 2008

So I've decided to turn my last entry into the first of a series.

I'll talk about entries I'm adding to my Design Tips, Tricks, and Techniques list I'm building for my own use as well as for teaching at Emagination.

For the record, they even have their own tag/label: "design tips"
So if you want to find the whole series, you know where to look. You're welcome.



So, onto business:
Next tip: "Don't be Afraid to Give your Players the Big Guns"

It is often the temptation to make the player have to work up to their most powerful abilities.

Alternatively, a designer might never implement a "big gun" powerful ability in order to help keep a game balanced.


But players love the big guns.
We want to not just kill things; we want to do it with style. We don't want just a little control over game tokens; we want as much as the designer will feed us.
We want to be able to do cool and hilarious things. We love overkill.
And we love completely dominating our friends.

One interesting example is Valve's games.
They are very good at creating "big guns", but I always find it very frustrating upon repeat play how long it takes you to play through the game to get them.
The gravity gun in Half Life 2, for example, is by far the best toy in that game, but it's quite far into the game before you get to play with it.

Portal takes you a much shorter, but still somewhat irritating span of time to get your portal gun fully functional final form as well.

Of course, both of those examples are because they are victims of Valve's technique of how they build up the game for the player, showing them how to play. Their technique is a very effective and welcome system in my book, so I don't want to fault it.
It just sucks somehow that in order to cover all the groundwork the player needs to know, their best toys get pushed back into later parts of the game.



Now, a recent moment where this "big guns" tip has come up within my design work was within another board game I'm doing with a group of students.

Our earliest board iterations were done with a grid based system.
We scrapped the grid-based board, as it was found to be too slow, predictable and tedious.

But in doing so, we did have to get rid of our biggest "gun".
We had a mechanic where you could convert one of your units into an explosive of sorts: use up 3 cards of a specific resource on him and he'd be converted into the explosive unit, with a blast radius of one square in every direction around him.
However, we also suggested players could put in MORE of that resource to increase their blast radius at one extra square per extra card.

We had one play test where one guy threw down 9 of the resource cards at once and ended the game with an apocalyptic explosion that took out half the board. It was quite the grand finale.


A few things about this:
1.) That epic explosion at the end there was pretty much the only fun thing about that particular play test of that iteration of the game. The ONE THING fun about our game at the time was this "big gun" attack. The situation where you'd have enough cards to create a huge blast wasn't that likely, but if you did, you could cash it in for quite the reward: the ability to nuke the hell out of the playing field.
Even better, it created a kind of feedback loop as even if you had enough cards, you could consider saving them until you collected even more cards for an even more massive blast at perhaps an even more strategic moment.

2.)
Because of the way we changed our board, new versions of the game can't benefit from quite as big a blast, as the game map now featured territories rather than a grid-based map, and therefore makes it impractical to have measured blasts of a certain size.

Our game is overall more polished now, but I think everyone on the team has admitted: We lament the loss of the potential of the gigantic blast attack.

Labels:

posted by Brian Shurtleff @ 9:48 AM  0 Comments Links to this post



Blog - Design Tips: Criticism has subtext

Sunday, March 9, 2008

I'm working on compiling a list for myself of game design tips, techniques and truisms that I've picked up over the past few years.
It is to help codify the ideas not only in my own mind, but also so that when I teach at Emagination again, I can present a more prepared lecture or two on game design.
I gave a game design lecture recently for SCAD's game development club and realized that I need to internalize some of these concepts more in my head, as I had only moderate success pulling them out while winging-it mid-presentation.

Also, this quarter I've made far more games than I ever have before, so I've been able to see a lot of these ideas go from abstract lecture content to real application before my eyes.
So, it's been on my mind lately anyway.



One that just came up, though, is one I've been taught on dealing with play testers, receiving feedback or critique of iterations on your game.
The advice is this: When someone complains about something wrong with your game, find out what they're really asking for. Or as I put it in the title above: criticism has subtext.

For example, a tester might only say "I think there should be more explosions!" but explosions themselves might not be what they actually need. They could, as just an example, actually be looking for the game to give them more feedback from their actions. Their brain skipped a step, however, and suggested an explosion would work to that end, but 1.) if handled improperly, not knowing what the suggestion was really for, it could just as likely remain ineffective, 2.) Something else could provide the same level of feedback, or more, and in a way that's easier to produce than their recommendation.


This design nugget-o'-truth popped into my head because I was just the instigator of this very same problem only a few minutes ago.


A friend was having me test his game, and I complained that it needed a bit of time after the menu screen but before the enemies started pouring in upon loading the game. I felt that I wasn't getting enough time to get my bearings yet before being immediately killed some of the times that I loaded up the game.

After a while it hit me what was wrong and I had to call him back before he ran off to implement some sort of timer feature.
The problem I was having wasn't necessarily a time based problem. I realized it was due to a difference in control systems between the menu screen and the game itself:
The menu was controlled entirely by the mouse, and the game entirely with key presses.

So, when the game loaded, every time I had to look down to find my arrow keys so I could move my hand there from the mouse. In that time where I was groping for the arrow keys, I'd often get blasted.

Of course, a timer could help too, but the key-groping was the bigger culprit and one that I didn't even notice until after quite a lot of play testing. The designer hadn't apparently thought of the problem either.


So yes, listen to what your play testers have to say, but then search for what they're REALLY trying to say, but couldn't find the right words.
Especially when you have the game design training/vocabulary and they do not.

Labels: ,

posted by Brian Shurtleff @ 8:15 PM  0 Comments Links to this post