dsl - usa - tecnologias del lado del cliente

Buscando un buen lenguaje del lado del servidor que permita a los jugadores cargar código que se pueda ejecutar

Question

Tenía una idea de un programa que quiero escribir, pero cuál idioma sería el mejor es mi problema.

Si tengo un juego de carreras de autos y quiero permitirles a los usuarios enviar códigos para nuevas pistas 3D interactivas (piense en pistas como las encontradas en la película Speed ​​Racer), vehículos y sus vehículos autónomos, entonces, crearían la IA para su automóvil que le permitirá al automóvil determinar cómo manejar los peligros.

Entonces, necesito un lenguaje que funcione rápido, y como parte de un mapa mundial que el servidor tenga de todas las posibles razas disponibles, y sus diversos estados.

Tengo curiosidad si esta sería una buena razón para considerar la creación de una DSL en Scala, por ejemplo.

No quiero tener que reiniciar una aplicación para cargar nuevos dlls o archivos jar, por lo que muchos lenguajes compilados serían un problema.

Estoy abierto a Linux o Windows, y para los idiomas, la mayoría de los lenguajes de scripting, F #, Scala, Erlang o la mayoría de los OOP puedo programarlos.

El usuario podrá monitorear cómo está funcionando su vehículo, y si tiene más de una IA cargada para ese auto, cuando llegue a ciertos obstáculos, podrá intercambiar un programa de IA por otro a pedido.

Actualización: Hasta ahora las soluciones son javascript, usando V8 y Lua.

Tengo curiosidad de saber si esto puede ser un buen uso para una DSL, en realidad 3 diferentes. 1 para crear una pista de carreras, otra para controlar un auto de carreras y la tercera para crear autos nuevos.

Si es así, ¿serían Haskell, F # o Scala buenas opciones para esto?

Actualización: ¿Tendría sentido que partes diferentes terminen en diferentes idiomas? Por ejemplo, si Erlang se usó para el control del automóvil y Lua para el auto mismo, y también para el circuito animado?

Answer 1

¿Por qué no JavaScript o EcmaScript? El V8 de Google es una forma de espacio aislado muy bonita para hacer esto. Recuerdo que fue realmente muy fácil. Por supuesto, tendrás que escribir algunos enlaces para ello.

Answer 2

Ya había hecho MMO antes, ya sabes, los scripts de respuesta de NPC usaban python, mientras que está en un marco de C ++, dicen que cualquier acción relacionada con NPC activará el framework para ejecutar un script de python (una interfaz C-python, por supuesto, no una llamada de shell como "python /script/run.py"). Los scripts son de tiempo de ejecución reemplazable, aunque necesitan que el jugador o el administrador del juego emita un comando para hacer una actualización, pero de todos modos el programa del servidor del juego no es necesario para reiniciar.

En realidad, me olvidé de si era necesario o no hacer un refresco al emitir un comando para un nuevo tiempo de ejecución del script. Dos años antes ... pero creo que es adecuado para usted.

Answer 3

Considera Erlang:

• Necesita sandboxing / DSL: puede escribir "generadores de analizador" para acceder a las llamadas al sistema crítico / vulnerable. El compilador de stock se puede "mejorar" fácilmente con esta funcionalidad.

• Necesita una programación precisa: tiene cierto control sobre esto siempre que ejecute cada "usuario" en emuladores por separado. Tal vez puedas hacerlo mejor, pero tendré que cavar más. Recuerde que la programación es O (1) :-)

• Necesitas particiones de recursos entre tus "jugadores" (supongo que si entendí correctamente): Erlang no tiene estado compartido, así que esto ayuda desde el principio. Puede crear fácilmente algunos supervisores que miren el consumo de recursos de los jugadores, etc. Consulte también el enlace en el punto anterior (muchos mandos para controlar el emulador).

• Necesita el intercambio en caliente del código: Erlang fue diseñado para esto desde el principio

• Necesita escalar: Erlang escala con SMP muy bien y, dado que se basa en el envío de mensajes con una comunicación intercomunicación perfecta, puede escalar horizontalmente

• Puede optimizar las rutas críticas con los controladores C

• Funcionalidad integrada de "supervisor" para reiniciar con gracia los "usuarios"

Ulf Wiger en concurrencia

Answer 4

Recomendaría Dot Net por varias razones:

Los jugadores pueden elegir en qué idioma implementan sus soluciones: C #, IronPython, VB.NET, Boo, etc., pero a su tiempo de ejecución no le importaría; solo está cargando dinámicamente ensamblados de punto neto en su entorno limitado. Pero esto les da a tus jugadores la opción de elegir su propio idioma favorito. Esto alienta a los jugadores a disfrutar de la experiencia, en lugar de que algunos jugadores decidan no participar porque simplemente no les gusta el idioma que eliges. Su marco general probablemente estaría en C #, pero el código de los jugadores podría estar en cualquier lenguaje de Dot Net.

