Showing posts with label Design. Show all posts
Showing posts with label Design. Show all posts

Wednesday, February 27, 2008

Two Great Tastes

It's getting late and I'm browsing my RSS feeds while my wife is getting ready for bed. Just browsing, a bit tired and droopy, when I spot this: PlayStation Eye Headtracking Requires Nothing But A Face on Kotaku. My brain ticks over, reconsidering how cool it would be to remove some of the limits. I say reconsidering because I was instantly reminded about the Johnny Lee demo using the WiiMote and a modded pair of safety goggles.

I scroll down a bit, scanning the comments, initially because the PlayStation related video is region locked, so I can't view it. And I run across the Johnny Lee video again, which I watch, because it is just so cool. You can watch it again (or for the first time below).



So I was thinking how cool that would be but how unfortunate it is that it only works for a single active player. Part of the fun of games, especially as they get more physical, is the interaction and ability to share with others. However, observing a Desktop VR game played by someone else would be difficult. Playing would be impossible.

Unless you could show more than one image on the screen. Which, apparently, you can.
Texas Instruments' Dual View: Look Ma, No Split Screen (Kotaku, again)

So, a video game that allows both VR and observers. Or even better, a games that would allow dual VR displays for head-to-head or co-op play. That would be a great taste of games to come.

Sunday, July 08, 2007

Getting Inside Your Head

Two years ago, before I began Ghosts in the Game, I probably wouldn't have been able to tell you the difference between Story and Gameplay in a videogame. This is not because I was a half-wit (despite popular opinion). It was because I didn't know the difference, and I didn't care. I was a consumer of games, books, movies, and music. I loved (and still love) story with a passion and went looking for it everywhere. I couldn't see the gameplay, I was blinded by my passion. I genuinely didn't know what parts were story and what parts were game. Most people don't. Most people don't care.

I have the fondest memories of playing Circle of Blood (The Broken Sword, for you Europeans), and The Dig, and Grim Fandango. These games enthralled me with their stories as much as any book had ever done. I was amazed by the power of a videogame to draw me in, make me care about the characters, and keep me interested by making me a part of the solution. It was these, and others like them, that inspired me to pursue game design specifically as a medium of telling stories. Which has led me here.

In all media there is a curtain that separates the creators and the audience. Most people are blissfully unaware of what goes on behind the curtain, in the realm of creation. Some are even unaware the curtain exists. It allows them to enjoy the magic that is created and presented to them. Sometimes the curtain slips, and they glimpse the gears and pulleys that are driving the show, but soon enough they forget. Those behind the curtain, however, can always see the machine if they want to. Once you know something is there, and how it works, it is a small step to see it everywhere. I've started to move the curtain of game design aside, and now I can see the gameplay.

Which in some ways makes playing games for their narrative, and their story, harder. Too often I see the gears of gameplay I never noticed before obscuring the potential of the game. Going back to play many of my beloved adventure games leaves me more frustrated at the clunky and obtuse mechanics employed to block my progress than elated by the discovery of character, setting, and plot. I see the puzzles for what they are to the gameplay, and can't get past my broken immersion to truly enjoy the story I'm exploring. This happens most when the story and the mechanics don't match.

Psychonauts: An Exploration of Mismatched Mechanics
I have experienced Psychonauts from the opening sequence to the final Boss in the final mind, and the sequel expectant epilogue. The impression it left on me was a good one, and I would recommend it to a great many people. However, I am forced to describe it as a game with a split personality. On one hand (or mind) it is one of the best story games I've played in a long time. It has rich world, unique and developed characters (for most of the minds you encounter), a subtle sense of humour, excellent dialog and voice acting, and surprising hidden depths. While the story itself is linear (more so as you progress), the game provides you with ample ability to explore at your leisure, allowing you to discover the characters and world as you progress.

However, your leisurely dip into the psyche of the game is often halted and battered by the action-platform mechanics used to make it a game. You encounter frustrating jumping and dodging puzzles, often made more complex by the same landscapes that add personality to the usually dull and repetitive platform genre. You have many Boss fights that serve no purpose greater than to pit you against a strong enemy at the end of an area. And, most heinous of all, in a game that normally gives you free reign on pacing you encounter areas and challenges that force you to run and react instead of observe and explore; killing you time and again when you fail to jump or dodge at just the right moment.

The game tries to alleviate these short-comings by providing copious amount of help to the novice (or untalented) player. The physics are as forgiving as possible. Death is never absolute, health is plentiful, and lives are easily restored. There is even an in-game hint guide given to you as soon as is feasible by the story: encounter a new enemy, difficult enemy, or unstoppable Boss and simply call on Ford Cruller for a quick but of advice. If you get stuck (especially in Boss fights) the game is apt to just give you the hints you need anyway.

But why is there all this emphasis on making the action-platform gameplay easier? I think that a lot of it was added in an attempt to make the mechanics invisible, or at least ignorable. The game really isn't about jumping and shooting and running and dodging. The game is about delving into the (sometimes warped) minds of those you encounter on your path to save the world, and your girlfriend. Half the psychic talents have no use during the action sequences. Most are best applied to creative puzzles born of environment deep seated emotional trauma. A couple are only used a handful of times because as the game progresses it increasingly relies on action to draw you along instead of the mystery and discovery that hooked you in the first place.

