Game Design Game Development

Object-Oriented Game Design

Hi, you’ve probably come here from some of the sites that link to this article. This post is an old one, though, and I’ve written a more up-to-date post called State of the Art Game Objects that you probably want to check out that has a lot more research links and info.

I’ve mentioned Object-Oriented Game Design by Britt L. Hannah before, but I wanted to write a bit more about it.

The article is not named very well. Game Design and Software Engineering are two different things entirely. The article isn’t actually about object-oriented game design, whatever that means, so much as object-oriented software development for games. It doesn’t make the information any less valid, however.

It basically discusses a component-based design for game objects. In a recent issue of Game Developer magazine, Mick West wrote “Evolve Your Hierarchy” which gives an overview of the topic. Some references listed in the article:

To summarize, there is a tendency to use object-oriented languages to create deep hiearchies. Scott Bila’s slides #7 and #8 show how inflexible and unwieldy these hierarchies can be. So if you can’t just have objects inherit from Drawable, Collidable, Shootable, or similar abstractions, what can you do?

You give an entity states in the form of objects. But rather than give a class private members to hold state like you usually would, you create a separate class for each state you would like to store. So instead of the following:

class Ship
int hitPoints;
string name;

you would do:

class Ship
State hitPoints;
State name;

What’s the difference? What happens if you need a new type of ship? Or an asteroid? Or a base? Or an alien? It is conceivable that you might have different types of entities that need to track the state of their hit points or names. It is also conceivable that those entities might not need to inherit the behaviors of a ship. So the states are placed into their own objects and assigned to Entity objects. You don’t really need to create a Ship class since a Ship is really nothing more than an entity that has the states that belong to a Ship.

Now the part that was a real eye-opener to me. It is very intuitive to create classes for things we think of as objects. In computer science class, we’re taught that classes have state and functions to manipulate that state. A class is created for a noun, and the functions in the class are the verbs.

Well, it turns out that the verbs can be encapsulated in classes. If we use the first example of a Ship above, actions would be functions defined in Ship:

class Ship
void setName( string);
string getName( );
void setHitPoints( int );
void adjustHitPoints( int );
int getHitPoints( );

Each time you add some state to a class, you need to add functionality to access such state. It can get really messy, really fast.

If you separate State into its own classes, however, then you can create Action objects to interact between entities. In the second Ship example, you can create an Action called AdjustHitPoints:

class Action
void doAction( ) = 0;

class AdjustHitPoints : public Action
void doAction() { entity.hasState( HIT_POINTS)->hp += amount; }

An Entity needs some way for the Action objects to grab state, so hasState() fills that role. Action objects have a function called doAction() that manipuates the states from an Entity.

Can you see how powerful this design is? Instead of hard-coding state into entity classes, you can construct entities at run-time. Instead of giving individual entities the methods to manipulate the state, you separate the events into their own classes. You can add a bunch of Actions to an Entity’s queue. The Entity can then pop the Actions off one-by-one and run doAction(). You don’t call adjustHitPoints(). You just activate the AdjustHitPoints Action object for the entity.

Normally if you have an abstract class called Human, you might derive Man and Woman classes from it. Let’s say you have a pointer to a Human, human, and it points to a PoliceOfficer object. You can’t say human->catchCriminal() because a Human doesn’t have the functionality of a PoliceOfficer. It is sometimes difficult and/or dangerous to dynamic_cast to the proper object type, so it seems overly difficult to get a PoliceOfficer to catch a crook since you don’t know who the PoliceOfficer is. If you change the code so that you know who the PoliceOfficer is, what was the point of needing to use a pointer to Human? Or inheritance, for that matter?

However, if you use the separate components to handle state, you can say human->activateAction( CATCH_CRIMINAL ). If it isn’t a PoliceOfficer, then it won’t have that Action. Nothing happens, just as we would expect. A PoliceOfficer, on the other hand, will have that Action object in its repertoire, and so the CatchCriminal Action will be activated. Eventually some code will run when the PoliceOfficer object updates that will look something like:


Even better than the above example is that you could create a different type of Human-derived object: a Deputy. A Deputy isn’t a PoliceOfficer, but it should also have the ability to catch criminals. There’s no need to duplicate code. You just give it its own instance of the Action.

Separating state into components and encapsulating events into their own objects allows for more flexibility in your game code. I’ve already found that this design was both easy to implement and fun to use. I have been writing a text-based board game, and I was surprised with how easy it was to construct entities. I sometimes find myself writing code that resembles the deep game entity hierarchy, but whenever I do it is a source of pain. Refactoring the code so that it resembles the component-based model has always made it easier to work with.

Game Design Game Development Games

Not at the GDC Again

While a number of people will be writing their coming blog posts from the Game Developers Conference, I will be reporting the action from Chicago. Again.

I would love to see Will Wright talk about what’s next in game design, but I’ll have to be content with seeing it on GDCTV when they release it later in the year. It would also be great to be there when they announce the winners of the Independent Games Festival, but I’ll just have to read about it at Game Tunnel.

Since I’m not going, I can treat this week as any other. I’ll work on game development and might get more accomplished since I won’t have as many blogs to distract me. B-) Since the GDC is generally about sharing what we know, this week I’ll try to post about what I have been doing with game development and design.

To everyone at the GDC, have fun, and good luck to the IGF finalists! My favorites for the Seumas McNally Grand Prize are Professor Fizzwizzle, Darwinia, and Weird Worlds, but I haven’t played Dofus or Wildlife Tycoon: Venture Africa yet.

Game Design Geek / Technical

Design Concepts I Just Learned

I was reading through the two Game Programming Gems books I have, and one of the gems describes a game entity factory. To understand this gem, you have to understand a few design patterns, including flyweight. I never learned exactly what a flyweight was or how I would use it. I still have a slight understanding that you would use a flyweight if you have data that is constant between different entities. Ask me anything else about it, and I’ll struggle. The Gang of Four book isn’t much of a help. It’s a reference book, which means it will be a better tool when I already understand it, but it is almost useless for learning.

I pulled out the Design Patterns Explained book, but it doesn’t have flyweight listed; however, there were a few interesting chapters on design principles. It’s been years since I cracked this book open, and I might have used it for class. I thought it was just a more in-depth version of Design Patterns, so I never found the chapters titled “How Do Experts Design?” and “The Principles and Strategies of Design Patterns”. The book refers to Christopher Alexander, the original author on design patterns. He was writing about physical buildings and architecture. While his approach doesn’t directly map to software design, his principles apply quite well.

One of the things I learned is that trying to put a bunch of pre-made components together to create software is not ideal. You should have a big picture of your project, and then you can decide what smaller components you’ll need. I never thought about the effects of trying to reuse components before thinking of the full scope of the project.

Another thing I learned was the principle of designing from context. I would periodically become stressed when thinking about the best way to design a class or relationship between classes. I don’t have nearly enough experience to be able to make judgement calls about the best way to design a project. I think I have enough of a grasp of programming that I can implement anything once I decide on a good design; I just need more practice with getting to that good design. I learned, however, that you can’t know how a pattern will be implemented until you understand the context in which it exists. For example, if you have a facade pattern, you can’t know how to implement it until you know what interfaces you need to link together. Essentially, you can’t just ask, “What’s the best way to implement XYZ?” You need to ask, “Under what circumstances will implementation A be a better fit than implementation B? How do those circumstances match up with my actual circumstances?”

I still don’t think I quite grasp the flyweight or its place in the game entity factory, but software design became a bit less mysterious. Heck, William Willing’s comments on a Timeless Way of Game Design make more sense to me now!

Also, since I’ve been researching design, especially software design, I found this helpful game engine design link: Object-Oriented Game Design: A Modular and Logical Method of Designing Games

Game Design

Game Design Notation

Danc at Lost Garden posted Creating a system of game play notation, which attempts to create a notation to document the game play of any game. Lost Garden has had previous posts that strongly emphasize the importance of regularly occurring rewards for the player’s actions. The description of the notation seems to be geared towards such designs.

