Most wanted/least wanted in MMF3

I generally avoid behaviors just because my events are usually so intertwined that it makes it extremely hard to debug with my events scattered across different event editors. Would be cool if there was a way to temporarily view behaviors alongside your regular event editor, like a second pane or something. I mainly just stick things in groups and collapse/open them depending on what I want visible at once.

Quote

I generally avoid behaviors just because my events are usually so intertwined that it makes it extremely hard to debug with my events scattered across different event editors.

I only use Behaviours to things that only happens one time or things that are always the same in each frame or small things, all that.

Things that can be added in global events but i put on behaviours to not saturated the Global Events editor with objects and conditions/events that makes hard to see the important things.

Quote

Come to think of it, I don't think I've ever heard specifics on just what the issues with it are, exactly. So I honestly don't know what sort of issues can come up when doing that.

Huh.

Ok, I see .

So, somebody can say any bugs or similar about qualifiers in GLobal Events/Behaviours to test it using this trick?

Yeah I have used behaviors in the past for things like animations or movements. One time I had moving clouds that wrapped around the screen so I just stuck it in a behavior since there was no need to ever have that interact with anything.

It would be nice if with the CF3.0 we did not need to worry about multiple instances. For example, a checkbox like "This object has multiple instances" in object's properties. Okay, we have some methods to work around this problem, but this option can help us a lot.

+1 for easy multiple instances. I think that's one of the most frustrating things for newcomers and game development in fusion

+1 for easier multi instances as well.

Quote from LB

I think that falls into the realm of polish, and other features (such as sub-events) have a higher weight in my opinion.

I disagree. It's not about polish, it's about strengthening the foundations.

Bolting on new features before the old ones are properly resolved results in feature creep, which has been the downfall of countless products. And it sounds like this problem has affected Fusion over the years, which is why the developers seem so eager to do away with backwards compatibility so they can properly start afresh (a great decision IMO).

I love Fusion, I truly do, but it contains a lot of poor UI decisions (outdated, inconsistent, illogical, counter-intuitive and/or just half-baked). This makes the program much less efficient to use than it could be, and effects everyone (whether they're aware of it or not). I estimate that I probably lose a few hours each week in lost productivity because of Fusion's inherent interface friction. When you're making your living as in indie game dev, that kind of wastage hurts.

I can't think of any program where finalizing the UI was something done early in development, really (or, perhaps more accurately, I can't think of any program where that would have been viable, and I don't think I've heard of such a program where they actually did that first). It's something that should come later, in my opinion, but it what does need to be done is they need to code it so the interface can be changed without breaking too much that they can't change it later (E.G. Changing the interface wouldn't break much of anything, only breaking things that would be very easily fixed, and I honestly don't see how changing the interface code in a reasonably-coded program (not to call any programs where that actually is an issue not-reasonably-coded, though) could break much of anything (except for maybe minor things), really).

Quote

I love Fusion, I truly do, but it contains a lot of poor UI decisions (outdated, inconsistent, illogical, counter-intuitive and/or just half-baked). This makes the program much less efficient to use than it could be, and effects everyone (whether they're aware of it or not).

I'll second this, although in some ways Fusion does things better than other programming languages, which saves you time. Hence, you never really account for the time you save while it's painfully aware when you're wasting time, such as losing your place in the event list, which could easily be solved with a bookmark function.

The underlying problem though is that up until recently it seemed like Clickteam didn't actually develop using their own products to get an understanding of these efficiencies.

I got very little support from Clickteam when suggesting alpha-channel transparency should not be included in the physics collision boxes, however anyone building a game using physics & anything other than pixel art would encounter this problem. It seems clickteam just uses pixel art and never built a game with smooth-edge graphics, otherwise this problem would have stuck out like a sore thumb. I see recently Francios has been building small games with Fusion, and this is a great step! If all the developers spent time in the event editor, these inefficiency problems would be immediately apparent and fixed quite quickly, but unfortunately if you don't know you have a problem, you can't fix it.

Quote from happygreenfrog

I can't think of any program where finalizing the UI was something done early in development, really (or, perhaps more accurately, I can't think of any program where that would have been viable, and I don't think I've heard of such a program where they actually did that first). It's something that should come later, in my opinion, but it what does need to be done is they need to code it so the interface can be changed without breaking too much that they can't change it later (E.G. Changing the interface wouldn't break much of anything, only breaking things that would be very easily fixed, and I honestly don't see how changing the interface code in a reasonably-coded program (not to call any programs where that actually is an issue not-reasonably-coded, though) could break much of anything (except for maybe minor things), really).

