The Daily Click ::. Forums ::. General Chat ::. MMF3 - what do you want

Post Reply  Post Oekaki 

Posted By Message



GOTM - MAY 2009 - 3RD PLACE!
11th April, 2010 at 22:51:28 -

I also don't like the thick selection outline when you click on an object. Makes it hard to do any detail work (although I usually use snap to grid)


SevenT2 - [GameStormers]


Wii OwnerVIP Member
13th April, 2010 at 01:34:31 -

I agree with what most people are saying. When i was younger an naive i was like "OMGOMGOMOGMOGMOGOMG!!!!Shift+111!!!!! 3D WOULD BE AWESOME!" and now that I've had hands on experience with 3D programming in C++... I have to say i really prefer 2D. And the experience you can get from a really good 2D game is unmatched by any 3D game in my opinion!! Though, i might be biased, because i still think that the SNES is the best console ever.

Add physics support to MMF3! Thats all i want, and HWA built in (which is already pretty much a reality)

AND KEEP THAT JAVA MOBILE THING GOING! I want to play my games on my N97

Current Projects:
+ S#32
+ Ricky Runfast!
+ The GameStormers (YouTube Channel)
+ Final Fart! (Board Game)

The GameStormers:
[ ]


Klik & Play Expert


I am an April Fool
13th April, 2010 at 03:00:54 -

I definitely agree with the event editor writing a script automatically, so that there is a choice. I think obviously a no brainier is object picking.

Jesse J


13th April, 2010 at 07:06:01 -

Originally Posted by SiLVERFIRE

Originally Posted by aphant

Originally Posted by Xgoff
it wouldn't be all that hard to have both 2d and 3d functionality without hurting the 2d all that much

The major annoyance most have with MMF, from what I've seen, isn't the 2D graphics part. It's the coding part, with the clunky (and slow) expression editor, the massive amounts of code required to do the very most basic of tasks, and so on. Take all of that hassle, that can only retrieve numbers from two axes, and put it into an editor with a third axis.

Yea, no thanks.

Uh, no. I don't believe that. I think many people including myself, find the event editor and the amounts of code is all a part of the designing of a game. If you want a cookie cutter game maker, use something else. MMF is about assigning ease to power and theres never been a better balance between the two. I think Clickteam just needs to evolve on what they have, not step back and consider redesigning any of it - beyond the need for extensive repair, such as more up to date editors. I would hate to see the functionality of MMF dramatically downplayed by adding automation. We've all already seen how that works out with default movements. Pass.

See, I didn't mention anything about wanting a cookie-cutting piece of crap or automation. Way to jump to a conclusion! Take the two examples of code, with whatever is italicized being something that requires data input:

Player1 moves joystick Left: Set X of Active("player") to X(Active("player"))-2
Who is moving the joystick..? Player1
...and which way is the joystick being moved? Left
What do we do when that happens? Set the X coordinate of an object to a value
Which object...? Active("player") what value? X(Active("player"))-2

Move Player left 2 units on keypress
How many units do we move the player to the left when they press the key down? 2 pixels

That's MMF2 code and what you probably think of when you hear "cookie-cutter," respectively. Now, this code example is more of what I'm talking about:

(1) New Function ("Move Left"), (a, GUID): Set X of Active(GUID) to X(self)-a
(2) User(1) presses "Left Arrow": Move Left(2, GUID(Active("player"))
(1) What are we doing? Defining a new function
What is the new function's name? Move Left
What arguments will this function take? a, GUID
What happens when this function is called? Set X coordinate of an object to a value
What object...? An active object, with the GUID supplied by argument #2 what value? X coordinate of the previous object minus argument #1
(2) Which user is pressing a key...? 1
...which key are they pressing? Left arrow
What are we doing when that happens? Calling function "Move Left", with the arguments of "2" and the GUID of Active("player")

In that example, the programmer would be defining a function (without an extension), and then calling that function when some conditions are met. They could then reuse that function for the AI, additional players, physics, whatever. Having to tediously copy/paste code is, as far as I'm concerned, an unnecessary workaround for a function (aka reusable code). Take a few programmers and set them to work just creating a bunch of functions and you'll have a library.

Here's another example of a much more lengthy workaround. I'll be honest, this isn't MMF2 code, but this is what I think of when I think of "unnecesssary workaround for a basic task." This is a script from Morrowind, painfully retyped from a printed copy of Useful Morrowind Scripts (Volume II, 5th ed.):
Try and guess what it does before the end of code block!

begin jdtrigscript

float ax1
float ax2
float ay1
float ay2

float angle

float angle_source
float angle_temp
float angle_temp2

int angleshort
float angledec

int anglequad

float axfinal
float ayfinal

float angconvx1
float angconvy1
float angconvx2
float angconvy2

int objnum

while ( objnum <= 3 )

if ( objnum == 1 )
set Z_one to axfinal
set Z_two to ayfinal
if ( objnum == 2 )
set Z_one to axfinal
set Z_two to ayfinal
if ( objnum == 3 )
set Z_one to axfinal
set Z_two to ayfinal
set objunm to 0
StopScript jdtrigscript

set objnum to ( objnum + 1 )

if ( objnum == 1 )
set angle_source to Z_input_angle
if ( objnum == 2 )
set angle_source to X_input_angle
if ( objnum == 3 )
set angle_source to Y_input_angle

if ( angle_source < 0 )
set angle_source to ( 360 + angle_source )

set angle to angle_source

if ( angle <= 90 )
set angle_temp2 to angle
set anglequad to 1
elseif ( angle <= 180 )
set angle_temp2 to ( 180 - angle )
set anglequad to 2
elseif ( angle <= 270 )
set angle_temp2 to ( angle - 180 )
set anglequad to 3
elseif ( angle <= 360 )
set angle_temp2 to ( 360 - angle )
set anglequad to 4

set angleshort to angle_temp2
set angledec to ( angle_temp2 - angleshort )
set angle_temp to angleshort

if ( angle_temp <= 10 )
if ( angle_temp == 0 )
set ax1 to 0.000000
set ay1 to 1.000000
set ax2 to 0.017452
set ay2 to 0.999847
elseif ( angle_temp == 1 )
set ax1 to 0.017452
set ay1 to 0.999847
set ax2 to 0.034899
set ay2 to 0.999390
elseif ( angle_temp == 2 )
set ax1 to 0.034899
set ay1 to 0.999390
set ax2 to 0.052333
set ay2 to 0.998629
elseif ( angle_temp == 3 )
set ax1 to 0.052333
set ay1 to 0.998629
set ax2 to 0.069756
set ay2 to 0.997564
elseif ( angle_temp == 4 )
set ax1 to 0.069756
set ay1 to 0.997564
set ax2 to 0.087155
set ay2 to 0.996194
elseif ( angle_temp == 5 )
set ax1 to 0.087155
set ay1 to 0.996194
set ax2 to 0.104528
set ay2 to 0.994521
elseif ( angle_temp == 6 )
set ax1 to 0.104528
set ay1 to 0.994521
set ax2 to 0.121869
set ay2 to 0.992546
elseif ( angle_temp == 7 )
set ax1 to 0.121869
set ay1 to 0.992546
set ax2 to 0.139173
set ay2 to 0.990268
elseif ( angle_temp == 8 )
set ax1 to 0.139173
set ay1 to 0.990268
set ax2 to 0.156434
set ay2 to 0.987688
elseif ( angle_temp == 9 )
set ax1 to 0.156434
set ay1 to 0.987688
set ax2 to 0.173648
set ay2 to 0.984807
elseif ( angle_temp == 10 )
set ax1 to 0.173648
set ay1 to 0.984807
set ax2 to 0.190808
set ay2 to 0.981627
elseif ( angle_temp <= 20 )
if ( angle_temp == 11 )
. . .
elseif ( angle_temp == 90 )
set ax1 to 1.000000
set ay1 to 0.000000
set ax2 to 0.999847
set ay2 to 0.017452

set angconvx1 to ( ax2 - ax1 )
set angconvy1 to ( ay2 - ay1 )
set angconvx2 to ( angconvx1 * angledec )
set angconvy2 to ( angconvy1 * angledec )
set axfinal to ( ax1 + angconvx2 )
set ayfinal to ( ay1 + angconvy2 )

if ( angle_quad == 1 )
set axfinal to ( axfinal * 1 )
set ayfinal to ( ayfinal * 1 )
elseif ( angle_quad == 2 )
set axfinal to ( axfinal * 1 )
set ayfinal to ( ayfinal * -1 )
elseif ( angle_quad == 3 )
set axfinal to ( axfinal * -1 )
set ayfinal to ( ayfinal * -1 )
elseif ( angle_quad == 4 )
set axfinal to ( axfinal * -1 )
set ayfinal to ( ayfinal * 1 )


end jdtrigscript

So, can you guess what that script does?

What it does is actually very simple: It finds the sine and cosine of three angles of any object.
That's it. It uses a pre-computed table of results to generate the sine/cosine, and that's the part I skipped over near the end: angles 11 through 89.

Sine and cosine, that's it. That is my definition of "unnecessary workaround for basic tasks," and I'm sure we've all seen or had to write MMF code like this to get something simple done.

Of course, your angle seems to be that "unnecessary workaround" is equal to "automation," and you oppose it for fear of a lack of control over your code. Would you rather translate the above code into MMF2 (and then copy/paste/update references for every object you wish to affect), or just use the built-in sine/cosine functions? Unless you're a masochist, you'd opt for the built-in functions because it's just stupidly tedious to have to write in a workaround for something and then manually update any references made by that workaround.

What I'm looking for isn't automation, I'm looking for a much easier to use that has more power to it:
Built-in support for functions (like "Move Left" from much earlier) would let you create your huge mess of sine/cosine, and then call that function later instead of having to copy/paste that huge mess every time you want to use it.
Support for objects with behaviors in global events. Make all of your objects (like enemies) on one frame, put all of their pathfinding and detection AI in a behavior, and you'll be able to create and manipulate that object from any other frame.
All around better qualifiers. Qualifiers should be able to support their own behaviors. That way, you can have a qualifier "Goomba" and any object with that qualifier will walk in one direction until it hits a wall to turn around.
Better referencing (like "self" to reference the current object (via qualifier/behavior) or the objects within the current scope (alterable value == 1)) would let you pick out which objects you want to work with, without having to filter it out by spread values, five different alterable values, a string, and the time of day. Being able to reference an object directly with it's GUID (testing for the fixed value is still subject to stupid workarounds like having to "pick one at random" until you get the one that matches) would also speed up the way we code. I see "self" being most useful for loops and checking their indices; On Loop("player_physics"), set alt A to LoopIndex(self).
Being able to parent objects to others. You have your multi-object tank? No more having to use spread values and then test them at random to assign children to parents, just use code like: Set X to X(parent(self)). Simple, effective, and no control lost. Object parents could be set in the editor (every tank body has a tank turret, for example), and at run-time (tank turret just got ripped off by a katamari ball). Although, a custom function could be used for object parenting instead...

That list could be boiled down to:
Built-in support for custom functions (eg, no extensions or objects needed)
Better support for behaviors
Better qualifiers (with support for behaviors, but that could probably be handled a custom function)
Much improved object referencing



13th April, 2010 at 10:59:20 -

Holy shit what a ridiculous exageration... with any programming language you can do what you say with very few lines of code.

But yes, when the game project gets complex, you truly get thousands of lines of code on your hands, and that cripples the artistic potential.





SnowMan!PS3 Owner360 OwnerI am an April Fool
13th April, 2010 at 18:44:27 -

built in 360


Always Serious


Code MonkeyKlikCast StarVIP MemberAttention GetterWii Owner360 OwnerThe Cake is a LieCardboard BoxHero of TimeI'm a Storm Trooper
I'm on a BoatIt's-a me, Mario!PS3 OwnerSonic SpeedGOTM - SEPTEMBER 2009 - WINNER!Evil klikerPokemon Ball!I am an April Fool
13th April, 2010 at 19:48:04 -

Codemonkey wishes for smooth zooming made easier.

You can log off any time you like, but you can't ever leave.

~Matt Esch~

Stone Goose


VIP Member
15th April, 2010 at 10:30:37 -

Inline looping (not event driven fastloop nonsense)

do these events ( expression ) times

Manual object picking with a foreach loop sort of construct

Pick Enemy one at a time
| if Picked Enemy overlapping backdrop ....

The ability to get and test the name of an object at runtime when using groups. I.e. Group6.ObjectName so you can distinguish between different types of objects in the same group while looping. This is sort of like knowing what the object type is without having to create a variable on each of those objects to specify it.

The ability to set variables in the level editor on an instance basis. If I make a tree active and put 5 of them in the level editor, I can't specify separate values for each of those trees at the moment.

When copying any object that supports alterable values, the values and value names should be preserved. It's annoying when I want the same variables on an object but copying an object doesn't copy the variable names.

Functions and Procedures would be nice. I am sick of calling a fastloop when I want to do something, I just want to jump to somewhere in the code, do those events and then jump back to where I started. While I don't imagine it's easy to support different return value types, all you need to be able to do is return a string. This could refer to an object id or something if you want to return objects.

It's probably worth mentioning that searching through events to find a particular fastloop is rediculous. The line number of each event could be registered in a table somewhere. You should have the ability to jump to any line in the events.

An efficient path-trace for movements is a good idea as well. Basically, testing collisions each time you move a sprite by 1 pixel in any direction is inefficient. You can test your starting position for a collision in the usual manner, and when you move the sprite by 1 pixel all you need to do is check the outline of the sprite for collisions. All those pixels in between are useless.

I am glad people aren't harping on about MMF3D. I think the goal should be to make it easy to allow any developer to implement advanced functionality such as 3D capabilities in the form of extensions. I wouldn't be prepared to pay for MMF3 unless it was based on a different fusion engine. The fusion engine should be known as the confusion engine, it's difficult to understand what it's doing, and this is clearly not the point of MMF. MMF is supposed to be logical and easy to understand. I don't want to have to know that something completely stupid is happening under the hood just to make my events work. The real issue I see is that there is probably some reluctance to overhauling the design because the product as it stands is very well supported by a large number of compatible extensions. MMF3 should be a complete redesign, completely recoded from scratch, and it should be allowed to lose compatibility with older versions of multimedia fusion in order to support this.

One feature that would be amazing is the ability to export the project to a real programming language, a C# or Java project perhaps. I have looked into the ability to do this and it seems viable provided the engine was designed with this in mind. This would also make the app much more appealing to those needing the tool for rapid application development, being able to transfer concept to tangible code. It might also be more efficient to export to a programming language and to compile the application in that language than to rely on the fusion engine.

If this wouldn't be considered, at least some manner in which to export game code and levels into a human readable format would be nice. Our games shouldn't be glued into an mfa and it should be easy for us to port our games to other platforms. It would be nice for the coder transitioning from MMF to some other language to have some resources to directly compare with.

Edited by ~Matt Esch~ Image


Possibly Insane

20th April, 2010 at 14:10:50 -

I want it to fix the stupid ladder bugs when I import my old games from knp and try to export them in something decently. But this could be done via some kind of import function like: file -> import knp game files.

Oops, I forgot to mention this: did anyone mention opgenGL support already?

Edited by Jenswa



20th April, 2010 at 15:24:55 -

really they should have gone with opengl from the start since that would make porting to other platforms easier




VIP MemberI am an April Fool
21st April, 2010 at 23:03:04 -

Keyframe animation editor. A more robust path movement.



God's God


Game of the Week WinnerKlikCast StarAlien In Training!VIP Member360 OwnerWii OwnerSonic SpeedThe Cake is a LieComputerChristmas Tree!
I am an April Fool
21st April, 2010 at 23:14:46 -

I'm still entirely in favor of and would really, really like to push multiple custom collision maps for MMF3. I whole heartedly believe that this would be a revolutionary feature for MMF3 that would make custom platform engines a thousand times easier to produce, and a hand full of unforeseeable flexibility in designing games that would be otherwise very complex as we use dozens of active objects and fast loops with spread values just to produce a few custom collision maps. This goes even further whenever you're trying to maintain this level of complexity over dozens of enemies, each with their own collision maps. It really just turns into a large mess and collision maps would immediately clean all of this up.

James Luke

Possibly Insane


22nd April, 2010 at 12:26:57 -

3D. For 2D I think that MMF2 is perfect.

when you look around you be very happy that you are alife and that peple love you because you dont know when their going to die and there are lots of peple less fortunite than you who are ding every day in the world and be lucky that you are quiet cleaver so you understand whats going on - James Luke, 2010


I like you You like you


Has Donated, Thank You!Game of the Week WinnerVIP Member360 OwnerDos Rules!Happy FellahCrazy EvilI am an April FoolGingerbread House
22nd April, 2010 at 19:29:23 -

I would also like to see some more decent racing car movements whose attributes can be customised. Why is it that after 15+ years of Klik there still isn't anything around that can do decent car mechanics off-the-shelf??


Subliminal Dreams. . ., daily gaming news and the home of Mooneyman Studios!


God's God


Game of the Week WinnerKlikCast StarAlien In Training!VIP Member360 OwnerWii OwnerSonic SpeedThe Cake is a LieComputerChristmas Tree!
I am an April Fool
23rd April, 2010 at 02:10:14 -

Because what they should be working on is tools to make advance game design easier, not templates to make cookie cutter game design easier.

Post Reply



Worth A Click