Does backwards compatibility matter to you?

Quote from MattEsch

Suppose Clickteam released MMF3 tomorrow. Would you be bothered if your current projects didn't work with it?

Nope I'd still have MMF2 installed.

Quote from MattEsch

In my opinion there are a lot of old features that I would like to kill.

They're not features; they're design flaws.

Quote from MattEsch

I would not be sad if the movements were completely replaced by new working ones, breaking backwards compatibility.

This is fine, because they were a design flaw anyway.

Quote from MattEsch

I would not be sad if some of the awkward and unintuitive edge cases were dissolved, at the expense of breaking events that relied on them either.

Again, these are design flaws, so it's OK to resolve them.

Quote from MattEsch

What is your opinion?

I think MMF3 should start from scratch in many places and take in community advice and design MMF2 in such a way that it accounts for everything and allows for new, unexpected things to be added.

Quote from MattEsch

Clickteam go a long way to maintain backwards compatibility with older products, I'm curious as to how many of us actually demand this.

There is, in my opinion, little to no reason for backward compatibility. It's not that difficult to finish existing projects with already installed software...

No backwards. Backwards limits the potential in my opinion.

Ideally MM3 is a new product. As such we will still have MMF2 installed. As such users can use MMF2 for their needs. I think that CT should develop game/application centered/focused products and let the users develop additional extensions after the product has been released as they are needed.

Simply put, it is as if Nintendo plans for physical backward compatibility with the Nintendo 64 for the WII U, but the restriction would be that only single player games less than (let's say) 12Mb could be loaded and played. While its handy that this managed to happen, it would be time inefficient, distract from the true intent of the product, and the added backwards compatibility would be highly sketchy at best.

In conclusion, a long time has passed from the initial release of MMF2 and now. People have learned how to do things differently and make them more effective. Why constrain yourself to the knowledge of yourself from years ago when you can drastically improve upon it and make the overall feature far better than the original

MMF3 must in fact not be compatible because MMF2 carries design flaws that dates back to Klik & Play. If it is fully backwards compatible, I will know the product has utterly failed and I will pick up another better product without a whole lot of baggage that holds it back. The competition is much harder now. There's Unity and Construct. Game Maker is now accepted on Steam. This is not a time to fall behind just to appeal to some people who want to carry their old projects over. In fact, I think MMF3 should do the opposite; be more focused and meant as an amazing easy-to-use yet advanced cross-platform game dev tool, not a tool that does a bit of everything but nothing super well. Look at Unity, it has loads more employees than CT, yet they make a much more focused project where every feature has to do with games, and they're doing super well. MMF3 should have the same philosophy, even at the potential cost of some people here abandoning it (new users and just skilled users not changing to another tool when they get too good will more than make up for it). Remove software rendering, remove the difference between actives and backgrounds since it doesn't make sense with HWA. 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? It's more time efficient to not implement something than implement it in a way that isn't useable), abandon objects such as DirectShow, Active System Box, Animation, AVI, CD Audio, DataGrid, Explorer, FTP, Score/Lives, MPEG, ODBC, OS, Print, Quicktime, Quiz, Sub-Application (object hierarchy support would be a much better replacement), ToolTip and Vitalize. I have a saying that goes "all time spent is taken from something else". Everything is a compromise, so when investing time, try not to make everybody happy at the same time (that's how a product becomes unfocused). Invest time in things that really count!

The old movement issues etc. could be easily remedied with a "legacy mode" checkbox or something...

Sent from my iPad Mini using Tapatalk HD

agree to all above to 110%! focus on making mmf3 the best possible product it can be snd leave mmf2 and klick & play behind!

For me it depends what MMF 3 will be.

If MMF 3 is going to diverge in the way some things are done where it would make sense to drop compatibility, I would be fine to keep MMF2 loaded for existing projects. I guess there's going to be a lot of work in regards to all the exporters, but perhaps the nature of MMF3 will make supporting all these platforms a much easier job that it is now? And Clickteam has more developers to help out here.

If MMF 3 is not going to change in this way then backwards compatibility, or at least a way to import MMF2 projects, is a must. I would support the legacy option, calling certain features depreciated if necessary if there are better alternatives in MMF3 and they can be dropped completely in a future version. Features I would like to see could easily co-exist with any legacy features of MMF.

I'm not so concerned about a lot of the older MMF objects (such as what Nifflas mentions) and I know if these are removed that would have an effect on backward compatibility, but if MMF3 still allowed an MMF2 file containing an abandoned object to be opened and edited (eg: have a NULL object for those that are removed that contain nothing more than the conditions, expressions and action references) then at least the user can work with their old MMF2 projects and make them compatible with version 3.

I also would like MMF3 to focus on what is important for games rather than applications.

