Posts Tagged ‘Design Patterns’

Human Skills: Elements of Game & Play

Tuesday, May 28th, 2013

The Problem with Genres & Game Design

As someone who contributes to creating games I have a difficult time understanding what other designers mean to say when they use a genre to describe a game system and its mechanics. For example, if someone says a game is a “First Person Shooter” I know that it is common for that genre to incorporate exploration, fast reflexes, precise hand-eye coordination, puzzle solving, tactics, etc. — But when talking game design, this is usually not the clear picture they intended: does their specific game involve any focus on puzzle solving? Does the player actually need to do any exploring?

This problem can cause an explosion of miscommunication among team members and result in an unfocused gameplay experience that ends up feeling like a mishmash of everyone’s ideas on what a game of this genre is supposed to be. Arguments can arise as people from different perspectives use a different foundation for discussion.

By looking at this problem, it’s obvious that vocabulary is at fault. Genres are designed to help the consumer by describing not only the raw game mechanics but also the theme, styling, and content of the media. This makes genres inappropriate and confusing when used to communicate the fine details of game design. This article aims to provide a more precise way of communicating the elements of play to avoid the issues that arise when describing a game based on genre.

A More Precise Communication Style

There is a field of thought that says that learning and exercising skills is instinctively fun for humans and animals. This is what drives us to play and what brings us enjoyment in play. With this in mind I find it helpful to understand “fun” as the act of learning and exercising skills. Games can consist of combinations of different skills: Like chemical compounds are composed of chemical elements, a game system is composed of the skills which it develops and exercises.

How-Video-Games-Can-Make-Kids-Better-People

Some skills that are commonly developed and exercised in games include the following:

  • Problem solving skills
  • Math skills
  • Statistics skills
  • Pattern recognition skills
  • Organization/categorization skills
  • Memory skills
  • Dexterity skills
  • Rhythm skills
  • Strategy & tactics skills
  • Navigation skills
  • Exploration skills
  • Visual comprehension skills
  • Social skills
  • Role playing skills

The vocabulary of skills doesn’t only provide a solid base of communication, but also forces you to think in terms of the most fine-grained elements that make up your gameplay experience. Knowing that a component of my game system is designed to exercise a player’s memory skills will help me design that experience to be more focused, coherent, and accessible to the player.

I may still use a genre, such as a First Person Shooter, to describe the presentation, pre-play expectations, high-level features, etc., but when communicating a game system design and fleshing out the details of game mechanics, human skills can be a much more effective way of communicating and thinking about your game.

Two Game Messaging Systems using Observer and Visitor Patterns

Saturday, September 22nd, 2012

Maximum output for minimum input.

…That’s the idea behind Juicifying Your Game. But this can lead to some pretty messy code if you start injecting extra code at every event that happens in your game. This is where messaging/event systems come in handy to ensure that every component of the game is given an opportunity to provide their own juice.

This article is a quick overview of a couple different ways to implement a messaging/event system in your game engine. Typically something similar to the straight observer pattern is used, but there might be situations where using a visitor pattern could assist in more readable and maintainable code.

Straight Observer Pattern

Typically, the observer pattern allows an observer to be registered for notifications when a state change occurs in the system. In this case, we will use it to send game messages to a list of all registered components by calling their handleMessage(GameMessage*) function. This will require all observers to implement a common interface which includes this function and register themselves with the Game Message Manager to receive messages.

observer_message_system

void Component1::handleMessage(GameMessage* message)
{
    switch(message->getMessageType())
    {
    case MessageTypeTargetDestroyed:
        // Do stuff to this
        break;
    // etc.
    }
}

Observer-Visitor Hybrid

A strong benefit of the visitor pattern is full encapsulation of logic within the visitor. In this case the GameMessage will be the visitor which will visit all observers rather than relying on the observers implementing their own handling logic.

visitor_message_system

void GameMessageManager::sendMessage(GameMessage* message)
{
    foreach(std::vector::const_iterator it = components->begin(); it != components->end(); ++it)
    {
        message->visit(*it);
    }
}

class GameMessage
{
public:
    virtual void visit(Component* component) {}
    virtual void visit(Component1* component) {}
    virtual void visit(Component2* component) {}
    virtual void visit(Component3* component) {}
    virtual void visit(Component4* component) {}
}

class TargetDestroyedMessage : public GameMessage
{
public:
    virtual void visit(Component1* component)
    {
        // do stuff to the component
    }

    // etc.
}

This second pattern may promote flexible and reusable public interfaces for certain components because the visitor must perform all actions upon those public interfaces of the components being visited. If you are concerned about your components becoming overladen with message-specific functionality, this pattern may assist in relieving that coupling.