Comunidad Game Maker

Hola a todos :D, yo de vuelta con mis preguntas un tanto muy raras. Pero es algo que ha estado dando vueltas y vueltas en mi cabeza por muchos meses.

Bueno, en tiempos recientes, he querido dejar atrás el desarrollo individual en GM que he tenido desde siempre, y crear un grupo de desarrollo considerablemente grande. Porque a mi parecer para crear un videjuego con fines de lucro y que pueda competir con los videojuegos consolidados, es indispensable trabajar en grupos grandes.

Pero he visto y he comprobado que gran parte de los proyectos en grupo son más propensos a no ser terminados, por diversos problemas, entre ellos que no se estandariza el modo de programar y no se planea lo suficiente y el entendimiento entre integrantes.

En mi caso no he podido terminar ningún proyecto en equipo usando GM.

Así que mi pregunta es,  ¿Como planean ustedes sus proyectos en equipo, como reparten las actividades entre los integrantes del equipo, que practicas utilizan, como estandarizan para asegurar que cada parte desarrollada sea compatible con las otras partes generadas por otros miembros del grupo?, en resumen,¿ Cual es el marco de trabajo que  han utilizado para desarrollar en grupos, usando GM?. ???

(todo esto con la finalidad de recopilar todas las buenas practicas y métodos utilizados, para crear un marco de trabajo mas completo que ayude a guiar al éxito los proyectos en equipo)

(Casi muero de infarto con la supuesta noticia del fin de CGM :P, que bueno que no.)

Saludos nuevamente a todos los que somos integrantes de esta gran comunidad  8)

Para empezar,ten en cuenta que cuanta más gente haya en el grupo del desarollo del juego,más desorganización puede haber. Por ejemplo, yo con mi grupo somos 3 personas (Yo, un grafista y un músico).Las otras 2 personas són principalmente las áreas que no se me dan especialmente bien.

Luego,deberías poner unas normas sencillas, tipo : Haced el "trabajo" puntuales, no discutáis entre vosotros,etc.

Y por último, nosotros tenemos un grupo en Facebook,por el cual hablamos, damos nuestras ideas, y así nos comunicamos bastante.

Espero haberte ayudado un poco, y suerte con tus proyectos. Saludos 8)!

claro que me es de ayuda compañero :D, lo que mencionas del grupo en facebook es una gran idea apara ponerse de acuerdo.
aunque luego los miembros suelen, no entregar las cosas a tiempo normalmente XD.

Únicamente se necesita una cosa para que tengas éxito en empresas de esta naturaleza: SUERTE

XD Basado en mi corta experiencia, este tipo de proyectos (colaboración en línea, sin contacto físico) es un volado y por más que estandarices y planifiques, el factor "SORPRESA" siempre estará presente. Probablemente no seas el único por aquí con el sueño de crear algo que se equipare y compita con los juegos consolidados, pero esos juegos (al menos la mayoría, me imagino) tienen la ventaja de que están desarrollados por un grupo de personas que tienen contacto físico a diario en un lugar común.

No, no estoy diciendo que no hay que participar en proyectos como el que propones, al contrario, apoyo dichos proyectos, lo que digo es que hay que estar preparado por si surge el abandono. Una cosa que yo haría sería poner reglas muy claras, por ejemplo:

A) Cada semana o el tiempo que creas conveniente, cada miembro debe enviar ya sea, un informe de lo que está haciendo, o en su defecto, el trabajo que se le encomendó (un trabajo de tamaño razonable para ser finalizado en una semana) o al menos una muestra del trabajo sin terminar.

B) De no comunicarse algún miembro en un plazo de 15 días con el equipo (no mandó ni informe , ni envió trabajo/muestra) corre el riesgo de ser 'despedido' (Sin rencores, es sólo por el futuro del proyecto y no dejar varados a los demás miembros ) :-[

C) Si un miembro cree que no puede cumplir con un compromiso por causas de fuerza mayor, avisar con dos días de anticipación al equipo. Acordar los días de prórroga para entregar trabajo con el lider del equipo.

D) Calendarizar cada semana o 15 días una reunión virtual con todos los miembros para darle seguimiento al proyecto.

E) Si un miembro ha estado enviando muestras inconclusas (ha estado entregando pocos trabajos completos) de manera continua, se le asignarían encomiendas más pequeñas y otro miembro se encargaría de finalizar los trabajos inconclusos (tomando crédito por ello)

