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

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/