Comunidad Game Maker

saludos makero ferhand

CitarParticularmente estoy tratando de desarrollar un proyecto entre dos programadores a mucha distancia. Primero estoy realizando aproximaciones del diseño dentro del modelado que quiero hacer. El proyecto es mediano y lo estoy diseñando por módulos lo más independientes posibles, para que podamos trabajar separados y aún así funcionen en conjunto. Una vez que terminemos quedará el documento de diseño y pensamos publicarlo acá en la comunidad a modo de ayuda como una forma más de hacerlo. 

Por favor publicalo, :D estaré esperándolo, yo voy a llevar un proyecto piloto aunque pequeño por el momento también utilizando mi forma de planear y modelar un videojuego y también cuando concluya el proyecto publicare todos esos documentos y bocetos de diseño e incluso todo el código de proyecto para que veamos como queda, también con el mismo propósito  ;), a demás pienso que de esa forma podre ilustrar mejor mi idea  :P.  y bueno quien lo quiera leer podrá tomar de el lo que considere bueno y practico ;D

Saludos de nuevo compañero ferhand, gracias por todos los aportes a este post, que considero no se ha hablado mucho de ello en la comunidad y es fundamental comentar sobre este tema.

Cita de: licshendu en Enero 07, 2013, 07:52:17 AM
saludos ferhand, mi compadre iros, el creador, penumbra,Marron121 por sus respuestas muy muy completas me están ayudando mucho a diseñar un marco de trabajo personalizado para  GM.
Compadre Iros también es mi deseo que sean en su mayoria los proyectos en grupo que tenemos terminados y el gran problema que vi en nuestros proyectos es que yo no entendía bien tus códigos y tu no entendías bien los míos, ademas de que cuando desarrollamos algún nuevo proyecto, uno de los dos hace la mayoria XD y el otro cuando quiere ayudar no entiende nada  de ese código cuando ya es mucho. ademas de que nos turnamos para programar y no programamos de forma paralela. Espero darle solución a eso y ya acabaremos mas proyectos compadre :D.
compadre el creado, tienes toda la razón al decir que se tiene que iniciar con proyectos pequeños, me gustaría llevar a la practica este modelo de diseño que estoy creando, te unirías a una prueba piloto?

Estuve investigando también mas por mi cuenta sobre metodologías para el desarrollo del software y marcos de trabajo en equipo para el desarrollo del software, y me encontré muchas cosas que podrían servir para trabajar en equipo en GM  :D :
el primero es scrum un marco de trabajo usado para el desarrollo de software.  aquí un vídeo por si alguien se interesa

y el segundo es:
Metodología(proceso) de desarrollo incremental esta es una metodología o también llamado ciclo de vida del software que es usada por el marco de trabajo scrum

Bueno pero las metodologías marcan los pasos a seguir para desarrollar software, pero no dicen que herramientas usar para el diseño. En programacion en general usando el paradigma orientado a objetos, lo que se usa normalmente para el diseño son bosetos de las pantallas y UML


Asi que en definitiva los diseños y boceto (modelado) del juego son extraordinariamente necesarios :D como dice mi compañero ferhand para distribuir las actividades. Yo he estado pensando en que usar para expresar esos diseños, pienso que UML va bien para lenguajes de programacion orientados a objetos, que cubren muchas de las características de ese paradigma, como java, c# etc. pero game maker aunque tiene ciertas características del paradigma orientado a objetos, no las aplica tal cual, asi que pienso que hay que crear diagramas adaptados de UML  y que sirvan específicamente para GM. He visto que la mayoría ocupa una descripción textual y algunos bocetos para diseñar un videojuego, algo como:

Invasores del Espacio

El juego consisten en destruir oleadas de naves enemigas que van bajando a una determinada velocidad y que disparan algunos proyectiles al jugador que se encuentra en la parte inferior de la pantalla.
Estas naves enemigas están ubicadas en filas de x naves enemigas por fila, y son 4 filas de enemigos. Se mueven al inicio hacia la derecha y al llegar al borde derecho bajan todas las naves la distancia de una fila, después cambia su dirección de movimiento hacia la izquierda. Lo mismo ocurre al llegar al borde izquierdo... (y continúan y continua mas descripción)

Así que estaba pensando en usar algunos diagramas basados en UML (porque dicen que una imagen vale mas que mil palabras, ademas que si solo se usan descripciones textuales tienden a ser muy largas) ^^ y nadie las va a querer leer.

Analizando lo que me han contestado en este post y lo que yo pienso, propongo algunos pasos y dos diagramas para el diseño, y los dejo a su critica para mejorarlos o corregirlos:

