In the last entry, I talked about the multitude of actions that a game like this needs, and how it's difficult deciding what to cut and what to keep. I then mentioned the term 'abstraction' and how it can help expand the number of actions available to the player without significantly increasing development time. Now I'll delve into abstraction and what it means for game development.
Abstraction is a somewhat nebulous term, and can be used to mean a variety of approaches within game design and development. In this case, I use it to mean a kind of separation between objects and their interactions, and a move away from specific actions to a more generic form. For example, one action can be used on many different items, without the need to code many different responses.
Saturday 11 May 2013
Thursday 2 May 2013
To do or not to do
There are a LOT of possible things for players to do in a game like this. A LOT. (not to be confused with an alot). For one simple example, imagine a character opening a chest. This simple action has many possible permutations - the chest might by booby trapped, it might be locked, it might be empty, it might be full of riches, it might have a vicious creature inside it, the chest itself might be a sentient being called Barry. The list goes on, but that's not the end of it. Every action has its own permutations and subsequent actions to consider.
If it's locked, the player might pick the lock, or they might bash the lock, or they might have a spell to unlock it, or they might have the key. If it's booby trapped, they might try to disarm it, or they might choose to deliberately trigger it and take the hit, or they might back away and try to trigger the trap through ranged attacks, or they might have spells to disable traps.
Suddenly the simple act of opening a chest has many different potential actions, each of which must be accounted for in the game. The problem as a game designer is which actions do you leave out? In a perfect world, the player would be able to do everything to anything. In the real world, there aren't enough hours in the day or enough coffee in the pot to make that happen. You have to make hard decisions and cut one or more actions in the interests of actually finishing the game before the world ends (which I am assured is any day now).
Now add into the mix the problem of player expectations - some actions are very common in games and to leave them out would result in many players being confused or annoyed that they cannot perform that action. Then consider that every action you add creates future expectations. If the player can bash the lock on a chest, they should also be able to bash the locks on other containers, and on doors. The decisions required for a game like this are incredibly complex and nuanced - far more than most people might realize.
Fortunately there is an 'out'. A way to include many actions at once, without hurting future expectations and without having to leave out many at all. This option is called abstraction, and I shall go into technical detail on this subject in the next entry.
If it's locked, the player might pick the lock, or they might bash the lock, or they might have a spell to unlock it, or they might have the key. If it's booby trapped, they might try to disarm it, or they might choose to deliberately trigger it and take the hit, or they might back away and try to trigger the trap through ranged attacks, or they might have spells to disable traps.
Suddenly the simple act of opening a chest has many different potential actions, each of which must be accounted for in the game. The problem as a game designer is which actions do you leave out? In a perfect world, the player would be able to do everything to anything. In the real world, there aren't enough hours in the day or enough coffee in the pot to make that happen. You have to make hard decisions and cut one or more actions in the interests of actually finishing the game before the world ends (which I am assured is any day now).
Now add into the mix the problem of player expectations - some actions are very common in games and to leave them out would result in many players being confused or annoyed that they cannot perform that action. Then consider that every action you add creates future expectations. If the player can bash the lock on a chest, they should also be able to bash the locks on other containers, and on doors. The decisions required for a game like this are incredibly complex and nuanced - far more than most people might realize.
Fortunately there is an 'out'. A way to include many actions at once, without hurting future expectations and without having to leave out many at all. This option is called abstraction, and I shall go into technical detail on this subject in the next entry.
Subscribe to:
Posts (Atom)