Sé que  estoy sonando a Sheldon Cooper, pero después de algunas experiencias que me han tocado, me doy cuenta que es mejor hablar de estas cosas ANTES DE iniciar el proyecto.

Como dije al principio: SUERTE  ;D

Definitivamente tienes toda la razón, hay que prepararse, porque esas cosas suelen pasar frecuentemente,

CitarB) De no comunicarse algún miembro en un plazo de 15 días con el equipo (no mandó ni informe , ni envió trabajo/muestra) corre el riesgo de ser 'despedido' (Sin rencores, es sólo por el futuro del proyecto y no dejar varados a los demás miembros )

que información sueles pedir en el informe compañero y para que lo usas?

Disculpa algo mas  :-[ que me vendría a la perfección , tienes algunas reglas o estándares para asegurar que el código desarrollado por un integrante sea compatible con el de los demás?

Muy completa la información que me das. Muchas gracias compañero. ;D

Nada de lo que escribí lo he usado, nunca he sido jefe de algún grupo de videojuego.  :-[

Una vez participé como grafista en un proyecto, que también sufrió de abandono y nunca se completó. Después de leer tu post y acordándome de mi experiencia, escribí las sugerencias que se me ocurrieron al momento, para tratar de evitar las fallas que nos pasaron, pero no sé si funcionen, no las he puesto a prueba.

En mi proyecto actual, se puede decir que soy el lider, pero nada más somos un músico y yo, por lo que se me hace exagerado aplicar mis sugerencias. Como no hay otro programador, no sé exactamente qué medidas tomar para maximizar la compatibilidad de código.

No me puse a pensar a detalle que información pedir en el reporte, jeje. Creo que el reporte sería más apto para los programadores, los grafistas o músicos tendrían que enviar una muestra de su progreso.

Es difícil juntar un grupo de desarrollo  :-[, si en grupos pequeños no es necesaria tanta estandarizacion y cosas  que solo harían  mas lentas  las cosas  :P
Gracias por todas tus sugerencias.
Saludos

   Saludos makero licshendu:

  Primero ¡Feliz año nuevo! Te deso mucha salud y dinero...   ...que el resto se puede comprar.  XD

   Preguntas por marcos de trabajo. Bien, creo que antes habría que tener en cuenta el documento de diseño. Ya luego es más facil repartir el trabajo pues se sabe qué se va a hacer y cómo se va a hacer.

  Un documento de diseño de un videojuego viene siendo los planos de un puente que un ingeniero dibujó. En los planosdebe estar reflejado todo, desde las estructuras más grandes hasta las más pequeñas, incluso los cálculos de los materiales a emplear, sus proporciones en las mezclas, todo.

Un documento (documentos) de diseño de un videojuego debe ser igual de explicativo y abarcador. Comienza por lo más general del juego (puede ser la historia, la mecánica, etc.), determina elementos del modelo como módulos y objetos a emplear y llega a lo más particular como funciones a crear para dar respuestas a las necesidades de cada módulo u objeto. Debe ser tan específico que no deje nada al azahar. Cuando el programador vea el documento sepa que programar y tenga una sólida idea de cómo hacerlo. Algo así como: debes escribir una función que recibe cuatro números enteros, que son las coordenadas de dos puntos, y debe devolver la distancia entre los mismos.

De esta forma todos los códigos que se programen son compatibles y ninguno estará duplicado o sin uso.

Insisto que el documento de diseño es muy importante, cuando más grande es el proyecto, más importante se vuelve la documentación, incluso si es para un solo programador.

Espero te sirva de algo, saludos.   

Bueno amigo Lizandro, es verdad que nunca hemos terminado ninguno de nuestros proyectos, y eso que algunos prometen como el Air Express xD, pero en fin, yo he logrado terminar proyectos en forma grupal, acá mis consejitos.


1) Plasmar la idea: Siempre es necesario plasmar la idea, nunca decir "Lo tengo todo en mente, no necesito escribirlo en papel", ya que de esta manera los demás integrantes del grupo no podrán saber con certeza que es lo que se debe hacer.

2) Identificar grupos de trabajo: De esta forma se pueden dividir correctamente todo el personal en diferentes áreas, por ejemplo, tenemos 10 sujetos de los cuales 3 son grafistas, 3 programadores, 2 desarrolladores y 2 historiadores. Es lógico que vamos a tratar de que estén las personas que se especializan en algo en un grupo y no un historiador trabajando de programador porque el trabajo se va a completar en mucho más tiempo. A lo que voy es que se debe ser ordenado a la hora de trabajar, y como alguna vez me dijiste, siempre se tiene que trabajar de forma paralela de manera que la producción no se vea afectada por la espera del trabajo del otro.

3) Organizar y plasmar los avances: Cada cierto tiempo es bueno que el coordinador (también pueden ser los desarrolladores que serían como el director de una película xD) les pida los avances a cada grupo para poder detectar problemas y corregirlos a tiempo. Así se podrán evitar grandes pérdidas cuando el juego esté en una etapa ya avanzada. Llamemosle como se dice en la industria, "Control de calidad correctivo" xD.

