Does backwards compatibility matter to you?

Quote

games are generally something you finish in one go and then don't touch again, and the developer is unlikely to switch tools midway through

Considering that point, isn’t it more logical to not include backward compatibility since the developer isn't likely to switch tools mid-production? They'd finish it with their current tool before using a new one.

Quote from MuddyMole

Having said that, what reason is there *not* to include backwards compatibility?
I hear people talking about how it would limit the extent to which Clickteam could make MMF3 different from (better than) MMF2 - but I haven't actually heard of one single feature that would break backwards compatibility.
I also don't buy the argument of backwards compatibility inevitably being very buggy - MMF2 does a good job of it

You haven't heard of any features because it's all speculation. If we had confirmed features about MMF3, then this conversation would change. We don't know exactly what would break compatibility, but based on a history of any software going through major upgrades/remodeling; we can determine that something isn't going to remain intact. Flash is a great example. Action Script 3 breaks Action Script 2 since in AS3, code is not embedded in objects since AS3 provides a more optimized method for dealing with code. (Basically like behaviors in MMF2) This breaks compatibility at the expense of greater features.

Perhaps the coding in MMF3's object selection will be improved upon but would break MMF2's method. Maybe a new type of parent/child concept will replace qualifiers, breaking any event associated with those. Events may possibly use an externalized sheet system instead of remaining static in the project. Due to the underlining of how MMF2 is coded, perhaps these features are non-existent unless you break compatibility with MMF2.

If MMF3 can manage backwards compatibility while including new features users want, then everybody wins. I can make a more solid judgment once I know exactly what’s planned for MMF3.

Quote from Danny

I'm interested to know how you reached that conclusion? Myself aswell as many others develop mainstream and commercial applications successfully using MMF2 and have done for a few years. There are rarely any posts regarding problems with app development because there aren't any...

I did not want to say that MMF2 can not produce good applications and that nobody are making some with MMF2. I am also making applications with it, for example rapid prototyping for GUI to show demos of future implementation. But you said it well, there is almost no posts about applications programming (new creation, concept questions, ...) on the forum and if I show on the clickteam website, almost everything is game oriented (trailer, examples, clickdisc). I would be glad to see more application oriented features but I can not blame Clickteam to choose to implement at the first time more game oriented features in MMF3.

Back to the subject, no backward compatibility is ok for a private use but if more than one person is using the tool in a company, it is painful and can banish this tool from development process.

To me It's not so much that backwards compatibility would break mmf3 or make it buggy, its more that it would hinder its evolution. I want mm3 to change and drastically improve the core systems like animation, events, alterable and global values, etc (some nice posts about this earlier).

I want clickteam to look at everything and come up with great features without being limited and keeping things similar to how they used to be in mmf2. If there's a better, smarter or more efficient way of doing things that will give users more power to create really nice games, then thats the way to go!

MMF3 should be as generic as possible but come by default with mostly platform-independent game-related plugins. The community can develop any kind of plugin it wants, including plugins for OS-specific controls and other application-related things. MMF3 itself should have no focus on games or applications in specific.

The things made in MMF2 can be finished in MMF2. So, just make MMF3 good.

Backwards compatibility is a MUST now for future MMF releases. Not specifically for MMF made games/application software for general release on PC, but for the commercial markets it has now ventured into. If MMF 3 arrived tomorrow with no backward compatibility for MMF 2 projects, then all MMF 2 created iOS App's/Android App's/XNA App's/etc., on the App Stores would not be able to be updated in MMF 3 and App developers who have developed App's in MMF 2 would need to keep a copy of MMF 2 on their machines. We all know that MMF 1.5 is not very comfortable on modern OS's so eventually MMF 2 would meet the same fate and with it, any App's being restricted to MMF 2 would no longer be able to be updated/worked on/etc. Backwards compatibility is no longer just an issue for general PC software releases, it now plays a part in commerical software ventures too.

Why would they need to keep a copy of MMF2 on their machine for people to download their app/game and use/play it? Any bugs should have been fixed already with the coming release of MMF3 in mind and everything planned in advance. If you're careless and you wake up one day to find out you've been using outdated software for years, you're probably not supposed to be developing anything in the first place...

I just don't think there is any need for MMF3 to support old MMF2 files. Everything dies or gets reborn (rewritten) eventually, it'd be insane to plan with the optimism that everything you have working now will work forever.

Since I've written 2 runtimes for MMF2 now, I think I can elaborate on the issue.

