Comunidad Game Maker

Yo soy licenciado en informática trabajo en una dependencia de gobierno de mi país desarrollando sistemas, aunque me hubiera gustado estudiar una carrera de desarrollo de videojuegos igual la familia hubiera intervenido XD, aún sigo soñando con algún día trabajar en una empresa desarrolladora de videojuegos. Aunque  por otra parte agradezco la pasión que tengo por el desarrollo de videojuegos ya que fue mi motor para no rendirme y aprender programación con lo cual ahora tengo trabajo, no abandono la idea de trabajar algún día en el desarrollo de videojuegos. Programar aplicaciones administrativas es divertido pero programar videojuegos es mucho más divertido.
;D

Me apunto soy programador, ahora mismo estoy trabajando en un proyecto algo similar en  :GM8: , pero ya en poco migraré a  :GMS:(que no lo he usado nunca) XD saludos.

jesuslizandrohv@gmail.com

CONTINUE ? 9.. 8.. 7.. 6.. 5.. [INSERT COIN]..   Yo también  haré mi aportación!! seria un ingrato si no devolviera algo de todo lo que me han enseñado  :), podemos evitar todo esto compañeros =) un saludo a todos, mereuso  a despedirme de esta grandiosa comunidad

La noticia me entristece mucho, prácticamente los conocí a la vez que comencé mi carrera como Licenciado en Informática, ahora mismo ya termine la carrera y me encuentro trabajando, muchos de los conocimiento adquiridos se los debo a todos ustedes por lo cual quisiera regresar les un poco de todo lo que me han aportado para evitar que cierre o ya es una decisión definitiva su cierre? espero que no, pienso que este foro tiene  mucho que ofrecer al publico aun.

yo también pienso que es una buena idea, aunque yo pienso que quizá no como secciones nuevas, pero en definitiva eso le hace falta al manual ser enriquecido con ejemplos de cada función :D algunos cuantos al menos,estaría fantástico para entenderlas mejor, con menos leídas, y con menos experimentos fallidos, aunque siempre el experimentar te lleva a un mejor entendimiento.

apoyo la idea, saludos compadre makero, veamos que opinan los admin y donde nos sugieren ubicar la idea.  8)

CitarLos engines pueden subirse a la sección de Descargas y compartirlo con los demás, ¿para qué crear una sección nueva?

Quizá no una nueva sección en el foro o un apartado en la página de la comunidad, no sé, ustedes son los más indicados para decidir en qué lugar ubicarlo, a mí se me ocurre también que podrían ser temas fijos en la sección de juegos en desarrollo, pero repito ustedes son los más indicados para sugerir un lugar.

CitarAdemás, estoy de acuerdo con penumbra, Game Maker no trata tanto de coger un engine y modificar/añadir cosas (para eso existen otros programas tipo RPG Maker), si no de crear tu propio engine, y por lo tanto, tu propio juego, desde 0.

No creo que todos en la comunidad tengan ese mismo objetivo o no siempre, si tu propósito es crear un juego rápido el Engine es perfecto, o si no tienes los conocimientos técnicos suficientes para crearlo también queda (algoritmos por ejemplo) y que mejor si es un Engine creado por toda una comunidad, no se compararía a un engine creado únicamente por los esfuerzos de una persona o de un grupo pequeño de personas.
Algunos géneros de juegos no son accesibles a un desarrollador o a un grupo pequeño ya que su programación es muy extensa por ejemplo, no he visto tantos juegos del genero de rol, rol masivo o de estrategia en tiempo real, por poner algunos ejemplos.
Usar programas como RPG Maker no es lo mismo, ya que si quieres realizar algo y las limitantes del software te lo impiden no tienes acceso al código fuente para realizar los cambios necesarios, en cambio si se tiene un Engine de RPG para Game Maker los makeros pueden modificarlo como quieran ya que tendrían a su disposición el código fuente. Otro aspecto a tomar en cuenta es el factor de la curva de aprendizaje que implica el uso de un nuevo software, si ya tienes algunos años usando Game Maker te será fácil entender cómo funciona el Engine a diferencia de aprender a usar un programa nuevo desde cero.

