[DEBATE] TEMA: MINI Rpg´s.

[erkosone]

Hola buenas, el tema que me gustaria debatir un poco por aqui está relacionado con los juegos RPG "ROLE PLAYER GAME".

- Como todos sabemos, este tipo de juegos se caracteriza por tener una historia lineal "o no" en la cual nosotros encarnamos a uno o varios personajes con el fin de completar la trama de sucesos y llegar hasta el objetivo final.


El caso es que realizar un RPG, resulta demasiado complicado para una sola personana, incluso realizar algo de calidad entre un pequeño team resulta bastante trabajoso.
Por eso queria sacar este tema, que tratariamos basicamente de definir lo que sería para nosotros un "MINI RPG".


Los juegos de rol, tienen infinitas cambinaciones de objetos, objetos magicos, objetos de pega.. todo esto normalmente es alojado en una base de datos.
Además tienen escenarios variados donde se desarroya la acción, siendo normalmente la parte menos fuerte del juego, la grafica, pero en alguna ocasión se ve alguna joya por ahi.
El sistema de juego normalmente se suele dividir en 2 partes.

- El mundo.
- La parte del mundo donde nos encontramos.
- La inter-accion con los NPC.
- Las peleas.
- El sistema de obtener niveles superiores.
- Inventario y objetos.

También sabemos que un juego RPG medianamente bien elaborado, ofrece entre unas 30 - 50 horas de juego continuado. "Esto es lo que dicen en varias pages como Meristation ".

Además, está la caracterización de cada personaje dentro del juego, esta parte suele ser muy cuidada para dar la sensación de que realmente cada personaje o NPC tiene su propio caracter o "estilo".




El tema es simple:

- Yo creo que para nosotros, los programadores Indy, un juego RPG está totalmente fuera de nuestro alcance, pues requiere muchisimo trabajo, y a la hora de evaluar el trabajo final, veriamos como hemos descuidado muchos aspectos del juego para potenciar lo que realmente sabemos hacer, que es programar.


Pensando un poco sobre esto.. se que algunos de vosotros ya habeis programado algún RPG, y me gustaria dejar un hilo en el foro, donde se hable de la experiencia y sobre todo el RETO que supone hacer algo así.
Seguramente es un proyecto que se empieza con mucha ilusión, pero a la larga puede ser muy frustrante ver como todo el tiempo invertido en el proyecto se esfuma tras dias y dias de toparte con problemas por la falta de previsión que se ha tenido.


Ami me guastaria mucho conocer, los que ya hos habeis liado la manta a la cabeza alguna vez y habeis programado un juego de tal capacidad tecnica, la esperiencia que ha supuesto, y sobre todo, los consejos que podais dar a los que vamos a empezar con este tema tan peliagudo.

Me gustaria conocer buestra opinión sobre estos temas:

- Cuantas horas de juego creeis que deveria ofrecer un RPG Indie?
- Algun consejo para no cagarla enfocando algun concepto mal desde el principio?
- Que aspecto resaltasteis vosotros para suavizar las carencias de un juego asi creado por una o dos personas?
- Que sistema de juego de los RPG conocidos os ha parecido mas sencillo de implementar?


Bueno, y algunas cosas que preguntarlas parecen tonterias, pero en general me gustaria mucho conocer, tras la experiencia de programar algo asi de "grande", que considerais como los "limites" para que el proyecto sea posible hacerlo completamente entre 1-3 personas.

Bueno gracias por comentar, espero que alguno ya halla programado algo así alguna vez y cuente su experiencia, y para los que no lo hemos hecho todavia, pues tambien opinar sobre el tema, asi por lo menos tendria una visión mas global sobre este tema.

Bueno gracias por leer este toston y espero esos comentarios haber si aprendo algo de todo esto jeje.

[necro_vampire]

Lo de las hs de juego es relativo...
Por ejemplo mira el viejo lufia 2 de snes, el juego tendria unas 25-30hs, pero una sidequest llamada ancient cave llevaria unas 75-100hs...
Las hs de juego dependen del jugador en si, porque puedes quedarte mucho tiempo en alguna parte por X razon; por los logros que debas obtener, tu habilidad en el juego,etc.

