Game Matters

An independent success

The headline for the press release reads: RealNetworks to Acquire GameHouse, Inc. The stunner is this part: GameHouse sold for a whopping $35 million!

Lots on indie developers read this blog, so I'm sure this buy-out is of great interest, and hopefully a great motivator. Although I don't play many puzzle games anymore, I've heard of GameHouse's games, such as Super Collapse II and TextTwist. But I would never have guessed that a studio that makes these sort of games could have sold for so much, yet I'm glad to see it happen.

A key stat from the press release touts that for 2003, "GameHouse generated over $10 million in revenue and $5.5 million of net income." This is big league revenue, guys. Never again will I doubt the money that can be made in this market. And for those looking for an entry point into the industry, the puzzle game path looks like one worth heavy consideration.

The genius of Pac Man

Below is an article that I wrote a while back, that briefly examines Pac Man as a role-model for game design perfection. I've always liked examining older games, which weren't nearly as reliant on graphics for their success, with the idea of learning from their gameplay design. I may write a few similar articles in the future, looking at games like Asteroids and other classic games. In the early 80's I worked in several arcades and was quite the game player, even winning several tournaments here in Dallas. A benefit of working in an arcade was being able to stay after hours and play endlessly for free.

Anyway, here's that article...

~~~~ begin ~~~~

The genius of Pac Man

It's the best selling arcade game worldwide, with over 250,000 machines sold. When it came out, I played it occasionally, but for me it wasn't in the league of Space Invaders, Missile Command, Scramble, Asteroids, Defender and other high-action arcade games I preferred during that time. George, my partner at 3D Realms, though, loved it and eventually memorized patterns that allowed him to play endlessly on a quarter. (These patterns can be found in a book George and I co-wrote in 1982, "Shootout: Zap the Video Games.")

The years passed and other arcade games faded away, yet I still found Pac Man in arcades and restaurants, and never being a fighting games fan (the only other games that seem to be around nowadays), I found myself playing more and more of Pac Man and eventually appreciating the game's genius.

I believe there are only a few software games ever created having perfect and pure gameplay. Tetris and Pac Man are two examples, but Pac Man is the better example because it's a more complex game, and therefore the greater feat. Every aspect of Pac Man has gameplay repercussions and provides the player with decisions that involve trade-offs. Also, the game is extremely quick to learn, but nearly impossible to master, and has just one ultra-intuitive control, a single joystick.

Just the act of eating dots is perfectly designed, because eating them slows Pac Man down, slightly slower than the pursuing ghosts. This makes the act of eating dots a trade-off decision for the player because to eat dots – to accomplish the game's primary goal – is to put the player in greater danger. While staying in lanes where there are no dots allows the player to move slightly faster than the ghosts, but does not accomplish the game's goal. A lesser designed game would have not slowed down Pac Mac just the right amount when eating dots.

When Pac Man eats one of the four power dots, it turns the tables on the ghost, not only taking away their threat to Pac Man, but making them valuable to eat. Again, there's just total perfection in the way this is handled. First, the pursuit of these harmless ghosts takes away from the player’s primary goal of eating dots, but it's a perfect trade-off decision for the player (greed for points vs eating dots and moving to the next maze). Plus, with each of the four ghosts eaten, the points double for the next ghost the player eats – but the trade-off is that going for the next harmless ghost puts the closer to the danger of that ghost turning back to the normal kind, and killing Pac Man.

Finally, the appearance of bonus fruit, which rises as mazes are cleared, is just another simple trade-off for players because those fruit are not required eating. But they are so compelling that players often take dangerous risks to eat them, and end up dying. And dying in this way the player knows full and well it was their own greedy fault.

There are other perfect design issues with Pac Man, such as the design of the maze itself, which includes dangerous areas where it's easy for Pac Man to get trapped, the tunnel that leads through the screen, and the different personalities (different AI) for the four ghosts.

