MMF Object Physics. (here we go..)

[Serephim]

It can be done. But can it be applied?

Ive made countless partical physics engines (posted one up here, it was made to be copy/paste avaliable to add bounce and collision physics to all objects under its group)

Now, im thinking about working on a actual Object Physics engine (also Copy/Paste friendly to all engines), and would like to discuss methods on going about doing this.

Concept - Make a system where each object has environment interaction physics. (such as a box being able to tumble and rest on its sides automated.)

Although copy /paste is going to be used, each object will have to have certian settings to peform right. (actully i think each object will have to be pre-programmed under the same physics engine.)

How to do it (UGH.)-

*imma use my EXTREMELY small knowlage of working with Blitz 3D to explain this.*

Okay, my only guess to make this work is to use the same method you would use in 3D - Make seperate objects' collisions combine to make a single entity. (at least im pretty sure thats how it works.)

This would be tricky, seeing as MMF does a really bad job with distinguishing objects that are dependant on other objects, but have multiple copies.

I dont have any pictures, but im going to use a simple Box as an example. (So spawn a 2D G.U.N. box in your head on a Sonic Playing level.)

From here, once again, there are 2 methods of going about realistic tumble physics Setup.

----The semi-hard way thats easier than the next way way.--------

Each side of the box (the box has 4 of them) should have 3 sensors - one on the left edge, one in the middle, and one on the right edge. The Edge sensors (shaped like circles) shouldnt be Directly on the edge, but a half an inch away inward from it. The Middle sensors (a horizontal bar streching almost the length of the side inbetween the edges) are basically the platform for the box.

Each box side has 3 sensors, and each of the edges should almost have 2 assigned to it. Thats 12 Active Objects per sensor. (problematic, but meh.)

Each sensor actully has X/Y gravity assigned to it, but shares the value with all other ones depending on what side the box is on. (ill explain what they do later on)

Each Middle sensor (which ill refer to as Base now) will have collision to them, but one of them must be a "Master Side" from which they all correspond to. Lets just go ahead and call this "Master Side" the "Foot".

The foot will act as kind of a Stand for the sprite being used, and will host its Initial Position. (upright.)

--The Foot.---

Let me go ahead and note that each Base Sensor will HAVE to be animated for this to work. The hotspot between the animation of the side sensor will be in the exact middle of it, and it will have 360 directions to it.

-North directions being standing upward

-East directions being leaning to the east

-South directions being upside down

-West directions being leaning to the west.

The Foot will be the leader of directions. It will be the only sensor at the start of the program facing completely north. Remember, all sensors must have these animations present.

--The Bases---

From here on, each other sensor MUST be programmed to correspond to the direction of the Foot sensor. For instance, the Foot sensor starts in the North position, which means the Base on the Topside of the box must be facing South. (Upside down.)

The one on the right side of the box should be facing left (on its side leaning to the left) , and the Left side should be facing Right. (on its side leaning to the right.)

--The Edges (Important!!!!!!)--

**havent completley figured this part out yet, so if i confuse you, know you arnt alone. X_X**

The edges dont really need perfect collision, because the only thing their here for is to tell weather the box is on a side, leaning over an edge, or Airborne.

The way this is done is with the X/Y values.

Each edge is constantly being effected by gravity. The edge should always be pulled down by gravity, or is at least being told to. The only time in which the Y value of an edge is 0 is if both it and its opposite edge are colliding with an obsticle. (this allows the box to be suspended between 2 objects even if there is nothing in the middle.)

Each edge, depending on whether its colliding with a background or not, is what controls the direction/tilt of the Base, but regardless of what its assigned to, it ONLY changes the direction of the Foot, because the foot regulates the tilt of each sensor. **IMPORTANT. Otherwise, not only will it not work, it'll get extremely confusing.**

