[Php-objetos] Tesis D&D
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Jue Mar 5 00:42:07 ARST 2009
Hola Gerardo!
El mié, 04-03-2009 a las 19:56 -0300, Gerardo Valiani escribió:
> una duda que me asalta antes que todo: por qué corno
> elegís enviar esto
> en un adjunto de MS Word que pesa 90K, cuando adentro hay 9K
> de texto
> plano?!?!?!?
>
> Te mande un zip de 9k con un archivo de texto de 90k. No se te
> aparecio. No hice nada raro. Simplemente zipie el archivo.
Sí, estaba comprimido y pesaba 9K... lo mismo que el contenido total
del texto _sin_ comprimir... si hubieras comprimido el TXT, te quedaba
de 2K.
Igual el punto no es el peso, que es despreciable, sino que me llama la
atención el uso del formato que multiplica por 10 el peso y no suma
nada... es como ir a comprar la leche en camión... pero me hacés
maniobrar un camión a mi, que yo iba caminando con la chismosa abajo del
brazo.
Acá, gente que pensó esto mucho más que yo, lo explica con más detalle:
http://www.gnu.org/philosophy/no-word-attachments.es.html
Por suerte nos conocemos y sabés que no hay que leer mis mails con voz
de enojado ;-)
> El mar, 03-03-2009 a las 18:47 -0300, Gerardo Valiani
> escribió:
> > Leo, te mando unos requerimientos mejor armados. No esta
> terminado. Lo
> > que pasa es que me encuentro con un problema. Hay tantas
> cosas que
> > explicar que me voy a pasar el curso con los requerimientos.
>
>
> Tal vez esto indique que el sistema que estás
> planteando es muy grande,
> y no es viable hacerlo completo como tesis del curso. Si es el
> caso
> podríamos buscar un subsistema.
>
> Si, se puede buscar un subsistema. No hay drama. Lo jodido de explicar
> es el significado de las palabras, mas que lo que hace el sistema.
No tanto... hasta ahora vamos bien.
> > Estaba pensando que se podria establecer el libro del
> jugador de
> > Calabozos y Dragones como un anexo a los requerimientos. Hay
> explica
> > absolutamente todo. Asi me puedo poner a trabajar en el
> diseño.
>
>
> Pero Gerardo! Un manual explica qué hace el usuario con
> el sistema, no
> qué hace el sistema! Nunca vi que estas cosas coincidan...
>
>
> No, lo que me refiero es que hay palabras que tengo que explicar que
> me llevarian mucho tiempo, cuando en el manual te explican que
> significan. Como que el manual del jugador sea el diccionario.
> Entonces cuando hablo de "caracteristicas", en lugar de copiar en el
> diccionario de los requerimientos las 15 paginas del manual,
> simplemente "digo ver capitulo 3", y listo. Despues en los
> requerimientos digo como se calculan o se determinan las
> caracteristicas.
Cómo diccionario sí vale. en tu párrafo parecía que lo querías tomar
como requerimiento y largarte a hacer el diseño.
> > Que opinas?
>
> Opino que corrés un riesgo enorme de no saber lo que
> tenés que diseñar antes de empezar a diseñarlo...
>
> Puede ser. Espero que no me pase. Creo tener bastante claro que es lo
> que tengo que hacer. Lo que pasa es que explicarlo con eso del "el
> sistema debe" se me hace complicado.
Es que es complicado determinar lo que el sistema debe hacer... es más
fácil pensar en lo que harán los usuarios con él, en como se instalará
en la computadora/servidor, etc.
Determinar qué debe hacer el sistema implica entender del todo el
problema, y por eso es difícil.
> Vamos a los requerimientos:
> (mis comentarios empiezan con un * )
>
> El sistema es un gestor de personajes de la saga Dungeons and
> Dragons
> para facilitar al master dirigir la partida.
>
> * pero es un sistema solo para facilitar dirigir la partida o
> para jugar
> la partida?
>
> Es para facilitar dirigir la partida. No para jugarla.
Ah!... entonces entiendo un poco menos... los cálculos que el sistema
entregará dónde los pone/usa el master? La partida a dirigir, dónde se
juega? Cómo le llegan al master lo que los jugadores hacen? Para qué
tirar dados de verdad, en vez de hacer todo a base de randoms?
[..]
> * Incompleto: cómo se determina una presa? Es otro personaje?
> "Modificadores varios" es ambiguo.
>
> Si, es la parte que no termine. No dice como calcularlo. Pero ya lo
> tenia en cuenta.
>
>
>
> El sistema debe poder adicionar al personaje su armadura,
> armas y
> equipo. Todos o algunos pueden ser seteados por el usuario
> siendo el
> resto creados de forma aleatoria por el mismo sistema.
>
> * La armadura parece un atributo más...
>
> El sistema debe poder crear monstruos nuevos. Estos pueden ser
> seteados
> por un usuario en todas o en alguna de sus propiedades siendo
> el resto
> creadas de forma aleatoria por el mismo sistema.
>
> * El monstruo parece solo otro personaje.
>
> Si, lo es. Lo que pasa es que las caracteristicas de los montruos
> pueden variar tanto que tal ves pertenezcan a otra clase. Son 6
> manuales de montruos con unas 300 paginas cada uno. Es como catalogar
> los animales reales. Hay de todo! Tengo que ver bien los atributos que
> puedan tener para determinar bien como diseñarlo. Tal ves esta parte
> la podemos dejar fuera de esta tesis.
Sí, o hacer como tesis solo esto. Es un problema interesante, porque el
soft es un esqueleto de posibilidades que luego el usuario usa para
componer los personajes que quiera.
Los objetos andan de maravilla para estas cosas!
> Diccionario:
>
> * El diccionario está bueno porque estás enumerando los
> posibles
> atributos que un personaje puede tener
>
> Al fin una bien!!
Eh! Es un proceso! No estaba mal lo otro: le falta más trabajo
solamente :-D
> Me parece que tenés que trabajar más sobre el cómo el
> sistema va a
> determinar las cosas (resultado de encuentros, aumento de
> habilidades,
> tiempo de vida, causa de muerte, etc). Se modela en base a
> comportamiento, y si te limitás a enumerar atributos y no a
> describir
> qué hacen los personajes, jamás vas a poder encontrar
> comportamiento que
> modelar.
>
> Te entiendo. Todo esto es una sucesión de atributos. Lo que pasa es
> que lo atributos son tan dependiente los unos de los otros, que la
> complejidad esta en armar el personaje mas que en lo que el personaje
> haga.
Bueno, justamente por eso es que hay Patrones de Diseño Creacionales.
Crear Objetos no es una tarea trivial!
> Por eso este sistema no es para jugarlo. Sino para ayudar al Master a
> dirigir una partida y manejar rapido y facil la infinidad de datos que
> existen. Hay sin exagerar unos 25 libros que te ayudan y te amplian
> las posibilidades de este juego. No te hablo de libritos de 15
> paginas. Libros de 250 a 300 paginas.
Sí... cuando murió Gary Gygax me enteré del volumen de su creación y
los anexos de terceros.
> Te adjunto la planilla de personaje para que se vea todo lo que uno
> debe completar para armar uno. Entra aca:
> http://www.devir.es/producto/dnd/players/docs/HP_MdJ3_5.pdf
Ya veo...
> Te explico un poco como seria la cosa:
>
> * Vos elegis una raza, ponele Humano.
> * Despues elegis la clase (seria como el oficio), ponele Guerrero.
> * Despues determinas las caracteristicas en base a tirar unos dados de
> 6 caras y elegis que caracteristicas queres que sean mejores que el
> resto. Entonces yo elijo pornerle a mi guerrerro las puntuaciones mas
> alta a Fuerza (para que pegue fuerte), a destreza (para que pueda
> moverse ágilmente) y a constitución (para resista bien los golpes).
> * La clase del personaje va a determinar con que habilidades me manejo
> facilmente (habilidades claseas) y con cuales no (habilidades
> trasclaseas). Para estas habilidades se tiran unos dados que dependen
> de la clase y del nivel del personaje y se determina cuando puntos
> puedo desparramar en todas las habilidades. Cuantos mas puntos tengo
> en la habilidad, mas probabilidades tengo que mi personaje ejecute
> bien esa habilidad.
> * Despues tenes cosas como las armaduras. Las armaduras tienen un peso
> y un limite de destreza. Si te pones una armadura pesada, absorves mas
> daño, pero te limita la destreza, por lo que es mas facil que te
> peguen. Ademas la armadura tiene un peso. Si vas muy cargado de cosas,
> tu personaje puede moverse menos distancia. El peso que podes llevas
> esta determinado por la Fuerza que tenes, la cual determinaste al
> momento de armar el personaje.
Se entiende...
> Bueno, y asi hay muchas cosas mas. Fijate como todos los atributos
> estan entrelazados intrínsecamente entre si. Entoces el master diria,
> "personaje ataque". El sistema tiraria un random (que seria el dado
> que tiraria el personaje) mas la puntuacion de ataque del personaje.
> Pero resulta que esa puntuacion surgio de un monton de variables que
> se modificaron entre si.
>
> Explicar todo esto por mail es medio complicado. Cuando lo hablemos
> personalmente va a ser mas rapido.
Se entiende bien.
Estoy de acuerdo en que es largo de explicar, pero no sé si es tan
complejo.
Si enumerás como hiciste arriba cada arma y atributo y como modifica
las cosas que pasan (aunque sea una descripción muy breve) te vas a
encontrar con que no es algo tan complejo de modelar.
A veces las cosas se ven complejas porque no se conocen por completo...
La parte buena, insisto, es que en objetos esto es mucho más simple que
en otras tecnologías.
Apovecho y te paso unos artículos de IBM sobre como escribir juegos en
PHP:
http://www.ibm.com/developerworks/opensource/library/os-php-gamescripts1/index.html
Ojo! La implementación es en Programación Estructurada! Los artículos
solo sirven para ilustrar algoritmos, que podrían ser en tu caso algún
método de un objeto.
Saludos!
--
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
Más información sobre la lista de distribución Php-objetos