My friend Dave Arata and I were talking about ironsights the other day in the context of all the actions that can occur when in ironsights. What happens when you reload? Go prone? Throw a grenade? If a programmer is going to work on an ironsights system, they are going to need to know all these details.
ACTIONS
Call of Duty 4 is easily the king of modern infantry combat on the modern generation of consoles (modern generation eh? what happened to next generation).
The game has some of the fundamentals that almost any modern infantry shooter would want. As a result, we decided to enumerate all of the actions in Call of Duty 4 we felt were fundamental.
- Cook grenade - Pulling the grenade pin but holding it before throwing it
- Throw grenade
- Reload
- Fire
- Aim Down Sight - Players need to actively hold down a button to look down the sights
- Sprint
- Switch Weapon
- Melee
- Jump
- Landing - When the player falls from a suitable height
- Vault - If the game has some type of vaulting system
- Prone
- Prone Move - Moving while prone behaves differently than moving when standing/crouching
- Change Stance
- Climb Ladder
- Moving
- Enter - For vehicles or mounted weapons
OPERATIONS
So what's the problem at hand? How can we define the relationships between these actions in a way that makes sense? Then, how can we translate those relationships into a language a programmer can work from (and possibly create a finite state machine).
First, we have to think about our basic formula. At any time, one action is in progress while another wants to start. So,
A - The action in progress
B - The action requested
Then, we need to define the different operations that can occur between these two actions.
Affected By
- A affected by B
- A and B can occur at the same time, but A will behave differently
- A blocked by B
- If B is in progress, A cannot occur
- A ignores B
- A and B can occur at the same time
- A interrupts B
- A will occur even if B is in progress, B will immediately transition to A
- A queued by B
- If B is in progress, A will occur when B has completed
This gives us 5 operations to build our matrix. We can start each action, then iteratively examine and note what happens when we try to do another action. A gameplay programmer can then use this matrix to develop the animation transition systems for our infantry.
Note: If you're really into algebra, you might care to notice that only ignores is commutative. In other words, if A ignores B then B ignores A.
Of course, I've created a matrix of my own, but what would be the fun in giving you everything you need after all? There are a few notable observations though:
- Change Stance ignores almost everything except Sprint, Vault, Climb Ladder and Enter
- Looking ignores almost everything except it's affected by Aim Down Sights
- Almost everything interrupts Sprint
- Vault blocks almost everything
- Most everything ignores looking and moving
Posts
2 comments:
Pretty good blog entry Brian!
Question; how come most shooters don't care if you handle a BFG or a simple pistol? Shouldn't players for example be forced to stand still or kneel when firing a bazooka?
Or like when a soldier runs: will he still point the machine gun straight forward?
I'd say it's based on the goals of the game you're playing. A game that intends to be very tactical and realistic, like America's Army, would probably do exactly what you say. But it's important to note one important thing you said, "forced to." It is a good principle, as a designer, to avoid forcing the player to do anything. It's better to give them interesting choices with consequences. In this case, it would be better to change the bazooka's accuracy or recoil when they fire standing up.
With regards to pointing the gun forward, I guess that's just a matter of doing what "makes sense" to the player. If they are looking in a certain direction, they expect to fire in that direction as well. I'll make a post about firing models in games to explain some of the tools designers use to give consequences.
Post a Comment