Siguiendo con los minijuegos en python, traigo el cronómetro, el cual consiste en tratar de parar el reloj en el segundo exacto (2.0 y no 2.1).

Código en python del sencillo juego de adivinar el número. Como siempre, lo hice pilladísimo de tiempo, asi que el código sigue siendo mierdecilla pinchada en un palo. Pero al menos hay código existente.

En este proyecto ya hay un pequeño problema, y es que este código está hecho con el cursillo de coursera, el cual usan una plataforma propia donde podemos escribir y ejecutar python. Al ser de introducción y demás, resolvieron la parte gráfica ofreciendo una librería desarrollada por ellos en la plataforma para que no tengamos que preocuparnos de ello.

Algo muy útil para los proyectos y que los IDE (programas que ayudan a programar) hacen de forma automática, son los makefiles. Make es una orden que se aplica a cualquier tarea donde algunos ficheros deben ser actualizados a partir de otros cuando éstos cambian.

Se basa un un fichero makefile donde se describen las relaciones entre los ficheros que componen el programa y las órdenes necesarias para cada uno de ellos. De forma automática actualiza sólo lo necesario, lo que haya cambiado y no todo.

Un día malo y de cabreo para mí... tanto tiempo estudiando y tanto tiempo desperdiciado porque no hay manera de concentrarse. Junta esto con Tweetalk y mi prácticamente abandono del blog, y ¡toma coctelera!

Voy a seguir otra estrategia, ya que veo que apenas actualizo, pero si voy haciendo algunos avances, voy al menos dejarme apuntes para que cuando actualice, ponga todo, de ahí que los días transcurridos, no coincidirán con el conteo del calendario, pero sí con la realidad.

En una ocasión os mencioné coursera, y coursera consigue que haga este código muy básico de python. ¿Conocéis el juego de The Big Bang Theory? Os dejo un video muy ilustrativo:

Os traigo dos ejemplos de código con joysticks. ¡Me lo he pasado como un niño pequeño!

El primer código simplemente lista los joystick conectados y algunos detalles, mientras que el segundo mueve un personaje (imagen) por la pantalla. Es una chorrada, ¡pero cómo me lo he pasado! Diez minutos moviendo el joystick como un imbécil viendo cómo se movía el personaje al mismo tiempo.

Joystick
SDL le dedica un subsistema sólo para ello, pero no es le más completo debido a que hay muchos y no siguen un estándar.

Gestión mediante eventos
Los ejes de movimiento del joystick producen el evento de tipo SDL_JoyAxisEvent:

typedef struct{
Uint8 type; // al mover el eje produce SDL_JOYAXISMOTION
Uint8 which; //que joystick
Uint8 axis; //que eje
Sint16 value; //valor del movimiento
} SDL_JoyAxisEvent;

Llegados hasta aquí, me gustaría recordar que nada de esto es mi autoría y viene del Tutorial de libSDL para la programación de videojuegos. Tampoco está escrito a modo de divulgación, sino a modo de constancia de lo aprendido en mi viaje y, por tanto, hasta para mi opinión, es un poco desastre las entradas escritas hasta ahora.

Ratón
Tiene dos tipos de eventos
De movimiento: contiene la posición del puntero, posición relativa respecto al anterior movimiento y si hay botón pulsado y cuál.
De pulsación: muy similar al de teclado.

Hoy ya he podido organizar mejor mi tiempo y vengo con bastantes cosas que había hecho en días anteriores y no había escrito. Y todavía me quedan varias cosas por escribir, que dejaré para el próximo día.

Hoy ha sido un buen día, no lo he dedicado mucho a recorrer mi camino, pero si ha sido aprovechado para otras cosas de las que os hablaré en otra entrada.

Pero de lo que sí hablaré, es que del tutorial que llevo tanto tiempo con él y que es prácticamente todo lo que escribo aquí, he llegado a la parte de los eventos con los joystick, y casualidad de la vida, mi compañero de piso tiene un joystick que tomé prestado para probar.

Amenizando un poco mi vida, leo cómics, tanto en papel como en web, y uno de los que suelo leer es Sinergia sin control, con el que suelo identificarme (y como yo, seguro muchos informáticos) y otras en las que no me identifico pero seguro no tardará en tocarme...

Eso si, humor a raudales!! Aquí una prueba que no es de las más divertidas ni de las mejores que tiene, pero que me parece buenísima.

