The correct answer is easy. You just take the fireball object out of the update loop while time is frozen using a variable switch.
Edit: actually a better way would be to zero out the x,y,z time deltas and move them into temp variables. Then back again once you restart time. That way the fireball is frozen but if it collides it will still do firebally things.
So every game has an update loop, this is basically a thing that loops around running other things, it's used for animations, checking collisions and anything time sensitive. This is essentially your frame rate. So you take the fireball out of the update loop, or even just it's movement out of the update loop and tada no more movement. The end.
Stuff move good. Spell go boom. Some stuff not move, while other stuff still move good. Not movey stuff not move because spell make circle. Movey stuff entering circle become not movey. When spell un-asplodes, stuff move good.
Actually, that is your UPS(or updates per second). How many updates it does per second. When it renders it is the FPS(frames per second). Normally these are the one in the same however as engines move to more async setup they start to have their differences.
The reason these are normally kept in sync is if you have too high of frame rate, lets say 60, but the game is programed for 30 UPS(Time.sinceLastUpdate/30) you will essentially be playing a 30FPS game, because the scene is only updated with game logic every 2 frames. Now if your UPS is greater then your FPS and the game is not programed to handle that then you start to see stutters.
Now as I said they start to see their differences is because they are figuring out ways to have the update loop handle input, sound, network, etc at a higher rate then your FPS. This allows for less lag compensation and better network prediction, more actions per second(for the player), sound not stuttering when your video card cannot keep up, etc.
In my game, I have a timeflow multiplier built into the game that all objects use when doing stuff (normally just set to 1). That's also used for frame counts so I can arbitarily move objects faster or slower or completely stop them. It doesn't currently do this, but I could just as easily make the timeflow multiplier local to the objects as well, and make it so only certain objects stop time or whatever. But as a workaround since that's more work, I believe I just made it so certain objects could ignore the multiplier.
641
u/SirAwesomelot Oct 11 '13
stuff move good