That sounds like a cool idea, especially for worlds where users are separated spatially. What you could probably do then is do your own implementation of the time-scaling (which you simply can’t use on a server that hosts people that should not be effected), and when bullet-time ends, simply let the group “jump” forward in time so everything is synchronous again.
The issue I’m having is of a different nature, however: I have people in the same (spatial) area who know nothing about each other. I think this is basically what is called “instancing”. I will be using it to make it possible that different groups of people can play the same level at the same time (another issue I’m running into with this is power-ups, but that’s much easier to solve - also collision detection becomes a little tricker, but there’s nice solutions to that hangin’ out in this forum).
Well, the major problem (and that’s the reason why I mentioned that in the other thread) is that I used a convenient short-cut in my prototype implementation (“bullet-time? HAHA, nothing easier than that, just do Time.scale = 0.2F and there you are”), which turned out as a rather severe issue to solve now that I’m doing “the real thing”.
That’s basically the “core wisdom” I gained from my multiplayer development experiences so far: What might be ridiculously trivial in single player or even “little-scale multiplayer” can become complexity hell in (larger-scale) multiplayer. It’s rather tempting to just add a network view, click on “synchronize” (ah, it’s the default, so you don’t even have to make that decision ) and think “there you are, you got a multiplayer game”. This sure works in many cases (so I think that proves it’s a good design), but then there’s those cases where it suddenly doesn’t work at all and you have to go the way through the dark forest with evil packet-monsters crunching RPCs while lurking in every corner
I’m sure I can solve the TRaceOn bullet-time issue, though (mentally, I’ve already made my way through that forest). In particular, because due to the nature of bullet-time, you can be somewhat loose with state synchronisation. 1/5 of time speed (Time.scale = 0.2F) automatically tolerates 5 times as much lag as “normal time” does. So, you can hand over control to the clients (or one “authoritative client”, for instance the one with the best ping time) without sacrificing toooo much playability.
I’d find an alternate solution to using time scale and implement my own time scale - thus defining which areas are affected by the scale.
In stead of working around the fact that it is local I’d underline it graphically - like the halo 3 shield.
Obviously a larger area would be affected than the area covered by the halo shield and this should be represented by scaling the shield effect up to match the area affected.
This also gives the added bonus of more game-play around bullet-time. As you’ll be able to see the border of the bullet-time area, players other than the initiator of the bullet-time (as the area would presumably still be attached with that player at centre? or not? could be fun if it was just placed?) would be able to jump in and out of bullet time by hovering around the border.
Obviously shooting projectiles from outside a bullet-time area into one would be an interesting challenge
a thought, whenever you enter a bullet time zone, have it slow down timescale quickly and gradually, for a cool effect, near outside, only thing that will mess up the looks(sp and anythingelse, is the timestep changing, esp for stuff that interp or exterp
Meanwhile I have the solution implemented in Traces of Illumination (that’s the new name of the game originally called TRaceON ) - you can have a look at http://www.ramtiga.com
In single player mode, you’ll have to get to the second level to be able to pick up the bullet-time powerup. You can then activate it by pressing T. I have the “slow-down” effect, which also has an effect on the sound which I think gives a very nice effect. Besides, I have some pretty intense visual effects added.
The solution for multiplayer was having my own “timeScale”. I think I explained that in some other (old) thread. Simply encapsulated Time.timeScale … ah, and I also had to encapsulate all the “waits” for coroutines to make sure they scale if I change my “local timescale”. So, on the server the timeScale is always “1” but each game group can have its own timescale (bullet-time always has an effect on every player of one game group … which is that way “by design”).
Not just to revive an old thread… but because I would be interested in this… Jashan, could you explain this a little bit more?
I really didn’t get how ou done it
) and think “there you are, you got a multiplayer game”. This sure works in many cases (so I think that proves it’s a good design), but then there’s those cases where it suddenly doesn’t work at all and you have to go the way through the dark forest with evil packet-monsters crunching RPCs while lurking in every corner 