A perfect game that we can still teach us, over 18 years later.

~~~~ end ~~~~

I think the key idea to take away from Pac Man is the principle of trade-off decisions. Every key decision you make has both a positive and negative side. With simple games it's easy to design with this principle in mind. With the more complex games of today this principle too often gets back-burner treatment. For example, we've all played a shooter in which the later weapons you collect are superior in every respect to the earlier weapons. The result is that the player ignores the earlier weapons. In Duke Nukem 3D, we tried to rectify this by having the later weapons all have both positive and negative attributes, and we succeeded to a worthwhile degree.

One final thought, as I will often talk about "principles" in this blog. A principle is a basic truth, a proposition that is reliable in most cases. I will rarely talk about game design "rules" because the word "rule" suggests a principle that's written in stone, and without exception. I prefer the word "principle" because it allows for some flexibility.

Are you questioning moi?

The remarkable and unexpected (back when I started) reader participation of this blog has spurred me to try a little something different once in a while: Accept questions and topic ideas for future blog entries. I get these occasionally anyway, but through my email, and it's a shame to answer them privately because very often the answer could benefit others just as well.

The kind of questions I can answer best have to do with general design principles, business and marketing. For those trying to get into the industry I won't have much advice other than to point you to the two good links in the right-hand column. Since my background includes shareware and indie games development, I might have useful advice in those areas. Also, I won't have much to contribute within the specific content creation disciplines, such as coding, music and graphics.

Questions that might be interesting include those that ask why we made certain design and/or marketing choices with our published games, even going back to the early 90's with the original Duke Nukem and Wolfenstein 3-D. These are the kind of behind-the-scenes questions I like to see answered by other developers.

Would you like to see any particular topics covered or questions answered in a future blog? If so, fire away. Also, if anyone sees a question they'd like to answer, feel free to do so. I may not be able to handle them all, so I'll take all the help I can get.

Auto-dynamic difficulty

There is a zone beyond that which is known to game designers. It is a place as vast as space and as timeless as infinity. It is the middle ground between boredom and frustration, between easy and hard, and it lies between the tips of our fingers, and the sparks within our CPUs. This is the dimension of pleasure. It is an area which we call... THE FUN ZONE.

(Forgive me, Rod!)

Okay, that out of the way, I'm going to start off with an actual, complete email I sent to the project leader of Max Payne a few months before the initial release of that game in mid-2001, almost three years ago:

From: "Scott Miller"
To: "....... ......."
Sent: Thursday, April 12, 2001 1:54 PM
Subject: Re: Max Payne Build 125

Here's the reasoning behind not having an easy skill level: We do not want players to finish the game and not have a satisfying feeling of accomplishment. Too many players will pick the easy mode just to get through the game, and end up finishing and think, "Well, that was nothin'! Where were the enemies!? Where's the challenge?!" In other words, if we give players a chance to shoot their own foot, some will.

Diablo 2 obviously didn't suffer from not having a skill level choice -- it's one of the three best selling games ever, with 2M and still selling.

Also, my view is that as developers, it should be *our job* to properly play balance the game, not the player's choice. In other words, skill levels are an easy way out for developers too lazy or incompetent to properly play balance their own games. (Okay, a bit harsh, but I'm saying this as someone who used to be a strong proponent of skill levels, too, so I was part of that incompetent developer group! *grin*)

Finally, a skill level screen is just another screen getting in the way of enjoying the game itself, like those boring as hell logo screens that I hope to g.o.d. we can get rid of in all future games we release!

Anyway, the perfect game will adjust its difficulty based on the player's personal ability. This was done in arcade games going back to Atari's Xevious in 1982. It should be really easy to do: Simply have a few variables that rate the player's ability, and the player's rating (completely internal to the game) determines the damage that both the player's weapon delivers, and the enemies' weapons deliver against the player. You do not want to adjust the health benefit of pain killers because that's something the player might notice being adjusted as the game goes along because it's represented by a visible bar.

