¿Con qué fuerza debe un motor de un jugador rechazar datos no válidos?

En un juego para un solo jugador, cuando intentas construir una entidad a partir de componentes especificados en scripts externos, ¿qué crees que es más deseable que ocurra cuando uno de los componentes está mal formado?

• ¿Debería el motor omitir ese componente y dejar que la entidad viva en el mundo del juego solo con los componentes que estaban bien escritos?
• ¿O no debería agregar la entidad al mundo si uno de los componentes está mal formado?

Tenga en cuenta que no estoy hablando de registrar los errores, eso debería ser obvio, sino de lo que debería sucederle a la entidad.

Si estás hablando de un juego modificable, entonces quizás quieras seguir una de tus sugerencias anteriores. Pero si le preocupa pasar por alto sus propios errores, le diría que no lo haga. Me he convertido en un defensor de Fail-Fast . Si esto es un error que se ha creado y se deben resolver antes de la liberación, debe hacer evidente el error. El artículo al que está vinculado en la parte inferior de la página wiki es una buena lectura sobre el tema de por qué fallar rápido es bueno y cuándo debe y no debe usarse.

La distinción entre usuario y desarrollador no siempre es clara en el desarrollo de juegos. Las técnicas de programación estándar como "fallar rápido" no siempre son ventajosas, especialmente a medida que aumenta el tamaño del equipo.

Por ejemplo, tal vez su artista técnico ha arruinado el sombreador para el esquema de orientación: rompió el retroceso, digamos, por lo que solo se está cargando en los sistemas SM4, y no se dio cuenta porque tiene un sistema de primera línea. Esto provoca que algunas animaciones no se carguen. Esas animaciones están referenciadas por un hechizo particular que tu diseñador de combate ha escrito. Finalmente, tu diseñador de niveles está tratando de poner los engendros en su lugar y todos los engendros pueden lanzar ese hechizo, pero ahora no puede colocar ninguno de ellos en el mundo porque sus hechizos no son válidos porque los efectos no son No es válido porque los sombreadores no se cargarán porque los diseñadores siempre tienen las peores computadoras.

Entonces, su demo no está lista para las 2PM y sus inversores se preguntan por qué ni siquiera pueden tener un solo enemigo en el juego y su proyecto se cierra.

O eliges la opción donde registras la falla pero sigues intentándolo, y el juego funciona bien, excepto que algunos efectos de hechizo de enemigos no aparecen, pero los inversores no saben cómo se supone que se verán de todos modos, por lo que no aviso.

Por esa razón, casi siempre abogaré por la primera opción: generar la mayor cantidad de entidad posible. Hay casos de fallas rápidas, como si los datos nunca se deben editar, excepto por personas capaces de hacer compilaciones (es decir, programadores y productores técnicos) y siempre se verifica al 100% en la carga, o si está absolutamente seguro de que la persona responsable de el problema es la persona que usa el editor, pero esos no son los casos habituales, y requieren una gran cantidad de infraestructura técnica per se, en la que quizás no estés preparado para invertir.

El usuario debe poder obtener una vista previa de la entidad que va a importar y saber de antemano si hay errores.

De alguna manera, debes decidir qué errores deben ser fatales, evitando que se agreguen al juego y cuáles pueden descartarse como advertencias .

Por supuesto, si por alguna razón la entidad importada pudiera alterar de manera irreversible los datos del juego guardado, es mejor que sea impecable.

Sugeriría que en el desarrollo, debería ser ruidoso sobre datos no válidos. es decir, registrar todo en algún lugar donde se leerá. Sin embargo, si su motor puede ignorar esto y continuar, debería hacerlo. Puedes tener lógica como

void setValue(int value) {
    if (value < MIN_VALUE) {
       log(value + " is too low, using " + MIN_VALUE);
       value = MIN_VALUE;
    }
    if (value > MAX_VALUE) {
       log(value + " is too high, using " + MAX_VALUE);
       value = MAX_VALUE;
    }
}

Incluso en un juego multijugador, esto es aceptable a menos que se suponga que un jugador está tratando de engañar al sistema.

Después de lanzar el software, es probable que desee desactivar este registro de forma predeterminada, suponiendo que los jugadores no van a leer estos registros.