Unos pocos códigos para estudiar y ver su funcionamiento, copiados basados en el tutorial con el que llevamos estos días.

En este caso son eventos de teclado y ratón. Incluyendo un cambio de cursor del ratón, el cual salió muy raro y no sé si es que está mal el código que había en el tutorial o mi ordenador lo ve raro.

Y nos vamos a los eventos en SDL, de Tutorial de libSDL para la programación de videojuegos.

La estructura principal es

typedef union{
Uint8 type;
SDL_ActiveEvent active; //tipo de evento
SDL_KeyboardEvent key;
SDL_MouseMotionEvent motion;
SDL_MouseButtonEvent button;
SDL_JoyAxisEvent jaxis;
SDL_JoyBallEvent jball;
SDL_JoyHatEvent jhat;
SDL_JoyButtonEvent jbutton;
SDL_ResizeEvent resize;
SDL_QuitEvent quit;
SDL_UserEvent user;
SDL_SysWMEvent syswm;
} SDL_Event;

Ya paso de decir nada sobre mi voluntad, lo que tardo en escribir, que si haré esto, lo otro... Tan solo seguiré. Y seguir, aquí sigo, tratando de repartir mi tiempo entre todo y he avanzado bastante. Hay cosas nuevas, cosas excitantes, buenos avances (dentro de lo que cabe).

Y el hecho de dejar para el final escribir las entradas, lo fastidia todo. Llego tan cansado del viaje que no soy capaz de plasmar aquí lo realmente sucedido en el día e incluso he dejado cosas para publicar mañana. Ya sé que es lo siguiente a cambiar.

Dos códigos, dos simples mains, uno cargo una imagen bmp en pantalla y el otro más de lo mismo, base para todo videojuego que pueda hacer y que se honre con tal nombre. Hasta ahora no tengo nada que lleve ese nombre.
Peeero, estos códigos son imprescindibles para mi camino a recorrer. ^^

Lo único a tener en cuenta en el código es la ruta hacia la imagen que se muestra, que debe ser si o si bmp. (Según la definición del método, tampoco he probado).

Continuamos con el pdf Tutorial de libSDL para la programación de videojuegos y sacándole mucho jugo, ¡cada vez más animado para hacer un juego! ¿Es posible que al terminar el pdf tenga ya uno?

Mapas de bits
Con SDL_Rect definimos el tamaño del cuadrado a copiar y la posición

Cargamos una imagen con el siguiente método, el cual devuelve NULL ante problemas.

SDL_Surface *SDL_LoadBMP(const char *file);

Querido diario:
Cómo se nota la diferencia cuando tienes vacaciones y puedes viajar a gusto, a tener que ocuparte también de otras cosas y más cuando te metes todavía más carga de trabajo.

Pero voy animado, no estoy realmente ocupando todo mi tiempo y tengo todavía un par de días para mejorar mi gestión del tiempo y ver como continuar mi viaje sin problemas.

Tras corregir el código de la entrada anterior, he añadido una clase triángulo y modificado el de la recta para permitir rectas oblicuas. El main ahora saca cualquier figura al azar.

Tiempo, tiempo, tiempo. Ese recurso que tanto dicen que malgastamos y que después lamentaremos.

Yo desde luego, aunque no es la mejor vida que escogería, estoy contento con mi vida y no lo cambiaría, y por ende, no pienso que esté perdiendo el tiempo. Pero si administrándolo un poco mal...

Código!!

Para el que haya echado un vistazo al pdf que sigo, notará que he hecho un copy-paste impresionante, y para colmo de males, no funciona CORREGIDO. Tengo que revisar mejor el código, pero algo hace que se cuelgue y tenga que cerrar por las malas la terminal.

Nadie se convierte en maestro de la nada. Todos los grandes maestros han sido alguna vez alumnos. Y desde luego yo no soy una excepción.

Dejando de lado si llegaré a maestro o no, soy ahora mismo un alumno, y sabiendo de lo inútil que soy siendo autodidacta, me he apuntado a unos cursillos de Coursera. Hay cosillas interesantes, y aunque no sean cosas sobre mi camino, creo que me ayudarán y mantendrán vivo el esfuerzo y constancia en el estudio.

Quiero compatir con vosotros un dispositivo que me parece muy bueno y que ya lleva un tiempo (poco) en el mercado, pero todavía a modo de desarrollo, no de comercialización para el gamer.

