Resource intensitivity is … well… set a minimum hardware requirement
Over the years I’ve given a fair bit of thought to system performance vs
independent logic timing. Obvious system performance stuff should be
reactive or capped in such a way that a system 10x faster than what you
developed for can still play the game peacefully without a need for a slo-mo
type of program.
I think it depends on the kind of game you’re designing. Alot of button
mashers, on, say, the original NES benefited from performance hits when
there was alot going on graphically — when a lot was going on, you didn’t
have to try to guess where things would be graphically while time was
ticking. At the same time, it’s mildly irksome on highly fluctuated games
to have to constantly keep your ‘internal clock’ matching the game.
a prime example would be an fps. having game logic limitted by graphical
fps is a good thing. if you walk into a room in doom on your 386sx and
there’s 50 monsties, it’d suck to die without knowing why. if the game is
playing slow, you can at least trudge through that area or similar.
Of course there are situations where it doesn’t matter if the system gets
bogged down… at which time it’s mildly annoying to have to wait to input
For an asteroids clone, I’d suggest keeping game logic limited by FPS. If
you have a HD spike or some other background process trigger at the wrong
time you’d get pissed about the game ‘jumping’ and then finding out you’re
dead… or game being jittery and hard to control.
Of course, there is plenty of gray area in the debate. Ya could have an
independent timing mechanism and only have it slow down if the system is
remarkedly slow over a given number of frames. Something along the lines of
#define AVG 10
times[AVG] = 0 // fifo
totaltime = 0
time = end-start
totaltime -= times[fifotail]
times[fifohead] += time
adjust fifohead and fifotail
if(frames < AVG) frames++
if(totaltime / frames > timethreshold)
logic fps = graphical fps
logic fps = 30fps
this way the game will slow down for just a moment during a single load
spike… or be semi-transparent if ya have weird load issues … or actually
bring the logic down to graphical speed if there’s something intensive going
on… and recover on its own. being spread out across several frames also
makes it a bit less jarring and even things out with intermitant issues
(rather than frame by frame basis), although if AVG is too high, you won’t
take the logic fps speed hit until alot has already happened.
then there’s fun of doing linear or quadratic speed changes from max/current
logic fps to match whatever the graphical fps is running at… where instead
of just logic = graphical, ya say adjust logic constantly to move it towards
graphical (within a limit of course) so that you get there over the course
of several frames… possibly yielding a slighty more fluid change.