Mostrar Mensajes

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.

Mensajes - vzk91

1
Cita de: kostra en Noviembre 01, 2015, 12:50:28 PM
en ese tipo de vista, tengo un truquito y es, en objetos estáticos en create, y en objetos que se mueven, como el player, en step:
depth = -y;

nada más, pero tienes que ver el origin de los objetos centrarlos por la zona mitad en la que representa que es la parte de alante y la parte de atrás, no sé explicarme xD

Buenisimo el truco, parece que ahora esta funcionando todo correctamente. Gracias !!
2
Cita de: penumbra en Octubre 31, 2015, 11:08:55 PM
Cita de: vzk91@gmail.com en Octubre 31, 2015, 03:39:56 PM
Cual seria la forma correcta de hacerlo para no malgastar recursos ??? Porque ahora mismo mi escenario solo tiene una casa y un arbol para hacer las pruebas, pero obviamente va a tener muchos mas elementos con los que podra chocar el player....
Si el usuario va a tener control sobre el jugador en todo momento, entonces usar física en el jugador no me parece ventajoso y hasta te puede dar problemas a futuro en comparación con la forma "normal". Se puede usar física, no es que esté prohibido, pero no le veo mucho sentido, sin contar que la simulación de un entorno con física requiere más cálculos que un movimiento normal de objetos sin física. Y si tu juego va a ser grande, pues habrán más cálculos. No sé de algún proyecto RPG 2D que use física en el personaje principal, ya que el control se puede hacer de la manera tradicional. Me parece (opinión personal) que difícilmente se justifica usar física en el personaje principal, a menos que se quiera implementar un movimiento "raro" o "poco común" (en términos de lo que se ve comúnmente en un RPG clásico)

Generalmente se usa física en objetos inanimados que no son controlados por el jugador, como rocas que caen y rebotan, partículas/proyectiles que chocan contra otros objetos, objetos mecánicos como engranes, balancines, etc. Sé que GMS incluye un tutorial de fisica donde se controla una nave mediante funciones de física, pero es más que nada un proyecto para introducir las funciones y dar una idea de cómo usarlas, y porque la nave y los otros objetos tienen la peculiaridad de que en todo momento se ven afectados por la inercia, efecto que se consigue "naturalmente" al usar física pero que difícilmente se ve en personajes de RPGs (y que también puede conseguirse sin física, claro)

Las colisiones simples en personajes animados, como chocar contra paredes y árboles cuando se camina/corre, se pueden implementar de la manera tradicional, sin recurrir a física.

Gracias por la explicación.

Estoy probando ahora haciendo los objetos solidos y a la hora de mover el player compruebo con place_free si existe algo delante. Mucho mas sencillo la verdad. Entiendo que esta es la forma "normal" que me sugerias.

Solo tengo un problema con este metodo, y es que no consigo ni de coña que el player quede por detras del objeto cuando no colisiona con la mascara. Es sobre todo para hacer el efecto de que el player pasa por detras de una casa. Adjunto 2 imagenes, una con la mascara que he aplicado a mi choza y otra con el bug.

En la segunda foto veis como el personaje esta sobre el tejado y deberia estar por detras de la casa.



Y este es el codigo que tengo para mover a mi personaje ( el unico codigo que tengo despues de la limpia de las fisicas ):

if keyboard_check(vk_left) && place_free(x-2,y) {
    sprite_index = Spr_Hero_Left;
    x -= 2;
    image_speed = 0.1;
}
if keyboard_check(vk_right) && place_free(x+2,y) {
    sprite_index = Spr_Hero_Right;
    x += 2;
    image_speed = 0.1;
}
if keyboard_check(vk_up) && place_free(x,y-2) {
    sprite_index = Spr_Hero_Up;
     y -= 2;
     image_speed = 0.1;
}
if keyboard_check(vk_down) && place_free(x,y+2) {
    sprite_index = Spr_Hero_Down;
     y += 2;
     image_speed = 0.1;
}
if(keyboard_check(vk_nokey)){
    image_speed = 0;
    speed = 0;
}


Un saludo
3
Cita de: Clamud en Octubre 31, 2015, 03:20:38 PM
En las propiedades físicas de la casa marca la casilla kinematic, así ningún objeto podrá afectarle.