The game becomes a mismatch of story and mechanics. The story is lost to the adrenaline rush needed to progress. The gameplay is hampered by the detail and design used to support the storyworld. In the end you get a game that has brilliant moments, and terrible ones. It contains aspects of drama, humour, action, suspense, and thrill but lacks a sustaining feeling. You get a game that despite its flaws is brilliant. And I can, sadly, understand why it never sold well to the mass market. The split personality is something that would ultimately grate on an audience that doesn't care to sift the story from the gameplay. An audience that shouldn't have to.

Mind Meld
I believe that there can be a balance between the story told by a game, the story created in the experience of play, and the gameplay itself. I don't think it is necessary to remove or replace what we know as gameplay mechanics to be able to tell a creative and deep story -- to build a world the player can explore. I do however think that choosing your gameplay to suit your story is an often overlooked, and sometimes ignored, part of development. When pitching a game, its easier to sell the fun than the depth.

I used Psychonauts as my example for two reasons: I had just finished the game when I started writing this post, and I believe that it could have been a better game. In fact, it probably could have been two better games. One would have had an incredible story about a kid discovering the power of his mind. The other would have been a kick-ass game with psychic powers used to create incredible action. By mismatching the story they wanted to tell with the gameplay they wanted to sell Double Fine wound up with an amazing game that I enjoyed immensely and fought with constantly.

Wednesday, June 13, 2007

Toys

Did you know that there are still people complaining about Wii Sports? And half the mini-game based games for the Wii. These rants and screeds usually devolve into complaints about the game graphics, or lack of depth, or even the control scheme. Some even go so far as to claim the Wii has no real staying power because the games released so far have been targeted casual gamers. But Wii Sports (and Wii Play) aren't games: they're toys. And because they are toys, they are perfect for getting people interested.

This post started in my head as a series of complaints against Wii Sports and Wii Play. I am a gamer, and I do seek more depth to the games that I play. These two titles are the mental equivalent of those ball-bearing spatial puzzles. I can play with them for a little while, but they become boring and repetitive. They lack even the mental addiction of having achievements and awards to collect. They are McDonalds(tm) Happy(tm) Meal(tm) toys and Cereal Box Boardgames. There is the potential for a a lot of interesting gameplay, but these games are not intended to provide it.

I would love to see well visioned golf game using a similar control to Wii Sports. Or a fully developed tennis game, or bowling tournament game (build and manage your bowling alley, while developing your bowling skills for online tournament play!). You could do more sports - like hockey, skiing, curling - and add levels of training, competing, and online play to flesh out the games into serious amounts of play. I'd love to see a full billiards simulation with multiple games/rules, trick-shot challenges, online play, and serious tournament handling. All of these ideas could even still use the Miis for avatars, just make the games deeper.

But Nintendo didn't want to the first games that new players encountered to be games of depth. Or real games at all. The best way to hook the uninitiated isn't to swamp them with detail, it's to give them a toy. What is the first game you are going to give to your non-gamer aunt to play: Twilight Princess or Wii Sports? The game that takes hours to play, or the toy that she can play with for hours? How about your uncle who loves sports, but hasn't touched a game since Pong? Would you dump him into an advanced golf or tennis game where you need to play tournaments and learn advanced skills, or would Wii Sports be the very first thing he plays and then the other sports games later?

Nintendo knew that the way into people's homes was to create something that everyone could play, and that everyone would play. Hook them by removing the mental barriers that the video game community has built around itself. Nintendo knew that toys have a much lower mental threshold than games do. So the first things you encounter when you buy a Wii are toys. If you get hooked, you'll look for more depth on your own.

I originally thought that Wii Sports was just a glorified tech demo. Something packaged with the system to show off what would be possible, and how to use the new controls. I was wrong. Wii Sports comes with the system so that you can show it to everyone you know, gamer or not, and they can play. It comes with the system so that the grandmother who buys the system already has the first toy, no video game store confusion. It comes with the system because it is the gateway to gaming: toy play.

Now Nintendo just has to get the real games to the waiting public. What's the hold up Nintendo? That's another post.

Wednesday, December 20, 2006

Reindeer Games

Holiday music usually sends me into a bit of a state. Don’t get me wrong; I love this season, filled to the brim as it is with good will, holiday cheer, and rampant consumerism. The thing that gets me – what really makes me twitch – is the repetitiveness of it. How many times can you listen to “White Christmas”? How many badly sung and poorly arranged pop-girl versions of “Frosty the Snowman” can one season take? And the radio stations and malls have been playing this stuff since the middle of November, without pause. Which is why I tend to retreat into the obscure back aisles of holiday music. If I must recognize the season through song (and I must), at least I try to do it via underplayed, unrecognized, and unusually odd jingles.

Without further ado: 5 Obscure Christmas Songs Games

5) The Same Christmas Cake (The Arrogant Worms)

Christmas makes me realize how greatly things do change
Friends lose touch, people age, and family moves away
But it is what had stayed the same that gives me the most tears
For I've had the same Christmas cake for almost thirty years

Granny made it back in sixty-eight and gave it to my mom
Who gave it to her uncle who gave it to her son
Who then gave it to me and that is where it stuck
For I was only three months old and clearly out of luck

Here’s your basic Match-3 rip-off, casual game. You have to escape the curse of the Christmas Cake, and to do so must match and remove the festive coloured candied fruit pieces. Not much here, except a theme, a thin back story, and a really odd song.

4) I Want an Alien for Christmas (Fountains of Wayne)

I don't need any ugly sweaters
And I don't play much basketball
But there's something kinda special
That I want most of all...

