Cómo crear un juego de rol

Supongo que sabes programar, pero te falta crear alguna historia interesante para un juego de rol. Aquí te explico como crearte una.

Los juegos de rol suelen tener un guión complicado. Debes ir a ver un sabio que te dice que hay otro sabio que sabe donde hay una cueva donde se esconde un artefacto que debes traer al rey para rescatar a su hija. Cuando estás en la cueva delante el artefacto, un enano te lo roba delante tus ojos que al final te obliga hacer una excursión al imperio de los enanos. El enano ladrón te dejaría el artefacto en cambio de otro que algún sabio más sabe donde. Cuando al final consigues traer el primer artefacto al rey, la hija ya se ha ido con algún vampiro romántico patético aunque se sospecha no de todo voluntario. (O al menos es lo que el rey quisiera sospechar.)

A primera vista parece que hace falta un guionista coreano para inventar un guión así de complicado, pero realmente basta cualquier funcionario con el papeleo correspondiente subyacente. Por ejemplo, una historia de complejidad similar es la siguiente:

Debes ir a la recepción de oficina que te envía a otra oficina que sabe donde está el departamento donde puedes conseguir el formulario con que puedes obtener el permiso de conducir. Cuando estás en el departamento ese, un funcionario no te concede el formulario por un detalle que al final te obliga ir al ministerio de minería. Ahí te darán un certificado que confirma que este detalle está en regla en cambio de otro formulario sobre que algún recepcionista más sabe donde puedes conseguirlo. Cuando al final consigues el formulario para obtener el permiso de conducir, la oficina correspondiente está cerrada por jubilación del funcionario en cargo.

Es fácil convertir la primera historia y en la segunda y vice versa. Sólo hace falta establecer correspondencias entre fomularios y artefactos, entre funcionarios y enanos y hijas de rey y el permiso que quieres conseguir. Para el primer nivel de tu juego de rol déjate inspirar para registrarte como autónomo en hacienda y la seguridad social. Jugadores más avanzados serán más atraído por contraer un matrimonio internacional o conseguir un pasaporte cuando están registrados como fallecidos.

Conviene también emparejar las características del jugador: A los puntos de fuerza en el juego de rol corresponde la paciencia en la oficina. La mágica se convierte en la capacidad de memorizar conceptos judiciales y, por favor, en lugar de luchar con la espada de fuego contra los habitantes malvados en la cueva aprovecha tu amistad con un abogado o el primo del ministro para hacerte respecto entre los oficiales. ¡No quiero incitar a acciones ilegales!

Lo curioso es que el juego de rol entretiene mientras el papeleo no. Igual será porque relaja más ser atacado por un vampiro rabioso que enfrentarse a un funcionario.

No olvides poner en los créditos que los caracteres que aparecen en el juego sólo tienen una semejanza con personas vivas por coincidencia – a menos que planificas una versión realmente dura de tu juego: una que no reemplaza los funcionarios y oficinas por vampiros y cuevas. Así tus jugadores tendrán un juego que asusta por su realismo y tú tendrás alguna denuncia que te daría publicidad para la primera parte de juego – y un guión para la segunda.

Así, ¡muchas suerte con tu juego de rol con muchos papeles de rollo!

Lectura adicional

Más formas para conseguir un buen guión para tu juego

• Subcontratación excesiva en España
• Programación orientado a objetivos
• Formas de trabajar en la vida real

Cómo hacer cosas más inteligentes

• Dos juegos flash de entremiento
• Cómo hacer una simulación numérica
• Por qué no me gusta usar la palabra “inteligencia”

Dos juegos flash de entremiento

Para relajarnos un poco me permito poner enlaces a dos juegos flash. El primero nos deja jugar a un sistema operativo popular. Aunque visualmente hace referencia a una versión veterana, la forma de usarlo no ha dejado de ser actual. Por ser un juego, esta vez no habrá datos reales a perder.

Se dice que el hardware recibe los malostratos por la culpa del software. En fin hay un software que emula el hardware. El segundo juego nos permite descargar las hormonas de estrés acumuladas durante el primer juego.

Comentarios sin comentarios

Honestamente, el título confunde: Este artículo comenta mucho los comentarios.

Programadores están obligados a hacer su código funcionar. Una restricción que les quita mucha creatividad. Sólo una minoría privilegiada, que escribe comentarios en el código, tiene la posibilidad de expresarse con libertad.

