#420 Sep, no he dicho que sea mejor, si no que sí que hay maneras xD
Ojalá tuviera yo una oficina donde separar ocio de negocio... pero de momento, a comer pizza y a currar en el salón.
Buenas gente! en el estudio estamos desarrollando un juego interno del que hemos comenzado a trabajar en el grafismo... esta sería uno de los primeros avances, un Enanillo
A ver si lo terminamos y subimos la imagen final 
#423 Está entre enfadado e ido de kilos, lo que le hace tener ese mofletes que cualquier abuela adoraría pellizcar :qq:
La verdad es que apenas he usado este post, pero voy a ver si cojo costumbre de ir usandolo e ir actualizando. De momento, voy a postear por aqui, mi mayor quebradero de cabeza:
Proyecto “fantasma” y mi frustración
Hace tiempo me puse a programar un jueguito que iba a ser de puzzles. Con la intención de que el juego se basara en asustar a los niños que paseaban por la casa. Que se habia colado por cualquier motivo. El metodo para asustar seria con el fantasma y con un aliado, que seria un esqueleto.
En ese entonces, la forma de asustar era muy basica, pasabas con el fantasma, te hacias visible y lo asustabas y debias poner al esqueleto para recogerlo. Ademas, de los multiples bugs(la camara, mostraba las partes sin mapas, el esqueleto iba muy mal).
Con el paso del tiempo, decidí que tal vez fuera viable y entretenido. Así que empezamos a trabajar en el.
Cambiamos los modelos del fantasma y el esqueleto. Añadimos paredes, distintas habitaciones, pathfinding para el esqueleto. Mejor sistema de asustar, ahora lo niños no desaparecian, siemplemente se iban corriendo, quite que la camara mostraras zonas sin mapeado, creamos varios objetos que se interponian en el camino del prota.
Nuevos modelos, esqueleto y fantasma:
Niños y algunos muebles
Trampas antifantasma, te arrastra y evita el movimiento
Nivel del juego
Tambien añadimos, niños “boss” en la que debias hacer una determinada mecanica, para poder pillarlos.
Total, que por mucho probar y testear, me he dado cuenta, que es aburrido, simple. Ademas, de que estamos programando juegos, para mostrarlo en un evento en Tenerife, ya no siento mucha felicidad por continuar este proyecto, al menos de momento. Siento que por mucho que lo toque no va a ser nunca lo suficientemente divertido y es un poco frustrante. De momento he decidido dejarlo aparcado y continuar con el remake del juego que hicimos en la pasada ludum dare. Más adelante, probablemente vuelva a reintentar hacerlo en gamemaker, tal vez alli, le encuentre mas futuro que con impactjs(menudo dolores de cabeza me ha dado este motor).
Me he leído y releído dos veces tus posts y, a pesar del apoyo de las imagenes, todavía no pillo del todo la mecánica del juego xD. Es posible que haya sido una buena idea abandonarlo, sí. Aunque si tienes una demo pequeña y quieres opiniones, puedes probar subiéndola.
#427 La base del juego es echar a los niños de la mansion. Algunos son muy simples, otros tenian que hacer ciertas cosas para echarlos. Es un juego simple, pero la verdad es que creo que divertido no es.
Ami tmb me ha parecido confuso al principio, pero para algo esta el preguntar xD, me gustan estos posts en los que planteais como era el antes y despues (cambio de planteamiento, personajes, etc.) de vuestros proyectos. A ver si consigo terminar mi maldito "kula world" en 2D y os pongo una demo de un proyecto que tngo entre manos.
En realidad me quedan pocas cosas que implementar, pero me da ami que son jodidas, aun asi os lo pondré por aquí para que lo jugeis, con o sin recortes xD
#426 "Total, que por mucho probar y testear, me he dado cuenta, que es aburrido, simple."
Creo que lo que te ocurre es que piensas en una idea genérica pero luego no lo consigues trasladar a mecánicas divertidas.
"Eres un fantasma y asustas niños" es una idea demasiado general y que no dice nada. Si lo trasladas así directamente a un juego, el juego tampoco va a decir nada.
Por poner un ejemplo: "eres un fontanero y buscas una princesa" no dice nada. Añádele elementos de gameplay (powerups, enemigos, rutas alternativas...) y el juego empieza a tener mayor profundidad.
Una mecánica debe ser:
- Ni muy fácil (aburrida) ni muy difícil (frustrante).
- Ni muy repetitiva (aburrida) ni muy diversa (confusión, falta de cohesión, dificultad de implementación).
- Altibajos emocionales: si es demasiado lento (por ejemplo, si tu fantasma anda a velocidad tortuga) el jugador tarda demasiado en recibir su recompensa y no llega a engancharse. Por otro lado si estás continuamente recibiendo recompensas (el caso contrario) estas pierden su valor y dejan de enganchar.
- Dar opción a la creatividad: si todos los jugadores (o un mismo jugador en varias ocasiones) solo se puede enfrentar de la misma forma al problema, este deja de ser un reto y pasa a ser un trabajo... y el trabajo no es divertido.
- Cuantas más mecánicas logres introducir (sin "emplastarlas" ) más oportunidades ofreces al jugador de cambiar de mecánica cuando lo desee, haciendo que el juego deje de ser lineal.
- Progresiva: la mecánica debe empezar siendo fácil e ir incrementando la dificultad añadiendo nuevos elementos.
- Sumar varias habilidades: si todo lo que tienes que hacer para pasarte el juego es usar una única habilidad (p.ej. ser capaz de encontrar a los niños), la mecánica pasa a estar vacía. Una mecánica profunda incluye varios elementos de habiliad (búsqueda, persecución, timing...)
- Y la más difícil de todas: original. ¡Nadie quiere jugar a OTRO plataformero estándar! Pero añádele un concepto nuevo (véase Fez) y tendrás al jugador enganchado.
Por lo que he jugado tuyo en lo que realmente pecas es en permitir al jugador usar su creatividad. Encierras al jugador en tu concepción de la mecánica, en lugar de permitir que el jugador se involucre en ella. Hablo sin saber y sólo por lo que intuyo del texto/imágenes, pero... ¿cuál es el elemento creativo de tu juego? ¿Se trata sólo de llevar a cabo la tarea? ¿Cómo puedes dar libertad al jugador para desarrollar el objetivo?
Por dar un ejemplo de una forma de hacer la mecánica más profunda: como fantasma dispones de trampas y cada una ejerce un efecto distinto en el niño: le paraliza, le obliga a correr en una dirección concreta, le atrae hacia la trampa... El objetivo entonces pasa a ser cómo disponer las trampas de forma efectiva para llevar a cada niño a la salida, fomentando la creatividad y haciendo cada solución única. Ahí ya puedes jugar con las limitaciones de la mecánica (número de trampas disponibles, duración de estas, interacciones entre trampas, un niño demasiado asustado se desmaya y se niega a moverse, etc.)
Algunos artículos interesantes:
#432 Hay varias formas de asustar a los niños, encadenar eventos y cosillas. Tambien supongo que ya no es solo el juego, si no tambien el impactjs, que me ha dado mas dolores de cabeza que nada en este mundo. Y digamos que le he perdido ilusion por continuarlo, incluso el equipo entero, no le gustaba el juego, asi que, de momento lo he dejado aparcado, tengo claro, que lo voy a arreglar, pero me lo planteare mejor, para cuando tenga avanzado otras cosas, porque el tema del FI3 nos tiene algo preocupados, asi que seguimos avanzando por ahi.
Cuando tenga un poco mas avanzado catwalk, hago por aqui la diferencia entre la version LD27 y El remake. Me esta encantando como esta quedando :$
#435 pues me llevé otra impresión por el texto/screens xD
Por curiosidad, ¿qué es exactamente lo que te ha dado dolores de cabeza de Impact?
Espero impaciente ese Catwalk
#436 colocar animaciones, colisiones y muchas cosas mas, que ahora no recuerdo, porque solo siento amor por gm y olvidé todo lo malo anterior xDD.
Lo que te puedo decir, es que personalmente, estoy contento por como esta tirando catwalk, va fluido, he podido implementar todo lo que en su dia no pude. El boss nuevo esta quedando mejor que el anterior y a ver si conseguimos dejarlo, en la forma que queriamos. Que de momento, todo apunta a que si. Sobre todo a la hora de añadir efectos
Los movimientos del boss son definitivos? yo lo haría que rodase aun incluso cuando va a subir a la plataforma y hasta que aterrice, y ahí lo pones de pie (bueno solo es mi opinion xD).
#438 no, son muy "alfa", hara un movimiento distinto. De momento yo lo voy programando y cuando los diseñadores, lo terminen lo implemento 
Ya me parecía a mi xD, ma dejao flipado eso de que cuando aterrice tiemble toda la pantalla, muy bueno! podrías hacer que la prota se quedara paralizada sino salta al mismo tiempo, vaya lo digo por si aun no lo teníais pensado ^^
#441 Premio para el caballero!
#440 Si, incluso me habia planteado, aparte de no moverte, una animacion de haciendo que la prota se tambaleara.
PD: Tu avatar es The question?
#437 Llámame loco, pero me gustaba más y me parecía más útil cargar las animaciones por código en ImpactJS que con el editor de sprites de Game Maker xD
Al tener que cargar secuencias de imágenes me obliga a repetir fotograsmas de forma inútil, y en ImpactJS pillaba los frames y le decía: [0,1,2,3,5,6,0,1,2,3,4,0,1,2,3,2,1] - por ejemplo - y con 6 frames hacía toda la animación.
En Game Maker en teoría se puede, pero con ese editor de sprites con el que no puedes seleccionar varios fotogramas a la vez como coj***s se supone que voy a repetir una animación compleja? ¿Existe alguna manera de definir la estructura de la animación por código?
Y sí, en cuanto al manejo de colisiones es inifinitamente mejor, con el rollo de poder definir formas, o ajustar la máscara al recorte del png, más todas las funciones que tiene para detección y gestión de colisiones está muy bien. Aunque yo sigo usando cuadrados como en ImpactJS para GWBW, tampoco es que necesite más xD
#442 Esto debería ir en el hilo de Game Maker, pero intento contestarte ;-)
Lo primero es saber los dos comandos clave para animaciones: image_speed y image_index.
Si por ejemplo el sprite que tenemos usa 7 imágenes, es el rango de image_index de 0 a 6.
Una vez tengamos la velocidad correcta con image_speed, es tan fácil como hacer un poco código de ifs (u otros comandos de condiciones), por ejemplo para hacer la cadena de anims de GreyShock se podría hacer entre otras formas con un for:
image_speed = 0
var i
for (i = 0; i < 16; i +=1)
{
if i >= 0 and i <= 4 {image_index = i }
if i > 4 and i <= 6 { image_index = i + 1}
if i > 6 and i <= 10 { image_index = i - 7}
if i > 10 and i <= 14 { image_index = i - 11}
if i = 15 { image_index = 1}
if i = 16 { image_index = 0}
Está hecho a ojo, pero salvo algún pequeño error se puede hacer así, o frame a frame con un switch. No es tan visual, pero sí que se puede tener total control de las animaciones dentro de un sprite.
#442 a ver hay cosas que me gustaba mucho en impactjs, que gamemaker no tiene, una de esas cosas es esa que dices. Me gustaba mas, cuando los eventos los llamabas tu dentro de la misma entidad, no tenias que ir graficamente 1 por 1, es un coñazo. Aunque hace poco #443 me comento que encontro una forma de hacerlo al estilo impactjs, que aun no he probado, que ya probare con el siguiente juego.
En gwbw realmente la colision exacta es pollada(en mi opinion), porque es point a click, pero a mi cuando ponia los cuadrados en la mayoria de juegos, pasaban cosas horribles, las balas colisionaban muy lejos del prota y tenia que pegarme ratazos tirando de offset.x y offset.y. Aqui en Gamemaker eso no pasa, pones colision exacta y todo va como la seda. Visualmente, mueres porque de VERDAD colisiona.
Aun asi, Weltmeister > Gm level editor. Menuda puta mierda mas coñazo e infumable. No hay por donde cogerlo. Pero en resumen Gamemaker >>>>>> Impactjs.
#445 Pues habría que probarlo, pero si no, con un switch, seguro que iría paso a paso y podrías controlarlo uno a uno, la estructurá más larga pero más sencilla,la guardas en un script y listo:
case 1: image_index = 0 break, case 2: image_index = 1, con un i += 1 al final de switch completo para que vaya aumentando la variable.
#444 Sobre el tema colisiones, hay varias formas de hacerlo. La mejor sin duda, después de muchas pruebas, es:
Cuadrado / Rectángulo para colisiones con terreno y plataformas, así evitas enganches y stucks.
Colision Precisa para impactos de enemigos, etc.
Es tan fácil como poner un cuadrado como personaje invisible a la vez que el sprite del personaje, siguiendo las coordenadas del cuadrado. Hay que tener cuidado con la Depth, eso sí, para que todo se dibuje a la vez y no vaya con retraso, ya que la Depth (profundidad) determina en qué orden se dibujan también las distintas capas de cada room.
#448 un step es un "paso" del gameloop. Game maker hace tantos steps como fps, así que a 60 fps, 60 steps por segundo.
Para no hacer más offtopic, sigo la conversación de Game Maker en su hilo: http://www.mediavida.com/foro/dev/game-maker-studio-dudas-colaboraciones-477428/4#94
Unas cuantas imágenes del hack & slash y los modelos que hemos estado preparando (bendita asset store de unity), finalmente no nos hemos decantado por los cubos (temática que tocaremos posiblemente en futuros proyectos), con modelos y herramientas listas en mano ahora queda maquetación y elaboración, os iré poniendo más noticias pronto ya que esperamos en estas dos semanas le podamos dar un sprint brutal.
Ya tenemos habilitadas cosas como inventario, misiones, menu de habilidades, menu de personaje con info sobre el personaje sobre sus estadisticas y los objetos que lleva equipados.
