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.

Y ya llevamos una semana. Si miro lo que llevo en el día de hoy, me parece poca cosa, mucha teoría pero nada de práctica, y aún así, me parece poco lo que he aprendido hoy, ítems, hud, colisiones y un añadido a los diseños de niveles. El inglés ni lo cuento porque es simple repaso de algo que ya sé.

Pero si miro lo que sé hoy, a lo que sé hace una semana, aunque me sigue pareciendo poco, ya tengo sensación de haber sacado cosillas, y sobre todo, de haber iniciado el viaje y no haber regresado a casa a los dos días, sobre todo cuando las cosas se torcieron y mi ordenador cayó bajo la tormenta.

Si os digo la verdad, me considero alguien que sabe escribir bien en el sentido de escribir sin faltas de ortografía. Pero viendo esto, o no me entero de lo que explica, o sigo sin ver qué es lo que está mal o directamente ya pienso que se equivoca.

De todas formas, todo en la vida es aprender. Escribiendo el blog, me doy cuenta de lo malo que soy y trato de corregirlo intentando escribir de otras maneras y viendo cómo escriben los demás.

Me quedaré con unos cuantos de estos avisos que os copio y pego de los posts de Daniel, en Advertainmen sobre cómo escribir mejor. Id a su web para ver el resto de cosas que no os he puesto aquí.

Continuando con la anterior entrega, os dejo la parte que faltaba:

Personajes
Hay que hacer una lista con los principales, con los jefes finales, con los enemigos normales, con los que son habitantes de una ciudad, con los que podemos interactuar o si jugamos con aliados. Por supuesto también meter los animales. El post de los personajes los tengo en cómo crear un villano y cómo crear al protagonista

Sangrando el contenido de Advertisemen (ni que fuera fan, sólo sanguijuela), saco esta entrada como resultado de esta serie de posts suyos.

En el documento de diseño está toda la información del videojuego, tanto el guion, como el presupuesto, tiempo... Todo. Es una extensión natural del guión, por lo que tenerlo muy detallado, ayuda mucho.

Todas las ideas que tengáis para crear un videojuegos, sacarlas de vuestra cabeza, y escribir un documento de diseño. Las buenas ideas sirven para hablar y dar forma pero no para trabajar. Una idea es brillante en función de lo bien descrita que está.

Y aquí estamos de nuevo querido diario, contándote cuánto camino he recorrido hoy, y con cuántas piedras he tropezado. Y he tropezado unas cuantas veces, pero eso no debería desanimarme, es lo esperado.

Pero aunque me espere los tropiezos y me levante de nuevo, es difícil para mí mantenerme en alto como antes. En vez de eso, me encorvo un poco más, mi ánimo baja un poco y una vez más las dudas asaltan. Esta vez no es si lo conseguiré o no.

A veces, simplemente no tienes oportunidad en el día de coger un libro o estar mirando a una pantalla. A veces es bueno, despejas y disfrutas un poco de la vida (o te cagas en todos los muertos cuando te toca hacer tareas hogareñas).

Pero no me gusta que pase, no porque lo considere tiempo perdido (sólo un poco), sino por el peligro de que se convierta en costumbre y dé al traste no sólo con mi viaje, sino con todo lo demás, ese gran peligro llamado procrastinación (cuesta esta palabreja).

El libro parece ser que es parte de un curso, no he podido saber de cuál, de qué partes se compone ni del orden. Tengo pendiente otro libro que reconocí como parte de la saga, pero tampoco sé mucho más. Quizás algún lector lo sepa, o encuentre la respuesta más tarde.

Habla de la interacción de los jugadores entre otras cosas, los cuales divide en tres tipos; usuario a videojuego, viceversa y videojuego a videojuego. Incluye bastante código de ejemplo, paso por paso bien explicado y con la librería Ogrex (en otra entrada os comento qué es ese bicho). La verdad es que me parece bastante buen libro, de lectura muy recomendada.

Y vamos con un libro más, este es más interesante que los vistos hasta ahora. Hablamos del Desarrollo de Videojuegos; Conceptos Básicos para Desarrollo de Videojuegos 2D.

Sigue siendo conceptos básicos, teoría y nada más. Pero ayuda mucho a tener las cosas claras, meterse un poco en la jerga (¿sprites? ¿blitting? ¿buffering?) y sobre todo, va directo al grano. Son unas 30 páginas y me parece muy recomendable.

Con los videojuegos no sé, pero con programación y con la organización de las carpetas en mi ordenador, sí se me da bien. Paso un poco más a la acción y me he inspirado en una entrada de un blog también prometedor, perteneciente a un programador de videojuegos.

¡Organización! Y para el que le parezca algo inútil, no sabe lo que es tener repartido por ahí tus proyectos y volviéndote loco para buscar algo, no te digo ya cuando tienes que meter los backups y versiones y empieces a tener copias distintas del mismo proyecto por ahí sueltas y no tener ni pajolera idea de cuál es la buena.

Prrrffff... Libro sacado de la libería OpenLibra. Descargué unos cuantos y he empezado por orden alfabético. Resultado: es una tesis que me ha sonado a aburrimiento mortal.

He leído las primeras 50 páginas y echado un vistazo por encima al resto, parece que habla básicamente de lo que representan los juegos, tanto directa como indirectamente, y su impacto en el jugador. Un ejemplo:

Y las dudas asaltan. Información, información y más información... Esto satura y mucho. ¿Cómo lo hacen los demás? Cada historia que leo, cada uno que dice haber estudiado por su cuenta, o no saber nada, ponerse y sacarse un juego pequeño, gente que se lee un tutorial y hace el juego...