Por qué comentarios

Miles de programadores (bueno, quizá más bien unos veinte) no tienen mayor preocupación que su aparición como coautor en este artículo. Por este motivo evitan el uso de comentarios en su código. Mientas tanto disfrutan el resultado simple y exacto de cada función, que devuelve 3 cuando el parámetro var1 es “OK” y var2 guarda 15. Tres significa que la máquina va a arrancar, el robot gira a la izquierda, el programa va a terminar o el contrario de esto – o todo a la vez o una combinación arbitraria de esto. Depende del contexto, el cual puedes encontrar 150 líneas más arriba o en otro fichero del programa. Mala suerte, si la función está mal y debería devolver 4, que es algo diferente que 3 o lo mismo. Depende del contexto. Hay muchas maneras de escribir código inmantenible.

No te entiendo

Usando comentarios trae la cuestión de lo que es un buen comentario. En general, yo consideraría un bueno comentario alto que explica la semántica y no la sintaxis. Alguien que sabe programar no necesita un comentario como

// Incrementa x en uno
x = x + 1

Sin embargo, es un comentario obligatorio cuando sería el único en una función de 1500 líneas.

Explicar la semántica puede ser difícil a veces. A continuación sigue una lista con ejemplos de la vida real, que muestran lo que no es probablemente un buen comentario.

bool ProcesaTeclaUsuario(void)
// de momento es global por problemas con los punteros

En este programa no hubo ninguna función no-global. Pero, por supuesto, puede haber una razón de no ser global diferente para cada función.

num_mens_control++;  //TODO tiene sentido???

¿Tiene sentido lo que haces ahí? Mientras funciona, todo tiene sentido. En este contexto me es grato presentar la definición

Un científico sabe por qué no funciona. Un ingeniero no sabe, por qué funciona.

Mientras cambias código y no estás seguro si el cambio fue bueno, puedes dejar las líneas originales comentadas y marcar la modificación con una palabra especial. Si tienes mucho que cambiar, entonces un poco de variación puede resultar más gratificante. Estos ejemplos son de un fichero con unos 2000 líneas:

//TODO
//XXX TODO
//WORKAROUND
//WORKAROUND TO DO IT BETTER
//XXX BAUSTELLE
//XXX BAU 28.06

Baustelle es alemán para “obras”. El aviso “constantemente en obras” en una página web es igualmente significativo. Quién esperaría que una página web cambiase.

!! rules necesarias para el correcto funcionamiento:
rule void Nr_Set_Visible_Displayed(object Ob_Strip input)

A diferenciar de las rules no necesarias y las rules para el funcionamiento incorrecto.

!!  start of Md_GbMDW_FPL needed rules

¿Escribes código que no es needed?

!! END OF RULE EXPERIMENTAL

Vale. Lo haces.

Cuando la comunicación falla, todavía te queda decir a otros lo que deben hacer por código fuente.

!! Note: move this(Ob_GbManCoord) to strip model.
export variable object Ob_GbManCoord;

Por supuesto, lo podrías hacer tú mismo, pero ¿por qué?

!! New model for waypoints line
model MdGb Md_Gb_Waypoints

O este comentario es actualizado frecuentemente o este modelo será nuevo para siempre.

!! Study assigment of colours
if Ob_Fp_Strip.In_Flag_Un_Flag_Field then

A veces, un ordenador toma un respiro se pregunta: ¿En qué color debería pintarlo?

!! Rule to solve the STR-1207: Panning in Playback mode

Resuelto. Una vez y por todas. Ni piensas en que este código podría ser útil para otro propósito.

//declarar el objeto, es importante inicializarlo a NULL
TStringList *Valores = NULL;
Valores = new TStringList; //crear instancia del objeto

Esto es un comentario importante. De otra forma el lector podría llegar a pensar que no vale la pena asignar NULL a un puntero que será sobrescrito inmediatamente después.

Como comentar mejor

En general podrías tener en cuenta las siguientes ideas para escribir un código.

