idea inicial del cdgen

Hace tiempo que no hago nada que sea políticamente correcto y ya tengo muchas ganas de comencer el cdgen (Criando al DeGENeradito). No es otra cosa (en un principio) que el criar a un punkie, aunque también tengo ganas de hacerlo extensible a un skinhead y a un católico.

Caracteristicas básicas

Las ideas para comenzar el programa son muchas, pero sobre todo son las definiciones que tengo que hacer para que esto comience a tener forma.

• La evolución del personaje es por niveles, donde los puntos necesarios para pasar al siguiente nivel es una progresión simple. Es decir, al principio siempre es simple subir de nivel, pero cuannto más se avanza son necesarios más puntos de experiencia (EP) para pasar de nivel. El problema para el cálculo puntual de la progresión es que en los niveles altos (i.e. más del 5 nivel) también deben haber acciones a realizar que tomen más tiempo y más habilidades para poder subir de nivel, con lo que una progresión simple como N+1 = N*2 (donde N es el nivel, y N + 1 sería el nivel superior).


• Obviamente que el personaje tiene puntos de vida (LP) que perder, haciendo mal algunas tareas de riezgo (como por ejemplo el punkie ir a una manifestación y terminar cagado a palos)


• El personaje tiene ciertas caracteristicas, i.e.:
  
  
  
  • inteligencia, se obtendría por comidas y en niveles superiores (luego del 5 o 10) por lecturas
  
  
  • carisma, se obtendría por comidas, y en niveles superiores (si llega a haber) debería incluir el manejo de grupos (aunque si el personaje intenta mandar a un grupo antes de que tenga algo de carizma esto le debería restar carisma).
  
  
  • fuerza, por comidas en un principio y luego por práctica de deportes o alguna otra actividad
  
  
  • karma, esto es en realidad si el personaje eljie hacer acciones malas o acciones buenas. Dependiendo del personaje tendrá más opciones de malas o buenas. El criterio de buenas o malas debería ser en lo que refiere al personaje, por ejemplo, un católico no debería ir a golpiar a un anciano, pero un punkie sí. Un punkie no debería ir a golpiar a un gay, pero un católico y el skinhead sí.
  
  
  • Estado anímico. Debería estar ligado a las distintas caracteristicas mínimas para el nivel, por ejemplo, si para el nivel 3 no se tiene X en carisma, fuerza e inteligencia el personaje tiendrá un -5 en estado anímico, lo que se debería interpretar como menos chances para lograr la misión/acción al 100%. Un punkie puede subir su estado anímico llendo a recitales, un católico llendo a misa y un skinhead llendo con sus iguales.
  
  
  • destreza de defensa, solamente por práctica en lucha o en luchas
  
  
  • destreza de ataque, solamente por práctica en luchas o en luchas
  
  
  • destreza de lucha, debería ser un promedio de los anteriores más lo que se entrene en algún arte marcial (lucha callegera, kun-fu, etc). La parte de defensa o ataque no debería superar cierto número N siendo N = ((DS + AS) / 2) * K). K debería ser un número fijo por cada nivel
  
  
  
  También deberían haber algunas caracteristicas que aparecen en niveles superiores y que estén relacionadas con los máximos alcanzados en las caracteristicas antes mencionadas. Por ejemplo, si el personaje supera un número X para los niveles 5 o 10 (nivel superior) se le debería otorgar imaginación para poder crear objetos o resolver más rápido todavía todas las acciones relacionadas con inteligencia


• Las acciónes (tareas, problemas, misiones o como se llamen) dan X puntos de plus para ciertas caracteristicas si se completan al 100%. También pueden dar algunos bienes (dinero, alimentos, etc) dependiendo de la misión. El total de lo obtenido, dependiendo del tipo de misión, debe verse afectado por las caracteristicas básicas(fuerza, inteligencia y carisma) y también por caracteristicas superiores (karma, estado anímico, destreza en lucha). Por ejemplo, si hay que derribar una pared, y no se tiene mucho de fuerza, la misión nunca podrá completarse al 100% por más que la suerte de el máximo puntaje.


• Todo (al menos en parte) se debe decidir por la suerte. O sea, haciendo un rand entre un mínimo y un tope. El mínimo debería variar en algunos casos, por ejemplo, en una misión de fuerza, nunca se debería obtener un 0 para un persojane que tiene demasiada/mucha fuerza para el nivel que tiene. Lo mismo que el máximo.

Esas son algunas ideas que estoy teniendo. Por ahora el lenguaje de programación será Perl, y la interfaz la haré seguramente Web (para que sea más simple).

La arquitectura sería

• Un server: Parte asincrónica que recorrería la base de de datos de pendientes por ciclos y los iría procesando y actualizando a los personajes. Por otra parte,debería estar la sincrónica, donde por ejemplo, estaría el comienzo de una misión, el resultado de comer (el de sed/hambre debería ser asincrónico, y resolverse de forma sincrónica).


• Cliente: Este debería ser el front-end, por ahora solo web. Enviaría datos al server y mostraría los resultados por pantalla.


• El paso de valores entre el cliente y el server, para hacerlo escalable a futuro, debería ser por XML, pudiendo haber un transporte/proxy en el medio (el cliente/server deberían ser programados para que se pueda agregar esto).


• El server debería dejar toda la información en la base de datos, se puede paralelizar muchas cosas (por ejemplo, en caso de que sea muy grande el parque de usuarios se puede poner otro server que atienda los request -tipo round robin- y ver en todos la misma información).

Los ciclos del juego

La parte asincrónica del server, sería delimitada por ciclos que duren N tiempo no estimado al usuario, de esta forma se puede procesar en batch todos los pendientes. Al hacer los ciclos de 1 hora por ejemplo, solo se procesarán las tareas que tengan más de 3600 segundos o más con respecto a la hora acutal (ciclo * tiempo del ciclo). Esto tiene una CONTRA bastante grave, si son muchos los usuarios el procesamiento batch puede tardar casi un ciclo completo, con lo que el último usuario en ser procesado, habrá perdido un ciclo de juego.

Para resolverla se pueden hacer grupos de pendientes (máximo N dependiendo del tiempo promedio de procesamiento de los pendientes) y procesar los grupos en paralelo, pero dentro del grupo de forma seriada. Esto consumiría mucho CPU, pero lo hace más escalable. Otra forma de resolver esto es hacer un downtime una vez al día y hacer que los ciclos sean de un día. Así todos los pendientes se pueden procesar sin que el usuario esté cargando el sistema. El problema de esto es que los ciclos de tanto tiempo pueden resultar aburridos para el usuario, dado que no se puede hacer nada más si ya se tomó una acción en el día.

Espero que en unos días pueda hacer un bosquejo de DFD para ir viendo que es lo primero a programar.