BerickCook ha expresado la idea correctamente. Deje los cálculos donde están si funcionan correctamente ahora.
Si puedes hacer el cálculo antes y estás seguro de que no los necesitarás a mitad del juego, entonces hazlo antes. De lo contrario, hágalo después de cargar. Si el cálculo durante el juego no se nota, puedes hacerlo allí. Si en algún momento la complejidad evoluciona y los cálculos se vuelven demasiado pesados, comience a optimizar.
Pero una cosa: si sus cálculos se implementan para ejecutarse a mitad del juego, siempre puede forzarlos a que se realicen durante la carga de todos modos.
Existen numerosas soluciones:
- calcular / cargar las rutas durante la creación / carga de nivel
- usa un segundo hilo para calcular las rutas
- optimiza tus algoritmos
- use un sistema interrumpible si no tiene acceso a subprocesos.
He visto y usado la última opción en un juego de mercado masivo. Simplemente asegúrese de guardar correctamente todos los datos necesarios para que se reanude el cálculo, y verifique regularmente el tiempo / operaciones restantes durante el cálculo.
Dependiendo de su caso, el sistema interrumpible podría proporcionar soluciones preliminares y parciales que se pueden utilizar antes de que finalice el cálculo.
Editar : respondiendo @Keeper
El "algoritmo interrumpible" fue útil solo debido a las restricciones que teníamos. Básicamente nos paliamos a la falta de multihilo.
En un momento tuvimos un juego donde la IA tenía que calcular grandes cantidades de movimientos basados en múltiples diccionarios. Durante este cálculo, todas las animaciones se detendrían porque los diccionarios se expandieron con más datos y el conjunto de datos que contenía los datos cambió y fue menos eficiente cuando el juego se adaptó para el modo multijugador (donde la IA tenía que interactuar incluso para los movimientos del jugador). Solo teníamos un subproceso disponible para el bucle del juego (el imperativo es que el código multiplataforma debe ejecutarse en todas las plataformas compatibles). En este punto, se decidió romper el algoritmo de cálculo para poder interrumpirlo. Por lo tanto, no podíamos usar el sistema recursivo que estaba en su lugar ya que las variables no se podían guardar. Las funciones fueron reemplazadas por objetos que simplemente contenían todas las variables y punteros necesarios para los objetos primarios y secundarios. Yo no'
- guardar el estado de sus cálculos actuales
- interrumpir al final de un ciclo o durante un ciclo (cuando un objeto hijo interrumpe)
- salir cuando se acabe el tiempo
- reanudar donde se detuvo, ya sea reiniciando un bucle en el índice derecho o llamando al objeto secundario que se encuentra actualmente en la parte superior de su pila secundaria.
- limpiar todo si se interrumpe el cálculo
- dar el mejor resultado parcial.
Solo las operaciones más caras se dividieron en objetos separados y tomó algún tiempo encontrar los lugares correctos donde pudiéramos detener los cálculos, pero al final funciona muy bien.
Perdimos el rendimiento, pero el rendimiento percibido fue mucho mejor para el usuario, ya que las animaciones funcionaron sin problemas en todas las plataformas, todas las plataformas podían usar los diccionarios más grandes sin sufrir animaciones o congelaciones entrecortadas. Además, esto nos permitió ejecutar varias instancias en paralelo cuando lo necesitábamos más tarde.
Por supuesto, ahora en el iPhone y iPad el juego no necesita esto, usar un segundo hilo sería ideal. Pero sospecho que el código sigue ahí.