4) Buena disposición del personal: Con esto me refiero a que el personal trabaje en lo que realmente se siente cómodo y concuerden sus ideales, como así un buen ambiente de trabajo. Claro está que si es un proyecto por internet como los que hacemos nosotros, el ambiente debe ser el entorno donde se llevan a cabo las conversaciones, todo el mundo debe de tratarse de manera correcta.

5) Finalizando el proyecto: A la hora de finalizar el proyecto lo aconsejable es que no se omita a NADIE en los créditos, de esta forma no habrán problemas de quién creó cada parte del juego. Es algo obvio pero varias veces suele pasar que quedan personas excluídas y suele generar conflictos a la hora de crear un nuevo proyecto.

6) Disfutar de la creación: Que más que decir que en este paso el juego ya ha sido creado y lo único que hace falta es disfrutar y sentirse orgulloso del buen trabajo en equipo :D


Bueno amigo Lizandro, espero que mi mensaje sea de ayuda, no solo para tus juegos con demás grupos, si no para poder terminar los proyectos y en especial "Air Express" y "El sendero oculto" xD

Hola Lizandro, como decia Mas... dire Iros xD es bueno tener plasmado las bases del juego a desarrollar ademas debes empezar con juegos pequeños para iros xD conociendo mejor , y mejor si conformas con mas de 2 personas cada area esto para proyectos grandes.
Por cierto iros el sendero.oculto no es ese rpg que recuerdo vagamente xD.

Saludos ^^.

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:


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.


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

• 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
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

Wow  :o

Se ve que te tomaste en serio lo de implementar el marco de trabajo. Muy interesante tus propuestas de los diagramas de relación y de definición de objeto. Yo creo que ambos diagramas son complementarios y deberían usarse los dos; si se emplea uno solo, faltaría información que no se podría incorporar en el otro diagrama.

Si todo esto lo planeaste  con miras a hacer un proycto en GM, creo que se le podrían agregar detalles. Por ejemplo, en el diagrama de definición de objeto, agregar un área, recuadro o sección que indique si el objeto es padre o es hijo, si es persistente o no; si es sólido o no; si es visible o no. (Quizás esta información vaya codificada en etiquetas o íconos con determinados colores o iniciales).

Más sugerencia que crítica: A primera vista, cuesta descifrar el diagrama de relación. Creo que debería haber distintos tipos de líneas (colores, formas) para especificar el tipo de relación. Por ejemplo, de control a jugador, una línea azul para indicar entrada desde ratón o teclado. De jugador a proyectil, o visceversa, una línea roja para indicar colisión y posible destrucción de instancia. Imaginando un objeto plataforma y un objeto jugador, la línea que los une podría ser rosa, para indicar que hay cambio de variables (dirección, posición, gravedad, velocidad, etc)

Por último, te dejo este enlace para que le heches un vistazo
http://www.youtube.com/watch?v=yPTZh13OTLU

Es una herramienta que podría interesarte a la hora de realizar tus diagramas. Yo la utilicé para crear un diagrama que indicara las habilidades de mi personaje, las variables de las que dependen las habilidades y la forma en que aumentaría de nivel. Lo malo es que es de paga, pero está disponible en demo (probé varias de este tipo y me pareció la más versátil)