• Como un programador ya sabe el lenguaje de programación, no necesitas explicárselo de nuevo. Una excepción sería si usaste el lenguaje de una forma rara y sorprendente como, por ejemplo, sobrecargar el operador + sin la connotación de “más”. No obstante, en este caso deberías considerar cambiar el código y no el comentario.
• No repitas código en tus comentarios. “Añadir cinco a x” no aporta ninguna información nueva a “x + 5”. Céntrate en el significado de x, por ejemplo “añade 5 metros a la posición x.
• No olvides que identificadores (variables, tipos y nombres de funciones) ya deberían contener su semántica en si mismos. Un comentario puede todavía ser necesario para explicar el contexto en que una operación tiene lugar, por ejemplo un comentario a send_to_printer(document) podría ser «Aquí el documento debe estar en un formato adecuado para la impresora».
• ¿Tiene importancia cuando el código o el comentario fue escrito y cuantas veces fue cambiado? Ten esto en cuenta antes de escribir una fecha en el código. “Nuevo” y “viejo” dan una idea de que algo fue cambiado, pero no cuando. No obstante, no tengas miedo en que comentarios podrían caducar en el próximo cambio de código. Todavía pueden dar una pista importante y un programador sabe que lo que hace un programa funcionar es el código y no el comentario.
• No olvides limpiar el código. Muchos de los ejemplos anteriores se “olvidaron”. Eran marcadores durante el desarrollo que perdían su sentido cuando el trabajo concluyó.
• Si tus ficheros usan una cabecera, sólo escribe cosas ahí para que habrá suficiente disciplina para actualizarlas. Un fichero guarda una fecha de última modificación, el último “autor” es probablemente uno de tu grupo de trabajo, y la versión del fichero fuente inútil. Un fichero ejecutable tiene un número de versión y todos los ficheros fuente para crearlo tienen este mismo número de versión automáticamente. A menos si vendes ficheros fuentes y no programas que funcionan.
• No es mala idea de usar comentarios para separar código visualmente en secciones (con barras o incluso con títulos). Es sabio usar el mismo estilo para el mismo tipo de sección.

Referencias

• Por qué poner comentarios en el código
• Documentación automatizada
• Formas de trabajar en la vida real
• Unmaintable Code (en inglés)

Diccionario tu jefe – español

Saber idiomas es esencial para poder moverse en el mundo laboral. Aquí viene un pequeño listado con «frases celebres» y su sentido.

Expresiones en el mundo laboral

Expresión	Significado
Lo importante es que funcione.	No te quiero ver haciendo cosas que no se ven inmediatamente en la pantalla. Lo importante es que el cliente pague aunque sea por engaño.
Debemos hacer calidad.	Lo importante es que funcione.
Programación orientado a objetos.	No sé lo que es programación orientado a objetos, pero debemos hacer calidad.
Lo más importante es la estabilidad.	Pon la nueva funcionalidad pero sin errores. Mañana hay entrega.
Cuando el cliente nos lo pide, hacemos la documentación.	No pierdas tiempo apuntándote cosas. Un buen empleado lo tiene en la cabeza.
Cuando tenemos tiempo…	Nunca.
A estas alturas del proyecto	Dos semanas después del comienzo
Tenemos una fecha de entrega	Nosotros quiere decir: yo pongo la fecha y tú la entrega. Es posible que el cliente no comprará el ordenador necesario hasta dos días antes.
¿Qué podemos hacer para dar un empujón al proyecto?	¿Podrías hacer horas extras?
Esto es un trabajo en equipo.	Nuestro código es como un piso de estudiantes: la limpieza impone el más guarro.

Formas de trabajar en la vida real

En cada proyecto existe un flujo de trabajo, en se recurren de forma secuencial varias etapas.

1. Se genera una idea general de que debe hacer el proyecto. Por ejemplo un programa que controla los movimientos de trenes en una estación.
2. Los ingenieros de sistema elaboran con los clientes un cuaderno de carga y traducen los requisitos a un diseño. Por ejemplo:  El programa tiene una ventana en que se puede editar el horario del tren. Tiene un botón «Aceptar» que copia los datos en la ventana a la base de datos.
3. Los programadores escriben un código que hace esto.
4. Los ingenieros de prueba comparan el comportamiento del programa con los requisitos en el cuaderno de carga

¿Esto no suene totalmente lógico? Pensar qué quieres, cómo lo quieres, hacerlo y comprobar si lo has hecho bien. Lógicamente es un ideal que en una empresa de alta tecnología no se puede conseguir siempre. Por lo tanto, el ciclo de desarrollo suele tener típicamente más bien el siguiente estilo.

