JOODE : practical use for games

Game Mechanics
#1

I thought about how much generic JOODE can be without being useless.
I explain myself : sometimes you have gameplays ideas that needs physics that aren’t as the real world, and you have to use tricks to realize that.
E.g. : take a 2d mario-like platform game. You want your personnage to remain upright. You can reset its rotation each step, but it :

  • isn’t clean
  • cause bugs
    So the best solution is to write your little physic engine yourself.
    It’s not the only case where a physic engine isn’t adapted.
    So JOODE may be better suited for industrial simulations than games. ( :\ )
    Another thought : we should split more our discussions : one topic for each programmation aspect.
    I don’t have the time to look at the sourcecode right now (I should release a beta version of my game soon, and I have a lot of work todo) but I’ll take a look later. I’m still interested and engaged.
#2

I’m planning in the coming months to write a racing game as a jogl applet. having joode available would help me integrating good physics modeling (although I’m not sure i’ll use it : i might go the “fun” way and don’t simulate car collisions with a physics engine). joode would help me to avoid signing that small game.

I’m also thinking about a jogl applet showcase, where everybody could plug a small opengl demo into a larger applet. joode in that context could boost some of the demos included.

My 2c’

Lilian

#3

So JOODE is just good enough for demos ? :-
Maybe we could add non-realworldphysics behaviors with special classes (I’ve no idea how… but that would be cool.)

#4

mmh a possibility to simplify some calculations (e.g. by simply ignoring some test cases or not applying forces automatically…) would be way cool. :smiley:

So we’ll have to think of a way to controll such things. Actually I think this might be very similar to the Xith-problem of acessing OpenGL/LWJGL directly during the program flow.

Let’s see, if we can find a good way of doing this.

#5

While a true physics engine like ODE is probably overkill for a mario-like game (it really depends on what you are trying to do in the game, it could be fun to have “real” physics), there may be simpler solutions:

  • you don’ have to render using the rotation angle, then the sprite is always upright, though this would cause problems with the rotation causing problems within the simulation when interacting with other objects.
  • I know very little about ODE at the moment, but can you not set hard constraints? I.e. can there be an infinitely strong force holding the sprite’s rotation in place?
  • Is there a way to hook into the objects to balance forces with artificial ones? So you could write a simple filter that would make sure the rotational forces always sum to zero for an object. I could see this as an extension of connecting player controls, such as thrusters for a space ship.
#6

It should be fairly straight forward to invent new joint types that provide contrainst that fix things like an ordinate or rotation in a global sense. Thus you could be able to do 2D platform stuff fairly easy. It would be harder to force the collision systems default primitives into a 2D envorment without wasting resources, however writing your own collision system and plugging it in would be fairly straight forward.

#7

I think so. I hope we’ll find a solution.

ODE is not built on a spring system, so you can’t do what you suggested. But you can reset the rotation each step, but it causes bumps when the object moves.

Yes and these joints should remove the rotation calculations or the performances will be bad.
How, and I really think we should make collision system pluggable.

#8

I don’t understand. Physics is physics. f = m * a applies regardless of the use of springs. Are you saying there is simply no way to inject a force into the system or filter out an undesired force component to artificially balance the forces on a body?

I basically suggesting that rather than resetting a position or rotation, that there be a way to prevent a (unbalanced) force from applying to movement on that axis of translation or rotation in the first place.

I admit I am speaking from ignorace of the ODE system though. But I wonder how constraints are placed on the system to begin with… i.e. if I wanted to model the classic amusement park test of strength game where you hit a lever with a mallet to send a weight shooting up a rod with a scale, toward a bell at the top… I hope you know what I mean :slight_smile: Anyway, how would you keep the weight on the rod? I guess that “sliding along a rod” thing is a special kind of joint? … actually I’m pretty sure that is a joint.

Now with a free body, call it “Mario” :), how does a special joint prevent rotation? If the joint is attached to Mario, what is the ‘other’ end of the joint attached to such that Mario can move around on the 2D plane, but not rotate?

It’s sort of interesting to apply a “real” physics engine to a 2D mario-style game like this.

#9

Yes, what you say is correct - As far as I understood the whole business, the joints simply apply forces to make sure the joint-restrictions are preserved. So actually both methodds of dealing with the problem would be equivalent.

BUT

If it is possible for joints to do more than this - Joints would be the way to go, because it’ll make calculation faster and the joints more stable.

#10

Wow ! I get pretty confused when I read all these thoughts…

Joint is a pretty undefined thing in my mind. Is it just :

  • A way to “attach” two bodies to obtain a specific behavior
    or
  • Something that apply a force each step ?

I abandoned ODEJava a some weeks ago but what I remember is when I was resetting the rotation there was bumps in my character’s movement.
It’s simply because :

  • Forces are applied to the body and it moves as realworld physics would
  • The collisions are detected
  • I reset rotation
  • The collisions are applied
    Or something like that (I can’t remember exactly)

We could probably make the physics “adaptable” because I think the realworld physics are pretty boring for most game cases. So if we could remove “features”, such as gravity (made in ODEJava), rotation, or inertia, or add some : air resistance…

I’m sorry I’m giving so general and vague ideas… but I have no clear idea presently…

Anyway it’s very interesting, I’m glad there are still some people interested in that…

#11

