The Big News Pack 5/6 - Epsylon

Actor classes updates

The design of the actor classes has been reworked and improved. So far various classes for the different actors existed to test the individual features. These features have now been collapsed into reusable base classes HumanActor and DragonActor. This way adding new features and characters is easier.

This includes also the dragon locomotion system which has been added to the game scripts similar to the one used in the animator editor during development. The locomotion system still has troubles and needs more work but the basic pieces are in place. To handle turning better collision detection has been augmented with some additional code to allow testing for rotation collisions. The code is currently still a hack as the bullet physics is supposed to take over this job later on (still a few problems in the way hence the hack is still in place). What does this mean now for the movement of the player? The main problem with dragon characters is that they are not rotation independent viewn from above. If you do not want to go through narrow places this is not important and a large cylinder can be used. For this game though the dragon actors have to be able to also get through narrower places. For this the rotation has to be taken into consideration. The way it is implemented right now before each motion the actor is checked for hitting geometry using rotation. The rotation is then blocked if a wall is hit. Doing the check like this allows a player to squeeze against walls and getting away from them easily. This system still has room for improvement though. Getting through doors still requires some aiming. That said this is not that bad though as a dragon in a narrow places would have troubles to maneuver in the real world anyways.

There exists an idea for doing a different kind of rotation testing which does not require actual rotation testing. Rotation testing is a nuisance and difficult to handle. This idea would require some unusual handling of the dragon character to work but it should be much more stable and less error prone. This will be tested in the time to come to see if it works better. Most important is that it fells well for the player to navigate.

Trigger system

A trigger system has been added which works similar to existing trigger systems in other games. In this game there is triggering and connecting. Certain objects can be linked to others using named targets. Linking objects requires the two objects to know about the type of each other. This is useful for certain cases but not for others. For example this does not work well for generic triggering like switching on and of a light source or triggering generic actions when an entity enters some location. To handle this triggering has been added.

Triggering works rather simple in that a trigger expression can be specified for „trigger*" type object properties. For example a light source has a property „triggerActivate". This defines an expression to be evaluated and the light is activated if the expression evaluates to true or false otherwise. A trigger expression composes of trigger names, modifiers and logic operators. Modifiers can negate (!) a trigger (hence return true if a trigger is not fired) or refer to the current state (@) instead of the global state. Triggers always store two states. The global state indicates if the trigger has ever been fired while the current state indicates if the trigger is currently in the fired state or not. Depending on what kind of trigger action you want to use either of the two can be useful. Logic operators exist two, the and (&) and or (|) operator. Parenthesis can be used to group sub expressions. So for example an trigger expression could look like this:

This would fire if either the player is currently in a trigger zone named trigPlayerInArea and trigActionA never fired so far or if trigActionB fired sometime earlier. This system is rather simple and allows to trigger objects which have no idea about the type of each other. Objects can have more than one trigger expression affecting different actions. So for example a door can have „triggerOpen" and „triggerLocked" both with their own trigger expressions. The door would therefore only open if both triggers are true. Granted you could do this like „triggerOpenExpression && triggerLockedExpression\" in this particular case too but it can happen that a door turned locked due to scripted means not using a trigger expression. Hence multiple trigger targets are possible allowing to combine the two worlds for a lot more flexibility.

In general the Trigger System is an addition to the Connection System. Combining the two allows for very dynamic game scenarios difficult (or even impossible) to do with other game engines.

Outlook

The last news post in the big news pack is going to deal with the new map geometry in general and launcher improvements. You've seen already a bit of the geometry in the preceding news posts. This one though is going to show more.