c++ - unity - motores graficos para android
FRP en un motor de juego. ¿Vale la pena? (2)
Hoy, he leído sobre FRP (programación reactiva funcional). Sin embargo, no sé cuánto encaja esto en el motor.
Después de leer el artículo de Gerold Meisinger , mi pregunta es si vale la pena usar FRP en lugar de una arquitectura basada en componentes. ¿Es este el futuro cercano del diseño de la arquitectura del motor del juego? ¿Es solo un enfoque simple para resolver pequeños problemas que hacen las arquitecturas basadas en componentes? Apreciaría cualquier artículo, explicación, opinión personal, etc.
Piense en un motor para un juego comercial, especialmente para tiradores o géneros de carreras (juegos en 3D). No piense en un juego de plataformas en 2D u otros más simples (hablando de la complejidad del motor). Usaría C / C ++ (noté que las personas que usan FRP confían en Haskell, debido a su naturaleza. Sin embargo, vi este documento y prefiero estar en C ++, como el "estándar de la industria").
C ++ no es naturalmente adecuado para FRP; cualquier biblioteca que uses ( Boost.Phoenix es una buena) conllevará algunos gastos generales que probablemente no querrás tratar en un juego comercial en 3D.
No solo eso, sino que FRP no es una técnica muy bien desarrollada para juegos, ni siquiera en Haskell, afaik; ¿Quieres hacer un juego o quieres desarrollar una técnica para hacer juegos?
Los sistemas de entidades basadas en componentes han existido durante bastante tiempo y son un concepto probado. Tienen sus limitaciones, sobre todo, ¿cómo se comunican los componentes entre sí? - una solución es tener dos tipos de componentes, atributos y comportamientos; estos últimos pueden acceder a cualquier atributo, pero no pueden acceder entre sí.
Si quieres hacer un juego, ve con CBS. Si quieres ayudar a desarrollar FRP en los juegos, haz eso.
Por cierto, estás muy equivocado al decir que los juegos 2D tienen motores simples. :)
Actualización 2014
Desde entonces, ha aparecido un nuevo lenguaje que hace un uso extensivo de las técnicas reactivas funcionales y está dirigido al desarrollo web, llamado Elm . Es muy similar a Haskell y es compatible con Prezi , afaik. El diseñador de idiomas tuvo una presentation bastante buena en la que hizo un pequeño juego con FRP. Cualquier persona interesada en cómo debe manejarse el FRP puede querer ver ese video.
Respuesta corta: probablemente ninguno de ellos!
Sin embargo, no sé cuánto encaja esto en el motor.
No entiendo lo que quiere decir con eso, pero cada código de pieza que involucra tiempo (es decir, usa update( float elapsedTime ) ) generalmente se ajusta a FRP, en teoría. Sobre "encajar en el motor", tal vez HaskellWiki Yampa - Game Engine ayuda a responder tu pregunta (una versión recortada y traducida en inglés de mi tesis que explica la arquitectura general). De las discusiones sobre FRP y de la lectura de algunos artículos de FRP, parece que todavía hay algunos problemas no resueltos con el concepto teórico general, por lo que recomiendo realizar algunas pruebas exhaustivas antes de usar cualquier biblioteca de FRP en un proyecto comercial (especialmente el rendimiento y la memoria). cuestiones). Echa un vistazo al video Frag . Es un juego de disparos escrito en FRP y el ejemplo más avanzado de la actualidad.
Piense en un motor para un juego comercial, especialmente para tiradores o géneros de carreras (juegos en 3D).
Hm, ¿cuál es tu enfoque? ¿Estás desarrollando un juego comercial? ¡Entonces usa un motor existente y no te preocupes! ¿Estás desarrollando un motor? Entonces FRP podría ser un concepto interesante. Variar objetos de juego con componentes no debería ser necesario para los tiradores y los juegos de carreras, ya que solo usan muy pocos objetos de juego diferentes y centrarse demasiado en la arquitectura puede ser una ingeniería excesiva. ¿No tienes un enfoque? Obtener un enfoque! No puedes desarrollar el próximo motor IdTech Y el próximo juego Doom por tu cuenta.
Vi este documento y prefiero estar en C ++, como el "estándar de la industria"
Hay algunas bibliotecas para C ++ también. Buscar "programación reactiva o temporal".