A ver qué más se les ocurre a otros  ;D

   Makero licshendu:

   Te lo has tomado a pecho y eso es bueno, quién sabe si de todo este tema saldrá una metodología de diseño de software para videojuegos utilizando la herramienta GM.  XD XD XD

  Por lo pronto estoy de acuerdo con el makero penumbra sobre aquello de que cuesta descifrar el diagrama de relación. Conozco la metodología RUP (Rational Unified Process), una metodología más lenta que Scrum. Entre los diagramas que se emplean en ella está uno llamado diagrama de actividades. En él se explica visual y textualmente como interactuan los diferentes elementos de un posible software, (usuarios, trabajadores, otros sistemas envueltos en el negocio). Es un diagrama muy explicativo y fácil de entender pues expone un grupo de interacciones como una máquina de estados finitos. Te invito a que le eches un vistazo.

  El comentario que hago es que desde el comienzo tratas a los elementos del juego como objetos. O sea cada elemento del juego lo denominas objeto desde un inicio. Todas las metodologías lo que tratan es de brindarnos pasos para transformar una "idea", una necesidad de un cliente, en "software". La mayoría de las veces es difícil saber cuando un elemento de la "idea" es un objeto completo o parte de un objeto y si debería ser así. Las metodologías nos orientan en ese camino, pero nunca al principio. Después de varias etapas dentro del desarrollo con sus diagramas correspondientes es que comienza a dilucidarse qué conforma cada elemento.

  No es para mal mi comentario, sino para bien y mejora. No siempre es lo más optimo convertir todo lo que "veamos" en un objeto, hay veces, muchas, en que la estructura "objeto" está sobre valorada y llega a convertirse en un lastre.  :-[

CitarSe ve que te tomaste en serio lo de implementar el marco de trabajo. Muy interesante tus propuestas de los diagramas de relación y de definición de objeto. Yo creo que ambos diagramas son complementarios y deberían usarse los dos; si se emplea uno solo, faltaría información que no se podría incorporar en el otro diagrama.

CitarTe lo has tomado a pecho y eso es bueno, quién sabe si de todo este tema saldrá una metodología de diseño de software para videojuegos utilizando la herramienta GM.

Si me lo he tomado como un insulto personal XD, es un enemigo que nos ha atacado a todos, o el que me diga que termina la mayoría de sus proyectos en equipo que alce la mano y de paso que por favor nos ilumine.

CitarMás sugerencia que crítica: A primera vista, cuesta descifrar el diagrama de relación. Creo que debería haber distintos tipos de líneas (colores, formas) para especificar el tipo de relación. Por ejemplo, de control a jugador, una línea azul para indicar entrada desde ratón o teclado. De jugador a proyectil, o viceversa, una línea roja para indicar colisión y posible destrucción de instancia. Imaginando un objeto plataforma y un objeto jugador, la línea que los une podría ser rosa, para indicar que hay cambio de variables (dirección, posición, gravedad, velocidad, etc).

Bueno el propósito de ese diagrama es solo para servir de herramienta de análisis, para determinar recursos y variables que pueden llegar a compartir esos objetos, según lo  analicemos mas detenidamente.
Aunque crear después uno mas detallado puede ser también de gran ayuda, ya seria algo mas presido, aunque aun no me doy bien  la idea de cual para mi seria la mejor manera de hacerlo  :-[, tendriamos que definir cuantos tipos posibles de relaciones hay en game maker.(yo pienso que muchas ^^!)

CitarConozco la metodología RUP (Rational Unified Process), una metodología más lenta que Scrum.

RUP creada por los mismos que hicieron UML =)..
^^! bueno aquí nadamas aclarar que scrum es un marco de trabajo y no una metodología compadre ferhand

CitarEntre los diagramas que se emplean en ella está uno llamado diagrama de actividades. En él se explica visual y textualmente como interactuan los diferentes elementos de un posible software, (usuarios, trabajadores, otros sistemas envueltos en el negocio). Es un diagrama muy explicativo y fácil de entender pues expone un grupo de interacciones como una máquina de estados finitos. Te invito a que le eches un vistazo.

si lo conozco ^^ es un diagrama también de UML, aunque no sabría como usarlo XD, también pensé en usar los diagramas de casos de uso, alguna idea compadre de como podríamos usarlos en GM, o convendría usarlos tal cual son, tu que harias?

CitarEl comentario que hago es que desde el comienzo tratas a los elementos del juego como objetos. O sea cada elemento del juego lo denominas objeto desde un inicio. Todas las metodologías lo que tratan es de brindarnos pasos para transformar una "idea", una necesidad de un cliente, en "software". La mayoría de las veces es difícil saber cuando un elemento de la "idea" es un objeto completo o parte de un objeto y si debería ser así. Las metodologías nos orientan en ese camino, pero nunca al principio. Después de varias etapas dentro del desarrollo con sus diagramas correspondientes es que comienza a dilucidarse qué conforma cada elemento.

Tienes toda la razon ^^, antes que convertir todo en objetos se tiene que planear también si es conveniente hacerlo o si no, idear distintas formas de hacerlo y analizar cual sseria la mejor.
Bueno en este ejemplo lo hice asi, porque el juego es muy pequeño ^^, un proyecto mas grande si requeriría forzosamente ese análisis previo... :S me faltaria diseñar algo para eso y no tengo ni idea ^^!.
alguna sugerencia?

Creo que tendría que desarrollar un proyecto completo basado en esto, para expresar mejor mi idea.. me cuesta trabajo expresarla bien XD , saludos compañeros

   Saludos makero licshendu:


  En realidad si está expresando bien la idea, lo que como toda idea tiene puntos de vistas diferentes en diferentes personas. ¿Recuerdas el cuento de los cuatro ciegos y el elefante?  XD

Esto es algo muy engorroso que se ha estado tratando de estandarizar desde hace mucho tiempo, pero solo es posible establecer marcos de trabajos y metodologías para un mismo sistema, al exportarlo a otro comienzan los fallos.

Yo pienso que cuando ya están hechos los planos de una casa y los mismos indican cómo y dónde poner cada piedra y cual va primero, no habrá problemas con los constructores siempre que sepan interpretar los planos.

Por eso insisto en tener primero un diseño completo del software (juego) a implementar. Cuando ya estén todas las especificaciones, los métodos, variables, objetos y pantallas del juego bien explicados, de forma tal que se pueda calcular el flujo completo en la mente o en papel, entonces será muy fácil decidir que tiene que hacer cada programador. Todo es posible una vez que esté todo documentado.

Dónde radica la diferencia, en el diseño del software. Por ejemplo:
* una forma es llegar a diseñarlo tal cual hemos explicado, detallado al punto que simplemente hay que escribir lo que dice en el documento de diseño.

* Otra forma puede ser solo llegar a determinar las variables y las funciones que utilizarán esas variables sin llegar a especificar el código dentro de ellas, dejando a los programadores desarrollar las funciones por dentro, pero sabiendo lo que debe hacer cada una.

*  Otra forma es detallando el juego en módulos independientes unos de otros y brindando la posibilidad a los programadores que desarrollen cada módulo por su lado siempre teniendo en cuanta las especificaciones para interactuar entre ellos. 

Ya eso depende de la metodología de trabajo que escoja el diseñador y el equipo en conjunto, pero siempre partiendo de un diseño previo bien completo.

Citarsi lo conozco ^^ es un diagrama también de UML, aunque no sabría como usarlo , también pensé en usar los diagramas de casos de uso, alguna idea compadre de como podríamos usarlos en GM, o convendría usarlos tal cual son, tu que harias?

  Utilizo los casos de uso cuando el proyecto es muy grande y no logro determinar las partes que lo componen en una simple mirada sin esfuerzo. De todas formas, los casos de uso son super importantes para determinar las funciones del programa. Eso sí, todo comienza desde el punto de vista del usuario, en este caso el jugador.

En el ejemplo de "space invaders" los casos de uso del negocio que yo veo podrían ser "inicializar el juego", "presionar la flecha derecha", "presionar la flecha izquierda", "presionar el botón de disparo" y "cerrar juego". Todos esos porque son inicializados por el usuario (jugador).

  Luego realizaría un diagrama de actividades por cada caso de uso donde intervengan las acciones del usuario y las respuestas del sistema. Estos me permitirán ver los casos de usos más desde dentro.

Con todo esto ya es posible determinar los requerimientos funcionales del software: una lista de "cosas" que no pueden faltar en nuestro software, algunas de ellas no salen del todo dentro de los diagramas, pero debemos incluirlas, por eso es iterativo e incremental.  XD

Ya hasta aquí llega el modelado del negocio y debe comenzar el modelado del sistema.

Particularmente 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.  XD

  La forma en que modelé el sistema es bien enredada, casi nada es un objeto completo. Las características como posición, "sprites", colisiones son solo variables con datos. Quiero que la IA de cada uno sea de la misma forma. Así tendré control sobre todos los elementos sin depender de la estructura objeto de GM que trae muchas características que no necesito. También deseo alcanzar la posibilidad de ingresar elementos nuevos una vez el juego esté hecho completamente para no tener tener que tocar el código más de una vez.

  Veamos que tal me resulta...Pues me he enredado bastante... :-[ :-[ :-[  y todo por la posibilidad de que corra bien en PC de pocos recursos.

  La optimización prematura es el enemigo de todo programador.  XD XD XD