A few words from our developers
"Welcome to the Fusion3 development blog!

Here we will regularly post news, images, videos and other information on how Fusion3 development is coming along and share some of our thoughts behind the design process. We hope you enjoy it."

Sprite Sheets

Posted on: April 10, 2017

Sprite sheets

A lot of our users enjoy working with sprite sheets when they make graphics for their games as it keeps all of the similar images in the same file.

“Sprite sheets” is a technique to store several images into one image while still being able to draw them as if they were individual images.

It is convenient for graphics artists and it makes it easier for one to find the file one wants to edit. A typical approach would for example be to have one file per object in the game that includes all the animations.

* Hero.png
* Enemy1.png
* Enemy2.png

Sprite sheets also have a performance benefits at runtime in some situations.

The graphics cards in your computer/phone/console is a very specialized piece of hardware and is very fast at drawing lots of geometry really fast – but only as long as things don’t change too much between each thing that the graphics card is asked to draw. Changing the texture between every object that we draw can become a performance problem quite quickly.

By bundling together lots of sprites into one texture then even though we want to draw a different sub-image from the same texture we avoid the time-consuming texture switch. This will be especially noticeable if you want to draw hundreds of the same type of sprite (for example in particle-systems) at the same time.

Graphics API’s such as OpenGL or DirectX have over the years invented new ways to make using many different textures “cheaper” time-wise. One example is ‘texture-arrays’ that allows you to make an array of textures and then simply ask the graphics API to draw using the texture at some index.

Right now we target the lowest common denominator of OpenGL ES 2 such that the same code will work on phones and in WebGL. This means that for now we stick to the good old sprite sheets. We might have optional support of newer OpenGL features in the future when available.

There are cases though where sprite sheets give no real benefit and that is unfortunately when you have a very diverse set of different objects you want to draw and you use the typical sprite sheet approach mentioned first in this blog post.

From the graphics API’s perspective it will typically only have to draw a very few number of sprites from each sprite-sheet for every texture switch it does. This is because the “logical” organization of your sprites doesn’t correspond very well to the order of how your sprites are drawn.

If your game for example draws these sprites in order:

* Hero
* Sword
* Enemy
* Grass tile
* Earth tile

Then it would switch to a new texture almost every draw call:

* hero.png
* weapons.png
* enemy.png
* ground.png
* ground.png

This would for a lot of sprites be slow. For small games it is hardly noticeable but it still matters. You could of course try to put all of your sprites into the same sprite sheet to minimize the texture-switches but that would remove all the benefits of the having the sprites in sprite sheets in the first place. For Fusion 3 we have a simple solution.

Sprite sheets in Fusion 3

Fusion 3 has native support for sprite sheets in the sense that it only cares about drawing a subset of a texture. Where the texture comes from is not important from the runtime’s perspective.

Fusion 3’s approach to the sprite sheet problem is can be either one of these or both. 1.Generate optimized sprite sheets at build-time. 2.Continuously update sprite sheets dynamically at runtime

Our runtime can during testing collect texture-switching statistics from “representative playthroughs” and figure out which images gets drawn most often in succession. Using this data we can generate optimal sprite sheets (for those representative playthroughs). In any case our build-time sprite sheets will be better than hand-made sprite sheets because of the statistics we can collect.

The static sprite-sheets will of course not be optimal in all cases. This is where a dynamic approach to sprite sheets really can shine. Those sheets can be continuously be updated over time to adapt to any situation. We already have most of this dynamic system in place.

We also have a working system that uses the exact same algorithms to cache the image of certain complex GUI objects that takes a relatively long while to draw but are rarely updated. We then store the rendered images of those objects into dynamic sprite-sheets and draw the cached images back to the screen. This has already proven to be very robust and works completely without any other user intervention.

Sprite sheet editing in Fusion 3

As you saw in our last blog post we are still working on the image editor. For now the inbuilt image editor only opens up the part of the image that is used for the image. When the image is saved we update the section in the sprite sheet.

If you want to edit the image where you can see all the other sprites at the same time you can of course simply chose a different image editor. That will open the chosen editor with the raw sprite-sheet image. There is of course the problem that arises if you want to resize an image that came from a sprite sheet. Making the image smaller is no problem. Making the image larger is a problem as there might not be space for it. For when there isn’t space we will have to save the image into a separate image.

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!



Image Editor

Posted on: April 5, 2017
Hi everybody. As promised here we will take a look at Fusion 3’s image editor.

But first a look back at what we had in Fusion 2.5 and previous products.

The image editor over the years

The image editor hasn’t changed much over the years mainly because it couldn’t get much simpler. It was a simple pixel-precise image editor that did what you expected it to do, it got the job done and you were able to import your graphics made in other tools. I’ve personally even heard of a few pixel artists not interested in game development that used the Fusion 2.5 image editor as their main graphics editor because it was down to the point, pixel precise, and did what it did well – plus you could preview your animations directly from the animation editor interface.

A look at the task at hand

Secondly, instead of writing about what the the image editor will be like, I’m going to take an alternative approach this time.

Graphic artists come from vastly different backgrounds drawing many (often multiple) different styles. Graphic styles vary from pixel art, vector inspired graphics, painted backgrounds, hand-drawn, 3D pre-rendered and so on. A good graphics editor for any of the mentioned art styles is incredibly difficult to make right – and there are as many different art styles as there are people out there.

Editing graphics is paramount when you want to make a game. As a game development tool this puts us in a difficult situation when designing an image editor as we cannot possibly fill all roles of being the perfect image editor for everybody. All graphic artists already have their own favorite drawing programs they are used to. Making an image editor that is customizable enough to fill so many needs is near impossible.

As a consequence of this we have decided to do something different in Fusion 3 than what we did in Fusion 2.5. We will still have an image editor but it will be like a “lowest common denominator” of image editors – something along the lines of which we’d had for years already: A good basic MS Paint like image editor but with extra features for the most common use cases and for drawing simple graphics.

But what about all the advanced features?

Third party graphics editors

For the cases where our own image editor is not going to cut it for your graphics editing needs, we will add third party image editor support.

This means that you in Fusion 3 will be able to define a set of your own favorite tools (such as Paint.NET, Photoshop, Paint Shop Pro or whatever you can think of) and assign those tools to specific images. This means that once you intend to edit an image within Fusion 3 we will check which tool you prefer for that image and load up the image in that. This saves you from having to import the graphics from your favorite program whenever you need to change them.

Our own image editor

Here is a work in progress image of the new editor…

Big things to come!

Posted on: March 15, 2017
Hi everybody. We apologize for the lack of blog post last week. We are SUPER busy hammerin’ our codebase into shape. We will get back to working on Fusion 3 in a little while, but first a short update for this week:

