Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.
Cita de: banano29 en Enero 10, 2013, 05:54:09 PMja ja bueno....que mas tengo para decirte................ bienvenido!!!!!!!!!!Citarademas busco grupo de desarrollo estan todos invitadosMe interesaria entrar soy buen spriter y guionista
para intentar unirnos
Cita de: The_Aesir en Enero 09, 2013, 07:54:15 PMmmmm..... la verdad...te soy sinsero...
Gracias por sus comentarios a los 2!! :D
Me gustaría saber en que parte les da problemas de colisiones, para poder entender bien cual es el problema.
pikamaker, quizas es más entretenido aprender uno mismo a base "ensayo y error" como funcionan algunos enemigos, a que te desvelen como superarlos en un "mini tutorial", que por lo general nadie lee XD, no se, es mi vision de las cosas :)
Cita de: licshendu en Enero 09, 2013, 07:27:46 PMyo no dije eso,,yo dije que podria ser muuuuuuuuuuuuuuuchoo mas simple con dos objetos (entiendes?)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.
Cita de: pikamaker en Enero 09, 2013, 07:02:28 PMeh................... me dejaste con la boca abierta....;D busque en........... en....... en........... ehhhhhhhhhhhhhhh..........Cita de: Creador de juegos GM en Enero 09, 2013, 05:06:08 PMo.o en donde buscaste?
una pregunta
¿como.... ¿que hay version gratuita de gm studio? XDlo anduve buscando pero no lo encontré :'(
yo uso :GM8:(gm8) y tambien :GM6:(gm6) bueno esa es mi pregunta
aquí esta
Cita de: licshendu en Enero 07, 2013, 07:52:17 AM:-[fiu.... :-[ que debate..... me leí todos los comentarios...
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 compatiblesY los pasos que propongo son estos: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:
- 1.Boceto(s) general(es) del juego
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.
- 2.Definir los objetos involucrados
Proyectil
Nave_enemiga
Pj (esta la voy a corregir ^^, porque si se usan abreviaciones puede haver confucion)
Control
CasitaEn este paso se tendría que pensar en que acciones cumplirá cada objeto y corresponden al diagrama de definición de objeto.
- 3.Definir las acciones de las cuales cada objeto sera responsable, mediante una lista de oraciones
En este diagrama se busca definir que objetos interactuan con cuales otros.
- 4.Definir las relaciones que existen entre los objetos
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.En este paso se tienen que definir lo que un programador necesitara saber de otros objetos, para poder programar un determinado objeto.
- 5.definir los requerimientos de objetos
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 variablesEn este paso seria definir a detalle las características de los recursos, ejemplos de esto serian:
- 7.definir características de los recursos(sprites,sonidos,background,scripts, etc.)
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 vidasCódigo [Seleccionar]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
Cita de: banano29 en Enero 09, 2013, 04:31:20 PMtienes razon,y...... bienvenido a cgm (al autor del post) (si no estabas desde antes) y.... una pregunta
Bienveindo y conforme a lo que tu dices, siempre es bueno comenzar el D&D , pero nunca tienes que dejar de lado estudiar un poco de GML ya que sin el tus juegos se mantendran con un nivel bajo... :P
Cita de: banano29 en Enero 09, 2013, 01:45:53 AMok espera que cuando termine edito ste mensaje y lo subo.Citarotra forma mas facil seria hacer la variable volver en una flecha,entonces cuando estas en el menu pon volver=0oye me podrias hacer un example te lo agradeceria
y entonces cuando aprietas pones:if volver=0 sevadondequieras if volver=1 sevuelvealmenu if volver=1 instance_destreoy(objetocontoladormenu) el menu pon un objeto controladormenu :
volver=0 y en el otro lugar pon volver=1
es muy complicado pero bueno
Cita de: Colmi en Enero 09, 2013, 12:31:54 AMotra forma mas facil seria hacer la variable volver en una flecha,entonces cuando estas en el menu pon volver=0
Hola Banano,
Esto es bastante sencillo, pero ten en cuenta que por defecto el boton Esc cierra el juego, así que recomiendo que si quieres usar este botón hagas primero un objeto vacío y le llames por ejemplo control, ahora te explico una forma sencilla para que hagas pruebas:
1º en las opciones de gamemaker tienes que desactivar una casilla que pone en ingles, cerrar el juego al pulsar Esc.
2º crea el objeto control y le añades:
2.1 evento Pulsar tecla o soltar tecla(Evento Key release), pones la tecla que quieras para cerrar el juego para poder salir mientras lo testeas.
3º crea el objeto menú y le añades:
3.1 evento soltar tecla Esc: Crear el objeto que sería tu menú si no existe y destruirlo si existe.
Esto se puede comprobar facilmente con o sin programación, sin programacion sería:
Evento soltar Esc(Key release Esc)
Apartado control: If a instance value: encojes igual a 0
Crear menú
Else
Destruir menú
No se si me entenderas bien porque no se tu nivel.
Mi consejo haz los tutoriales, empieza con el de las bombas y no solo lo hagas, fíjate en cada acción y pregúntate lo que hace, yo empecé asi y ahora hago todo lo que se me ocurra, solo tenia una duda para guardar archivos en el disco pero ya la solucioné, era un fallo del Sistema operativo y permisos.
Si no entiendes y quieres un tutorial te puedo hacer uno con pantallazos y explicación paso a paso y el porqué de cada acción, pero yo tengo el GM 8.
Aunque en realidad realidad los GM van todos igual para mi forma de verlo XD
Si no entendiste solo pídelo y te lo hago en mis ratos libres
Nota personal:
Para juegos 2D creo que el GM es uno de los mejores motores que existen, asi que si te gusta hacer juegos no te desesperes, todo se puede lograr.
otra forma mas facil seria hacer la variable volver en una flecha,entonces cuando estas en el menu pon
Ahora si quieres usar 3D el GM no es muy potente en ese aspecto ni tiene soporte actualmente.
Un saludo
