Fusion 3’s Backbone

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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…

Crossfade

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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:

Str$(42)
Int(“42”)

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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.

textsize-optimized

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

textcolors-optimized

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.

textalign-optimized

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.

texticons

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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.

backdrop_1

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.

backdrop_2

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:

backdrop_3

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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…

json_out

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/

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!

storyboard

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!

https://twitter.com/Clickteam

https://www.facebook.com/clickteam/