Currently we are working on optimizing certain parts of the codebase, make serialization between JSON and our internal data structures as fast and robust as possible (there’s a LOT of data to parse) and making testing different export modes as easy as possible.

For example we are experimenting with a build-mode selector right next to the build button.

This is a screenshot of our early prototype of a slightly different build-button. The build-and-run button is the button you most likely will be pressing the most to test out your project. Don’t worry, we haven’t forgotten about the “build-and-run frame” button!

With a game targeted for multiple platforms you will probably like the ability to switch between the different targets very easily and maybe even run them simultaneously to compare how they run.

For next week I’m hoping I can show off the Image editor for Fusion 3!

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!



Fusion 3's Backbone

Posted on: February 14, 2017
As we’ve mentioned in our previous blog posts our engine is a written in modern C++. Despite it’s age it is still one of the most popular languages to write software in today as it has excellent platform support and loads of tools that can help debug and improve the software your are writing. The C++ language has over the recent years evolved quite a bit and has added a lot of nice new features. Useful language features can help us help you in turn.

Fusion 2.5’s windows runtime was written in C++ but we have “native” ports of all our runtimes to various languages including Java, Objective-C, Actionscript, C# and so on. This unfortunately gave us the multiple-maintenance problem of having to fix the same bug in all the different runtimes. When various platforms started out we had to port the runtime to the supported language to even run on the platform. Android for example initially required programming the apps/games in Java.

Managed programming languages has some drawbacks including cost of garbage collection, limited amount of RAM and other issues. Garbage collection and managed memory often feels like they godsend to programmers as it creates more reliable programs and needs less time to get memory management right (memory leaks and crashes relating to already released memory).

All major platforms have moved to allow for the use of native programs – for example written in C or C++. C++ still seems to be the industry de facto standard and there is excellent support all over. Many game related libraries typically come with C++ bindings so you can hook it into almost any game no matter what they are written in. This is among many other reasons part of our decision to program Fusion 3 in C++.

Fusion 3 on the web

HTML5 is latest new holy grail of the web. It allows you to make interactive websites like never before – that includes entertainment like games and other interactive media.

Native apps and games on the web doesn’t seem like two things that go hand in hand. This however changed a few years ago with the creation of “Emscripten”. Emscripten is a source-to-source compiler that takes something called LLVM bitcode and spits out javascript. Basically it allows us to compile Fusion 3 made games into javascript based games/apps with relatively little effort and with very high performance.

Won’t C++ compiled to Javascript be slow?

Not really. Emscripten compiles to a subset of Javascript called “asm.js”. It is basically fully valid javascript but since only a specific subset of it is ever used it allows the browser to do some very aggressive optimizations on the code and even on-the-fly compile the code to native code for the platform you are running it on. This means that even though your game/app will go through a Javascript step it will “just be a phase” so to speak.

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!



Evolution of the Event List Editor

Posted on: February 7, 2017
Over the weeks people have been asking more and more often about how the event list editor would look in Fusion 3.

Short answer: There will be no (separate) event list editor. It will be merged with the event editor itself into one single editor that can do everything in a simple and easy way.

As you most likely know, Fusion 2.5 and previous have always had two different types of event editors: The event editor and the event list editor. The event editor was the “main” editor where you see all the rules of your game at a glance in a spreadsheet kind of way. This view is very compact and can pack a lot of events into a little amount of screen space.

The event list editor is almost identical in the sense that it shows almost the same information to you as a user with the exception that it has focus on showing the order of things in a list like fashion. The event editor never shows you the absolute order of actions for objects (only within the context of the one object you are inspecting by hovering your mouse over the checkmark). To get the full order of all actions in the event you had to use the event list editor.

The event list editor in Fusion 2.5 and previous has two modes – one where you edit all the events – and one where you only edit the action order of a single event. Having two editors made it feel slightly awkward when you had to leave the editor just to change a specific detail. The editors were themselves so similar in nature that they kind of begged to be merged together. Thus was the idea for merging them was born.

At the time of writing a single click on the event number toggles it’s display mode into the “event list editor” kind of way. While a simple feature, it already feels like a major improvement to the overall workflow when you write your events. All the information is there at your fingertips with as few clicks as possible.

Doing this for one event at a time is simple enough. What if you actually preferred to only code in the old event list editor? No worries, we got you covered. With a click of a button you can toggle the entire editor into “event-list-mode” which forces all events to show their actions.

When you leave the event list mode it will restore the display modes of your individual events.

You might notice that the object icons in the horizontal row at the top disappears. This is because they have no function while in event-list mode. We are testing out what the easiest way is to add new actions to an event in alternative mode.

Merging the two editors have several benefits

-You don’t feel like you are leaving the editor

-The scroll position will be kept as you toggle so you don’t have to search for the event you were just looking at after you change to another editor.

-It is a lot more space efficient on the screen when you only want to edit a single event.

-Is much more intuitive. It is simply just an alternative way of displaying information with an easy way to toggle it.

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!



Transitions in Fusion 3

Posted on: January 30, 2017
In this blog post I’m going to cover a bit about transitions.

Transitions between screens/images/levels are very useful in any kind of game but there haven’t been a wide variety of them for Fusion 2.5 and previous titles. To make them for Fusion 2.5 you needed to program in C++ and it was only using functionality originally designed for software rendering (no hardware acceleration). To make matters worse the transitions also suffered from not being very portable to the other runtimes. We felt that transitions had been overlooked for too long. But how can you make something like transitions easy to modify for clickers?

To look forward you sometimes have to look back first.

Some of you might remember the rarely used functionality in The Games Factory where you could make a frame designed to be used as a transition. It sounds pretty useful but it had a few limiting quirks: You didn’t have much control over what was drawn and what wasn’t. It worked by using the objects in the “transition frame” as invisible “coins” on a big “scratch & win” card – revealing the next frame wherever the objects moved for as long as the transition duration. It was actually kind of cool but it was very limited in scope.

The idea that you could make your own transitions kind of stuck since then. As you might have read in all our previous blog posts we have a completely new type system which is our sort of version of an entity/component system but it ties nicely together with object oriented programming. A “Frame” is in Fusion 3 just another object of sorts – an object that we can subclass quite easily. All frames in Fusion 3 are in effect sub classes of “Frame” in one way or another but they can also be sub-classes of other frames inheriting their special features and functionality.

This means that we could simply make a subclass of “Frame” called “Transition” that gives one access to two images – one image representing the previous frame and one of the next frame. With those two images you can then event your very own transitions using whatever objects or pixel shaders you can think of. Here is how I implemented a few simple transitions…


Just position two image objects on top of each other. At the start of the frame the two image objects have their images set to the previous and next frame images respectively. Then, in an always event, I set the opacity of the top image to the transition progress (retrieved from an expression). Done!

