Blog - Reflections on DJ Hero -- Music Games aren't Dying, They Just Forgot Who They Are
Friday, January 22, 2010I have read about how sales are down on the music-game-with-plastic-instruments game genre as a whole. That they haven't been meeting sales expectations. I've heard cries that the genre is waning. Dying out. DJ Hero is one of those titles that just wasn't meeting sales expectations (despite Activision now boasting that it's generated more sales than any other new IP this year, ironically... although it seems that was in terms of revenue, not copies sold.)
Playing DJ Hero, though, I get the feeling that the problem isn't that the genre isn't dying-- the genre has just forgotten who it is. Or, more accurately, it forgot what made it hot in the first place.
I've mentioned many times here before that I'm a huge fan of Harmonix's first game, Frequency which is also a DJ game in a sense but in far more abstract terms. But Frequency and it's sequel were never the successes that their later game Guitar Hero was... Guitar Hero was the game that REALLY kick started the recent craze in music games, despite the fact that they've been around for quite a while now. And comparing the two games, it's not hard to see why. I think people at Harmonix would be the first to admit all the things that Frequency does that make it no where near the commercial and popular success that their later games have been. And I say this saying that I actually like Frequency BETTER than I like Guitar Hero -- that doesn't stop me from viewing it's flaws critically and admitting that it's not nearly as accessible of a game.
Playing DJ Hero, and the few times I've been able to play Activision's contributions to the Guitar Hero franchise as well, makes me wonder if the developers of the game really took the time to look back into the past and see the paradigm shifts that happened at Harmonix to take them from Frequency to their smash hit Guitar Hero (and it's continued legacy in Rock Band).
I say this because playing DJ Hero gives me the feeling that it's falling into all the same traps as Frequency. And as the Guitar Hero series progressed post-Harmonix, they just got harder and harder... and I stopped finding them less fun as a result.
Two things really made the initial Guitar Hero blast off in a rocket of success:
First, it was super-accessible. The music itself was, for one thing -- rock music is more generally popular and accessible than the stuff in Frequency, and they had enough flavors of it to more or less satisfy everyone. But also there's the interface -- the interface of Frequency/Amplitude is a big scary octagon of doom which intimidates the hell out of people who have never experienced the game before. A friend of mine watched me play Frequency for 20 minutes straight and said "I still have NO idea what's going on." But Guitar Hero? Pretty straightforward.
Second, it made you feel like a rock star. You could pick up the controller and after you get the hang of it after a couple songs, you're really rocking out. It's easy to get all stupid getting into character with friends and trying to look your most badass while shredding...
Frequency, although it got you into a real groove sometimes... and sometimes you'd pull off something impossibly hard in the game and feel a bit like a legend... was in the end too abstract to really make you feel like a rock star in any capacity.
So-- DJ Hero. When I played it, I initially jumped into playing it on medium. I guess I knew that it was going to be a different experience and would probably be lost jumping straight into expert mode... but cocky enough about my skills at other rhythm games to swallow my pride and try easy mode.
So, starting on medium difficulty-- I was immediately overwhelmed. On MEDIUM.
Oh sure, I got the hang of it eventually, and beat the whole game on medium... but initially it left me very flustered. I've now gotten used to where the controls on the mixer are located, but first starting, I'd be watching the screen and groping-- nay, flailing, trying to find them while keeping my focus on the screen.
Feel like a rock star DJ I certainly did NOT.
Even now, having beaten all of the hardest songs in the game on medium... I still don't think there's too many songs easy enough that I could properly show-boat and act like a cocky pro DJ if friends were over to play it as a party game. ...on medium.
I eventually decided though that it was unfair that I was judging the game in this way by medium difficulty mode, and went back to try the others. I take some of it back now. For example, beginner mode can't help but be too easy for anyone but the person who has never played a single rhythm game in their life before, and are hopelessly uncoordinated. So, accessibility as far as difficulty goes? I'll give it to them after all.
And having played through some songs on all difficulty levels now I'll admit that there actually is a really decent curve of difficulty between all the different difficulty modes. I can't think of a better way than they did it. But... it still doesn't feel quite right to me. But as I can't admittedly think of a way it could be better -- sure, you win this round, DJ Hero.
I've since, btw, jumped into playing Expert mode now, and at first I thought it was actually pretty cool -- terrifyingly difficult, but it's interesting that it's far more accurate to real turntablism than the rest of the game, and the challenge of actually having to scratch in the right directions is kind of fun.
(...But those damn peak spikes! WTF ARE THOSE?! They are just annoying as hell, impossible to juggle on top of everything else and are entirely unlike anything a DJ does ever!! Again, W-T-F?! ...there, got it out of my system... sorry)
However, all that said, there's still a problem -- the interface. At first it seems simple -- 3 note track. Not bad! But as the game goes on, it adds more and more things that happen to that track-- the crossfader that splits the track, the different kinds of scratch portions, the sample-playing sections, the dial-tuning bits and the peaks...
If you hadn't played or seen the tutorials, you'd have NO IDEA what's going on!
Guitar Hero you could easily play without a tutorial, but I can't imagine anyone playing most of the songs in DJ Hero without having seen the tutorials, especially the higher the difficulty modes. Really hurts the game as far as being pick-up-and-play at a party -- which is what made Guitar Hero explode in popularity.
And, furthermore, the problem with all those things that clutter up the track is that all that all of those things are entirely different actions you have to perform!
Here, let's go back and look at something...
Frequency had quite a few actions possible:
-hit beats
-switch tracks
-deploy powerups
-scratch/play samples (when available)
-play with the axe (when available)
Guitar Hero?
-hit notes, sometimes chords
-strum (basically always done at the same time as the hitting of notes, so it's almost only really one action, and not two)
-deploy star power.
5 vs 3.
And... which one of those two was the more accessible, hugely selling game again?
DJ Hero's list...
-hit beats, sometimes 'chords' of them at the same time
-crossfading to the left or the right with the crossfader
-scratching, sometimes freestyle, sometimes in more specific discrete directions
-tuning the audio with the effects dial knob
-deploying 'euphoria' (read: star power) with a button on the mixer for that
-spinning back the platter to rewind the track (when available)
-hitting peak spikes with the crossfader
7. Woah.
(Isn't the limit to how many things a person can even juggle in their head... 7 things? HMM...)
Note also that the game often has you doing some completely ridiculous juggling of things that are on completely different controls!
Sometimes I swear it seems like there's more things available for you to do at a time than is physically possible with only two hands.
Again, feeling like a rock star, I did not. I just felt incompetent.
Admittedly, the difficulty level you're on does determine how many of those features you'll see or have to use (thank god). So, put Grandma on beginner mode and all she'll have to do is hit one button and freestyle scratch -- not bad. Easy mode, best as I could tell (didn't play too many songs on it) adds all three buttons. So in some ways it still does beat Frequency's list, if you're playing on a low enough difficulty mode.
But I can't see myself ever 5-starring more than the first 4 tracks on expert mode. Thanks for making me feel like a loser, game.
And since even on medium, I find most songs too difficult to show-boat so I can feel like a rock star... the game just doesn't make as good of a party game as even Guitar Hero, let alone the new "band" games out these days...
At least DJ Hero provides a 2 player mode -- a nice attempt. But I don't think it's enough to make it work as a party game, and so it'll never be the success that Guitar Hero was.
But after all that criticism of DJ Hero -- the game certainly isn't awful. If I had worked on it, I'd be pretty damn proud. The game design may not be as polished as it should be -- but the game as a whole certainly is! Some of the mashups are really awesome, and there's not too many song/levels I straight up dislike -- the overall quality of the tunes available are pretty good. I totally love the spinback-rewind powerup -- time rewinding in a Guitar Hero style game is really interesting and actually leads to at least some strategy (something the rhythm game genre generally sorely lacks). The game has certainly kept me playing it, and nothing BUT it (due to the fact I AM in crunch right now so not really much free time for gaming...) for a week now. So kudos, Activision.
But yes-- that said, I can't lie to you either-- the game's got some real issues too.
But hey, nobody's perfect. I can tell you a million things wrong with my games...
Labels: design, DJ games, Frequency, game design, music
posted by Brian Shurtleff @ 10:30 PM 0 Comments Links to this post
Blog - Endings in Games
Sunday, November 29, 2009Reading another book on screenwriting today, the book mentioned an old Hollywood axiom:
"Movies are about their last twenty minutes."
It's interesting to compare this statement to games.
Are games about their last twenty minutes?
(Note: I will use the 'twenty minutes' a bit more metaphorically for the rest of this article, since games are not nearly as uniform in length as film...)
Given how it often seems like game developers take many of their cues from film (those of Hollywood itself, commonly) it's odd that I don't feel this statement as ringing quite as true for games. So what is it with games and endings then-- is it something about the video game medium itself that makes them fundamentally different in this area? Or is this a case of developers neglecting lessons from our media cousin out of ignorance or stubbornness? I suppose the two aren't mutually exclusive and it's a bit of both and on a case by case basis.
On the one end of the spectrum, I recently read an article where someone was venting their frustration at having to beat all of the puzzles in Braid to unlock its ending. It's a valid point-- that is a game with one of the most astounding endings I've experienced in a game, yet it is fairly frustratingly difficult to complete a few of the puzzles. Some of them aren't even brain-teasers-- a few require real physical skill like timing button presses. What is the player to do if they just completely lack the coordination for such a puzzle? Either they have to find a way to cheat past it, or give up and miss out on the brilliant ending.
On a much broader scale-- I've read that most players won't make it to the ending of most games. This is, of course, completely unlike films-- you can't help but encounter the end of a film unless it bored you so much you walked out or fell asleep. DVDs even make cheating and skipping to the end an always instantly accessible option (and easy for anyone who's ever used a DVD player before-- i.e. much more accessible than video game cheats). The closest thing I can think of in film is more cerebral or deliberately disjointed movies which require intellectual skill of sort to comprehend them-- but even then you're at least experiencing the ending even if you don't 'get it'.
But games are often far longer than films and generally require you to actually beat areas with some kind of skill (intellectual, twitch, etc.) to unlock more of the content/story/etc. If you hit a wall-- you don't get to the end. You won't get those supposedly great last 20 minutes. Hell, forget a great ending-- you don't get any kind of closure at all. And human beings crave closure...
Then you've also got your largely multiplayer fragfests or competition games like when friends get together to blast each other in Halo or play Super Smash Bros. On the one hand, you could say those NEVER end... how can the last 20 minutes possibly be great if there is no end at all? On the other end-- each match could be seen as it's own little mini-story and those usually do build to some kind of climax as things get down to the wire of the last few seconds/lives.
But finally, consider the game Indigo Prophesy.
If you read the postmortem for the game, the developers lamented their mistake at focusing too little on the ending-- since, again, they figured not as many players make it all the way to the end. So, when players DID make it to the end, and cried out "What the hell is this?!" the developers realized their folly.
In fact, a game with a bad ending is worse than a film with a bad ending, because the game makes you WORK for that terrible ending. If a film ends up as a dud, all you've lost is a couple hours and the price of your ticket. When a game's ending flops? That could be after weeks of grinding, or blood, sweat, and tears of trying to beat that last damn final boss or level. In other words-- it was possibly frustrating even BEFORE you saw the bad ending. Not to mention that to that frustration you add the lost cost paid for the game, which if it was a new $60 game can hurt a lot worse than a wasted movie ticket.
So, this seems to be a problem. Indigo Prophesy's ending proved that endings may be just important in games as they are in film (maybe it's not the best game example, as it is a very cinema-inspired title... but meh, you get the point.) However, make a brilliant ending like Braid and maybe only half your audience will actually make it all the way there to see it-- and that's the best part of the game, if you're following that axiom. Players are missing your best content. So what's a developer to do?
There is, of course, the overall "dumbing-down" of games to make them appeal to a broader audience, and that is part of it. Only the hardcore were insane enough to play through the challenges to see the endings of games, which frustrated everyone else who didn't have the skills to achieve the closure they seek in their media experiences. But at the same time, this dumbing-down is somewhat despised by gamers-- although, admittedly the ones complaining are only the hardcore minority who never had this problem. But they do have something of a point-- if it's too easy to get all the content, you lose any
sense of accomplishment.
Of course, as the article venting about Braid pointed out-- that notion only appeals to players who seek fiero, which isn't everyone-- especially as games branch out to larger audiences. It's an issue of balance between players who are achievers and those who are explorers-- either way you're disappointing one of those two sides.
So, is there a way to find a happy medium for both achievers and explorers?
Maybe returning to something similar to the old favorite-- difficulty modes?
Have, say, an explorer mode and an achiever mode: Achiever mode has you play to unlock content, and explorer mode makes it easy to skip ahead, ala the New Super Mario Bros for the Wii (presumably-- haven't yet got to play it!)
I'm thinking if you have players decide in advance their play styles it won't sully the achiever's sense of accomplishment if achiever mode has no way of 'cheating' to get ahead like explorer mode. And just completing achiever mode could, of course, have an xbox-live achievement attached to it, as further enticement for achiever players.
Thinking about it, an interesting case study would be Jason Rohrer's game Passage, which has a brilliant, brilliant ending that the players can't help but get to, like a film-- you basically get there even if you do nothing other than start the game and then just sit there. It's so easy to get to the 'end' that the game goes further and actually makes any attempt at achievement you made feel very intentionally frustrating, depressing and empty -- and that, in this game, serves to make your ending even more powerful and charged with meaning.
So, in a sense-- Passage DOES appeal to both explorers and achievers-- if you try to achieve as an achiever, your ending can resonate stronger in failing to achieve a state of fiero than if you did not even try to 'win' a high score, and explorers are free to explore the entire gambit of meaning from achieving to not even trying at all (I did!)
Can most other games pull that particular trick off? Probably not-- but it's an observation I felt was worth noting nonetheless.
Labels: design, endings, writing
posted by Brian Shurtleff @ 11:16 PM 0 Comments Links to this post
Blog - Garfield Minus Garfield and Games -- New Experiences Through Removing Elements From Classic Games
Tuesday, July 28, 2009Was just reading through the website Garfield Minus Garfield again. If unfamiliar, the premise is this: a guy takes old Garfield comics, and erases any reference to the title character, Garfield the cat.
What happens is pretty spectacular-- the context of the comics is changed entirely and the comics begin to chronicle the rather depressing life of a lonely and rather insane-sounding Jon (the character who normally is Garfield's human owner).
He now talks to himself, and appears to cry or scream for no reason. His comments normally directed towards Garfield where he expresses, say, his excitement to go fold some socks, now is just idle musings and makes his life seem even more empty and meaningless than it already did.
So I'm thinking now about doing that same idea with classic games, rather than comics.
Now, I guess I shouldn't be too intrigued by this idea, as one of my first class projects as a game design student (actually, my first game design project ever, I think) was to modify a pre-existing board game by adding or subtracting one rule, and see how that changed the game.
Games, as dynamic systems, I suppose naturally lend themselves well to experimentation with what happens when you remove some kind of critical element.
When designing a game the designers are somewhat encouraged to test the limits of what needs to be in their system and does not. Everything must be there for a reason.
Yet, Garfield is there for a reason in the Garfield comics-- yet there's something really awesome that happens when he's removed.
I suppose I've seen a few things that border on this concept already in the realm of video games.
Rom Check Fail plays with the idea of replacing critical game elements from classic games with elements from a different game. Granted, it's a replacement, rather than a removal, of a critical element-- but that's still pretty close.
Of course, a lot of times, when removing game elements what results fails to be a game anymore. In board game terms, what the hell would Battleship be if you removed the battleships themselves? Or the ability to fire? Are either one still a game?
That example above provides some pretty terrible results, but this is not always the case... an extreme example of removing game elements to create an interesting new piece with a new context would be Cory Archangel's Super Mario Clouds-- a hack of Super Mario Bros. where everything but the sky was removed.
The resulting piece of art is no longer a game, or even interactive-- you just watch 8-bit clouds peacefully roll slowly on by, as though you're looking out of a surreal alternate reality window. But even though the result is no longer a game, it's a decidedly cool piece of art, at least in my opinion.
So, I'm currently having fun exploring how various games would work without their title character and their according mechanics. It's difficult to try to make the results still playable, let alone as interesting as Garfield Minus Garfield comics are. (Ironically, Garfield Minus Garfield comics are usually more interesting than the real original Garfield comics...)
Part of the problem is the nature of the avatar-- most title characters are the avatar, and with that removed, the result is typically no longer interactive. If you removed Pac Man from Pac Man, well, you'd just watch ghosts run around a maze. I suppose that's about as interesting as Super Mario Clouds, but seems a bit disappointing.
But take, say, Sinistar, a game who's title 'character' is not the player character, but the villain of sorts.
The level ending conditions of, y'know, destroying the Sinistar get a bit thrown out of whack if you removed the Sinistar itself from the game, obviously. But other than that, the game seems like it could at least function with out him, just as a kind of rather uninspired space shmup sort of game. So, sure, it works still as a game... but the only meaning provided by removing the title character is pointing out how much better the game is with him in it. :)
And on the other extreme-- remove the Halo from Halo and, well... you'd have a slightly different storyline, but the gameplay would probably be mostly unaffected. Again, the element of removal doesn't provide an interesting new context like the Garfield Minus Garflield scenario.
So I'm trying to think of more examples that would turn one game completely upside down in a truly interesting way by removing something important, just like how Garfield Minus Garfield makes for a more interesting comic than the original by removing the main character.
Labels: design, garfield minus garfield
posted by Brian Shurtleff @ 12:39 AM 0 Comments Links to this post
Blog - The Button Game
Sunday, June 7, 2009For one of my game design class projects, I was put on a team and asked to develop a non-digital game that, using the MDA framework, would get players feeling a specific emotion.
Our team chose "paranoia", and for some reason so did most of the other teams in class.
I ended up talking to a friend and fellow SCAD game design student about this project and he said that when his friend was in the same class, they had the same project and ALSO picked the same theme of a paranoia-inducing game.
And he proceeded to tell me the same idea he had suggested to his friend for the project:
"You need to design a game that induces paranoia? That's easy. Just give everyone a button, and when your button gets pressed, you lose."
Although for the project, my team ended up developing my best board game, Rats, me and that friend ended up actually making this game too.
It became simply known as "The Button Game" and for a few days enjoyed some play testing experiments around our department.
We simply purchased a 2 four-packs of tap-lights. At the start of the game, each of the 8 players who had received one of these "buttons" were instructed to tap their lights on. If their light was tapped out, they lost.
Sadly, the lack of further rules lead to the game's failure in our actual playtest sessions. People found clever exploits all around that made the game unfair or simply out of control.
So, I'm considering reviving the button game with the following rules:
Your button must remain on the table, where it was first placed at your spot at the table.
I'm remembering from our playtests back then were that several people tried to place large protective objects over or in front of their button as shields. I'm not yet sure if this should be allowed or not, so that's something for future play tests.
Labels: design
posted by Brian Shurtleff @ 5:55 PM 0 Comments Links to this post
Blog - Theme in Artificial Evolution
Wednesday, April 1, 2009I've written before on how developing a game based around a theme is very similar to the concept of building a game around a core mechanic.
One of my past projects, Artificial Evolution, benefited from being developed around a theme, and memories of this floated around my head at one point today and I feel they should be shared. After all, part of the function of this blog is to give people a look inside my design process.
When the project fell into my hands, it had already been determined that the setting for the game was a world where robots had already long since killed off all living things.
It may seem strange then that we chose the theme we did, which was evolution, with a particular emphasis on Darwinian survival of the fittest. A process that is entirely natural and biological.
Yet the game's core mechanics involved defeating other robots and stealing their parts to make your robot ever more powerful. The survival-of-the-fittest theme made at least some degree of sense given those mechanics. Why it stuck then, I'm not sure, but it did and we ran with it. Over time the game's back story and plot and even combat mechanics and aesthetics were all being influenced by the decision.
For example, we had been debating for a while how to do ranged combat. Nobody could agree on anything we came up with and it just never felt quite right for our game. We started to question why these robots would use guns or lasers at all. Wouldn't the player just be damaging the parts he was trying to harvest? How much would such weapons really damage a robot anyway? If there's no people or animals left, would guns become obsolete?
So, it dawned on us that the theme of the harsh animal-like conflict of a Darwinian world should be reflected in the combat system. Even though our robots are not animals, and for the most part don't even resemble animals, our combat began to be inspired by nature. Our robots wouldn't use weapons, they'd use their claws and go savagely for the (metaphorical) jugular. Combat became fierce, personal, and brutal.
And as your player's robot was attempting to harvest new appendages and components for itself, this form of combat made sense. You want that arm that robot has? Tear it off. I found I really liked this system as it avoided a lot of what you think of as 'typical' robot combat... there's no laser beams or buzz-saws or anything stupid like that.
And so we developed a really clever little control scheme for how to pounce onto your enemy, grappling the part you want, and tear it off their struggling, fighting body. It was pretty simple and fit perfectly.
The story that developed out of the theme was also an interesting and very atypical of robot uprising stories. Once evolution became the dominant theme, as on the one level the player is literally 'evolving' their single robot, the story actually tackled evolution in a more proper form. If robots became a species, how WOULD they evolve?
We already had established that you play a robot who goes rogue to explain the fact why you're killing all other robots, trying to take out the master computer that controls them all (the game needed some sort of end goal, a 'master computer system' seemed like an obvious choice). Just going rogue, however, wasn't a very good solution. First of all, there's too many damn robot stories out there where a robot goes rogue. And playing a rogue robot is just kind of weird when you start to think about it... players are generally too logical to be playing something that is essentially a force of pure unpredictable chaos.
So eventually the story developed where every now and then the robot species creates random variations of itself, and allow for a Darwinian run to see if any of these new robots can defeat the stagnating old robot species. The player therefore is playing one of these random variations. It made a lot of sense for explaining how the robot species works, fits the theory of evolution better than anything else, and explains the players actions and goals. The player is behaving unlike the rest of the robots but still more logically than if it was just malfunctioning because it's not malfunctioning - just a special robot designed to attempt to overthrow the rest of it's species as part of the evolutionary process. The machines created a system to improve themselves by imitating life, but yet, put in this context points out how very mechanical the process of natural evolution really is, which is a dark irony I always did love about the project.
So, the game really benefited from having a theme. And note that picking a theme that seemed initially counter-intuitive with our characters and setting caused us to create something that, even though it uses a somewhat cliche game topic of robot uprisings, caused lots of new developments that defied the typical trappings and made things fresher. posted by Brian Shurtleff @ 11:51 PM 0 Comments Links to this post
Blog - Unusual Constraint - Design a Game with a Specific Time Limit
Friday, November 14, 2008For the final project for my programming class, we are to make a game.
The twist, as always, is found in the constraints.
Constraints are interesting things. They force you to think on your feet, very creatively, as you have to work to not only think up a game that meets the constraints but preferably one that is enhanced by them. In other words, to design a game that doesn't just fit the constraints, but fits them like a glove. Constraints can lead to some extremely creative ideas and original games.
The following constraints are placed on me for my programming final:
-The game must be played only with the mouse.
-As we've not covered any code for networked play, our game is limited to being a 1 player game.
-It's a student project, so, not surprisingly there's no budget.
-The deadline, of course. There's always a deadline. We have 1 week.
Finally, there's the really interesting one:
-The game play has to last exactly 15 seconds.
I'm interested by this surprising challenge. I tend to think of play time only much more generally, as in "this phase of the game is taking the players too long to complete", etc. This constraint is another matter entirely. What mechanics and dynamics benefit from such a brief and specific time limit? Which ones support it?
What narratives would make sense to explain why there's a time limit in the first place? Does the short time limit lend itself more to a casual game or something more hardcore?
It's been fun to think about while I had to come up with my game concept pitches.
Labels: constraints, design, game design, time
posted by Brian Shurtleff @ 12:50 PM 0 Comments Links to this post
Blog - SIEGE 08
Sunday, October 5, 2008I just got back from the SIEGE 2008 convention.
To those who met me there and found your way here, welcome to my blog!
I had a great time, and networked harder than I ever have before as I really pushed myself to talk to people even if I was nervous.
Given that every guest speaker who worked with EGD's Atlanta camp were people I had met at SIEGE 07, I decided to wear my Emagination work shirts for most of the con. After all, it is a game industry-related company in the Atlanta area, so it deserves some representation there. So, if you saw an Emagination shirt there, that was me.
Speaking of shirts, I won a t-shirt there as well, as my team had the winning game pitch for Brenda's Iron Designer Challenge, a game design challenge ripped straight out of her recent book with Ian.
It was a brutal challenge: in a short time limit, we had to create a pitch for a game that simulates a battle from the civil war which does not involve eliminating enemy soldiers or acquiring territory.
Needless to say, that is a difficult game to design, so I'm glad we accomplished the feat along with all of the other teams, and our game was selected as the best by the judges.
Congrats to the rest of my team should any of you stumble your way onto my blog (I know at least some of you got my card...) and honestly, to everyone who participated and completed such an insane design experiment. :)
Labels: design, networking, SIEGE
posted by Brian Shurtleff @ 9:12 PM 2 Comments Links to this post
Blog - Childhood Recall: Drawing with Crayons
Thursday, September 25, 2008Being at an art school after all, I've found myself in a traditional art class (i.e. drawing) this term.
Based on my professor's recommendation, I tried out this new material to draw with today (Prismacolor sticks) and found them very pleasurable to work with.
Now, I'm not one of those artists that like to get all dirty and paint-smeared when they work. That's why I find the primarily digital art required of video game development to be appealing. No mess! So, I've never been a fan of many kinds of art materials. Pastels, chalks, and charcoals get all over my hands and clothes and that bugs me. Paint can as well, and requires too much set-up and clean-up for my tastes.
I assumed this suggested material would be similarly annoying to me (it LOOKED like pastels/chalks) but was surprised when I touched it that it was waxy and didn't rub off onto my skin at all. That was a huge perk, but it also performs its function very well. It smoothly draws very nice, thick lines.
What does this have to do with game design, you ask?
I recognized that I was really enjoying something -that this particular tool was making drawing more pleasurable for me- and my game designer brain couldn't just ignore that fact. I had to think about why it was making the act of drawing more... well, "fun".
Now, it could have just been any of the things I've said above. It had a nice feel to it (tactile quality, which is always interesting to examine in games), and made drawing slightly more effortless then the pens and pencils I'm used to using.
But thinking about that, I'm wondering to what degree I enjoyed using this material because it reminds me of a crayon. It does, after all, come in short sticks, makes thick lines, and has a waxy sort of surface to it.
I already note that many play experiences found in games owe some degree of ancestry to common forms of play people experience as children.
The Sims involves elements of 'playing house', 'playing pretend', and dress-up, for example.
Doodling/playing with crayons is something we do as children, and I'm wondering if using this new material is recalling that experience in a similar way. posted by Brian Shurtleff @ 2:10 AM 0 Comments Links to this post
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