There are some games which actually use at least two threads - one for rendering and one for gameplay. While the rendering thread renders the current gamestate, the gameplay thread calculates the next.

But this software architecture is a lot more complex than it seems at first glance. If implemented poorly it can actually hurt performance.

One problem is that it is important to synchronize these two threads properly. You don't want the renderer to render half of the previous and half of the next state. Badly implemented thread synchronization can have worse performance than doing the same things in a single thread.

Another is that you need two copies of the gamestate - one for rendering and one the gameplay thread builds (or at least of those components which are relevant for rendering). And those two copies better don't get out of sync. A naive approach to this is to just create a whole new copy of the gamestate, but that means that you might copy a lot more data each update frame than you need to.

There are some games which actually use at least two threads - one for rendering and one for gameplay. While the rendering thread renders the current gamestate, the gameplay thread calculates the next.

But this software architecture is a lot more complex than it seems at first glance. If implemented poorly it can actually hurt performance.

One problem is that it is important to synchronize these two threads properly. You don't want the renderer to render half of the previous and half of the next state. Badly implemented thread synchronization can have worse performance than doing the same things in a single thread.

Another is that you need two copies of the gamestate (or at least of those components which are relevant for rendering). One copy for rendering and one copy the gameplay thread builds . And those two copies better don't get out of sync. A naive approach to this is to just create a whole new copy of the gamestate, but that means that you might copy a lot more data each update frame than you need to.

There are some games which actually use at least two threads - one for rendering and one for gameplay. While the rendering thread renders the current gamestate, the gameplay thread calculates the next.

Keep in mind that it is important to synchronize these two threads properly. You don't want the renderer to render half of the previous and half of the next state.

Another caveat is that this software architecture is a lot more complex than it seems at first glance, and if implemented poorly it can actually hurt performance. One problem is that you need two copies of the gamestate - one for rendering and one the gameplay thread builds (or at least of those components which are relevant for rendering). And those two copies better don't get out of sync. A naive approach to this is to just create a whole new copy of the gamestate, but that means that you might copy a lot more data each update frame than you need to.

There are some games which actually use at least two threads - one for rendering and one for gameplay. While the rendering thread renders the current gamestate, the gameplay thread calculates the next.

But this software architecture is a lot more complex than it seems at first glance. If implemented poorly it can actually hurt performance.

One problem is that it is important to synchronize these two threads properly. You don't want the renderer to render half of the previous and half of the next state. Badly implemented thread synchronization can have worse performance than doing the same things in a single thread.

Another is that you need two copies of the gamestate - one for rendering and one the gameplay thread builds (or at least of those components which are relevant for rendering). And those two copies better don't get out of sync. A naive approach to this is to just create a whole new copy of the gamestate, but that means that you might copy a lot more data each update frame than you need to.