3D Card Flip transition

For this transition I simply only show the first image when the transition progress is less than 0.5 and only show the second image when the progress is greater than or equal to 0.5. This switches the images midway. Secondly I set the user matrix of the two images to be the rotation matrix around the Y axis for 180 degrees times the transition progress. This slowly animates the rotation around the vertical axis. I made sure that the hotspot and center of rotation were are the center of the images. Finally I set the blending color of the images to slightly darken them as the angle isn’t 0 or 180. Basically:

[Image A] and [Image B]:
—Set “darkeningFactor” to (1 – abs( sin(progress*180) ) * 0.3) * 255
—Set blending color to: Color(darkeningFactor, darkeningFactor, darkeningFactor, 1)

Other types of transitions

As I mentioned you can use pixel shaders and even several objects to represent the transition between two images. We haven’t worked on object transitions yet but they will simply use the exact same system. You will have the full power of all your coding creativity at your disposal when it comes to this. As people get creative with this system I’m predicting it will be used a lot more than it currently is. I’m imagining the flip transition being used for card games when a card is drawn from a deck.

I can even imagine this being used a lot for making reusable special effects on objects. For example different “kill” effects on objects as they are destroyed using different weapons. One transition could make objects appear to disintegrate in various ways, others could show the object having an electrocution effect and have it burn away – even more complex transitions that can make the objects appear to “melt”.

I’m very excited about Fusion 3’s transition system so far. Mostly because it hardly required any extra work on our part to bring so much more power and creativity in the hands of our users.

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!



Collisions in Fusion 3

Posted on: January 23, 2017
Today I want to talk a bit about the collision system in Fusion 3.

Collision detection is very important in many games and we want to keep it as simple and intuitive as it has been in previous titles.On of the major differences between Clickteam Fusion and other game engines is how short there is from intent to implementation. In other engines you typically have to manually set up event handlers, callbacks or other methods or possibly even loop through all instances yourself to check for collisions. In Fusion and earlier products you only had to define the event…

If [SomeObject] collides with [AnotherObject]
—> [SomeObject]: Bounce

The KnP/TGF/CnC/Fusion engine then automatically knows your intention and handles everything for you. The game engine knows the context of all that is needed in this example. For example from “SomeObject”’s point of view the “Bounce” action means bounce off of whatever it just collided with. In this case it is “AnotherObject” and the engine can from the collision detection system figure out the resulting new angle for “SomeObject” to travel in after the bounce. High level programming, like what you do in Clickteam products, is all about getting your intention down into code that works like you expect it to do – but not limit your options when you want something different to happen.

The collision system in Fusion 3 will not be much different to what you are already used to. We will however do a lot of interesting things behind the scenes to make the system even better.

Limitations in Fusion 2.5

To use the Fusion 2.5 collision system properly you had to use some sort of movement. Without them you sometimes had to manually implement your own collision detection systems.

Always setting X,Y positions on your objects to move them would not generate the “On collision” events properly. Even when they fired the collision system would have no idea how to handle any “bounce” actions or similar. Always setting an object position is to the collision system the same as the object being completely still but always teleporting a tiny amount. It would not see this as a physical “momentum”.

To overcome this, many users used the Ball movement and controlled it’s speed and direction carefully. Some also completely ditched the Fusion collision system and only relying on the “Object is overlapping” conditions and extensions like “Move Safely” to manually move objects.

To those who don’t know the “Move Safely” extension it is an object that you can ask to move an object towards a given position. It would then in small incremental steps move the object a little bit of the way and ask the runtime for collisions. If the object was in a “forbidden” zone (like overlapping some terrain, or object it should collide with) it would carefully move a bit backwards until no longer overlapping. All this would happen nearly instantly and the end result would be the object appearing to use a very fine collision detection system. It was a clever use of callbacks and and some aspects of the Fusion collision system.

It was however slightly confusing to new users, required you to set up callback events to tell the extension when a collision was happening or not. Furthermore you would not be able to use actions like “Bounce” since the collision system never saw an actual collision itself and it would have no idea which direction to move the object in afterwards.

We want to do better.

The Fusion 3 collision system

We wanted the ability to make use of the easy to use collision system even when not using a movement. So how can you move an object some distance and have collisions be tested for along the way to the new destination? In Fusion 3 we are introducing a new action called “Move to” that at first hand looks like and works a lot like the “Set position” action. It will however work a bit like the “Move safely” object in the sense that the object might be stopped “underway” to the destination if your “On collision”-events have stopped the object.

With the “Move to” action you can make your own Ball Movement replacement in a few lines of events while still taking full advantage of the fast collision system in Fusion 3. In fact the default movements in Fusion 3 are all using this “Move to” internally. Eventually you can code your own movements and share them with your friends and they can use the movement like if it was an inbuilt movement.

From the technical side – behind the scenes

In Fusion 3 we use an acceleration data structure called an Axis Aligned Bounding Box tree (AABB-tree for short) to make your games all nice and fast. The AABB tree allows us to “split up” the world into logical pieces when we perform the collision detection so that we don’t have to test for collisions on all pairs of objects. If we didn’t do that your games would run incredibly slow. If you had 1.000 objects in your game (not entirely unrealistic) and all objects could potentially collide, then a “naive” collision system would have to test 499.500 pairs of objects for collision. Why so many pairs? It can best be described as the “Handshake” problem. If there are two people in a room then in order for all of them to greet each other then only one handshake would be required. If there are 3 people then you need 3 handshakes, 4 people = 6 handshakes, 5 people = 10 handshakes. I got the exact number from the equation: n(n-1)/2

Obviously we do not want that amount of testing to happen all the time in your games. Instead we have to be smart about which objects could potentially collide. If two objects are far apart and don’t move much then we don’t even need to test them at all. The good old rule of thumb for performance sound a bit like:

“It’s not how fast you can do some work, it’s how fast you can avoid doing unnecessary work”.

One obvious observation is that if no objects moved then no collision detection is even needed. As a consequence of this we can also only iterate objects that actually moved when we need to test for collisions. This means we can in our “outer loop” ignore iterating the static objects like walls. For all the iterated objects we can then ask the AABB tree which objects are nearby and then iterate those in the inner loop to test for collisions.

The AABB tree works by asking it for the closest node that fully contains a given rectangle or circle.

In the example image we use the bounding circle of the bounding box of the object. In practice one can take a much more snug fitting bounding circle but that requires doing a little bit of image analysis to find the best fitting bounding circle for that particular image/object.

The part where we ask the AABB-tree for the nearby objects is the key to the performance of the collision system. It allows us to ignore all the objects that aren’t relevant.

Fast moving objects

Even now we have a lot of potential objects to test for collisions with. To make matters worse we have to take care of a typical problem in collision systems: fast moving objects.