Objectively, the MMF2 runtimes are a mess. It's clear that backwards-compatibility has really been a counter-intuitive decision, and some of the code dates back to the KnP ages. The native movements are, to put it mildly, rubbish, since backwards-compatibility has been a priority, leading to bugs and quirks of the previous generations. It's extremely silly how native features, movements and objects are useless, and how you have to use extensions to fix/add features that should've been there in the first place (Select object, ForEach, Platform movement object, etc). Object selection is a mess, and even though it does make a tiny sense in the code, it's not clear to the user why objects are selected and iterated in the way they are. Extension development isn't fun either, and the outdated API for events, object selection and qualifiers is just depressing. I think it's safe to say that keeping backwards-compatibility for another generation would be a fatal decision for the future of MMF, not only for the users who may see Construct/Unity as a better option, but also for CT themselves as they try to fix and refactor something that's inherently broken.

Subjectively, I would like to see MMF3 as a new product. They should try and be more like Unity and Construct, but still keeping the simplicity of the object, frame and events editor. It does need more advanced features too, like hierarchies, event sheets and so forth, since otherwise, it will not be appealing to anyone who wants to do any serious work with it. That's how MMF can (re)gain ground, and seeing as MMF's largest competitor, Construct, is currently failing with its HTML5 approach, there is still time left for MMF to flourish into a great product. That is, if CT has the ambition and willingness to try something new, and let go of its KnP quirks.

In terms of applications vs. games, I think it's fair to say the latter is of most importance. The one doesn't exclude the other though; you can still render GUI regardless of the graphics API, so it's really a pointless discussion.

Thank you Mathias, for exactly explaining perfectly what I mean and what I agree with.

Backward compatibility has nothing to do with technical issues. All the reasons that Mathias mentioned (and there are more) are good reasons to change totally the architecture of MMF. But it is not the only reason that should be taken into account. Its current customer population should also be considered. Fortunately, Clickteam has no big game developer studios or companies as customer and they can afford to abandon old design. But they already need to think at the evolution of MMF3. All the best I wish for MMF3 is that not only single persons are using it but also bigger structures, and this for a long term use.

For example, try to convince your manager that you need to write again all the software or firmware on production machines because there are design flaws on the development tools. It would mean to write again all of the software on the production lines, train with more effort the developers with the new tool (even if it is easier to use), perhaps organize differently the upgrade on machines. You have almost no chance.

Good points Mathias, agree to 100%

conceptgame: What does that have to do with a new version of software coming out that is optional to use or not use and doesn't affect you using the older software?

It affects mainly the company which wants to sell the new version. Selling a new version of a software to new customers is more difficult than convincing current customers to upgrade. If they have the guaranty of backward compatibility, the chance that they switch to another tool is smaller than if not.

Quote from Mathias

It's clear that backwards-compatibility has really been a counter-intuitive decision, and some of the code dates back to the KnP ages. The native movements are, to put it mildly, rubbish, since backwards-compatibility has been a priority, leading to bugs and quirks of the previous generations.

Exactly this, which is what most have been stating for the last few pages.

Backwards compatibility for the stuff which needs an overhaul could be dealt with with a simple "legacy mode" checkbox which switches to the old code. If you open up an app created on an older build it could automatically set it to on.

Good in theory DistantJ, but even the extension SDK code for MMF2 would best be described as obsolete, patched together like a quilt, and overall quite hacky (although hacky-wise it has nothing on my code). I agree that a separate MMF2->MMF3 converter (as was the CT decision afaik) was the best way to go.

I'm not putting down any devs who worked on that code. When you modify code without having the luxury of changing just whatever you want, it gets horrible even for experts.

Perhaps Clickteam could create a conversion tool that would take old .mfa's and make them compatible with the new version?
Essentially, your game is just a bunch of conditions and graphics/sounds. Even if MMF3 is completely different, I see no reason why your conditions, graphics, etc. couldn't be converted to run in a totally different environment, sort of like how the current exporters work.

All I want from MMF3 is a Mac version and support for all the exporters.

Pineapple, though that is possible, all time spent is taken from something else. Do you remember the switch between MMF1 and 2? How many projects could we actually load in MMF2? None of mine for sure due to incompatible extensions. So, let me ask; would you want to have a good .mfa importer at the cost of MMF3 not having some features it would otherwise have? I guess opinions differs here, but I'd like focus on a better MMF3 and all time invested to exclusively for that purpose.

As long as having MMF3 installed does not mess with the MMF2 installation then backwards compatibility is not important.

As well as a better SDK next time around what i would like to see is a way to code the GUI like Unity allows, so for example i add in a script which gives me a new right click menu option or add in a custom menu tab which opened a custom dialog and so on...

These days i am not using MMF2 much and just directly code everything now (AS3, AIR and Java mainly) however so i am just waiting to see what MMF3 does differently and if it will be of use to me.