I want an alien for Christmas
Bring me an alien this year
I want a little green guy
About three feet high
With seventeen eyes
Who knows how to fly
I want an alien for Christmas this year

I have two pictures that pop into my head here. One is of the crappy two-minute flash games where you are either dodging or catching something that is falling from the top of the screen. The second is a 2-D platformer where you go on a mission to get an alien for Christmas, then have to take care of him, and play with him. I think that the two could be combined into a short Flash-based game where you have to jump dodge and fetch various items while avoiding bad presents, federal agents, and angry alien parents (but perhaps not all at once). Again, not the deepest of stories or gameplay – just something fun for a holiday break.

3) Chiron Beta Prime (Jonathan Coulton) [Bonus Link]

Merry Christmas from Chiron Beta Prime,
where we’re working in a mine for our robot overlords.
Did I say overlords? I meant protectors.
Merry Christmas from Chiron Beta Prime.

On every corner there’s a giant metal Santa Claus
who watches over us with glowing red eyes.
They carry weapons and they know if you’ve been bad or good.
Not everybody’s good but everyone tries.
And the rocks outside the airlock exude ammonia-scented snow.
It’s like a Winter wonderland.

I think that this song has only one place to go: Christmas ‘Shmup. Start as a Christmas convoy from Earth, carrying presents past the defenses of the Asteroid Mining Company to the indentured workers on the surface of Chiron Beta Prime. Levels could include: Open Space, Asteroid Field, Ammonia Winter Wonderland, Mine Shafts, and Escape from Chiron. Swoop in, drop of the holiday cheer, and escape with your life (and maybe a few freed slaves – I mean volunteer workers).

2) Oh, Santa! (Veggie Tales, Silly Songs with Larry)

Umm… this one needs a video.

This is a social game, involving the sharing and passing of cookies. Something like a cross between Lost (the game, not the show – invite here), and the Zune commercial with the never-ending DRM-infected cookie. Only without the icky DRM. You start with a few cookies to share, but you need to hurry or they can be stolen. Share them and you’ll get more as your friends share theirs. Or steal cookies from already invited friends to keep your stock up. The game could run as a special promotion in the weeks running up to Christmas. You need to finish the week with at least two friends and one cookie to get a special “gift” from Santa. Incentives go to the sharers, and while the game seems easier if you steal, it winds up being easier to lose (I think that you’d become a bigger target for other thieves).

Basically a light, social game to promote sharing and community during the holiday season.

1) Elf’s Lament (Barenaked Ladies)

I'm a man of reason, and they say "'Tis the season to be jolly"
But it's folly when you volley for position

Never in existence has there been such a resistance
To ideas meant to free us
If you could see us, then you'd listen

Toiling through the ages, making toys on garnished wages
There's no union
We're only through when we outdo the competition

I make toys, but I've got aspirations
Make some noise
Use your imagination
Girls and boys, before you wish for what you wish for
There's a list for who's been
Naughty or nice, but consider the price to an elf

This song (and if you haven’t heard it, I’d encourage you to find it and have a listen) has the most depth, and as such has the most potential to inspire gameplay. I could see this being enacted as a full-sized economic sim and construction game. Cross the building and management play from a Tycoon game, with a deeper economic strategy (to manage the work force and changing product demands), and then give it the visual styling of the later Santa Clause movies.

Build the North Pole from a tiny little one-room workshop into a bustling hidden city of candy-coloured buildings and toy manufacturing machinery. Deal with all sorts of obstacles of progress including unionization of the elves, outsourcing of production, time and resource management, campaigning and funding to support the internal economy, and more. Create whimsical production devices by combining simpler assembly gadgets into larger contraptions. Micromanage by assigning work shifts and duty rosters, or let the elves manage themselves and reassign as factories become automated.

Delivery’s a snap, it’s making the toys that’s the challenge.



Thursday, November 16, 2006

Grammatical

To understand what use a Grammar of Games would be, I’d like to take a walk through the use of grammar in other mediums. I’m treating this as a thought experiment, so please hold onto something; this might become a little bumpy.

How about a definition to start us off? Dictionary.com gives us this:

  1. the study of the way the sentences of a language are constructed; morphology and syntax.
  2. these features or constructions themselves: English grammar.
  3. an account of these features; a set of rules accounting for these constructions: a grammar of English.
  4. the elements of any science, art, or subject.

Notice that the majority of the definition concentrates on language. Particularly on the rules that can be extracted from it, or applied to it, to create consistency. Grammar is a set of conventions developed and applied to allow easy communication. Not only language itself (syntax, conjugation, punctuation), but also any subject matter with sufficient history to have developed definable elements.

So, based on this definition, games already have a grammar, or are at least forming one as we continue to deepen our knowledge of creating and playing them. Any time we talk about aspects of a game, gameplay, or design we are using our established grammar to communicate ideas. However, as games (and especially computer enhanced games) are relatively new, the grammar that we have is incomplete and ill-defined.

Shifting Sand

One of the fascinating aspects of language is how it changes over time. I’m not just talking about lexicological shifts – words are created or acquire new meanings or contexts over time, that’s a given. Grammar shifts as well. This can be seen most dramatically in they way that punctuation is used today, as compared to even a decade ago. While some of this is due to haphazard education, laziness, and apathy, some is purely a result of cultural shift.

Go ahead and pull out any given paper or essay that you wrote in school. Something written at the high school or post-secondary level. Compare the grammatical construction of that writing with your last blog post or e-mail. What do you differently online than you did on paper? These shifts in grammar are not just limited to the internet. As new forms of communication become the de facto standard the grammatical shifts leak into other means of communication.