Quote from MattEsch

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. Development would be fast because there would be no legacy to support, iteration would be fast. The runtime would work on many platforms already out of the box, it would work in your browser, it would inherently run on linux and mac, android even.

Nooooo not HTML5...

I've been having to work with HTML5 lately and it's just NOT GOOD. It isn't there yet... it might not be there for many years. It might be "the future" but right now I think it is not what Clickteam should be focusing on. First of all, HTML5 is slower than native. That is just a fact.

Secondly, you are boasting the same thing all HTML5 dev tools boast: "it works on so many platforms!"

Well, "working" and "working well" are two completely different things. Please go try and play a game that requires some scaling and opacity changes on anything in HTML5 for iOS devices. Your framerate will crawl. Apple does not support webGL (and doesn't look like they plan on it any time soon) so it's basically like running things in software mode. It is bad. So bad.

MMF lacks:

- subevents (this is a huge improvement... a must have)
- easy to read events editor (can't read actions without using the jumbled events list viewer or mousing over grid boxes)
- better system for storing values... (unlimited values, reorganizing values, naming them whatever you want, one value can be a string *or* a number, values shouldn't exist on objects until you create them to save memory)
- custom functions
- better animations features (remove all the unnecessary default animations that you can't get rid of, allow for easier manipulation of animations, etc)
- draw your own collision masks per animation frame. fine detection should be removed or at least disabled by default
- unlimited action points for objects
- being able to store images for objects externally and load them at runtime easier
- assets get treated like assets, so you can modify them externally and update them in the game in one click. (for example, you can use a sprite sheet for your character that lets you modify it externally and then import it, so you don't have to go into individual frames of animation and update frames one by one)
- support alpha channels for sprite sheet loading
- better default special effects, add in some built in behaviors like sine movement so you can easily wiggle things or have them moving up and down or left/right via sine movement. (right now it's limited to just a circular behavior on position that you can tweak to be left/right or up/down) but I'd like to see a way to easily add "juicy" effects to stuff, like having it scale up and back down quickly when you mouse over it, or wobble around a bit to give it some life.
- built in 2D physics
- built in networking
- support for loading in 3D meshes (okay maybe this one is just for me, but I know a lot of people would love to be able to just import 3D meshes... it opens up huge doors for how a game can look. I'm not talking a full 3D engine, just loading in 3D meshes to display as 2D...
- animation editor needs features of other popular sprite software out now... like being able to use skeleton rigs or animating multiple sprites as their own "piece" and being able to change their images at runtime. (that way you can have a character holding a weapon, and you can just swap out the weapon graphic to have them holding whatever you want... without having to save out dozens of different animations)

As for the original thread topic... lol. Yeah MMF3 can NOT be backwards compatible or they will have wasted so much time. As others have mentioned, we still have MMF2 if we need to work on MMF2 projects.
MMF3 needs to be a totally new piece of software, with only some of the stuff from MMF2 carrying over (but improved) It's a must to be able to export to all the most popular platforms pretty much straight away... Even if you have to pay separately for each exporter.

Quote

What does MMF currently lack in your opinion, with regards to the focussed objective? While you mention a lot of things you would abandon, that only highlights a surplus in features. Would it make sense to strip down MMF with your suggestions? Does it even need additions?

Actually, I don't only see things that are lacking as a problem. I also see a poorly working feature or extension as something that reduces the average quality of the product. No movement is for example better than a buggy movement. The reason we need to strip down so many of the current features is to avoid spending time to port them, manage them, find and fix bugs over time, and so on. What I mean with a focused product is a product designed for a specific purpose and every feature has to do with this purpose. I'd like the purpose in MMF3 to simply be "the best tool on the market for 2D game creation" much more than "a general purpose software/game/multiformat media player creation tool" (ofc extension developers can still do more application oriented extensions but I don't think CT should focus on that). As for things I'd like to see added/changed:

* Use the standardized names for everything (scene instead of frame, frame instead of animation frame/image (MMF2 mixes due conflicting terms, e.g. Image('active') to get an animation frame), consistent naming style for ACE's, consistent 0-based indexes. Remove double negatives (e.g. negating "Channel X is not playing") and double conditions (is visible/is invisible) when it ca only be "is visible" (which could be negated).
* Get rid solutions where devs made something wrong by trying to be smart. E.g. "is object visible" returns False if the visibility flag is set to True but the object is in an invisible layer. I mean, one can argue "hey, but the object IS invisible because you can't see it in an invisible layer", but in practice it removes the functionality to check the visibility status of an object in an invisible layer. What if we actually want to make this check? Nope. Impossible. Alterable value workaround.
* Zooming and rotating the playfield
* Split viewpoints and layer viewpoints on top of each other
* Better ways to iterate
* Sub-conditions, sub-events
* Evented functions
* Else
* An object hierarchy system similar to Unity so we can treat bigger things as entities.
* Qualifiers with custom ACE's. This would get rid of the need for many C++ based extensions that could be evented, though ofc not all). Unlike with the current compiled black-box extensions, this would allow the entire community to share their AI's, custom movements, inventory systems, sound systems, effects, drawing systems as easy to understand single-entity objects with simple ACE's instead of being interfaced with through alterable values and triggering fastloops.
* Sample-accurate synchronization of multiple sounds and some sound effects (reverb, filter, delay and a compressor are the most important ones).
* Support for a single video format without external codecs.

Please login to see this link., Please login to see this link., Please login to see this link. and Please login to see this link. are examples of cool games that for various reasons (iteration speed, synchronizing multiple music layers, viewports, playfield zoom) would be very difficult to do in MMF2. When devs get good, they'll be quick to change dev platform if they have an idea that doesn't really work with the current one, and those are the last users we want to lose.

By the way, I agree a lot with the post above, but I'd like to point out one thing about it.

Quote

- better system for storing values... (unlimited values, reorganizing values, naming them whatever you want, one value can be a string *or* a number, values shouldn't exist on objects until you create them to save memory){

With hierarchies, you could take any extension of choice (e.g. a value/array one) and make it the child of e.g. a sprite. Even make combinations.

Quote

- draw your own collision masks per animation frame. fine detection should be removed or at least disabled by default

With hierarchies you can make a mask sprite the child of a graphical sprite. Or two. Or three.

Quote

- animation editor needs features of other popular sprite software out now... like being able to use skeleton rigs or animating multiple sprites as their own "piece" and being able to change their images at runtime. (that way you can have a character holding a weapon, and you can just swap out the weapon graphic to have them holding whatever you want... without having to save out dozens of different animations)

That's basically hierarchies.

I'm sorry, I just really like hierarchies...

For me personally, I will be concluding my work on Asunder and if I can't port it to MMF3, I probably won't have a need for MMF3 at all. Now I can certainly see plenty of reason not to be backwards compatible, that said.

This is just me personally and only one person. I will loose nearly 400 files to non legacy support of some kind, unless I can somehow import and convert the files. Thirteen years of work will be lost and a website (here comes a shameless plug) that has helped hundreds of Clickteam users, and has become legendary among some users, past and present will vanish in an instant.

Maybe there will be a cult following for MMF2, but I doubt it. I understand where the ranting is coming from. Maybe Clickteam can make a conversion program, but probably not for just a tiny few people who need it.

Marv

This is how it have always been and will always be. Tutorials, examples and features become obsolete, something new replaces something old. I think it's important embrace this. Besides, it's not like our old games actually disappear.

If the programming side is heavily improved in MMF3, the old way to program with will be outdated and your examples won't be that helpful anyway. Instead, take your best stuff and remake it for MMF3's programming style from scratch. Take the opportunity to improve the comments, naming, and structure. If we can push the hierarchy/custom ACE's idea to CT, you'll be able to provide what you do in something that's much more beginner friendly than ever before. I know I will.

It may not be compatible, AS LONG as we have a tool to convert the MMF2 files to MMF3.

I'm sure there will be some way to convert scenes and objects, but probably not events simply because I think a big part of the event structure and functionality needs to be changed in place of something better and more consistent (if it'd had to be compatible, it'd be much more limiting what could actually be improved).

Quote from Konidias

- subevents (this is a huge improvement... a must have)
- easy to read events editor (can't read actions without using the jumbled events list viewer or mousing over grid boxes)
- better system for storing values... (unlimited values, reorganizing values, naming them whatever you want, one value can be a string *or* a number, values shouldn't exist on objects until you create them to save memory)
- custom functions
- better animations features (remove all the unnecessary default animations that you can't get rid of, allow for easier manipulation of animations, etc)
- draw your own collision masks per animation frame. fine detection should be removed or at least disabled by default
- unlimited action points for objects
- being able to store images for objects externally and load them at runtime easier
- assets get treated like assets, so you can modify them externally and update them in the game in one click. (for example, you can use a sprite sheet for your character that lets you modify it externally and then import it, so you don't have to go into individual frames of animation and update frames one by one)
- support alpha channels for sprite sheet loading
- better default special effects, add in some built in behaviors like sine movement so you can easily wiggle things or have them moving up and down or left/right via sine movement. (right now it's limited to just a circular behavior on position that you can tweak to be left/right or up/down) but I'd like to see a way to easily add "juicy" effects to stuff, like having it scale up and back down quickly when you mouse over it, or wobble around a bit to give it some life.
- built in 2D physics
- built in networking
- support for loading in 3D meshes (okay maybe this one is just for me, but I know a lot of people would love to be able to just import 3D meshes... it opens up huge doors for how a game can look. I'm not talking a full 3D engine, just loading in 3D meshes to display as 2D...
- animation editor needs features of other popular sprite software out now... like being able to use skeleton rigs or animating multiple sprites as their own "piece" and being able to change their images at runtime. (that way you can have a character holding a weapon, and you can just swap out the weapon graphic to have them holding whatever you want... without having to save out dozens of different animations)

Display More

These are all really nice worthwhile additions in my view! Mmf3 should focus more on being a game tool first and application tool second.

Also agree about HTML5.. been working on it some and while its great compared to regular HTML, the browsers arent 100% compatible yet anyway and it would slow things down for sure. The current model is really nice in my opinion, with the main program written for windows, and multiple runtimes for different plattforms. I think Clickteam should focus on making the runtime more general, optimized (remove all old legacy klick & play stuff) and easier to port to other plattforms for MMF3.

Event system on top of javascript is a bad idea, and it'll hold Construct 2 back. This is one of the areas where MMF3 can be much better. It's not really a problem to create cross-platform stuff in C++ if good libraries are used and the software is designed right. Besides, I want to do much more demanding things than MMF2 can do today without using up too much CPU. An improved event system with sub-events and better iterations will help massively, but the runtime still really needs to be written in C++ for it to be fast enough.

Quote

- support for loading in 3D meshes (okay maybe this one is just for me, but I know a lot of people would love to be able to just import 3D meshes... it opens up huge doors for how a game can look. I'm not talking a full 3D engine, just loading in 3D meshes to display as 2D...

I think that's the one suggestion I disagree with. It can be a third party extension tho, but I'd like CT to just focus on the 2D stuff and make that amazing. No raycasting, no Z-mode'ish features, no 3D meshes. We've seen features like that already and I don't think what came out of it really justified the time spent implementing it.

Quote from Nifflas

I'd like the purpose in MMF3 to simply be "the best tool on the market for 2D game creation" much more than "a general purpose software/game/multiformat media player creation tool" (ofc extension developers can still do more application oriented extensions but I don't think CT should focus on that).

I can agree with majority of what's been said with regards to MMF3 but I cannot agree with this quote. This is exactly what I was pronouncing in my Please login to see this link.. A prime example of how I insinuated that majority of the sole "game developers" will aim to steer MMF3 in their direction when you will be subtracting a huge quantity away from Application development included and not limited to all platforms supported.

If Clickteam steer away from app development and concentrate solely on game development then there is a huge loss for application development which is equally important as 'game development'. Even some of the stuff we do related to game development is classed as app development. For example, one of my games I wrote the external level editor as a separate application in MMF2, I wrote the engine in MMF2, I then wrote an automatic update utility in MMF2 and to conclude I then wrote the final installation/setup file in MMF2 so my entire project from start to finish, application and game wise was all done within MMF2.

Quote from MattEsch

Ok I'm going to have to dispell the idea that HTML5 isn't ready and it is slow and other such nonsense.

First of all, I will admit that quality does vary wildly, depending on choice of browser. I'm not suggesting that you give the user the choice of browser, but you a) write extensions using JavaScript b) provide a lightweight container so that it runs fast as a native application in the target environment.

In fact, I would write an object-based rendering engine, capable of rendering textured surfaces, SVG and 3D scenes (I have been working on this anyway), and use JavaScript in V8 to drive it.

I am saying, kill runtime bytecode interpretation. Downcompile to JavaScript, run it on the fastest JS implementation there is (which compiles to assembly code on the fly) and use it to drive a graphics engine implementation, which could be WebGL based or based on DirectX or OpenGL, but ideally what is a single executable and not something which requires a browser to run.

To make games work with JavaScript you need to control the environment in which the user runs it, period.

HTML5 is suitable for mobile scenarios. It's awful in the default browsers, but you wrap your game in a native, hardware accelerated container (See Please login to see this link.).

I only suggest JavaScript because it's ubiquitous, it has momentum and it's only going to improve. It's embeddable and demonstrably capable of driving a modern game, just as Lua or Python (Anaconda is still the most efficient runtime for MMF2), and other scripting languages can. The expense is in the graphics rendering, so providing you have a native hardware accelerated context in which to render things, it works.

I also argue HTML5 is the simplest way to build user interfaces today, and as a product that aims to be intuitive , you need to give your developers the best chance of building exactly what they want, looking exactly how they designed it, as fast as possible.

Display More

Some good thoughts here. HTML5 will eventually become a great way to distribute cross-platform games, much like Flash. However, I think the biggest problem with ditching native runtimes and staying only with HTML5, is HTML5 has numerous low-level limitations (such as file and system access) that would make things impossible for application developers (not everyone makes games with MMF ). I guess APIs could be written into the wrapper ala Metro apps, but that might make things complicated for extension developers. All that said, I think HTML5 is the most important runtime that Clickteam will ever create, and it should remain high on the priority list of runtimes to maintain.

On a side note, have you managed to get CocoonJS to work with MMF? PM me if you have, thanks