Finally you may want to put both mphys and bullet integration under the same interfaces, so it would be possible to switch from one to other with no effort.
Itâs not really possible. I left the bullet integration floats and mphys is double all the way. Plus, the whole point of the mphys library is the zoned loading/unloading as they become active/inactive and there is nothing like that with the bullet integration.
Also, in the end I expose many raw implementation specific classes on both sides.
âŚwhich reminds me, I still need to implement control drivers on the mphys side.
Plus, feature-wise there isnât really much competition. If you want mesh-accurate and robust physics then bullet is still the way. If you want a physics engine that has âinfinite worldâ support built in and allows you to 100% customize the collision detection (with a block-based collision system all ready to go) then mphys is kind of the only answer.
So there are significant limitations either way and not likely something youâd swap back and forth.
I see. Thanks for explanation.
WIP, I need to make runes flicker or something like that and add one more flash at the end. Of course the whole animation need some sound.
But all that being said, Iâm trying to keep the patterns the same as much as possible so that learning one is directly application to learning the other.
Hello again guys!
So this post isnât really about jme, but it is pretty interesting I think so I figured Iâd share. Also I need a few playtesters
As the story goes, a few weeks back I got a university seminar assignment to make something in WebGL. Not anything as substatial as you see below was required but Iâm prone to going overboard with this sort of thing despite basically working with matrices and my bare hands instead of a rendering engine.
So me and a colleague of mine decided to make a NodeJS based multiplayer browser game by basically cloning World of Tanks with low poly comic graphics and a counter strike source like server setup. It uses Ammo as its physics engine which is basically a really shitty javascript Bullet port (and one from 2011 that was still compatible with Node) that can only use primitive colliders so the collisions are kinda approximate.
Oh and itâs completely server authoritative, which was really important to me as an excercise, but also as a good practice I guess.
@pspeed Iâve also put your drop shadow idea to use, albeit with just doing it in the material shader for every tank since theyâre the only moving thing. The rest of the shadows are blender cycles baked.
Well funny thing though, unlike a post about a jme game you can actually go play this one right now here: http://warzonegame.chickenkiller.com. So aside from WebGl supporting jack shit in terms of advanced shader features this is still a really cool way to deploy with none of that Steam complicating and access to a wider audience. Btw server is on Scaleway and is Amsterdam based so it may not be best ping-wise for the Americas, so take that into your calculation.
It also technically runs on phones really well since the shaders and meshes are lightweight but the gui may be a bit broken and it needs a mouse and keyboard to actually send any inputs so at best you can spectate.
I feel like it would be really interesting to make this scale horizontally with one master matchmaker server starting actual game instance subservers for each match, but I have no idea how that would even bind together to a port on the same physical server with only one IP. Anyone ever heard of how that is generally done?
Drop shadows make a big difference, eh?
Would be interesting to see with/without pictures side-by-side. Because what youâve posted looks pretty âproâ already⌠and I bet the shadowless version looks decidedly less so.
Pretty Neat! The controls seemed to lag a lot, probably due to the ping. I assume there wasnât any sort of client side prediction?
Damn straight, here you canât even tell where the tank ends and the ground begins. It looks, I believe the technical term is âlike assâ. Drop shadows definitely add a lot of brain spatial recognition helpers to the scene.
https://i.imgur.com/2y2NjU0.png
Actually there is some basic linear extrapolation code which fills in for the missed frames otherwise it would be really choppy, but with high ping it probably wonât be able to compensate well and it doesnât really do the whole âimput controls immediately then sync when server confirmsâ concept since the client is kind of a dumb terminal and doesnât really know anything much about the world space. Again, the server is in Amsterdam so itâs probably only no-lag playable in Europe.
I didnât really look up any established way to do predictions and just kind of winged it for now.
I wanted to start adding control drivers to mphys like Iâve used in my other physics engines. One of the easiest ways to test it is to have a simple control driver thatâs just supposed to keep an object upright (ie: kill non-yaw rotation). I needed a nice top-heavy object and since the next logical step is usually some kind of wander behavior⌠I loaded up my BlockEd app and made a quick-and-dirty pixel man, nice and top heavy.
To test it, I replaced one of the shoot objects with pixel-man. Shooting him around was pretty fun, actually. Oddly shaped objects always fly funny on contacts.
And they look kind of funny piled around:
Sometimes 10 minutes of effort is very rewarding in game development.
I imagine them making âgeneric business soundsâ interspersed with âmy cardâ âmy cardââŚ