In the digital community shifts such as these are accelerated. Think back over the last year or two of game design, gameplay, and the theories that hover around them. How many new ideas were put forward? How many terms bandied about, discussed, created, changed? How many theories of design toted, praised, rejected, argued? The list is a lot longer than the number of changes to punctuation created in the same time frame.

From Analysis

I do believe that we are on a solid path to developing a mature grammar for games – play and design. For instance, there are people who are dedicated to the analysis of gameplay. The goal, so far, is to understand how and why people play. This gives us a foundation for analysing what people enjoy and giving us meaningful feedback about it.

Without the language to describe the systems, and our interactions with them, it is impossible to separate the elements that work from the elements that don’t. By elements, please don’t think that I’m trying to define games as something that can be broken into Lego-esque building blocks for easy reconstruction and recombination. It is more chemistry. There are atomic building blocks, but also formula and restrictions that must be discovered and communicated. A mature grammar can be developed by deconstructing (to a point) existing formula to discover the combinations that went into the mix.

To Design

Grammar isn’t going to solve all of our big design problems. You can’t take the short story you wrote about dragons in the fourth grade, upgrade the grammar and spelling, and expect an award winning piece of fiction. Grammar is a support, a framework, and an ideal – it will not create on its own. Designers will forever be struggling against conventions, story, and play in an attempt to create something new.

It will, however, strengthen the core of design as we push for the edges. By applying our grammatical tools – structural analysis, play styles, gameplay notation – we can strengthen our work. This process will become akin to editing your writing. You go back over the work using critical analysis (proofreading) to find grammatical hitches. You add a comma here to create a necessary pause. Something gets re-written to remove ambiguity. An element replaced to create a deeper symbolism.

(…)

I think that I’ve wandered enough for one post. What I’ve tried to imagine is a series of tools, conventions, and definitions – a common grammar for games – that would enable us, as designers, to better understand and develop our work. I see it as incomplete right now (perhaps perpetually), but in progress. I see it as worthwhile to pursue and understand. Just so long as we don’t forget that it will not solve our problems, and it will not design our games for us.


Thursday, September 21, 2006

Conventioneering

I have a great many “strong convictions” about conventions, or so I have discovered over the past week as I thought about this month’s Round Table topic. By “strong convictions” I mean to say baseless opinions about good design, how to achieve it, what works, what doesn’t, and a raft of other topics. It comes from knowing a lot of theory, but having little practice. In truth, I had a much longer and deeper post about conventions, user interface, and bringing non-gamers into a gameplay space. Lots of theory. Something I should probably stay away from.

I’ve also had my ass kicked by a strange combination of work, head cold, Animal Crossing, and Fraggles. The first two led me into not wanting to do much but enjoy the latter two. Also, Katamari. Hopefully more on some, or all, of these things in other posts… On with the conventioneering!

The first thing I’d like to do is forward a definition of a convention. A convention is an arbitrary pattern within any information space that is recognized and adopted by designers and users. Joel Spolsky refers to is as a “mental model” held by users and programs alike. If the mental models of two interacting entities match, then there is recognition and compatibility. If, however, they differ, there is confusion, frustration, and the need for at least one party to adapt. Invariably, the hard-coded model forces the other to change.

Conventions are a short hand in most design. They are a series of well recognized mental models that will provide a specific user-base access to your design. In UI, this is the 3D button, or the check box, or the underlined link. In games this is the right thumb-stick to move the camera, or the Tank-Healer-Assassin-Mage class system, or the Jump-On-Enemies-To-Kill-Them. If you use a convention, then your design can be understood with ease. If you subvert, invent, or break conventions then users must adapt to your system before they can fully use it.

Should conventions be used? Of course. Without conventional design there would be impenetrable barriers between technologies. People would never want new software, or hardware, or books, or music. Does using only conventions produce stale technology and design? Yes. Innovation demands new design, which leads to new conventions or adaptation of older ones. Are all widely accepted conventions representative of best methods? Of course not. Conventions are publicly agreed upon and are therefore often bloated and inefficient.

Can you do better? Should you try? I would have to say that sometimes you should. But mostly you shouldn’t. If you are trying to create something mainstream you need to use conventions that are broad, intimately understood, and easy to learn or teach. New conventions are none of these things. New conventions are for narrow audiences, cutting edge design, and the leaders of the pack. The middle 80% won’t go near your work until everyone else is doing the same thing. So how do you win? How do you innovate without alienating?

Saving the Baby

My first example of new design, focused on the mainstream, that appears to buck convention is the iPod. Apple’s little music player that could. But what makes the iPod so special? Is it sleek physical design, or funky advertising? Does success come from supporting software and media, or a brand name backing? I would argue that there is one thing that caused the iPod to stand above the competition, both past and present (excepting the Zune, jury’s still out on that one). Interface.

Apple innovated by adopting broad, and unused (by MP3 players of the time), interface conventions to make navigation easy. By utilizing the same principles as a dial, users were easily able to understand and better navigate the information provided through the touch wheel. By providing a familiar file system, and a large screen, the information could be clearly displayed. The difference between the iPod and its competitors became ease of use through a non-cryptic interface.

And this line of thinking follows into today, and games, through the Wii. By subverting existing interface conventions Nintendo intends to make video games accessible to a broader demographic. The controller is a remote, found in nearly every couch across America. Everyone from your 2 year-old nephew to your 96 year-old grandmother knows how to operate a remote.