[erkosone]

Lo comentava por el Guión, por poner un ejemplo clasico:

Personaje aparece.
Se le cuenta un royo que lo situa en la historia.
Personaje va a saco a por el reto final del juego.
Juego termina.


Yo estava pensando que un RPG con unos minimos de argumento pero sin ser demasiado largo, quizá podria ofrecer unas 5 horas de juego?
Quiero decir, 5 horas teniendo en cuenta de que el que juega a a saco, sin pararse en nada, si no se le mete mucho royo estilo puzle y/o de pensar demasiado, puede ser un guión de 10 pages?

Esque parece facil, pero si te fijas, para encontrar ese punto de "velocidad" en el juego, osea, que no se haga demasiado cansino de jugar, hay que tener en cuenta algo de esto.

Y si, muy cierto, algunos RPG ofrecen años de juego si quieres, están tan currados que el mero hecho de pasearte por ahi ya vale la pena.


5 Horas de juego continuo paracen asequibles facilmente, lo digo por poner un limite al primer intento que voy a hacer..

Tu hiciste algo así necro? Te parece poco tiempo final de juego?

[necro_vampire]

asi no he jugado rpg "ligeros" como el que dices...

personalmente, creo que una vez desarrollado el core/engine usarlo para algo que dure tan poco es un desperdicio...
aunque siempre puedes reutilizarlo, por ejemplo si sacas una serie de rpg cortos como si fueran capitulos...

primero que nada tienes que tener muy en claro, el guion y el sistema de batalla lo mejor definido posibles (siempre ocurren cambios en el desarrollo...)

[erkosone]

Si, la verdad es que necesita una buena planificación.

El miedo que tengo yo ahora mismo es sobrecargar de objetos y cosas así la IDEA principal y que luego sea un autentico caos desarroyarla, por eso preguntava por algun dato sobre numero de objetos, y sobre todo cosas a tener en cuenta antes de empezar.

Bueno gracias por la sugerencia de preveeer el tipo de combate, la ve verdad es que esa es la base para poder estructurarlo todo.

Haber si alguien que haya hecho algún rpg largo puede dar algún consejo mas para no liarlo todo y que al final resulte imposible de hacer.

[Nightwolf]

bueno, io tengo algo de experiencia en los juegos de rol. Te comento las partes más importantes que tienes que tener controladas:

Sistema de menú. Que sea como quieras, pero piensa que debe ser tan flexible como para poder moverte por distintas opciones, poder equiparte equipo, mostrar la información que ese equipo mejora (o no), ver las estadísticas, el inventario equipoado, que permita comprar equipo, incluso venderlo. Importante definir si solo habrá un protagonista o varios. Por defecto, hazlo como que permita varios jugadores, aunque solo haya uno, "por si las moscas".

Sistema de mapa: Es lo que se ve en el juego. Necesitarás un sistema de eventos. Los más simples, los que te permitan desplazarte de una pantalla a otra. Luego los eventos sencillos a la hora de examinar un objeto, una fuente. Los NPC's en realidad son eventos que se mueven (¡o no!) y te van dando información, te piden tener un objeto en el inventario, etc.

Sistema de Combate: Cuando la diplomacia falla... aquí es donde debes elegir qué tipo de comabte quieres poner. ¿Por turnos? ¿En tiempo real? Sea como sea, piensa que en el sistema de combate deberás tener como poco, un sistema de ataque/defensa (y aquí lo complicas agregando si quieres esquivar/bloqueo, etc) Magia (o habilidades especiales que dan más variedad a los combateS) e inventario (poder usar un objeto de inventario como pociones)

En el combate tendrás que definir los enemigos, según sus propios características que no tienen por qué seguir los mismos patrones que rigen al prota. Para empezar, con que tenga vida y defensa y velocidad es más que suficiente.

