Tengo más o menos mil líneas de código para crear mi propio juego 2D basado en el espacio, que crea redes de sistemas estelares generados aleatoriamente y los completa con una selección aleatoria de planetas, estaciones, barcos y armas.

Potencialmente habrá cientos de estaciones / barcos / etc. diferentes que el juego necesitará usar, así que esto es lo que me preguntaba. ¿Debería pasar el tiempo para crear un cargador de datos 'softcoded', que almacenaría toda esta información en (por ejemplo) archivos XML y, por lo tanto, sería algo más fácil de modificar más tarde, o simplemente debería ir con lo que he estado haciendo ahora mismo: codificar todos los objetos en el motor principal del juego.

Soy la única persona en el proyecto, y como dije, es solo un pasatiempo que hago en el tiempo libre fuera de la universidad. Pero, ¿recomendaría la comunidad invertir en crear un sistema adicional completo de almacenamiento de datos en archivos adicionales?

¿Cuáles son los beneficios de codificar datos de una manera como esta, en lugar de simplemente codificarlos todo a través de constructores? ¿Existe un beneficio a largo plazo para tener archivos externos que pueden modificarse? Si no estoy buscando que el juego tenga 'mods', ¿es necesario tener archivos externos? Si es solo una cuestión de afición a la que podría renunciar en unas pocas semanas o meses, ¿debería perder el tiempo en esto?

Sí. Debe implementar un sistema para cargar contenido fuera de su motor principal.

Encabezados para respuestas concisas.

No. No consume demasiado tiempo.

Creo que la cuestión de si es una asignación válida de su tiempo limitado es discutible; aunque solo sea por el hecho de que será una pequeña porción del tiempo total del proyecto.

Pasará cientos (miles) de horas en un proyecto de juego que completará. Tal vez no en un clon de Pong, pero seguramente para tu complejo juego espacial. Compare eso con un lector de archivos de configuración. Implementar un sistema para canalizar XML en su constructor principal, y posteriormente reiniciar el proceso del juego, tomará tal vez 10 o 20 horas. Incluso si te lleva 50 o 100, será una pequeña fracción del tiempo total del proyecto.

Ahorrará tiempo

No es un gasto de tiempo; Es una inversión de tiempo. Y valdrá la pena.

El flujo de trabajo es importante, y tener un cargador de configuración mejorará su flujo de trabajo. Al crear un sistema que le permite editar configuraciones sobre la marcha, ahorrará innumerables reconstrucciones. Puedes mirar el juego mientras se está ejecutando, ajustar XML y volver a verificar en segundos. O puede mirar el código, encontrar una línea de código (entre miles), editar sus valores con mucho cuidado (está en su motor principal, después de todo), reconstruir, ejecutar, devolver el juego al estado de prueba, esforzarse por recuerde cómo se veía antes del cambio y vea si su cambio tuvo el efecto que deseaba. Asumiendo que nada se rompa en su motor, su tren de pensamiento seguramente se ve interrumpido.

Desde una perspectiva más fundamental de comp-sci, trate de recordar que la parte más lenta del software de escritura es no tener algunas teclas adicionales o espacios en blanco. Es cazar insectos. Y si dedica un poco más de tiempo para aclarar las cosas escribiendo un código más detallado, se ahorrará mucho más tiempo después. En su caso, escribir un importador de contenido da como resultado un código más limpio que será más fácil de leer. En lugar de millas y millas de valores codificados, su fuente presentará una carga de archivo simple. Del mismo modo, puede leer el archivo de configuración sin necesidad de leer el código del motor del juego. Ambas partes se vuelven más fáciles de mantener y más fáciles de depurar.

Los equipos de un miembro se benefician más

Si contrataste a un artista para generar parte de ese contenido, necesitarías crear herramientas con las que trabajar. Necesitan hacer ediciones de píxeles y ver los efectos rápidamente. No se atrevería a obligarlos a reconstruir el código para ver cada cambio. Su tiempo es costoso y no quieres desperdiciarlo.

