|Engine Module Type String||Physics|
|Module Type Usage||Single Type|
Physics Modules enable the Drag[en]gine to do collision detection and physical simulations. Physics modules are Single Type modules since only one can handle physics simulation at the same time. This module is one of those modules most important for the end user. The right choice is important to get the best out of games. You can use though for different games different Physics modules if you like. Launchers usually do not download Physics modules on their own since games do not request them. Pick from the list of available Physics modules the one which matches best your system as well as your taste.
Every computer installation is unique which makes it difficult for game developers to produce an optimal engine. With the Drag[en]gine you can pick what works best on your system. Choosing the right Physics module allows you to get the most out of your system. Physics modules have different properties.
What sort of simulation is required?
There exist various types of physics simulations depending on the needs of a game. In general a distinction can be made between simulation physics and kinematic physics. Simulation physics is what people usually associate with Rag-Dolls and describes complex physical simulation trying to mimic realistic interaction between objects. Kinematic physics on the other hand uses simple and non-realistic physics. Games tend to have both with varying strength placed on one or the other. For games not requiring heavy physics simulation simpler Physics Modules can improve performance. Launchers make sure the chosen Physics module works for the game you want to play. Often though you don't need heavy physics simulations for a game. Nowadays physics is often smacked on games that don't really require it. You have the possibility to spend your computer power on other aspects like graphics or sound by choosing a weaker Physics module instead. Physics modules are usually powered down first to make a game run faster. Some games even do not require much physics at all. 2D based games or games on consoles are typical examples.
How fast is my machine?
Speed is an important question if it gets down to physical simulations since the more elaborated they are the more processing time they use. Unlike Graphic modules the Physics module usually works on the CPU and has no external card to delegate work to. Hence the speed of your machine governs a lot what Physics module you can use. The requirements are listed on the page of the individual modules.
Do I have extension cards or computability support?
Extension cards for physics simulation started to pop up some time ago and in the vague of them computability support in graphic cards started to arise. If you have such an extension card or a graphic board with computability support it is a good idea to look for a Physics module able to take advantage of them. One of the big features of the Drag[en]gine game engine is that you can improve it with all new hardware coming by altering the modules not the engine or the game.
Launchers will provide you with a default choice for a Physics module based on the requirements of a game. Usually this is a reasonable choice but sometimes you have to change the choice on a per game base.
Physics modules have a tricky task in that they have to find a trade-off between accuracy of simulation and how much speed is required to calculate them. To help you the Drag[en]gine game engine provides resource Peer objects which notify you about changes to the simulation world. The Peer object you can create yourself to store data in the fastest way for your simulation. Neither the game engine nor other modules know or do care about the content of your Peer objects.
Physics simulations take part in the same world used for rendering. The deWorld object composes of a set of geometry, objects or other elements.
Simulations are carried out on a per world basis. Each frame the game scripts call the DetectCollisions function of the deBasePhysicsWorld Peer object. The Physics module has then to step the simulation by the given amount of seconds forward.
To carry out a simulation deCollider objects are used. These objects are created by the game scripts. The Physics module does not care about the purpose of such a collider. Colliders have physics properties assigned that indicate if they can collide with other colliders and how their physical properties are. Each collider has a deBaseScriptingCollider object assigned which is your connection to the game scripts. If two colliders can collide you can call the CanHitCollider function to ask the game scripts if you have to track a collision. If the game script requests to calculate a collision response on its own call the CollisionResponse. The game scripts then fills the provided deCollisionInfo with the response. After the simulation phase is done call the ColliderChanged function for all colliders that have changed.
The game scripts can request three kinds of collision behavior. If ertStatic indicates that the collider is a static element in a world like world geometry that never moves but other elements can bounce off it. ertDynamic indicates that the Physics module has to apply physical behavior to the collider. If ertKinematic is specified the game script wants to do its own simulation. Kinematic behavior is often used for objects which defy physical laws or move on their own like a player or a guided missile.
How detailed the physical simulation is that your Physics module provides is up to you. Not every Physics module is required to support advanced physical simulation. This is especially the case if the Physics module is destined to run on weaker system or consoles where speed is a concern. To get you started on Physics modules have a look at the deBasePhysicsModule module.
Every Physics module has to provide a compatibility value which indicates how well the module suits the computer it is running on. This value is a percentage value with 100% indicating full support and 0% indicating not running at all. Values above 50% are considered playable. The value has to be determined by examining the possible abilities of the Physics Module compared with the usable ones. If there is some support missing 0% has to be returned.
Games can request certain physical features to be present. This value indicates how well the Physics Module can handle those features. A value of 100% indicates full support for all requested features whereas 0% indicates no requested feature is supported. If at least one feature is not supported 0% has to be returned. Usually this value is simply the number of supported features divided by the number of requested features. This value is important for the engine to propose a module to the user. Only modules with 100% are proposed. Should there be no matching module the best matching one is proposed with a warning about possible non-playability. Games are required to only request for features which are really a must for the game play and not neglectable at all.
Detailed informations can be found here: