I decided to stop spamming the screen shots thread with videos and download links for now.
So, I’ll just create this thread here.
I started making a simple 2D space shooter game to test a network synching library. I haven’t added the multiplayer parts yet but the game is architected for it. This will all be open sourced when it’s further along.
The working title is “Ethereal Space” because the working title for the network synch library is sim-ethereal. Both subject to change at my whim when I get closer to publishing. Heheh.
Yeah, it will be built on top of Spider Monkey (I wrote Spider Monkey, too. :)).
This is for doing object position/rotation synching in real time. It uses spatially defined zones + lots of compression to send the state for a lot of objects at once… and only for the zones the player is interested in.
Sounds pretty nice. Is this sim-ethereal going to be something included with a future version of jME?
As for the game, what type of game is this going to be? 2D space combat arena? I remember playing a multi-player 2D space combat game a long time ago that was really quite enjoyable. Just a bunch of space ships flying around shooting each other.
Probably unlikely. We’ve said many times that this level of tech tends to be pretty specific for a subset of use-cases and I think folks will see that’s true when I push it out. So while I think it will be useful for a variety of games there will be certain tradeoffs I choose that may make it unsuitable for a large number of other use-cases. But really, if it’s a plugin then I don’t see the difference and I’m one of the ones that feels like half the stuff we include in core should just have been plugins anyway.
Yeah, pretty much. Space ships shooting each other. With some asteroids bouncing around… and maybe some random enemy ships to make it interesting. The open source version will be pretty simple but I have a non-open source version planned with a bunch more features and more to do between combat matches, etc…
Makes sense. I usually try not to give people code snippets and such that I feel are too case specific or otherwise not really useful for any application other than what it was made for. In that case I feel an explanation of how it works is more useful because it doesn’t rely on a bunch of variables and methods that don’t make sense out of context.
Sounds entertaining, certainly looking forward to it!
@Tryder, are you talking about this game I made long ago?
It is probably not as advanced as this one but it was my attempt at making a space shooter. @pspeed, on my PC it doesn’t work. The game runs and the engines fire but the ship does not move.
Also no “pew pew” …
I think there may be a tight chicken and egg problem in the entity system ordering that happens only rarely. I fixed one and I suspect there might be one more.
I really need to beef up logging and make it persistent and rolling so that I can more easily capture these things. I’ve been trying to standardize it even but my config is always log4j specific.
I used dyn4j because I need 2D physics, not 3D physics. The complexity of a physics engine between 2D and 3D is exponential. I don’t even begin to know how I’d make accurate 3D collision shapes for my 2D sprites. And all the extra math involved in 3D calculations probably reduces the number of objects I could handle to about 10% of what I could do with dyn4j.
The networking API just publishes position+orientation… it doesn’t care where it came from. As long as you can hook the end of the physics frame and grab this state then anything will work.
…the force fields I did by using some of the laser beam sprites on a fork of unshaded that allows me to supply a texture offset. So I just scroll the y-coordinate of the texture 8 times a second or something.
Then I encourage you to have a read to the link above (Emphasys mine):
Deterministic lockstep is a method of synchronizing a system from one
computer to another by sending only the inputs that control that
simulation, rather than networking the state of the objects in the
simulation itself
It depends on a lot of factor if the lockstep approach is viable. The main one is latency. In any game that depends on low “input to action” latency the lockstep method can be ruled out. Simply because it requires a few roundtrips to send, validate and confirm each step.
In other games however, mostly RTS types of games, it is used a lot. Unfortunately it is also a bitch to implement because every the slightest difference in the simulations can chain-react to game changing deals.
As i tried and failed a few times to implement a system like that i can give you a pretty nice example what happend to me: (and i never succeeded in implementing it correctly)
RTS style game, everything is locked, even the frames per second. Two units shooting at each other. Due some slight lag (not noticable) on client 1 the weapon timer fired on frame earlier than client two. Sounds pretty meaningless, since we are talking about <16ms difference, but in reality, and in big battles, that could and can mean that the bullets fired will hit different units. Maybe resulting in a death of one unit on client one and not on client two.
Beside the fact that it is pretty hard to implement such a fully framesynched stepping, it is even harder to track issues down the the origin of the problem
It sounds like shared dead reckoning… which has 100 different issues.
This is what I mean by the fact that each type of game will have different requirements. While SpiderMonkey can be used as the basis for just about any networked game, pretty much anything higher than that will have trade offs.
Mine is based on the approach valve uses for the source engine. Local object state is broadcast only to the clients that are interested. And only what’s changed is broadcast. I also add some compression to it based on required precision. (This also limits some types of cheating, by the way, since users are only ever aware of their immediate surroundings… their clients don’t even see events about anything else.)
There are drawbacks. Latency degrades one player’s experience while others operate just fine. The lock step approach, I guess everyone is operating at the worst person’s latency.
To me, most physics based games are automatically squishy just by the nature of acceleration. This can pretty easily eat some of the latency. Insta-kill style twitch weapons seem to be the only real issue. Even in Valve’s case, the only synch problems they really have are for guns that aren’t simulated by actual projectiles.
…and I think a large variety of games could avoid those types of insta-kill weapons and be fine with the type of physics synch I’ve already built. (Which is the other key point… I’ve already written this into two different prototypes and now I just need to package it properly.)