Para que el personaje no rote, primero establece una fricción angular alta, en el evento Create:
[gml]phy_angular_damping = 100;[/gml]
después, en el último evento previo a Draw, anula la velocidad angular y la inclinación:
[gml]
phy_angular_velocity = 0;
phy_rotation = 0;
[/gml]

Así debería funcionar, sin embargo este método está gastando recursos en exceso al estar simulando cosas innecesarias, sólo es recomendable si el escenario va a tener pocos objetos colisionables.


Cual seria la forma correcta de hacerlo para no malgastar recursos ??? Porque ahora mismo mi escenario solo tiene una casa y un arbol para hacer las pruebas, pero obviamente va a tener muchos mas elementos con los que podra chocar el player....
4
Cita de: kostra en Octubre 31, 2015, 12:11:35 PM
LoL que risa ese bug jajaja, en fin, veo absurdo usar ese tipo de "colisiones avanzadas" puediendo usar un movimiento normal sin físicas ni nada, para ese tipo de juegos va perfectamente :/

pero si insistes, porqué no pones el código que le pusiste en vez de la info del objeto? xD

Realmente lo hago asi porque es la unica forma que se jeje. Desde la info de los objetos ves todo los codigos que le puse.

Si conoces alguna guia/tutorial sobre el sistema que dices, te lo agradeceria... porque si es mas simple y va perfectamente me va a ayudar muchisimo.

5
Buenas,

Estoy siguiendo este tutorial para empezar a prototipar mi mapa con las fisicas básicas y demas. El problema que tengo es que algo estoy haciendo mal porque a la hora en la que mi player choca contra otro objeto (una casa o un arbol) en vez de chocar, desplaza al objeto. Ademas mi personaje se tuerce y ya no queda recto.

Este es mi objeto player (el Heroe):

Information about object: Obj_Hero
Sprite: Spr_Hero_Down
Solid: false
Visible: true
Depth: 0
Persistent: false
Parent:
Mask:

Create Event:

execute code:

image_speed = 0.1;

Step Event:

execute code:

/// Depth Correction
depth = phy_position_y * -1;

execute code:

/// Handle Input Logic

if(keyboard_check(vk_left)){
    sprite_index = Spr_Hero_Left;
    phy_position_x -= 1;
}
if(keyboard_check(vk_right)){
    sprite_index = Spr_Hero_Right;
    phy_position_x += 1;
}
if(keyboard_check(vk_up)){
    sprite_index = Spr_Hero_Up;
    phy_position_y -= 1;
}
if(keyboard_check(vk_down)){
    sprite_index = Spr_Hero_Down;
    phy_position_y +=1;
}

Collision Event with object Obj_Tree_1:

execute code:

///Collide With

Collision Event with object Obj_Choza_1:

execute code:

///Collide With



Este es mi arbol:

Information about object: Obj_Tree_1
Sprite: Spr_Tree_1
Solid: false
Visible: true
Depth: 0
Persistent: false
Parent:
Mask:

Create Event:

execute code:

depth = y * -1;



En la Room en la que estoy trabajando tengo habilitado el check Room is Physics World, con Gravity x e y a 0.

Que puede estar pasando ??

Adjunto una captura de la ejecucion para veais el problema.
6
Cita de: kostra en Octubre 30, 2015, 02:36:39 PM
puedes descargarte el GMS original gratis, registrar tu correo y te dan una licencia freeuser, que ya va muy bien y en todo momento, si te da por comprarlo, simplemente puedes actualizar tal licencia ;)

No esta algo limitado con respecto a la version pro o master ?? O sus unicas limitaciones son los modulos de exportacion ??  Porque si fuera el caso me vendria genial para ir avanzando con el GMS y ahorrarme luego el port desde el 8
7
Propuestas y soporte / Re:Cambiar mi usuario
Octubre 30, 2015, 12:08:14 PM
Espero que algún admin lo vea y pueda ayudarme jaja
8
Cita de: penumbra en Octubre 30, 2015, 10:26:42 AM
Puedes aumentar el tamaño de la habitación, y usar vistas, para mostrar sólo una sección del mapa. La vista seguiría al objeto jugador. Como es de esperarse, con mapas muy grandes, el tamaño del juego crecerá mucho y también el tamaño de RAM requerida para cargar los fondos.

