Rpg Rules System

[manko]

 El siguiente paso en mi proyecto es crear el sistema de reglas del Juego (un juego de estrategia-rol), y estaba dandole vueltas a la cabeza y buscando info por internet, pero entre tanto os pregunto a ver que habeís hecho vosotros o que conoceis en este terreno.

Mis dudas son dos: ¿que sistema de reglas usar? y ¿como implemantarlo?

De momento no me he informado muy exahustivamente, pero en cuanto a la primera pregunta me gustaria que fuera uno muy estandar, parece que el de mas aceptación es el de D&D y GURPS, ambos libros son de pago, un punto en contra.

Y en cuanto a como implementarlo pues tengo varias ideas, aún no me decido. Seguramente empezare por una serie de funciones vacias en plan:  

char* ataca(pj1*,pj2*, modificadores...)

de modo que las puedo empezar a usar y puedo seguir con el juego hasta que se me ocurra implementar el Sistema de Reglas.

Que os parece? cuales usais vosotros?

[sés]

 Personalmente, las reglas de D&D me parecen una mierda como un piano; están llenas de cosas sin sentido.

Yo intentaría hacer unas reglas en las que no haya niveles... o no como se entienden normalmente.
¿Tiene sentido (y esto ocurre muuucho) que un mago se pase días matando bichos con una ballesta y de repente suba de nivel y aprenda varios hechizos nuevos? Ejem... D&D ^_^

Este sistema puede estar bien para un mata-mata (Diablo).

Si hablamos de ROL, lo lógico es que sea lo más real en el desarrollo del PJ, ¿no? Mejor un sistema en el que aumenten las habilidades que se utilicen. En el caso anterior, ese mago habría ganado una extraordinaria habilidad con la ballesta... y musculatura, que un mago enclenque cargando constantemente con una ballesta enorme al hombro...


Un apunte chorra sobre ese ejemplo que has puesto:

Código [Seleccionar] Expand

char* ataca(pj1*,pj2*, modificadores...)
Solo sería necesario (en principio) pj1 y pj2, cada PJ tendría sus propios modificadores. Y si te refieres a otros modificadores (del terreno, por ejemplo), creo que deberían estar implementados en el propio motor.

[gdl]

 Yo te aconsejo leer Las Lucubraciones Inconexas De MU. La única pega es que están en inglés. :(

Si quieres ideas por un tubo, pásate por El Foro de Deseos de PlaneShift. También en inglés. <_<

Y para cosas en español.. ¡¡la página de RRC2Soft!! :D (El cual pulula también por estos foros)
 

[jelorol]

 Te recomiendo que hagas tu propio sistema, o al menos ajustes alguno ya existente a tus necesidades. Por lo general, en un RPG para ordenador puedes meter reglas más sofisticadas, ya que como va a ser el PC el que se encargue de gestionarlas...

Como base para un reglamento yo usaría Fuzion:

http://www.thefuze.com/

El reglamento básico es gratuito, y para mi gusto es bastante flexible como para adaptarlo a cualquier ambientación. Hay ampliaciones también gratuitas que cubren aspectos como magia, ciberpunk, etc.:

http://mecha.com/~conkle/fuzion/plugins.html

Otras reglas bastante adecuadas son las que se extrajeron y adaptaron para RPG de lápiz y papel del juego Fallout.:

http://www.dungeon.gr/database/archive/fal...out_pnp_2_0.zip

Sobre los dos reglamentos que comentas, ninguno me gusta demasiado...el GURPS a lo mejor, pero el D&D es demasiado rígido, y gran parte de la mecánica que usa está completamente desfasada. Eso sí, es conocido por una amplia proporción de roleros y por tanto más sencillo a la hora de conectar con los jugadores.

Finalmente un consejo: antes de programar, ten decidido el diseño del juego y las mecánicas del mismo a alto nivel. No hace falta que definas ya los algoritmos de por ejemplo, un ataque, pero sí que tienes que saber cuándo será posible atacar, qué factores influirán en el éxito o fracaso del ataque, etc. De otro modo, lo que vayas preparando ahora a nivel de programación seguramente tendrás que tirarlo a la basura o dedicar  muchos esfuerzos a adaptarlo al diseño final. Seguro que los más curtidos del foro pueden darte mil ejemplos de desastres debidos a pensar en el diseño del juego después de programarlo...

[Vicente]

 Hola,

yo discrepo de que las reglas del D&D (y por consiguiente el d20 en general) sean una mierda. Todos los sistemas hacen aguas, ni uno se salva. El d20 tiene niveles, y puede que no sea una mecánica "real", pero es que el mundo real normalmente no es nada divertido. Y tampoco está desfasado, el d20 es de los sistemas más actuales que hay en el mercado (mucho más que Gurps u otras cosas que se comentan por el post). Tienes además varias ventajas:

- el sistema d20 está liberado: no tienes que pagar ni nada por el estilo. Las reglas las tienes aquí (acaban de liberar el d20 3.5 hace poco creo):

Open Gaming Foundation

En esta URL tienes parte de los SRD traducidos por la gente de d20-es:

d20-es

En la página de Wizards of the Coast tienes seguramente más cosas.

- las mecánicas del d20 no se llevan nada mal con el PC (el combate por ejemplo usa un tablero, cosa que ayuda mucho a adaptarlo). Tanto el Neverwinter Nights como el The Temple of Elemental Evil usan el sistema d20. Tienes editores de personajes y bastante soft alrededor de este sistema (PC Gen por ejemplo, es un editor de personajes muy bueno, RolePlayingMaster es una herramienta variada tambien muy buena).

Quizás la mejor página para encontrar informacionsobre el d20 sea esta:

ENWorld

- el d20 no solo vale para Dungeons & Dragons. Wizards ha sacado varios juegos más basados en este sistema: d20 Modern (que se ha ampliado con d20 Future, y no recuerdo cuando salía d20 Past) y Star Wars d20.

- tienes muchiiiiisimo material, y de todos los gustos y colores: que te va más el estilo medieval- ciberpunk? Echale un vistazo a Iron Kingdoms de Privateer Press. Te mola el mundo del Everquest? Pues tienes tambien libro del tema, etc etc. Basicamente todas las empresas del mundo del rol producen o han producido material para el d20 (y han sacado sus propios juegos, reglas, etc etc).

Eso si, por experiencia personal, el d20 requiere que pienses las cosas muuuucho, pero mucho. El sistemas no es nada rígido, es más, es demasiado flexible y la implementación se puede volver complicada si no te lo conoces bien y no tienes las ideas claras. Si te lo conoces yo tiraría con él, pero si no es el caso, y no tienes ganas de leerte los SRD, hacer pruebas y en fin, dedicarle una buena cantidad de tiempo antes del diseño, pues no se, busca algo más sencillito.

Espero que te sirva de ayuda. Un saludo!

Vicente

[Buffon]

 Realmente que más da una forma u otra mientras enganche, no?

las reglas del d&d están muy bien, sino no tendrían los adeptos que tiene, lease baldurs gate y sucedaneos siempre son records de ventas antes de ser lanzados... neverwinter nights, algun juego de rol mejor que este? ¬¬

si nos basamos en subir las habilidades segun las usamos, tenemos ULTIMA ONLINE - DUNGEON SIEGE, este último muy bueno en gráficos pero una mierda en jugabilidad desde mi humilde punto de vista, el ultima online, no hay nada que echarle en contra, de lo mejorcito :)