Sandboxing y la carga dinámica son muy maduras en Dot Net. Puede cargar los ensamblajes de los jugadores en sus propios AppDomains de espacio aislado que se ejecutan con Confianza parcial. No tendría que reiniciar el proceso de contenedor para cargar y descargar estos AppDomains de jugador.

Se anima a los jugadores a "jugar" este juego porque el idioma (cualquiera que sea el idioma de Dot Net que elijan) no solo es útil para secuencias de comandos de juegos, sino que también puede conducir a una carrera real en la industria. Hacer una búsqueda de trabajo para "C #" da muchos más golpes que para "Lua" o "Haskell", por ejemplo. Por lo tanto, el juego no solo es divertido, sino especialmente para jugadores más jóvenes, y en realidad les está ayudando a aprender habilidades verdaderamente útiles y comercializables que les permitirán ganar dinero más adelante. Eso es un gran estímulo para participar en este juego.

La velocidad de ejecución está ardiendo. A diferencia de algunas alternativas como Lua, este es un código compilado que es conocido por su excelente rendimiento, incluso en juegos en tiempo real. (Ver Unity3d, por ejemplo).

Los jugadores pueden usar MonoDevelop en Mac y Linux o pueden usar Visual Studio Express gratis de Microsoft, o pueden usar un buen bloc de notas y la línea de comando. La diferencia con las alternativas aquí es que los IDE maduros y modernos están disponibles si los jugadores deben elegir usarlos.

Un DSL no parece una buena idea para las partes de IA del problema simplemente porque la implementación de la IA para los vehículos va a requerir una gran cantidad de resolución creativa de problemas por parte de los jugadores. Con una DSL, estás encerrándolas solo en la forma en que definiste el problema cuando lo pensaste. Los jugadores inteligentes con una plataforma completa como Dot Net (o algunas de las otras opciones mencionadas) pueden tener soluciones radicalmente nuevas e innovadoras para algunos de los problemas de IA que nunca previste. Con las herramientas adecuadas, estos jugadores podrían implementar programas de aprendizaje loco o pequeñas redes neuronales o quién sabe qué para implementar su IA. Pero si los bloquea en una DSL simplificada, puede que no haya mucha variedad en las implementaciones de IA de los diferentes jugadores (porque su conjunto de expresiones de ideas disponibles es mucho más pequeño).

Para las otras partes del problema, como la definición de las pistas, una DSL podría estar bien. De nuevo, sin embargo, me inclinaría por uno de los lenguajes más simples de Dot Net, como Boo, simplemente para que pueda tener una pila tecnológica unificada para todo su proyecto.

Answer 5

Tu situación suena como un buen candidato para Lua.

• Necesitas sandboxing: esto es fácil de hacer en Lua . Simplemente inicializa el entorno de los usuarios al sobrescribir o eliminar el comando os.execute , por ejemplo, y ya no hay forma de que el usuario acceda a esa función.
• Desea rápido: revise algunos de los puntos de referencia de Lua en comparación con otros idiomas .
• Es probable que necesite interoperar con otro idioma. Lua es muy fácil (IMO) para incrustar en C o C ++, al menos. No he usado LuaInterface , pero esa es la unión de C #.
• Lua tiene funciones de primer orden, por lo que debería ser fácil intercambiar funciones sobre la marcha.
• Lua soporta OOP hasta cierto punto con metatables.
• La estructura de datos primaria de Lua es la tabla (matriz asociativa) que es muy adecuada para estructuras de datos dispersas, como la integración con un mapa mundial.
• Lua tiene una sintaxis muy regular. No hay trucos divertidos con punto y coma o sangrado, por lo que una cosa menos que tus usuarios deben aprender cuando recogen tu idioma, sin mencionar que usar un lenguaje bien documentado te quita parte del trabajo que tienes que hacer en términos de documentarlo usted mismo.

Además, como señala @elviejo en un comentario, Lua ya se usa como lenguaje de scripting en muchos juegos. Si nada más, definitivamente hay un precedente para usar Lua de la manera que usted ha descrito. Y, como menciona @gmonc, existe la posibilidad de que tus usuarios ya hayan usado Lua en otro juego.

En cuanto a cómo integrar con Lua: en general, sus usuarios deberían simplemente cargar un archivo de script Lua. Para simplificar groseramente, puede proporcionar a los usuarios las funciones disponibles, como TurnLeft , TurnRight , Go y Stop . Luego, los usuarios subirían un script como

Actions = {} -- empty table, but you might want to provide default functions
function Actions.Cone()
TurnLeft()
end
function Actions.Wall()
Stop()
TurnRight()
TurnRight()
Go()
end

Luego en el lado del servidor, podrías comenzar con un Go() . Luego, cuando su automóvil llega a un cono, usted llama a su función Actions.Cone() ; un muro lleva a la función Actions.Wall() , etc. En este punto, (con suerte) ya ha puesto a prueba el entorno Lua, por lo que puede simplemente ejecutar su script sin siquiera tener en cuenta la comprobación de errores, si los resultados de sus guiones en un error, no hay razón por la que no pueda pasar el error directamente al usuario. Y si no hay ningún error, lua_State en el código de su servidor debe contener el estado final de su automóvil.

