Tuesday, February 9, 2010

Physics as AI

I don't think any element of a game design can tap into the natural desire to do well than the addition of simple physics. In many ways it is the ultimate form of AI because it pits the player wholly against their environment. If something goes wrong they only have themselves to blame.

This is a major part of the attraction to golf and billiards. Only through years of practice can the player learn the subtleties of the friction along the felt of the pool table or the precise angles and speeds of a pitching wedge.

When we first started developing [absorb] we were looking at games like Flight Control where you would draw out a full path for an object. While it works extremely well for Flight Control, it just didn't feel satisfying for a game like [absorb] and also made the game far too easy.

We could have added some kind of AI to [absorb], but instead we gave a simple physics implementation a shot. It adds a very dynamic feeling to the game, and also requires practice by the player to learn the "feel" of the game. Once the player does get the feel of the game and is able to get orbs into the gate with repeated success, it's much more satisfying than if we had included no physics and gave the player 1:1 control.

(1:1 control on touch screen devices is an issue that I believe deserves its own post. I'll come back to that at a later time.)

If your game is not difficult or satisfying enough and you start considering some form of AI implementation, consider for a moment how physics can make your game more difficult. There's a good chance it will also make it more fun.
Bookmark and Share

Sunday, January 24, 2010

Everyone is a Game Designer

One thing I notice more and more is that everyone is a game designer. You probably did it all the time when you were a kid. Give some people a deck of cards and some drinks... You'd be amazed at what kinds of games are designed, by people that don't even consider themselves game designers.

-On the court you played PIG instead of HORSE to make the game go a little quicker, and to make it easier for a younger brother to play.

-In school you changed the fortune's of your cootie catcher so they would be more interesting to your friends (e.g. "You will marry Zack Morris when you grow up!")

-Tetherball may devolve to everybody hitting the ball clockwise, just to see how fast you can make it go.

Let's look more closely at this process. Say you have 5 people and you want to play a game of football. Doesn't sound very realistic, not to mention a huge problem staring you right in the face: the group can't split into evenly sized teams.

So everybody in the group without realizing it puts on their game designer hat and someone presents the following new rule:
"One person plays quarterback for both teams"

Making some progress, but this presents a couple of new problems. Immediately one of the other players uses his game designer intuition and presents the following amendments
"The quarterback is not allowed to run the ball."
"The defenders aren't allowed to touch the quarterback"

These even the field quite a bit more, even though the teams are lopsided. They are pretty common sense rules. While not as fun as a full game of football, they've at least put in enough utility to get the game started.

The rules and goals in these examples have been modified by the players themselves. They have been modified for a specific purpose and situation, making the game more enjoyable for the majority of players involved. You as a "video game designer" should take heed of their example, put yourself into the game and become a player first, game designer second. The end product will be all the better for it.

Here are the questions:
-What are some more examples of game designs you've created or modified as a game player?
-If everyone is a game designer, what tools and skills do you bring to the table that makes your involvement so crucial to the game's success?
Bookmark and Share

Wednesday, January 13, 2010

From Rules to Goals

Last time we looked at a couple of abstract rules, a game design at its most primitive. This time we will look at how those rules were built upon to create Absorb.

As a refresher, here are the rules we set up in the initial post:
1. In the game universe there exists several objects.
2. Each object has a color.
3. Objects that don't share the same color are destroyed if they touch.
4. Objects that do share the same color are combined if they touch.

To these we added five more concrete rules and modifications:
5. An Orb is an Object that moves in to the game universe at ever decreasing timings.
6. An Orb's velocity can be interacted with by an outside force.
7. A Gate is a special Object that is stationary and will absorb Orbs of the same color that pass through it.
8. If a Gate is destroyed, it can be rebuilt by combining 5 individual Orbs of that Gate's color.
9. If all Gates in the game universe are destroyed, the game is over.

With these rules in mind I felt like we had a pretty good starting point. Our Game DNA felt pretty solidified. Just thinking about how this would work felt pretty interesting. So we started implementing it.

Naturally as we implemented Absorb and could see it running on the screen, some questions arose that were answered with even more detailed rules. More importantly at this time we came to a great realization: This game is at least somewhat fun, but what is the point?

In our case we entertained the thought of this being a "get the high score"-style arcade game. Boooring!

We liked the idea of having levels to progress through. I also really liked the idea of having a very consistent game world, where the levels were more about seeing what could be accomplished given the set rules. Much like how the rules started building, we came up with several styles of levels. Here's an example of a level along with a sneak peak of Absorb.

(I apologize in advance for the video quality)




No questions today, but as always would love to hear your thoughts! If you like the post make sure to share it with your friends.

Bookmark and Share

Saturday, January 9, 2010

Transforming The Rules

Rules are the most basic of building blocks a game has. Rules are to a game what DNA is to a person. They tell the game how to behave in every basic scenario. Rules create the underlying character of the game. It doesn't take many rules before the game starts taking on a life of its own, and as such rules are a great place to start your game's design.

But also like people, DNA is only part of the equation. It takes a good upbringing to turn interesting rules into a great game. This is one of the game designer's most crucial tasks.

Depending on how the basic rules are nurtured you could end up with:
-Checkers instead of Chess
-Golf instead of Croquet
-Tetris instead of Space Invaders

I find this process to be extremely interesting and inspiring.

The game I'm currently working on was born from a few basic/abstract rules:
1. In the game universe there exists several objects.
2. Each object has a color.
3. Objects that don't share the same color are destroyed if they touch.
4. Objects that do share the same color are combined if they touch.

-What game would you dream up given these extremely basic/abstract rules?
-How many rules and goals would you need to add to turn this into something more interesting and challenging?

I'll be sharing some of my own results in more upcoming posts. In the meantime I'd love to hear your thoughts!

Bookmark and Share

Wednesday, October 21, 2009

Stop Porting


In a great game design, something magical happens when the player executes an action. The resultant effect on screen does not seem like an afterthought. It feels fluid, natural, cool - it provides that feeling of control that can be found in no other medium.

This entire process requires a lot of conscious thought to "get it right." It's up to the designers to decide how the user interfaces with the game to create this sense of control. In order to successfully accomplish this, specific hardware has to be targeted by the design.

Think about something seemingly simple like shooting a bullet in Halo. You pull down on that trigger, and it feels great. That motion on some of the other controllers of the time like the PS2 controller would be a simple button press. Not nearly as satisfying, and when it is one of the main game mechanics, it can really change the feel of the game.

Let's look at two popular touch-screen interfaces. One is the Nintendo DS, the other is an iPhone. At first glance you'd think almost any simple touch-based game could be built on both easily. But after playing around with each it's clear that many game designs simply don't work well on both. A game like Meteos on the DS is extremely fun, but if/when it's ported to the iPhone, I guarantee it will be a frustrating experience. The iPhone screen was built for big, clunky human fingers. Not tiny precise plastic styluses (styli?). Meteos hinges on having this precise control, and should never be subjected to anything less.

These subtle differences in hardware matter, and mainstream game designers need to stop pretending that they don't. Please, stop the porting!

Here are the questions:
-What was the last ported game you played that just felt absolutely great to play?
-What are some more examples of subtle differences in hardware that are underestimated?
Bookmark and Share

Friday, July 10, 2009

Asteroids or Mini-map?

Mini-maps suck! If you are a game designer and you bust out the mini-map for your game, you better have a really good reason for it. I would wager 90% of the time the reason is:

"This level is too big."

...! Seriously? Have you heard the Seinfeld bit about the bike helmet? He said man invented an activity that could crack the skull. So instead of discontinuing the activity, he invented the bike helmet.

Mini-maps are an invention by game designers so gamers don't get frustrated (and crack their skulls).

If the designer thinks the player needs a mini-map, they are probably right. In these scenarios I find myself spending more time focused on the mini-map instead of enjoying the actual game. This sucks! I might as well be playing Asteroids looking at that little thing.

When I think back on the best gaming experiences of my life, nothing was ever too big to where I needed a constant visual aid to orient myself. The key as with anything is balance. If the level is too big, or there aren't enough landmarks, you would be better served by editing your level design instead of throwing in the mini-map.

I'll give these guys a tiny bit of credit though. At least they recognize their level design is too big for a normal person to enjoy. What about the people that don't!? Banjo-Tooie, I'm looking at you.

Don't use mini-maps, make better level designs.

Here are the questions:
-Do mini-maps annoy you?
-What is the best and worst use of a mini-map you've seen in a game?
Bookmark and Share

Wednesday, July 8, 2009

Crossfire, You'll Get Caught Up In The (Part II)


(Click here to check out Part I)

There are three basic categories of multiplayer:

Competitive - playing against each other
Cooperative - playing with each other, common goals
Cohabitive - playing with each other, non-common goals

Personally I don't feel there has been a whole lot of freshness in competitive multiplayer. We are still dealing with classic one-on-one fighting games, free-for-all FPS games and free-for-all racing games. They can be fun, and the ubiquity of online has given a nice jolt to this format, but the other two areas are much more interesting.

We are beginning to see a lot of great uses of cooperative multiplayer, with more and more games being built around that concept (e.g. Resident Evil 5). This is a very welcome change, and most gamers agree. There is just something about working with another person to achieve a goal that makes it that much more satisfying.

That being said I think co-op games have a long ways to go. The co-op games we see are typically watered down. The designers put certain aspects of the games on dials, and they are just cranked up as more people are added to the game. Too Human adds more enemies to a level as more people join the game. Many games don't go any further than that.

What was the last game you played where you accomplished tasks that truly required multiple people to play the game? I'm not sure I've EVER played something like that.

Now let's discuss cohabitive games. There aren't many of these out there... yet. Essentially I see this form of multiplayer catering mainly to the emerging "casual" game market. Animal Crossing was probably one of the earliest forms of this genre. Although multiple people wouldn't be playing at the same time, they would inhabit the same virtual space, and would go about their own tasks, interacting with others in the town at their leisure. A more sophisticated form of this would be something like Sony's Home and Second Life.

I think multiplayer is an extremely valuable tool in the game designer's arsenal, as long as it is used wisely. Technology has enabled our definition of multiplayer to expand beyond head to head competition, and we've barely scratched the surface of cooperative and cohabitive games.

Here are the questions:
-Have you ever played a cooperative game that truly required multiple players to accomplish a task?
-How could elements of cohabitive design be applied to more "hardcore" types of games?
Bookmark and Share