Ahora imagine que el artista es muy inexperto y lento (artista programador), y tiene muchas otras cosas de qué preocuparse porque también son el principal programador y músico. Definitivamente no quieres perder ese tiempo, o el proyecto nunca terminará. Y ese artista horrible odiará la capacitación para ser un mejor artista, porque pasan todo su tiempo cambiando el nombre de las cadenas de activos en el código.

No te hagas eso a ti mismo. Crea las herramientas y tendrás más tiempo para hacer un juego.

Esta es una buena pregunta y la mejor respuesta que puedo dar es que solo la experiencia realmente puede decirle cuándo es una buena idea tomar el camino que es más difícil / lento. Si alguien te dice que SIEMPRE debes hacerlo de la manera "adecuada", entonces simplemente están equivocados.

Ya entiendes que es un tradoff. Por un lado, el hardcoding es muy tentador porque es rápido y fácil de comenzar, pero a la larga agregar funciones y depuración se convertirá en una pesadilla. Por otro lado, escribir un sistema excelente, flexible y expandible requiere una gran inversión inicial, pero hace la vida mucho más fácil a largo plazo.

El objetivo es terminar algo, y si te atascas en hacer un gran sistema, el objetivo retrocederá aún más y perderás la motivación. La codificación rígida está bien en algunas circunstancias, pero debe comprender las ramificaciones de hacerlo. Aquí hay algunas razones por las cuales la codificación rígida es una mala idea:

• Puede pensar que su proyecto es pequeño, pero es posible que crezca a medida que decida agregar más funciones. Si comienza la codificación rígida, llegará un momento en que la energía requerida para mantenerlo (actualizándolo con cosas nuevas y reparando la miríada de errores inevitables) comenzará a superar en gran medida las ganancias iniciales.

• El material de codificación es, por definición, específico del proyecto actual. Para el próximo proyecto, tendrá que comenzar desde cero nuevamente, posiblemente codificando cosas nuevamente (porque con eso se sentirá cómodo). Si hubiera dedicado tiempo a un sistema de carga decente, podría omitir ese trabajo y dolores de cabeza para todos los proyectos futuros.

• Es posible que esté trabajando solo en este momento, pero puede llegar un momento en que desee traer a alguien más al proyecto. ¿Te tomarás el tiempo para explicar tu desagradable sistema parroquial y escribir documentación para ello?

• La codificación dura a menudo implica tener que saber qué significan ciertos números mágicos o dependencias de clase complicadas. Es posible que pueda tenerlo todo en mente ahora, pero solo espere hasta que haya estado alejado del código por un tiempo. Incluso con comentarios extensos, una estructura mal diseñada es un infierno al que volver.

Diría que debe sentirse libre de codificar cosas solo con los detalles más pequeños. Si tiene la más mínima noción del elemento en el que está trabajando para ser utilizado por otra persona, crecer mucho o ser utilizado en otro proyecto, tómese el tiempo para hacerlo bien, ahora.

Por otro lado, prototipo como un loco y codificar ciertas cosas es rápido y fácil y te deja libre para concentrarte en experimentar. Depende de tu estilo de trabajo.

De lo que estás hablando es de programación basada en datos. .

Para proyectos pequeños, puede que no valga la pena invertir tiempo, ya que a menudo hay características mucho más importantes que podría mejorar.

Sin embargo, la programación basada en datos puede ser MUY fácil de implementar. Si lo toma en serio, probablemente debería usar XML, JSON o YAML, pero también puede usar archivos de texto sin formato.

Programación basada en datos

Pros

1. Permite a los diseñadores acceder y modificar los datos del juego sin conocimientos de programación.
2. Puedes hacer modificaciones al juego sin necesidad de volver a compilar . Esto no debe subestimarse, ya que puedes desarrollar un juego mucho más rápido de esta manera. Los buenos juegos vienen después de muchas iteraciones.

Contras

1. Se necesita tiempo y esfuerzo para implementar.
2. Puede aumentar la complejidad del programa.