What use would a good game engine be without a good front-end? Not that funny to use for common gamers. This update sheds some first light on the front-end part.
Most work went this time into the GUI launcher for the games. This included especially a long overdue redesign of the compilation process on Windows. Due to a bug in windows (infamous 32k command limit on CreateProcess) compilation using SCons and MinGW resulted in problems. Various hacks and improvements on the build scripts allow now the entire game engine, the IGDE and the launchers to build also properly on Windows 32bit and 64bit (Linux 32bit and 64bit always worked).
So what does the GUI launcher provide? Another Desura or Steam? Not exactly. The GUI launcher provides a one-spot solution to install, run and tune games build for this engine. This is the main difference between the Drag[en]gine GUI Launcher and Desura or Steam. It is designed to handle games build on this engine and nothing else. This is required since applications like Desura do not want to deal with the complexity involved handling this game engine. This is where the Launcher comes into play.
Currently the launcher supports running games as well as some basic fine tuning support. Games are not required to be installed using the Launcher as long as they install their Game File into the proper directory. This directory is global for all launchers. Using this principle you can use whatever launcher you want for your Drag[en]gine based games. Once installed the games can be run from the launcher like you know it from applications like Desura or Steam so just double click and get going.
The interesting part though is the fine tuning part. The common player does not worry about those and can just run the games on his machine. For power gamers though the tuning system allows to get the most out of your games if you are willing to turn some skrews. For this the launcher supports Game Profiles. Game profiles can be created globally for all games as well as individually for each game. You can define which profile a game uses by default so once you got a nice tuning starting a game uses this profile. You can though run a game any time by selecting explicitely a different profile. This can be useful for testing while creating a game or using alternate profiles like a "no sound" profile or a "window mode" profile or maybe a "capture video" profile and so forth. The most important choice you can make for each profile is which Engine Modules you want to use for running a game. A simple example would be to have one profile with OpenAL as sound module while another use NullAudio. Obviously the later one would provide a silent game which can be useful for certain games or if your boss is not supposed to know you are gaming instead of working :D . Furthermore every module in the engine provides a list of Module Properties. For each profile you can define which property values to set. All property values you do not set in a profile use the default values. In the screenshot below two sample screens are included giving an idea on how this looks like. Using this system you can tune your games the way you see fit. For the lazy ones the launcher provides a default profile which includes the best matching modules for your machine. Specifying no profile uses this default profile.
The entire engine as well as running games is handled in separate processes so no matter if the game fails for some reason (either due to scripting errors while modding or due to a crash in an experimental engine module) the launcher stays alive all time. You can also kill a running game if you managed to get it stuck for some reason. Something which is useful that other game frontends often lack. Each game can be run only once. Support for running more than one instance of a game in parallel can be added later on if this is desires. For most games though more than one instance does not make much sense.
The GUI Launcher is not finished and requires more work. Installing games as well as uninstalling games is not yet implemented. Also the module rating and optimal profile generation is not yet implemented. This requires some additional engine stuff to work first. Updating is also not yet included. This will later on be included when the engine turned into a releasable state. Last but not least the GUI is currently made to be functional but not yet esthetic. A nice look will be added later on. Important at the time being is the functionality.
One of the larger construction sides remaining had been the logging part. So far everything from the engine over modules to launchers used printf for logging and that's ugly to work with in the long run. The other half of the work this time went into building a proper logging system which is not only simple to use but also versatile and efficient to use. For this a bunch of logger classes have been created. These are organized in a hierarchy so you can use any combination of color-console logging, file logging and custom logging depending on your needs. For games running through the launcher log files will be written using a file logger to a separate log file for each game. All other log messages are written using a file and a GUI logger. This way the important logging informations about the launcher can be viewn in a separate window. Overall logging is now proper and works similar on all supported platforms.
File Hierarchy Clean-Up
This may sound now not like news worthy but it actually good news for Windows 7 users. Windows 7 has rather restrictive ideas about which files are allowed to be stored where getting in the way with a complex engine system as the Drag[en]gine is using. The IGDE and the Launcher have now been modified to conform also with the restrictive file hierarchy requirements of Windows 7.
With this work out of the way the next steps can be taken care of including Environment Mapping which works already but more about that later.
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.
Video on ModDB, Video on YouTuve
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.
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:
(@trigPlayerInArea & !trigActionA) | trigActionB
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.
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.
GLC (capture software) has a little problem right now so I decided to change the order of the remaining news posts in the pack a bit. So this one is going to be a technical one while the next one will have some video and less text. Let's a go!
A couple of news posts ago I talked once about the dual-shadow mapping code in use by the engine to simulate better lighting conditions indoors. Rendering many shadow maps is though a strain on the GPU and slows down rendering a lot. Dynamic lights and therefore dynamic shadows are not required for all lights or all the time. To improve performance static/dynamic shadow maps have been added.
The idea is rather simple. Looking at a given light source there are usually two kinds of objects casting shadows: static and dynamic objects. Static objects do not alter their position, orientation, size nor their geometry. For such objects dynamic shadows would not be required since the shadows cast by them are the same for all rendered frames. On the other hand the dynamic objects alter at least one of these properties so their cast shadows change over time. Most games choose a light to be either static or dynamic rendering full shadow maps for the dynamic case or missing shadows in the static case. Both have their advantages and disadvantages. Therefore I chose a hybrid approach similar to the dual-shadow maps version I did before.
Light sources have now one or two shadow maps depending on their type. Dynamic lights always use one shadow map all objects are rendered into since these lights change their position so any kind of static shadow map is impossible. For static lights though two shadows maps are used. One shadow map is for static objects the other for dynamic objects. Objects are classified either static or dynamic with the ability to switch class at any time and as often as they want. The static shadow map is calculated once the light starts to affect the view frustum. It is then reused for all further frames until it stops affecting the view frustum. Furthermore a dynamic shadow map is calculated every frame with only the dynamic objects. During shadow casting both shadow maps are tapped and combined.
Why doing two shadow maps? Isn't this slow? The idea is simply and based upon timing measurements and other observations. Static objects are usually static map geometry or props not supposed to move. These tend to affect large spaces in a shadow map. Speed of shadow mapping depends largely on the amount of shadow map pixels affected/written. By rendering these large and static objects only once into a static shadow map a lot of render time can be saved. The dynamic shadow map is therefore only affected by smaller and fewer dynamic objects. This reduces the shadow map render time for the dynamic shadow map a lot. Tapping from 2 shadow maps is only marginally slower than tapping from 1 shadow map. As a test case I used a room lit with 11 light sources. Using this technique 11 light sources could still be rendered while without a similar performance occurred already with 6 light sources.
This is not the end though since the performance still has to improve more to meet my expectations. This will be achieved with static light maps for situations where lights are not required to cast dynamic shadows. Using this dual-shadow map technique though the amount of dynamic lights that can be rendered can be increased. Only downside is larger memory consumption. But for static shadow maps the resolution can be dropped by a notch to compensate if required.
A new texture property type has been added named "ambient.occlusion". This property accepts a 1-component image defining the occlusion of a point on the surface. Ambient occlusion exists in different fashions and people tend to use it for the wrong effects. By definition ambient occlusion defines for each point on a surface the percentage it sees of a hemi-sphere around the point of interest aligned with the surface normal. The result is a value which can be used to darken points simulating how less diffuse light reaches points located in surface cavities. Due to this ambient occlusion is often brought in connection with sun light. Ambient occlusion can be used for this purpose but it's not the only purpose. In fact it can be also used for darkening other light sources. The graphic module supports now ambient occlusion for various light sources. In general all ambient light contributions are affected by this texture property. To avoid flat surfaces the ambient occlusion is also affected by normal maps.
Okay... the next time "will" be the dragon in narrow spaces one... stupid capture software. Also included some "trigger-happiness" :P . Say tuned.
For handling day-night cycle a proper game clock has been added. This clock provides the game time in years, month, days, hours, minutes and seconds. The system is kept very simple to avoid complicated calculations. The different spacings (like days per week or days per month) can be set individually. This way various game clocks can be implemented.
Concerning the sky a dynamic day-night cycle with realistic light intensity values has been added. The system uses a set of backgrounds and planets. Backgrounds define a texture to be used as the background for the sky and has the support to blend between various backgrounds. This way the different day times can have different backgrounds. Planets define the sun and moon and other light sources if required by a game. They are squeezed between backgrounds and foreground layers. They have settings to move across the sky on an curved path. Their light intensity changes according to the game clock time. Clouds can then be placed in front potentially covering the sun and moon. The system is rather simple but should provide enough flexibility for common sky scenarios. Since this is though just a sky system implemented on top of the game engine sky system it can be replaced at any time with an entirely different sky system.
ModDB, YouTube or Direct-Download (11MB)
Some explanations on the video. I added a time-lapse key to the code just for testing. In the game later on this will not be included. The time lapse simple makes time go past by faster but only for the sky and game clock. So everything else still works using real timing. This is just a basic test with only 4 backgrounds (night, dawn, day, dusk), a static cloud layer and the clouds not affecting yet the light to get the system working. Improvements will be made later on by adding a planar mode to layers (as the sphere mode works only well for very distant objects moving), actual 3D clouds (so they have an actual placement in the world which is more realistic) as well as clouds reacting on lighting conditions (various effects known from other games). The light intensities and direction are not coded but actually calculated from the sun and moon position and their light intensities (which is given by a curve) by weighting their influence. What can be seen already in this video is the intensity transition which goes from 20 (sun-light) all the way down to 0.01 (moon light). The varying light situations are handled by the HDRR code. The intensities are roughly oriented on real light intensities (lux) but roughly divided by 1000 and scaled a bit to make better use of FP16 values. Due to clouds, planets and the background being on different layers the clouds cover up the moon/sun as well as being able to have multiple cloud layers. You can not see the moon light in the video since codecs are not sensitive enough to such contrast variations. In the game though you have moon light casting shadows. You can barely see though at night which is supposed to be like this. See the additional screenshots below for an actual in-game lighting situation for day and night. You'll going to like dragons in that situation as they see better at night.
, 
To help in making skies a Sky editor has been created. It's based on editing layers and defining their day-time behavior using properties. Each property can be assigned links. Links just serve the purpose to reuse day-time values. A link defines a controller and a mapping curve. So far this system is similar to the Animator System as outlined in an earlier news post. A controller would therefore be filled with the current time in hours or other manipulation values. The curve can be constant, linear or bezier interpolated. So far this is the first version of the sky editor. The red ring is just an orientation help. Later on an optional full sky grid will be provided so you can better align objects on the sky. You are not required to use this editor since it just produces an xml file a bunch of scripts read and interprate. So you can also ignore this all and just provide your own scripts to handle the sky. For this just subclass the SkyDirector class in the game.
The next news post will be in the game profile and therefore talk more about the changes there.
I planed to do a different topic in this news post but I have changed it in the last minute. The reason is that some parts of the news post would shows lots of stuff which comes in a later one which would be odd. Even with this change there is no way around having tidbits of later news posts to be shown but it's less this way. So enjoy this news post. And don't worry, the "dragon in narrow spaces" will come in another news post.
This had been on my wish list since quite some time and I eventually got around to pull it off. Video resources have been added now to the game engine to support loading (and later on saving) videos of various kinds. To begin with Theora is supported as video format (hence *.ogv files). The implementation of videos in the game engine works similar to the way streaming sound files are handled.
The Video resource is obtained once a video is loaded from a file. This is a streaming resource object hence the actual file is kept open and the video is not yet loaded. To use a video in your game you have to use a Video Player resource object. Simply create one and assign it the video resource you loaded. Video player resources provide support to obtain individual video frames from the attached video resource. This is done internally using a decoder object provided by the Video Module that loaded the video file. To make it easy to use videos the video player provides support to define a play range, play speed as well as pause/resume support. Playback can be either looping or not in which case the video player stops playback after the play range is left. Otherwise playback loops endlessly. The playback speed determines as expected how fast the video plays back. You only have to call the "update" method with the amount of game time elapsed. The video player takes care of doing all the calculations.
Videos are usually used for textures. For this purpose you need a Dynamic Skin object. Simply create a renderable with the matching name and assign the video player to it. The graphic module then takes care of picking the right video frames from the video using the settings you made in the video player. Since you can use renderables for all kinds of texture properties videos can therefore be used also for all kinds of texture properties.
Here a sample video showing the video object and video player in action. See the image description for some further infos.
ModDB and HD doesn't like each other. See it HD on YouTube or Direct-Download (11MB)
Video on ModDB
Video encoding support will follow later on.
The sky had been one of the few places left in the OpenGL module which have not been yet using OpenGL 3.0 shaders. They are now changed to use this shader version. Furthermore the shadow casting has been altered at the same time. Sky shadows now support too PCF filtered shadows. As another change the boundary calculation for the Cascaded Shadow Maps technique has been altered. The shadow system though still requires some changes as the stock CSM technique does not work well with the large shadow range the engine supports.
Besides these changes ambient lighting has been added. So far the engine decided how much ambient light a sky light has. This is though not flexible and designer might wish to have specific lighting situations. The introduction of an explicit ambient lighting takes care of this. Sky lights now have two light intensity properties the light intensity and the ambient intensity. The ambient intensity defines the strength of light in shadow areas where the sun light only reaches over multiple bounces. The light intensity defines the strength of areas in plain sight of the sun light. The two values are additive in nature. Hence geometry in the sun shadow receive ambient-intensity light. Geometry in the plain sight of the sun receive ambient-intensity + light-intensity. This allows to implement daylight effects like clouds obscuring the sun in a dynamic way. By altering the light-intensity parameter this effect can be simulated. Moving the light intensity towards 0 the areas lit by sun light come closer to the areas only light by the ambient intensity. At 0 all areas have only the ambient intensity. This allows to break up the monotonicy of typical sun lighting as found in many games.
The image below (click, it's a GIF animation) shows a sequence of direct light values for showing the effect.
In a next step an explicit sun occlusion will be added to make lighting distribution inside buildings more natural.
The next news post will take a look at some game changes including the Day-Night cycle using the modified Sky System.
Engine Profile
Engine Profile