For sure… I think it would be cool if we could “change the rules”… e.g. make the force of gravity act more like a spring pulling objects down, or have surfaces with inverted friction characteristics, so they didn’t counteract a force, but complemented it to increase the force vector… making “super ice” that was “less than frictionless” :slight_smile:

For your rotation problem, that’s where it makes sense to implement the “rotation stabilizer” as a joint. Then while forces are applied the “joint” could constrain the rotation forces so that they are always 0.

#12

[quote]So if we could remove “features”, such as gravity (made in ODEJava), rotation, or inertia
[/quote]
Not remove, but the possibility to unplug those. Or to change them by setting the reaction with interfaces.
i.e.:


interface Reaction {
  public void execute(Body b); 
}

it could then be used like this:


class Gravitation implements Reaction {
  public void execute(Body b) {
    b.addForce(0,0,-10); //if z is up
  }
}

or


class AirFriction implements Reaction {
  public void execute(Body b) {
    Vector3 v = b.getVelocity();
    v.scale(-0.1f);
    b.addForce(v);
  }
}
#13

Yes !!
It’s really a good concept I think.
We should dig that more, I’m sure we can implement other game ideas with that.
Hmm… could we do slightly more complex behaviors/reactions ? How about a pre-made boucing ball ? You just have to adjust its mass, bounce factor… We could do many more predefined objects like that. Or if you don’t like that system we could just make a list of examples “How to do platform movement with JOODE”, or “How to have proper car physics”. I think it’s good if we think of JOODE as game-oriented rather than realworld-physics-oriented.

#14

[quote]I think it’s good if we think of JOODE as game-oriented rather than realworld-physics-oriented.
[/quote]
definitely :slight_smile:

#15

[quote]Joint is a pretty undefined thing in my mind. Is it just :

  • A way to “attach” two bodies to obtain a specific behavior
    or
  • Something that apply a force each step ?
    [/quote]
    Joints enforce a constraint between two bodies (or sometimes just one body). The constraint is defined using a jacobian matrix. Using that archetecture you can make the two bodies hold an invarient to one another such as they must rotate around a certain relative point etc. It would be fairly easy if you understood these jacobian matrices to create an invarient that kept the body positionally in one plane or stopped it rotating. As for doing this economically without wasting computers resources on unecissary 3D calculations that is really out of the scope for one system.

[quote]Hmm… could we do slightly more complex behaviors/reactions ?
[/quote]
Actually I was doing this using javaODE. The first step to making the system easy to expand is having a well defined event system. The way I had it working was that when bodies, joints and geoms were created or destryoed they emmited an event. The were also of the type “Bindable”. Bindable objects could be bound to other bindables. When was destroyed all other bound objects would be destroyed. With this event system it was fairly easy then to add custom behviours to things. Behaviours were bindable and becuase of the event system they were tidied up when stuff was going on. The other main event model I added was an event system that delivered world.step() events.

So yeah, if you wanted a spring system added you could create a Spring and add it to a body. This would behind the scenes bind to the body(or bodies) and also register itself with the step event model. Every time the world would be stepped the spring could apply its forces. If the body (or bodies) was removed from simulation you would not need to worry about tidying up the spring becuase it would take care of itself.

It was kind of my intention from the start to add a good event model to JOODE becuase it makes it so much more extensable. If you want global behviours for bodies (like gravity) you can add code that listens for creation events and add bindable gravity behaviours to all bidies that are created.

Like I said I have had this kind of thing with my old system. What I also had with my old system was a generic way for behaviors to be defined. I did not actually like it though because to make it generic it basically ended up as complicated as just writing java code. What I did find really useful though was allowing behaviours to be defined in scripts (beanshell scripts actually). So I am thinking maybe it would be really good if we added that kind of support to JOODE. I am not sure if people will think its poluting the system though. I would suggest we add scripting support using whatever that standard is for scripting, thus not tying the user to any particular scripting technolgy. I would also suggest that scripting and dynamically loading behaviors should be transparent operations. So you add behaviours defined in scripts exactly the same way as behaviors defined in dynamically loaded classes (so you can gradually replace scripted code with compiled code).

Anyway, most of these concerns are secondary utill JOODE is working preoperly ???

#16

I totally agree with you.

I’m actually continuing my own little physic engine for my 2D game cause I need to release a version soon, but after that, I’ll take a look at the code and contribute as I can. So later we can add all these desired features.

#17

Okay, me again.

So I didn’t changed my plans, I think I will :

  • Make a “clean” version of my little physic engine (2D, no rotations, simple collisions, no complex algorithms) for a first version of my game
  • Merge with JOODE / use JOODE later

But I’m not sure how the 2nd stage wil be realized…
Do you think it’s possible to do a 2D/3D engine ? How will we be able to “unplug” some features (like rotation) ?
What is going on actually for JOODE ?

#18

a good (fair complex) 2d phisics engine would be a very nice tool to have, this game (gish) comes to my mind. It has the better phisics engine in a plataform game i’ve ever seen.

#19

Yes, you’re right, Gish has a really wonderful physics engine…
Any JOODE developer idea on 2D/3D issue ?

#20

Well beyond what I said last time, creating special joints that fix objects into a 2D plane or stopping rotation, no.
But I beleive those two ideas to be pretty interesting, so when I do joints I am gonna have a look to see if I can do that.