Comunidad Game Maker

Yo estoy de acuerdo. Es un juego hecho en 1 semana por diversión, por mucho que nos lo curremos no será el proyecto de una vida. Seguramente se hagan cosas guays que serían interesantes compartir dando el código fuente.

Respecto al D&D es cierto, yo diría que el cómo hagas el juego, si en Drag&Drop o en GML, no debería afectar al resultado final. Todo juego hecho en D&D puede ser hecho en GML pero no en viceversa (creo), usar D&D te limita mucho en algunos aspectos, pero igualmente puede salir un juego que se vea profesional, aunque dentro de todas las limitaciones y la complicación (aprender GML es el siguiente paso, no os quedéis en D&D e intentadlo, GML es hamor puro <3 )

Nunca pensé eso, pues en 1-2 semanas todos harán juegos geniales, solo lo decía porque ellos tendrían que trabajar más al ser individual. A parte, nuestro juego quizás deba ser juzgado más fuerte que los individuales de la misma categoría, así que está compensado :D

Bueeeeno... digamos que, después del Four elements, nunca he acabado ni un juego (me cansé porque hacerlos yo sólo me aburría un poquillo y porque se hacían demasiado grandes para manejarlos yo sólo)... pero he iniciado proyectos en grupos de 2-4 personas muchas veces. Todos ellos fueron abandonados rápidamente porque se cansaron de seguir (gente que no se lo toma en serio), pero tengo la experiencia de estos 5-10 años acumulada... así que dame gente que no se eche atrás y me ayude a spritear y diseñar historia/gameplay/ideas y temblará el mundo xDDD!! (me pasa igual con el juego 3D que estoy haciendo ahora, congelado por gente ausente <3)

Lo que sea, me siento un poco mal por hacerlo en grupo mientras los otros no, ya que eso da más facilidades :c

Cita de: kostra en Enero 22, 2016, 05:35:12 AM
DarkRulerz, hace un grupito? ;)

Oka, entro :D Nosotros dos, o tienes en mente un tercero? Yo podría entrar a la categoría máxima si mi rol principal es la programación. Puedo spritear y podría sacar cosas guays, pero intento no hacerlo si tengo otro que spritee por mí. Y escribir y pensar mucho, pero no yo solo :)

Y sí, no hay que dividir de forma exacta. Quizás la mitad quiere categoría máxima y sólo 2  categoría intermedia, no puedes dividir 12 participantes en 4 por categorías. Es complicado...

PD: Se permite reutilizar código y sistemas antiguos? Tengo un sistema de un juego antiguo que abandonçé que quizás nos molaría usar... o parte de él

Buenash! Pues veréis, yo dibujo muchas primitivas con 4 vértices formando un cubo. Tenemos los 4 muros, rotados 0, 90, 180 y 270º respecto al eje z, pero nada más (100% verticales), luego la primitiva del techo, mirando hacia arriba, y la del suelo, hacia abajo. Son 6 primitivas cuadradas formando un cubo, para simplificar el problema. Todo el tema de la iluminación ya lo tengo montado y funciona, yo pongo varias luces puntuales en el escenario e ilumina las caras. Aquí viene el problema...

Supongamos, para ejemplificar, el cubo centrado en 0,0,0, y las caras a 100 píxeles de distancia (la arista sería de 200)

Quiero, para cada primitiva (para cada cara del cubo), decir si está "lo suficientemente iluminada". Yo tengo acceso a cada cara y sé cuál de ellas es. Por ejemplo, para la cara superior, que estaría en z=100 (hacia arriba), si yo pongo una luz en 0,0,200, la cara está totalmente iluminada. Si la luz está en 100,0,200, la iluminaría parcialmente, pues no viene de frente.

Y así para cada cara. El objetivo es, para cada cara, teniendo en cuenta todas las luces del escenario (cada una es un objeto que puedes ubicar en el espacio), darle a ESA cara un número entre 0 (totalmente oscura) y 255 (totalmente iluminada). Poder decir la cantidad de luz que recibe esa cara teniendo en cuenta todos los focos de luz, ya que después necesitaré filtrar aquellas que estén bastante oscuras (por ejemplo por debajo de 30) para usarlas en el gameplay (digamos que el prota tiene un poder especial si está mirando a una pared o techo "poco iluminado", es decir, por debajo de 30)

