You should always have a game script, or a script that is not attached to an
object that controls game state. The class should extend
DGame
, and extend any or all
of the following:
title
: The title of the window (for the title bar and taskbar).onInitialize
: Called when the game is starting.onUpdate
: Called every frame on the update cycle.onDraw
: Called every frame before rendering.onShutdown
: Called on shutdown.onRefresh
: Called when assets are refreshing.Component scripts are any scripts you would want to attach to an object. The
class extend the Component
class. If you want them to be addable through YAML, you should annotate the class
with @yamlComponent()
.
You should also add a mixin of
registerComponents
(with the template parameter being the name of the current module) anywhere in
your scripts, but it is recommended to add it in the module you’re registering.
You should also annotate each member with
@field()
, with an
optional parameter that is what you want the name of the field to be in the YAML.
The template parameter is the loader you want to use for the parameter,
which overrides the loader (if there is one) for the type of the field.
An example script might look like this:
import dash.components, dash.utility;
@yamlComponent()
class MyComponent : Component
{
@field()
float x;
@field( "Y" )
float y;
override void initialize()
{
logNotice( "Initializing!" );
}
}
An object definition that uses it might look like this:
---
Name: Object3
Mesh: MeshX
Material: MaterialY
MyComponent:
x: 1.0
Y: 10.2
Loaders can be specified on subclasses of YamlObject
and
@field()
s. They
exist so that you may add a field or component to an object that has already
been created. A good example is Meshes
,
which rely on loaders because they are not created from YAML, but instead from
files. They’re annotation looks something like this:
@yamlComponent!( q{name => Assets.get!Mesh( name )} )()
class Mesh : Asset { ... }