Would you recommend Clickteam Fusion? I hear a lot of negative things about it, and by the way you speak of it, it doesn't sound like you think super highly of it, either
I feel like I’ve probably talked about this before but I’m too lazy to go looking for the post so I’ll just re-write it.
My feelings about Clickteam Fusion are complicated. And, in truth, if you ask anyone who’s spent a long time with an engine like this – Unity, GameMaker, whatever – they probably have their own gripes. No game creation tool is perfect. They all have frustrating quirks and weird limitations.
And it’s hard to unpack exactly how I feel about Clickteam Fusion. I’ve been using some variant of this software since 1998, back when I knew it as “Corel Click & Create.”
I like it because I know it inside and out, backwards and frontwards. 20+ years of experience will do that. If I can think of a sprite-based game I want to make, chances are, I can get it done in Clickteam Fusion one way or another.
I also like its editor, for the most part. Some ease-of-use features have been lost over the years, like it’s not quite as fast to plop down large amounts of tiles as it used to be, but in terms of coding in it I understand things very easily.
The best thing about Clickteam Fusion is just how easy it is to identify object relations. All of your variables are stored inside of objects, and you can just click on an object in the code editor to see exactly where any of its attached variables are referenced.
So in the above screenshot, from a Sonic codebase called “Not So Simple Sonic Worlds,” I can click on the Player_MovementValues object, which contains all the variables involved with Sonic’s movement, and it’ll show me everywhere that information is referenced. Things like jump height, movement speed, gravity strength, all of it is attached to this object, and I can find it all quickly.
And it’s not just that, either, but the way it’s all laid out makes it feel more organized than normal code, too.
Each object is almost like a folder full of variables, and if you organize them as such, you’ll know exactly what’s being called in each line of code. Like I said, Player_MovementValues handles all of Sonic’s movement variables, so I know if that’s being referenced, it has something to do with that.
And one way or another, I find this much easier to read than “real” code. When dealing with older code I may have written months or even years ago, it makes it very easy to decipher what something does.
Some of that is due to just being extremely familiar with Clickteam Fusion. It’s comfortable.
But it also feels kind of like a trap, because code isn’t written like this in the real world. I’ve mentioned it a few times on this blog, but I did learn a little bit of BASIC back in the day, on my TI-82 calculator. I’ve written text-based games in mIRC scripting. And after two days of failing to get C++ to output a simple piece of text-based code reduced me to literal, actual tears, I retreated in to Clickteam Fusion and never looked back.
I “know” how to write real code and I could if I really wanted to, but the thing is that I don’t want to. So it’s a double edged sword: I can wield phenomenal power with Clickteam Fusion, but I feel kind of stuck to it.
And there are a lot of things Clickteam Fusion does wrong.
The top level problem is that it’s slow. The easiest example I can point to here is Freedom Planet. That game has the technical prowess of, say, a Playstation 1 or Sega Saturn game. And the original release on Steam had absolutely comical system requirements – you needed a modern, 3ghz+ processor to run it, and even then, levels would have framerate problems.
When it came time to do a console port of Freedom Planet, they hired the services of MP2, a guy who specializes in converting Clickteam Fusion projects over to C++. In doing so, the Steam version of Freedom Planet got something like a 500%-1000% performance boost. That game can practically run on a toaster nowadays. None of the game logic necessarily changed, it was just getting it out of Clickteam Fusion that helped speed things up so much.
Even mildly “complex” games are outrageous resource hogs. I’d heard that was because Clickteam Fusion rendered everything in software, meaning it was pegging your CPU even to draw graphics, but it had an update years and years ago for GPU-accelerated graphics and it’s still a problem. They’ve tried other things over the years to speed things up, but again, it’s still just embarrassingly slow if you plan on making a game that looks like it came out after 1994.
(And some things are slower than others, like they let you change palettes on sprites, but doing that is a sure-fire way to tank the framerate)
The second problem, and the one I find most frustrating, is object instancing. The example I always use is, like, Goombas in Mario, right. In most game coding, you’ll have a way to tell one Goomba apart from another Goomba, so you can make the game pay special attention to Goomba #3 in a group of ten.
Clickteam Fusion has trouble doing that. In practical terms, what this means is that if you have a group of ten Goombas, and three of them collide with a wall on the same frame, Clickteam Fusion has a hard time understanding which Goombas touched the wall and which ones aren’t touching a wall. It just knows “a Goomba somewhere touched the wall” and will report as such.
So if you’re writing, like, your own custom object physics, making Clickteam Fusion parse large groups of objects and see them as individuals is an uphill battle. Clickteam Fusion has tried to add more tools and features to help with this problem, but they feel more like temporary bandaids and most of them drag performance down even lower.
Which is tied to the third problem, which is that Clickteam Fusion largely still feels like the same software from 1998. Again, it’s very cozy and comfortable for me, but a lot of the fixes to the software’s longest standing problems feel more like temporary hacks and half-steps. The problems are still there, just reduced (or traded for other problems).
Like, Clickteam Fusion can’t do 3D. Over the years there have been several extensions that let you import polygonal graphics in to the engine, but they’ve always been slow and limited. Their best and latest effort is Firefly, but if you expect it to be competitive with Unity you’re fooling yourself.
All of this is leading up to the eventual release of Clickteam Fusion 3.0 at some point in the next few years, which will be a total top-to-bottom rewrite of everything. How it renders graphics will change, how you write code will change, everything will be different, and they claim every problem I just listed will be fixed.
Given that I like Clickteam Fusion for how cozy I am with it, the idea of everything changing like that is a bit scary to me. If it’s going to be so dramatically different, what’s stopping me from finally breaking it off and just learning Unity, you know? Or maybe I’ll just stick with Fusion 2.5.
Either way, it’s the sort of thing where I don’t think I’d recommend the current version of Clickteam Fusion to anyone else, but I won’t berate them for learning it, either. It is what it is. If you want to take on the curse, that’s up to you, but I’m not gonna suggest it.