A few ideas for variables that determine the damage ratings of weapons might include:

o Max's average health (i.e. if it averages around 25%, then the weapon power variables need to be adjusted to favor Max slightly, but if Max's health averages 80% or higher, then up the difficulty).

o Kills made per level, vs number of possible kills per level. A good player will leave few left standing, if any at all.

o Number of times Max dies per level -- this is a good indication of how good the player is.

o Note: I wouldn't keep track of shots fired or number of saved games--those can be misleading either way.

Finally, never make a change during a level, only between levels.

At the end of the game, via a cheat code, you could plot a graph of the ups and downs as the player played the game, which would be a very interesting graph to compare with other players!

Scott Miller
3D Realms Entertainment
www.3DRealms.com

As can be gathered in this email, it's my opinion that games should only rarely allow players to set their own difficulty level. Afterall, it should be the designer's job is to insure the proper play experience, not the player's. The idea behind auto-dynamic difficulty (ADD) is to keep the player in the sweet spot, where the game remains challenging, but never impossible. A perfect game experience is one that constantly tests the player's skill, without being so hard they want to give up. Completing such a game gives a player an elated feeling of accomplishment, because they know they passed a tough test of their ability.

One of the key challenges developers must overcome in broadening the appeal of our games is making our games less hardcore in nature. We need to improve in many areas, like interface, content, and adding emotional involvement for story-based games. ADD should become one of our best tactics to help us achieve this important goal.