Ese dispositivo, es el Oculus Rift. Unas gafas que te sumergen en el juego de una forma bastante realista. La verdad es que he visto vídeos ¡y me quedo con muchas ganas de probarlo y que lo comercialicen con juegos!

Y seguimos con el tutorial de SDL de Antonio García Alba, las partes I y II por si os lo habéis saltado.

Manejo overlay
Crea un overlay. En caso de error devuelve NULL.

SDL_Overlay *SDL_CreateYUVOverlay(int width, int height, Uint32 format, SDL_Surface *display);

Libera el overlay

void SDL_FreeYUVOverlay(SDL_Overlay *overlay);

Antes de acceder a los datos del pixel, hay que bloquear y después desbloquear.

int SDL_LockYUVOverlay(SDL_Overlay *overlay); //cero si correcto, -1 al contrario void SDL_UnlockYUVOverlay(SDL_Overlay *overlay);

Un día más con la intención de recorrer camino. ¿Os acordáis de mis queridos compañeros de viaje? Deimos y Lyria.

Deimos había caído bajo una tormenta, teniendo que ingresarlo, y tras largo tiempo y muchas peleas con los responsables, he conseguido su medicina y ahora ya está de nuevo en pie. Pero todavía le queda rehabilitación... Creo que en un par de días estará de nuevo en marcha.

En cuanto a Lyria, cayó un par de semanas después. Y aunque ahí estaba, no terminaba de recuperarse. Hace poco que por fin ya la tenía de nuevo entre mis brazos como antaño.

Continuando la entrada anterior sobre el tutorial de Antonio García Alba

Inicialización de librerías adicionales

• SDL_image

#include &ltSDL/SDL_image.h&gt

compilar con -lSDL_image

Otro de los pdf que encontré y hasta ahora el que mejor pinta tiene para ayudarme a arrancar con algún jueguecito y estrenar mi portfolio.

Se titula Tutorial de libSDL para la programación de videojuegos y empieza con mucha teoría sobre SDL acompañado de bastante código de ejemplo para ir practicando. Algo ya había puesto en esta entrada, pero volveré a postearlo para dejar una serie de entradas juntas sobre dicho tutorial.

Sin palabras... Algo más de un mes parado.

Vale, si, tengo "excusas", motivos que me han metido en esa situación. Pero no puedo evitar agachar la cabeza ante un conteo de días en los que debería tener algún resultado, contando con el mantener el blog, y, en lugar de eso, sin resultados y un parón de un mes.

¿Sabéis de esas historias en el que el protagonista tiene todo a su favor? Si hombre, de esas historias que haga lo que haga todo le va sobre ruedas.

No esperaba que fuera tan fácil ni rápido ni nada por el estilo. Pero tampoco me esperaba algo tan malo como "Una serie de catastróficas desdichas".

Ya hace días que os comentaba sobre un pdf que contenía un tutorial para hacer un juego y que empezaba desde hacerlo en modo texto a hacerlo gráficamente.

Son varios minijuegos los que se termina haciendo en el pdf, mayoría en consola, comenzando con un clásico juego de números al azar con el que te enseña los comienzos con C#.

Siguiendo el tutorial de Nacho Cabanes, he terminado con la parte del juego en modo texto. Aquí os dejo el código en varias clases que se compila con gmcs y los nombres de los ficheros.

Y aquí vengo con lo prometido, esa maravilla de documento que os había comentado hace tiempo y que explicaba paso por paso cómo hacer un juego y con los códigos incluidos. Os dejo el enlace a dicho manual/tutorial de Nacho Cabanes y vamos con la parte práctica.

En dicho tutorial, usa C# y Mono y va paso por paso, sin presuponer apenas conocimientos de programación ni del lenguaje ni nada. En mi caso, tengo experiencia y me saltaré la parte de explicar, asi que directamente comento lo que hago y os dejo el código.

Querido diario del viajero.

Cuando abrí este blog para escribir durante mi viaje a estos mundos, lo hice precisamente por lo que me está pasando ahora. Soy humano, y como tal, soy difícil.

Durante muchos años no tuve sueño alguno, ni tan siquiera motivos por los que vivir, y por ello dejaba pasar el tiempo, perdido en mis pensamientos y transportado a un mundo creado por mi.

