Comunidad Game Maker

A mi me parece que no se puede establecer una tasación infalible. En internet hay muchas discusiones sobre cuál es el precio justo para el pixel art, y creo que ninguna llega a un acuerdo.

Al final, el precio depende de muchos factores: calidad del trabajo, tamaño del sprite, número de animaciones, y desde luego, la más determinante: el precio que decida ponerle el artista (y el precio que estés dispusto a pagar). Incluso, con dos artistas que te hagan el mismo sprite final, el precio puede variar mucho de uno a otro.

En lo que la mayoría de gente y artistas concuerdan es que el pixel art (bien hecho) no es barato. Animar pixel art, es muy laborioso (no me refiero a ni a animación por huesos 2D ni a animaciones sencillas con poco movimiento, sino a animaciones completas, por ejemplo de ataques, ciclos de caminata, etc). Si son todos sprites de 32X32, quizás el precio no sea mucho.

Aquí hay una especie de referencia para dar una idea
http://2dwillneverdie.com/blog/how-much-do-sprites-cost/

Cita de: millansoft en Diciembre 02, 2015, 04:06:38 AM
Hay forma de que le deje el valor y no el string?

Como lo pretendes realizar, no. Analizando tu código:
[gml]rival = "rival" + string(i);[/gml]
Lo que hace es que la cadena "rival" se concatena con la cadena string(i). Por ejemplo, en la primera iteración del ciclo, del lado derecho de la igualdad se tiene "rival0".

La cadena "rival0" es precisamente, una cadena, no una variable. No hay relación (para GM) entre "rival0" y la variable rival0. Es cierto que lucen similares, ambas aparentemente están compuestas por los mismos caracteres, pero para GM son cosas distintas. Para GM, "rival0" es una serie de caracteres ascii (o utf-8), mientras que rival0 es un identificador que apunta a una dirección de memoria.

Fíjate que incluso en el editor de GM, el color de una cadena "valor0" es distinto al color de una variable valor0, para ayudar a diferenciar su "naturaleza".

Lo más sencillo es que uses arreglos, como te sugirió NiuWeb. Si eres de los que no se conforman con el método más sencillo, entonces, sí hay una manera para que, variando el sufijo numérico de una cadena puedas acceder a un valor guardado: Mapas.

Los mapas almacenan información basándose en un esquema clave-valor. Las claves en un mapa pueden ser cadenas, por lo que un mapa puede tener una estructura
"rival0": 84
"rival1": 34
"rival2": 50

Entonces, aquí sí que es posible usar el truco
[gml]"rival" + string(i)[/gml]
para recorrer el mapa, modificando el valor de i. Las claves de los mapas también pueden ser números, y como en GMS ahora hay "accessors", casi no hay diferencia entre manejar mapas y manejar arreglos (desde el punto de vista de facilidad de uso, no digo que sean la misma cosa)

Sí, por eso mencioné que el ejemplo necesitaba pulirse.

Estuve probando y nunca vi que la pelota quedara pegada al borde de la pala. El único momento en que la pelota queda quieta (en mis intentos) es cuando queda atrapada entre la pared y un borde de la tabla, pero esto a mi me parece normal, ya que la pelota no tiene espacio a dónde moverse.

Realicé cambios al ejemplo: en el evento de colisión se detecta si la pelota contacta en uno de los bordes de la tabla, y de ser así, se afecta su movimiento mediante la función motion_add(). Forcé más rebotes, y no he apreciado que se haya quedado pegada a un borde alguna vez.
https://www.dropbox.com/s/jo154pcugvf072r/arkano.avi?dl=0

si no usas randomize(), GM escogerá el mismo valor siempre que uses choose(), irandom(), etc. randomize() hace que la elección sea al azar.

En términos más técnicos. randomize() le da un valor aleatorio a la semilla aleatoria
http://docs.yoyogames.com/source/dadiospice/002_reference/maths/real%20valued%20functions/randomize.html