One of the most common ways games sabotage their potential to appeal to larger numbers of players is by being too difficult (or too easy, but that's much less common). Practically everyone designing games nowadays is a hardcore player with elite skills. It's therefore easy for game designers to misjudge the difficulty of their own games, making them too hard for average or new players.

Sequels, especially, are a breeding ground for ramped up game difficulty. The natural tendency with sequels is to add more features, leading to more controls. And higher game difficulty. Also, with sequels designers naturally assume that players have all the skills learned from the previous game, and so the challenges are made tougher for new installments. Not exactly an inviting situation for anyone but the hardcore gamer.

ADD provides the near-perfect solution for most problems dealing with game difficulty. At least if implemented well, but that's the case with any facet of design. There are two primary issues with implementing ADD:

[1] The first issue when implementing ADD is to make it invisible to players. It should not be obvious when the game is self-adjusting its difficulty level, as this can hurt the game's immersion.

[2] The other issue is to make it so that's it's hard for player's to manipulate the system, taking advantage of it. For example, a player might play very poorly for the level leading up to the boss, just to make the boss a breeze to beat. While clever players will always be able to manipulate games with ADD, there are ways to make manipulation more trouble than it's worth. And, the bottom-line is that players who do this are only cheating themselves, so perhaps this is not too great of an issue.

One last point that developers should consider: If a player completes your game, they are much more likely to buzz about, spreading the word that it was a great game. We all love to brag about feats of accomplishment, and beating a game, for a gamer, is near the top of the list. A game with a well implemented ADD system is more likely to allow players of wide ranging abilities to complete your game.

I think Max Payne benefited greatly from its implementation of ADD. And I think this should become a standard feature for most games. At least, if broadening our customer base is of any concern.

Contract deal points

Well, another week where I was too busy to write a good blog entry. So, I'm gonna take the cheap way out and dump one of my handy text files here, one that I use to keep track of contractual deal points for future agreements. This is real behind-the-scenes stuff.

I started this doc about 7-8 years ago, and every now and then I'll add a little more too it, especially if I've talked to another developer who tells me of a technique they use, or a publisher trap they try to avoid. Whenever I enter into a new agreement, I make sure that all of these points are considered and covered, if possible. It works as a reminder list.

The hope is that others will benefit from it. So, here it is, warts and all, a full, unedited dump:

o We have full approval rights on the product.

o We have full approval rights on all marketing of the product.

o We must have audit rights. There must be a interest penalty for late payment.

o We must have credit/logo on packaging, at least equal to the publisher's logo size and placement

o COGs must be precisely defined and capped -- never leave this open-ended.

o Make sure there's a clause that prevents the game from being assigned to another company under any condition, including the sale of the company.

o If there's ever a port or remake (or otherwise) opportunity, and the publisher doesn't want to pursue it, then rights revert to us.

o Credits: Original developer's credits are always listed first, even in ports (even if ported by a third party).

o Marketing costs should not come out of COGs -- this is a publisher expense.

o We need to see the top 12 countries' quarterly sales reports, broken out individually so that we can see how the game is selling in each of those countries.

o We get all awards, plaques and trophies for the game. (The publisher may pay for duplicates for themselves.)

o Reserves for returns should be capped at 15% of royalty.

o Reserves must be paid the following quarter.

o Penalties for leaks during development (e.g. penalty of 25k per leaked screenshot or demo, penalty 250k for leaked build).

o Currency risk to publisher i.e. payments locked into our currency (USD).

o Updates (patch obligation) limited to one year after release.

o Penalty for late advance or royalty payments -- and if late beyond a certain cure period (say 60 days), then the term of the agreement and all rights are negated.

o Three late payment notices, by Fedex or other tracked service, is considered material breach of contract and can be cause to severe all agreements, including those for games still under development. Quite simply, make payments on time. Being paid is the entire point of the relationship!

o No console rentals for the first five months of each individual's console release. Rentals destroy retail sales.

o If the publisher makes royalties or bonuses from rentals (i.e. console rentals), then we get 50%.

o Limit the number of games that can be used for promotional purposes, or for sales incentives, to 1000 games. Otherwise, the publisher can shrewdly use your game as part of a sales package, and move 1000's of them without your benefit.

o Make sure indemnity works both ways.

o Kill Fee. The rationale behind asking for a kill fee is that the publisher can cancel the project at any time, in which case the developer may be in dire straits. Often times the developer has added staff and increased expenses to accommodate a project. A kill fee should buy you enough time to land another deal, and also make the publisher think twice about canceling the project. At the very least the kill fee should cover the current and next milestone payments.

o IP. Most developers in the console world work on games who's IP is owned by another party or by the publisher. Regardless of who owns the game IP, it is crucial to maintain ownership and control of your code. A proprietary engine for example is something that console developers will use on multiple projects with multiple publishers. You can't do this if you give the rights away to one publisher. It is unreasonable for a publisher to expect that just because they pay for the game, that they get rights to your code also. Especially if the code existed prior to this publishing deal. Don't agree to ship code to the publisher by request. You should be able to argue that the code will be held in escrow. This will prevent the publisher from accidentally borrowing code.

o Passive royalties. It is fair to expect a passive royalty on ports based off of this game that are not done by you. A passive royalty of 5% is pretty standard. If the publisher decides to do a sequel with another developer, but wants to use assets that you've created for the franchise, it is fair to expect a 5% passive each time it's used. Royalties from one game should never be cross collateralized with royalties from sequels.

o Ports & Sequel rights. You should be able to get sequel and port rights to this game if the publisher decides to do them. It's a good idea to spell out the terms of the sequels and ports in this contract too. You should include royalty rate, recoup rate, and game budget.

o Budget. When asking for a bid on a project, several console developers will also ask for an expense break down for things like salaries, overhead, etc. *NEVER* *NEVER* *NEVER* give a publisher information about how much you pay your people. It is none of their business. The most you should tell them is that the bid you are providing includes salaries, overhead and a small margin to cover unexpected costs. If you give out specific numbers, you will only be whittled down. Also, advances should under any circumstance, ever be refundable.

o Key Employee List. It is fair for a publisher to ask for a key employee list for the project, but that list should be limited to lead artist, lead designer, and lead programmer. Also, the terms of the Key Employee List should not state that these people will work only on this title, but that these people will give priority to this title. Console developers with multiple teams will often share resources for efficiency, i.e.. an engine team, a tools team, art director, creative director, technical director. These people should never be contractually bound to one title.

o Dependencies. In the console world, where working on a licensed IP is common, the developer is dependent on timely delivery of certain things by the publisher in order to get the job done. It is important for the contract to state that any delay in getting material or approvals needed to develop the game, will cause a delay to the schedule. Any such delay will result in cost overages which are to be paid by the publisher, and not held recoupable versus royalties. Dependencies should include things that are the publishers responsibility, for example, providing audio, materials & approvals for the IP, etc.

And to wrap up, if you liked this stuff and want a little more, you can jump over to the IGDA where you'll find an article I wrote in 1998 (as one of the owner/founders of Gathering of Developers), The Ten Developer Commandments. If you have any similar contractual deal points, please do share...

The problem with games

I'm going to make this one a quick entry, what with the holidays and all, and hope that it expands into something worthwhile due to everyone's participation in the comments section.

I've nearly finished reading Rule of Play, by Katie Salen and Eric Zimmerman, and must add that this may be the best book on pure game design that I've yet read. In effect, this is the first book that I've seen that could be used as a college textbook on game design. It's well written, researched, and covers a great many topics from a fundamental angle that I've not seen done as well in other books.

One section of this book covers the definition of "game." The authors present their definition along with definitions from several other industry notables or academics. For those who haven't the book in front of them, here's some of the definitions of game from the book:

o "A game is a context with rules among adversaries trying to win objectives." -- Clark Abt

o "Playing a game is the voluntary effort to overcome unnecessary obstacles." -- Bernard Suits

o From Chris Crawford's The Art of Computer Game Design, he gives a lengthy definition that includes qualities of representation, interaction, conflict and safety. In part, he writes, "A game is a closed formal system that subjectively represents a subset of reality."

o "A game is a form of art in which participants, termed players, make decisions in order to manage resources through game tokens in pursuit of a goal." - Greg Costkyan

o "Games are an exercise of voluntary control systems, in which there is a contest between powers, confined by rules in order to produce a disequilibrial outcome." -- Elliot Avedon and Brian Sutton-Smith (from their book, The Study of Games)

o "A game is a system in which players engage in artificial conflict, defined by rules, that result in a quantifiable outcome." -- Katie Salen and Eric Zimmerman, from their book.

(Note: I do not include Sid Meier's informal definition, "a series of interesting decisions," because I do not think he meant this to be anything more than an off-the-cuff shorthand comment, even though I've seen him quoted dozens of times as if this was his gospel definition.)

All of these definitions generally work, but I'm a fan of simplicity. So, while reading these definition several months ago, I spent about five minutes to see if I could come up with a very short definition that still covers the key points. Here's what I ended up with: A game is a structured set of fun problems.

Here's why I like my definition: Conflict is not required, which means it includes games like The Sims, Bejeweled, Tetris, and flight simulators. Also, there's no requirement of a final outcome -- I do not require a game to be winnable. Costkyan talks about managing resources, but I disagree with this requirement because games like Frogger and Tetris don't have resources to manage -- they have a game piece to manipulate, but no resource to manage, and calling a game piece a resource is a real stretch. I include "structure" because a game must have rules and context. Lastly, I include the requirement of fun, which, strangely, most definitions I've seen leave out.

The heart of my definition is "fun problems". This is truly the essence of any game, and separates a game from any activity we don't prefer to do in our spare time. Problems can take the form of enemies, puzzles, hazards, conflict and anything that's a challenge. (If a game is not a challenge, then it's not fun, so challenge is built into the definition of fun.) Game designers do nothing else but throw problems at players, in one form or another, and successful games make problems fun to solve.

So, does my definition blow chunks? Got a better one? If so, let's hear it in the comments section...