It starts with a history of musical notation. Once it was possible to record music on paper with accuracy, it was easier to communicate the music to others. Also, it was easier to identify and fix bad compositions. You could analyze a composition on paper rather than require the music to be played over and over again. It also allowed more complex and sophisticated music to be created. I think it is like the idea that the human brain can only handle so much at once, but if you were to write down your thoughts, you could free up your mind for higher-level thinking.

Danc argues that game design language is currently in the same situation that music was before the invention of the musical staff. The idea of a language for game design isn’t new, and some attempts at providing a vocabulary exist, but I don’t know of anyone who has tried to codify it as extensively as the description at Lost Garden.

I think one of the coolest parts is the application of business information visualization to game design. Danc refers to it as making complex game data “glance-able”. The science behind it is that the human eye can take it huge amounts of data at once. Present someone a paragraph of text, and it might take some time to read and understand. Present that same person with a bar graph, and they can instantly tell you that one bar is bigger than another and by how much.

My favorite quote:

What we do get is the ability to describe a game using well defined terminology. Instead of saying “This is boring”, you can point to a period of 5 second in buzz graph with no rewards and identify the events leading to that situation.

Can we get that precise? It would be amazing if we could; however, some people would argue that game design involves much more art than science. The idea of codifying game design might be similar to “An Introduction to Poetry” from Dead Poets Society: “I give American McGee’s Alice a 42 but I can’t dance to it.” Rather than help with improving game design it would actually result in a bunch of games that look and feel exactly the same.

I personally think that it won’t be the case. For one, without such notation the game industry has already been accused of stagnating. It can’t hurt to form a common language. Once you can identify the chords, you can learn to put them together in different combinations to make your own great music. Once we can speak in a standard way about game design, whether with Danc’s notation or the 400 Project, we can piece the different parts together to make great games.

Game Design

Basics of Game Design

William Willing came up with a list of some of the basics of game design. He provided a few links to other articles on the various entries and game design in general, and I can’t wait to read what he has to say about learning curves.

Game Design

Game Design Directions

Cliffski juxtaposes two theories about the direction new games should be developed.

On the one hand, technology is getting more complex. Everyone uses computers, everyone watches involving television shows, everyone has a cell phone that has more computing power than the first computers did. Why shouldn’t games also become more complex to keep up?

On the other hand, information overload is very real. People don’t understand that “their Microsoft” isn’t broken. There are too many channels to surf. Too many websites to look at. Life has become overwhelming, and games should become a safe haven. Make them simple, and people will enjoy them more. It isn’t fun if it feels like work just trying to get the game to start.

Cliffski leaves it at that, but I guess that’s where we’re expected to come in and talk about it. Diabolical!

Steven Johnson, author of “Everything Bad is Good For You: How Today’s Popular Culture Is Actually Making Us Smarter” would argue that the Sleeper Curve is at work. Popular entertainment is requiring more and more brains to “get it”. He compares classic shows such as Dragnet with 21 Jump Street, and he demonstrates how today’s shows, even “reality” shows, are just more complex. Dragnet was easy to watch. One event led to another. Everything was sequential. People would say the obvious as an aid to the audience. While watching it today might bring back some sense of nostalgia for some, you’ll quite frankly get frustrated at the simplicity of it. They hit you over the head with plot points and dialogue.

Today, even the “dumbed down” shows have more complexity than the brightest shows of the past. You just need to think more to understand television today.

Similarly, I think, with video games. A child today is able to work with a complex piece of equipment such as an XBox controller as if it was an extension of his/her body. Children look at older games with disgust. They make fun of Pong and Super Mario Bros. My cousin laughs at me for loving Pac-man instead of some new racing game that’s all the rage.

But what about people who don’t play video games? There is a learning curve involved, and for some games, that curve is incredibly steep. Casual games are meant to be simple to play, and it would be easy to say, “Complex games for those who can handle it, and casual for the rest”. But are these people relegated to playing casual games exclusively?

