Interacting with the game

This chapter covers ASC game itself, the mapeditor is working differently in that it doesn't have any Commands or GameActions.

Read-only access

All major classes provide lots of methods to extract information out of ASC. But you should be very careful about doing any modifications. Lots of classes must not be changed, like all the Type classes (Vehicletype, BuildingType, ObjectType, TerrainType, Technology).

Changing the map

Other items (like Vehicle, Building) will definitly be changed. But this should not be done through write access to these instances, but rather through the classes derived from Command . This is the classic Command design pattern.

The commands ensure that all modifications are recorded in the gamemap, which servers several purposes:

• the player can undo and redo these modifications
• the replay is based on these commands to show your moves to the other players (well, only the moves that happen in their radar coverage, of course)
• the replay is also the ensurance against illegal modifcations for cheating. Running the same Commands on the other player's computers must result in exactly the same modifications to the map

History

The introduction of the Command pattern is a relatively new addition the ASC engine. Not all modifications are have been converted to Command classes. This is an ongoing effort. If you are writing new code that modifies the map, you should either use existing Commands (see the descends of the Command class) or write new child-Command classes.

Commands and GameActions

While Command derives from GameAction, there is a very severe distinction between Command and non-command GameAction

A Command is a top level command from the user to some building, vehicle of something. A user never issues normal GameAction The Command may need to do some lower-level modifications of the map, which are governed by the game machanis.

Here is a (simplified) example, showing what happens if the user wants to move a tank from one field to a neighbouring field. A MoveUnitCommand object is created, which will then create lots of child GameAction objects, breaking all the map modifications down into atomic actions.

      MoveUnitCommand
       + Unregister unit from starting field (Action: UnitFieldRegistration)
       + put a track object on departing field (Action: SpawnObject)
       [display animation of moving tank] 
       + put a track object on destination field (Action: SpawnObject) 
       + Register unit on destination field (Action: UnitFieldRegistration)
       + consume fuel for movement (Action: ConsumeResource)
       [an enemy unit start reactionfire]
       + attack Tank with EnemyUnit
       ++ Enemy unit consumes one piece of ammo (Action: ConsumeAmmo)
       ++ Enemy unit gets experience (Action: ChangeUnitProperty)
       ++ Tank is damaged (Action: ChangeUnitProperty)
       [ damage is 100%, so our Tank is destroyed ]
       +++ Tank is destroyed and deleted from map (Action: DestructContainer)
       ++++ Wrackage object is created (Action: SpawnObject)
       + View is recalculated (Action: ViewRegistration)
  

---