Tisnart Shapes

Tisnart Shapes delivers an exciting unique take on the familiar match game styles. There are many challenges for you to conquer, twists and turns that await you on each new level. Dice Blockers, Rivet shields, Rotators, Shape Shifters and more will be there to surprise you just when you think you know what to expect.
Fading Suns Noble Armada is a new fleet combat game set in the Fading Suns universe, featuring some of the same awesome gameplay found in the table-top version with new twists for the world of video games. Play one of five different houses, each with unique campaigns, as you attempt to assert dominance in any of the systems of the Known Worlds.
Outbuddies is a deeply crafted 16-bit style Metroidvania for Windows-PC and a story of teamwork and friendship between two very unlikely heroes. It was our natural desire to integrate a local Co-Op option, so you can explore, enjoy or even speedrun this game together.

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!



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…

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!

In Valiant Saga, live the experience of a kingdom in despair. An evil sorcerer has seized the legendary relic known as the Scepter of Desolation, which, according to legend, is able to grant the absolute darkest powers to the one who finds it.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!



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!



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!