Guía de desarrollo de juegos Indie

#702 Yo ya te recomende la wacom pen de 50 pavos, imposible q exista una mejor relacion calidad precio.

#706 Pues la verdad es que no lo he tocado mucho.. estoy dándole al coco para ver si tengo alguna buena idea

No he participado apenas por el hilo principalmente porque apenas he tocado programación, y lo poco que hago es con Game Maker. Pero bueno, aun así ahí le doy de vez en cuando. Sé que no es lo mismo y blablabla, pero al fin y al cabo, a pesar de las limitaciones del software en sí, es lo único que puedo usar y la desmotivación de pensar que es un programa de mierda o que soy un vago por no intentar aprender algun lenguaje decente la intento reemplazar con la motivación al ver juegazos hechos con este programa.

Respecto al tema de ideas que estáis comentando. Mi principal problema ya lo comenté por aquí, el tema de diseño en general. Yo no sé dibujar, así que hasta ahora para ir aprendiendo he ido tirando de sprites gratuitos / liberados / whatever, y con lo que voy recopilando de internet voy pensando en cosas e intento hacer movidas para aprender a desenvolverme. Así que si es tu caso, Midgard, que creo que sí, pues puedes probar a eso, a ponerte a mirar librerias de sprites gratuitas o lo que sea y ya pensar qué puedes llegar a hacer con eso. Que sí, que tu juego no va a ser ni original ni nada, pero es que en un principio se supone que no deberías ni plantearte el mostrarlo ante el público más allá del 'estoy intentando hacer uno de mis primeros juegos y quiero algo de feedback', que lo haces por aprender, etc.

Yo hasta ahora no he sido capaz de finalizar nada. El error común de todo el mundo: tienes una idea, crees que puedes hacerla, la empiezas, y te va todo genial hasta que te das cuenta de que realmente era más complejo de lo que pensabas, que te falta x recurso, en resumen, que simplemente no está a tu alcance. Pero bueno, ahora estoy algo más ilusionado ya que por fin tengo algo entre manos con intención de hacer de verdad, de intentar acabarlo y pulirlo y tal. Ya iré poniendo alguna cosilla por aquí supongo.

#708 No sé, he aprendido bastante más intentando hacer proyectos imposibles que haciendo juegos simples, pero bueno... la idea que espero tener es simple pero que mole.. es decir, una idea original que atraiga.

Es como pedir ser millonario pero bueno.. si me surge la idea la desarrollaré como mejor pueda ^^

#710 jojojo, ¡DIV Games Studio!

Me lo regaló mi hermano con... ¿9 años o algo así? Y fueron mis primeros pinitos programando. Qué recuerdos.

¡Ponle cooldown al ataque!

Con respecto al movimiento, haz lo que dice GreyShock, pero en cuanto tengas obstáculos te va a ir más bien mal.

No sé si sabes algo de teoría de grafos pero A* es bastante fácil de implementar (no tanto de entender) sobre un grafo cualquiera.

Separas el "campo de juego" en nodos (estilo rejilla) y marcas como inicial el propio enemigo y final el jugador. Luego simplemente vas recorriendo el grafo manteniendo una lista de visitados y por visitar. Hasta aquí es una búsqueda normal en grafo (depende del orden de búsqueda tendrás en profundidad o en anchura.) La magia de A* es asignarle una heurística a cada nodo para elegir el orden de evaluación.

El algoritmo va tal que así (cada nodo tiene dos valores, d(x) = el coste RECORRIDO HASTA ÉL y h(x) = heurística del nodo actual)

ESTADO INICIAL:
- Visitados []
- Por visitar [
  Nodo_Enemigo [d(x) h(x)] <- d(x) = 0
]

1. ¿Está vacío "Por visitar"? No hay camino entre Nodo_Enemigo y Nodo_Final

Si no está vacío:
2. Coger el nodo con menor d(x) + h(x) de la lista de "Por visitar"
3. ¿Es Nodo_Final? Has llegado al final en d(x) distancia

