Table of Contents
Start Page » Game Development with the Drag[en]gine » Prop Fields
Large outdoor sceneries are no more uncommon in games. Rich outdoor sceneries though require a lot of smaller plants and props laying around on the ground interacting with wind and actors walking through to be believable and up to a standard level of graphic details players grew accustomed to. Placing large numbers of props though using Components is very slow since they are rather heavy weight. In addition such scenery props are usually redundant which means that they are not required for the game mechanics to work but are there only to enrich the player experience. Especially players with weaker computers wish to reduce the complexity of such background scenery elements to improve framerate since after all the game play is important. To cater for all these goals the Drag[en]gine supports so called “Prop Fields”. A prop field is as the name suggests a field of redundant props. These fields can contain large numbers of props while still producing a good frame rate. In addition props in a prop field are influenced by Force Fields allowing them to wiggle under the influence of wind or other forces. Due to the high performance requirements the way prop fields work is slightly different than the way other world elements work.
Module Interactions
To crank up performance prop fields use a special way of defining the props they contain. Each prop field contains a list of Types which define a set of props all using the same model and skin as well as sharing certain physics parameters. Each prop is represented by an Instance. Each instance defines the initial position and orientation of the prop it represents. These informations are given by the game scripts upon creation of a prop field. Furthermore each instance contains bending parameters which are managed by the physics module only and used by the graphics module only. The game scripts do not have to touch those. The main interaction happens between the graphics module and the physics module. The game scripts are only used to create the prop field. From that point on the game scripts do not worry about the prop field anymore. In contrary to the other world elements the game scripts only create the prop field itself but not the content. The reason for this is that creating prop fields fully populated for large worlds consumes tremendous memory and is unsuitable. Here the graphic module decides when it needs a prop field to be populated with instances. Therefore the graphic module is the main manager of all prop fields the game script set up. If the graphic module requires a prop field for rendering it queries the game scripts using a callback ( see your scripting module of choice on how those callbacks are implemented ). The game scripts then populate the given prop field with instances. To fine tune performance a density parameter is provided with the callback indicating the percentage of instances to place in the prop field. This way the graphic module can control precisely the performance of rendering by either demanding more or less detailed prop fields. The graphic module also clears prop fields if they are no longer used. It happens therefore often that a prop field is filled multiple times during a game session for example if a player revisits a location.
Physics
The physics module also obeys to the commands of the graphic module in this situation but has its own means to control performance. For each prop field a set of Bending States are maintained. These bending states are created by the physics module depending on how accurate it can or wants to simulate the physical interactions of prop fields with force fields or other world elements getting in contact. Each instance is assigned to a bending state. Therefore usually a group of instances is controlled by the same bending state which improves performance. Once set up the physics module drives the bending states which in turn then are used by the graphic module to render the instances.
