¿Deben los scripts interactuar con una abstracción del motor?

Estoy usando Java y Jython, y después de un poco de investigación descubrí que dar acceso directo a la interfaz del motor a los scripts podría ser un error, ya que acoplaría estrechamente a los dos.

Parece que la mayoría de las secuencias de comandos que permiten a los mods crear y administrar entidades lo hacen a través de algún tipo de abstracción. ¿Estas abstracciones están ahí por esta razón, o es solo para proporcionar una forma más intuitiva para que los no programadores modifiquen el juego?

Ambos, en general. Sus scripts deben hablar con una capa de funcionalidad abstraída, o al menos intermedia, y no con el motor en sí.

Primero, esto le proporciona una medida adicional de control y seguridad. Le permite definir de manera fácil y limpia la interfaz que un script puede tener con su juego y, por lo tanto, con qué puede molestar, así como también le permite colocar controles de seguridad adicionales en el intermedio más adelante que no necesariamente serían apropiados en el juego. Capa de funcionalidad real en sí.

En segundo lugar, le permite simplificar la interfaz expuesta a los scripts para que sea más amigable con los programadores o más fácil de usar en general.

Sí que da un poco de aislamiento contra el acoplamiento entre los dos, pero a menudo no es que una gran cosa porque los scripts siempre se acoplan a las interfaces que se les permite interactuar con, por su propia naturaleza. Los otros dos puntos son mucho más beneficiosos.

También creo que te ayuda en caso de que quieras hacer modificaciones en el motor. Puede hacerlo sin preocuparse de tener que cambiar todos sus scripts desde que cambió el motor. Solo tienes que cambiar la capa de abstracción que Josh mencionó.

En mi opinión, es necesario crear una capa entre el núcleo del juego y los scripts, que se usa para crear modificaciones.

Obtiene varias ventajas al usar este método:

Más fácil para los modders:
una buena razón para hacer esto es, como mencionaste, una forma más fácil de hacer modificaciones. Escribir menos líneas de código significa más legibilidad y minimiza los problemas de comprensión para los novatos de programación. Idealmente, esta API debería ser una colección de métodos para cambiar algo en el alto nivel del juego . Esto significa, por ejemplo: generar una entidad sin saber cómo se genera realmente , o mostrar una imagen con una sola llamada, que solo toma el nombre de la imagen como parámetro.
Usted, como programador, también se beneficia de él, ya que puede escribir más en menos tiempo del que necesitaría con Java.

Seguridad:
evitar que las personas controlen todo el juego es esencial. No me importaría, si el juego fuera un título para un solo jugador, pero me importaría cuando el juego tenga alguna acción multijugador. Incluso si es solo una tabla de puntaje alto.
Otras personas siempre se sienten frustradas cuando alguien gana debido a las trampas (por ejemplo: cambios de posición, más específicamente: cambio de posición y límite de bandera directo). Evitar que los jugadores lo hagan es su tarea principal aquí.
Tenga en cuenta que el tramposo siempre puede descompilar, cambiar el código, volver a compilar y jugar con este cliente, así que agregue comprobaciones en el lado del servidor. En general, la "Seguridad" proporcionada es solo otra opción, no 100% segura, para dificultar la vida de los tramposos.