In the first-person shooter game Halo, a player uses a joystick to turn and move his avatar (Master Chief) through a network of hostile locations. Every location has one or more neighboring locations. The game is completed when the avatar exits the final location. The player views his avatar's current location through a virtual camera mounted above and behind the avatar.
Locations contain prizes and features. Types of prizes include vehicles, weapons, armor, ammunition, and medicine. The player can use the joystick to direct Master Chief to select and acquire a nearby prize. Types of features include doors (to other locations), bridges, paths, ladders, trees, rivers, walls, and rocks.
Unfortunately, locations also contain enemies who perpetually attempt to kill Master Chief until they are killed or are successful. Fortunately, the player can use the joystick to direct Master Chief to select one of his acquired weapons, aim it, and—if it has ammunition-- fire it. If an enemy is hit, it is killed.
A player can save his avatar's progress. When the avatar is killed, the player can restart the game from the last saved point of progress.

Note that the problem requires an analysis object model. This is just the class diagram part of the analysis model and doesn't include the dynamic models for the controls.
I divided my model into the following packages:

Types of prizes
include vehicles, weapons, armor, ammunition, and medicine.

Types of features
include doors (to other locations), bridges, paths, ladders, trees, rivers,
walls, and rocks.

Every location has one
or more neighboring locations. The game is completed when the avatar exits the
final location... Locations contain prizes and features... Unfortunately,
locations also contain enemies...

... Master Chief to
select and acquire a nearby prize... Master Chief to select one of his acquired
weapons...

Avatar would be a good candidate for the Singleton design pattern because its only instance is Master Chief.
Since Master Chief can acquire prizes, we will need to equip him with storage to hold his collection. One prize is special, though: the selected weapon. Of course Master Chief is always in some location. Since Master Chief can be killed we will need some way of telling if he's still alive. This would normally be done with a Boolean flag, but I have taken the liberty of introducing a health attribute that will range from 0 to 100 with the understanding that Master Chief is dead when his health equals 0.
Here's a partial sketch of the code:
public class Avatar {
private Location location =
Location.ENTRANCE;
private Collection<Prize> prizes
= new HashSet<Prize>();
private Weapon weapon; //
prizes.contains(weapon) required
private int health = 100;
// etc.
}
To make the main diagram simpler, I divide it into two parts: input (featuring the joystick input device) and output (featuring the camera output device.)
... a player uses a
joystick to turn and move his avatar... The player can use the joystick to
direct Master Chief to select and acquire a nearby prize... the player can use
the joystick to direct Master Chief to select one of his acquired weapons, aim
it, and... fire it.

My controls more ore less correspond to my use cases. It's always a good idea to try to sketch the execute algorithm for each control. This will give you a better idea about merging and splitting controls. Here are some examples:
class SaveRestart {
private Avatar avatar;
private static Avatar savedAvatar;
public boolean execute(String cmmd) {
if (cmmd.equals("save")) {
savedAvatar = avatar.clone();
} else if
(cmmd.equals("restart")) {
avatar = savedAvater.clone();
}
return true; // success
}
}
class TurnMove {
private Avatar avatar;
public boolean execute(String cmmd) {
if (avatar.getHealth() > 0) {
// parse cmmd:
String
op = cmmd.next();
int amt = cmmd.nextInt();
if (op.equals("move"))
{
avatar.move(amt);
} else if
(cmmd.equals("turn")) {
avatar.turn(amt);
}
return true; // success
} else {
return false; // failure
}
}
}
The player views his
avatar's current location through a virtual camera mounted above and behind the
avatar.

I have stereotyped the camera as a boundary object. A case can also be made for making it an entity, and introducing an associated boundary class called something like CameraView. However, the camera is not actually part of the game. It isn't in any location.