¡A la m***** todo! Tengo 24 horas al día, estoy solo en casa, sin nada que hacer, o más bien poco... ¿Y no hago nada en todo el día?

El mayor peligro de los sueños y caminos no es no valer para ello, tampoco el tiempo, ni los problemas, ni nada de eso. Sino uno mismo. Véase, yo que no le pongo voluntad a aprovechar el mejor y no hago más que repetirme una y otra vez que mañana lo haré mejor, trabajaré más, bla, bla.

Al menos para amenizar un poco y actualizar el blog, os traigo un poco de humor que me encontré en El Jueves sobre los videojuegos. ¡Disfrutadlo!

Esto es una locura, ahora que ando programando, mi rendimiento ha caido en picado y por culpa de lo detallista que soy con mi código. Avanzo, avanzo, programo, leo, sigo programando... y sigo retocando cuando ya debería haber avanzado.

Mi mayor problema está en el poco dominio que tengo con el C++ y también con SDL aunque por ahora ha tenido poco efecto. Nunca pensé que ser tan detallista con mi código (por lo que suele salir buen código), se convertiría en un problema.

Intentando programar algo gráfico, me encuentro con este pdf de tutorial sobre SDL que parece muy bueno y estoy siguiendo conjuntamente con el de Nacho Cabanes de un pdf encontrado en la librería de Open Libra y tras mucho buscar, encontré una versión más actualizada en su página web.

No voy a pararme en los pdf porque no he terminado de leerlos y tengo intención de profundizar en ellos más adelante, aquí dejo lo que me he enterado del SDL.

En un intento de seguir los pasos de un pdf, he terminado haciendo un breve código como iniciación al SDL, librería gráfica que usaré para el juego que estoy programando.

Hay código redundante y se podría mejorar, pero lo he dejado así ya que me parece mejor a la hora de entenderlo y ver cómo funciona. Como único detalle, la ruta de la fuente es la mía personal, hay que cambiarla para que funcione. En general, la fuente se dejaría junto al código fuente, pero paso de hacerlo tan estricto.

Y ya por fin terminó esta semana y poco de parón y me encuentro de nuevo en el camino principal, empezando de nuevo con ganas y energías. Un camino en el que me he quemado, golpeado, aburrido, mojado y unos cuantos "ados" más, pero ha estado bien, no todos los caminos son hacia los mundos del videojuego, pero no por ello van a ser una pérdida de tiempo.

De alguna forma tengo que compensar este parón, en el cual no he aprovechado nada del poco tiempo disponible que tenía. No sé como lo haré, pero lo que sí sé, es que mantendré la marcha que tenía antes y mejor.

Es decir, esos juegos "amateur", que hacen aficionados y sin un duro, véase, yo mismo. Asi que vamos por lo que creo que ya es lo último que puedo sangrar a Advertainmen, los juegos indie. La serie de entradas la verdad es que me decepciona, simple teoría que se parece a la ya vista, y que se ajusta a cualquier proyecto de videojuego, no solo indie.

Lo primero es tener claro que vamos a estar limitados, asi que nada de pensar ¿y esto cómo podría hacerlo? Tenemos que hacer que nuestro universo sea fácil de hacer y que esté integrado en nuestra historia.

Si, si, día 13, es que atravesé un pequeño portal de vaya usted a saber, y enseguida el día y la noche se mezclaron, y aquí estoy, días después en alguna parte sin saber muy bien dónde estoy.

Pero algo claro tengo mirando hacia el horizonte, me espera como una semana horrible, sin poder hacer prácticamente nada hasta que pueda salir de este lugar tan raro y seguir con mi camino.

Poca cosa he hecho hoy, pero una poca cosa muy interesante, uno de los pdf que tenía pendiente por leer, parece muy bueno para lo que yo ando buscando, que es ir programando un poco. No pondré hoy la entrada, principalmente por respeto al autor y pedirle permiso antes, asi que en unos días, cuando me conteste, dejaré constancia de dicho pdf.

Y bueno, eso ha sido todo por hoy. Ya dije que no había recorrido mucho camino hoy, y en los siguientes días no tiene pinta de que vaya a avanzar mucho, me he topado con una pequeña feria por el camino y a gente conocida, y pasaré unos días con ellos, a disfrutar de los artículos y la compañía.

