¿Cuándo deberías rodar tu propio motor de juego? [cerrado]

He sido desarrollador de software durante 5 años, ahora, y quiero entrar en el desarrollo de juegos para iOS. He jugado con el SDK de iOS durante aproximadamente 2 años, asistiendo a reuniones de cocoaheads, y siento que entiendo bien el objetivo-c, el cacao e incluso c y c ++.

Tengo una idea de juego y sé que usaré Box2D, pero me pregunto si debería usar cocos2D o no. Las razones principales son:

1. Es posible que desee hacer cosas, gráficamente, que no estén disponibles en cocos2d.
2. Si hago rodar mi propio motor de juego, tendré más control.

Por supuesto, la razón principal para usar un motor de juego ya existente es el tiempo que ahorra y facilita las cosas difíciles; pero para alguien que tiene las habilidades técnicas para rodar la suya, ¿tiene sentido?

La mayoría de las otras publicaciones serán "hacer un juego, no un motor", pero voy a suponer que tienes un juego en particular que quieres hacer y quieres saber cuándo es una buena idea comenzar con el código de otra persona base o comenzar desde cero.

No debe rodar su propia tecnología a menos que sepa que necesita rodar la suya . Eso puede sonar frívolo, pero en realidad es la única respuesta correcta. Como con la mayoría de las decisiones, hay compensaciones. Solo usted puede determinar para su situación particular el análisis de costo / beneficio.

Debe comprender las siguientes cosas (esta lista no incluye todo).

• Qué middleware ya existe que podría usar ("motor" o de otro modo)
• Lo que ese middleware trae a la mesa, es una característica inteligente.
• Cuán maduro / probado es el middleware, especialmente si le importa el soporte multiplataforma
• Qué tipo de herramientas proporciona el middleware, o no proporciona, para ayudar a acelerar el desarrollo (no descarte las herramientas con su propia tecnología)
• Qué limitaciones tiene el middleware (como ejemplo simple, Unity 3.x no hizo sombras en tiempo real de luces dinámicas en iOS)
• Lo específico de las características de su juego en particular tiene que tener .
• Cuáles son sus plazos y cuánto tiempo tendrá que pasar para llegar al punto en el que el middleware lo llevará frente a cuánto cuesta el middleware.
• Cuán extensible es el middleware (por ejemplo, puede solucionar el problema de las sombras en iOS en Unity mediante el uso de sombras de manchas. O tal vez sombras de proyección).

(Tenga en cuenta que específicamente no puse "más control" allí. Esa es una frase cargada que podría variar de "No me gusta el código que no escribo" a "Necesito poder ver, comprender y ajustar todas las variables en el motor de física para lograr este efecto particular ". La primera no es realmente una consideración válida, pero la segunda sí lo es).

Personalmente, creo que rodar su propia tecnología para un juego de bajo presupuesto casi nunca vale la pena. La cantidad de energía que obtienes los motores baratos en estos días es ridícula. No estás en un punto en el que te estás decidiendo por una licencia de motor triple A multimillonaria o no. No podrás superar lo que, por ejemplo, Unity te ofrece por $ 3k. O Cocos2d por lo que cueste (¿no es gratis?).

Ahora, si su juego se centra principalmente en algún tipo de tecnología que otros motores no pueden proporcionar, o no pueden proporcionar a una velocidad de fotogramas razonable, entonces podría valer la pena investigar lo que puede hacer. Sin embargo, eso no significa que deseches el otro middelware por completo. El hecho de que necesite su propio procesador, por ejemplo, no significa que no pueda usar otro middleware para física o sonido o interfaz de usuario o lo que sea.

No enciendas tu propio motor. Tira tu propio juego. Si usted escribe un motor al mismo tiempo, entonces es bueno para usted, si no, siempre puede refactorizar las partes que desee reutilizar para que sea más "motor".

La gente a menudo sobreestima lo que se necesita para escribir la parte del "motor" de un juego. Si solo haces lo que necesitas, no te llevará tanto tiempo. La parte difícil es no quedarse atascado en la infraestructura de escritura y solo escribir lo que absolutamente debe para resolver su problema.

Usaría un motor existente cuando:

• Tengo una fecha límite apretada
• Tengo un conjunto de características fijas conocidas para poder elegir un motor para eso

Creo que deberías escribir tu juego, y tal vez terminarás con un motor más tarde . Escribir el motor de gráficos (que es todo lo que parece que estás hablando) desde cero usando nada más que OpenGL probablemente solo te hará perder el tiempo. Es un problema relativamente bien resuelto, por lo que, en general, solo cambiaría la forma de la API sin agregar muchas características importantes en relación con cualquier otra solución de terceros disponible.

Si Cocos2D o alguna otra capa de gráficos cumple con sus requisitos ahora, úsela. Si sus requisitos cambian durante el desarrollo, puede cambiar el back-end de renderizado con relativa facilidad: si realmente cree que tiene la experiencia y los medios para crear un motor usted mismo, ciertamente debe tener lo que se necesita para estructurar su juego de tal manera que el intercambio El back-end de renderizado es una operación relativamente trivial.

Cree su juego, permita que sus necesidades específicas controlen el conjunto de características del código que escribe y escriba el código teniendo en cuenta la reutilización y la buena arquitectura. Naturalmente, terminará con un "motor" después de que termine algunos proyectos como este, y los terminará más rápido porque no se atascará en el arrastre de características de nivel de marco.

Es muy simple. ¿Cuál es su objetivo principal: aprendizaje o tiempo de comercialización?

Evite usar una biblioteca si su objetivo principal es aprender de la experiencia de implementar los conceptos resueltos por la biblioteca. Cada vez que desarrollo un juego (a tiempo parcial), mi objetivo es puramente aprender. No me importa cuánto tiempo lleve, ¡por eso lo hago todo desde cero! Ahora tú decides.

Deberías poner en marcha tu propio motor de juego cuando sepas que es necesario .

Entonces, por ejemplo, digamos que no tiene el dinero para gastar en Unity. O prefieres gastarlo en un nuevo hardware. O bien, existen problemas de rendimiento con los motores gratuitos disponibles, o necesita tener más control en un nivel bajo.

Si te encanta escribir software por el simple hecho de escribir software, entonces te encantará escribir un motor de juego. Una trampa común de los programadores principiantes de juegos es quedar atrapados escribiendo un motor como algún tipo de proyecto perpetuo. Sinceramente, creo que así surgieron todos estos motores de juegos de código abierto: programadores de juegos que en realidad no lo hicieron

Luego, en ese caso, escriba su propio motor.