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."

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!