https://en.wikipedia.org/wiki/Random_seed

Reeditando el ejemplo similar:
http://www.comunidadgm.org/preguntas-y-respuestas/hacer-botar-una-pelota/msg119829/#msg119829

Para simular un arkanoid
http://www.mediafire.com/download/ddx8orjaa2xyg7e/rebote_arkanoid.gmz

El ejemplo apenas tiene código. Todo gracias a la función move_bounce_all(). Obvio que se debe pulir, pero el rebote parece que funciona bastante bien (las bolas van más rápido de lo que se ve en el gif):


Como dijo Clamud, es necesario limitar la velocidad de la tabla, porque moverla a la velocidad del puntero es muy fácil.

Según lo que comentas, no es muy recomendable usar t=choose(30, 60, 90, 120) en STEP. Ya que en cada paso el valor de t podría cambiar. SI por ejemplo, en un paso, el contador es 59 y t se había fijado en el paso anterior a 60, pero en este paso actual se escoge 30 como valor de t, la condición que estaba a punto de cumplirse para c == t=60 ya no se cumplirá.

Yo haría algo parecido a:

CREATE
[gml]
contador = 0
randomize()
alarm[0] =choose(30,60,90,120)
[/gml]

STEP
[gml]
contador++
[/gml]

ALARMA[0]
[gml]
contador = 0    //Reiniciar contador
randomize()
alarm[0] = choose(30, 60, 90, 120)  //Volver a elegir un valor aleatorio
[/gml]

Esto creo que hace lo que quieres. La alarma elige un valor al azar al comienzo (CREATE), el contador se va incrementando en STEP. Cuando la alarma llega a su límte elegido al azar, por ejemplo, 60, el contador se hace 0 (en el evento de alarma). Esto es lo que hacías al preguntar en STEP si el contador y t eran iguales: reiniciabas el contador. Por último, la alarma vuelve a correr con un valor al azar, y el contador comienza a incrementarse desde 0.

La sugerencia que te da Guacusio probablemente sea la mejor, ya que con una sola línea de código conseguirías ordenar por puntaje, por ejemplo. Los otros métodos que se me han ocurrido implican usar demasiado código. Como habías mencionado, las listas se pueden ordenar, pero esa función sólo ordena una lista (registro) individual, y tú quieres que al ordenar por puntos, aparezca información adicional que no está incluída en ese registro (a qué liga pertenece el puntaje). Es cierto que también, conociendo un puntaje, se puede buscar la entrada en una lista, pero el tema se complica si es que hay puntajes iguales o  repetidos (lo cual es muy probable que ocurra)

Probé otro método basado en arreglos, y funciona, pero es muy engorroso, porque se necesita implementar un algoritmo de ordenamiento para distinguir entre un valor menor y uno mayor, y además de ordenar los puntajes, también mover los nombres "LigaJ1", "LigaJ2" arriba o abajo, según se haya movido el puntaje asociado. En resumen, demasiado código para lograr algo que se hace llamando a la función que te mencionó Guacusio.

¿A qué le llamas "variable con array"? No entiendo, por ejemplo, cuando dices:

Cita de: millansoft en Diciembre 01, 2015, 03:39:37 AM
Cada jugador que es una variable con arrays

Lo que entiendo es que tienes 6 arreglos. LigaJ1 a Liga J6. Y que quieres ordenar el octavo elemento [7] de esos arreglos

Lo que quieres hacer es:

a) ¿Ordenar los valores y olvidarme de a qué arreglo (liga) corresponde ese valor, por ejemplo (3, 5, 6, 7, 9, 10) sin saber a qué liga pertenece el 3, el 5, etc.?

o

b) ¿Ordenar los valores (3, 5, 6, 7, 9, 10) y saber que el 3 pertenece a la ligaJ3, el 5 a la ligaJ6, etc?