Bueno antes de esto, quiero aclarar en que me base para proponer esto. Me guié en la filosofía divide y venceras por eso pienso que un videojuego  debe de ser dividido en sub-sistemas ( si es muy pequeño, claro puede no requerir ser dividido en sub-sistemas), siendo un sub-sistema un conjunto de recursos de GM:
    -sprites                        -rooms
    -backgrounds                -objetos
    -scripts                        -fonts
    -time line                     -etc.

Los dos diagramas que propongo son estos:

el primero Diagrama de relaciones de objetos/sub-sistemas tiene como objetivo evidenciar a primera vista las relaciones que forman los objetos, para hacer funcionar un videojuego. La  mayoría de objetos/sub-sistemas en un videojuego interaccionan con los demás , pero no siempre todos interactúan con todos.
Por "relacion" me refiero a que podemos deducir que dos objetos están relacionados de alguna manera ( aun no  sabemos específicamente de que manera detalladamente, porque no lo hemos analizado bien aun) porque alguna parte de la lógica del videojuego los involucra a ambos. Es decir que con que nos digan la lógica del juego podemos crear un diagrama de las relaciones.

Por ejemplo si nos dicen en la descripción general del juego:
El héroe va por los bosques matando monstruos.  podemos intuir que si hacemos un objeto de heroe y un objeto de mounstro, deberemos crearles una relación, porque al interactuar, a fuerza compartirán una que otra característica(variable, recurso) para funcionar.

Como este diagrama hace ver las relaciones entre los objetos/sub-sistemas, nos sirve para darnos cuenta de que al programar alguno de los dos objetos/sub-sistemas involucrados, tendremos que sentarnos antes a definir esos elementos que compartirán debido a que hemos identificado una relación, ya sean nombres de variables, de recursos y de paso, definir que objeto sera el encargado de manear esas variables o recursos.


El segundo Diagrama de definición de objeto/sub-sistema
Basado un pocoen los diagramas de clase de UML y el diagrama genérico que representa cualquier programa  "entrada  ->  proceso  ->  salida"
Pretende determinar que acciones ejecutara cada objeto.
Que información sobre los otros objetos relacionados a el necesita conocer, para operar.(se usa el diagrama de relaciones para este análisis)
por ejemplo cuando un jugador mata a un enemigo en un juego de RPG:
La experiencia del jugador es aumentada.

esta es una variable que podríamos decidir ponerla como global, o podríamos decidir que  uno de los dos objetos que intervienen en la relación, la manejen, por ejemplo en este caso yo decido que el  objeto llamado Panel lo maneje.

de una u otra forma es una variable externa que requiere ser nombrada ya!, para que aunque sean programadores distintos los que se encarguen de los objetos Personaje y Panel, los dos objetos serán compatibles

Y los pasos que propongo son estos:

• 1.Boceto(s) general(es) del juego

   En este paso los diseñadores deberían hacer algunos dibujos donde se ilustren los elementos que intervienen en cada una de las pantallas del juego ( menus, el juego en si, los mundos etc.), definir las proporciones de cada elemento por ejemplo:

• 2.Definir los objetos involucrados

Pensar en todos los objetos que seran necesitados para que el juego funcione, pero pensar en estos objetos de manera genérica, y de una vez definir que nombres darles. yo propongo que  los nombres se escriban iniciando con mayúsculas, como se hace ne java para definir nombres de clases. Creo que de esta manera nos ahorramos el tener que poner objProyectil por ejemplo. Ademas pienso que  para definir nombres de variables o recursos trabajando en equipo, es conveniente no usar abreviaciones, ya que se pretende que el codigo sea entendible para la mayoria.

  Proyectil
  Nave_enemiga
  Pj (esta la voy a corregir ^^, porque si se usan abreviaciones puede haver confucion)
  Control
  Casita

• 3.Definir las acciones de las cuales cada objeto sera responsable, mediante una lista de oraciones

En este paso se tendría que pensar en que acciones cumplirá cada objeto y corresponden al diagrama de definición de objeto.

 

• 4.Definir las relaciones que existen entre los objetos

En este diagrama se busca definir que objetos interactuan con cuales otros.

por ejemplo:


vemos que Proyectil interactua con nave_enemiga y Pj y casita, porque si el proyectil colisiona con cualquiera de ellos los destruye. claro que para casita solo la destruirá cuando el proyectil sea del enemigo pero ese ya es un aspecto interno del objeto Proyectil.

• 5.definir los requerimientos de objetos

   En este paso se tienen que definir lo que un programador necesitara saber de otros objetos, para poder programar un determinado objeto.
Por ejemplo:

Digamos que yo quiero programar el objeto Pj. Como una de las acciones es restar una vida cada vez que muere. necesitaré saber como será llamada esa variable que contendrá el  numero de vidas que tiene el jugador.