As you might know most game engines are only updated around 60 times per second. Moving objects might not move far between each frame when the speed is low, but if you are factoring in incredibly fast moving bullets then they might “skip” over entire walls or objects between frames. This is not acceptable and we have to find a solution.

Many game engines use sub-stepping which breaks the collision routines into even finer steps so you might end up doing up to around 500 collision detection steps per second to find those collisions that might have been missed for the fast moving objects. When you have many objects this will also become a performance bottleneck. In Fusion 3 we are using a different approach that again draws back to the quote from earlier “it’s how fast you can avoid doing unnecessary work”.

To ensure that no object is skipped we make the AABB-tree look at a larger area that covers the entire area the object moved from and to. We call this area the “broadphase”. This gives us a larger list of potential objects to look at in the collision detection algorithm but it gives us the security of not missing any objects. It is still better than many-doubling our workload and not even getting guarantees for accurate collisions.

In the GIF you can see the broadphase as the trailing blue circle.

From our inner collision detection loop we have now reduced the problem to only looking at a pair of objects. Are those two objects even colliding? We only know that they might since they are near each other and at least one of them moved. Doing fine and accurate collision detection between only two objects is still a big task and can be slow. Looping over all the pixels in two sprites to find one pixel that overlaps is not very fast. Once again we will attempt to avoid doing unnecessary work by not even getting to that point.

Fusion 3 then does a series of simple tests to weed out the cases where objects aren’t colliding and it’s quick to determine so. Since both objects can potentially be moving very very fast we can’t simply test if their bounding boxes overlap each other. We need a way to test if they might overlap that takes time into account. In Fusion 3 we implemented a fast quadratic solver that very quickly can determine if the two moving objects will collide along the way and return the first possible time of impact. If the solver sees that they will not collide then the pair can be discarded and we move on in the collision system. If it however sees that there is a potential collision we can perform more precise substepping as needed.

In this GIF the resulting collision surface normal can be seen pointing out from the collided surface.

Collision systems are hard to do properly and I can’t get fully into all the details that we have put into ours. There are many edge-cases and other performance optimizations that are simply too boring to write and read about for these blog posts.

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!



More on Data Types

Posted on: January 16, 2017
James here, Anders is taking the week off from blogging, allowing me to slip in and talk a bit more about data types!

In a previous blog Anders talked about our plans for data types. But I thought it might be worth a bit more time to go a little deeper into what we plan for this critical part of our work. In Fusion 3, we really wanted to bring the power of “real” programming into the event editor. We decided early in the project that one of the first things we needed to address to make this possible was to implement a real type system. What do we mean by a type system? Well, Fusion 2.5 only really has three types in expressions:

* Strings
* Integers
* Floats

There are special casing exceptions to this where functions need to accept more complicated types of parameters. In Fusion 2.5, actions and conditions can create custom parameter types, like the direction picker that appears when you call the “Set direction” action. Arguably, objects in the frame themselves in Fusion 2.5 are also types, and can be passed as object parameters.

To simplify all of this in Fusion 3, we have remodelled the type system to work more like object oriented programming languages. In Fusion 3, everything is a class, whether it’s String, Integer, BallMovement, or FlyingSaucer. These classes can derive from each other, so for example:

* FrameObject is a class that has properties for a position and size
* Sprite is a class _derived_ from FrameObject that adds further properties to handle animations
* When you insert a Sprite into your application, yet another subclass “Sprite1” is created, allowing you to add your own properties and events.

Let’s say we had two objects in our game: a FlyingSaucer, and an Alien. The inheritance chain for these objects is:

FrameObject -> Sprite -> FlyingSaucer
FrameObject -> Sprite -> Alien

Both of these objects behave like enemies in our game: that is, when we shoot them, they die and we gain points. In Fusion 2.5 this might have been accomplished by adding an “enemy” qualifier to both objects, and adding events specific to that qualifier. In Fusion 3, it’s possible to implement this in a manner much closer to “real” programming languages, using inheritance:

FrameObject -> Sprite -> Enemy -> FlyingSaucer
FrameObject -> Sprite -> Enemy -> Alien

Now, simply adding events to the “Enemy” class will affect the behaviour of both FlyingSaucer and Alien. Similarly, if Clickteam were to update the Sprite object, your derived Enemy class and any further subclasses would automatically inherit the updates in exactly the same way.

Primitive Types

In Fusion 3, even the primitive types like String and Integer are classes that can have their own actions, conditions and expressions. In Fusion 2.5, strings themselves had no functions: instead, they had to be passed to another function to be processed (much like C):

Mid$(“hello”, 1, 2)

In Fusion 3, because even primitive types are classes, they now contain their own functions (more like JavaScript):

“hello”.substr(0, 2)

Types can be combined in an expression. For example, the string “split” function returns an Array: a type which doesn’t exist in Fusion 2.5. The get function from Array can then be applied to retrieve one of the elements:

“one two three”.split().get(1)

# Type Coersion

In Fusion 2.5, it was necessary to explicitly convert between numeric and string types:


In Fusion 3, this conversion is automatic. However, unlike weakly typed languages such as JavaScript or Python, type conversion cannot fail at runtime: for example, you cannot even attempt to pass a Bitmap to a function that reverses a string. This is because Fusion 3 is a strictly typed language with type coersion, which means that all type conversion is checked before build and then compiled into explicit conversions.

This arguably gives us the best of both worlds: explicit type conversion is not necessary for common tasks such as converting an int to a string, but there is no possibility of a “incorrect type” exception being thrown at runtime. We also gain a performance boost by using strict types, in that the generated code never needs to store or check types at runtime.

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!



Welcome to 2017

Posted on: January 9, 2017
Hi everybody and welcome to the Fusion 3 blog posts 2017 version! We hope everyone transitioned from 2016 to 2017 safely. With new year celebrations out of our system Clickteam is getting back to work bring Fusion 3 to life. Most of our previous blog posts have been mostly technical and describe new features in Fusion3. To kick off the new year this week I want to talk a little bit about how Fusion 3 is made differently than it’s predecessors.

As mentioned previously Fusion 3 is a cross-platform project which means that it has to work on many different platforms flawlessly. This means that we both have to develop and use Fusion 3 on those platforms that we target. A computer isn’t just a computer, for instance for macOS we have to test it on a Mac but for Windows of course we have to test it on a PC.

We all have our own favorite operating system. I have been a Windows user for many years now and have been developing for it for almost as long. Over the years I’ve started to like how polished macOS’s development tools are though. I get a simple to-the-point UI in XCode along with some pretty powerful debugging and profiling tools.

While I know and use command line tools I’m more of a GUI / IDE guy, James is the command-line-wiz. His development setup on Linux (and macOS) with vim (a very complex and powerful text/code editor). Watching him code will leave most people flabbergasted.