Es fundamental que registréis vuestras obras para evitar copias, malentendidos y sobre todo porque si queréis enviarla a un estudio o distribuidora, lo normal es que os piden tenerlo registrado. ¿Por qué? pues muy sencillo, porque por un lado se aseguran que están hablando o negociando con la persona que tiene los derechos y segundo, porque así no hay posibles malentendidos del tipo "yo te he dejado mi documento de juego y al mes ha salido un juego igual al mercado".

Es una práctica habitual y para ello hay dos formas de hacerlo, entre otras que hay por ahí:

Licencias Creative Commons

¡Si! ¡Un poco más de movimiento! En Advertainmen tienen una serie de post para realizar juegos en móvil con java, concretamente en 2D. Java es un lenguaje que domino, y móvil tengo uno a mano para pruebas... ¡Todo listo!

Bueno, quizás no me ponga a programar ya mismo, en primer lugar porque habrá que planificar un poco, y en segundo lugar porque sigo sin tener el ordenador, el cual está más grave de lo que pensaba, pobrico. También tengo que indicar que los post son de 2009, es decir, unos cuantos años ya y casi seguro ya no se aplica hoy en día lo que nos cuente. Intentaré contrastar con la actualidad lo que aprenda.

Continuando con la inteligencia artificial de parte de Advertainmen, pasamos a algo interesante, el comportamiento del jefe final, el cual es un enemigo, pero normalmente de poderes y morfología impresionantes.

Definir el entorno del jefe final
Para derrotar a un jefe final suele ser interesante interactuar con el entorno, aunque el jefe se empeñe en destrozarlo y tirarnos trozos de ello. Suelen aparecer en sitios muy acotados y definidos, pero no se podrá salir de la zona. Por eso es fundamental que tanto en el diseño de mapa como en el argumento pase algo para poder estar bien encerrados.

Inteligencia Artificial, materia que dí en mi carrera y la verdad... si estáis pensando en androides o máquinas con código la mar de interesante, ya podéis olvidarlo porque no es lo que parece y encima me pareció un aburrimiento. Pero en videojuegos se ve más interesante y os pongo en un par de entradas la serie de Advertainmen sobre el tema.

Cuando hablamos de IA hay 2 personas que se ponen a temblar, el programador que tiene que programarla y el diseñador que tiene que definir el comportamiento de los npcs.

Un día más en este viaje hacia los mundos del videojuego.

Un día más que no está mi querido compañero al lado.

Y un día más que no toco la práctica. Y encima con recochineo, había encontrado una serie de post para hacer un juego en el móvil y me ilusioné, comencé a escribir alegremente la entrada comentando mis impresiones y el material. Creo que más de uno se habría reído con la cara que se me quedó cuando aquello acabó. ¿Eso era todo?

Había al lado otro sobre juegos indie, pero no he tenido tiempo de mirar, y después de este fiasco, no sé que esperar. Mañana sabremos más. Paciencia pequeño saltamontes, no mires todo lo que te queda por aprender, mira lo que has aprendido y compáralo con ayer.

Y ya, con esta entrada terminamos la saga (I, II, III) hablando de los juegos en línea. ¡Mañana más material interesante y menos tocho!

Diseño de juego en linea persistentes
Son juegos completamente en línea y están pensados para permitir jugar a un gran número de jugadores (millones), y es por ello que usan suscripciones mensuales para el mantenimiento de los servidores.

Tercera parte...

Videojuego a Videojuego
Se produce entre consolas/ordenadores por la red. Se presupone conocimientos de redes, TCP/IP, TCP y UDP entre otros, asi que me salto la parte de arquitectura de internet y otros conceptos.

Programación de la red
Necesitamos crear las conexiones y definir la comunicación entre aplicaciones. Opciones:

Continuamos con el "resumen"... Todavía queda al menos otra entrada y ¡pensad que estoy resumiendo 114 páginas!

Videojuego a Usuario

Pantalla
El juego se ha de diseñar pensando en el público objetivo. Podemos usar el esquema de la Asociación para la Interacción Persona Ordenador (AIPO).

De esta entrada, había quedado pendiente una segunda parte. Bueno, pues he terminado releyendo el libro y mandando a la mierda el asco de resumen que me estaba saliendo, asi que repito de nuevo la primera parte y pongo el resto en sucesivas entradas, esperando que esta vez el resumen esté bastante decente.

