# Running subsystems at difference update intervals

I want to update the rendering at 60fps, but the logic at some lower rate, say 15Hz. But if an object only moves when the game logic updates, then it would appear to stutter badly especially for lower frequencies. I guess the rendering system could interpolate an entity's vector and draw the model moving at a lower dt, but if the game logic causes the entity to change direction it will appear to teleport back, and so on. I can imagine many more problems.

How is this usually solved in games? Surely most engines want to decouple rendering from game logic, so there must have been some though put into this. Or does everyone just update all systems that have graphical effects at the same rate?

What you've described is backwards. If nothing has updated, then there's no reason to redraw anything. You've suggested showing the same image 4 times before updating it, limiting your effective graphical frame-rate to only 15Hz.

What you want to do is Update() using the smallest deltaTime possible. This allows animations to take more, smaller steps, increasing visual fidelity.

You don't have to Update() every object's velocity vector, every frame, but you should Update() every object with a velocity, every frame.

• It's actually a very common pattern in games that systems like network replication or physics tick at a slower rate than the actual rendering, and the positions of objects are interpolated or extrapolated when rendering frames between these update ticks. Using a lower rate of logical updates helps maintain gameplay consistency across a range of devices and framerate scenarios, as well as potentially being more battery-friendly than updating everything with the smallest possible timestep. So, this user's question isn't backwards. – DMGregory Sep 16 '17 at 13:39

I would decouple the different concepts, and having 3 systems with separate goals:

1. Position/Render system: updates/applies the visual position of your object every time this is rendered (60Hz)

2. Logic system: takes decisions like "now I want to go towards point B" (15 Hz)

3. Motion (or similar) system: "translates" the decisions taken by the Logic into whatever action are needed, for instance creating an interpolation from the current point towards point B (60Hz)

This way you keep the lower level system atomic and independent from each other (Position and Logic) and create a higher level system as a glue between them.