FreeGameDev Planet - Development

Also check out the games planet.

December 03, 2016


xsge_physics 0.12 Released

This is a release I meant to make some time ago, but forgot about. It's a pretty small upgrade, but very useful for making certain code much shorter.

Version 0.12 of xsge_physics adds two meta-classes: "Wall", which all wall and slope classes inherit, and "Slope", which all slope classes inherit. These allow code that is designed to check for any wall object to be greatly simplified.

by Julie Marchant at December 03, 2016 04:04 PM

Castle Game Engine

We announce a new file format for transferring animation from Blender to Castle Game Engine: castle-...

We announce a new file format for transferring animation from Blender to Castle Game Engine: castle-anim-frames.

- It can transfer all the cool animation methods from Blender -- transform, armature, shape keys, hooks, physics (rigid body, cloth!), material animation, even Blender particles!

- The exporter for Blender is available on . The latest view3dcene version from GitHub ( ) or from snapshots ( ) can read it.

- It handles multiple animations (from Blender actions). So you can load a castle-anim-frames file in your game, and use the TCastleScene.PlayAnimation method to play various animations inside.

- It records a bounding box calculated from Blender, for fast loading and collision detection.

- The exporter can even handle particle animation, by a checkbox "Make Duplicates Real (Export Particles)". (Be careful with the number of particles, though.)

- The exporter by default creates a single file, with static frames encoded inside.


- The format is a series of static X3D frames. All the advantages and disadvantages come from this simplicity. On one hand, it can be used to transfer any Blender animation to Castle Game Engine. On the other hand, it can be somewhat "heavy": loading large animations takes some time, and they eat some memory.

Some of these disadvantages may be mitigated in the future (as we will internally convert it to better X3D interpolator nodes). But it will always remain somewhat "heavy solution".

At the same time, it will always remain something that can handle any Blender animation, right now. As opposed to X3D exporter (that currently cannot export Blender animations at all, and in the future will support a limited subset of Blender possibilities).

More information about the format is on .

- It is not actually a new format, but a much upgraded (and backward compatible) version of the previous KAnim format.

Besides the new features listed above, probably the most important change is that we no longer call it "obsolete". We finally admit that it's a really cool way to transfer animations from Blender to Castle Game Engine, and we want to support and improve it in the future!:)

As it will always be more "heavy" than simply transferring animations through X3D files, so improving Blender X3D exporter is also still on our roadmap. But "castle-anim-frames" will also have it's place, as a way to export EVERY Blender animation to Castle Game Engine.

December 03, 2016 08:41 AM


Dyon 0.13 is released!

Dyon is a rusty dynamically scripting language, borrowing ideas from Javascript, Go, mathematical notation and of course Rust!

In this post I will go in depth about two features of Dyon, and discuss them from the perspective that I use and need them.

Dynamically loaded modules

One of the things that makes Dyon special is the way of organizing code using dynamically loaded modules. When scaling up big projects in Rust, I noticed that each project required a configuration file to tell which dependencies it has. This is useful, but introduces extra work when moving code around. Another problem is when I work on some game, and want to refresh the game logic while running, there are many ways to do this and it depends on the specific project.

Sometimes I want to experiment with different algorithms and compare them side by side. While a version control system is great, it does not allow you the playful coding style I like. The projects I work on tend to focus on exploring some idea, and this leads to a dozen files spread across folders which does not fall into a neat namespace hierarchy. I do not want to think too much about how to name stuff, it gets in the way for productivity.

A Dyon script file does not know which other files it depends on, so you need to tell it for each project.

Setting up dependencies is part of a loader script, that loads modules and connect them together.

For example:

fn main() {
    find := unwrap(load("src/find.dyon"))
    unop_f64 := unwrap(load("../dyon_lib/unop_f64/src/lib.dyon"))
    unop_f64_lib := unwrap(load(
        source: "src/unop_f64_lib.dyon",
        imports: [unop_f64]
    set_alg := unwrap(load("../dyon_lib/set_alg/src/lib.dyon"))
    main := unwrap(load(
        source: "src/main.dyon",
        imports: [unop_f64_lib, set_alg, find]
    call(main, "main", [])

Horrible, right? Yet, there are some upsides:

  1. Easy to change the loader script to reload code on the fly
  2. Easy to generate code at loading and running time
  3. Easy to control preloading of modules that does not need reloading
  4. Easy to rewrite and refactor code from Dyon to Rust
  5. One configuration file per project

In most languages, you need some complicated system for these things, but in Dyon you learn how do it as a beginner.

The 0.13 version adds some important changes:

  1. Modules are now represented as Arc<Module> behind a Arc<Mutex<Any>> pointer
  2. External functions (Rust code) are resolved directly instead of depending on the module

The reason for 1) is when closures escape module boundary. Variables in Dyon are 24 bytes on 64 bit architectures, which was makes it possible to fit in more stuff like 4D vectors and secrets. I squeezed in a pointer to the closure environment stored beside the closure pointer. This keeps the track of the information required to find the relative location of loaded functions. The Arc<Module> pointer makes it possible to create the closure environment faster, instead of cloning the whole module for each closure.

The reason for 2) is when I use another pattern:

fn main() {
    window := load_window()
    image := load_image()
    video := load_video()
    input := load_input()
    draw := unwrap(load(
        source: "src/draw.dyon",
        imports: [image]
    sample := unwrap(load(
        source: "src/sample.dyon",
        imports: [draw]
    animation := unwrap(load(
        source: "src/animation.dyon",
        imports: [sample]
    main := unwrap(load(
        source: "src/programs/checkerboard.dyon",
        imports: [window, input, animation, video]
    call(main, "main", [])

In the example above load_window is an external function (written in Rust) that returns a module. The returned module containst other external functions, which then get imported into the other modules.

To make this logic work, I decided to use a direct function pointer and wrap it in FnExternalRef. The downside is that you can not track down the location of the external function when something bad happens. I am crossing my fingers and hope this will not be a big problem (famous last words).

Try expressions

A new feature in 0.13 is the ability to use try to turn failures into err and success into ok.

Link to design notes

Some background of why I care about this so much: I am working on path semantics, which is a big dream I have.

A path is a function that relates one piece of a function to another function in a space called “path semantics”, because it is a space of meaning (semantics). Normally there is a bunch of paths for a function, that might differ for arguments and return value, but they all need to work together to get to the other function.

When the same path is used everywhere, it is called a “symmetric path”.

Symmetric paths are extremely mathematically beautiful and rare.


and[not] <=> or

which is equal to, but not meaning the same as the equation:

not(and(X, Y)) <=> or(not(X), not(Y))

I just occured to me that this is one of De Morgan’s laws.

Here is another example:

concat[len] <=> add

which is equal to, but not meaning the same as the equation:

len(concat(X, Y)) <=> add(len(X), len(Y))

You can use these laws to do transformations like these:

add(X, Y)
concat[len](X, Y) // using a symmetric path to reach the other function
// there exists `Z` and `W` such that `X = len(Z)` and `Y = len(W)`
concat[len](len(Z), len(W))
len(concat(Z, W))

I want to create an algorithm to explore the space of path semantics efficiently. There is no currently proof technique I know to derive them, except to “make a hypothesis and falsify”, kind of like how scientists do. The only way to find which functions that works with others is by trying.

Here is a function that tests for a symmetric path candidate:

/// Infers whether a path can be used for a function
/// in a symmetric way for both arguments and result.
sym(f: \([]) -> any, p: \([]) -> any, args: []) =
    all i {is_ok(try \p([args[i]]))} &&
    is_ok(try \p([\f(args)]))

Let me take this apart an explain the pieces:

  • sym is the function name
  • f: \([]) -> any is an argument f of type closure taking [] (array) and returning any
  • p: \([]) -> any is an argument p of type closure taking [] (array) and returning any
  • args: [] is an argument args of type [] (array)
  • \p([args[i]]) calls the closure p
  • \p([\f(args)]) calls the closure f and then p
  • all i { ... } is a mathematical loop that automatically infers the range [0, len(args)) from the body

The \ notation is used in Dyon because type checking happens in parallel with AST construction, plus some other design choices that closures always return a value. I needed a design that was easy to refactor and different for normal functions and closures.

The problem was that this function gets called many times with different closures, and sometimes it fails and crashes because the types are wrong.

try converts all failures into err, such that the function sym can detect a path candidate.

Now, you might think, why not use try and catch blocks?

Dyon already has a way of dealing with errors: res, like Result in Rust but with a trace and any as error type. There is no need to add a second way of dealing with errors, when the first method works just fine.

For Rust programmers, the try keyword can be a bit confusing, since they might be thinking of the try! macro. In Dyon, you use the ? operator instead of try!, just like in Rust. I decided to use it because it feels closer to what we mean with “trying” in natural language.

For example, when a function foo returns res, you can write:

fn foo() -> res { ... }

fn bar() -> res {
    a := try foo()?

This is executed as try (foo()?), returning err early, so you can handle the case where it failed. Interestingly, it gives the same result as (try foo())?.

December 03, 2016 12:00 AM

November 30, 2016


Castle Game Engine

You can create an animation using Blender physics ( ), and export it to .castle-...

You can create an animation using Blender physics ( ), and export it to .castle-anim-frames format and play the animation in Castle Game Engine ( ).

That's how e.g. they did the bridge collapse at the beginning of "Half Life 2: Episode Two" !:)

The sample models are available in (subdirectory castle-anim-frames/physics/ ) . You can test them in view3dscene (use the view3dscene version from snapshots on or from GitHub sources on ).

The .castle-anim-frames exporter can be downloaded from .

November 30, 2016 07:55 PM


Newly Added Game Templates

With Xenko 1.9β, we’ve released our brand spanking new Game Templates! Super fun stuff, so open the blog post to see more!

Templates were designed to help bring your game ideas to life faster. With Xenko 1.9β you can now create a project more efficiently with our new templates, which will help kickstart your game development efforts!

We’ve started transitioning from small individual samples to more complete game templates and asset libraries to help you get the most out of Xenko. In the spirit of transitioning Xenko to an overall-game-dev-solution-provider, we’ve implemented templates for three popular game design genres - which you can now use as a starting point for your game.

The three templates we’ve added are:

  • First-person shooter
  • Third-person platformer
  • Top-down camera RPG


First-Person Shooter

Arguably one of the most popular game genres today. Xenko’s FPS template helps our developers put together a game with a pre-set, first-person camera where you can shoot at the Xenko crates. The controls support both controllers and mouse/keyboard input. The crates come with physics’ collider bodies and are fully interactive. The template also shows how to spawn particle effects alternating between bullet impact effect and a smoke trail depending on if you shoot a wall or a crate. Production quality model and animation assets make it easy to learn about controlling and switching animations.

Third-Person Platformer

This template is a great starting point for ever-popular platformer games. While the template is set in 3D it can be easily tweaked to become a 2D platformer. Just disable camera rotation in your 3D game to transform your game into a 2D platformer. Additionally, we’ve implemented a few techniques which we hope will be useful to you. Controls will now support both controllers and mouse/keyboard style input. The animation controller seamlessly blends the idle, walk and run animations providing striking visual feedback.

Top-Down Camera RPG

This template positions the camera at a fixed angle above the character and enables touch screen controls as well as mouse point-and-click, similar to many traditional RPGs. It also uses the Navigation Mesh feature so your character won’t get stuck in bad pathfinding or hit walls. On the game logic side, the template shows several kinds of interactions with game objects, like collecting coins and loot and attacking and breaking objects.

New Game Template

New Game Template

Our New Game template has access to existing production quality assets we used to create our templates! We have particle effects, physically-based materials, lots of animations for our new Xenko mannequin model and building blocks with physics ready for your rapid level prototyping. Unlike the templates, which are kept concise, the extra packages contain many more assets. You’ll even find some props which are not in the templates (swords for example!).

As always, we are committed to offering you best-in-class game dev solutions directly in Xenko’s Game Studio.

Additionally, we are looking to be able to give our users the opportunity to make their own templates that you will be able to share with other Xenko users. Of course, we’re planning on offering more templates as well. Keeping in line with our goal to become one of the best game engines for VR, we are also planning on adding a VR template in the not very distant future.

Do you have a template that you’d like to see on our Roadmap? Let us know in the comments!

November 30, 2016 03:00 PM

Castle Game Engine

See this cool "lizardman" character, animated, with normalmaps and ambient occlusion textures:) Everything...

See this cool "lizardman" character, animated, with normalmaps and ambient occlusion textures:) Everything done in Blender, viewed in view3dscene:) More info soon! In the meantime, for the adventurous: sources (in Blender and Castle Game Engine formats) are inside !

November 30, 2016 04:23 AM

November 29, 2016


Cocos Creator v1.3.2 released!

Cocos Creator 1.3.2 officially released! We are excited to release version 1.3.2 of Cocos Creator. Cocos Creator is a new, unified, development tool that handles every step in the game development process. 1.3.2 Main Features [RichText] Added custom TTF font

by slackmoehrle at November 29, 2016 03:25 AM