On a day-to-day basis the team writes and commits code into our source control system. From there all changes we do are quickly propagated out to all our development computers and can be tested seconds after they have been pushed to the repository.

This is my (Anders’) home office setup. Here I can test on both systems side-by-side. You might wonder why I have a freezer next to my desk.

1) Space constraints in the kitchen.
2) I needed an extra table for random stuff.
3) I’m addicted to ice cubes.

Hopefully next blog post we can get James to share what exactly his working environment looks like as well.

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!



The Art of Strings

Posted on: December 19, 2016
Text is everywhere. You’ll find text in almost all games and applications in some way or another, some of them using loads of it and others using a lot less. No matter what, text is one of our most powerful ways of communicating information to another person.

Another look back

In Fusion 2.5 you had a very limited set of options for displaying text if you didn’t “bake” text into your images. The good old String object could do the basics such as drawing a using a font, size and color but not much more. Alternative options such as “Text Blitter”, “Character image object” and “Graphic Font object” were created so you could use your own hand-drawn glyphs in your games with various effects.

For the windows runtime you also had the “Rich Text” object that allowed you to mark up your text like you wanted to (like in Word) but it was unfortunately too difficult to port to the other runtimes and wasn’t well suited for games.

Font sizes like “24pt” aren’t very intuitive and didn’t make much sense in a game world (as opposed to printed media). How big would the text be in the game? How big should my font size be for my text to fully cover a certain area? What about on other platforms with different fonts that are sized differently?

A technical challenge

Getting text “right” is a massive task and for Fusion 3 we wanted to get it right (or as close as humanly possible).

We wanted to make a better solution that would fit most needs.

3 added several new challenges for text drawing:

-Resolution independence (no more 1 pixel = 1 unit)
-You can see the text at any zoom level and it must look crisp and clear – even heavily magnified.
-Small fonts must not look blurry
-Embedding custom regions into the text for drawing custom objects such as symbols/emojis.

Drawing text in any kind of size and shape while looking good and being fast is hard. We decided on a hybrid solution between good old crisp text drawing in a bitmap and a more modern OpenGL accelerated approach that looks good at big magnifications.

Text is mostly vectorial in nature and vectors scale very nice to nearly all resolutions. Why not all resolutions? More on that later.

Vectors are however really difficult to render in a game in realtime without serious performance problems. We settled with a really interesting approach to single-color vector drawing in OpenGL called “Multichannel Signed Distance Field” maps. We found and modified an algorithm to suit out needs to perform really well within Fusion 3.

From the glyph we want to draw we extract the vectorial shape, draw it into a good old bitmap using a special algorithm. Exploiting several color channels to store information in we can store the glyph images at low resolution. When rendered to the screen using a special pixel shader we can get crisp and sharp shapes without the drawbacks of bad filtering or unintentionally rounded edges that normal Signed Distance Field algorithms typically suffer from. The result is low memory footprint for our drawn text while looking sharp at most resolutions.


“Excuse the bad GIF compression. Our screen recording software downsamples the images while also losing a lot of color information. It looks much more crisp and nice in real life.”

The limitations of vectors

While vector graphics are often seen as the ultimate resolution-independent image format it does have some drawbacks – mainly at small sizes.At small sizes drawing vector images often tend to become blurry and loose visual fidelity as long as you draw the text unmodified. The reason for this is that the vector edges end up at floating point coordinates and the rasterizer (the drawing system) then have to spread out the line into several pixels on screen. Lucky for us this is a solved problem in one of the most popular font loading libraries out there: FreeType2.

It specializes in drawing vectorial text at small pixel resolutions by “snapping” the vector shapes to the pixel grid – slightly modifying the overall shape of the character but in such a way that it becomes a lot more readable. We exploit this at small font sizes on the screen so you get the best of both worlds. Super crisp font rendering at small sizes while having slick looking huge fonts with no slowdown.

Attributed texts – Rich Text within any string.

So besides the (maybe) boring description of hybrid font rendering I wanted to throw in a bit of fun images for this blog post. It is nearly christmas after all.


This image shows our Attributed String. It allows you to set any font attributes on any range within the string itself. Here I set up a little christmas’y light show by setting the font colors in a sine wave. The text can also mix fonts and sizes within the same string.


Here I made some text do a little christmas boogie. Our text alignment is not limited to “Left”, “Center”, and “Right” or “Top”, “Middle” and “Bottom”. It can be any value in between. The in-between values might not be very often used but it might prove useful in some animations.

Icons and emojis

Our underlying text layouting technique also supports custom elements inserted into the text. We still haven’t decided how to expose this functionality to you as the user yet. In Fusion 3 itself we for example use this feature to draw icons within the event editor.


The two object icons are simply images. The “SPACE” icon is actually a Nine-slice image rendered with dynamic text on top. As you can imagine this could be used for drawing emoji’s and other game-related icons directly in your games’ text. I’m imagining this could get used a lot in RPG-style dialogs.

Other types of text features

In this blog post I haven’t covered other types of text such as bitmap texts. That will be in another blog post.

See you on Jan 9th 2017 for our next Blog post, Happy holidays and have a good new year!

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!



Evolution of Backdrop

Posted on: December 13, 2016
Since Fusion 3 is a complete rewrite we have the rare luxury giving our “old” objects a complete overhaul. The core objects of the Fusion line hasn’t changed much over the years because each of them had a pretty well defined purpose and use case. This doesn’t mean that we can’t improve on them however. For instance let’s look at the Backdrop and Quick Backdrop objects…

Backdrop & Quick Backdrop:

In Fusion 2.5 and previous versions the backdrop object(s) have always been quite similar in functionality; they sit behind everything on the layer they are on. They are simple in nature. Act as the background behind other things that are more interesting. However having two separate objects for this seemed to us a bit confusing as their functionality is almost the same.


We will in Fusion 3 be merging the Backdrop and Quick Backdrop object into one “Backdrop” object that covers both their previous use cases and adds more to it.

Along with the usual modes you will find a new “Nine-slice” method which I think will get quite popular. “Nine-slice” is a method where you can use 9 individual “slices” of an image to draw an object of any size where the borders doesn’t scale. Think the borders of buttons.


Since we can already draw buttons in your games why not give you the ability to use our button-drawing functionality for all sorts of other things than just buttons? First game-related thing that pops into my mind is Mario-esque blocky backgrounds.

Objects even of the same type can in Fusion 3 can have their own individual size and scale in the frame editor. This means that you can drastically reduce the amount of cloned objects you will be using.

A lot of our users also expressed interest in being able to change some of the backdrops at runtime – for example changing their colors, gradients or images. This was not possible in Fusion 2.5 because the backdrops were handled differently and weren’t even visible in the event editor.