y ya más accion, diablo2.

por lo general, usa el método que mejor te convenga o el que más te guste, todos los métodos tienen a gente que le gusta o que discrepan, así que hazlo a tu gusto.


sobre la funcion esa, si lo haces con OOP y tienes varios jugadores en un vector por ejemplo o en una list creada por ti mismo, la funcion para que kieres que te devuelva un char* ?

yo más bien la haria propia de la clase PJ y hacer

vector jugadores;

blablabla

jugadores[1].atacar(jugadores[2],modificadores);

no se si me he explicado bien :S

es lo que tiene la POO.

[manko]

 Gracias por las respuestas, me han resultado muy útiles.

Ahora antes de escribir una sola linea de código voy a leer los diferentes sistemas y pensarmelo un poco, es verdad lo de que primero tener muy claro el diseño y luego a picar.

Y ya vere que sistema escojo, de momento implemento uno vacio (q no hace nada, para poder seguir con el juego) que parece que este es un punto bastante mas grandecito de lo que habnia pensado, o hare una primera versión de las reglas muy facilitas.

Y de momento me tira mas el clasico d20, mas que nada porque hace mucho que no juego rol, mis ultimas partidas fueron de Señor de los Anillos. De todos modos veo que me queda mucho por aprender en este tema, a leer toca.

Y Buffon , en cuanto a meterlas en la clase jugador con POO, pues si, tienes toda la raxon seguramente ese sea  el diseño normal. Pero prefiero tener una clase jugador con solo la ficha (en plan struct) y luego las funciones en un namespace a la que pasarle los punteros de los jugadores (vamos que tiro el POO a la basura en este caso), es por gusto personal, y tener mas separada cada accion, nose, pero vamos que gracias, que es buena idea.

Un saludo a todos.

[Mars Attacks]

 A ver para cuando un juego de estos en los que tengas que pacificar las guerras entre razas y clanes a base de diálogo y de Talante®. Para luchas ya hay bastante con los Bush, el mercado está saturado.

[manko]

 No se si pacificar guerras, creo q seria un poco aburrido, jeje. Pero si resultaria muy interesante plantear en los juegos de recursos-estrategía (no se cual es la palabra exacta, vamos los AOEs) hacer de alguna manera un juego de suma no cero.

Me surgieron muchas ideas a raiz de leer el libro "El dilema del prisionero", no recuerdo el autor, que trata la teoría de juegos y su creador John V. Newman. El caso es que las decisiones mas díficiles se originan en situaciónes de suma no cero, y donde la situación de equilibrio es difícil de calcular.

