Category: Game Design

Categories
Game Design Game Development

Can You Envision a Casual FPS?

At the Chicago Indie Game Developer Club meeting last Tuesday, Impossible mentioned the idea of making a casual first-person shooter. We both wondered how one would make such a game. What would it be like?

At first, I was just amused at the idea, but then I thought that it might make for a good thought experiment. So I started thinking about it.

Normal FPS
What’s makes a regular, normal first-person shooter? The industry-standard controls involve the use of WASD, although some players prefer the arrow keys. The mouse controls which way you are looking. One button controls shooting. The other can be used for jumping or alternate fire. Those are the basics, although some games allow you to use other keys on the keyboard to control whether you are running, walking, standing, or crawling. Other keys allow you to perform context-sensitive actions. You can switch weapons. You can taunt. You can send messages to everyone or limit them to teammates or enemies. Some keys correspond to launching flares or grenades. Some bring up different aspects of the HUD.

Now, I will admit that it just sounds complex. Most players don’t concentrate on using all the keys, after all. You can play Quake 3 Arena with just WASD/arrows and the mouse, ignoring the crouch key, for example. On the other hand, expert players will utilize whatever they can to play well. From changing the view radius to increasing the speed of mouse movement, they will simply be in a league of their own compared to completely new players. There are people who play often enough to memorize the order of player spawns and take advantage of this knowledge to kill opponents before they have a chance to move. It can be frustrating for regular players, but I can see it discouraging newbies completely.

Casual FPS
What would you change to make an first-person shooter more accessible to non-gamers? For one, change the default controls to the arrow keys. Maybe it is different for foreign keyboards, but I have yet to see a new computer gamer that hasn’t used the arrow keys and wondered why the game wasn’t responding. Harry Potter and the Chamber of Secrets even used WASD! Children are just supposed to pick up on this control scheme? It reminds me of playing games on the Apple II in which every game used IJKM. It took me a little getting used to, especially since the arrow keys were right there and made a heck of a lot more sense.

As for controls, I think simplification can only help. For example, in Alien vs Predator 2, you can turn on the shoulder lamp. The battery would drain, and it would recharge when you turn it off. Well, for a casual version of the game, I think that you would throw out the concept of draining and recharging. Maybe even have the lamp work in a context-sensitive manner or just have it always on. Let the player worry about maneuvering and shooting rather than which key to press to turn on a flashlight. “Oops, I accidentally launched a flare. Wait, that was the key to activate the hacking tool. I’ve almost got it…no, not Gadget Umbrella!” A casual FPS would allow the player to focus on the essential parts of the interface.

I think steps could be taken to prevent veterans from having an advantage over newbies just for knowing more. For example, there is a map in Quake 3 Arena that allows a player to stand in one spot and quickly shoot opponents with the rail gun as they are spawned. Shoot at one point, then aim at the new point and wait for the player to appear. Repeat. New players are still trying to get their bearings, and this specific level is one of the worst to play for the first time. Some people might grind through and try to fight back, but casual players will simply find a new server. I am not saying that veterans shouldn’t play better than newbies. I just think that it can be annoying to play against someone who is winning for no other reason than that you don’t know the level layout as well.

And what about the idea of a shooter in the first place? Does it have to involve guns, blood, and gore? Maybe a casual title might involve construction instead of destruction. Maybe it could feature a capture the flag type of game where the object is to grab resources from a central area and return to your base without dropping them. Cooperation could be encouraged, and it would be more than simply blasting through the campaign levels together.

Hmmm…
While the above are high-level ideas to think about, I know that I am leaving out and/or forgetting many more. What do you think would make a casual FPS?

Categories
Game Design Games

Documenting Game Innovations

Danc at Lost Garden wrote about GameInnovation.org, arguing that we need better, standardized language in order to discuss game design. If everyone has a different definition for “challenge” or “reward”, then you can’t hope to have a meaningful conversation with other game developers.

The goal of the GIDb is to classify and record every innovation in the entire history of computer and videogames.

The Game Innovation Database is in a wiki format, which means that anyone can contribute. I especially like the Challenge Page, which asks questions such as “What was the first digital RPG (role-playing game)?” and “What was the first game with autofire? “. You can browse by game or by innovation, and of course you can edit something if you think an article is lacking, missing, or just plain wrong.

Categories
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:

action->doActions();

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.

Categories
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.

Categories
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

Categories
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.

Categories
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.

Categories
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?

Categories
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!

Categories
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 GameDev.net 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.