Comunidad Game Maker

Cita de: ascoiderº en Febrero 07, 2015, 11:49:20 AM
PD: randomize() es necesario en la primera linea?

Sí, randomize siempre e necesario antes de llamar a la primera función aleatoria (choose, random, irandom, etc)

Cita de: ascoiderº en Febrero 09, 2015, 07:41:20 PM
Si pudiera alguien dejar un ejemplo me iría de perlas, por favor.

No alcanzo a comprender por qué usas ese procedimiento que comentas en el primer mensaje: generar un objeto aleatorio y borrar el objeto master, y después que el objeto aleatorio " da un punto"  (un punto de qué o para qué) se vuelve a crear el objeto master. A mi esta manera de borrar un objeto y luego generarlo de nuevo no me convence. Podría hacer un ejemplo, pero creo que necesitamos saber cuál es la idea de que el objeto aleatorio "dé un punto" y luego cree al objeto máster y se destruya.) y también por qué usas distintos objetos A, B, C, D y E. Así sin tener idea de lo que quieres, me parece que se podrían usar menos objetos en todo el proceso.

Pues al menos ya diste con el problema. EN algún (código que no pegaste en los ejemplos de arriba) se está dibujando la última subimagen. Podrías ponerle comentarios a todos los draw e ir habilitando uno por una para ver cuál actúa de manera incorrecta

la mayoría te va a decir que el mejor editor es el que ellos usan  :D (Y es cierto, el mejor editor es el que uno usa)

Los gráficos tipo pixel art se pueden hacer prácticamente en cualquier editor (bitmap, no vector). Prefiero no sugerirte uno en especial, y dejar que pruebes y decidas. (He visto discusiones encarnizadas en otros foros, de cómo cada usuario defiende su editor favorito y al final no se llega a nada). Las herramientas para hacer pixel art no son nada sofisticadas, creo que la mayoría de los sprites de http://www.spriters-resource.com/ se hicieron en aquellos tiempos en que las computadoras todavía traían su unidad para leer diskettes flexibles

http://www.comunidadgm.org/grafismo-composicion/un-buen-programa-para-crear-sprites-y-fondos/

Cita de: arcangelcaos en Febrero 09, 2015, 11:44:15 AM
Bufff, madremia. Aqui me as chafao to la ilusion. Necesito como unos 80sprites de guerreros varios. Arqueros, a caballo,  etc. Pero yo de dibujar eso lo tengo complicado.  Parece que pinto con los pies.
Modificarlos, luego a luego si que podria. Pero desde cero ya es mas complicado.  Y encima tengo que darles movimientos. Andar y atacar. Haber que hago.

No era mi intención.  XD  ¿Pero quién dijo que hacer juegos era cosa fácil? (al menos no juegos como los que quieres hacer). Pero siempre está la posibilidad de que encuentres a un grafista o dibujante que se una a tu proyecto.

Cita de: arcangelcaos en Febrero 09, 2015, 11:51:53 AM
Yo uso spriter de esta web
http://www.spriters-resource.com/
Hasta que punto es legal, o no se puede usar en juegos comerciales??

Si tienes permiso expreso del autor o compañía para usar esos sprites, o si explícitamente el autor o compañía ha referido que su uso es libre para cualquier finalidad, entonces es legal usarlos. En cualquier otro caso, es ilegal (Ah, y no confundir las cosas, que "todo el mundo" los use o que haya personas que digan "yo los uso y nunca he tenido problemas" no significa que sea legal, tampoco significa que si los usas, te va a buscar el FBI) Aquí ya entran cuestiones éticas que cada quien es libre de considerar o ignorar

Cita de: arcangelcaos en Febrero 09, 2015, 11:15:33 AM
Respecto a lo del copyright,  ahi es donde tengo el mayor problema. Muchos de mis sprites son descaragos de internet. Son sprites de 8 o 16 bits. De consolas o juegos antiguos. No usos los de los personajes principales, pero siblos secundarios. Por poner un ejemplo. Uso los sprite de heroes of might an magic 2 o el 3. Por este motivo podrian cancelar la cuenta???

Pues sí, habría la posibilidad de que fuera suspendido. ¿Qué tan probable? No creo que haya alguien que pueda responder con exactitud a eso. Pienso que el proyecto está más en riesgo  cuando se trata de un clon o réplica, que un juego donde se usan sprites de distintos juegos (y de todas maneras en ambos casos sí podrían darlo de baja). Incluso si el juego es gratuito, la suspensión es posible y probable. Si la intención es desde el principio publicar el juego en una tienda oficial, yo de plano ni siquiera contemplaría la idea de usar sprites de terceros. Desde mi punto de vista, para comenzar en serio un proyecto con miras a ser publicado, creo que debes contar con gráficos propios sí o sí.

Y si no gráficos propios, sí al menos gráficos de uso libre (aunque no voy mucho con la idea)
http://opengameart.org/

Lo que pasa es que el espíritu de la comunidad es mantenerse alejada del "lado oscuro", y no dar soporte, ni enlaces, ni comentar cosas sobre "los del parche". Según lo dicho por  algunos moderadores, esto es debido a que YoYo Games reconoce (no sé de qué manera, me limito a comentar lo que he leído aquí) a ComunidadGM como una comunidad "semioficial" en español de Game Maker.

En mi andar por la web nunca me he topado ni he sabido de baneos como los que mencionas en el punto 1 (Sin embargo, sigo pensando que en YoYo, no tienen ningún impedimento a nivel técnico para saber si un juego está hecho legalmente o no, a pesar que muchos usuarios piensen lo contrario). Los únicos baneos de los que he sabido son baneos relacionados con las compañías de publicidad, por clicks "fraudulentos" o retiro de juegos y suspensión de cuentas por usar material con copyright sin el debido permiso.