The way to do this is have each sensor add to a value on the Foot (a value assigned "Left tilt" and one assigned "Right Tilt".

***The X and Y values of the Edges ***

>>>>>1:19AM. im tired, so ill finsh typing this tommrow. Discuss.<<<<<<<,

[MidimanNull]

LUA Object. thats.. really all you need.

[Draco Icebane]

I don't know why you'd want to add a Havok physics engine to your game in the first place, but hey, it's your mouth and as long as you don't kiss me with it

[Aaron C-T]

Draco: There are reasons for this sort of thing and it would make perfect sense if you had an open mind. It can be used for things like beat-em-ups and puzzle games. Honestly, what kind of comment was that? One of my project ideas at the moment requires some degree of this sort of thing for even the basic gameplay. Go figure.

Midiman: Never heard of this LUA object? Does it work in MMF2? If not, this is still extremely useful.

Serephim: For my idea, I wasn't even going to go that in-depth with it. I was simply going to have the box as an active object with 4 sensors. No matter what the box does, even if it's spinning through the air, that bottom sensor would stay at the bottom of the box object. When the box touches the floor, assuming it lands on an edge, the sensor would simply slide over depending on what frame of animation it was on (if it's leaning more to the right, it would slide to the right and if there's a wall or something there, the side sensors would tell me and it would simply stop). As it slides, the rotation animation continues until it's perfectly flat. At least that's the idea, getting it to work is a different story. As long as it looks right I couldn't care less.

[MidimanNull]

the LUA object is in the bonus pack for MMF2.

[Serephim]

.....Midiman, the main reason im doing this is to add physics to MMF WITHOUT use of an extention..

Going in-depth with it because although im trying to think of a way to achieve it, i havent applied it yet. X_X;

Edit-

And although that method would definately work Scatta, i dont think it would be able to interact with other boxes. (like stacking.)

And i doubt mine will either, though. The Collision of the base sensors wont be good enough to do that, i dont think. Im going to apply it today, and tell you how it goes.

[Aaron C-T]

Serephim: I don't see why not: if you can make it so you can stand a box, then you can make it so that one box sits ontop of another. Speaking of which, I always have huge issues when it comes to that sort of thing. How do you make a player stand on an active? I'm assuming that's also how Aero's oldschool bridge thing is done and I need something like that.

Midiman: Oh? I have that pack installed. I'll check it out.

[Serephim]

But if 2 boxes are sitting on top of eachother, their going to have to react if one or the other moves.. which now that i think about it would cause major problems.

I might rewrite the rest of this with more sensors in mind. I havent finshed hte rest because im trying to apply with i' ve posted already.

Mind you, everything ive typed so far was something i just upped and decided to do, and ended up taking it very far.

- Scatta, you way works by simply making the box tumble a bit when it moves, and make sure it sits on its side when it stops.

My way works by using a force (player, fireball, ext) to make it move, then having the environment determine where it tumbles.

Right now, im having trouble coming up with a equation to have each base sensor's direction correspond to the Foot sensors'. (the directions go from 0-31, then back to 0. If the direction values go past 0 and dont start adding into 31 or vice versa, it wont work correctly.

And even though i have the idea of how the sensors would WORK, im having doubts it would even collide correctly. For instance, if one box was slanted and another fell on top of it completely stright, would it slide off of it or go through it?

Im having fun programming this, but i doubt it'll work perfectly. Even if it doesnt, ill still release it to be used in everyone's game with a super easy interface.

--Edit:

And even if the finshed product wont be worthy of making physics puzzles out of it, it'll still be an awesome addition to a game.

In sonic, we could pull a Sonic Next and make the parts from the badnick / boss go bouncing and tumbling all over the place when it explodes..

Or when sonic enters Death Egg and the gravity shuts off, a few objects in the environment can lose their gravity and go floating around the place, bumping into sonic and stuff.

Or in a Fighting game, using certian attacks can cause environmental objects in the background to jump around, and shockwaves can blow pieces of the foreground/background away with nice effects...

So even if this doesnt make a perfect Tomb Raider Legends concept, it'll still make eyecandy for our products that make people go "OOHHHH...".

Im personally using this for my Tails Adventure game, as well as my new Sonic RPG engine im making and me and ChaotiControl's Fighting Game.

[LarkSS]

I actually thought about this before, but never bothered to try it. How about this for a starting thought. I know you said no extensions, but MMF1 rotation sucks.

_________________________________________________

Note: If I use the word box, I mostly mean any kind of object, but I prefer to use box instead as that's what my example consists of.

Start with the Active Picture Object. Have it load an image of a simple box. ( With equal sides. I haven't thought of a way to get it to work with one side being a different length than another. Also, this method wouldn't work with an object that has a roundish part. )

Okay, now set Alterable Value A to the number of sides it contains. This way, it's not restricted to an object having 4 sides. This will be explained later on.

If the box is hit, Alterable Value B, which is the box movement speed, should be increased and effect the speed of the box's rotation.

Now, the box will have 4 different effects of speed against it; ground friction, box friction, the weight of the box, and the distance of the angle away from a corner.

=Ground Friction - For different surfaces like dirt and ice; also good for the deceleration to change in mid-air.

=Box Friction - Allows you to give boxes different material effect. Not really required though.

=Weight - Self explanatory. This lets you make the object more realistic by giving it a specific weight. It'll effect the drop rate, slope effect, and the angle to point effect.

=Angle to point distance - Used as the closer the object is to one of its corners, the less it'll slow down; the closer it is to a flat side, the more it'll slow down.

Ground Friction can be alterable value C and changed based on what surface the box is in contact with, Box Friction can be alterable value D, and the weight can be alterable value E. The last thing is pretty much calculated during run-time.

Here's my solution to ground detection. The object itself can detect ground collisions. Detectors will be needed for wall and ceiling collisions as MMF doesn't support pixel checking. To do this, at the start of the frame spread 1 in alterable value F for all box objects. Next run a loop called box.sensor for the number of boxes. During the loop, create a sensor object, set alterable value A for that sensor object to the loop index, and check to see if the loop index matches alterable value F for a box and position it to that specific box. What this will do is give each box its own sensor and the sensor will only react for that box by comparing to see if the sensor alterable value A is the same as the box alterable value F. Collisions and whatnot can be handled from there.

BTW for ceiling collisions, I'd inverse the Y velocity instead of setting it to 0. The same should happen for wall collisions except I'd probably take away from the speed based on the object weight. ( Heavier objects would rebound much less. )

Continuing, as the box is moving, subtract the box and ground friction from the speed if it is on an obstacle. Also, you should subtract from the speed '[insert number here] * Sin( [Angle distance to Point] )'. I'm not exactly sure how to come up with the angle distance from the current angle to the nearest point, but I'm guessing it's something dealing with taking the number of sides ( explains alterable value A ) and dividing by 360 and comparing the number to the current angle or something along those lines.

That basically sums up my thinking on it. Maybe if I get myself some time I could give it a shot. If you have MMF2 ( unlike me ) and since I believe it supports active object rotation, you can simply ignore using the active picture object and use the rotation value of the object.

Edit: Thinking on this some more, I now relize you would need a sensor on the middle of the bottom side to check if it's sitting on a ledge or not. Since the box itself does the ground collision, if the sensor isn't on an object but the box is, it means more than half is off a ledge and it needs to start falling.

Also, it seems my method would have trouble with slopes ( it would go on them, but treat them like flat ground ) and that would mean needing sensors on every point of the object, which I believe leans over to Serephim's method. =/

Edit2: I almost forgot to mention that half the width needs to be stored in an alterable value along with making sure the hot spot is in the center. The half-width value is needed to determine where the points are located on the object and the distance of the sensors.

[Serephim]

Could work as well.

As for ledges, i said a method of having 2 edge sensors would basically tell if its leaning over an edge or not, but it wouldnt tell how much it would be leaning.

Now that i think about it, The edge sensors should be more towards the point where the box would tilt from imbalance on a ledge...But that would make having hte box stand between 2 edges impossible.

..Unless we addded 2 more sensors.

Yea, there are many methods to go about this, but im pretty sure making it work the way we want wont be too easy.

(BTW Lark, you actully thought me something with that "assign a object to anoteher object through a loop" idea, im definately gonna use that, maybe to make my old Shadow Clone AI collide alot better.)

[LarkSS]

Now that i think about it, The edge sensors should be more towards the point where the box would tilt from imbalance on a ledge...But that would make having hte box stand between 2 edges impossible.

Wouldn't you just need to check if less than 2 point sensors are not colliding with the ground?

Btw, I believe one object could do the point detection for all the points of one object. I don't mean that it'll take only 1 during runtime, but I mean one type of object instead of a seperate one for each. Also, I believe a sensor would be needed to check if the middle between the two points closest to the ground is colliding with an obstacle or not, since imo if more than half the object is off a ledge, it should start falling.

Yea, there are many methods to go about this, but im pretty sure making it work the way we want wont be too easy.

Just thinking about it wasn't easy. =/ There's a lot more involved into getting it working than I actually thought about. Sure you can make it rotate and whatnot, but getting it to work as realistically as possible is a real bother.

(BTW Lark, you actully thought me something with that "assign a object to anoteher object through a loop" idea, im definately gonna use that, maybe to make my old Shadow Clone AI collide alot better.)

I actually use the loop system a lot now as it helps me to fix MMF's stupid problem at identifying a certain object of a similar type group. I have noticed that it fails when doing two loop checks at once that rely on each other, but doing it without the loop should fix that right up. ( Or a slower, more relyable loop extension. )

Good luck with this. I'd like to see if you can actually get it working.

[Serephim]

Bumped out of curiosity.

Does anyone know if that new physics extension for MMF covers this? Im thinking about trying to experiment with this.

[sonikku x]

Just posting to subscribe to threads I'll look into later so I know which ones to read.