Most wanted/least wanted in MMF3

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Hey all,

    I'm sure there are threads like this all the time around here, but still I thought it'd be fun if we all post one feature that we'd want more than anything else in MMF3. You can also post a feature that you think everyone else is probably going to want, but you want least of all. I'll go first

    Most wanted: Embedded scripting language. I think Clickteam products are far superior to Game Maker, but the one advantage GM has over MMF is that is has an embedded scripting language. If MMF3 had this, there'd be literally no reason for anyone to want to use GM (unless they're a cheapskate).
    Multimedia Fusion isn't just for beginners anymore... Professional game developers use it too. Ideally, you'd want the software to appeal to both types of users. I think it'd be great if MMF3 preserves the accessibility of the event editor, while adding the option of using the raw power of a scripting language. A game could be coded entirely in events, entirely in script, or a combination of the two. The engine could be restructured so that every event is actually just a macro that gets converted to script before the game is run.


    Least wanted: Backwards compatibility. I'm sure plenty of people are going to really want to import their old MMF2 projects into MMF3... and I just don't get it. Just because MMF3 comes out doesn't mean MMF2 is going to magically disappear.
    If Clickteam focuses on backwards compatibility it could prevent them from making a new, genuinely innovative, rock-solid game engine that's unlike anything we've seen before.
    Take this one of many examples: the old Platform Movement. It's a holdover from the Klik & Play days and it's glitchy as hell, but Clickteam hasn't changed it, and I understand why... it's because they don't want to ruin backwards compatibility. But wouldn't you rather have a nice new rock-solid platform movement for MMF3, even if it means you have to go back and change your game a little bit?
    For MMF3 I would urge Clickteam to abandon backwards compatibility altogether and focus simply on making the most solid, powerful piece of Clickteam software yet. If you want to yield to popular demand, at the most, you should create an MMF2 to MMF3 project converter. It need not be a perfect conversion... the users can go back and fix any glitches or problems that may have resulted from it. That's why it's called "porting" and not "Clickteam does everything for me."

    Anyway that's just my two bits :]

    Please login to see this link. (Indie games and Fusion resources)
    For freelance inquiries please email admin at ultimatewalrus.com

    Backwards compatibility would be incredibly convenient to a lot of users. But I can agree killing that off could give better results in the future. MMF2 is still a solid platform, if anyone needs backwards compatibility, there isn't anything stopping them from having both that and MMF3 installed. Really anyone needing that will most likely have MMF2 still anyway.

    A few things I'm looking forward to seeing would be a built in physics system. It's nice using extensions like Box 2D for this, and having full control over it. But setting it up where it's built into the 'built in movements' would definitely be cool. Still being able to change it's movement properties in there with a few clicks.

    Redesigning online components. Again, this would be possible with extensions, but I think if it was possible, use MMF3 to completely and automatically design everything that needs to be on it's server. Even set up FTP info there and MMF3 will sync everything it needs to with it. Not completely saying to have MMF3 build the game completely for me, just make everything like this easier.

    I do like what you mentioned with the scripting language. But what would that be able to do that events cannot handle? Would make me want to focus on typing everything up a bit more just because I can, but I've grown very used to the regular event system in place now.

    But there are other tidbits too. Like the rumors of a OSX version of MMF3. Would be cool if there was a way to incorporate Xcode directly into that, and deploy the app to the iDevice from MMF3. Similar to that Adobe product (forgot exactly what one it was).

    Clickteam's model is to make games and applications as easy to make as possible. Having more things that MMF3 can take care of would definitely be a plus if executed correctly. Everything apart from my last idea is already possible in MMF2, but I would like to see it more user friendly in the next revision.

    Please login to see this link.

    I am hoping that add some features to the Group format. Basically I'd like to have the group format but with If and While and For features, so you could have a group of code run X times per frame.
    Also, this would greatly simplify nested conditionals, so we don't have to repeat them.
    This isn't a completely radical change, in my opinion, and it's optional, not some enforced change, so I really hope they think of this.

    Also, I'd like to see some more widget functionality, meaning MMF3-made objects that have conditions and expressions and actions. I think this idea has been talked about before so I don't need to elaborate.

    Another idea I think could be cool is a type of framework generator where you could code groups of code with abstract objects. Then MMF3 would need to support importing these groups of code, and on import you would have to specify which actives are which.
    Suppose you make a platformer group of code, it relies on a single active for the player. The importer would ask you "Which player is the active?" and you would show tell it which active to use.
    This is really the key to code reusability. I find it hard to reuse code in MMF2, so I rarely do, if ever.

    EDIT:
    On the topic of backwards compatibility, I agree that MMF2 is still around and is strong software, so I normall would go all out agreeing with you guys on this. However, what happens when MMF3 releases an HTML5 exporter? Or perhaps a new Wii exporter? (Hypothetically, of course)
    If you wanted to port some old projects, you would basically have to recreate them in MMF3 if there were no way to import an old project. I think that's the main problem with removing backwards compatibility. I certainly hope that Clickteam doesn't restrict MMF3, though. They're probably better off giving it their best and making it powerful, rather than trying to keep some form of link between MMF2 and MMF3.

    Quote from xhedgehogx

    But what would that be able to do that events cannot handle?

    Hoo boy. You may not realize it if you don't know any programming languages, but scripting would allow the user to do a massive amount of things that, while probably possible with events, would be incredibly awkward and cumbersome.

    Take for example an extension as complex as Box2D. Do you really think it'd be practical to code something like a complete physics simulation in pure MMF? If I needed to make something like that from scratch in MMF, I'd go "screw it" and write my own extension in C++.

    Embedded scripting would allow users to create game engines that are complex yet organized and tight. A highly complex program needs things like functions and data structures. (somebody's undoubtedly going to point out that there's a function extension for MMF, but do you really think that's at all comparable to the flexibility and ease of use that a scripting language would offer?)

    This list could go on infinitely, but here's just a few examples of things I can easily do in a scripting language that are much more difficult with pure MMF events:

    Code
    struct ENEMY
{
  float x,y;
  enum TYPE{GOOMBA, PIRANHA_PLANT} type;
  ENEMY *best_friend;
  PLAYER *worst_enemy;
  ITEM items_contained[10];
  STATS stats;
};



    I agree with your suggestions of built-in physics and better online components, that would be rad. I couldn't care less about an OSX version but apparently that's important to some people? (shrug)

    Please login to see this link. (Indie games and Fusion resources)
    For freelance inquiries please email admin at ultimatewalrus.com

    Quote from LB

    (Multiple) inheritance and polymorphism in MMF3...I consider this to be very useful for games :)

    Agreed! Though possible with events this would obviously also work very well with a scripting language

    Please login to see this link. (Indie games and Fusion resources)
    For freelance inquiries please email admin at ultimatewalrus.com

    My most wanted features are:
    Built in collision masks (or something similar)& a platform movement that is both bug free and flexible enough to be used for enemy and player movement.
    If these things don't show up in MMF3 then I'll probably end up taking my money to clickteams competitors instead.

    As for least wanted features I can't really think of any, but I suppose I can agree about backwards compatability if it would allow MMF3 to be a better product.

    Quote

    If Clickteam focuses on backwards compatibility it could prevent them from making a new, genuinely innovative, rock-solid game engine that's unlike anything we've seen before.

    iawtc

    Please login to see this link.

    Honestly speaking, MMF3 should just drop 2d development entirely and be built straight into a 3d engine like OGRE, with tools focused on ease-of-modelling, texturing, etc. I know this won't be the case, but it would have given it a niche that would be 1-of-a-kind

    Quote from UltimateWalrus

    Embedded scripting language.


    +1 Vote, this would be great.

    A big advantage it would have is that you could have a script which work across multiple runtimes, rather than the current system of needing object ports for each version. Also with scripts it's easy to have snippets people could post on the forums then others can easily modify or use them in projects. There could also be built in or 3rd party management tools for snippets etc which would be even better yet.

    Other big requests would be real floats rather than int based things, unlimited alterables where you give them a name/id, nicer graphics as default with smooth rotations and a real anti-alias option, a real SDK with ways to make new file format support, transitions and create custom dialogs etc and generally better organization features like sub folders, search for events etc

    Just to add something based on what was mentioned at the convention by Yves,
    MMF's focus is not on scripting, there are many tools that do that already and do it very well. What MMF does well is ease of use and power. Those are the two things that are core to the product. The key is to improve the power while improving the functionality.

    For MMF3, that doesn't mean to say there would never be a scripting component, but if it was it would most likely be an object rather than built in (as the amount of potential support of such a feature would take up important programming support which isn't a benefit to the core product).

    With regards to backwards compatibility, at the convention Yves (or Chrisb cannot remember - sorry :)) said it will either be an importer type system - where it imports the previous version file and updates it.

    I think we can certainly think about removing compatibility with previous version of MMF... e.g 1.5/1.0/K&P or anything that is still able to be imported (I don't know what can and can't at this point, just making the suggestion that if you own a very old version, then really its quite possible these would no longer be supported). IMHO - i also think its time to start thinking about dropping certain OS support as well, - such as Windows 95/98 etc (again i don't remember precisely what MMF2 supports).. but its sensible to think that you will need a later OS to use MMF3 when it comes along...

    Jason

    Games Twitter : Please login to see this link.
    Websites: Please login to see this link. - Game Dev.

    Quote from JasonDarby

    IMHO - i also think its time to start thinking about dropping certain OS support as well, - such as Windows 95/98 etc (again i don't remember precisely what MMF2 supports).. but its sensible to think that you will need a later OS to use MMF3 when it comes along...

    Jason


    MMF2 native Windows runtime runs on Windows 2000 and newer NT-based Windows. :)

    Lior Halphon

    Quote from Pixelthief

    Honestly speaking, MMF3 should just drop 2d development entirely and be built straight into a 3d engine like OGRE, with tools focused on ease-of-modelling, texturing, etc. I know this won't be the case, but it would have given it a niche that would be 1-of-a-kind

    1-of-a-kind, really? Because I think you just described Unity.

    If MMF3 went completely 3D like that, then what the hell am I supposed to use for my 2D games??


    Quote from JasonDarby

    Just to add something based on what was mentioned at the convention by Yves,
    MMF's focus is not on scripting, there are many tools that do that already and do it very well. What MMF does well is ease of use and power. Those are the two things that are core to the product. The key is to improve the power while improving the functionality.

    For MMF3, that doesn't mean to say there would never be a scripting component, but if it was it would most likely be an object rather than built in (as the amount of potential support of such a feature would take up important programming support which isn't a benefit to the core product).

    "Ease of use and power..." wouldn't an embedded scripting language do wonders for working towards this goal? I think it'd be much, much easier if, instead of having to crap together tangles of events with fastloops, spread values, crafty object selection, and using alterable values as makeshift "parameters," I could simply add a few lines of code when I need to do something more complex than what can be easily done with events. Putting the scripting in an object would be a lot more inconvenient than this, and would probably be similar to what we already have (the Lua object).

    Embedded scripting would definitely improve power and functionality. I feel like you just gave me reasons why there should be embedded scripting in MMF3, but then you say it's probably not going to happen. If this is the case, it's pretty disappointing... of course, I'd still buy MMF3 when it comes out. :]

    Please login to see this link. (Indie games and Fusion resources)
    For freelance inquiries please email admin at ultimatewalrus.com

    Quote from UltimateWalrus

    I think it'd be much, much easier if, instead of having to crap together tangles of events with fastloops, spread values, crafty object selection, and using alterable values as makeshift "parameters," I could simply add a few lines of code.


    How about: I think it'd be much, much easier if instead of having to crap together tangles of code with for(loops), spreading values, manually assigning object selection, and creating variables and linking them to objects instead of alterable values, I could simply add a few events.

    Events should remain the center of MMF. I, and many others, only ever used it because when I started, scripting was scary and events were easy yet powerful. I don't want to have to memorise functions and syntaces when I could use human readable events. If MMF3 were completely scripting-based, I wouldn't even buy it. I might as well code in C++ or Actionscript themselves.

    For a list of my achievements, hit up Please login to see this link..com/
    Unless you want to party, then go to Please login to see this link.

    Quote from Jacob

    How about: I think it'd be much, much easier if instead of having to crap together tangles of code with for(loops), spreading values, manually assigning object selection, and creating variables and linking them to objects instead of alterable values, I could simply add a few events.

    Events should remain the center of MMF. I, and many others, only ever used it because when I started, scripting was scary and events were easy yet powerful. I don't want to have to memorise functions and syntaces when I could use human readable events. If MMF3 were completely scripting-based, I wouldn't even buy it. I might as well code in C++ or Actionscript themselves.


    That's completely not what I suggested. I absolutely believe that events should stay in MMF, and continue to be powerful enough to make complete games with them. I want embedded scripting to be an additional feature that would make the lives of us advanced users a hell of a lot easier.

    And if any scripting language-style code you write could be considered a "tangle", you're a horrible programmer.

    Events are part of what makes MMF amazing for rapid prototyping --- using them I can make games blazingly fast. But what if I want to do something events don't support? Wouldn't it be nice if MMF development could be both fast and powerful?

    (on that note, how cool would it be if the event editor had keyboard shortcuts for common actions/conditions? development gets even faster)

    Please login to see this link. (Indie games and Fusion resources)
    For freelance inquiries please email admin at ultimatewalrus.com

    Quote

    I want embedded scripting to be an additional feature that would make the lives of us advanced users a hell of a lot easier

    As soon as you add something like scripting into an eventing system, you bring a whole lot of support issues and time, effort and money to support it, for what would be a minority of the MMF/TGF2 users. There are products out there that have had many years of development in scripting only, and to be honest, there is no point CT going down a duel layered system, because it would take a very long time to get anywhere near the power and flexibility of those scripting only systems. So people using the scripting languages would continue to use them, and to be honest, if scripting is what you want then they may be a better choice of product.

    On another note, the one product that does use eventing and scripting in the same package, well i found that sometimes you have to use events, and other times you have to use scripting and to be honest, it was not very good in that respect... it basically causes issues when one works and the other doesn't. Alienating the very users that only want to use eventing or only using scripting.

    MMF/TGF2 are products for people who want to make things quickly, but also professional games without the need for a coder/learning code (e.g great for designers and artists who really don't want or can't find a programmer).

    CT has a massive list of user based suggestions for making functionality and eventing features for MMF. Some of those features have been suggested by casual users others by very advanced users.

    I think this shows that the eventing system has a lot of growth in ways of making it better, easier and more powerful.. if there was no scope then i might agree, but seeing what has been suggested by our programmers, users (of all levels), there really is a massive amount CT can do to make eventing even better. Which is great, and i for one cannot wait :D

    Anyway these are just my opinions, but to give you some kind of response really.. so you don't think you are being ignored... but..I would recommend if possible taking a listen to the Convention videos that have been uploaded as some of these questions have been mentioned in that and there is more information about what ideas the coders at CT have in making the product even better..

    Jason

    PS on another note, if there is something that the events don't support, then in your case, being an extension developer, wouldn't you just write an extension? surely that would be the best method for you in that respect, because even with a scripting product, you would do the same, and use an SDK of some kind to add that feature.

    Games Twitter : Please login to see this link.
    Websites: Please login to see this link. - Game Dev.

    IMHO the only scripting system which got sense is the one I proposed the other day - being strict co-relative to Event system, working on the same basis which is just typing of whole event editor, and which at the same time generates appreciative events.

    Anything other like 'more powerful' scripting is nonsense and can be achieved by using LUA/Python/DotNet/Extensions - where we should get rid off extension on the base of Widgets and power powerful built in system what I'm proposing with Nifflas for a long time, and other companies are attempting to introduce, but I'm staying with MMF.

    Why it's nonsense? Because we will create dual system, where more advanced users will use scripts and less advanced events, which is pointless instead of supporting 1 product we will have 2. Whereas with mine system it would be the same 1 product with 1 code system, but one designed mostly for mouse, other one for keyboard.

    End is near.

    Most wanted - Integrated Physics engine which could create custom shapes based on bitmap masks so there would be no more time consuming ways of creating custom shapes using polygon points and csv strings :(

    Least wanted - Scripting system. I'm not the greatest programmer but if I spend time, I can usually get things to work via the MMF events. Adding another level will just make me feel like I have to learn scripting to get the most out of the program, or that i'm missing out on features or easier ways of doing things because I can't understand or want to learn scripting.

    JasonDarby, thanks for the response. You make a pretty compelling argument... obviously I understand that Clickteam isn't magic and they can't just add in every amazing feature that pops into the users' heads. I suppose it would be difficult to maintain the same level of support Clickteam has now, with both an event editor and a scripting language to worry about. I really appreciate how receptive and helpful Clickteam can be, and I certainly don't want that to change.

    I know that one of the most well-known MMF users, Konjak, switched from using MMF to using Construct, I think primarily because of its embedded Python scripting. Unfortunately I haven't spent much time with that software so I can't comment on whether it works well or not (I do know it's very glitchy).

    You seem to suggest that MMF2 is primarily for people who don't know how to program, but I think there are actually a ton of programmers (like myself) who know how to and have made games the "professional" way, but still use MMF2 frequently because of the sheer speed of development. In general it would probably take me longer to prototype something in C++ than it would for me to make the complete game in MMF.

    I guess it's just frustrating because while the event editor lends itself well to making simple things quickly, if I want to add something slightly complex to that game I quickly made, the event editor starts to work against me. I have a C++/Allegro game on my website called "PC PuzzleGlobe" with a simple physics engine and color-matching algorithms... I can't imagine how nightmarish it would've been to do this in MMF, even though it's a very simple game.

    I suppose another possibility to alleviate these type of problems that you might look into (you sorta seemed to suggest this), would be to add more programming language-like constructs to the event editor. Built-in functions and parameters, if/else, while, #define, switch statements, data structures, scope/local variables and arrays, etc. would all be very welcome additions and I don't think they would make the program any less accessible or harder to maintain. You could even put them under an "advanced" icon so beginning users need not worry about them.

    You could even combine this with fanotherpg's idea of typing out events. Consider this:
    1.)Create the aforemention "advanced" events similar to scripting language constructs.
    2.)Make it so any event can be created via text by typing it out.
    It doesn't sound so hard when I put it that way! Doing this would give us a simple pseudo-scripting language in which every script would be exactly equivalent and translatable to events in the event editor. How cool would that be?? I think it's a great idea, but then what do I know, I've only been using Clickteam products for ten years

    Please login to see this link. (Indie games and Fusion resources)
    For freelance inquiries please email admin at ultimatewalrus.com

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login