Una vez que tienes esto más o menos funcional. Haces un pequeño pueblo, con cuatro habitantes. Haces que haya la entrada a una cueva en ese pueblo y haces una misión de buscar algo en esa cueva. Esa cueva puede tener muchos pisos (generados aleatoriamente por ejemplo) con bichos que van incrementando su dificultad. Hasta llegar a un piso determinado, sale el bicho final, lo matamos y ganamos.

Luego tendrás que pensar ¿cómo mejora el personaje? ¿Con experiencia? ¿Usando las habilidades? ¿Y las magias? ¿Cómo se aprenden? ¿O se compran?


- ¿Cuántas horas de juego creeis que debería ofrecer un RPG Indie?
Mientras sea divertido, esto realmente no importa. Mejor un juego corto pero que esté completado que no algo con mucha ambición y que quede en saco roto.

- ¿Algun consejo para no cagarla enfocando algun concepto mal desde el principio?
Ten una idea sencilla, lo máximo posible en mente y cíñete a ella. NO intentes llenarla de detalles. No hasta que tengas hecho toda la base. Ya habrá tiempo para agregar cosas como el día y la noche...

- ¿Que aspecto resaltasteis vosotros para suavizar las carencias de un juego asi creado por una o dos personas?
Utiliza tu fuerte. Un RPG se caracteriza por varias cosas. ¿Te gustaría una buena historia tras el juego? ¿Eres bueno con gráficos? Que tenga un estilo gráfico único. O una música única. Un sistema de combate especial.

- ¿Que sistema de juego de los RPG conocidos os ha parecido mas sencillo de implementar?
Los sistemas son sencillos. Lo que se hace complejo es el desarrollo del mismo. Pero por lo que he visto, un rpg por turnos es más sencillo que en tiempo real.

[erkosone]

Muchas gracias por toda esta información Night.
Realmente llevo tiempo desarrollando el sistema de eventos en papel.. para no caerme de boca luego.. pero le veo lagunas todavia..

Estoy pensando en un sistema que paralize el juego, S_SLEEP al proceso y familia de procesos que estan funcionando, y desplazarme a una zona del mapa que está en negro, para montar ahi el escenario de la batalla.
No se si me estoy complicando ya desde la base..
Pero creo que así lo podria hacer de una forma sencilla.

El tema de los eventos.. no lo tengo claro todavia..

Estoy estudiando la forma en que un evento paraliza el juego y realiza "algo", para luego revivir el juego y desaparecer como evento que es..
Pero no veo un mecanismo simple para hacer esto.


Haber si poco a poco voy cojiendo conceptos claros sobre todo este sistema, porque un error de planificación.. y el juego al a basura..

[PAMERCO]

Pues hombre tanto como a la basura no, pero mucho tiempo perdido sí. Erkos en las revistas divmania, trataron el tema en cursos de varios números...sí no lo tienes vetjmp puedo escanear y le das un vistazo... en el foro estaban los cds que también te orientan

[erkosone]

Pues seria n detallazo tio, la verdad es que te estare muy agradecido si me lo pasas

[Nightwolf]

Congelar todos los procesos para poner un sistema de combate, puede resultar más molesto que otra cosa. Piensa en estructurar el juego en tres partes:

Lanza_Mapa() -> Este proceso lo que hace es muestra un mapa determinado, con las funciones de personajes, el protagonista, etc, etc.
Lanza_Menu() -> Este proceso lo que hace es muestra cualquier menú, tanto ingame para opciones cuando te preguntan algo, como ver el inventario, comprar, etc
Lanza_Combate() -> Este proceso lo que hace es gestionar el sistema de comabte. Presenta enemigos, e inicia la batalla.

Y estos tres procesos en un unico loop principal.

Luego, ¿cómo hacer los eventos? Lo que hago en el Hydlide 3, es asignar los eventos con el tileador de procesos (sí, el juego usa un tieleador, pero no para los fondos, sino para eventos y elementos interactuables) Cada evento es un proceso y tiene un código único (del 0 al 999) Y lo que hago, si el jugador está encima de ese evento, lanzamos el código de ese evento.