He probado a hacerlo manualmente, pero me he hecho un lío. El tema es que quizás hay una forma más sencilla y rápida de encontrarlo. Quizás relacionado con las matrices de transformación o iluminación, las normales de los vértices... algo. Al fin y al cabo Game Maker coge, para cada vértice, su normal, y la ilumina acorde al ángulo que forma con TODOS los focos de luz. Quizás puedo aprovechar lo que hace y coger ese número y ya. Alguna idea?

Hm, aunque el que haya gente haciendo el juego sola y otros en grupo sería injusto, pues el juego del grupo sería mejor en media, y tardarían menos. A ver qué opina la gente sobre si el concurso fuera en grupo, se podría incluso hacer pues no habría que cambiar nada más que hacer que cada uno dijera sus roles para que el mod hiciera grupos justos :D y para fomentar la actividad qué mejor que los usuarios trabajen en equipo ^_^

Habéis pensado hacer el concurso en equipos de 2-3 personas? Yo estuve toda la vida haciendo mis cosillas sólo, pero últimamente tengo casi cero motivación para hacer un juego yo sólo, después de haber trabajado en equipo (aunque actualmente no lo que me gustaría), así que puedo hacer mis cosillas, pero acabar un juego yo sólo pues no... a parte se ganaría experiencia de trabajo en equipo. Lo suyo serían cosas como programador+spriter (ambos escriben), programador+escritor (ambos spritean), escritor+spriter (ambos programan) y todo tipo de combinaciones

Y si queréis animar la comunidad qué mejor que hacer los juegos en grupitos de 2-3. Hacer juegos sólo, al menos para mí, es un tanto pesado últimamente. Motiva mucho tener otra persona con quién hablar y debatir las ideas y mecánicas, en mi caso siendo programador.

Hacer grupos no sería difícil, cada uno podría decir su campo principal y su campo secundario (programador, spriter y escritor, yo creo que con esos 3 campos es suficiente) y luego el moderador hace los grupos basándose en equilibrarlos. Los grupos, siendo sólo 2-3, se coordinan fácilmente por facebook, skype, etc, y creando un documento en Google Drive pueden tener sesiones de lluvias de ideas fácilmente. En ese entonces seguramente sí participaría :)

Gracias!! event_user lo resolvió a la perfección, y sin usar los feos cubitos DND xD Es curioso, al llamar a event user dentro de un for, todo el código de ese evento tiene la variable iterativa del for. Definitivamente como si todo estuviera junto

Sep, pero la condición de b está en un BLOQUE únicamente (un bloque de drag&drop), la de c en otro bloque separados, y quiero hacer la condición de a que agrupe ambos bloques. En total 4 bloques:

el primer bloque es el "if ( a ) {"
el segundo el "if ( b )"
el tercer el "if ( c )"
el cuarto el "}"

El "if" del primer bloque conecta con la llave del cuarto, y agrupa a los dos bloques intermedios. Con un mismo bloque, todo el código junto como tú dices, ya lo tengo, pero quiero ver cómo hacerlo funcionar en 4 bloques separados. Es MUCHO código y lo tengo separado y ordenado en 6 bloques distintos, no quiero juntarlos o sería caótico

PD: Sé que podría copiar cada bloque en un script separado, y desde un mismo bloque hacer el if (a) y llamar a los 6 scripts, como última opción lo tengo, pero realmente quiero mantener los bloques en el objeto sin usar scripts

Adjunto una imagen de cómo podría funcionar, pero no sé si podemos hacer que el "if expression" sea otro pedazo de código, básicamente porque me di cuenta que no debo hacer un if, sino un FOR que dentro agrupe los 6 bloques

Buenash! Pues yo tengo 6 bloques, cada uno con mucho código, pero tienen que ser bloques separados. Hay alguna forma de poner al inicio del primer bloque un:

if ( a ) {

y al final del último:

}

Es decir, que el código de los 6 bloques se cuenten como todo un conjunto encerrado dentro del if, pero MANTENIÉNDOLOS separados en los 6 bloques? Sé que podría juntar el código en un sólo bloque, pero quedaría fatal en cuanto a organizarme

Vale, fue mi culpa. Yo tenía asignada a cada objeto una depth igual a la distancia a la cámara, así lo más lejano se dibuja antes, pero resulta que en la pared no estaba recalculando la depth a cada step, de ahí los fallos... lo he arreglado y ahora sí, se dibuja lo que está al fondo primero y luego las pelotas.