CitarAdemás, comprometes la originalidad y la creatividad de tu juego al usar un motor ya creado. Queremos ver juegos originales, no un montón de juegos clónicos.

No creo que se vean comprometidas, por ejemplo en esta comunidad he visto infinidad de juegos muy originales y creativos, sin embargo no escapan del género, todos ellos tienen características similares, muchos de ellos podrían ser generados a partir de un mismo Engine, y seguirían siendo originales ya que en lo único que ayuda el Engine es en generar esas características comunes propias del género. Ivn_eze mensionó buenos ejemplos de la diversidad que se pude lograr al usar Engines y de su uso descarado XD, pero eso ya depende del que lo utiliza.

CitarEl que quiera contribuir con engines, puede hacerlo, no está prohibido en ninguna parte, puede subirlo a la sección de Descargas y, si lo ve necesario, darle un poco de bombo mediante el Shoutbox de la página principal.

No es lo mismo que yo o un grupo pequeño de personas genere y exponga un engine, a que toda la comunidad o interesados en desarrollar juegos de un genero en específico colaboren para crearlo, de esta forma se pueden cometer menos errores de diseño y además se fomenta el trabajo en equipo. 8)

buenas ivn_eze que tal, con cada versión nueva de un Engine en ese mismo post se publicarían versiones para  cada tipo de GM
:GM5: :GM6: :GM7: :GM8: :GMS: :GMHTML5: :GMMAC:

voy a diseñar una plantilla y detallar mas la idea, saludos.

Propongo crear una sección en la cual se publiquen Engines accesibles para todo usuario de esta comunidad y que sean generados y mantenidos también por toda la comunidad. Los Engines de esta sección serian con respecto a géneros de videojuegos, es decir un Engine de Plataformas, Engine  RPG, Engine de Rol, Engine Estrategia en tiempo real, etc.

Los beneficios que yo percibo de la existencia de esta sección serian:

-Engines mejor definidos, mas completos, ampliamente probados, mejor documentados y mejor diseñados ya que toda la comunidad colaboraría en su desarrollo.

-Reducir el tiempo de desarrollo para todos los integrantes de esta comunidad

-Excelentes ejemplos de las mejores practicas y técnicas de análisis de requerimientos, diseño y programación.

-Evitar reinventar la  rueda y enfocar los esfuerzos en una sola dirección y por el bien común

Espero sus comentarios un saludo a todos  :D

Citaresto es lo que tengo

if (resistencia <76)
{
image_index=0
}

if (resistencia <51)
{
image_index=1
}

if (resistencia <30)
{
image_index=2
}

if (resistencia <25)
{
image_index=3
}

if (resistencia <10)
{
image_index=4;
}

if (resistencia <1 )
{instance_destroy(); instance_create(x,y,object1);}

image_speed=0

perdón por interrumpir, supongo que el codigo que tienes esta el el evento step, así que para poner el código de alarma 0 que te dio  Black_Cat tienes que poner una variable bandera para que solo se ejecute una vez, ya  que de lo contrario en cada step pondra la alarma 0 con el valor room_speed * 2;  por tanto nunca se ejecutara. Tambien pienso que la instruccion instance_create(x,y,object1); debe ir antes de instance_destroy();

Evento Step
if (resistencia <1 and bandera=false) {
     alarm[0] = room_speed * 2;
     bandera=true;
}

En el evento Alarm[0]

instance_create(x,y,object1);
instance_destroy();


un saludo

 ;D me puse a jugarlo ^^ a mi hermanita la pondre a jugar cuando llegue :D, y comentare que me dijo ;).  Yo complete todos los minijuegos excepto el del puzzle porque no podía mover las partes  :-[.
Se traba un tanto dora en los troncos y en los escalones.
Pienso que seria conveniente agregar narraciones con voz, para cada instrucción en los minijuegos ya que como es para las mas pequeñas de la casa, varias de ellas no saben leer aun  :-[
Me ha gustado se ve y se escucha muy alegre jejejej XD.

saludos maestro ades  8)

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.

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.

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.

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