For Fusion 3 the backdrops will also by default not show up in the event editor but you can change that with a setting for that object.

This means that you can now change all that in the backdrop at runtime:


The inverse problem was also present though. Often you would have tonnes of non-backdrop objects, like strings, that were only for show and didn’t need any logic. With the same setting you can hide them from the event editor so they don’t clutter it up for you.

The backdrop objects aren’t the only objects getting a long look at. All the objects shipping with Fusion will get a good look at and we will see where we can do things better and simpler. For example there is the case of the good old system box objects. How many can explain the precise difference between the “Active System Box” and the “Background System Box” object? – other than the background one being in the.. background?

The background system box object was mainly an optimization when it comes to drawing performance in a software rendered environment. It utilized the “background saving” technique that traded extra memory usage for drawing performance as long as the object didn’t move or change appearance. With the introduction of hardware accelerated graphics the object got largely obsolete as it then just became a lesser-featured version of its “Active” counterpart.

Guess which object gets the cut? Well more next week!

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!



Version Control and More

Posted on: December 5, 2016
Today’s blog post is a bit more geeky and behind-the-scenes.

One of the things we wanted to fix with Fusion 3 is how your games and applications are saved on disk while you’re working on them. Fusion 2.5 uses a “MFA” file, which is a binary file format and only readable by Fusion 2.5 itself. This makes it difficult to use things like version control to track changes to your project, or to manage assets and events in the filesystem.

In Fusion 3, we have moved to a completely JSON based approach. This means that you can look at the “source code” of your game or application in any text editor, check it into version control like GitHub, or even write your own tools to work with Fusion 3 projects. Additionally, all of the assets such as images and sounds in your game are saved into a folder along with your project JSON files, which allows you to quickly access your assets and edit them using your own tools.

Here’s a sneak peek of what the JSON file for a simple application looks like in the Fusion 3 alpha. See if you can guess the game…


Using JSON for almost anything

For those who do not know JSON fear not. You don’t have to write it, look at it or even know about it. It is simply a different way of storing data.

We chose JSON because of the simplicity of the format. Another candidate was XML which is another quite popular textual data storage format. We however felt that XML is not consistent enough for our tastes. For example you can in XML store your data either as a tag or as an attribute. In JSON there is only one way to store your data and it is, in our humble opinion, a lot more readable with less visual noise and more to the point than XML.

JSON often explained as a “subset” of the Javascript syntax which isn’t 100% accurate even though it is very close. You have 6 different “basic” ways to represent data in JSON (Strings, integers, floats, boolean, arrays and dictionaries)

With these simple data types we will store everything about your events, frames, objects, movements and more.

It might be surprising to some that almost anything can be serialized down into those few types.

For example the “Vec2f” type, which we use internally for all coordinates in Fusion 3, consist of two floats. One X and one Y coordinate. In memory they are tightly packed floats. In JSON they are simply serialized into something like:

{“x”: 102, “y”: 472}

As you can see we exploit JSON dictionaries to store multiple named variables. We can nest all of this into larger and more complex objects.

One thing that JSON isn’t good at is storing binary data. We instead store all your binary data files separately – such as images and sounds.

From JSON to native code

When you “compile” your game for other people to play you maybe don’t want your source to be publicly available for anyone to see. Fusion 3 will take all the JSON as input and spit out C++ code which will in turn be compiled into native code for your target platform. This means that there will be no JSON left to peek into. After the C++ compilation step you cannot go back to the JSON source in any way.

More on the C++ code generation in a future blog post!

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!




Posted on: November 28, 2016
What is a storyboard?

A storyboard is a way to figure out how a story progresses over time.

In Fusion 2.5 and previous the storyboard was a simple list of frames and didn’t give much indication on how frames were interconnected. They simply flowed from beginning to end like a movie. But games and applications aren’t movies. For Fusion 3 we are working on a better Storyboard for you that can give you a much better overview over how the flow is through your game/app’s frames.

The New Storyboard Editor

Apologies for the ugly “shopped” arrows in this picture and the lack of frame previews. They are being worked on!


We also want to show frame inheritance with another type of arrow in the future. It will be possible to hide these arrows though as the storyboard can easily become cluttered.

The Storyboard Editor is now simply an alternative view to the frame inheritance tree you see in the Workspace to the left. Frames can be dragged around by you to align them in a way that makes sense to you.Our aim is to draw automatic arrows between the frames where you have a “Jump to frame” or “Next frame” actions to them. While a seemingly small change it will make organizing your frames much easier for big and complex projects – especially for huge adventure games where you can now lay out your frames the same way they are located in your game itself.

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!



Coordinate Systems

Posted on: November 21, 2016
In the 7th edition of the Fusion 3 development blog we will continue to discuss last weeks look at layers.

In the olden days

All the way back to Klik & Play, the “Click” series has only had one type of coordinate system – one that pretty much was 1 unit = 1 screen pixel (with the exception of intentionally retro-looking games with larger pixels). One object only ever had one [x,y] coordinate on the screen. This was simple and easy to understand for everyone. It was very limited though.

With the addition of layers things got a little more complex. There you have multiple “planes” (layers) of objects that could parallax scroll at different amounts depending on the scrolled position. To keep things simple in the case of parallax scrolling objects still only had one coordinate. If you did Always -> Set position of [object] to XMouse, YMouse then no matter which layer the object was on it would end up underneath the mouse. The coordinates were always interpreted as being some sort of “global” coordinate system.

While this was simple to understand it could complicate more complex games unnecessarily. If a layer scrolled with a parallax multiplier of something different than 1 then all objects in that layer would effectively change their coordinates as the screen scrolled. This meant that you could never store coordinates in alterable values and reuse them later for something as at that time the coordinates would have lost their meaning without doing some offset conversions.

Conversion between coordinate systems

As you saw in the previous blog post we will allow layers to exist in a hierarchy – even allowing objects to have sub-layers with no restrictions on the depth of this hierarchy. With this system then each layer manages it’s own private coordinate system. If you inside you’re own custom object position something at 0,0 then you expect it to be located at the top-left corner of the object no matter where you position the parent object in the frame. Each layer can also have it’s own scale, angle and “camera” position so suddenly the old system with only one coordinate system completely break apart.

As a consequence of this there will no longer *gasp* be a global XMouse, YMouse expression anymore! The one global mouse position you can get is in window-local-coordinates (which aren’t affected by the scrolled position). So how would you position an object underneath the mouse? Where do you get the mouse coordinates from then? Answer: From the layer! Every layer in your frame will now show up as any other object that you can get information from:


Or you can get it dynamically from whatever layer the object is currently on (in case your object type is on several different layers or is moved between them).


Or even chose to convert the window coordinates to the layer coordinates.