Entonces acomplejando el diagrama de descripción de objeto, quedaría:

• 6.definir nombres para variables y recursos que son usados por varios objetos relacionados

  Bueno este paso, es para definir  los nombres de las variables y recursos que usan varios objetos para su funcionamiento. Las demás variables y recursos que sean para uso interno, no importa definiros, solo se perdería tiempo y no tiene sentido conocerlos para los demás programadores, así que esas otras variables pueden ser llamadas al gusto.
Por ejemplo siguiendo con el ejemplo del paso 6. tendríamos que definir el nombre de la variable que contendrá el numero de vidas del jugador. Digamos que la llamaremos vidas y digamos que decidimos que el objeto Control al tener la acción de dibujar el numero de vidas que tiene el jugador y su puntuación, sera el, el encargado de manejar esas dos variables

• 7.definir características de los recursos(sprites,sonidos,background,scripts, etc.)

En este paso seria definir a detalle las características de los recursos, ejemplos de esto serian:
  definir por ejemplo el numero de frames para cada sprite en particular.
El estilo de dibujo usado para los personajes (digamos con estilo anime de personajes chibis con una proporción de 3 cabezas)
Los colores empleados, etc. aquí pueden ser todos los que se quieran.


Pienso que con estos pasos, ya podríamos repartir las tareas y programar paralelamente que es lo que mas me importa resaltar, por ejemplo si voy a programar el objeto Pj,  ya sabría que para restar una vida al jugador tendré que llamar a una variable que esta en el objeto Control llamada vidas

Código [Seleccionar] Expandir

control.vidas-=1

y el que vaya a programar al objeto control, ya sabe que tendrá que llamar a esa variable vidas

Bueno con estos pasos se pretende tener claro desde el principio aspectos compartidos entre objetos, para que se puedan desarrollar por separado y se puedan unir después, asegurando su funcionamientos.Los otros aspectos que son internos , no interesan mucho como funcionen, sino simplemente que funcionen según lo establecido en las acciones.
Esta claro que estos diagramas pueden ser modificados en el transcurso del desarrollo, no precisamente deben estar 100% bien especificados desde el principio, porque no se si les a pasado, pero casi nunca se ejecutan las cosas tal cual fueron planeadas y no exactamente por mala planeacion sino que muchas veces se cambian partes de la mecánica del juego o se añaden nuevas, o al ir desarrollando el juego te das cuenta que omitiste cosas y etc.

Para proyectos  muy grandes, se puede dividir el juego en subsistemas  y usar estos dos diagramas para representar la relación entre subsistemas, definir cuales serán sus acciones y requerimientos. Y ya para cada subsistema, de igual forma se usarían esos mismos dos diagramas. Y así, si un programador abandona el proyecto a la mitad , el que lo releve podrá darse una idea de como funcionan las cosas y como continuar el desarrollo desde ese punto.(para no desperdiciar nada del trabajo realizado)

Espero que no lo consideren como que nos estamos desviando del tema, ya que el diseño es parte de la planeacion y la planeacion parte de un marco de trabajo.
Espero mas comentarios sobre la forma en que planean y se organizan, también criticas a mi propuesta, nuevamente gracias por todas sus respuestas. :D

Saludos makeros :D , tenemos que agruparnos para atacar..!!! XD

:-[fiu.... :-[ que debate..... me leí todos los comentarios...
si quieres hacer un juego simple (de desarrollo simplificado o sea facil de hacer) te recomiendo hacer un proyectil
de enemigo y otro de el pj (jugador)
ahora.... si deseas hacerte la/el  fanfarrona/o quedaria mejor como lo estas haciendo....
la verdad en todo lo que se pueda (exepto en las variables y esas cosas) deseo hacerlo sin scripts ni codes
simplemente con las acciones (aunque se pueden hacer mas cosas con codes y scripts)
por ejemplo yo estoy hacieno mi juego bebe al rescate 1.0 (talvez que haga dos versiones,una lite y otra de pago)
y no utilize scripts.
pd:mi juego es estilo mario bros pero no podes destruir a los enemigos. :- ;)

Citarsi deseas hacerte la/el  fanfarrona/o quedaría mejor como lo estas haciendo....

XD me has dicho fanfarrón indirectamente XD. No quiero fanfarronear solo quiero definir objetos genéricos que después pueda usar como parents para crear por ejemplo 2 o mas objetos heredando esas características genéricas de proyectil y así reutilizar el código. no soy fanfarrón soy bago(flojo) no quiero repetir código. XD
Aunque depende mucho del tipo de juego que quieras hacer, no siempre tiene que ser asi, por ejemplo para un juego pequeño como space invaders   no se ve mucha repercucion si haces dos objetos separados, es mas se entiende mas facil, proyectos grandes o medianos si conviene no generar demasiados objetos, hacerlos genericos ;).