I don’t know how to play poker, but I don’t want to play Go Fish or solitaire all my life either. Won’t military history buffs want to play accurate war games? Games like Uncommon Valor, as great as they might be, might not be appropriate because they are just so darn complex! I bought this game thinking that it would be like Koei’s PTO II, which I had bought for the SNES. It turned out that it was incredibly detailed, and focused on a very specific part of the Pacific Theater of Operations. I tried to play a few turns, but it was hard to tell if I was doing anything important. Oh, to have hours a day to play games again…

So while you can focus on making a game complex to keep up with the Sleeper Curve or making it simple to provide relaxation for the mind, I’d have to argue that some people might not appreciate the idea that you need to “dumb down” games for them. Sure, there are some people who will say, “I don’t want to think!” but other people WANT to be challenged. They don’t want to passively have fun. They want to be involved in the fun!

So I think I won’t be as quick to complain if someone takes an old game and remakes it with “more weapons ” and “better AI” anymore. It seems to be a natural step to take something and add complexity to it. Those kinds of games might not be all succesful (Tetrisphere comes to mind), but I don’t believe there is any law that dooms them all to fail.

But adding complexity doesn’t necessarily mean making it impossible to play. People figured out how to drive cars. Automatics were added to make it easier, but you don’t see labels like “casual driver” being thrown at those who use them. I think you can add complexity and the requisite brain power to play a game while simultaneously providing the player with the means to easily “get it”. You can also do so without upsetting the veteran game player who doesn’t need any hand holding. It’s a balance, and it might be tough to achieve, but hey, that’s what helps a great game appeal to such a wide audience, right?

Game Design

Somewhat Interesting Game Idea: A Buggy Game

On the way home last night, I thought, “What if you can make a game that looks and feels buggy, but was purposely made to seem that way? A game that is fun because it seems buggy, but in reality it isn’t?”

It sounds weird. Or at least I think it sounds weird. I don’t know of anyone purposely making a game seem buggy, but if you do I would love to know about it. Software, and video games are no exception, is generally hard to keep bug-free. There is the idea that every program has a bug in it. It’s hard to completely and comprehensively debug a program. But that’s besides the point.

I’m talking about making a game where the “glitches” and “hiccups” are purposely created. You are walking down an alley, and a ninja comes out of nowhere. Except he seems to flicker and splits into two images of the same character. You know, like the Mouser bug in Super Mario Bros 2 (which is apparently not documented on the Interweb?). It was still one guy, and you only had to hit one guy to defeat him, but it had a bug where it move back and forth fairly quickly. Well what if you made the bug funny? Like, the ninja’s split image made faces at you, or looked like a clown?

Or how about that same ninja being able to run through walls? Or if you could run through walls? You know, when you’re temporarily invulnerable because you just got hit. What if it lets you walk through walls? Or what if you jumped at a wall and got stuck on the side of it, allowing you to climb up? I’ve survived pits in the original Super Mario Bros. or Bionic Commando because of bugs that allowed me to stand next to a wall without falling. Wouldn’t it be interesting if they were purposefully placed into a game?

It would make the gameplay interesting because part of the fun is figuring out what weird thing you could do next. What inconsistency would you be able to leverage to progress through the game? Would you be able to use water to put out a fire but find that the water itself burns because, you know, “fire burns everything”? Could you use that? What if you could punch a firepit? Or swim both in the water and in the air? What if you could kill your ally, but your ally comes back for a cut-scene? Original War had a bug similar to this one. Generally people in your army talked, and an image of the person speaking would appear. Once in a great while, the image and/or the voice would not match the person who should be speaking. So what if your ally returned, bloodied and bitter, but due to obligations in the game, HAD to come back to make a speech?

So maybe it isn’t necessarily a “buggy” feel so much as a “this-is-not-the-universe-you-think-it-should-be” kind of game. The point would be that reasonable expectations are thrown out in favor of surprising the player with odd behavior and unexpected reactions. It might be tough to develop such a game. After all, keeping track of real bugs, the difference between actual results and expectated results, would be a chore. But it would also be different enough that it might confuse players more than anything. Who would find it fun? I know I like to explore the boundaries of a game. I once jumped over the flagpole in Super Mario Bros. I’ve fallen off the edge of the screen in Super Mario World while spinning. Side note: are Nintendo games that much more buggy, or is it just me? B-)

