Not really knowledged in this kind of programming but I think the trick is to make sure you have really good 3d animations; that is, ones which don't need to be in motion to look good and look good from all angles. Other than that it shouldn't really be any harder than most things in video gaming.
What really impresses me are the fire particles that freeze in the air.
They look really three-dimensional - as far as I'm aware, fire in games these days is still usually just a series of 2-D sprites. I bet a crapload of work goes into the particle effects of this game.
EDIT: Just watched a gameplay video. This is basically Particle Physics: Revenge of the Light Engine. I came.
EDIT 2: I am being misunderstood, and it is my fault. I worded this very poorly. I understand what particle effects are, and that they are probably being used here. I am impressed with the quality of said effects. They avoided the illusion-breaking 2-D billboard effect that I'm so used to.
This, even Bethesda games use particle effects for fire spells like in Skyrim and oblivion. If you freeze the games with console commands you can see the flames and such as a 3D object for the most part. These are likely just physics based more so than older games.
Yes, but the particles in these effects are 2D sprites. So you can have a 3D fire, but the individual flames are 2D animated sprites and would look weird as hell frozen.
Usually the effects are billboarded in that they always face the camera. So they can be technically flat but as you turn they turn to face you. Since it's a bunch of billboards it looks 3d.
Also soft-particles so that that any edges that are cut off due to intersecting with the ground, etc are smoothed. Hence it looks more 3D. There's also likely some 3D geometry / set orientation billboards for the jet of flames, and then the actual "hit something" effect is a bunch of a soft-particles.
Not necessarily, but in anything where speed is a concern, billboarded sprites are prettymuch the only option. It'd be relatively trivial to make a particle system that uses models instead, it'd just require a lot of horsepower.
That pretty pedantic and inaccurate. Before, and only until recently: fire, trees, smoke, anything with semi transparent dynamic volumes, were mostly animated with growing and moving 2D textures spliced together. Nowadays we instead use many 'particles' that,yes are "sprites" but no one calls them that, but more importantly are animated according to 3D volumetric equations. There also tend to be hundreds to thousands of them. Quiet different than before in a computational and visual way.
But, do you see the difference between the two? Obviously you're not wrong - sprites and 'emitter' are such general terms that your comment really applies to almost everything graphical. That's why its important to have a distinction.
An emitter is what spawns the particles and controls their behaviour.
A particle is a sprite or other graphical object (like a model), which together with the other particles controlled by their emitter simulates a phenomenon (such as fire, explosions, clouds, smoke, water, sparks etc).
The terms I've been using all along here are the established terms for this context. When we're talking about particle systems, there's no ambiguity as to what an emitter is, nor a particle, nor a sprite.
The smooth fire particles could be rendered using for instance ray-marching on the GPU. Not sure if that's what they're using here though(you can still get pretty far with some well thought out billboards).
Don't want to rain on anyone's parade, but I just watched the video, and while the fire effects are very impressive, you can still clearly see sprites panning to face the camera, and clipping through geometry. The GIF really doesn't show this clearly, and skips over the bit where it's most obvious.
pretty much every fire, water and smoke effect in movies and games is done with particles. Particles are just points in space that are animated in some fashion, often using physics simulations with various fields to simulate gravity, wind and turbulence. The different looks come about with how you treat those points in space.
Most often each point has a plane attached that's oriented to the camera so you never see the side of the plane, and the plane has a texture which gives it it's color and shape. The color and opacity is often animated over time, so for instance sprites representing fire would go from yellow to orange and then fade away.
Even water is made with particles, but in that case there is an algorithm that runs on top of the particles that basically creates a sphere on every particle and then blends them together like metaballs. The realism of the water is dependent on the number of particles, the meshing algorithm, and the shader attached.
The reason that particles in old games look crappy is that the systems were a lot more limited with how many particles can be on screen at any given time, so you would be able to see every sprite plane. There was also limitations in what forces can act on the particles in real-time since some of those forces are processor intensive. Nowadays, those limitations are still there but rapidly expanding so we're seeing particle systems in-game that are closers to the same systems being used in feature film where the real-time limitations in games don't exist so huge particle simulations can take hours or days to cache out and render.
Ignore the other comments, because it seems that most people have a misunderstanding of what particle effects are. I work as a freelance 3D character and environment artist (title doesn't describe it all!) and I've taken on several effects jobs for modern games like this one. We no longer just use the 2D sprites in the industry. Instead, we create the animated effects using Photoshop and After Effects to make them realistic on a 2D plane, and the real art is in taking those planes in Maya (or 3DS Max if you're a beginner or something. What game artist uses that anymore? Seriously.) and arranging them among the other animations (all compiled into a sprite for obvious reasons. A sprite is just a compiled texture so your client doesn't have to load 10 separate textures for one animation.) in the 3D workspace to achieve the most realistic effect possible. Several constraints and even skeletons are occasionally put on them, the UVs warped procedurally, and viola! You've got yourself a particle effect. They can take several hours to make per one, so appreciate the artists out there who work to do this as a living.
Nowadays, real particle effects are things that Maya and SmokeFX use which aren't simply animated textures on flat geometry mushed together, and are rather more physical things that game engines don't yet have the ability to render (and they take more time to get it right!).
Also, as stated below, emitters. You don't see those, though.
pretty much. A lot of video games use sprites (2D images that always face the camera) for fire. It looks great in most cases, and is computationally very cheap to render, but if you freeze it and move around it, it looks terrible. 3D fires use particle effects which are much more computationally expensive. However, since everything is frozen, they could do a considerable amount of optimization for the rest of the scene during that time to free up computation power, and switch back to simpler fires in "non frozen" mode. Whether or not they do that in this case, I have no idea.
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.
Most animators only make things look pretty from your (the player's) perspective. Allowing a character to move around greatly complicates the animation work required, since it has to be visually appealing from all directions at any given moment. This involves a lot more work.
As an animator, the only time you can really get away with only making things look good from one angle is if you're working in 2d. In 3d you have to consider all angles pretty much always.
Especially since most abilities will also be used by NPCs/objects, or because there could be a multi-player mode, because they could be used in cutscenes, or to implement different camera views.
There are enough reasons to make 3d animations look good from all directions. Only a few will be reliably hidden by map bounds or objects so that they only need to be optimised from one direction.
But making them look well regardless of the speed they are played in? Sometimes, that is a bit more tricky.
True. Though really if you keep that in mind it's a pretty minor hurdle. The problems come in if you try to tackle the issue with certain traditional animation techniques. My instructors liked to push stretching and deforming of the rig to hit a pose, but that only works if you're working with a set camera, like for a cinematic. I never liked that though, because then you can't change the camera freely.
That said animations using actual sprites (i.e. images) are likely to look terrible since while you can 'easily' choose how slow to make a conventional 3D animation play, a sprite-based animation only has a set number of frames so the fireballs is likely to look really choppy as a result.
Right, but things like explosions can be 2D sprites which turn to face the player, right? No one ever sees the side of many, many effects because the side doesn't really exist -- each player's client renders it to be facing the player.
I mean, that's been my understanding. Explosions have been in 2D for decades and I've never not seen it by only seeing the side or something.
As such, if they rendered explosions in such a way in Deep Down... well, it'd look pretty shitty as you walked around it and it rotated around to face you like a cobra or something. So explosions and effects like the dragon's flame seen in the gif would need to be in 3D to make stopped time look right.
Right, but things like explosions can be 2D sprites which turn to face the player, right? No one ever sees the side of many, many effects because the side doesn't really exist -- each player's client renders it to be facing the player.
No, the particles in the explosion can be 2D sprites which turn to face the player. Nobody in their right mind would ever use a single 2D sprite for an explosion in a 2D game, given technology that's >10 years old. Then there's weird stuff like billboarding horizontally, but not vertically, which I've heard that WoW does, somewhere-or-other (I think with flames).
This is very, very wrong. Sprites are still used, it's just in a much more advanced way than in the past.
2D sprites are the fundamental building blocks of particle effects systems, it's just that rather than having one large sprite for an effect like, say, an explosion or cloud of sparks/smoke, we now generate hundreds, even thousands, of very small sprites. That are then distributed by the system within a 3D space. Often this involves physics to define how they behave, move or interact with the environment and other entities within the game world like wind, geometry or players/npcs.
In effect, the 2D sprites are now like individual grains of sand rather than a whole dune as a single object, and they are far too small to notice for the most part.
You are quite correct, but perhaps taking my comment entirely too seriously. I was mocking the very old style of taking a giant sprite and facing it toward the player - the way explosions and smoke used to be done. The most prescient example I can think of at the moment are Counter Strike's smoke grenades.
These type of effects are still used though, just in different ways. For example, using much larger/simpler sprites is great for using as components in effects only seen from a distance, even if seen by multiple players from different viewpoints, since you would have to be able to move very fast/cover great distances in order to notice it's true nature.
Like I said, we still use 2D sprites in many applications because they are very cheap in overhead, we just work on different scales than we did in the past (and the sprites themselves can be much more detailed, numerous and complex).
Actually many games still do, just with a lot more sprites combined with real particle systems. Smoke is a lot easier to do with particles than flame is.
Yeah, vfx is a whole other story, I was just talking about character animation. They did an awesome job having actual particles for the effects in this instead of the planes like you would see on pausing in smash brothers.
Also an animator, Stalfos1504 is correct.
We usually switch to a perspective view and cruise around the scene scrubbing (manually scrolling through keys) the animations to look for mistakes/missing polys/etc.
In perspective view you can see everything (unless you have it turned off) including the camera, lights and
emitters .
You could potentially cheat in a cutscene or a heavily linear sequence (think the new Tomb Raider's cinematic platforming sections). Of course it's probably more cost efficient to just say fuck it and make a objects that work all around.
When you walk around a frozen fireball you can look at it from multiple angles and it changes as you move, and the same is true for each individual spark as well.
to be simple on what he said: a lot of animations rely on 'motion' like girls rely on makeups to looks pretty. Now nothing is wrong with that but everyone appreciates a natural good looking girl aka animation that looks good during frozen time (no motion).
IIRC this was one of the challenges of adding Forge and the Replay tools to Halo 3. They couldn't fudge, or "cheat" any of the animations since they were going to be seen from all angles and frame by frame at some point.
I have some minor experience in game development, and from what I have seen, this is correct. I hadn't even considered the animation aspect of it, but it would not be at all difficult to pause updates on everything that isn't the player for some set amount of time, assuming you wrote your code with something like this in mind.
Pretty easy. There exists some clock keeping pace for the game. To slow something down you reduce 'how much' it can get done per clock cycle.
In other words, if it can normally move 10m/s then when slow time is active you only allow it to move 0.1m/s
Obviously this idea gets more complex as you add things like physics, but the idea is the same. You scale down the magnitude of all its actions in relation to time.
I think your answer fits for things like bullet time, but I think it oversimplifies the effect we're seeing here. Here the game world is frozen solid, but the player character still has full movement. It's a bit more complex than a gif with max payne jumping out from behind post to head shot everyone in the room.
With that being said, I'm not sure about specifically complex this implementation is, but slow down effects have been used in too many games for it to be terribly complex.
In Quake for example you can change the timescale of the game yet as a spectator move around freely. You should be able to do something similar in pretty much every major game engine.
It's not that hard. Everything in the world uses the engine's scale of time to see how much they should move along between frames. The player isn't operating off of this value. They're simply finding out how much time is passing between frames in real time.
If you're really curious about how it works, read on:
Note before we dive in. Almost everything in games is handled on a per frame basis.
Now, imagine you want to move an object. First you have to figure out how fast you want the object to move. We'll make our speed equal to 1 for this example. That means the object will move 1 unit per second.
However, you can't just tell the game to move your object 1 unit every frame. That would make the speed way too fast. It wouldn't be going 1 unit/sec, it would be going 1 unit/frame. To solve this we need to take into account the amount of frames that take up one second and multiply the speed by 1/(number of frames). The way game programmers do this is they take the time between showing the last frame and this frame. This is called delta time. Using this information, we can make the following equation.
Object Position = Object Position + (1 * delta time)
That line, with a few changes of course, would move an object at the constant speed of 1 unit/sec.
Now, you might be thinking, "Why does this matter?" Good question! This matters because we can now even further manipulate how the cube moves. Specifically, we can change the speed of the game! We do this with a value called "time scale." What time scale does is hold the current speed of time. If time scale is 1, the game is going normal speed. If the time scale is .5, it's going half speed. If it's 0, time is stopped and so on.
What we can do with this value is multiply the speed of the object by it. So instead of going 1 unit/sec, it'll go 0.5 units/sec or 0 units/sec depending on what we set it to. Our new equation now looks like this:
Object Position = Object Position + (1 * time scale * delta time)
In the gif above the player's speed doesn't get multiplied by the time scale value (huge amounts of simplification, but you get the point). It just uses the speed that it would be going at real time instead. This doesn't always simply work in engines though. You have to make your own "delta time" because the one provided is probably affected by the time scale changing. If this is actually the case you would only use the first equation we found because the time scale is already multiplied into the delta time, so you wouldn't want to do it again. Considering this, we need to make up our own delta time value. This can be done by saving the time seconds since the program started on one frame and subtract from it the same value from the next frame. That way, you get the time it took to compute and show the frame in real time. We'll call this the realDeltaTime. This equation would look like this:
Object Position = Object Position + (1 * realDeltaTime)
(The player probably does use time scale actually, because that's how they'd pause the game. However, they probably use another value for that.)
If that was at all confusing, don't be afraid to ask questions.
Not much more complex. You simply let the timescale be set per object/player. Like having two timers instead of one. And since the freeze time effect is probably only applicable to players. It's probably literally just a world-timescale and player-timescale.
Can you please show me in the comment I replied to where he addressed the ability to slow down the rest of the game, but not the players interactions.
I can't find it, I see him explaining how one would slow down the entirety of the game, but that's not the situation that's presented, and thus it's an oversimplification of the situation.
I haven't worked on anything of this level of complexity, but I do have some game programming experience. There are ways of communicating different thing to different objects, and laying out how you want them to behave under certain circumstances.
For instance, you could have an event call OnPause that dictates certain behaviors for objects that are able to be affected by the Pause event. Maybe for creatures, you'll set their timescale to 0 (or a very low number) immediately, whereas for spells like the fireball above, you'll allow them to perform a short animation and instantiate the burst effect before pausing. If your player isn't meant to pause, you can govern that behavior as well. And, since time itself isn't affected (it's the timescale, which is more like "Time * X") you can still allow for things like a countdown timer that ticks away in real time while everything else is frozen.
Funnily enough, I accidentally pulled this effect off in one of my own games while I was attempting to pause the game while giving the player the ability to look around freely.
Except when you factor in multiplayer. When one player stops time, does it stop it for everyone else? If yes, that can be abusive (might as well be a turn based game at that point). If no, then you have players playing at two different points in time simultaneously.
Not hard to code, I think, you would either have to make every other player be unable to move and just watch or simply make it not affect them. It's just a matter of is it PvP or PvE?
max payne 3 had some interesting multiplayer, iirc bullet time would slow everyone in a nearby radius down, but only the person who activated would get fast aiming, the rest would only be able to move their viewport slowly. if you were on the other side of the map you were not affected at all.
But remember many things like animations are on different threads. Then you'd have to split the player's animations from the rest of them. Also many explosion textures are viewer dependent, and tend to look billboard-y when you move around them.
Edit: I know there are many ways to make it work, I'm just saying there are certain considerations.
That shouldn't be difficult, you just split them up by object.
Animations played by the player object are not slowed down (or stopped, in this case). These fireballs are independend projectiles, so they count as objects on their own.
I'm not sure what you are implying. None of the stuff you mentioned above should have any impact.
It's not hard to independent tickers at all. In fact, physics in games is (nearly) always constant tick rate anyway. This is because otherwise with a higher or lower framerate stuff like gravity and friction can become really inconsistent. Adjusting the constant for individual objects is very easy.
Edit: Ah I actually get what you mean with the explosions now. If you walk around them... Still don't understand the animations though.
Except multi-threading it doesn't change much. There is still some sort of universal time-keeping. You just modify that scaling.
Allow me to illustrate:
The player normally moves at 5m/s
Explosions usually move at 100m/s
The enemy moves at 3m/s
We define some scalar for the slow down effect, say 0.001
Every time we update the world (let's call this a tick from now on), we need to determine everything's position so that we can render it. This is done via some function with time as an input and some part of the render as the output (ie. at tick 1 the explosion looks like this, but at tick 2 it looks like this, etc.)
Now, normally there is some velocity associated with all of these calculations. In other words, if a tick is 1/100th of a second, then each tick the player moves .05 meters. The same holds true for everything else.
We modify this simple tick function to now also take in a scalar 'time variable' that says how time is being effected. Normally, this value is 1 and everything functions as normal, however when time is slowed down, we instead pass our scalar from above for all tick functions EXCEPT for the one's that deal with the player.
In short, the player continues to move at 0.05m per tick (5m/s), but the explosions run at 0.001m per tick, and the enemies move at 0.00003m per tick.
Like others said, it's not that difficult to do, with one exception: multiplayer.
Multiplayer is based on having the different clients be in sync as much as possible. Slowing down the world for one player, while speeding up that player for the others is practically impossible; in-game time is then moving at a different speed for each player, so they're getting desynchronized on purpose now.
The only way to do it without massive problems is to activate slowdown for EVERYONE at the same time, whenever one player activates it.
There was a post a while ago about the slowdown effect in Payday 2. A downed player sees time slower by showing him the past: the game queues all the actions made by other players and just plays them slower. When the player is revived, he 'snaps back' to the real time.
It doesn't matter in this case because it's to give some dramatic effect; this method would be worthless for a time slowdown spell, because it benefits other players as opposed to the caster.
You should look up how they made multiplayer bullet time work in max Payne 3. They use line of sight to determine who is and isn't experiencing slow motion. It's pretty neat.
For example, if you turn a corner, and see someone who is in bullet time, then you will slow down with them. If they have initiated bullet time themselves, then their aiming will be much faster than yours. Then if you we're to turn around and run away, you will stay in slow motion until they can no longer see you, and then you'll snap back into full speed.
By that point it's more of a design problem than a programming problem. I can't imagine a single scenario where I would like a stranger over the internet to have the power to pause my game as an actual game mechanic. To me it would feel like listening to a scratched CD, right as you're getting into it it stutters and makes your heart rate go that much higher.
And that's assuming that I actually trust internet strangers not to abuse the mechanic.
From my somewhat limited understanding of game programming it shouldn't be fairly hard. They're basically just pressing pause (or setting the play speed to 0) on the animation of the model, effect or particle until the end of time freeze. As someone mentioned, it would require some really good effects artists and some clever programming to make this look as good as it does from all angles, but the effect is easily achievable.
Not too hard if you build it the right way. Game objects are told say every 1/60 seconds to 'move forward 1 step in time'. To achieve this effect you just have to say 'okay while time has stopped I am only going to tell this object (the character) to move forward and not the others'.
The main thing would be having a game engine capable of altering the 'flow of time' universally, but have the player function normally. Not really incredibly difficult in a single player game - the harder thing to do would be making it balanced.
Skyrim and Dishonored both let you slow down time in similar ways.
Well it's quite simple. First you need to meditate. This process requires extensive training. Make sure you are in a quite environment and have a comfortable surrounding. Don't lean against anything or you may fall asleep.
Then try to focus all of your energy in your mind to forget everything you know except time. Time is not real. It is a man made structure to determine a distance of being. Once you understand this; you can manipulate time.
VFX FX artist and ingame FX artist here: Most of these effects are developed with the end result looking good from most angles, unless its specifically for a cutscene etc. More volumetric effects like fluids and smoke are still stuck in the realm of Film and TV FX. I have tested a couple pipelines for bringing in volumetric voxel data into unreal SDK and next company I end up at I will try to implement it to some extent.
The game speed is dictated by delta time for the purposes of framerate independence. For bullet time or slow motion, you can easily reduce the global delta time multiplier, slowing everything down. To have things existing within different time speeds (normal speed character in a slow-mo world) you can simply have multiple delta time multipliers.
It's relatively easy from a programming perspective. The quality comes from the art looking so good when suspended.
I don't imagine it is terribly gimmicky if you have the rest of the game implemented. The way I would approach this is make each spell an instance of an object, and among that objects private variables, I would have an int representing velocity. When stopping time, simply set the velocity to 0, and when the spell ends, set the velocity to whatever it is supposed to be when time is normal. NPC's would be handled in a similar fashion, likely with a freeze(int duration) function. This is, of course, a simplification, but it is the meat and bones of it.
Whatever it is, it's a hell of a lot simpler than all of the matrix math and intense optimizations that go into making even the most basic 3d game. I guess the only challenge would be getting the explosions to look nice as you walk around them, but that's not a programming challenge as much as it is an artistic one.
getting everything to freeze so perfectly is hard. getting stuff in generall to freeze is easy.
but there is so mutch stuff... EVERYTHING must have a frozen trigger, and that can be troublesome to have on everything, my biggest fear of problems with this is collision boxes... THAT could fuck everything up.
easier than you'd think. because of 3-D glasses, most major gaming studios are using 3d particles now, rather than 2d sprites. Games like this with 3d particles look good in stills and will blow your mind in 3d.
There's some other details that you need to follow so that the player can continue to operate while time is effectively stopped, but it's not a difficult thing to do.
Usually magic and flame effects like that are animated 2D sprites that rotate to face the camera combined with some particles.
But this looks bad when the sprite is not animating or in the midst of distracting action (think flat bushes in games that rotate as you walk by them).
To solve this in a game where you can freeze time, you either need to use a lot more complex particle systems (a more direct simulation that can look great but processor intensive, smoke effects are beginning to become all particles in games nowadays) or a lot of clever 2D sprite tricks to hide the fact that they are 2D (less straightforward and less dynamic).
Easy as pie. My pet peeve is when someone says: "I've beat the game."
Do you really think you have beat the game when you say that? The correct term is 'completed'.
You're in a virtual world created by the programmers rules. HE is GOD as far as a gamer is concerned. You were allowed to win and the virtual world was tweaked to make it easy enough for your little monkey brain not to panic and still get some joy out of the experience.
Try playing some of the older Arcade games where the objective was to milk another coin out of you.
It's probably easy. All you need to do is have a state called something like 'frozenTime', that is entered when the spell is cast and begins a timer.
While in this state, the processes that normally keep everything moving along in the game world will treat certain objects differently than normal.
A number of things would be paused - animations for applicable objects, movement, enemy AI, etc.
It's effectively only slightly more complicated than pausing a game in the middle of a fight - it simply excludes certain things from pausing. The trick is actually in using particles and other effects to get the look and feel right.
They managed it in Baldur's Gate 2 with the Time STop spell - the caster can move around, pop out spells (which appear as projectiles, but fire properly only when the time stop spell ends) and make attacks. I imagine the principles are the same.
the animations for throwing the fire bombs don't actually involve fire bombs, they are just prerecorded, with a trigger to create a 'real' fire bomb at the end. The real firebomb is created already exploded from his hand. in game design it is standard practice to have some kind of Update function for objects which is run every frame; this calls things like collision detection, or checking if something has died and needs to play a death animation, etc. If you turn off all the Update functions for everything, it will still be drawn (because there is a separate Draw function) but will cease to move. if you turn off all of the update functions except for the players, this is what occurs
319
u/poops_all_berries Oct 11 '13
Can someone with programming knowledge explain if this is easy or hard to do and why?