- Creation Tools
- Export Modules
- Other Products
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:
someExpression(anotherExpression$(moreExpressions(lastExpression$())))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.
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?
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!
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?
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!
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.
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.
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… :-)
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!
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!