After following some conversations about bullet and zay es I started to implement my own library to connect those pieces. It is far from finished but I build a little example how to use it. I think it isn’t that complicated to couple zay es and bullet. Maybe this example could be a help for those of you trying to accomplish the same task. If you have some questions or improvements don’t hesitate to ask.
To give some information: I have a BulletSystem which only have an update(float tpf) method. It handles the conversation of the es data to the physics engine and back. To use bullet you only have to add some special components (of course free of spatials) to your ES and call this method every now and then. As a result you can use your own update loop and don’t have to rely on the StateManager. Of course I have implemented an AppState which handles calling the update method for those of you who rely on the StateManager. You can even use the BulletDebugAppState.
I finished the first release of this library and went that extra mile uploading it to bintray.
What does this release include?
BulletSystem - the main class which updates the components based on the physics engine.
ESBulletState - an AppState which encapsulates the BulletSystem and calls its update method every frame.
Lots of components for RigidBodies and GhostObjects (Force, Impuls and Velocity)
A component for collision
Some examples (e.g. the wall example from the jme3-example project)
How do I use it?
You have to use gradle:
Add these lines in your dependencies defintion:
(sorry I don’t know what went wrong with the formatting)
Now you should be ready to copy some of these examples:
How do I add features?
- ask me
- write your components and a sub PhysicsSystem which can be hooked into the BulletSystem
- obtain direct access to the PhysicsSpace through BulletSystem.getPhysicsSpace()
I hope some of you find it useful. I won’t add new features to this library for the moment if no one asks because I don’t need them.
Edit: Got approved in jcenter. You don’t need to add the repository to the gradle file anymore.
Does your code already include something like the BetterCharacterControl?
It could be that it makes sense to include that behavior into specialized systems instead of the already available controls.
Btw: I guess you figured that out on your own but: Single Backticks only lead to that
text whereas you need three backticks return code return three backticks, where you can specify the language directly after the first 3 backticks.
No yet because I think a good character control is very game specific. Nevertheless I will try to make a generic one out of mine. Do you have any requirements? I think these features could be important:
- not flying over hills
- maybe stair support (could be replaced by ramps in a smart level design)
Is there anything I forgot?
Well, maybe we can have a set of options for many possibilites or make it a bit modular (e.g. how can you add “double jumping”, which some fast paced games have).
BCC sets the friction to infinity (or something) while it doesn’t warp the player. On one hand this is bad because you want your bcc to be effected by explosions and the like but on the other hand this might be required to prevent the drifting away the capsule has?
This however is alo related to the hills/ramps: A character (human) can stand on say 20° ramps, but as opposed to BCC it would slowly drift away at 90° (Though I guess games like assasins creed would need a completely different character control).
Other than that I hope that I have the time to try it out the next weekend
Edit: Coming back at BCC: There are some forum posts and modified bcc which might give you an impression over the pitfalls/problems a character control has (e.g. when you jump against a wall and press walk, you are glued to it).
Another thing I just remembered: Acceleration and Deceleration (Or rather momentum?
Masseträgheit) is what you feel in some games. Personally it just annoys me, but might be a design consideration.
I would implement this “set of options” as single components with its own systems which change the physics state or other components.
I’m testing some prototypes of character components and doing my research about BBC. But I’m very busy doing an university project. Give me a bit time and I will show my results.
Do you/gamers really like acceleration? I always thought delay between key press and movement is bad. Maybe there is a difference between a shooter and a role play game. Or do you mean that a player becomes faster after two meters? I think that could be done by the user of this system. If you want to increase the speed every second you have to set a higher value to the movement component every second. Or am I missing something?
Nevertheless I added some javadocs and fixes. Now it should be easier for you to test the library. If you have any questions and comments don’t hestitate to ask. By the way the new version is 0.1.1.
No worries, I finished my bachelor thesis last week and had an exam on friday.
I now took a look at the library, but it still takes some time until I can understand it in it’s entirety and especially migrate all my code to it.
What is your impression, do you think it is relatively easy to implement the bullet parallel threading type? I saw the comments but can’t judge the complexity.
Personally I don’t like that behavior, but I don’t think about lag or acceleration during walking (because in reality you are also pretty fast at accelerating). What I meant is the
Moment of inertia, the same effect you have when using steering behaviors. I first noticed that in GTA 5.
When you start to walk there is some acceleration effect which could also be some clever animation trick, I don’t know, however when you try to change directions while running (e.g. trying to strafe left when you were walking forward), you feel the “understeering” effect you would have when driving a car. The character still has some impulse in the forward direction.
So technically speaking: instead of setting an impulse each tick you should rather control the character by adding forces on it which lead to impulses (to have that integration component in, you also have on steering behaviors, so to say).
I have just implemented it in ESBulletState. You can select the threading type in the constructor.
I finished my next release. In this version I have a set of components which won’t change any more. Those components give access to the most important features of bullet. The BulletSystem is also more stable and the public methods won’t change. Meanwhile I started to develop my own debug view because it’s very difficult to use the bullet debug view without 3d models (you only see coloured lines). And I improved the ESBulletState with multithreading options.
As you can see I have finished all important preparations to create a character control.
Now I know what you mean (thanks for the great explanation) and I think it will come for free when I “only” use forces to move the character. Of course I will have to use some other tools then forces to cheat at certain unwanted situations. I will address the “hill flying bug” first.
May I ask what kind of game are you developing?
Random stuff that may or may not be useful:
In Mythruna, I used a similar ‘driver’ approach that I did in the Sim-eth demos. Basically, objects controlled by the player (or other actors) have a driver that directly applies forces for the object. So when the player pushes forward, we supply a forward force. When the player turns, we supply a lateral counter force to prevent sliding and so on.
Unlike in the sim-eth demos, the Mythruna driver also has access to the collisions/contacts that frame. This allows me to adjust the forces base on whatever logic I choose. For example, lateral counter forces based on friction with the ground. Automatically climbing steps by supplying an upward force if running into short walls, and so on.
May or may not provide any inspiration but it seemed like a relatively good solution… presuming the info is available to hook into and so on.
Judging by the CharacterTest I played around with this is already “implemented” actually. But now that this is a consideration: How can you get rid of that behavior without using impulses directly (Because an impulse might bypass friction and such)?
It essentially is a FPS with the Open World Buzzword (which is the entire reason why I took an ES, to use some paging and seperate the game logic from the view).
It will however also get some RPG features and currently even has a “grapple hook” (Some manual joint creation to have like a physical winch)
Edit: I can’t use your new debug app state because I am missing the assets from the assets folder. Probably they aren’t contained in the jar? Maybe it works when they are put into the ressources/ folder?
And: Currently the Character has too much slip, what if you add a high friction? that would affect the acceleration in a bad manner
r u preparing for a release?
“But be warned that there could still be breaking changes in later releases.”
should I use the one released on feb. or clone the latest?
To run the examples you have to clone the repository import it to your ide with gradle and run the wanted example.
If you want to include it in your projects you can use the latest but old release on bintray or build it yourself and add the jars to your project. Nevertheless I will prepare a new release in the next days. There won’t be many changes to the core any more. After testing it multiple times and writing many examples I am very happy with it so far. There is only a little bug with the composed impulses that has to be sorted out but you probably won’t even use that feature. Just look through the examples adapt what you like and tell me what you don’t like