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)
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:
Good:
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")
...to what value? X(Active("player"))-2
Bad:
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
...to 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!
if ( objnum == 1 )
set Z_one to axfinal
set Z_two to ayfinal
endif
if ( objnum == 2 )
set Z_one to axfinal
set Z_two to ayfinal
endif
if ( objnum == 3 )
set Z_one to axfinal
set Z_two to ayfinal
set objunm to 0
StopScript jdtrigscript
Return
endif
set objnum to ( objnum + 1 )
if ( objnum == 1 )
set angle_source to Z_input_angle
endif
if ( objnum == 2 )
set angle_source to X_input_angle
endif
if ( objnum == 3 )
set angle_source to Y_input_angle
endif
if ( angle_source < 0 )
set angle_source to ( 360 + angle_source )
endif
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
endif
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
endif
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
endif
endif
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 )
endif
endwhile
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
---------------------------------------------
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.
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?
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.
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 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??
Advertisement
Post Reply
with any programming language you can do what you say with very few lines of code.
Edited by ~Matt Esch~
jenswa.neocities.org
