Consideraciones sobre un juego de simulación

Question

El tipo de juego de simulación que tengo en mente es el tipo en el que tienes cosas que construir en varios lugares y trabajadores / transportistas que conectan dichos lugares.

Algo más parecido a la serie Settlers.

Supongamos que no quiero ningún gráfico en este momento, que creo que puedo gestionar.

Así que mis dudas son las siguientes:

1. ¿Todas las entidades deben ser una clase y cada una debe tener un hilo?
2. ¿Deben agruparse las entidades en listas dentro de las clases y cada una tiene un hilo?

Si uno toma la implementación 1, será muy difícil de ejecutar en máquinas de baja especificación y no se escalará bien en grandes cantidades.

Si uno toma la implementación 2, será mejor en términos de recursos, pero luego ...

¿Cómo debo agrupar las entidades?

1. ¿Tiene una clase para casas en general y tiene una lista de interfaces para gestionar eso?
2. ¿Tiene una clase para grupos específicos de casas y tiene una Lista de objetos para gestionar eso?

y ¿qué pasa con los hilos?

1. ¿Debo tener el bucle principal del juego simplista?
2. ¿Debo tener un hilo para cada grupo de clase?
3. ¿Cómo encajan los trabajadores / transportistas en la imagen?

Answer 1

El enfoque normal no utiliza subprocesos en absoluto, sino que implementa entidades como máquinas de estado. Entonces tu mainloop se ve así:

 while( 1 )
{
    foreach( entity in entlist )
    {
        entity->update();
    }

    render();
}

Answer 2

El MMORPG Eve Online utiliza python sin pila y el modelo de actor para emular un sistema de subproceso por entidad sin el impacto del recurso.

Echa un vistazo a este enlace para obtener más información: http://harkal.sylphis3d.com / 2005/08/10 / multithreaded-game-scripting-with-stackless-python /

Answer 3

Estoy bastante seguro de que solo quieres tener un hilo ejecutando la lógica del juego. Tener múltiples hilos no acelerará nada, y solo hará que el código sea confuso. Tener un circuito de juego principal está perfectamente bien, aunque las cosas se complican un poco si el juego tiene varios jugadores.

Estoy un poco confundido acerca de la parte de tu pregunta relacionada con las clases. Si entiendo su pregunta correctamente, mi sugerencia sería tener una clase para cada tipo de casa (granja de cerdos, molino de viento, etc.) que se derive de una clase base común Casa . Luego almacenarías todas las casas en el mundo del juego en una lista de Casas.

Answer 4

Piensa en usar Erlang. Con Erlang puede generar muchos más procesos (= hilos ligeros) que un sistema normal. Además, está distribuido, lo que significa que si tu sistema no es lo suficientemente bueno, agrega otro nodo.

Otra alternativa sería Python sin pila (o la alternativa Python actual), ya que también es compatible con algún tipo de hilo liviano, que es muy bueno para los motores de juegos. Eve Online lo utiliza para sus servidores. Pero no se distribuye, pero eso se puede lograr fácilmente de forma manual.

Answer 5

Si bien la respuesta de @Mike F es correcta en su mayor parte, hay que tener en cuenta que la iteración sobre las entidades en un ciclo foreach hace que el orden de evaluación sea significativamente determinista, lo que tiene efectos secundarios indeseables. . Por otro lado, la introducción de subprocesos abre el potencial para heisenbugs y problemas de concurrencia, por lo que la mejor manera que he visto y utilizado se basa en combinar dos ciclos: el primero recopila acciones de agentes / trabajadores basándose en estado, el segundo ciclo compone los resultados de las acciones y actualiza el estado de la simulación. Para evitar posibles sesgos, en cada ciclo el orden de evaluación es aleatorio. Esta BTW se puede escalar a una evaluación paralela masiva, sujeta a una sincronización al final de cada ciclo.

Answer 6

Evitaría crear una clase separada para cada entidad porque entonces tendrás situaciones en las que estarás repitiendo el código de las capacidades compartidas, o tendrás un árbol de herencia funky.

Argumentaría que lo que quieres es una sola clase y objetos con funcionalidad compuesta en ella. Vi un artículo en un blog que hablaba sobre este mismo concepto en un RTS ... espera, creo que fue un recorrido por patrones de diseño que alguien estaba escribiendo .

Use el patrón de visitante que genera un hilo en el método DoEvents (por falta de una palabra mejor) de cada objeto para decirle a cada objeto que haga lo que va a hacer durante este bucle dado. Sincronice los subprocesos al final de su bucle porque no desea que algunos objetos con lógica compleja sigan funcionando desde los diez bucles atrás, cuando en realidad se destruyó hace cinco bucles.