The primary interface the remote provides is a point-and-click system. No more highlighting with the left hand and selecting with the right. Just point at the screen, and click. Even movement is a convention we understand far better than current game controls. How many people, when swinging a sword, or tennis racket, thinks about twitching their thumbs? It is easier to have the interface be the action.

Engineering has let us remove some of the layers of interface. We don’t need to invent new conventions to create new forms of digital play. Sometimes it is as easy as finding old conventions – hidden conventions – that make more sense. It is simplicity through better conventions.

Additional reading includes Joel Spolsky’s online book User Interface Design for Programmers. If the idea of creating an interface has ever scared you, confused you, or caused you to pull your hair out, then you should read this.


Friday, September 15, 2006

Inkblot – Post Mortem

Timeline (or 2 1/2 Weeks Too Long)

Week One – Spinning My Wheels

My first week of the competition was spent in Saskatchewan, at my parent’s house. They live in one of the most rural provinces of Canada, in a small town, and half of my family was going to be working for the week that we were there. I took my laptop, loaded with Visual Studio 2005 Express Edition, and high hopes of Getting A Lot Done. I did. And I didn’t.

I spent the first week trying to work out, in code, how I was going to make my vision of a spreading stain of ink come to screen. I was playing with Visual Basic, partly because I could. Partly because VB let me set up applications very quickly, while writing minimal code, so I could tinker. These were some of my first Visual Basic .NET programs ever. To my credit, I did slap off 6 different prototype designs trying to get the blob to move and draw right. By the end of the week I was ready to go home, but I had my mechanic.

Week Two – Getting Up to Speed

Shortly after getting home I had a revelation that could have saved me the previous week. Now I had a good idea of what I needed to do. I was ready to jump into some code. Except, I wasn’t going to be able to program a whole game from the bottom up. Three things were critical to any “game framework” that I was going to use. It needed to be primarily 2D (or at least have really good 2D support, and allow me to do pixel operations). It needed to be easy to use (language wasn’t too important, but one I was familiar with would be ideal). It also needed to be free.

I found the PopCap SexyAppFramework. This is the backbone that the best PopCap Deluxe games have been programmed on. As a bonus, it came with a series of demos to get me up to speed. Week Two was spent learning the PopCap Framework, and reacquainting myself with C++. By the end of the week I knew how I was going to implement my blob, and the shape of the game itself.

Week Three – Dash to the Finish

I programmed 70% of the finished game in the third week. It was hectic and busy. I spent two to three days taking the framework and building the foundation of Inkblot. Resource Loading, Title Screen, Game Board. All the supporting code that makes it run. Only then could I make it dance. I built the procedural blobs that you play against. I added user control. By Friday I had an almost game. There was no reason to play it; it was more of a toy than a game. I could have handed something in, but it wouldn’t have been finished. Then we got an extension.

Week Four – Cruisin’

The addition of a week changed Inkblot into something playable and, I think, fun. It also changed me from stressed and manic into laid back and happy. What happened is that gameplay took shape. Inkblot went from toy to game in several easy steps. I added input through the Dance Pad (thanks to the code provided in the EGP Framework). I added a goal, with limits. I added feedback. And then I added cycles. All of this was simple and easy. All of this made all the difference in the world.

The Missing Half

For those keeping score at home, there is still half a week of time missing. The Contest (part 2) technically ran from August 16, when the winners were announced, until September 15. 4 1/2 weeks. The first half a week I was getting ready to go to on vacation, I was busy with work. I did nothing that furthered Inkblot. If I had been on task, the first 2 1/2 weeks would have happened before the second part of the competition even began. I would have had more time to do what counted. In reality I had two week to program Inkblot. I should have had four. The missing half was really the first half.

Things I Learned (or Trite But True)

Any “realistic” system can be cheated (and is usually better if you do)

I’m a bit of a purist. I think it comes from my engineering side. I like equations and simulations, things that are clean. Cheating is dirty. But cheating not only gets things done faster, it sometimes does them better. The way the blobs work can be explained, technically, as a field effect. Each drip exerts a field. Where two drips overlap the fields add. Everything not above a threshold value is removed. This makes smooth areas where the drips touch.

Practically speaking, this is a number of image blits, each drip having a transparency gradient from the center to the edge, followed by a masking operation to smooth the edges. This is faster than running all the calculations needed for the pure way. It also allows me to draw with non-perfect shapes, which makes the blob seem more uneven, without adding any overhead. Faster and better. It took a week to get to this because I went looking for a pure solution.

Things always take twice as long as you expect (even if you expect them to)

This is just a fact of life. I thought I could learn the PopCap framework and have the core of the game up and running in less than a week. It took much longer than that. If it wasn’t for the lenient attitude that the EGP and RedOctane have had for this competition, I would have bitten the dust weeks ago. Maybe I’m out of practice (actually, I know I am), but even when I was on time, things took longer than I expected. There are always little bugs to fix, and little tweaks to make. It all adds up.

Plan for life to get in the way (because it will)

You need to make time for everything else. I thought I could work on my vacation. If I had stayed home, maybe I could have. Even though my family knew I was working on something, it was still more important that I spend time with them. The rest of the competition was the same. I’d get some time uninterrupted, but I’d also have those days where things needed to be done. Locking myself in the computer room wasn’t an option. Sometimes life (and other people) are more important.

The feature you want won’t be available (and creating it will take too long)