Un juego de suma cero, es donde lo que tu ganas, lo pierde el contrario ( el ajedrez, guerra, etc... ), un juego de suma no cero es El dilema del Prisionero.

Pues estaría interesante añadir en estos juegos, aparte de la administración de recursos y la fuerza del tamaño de tus tropas, factores de decisión estratégica de este tipo. Mi imaginación no da para mucho, pero serian situaciones donde colaborar ofreciera muchos mayores beneficios que la guerra, siempre existiendo el riesgo del engaño o el sabotaje por detrás. Comercio, carreteras y ferrocarriles, Construcciónes tan grandes que deban ser costeadas por varios jugadores y que luego aporten gran numero de recursos (acueducto? presa?) con el riesgo de que algun jugador decida dar un golpe militar a la alianza y quedarse con la construcción.

Supongo que para ello el objetivo del juego sería acabar con el mayor número de riquezas (un dato que sería muy conveniente tener en secreto), los espias serían una unidad vital en este juego.

mmm ¿? vaya se me esta ocurriendo un juego mientras escribo XD. Bueno os comento esto para que opineis sobre dar un pasito más en este tipo de juegos y que no se queden solo en el recolectar-fabricar-atacar.

Un saludo.
 

[rrc2soft]

 Llego un poco tarde, pero quiero dar mi punto de vista (y el de un amigo) sobre como implementar las reglas.

El caso es tener un modulo (clase unica, unidad) REGLAS, que se encargue de manejar toda la dinamica interna del juego (usar objetos sobre personajes, definir la influencia de los estados anomalos [silencio, envenenado] sobre un personaje, calcular el exito de una tirada de habilidades [robar, esconderse,...]). Uno de sus elementos, por ejemplo, es la funcion/metodo APLICAR(datos_objeto,personaje), que utiliza un objeto (que puede ser tanto un objeto como la descripcion de una magia) sobre un personaje/ente. Internamente, el modulo de reglas se encargara de descubrir si el objeto es un arma, o algo que cura (tanto hechizos como pociones), y aplicarlo (calcular el impacto, restar los puntos de vida, devolver informacion,...).

De esa forma, puedes hacer dentro del engine que cualquier entidad (personaje, objeto) cause danyo a otro personaje. Por ejemplo, cada objeto tiene asociado el tipo de danyo que causaria a un personaje en caso de impacto ("datos_objeto"), y si con un rifle de gravedad (*ejem*half-life2*ejem*) lanzas un objeto a un personaje, sencillamente "aplicas" las reglas en caso de impacto.

Pos eso  ;) .

[ethernet]

 Cuando hice el PFC usé modelos ocultos de markov para entrenar los modelos de los fonemas del reconocedor de voz.  A grandes rasgos vienen a ser una serie de estados que "aprenden" a medida que les das estados de muestra para después poder hacer una serie de operaciones con ellos, entre ellas saber a partir de una serie de estados cual será el siguiente, etc.
A qué viene todo esto? pues que siempre me pregunté como funcionaría un sistema así aplicado a la lógca de combate de un juego de manera que la máquina fuera aprendiendo de los movimientos del usuario a medida que avanzara en el juego haciendo a los personajes más inteligentes.

No es una herramienta matemática fácil de usar y mucho menos de aplicar pero sería interesante verlo así

ahí queda :P

saludos

[gdl]

 

El caso es tener un modulo (clase unica, unidad) REGLAS, que se encargue de manejar toda la dinamica interna del juego (usar objetos sobre personajes, definir la influencia de los estados anomalos [silencio, envenenado] sobre un personaje, calcular el exito de una tirada de habilidades [robar, esconderse,...]).

Opino que sería mejor que ese módulo de reglas sea la clase base de la jerarquía de objetos del juego (elementos de aquí en adelante, para distinguirlos de los objetos que no son de las reglas del juego como los gráficos o los sonidos). De esta forma, bastaría aprovechar el polimorfismo de función para que la misma llamada a una función miembro (por ejemplo "atacar" o "aplicar") tuviese diversos efectos según el elemento (sea arma, herramienta, bicho o jugador). Si no hay una regla especial para ese elemento, se usa la de la clase base (que es lo que se hace automáticamente en la POO).

También es muy recomendable tener una funcion miembro "EsUn". De esta forma, por ejemplo, una espada mata dragones, le preguntará al objeto atacado si "EsUn" dragón, en caso afirmativo hará un ataque distinto (y presumiblemente más poderoso).

Por otra parte, los efectos de "atacar" o "aplicar" se deberían hacer a través de funciones miembro especiales del tipo "daño", "cambiar_estado", etc. Así si el dragón de antes tenía resistencia a las espadas, el daño que le hace la espada matadragones es menor que si fuera una lanza matadragones. De nuevo, en "daño" haríamos un "EsUn" a la espada y actuaríamos en consecuencia.

Con este sistema, conforme se van añadiendo elementos se van añadiendo reglas y el sistema no es monolítico.

Claro, que también es más divertido (=difícil) de programar :)