Does backwards compatibility matter to you?

Quote from LB

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.

LB, I don't think you understood my point. As an iOS App developer, I update my App's as and when needed, currently through MMF 2. If MMF 3 arrives with no backward compatibility, no way to load/import MMF 2 projects, then any and all App's made in MMF 2 will face an uncertain future for keeping them up and running. I'm not saying MMF 3 has to be able to load KnP projects, but it should be able to load in MMF 2 ones so as not to hinder commercial software developers who use the tool.

I haven't heard of a lot of developers in your situation. I've heard much more about developers leaving MMF before going professional in order to work on a better game dev platform. MMF2 really needs a reboot that goes beyond what can be backwards compatible, and if an MMF2 project importer can be made, I'd rather see that time being spent on things that makes MMF3 itself compete better with other game dev platforms - even if we lose a few ipad/iphone apps.

Forgive my naivety, but how would MMF3 coming out stop people with MMF2 from updating apps and such?

@_@

Quote from Nifflas

Remove support for every image/video/music format that isn't essential (gifs are 1995, mod/xm/it are cool but the player lacks options for setting interpolation algorithm, following song position commands or not cutting the notes when the song loops, why should it be supported at all?

Quote from Simon

To that end I also disagree with the notion of cutting down on number of supported file formats etc. These things can add richness to applications and a clever design need not exclude features such as this. Lots of people use the product in lots of different ways, it is really important to think outside of one's own box when contemplating such a product.

I think having a SDK for file formats and making them similar to the way extensions work would be better. That way everything is modular and usage is optional so if there was a new image format which appeared one day for example and people then wanted support for it the SDK could just be used and people would simply place a file in a folder then the format would be available to use.

Quote from MattEsch

If I were writing MMF3 I would start fresh and ignore everything. It would, as I have already ranted about, be written in HTML5. It would end up on your desktop in a native wrapper, so you would never know. It wouldn't feel like a website, but run like a native application.

Like others here i don't agree with this, HTML5 is good as a export choice and maybe even built in for some things like being able to make custom dialogs based on HTML/canvas. However it's not a good idea to base the whole program and all export modes around HTML5. Something like C++ with SDL/SFML which has OpenGL enabled would be much better for the editime/runtime and the EXE export.

I am not sure why anyone would want them if they had native exporters but as long as HTML5 was a export mode you could have both. Since you can export HTML5 to various wrappers i see no harm in additionally having that with a HTML5 sub menu for Web, Native and all of the PhoneGap/Cordova etc formats. The current system is good though and i would much rather have real native exporters than wrappers any day.

Quote from Nifflas

Yet, Unity dares to focus more on one side and they're doing excellent. I'd say having a better and more focused game dev tool is OK even at the cost of losing some of our users. On the other hand, I'm disposable too, maybe MMF3 should go much more towards software development so those kind of users gets all the features they need and I'll switch to another game platform. Focus on something and try to be excellent. I just don't think it should try hard to be everything, the most successful game platforms clearly does not - and I'm pretty sure that's why they're so good.

I agree that MMF3 should take a more minimal but more low level approach but i think it should at least have a set of standard GUI elements and events for application development still. With GUI controls they should NOT be windows control based as in MMF2 next time around and they should have the option for custom skin images. That way app developers remain happy, controls would port to all platforms and game developers can still make use of them in option menus etc.

The base extensions should all be open-source and as you say 3rd party devs can make other extensions like with MMF2 now while the main developers work on the actual program. Clickteam should maybe hire a few extra coders dedicated to certain tasks like exporters and extension development, this way the base program is enhanced and at the same time so is features and it's not only aimed towards games so everyone remains happy.

With extension development if things are done well next time with the SDK it should mean making things is much less time consuming for developers. Clickteam needs to put a lot of time into the base of the program, the SDKs and try to focus on making things modular and expandable then all of that work will in turn save loads of time later down the line.

With Unity for example you can make additional dialogs, connect to basically everything, get data back from the editor and scene etc and even code extensions in multiple programming languages. So now they have a load of 3rd party developers making things which are so complex such as shader/events editors, model editors etc they are almost like new programs altogether and this is just down to the fact they designed for modularity and the scripting to be very flexible for 3rd party developers. That has definitely worked out well for them and they even have professional game studios which used to make there own custom engines now using it instead because they can design it around the workflows the development team uses and easily create new tools when they are needed.

