Welcome to the Clickteam Blogs
This new area of our site will host a range of blogs including Clickteam News, information about Fusion 3 development, ClickStore Features, User Devlogs and much more besides.

If you would like to write a guest blog article about your game, app, development or something else then please Contact Us for more information.
Building Extensions
Posted on: February 27, 2017
Clickteam Fusion has for a long time been all about extensibility. If you look at the available plugins and extensions for Clickteam Fusion 2.5 you get a huge list of readily available objects. All of those have been up until now been written in C++ code (for the Windows runtime) and in the respective languages for the other platforms.

We have in these blog posts already covered a bit about how you in Fusion 3 can create your own extensions/objects using only events directly from Fusion 3 without any C++ code at all.

Will you still be able to write C++ extensions for Fusion 3? The answer is yes.

The Extension SDK

Fusion 3 and it’s “runtimes” are all based on our own C++ written “nucleus” game-library. If you can interface with this library you can write your own extensions quite easily. The extension SDK will basically be a bunch of headers and a library file.

Here is a quick overview over how extension developers can expect the extension development workflow to look like.

All objects in the nucleus library are deriving from a simple “Object” class which is the basis of any kind of Object. Any object that will be drawn on the screen as a member of one of your frames is a subclass of the “FrameObject” class which is also an “Object”. FrameObjects will typically be the object your extension will derive from. Math or functionality-only objects can simply derive from “Object” as they don’t need to be drawn on the screen.

After that you can begin implementing various methods for your extension that you can call directly from Fusion 3 as an action/condition or expression.

Interfacing with Fusion 3

Your source code for your extension might be the cleanest and most beautiful code ever created but Fusion 3 can’t magically use it without some sort of extra information.

You create your own extension definition by defining all your actions/conditions/expressions and properties in a JSON file.

The general layout of such a JSON file would look like this:

In the various JSON arrays you can specify which methods are actions, which are conditions and which are expressions. You can even name your parameters with translations to various languages.

This is an example of how the “Position” property from FrameObject looks like in JSON:

The definition contains the type of the property, the name, description (as seen in the Property pane of the editor), if the particular property is shared between multiple instances of the same type or not, the default value and then the setter and getters. Properties are often found in other programming languages as being like variables on steroids. Not only do they work as a variable but you can also assign logic to them – in this case define a c++ setter and getter method. If only “getting” should be allowed then you can set the “setter” to “disallow” and vice versa.

With these definitions Fusion 3 has an idea how it can interface with your extension. It can pass all sorts of nucleus types as parameters and all the usual C++ types such as bool, int, short, long, size_t, string and so on.

Many popular third party game libraries are written in C++ and are very portable. Writing a thin wrapper class to allow it to talk with Fusion 3 will now be a very simple task.

Distributing your extension

For Fusion 2.5 and previous titles you distributed your extension as a compiled binary (basically a renamed .dll file). While it will be possible to do this for Fusion 3 as well we are hoping we can encourage extension developers to chose the Open Source approach.

Writing a closed source extension has several drawbacks:

  • – Is only available to the platforms the extension developer has access to
  • – If “nucleus” changes too much and the binaries aren’t compatible any longer the extension has to be recompiled or possibly altered a little bit.
  • – The extension developer has to create one binary for each and every platform they wish to support.
  • – Any new supported platforms in Fusion 3 will not have the extension immediately available (until the extension gets compiled for it).

With an open source approach the source code can be bundled with the extension and be compiled directly into the game. If you write good cross-platform C++ code then it should in theory “magically” work on all supported platforms that Fusion 3 will export to.

Third party libraries can still be included, both closed and open source.

We’d love to hear your comments on our blog posts and on our development.Throw us a mention on Twitter or Facebook and tell us what you think!

Visit Clickteam @ FacebookVisit Clickteam @ TwitterVisit Clickteam @ YoutubeVisit Clickteam @ TwitchVisit Clickteam's The Reactor @ PatreonVisit Clickteam @