at the moment I’m struggling with implementing physics.
The problems are as follows:
I have a client and a server side. For Lag compensation I would need to step back or save the physic space’s states (like it was recommended in “Decoupled Physics”). This alone wouldn’t be the problem.
-I have a world that should be practically infinite. That’s the main problem: Either I seperate the world in several pieces, but then I can’t use bullet anymore, can I? Or I use doubles in physics. Changing that seems too much work, that I’m on top of that very unexperienced in.
Using just bullets intersection tests and writing the rest myself would be too much effort I think after reading the “Game Engine Architecture” (by Jason Gregory) chapter about physics.
So do you have recommandations for me what I should do? I wan’t to start walking around in my world
Basically you move the world instead of the player. Physics is just applying some locations and rotations, you’d have to use the base physics objects and run the physics space yourself, getting whatever information you need. But seriously given how unexperienced you are I guess starting out with an endless world with collision and stuff isn’t exactly within your reach yet as apparently you want to network it too. Our own @pspeed does all this in mythruna but he is a seasoned developer with over 20 years of experience. I guess if you want to learn game development start smaller and if you just want to “have your world”, use some FPS modding system or similar thing.
Basically you move the world instead of the player
That seems a bit strange within multiplayer, doesn't it?^^
you’d have to use the base physics objects and run the physics space yourself, getting whatever information you need
So you say I should do simple physics by myself? (Indeed I don't need very much of it: Walking characters, flying arrows and maybe flying magical spells. Later maybe more stuff like blowing away incoming arrows. The stuff that I'm unsure about is especially the collision resolution. All this would be easier with something that's already working ;) )
Stuff like ragdolls would be nice but thats only needed on client-side where I can use bullet (and it can be added later).
PS: Giving up is not an option ; )
If I'm informed right, Empire_Phoenix started out similar and look where he got. It takes time but I will get something playable upon which I can improve.(<-- Not sure about grammar^^)
The camera stays in place, the world moves. Effectively theres no difference to the player but you avoid high numbers for spatial locations etc.
I say you will have to handle the physics using the base objects (PhysicsRigidBody et al) yourself as you can not use the physics controls for this then. You could create similar ones that apply the locations in this inverted way. Like I say, its a task for somebody experienced in programming or willing to take moments of frustration and intense research and learning. Empire coded and learned a lot with jME2 already.
Normen’s points are still 100% valid but I thought I would clarify at least one point.
Mythruna does the “world moving” thing on the client to avoid a lot of issues but physics is done globally using doubles and my own custom physics engine. So in the “server” the world is in doubles.
It does seem like you are biting off more than you can chew, though.
If rebuilding bullet for doubles seems daunting then maybe you should simplify your goals.
Note: you will still want to partition your world into local active physics spaces. An endless world with an infinite amount of physics going on is not really going to perform well. Keeping track of active physics zones and/or merging them as players move around is a trick unto itself.
@enum said:
- I have a client and a server side. For Lag compensation I would need to step back or save the physic space's states (like it was recommended in "Decoupled Physics"). This alone wouldn't be the problem.
or willing to take moments of frustration and intense research and learning.
If you never try you will never get it done or learn something. If my goal is too simple I get bored quickly.
Maybe it's really a big thing I'm doing right now, but I'm having more fun coding and thinking than with everything else I did before. That matters ;)
If rebuilding bullet for doubles seems daunting then maybe you should simplify your goals.
The problem is, that I never worked with native libraries in Java and so I tried to avoid this. But thats why I opened the Thread, to learn which solution would be simpler.
So I can conclude from your reactions that empire's way is the easier one?
An endless world with an infinite amount of physics going on is not really going to perform well.
I guess you guessed that I wouldn't want to load the "whole infinite" world and all its entities ;)
Keeping track of active physics zones and/or merging them as players move around is a trick unto itself.
Yes, I thought about that when I was thinking about using the sector-approach I mentioned above.
Note: I also don’t intent to worry about lag compensation on the server as Mythruna won’t have any “instant” weapons like rifles. Everything will be physics-based and so lag compensation isn’t really needed… ie: if you wanted to make a head shot with a bow then you had to account for arrow travel time anyway… lots of slop in such a system.
If its a networked game people might run around in lots of places, you still should partition.
I wouldn't have done it different. The terrain loading works already in a divided way and works very well with two machines connected.
I am not as experienced as pspeed (that's impossible :D) but I'm not dump ;)
If you find something that can help, wil you return there to share the logic please? XD
I will see if I find something good and will then let you (all) know and/or share code. I hope you would do so, too ;)
(I am not very fast at the moment due to university stuff, for the next 4 weeks. But then I have 6 weeks spare time :) )
Edit:
I also don’t intent to worry about lag compensation on the server as Mythruna won’t have any “instant” weapons like rifles.
Yeah, that thought made me a bit relax concerning lag compensating when I thought about it a few weeks ago. Nevertheless I build the system to be able to do lag compensating if it should be neccessary for very dynamic fights. I do not know, what you plan? Fighting more like Minecraft, like for example Fable or in between?
@enum said:
Yeah, that thought made me a bit relax concerning lag compensating when I thought about it a few weeks ago. Nevertheless I build the system to be able to do lag compensating if it should be neccessary for very dynamic fights. I do not know, what you plan? Fighting more like Minecraft, like for example Fable or in between?
I plan physics based fights. Anything that isn't instant then there is already a built in expectation of a delay. It's the instant rifle head shots where lag compensation comes into play and you need to make sure that the play didn't see an event that the server then rejects. It's only important for instant effects.
Anything like shooting a bow or swinging a sword or whatever, the player already feels the lag and can compensate on the fly.
re: "The terrain loading works already in a divided way"
Terrain loading is a little different I think because that's client only. For physics spaces on the server you need to manage what's active and what isn't on a global level. Either you center active zones around the player and somehow merge them when two players meet or you pick a fixed zone allocation and just activate them as needed. Then you have to decide what to do when a physics object crosses from one zone to the other... whether that makes that new zone active if it wasn't before... how far away from players do you allow zones to be active, etc.
I have the server loading the terrain because the server manages the entities. When a malicious client doen’t ask for those terrain chunks where important entities are around him, this would cause problems^^ So I decide on server side which chunks are needed.
Of course you are right that merging these active zones is much easier for static terrain (take from cache instead of freshly generating when it’s available) than for moving stuff.
Anything like shooting a bow or swinging a sword or whatever, the player already feels the lag and can compensate on the fly.
I will definitely try it first without much compensation and implement that when it nevertheless seems neccessary.
If someone has any more inputs concering physics, I am grateful for every advice ;)
ACtually rewriting the jme bullet binding to a 64 bit version is somewhat doable in a few hours (make it 1-2 weeks if not experienced with c++ and the binding)
Since I “only” need relativly few physic objects in a smaller solar system scale that resolves me from doing partitioning. (Players a pushed back more and more as they reach the limits, untill they cannot go out further)
On the client I do the move world around player thing then as well
Lag compensation/prediction is only planned for player movement, but for nothing else, as there are no instahit weapon and larger masses like vehicles do need a few ms to reac in real-live as well due to momentum.
Note: even the valve articles (links provided if needed) only do lag compensation on the server for insta-hit weapons like bullet weapons. Rocket launchers and stuff they say don’t need it.
So I will read all hints @Empire_Phoenix gave all over the forum about building bullet withs doubles and take this way. Nice opportunity to learn how JNI works in detail.
He just thinks this is the wrong way, as he state often enough. if you really need enless worls this wont help btw. for limited but larger worlds this is a working solution.