Citarsimplemente con las acciones (aunque se pueden hacer mas cosas con codes y scripts)
por ejemplo yo estoy hacieno mi juego bebe al rescate 1.0 (talvez que haga dos versiones,una lite y otra de pago)
y no utilize scripts.
pd:mi juego es estilo mario bros pero no podes destruir a los enemigos. :- ;)

claro!! siempre hay que buscar hacerlo simple, entendible y ordenado. buen aporte compañero Creador de juegos GM saludos.

Citartendriamos que definir cuantos tipos posibles de relaciones hay en game maker.(yo pienso que muchas ^^!)

Bueno, no me he puesto a pensar en ello, pero creo que más bien son pocas las relaciones entre objetos. En mi ejemplo mencioné 3, colisión y destrucción de instancias (rojo), entrada controlada por usuario (azul), colisión y cambio de variables (rosa). Seguro hay más, pero no creo que muchas más. Se me ocurre IA, para distinguir el control mediante teclado/mouse.

Una pregunta. Suponiendo que el estándar ya está definido como dios manda. Me imagino que en la creación de diagramas, documentos, etc., intervienen todos los miembros del equipo, ¿o esto lo hace el líder nada más?

CitarBueno, no me he puesto a pensar en ello, pero creo que más bien son pocas las relaciones entre objetos. En mi ejemplo mencioné 3, colisión y destrucción de instancias (rojo), entrada controlada por usuario (azul), colisión y cambio de variables (rosa). Seguro hay más, pero no creo que muchas más. Se me ocurre IA, para distinguir el control mediante teclado/mouse.

Bueno quizá debemos pensarlo mas detenidamente y podría ser una evolución de ese diagrama.

CitarMe imagino que en la creación de diagramas, documentos, etc., intervienen todos los miembros del equipo, ¿o esto lo hace el líder nada más?

yo pienso que si intervienen todos, claro que en los diagramas y documentos donde se detallan aspectos generales del juego intervienen todos. y en cosas especificas que le toco desarrollar a cada uno o aun agrupo dentro del grupo de desarrollo, generaran  cada uno,su propia documentación y diagramas bien detallados de lo que hicieron.

   Saludos makeros involucrados en el debate:


  En las metodologías mencionan a distintos roles (trabajos) que se deben desempeñar por los miembros del equipo. Esto tributa a que en los diagramas intervengan la mayoría del equipo.

   Sin embargo, particularmente prefiero realizar los diagramas solo y en intervención del diseñador, en caso de no ser yo. De esta manera las documentación tendrá un mismo estilo. Hay veces que aunque se siga una misma metodología, cada persona tiende a entenderla a su manera y de esa forma lo plasma. Una documentación escrita por varias personas tiende a ser poco comprensible.

  En la escuela siempre eramos un programador web, un programador "descktop", un ingeniero en sistemas y un grafista digital. El ingeniero en sistema era el encargado de realizar la documentación aún no siendo él el diseñador del proyecto inicialmente. 

Cita de: licshendu en Enero 09, 2013, 07:27:46 PM

Citarsi deseas hacerte la/el  fanfarrona/o quedaría mejor como lo estas haciendo....

XD me has dicho fanfarrón indirectamente XD. No quiero fanfarronear solo quiero definir objetos genéricos que después pueda usar como parents para crear por ejemplo 2 o mas objetos heredando esas características genéricas de proyectil y así reutilizar el código. no soy fanfarrón soy bago(flojo) no quiero repetir código. XD
Aunque depende mucho del tipo de juego que quieras hacer, no siempre tiene que ser asi, por ejemplo para un juego pequeño como space invaders   no se ve mucha repercucion si haces dos objetos separados, es mas se entiende mas facil, proyectos grandes o medianos si conviene no generar demasiados objetos, hacerlos genericos ;).

Citarsimplemente con las acciones (aunque se pueden hacer mas cosas con codes y scripts)
por ejemplo yo estoy hacieno mi juego bebe al rescate 1.0 (talvez que haga dos versiones,una lite y otra de pago)
y no utilize scripts.
pd:mi juego es estilo mario bros pero no podes destruir a los enemigos. :- ;)

claro!! siempre hay que buscar hacerlo simple, entendible y ordenado. buen aporte compañero Creador de juegos GM saludos.

yo no dije eso,,yo dije que podria ser muuuuuuuuuuuuuuuchoo mas simple con dos objetos (entiendes?)
te queria dar una ayudita como para que lo pienses.
pd:si quieres entrar o si alguien quiere entrar en mi grupo de desarrollo mandenme mp.