Una alternativa en ese caso sería crear un mapa a base de celdas, y dibujar sólo las celdas de la región donde "virtulamente" esté el personaje, aunque esto complicaría un poco las cosas en comparación con el método simple de usar vistas. Si los mapas no son TAN grandes, entonces usar vistas sería una buena alternativa (no deberían ser tan grandes, ya que mencionas que es un juego para móviles).

Personalmente siempre he sido de la idea de que no es muy recomendable comenzar con un RPG si eres un recién iniciado, pero, bueno, suerte con tu proyecto.

Por cierto, no sé si sólo se trata de un error, pero el ícono del post es de GM8 y también en el primer mensaje mencionas GM8 y Android. Con GM8 no es posible exportar ni a Android ni a iOS. En ese caso es necesario usar GM Studio.

Gracias por la respuesta. Actualmente estoy prototipando en GM8 para ir probando texturas y ver el tamaño del mapa, mi idea es luego trasladar ese prototipo al GMS y ya empezar a desarrollar el juego. Estoy haciéndolo así porque no tengo aun una licencia de GMS (no me entere de la promoción del humble bundle y ahora mismo no puedo permitirme la licencia, a ver si para el mes que viene...), asique espero luego no tener problemas para pasarlo.

Realmente soy un iniciado con GM, pero ya he hecho algunos proyectos para Android pero en Java nativo, solo que un juego de este estilo se me escapa de mis posibilidades en Java.

El tamaño que tengo en mente sería como el Pokemon plata para que te hagas una idea. Estoy aun terminando el boceto inicial del mapa con digamos las ciudades/pueblos principales de la historia, pero vendría a tener ese tamaño.

Un saludo
9
Cita de: kostra en Octubre 29, 2015, 01:12:10 PM
básicamente, cada uno lo hace a su gusto jajaja, normalmente, se hace en una sola room, lo que es un mapa general, y en otra room, cuando cambia el lugar donde estás, por así decirlo... o por ejemplo, a veces están separadas en distintas rooms una sola ciudad, separados por "norte" "sur" "este" "oeste" y "centro", y eso ayuda al jugador a interactuar más en misiones, por ejemplo una mujer necesita que hables con su hija que está jugando en la "plaza central"... pero en fin, lo dicho, tú hazlo como tú quieras y sientas más cómodo y atractivo de jugar

Entiendo... cuando tenga acabado el boceto final del mapa veré si me sale rentable fragmentarlo en secciones o hacerlo todo en una room.

Otra duda que me surge es el tamaño de las rooms, por defecto se cargan a 1024 x 780, pero entiendo que este tamaño no es real para un juego tipo RPG y deberían ser tamaños mucho mas grandes para poder abarcar todo el mapa. ¿Estoy en lo correcto?

Igual son preguntas obvias, pero son dudas sanas de recién iniciado jaja.
10
Propuestas y soporte / Cambiar mi usuario
Octubre 29, 2015, 12:13:00 PM
Hola,

No se en que parte del regisrto la he cagado tanto, pero mi usuario deberia ser vzk91 y por algun motivo a terminado siendo vzk91@gmail.com....

Podria cambiarlo para ponerlo bien de alguna manera ?

Un saludo
11
Buenas,

Voy a comenzar a montar un juego RPG 2D (estilo zenda, pokemon, etc ) con el GM8 paraAnroid/-iOS, y quería comenzar el prototipado del mapa. Pero me surge una duda que seguro que los expertos me sabrán aconsejar rápido.

A la hora de ir montando el mapa, colocando hierba, arboles, ríos, casas...etc. ¿Montáis todo el mapa sobre la misma room? o Vais partiendo el mapa por secciones y cuando el player llega al limite de la room hacéis el cambio ?

Entiendo que las cuevas, casas y demás espacios internos si se montan en rooms independientes que al entrar en estos sitios son cargadas.... pero no se como hacer el mapa general.... si todo en una room o separandolo por secciones.

Un saludo