Slashdot Mirror
Matrix-Style Bullet Time for Realtime Online Games
gcnaddict writes "Creating a slowdown in time on one end of an online game while maintaining normal speed on another was once one of those impossibilities which should never have happened. However, Finnish researchers have successfully invented a way to replicate a bullet-time-esque scene on one end of a real time multiplayer game without affecting the play speed on the other end(s). Of course, there are some slight issues which may never be resolved, such as when a player may occasionally think they have shot an opponent in a game and is surprised when his target refuses to die..."
My brain hurts trying to think of how this works.
http://www.specialistsmod.net/
The game has had bullet-time for quite some time, and only effects players in your immediate area. This allows the rest of the game to go along unhampered by your slow-flying bullets.
just what we need. European-designer-lag. I get enough matrix-style lag already, thatnk-you-very-much. (If this is more than just smooth lag, somebody please explain it to me because I'm obviously missing something important...)
On a side note, I had wondered if a space-time distortion bubble could be created in a multiplayer game. Sort of a local bubble of temporarily slowed time, which as the effect wears off, hyper-accelerates to catch up to the rest of the game world. The difference from lag there would be that all player within the bubble would experience the same slow time, and a player entering ot exiting the bubble would pass through an area of distorted time as they transition from one timeframe to the other... not sure what sort of paradoxes would have to be sidestepped to make this work right. any astrophysacists want to step in and take it from here?
hmmm, I think I just described the Tokyo-Jupiter temporal distortion from Ra-Xaphan...
One of the problems with hiding lag is that players cannot tell when lag has effected a kill.Without actually being able to demo it, I think this technique will just increase this confusion.
Also, the article mentions that lag commonly varies from 10-60ms (i.e. optimistic estimates) and does not mention whether that effects how much bullet time you can have. I would say it is sensible to suggest that less bullet time is available for 10ms people than for 60ms people.
If this is so, then how well does the system perform when the lag is varying wildly as it is want to do?? Does the play get a fixed lowest estimate for bullet time, or does the player never know how much they will get??
Is this one of those system they test in a "lab" with a fake lag generator and so forth? Or did they do real world tests??
I really hate articles that don't mention the important bits....
Realizing Bullet Time Effect in Multiplayer Games with Local Perception Filters (PDF)
In MxO all they do is play the animation at half the speed and spin the camera around a bit. Other players see the animation played at full speed. The result is that your character appears to do a fast move and then just stand there for a while before you leave interlock. Seeing as most players just stand there after they leave interlock anyway it really doesn't make any difference to gameplay (except it looks cool). That is, until you get the stuck-in-interlock bug and have to /suicide.
How we know is more important than what we know.
This method involves the introduction of excess latency to the system so that the player who is working in slow motion can be allowed to "catch up" to the server's actual state for as long as he is in bullet time. The problem with this method is twofold.
First of all, there is the issue of lag in the standard game. Unless the server-side prediction is able to perfectly determine the paths of the slowed player, it will not be able to send an accurate picture of where that player is to his opponents. This will make a bullet-time'd player either invulnerable or just very difficult to damage. The other problem arises when a player is bullet-timing and kills another player. The player could perhaps be completely out of site from the bullet-timing player, but because his lagged position is still visible to the bullet-timing player, the hidden opponent could still be killed. The frustration this would add could never make up for the gameplay benefits of such a system.
Some things are not merely hard, but impossible.
Slow-time for me, while the other player sees normal speed? No thanks, I used to play quake on dial-up all the time.
While abusing the lag compensation and slowing other's game play is a cool idea, I still see a problem.
Let's assume it is a Matrix game, and two players are replaying the helicopter landing pad fight scene, one on one. When player A shoots (normal game speed), player B goes into matrix mode to dodge. What animation does player A see of player B, considering player A has slowed their game play to theortetically choose a decision? Player A's computer has to predict what animation to play back (very quickly) before Player B has choosen their move.
This might work for games that have one-button matrix moves vs a free form matrix mode. It would also help if the results are RPG skill based versus directly controlled actions (like most MMORPGs).
Anm
and I thought that a Rogue's Stealth was unballancing ...
Would it be theoretically possible to cache the time (bad way of explaining it, but think of it like 'giving access to time to carry out commands which is stored within a timenudge to gain an advantage').
So you start a deathmatch for example, then say you have a delay of 10 seconds where ostensibly you are waiting for a map to load in a fps game. Now, when the match starts, both players are inputting controls which move their characters around the map, but they could draw from those ten seconds to have ten seconds of bullet time within the match, sort of a slowdown advantage instead of a speed-up advantage.
The only problem of course is that you have to use the ten seconds from the start, but that puts a gap between the start of the game when entered into the buffer, and when you start entering key strokes to move your character. So you would actually have a latency of 10,000 for a second, then the game begins and no bullet time feature >:-|
So this way only works if you can borrow time from the end of the match, or from a point in the present onward, but that's a shaky way of drawing off of lag, rather than a steady feed of delay from a buffer. Meaning my way of implementing the bullet time is inherently flawed. (Damn you special relativity!! Why can't gaming take advantage of the curvature of timespace?)
But it would be smoother than simply using a stagger effect of time apropos lag - because as I make it out, you'd be using your opponent's lag to get your bullet time bonus power in the article's proposed implementation. So the lagger gets doubly penalised - meaning the game sucks.... unless I'm wrong again.
So, my question: can this be done, effectively, understandably, in a buffered way, that is fair to both players in a 1v1 deathmatch - which is probably the ideal situation for this feature rather than a free for all or other game mode?
So, this really isn't that incredible. All games presently interpolate player positions to compensate for network lag. SOME games in the past have given the players leeway as to when their actions are committed. (IE: server-side timestamping vs client-side, unplug your network cable and shoot the enemy.. etc)
Someone finally figured out that if the path of the Bullet Timed (BT) player is KNOWN, ie: not moving, or in a dive motion etc. Then their movements will not appear lagged, only their actions. So...
Player 1 dives and enters BT, his perception is slowed to some % of full speed, and gets X amount of time to shoot at player 2. After his dive is over, the game accelerates or 'fades' time to catch up with the current real-world state.
Player 2 sees player 1 dive at normal speed, and then spend an amount of time picking his ass up off the floor (this non-action time is equivalent to the allotted time difference between the 'real world' and the player's slowed words, during this time player 1 is still diving through mid air on his screen.)
The only elements remaning lagged are any projectiles or actions that interact between player 1 and 2. So, the closer the 2 players are, the laggier this is all going to seem to the 2nd player. But throw some nice shader blurring on top of the whole thing to create a MAGIC TIME WARP (tm) effect, and you might have something, even if player 1's position ISNT known exactly.
I dunno. I always thought that although bullet time is a neat and helpful game play mechanic, it's not really designed for multiplayer games.
What you _want_ is to speed up one player's ability to move--reaction time and quickness of response. You can't do the former directly, and the latter is taken care of by mouse/joypad sensitivity. That's what bullet time represents: the activator moving so fast that his opponents literally can't track him with the eye.
The current method is to slow down everyone in a little area. Since the activator is the only one who sees it coming, he's the only one prepared to deal with a sudden change in movement speed--simulated decreased response time by slowing everyone else down. It's nifty, but not exactly elegant and focuses way too much on the "slowdown" aspect of bullet time.
All bullet time really does is slow down stuff so the _audience_ or _bystanders_ can observe all the little details, rather than just seeing two huge blurs and a dead body fall out of the air. Until you can arrange it so that a spectator can look at two fighting players and see just barely distinguishable blurs of fists and bullets as these ultra-elites battle it out at inhuman speed, what's the point? Slowdown (and faux-lag) is useful, but in the end sorta silly, trying to simulate using flashy graphics tricks what player skill will never do.
Realtime slo-mo dodging would require a distortion in the spacetime continuum which would cause time to slow down for the person who is doing some bullet dodging. This is basically creating lag for players while one of them starts blasting away unaffected by the lag. I'm sure they could make it feel realtime for the person in slow motion, but the other players will not like the amount of lag.
This is how I envision this version of bullet time: Player 1 is aiming his assault rifle at Player 2. Player 2, with his jedi-like prediction abilities, decides his only option is to go into bullet time to dodge Player 1's attack. Player 2 presses a button and steps out of the way quickly. Player 1, who cannot see that Player 2 is dodging due to the lag, continues to shoot at the spot where he sees Player 2 in. Meanwhile, Player 2 whips out a magnum, aims carefully, and shoots Player 1 in the face. Player 1 would normally scream "OMFG teh lag spike!!1," but with the introduction of "realtime bullet time" he now says "FCUKING NUB!!!1!" whilist throwing his controler through the TV screen.
I think what he meant is this:
There is a a core point where the temporal distortion occurs. The properties: The closer you go to this point, the slower you can move (animation/response-wise). Let's say a radius of 25 meters or so. People at the very centre of it would move at 1/10th speed. People 23 meters away from the centre would move 9/10th speed. People 26 meters away, and beyond, would move 10/10th speed.
People inside the distortion would see things the same was as people outside of the distortion.
The benefit of this distortion would be for someone who needs to perform an excessively complicated move (think: fighter game supercombo) and attempting it in slo-mo would be significantly easier.
Also, perhaps dodging bullets would be beneficial as well. Say you're caught in the middle of an ambush, with fire from every direction, such a distortion would be useful in buying yourself a few more seconds, until your friendly camper sniper can take out the enemies (whose bullet would also slow once it enters the distortion).
Now, in terms of the hyperspeed-up once the distortion expires -- this is purely for cinematic purposes. Let's say the distortion lasted 10 seconds. We can keep track as to how many [animation] frames each player performed in the distortion (to keep track of how fast you were going). If normal rate is 10 fps, then someone who experienced 1/10th speed would experience 10 frames. Once the distortion is over, let's say we want it to catch up in half the time. That would mean it would have to hyperspeed it up for 5 seconds, at a rate of 100fps.
Someone who experienced 5/10th speed, would get their hyperspeed at 20 fps.
This is, indeed, pointless. But it could provide a neat effect.
Scenario: You're ambushed by 5 gun-toting wankers. You, magically, create a time distortion fields. Gun-toting wankers shoot at you, you dodge for 10 seconds while dealing out the occasional punch, kick and knife stab. 10 seconds are up, your gameplay speeds up x10, while gun-toting wankers try to aim at you at super-high movement speed, you escape -- roadrunner style. Meep meep!
This could certainly introduce some interesting gameplay.
- shazow
You know, they're right. It's entirely doable, and the matrix offer you all the answers. The characteristics of bullet time are: - the target sees the bullets slow down - the target sees the bullets become tagged with trails for visibility - the target becomes blurred to an outside perspective Once you add in the many-player-copies/motion-blurring effect you help conceal the fact that you're shooting them and they're not taking damage. I don't think lag even has to play a part in this as it's an entirely subjective experience. At the target end, you'd do just as the article suggests and slow the bullets locally and let the client report to the server if damage was taken. Brilliant! Good thinking there guys!
What I think a lot of people don't realise is that the use of bullet time and bullet dodging was itself an implicit demonstration of philosophical questioning, which fit in well with the other thematic material in the Matrix films.
When Neo dodged bullets during the roof battle scene, although time radically slowed down from his perspective, from Trinity's point of view he was moving as quickly as the Agent had. This was intended to underline the subjectivity theme...that while manipulation of the Matrix's physics engine allowed an effect that was the same in one respect for both participant and observer/s, (successful dodging of bullets) it was markedly different otherwise. The reason why time *slowed* perceptually for the participant was to give the participant enough time to successfully dodge the bullets, while in order to rectify that so that the observer/s would see something relatively sane, the system then had to give the observer/s the image of the participant moving as rapidly as the bullets themselves.
This is only confusing when we think of the virtual environment as just that...an *environment.* However, it becomes much less confusing when we think of it in terms of simply being a set of *different* neurological signals being sent to the individual brain of each person. In order to maintain cohesion, the Matrix had to be flexible with regards to what each person was able to see. In other words, rather than a set of immutable laws, the physics engine would have had a fuzzy scale. (Viewed from this perspective, it becomes clear that the rebels didn't actually *break* the rules of the system as such...they simply learned how to occupy nonstandard positions on the physics engine's scales)
If we want to create a multiplayer, genuinely Matrix-like environment however, that is what we would have to do. The world itself could be server side, but for the resolution of certain events, (such as the dodging of bullets) you would need a scenario where the physics could be manipulated in a certain way from the perspective of the client invoking bullet time, and the server would have to figure out how to make said manipulations at least vaguely uniform with the rest of the environment. (In terms of dodging bullets, it probably makes more sense to cause everyone else to see the person moving at the same speed as the bullets, because if you were to make the bullets become as slow as the person, the server would then have to work out the range from the bt-invoking client at which they would begin to slow down, whereas from the perspective of the bt client itself, the bullets could start to slow from any range. Also, speeding up the person means only manipulating one coherent object - slowing the bullets means manipulating several, with the corresponding rise in computing power that such would require)
A large number of the characteristics of the physics engine within Unreal Tournament in particular are both expressed numerically and can be manipulated. One of the major things which would need to be worked out would be how each user could be given the ability to modify one of these characteristics (gravity would probably be the easiest place to start, although it could still be tricky, because it could involve dynamically changing the gravity attribute across multiple zones) relative purely to their own pawn, while still allowing the server to create a consistent environment. As I said, gravity would be the easiest one to start with...work out how each pawn could create its' own hi/low grav fields (part of Trinity's crane kick). The lightspeed barrier currently prevents this from working in terms of the time manipulation, but it'd be worth working out what we could for when zero-lag technology *does* arrive.
Although the level of computing power (not to mention the complexity of the programming logic) required to make this *truly* identical to the films would be utterly ludicrous, I'm inclined to believe that with a form of bandwidth using quantum teleportation, (zero lag, which you'd ne
between a program that simulates bullet time with pings abbreviated LPF, and the term of endearment for those with ridiculusly low pings, Low Ping Fuckers?
I Browse at +4 Flamebait
Open Source Sysadmin
MMO flight sims have been using "predictive technology" (=lag balancing) for at least a decade. Physics at that speed means that you can't really pull any surprises on the lag engine; on the other hand, collisions are done on the attacking machine. So you objects in your six view are closer than they appear, that guy who doesn't look like he has a shot probably does, and single-aircraft midair collisions do happen.
Still, you could introduce a cool-looking "bullet time" effect by playing with the "predictive buffer".
"a player may occasionally think they have shot an opponent in a game and is surprised when his target refuses to die..."
:)
Well, this is normal. This happens in Counter Strike all the time. You think you just emptied the magazine of your AK-47 to other player's back but after a second you get shot yourself. Then you check the damages you made to him from console only to see that every bullet got lost in bit-heaven
You don't know what you don't know.
Question is, how many lines of code?
RUPERT! I TOLD YOU TO WATCH THE BAGS! You were looking at the boys again, WEREN'T YOU.
has become "this is my idea of how bullet-time should work," this is my idea of how bullet-time should work:
Player's are either moving "normally" or "quickly" at all times.
The bullet-time restriction must be very strict : a difficult to get power-up, or a fairly short total time per level/game (a la 60 seconds per race of extra 50 hp to pass in some open-wheel racing tours)
All players actually move at the same rate (in m/s, or whatever).
Any player moving quickly cannot be hit by any aimed/directed attack such as a bullet or knife (this is why bullet-time needs to be very limited). Area/detonation damage still applies.
Any player moving normally sees a blurred representation of quickly moving players that is delayed from where the quick player actually is. Basically, you can react to where he was a second ago, but because he's "moving faster" than you, you have to lead him. Instead of the computer having to worry about prediction models, you get to! Fun!
When a player transitions from normal to quick, the player's blurred representation increasingly separates from his actual position until it reaches the maximum delay of 1 second (or whatever seems to work best).
When a player transitions from quick to normal, the player pops instantly from the blurred/delayed position to the actual position. This makes the choice of when you return to normal time as important as the choice of when you start bullet-time. It also allows the "I've run up to you and gotten past your defences and now I'm going to blow your head off" moment.
Note that neither transition - in fact no part of bullet-time at all - will necessarily appear different to the player transitioning. All bullet-time does as far as the quickly moving player is concerned is make you dodge all the stuff that's about to kill you (and you don't have to try).
The main disadvantage is, it doesn't have the "wow, cool, everything's moving slow" effect. Oh, well . . ..
Don't save Windows XP! http://www.petitiononline.com/jjw1xp/petition.html
Bullet time is, at best, a very cool looking special effect that isn't all that special in terms of gameplay.
Instead of adding bullet time to these sorts of games, I'd rather see them just take a game with cool moves that's played at a normal pace, such as Gunz Online, and add a Replay Mode similar to Gran Turismo's. The actual game is played at normal speed, but when you play the replay, you have a beautifully choreographed video of your exploits that's full of swords sparking, water flying around, and trenchcoats flowing in the wind. It would essentially turn a game of deathmatch into a cutscene from Devil May Cry 3.
|| Geshem ||
Flux capacitor joysticks.
and I'm patenting it too so pffffft.
If I can't smoke and swear I'm fucked.
Bullet time is created in the film industry with cameras that have a HIGH recording speed. This means a movement that normally may take say 6 frames in stadard film cameras could take 600 frames to complete.
Something that is invented in bullet time is that the character that "created" the bullet time event is basically just cranking up the frame rate. But since our human brains have a maximum frame rate the play back or viewing of the high frame rate has to be slowed down for us. This is why bullet time slows down. for us to see every frame of detail and understand it it is slowed down.
The magic that is added to bullet time is that the "person" that triggered the bullet time is granted the ability to move faster than they could before bullet time but are allowed to see the world moving "slower" while the rest of the world continues to move at normal speed.
Technically bullet time for the person that triggers it slows down but can't really speed up the character's actions. The pragmatic idea is that it is a nitro effect on the brain that more information is going into your brain faster and you are able to see the bullets fly in the air. Your brain is acting faster to process the information feed. That way no special bubbles have to be created.
But it does create the problem that if one wants to create the effect that the person in bullet time gains the ability to move at "normal" speed even during the slowed down bullet time. What this means is that if on a 600 frame rate played back to us in a speed that we can handle in our brains if a character where to move at a "normal" real speed the character would have to have been recorded moving at a much faster rate!!! So to the viewers of a bullet time activated character with the ability to move about in an unrestricted time they are just cranking a hella refresh rate of information and are moving twice or more of their normal speed.
pragmatic way to approach the idea. but not the solution for games and real-time between two people. the problem.. both people have a maximmum brain limit on how fast they can see information. Bullet time is a rush of information in high detail. if you had the ability to see the action sooner then you have gained that abiilty to react. But... does bullet time create the ability to move faster? In the matrix it seemed to allow that ability.. why not.. if your brain becomes faster in receiving information why not have an increase on muscle twitch.
but only interesting hacks will exist.. all information at each computer node has to be translated back to the rate that all brains can handle.....
so it sounds they've solved the whole thing...except for, um, the hard part...where everyone playing the game is supposed to have a consistent experience despite the difference in 'local time'. can i get paid to do work like this? sheesh.
...on it is that everyone plays the game at a theoretical point in time, which isnt 'game now'. Everyone plays at a point 'game now' + X ms. So the players are actually at 60ms for example. When a player hits the button, X increases because rather than moving forward in time at the same rate ([game ms per realworld ms] = 1), instead every 'game ms' takes for example 2 or 3 'realworld' ms. So, as you hold the 'bullettime' button down youre X number will increase. After you let go of the button, you will be at (for example) X=360ms. Presumably, to remedy this, the game will begin to 'catch up' ie slowly reduce this number back to 60ms. During the 'bullet time' you wont necesarily move more quickly, you will still move at the same speed (thats 'game meters per game seconds'). The important thing is that everyone else will see you ducking or jumping to dodge bullets in a way similar to how high difficulty level quake bots dodge rail guns. Theres no reason why anyone should be able to run faster. They could, but thats not the point of 'bullet time'.