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

11

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.

component-based validation

— Paul Manta
fuente

¿Estamos hablando de un jugador o multijugador?

— o0 '.

@Lohoris Un jugador.

— Paul Manta

2

Como la mayoría de las respuestas ya han mencionado, ¿quién es su audiencia? ¿Estás haciendo un juego modificable o estás hablando con fines de desarrollo interno?

— Tetrad

@Tetrad Me gustaría que el juego sea lo más amigable posible con los modders.

— Paul Manta

11

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.

— John McDonald
fuente

2

Creo que esta es una gran dicotomía, que diferencia entre los errores del usuario y los errores del desarrollador. Tiene sentido por la misma razón por la que los errores del compilador son generalmente bastante fáciles de solucionar, pero los errores de tiempo de ejecución / semánticos son el demonio.

— jhocking

Si el motor incluye una forma de modificar las entidades una vez que el juego ha comenzado, al menos deberías darte la oportunidad de corregir el error antes de fallar.

— Blecki

7

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.

— cenizas999
fuente

1

Me gustaría pensar que el escenario que propone puede evitarse con buenos sistemas de control de fuente. En su escenario, el artista ha "roto la construcción". Cualquier otra persona que trabaje con el sombreador roto debería poder revertir el sombreador a una revisión anterior hasta que se solucione el problema.

— John McDonald

1

@John Si bien es necesario un buen control de la fuente, y a veces es necesaria una reversión para restaurar el resto del proyecto a un estado de funcionamiento hasta que se resuelva una falla localmente, rara vez es útil como mecanismo de prevención y no se debe confiar como tal .

@John: en proyectos grandes, las compilaciones pueden llevar horas (o un día entero). Por lo tanto, realmente necesita un enfoque doble: no solo necesita control de fuente, sino también control binario, para que un no programador pueda retroceder a compilaciones anteriores completas. Pero, por supuesto, eso tiene sus propios riesgos y costos, porque ahora está desarrollando nuevo contenido contra otro contenido desactualizado, con ejecutables que pueden tener otros errores. E incluso encontrar la compilación correcta para retroceder podría llevar más de 30 minutos: si todos sus diseñadores tienen que detenerse durante media hora y jugar con las compilaciones, se desperdicia mucho dinero.

@ Joe Wreschnig: Eso tiene sentido. Así que supongo que debe haber un punto en el que fallar rápido ya no sea un activo. Ya sea en los tipos de personas que lo usan, o en proyectos de cierto tamaño. Supongo que depende de las personas del equipo decidir qué les funciona.

— John McDonald

2

No estoy seguro de rápida dura fallo, que es realmente lo que la pregunta se refiere, es siempre una ventaja. Incluso en un "equipo" de una sola persona, tal vez no quiera lidiar con el código del sombreador porque realmente tengo que lograr este nivel. Ciertamente escribir buen manejo de errores y registrar todos los errores, pero casi siempre tienen una mejor idea de lo que es importante en este momento en este momento que lo hice cuando escribí el código de error hace seis meses.

1

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.

— o0 '.
fuente

0

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.

— Peter Lawrey
fuente

Suponiendo que los registros no presenten ningún problema de rendimiento, debe seguir iniciando sesión en las versiones de lanzamiento y enviar los informes al equipo de desarrollo. (Por supuesto, informar adecuadamente a los jugadores.)

Debería poder grabar registros más concisos para su publicación. En el desarrollo puedes tender a ser más detallado.

— Peter Lawrey