Corollary: creating a workaround only saves time if you only do it once. My practical example is the numbers that count in the level. The PopCap framework has a nice system for image-based fonts. The problem is that they have no easy way to scale the fonts or print larger text. Making the numbers grow and fade would have meant creating a new way of drawing fonts. The workaround was to use preloaded images. If I’d needed to do it again, I would have had to duplicate the process. It was a singular quick-fix. It works, but only because I use it once.

What Went Right (or The High Points)

I feel the game turned out quite well, and I am happy with the result. In fact, I found that the closer I got to completion the more it would up looking like my initial proposal. Or at least the proposal in my head. Procedural blobs worked better than I had hoped, and meant that I didn’t have to waste my time on generating art. It also means that the game can play forever. I wanted it to be fun, and challenging, and simple. I feel that I’ve achieved that. People can use different strategies for getting the blob to fill the space. I wanted people to move, and press lots of buttons, and stretch themselves a little to do it. I think they will.

What Went Wrong (or The Laundry List)

I could list a bunch of things, I suppose, that failed or went awry. Who can’t? The worst three things that happened were: wasting the first weeks, not playing it enough, and not having sound. I’ve gone over, in excruciating detail, the first point. The second point is self evident. Games cannot improve in a vacuum. They need to be played and then they need to be made better for it. For all that I think Inkblot is fun (and so does my wife), I don’t know that you will. I could have done more to find out.

Not having audio is a minor point, but one important for creating a polished work. You’ll notice that there is rudimentary functionality written into the game to handle audio. There are sliders for music and SFX in the Options Dialog. The code that it would take to load sounds, and play them back, is minimal. It would take nearly no time. But finding or creating the rights sounds wasn’t on my timeline. It has no sound because I didn’t want to tack something on, and I didn’t set aside the time to do it right.

Conclusion (or Wrap it up Already!)

I had fun with this project. Even with the extra time that it has taken, it never become insurmountable or painful to work on. It was a challenge, and I enjoy those. It was invigorating to have something to program, and it was even better that it was my own design. I went into this competition hoping I would get a chance to design, to program, and to grow. I’ve done all three, so I’d call this a win.

I hope that you enjoy playing Inkblot half as much as I enjoyed the time I spent making it. If you’ve been reading this and still haven’t played the game, perhaps now would be a good time. Thanks for reading, and playing. Comments go at the bottom. :-D

-----
Download Inkblot here, or check out the other games and EGP Comp 2 entries at the Experimental Gameplay Project.

EGP - So Much For Mini Updates

Yeah, my bad. It's not that I don't love you. It's just that I suck at blogging in general. I have lots of things to say. I thought about posting mini-updates several times in the past week. I didn't though. I was working, or I didn't have time, or I wasn't in front of a computer. Stupid excuses. No glimpse of my working habits here.

So, on to news. Last Friday was the Experimental Gameplay Project - Competition 2 deadline. Until they extended it by a week at the 11th hour. Today is the new deadline. The extra week has been a godsend. I went from having a neat idea, and half a game, to having a playable and near complete game.

Playtesting happens today. The game gets tweaked, polished, and submitted. It feels nearly done. Truth be told, I'm pretty happy with it.

The Post-Mortem goes up tonight (after I write and edit it). So does Inkblot. If you get a chance, check it out.

Wednesday, September 06, 2006

EGP - Best Supporting Code

When you sit down to design a game, especially when you are working around a simple idea, or striving for a focused gameplay experience, you tend to think along focused lines. I began thinking about Inkblot (in a rough and unfocused sense) back at the end of July when I first read about the Experimental Gameplay Project’s Contest. Over the following weeks, I focused on what I wanted to create, trying to get a clear picture of it. I thought about the Dance Pad – how I could use it in a unique way. I thought about the game mechanics – how the blob should move, and grow. I thought about feedback loops – how I was going to drive the player on, and reward them for playing well.

What I didn’t think about was all the rest of the stuff that has to go into the game before, and around, the gameplay to make it into a whole. In short the supporting code. The Academy of Motion Picture Arts and Sciences gives high regard to actors and actresses in supporting roles for a reason. While they may not be the stars, with all the focus and glamour, the films they are a part of would be pale and flat without them. So to in programming.

I have spent the past two days getting an outline of my game working. I had to work on supporting art resources (not my strong suit). I had to code together the core objects that make the game a program. At the moment it can load resources, change some core options (such as 3D acceleration and Fullscreen mode), and get into a Game Start mode. Fortunately the framework helped a lot, and will continue to do so.

This has been a big lesson to me. I tend strongly towards two activities, Design and Problem Solving. These are the things I love the most. I like to envision new ideas, map them out, and develop them into solid concepts. Most of this happens off-screen, in note books, on scraps of paper, and in my head. I also like to design creative solutions to difficult problems. Whether this is writing the prototype code to do something cool, or finding and crushing the obscure bugs, it tends towards unique and challenging tasks.

I don’t like to write menial code. I hate setting up boring classes, writing dozens of accessors, and generally getting the foundations of the program poured. I would be happy if every task was a new thing to learn, or a new challenge bright and clear. Then, after each solution is revealed, pass off the boring implementation to someone else. Life’s not like that, and good programs (games or otherwise) need a lot of good supporting code behind them.

I should have set more time aside to get my game structure working. So far it’s been 8-9 hours on the code, and about 4-5 on the art. I only got about 4 hours last night, but I made sure that the application ran, and was ready for the gameplay.

Monday, September 04, 2006