Por ejemplo, en un objeto botón que sirva para comprar:
EV. MOUSE LEFT PRESSED
[gml]
if (obj_jugador.dinero >= precio_vida)   //Si se tiene suficiente dinero...
{
    obj_jugador.vidas += 1
    obj_jugador.dinero -= precio_vida   //Comprar una vida y restar el costo del dinero del jugador
}
[/gml]

dinero: variable con la cantidad de dinero recolectado. Pertenece al jugador
precio_vida: el costo de una vida. Puede ser una global.
vidas: número de vidas. Pertenece al jugador

Esto es sólo una idea básica- El código depende de cómo queras manejar tu tienda, por ejemplo, puedes agregar otra variable, cantidad_vidas, y antes de presionar el botón de compra, preguntar cuántas vidas desea comprar, y guardar la respuesta en esta nueva variable. Entonces, el código se modificaría a
[gml]
if (obj_jugador.dinero >= precio_vida * cantidad_vidas)
{
    obj_jugador.vidas += cantidad_vidas
    obj_jugador.dinero -= precio_vida * cantidad_vidas
    cantidad_vidas = 0
}
[/gml]

Depende de cómo se quiera implementar, pero no creo que sea algo hardcore, si no más bien relativamente sencillo. Hay muchas maneras de resolverlo, pero la más sencilla me sigue pareciendo la primera que propuse, usar gravity_direction, que permitiría tanto subir la rampa como deslizarse con muy pocas líneas de código. También dependerá de cómo son tus rampas, si son todas iguales o si tienen distintas medidas e inclinaciones.

Cita de: NiuWeb en Noviembre 27, 2015, 02:40:15 AM
En fin, ¿El código que puse antes era más o menos como el que tu indicabas?

En teoría sí, pero se necesitaría más código. Lo que pasa es que sólo presté atención a lo de "deslizamiento", pero no sabía que querías subir y bajar por la rampa a voluntad. Yo pensé que sólo querías dejarte deslizar hacia abajo por la rampa.

No sé cómo quieras que se comporten las rampas, pero quizás también sea posible crear un path que siga la "línea" de la rampa, y hacer que el jugador siga ese path. Obvio esto no siempre es lo deseado, dependería del juego.

Yo soy el que pide disculpas. Es que en casos así, donde existen muy distintas maneras de implementar una solución, no me gusta dar código para copiar y pegar. Tengo muy poca fé en el hecho de copiar y pegar códigos, que siempre será la solución más fácil, pero que en mi opinión, muchas veces quien usa el código no entiende qué hace el código (no estoy diciendo que este sea el caso, estoy hablando de manera general). Esto seguramente está muy bien, pero entonces el término "desarrollador" queda muy diluído, porque la solución pasa por simplemente copiar y pegar código. Pero bueno, olvida mis manías de makero amargado.

Sólo quería traer la atención al hecho de que si la pendiente es 1, el jugador se moverá los mismos pixeles tanto en x como en y cuando avance por la plataforma, si la pendiente es 0.5, por cada 2 pixeles en x avanzará 1 en y, Si la pendiente es 0.3, entonces por cada 3 pixeles en x, el jugador avanzará 1 en y, etc. Esto con el fin de evitar el costo de procesar muchos cálculos o colisiones, que son otros métodos alternativos.

Entonces la idea está bien, lo que falla es la implementación que haces. Yo he hecho pruebas y el método funciona.

Si sabes cuál es la pendiente de la plataforma, podrás saber cuánto tienes que mover en X y en Y al personaje, si es que quieres hacer el movimiento "manual" (sin gravity ni speed)

La manera más fácil que se me ocurre y menos invasiva sería usando gravedad.

GM no solo permite controlar la magnitud de la gravedad, sino también la dirección, mediante la variable gravity_direction. Así que nada más sería cuestión de saber cuál es la inclinación de la plataforma para aplicar un ángulo de dirección adecuado a la gravedad. Dicho ángulo sólo debería ser válido mientras el jugador esté sobre la rampa, al momento de salir de ella, se tendría que cambiar por la dirección "normal" (270°)