Supongo que, como dices, al desactivar el zwrite, se desactiva para TODO, y NO PUEDES desactivarlo de forma concreta para una sola instancia. Por lo tanto tengo que dejarlo desactivado para todo, y manualmente darle una depth a CADA objeto. Debo dibujar lo más lejano primero y lo más cercano después, así aún sin zwrite, irá bien. Y dentro del mismo objeto no me importa el orden, así que todo funciona bien ahora :D

Lección: ajustar manualmente la depth de todos los objetos acorde a su distancia a la cámara y mantener el zwrite desactivado para TODOS los objetos del juego y siempre. Doy el tema por resuelto, gracias :D

Precisamente quiero que la esfera lejana pequeña se dibuje por encima de la grande cercana (o por detrás, no me importa el orden) . Bueno, realmente no quiero, pero para mi caso se ve perfectamente de ese modo y es lo único que he encontrado para resolverlo (pues como digo, no puedo saber en qué orden dibujar las primitivas para odenarlas, son demasiadas. Incluso he tratado de usar d3d_set_depth para intentar dibujas las más lejanas primero, estando seguro que EN ESE CASO estaban bien ordenadas, y no ha funcionado). El problema es que hay una pared al fondo de todo, y esa pared se dibuja por encima de ambas esferas, cuando el zwrite desactivado debería afectar a SÓLO las dos esferas (las cuales dibuja ambas un mismo objeto) y que NO afecte al muro detrás de todo. Desactivo el zwrite antes de dibujar ambas esferas (desde un mismo objeto) y lo activo después. El problema es hacer que el zwrite desactivado no afecte al muro de hay que detrás ni a ningún otro objeto, es decir, sólo a aquello que dibuja ESTE objeto, pero no lo logro :)

Ejemplo: tenemos el objeto A que dibuja dos pelotas y el objeto B que dibuja otras dos (mismo objeto, dos instancias). Las cuatro alineadas. Yo quiero que ambas esferas, para CADA objeto, se dibujen con el zwrite desactivado (viéndose las más lejanas por encima de las cercanas en algunos casos), pero que las dos del objeto B NO SE PONGAN POR ENCIMA de las dos del objeto A. Es decir, desactivar el zwrite, y dibujar sin zbuffer, para todas las primitivas de UN MISMO objeto, pero NO interfiriendo con otros objetos, es lo que no logro

Buenash! Pues veréis, tengo UN objeto que dibuja MUCHAS primitivas, y me es "imposible" saber en qué orden se dibujarán todas, pues depende de dónde esté la cámara, y al estar todas juntas... el precioso algoritmo del pintor peta y se ve todo fatal. He probado a trabajar con d3d_set_depth pero no funciona, aún así sería un lío calcular en qué orden debería dibujarlas

Sea como sea, quiero ver si se puede solucionar con d3d_set_zwriteenable. Quiero desactivar el zwrite sólo para ESE objeto del enemigo, para poder dibujar todas las primitivas ignorando el z buffer, pero que SÓLO afecte a ESE objeto. Desactivo d3d_set_zwriteenable al inicio, dibujo, y luego lo activo. Funciona, el problema es que también afecta a otros objetos (a otros enemigos e incluso a los suelos y paredes). Hay forma de que sólo funcione para ESE objeto? Es decir, dibujar todas las primitivas ignorando el zbuffer pero sólo ENTRE ELLAS, sí teniendo en cuenta el zbuffer de los demás objetos.

PD: Me doy cuenta que es parecido a una duda que puse hace poco que creí resuelta, aunque en ese caso el problema resultó ser otro, este es concretamente ESTE problema del zbuffer

Mi juego siempre está en pantalla completa (tengo en step un código para ponerla completa si pasara a modo ventana por alguna razón ajena al programa) así que supongo que todo perfecto. Ya entiendo :)

Resuelto. Tuve que usar el zwrite, pero realmente... "no había problema". Al estar en la misma x e y, la distancia es la misma (depth = distancia) y la parte superior del cubo inferior se superponía al cubo superior por alguna razón. Lo arreglé (no dibujar el cubo inferior pues el superior lo tapa, debería taparlo pero tuve que taparlo manualmente) y ya. Cosas raras pero que por ahora solucioné. Muy raro todo xD