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

Version Control and More

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!