Tips & Tricks

We recommend you download the Dage Demo game (that comes with latest Dage Release) and study the script folder for comments about the game. There you can backtrace how most features inside Dage game works.

When user executes dage.exe in root folder, game looks up folder called data. This cannot be changed. From data folder, Dage opens config.txt file.

Inside config.txt file is all the basic configuration that determines how the Dage will behave.

Let's see how:

-- This Config file should be compiled before distributing to end-user.
 
Game = TGame.Create(); --This line is compulsary!
 
Game.Caption = 'DAGE - Dage demo'; --Sets window caption
Game.Title = 'Dage Demo'; -- Set taskbar button title
 
Game.LoadScript('scripts/GUI.txt'); -- Loads the graphical user interface scriptfile
LoadGUI(); -- executes LoadGUI() function inside GUI.txt
Game.LoadScript('scripts/onGameLoad.txt'); -- Loads the game

Line

Game = TGame.Create();

is essential. This creates script object for Game object inside Dage engine. So scripting and Dage can work together.

Next comes basic configuration. Like Game.Caption, which sets the window caption, or Game.Title, which sets the taskbar button title. For more about possibilities to configure Dage see Script reference.

Next Dage wants to load GUI.txt inside script folder.

Dage handles files with folder - package system. Lets take example a line

Game.LoadScript('scripts/roomscripts/Room01.txt');

First Dage tries to open scripts.dog file (data package, that we tell more about later). If it isn't found, Dage tries to open subfolder called scripts. Then again, it tries to open roomscripts.dog file, and then subfolder, etc. Until it finds Room01.txt either inside package, or inside subfolder.

This makes very versatile way to organize your data in different folders/files. If you (for some reason) want that all your files are straightly accessible from data folder, this is possible. Or maybe you want all the files in Game0001.DOG, Game0002.DOG, Game0003.DOG etc files, which is also possible. (Note: you cannot create yet DOG package files, but it will be implemented later releases of the engine).

It is wise to organize files to many subfolders, as when you need to send an update to your players, you don't have to send whole 200 megabytes large Game0001.DOG file.

Note: Currently DOG packages cannot be created but it is good to know, how file-handling will work in Dage, so you can plan your code appropriate.

.DOG files can have folder structure, and contain multiple files, all the formats Dage supports (JPG, 3DS, etc), except Script files.

So tree structure inside Data folder could look like this:

• data
  • config.txt
  • models
    • actormodels.DOG
      • Wayne
        • wayne.3DS
        • wayne_tm.jpg
        • wayne_ani.smd
      • Fred
        • fred.3DS
        • fred_tm.jpg
        • fred_ani.smd
    • rooms
      • bunker.DOG
        • bunker.3DS
        • texture01.jpg
        • texture02.jpg
  • scripts
    • onGameLoad.txt
    • roomscripts
      • bunker.txt
    • GUI.txt
  • shader
    • data.DOG
      • Shader01
        • frag.txt
        • vert.txt
      • Shader02
        • frag.txt
        • vert.txt
      • Shader03
        • frag.txt
        • vert.txt

End-user would see the inside of Data folder, after creating Dog packages, like this:

• data
  • config.txt
  • models
    • actormodels.DOG
    • rooms
      • bunker.DOG
  • scripts
    • onGameLoad.txt
    • roomscripts
      • bunker.txt
    • GUI.txt
  • shader
    • data.DOG

Dog packages are good way to hide the data from user so that user can't view or modify it.

Now if you would want to access bunker.3DS file, you could use it like Bunker.filename = 'data/models/rooms/bunker/bunker.3ds' inside scripts. You can use the basic windows folder structure as long as you are developing the game, and when you want to publish the game, you simply use Dage Dog tool to create folder structure.

Script files cannot be included inside DOG files, but end user will not have access to them, because you can compile them to compiled Lua scripts.

Dage also seeks all script files inside scripts folder. So you need to place your scriptfiles there.

When developing Dage game, lots of functions will go around mouse events. What happens when users clicks different game objects.

Regardless of the mouse event, Dage seeks the object under mouse in the following order:

1. TInventory (meshes in inventory)
2. THudsprite
3. TMesh
4. TActor
5. TDummy
6. TRoom

That means, if TActor goes in front of TMesh object, it won't trigger the mouse-events, and so on.

Specially when player clicks on screen, and Dage finds out, that TRoom is clicked instead anything else. Dage will position MousePawn to 3D position. MousePawn marks the spot where player clicked. Then Dage finds all the Actors, that has MouseControl set to 1, and tells them to walk towards MousePawn position.

Insert to an onRoomMouseDown event Actor.ClearWalkpoints();

function onRoom01MouseDown()
  Actor.ClearWalkpoints();
end

Even though hardwares now-a-days are capable of astonishing results, we cannot use the resources limitless.

FPS (Frame Per Second) tells how many times per second the Dage draws (or renders) the images to the screen. The higher it is, the better and the smoother the game will run.

There are many ways to increase FPS. User of course can decrease the resolution, disable effects like dynamic shadows etc. But there are things you can do as a developer.

• Low polygon modeling
  • Less polygons, higher FPS. Rooms should not have more than 10000 polygons, and actors no more than 500.
• Small texture sizes
  • Textures, lightmaps, animation files, etc should be kept as small as necessary to make the game look good.
  • Textures higher than 512×512 are not recommended
  • By keeping the textures dimensions in power of 2's, increases the FPS a little. Like 32×32, 128×64, 512,128 etc.
• Simplier walkareas.
• Less game objects.

We try to make Dage use as little as possible memory, but…

we cannot predict, what you want to keep visible in game. For example inventory objects, or some kind of Holodecks, where some objects stay and other room loads in background. This is why it is your concern to unload the objects, when they are not necessary anymore. All objects have Destroy event, so when they are not needed, just fire up Destroy event and *puff* - it was never there. Note: If you destroy Room, you need to destroy all the objects inside the particular room, or they will haunt you.

Dage has a lot of default attributes, but as we want you to make your own game, you can customize (almost) everything. Inside script reference, there is a lot of information about what can be configured (note: as developing goes further releases, we include even more customizable attributes. If you have something in mind you would like to see customized in Dage, drop us a message and it could end up in following releases!