Thing is, there's a danger in turning MMF3 into a modular monster where everything is replaceable and scriptable in multiple languages. The reason the Unity team can pull this off is because it's a big company with loads of developers working on it. Very often though, the modular monster is one of the most common ways that projects never finish - especially game engines. I actually think MMF3 should get rid of some modular aspects. There are currently image and sound filters supported, but no SDK for it because time is limited and was invested in something else (besides, the lack of custom ACE's wouldn't make the features that useable anyway if you e.g. has a sound format where you need to customize specific aspects there are no actions for). Because CT is so small, I lean toward the opposite, remove modular stuff where it's not needed and just support two image formats (one lossy, one lossless), two sound formats (lossy+lossless), and a single video format. Modular things can be incredible and my suggestion with custom ACE's and hierarchies is all about this, but due to CT's limited time we haven't actually been able to develop with a HWA SDK yet. It's easy to think "We want MMF3 to have EVERYTHING!", but CT doesn't have a lot of developers and should carefully weight features against each other. All time spent is taken from something else - make all time invested count!

I honestly think that you're over estimating the amount of time required to add additional format support Nifflas, it's a matter of using standard libraries and codecs and at the end of the day it's just not going to add any significant delay to the proceedings. To that end, there really is no need to remove them from the equation... I realise that you don't use them but I can bet you there are people who do and would miss them. There are more critical things which will slow up the development but a few codecs is not a likely suspect in the line-up

Yeah, suppose. My post isn't only about format support tho, a bit more about making everything in general modular. But on the topic of codecs, I also imagine all those video extensions must have taken time to do and then making them compatible with more runtimes must be hard. I still imagine e.g. a single video format would make it much easier to support all platforms. But yeah, image filters may be a bad example.

The main reason I bought MMF2 was the application development possibilities. I founded my company on that principle - I never managed to release a game for the masses (just side projects, proofs of concept and client work), but I have developed several commercial applications using MMF.

That being said, I don't think it's easy to do it, and even small sized projects can quickly become a mess, due to events being illegible, non-modular (you have to change the object they apply to) and non-reusable. Those of you who develop applications, tell me this: Is it easy to create interfaces? Have you ever had to sift through the nightmare that is making active system boxes automatically fit the window on resize? If you have a screen with lots of options and forms... I had days where I'd need 4 hours just to gather the strength to open MMF2 and continue working.
Some of the app-dev extensions break (e-mail object, activeX, ftp, memory) all the time or simply don't have enough features, printing is impossible in mmf, and the "game development only" mindset some times hinder discussion: for instance, you can't ask "how to properly connect and do work in a mysql database in MMF" without being told "you are doing it wrong! It's terribly unsafe! You should make PHP scripts!"... well what if my application is meant to be a server-side tool to monitor mysql databases? And that's not even mentioning basic things that we had to wait for YEARS, such as the chart object.

Someone suggested splitting the product into two versions, one for game development and another for application development. To be honest, I don't really care, and I'd buy both versions, but I'd prefer to see one version - sometimes you need active objects and bouncing balls in your application (don't ask).

Also, while I agree with much of what nifflas said:

• hierarchies
• custom ACEs
• better alterable value handling (In addition to "unlimited/renameable/sortable/groupable/public-private-protected" I'd love to be able to store object instances in a variable and be able to make them do stuff through the variable)
• native, blazing fast C++ engine
• software mode disabled by default or even non-existant (most modern processors can virtualize hardware support, the intel i series even has the h55 gpu integrated)
• more than one action point

I don't think clickteam should cut corners (in the form of hardcoding stuff) in order to save time - I see it as being the opposite, they should create the least amount of content possible - things like movements should be made by the community (even if it means requiring movement code to be open).
Also, I wouldn't be afraid to break backwards compatibility between releases/patches to correct design flaws - construct 2 breaks it every ~10 releases and no one complains.

Now, html5 is still a long ways to go, and you should take what I'm about to say with a grain of salt (considering I'm an armchair game dev), but I find their workflow to be immensely better than MMF:

