Si su juego va a requerir un uso remoto de hardware, entonces necesita hilos para hacer frente a todo el hardware moderno; Las futuras CPU que saldrán en el próximo año o dos están comenzando a hacer 4 núcleos como mínimo y hasta 16 núcleos comunes para los mercados de entusiastas / rendimiento. Si está haciendo subprocesos múltiples, definitivamente haga una arquitectura orientada a tareas, ya que cualquier otro modelo de subprocesamiento está inherentemente roto para los motores de juegos con visión de futuro.
Ahora tenga en cuenta que por "tareas" me refiero a "trabajos" y no a "hilos separados para diferentes subsistemas del motor". Absolutamente no desea hacer algo como tener un hilo de gráficos, un hilo de física, un hilo de IA, etc. Eso no escala más allá de un pequeño puñado de núcleos y de todos modos no le da ningún paralelismo real. La física no debe ejecutar más de una actualización por actualización de IA (desea que su IA pueda reaccionar a los eventos de física), y los gráficos no tienen casi nada nuevo que representar si la física no se ha ejecutado, por lo que cada subsistema se ejecuta naturalmente en secuencia orden. Usted no
Lo que quieres hacer es esto. Crea un carrete de hilo. Ejecute su ciclo de juego con la secuencia clásica de actualizaciones del subsistema. Sin embargo, para cada subsistema, separe la carga de trabajo en lotes separables distintos y distribúyalos al grupo de subprocesos. Espera a que se completen todos los trabajos antes de ejecutar el siguiente estado del ciclo de actualización del juego. Algunos subsistemas pueden tener múltiples subetapas; por ejemplo, los gráficos pueden emitir una serie de trabajos para eliminar y luego una segunda serie de trabajos para realizar la creación de la cola de representación. Este enfoque evita el problema de sincronización del primer enfoque, escala a un número mucho mayor de núcleos y, francamente, es más fácil de codificar, depurar y mantener.