Que depende de lo que sea, pues lo mismo es cambiar de sala, iniciar un combate, mostrar un mensaje (o mostrarlo solo si pulsamos espacio), dar un objeto, pedir a cambio otro.

Lo que hago para llevar el flujo de eventos, es utilizar una variable tabla cuento[999]; En esta tabla, voy guardando la información de lo que hace el jugador, para que en caso de cargar una partida, se mantenga como está. Por ejemplo, si un jugador abre un cofre determinado, cuento[0]=1; De esa forma, ya el jugador no podrá abrir ese cofre si recarga la partida. Obviamente ese valor, se tiene que grabar cuando salvamos la partida, junto con los valores del protagonista. Y al ser una simple tabla, es muy sencilla de grabar y cargar.

Procesos que necesitarás:

Process Dame_Objeto(objeto, cantidad);

Deberás crear un proceso que se encargue de dar o quitar un objeto. Cuando un personaje use un objeto y este se gaste, como cuando compres un objeto, necesitarás una manera sencilla de dar (o quitar si ponemos un valor negativo) un objeto.

La manera de hacerlo simple:

El protagonista, tiene una tabla de equipo

My_Equipo[99];

Por defecto, todos los valores son 0, es decir, no tiene nada. Vamos a suponer que el personaje puede equiparse cabeza, manos, pecho y pies.

Lo que hacemos es asignar que cada tipo de esos cuatro objetos ocupe un sitio. Es decir:

Si tenemos que My_Equipo[0]=1; Tenemos el objeto 1 equipado. En 0 vamos a poner que es la cabeza siempre. Y 1 es de una lista de objetos, el que está equipado.
My_Equipo[1]; que sea siempre el pecho
My_Equipo[2]; que sea siempre el arma
My_Equipo[3]; que sean siempre los pantalones.

y apartir de ahí, que sea lo que tenga el personaje en el inventario.

Siguiendo este patrón, es muy sencillo implementar un inventario.

Para gestionar más de un jugador, sería

My_Equipo[9,99]; Es decir, podríamos tener hasta 9 personajes distintos, cada uno con su inventario de 99 cosas.

Con este sistema, puedes reservar huecos, por si más adelante quieres poner, digamos anillos, así que lo recomendable sería que el inventario empezara en my_equipo[10];

El proceso Dame_Objeto se puede mejorar si se convierte en función y además, indicamos que devuelva un valor. ¿Para qué? Si ponemos en vez de cantidad un valor, lo dejamos a 0, para que devuelva positivo si tenemos ese objeto en el inventario, o no.

Así es muy facil hacer un evento de:

¿Tiene el jugador la piedra rosa (siendo la piedra rosa un objeto con el código 10?
if(Dame_Objeto(10, 0))
En tal caso, dale el faisán verde (siendo el faisán verde codigo 11)
Dame_Objeto(11, 1)
y quitamos la piedra rosa
Dame_Objeto(10, -1)


Process Dime_Que_Es(objeto, pregunta)

Es este proceso (o funcion seria mas adecuado) devolvera los valores de los objetos. En un momento determinado, necesitaremos saber que nombre es el objeto 1, en otros, que valor tiene, o su peso, o el daño que hace...

Select(objeto)

case 0: // Vamos a suponer que 0 siempre devolvermos el nombre:
return Nombre_Objeto;
case 1: // Vamos a suponer que 1 siempre devolvemos el precio
return Precio
case 2: // Vamos a suponer que 2 devuelve el tipo de objeto equipable. Si 0 cabeza, si 1 Pecho, si 2 Armas, si 3 Piernas, si 4 no es equipable...
... etc...


Asi si necesitamos operar con los objetos, tenemos nuestra propia funcion muy potentosa ella, que nos facilitara los valores de los objetos.

Luego los objetos los puedes crear de la manera mas simple: Objetos[99]; si por ejemplo, solo hay 100 objetos distintos. La mejor forma es hacer un struct claro, pero al principio, si quieres las cosas sencillas, quizás con eso te sirva para luego más adelante complicarlo más.