(November 2018) Monthly WIP & Screenshot thread

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. :slightly_smiling_face:

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.

3 Likes

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.

12 Likes

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.

1 Like

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 :wink:

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?

10 Likes

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.

5 Likes

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.

7 Likes

I imagine them making “generic business sounds” interspersed with “my card” “my card”…

5 Likes

Your first image there is giving me some strong ASDF vibes

7 Likes