Algunas partes, como la historia, lo he quitado. Y como no deja de ser un resumen, si os parece un contenido interesante, dadle un vistazo al libro. y aviso, tanto en esta entrada como en las otras, puede ser un tochazo aburrido. ;)

Y de hoy saco algo en claro. NUNCA dejar las cosas para último momento. ¿Alguna vez os ha pasado de viajar y que la noche se os echara encima? Pues eso me ha pasado, altas horas de la noche y todavía ando por aquí haciendo el tonto con el maldito libro que quiero terminar de una maldita vez.

Y eso es todo, un libro, que por cierto ya había leído la mitad antes. Y con tormentas y más tormentas que no han hecho más que estorbar mi camino.

La verdad, ya desvarío, cuando llevo horas trabajando/estudiando y con cansancio, mi cabeza sufre unos efectos muy similares al emborrachamiento, excepto en que mañana no tendré resaca. Que si hablo por los codos hasta con las paredes, que si me tambaleo, que unas pedazos ideas para juegos... ¡Se me ocurrió uno buenísimo!

Si mal no recuerdo, habíamos visto por algún lado qué era esa palabra. Pero por si acaso, es la interfaz de comunicación con el jugador durante el juego. Quedan menos cosas por ver en Advertainmen, y ahora toca La creación de un HUD y como suele ser habitual, yo dejo aquí una especie de resumen y os aconsejo que vayáis al post original.

Denominamos HUD a todo lo que se “pinta” por encima del render del juego y que le da información al jugador, es decir, todo lo que vemos en pantalla de información: la vida, la energía, la munición que me queda, el mini mapa, la vida de los enemigos, etc..

Esta entrada es un complemento a la teoría del diseño de niveles de un videojuego.

Sacado de Advertainmen en su par de entradas, con otro punto de vista, lo explica con una analogía y menos tecnicismos, con algunos detalles y consejos más, para tener un poco más claro qué es lo que hay que hacer.

Imaginaos que sois un Master de un juego de Rol, imaginad un escenario (unas mazmorras repletas de esqueletos asesinos y de bestias inmundas) y empezamos a crear jugabilidad.

Articulo sacado de Genbetadev. El artículo es prácticamente una copia, solo que dicho con otras palabras y omitiendo los códigos de ejemplo que nos ponen, por lo que os animo a ir a su entrada como forma de reconocimiento a su trabajo.

Decimos que dos objetos colisionan cuando uno de ellos se sobrepone a otro en este momento debemos disparar una “señal” y tratar dicha colisión en consecuencia.

Trabajando en 2D, tenemos sprites los cuales simplificamos geométicamente en círculos y rectángulos (según la geometría del sprite). Un círculo lo podemos representar con un punto p que represente el centro del mismo y un valor r que defina el radio. El rectángulo lo representamos con un punto p 2D (x, y) que represente la coordenada de la esquina inferior izquierda, un valor w que represente el ancho y un valor h que represente la altura.

Continuando con el diseño de ítems sacado de Advertainmen, es importante definir todo, desde su tamaño y características físicas, si se puede guardar en el inventario o si lo podemos combinar con otros objetos hasta los efectos y las penalizaciones.

Cada género tiene sus propias reglas y necesidades y que con los ítems ocurre lo mismo. Lo primero que los ítems son un en estorbo para el jugador, pero que no se nos olvide que casi todo el mundo quiere jugar en modo "dios". Lo segundo, es que los ítems restan credibilidad a nuestra historia, porque no hay nada más absurdo que encontrase un botiquín de vida en una cueva por la que no ha pasado nadie y solo hay orcos.

Y ahora toca, por parte de Advertainmen también, teoría sobre los ítems.

Un ítem es un objeto que podemos encontrar durante el desarrollo del juego y que nos aportará algo, ya sea información, ya sea una herramienta para desbloquear un puzle o lo más común, recuperar vida o munición. Las confusiones llegan con el armamento, porque un arma no es un ítem, o no debería serlo, un arma es un arma, al igual que las mejoras de vestuario, una armadura por ejemplo no es un ítem, es vestuario.

¿Entonces como los diferenciamos? Una pequeña regla de los manuales americanos: un ítem es un objeto que proporciona una función temporal al jugador. La munición se gasta pero las armas no. Una poción de recubrimiento de escamas de dragón se gasta pero una armadura no. Aunque seguramente encontréis situaciones donde la regla crea conflictos, pero bueno.