Fizzy integration on MarteEngine

[Gornova]

I wonder if is possible to add on MarteEngine, Fizzy: http://slick.javaunlimited.net/viewtopic.php?p=16141 a Jbox2d wrapper :D

My idea is to have all the physics stuff addable on each Entity and World take care of the rest. There are many issues on this approach:

• Body (https://bob.newdawnsoftware.com/repos/slick/trunk/fizzy/src/org/newdawn/fizzy/Body.java) have all the stuff of a physics body (shape, angle, density, friction, etc..). How handle this on our Entity ? Some property (I'm thinking about hitbox) are handled here.. better approach is to Extend Entity with a FizzyEntity?
• World (https://bob.newdawnsoftware.com/repos/slick/trunk/fizzy/src/org/newdawn/fizzy/World.java) in Fizzy contains all the body.. so we can think to extend our World and change update stuff only ?

I think that integration is possible but first step must be extend our object, not change it directly and see if it's working :D

[thaaks]

I think adding a physics engine like Fizzy is a good idea. I'm not sure yet what would be a good approach. Because for many games (especially the simple ones) you don't need all this physics stuff. So having a subclass like FizzyEntity would allow us to use the fizzy Body instead of our own "homebrewn" entity instance variables. BUT! This would mean we have to say goodbye to direct instance var access and switch to getter/setter methods completely to allow proper encapsulation of the Fizzy Body in our FizzyEntity.

Let's tackle that when we're done with 0.2 ;-)

[Gornova]

I move this to 0.4, better stay on focus on stability then extend

[nanodeath]

If it makes development any easier, I'd like to point out that I've uploaded Fizzy to GitHub on my account, here https://github.com/nanodeath/fizzy (with Kev's permission). Most of the tweaks I've been making have been in order to surface JBox2D properties (like isBullet, FixedRotation), but I also upgraded Fizzy to be compatible with the latest edge version of JBox2D (woot fixtures). Even if you don't want or like my enhancements, there's a tag, "kev", that corresponds to the last commit that Kev made (that is, the last commit when I imported the tree from his SVN repo), that you can reference.

[thaaks]

Great to hear that you continue to work on Fizzy. I think we will definitely take a look at your version when we start to tackle real physics for Marte! Thanks for pointing us to your version, highly appreciated!

[Gornova]

great news! Nanodeath, you must write this on slick forum, community could help or be interested in use it!

[nanodeath]

http://slick.javaunlimited.net/viewtopic.php?p=20468

Happy now? :)

[Gornova]

yes! :D

[nanodeath]

Actually, of somewhat higher concern is how tightly coupled the current "lite" physics solution is to the core objects -- even Entity has the "lite" physics baked in. I'd consider using MarteEngine + Fizzy, but there'd basically be two engines running. You actually touch on this in the original post, but I guess I wanted to maybe propose something like moving "lite" physics engine to its own module in 0.x, and adding Fizzy support in 0.{x+1}...

I can't provide any counterexamples against creating a FizzyEntity subclass, but I feel like this would be better solved with composition. What an entity is is not entirely encapsulated in whether it has a physics representation or not...

That said, it's highly unlikely that a developer will want to use multiple physics engines, so I think instead there should be something like...ME.physicsEngine = Engine.FIZZY; and then "give" objects physics on an as-needed basis. This can be done either with:

1. a givePhysics(); method in the constructor of an Entity
2. a @HasPhysics annotation
3. Simply giving some protected variable (i.e. protected PhysicsEntity phys;) a value at all.

The main hazard I see with composition like this is it's yet another layer of abstraction. You'd need a PhysicsEntity interface and a FizzyEntity representation, which is a layer on top of Fizzy's Body, which is a layer on top of JBox2D's body.

Perhaps a hybrid approach would be best. Simply give each entity a liteBody and a fizzyBody, and then the global configuration will determine which to actually use (that is, methods in the Entity class would check ME.physicsEngine). It does clutter the class a little, but it's either that or the above-mentioned layer of abstraction that we don't really need.

p.s. stop using Hashtable! That's from Ye Olden Collections. Use HashMap instead; it's not synchronized and should be faster.

[thaaks]

Hi nanodeath, can you show me where Entity has lite physics baked in? This is not intended. Speed, angle and scale are in but those have nothing to do with physics. All "lite" physics stuff should be part of our PhysicsEntity class.

I haven't yet thought about how to integrate. The lite physics should move into a separate package, I agree with you. And I also agree that a user only needs one physics engine at a time. But because of that subclassing might be a better approach than composition. Composition implies (as you already mentioned) another layer of abstraction and it implies different behavior/switches/if-else in the code. So here subclassing helps to separate the two physics implementations better. Entity itself is pretty basic and shouldn't interfer any of the physics implementations. Let's argue a bit back and forth to find the optimal solution.

Regarding your p.s.: Thanks! I wasn't aware that Hashtable-HashMap is similar to Vector-ArrayList. I or Gornova will fix the code and I hope to use HashMap from now on. Makes sense of course!

[nanodeath]

Well...I'm just confused then :) In Entity#update, the position is being incremented by the speed vector -- this seems, if not actually physics-related, then movement-related. When I render my physics entities, the position is determined by the position of the underlying body object -- same for angle (just stating the obvious here). The important part isn't whether there are actual physics involved or not, rather how the angle and position of an entity is calculated.

So...I guess my point is, can you clarify on how speed/angle aren't physics related? (Scale isn't, I'll give you that)

Regarding subclassing vs. composition...as nice as composition sounds to me, it IS more abstraction, and yet another layer of abstraction (and proxies! 25%+ of Fizzy is just proxying to JBox2d, I feel) for...I'm not sure what benefit exactly. While I would love to be able to have an Entity object and just plug in this physics module and that sound module and those...other...things...I feel like physics really is integral to the entity. It determines where and how images render, whether something was destroyed, whether a sound needs to be played, etc. Graphics and sound aren't pluggable; you're just saying "use Slick!", which is fine, but...I'm not sure what other modules there could be, really. Admittedly, I have barely any game dev experience, but having difficulty coming up with any other components as significant as physics does suggest that FizzyEntity would be okay to use as a base class.

[thaaks]

Okay, now I see your point. So there seems to be some overlapping regarding speed and angle. It's in the base Entity class because it helps to create simple movement and image rotation for simple game entities. But I agree: those variables are also very important for physics based entities. But I would'nt want to remove them from the base Entity class because many games can get along with just that without the need to touch any other physics related stuff (like bodies and joints and so on). And MarteEngine's main purpose is to be simple to get you started coding games. In the simple case of just using Entity the game developer modifies angle and speed to move his entities. In a physics world the environment, collisions and gravity affect position, speed and angle of an entity. And I consider using "real physics" like Fizzy an advanced mode for advanced users of Marte.

Did I get it right that you also suggest subclassing for FizzyEntity? Sorry, but english isn't my native language so sometimes I don't get things right at the first time ;-)

[Gornova]

I think that subclassing seems to be more simple and fast to develop?

[nanodeath]

I think my point was that in Java, it's simply more pragmatic to use subclassing in this case. Some other languages may make the composition route feasible (like Ruby, say, which uses duck typing and thus would let you assign the "body" object to FizzyBody, MarteBody, WhateverBody), but here...I think subclassing is easiest :)

[thaaks]

Agreed :-) Yeah, some languages make composition really easy, for example Scala offers Traits which would fit here pretty well too. So I would suggest we try the subclassing first as soon as we start dealing with Fizzle. Right now I still have some particle issues to finish ;-) But I'm looking forward to get in touch with a real physics engine!