Mejor ejemplo

Aquí hay un archivo C independiente que toma un script Lua de stdin y lo ejecuta como he explicado anteriormente. El juego consiste en encontrar Ground, a Fence o a Branch, y debes correr, saltar o agacharte para pasar. Usted ingresa una secuencia de comandos Lua a través de stdin para decidir cómo reaccionar. La fuente es un poco larga, pero ojalá sea fácil de entender (además de la API de Lua, que tarda un tiempo en acostumbrarse). Esta es mi creación original en los últimos 30 minutos, espero que ayude:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include "lua.h"
#include "lauxlib.h"
#include "lualib.h"
#define FAIL 0
#define SUCCESS 1
/* Possible states for the player */
enum STATE {
RUNNING,
JUMPING,
DUCKING
};
/* Possible obstacles */
enum OBSTACLE {
GROUND,
FENCE,
BRANCH
};
/* Using global vars here for brevity */
enum STATE playerstate = RUNNING;
enum OBSTACLE currentobstacle = GROUND;
/* Functions to be bound to Lua */
int Duck(lua_State *L)
{
playerstate = DUCKING;
return 0; /* no return values to Lua */
}
int Run(lua_State *L)
{
playerstate = RUNNING;
return 0;
}
int Jump(lua_State *L)
{
playerstate = JUMPING;
return 0;
}
/* Check if player can pass obstacle, offer feedback */
int CanPassObstacle()
{
if ( (playerstate == RUNNING && currentobstacle == GROUND) )
{
printf("Successful run!/n");
return SUCCESS;
}
if (playerstate == JUMPING && currentobstacle == FENCE)
{
printf("Successful jump!/n");
return SUCCESS;
}
if (playerstate == DUCKING && currentobstacle == BRANCH)
{
printf("Successful duck!/n");
return SUCCESS;
}
printf("Wrong move!/n");
return FAIL;
}
/* Pick a random obstacle */
enum OBSTACLE GetNewObstacle()
{
int i = rand() % 3;
if (i == 0) { return GROUND; }
if (i == 1) { return FENCE; }
else { return BRANCH; }
}
/* Execute appropriate function defined in Lua for the next obstacle */
int HandleObstacle(lua_State *L)
{
/* Get the table named Actions */
lua_getglobal(L, "Actions");
if (!lua_istable(L, -1)) {return FAIL;}
currentobstacle = GetNewObstacle();
/* Decide which user function to call */
if (currentobstacle == GROUND)
{
lua_getfield(L, -1, "Ground");
}
else if (currentobstacle == FENCE)
{
lua_getfield(L, -1, "Fence");
}
else if (currentobstacle == BRANCH)
{
lua_getfield(L, -1, "Branch");
}
if (lua_isfunction(L, -1))
{
lua_call(L, 0, 0); /* 0 args, 0 results */
return CanPassObstacle();
}
return FAIL;
}
int main()
{
int i, res;
srand(time(NULL));
lua_State *L = lua_open();
/* Bind the C functions to Lua functions */
lua_pushcfunction(L, &Duck);
lua_setglobal(L, "Duck");
lua_pushcfunction(L, &Run);
lua_setglobal(L, "Run");
lua_pushcfunction(L, &Jump);
lua_setglobal(L, "Jump");
/* execute script from stdin */
res = luaL_dofile(L, NULL);
if (res)
{
printf("Lua script error: %s/n", lua_tostring(L, -1));
return 1;
}
for (i = 0 ; i < 5 ; i++)
{
if (HandleObstacle(L) == FAIL)
{
printf("You failed!/n");
return 0;
}
}
printf("You passed!/n");
return 0;
}

Construya lo anterior en GCC con gcc runner.c -o runner -llua5.1 -I/usr/include/lua5.1 .

Y prácticamente el único script de Lua que pasará con éxito siempre es:

Actions = {}
function Actions.Ground() Run() end
function Actions.Fence() Jump() end
function Actions.Branch() Duck() end

que también podría escribirse como

Actions = {}
Actions.Ground = Run
Actions.Fence = Jump
Actions.Branch = Duck

Con la buena secuencia de comandos, verá resultados como:

Successful duck! Successful run! Successful jump! Successful jump! Successful duck! You passed!

Si el usuario intenta algo malicioso, el programa simplemente proporcionará un error:

$ echo "Actions = {} function Actions.Ground() os.execute(''rm -rf /'') end" | ./runner PANIC: unprotected error in call to Lua API (stdin:1: attempt to index global ''os'' (a nil value))

Con un script de movimiento incorrecto, el usuario verá que realizó el movimiento incorrecto:

$ echo "Actions = {} Actions.Ground = Jump; Actions.Fence = Duck; Actions.Branch = Run" | ./runner Wrong move! You failed!