There are also expressions to easily convert coordinates between different layers. The action for moving an object between layers will have the option to convert all of this automatically so that you don’t have to worry about it.

Layer layout/display modes

The iOS runtime was the first runtime to get the notion of certain different display modes such as “Center”, “Adjust window size”, “Fit inside”, “Fit outside”, “Stretch to fill”. Instead of just being an option for the window those methods are now an integral part of how layers work. This is really useful for those of you who make your own objects with the layer hierarchy.

For example if you take our custom checkbox example again from last week:

If the checkbox object is originally sized to be 48×48 then the object’s content-size will be 48×48. Say you resize the object to 96×72 units, how will the object respond? Will it scale? Or just show more content if available? That is what the layout mode is for and is handled completely automatic for you.


An UI control like this custom checkbox might use the “Fit inside” option as the default. Some UI controls like a scrollable view would just use the “Expand” mode to show more content within the object. (- Yes, you can even make your own scrollable views if you want. It is just a layer that clips it’s content to the object size.)

As you can see, with all these new layer features it is quite useful to be able to convert between coordinates in all sorts of different layers. All of this is behind the scenes simply turned into a single “matrix” which are super fast to use for both drawing and coordinate conversion so it is very performant at runtime.

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!




Posted on: November 14, 2016
This time I’m going to talk about layers. Some notion of layers are used in all games. Usually you have a “game” layer and some sort of user interface layer that always exist on top of the rest of the world. Sometimes you have a background layer for distant objects or other effects.

Layers themselves are usually not that interesting. They usually just contain objects and not much more. Layers in Fusion 2.5 is an ordered list sorted from top to bottom. Each layer can contain a large number of objects and can on Windows have it’s own effect that applies to everything. Each layer can also be scrolled to a given position but usually just follows the global scrolled position.

So why a dedicated blog post on layers for Fusion3? Because they will change drastically to make your life so much easier in many ways that might not be immediately obvious.

