Abstract:
En los últimos años, la creciente popularidad de los juegos casuales para dispositivos móviles y web tiene promovió el desarrollo de nuevos editores de juegos para crear juegos 2D donde el comportamiento de los elementos del juego se describe visualmente y no es necesario para los usuarios tienen habilidades de programación. La creación de videojuegos está en camino de ser democratizado, para que cualquiera que esté interesado, sin un conocimiento avanzado de programación, puede crear juegos para dispositivos como teléfonos móviles o juegos consolas. Sin embargo, a pesar de las mejoras, incluso hoy en día, la mayoría del desarrollo los entornos dependen de la forma de programación tradicional. Este artículo presenta un nuevo 2D motor de juego que reduce la complejidad de los procesos de desarrollo de videojuegos.
Las contribuciones de este trabajo están dirigidas a la simplificación del juego
especificación, también disminuyendo la complejidad de la arquitectura del motor e introduciendo un entorno de edición muy fácil de usar para la creación del juego. El juego presentado motor permite definir el comportamiento de los objetos del juego usando un conjunto muy pequeño de
condiciones y acciones, por lo que la complejidad del uso de bucles y estructuras de datos complejas es evitado Algunos experimentos han sido diseñados para validar su facilidad de uso y su capacidad en la creación de una gran variedad de juegos: usuarios con poca experiencia en la programación han desarrollado juegos de arcade usando el entorno presentado comparando su facilidad con otro software visual popular. Los resultados obtenidos avalan el concepto y la hipótesis de la facilidad y demostrar el potencial de la
presenta el motor de juego 2D.
Introducción
La creación de videojuegos es un proceso realmente complejo donde la participación de un equipo multidisciplinario, como así como el uso de herramientas para ayudar a la creación de contenido, se requiere. Los diseñadores de juegos no solo tienen que lidiar con
los problemas de crear juegos lo suficientemente grandes para encantar a los jugadores, pero también con la complejidad de la técnica características necesarias para los juegos de computadora actuales: recursos gráficos, mecanismos de interacción y reglas de comportamiento
[1] Para simplificar el problema, desde mediados de la década de 1990, el desarrollo del juego ha evolucionado rápidamente, principalmente
debido a la aparición de los motores del juego. Salieron con el objetivo de crear software reutilizable para proporcionar un
una forma más fácil de generar juegos y reducir sus tiempos de producción. Aunque, al principio de este nuevo desarrollo
la tenencia de la filosofía, la ocupación principal de estos motores fue el sistema de renderizado, otros como
la inteligencia artificial, la animación, la física, el sonido o la red aún no se han abordado en ellos. Progresivamente cada motor de juego ha incluido estos subsistemas y avanza en su modularización. Esencialmente sobre esa base, todo se trata de desarrollar una forma más simple de crear nuevos juegos y sus componentes sin cambiar el núcleo del sistema, conocido como el motor. El valor de esta separación introducida entre el juego y el juego
el motor es esencial en la industria actual.
En sus primeros días, los motores del juego se desarrollaron como bibliotecas de lenguaje de programación, por ejemplo C ++. Era esencial para el desarrollador tener un amplio conocimiento de codificación para poder trabajar con ellos y para tratar con sus estructuras de datos y algoritmos. La curva de aprendizaje era demasiado empinada para los motores del juego desarrollo. Con los años, este tipo de software ha dado un paso más, evolucionando a otro nivel de abstracción incluyendo editores visuales. De esta manera, los usuarios pudieron construir visualmente la interacción y el comportamientos de los personajes y objetos, e incluso para depurar errores. Además, el concepto del objeto del juego era introducido como el elemento clave para cualquier composición de escena, donde diferentes tipos de componentes y propiedades se pueden organizar para cumplir su función, incluso para ejecutar scripts.
Antes de continuar con el estudio sobre los motores de los juegos, es necesario dedicar un tiempo a diferencia existente entre aquellos que usan un modo de visualización 2D y aquellos que usan un 3D. En esos casos,
la diferencia radica en la complejidad de la creación de contenido más que en el diseño conceptual del juego. Un motor capaz de crear fácilmente contenido 2D puede no ser capaz de desarrollar las mismas cosas para 3D [1]. Incluso para los diseñadores, donde el
el conocimiento requerido de modelado y animación en 3D es, en la mayoría de los casos, demasiado específico y demasiado complejo. Esto es por qué el acceso al desarrollo de juegos y su democratización es más accesible en 2D.
Para este propósito, buscando generar soluciones viables para este tema, este documento presenta un enfoque simplificado motor de juego dirigido a proporcionar herramientas a los no programadores y facilitar el desarrollo del juego. Las contribuciones
se centran en la simplificación de las especificaciones del juego, haciendo que la arquitectura del juego y el editor del juego diseño más comprensible y fácil de usar. Como punto de partida para este esfuerzo, la estructura general va para ser especificado y resumido mediante la introducción de la arquitectura del motor de juego 2D basada en el concepto del juego objeto y su lógica, junto con su propio editor de juegos. Por lo tanto, los usuarios pueden crear juegos de arcade sin el dependencia tradicional de bucles, expresiones lógicas o estructuras de datos complejas [2].
Para alcanzar esta suposición, el sistema ha surgido dos ramas diferentes para construir sobre él: uno técnico y uno basado en el usuario. En el primero, una estructura de sistema conceptual fundada en la concurrencia
entre el motor del juego y el editor del juego se ha ideado para desarrollar una conexión resistente entre ellos. Para este efecto, cada proceso dependiente del usuario se ha simplificado tanto como sea posible para proporcionar un
nivel mínimo de abstracción en términos de tecnología. También se ha definido el objeto del juego y sus características, basado en este concepto simplificado, junto con la definición del juego y sus objetos de escena respectivos, también descritos y discutido últimamente en el periódico. Por el contrario, en la segunda rama, se realizó un análisis comparativo con
otras herramientas destinadas a crear el mismo género de juegos. En este sentido, este análisis se ha realizado en un ámbito centrado en el tipo de juegos que este sistema es capaz de realizar: los juegos de arcade. En este punto, los límites sobre lo que en realidad es un juego de arcade debe definirse. Para cualquier juego, para ser considerado como un juego de arcade, tiene que mostrar algunas cualidades, como niveles cortos, controles simples e intuitivos, física simple y un rápido aumento dificultad [39]. El término siempre se ha alineado con la industria de la diversión que funciona con monedas debido a su
contexto original de producción y uso. Además, como parte de este alcance, es posible seguir investigando.
El resto del documento está organizado de la siguiente manera. En la sección 2, se presenta el trabajo líder en el área
con el estado del arte en los motores de juegos. A continuación, en la sección 3, se desarrolla la concepción técnica de este trabajo,
centrándose en la especificación del motor del juego junto con el editor del juego y el sistema de especificación del comportamiento.
A continuación, en la sección 4, se presenta un ejemplo completo de caso de uso a través de dos métodos de programación. Entonces el
experiencia adquirida en un experimento llevado a cabo con niños junto con sus resultados se presentan y discuten en sección 5. Finalmente, la sección 6 analiza las principales contribuciones de la propuesta y sus limitaciones junto con un avance de los trabajos en curso.
- Estado del arte
La industria de los videojuegos, como cualquier otra, trata de minimizar los costos de producción para maximizar los beneficios
[4, 5]. Con esto en mente, a mediados de los años 90 algunas compañías, como Id Software, agregaron a sus sistemas de juego un modularización en sus motores principales, el arte y las reglas de los juegos. Entonces, con esta filosofía, ellos desarrolló el juego Doom de First Person Shooter (FPS), del cual cualquier otra adición o cambio fue bastante
más fácil de implementar en el sistema: modificar niveles, personajes, armas o incluso crear juegos nuevos. Esto llevó el concepto de motor de juego y herramientas conferidas a los desarrolladores para crear nuevos juegos de una manera más fácil y
dando lugar a la comunidad mod. A finales de los 90 algunos juegos como Quake III de Id Software y Epic Game’s Unreal [1, 6] se construyó sobre una concepción modular y reutilizable. De esa forma, los motores de juego mejoraron posibilidades de personalización que agregan características de codificación, por ejemplo, funcionalidades de scripting como Quake C. punto, las empresas de desarrollo de juegos se dieron cuenta sobre el interés comercial en las licencias de motores de juegos, comenzando una mira hacia una segunda fuente de ingresos.
Como las líneas entre un juego y su motor son borrosas, algunos motores hacen una clara distinción entre Código de motor y código de juego, pero otros no. Para llevar a cabo esta subdivisión es necesario hacer uso de una arquitectura basada en datos. De esta forma, un motor de juego funciona como un reproductor de video, capaz de ejecutar cualquier juego
siempre que tenga un formato de archivo legible Sin embargo, es capital considerar que cuanto más general es un juego motor, será menos eficiente en algunas plataformas. Por ejemplo, un motor seleccionado para una escena al aire libre
No es lo mismo para interiores, la tecnología requerida puede ser bastante diferente. Sin embargo, la mejora en el hardware gráfico, la tecnología de visualización y la estructura de datos están cerrando la brecha entre los motores de los juegos
diferentes propósitos. Hoy en día, es posible crear juegos 2D o 3D con el mismo motor de juego. Aunque la especialización sigue siendo capital [1], la creación de un Juego en línea multijugador masivo (MMOG) es bastante diferente de un FPS. Las características requeridas de los motores de juego pueden ser muy diferentes. Por ejemplo, los sprites animados en 2D son bastante más simple de configurar que los algoritmos de visualización 3D realistas [22], o de la misma manera, cálculos de colisión
y las simulaciones físicas en 3D son mucho más complejas [29]. Un ejemplo de estos motores de juego es Unity [24, 28], una poderosa plataforma capaz de desarrollar proyectos para juegos 2D o 3D, donde un profundo conocimiento del motor del juego
términos y características y una experiencia avanzada en el lenguaje de programación C # se requiere para poder para desarrollar cualquier cosa En algunos de estos editores de juegos, hay sistemas de programación visual adicionales como visual conectores entre los componentes. Un ejemplo es el sistema Blueprint Visual Scripting en Unreal Engine
[27]
En la búsqueda de este objetivo, algunas compañías han desarrollado algunos motores de juegos 2D diseñados para creadores de programadores. Para recapitular, un breve resumen comparativo de la simplicidad y uso de la lógica del juego tiene llevado a cabo para mostrar las diferencias en la especificación de comportamiento entre el juego 2D más popular
motores. Un breve resumen de estos análisis se presenta en la Tabla 1, donde los artículos se ordenan en un ascendente jerarquía basada en la cantidad de nodos y su facilidad de uso. Algunos conceptos han sido analizados en ellos, como el lenguaje de scripting y la plataforma utilizada para desarrollar, escritorio o web. Por otra parte, el comportamiento
Sin embargo, aunque estos pasos son muy significativos, el uso de este tipo de software aúnnrequiere altos perfiles técnicos y capacitación específica, dejando fuera a la mayoría de los usuarios potenciales de estas tecnologías [13, 14], especialmente aquellos que están aprendiendo programación. Considerando esto, es necesario encontrar una manera más simple para crear juegos, donde los usuarios inexpertos podrían desarrollar sus propios juegos haciendo uso de gráficos entornos que no requieren habilidades de programación [15]. En este asunto, Furtado et al. [16] proponen un descripción de los motores de juego basados en un conjunto de capas más abstracto y expresivo. Además, Zarraonandia et al [17,18] presentaron en su trabajo un modelo conceptual para organizar las características del juego de forma modular. Conducido por un diseño, una descripción y una definición para crear una combinación de subjuegos basada en un conjunto de configuraciones configurables elementos y un vocabulario básico para cada característica. Incluso los métodos de ingeniería de software han surgido como posible forma de abordar este problema, proponiendo una sistematización del proceso de desarrollo del juego [19, 20, 21].
Todo este análisis demuestra que el desarrollo del motor de juego todavía tiene potencial para ser simplificado y aliviado.
- El motor de juego simplificado
Aunque hoy en día existen varios motores de juego con un diseño para no programadores, ya que
En la Tabla 1 se muestra, el desarrollo del juego sigue siendo una tarea compleja y queda mucho por hacer. Cada uno de los
Los motores de juego presentados anteriormente conservan varias características complejas: interfaz de usuario, descriptores lógicos, comportamiento
especificación, objeto del juego y sus características de comprensión.
El objetivo principal de este trabajo es facilitar los procesos de desarrollo del juego, que a pesar del progreso son
sigue siendo demasiado complejo. Para realizar esta tarea, es necesario facilitar la comprensión de los conceptos conectados a las características técnicas complejas utilizadas hasta ahora y para reemplazarlas por otros conceptos más convencionales. Para esto
razón, el juego se ha expresado como una obra teatral interactiva donde los niveles son las escenas y el el juego se opone a los Actores. Esta premisa ha sido la fuerza impulsora para el diseño de un motor de juego simplificado (SGE) sistema de descripción y, en consecuencia, un entorno de desarrollo de juegos simplificado.
Sobre esta base, la especificación SGE ha sido desarrollada a partir del concepto Actor y su comportamiento reducción de descriptores junto con una arquitectura SGE estrecha basada en una arquitectura de motor de juego clásica. los resultado de este desarrollo ha producido un sistema donde bucles, expresiones lógicas y estructuras de datos complejas
no son necesarios, lo que ha llevado a un sistema general con los fundamentos para el diseño de un Editor de SGE. De esta manera, se ha hecho un esfuerzo en el acceso a los procesos de desarrollo del juego, mediante creando una aplicación basada en web 2D donde el método de guión se basa en árboles de decisión con un conjunto reducido de elementos de descripción de comportamiento. Además, por su concepción basada en la web, los usuarios tienen acceso completo a la herramienta y su repositorio en cualquier momento y en cualquier lugar, independientemente de la plataforma utilizada y sin ninguna previa instalación.
Con todo esto, las siguientes subsecciones analizan los elementos que contribuyen al motor del juegosimplificación: la especificación del juego, la arquitectura del juego y el editor del juego.
3.1. La especificación del juego
En el motor del juego presentado en este trabajo, el juego, las escenas y los actores son el sistemadescriptores. Básicamente, un Juego SGE se puede representar como un conjunto de Escenas con conjuntos de Actores, donde los Actores son los elementos presentes en el nivel y la Escena es el escenario utilizado por los Actores. El concepto detrás de esta configuración es hacer que los actores funcionen como agentes independientes [25] llevando a cabo sus roles e interactuando entre ellos y con la configuración de escena. En consecuencia, se ha desarrollado una estructura de especificación de juego, ya que el presentado en la Figura 1, desde el Actor, y a través de sus Propiedades y Reglas, cualquiera de estos tres elementos pueden configurarse o modificarse
El juego es el objeto principal para la estructura de datos del juego. Sus propiedades están relacionadas con la pantalla
resolución y la orientación de la pantalla junto con el sonido vinculado a todo el juego. Además, tiene la opción de agregue variables personalizadas para almacenar algunos requisitos del juego, por ejemplo, para almacenar la puntuación del juego. En el futuro,
el siguiente paso en la estructura de datos del juego es la Escena.
Tomándolo como contenedor de un actor, la escena es la responsable de almacenar las propiedades de la cámara, como la posición, el ángulo y el zoom. También establece la información de gravedad y, al igual que en las propiedades de Game, también tiene la opción de agregar variables personalizadas. Finalmente, el último de los tres elementos principales en la estructura de datos del juego es el Actor. Es el más complejo, ya que es la clave en
que toda la interacción se apoya.
3.1.1. Actor properties
Los actores son el único elemento en la escena y están organizados por una lista ordenada para determinar el orden de visualización De esta manera, todos los elementos dispuestos en una escena, como los personajes, fondos, decoración, emisores de sonido, marcadores o HUD, son Actores. Todo esto da paso a un sistema simplificado donde
entran en juego como el elemento clave de la definición del juego, a través del cual todo es realizado por su Propiedades y sus reglas. En un motor de juego convencional, el concepto de actor se expresaría como un juego objetos con diferentes tipos de roles: luces, cámaras, sonidos, geometría, etc. Sin embargo, en este caso, este especificación solo requiere el uso de un tipo de elemento: el Actor, lo que lleva a la desaparición de la confianza en la jerarquía de juegos clásicos, un tema principal en la implementación de juegos tradicionales, pero en realidad no es esencial para hacer la mayoría de los juegos de arcade clásicos.
Además, se ha agregado otra característica a cada Actor. Tienen un conjunto predeterminado de Propiedades, asimismo, a un software de dibujo: color, ancho de línea, etc .; pero aquí, tiene la capacidad de almacenar su propio unos como variables personalizadas, así como para las escenas y el juego. Los diferentes tipos de datos listos para ser almacenados como
Las propiedades son imágenes, sonidos, texto, números y booleanos. Estas propiedades impulsarán el tiempo de ejecución del sistema junto con las reglas de comportamiento de los Actores. En este sentido, también son útiles para establecer el comportamiento de los Actores
reglas, a través de las cuales juegan sus propios roles. Como un ejemplo de ellos, una propiedad de «puntos de vida» se puede sentar a controlar la vida de un actor. Las propiedades del actor pueden clasificarse y organizarse en categorías, para obtener un
una mejor comprensión para el diseñador del juego. Estas categorías son:
- Básico. Estas propiedades se relacionan con la posición, la escala y la rotación del Actor. Además, incluye información sobre el perfil de forma de colisión y si el objeto está habilitado o deshabilitado.
- Gráfico. Relacionado con las propiedades visuales y gráficas: la textura Actor y otras opciones de transformación como
voltear, repetir y desplazar. - Texto. Los actores pueden mostrar el texto en una posición determinada con una fuente y estilo determinados, todos
determinado por el diseñador. - Sonar. Un sonido se puede asociar al Actor. Presenta algunas propiedades para permitir la modulación de
su volumen, para determinar el momento en que comienza y si está en bucle. - Física. Estas propiedades están relacionadas con el tipo de cuerpo físico: dinámico, cinemático o estático. Otro
características tales como su velocidad y sus propiedades dependen del material como densidad o fricción son
incluido en esta categoría. - Personalizado. Además, es posible almacenar información sobre variables para personalizar los juegos aún más.
3.1.2. Las reglas del actor
Los actores están a cargo de administrar cada evento de lógica de juego que ocurra en el Juego. Para ese propósito, un sistema de reglas ha sido diseñado para definir la lógica y los comportamientos interactivos del juego. Un comportamiento la regla está determinada por un sistema de árbol de decisión [26] impulsado por un conjunto reducido de Acciones y Condiciones, listo para ser ejecutado si el flujo pasa a través de ellos de acuerdo con si las Condiciones existentes se cumplen o no. Un diagrama de la configuración de estas reglas se muestra en la Figura 2, donde una especificación lógica hipotética está determinada por un
árbol de decisión.
En este sentido, la estructura de la Regla está definida por dos elementos: Acciones y Condiciones, que son arreglado en una composición determinada por el usuario para realizar las Acciones para un comportamiento específico cuando
La condición se cumple, cuando no se cumple o en ausencia de Condiciones. Además, en términos técnicos, tanto acciones como Las condiciones están listas para trabajar con expresiones numéricas y con funciones matemáticas: sin, cos, tan, asin,
acos, atan, sqrt, random, etc; y los tipos de datos admitidos por este sistema son números y booleanos.
Las acciones son los elementos que definen los comportamientos específicos de los Actores. En este sentido, una profunda reflexión para generar la simplificación adecuada y más estable se ha llevado a cabo durante el tiempo de este trabajo ha tomado, para organizar un conjunto mínimo de acciones predeterminadas y luego simplificar la lógica del juego. los
El estudio ha producido un resultado de quince acciones, de las cuales algunas son dignas de ser descritas brevemente:
- Animar Organizador y controlador de animación. Listo para ejecutar animaciones organizando sprites en un tasa específica de cuadros por segundo.
- Destruir Esta acción elimina al actor de la escena cuando se activa.
- Editar. Para cambiar cada Propiedad por un valor o expresión específica. Funciona igual para el Juego, el
Escena o el Actor. - Mover. Para traducir al Actor una cierta cantidad de unidades en la pantalla. Tiene una Acción relacionada llamada Mover
Para, viajar hacia un puesto específico o Actor. - Empujar. Para aplicar fuerzas sobre el Actor. También tiene una acción relacionada llamada Push To y otro paquete
trabajando con el mismo concepto para aplicar fuerzas angulares llamadas Torque. - Girar. Para girar el Actor un cierto número de grados. También hay un giro a la acción.
- Escenas. Para manejar la gestión de escenas con Añadir escena, Eliminar escena y Ir a escena.
- Engendro. Un generador automático de copia Actor.
- Sonar. Para iniciar un sonido con el sonido Play.
Por el contrario, los otros elementos de la Regla son las Condiciones. Son los desencadenantes del evento, responsables de
definir las Acciones a realizar en un punto de toma de decisión determinado por una ocurrencia. Del mismo modo, en cuanto a la Acciones, se han reducido para resumir cada posible caso de uso. Para eso, solo seis opciones tienen sido definido, explicado abajo. - Comparar. Compara dos valores de datos o expresiones de cualquier Juego, Escena o Actor Propiedades con otro valor o expresión
- Comprobar. Para verificar si se cumple una propiedad booleana o no.
- Colisión. Comprueba si dos actores están colisionando. Se basa en la forma de colisión del actor.
- Teclado. Para recopilar qué tecla se ha presionado en el teclado.
- Toca. Para gestionar la interacción del usuario con el mouse o eventos táctiles a través de dispositivos.
- Temporizador. Para realizar conjuntos de acciones después de una determinada cantidad de segundos.
Este enfoque del problema intenta ser una solución al pensamiento de codificación y computación Introducción. Estos elementos pueden proporcionar conocimientos básicos de codificación sin renunciar al complejo juego desarrollo. Para este propósito, también se ha descartado la dependencia de oraciones recurrentes como bucles, ya que el
Game Loop implementa la evaluación del comportamiento de cada Actor en cada iteración. Además, en unaintentar simplificar aún más el desarrollo del juego, el uso de expresiones lógicas y datos complejos estructuras tales como matrices, arreglos u otras estructuras complejas como árboles o gráficos para crear las Reglas del Actor ha sido descartado, lo que obviamente construye árboles de decisión más complejos y, sin embargo, alivia el comportamiento.
3.2. La arquitectura del motor del juego
Básicamente, para la mayoría de los motores de juegos existentes, sus arquitecturas son bastante similares y varias de sus subsistemas permanecen sin cambios. Esto se debe a que son necesarios para prácticamente cualquier juego. No importa cómo agresivamente se hace la reducción de los subsistemas, un sistema generalista todavía necesitará algunos tales comoprestación, sonido, evaluación lógica, sistema de entrada e incluso física. Es por esta razón que los subsistemas que este sistema SGE se construye coincide con uno clásico: física, audio, representación, lógica de juego y entrada.
De cualquier manera, cada uno de ellos tiene características en su arquitectura con posibilidades de reducirse.
En esta propuesta, se ha definido una estructura de clases y jerarquía, donde el motor del juego tiene un conjunto de cinco submódulos como controladores de la computación de la física, la gestión de eventos, las evaluaciones lógicas, la reproducción de sonido y la representación de escena. Una representación de esta arquitectura se presenta en la Figura. En de esta forma, cada Actor será evaluado para todos ellos en un Game Loop continuo de acuerdo con el configuración de la escena y el juego. Este Game Loop viajará a través de estos cinco submódulos en cada iteración. Eso comenzará en la física, pasará por el manejo del evento, continuará en la evaluación lógica del juego y
finalmente mostrará el estado del juego por los módulos de sonido y renderización. La implementación de un juego
Loop en un motor de juego clásico puede convertirse en una tarea muy desafiante y muy compleja [2], con la capacidad de
absorber a los usuarios en scripts personalizados para cada objeto del juego que se ejecutará en diferentes etapas del juego, o
incluso en un número diferente de veces por fotograma, lo que hace necesario un gran conocimiento del motor del juego
estructura y operación.
3.3. El editor de juegos
Para democratizar el desarrollo del juego, es necesario apuntar de la manera más fácil y accesible
para presentar las herramientas de desarrollo del juego para los desarrolladores de juegos. Por esta razón, la creación de un
editor de juegos complementarios se ha considerado tomar como punto de partida algunas de las características principales de la
literatura de interfaces de usuario existentes y su posterior integración en todo el entorno SGE.
3.3.1. El editor de escena
Después de estudiar la literatura de la interfaz de usuario y la forma de encajarla en el sistema SGE, algunos derivaron
la decisión fue tomada. El primero fue replicar el diseño de la interfaz de usuario y los conceptos de interacción detrás de un
software de presentación de diapositivas [30]. Estas aplicaciones están diseñadas para ser muy fáciles de usar y tienen una muy similar
estructura de los juegos: varias diapositivas similares a los niveles del juego o Escenas en este caso, colocación de objetos y
propiedades como Actores y sus Propiedades y, finalmente, animaciones interactivas de eventos como las Reglas de comportamiento.
Otra característica del diseño está relacionada con el aspecto visual. En este sentido, Google Material Design [31] ha sido
el núcleo de esta especificación de interfaz. La definición de diseño está dirigida a aplicaciones de dispositivos múltiples con fluido
navegación para cada uno de ellos. Un ejemplo de esta configuración se muestra en la Figura 4 con un Juego de Plataforma.
La lista de Escenas para ese juego está disponible en el menú de navegación. La captura representa el diseño
entorno para la primera escena. El Actor representado por el personaje azul es seleccionado y su artilugio y su
el menú gráfico asociado es visible. A través de este menú, el usuario puede acceder a las propiedades del Actor,
Lista de reglas y algunas opciones adicionales como copiar y pegar y eliminar. Un ejemplo de estas características se muestra en
Figura 4, donde, después de seleccionar el ícono de propiedades del Actor, un panel modular sale del lado derecho del
pantalla que muestra todas las propiedades organizadas en pestañas de acuerdo con la agrupación presentada en la sección 3.1.1.
El paquete completo se basa en objetos materiales dispuestos en un espacio y tiempo específicos, que se ajustan correctamente con el
Filosofía de SGE. De esta forma, es posible crear una aplicación única lista para trabajar en dispositivos táctiles
y en contexto basado en web, simplemente configurando los controles para que estén listos para funcionar en cualquier dispositivo, táctil o basado en puntero.
3.3.2. El editor de reglas
Además del editor de escenas, existe otro entorno de herramientas de edición ligeramente diferente donde las reglas
asociados a los actores están definidos. Este editor de reglas se ha creado como un editor de árbol de decisión simple, donde
Las acciones y condiciones se organizan y configuran visualmente hasta que se cumpla el comportamiento deseado.
De forma similar a las Propiedades del actor, este editor de reglas es accesible mediante el menú contextual del Actor. Ahí,
la pantalla mostrará el editor del árbol de decisión, a través del cual los comportamientos pueden ser compuestos por la disposición
de las Acciones y Condiciones. Se puede acceder a estos elementos desde dos fichas amarillas y azules, que sirven
accesos directos al conjunto reducido de Acciones y Condiciones, respectivamente. Además de eso, la edición de la Acción y
Los elementos de condición están disponibles desde un panel modular del lado derecho. Después de seleccionar uno de los elementos, ese panel
saldrá mostrando las Propiedades y las opciones determinadas para ello. Como un ejemplo de estas características, en Figure
5, se muestra un árbol de decisión que realiza un comportamiento Jump para un Jugador específico en un Juego de Plataforma. En eso
Por ejemplo, primero se verifica si el reproductor colisiona con el piso y luego, si se presiona la tecla hacia arriba, en ese caso
la acción de salto se produce al establecer la velocidad del eje y del Reproductor a 300 píxeles por segundo. Si algunos de estos
Las condiciones no se cumplen, el flujo viajará a través de su rama izquierda y no se realizará ninguna Acción. También en el
figura, el panel derecho muestra las Propiedades del elemento seleccionado, en este caso, el elemento Editar Acción.
Además, para facilitar la comprensión de la Regla, se adjunta una versión de pseudocódigo en el Algoritmo 1.
- Ejemplo de juego: Candy Crush
El propósito de este trabajo no es socavar la forma tradicional de scripting, sino demostrar que existe
son formas más simples de crear los mismos contenidos sin habilidades de programación. Al hacerlo, a primera vista, parece
Es difícil imaginar que un juego como Candy Crush [3] pueda construirse con SGE. Es un videojuego de tres puzzles, en
que los jugadores tienen que intercambiar dulces en un tablero de juego para producir combinaciones de tres o más con el
del mismo color, esos desaparecerían y eso le permitiría al jugador ganar puntos y alcanzar objetivos. Para
desarrollador clásico, el problema lleva a pensar en una matriz para almacenar el tablero de juego, pero es difícil de creer que
un usuario no experimentado piensa en estructuras de datos tan complejas. El sistema SGE permite que los usuarios tengan
disponible un enfoque diferente como forma de crearlo sin utilizar esas estructuras de datos. La clave para lograrlo es por
tratando de resolverlo usando una metodología basada en agentes, donde cada elemento funcionará con un individuo y
conjunto independiente de tareas para componer una comunicación entre ellas, que está cerca de la forma común
de pensar A través de este modelo, la forma de abordar la lógica del juego cambia y establece las interacciones entre
los elementos para crear un juego y sus características.
Para establecer una comparación entre estos dos enfoques, este juego se ha desarrollado utilizando un
método de programación común que se ha implementado con la herramienta de programación visual Scratch y también
mediante el uso del método SGE. Además, para facilitar su comprensión, ambos métodos han sido anexados por
pseudocódigo. Sin embargo, es necesario aclarar que esta sección no es una comparación entre SGE y
Rasguño. Esta es una manera de presentar una línea de base distinguible entre la forma de programación clásica y la
propuso en este trabajo crear programas complejos e interactivos como los videojuegos, tratando de demostrar que
es posible realizar el mismo tipo de proyectos de una manera más fácil.
4.1. Solución Scratch
En el procedimiento de inicialización, el tablero de juego debe ser recorrido asignando, para cada Candy, un
textura aleatoria con un color específico. El código necesario mostraría una secuencia de instrucciones similar a la
se muestra en el Algoritmo 2 y su configuración relativa de Scratch ilustrada en la Figura 7. Por simplicidad, en el
siguiendo algoritmos y figuras, se supone la inicialización de variables.