1. El director general de los tuyos y de los suyos firman un contrato, donde aparece por primera vez una fecha de entrega.
2. Los ingenieros de sistema comienzan a ingeniarse un sistema y avanzan a buen ritmo.
3. El jefe de los ingenieros de sistema se da cuenta que el buen ritmo haría duplicar el tiempo previsto para esta fase y pide que se diseñen los componentes en dos en lugar de cuatro semanas.
4. Como los ingenieros de sistema no llegan, los programadores empiezan a programar aunque todavía no está de todo claro qué.
5. Los programadores avanzan a buen ritmo.
6. A la medida que los ingenieros de sistema completan el diseño del programa, los programadores deben modificar el código.
7. Los ingenieros de prueba comienzan a probar el programa que a veces falla porque las partes en cuestión aún no están programadas.
8. Entre fijar los errores reportados por los ingeniero de prueba y modificar el diseño del programa hay tímidos intentos de adaptar el programa para hacerlo más legible, orientado a objetos, modular y tal. Por alguna coincidencia hay de repente dos días enteros para esto porque el programa ya contiene todo para la primera entrega parcial al cliente.
9. El cliente está contento porque ve que están todas las ventanas aunque los botones no funcionan. Los ingenieros de sistema sugieren un cambio propuesto por los programadores de reducir el número de
   los botones «Aceptar» a uno por ventana.
10. Los programadores lo cambian.
11. Mientras añaden componentes adicionales a la funcionalidad, el cliente se muestra preocupado por el elevado número de errores detectados por los ingenieros de prueba. El jefe del programa promete reducirlo.
12. Como el tiempo entre arreglar errores y programar nuevas partes con más errores se hace corto, el jefe del grupo prefiere aumentar la rapidez. Lo que se podría dividir en dos ficheros también cabe en uno, además a estas alturas del proyecto ya no conviene agrupar los ficheros en directorios por tener una mejor modularidad.
13. El cliente se da cuenta que no se puede configurar la aplicación. Pide editores para que los parámetros fijos sean variables inicializadas con un fichero de texto.
14. Los programadores empiezan a reescribir su código para que todos los arrays sean de un tamaño variable.
15. El jefe del programa se muestra preocupado, porque que fallan partes del código que funcionaban antes.
16. Los ingenieros de sistema adaptan su documentación de diseño a lo que realmente hay programado.
17. El programa se cuelga tres veces en una prueba con el cliente. Esto tiene máxima prioridad y justifica que al final, sí, se dividen los ficheros en varios directorios.
18. Aún falta un 20% de la funcionalidad. La lista de errores ha crecido porque todos los programadores estaban ocupados por los fallos fatales de la semana pasada. Al mismo tiempo, se ponen por lo menos tres errores por anomalía reportada para que el número de errores parezca más pequeño.
19. Un programador detecta que la ventana de configuración debe tener opciones que son técnicamente imposibles de realizar. Después que el programador descubra como se podría hacer algo similar, el ingeniero de sistema propone que el programador le diga como lo haya programado para que pueda adaptar el documento de diseño.
20. El programa se cuelga sin más razón aparente cuatro días antes de la prueba final. Las revisiones de los programadores durante el fin de semana fallan por la documentación incompleta de bibliotecas externas. El cliente no acepta el programa a pruebas.
21. Tras haber codificado toda la funcionalidad, el cliente quiere que todos los mensajes de textos sean leídos desde un fichero. Realmente ya lo quería desde el principio, pero como esto no añade funcionalidad, nunca se hizo.
22. Tres programadores se quedan con los errores no resolubles. Uno de ellos tiene también la tarea de inventarse los comentarios para que parezca que al menos un 30% de líneas sean comentarios.
23. Supuestamente, el cliente usará el proyecto y no se puede excluir que también será documentado.

¿Qué conclusiones podemos sacar? Pues, la primera es ciertamente que hagas un repaso a tus ideales juveniles pero sin deprimirte. Aunque parece imposible de cambiar el mundo entero, sí, es posible que al menos tú hagas lo mejor posible.

Por ejemplo, el cambio que podrías enfocar desde ahora es dejar de quejarte de que la imprevisión e la improvisación son la regla (a pesar de lo que diga tu jefe), sino que se planifica en tiempo real. Suene muy bien y es una pieza para obtener la actitud adecuada para que algún día tú serás el jefe.

Te deseo mucha suerte.