Fusion3 differs quite a bit from all of this on several key areas:

  • – Hierarchy, in both layers and objects
  • – Private coordinate system
  • – Layout mechanisms (expand to parent, fit inside, fit outside, stretch, ect. ect.)
  • – Certain automated object layout systems
  • I can’t fit all of these topics into one blog post so I’m going to split this one up.

    Layer tree

    You might notice a trend in these blog posts when it comes to revisiting old features; lists of things are typically turned into trees/hierarchies. The layer system is no exception.

    Layers will in Fusion3 be a tree of layers in the sense that each layer can have a list of sub-layers. And those layers can have sub-layers as well. This allows you to do complex combinations of effects if so desired. Having the layers as a tree is actually a relatively simple change. It is not here the true power of the new Layer system lies though.

    Object sub-layers

    We have previously talked about how you can make your own custom objects that are a combination of other objects. So how will you organize all those objects that your object is made out of? In a layer of course! But what layer? Answer: In your object’s sub-layer.

    Any object in Fusion3 can have an optional sub-layer. In that sublayer you can place any objects you might want to. So if you see the complete hierarchy of objects in a Fusion3 app/game you will see layers and objects interwoven in logical ways.

    Say you want to create a custom animated checkbox object with a background image and a checkmark sprite your object hierarchy would look like this:

  • Your “base” object
  • -Checkmark sprite
  • -Background sprite
  • The “base” object can be any type of object of your choosing. Usually you would pick a Sprite/Active object but you can also chose the parent type “FrameObject” which is an empty object that does nothing. In your object’s custom events you can check for when the object gets clicked and then animate the state of the checkbox. You can also extend on other existing types. In Fusion3 the layers will be an integral part of how objects are managed and are not only limited to something you find in a “Frame”.

    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!



    Child Events

    Posted on: November 7, 2016
    Hi everybody, welcome to the fifth edition of the Fusion3 development blog. Today we’re going to show you a long overdue feature that will finally be available in Fusion 3. It’s a feature that was originally discussed many years ago back in the private beta days of Multimedia Fusion 2. It was always planned to be added at some point. Changing MMF2 to allow for this turned out to be too big a task for the time constraints at the time. It turned out a major rewrite of the underlying codebase was needed.

    So it was postponed – until now…

    So what is this feature?

    Every so often you come across some logic that begs for finer control over both your events but also object selection. Often you want something to happen only when multiple criteria is met – but at the same time you wanted other things to happen when any of criteria was met.

    In Fusion 2.5 and older you would typically duplicate your events and specialize the events only after several conditions that are already identical across several other events. I remember seeing games made where the first 10-20 event lines started with “Start of frame” conditions and then followed by the specialization.

    Imagine if you could just make that “Start of frame” event once and then specialize under it?

    Child Events

    Fusion 3 is all about better code reuse and organization than ever before. In the image you can see how we nest several events into each other in a tree-like fashion.

    Any events that are nested below their parent event will *only* happen if the parent event passed all of its conditions (evaluated to “true”). For example the “[Truck] is stopped” event will only be evaluated if both “Space” is pressed AND only for trucks that are actually overlapping the “Grass” tile.

    Yes – object selection is inherited down the hierarchy of events. This is incredibly powerful and useful for any game or app. The inherited object selection means that you can make incredibly precise filters on exactly which objects you want to be affected by your actions in any situation.

    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!



    Expression Editor Syntax

    Posted on: October 31, 2016
    Hi everybody, welcome to the fourth edition of the Fusion3 development blog. As a continuation of last weeks talk about the new type system I thought it was appropriate to talk a little about our change to the expression editor syntax.

    A look back

    In Fusion2.5 and older we used the C-style function syntax:
    SomeProperty(“MyObject”, someParameter, someOtherParameter)
    Like X(“MyObject”), Left$(“SomeString”,5)

    While you might immediately recognize the above examples and know what they do, there are other examples where that might not be immediately clear.
    For example: something$(“SomethingElse”)

    Is this an expression that returns a string from the object [SomethingElse] or is it a global expression that does some manipulation on the string “SomethingElse”?

    It might be obvious to the user that made the code but other users reading had a hard time figuring out the meaning.

    It got even more convoluted when you wanted to chain the result of expressions together:

    It can be read as something along the way of, the “someExpression” of “anotherExpression” as a result of “moreExpressions” on “lastExpression”. While it is a valid and perfectly fine way of explaining it, it also requires you to remember the entire expression at once to get the meaning.

    New syntax

    As we have talked about before we are changing the expression syntax to be more “functional”. If you want to retrieve data from something you first type the name of that something and then what you want to get.

    Instead of Len(“SomeString”) you now type “SomeString”.length
    Instead of X(“MySprite”) you now type MySprite.x

    This has several benefits to you. You can chain expressions together easier and we can now show you intelligent code completion.


    In the above animation you can see how typing “ColorRGBA.” gives you a popup that show you available options for that type. “Yellow” is a convenient static property of “ColorRGBA” so we can select that one. We now have the yellow color which we can then access. You can see we have the ‘r’, ‘g’, ‘b’ and ‘a’ values available from it which are “float” components of the color.

    Now we can chain the expressions even further by getting another color from our yellow color. The expression “withAlpha” simply returns a version of that color but with the alpha component replaced with the one we give it.

    To demonstrate the point about how easy it is to chain expressions together we go all the way and convert the color to a string and list some of the available string operations you can do.

    We have a lot of powerful functionality ready in our basic types that we haven’t made available to the editor yet. Stay tuned for more cool examples!

    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!



    Data Types

    Posted on: October 24, 2016

    In Fusion 2.5 you only had 2 types you could use – numbers and text. Well that is actually 3 types when the numbers could either be floating point or integer. What value (float or integer) type was stored depended on how you typed out your expressions. It’s amazing how much you can do with only those types really. All other types of data somehow was able to fit into either category. For example colors were stored into a single integer value and you had to extract the red,green and blue components from it using expressions like GetRed(myColor).

    Fusion 2.5 also had the notion of “flags” – a value that could either be on or off, 1 or 0. A boolean if you will. These were never really a “type” as such and was only exposed to you through the actions “Set flag on”/”Set flag off” and the condition “Flag is on”/”Flag is off” and could be given to you as an integer with the expression “Value of one of internal flags”. These flags were accessed through an index – not a name like the alterable values or strings.

    Can we do better?

    A new type of system…

    While the limited types in Fusion 2.5 worked fine in the past and has allowed for the creation of awesome games we still feel like all of this could use a major overhaul. Fusion 3 brings you a completely new type system. We will be adding a whole lot of new types that you can use so it makes your game even easier to make. Fusion 2.5 kept “alterable values” and “alterable strings” completely separate (as well as flags).


    Wouldn’t it be nice if you could store any type in your objects? Strings, values, floats, X,Y coordinates, colors, images, binary data, That is what we aim for now! Gone are the limits of only alterable values, alterable strings and flags. We now give you alterable ”anything”.

    See you next week! 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!



    Reuse of Events

    Posted on: October 17, 2016

    Hello again, check out our second post of our Fusion3 development blog. Today we want to talk about the hot button issue of code reuse. We think you will like what you see so far. Also we wanted to send out a thank you for the positive feedback on our first blog post.

    One of the features that you, our users, asked for the most is better reuse of events. We wanted to do better than simply copy-pasting frames full of events or making a mess out of global events. So how can you solve the problem of wanting to reuse as much of your events as you can while maintaining a clear structure?

    Enter the frame hierarchy…

    Typically you either event most of your gameplay in one frame and copy that across your other frames or put them in global events or similar. With the Fusion 3 frame hierarchy you can put all your usual gameplay code into one frame and have a whole set of “sub-frames” inherit all your objects and events from the “parent”-frame. You can then in the child-frames design your levels without having to do anything else.


    You can in your child-frames add even more objects and events if you wish. In the example above for the “Boss battles” frame we could have added a “Boss health bar” object and various events taking care of other boss-battle related things. This could easily be reused for all the other boss battles in the game so we put that into a frame for itself. Then inside the boss battle frames “First boss” and “Über boss” you would have all the events and objects available from both “Gameplay” and “Boss battles”. With this hierarchy your event structure will be so much simpler and easier to manage.

    This concludes our second blog post. 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!



    Welcome to the Fusion 3 Development Blog!

    Posted on: October 11, 2016

    We hope that this blog will give you a detailed look at some of the fantastic features of Fusion3 which it is not possible to show in a short video preview.

    Some of our users expressed some disappointment that we couldn’t show off more of Fusion3 during the livestream – particularly how we are trying to make it easier and faster for you guys to make games. Videos are great for showing off fancy flashy features but they do not give you much information about the thoughts behind what you are seeing.

    So in this first episode of our dev-blog, let’s start out small and have a look at a few more simple and less “flashy” improvements of Fusion3, but when combined, will improve your overall workflow.

    Object Snapping


    The “ancestors” of Fusion3 all had “Snap to grid” which mostly got the job done, but was a bit rigid in the sense that you always had to adjust the grid settings to fit your needs.

    Now in Fusion3 we have proper object-snapping. As you can see in the GIF, we draw guide-lines to show you which edges snaps to which. This feature, even though it’s simple, will greatly speed up designing levels for your games where objects need to align with each other.

    You can, of course, still use the good old grid function found in previous versions of Fusion.  So the ability to set a “snap to’s” starting X and Y positions and the amount of pixels you step through horizontally and vertically remains the same- allowing users to continue to place objects in the frame editor as you could with Fusion 2.5. We believe the combination of the two features provides Fusion3 developers maximum power for accurate object placement in the Frame editor.


    Duplicate dialog improvement:

    The duplicate dialog has always been there and has been perhaps the most boring dialog in Fusion.

    Our new editor makes it simple for us to add extra visualisations to aid us where needed – for example, a preview of where the objects will be created:


    Sure, improving on this dialog may be low hanging fruit – but when you think about it you may be left wondering “why didn’t we have this before?”.

    In the works:

    We have lots of ideas for improving small dialogs like this even more. It would be a piece of cake to add in certain degrees of randomization to either position, size, scale, angle, direction and so on.  With that kind of randomization you could almost generate the basis of an entire level for a game; either game tiles, or detail objects like dirt, grime or grass.

    The “Duplicate dialog”… Who would have thought… :-)

    Custom Actions/Conditions/Expressions:

    People using Click software had a tendency to evolve their own coding style – some of them quite creative. People exploited groups of code along with the “On group activation” event to simulate functions.

    Rarely do you find a feature that (even though somewhat simple to understand) can have such a huge impact on how you make your games:

    One of the features we’ve talked about in the past is the ability for you users to define custom Actions, Conditions and Expressions (ACE for short).  With this we are stepping closer to an actual Object Oriented Programming approach.

    In Fusion3 you can simply go to the “Custom ACE” tap of your object and add your new action definitions. (We are still busy hammering on the UI, please excuse it looking incomplete).  Clicking on the ‘Event editor’ icon to the right of the definition you get sent to a “private” event editor only for that ACE. In there you can set up the parameters that the ACE requires.

    After you have created your new ACE you will find it in your event editor ready to use!

      image01   image00  

    But wait, there’s more!

    Why would we limit this to objects only?

    You can add custom ACE’s to your Frames as well – AND your Application.

    This effectively replaces global events from Fusion 2.5.

    We will in the following blog posts show you how this can change how you organize your code in your games – and how to give them better looking names than “newAction1” :)

    This concludes our first blog post.

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