• events are more readable (you don't have to hover over cells)
• you can sub-event
• if-else
• transform layers (rotate/scale/apply effects)
• ordered/conditional foreach
• the SDK is a lot more intuitive (you can read the manual and crank out an extension in one day)
• there are loads of effects (which are stackable)
• scenes can have more than one "event sheet"
• they recently added containers

Construct 2 feels more casual-oriented though, while mmf seems to prefer large projects - I get that, and I think that's the way it's supposed to be, because you're not going to waste your time downloading some random .exe if the game is just a simple 3 minute platformer, unless you're on Ludum Dare or something.

Multimedia fusion still beats construct 2 for some projects, I'll highlight some advantages

• stuff that requires server communication (MMF has more extensions, and they are more complete)
• performance (HWA and C++ engine)
• multiplayer (MMF suppors UDP)
• sub-applications (c2 doesn't have them)
• native features (create/read files, read from registry, map controls - javascript can't do that and will never be able to)
• stuff that needs to work on old machines
• you are less reliant on browser whims (ex: your game can keep running in the background, whereas browsers slow down javascript when the tab is inactive)
• debugging is easier
• you have tons of control (example, making a kiosk game/application is near impossible in construct, since a random person could just alt+f4)

Now for a list of disadvantages in construct, this should help make clear MMF's strengths and help you all see why a native exporter is sometimes the better choice:

• Construct is too casual-minded, you can make big projects with it, but the community doesn't seem interested.
• You have to jump through hoops when browsers don't support something
• When third parties (browsers, wrappers, third parties in general) have a bug, you usually have to wait months for a fix
• Sometimes it's just impossible to do something - real time games via websockets are such a case, and the w3c can take years to decide on a standard that makes it viable

MMF is very powerful, and can do most things that are worth doing, but your code becomes spaghetti too easily (the #1 reason I abandon projects). All of the stuff above is VERY hard to implement without breaking old code.

Quote from Fimbul

MMF is very powerful, and can do most things that are worth doing, but your code becomes spaghetti too easily (the #1 reason I abandon projects). All of the stuff above is VERY hard to implement without breaking old code.

Hey
My advice, to anyone using MMF2:
- Learn to comment your Event editor properly, never implement tons of features or functunality without organizing your Events in 'segments explained by comments' ( if you are serious about following through with your project )
( Usually 30% - 50% of my Events are comments, and i can allways see and understand the structure of my code )
- Make your comments have a standard 'background color', and make the Font bold to easier be read
- Make 'sub comments' have a lighter background shade. This way you can easily identify Event segments, and also the sub Event segments within
- When you implement a function for a Flag, allway straight away create a Yellow ( or other color ) Comment at the top of the Event Editor explaining what the the Flag does and who the Flag belongs to
- Use Groups Of Events to further organize your code and for easier navigation and better organization

As for MMF3, i simply hope CT extends uppon the awesomeness that MMF2 is
I myself hope that MMF3 will become MMF2 times 10, or at least MMF2 times 1.5

I think it would be a good idea to make backwards compatebility, or a converter, a secondary priority, focus on the future not the past
Current MMF2 App and Game developers can still continue using MMF2

I agre with all here that say MMF3 should focus on MMF3
Focus on making MMF3 a superior product first of all
If MMF3 in spirit will be similar to MMF2, developers klinging to MMF2 will in time come to realize this, and a jump from inferior MMF2 to superio MMF3 wont be that far. The better MMF3 is, the easier it is to make the desission to jump
Time spent making MMF3 as best it can be will benefit everyone in the long run
I guess people can get alittle scared when the good old road is about to take a new turn intoo new and unpredictable teretory

Also, if MMF2 today is dragging behind its quirks, faults and flaws ( as i have heard people state ) from the earlier legacy of products, i can only assume that such a backward focus will introduce obstacles and problems.
I have no problem with MMF3 being a new and superior product unrelated to MMF2

When i embark on a MMF2 project based on an idea i have, there are eventually alot of things that dont work that great
I try to patch it up, fix it, find and remove the buggs
Eventually however, i start over with a blank page, creating the NEW project bigger and better with the help of my previous knowledge avoiding my previous faults and errors

Dont missunderstand, im not saying MMF2 compatebility is a bad idea, im just saying its a bad focus for a NEW product ( imo in this particular case )