Esta es una pregunta de seguimiento a esta otra .
Me gustaría saber si hay un patrón común / típico / mejor para escalar mi representación del mundo (actualmente 160Kmx160Km) para que se ajuste al área de dibujo (actualmente 800x600 píxeles).
Puedo pensar en al menos cuatro enfoques diferentes:
Una ingenua (como lo hice hasta ahora). Implementé una función global sc(vector)
que simplemente devolverá una copia reducida del vector pasado. Esto, por supuesto, funciona, pero me obliga a escribir código como:
drawCircle(sc(radius), sc(position))
Funciones de envoltura . Podría definir varias funciones, cada una de ellas envolviendo el middleware original. Por ejemplo, podría definir myDrawCircle
que primero escalaría los argumentos que necesitan escalarse, y luego llamar drawCircle
con el último. Esto haría que mi código sea más legible y fácil de mantener, pero debería escribir muchas funciones de ajuste, que suenan tontas.
Decorador de funciones . Podría simplemente decorar las funciones de middleware existentes, proporcionando escala automática para todos los parámetros que son una instancia de la clase Vector3D
, pero el problema es que esas funciones también trabajan con los mismos parámetros de estar list
o Vector2D
también, y el decorador no tendrían ninguna manera de saber qué listas deben escalarse (el radio, por ejemplo) y cuáles no (los valores RGB).
Inicialización de superficie . Al definir la superficie en la que voy a dibujar, podría definir el factor de escala (para luego usar metros y no píxeles como parámetros). Esto funcionaría de manera transparente para mí y sería mi solución preferida, pero, por supuesto, debería implementarse en el middleware, por lo que no es una opción real.
... de todos modos: dado que este es un problema muy común, me pregunto si hay un patrón establecido que resuelva elegantemente este problema que no pude encontrar.
PD: Para este proyecto, estoy usando python (con pygame ), pero, aunque una respuesta específica de python / pygame es muy apreciada, estoy más interesado en la descripción general / de alto nivel del patrón en lugar de su implementación concreta.
Gracias de antemano por su tiempo y experiencia.
fuente
Por lo general, las personas no intentan escalar en tiempo de ejecución en juegos 2D. No estoy de acuerdo con que sea un problema común. Si las personas desean un minimapa o algún otro cambio de escala fijo, a menudo se hace un nuevo conjunto de gráficos para este propósito. Es raro que necesites una rutina única para correr a 2 niveles de zoom diferentes en un juego 2D.
Si usa una API 3D, puede obtener esta funcionalidad de forma gratuita, solo cambie los parámetros de la cámara / ventana gráfica.
PyGame es una API muy antigua y desafortunadamente solo es realmente adecuada para 2D. Incluso si pudiera encontrar sistemas de escala adecuados para los diferentes niveles de zoom, el rendimiento no será lo suficientemente bueno y es probable que la apariencia sea inaceptablemente mala.
Aconsejaría que si desea acercarse y alejarse mucho, cambie a una API 3D moderna lo antes posible. Recomendaría Pyglet, pero es probable que también haya otros.
fuente
pyglets
en el pasado para una simulación 3D. Seguramente es más capaz que esopygame
, pero el soporte para 2D es bastante más bajo que el de adentropygame
. La documentación / ejemplos disponibles también son menos detallados, lo cual es una molestia para mí, ya que soy un principiante en el desarrollo de juegos, y realmente necesito entender la base de las operaciones más comunes. :) En cuanto a la "edad" del pygame: tienes razón. ¡Sin embargo, hay una modernización en progreso! :)pygame.sprite.LayeredUpdates
por ejemplo). En cuanto a la relación inmutable: tengo lo que quieres decir. El comportamiento que describe no es el que quiero replicar, pero entendí lo que quiere decir, ¡gracias por la aclaración! :)