EGP – Down to the Wire

I’ve been slightly absent in my blogging as of late. Not due to inactivity, mind. Just unable to find the time to sit and write. So much for that, I’ll make time. I’m back, and I’m going to make a point of putting updates back on track. If this is coming out all disconnected and strange, it is because my brain is occupied elsewhere; I apologize.

First, news: At the beginning of August, the Experimental Gameplay Project kicked off its second Gameplay Competition. Sponsored by Red Octane, the EGP set off to cover new ground and get intrepid programmers and designers to create new ways to play. The challenge – Create a non-rhythm based game designed to be played with a Dance Pad. Round One consisted of designers putting forth their best ideas. The chosen designs (15 in all), would move on to Round Two.

Round One Winners got mailed an actual Red Octane Ignition Dance Pad (yes, they gave away 15 of these for really simple designs!). We now have until the 8th of September to prototype out designs. Yes… we. I was set alight by an idea. I submitted a design. I was chosen to go on to round two.

I’m now on the wire.

-----

This is the final 5 days of the competition.

I’ve been quiet (blogging-wise) up to this point: partly because I’ve been busy and party because I’ve been spinning my wheels. I’ll admit that I’m a bit rusty when it comes to programming and prototyping for windows. I have a tendency to over-design and over-think problems. The practical upshot of this is that I spent the first week (during my vacation) spinning my wheels on ideas. I created half a dozen prototypes trying to get a graphical idea to work. I managed it, but at the cost of a week.

The second week was me trying to get my brain into game-programming space. I needed a game framework that would allow me to do direct image manipulation, which was easy to use, and that was free. I found a few and settled on the PopCap Games Framework. I spent the second week learning the API and game programming practices. I was back at work, and learning a new API is not the lightest thing in the world. Week two, cram session.

So where am I now? I’ve got a framework. I’ve got a prototype layout. I’ve got some graphical resources. It’s about to get wacky. Stay tuned this week for micro-updates and pre-mortem breakdown. Perhaps even a few glimpses of Inkblot.

Tuesday, July 25, 2006

The Medium is Not the Message

The discussion of narrative and story in games has cycled back again. I started this blog because I found myself reading a number of blogs and articles on the subject and in need of an outlet for the overflow. Here we are again, this time discussing the role, or perhaps roles, that story and narrative have on games.

A reiteration, in a brusque and slightly inaccurate fashion, of the posts and positions recently presented:

  • Computers can’t tell stories, because stories are complex, so a computer creating interactive fiction is silly. (link)
  • The story is not the game. It is just a small element, like other aspects of gameplay that give the user feedback and should be used as such. Anyone who thinks otherwise is a story snob. (link)
  • Stories follow certain forms, granularities, styles, and levels of immersion. Despite current “wisdom”, story is not expensive and perhaps necessary to draw new players in. Story is therefore obvious. (link)
  • Any story that can be seen, or is being delivered is a bad story. All interactive stories should be transparent, any visible story is worthless. Story is everywhere and should not be treated as a separate segment of design. (link)

-----

The thing that bugs me the most about almost all of these posts/articles is that they assume (or come close) to an absolute version of what story should or should not be in a game. It has to be an element and cannot be the gameplay itself. It cannot be told in a recombinant form because stories are fragile things not conducive to reassembly. Story must be delivered this way, or that way.

Gah! Who said story was absolute enough to define? We are talking about a form of communication, creation, and art that is older than any other. Before there was recorded history there were stories, it was how people remembered. Stories are oral. They are written. They are visual. They are interactive. They are static. They are serial. They are a great many things, none of which is absolute. Hell, we can’t even agree on a definition for story, narrative, fiction, drama or a half-dozen other words.

So, of course, we have done the one primary thing that humans do when faced with an amorphous concept: we’ve classified it. The first level of classification is, arguably, medium: how the story is delivered. Written stories are different from film stories, are different from interactive stories, etc. Each medium has shared tools and medium-specific tools. You have to show things in a film where you could allude or describe in print. You can evolve characters in games according to play where you’d have to evolve them (or leave them static) by specific choice in other media. The medium of the story defines a toolset available for telling the story.

Another common classification is genre. From theme, to style, to emotion, to mechanics, genre provides a common framework for a story. Independent (to a degree) from medium, the genre of a story provides a further specific toolset based on convention and commonality. New genres are created through creating new conventions, while new mediums are created through new technology and formats. In this way, genre becomes a subset of medium by further defining how the story can (and should) be related.

But a story is not specifically defined by these characteristics. A story is defined by the characters (including settings and props), and the events presented. The medium and the genre that they are presented through affect the consumption without altering the underlying story. This is why fairytales can be retold – the interpretation changes the narration without affecting it on the story layer. Archetypes exist outside of medium and genre, allowing them to appear in any form. Stories, or at least the core of stories, do the same; often boiling down to base archetypes.

Thus you have the ability to take a story, consisting of particular characters and events, and present it as a romance novel, or a thriller-noir film, or a tongue-in-cheek cell-shaded action-platformer. Each time it is presented it becomes a specific narrative. If I’ve gotten the terms story and narrative backwards, according to your particular world view, please feel free to reverse them. The idea I’m trying to get across is that the mechanics of media and genre have only superficial effect on the story, changing its presentation. At the same time, each presentation is a unique narration, and independent from each other narration.