¿Cómo lo hacen? Yo me pierdo entre tanta información, e irónicamente me sigue faltando el básico. Veo por todos los lados enlaces de si un foro que te ayuda a programar, tres o cuatro blogs que hablan de cómo hacer uno, diez pdf sobre la temática... Y cada uno de ellos te vuelve a enlazar a otros foros y blogs.

Cambiando un poco de material, he leído este pequeño libro. Se trata del Curso de Diseño de Niveles del Videojuego.

Dicho librito/pdf, es corto, unas 23 páginas las cuales más de la mitad es para un ejemplo. Está bien, tiene cosas interesantes pero he tenido la sensación de quedarme con cuatro frases útiles y para de contar, además de que al principio no me quedaba claro lo que intentaba explicar y el ejemplo más que ayudar/aclarar, empeoraba la compresión.

En todo viaje siempre hay contratiempos. Y el mío llega pronto y ha sido una tormenta.

En condiciones normales, no es algo que me afecte. Voy más o menos preparado para continuar incluso si tengo que dejar guardado y protegido a mi compañero de viaje, el ordenador. Pero en esta ocasión, sufrió.

También aplicado a los héroes y demás personajes, y, cómo no, sacado de la mina de oro de Advertainmen en su post.

El habitual resumen:
Hay que conseguir que al villano se le odie tanto como se le ame, de forma que se quiera acabar con él, pero no hay peor enemigo que el que no quieres derrotar porque le amas, conoces su historia y sabes porqué es malo, te identificas con él.

Seguimos sangrando a Advertainmen con cómo crear al protagonista I y la parte II. Como viene siendo usual, os aconsejo ver los post originales que el tío es bueno escribiendo y yo... bueno, dejémoslo ahí, lo voy a tener difícil para escribir un guión.

El protagonista es alguien con quien el jugador se identifica, por lo que lo primero de todo es asimilarlo a nosotros mismos.

Una vez más de Advertainmen saco unas pequeñas pautas para crear un guión de videojuego digno de estos mundos, concretamente de los mundos que más me gustan, los que cuentan una historia, no los que se lían a tiros y poca cosa más.

Me hago aquí un resumen de lo que nos cuenta:
Un guión de videojuegos tiene dos partes, el storyline de unas 5-8 páginas y el guión detallado que debería tener entre 90 y 120 páginas.

Esto si que me va a venir bien para enterarme del idioma en que hablan estos mundos. Cada uno tiene el suyo propio y si no eres un gran aficionado o no estás metido simplemente terminarás por perderte.

GamerDic es un diccionario online que todavía está en su versión alpha (de lo primerísimo que desarrollan, con muchos posibles bugs) y como cualquier diccionario, te ofrece los significados y ejemplos de las palabras que busques, pero enfocado al videojuego.

Mentira podrida... día y medio, por eso lo siento tan aprovechado. Después del fracaso del día de ayer, hoy noto que he recorrido mucho más camino. Y eso a pesar de haber perdido tiempo en configurar el blog y todavía no haberlo terminado. Es lo que tiene ser demasiado detallista.

Muy interesante me ha parecido la página de advertainmen, con cosas interesantes para mi camino.

De lo primero que he visto ha sido cómo crear un trailer de un videojuego con algunos ejemplos incluidos, y aunque no es algo que me sea útil directamente, tampoco tiene pérdida alguna.

Resumen sacado del pogramador de videojuegos: Proceso de creación de un videojuego

Intro del juego: una buena intro alimenta las expectativas de los jugadores

Personajes: Se definen y enmarcan dentro de la historia, manteniendo la coherencia y la trama. Se definen su aspecto visual, perfil psicológico, habilidades, historia, armas, vehículos...

El hundir la flota en C y con la librería gráfica allegro.

Hay que instalar Allegro con la versión 4 (versión probada allegro4-4.4.2-2), la cinco no consigo compilar. Se compila con gcc -o hundirLaFlota hundirlaflota.c `allegro-config –libs`

Hecho con un simulador MIPS en java que podéis descargar. Si alguien necesita ayuda para ejecutar el código, que deje un comentario.

El código es funcional, faltaría poner un poco de inteligencia artificial (modo difícil) y usar los nombres de los jugadores que se pueden personalizar.

Los barcos enemigos se muestran, lo dejé así para probar si funciona. Si quieres jugarlo de verdad, cambia el uno a cero en la sección del bucle de juego, en la línea 503:
li $a3, 1 #cero si no quiero que muestre los barcos enemigos

Y de momento empezamos bien, con bastante poco camino recorrido.

De los enlaces que os mostré, estuve mirando el blog del programador de videojuegos y la verdad es que terminé un poco desencantado, tiene algunas cosas, con código fuente incluido, pero se me hace demasiado nivel para alguien que no tiene ni idea de nada (renderizado 3D? shiva?).

El viaje será bien duro, horas y horas programando, pero da igual las horas que le eche, si no sé que programar ni qué aprender. Si quiero entrar en alguno de esos mundos, primero necesito saber que son y cómo funcionan, un poco de la teoría de cada uno de ellos.

Con una simple búsqueda de google, empieza a salir muchos resultados, que me temo que unos cuantos es basura, y el resto es… bueno, demasiado material. Os dejo los enlaces que he encontrado hasta ahora y que iré mirando y comentando a medida que me los lea.

Mandos de la play, xbox y otros… listo.
Cuaderno para apuntes del viaje… listo.
Mi peluche para dormir por las noches… listo.
Barritas y bebidas energéticas… listo.

No sé si me sobran o me faltan cosas en esta improvisada mochila, pero