Cita de: arcangelcaos en Febrero 09, 2015, 10:20:27 AM
Respecto al 2. Como saben que eres tu?? Por la ip o por que saben que gmail le da el click?? Lo digo, porque si mi mujer le da, desde su movil con su cuenta?? Se dan cuenta por la ip??

Las compañías de publicidad no proporcionan esa información, precisamente porque no les conviene que se sepa cómo trabajan los algoritmos que usan para detectar clicks fraudulentos. Lo que he leído es que usan múltiples técnicas, y que una vez que te banean, no hay manera de restablecer la cuenta ni aclarar nada.

Cita de: matiascarpello en Febrero 09, 2015, 12:18:15 AM
Entonces, ¿hay alguna manera de grabar en donde quedo puesto el zoom?

Cualquier valor/variable se puede guardar en archivos ini o de texto, eso solucionaría el problema.

Cita de: Yoo en Febrero 09, 2015, 12:34:19 AM
funcionaria tambn cuando hay mas de un jugador(osea hay mas de un player q crean el objeto bomba,¿no pasará q el player q tenga el item pueda reventar las bombas de los demas? )?

La función instance_find no tiene manera de reconocer que instancia creo tal o cual bomba. Tendrías que crear un modo de identificar las bombas según su "padre". Es sencillo, mediante una variable puedes guardar en las bombas algún valor o cadena o el índice de objeto del jugador que creó la bomba, y cuando quieras destruír las bombas, preguntas por esa variable para ver a que jugador corresponde.

Cita de: vitail en Febrero 09, 2015, 03:10:19 AM
se movia por todo eso, eso para que sirve, es como un random_range?

Para eso está el manual, que explica TODAS las funciones. random() escoge un número al azar entre 0 y el número entre paréntesis - 1.

http://docs.yoyogames.com/source/dadiospice/002_reference/maths/real%20valued%20functions/random.html
http://www.inventati.org/estupidezartificial/manual.html (en español)

No se necesita usar dos views, pero en el código que pusiste estás usando x e y, esas son variables del objeto o instancia, si quieres mover la view, debes usar las variables x/y de la view

Según el código que pegaste, ese código funciona cuando a TI te mata un zombie, pero si quieres usar el mismo código cuando derrotas a un jefe, pues no va a funcionar (el que muere es el jefe, no tú). Además el código usa un objeto obj_playerdead que supongo no tiene caso usar porque al derrotar al jefe, tú seguirías vivo.

No logro ver dónde está la falla. Quizás en otra parte del código. Yo usaría el debugger para ver si los indices de las texturas son diferentes JUSTO ANTES de dibujarlas en DRAW. Tengo una duda. En el primer código que subiste, escribiste:

scrIniciaCambioTextura();
    draw_sprite(sprEliMano, 1, 64, 64);
    draw_sprite(sprEliPluma, 0, 64, 64);
    textura1 = scrAsignaCambioTextura();


pero en el último mensaje, le estás pasando argumentos a los dos scripts
scrIniciaCambioTextura(128);
    draw_sprite(sprEliMano, 1, 64, 64);
    draw_sprite(sprEliPluma, 0, 64, 64);
    txtManoLR = scrAsignaCambioTextura(128);

¿Qué hace el 128? porque en el código de ambos scripts, al menos los que pusiste al principio, no había nada para hacer referencia a argumentos, y cuando hay esta discrepancia, GM lanza un error. Fuera de eso, el código me parece bien, Compruebas si existe una surface, la limpias, dibujas en ella, cambias el target de nuevo a la pantalla, devuelves el índice de la textura y la guardas en una variable. Eso se ve bien, a mi entender. Lo que no tengo claro es las coordenadas de 64, 64 que usas para dibujar los sprites, pero supongo que tiene que ver con cómo tienes acomodados los orígenes de los sprites.

Es difícil decir cuál es la mejor manera porque cada quién descubre cuál es su mejor manera de aprender (casi siempre por prueba y error). En mi opinión personal, creo que la ruta que has tomado es la que mejor resultado da (consultar siempre el manual y realizar tutoriales). Lo demás viene con el tiempo, no se puede aprender todo el lenguaje en una cuantas semanas, de hecho, no es necesario aprenderse TODO el lenguaje para hacer un buen juego. A mi parecer, es más importante entender cómo funcionan las cosas en GM (eventos, variables, instancias, objetos, scripts, propiedades de los objetos, etc)

Comienza a hacer un juego, sin ir por algo demasiado ambicioso, pero que te resulte interesante/divertido. Pocas cosa son más didácticas que fallar (y tratar de resolver el problema por uno mismo).

Estas son las opciones que deben estar activas para que el editor vuelva a mostrar la ayuda

No uso android, pero he leido en algunos lugares que una alternativa (algunos dicen que mejor) a AdMob es Millenial Media
http://www.millennialmedia.com/

De AdMob, no tengo idea qué suceda, pero últimamente he visto comentarios negativos, sobre que cada vez paga menos, o que a muchos usuarios les ha suspendido la cuenta "casualmente" cuando están a punto de alcanzar la cifra para que les hagan el pago (argumentando que el usuario ha incurrido en prácticas indebidas para aumentar los cliks). Según los comentarios que he visto, parece que de nada sirve quejarse o tratar de aclarar el asunto.

Concuerdo, el formato que usas hace difícil leer el código. La evaluación de corto circuito está integrada en Studio desde las primeras versiones 1.3, incluso en las preferencias es posible desactivarla, pero por defecto viene activa.