Player controlled game speed

Started by
8 comments, last by Norman Barrows 8 years, 2 months ago

The players are constantly asking for a way to increase game speed when "nothing happens" in my sim game. But I don't know how. The CPU is maxed out and FPS are around 16.

Is it possible, and how should I design it?

Advertisement

It is possible, but may not match your current implementation.

First, your simulation needs to be decoupled from your rendering. Hopefully that is already the case.

After that, there are two options.

Some game simulations break badly with variable time slices. For example, a physics-based game will works best with a fixed update rate. In that case, run more than one simulation update as CPU time allows.

Other game simulations are designed with variable time in mind. Consider something like FarmVille every item in the world can be advanced by 2 seconds or by 2 days. Implementing a fast forward in that type of game you pass larger time deltas to the simulator object updates, and the object works out if anything has happened to it in the time window.

Thankfully, updating a simulation is typically -- but not always -- a very fast operation. Usually it is rendering that takes the largest chunk of time. If that is your case then you should be able to add additional updates or bigger steps to your updates without hurting the graphical quality.

Ok, so I just pass a bigger time step to the Sim.

Won't the sim outcome be different depending on the time step size?

Ok, so I just pass a bigger time step to the Sim.

Won't the sim outcome be different depending on the time step size?

Equivalence of a single long update and multiple short updates of equal total time, depends on implementation. (this is same as the simulation having similar results regardless of how long delta time each step is given, within some boundaries of possible delta times of course)

If they are equivalent (the aspects you care about, and to the accuracy you care about), you can do it.

If they are not equivalent, you can not. So you must either only do the latter (perform simulation steps at a faster rate when you want faster simulation), or you must make changes to your algorithms and/or design until the two approaches are functionally equivalent.

And as mentioned, if graphics is your bottleneck, separating it from simulation might allow you to do simulation steps at higher rate without killing FPS. If simulation is too slow, just optimize it until it goes faster. If you can not optimize it in any way, you must use the bigger time step approach, which means ensuring this wont change results.

o3o

On some of the larger maps with lots of agents the Sim is the bottleneck and causes lowered framerates.

It occurs to me that some parts of the Client/rendering should change speed, but others should not. Particle effects and model animations should be affected, but interface panel and GUI animations should stay the same.

The first test seems to work fine with a 2X speed increase. Of course detecting if there are differences in the sim outcome with normal and changed speed requires some work. But I am also wondering if anyone will really care...


The first test seems to work fine with a 2X speed increase. Of course detecting if there are differences in the sim outcome with normal and changed speed requires some work.

That is why it is important to design this into your game as early as you can.

Some simulations handle large time steps just fine. I mentioned FarmVille and similar games above. Tell a plant X time has plant and it knows to update the right amount. The code is built so it can just as easily step one sim-millisecond or one sim-week.

Other simulations hand large time steps badly. A physics simulation with a 10ms step means objects bump and collide rather nicely. Taking a one week simulation step means all the moving parts have moved out toward infinity. The code is built around specific regular time steps.

Sim-games generally can be made to handle arbitrary time steps.


Particle effects and model animations should be affected, but interface panel and GUI animations should stay the same.
Particles and animations are not simulation steps, they are graphics that should be decoupled. That might be a little mixed if you have a system to embed events in your animations, you will need to make sure all the events are virtually triggered, but for once enough time has passed it is still something that could be addressed entirely on the simulation if you need to.
If everything in the game is linked to time, meaning time of day (hh/mm/ss) you could use a multiplication factor and define a few presets of which the player can choose. Like mentioned earlier, this depends on your inplementation of "time".

Crealysm game & engine development: http://www.crealysm.com

Looking for a passionate, disciplined and structured producer? PM me

I think the most time critical part in my game is the combat code, because it depends on agents positioning themselves next to each other before they can engage in melee combat. If the time steps are too big I could imagine them overshooting each other. But I just tested it with 4X speed and it looked OK.


The players are constantly asking for a way to increase game speed when "nothing happens" in my sim game. But I don't know how. The CPU is maxed out and FPS are around 16.

Is it possible, and how should I design it?

this is whats known as "accelerated time". its commonly found in flight sims and other hard core vehicle sims, and almost nowhere else in games, with the sims and total war battlefield mode being notable exceptions (but then again, those are both sims as well).

the basic idea is you do multiple updates per render.

never implemented it with a "fix you timestep" algo - multiply ET by accel factor perhaps? that ought to work. 16fps = ~62.5 ms for ET. double it and ET becomes 125ms, consume in DT sized chunks as usual, you get double the updates per render (on average). yeah - it should work. or just call update twice with the original ET value both times. this will help guarantee you don't pass in huge ETs that make your update blow up. might also help with keeping results of accel and non-accel time the same. FYI: i've never found that to be an issue. perhaps in multiplayer, but not single player games.

Caveman supports unlimited acceleration. 2x, 4x or 8x are great for manually walking cross country quickly. combat is possible at 2x and 4x, but 8x is a bit too fast. when nothing is happening, speeds of 1024x to 4096x are usually used. there's hotkey support for speeds up to 16K acceleration, and you can use + and - to go even higher. at any time, backspace drops you back to 1x. the game also automatically drops back to 1x when a band member gets an encounter or finishes an action.

in general, accel time is not recommended for combat. in caveman i give the player full control of accel time at all times. so they can speed up combat if desired. but the number one cause of death is running too fast in accel time. so fast you start to take damage from dehydration and lack of food. speeds like 1+ hours of game time per second of real time - IE: around 3600x acceleration. if its just a shooter and you can stand around forever and not die, no problem. but if its a simulation where you must eat or drink, seek shelter from weather, can get random encounters, or similar things can happen when the player is just standing around, then excess accelerated time can lead to death.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

This topic is closed to new replies.

Advertisement