Before I became an indie game dev, I was a professional interface/web designer for a number of years, and in my experience, the earlier design and programming start talking to each other, the better. (You wouldn't call an architect in only after the interior of the building is done, right?) Without design, the programmers are building a lot of their programming blind. They'll either have to redo a lot of their work once the design starts being properly considered, or else things will just be left half-baked. Or, perhaps even worse, they'll implement the designer's features by resorting to workarounds and hacks.

In my experience, the projects that turn out the worst are those where design was tacked on at the end (or programming was - I've experienced both). These are usually frustrating for the designer (because their design is implemented sloppily, with bugs, or not at all) the programmer (because the designer came in at the end with his big ideas and stomped all over the programmer's hard work), and the user (because they have a clunky product that wasn't built with their usage patterns properly considered).

But why are we talking about this anyway? The Fusion product is as old as the hills (yes, Fusion 3 is a big step, but they're not reinventing the wheel - I'm sure they'll evolve what is already there for the most part). Some of the UI problems I'm talking feel like they're remnants from the 90s incarnations. It's possible some of them were already due for a change before you were even born

Yes, but since Fusion 3 is being built from scratch, it's unlikely it will have an identical interface anyways. That, and CF2.5's interface manages to make MMF2's interface look a whole lot better, and, even though most of the changes are just in appearance (it functions the same), it's actually a pretty big step forwards in my opinion.

Also, the interface is different from the design. I can understand that they would want to know the design in advance, but no need to make a fully-polished interface first. One thing I've learned when making games is that the interface should probably not be in its final, fully-polished form early on, it should just be simple and get the job done. For example, there are probably some improvements I could make to War for Robovania's interface that I will probably make at some point, though that's nothing compared to what the interface for the game originally looked like when compared to how it looks now. Anyways, as you are developing the game, you can improve the interface as you come up with ideas for a better one, and keep coming up with improvements for it (and of course keeping on implementing said improvements). Now, I don't know how much that applies to application development, or how much it applies when using actual programming languages like C++ (though some videos I've seen of Bit Trip Runner 2's development make me think that it does apply to some extent), but I'd imagine that the code isn't that much harder to change when making applications.

I really think Fusion 3 should start using separate "event sheets" instead of a fixed list of events connected to each frame. With event sheets you could create logic for many different systems in separate sheets and then only use the ones you need in each specific frame.

Sireatalot- interesing you mention about event sheets, Contruct2 already has this and it works pretty good. You can include an event sheet for player enemy into a stage or level sheet. i would hope ctf 3 pulls something similar or better.

happygreenfrog: yeah, you make good points. Especially for new features or complex existing features, you're right.

In certain cases however, I'd like to see fusion 3 use more common Windows interface conventions than 2.5 does. Those are more tried and tested, and likely to be intuitive to most users. In these cases, nothing really needs to be invented per se, as the conventions are already there. But I imagine that the longer you build outside of these conventions, the harder they'll be to add back in.

But there are also several small UI problems that should be very easily fixable at any stage of development.

For example, when you drag an object from the top row of the event editor to another column, the cursor gets a "+" symbol, even though you're moving, not copying. Meanwhile, if you drag a green checkmark from one event to another, you don't get a "+", even though you're copying, not moving. This is misleading and just....wrong. These are bugs that should have been squashed with little effort long ago. But they continue to be ignored, which concerns me as it suggests that UI is way down on the list of priorities. If it continues to be so low, then Fusion 3 will probably always have these sorts of UI issues too.

Another example: the "ok" button is always highlighted in the animation editor (signalling that hitting enter will activate it), even in cases where enter will no longer actually activate it (eg. during/after editing the hotspot X field). Again, this is a misuse of a common Windows convention that shouldn't have happened, or should have easily been rectified when spotted. In this case, the "ok" highlight should dim while you're in the hotspot X field, but then when you press Enter to exit the hotspot X field, "OK" should be fully highlighted again, and enter should be able to activate "ok" again.

Some other issues I'd like to see improved are the unlabelled folders in the event editor, for navigation of the event group hierarchy to be more robust and intuitive, and for code in the expression editor to have a smarter and more intuitive layout (more like what you'd see in notepad++ for example: indents, open/close bracket pairs highlighted, etc.). And some way for dealing with hotspots and action points to be less painful. Some ideas:

-let us use Ctrl+numpadKeys to assign the 9 different directions without having to use the mouse
-give us the option to import graphics without altering the hotspots that are already present
-give us options to "create opposite directions" both with and without flipping hotspots.
-make it more immediately clear what the difference between hotspots and actions points is
-add a checkbox to the rotate tool area that lets us rotate with or without changing the hotspots
-fix the issue where editing a hotspot field prevents Enter from being able to activate "ok" until focus is manually changed with the mouse (mentioned above)
-give us a "chainlink" button or checkbox that locks hotspots to action points, so that any change we make to one automatically adjusts the other

Again, I want to stress that I think Fusion 2.5 is great. But like everything, it can be better. And in the case of UX, there are a few easy wins to be had, if only the Clickteam guys want to take them.

I'm pretty sure that Fusion 3 has a lot of (or at least a few) new people on board to work on it, such as James (ever wondered why Lacewing has been taking so long to get updated?), and you also have to consider that the people who would otherwise be working on those issues may be busy making sure Fusion 3 doesn't have those very issues to begin with, and that non-interface-related bugs can sometimes be more important, such as crashes or objects not behaving quite right, which is the sort of thing that Clickteam is fixing. Those are the reasons that I can guess for as to why Clickteam isn't fixing those issues, anyways...

Volnaiskra, please submit bug reports and feature requests in the Please login to see this link., thanks. We've fixed or implemented 1000+ bugs and requests in the bug box since the product has been in beta stage (and a large part after the release) and we'll continue doing it.

BUT you have to know that (1) there are thousands of users with their own different requests, (2) we also have to develop F3 at the same time we can't put everyone on the improvement of 2.5, (3) making changes in such a huge product that is used by tons of users is difficult, as there is a huge risk of breaking things even with a simple change. The number of new features or fixes we can implement in the product is limited by these constraints, so you can't expect the features you wish will be implemented either quickly or at all.

PS: the issue with the highlighted OK button you are talking about sounds easy to fix for a non-developer but in a complex dialog box like the Animation editor it can take a day to a developer to fix it. You always have to weigh the cost of a fix.

That's exactly why I've posted about these issues in this thread. I understand that fixing issues in a program with such a long history as MMF/F2.5 is tricky (though you're probably right that I've underestimated the difficulty sometimes, like the OK button). My hope is that since you're building Fusion 3 largely from scratch, a lot of these sorts of issues can be thought about from the beginning, and addressed before the code base becomes too tangled.

Though it does require that at least one person on the core development team is taking UX very seriously from day one. I hope this is the case, though I know from having worked with many programmers in the past that unfortunately UX isn't always on their radar by default.

Even though I'm building my game in 2.5, I'd personally be happy for you to ignore these UI issues in 2.5, if it means that you have more time to concentrate on making 3.0 as good as it can be. If 3.0 is as good as many of us hope it will be, and happens to be released before my game is complete, I will gladly buy it and port my game over to it, even if I have to do it manually

In a design-oriented package such as Fusion I think UI should not be underestimated. First impressions are the only thing that matters these days Consciously or not a smooth UI enables users to experience a far more productive workflow. I really think no matter how technically advanced or sloppy the programming, UI can make or break a product.

+1 intuitive UI in Fusion 3.

edit: I posted a bugbox request a while back for the event list editor to open at your current position in the event editor. Right now it scrolls to a random position or displays nothing until I scroll up.

I dont know if this was said in the previous messages, but, a nice thing would be import animations directly from animation software like Spine or Toon Boom Harmony.
I believe that would make animations lighter wouldn't be?
And of course be able to export to PS4 and Xbox ONE!!!!