So why do people think that Books = Movies = Games? Or even that one genre of game would transpose to another genre? Why would the same set of story tools be used to create a story for an RPG and an FPS? They might share a small set of tools; indeed as they are both of the same medium (broadly) they do. But as different genres there will be particular conventions that apply to one and not the other. The gameplay is not the same, why should the narration be?

Designers are trying to use the wrong tools to do the wrong job. Hollywood mentality and storytelling will not work in most games, just as comic book pacing needs to be adjusted and changed for the silver screen. Neither can we create a single set of tools for all interactive storytelling. There can be a shared language, common conventions that reach across genres, and even the creation of certain pluralistic tools. But when you get down to the nitty-gritty, the designer will have to find a voice for the story that is unique to the game, and the play, that they are trying to deliver.

Thursday, July 20, 2006

Game Path

I have always loved games, anyone from my family can attest to that. As far back as I can remember I have been playing, finding, creating, and sharing games with anyone that comes in close contact with me. I don’t know if there is a definitive moment that games became more important than anything else, they were always just there. If anything, it feels more like a series of events, spread over a number of years, which has led me to where I am now. Another epiphany may yet alter my course further. For this month’s Round Table I’d like to share some of these first steps with you.

Elementary Gamer

The first two clearly game related memories that I have are from Elementary School (grades 1-6 for those of you playing against different systems). The first is of creating a game. It was the final project for a book report; you know the kind I’m sure. You read a chapter or two a week, answering questions after each. At the end of it you have to do some form of final craft-related project, usually the infamous Shoebox Diorama. I made a board game. Yeah, I had to be different. It was a simple follow-the-path game using events from the book as jumps and hinders. But it did have multiple paths you could select, and cards that altered your progress based on decision making factors. And I understood that you had to space and balance the game (I always hated playing board games, especially cheap ones, that would have you skip 3 spaces only to land on a lose a turn, or some such).

The second memory is of rescuing a fantastic game from the obscurity and ruin of the Lunch Room Game Cart. Brought out on days too rainy or cold to be let outside, the game cart held games, toys, and other things in various states of childhood destruction. Lost and forlorn at the bottom of the cart was a marvelous game called Quest for the Philosopher’s Stone (note: that is not me in the picture). How it got there I’ll never know. It is a game of mental challenges and puzzle solving. I could never get anyone to play with me. Not really surprising if you knew me back in elementary school. I did, however, convince the lunch ladies to relinquish the unplayed and unloved game to me. I still have it, and I still find the game intriguing. It was my first step to collecting great and rare games.

Digital Gamer

While elementary school held some computers and edutainment related games (such as Oregon Trail, and Math Blasters), it never held much for me. When they upgraded from Apple II’s to a lab of stylish Mac’s, they removed all the fun from the computers via a program interface called AtEase. It wasn’t until I moved on to Junior High (grades 7-9) that I truly began gaming on computer. With a school full of Macintosh computers (we are talking a library full, a couple of labs, and several hall areas with computers too), gaming was inevitable.

It was my first introduction to networked play. We’d play Bolo over the Appletalk network, and try to hide the games from our teachers. It was also the first time I created a digital game. I made a couple of attempts at point and click adventures using HyperStudio. My artistic skill were simple, but I had non-linearity, small puzzles, persistent items (across hypercards), and cheesy story. It was bad, but it was fun to create.

Principled Gamer

Since those early years, I’ve played dozens of games. I’ve even completed a few of them. I’ve tried to learn something from each one, and the more I play the more I can see the choices the designers made, and why they work the way they do. The more I understand the framework, the more I want to create something of my own. More than that, I want to create worlds – places of character and depth and story. I want the things in my head to be in front of me, and everyone, to play and explore.

It has been a long journey to this conclusion. Part of this realization is the firm knowledge that I have a long way to go before I can do that. There are still many things I have to learn about games, gameplay, design, programming, business, life, philosophy, literature, music, economics… the list, perhaps, is endless. I am comforted by the fact that I am young, and have resources available to me that will allow me to pursue this knowledge.

But there is one last formative step that stands out. I started with an obsession for trivia. I love it, especially obscure and funny trivia. After playing You Don’t Know Jack, I was hooked. It was hilarious and irreverent, packed full of odds and ends. But most impressive about the game was its ability to draw you in and make you feel as if there is another person, just the other side of the monitor, asking the questions. Sometimes there is a whole cast of people, ready to jump into your computer room.

I’ve followed the work of only a few game studios closely over the years. Jellyvision has the (dubious?) distinction of being one of them. They have a track record of creating these interactive, and immersive, games and sites and concepts. They have also conveniently boiled down their wisdom into something they call the Jack Principles. It is a set of guidelines to writing and delivering interactive experiences. I wish more designers would read these guidelines before setting out to design a conversational interface. They aren’t easy, not a one, but they are crucial to creating a dialog that seems natural and fluid.

In finding and incorporating these principles into my Gameview (like a Worldview, but narrower… and virtual) I’m slowly understanding where a lot of immersion breaks down and why. It has helped me to analyze games. It has also begun to change the way I think about the stories I want to tell. The Principles don’t apply to all situations, but they do help to shape certain aspects of play. Learning these things has also led me to seeking out understanding of other game design concepts, fostering yet more learning.

Step-By-Step

I see myself as on a path littered with games. They are everywhere I look. They occupy spare thoughts and lost dreams. I want to play games. I want to share games with others. Most of all, I want to create games. I want others to share my games, my stories, my visions. Each step I take along this path teaches me something new, each new direction leads to deeper understanding. In my mind, that makes this a worthy path to travel.