NOTE: If you are somehow reading this post without the comments, I would strongly suggest you read them, too. Some good discussion is coming out of this post, and you’ll miss it!

Game Design

Game Design Resources

Even while I continue to work on Oracle’s Eye, I am looking forward to working on my next game project. Since OE took so much longer to develop than I expected, I can imagine that something similar will happen with my next project. I’ve also mentioned that I want to create a game for the next Independent Games Festival. I want to make sure that I dedicate enough time to that project, so I might as well get a jump on designing it instead of postponing it.

I’ve set a deadline by the end of December to get a basic idea of what kind of game I want to make. Of course, I’d like to be able to come up with more than just “it’s got spaceships and explosions and stuff!” I’ve realized that game design is a complete discipline in and of itself. You can’t design games just because you’ve played a lot of them when you were younger, just like you can’t be a high school educator simply because you went to high school and “know all about it”. While hacking it out is great for getting things accomplished quickly, it is also hard to know what it is you will end up with by the end. Also, I’d rather avoid potential game design pitfalls if I can help it. While reinventing the wheel is good for learning how it works, I wouldn’t mind reading about how other people might have messed it up before getting it right. I’ll mess up enough as it is. I’m all for taking risks instead of stagnating with what is safe, but I don’t have to ignore potentially helpful experiences that other people have been thoughtful enough to document for me. B-)

And so I decided to look up game design. I went to first and checked out the Game Design articles since I remember going there years ago. HOLY. COW. I don’t remember having access to that many articles on the subject! Maybe I just appreciate how important the topic is these days. Maybe there really has been that many new articles produced in the past couple of years. There are definitely a number of new game design books.

And I definitely have a lot more reading to do.

Game Design Game Development

GameGame 1.0 Released

GameGame announced the release of GameGame 1.0, a brainstorming tool to help with game design. It’s a card game that you can play to make a game.

Each card represents game design elements, such as a Goal or Theme. When you want to have something for the player to do, add a Game Mechanic card. When you want a place, add an Environment card.

Using a game to come up with a game is a cool idea. I printed out the cards and instructions myself since I figured they would be fun to try out, although it would be weird to use the Publisher card to put the kibosh on my own ideas.

Game Design General

Your Writing Style

Conversational Writing Kicks Formal Writing’s Ass is another insightful post on Creating Passionate Users that say that formal writing, as nice and professional as it is, is less effective at teaching than conversational writing is. Conversational writing does something to the brain that makes it act as if it is involved in an actual conversation and so forces the reader to pay attention much more than formal writing would. You just remember certain things easier this way.

I’ve mentioned before that I am always interested in learning how to write more effectively, and this post had some good points. Of course, besides writing better, I’m wondering how this principle might apply to game development. Specificially, how do I make games that you would respond to (notice I said you instead of “the gamer” or some other third person term)?

“You Win!” was always more exciting than “Player 1 Wins!” or “GIAN is the winner!”

In RPGs, it is common to meet NPCs that talk to your character. Even though the main character in Chrono Trigger never talked back, the conversation was more compelling because you really only controlled the main character when walking around. People were talking to YOU vicariously through the character, and it was all the more real when you used your real name in the game.

Is your game an educational title? Perhaps you should make the text in the game more conversational and appear to involve the player more. I don’t think it all needs to be second-person “you” and “your”, but you definitely don’t want anything to appear stuffy and formal.

Are the instructions for a game more understandable if you say, “If you wish to access the main menu, hit ESC” rather than “Hit ESC for main menu”?

What about marketing? Can your website become more conversational? Does it sound too much like a thesis? Would changing some sentences or whole sections make the game more memorable and therefore more likely to bring back a potential customer to make a purchase?

The post, like many on that blog, has given me some things to think about.