Si no es nodo final:
4. Añadir el nodo a Visitados
5. Añadir todos sus nodos adyacentes que no hayan sido visitados a "Por visitar" con d(adyancente) = d(x)+coste de x a adyancente (1 en tu caso porque no hay coste variable... esto vale si hay terrenos de diferente coste de movimiento y cosas de ese estilo)
6. Volver a 1

h(x) debe ser una heurística admisible, es decir, tal que 0 < h(x) <= h(x) donde h es la heurística perfecta (si supieras el camino correcto hasta Nodo_Final.) Cuando más cercana sea tu h(x) a h(x) más rápido será tu algoritmo. Si h(x) > h(x) puede que no encuentres el camino óptimo. Si h(x) = 0 no tienes información heurística y A* degenera en búsqueda optimal (por camino recorrido.)

Ejemplos de heurísticas admisibles típicas son por ejemplo:

• Distancia euclídea: sqrt( (x-x' )² + (y-y' )² )
• Distancia cuadrática: (x-x' )² + (y-y' )² <--- funciona igual y es mucho menos intensivo para la CPU
• Distancia en "tiles" del grafo: abs(x-x' ) + abs(y-y' )

#714 lol

No sé si el GIF significa que es muy complicado o que es más simple de lo que parecía.

Si es lo primero... ¡no es tan complicado! El algoritmo es un bucle con 6 (cinco en realidad) pasos muy simples. Lo más complicado es el manejo de listas y en casi todos los lenguajes vienen ya definidas. Hasta C++ que es lo más low-level que te echarás en cara para videojuegos tiene listas en la stdlib.

Los nodos son un tipo de datos cualquiera con 3 valores:

• [posicion distancia_hasta heurística]

Incluso la heurística te la puedes ahorrar porque es función de la posición (aunque no está de más guardarla computada, es una cuestión de trade-off entre CPU y memoria.) La distancia es bueno que no guardes distancia si no el camino recorrido hasta (porque te interesa el camino, no el coste ) y la distancia precomputada también (por la misma razón que guardar la heurística pre-computada.)

Lo más complicado es crearte la rejilla con adyacencias y tal, pero eso es cosa del propio juego más que del algoritmo.

Lo más difícil del algoritmo es entender el por qué más que el como, pero para implementarlo no necesitas el por qué Basta con seguir lo que he puesto antes como receta, elegir cualquier heurística de las que puse y asumir que mágicamente encuentra el mejor camino.

#716 ya te digo que suena más complicado de lo que es. Si en lugar de heurística le llamo "estimación" ya no suena tan chunguer, pero queda más profesional llamarle heurística, así parece que sé algo xDD

En realidad el algoritmo se puede complicar más pero por cuestiones técnicas de eficiencia: un nodo puede aparecer dos veces si has llegado por dos caminos diferentes así que sólo te debes quedar con el de menor f. Aún así mi algoritmo funciona, aunque a veces mantiene varios nodos a la vez (aunque no llega a evaluar los de mayor distancia porque... evalúa antes los de menor...) por lo que gasta más memoria. Para un pequeño mapa como el de un videojuego da igual. Para un mapa con millones de nodos (Google Maps anyone?) puede ser un problema.

El por qué no lo vas a entender sin echarle un rato LAAARGO (implica más de lo que parece el hecho de que sea óptimo) pero el cómo no es mucho más complicado que el pathfinding más tonto. Se complica aún más entenderlo si pretendes que la heurística no sólo sea admisible si no consistente (que paso de describir porque, en efecto, se complica.)

--

De nada por las perlas de conocimiento No sé si a alguien le interesarán/le serán útiles pero a mí me ayudan a afianzar conocimiento (no hay mejor forma de afianzar conocimiento que explicárselo a alguien) y si de paso ayudo a alguien pues mira qué bien.