¿Qué tal? Su amigo Ópalo está de vuelta para guiarlos un poco en este extraño mundo del scripting...
O al menos los representaré a la hora de tener dudas de importancia con respecto a cualquier tema.

Empecemos con algo que todo queremos hacer, mostrar una ventana. Será como una de esas de diálogo o de algún menú sencillo que hayan visto ya.


Lo primero que deben de saber es que window significa ventana en inglés. Si lo recuerdan, esto les ahorrará mucho tiempo.

En el Maker, ya sea XP, VX o Ace, necesitamos ventanas para casi todo que pueda mostrar información. La ventana básica es la clase Window. Como el Maker con RGSS 1, 2 o 3 necesitaba hacer ciertas cosas en C o C++, eso no está disponible para nosotros de forma directa. En su lugar nos dejaron otra, a su hija Window_Base.

¿Será que podré salir con ella algún día?

Ejem, volviendo al tema, les cuento que toda clase empieza por lo más básico... ¡DEFINIRLA!

Claro que ustedes ya lo sabían... ¿o no lo sabían?  

Eso se hace de una sencilla manera, llamándola una clase o class. Así como a la gente le llamamos por su título o título nobiliario, así también debemos llamarle al definirla. Como es una hija de Window, debemos mencionarla por igual a la clase madre, porque de esta hereda muchos métodos o elementos para poder funcionar correctamente según nuestras especificaciones y gustos.

Digamos que a la hija la llamamos por su título class, su nombre propio Window_Base y su "apellido" Window. Los términos correctos en inglés son child class, class name y super class.

Código:

class Window_Base < Window

El símbolo menor que < indica ese parentesco, Window_Base hereda de Window.

Es así de obvio.

Bueno será mejor que no lo olviden...  

Ópalo el Scripter escribió:En Ruby una clase se puede abrir y cerrar las veces que queramos, no tiene impedimentos, pero en la práctica jamás se cierra, porque le podemos seguir agregando más y más cosas.

Una vez que llegamos a la siguiente línea, debemos de digitar un medio para despertar a una clon de esa clase hija...

Ahora que lo pienso bien ¡siempre he trabajado con clones!

En fin, debemos crear algo así como nuestro despertador o nuestra máquina para hacer helados o copos de nieves o granizados.

Código:

def initialize(x, y, width, height)

Se me olvidó que no les he dicho qué quiere decir todo eso...

Bueno empecemos con algo que veremos muy seguido, def. El def lo usamos para definir el método o lo que nos permitirá manipular a la clase, en este caso a su despertador o inicialización, en inglés initialization. El verbo en ese idioma sería to initialize así que eliminamos el to y nos quedamos con el resto.

me encanta saltarme las palabras innecesarias al hacer scripts.

Todo método debe tener un nombre y ese será initialize. Este es el único método al que no le podemos cambiar el nombre en Ruby.

¡No, no lo intenten!

¿Recuerdan que dijimos que Window_Base es hija de Window? Esto tiene ciertas implicaciones. Entre ellas está que si la madre necesita ciertos argumentos o valores para despertarse y mantenerse despierta, como quien se toma un café y se atraganta con un delicioso desayuno. En el caso de ambas clases se comerán 4 cosas, que no huelen a café recién tostado, y son...

x, y - Coordenadas cartesianas, x es horizontal mientras que y es vertical.   Siempre empiecen pensando en la esquina superior izquierda de su pantalla o de la ventana principal del maker al jugar. ¡De ahí partimos siempre!

width o ancho, height o altura -   Sí, ya sé que subí algo de peso y que no soy muy alto que digamos, pero eso ejemplifica a la perfección lo que hacemos ahí, engordamos o adelgazamos a la ventana, la hacemos crecer verticalmente o la hacemos enana.

Luego viene otra línea que dice...

Código:

super()

Eso de super significa sobre como que encima de algo. En esta oportunidad es Window quién siempre está encima de Window_Base molestando sin parar...  

Cuando se deja así con paréntesis pegados uno al otro, le decimos a Ruby que no le enviaremos NADA a su madre Window.

Me encantaría decir que somos bien malos con ella.

La verdad es que sí lo hacemos al final de cuentas como a regañadientes.    Se los explicaré más adelante...

Código:

@windowskin_name = $game_system.windowskin_name

Ahí podemos leer una cosa importante, cómo se llama el "maquillaje" que la hija va a ponerse antes de salir a la calle. Es su piel, su skin o windowskin. Como todo debe llevar un nombre, la debemos llamar @windowskin_name.

Sin esa piel no podemos hacer nada útil. Nada.

¿Dónde la encontramos?

Pues es en $game_system.  

¿Qué es eso?  

Digamos que es la parte del sistema del juego que nosotros SÍ podemos manipular. Digamos que nos servirá de esqueleto para mantener armadas varias piezas de nuestro cuerpo makero.

Como no ocupamos a todo nuestro esqueleto $game_system, agarraremos solo una partecita, windowskin_name. Esto quiere decir nombre de la piel del sistema y ahí guardamos el nombre de ese archivo gráfico cuando estamos jugando o probando nuestro juego.

Por cierto, la mía es bien roja con algo de blanco.  

(Cuando manipulamos la base de datos está en otra parte...)

Para indicar que pertenece a $game_system le agregamos ahí un punto . tal como usaríamos "de" para unir un objeto a quien le pertenece en una oración.

Imaginemos que hablamos inglés o japonés y que por eso el dueño va primero y la posesión después.

Como ya la tenemos guardada para uso futuro en @windowskin_name cuando le pusimos el igual = y dejamos todo ese texto al lado, podemos saltar a la siguiente línea.

Código:

self.windowskin = RPG::Cache.windowskin(@windowskin_name)

self es mismo, yo, etc.    Sí, me gusta robar cámara, ¡lo admito!

En este caso nos referimos a la clase hija, Window_Base. Necesitamos darle ya su piel o maquillaje, entonces mencionamos windowskin que la representa y le asignamos un valor, la hacemos igual a algo.

¿De qué se trata ese algo? Pues de lo que nos permitirá llamar al archivo con su piel. Eso es manejado por RPG::Cache.

Digamos que esa es una parte de toda la memoria de nuestro juego, algo así como su memoria fotográfica hecha un cofre o disco imaginario. Es lo que tendrá a buen recaudo nuestras pieles para ventanas y las obtenemos al pedirle su windowskin y especificando cuál de todos queremos, @windowskin_name.

Err, ¿se acuerdan de que dije que la madre Window igual nos iba a exigir cuatro cosas? Pues esas son las cuatro siguientes líneas...

Código:

   self.x = x
    self.y = y
    self.width = width
    self.height = height

No se la dimos desde el inicio, así que nos las fue pidiendo una por una...   Nos dejó sin nada de eso...

Ya le dimos nuestra x, nuestra y, nuestro ancho y nuestra altura. Sí, son las mismas cuatro de antes.  

¿Saben qué es lo peor? ¡Que nos quita una quinta cosa!

Código:

self.z = 100

Esos cien que le damos a z se los va a tragar para salir más lejos que al inicio, en lugar de quedarse en el punto en el que estaba.

z ahí es igual a una tercera coordenada y se utiliza para la profundidad o la cercanía a nosotros los jugadores. ¡Recuerden esto!

Mamá Opalina escribió:¡Ya ve a sacar la basura de una buena vez!

¡Qué queda! A sacar la basura...

Código:

def dispose

Ahí dispose quiere decir desechar, tirar (a la basura). ¿Cómo lo hacemos?

Código:

if self.contents != nil
      self.contents.dispose
    end
    super

if es igual a si condicional y pregunta si su contenido self.contents no es igual != a nada o nil.

Si hay basura o cosas viejas por tirar, entonces vaciamos todo su contenido con self.contents.dispose.

Cuando ya lo terminamos de hacer o lo hace ella a su tiempo, debemos ir a preguntarle a mamá Window si todavía queda más por tirar, de ahí que usemos super para hacer que suceda.

Sí, que se encargue ella del resto.

Ahí no necesitamos los paréntesis () porque damos por un hecho que ella sabe de nuestra basura ya empaquetada. ¡Ya es hora de rumbear para desentendernos del resto!

Cerramos ambos métodos con su propio end o fin o final.

¡Tranquilos, muchachos! Aquí nadie muere...

Ópalo el Fiestero escribió:¡Dejaremos los demás detalles para otra ocasión!

Y aquí les dejo el código un poco más completo, aunque en el maker notarán que existen muchas más cosas.

Código:

class Window_Base < Window
  def initialize(x, y, width, height)
    super()
    @windowskin_name = $game_system.windowskin_name
    self.windowskin = RPG::Cache.windowskin(@windowskin_name)
    self.x = x
    self.y = y
    self.width = width
    self.height = height
    self.z = 100
  end

  def dispose
    # Dispose if window contents bit map is set
    if self.contents != nil
      self.contents.dispose
    end
    super
  end

  def text_color(n)
    case n
    when 0
      return Color.new(255, 255, 255, 255)
    when 1
      return Color.new(128, 128, 255, 255)
    when 2
      return Color.new(255, 128, 128, 255)
    when 3
      return Color.new(128, 255, 128, 255)
    when 4
      return Color.new(128, 255, 255, 255)
    when 5
      return Color.new(255, 128, 255, 255)
    when 6
      return Color.new(255, 255, 128, 255)
    when 7
      return Color.new(192, 192, 192, 255)
    else
      normal_color
    end
  end

  def normal_color
    return Color.new(255, 255, 255, 255)
  end

  def disabled_color
    return Color.new(255, 255, 255, 128)
  end

  def system_color
    return Color.new(192, 224, 255, 255)
  end

  def crisis_color
    return Color.new(255, 255, 64, 255)
  end

  def knockout_color
    return Color.new(255, 64, 0)
  end

  def update
    super
    # Reset if windowskin was changed
    if $game_system.windowskin_name != @windowskin_name
      @windowskin_name = $game_system.windowskin_name
      self.windowskin = RPG::Cache.windowskin(@windowskin_name)
    end
  end
end

M

Excelente, para alguien que no tiene ni idea, le servira de mucho.

Material asi es porque se creo la scene hispana, todo ese ingles esta consumiendo al mundo. Asi que se te agradece el aporte zorro, quizas mucha gente no lo valore, pero yo se cuan dificil es ponerse a escribir una guia.

A mi me da mas pereza que otra cosa xD

Saludos y que orochii te guie.

Muy buena guía, espero que a muchos les sirva, a mi seguro que sí porque soy un asno para lo que se refiere a códigos. Por lo que la voy a tener a mano y repasar a la hora de makear. De hecho puse la página a favoritos por si luego me olvido donde estaba.
Seguro otros además de mi le van a sacar provecho, espero que quien quiera aprender un poco, se tome el tiempo y la dedicación de leer atentamente. Que la gente se asusta cuando ve un poco de texto. Mas está explicado muy bien por lo que puedo apreciar. Así que gracias por el aporte. Al menos a mi me sirve...a ver cuales detalles quedan para la próxima ocasión.

En fin, saludos.

Otra cosa que podemos meter en el initalize o la inicialización de nuestra ventana es el color de la letra o tipo o fuente o font en inglés.

Empecemos por lo más fácil, con el color. Aprenderemos a definir un color.

Es muy sencillo, solo debemos recordar que hay que crear una copia o instancia o clon de Color, la clase que le da más vida a los textos de nuestras ventanas.

¡Qué bien! Ahora podré pintarme de rojo sin problemas.

Código:

Color.new(255, 255, 255, 255)

Eso es le damos color nuevo y 3 o 4 argumentos o parámetros o valores para definir dicho colorcito. Por tradición son Rojo o Red, Verde o Green, Azul o Blue, todos mejor conocidos como RGB en muchos editores como Paint, Kolourpaint, Gimp o incluso Photoshop.

A GraphicGale o como se llame lo dejamos fuera por caerse a cada rato, ¡ja, ja!

Aunque creo que dije que podía haber un cuarto argumento...

¡Es cierto! Me olvidé de que era el alfa o Alpha y que por eso también existe el RGBA.

Si les cuesta entenderlo así, véanlo como un control de nivel de opacidad, 0 para invisible y 255 para 100% visible y no traslúcido. Para traslúcidos pueden dejarlo en algún valor intermedio.

¿Y ahora cómo hacemos un blanco?

Bueno solo debemos definirlo como 255 para rojo, 255, para verde y 255 para azul. Esta combinación nos dará blanco. Cualquier artista digital se los confirmará.

¿Y si lo que quiero es un gris?

Puedes hacerlo como un color, o simplemente cambiar el cuarto argumento de 255 a no sé, 180 o 160 o 120. Con menos opacidad, el blanco se ve grisáceo.

Recuerden que el cuarto argumento de opacidad es opcional si su valor fuera de 255.

No, lo que yo en realidad quería era un negro como el de mis manchitas...

Entonces sería especificar ahí un 0, 0, 0 y ¡listo!

Lo haces sonar como algo muy fácil.

En realidad si lo piensas bien, no es difícil, solo recuerda que esto se va a los extremos. Si todos los 3 dan blanco con 255, lo mismo será negro si les damos 0 a todos esos.

Para un celeste pueden utilizar...

Código:

Color.new(192, 224, 255, 255) o solo Color.new(192, 224, 255)

Para un amarillo puede servirles esto...

Código:

Color.new(255, 255, 64)

Para un rojo sería...

Código:

Color.new(255, 64, 0)

Para un café o castaño...

Código:

Color.new(90, 45, 0)

Sí, muy bonito que podamos escoger el color, pero ¿cómo rayos se supone que se lo doy a un texto?

Bueno, lo siento, ¡no me mates por olvidarlo!

Eso se puede hacer con asignarle ese bonito color a la fuente, como Arial se usa por defecto, no debemos hacer nada por definirla antes.

Código:

self.contents.font.color = Color.new(192, 224, 255)

Y tendríamos un texto en celeste.

¿Será que se me olvidó algo más en esta sección?

¡Caray! No les dije algo importante para evitar un crash fatal...

Antes de asignar colores a font o la letra para nuestros textos, necesitamos un lienzo electrónico y a esto le llamaremos Bitmap o "mapeo" de bits o conjuntos de bits que muestran uno o más colores cuando se juntan. Eso lo meteremos en self.contents donde la clase representada por self mete sus contenidos o contents en inglés.

Lo creamos así:

Código:

self.contents = Bitmap.new(ancho, alto)

Con eso creamos una imagen vacía de relleno con el tamaño que consideremos útil para mostrar todos nuestros textos y quizá otras cosas más por ahí.

¿Dónde nos conviene colocar todo eso de self.contents?

Eso sería en uno de varios lugares.

• En el método initialize
  
• En el método refresh
  
• Opcionalmente en un método draw_algun_nombre
  

Este último puede ser un método que ya exista en Window_Base o incluso uno que nosotros creemos a voluntad. Todo dependerá de si luego de crearlo necesitaremos recrear el Bitmap o no lo ocuparemos. Por lo general se lo suele dejar en initialize en una clase hija de Window_Base, algo así como la nieta de Window.

¡Ya se nos hace grande la familia!

Recuerden que NO conviene hacerle muchos cambios a Window_Base, no la toquen si no saben MUY bien lo que están haciendo. Si se van a embarcar en un viaje desconocido, háganlo en su propia clase. Sería algo como esto:

Código:

class Window_MiVentana < Window_Base

Luego ahí le pueden meter todo el relleno que gusten, siguiendo los consejos de su amigo Ópalo o los de cualquiera otra guía.

También les recuerdo que no olviden definir ahí self.contents = Bitmap.new(ancho, alto) SIEMPRE con el self, o sea la misma clase, para que el script no les dé error.

¿Por qué lo dices?

Bueno es que si no me hacen caso, el script pensara que es una variable local o un objeto momentáneo que puede tirar a la basura cuando termine de inicializar su ventana.

¡Y ahí los veré cómo les suena el cornetazo por hacerlo mal!

self.metodo es una forma de decirle a la clase que busque un método dentro de su lista de métodos y no una variable o nombre descartable ahí mismo.

Les dejo un ejemplo por si acaso más de uno no captó aún a qué me refiero. ¡Así que paren esas antenas!  

Código:

class Window_TempWindow < Window_Base
  def initialize(x, y, w, h)
    super
    self.contents = Bitmap.new(w - 32, h - 32)
    self.contents.font.name = "Times New Roman"
    self.contents.font.color = Color.new(192, 224, 255)
  end
end

Pero ahí veo que también hay una fuente que reconozco, la Times New no sé qué.

Es cierto, antes puedo definirle el tipo de letra de esa manera con self.contents.font.name. Como no ocupamos toda la font no terminamos justo en font sino que llamamos a su método name o nombre en español. Pudo ser "Verdana" o "Trebuchet" o cualquier otra, preferiblemente de tipo TrueType Font o TTF.

¡Momento! Ahí tampoco le dimos nada a la madre, Window_Base, como nos lo dijiste...

Piénsalo mejor, ahí hay un super que automáticamente le pasa todo a la madre.

No era malo preguntar para evitarse congojas después...

Ahora me les adelantaré y les diré cómo hacer que su mensaje salga en pantalla con el texto que Uds. deseen.

Para eso requieren de la ayuda de otro método de Window_Base llamado draw_text.

¡Ya me voy a convertir en artista!

No tan rápido, que solo vamos a mostrar texto, mi amigo grafitero.

Lo haremos así:

Código:

self.contents.draw_text(x, y, ancho, alto, texto, opcional es la alineación)

Esos serían los datos o parámetros o argumentos que debemos pasarle para que funcione. Esto debe servir tanto para XP como VX y VX Ace. Lo que sucede es que estos otros pueden tener métodos más específicos para cosas muy concretas como datos del personaje o stats.

Código:

self.contents.draw_text(0, 0, width - 32, 24, "Olakeaze")

Ese soy yo hablando después de pasarme de tragos o de niveles recomendados de azúcar en la sangre.

Eso imprimiría un texto muy mal redactado del lado izquierdo de su ventana, no de la pantalla. Deben saber que la ventana puede ser colocada en cualquier parte del espacio disponible en su juego.

En XP sería de 0 a 640 de ancho y de 0 a 480 de alto, pero en los otros dos sería hasta 544 de ancho y 416 de alto. Incluso si lo hacen de lo peor, pueden colocarla total o parcialmente fuera de foco o fuera de la parte visible del juego como un -640 para x solo por dar un ejemplo.

Nunca hagan eso a menos que sepan BIEN lo que están haciendo, chicos.

Si suponemos que le dimos un tamaño como el de la ventana de diálogo del Maker, eso se vería así...


O eso nos mostraría F2 si lo presionamos mientras digitamos el contenido textual. Solo tengan en cuenta que ahí no le dijimos que usara colores que normalmente podemos encontrar en la ventana de diálogo y por eso sale todo en blanco.

¿No me creen todavía?

Bueno aquí les va la prueba de que lo que les digo ahora es totalmente verídico.


¿Lo ven ahora? Incluso les probé cómo Alexis es su propio némesis, ni con dos de ellos hacemos un medio.

Aquí les dejo el código.

Código:

class Window_TempWindow < Window_Base
  def initialize(x, y, w, h)
    super(x, y, w, h)
    self.contents = Bitmap.new(w - 32, h - 32)
    self.contents.font.name = "Times New Roman"
    self.contents.font.color = Color.new(192, 224, 255)
    self.contents.draw_text(0, 0, width - 32, 24, "Olakeaze")
  end
end

Peguen esto en un llamado a script desde algún evento activable mediante el botón Aceptar.

Código:

$win = Window_TempWindow.new(240, 80, 180, 64)

Creen un diálogo como el del ejemplo de la manera tradicional ahí mismo y se terminarán muriendo de la risa como yo. Es que me encanta serrucharle el piso a ese pusilánime de Alexis.

Solo recuerden que el Bitmap debe tener 32 pixeles de ancho menos de ancho y de alto que la propia ventana o les saldrán cosas raras.

---

A petición de un usuario les agrego que para ir corriendo un texto a imprimir en pantalla deben de hacer lo siguiente:

Código:

self.contents.text_size(texto_a_medir)

Eso les "proveerá" o retornará un valor, un rectángulo o clase Rect.

Como en todo rectángulo hay un punto de partida x más otro y, además del ancho o width y la altura o height. El de RGSS no es la excepción.

Para convertirlo en el ancho necesitan esto otro:

Código:

self.contents.text_size(texto_a_medir).width

Y obtendrán el ancho o width de ese rectángulo.

Para poder aplicarlo a algún texto predefinido o escogido ahí, es mejor que lo asignen a una variable. Es decir, vayan a igualarlo a una palabra escogida al gusto como aquí:

Código:

ancho = self.contents.text_size(texto_a_medir).width
self.contents.draw_text(ancho, 0, width - ancho, 24, otro_texto)

A que soy un genio escogiendo nombres.

Para ir agregando cosas solo deben sumarle el ancho del siguiente texto a la variable local, que aquí es llamada ancho.

Código:

ancho += self.contents.text_size(otro_texto).width

variable += valor numérico es igual a variable = variable + valor numérico

En palabras simples, es una manera rápida de decirle a RGSS o Ruby según el caso, que vaya y al valor original de nuestra variable se le sume un nuevo valor, o sea, pasamos de 20 a 20 + 16 para que quede en 36 para la próxima vez que la utilicemos.

Pero solo puedo usarlo una vez...

No hay problema con repetirlo las veces que sea necesario, eso bien podría llegar a cientos de repeticiones si es de su gusto.

---

Yo me despido... ¡Hasta la próxima!

En la lección de hoy veremos cómo insertar un ícono en las ventanas que creamos.

¿Cómo cuál sería? No me queda claro...

Pues, se trata de íconos o pequeños dibujos de los objetos que los héroes pueden ir acumulando durante el juego, uno de los más comunes es poción. Para los amantes de Pokemon serían cosas como Baya Ciruela o Caramelo Raro o Super Repelente.

Me haré pasar por un pokemon para hacerme con todo eso.

Sí, qué buen plan, amigo Ópalo...

Para eso iremos al script Window_Base y buscaremos el siguiente método en XP:

Código:

def draw_item_name(item, x, y)
    if item == nil
      return
    end
    bitmap = RPG::Cache.icon(item.icon_name)
    self.contents.blt(x, y + 4, bitmap, Rect.new(0, 0, 24, 24))
    self.contents.font.color = normal_color
    self.contents.draw_text(x + 28, y, 212, 32, item.name)
  end

...o este otro en VX:

Código:

def draw_icon(icon_index, x, y, enabled = true)
    bitmap = Cache.system("Iconset")
    rect = Rect.new(icon_index % 16 * 24, icon_index / 16 * 24, 24, 24)
    self.contents.blt(x, y, bitmap, rect, enabled ? 255 : 128)
  end

En el primero, XP recibe el objeto a utilizar, digamos que es la poción, y las coordenadas x y. Si por error no hubiera ninguna poción ni nada más ( == nil), terminará ahí el llamado sin dibujarnos nada.

¡Esa condenada ventana tan vagabunda!

Presten atención aquí, en bitmap vemos que se le asigna un valor de la memoria, RPG::Cache, muy específico, un ícono o gráfico pequeño, sería como de 24px por 24px. Todos los objetos, las armas y las armaduras tienen un método llamado icon_name o nombre del ícono, un simple texto.

Nada hago yo con eso.

Te equivocas, lo ocuparas muy pronto. De hecho así es como busca el archivo de ese ícono en Icons.

Como ya lo aclaró él, lo busca ahí y lo convierte en un Bitmap, que tiene x, y, ancho y alto.

Si lo recuerdan, sabrán que en self.contents veníamos guardando los textos a desplegar. Ahora le vamos a añadir el ícono utilizando un método especial, blt. Es como una abreviatura de un nombre técnico para describir la transferencia de una imagen a otra en blanco. Como era de esperar, debemos darle un punto de partida x y, además de pasar el nuevo bitmap entero y como último dato obligatorio le damos las dimensiones del rectángulo Rect que deseamos que muestre. Ahí pueden confirmar que es de 24 px.

En casos como estos no hay problema con luego agregar un texto como ya lo veníamos haciendo. Allá arriba pueden ver como le asignamos un color y un texto, item.name o nombre del objeto, la poción. normal_color no es otra cosa más que el color blanco.

No es más complicado que eso en XP.

Pero VX es otra historia...

Allí en draw_icon, dibujar ícono, le pasamos un quinto argumento enabled que define si el ícono se verá normal 255 o algo traslúcido 128.

¡Ay! Mi ventana bebita es glotona como yo.

Los otros parámetros son icon_index, x, y. icon_index simplemente es la posición del ícono.

Siento que sigo en el aire.

Err, se trata de lo siguiente, en VX ya habrán notado que hay no una serie de archivos de íconos como en XP sino uno único, donde se colocaron todos ellos, uno tras otro.

Están tan bien coordinados los pobres que ya quiero ir a sembrar la semilla del caos con una protesta sindical para provocar tumultos.

Buena suerte con eso, mi rojizo amigo...

Como en Ruby y por ende también en RGSS toda posición empieza con 0, como decir el 0 centímetros en una regla, debemos contar cada cuadro desde cero hasta llegar al que deseamos.

Mejor sería dejar que lo hiciera el maker por uno que cansarse haciendo eso.

Y tienes toda la razón, el maker lo hará por nosotros de todas formas. Lo malo es que antes de eso nos hicieron algunos cambios en VX. Ahí el bitmap ya no es igual a RPG::Cache, lo renombraron y se le conoce ahí como Cache.

Al menos es más corto que el anterior.

Otro detalle es que en VX no existe la carpeta Icons. Debemos buscarlo en Systems así Cache.system(nombre_del_unico_archivo_de_iconos), en ese caso simplemente es "Icon Set".

¿Recuerdan toda ese discurso sobre el Rect?

Claro, la parte en la que casi me haces caer dormido.

Perdón... Lo que pasa es que allí se define rect como un Rect nuevo con new.

(icon_index % 16 * 24, icon_index / 16 * 24, 24, 24)

Allí el maker automáticamente recuerda la posición del ícono y la divide entre 16 para sacar el cociente, si no es 0 porque sobro algo entre 0 y el ancho máximo de íconos menos 1, lo buscará en la siguiente columna hasta llegar a la correcta. Hace lo mismo con el eje pero solo lo divide entre 16 y listo, así saca a qué altura (o fila) está.

Se me congeló el cerebro como si hubiera comido un helado muy frío...

Esperemos que se te pase pronto, mi estimado Ópalo.

Una vez que hicimos ese cálculo "sencillo", se lo pasamos a blt en lugar del Rect del XP, ya que la ubicación del rectángulo del ícono en VX es muy variable.

Estoy confundido, ¿qué obtenemos de todo esto?

Err, bueno, resulta que no necesitaban saberlo realmente...

¿Qué cosa has dicho? Nos hiciste perder el tiempo ¡porque sí!

No es del todo cierto, resulta que si les diera algún error, ya pueden tener una mejor idea de cómo es que ocurrió. En especial si no logran ver el ícono y saben que sí es visible en el archivo o sí tiene el tamaño adecuado.

---

Creo que eso era un poco avanzado para mí...

¿Solo un poco? Si tú lo dices, Ópalo.

De todas formas no sé aún qué hacer con eso.

Ah eso se arregla fácil. En XP solo deben agregar un llamado así a su ventana:

Código:

draw_item_name(objeto, x, y)

En VX sería:

Código:

draw_icon(posición_del_ícono, x, y, debe_verse)

Ahí enabled o debe verse es opcional, pueden omitirlo si lo desean y es igual a true o cierto. true es un boolean o valor para verificar la existencia o no existencia de algo, en esos casos los valores deben ser true o false.

Creo que todavía me debes algo.

¿Cómo qué sería, Ópalo?

¡Ah, es cierto! No me lo has demostrado con una ventana.

Disculpa por olvidar ese pequeñísimo detalle, pero justo ahora podemos pasar a esa parte.

Pero apresúrate que no tengo tiempo qué perder.

Esta bién, pero en el caso de XP haremos que se parezca al de VX al hacer nuestra una versión del draw_icon que parece ser tan útil...

Yo ya sabía que pensamos parecido, mi amigo del alma. No tiene nada de malo que nos apropiemos de algo que sirve, ja, ja.

Es todo un honor, mi querido Ópalo...

Código:

def draw_icon(item, x, y, enabled = true)
    bitmap = RPG::Cache.icon(item.icon_name)
    rect = Rect.new(0, 0, 24, 24)
    self.contents.blt(x, y, bitmap, rect, enabled ? 255 : 128)
  end

Y ahora se ve similar al de XP. Si tienen VX, no hace falta que lo hagan a no ser que deseen crear un nuevo método para íconos más grandes o sueltos / separados como en XP.

aquí les dejo la imagen.


¡Pero qué fotogénico soy!

Roba cámaras dirás...

El código correspondiente se los dejo aquí.

Código:

class Window_TempWindow < Window_Base
  def initialize(x, y, w, h)
    super(x, y, w, h)
    self.contents = Bitmap.new(w - 32, h - 32)
    refresh
  end

  def refresh
    self.contents.clear
    self.contents.font.name = "Times New Roman"
    self.contents.font.color = Color.new(192, 224, 255)
    draw_icon('opalo saluda', 0, 0)
    text = "¡Saludos a todos mis amigos foreros!"
    self.contents.draw_text(48, 0, width - 32, 24, text)
  end

  def draw_icon(item, x, y, enabled = true)
    if item.is_a?(String)
      bitmap = RPG::Cache.icon(item)
      rect = bitmap.rect
    else
      bitmap = RPG::Cache.icon(item.icon_name)
      rect = Rect.new(0, 0, 24, 24)
    end
    self.contents.blt(x, y, bitmap, rect, enabled ? 255 : 128)
  end
end

Como podrán notar tuve que correr el texto del saludo para que no le cayera encima a nuestro amigazo de Ópalo.

Es que todo el mundo tiene derecho a admirar mi gallardía.

Vaya, ¡que buen tutorial! Está bien explicado y es fácil de entender para el que no sabe programación, además que la narrativa interactiva con Ópalo lo hace divertido.

Te dejo 




Esperaré con ansias la siguiente lección, por que también quiero aprender programación para juegos.

¡Qué genial!
Ya decía yo que hacía falta un scripter buena onda que se diera la tarea de compartir su sabiduría. Y era cuestión de tiempo para que llegaras vos.
La verdad es que todavía no lo pude leer, por mi falta de tiempo, pero no me cabe duda de que este post merece un
Espero que sigas adelante con este emprendimiento bienaventurado.

Saludos,
Vala.

¡Ah, sí! Yo recuerdo esa serie. Creo que ahí es donde salía la exmujer de Ben Affleck, esa Jennifer Gardner...

Hablamos de scripting, no de series ni actrices.

¡Perdón, mister amargado! Y yo que pretendía prestar atención a la lección de hoy...

¡Cómo sea! El asunto es que este tema ni siquiera es muy gráfico que digamos.

¿Y qué esperas para hacerlo bien gráfico?

Es imposible, mi rebelde amigo, ya que no tiene nada que ver con dibujos ni textos en una ventana del maker.

Y una vez más me quieren hacer quedar como tonto...

En fin, alias es el método que nos permitirá reescribir un método sin borrar su contenido original. Esto sirve para una cosa...

Para aburrirme no más.

Err, no, es para solo agregarle algunas cosillas extras a un método que alguien más haya creado, como pasaría con los scripts por defecto del maker.

¡Qué gran revelación! Los scripts del maker son defectuosos.

Bueno, eso no era lo que quería decir, pero sí, de vez en cuando hay algún pequeño fallo como el de evaluar un script o llamado a script que retorna false y nos manda todo al carajo por no hacer lo que se suponía que hiciera en primer lugar.

Y me volví a entumecer como si me hubiera emborrachado hasta las...

Sí, es mejor que no termines esa frase, mi bebedor Ópalo.

El asunto es que hay momentos en los que le queremos agregar algo al maker sin quitar lo que ya viene haciendo en esa área. Un ejemplo claro sería algo tan simple como darle una edad a los héroes, cosa que no viene en ninguna de las versiones del maker hasta la fecha.

Pondré que tienen 100 años y son todos unos vejestorios, je, je.

No te lo creerán, basta con ver sus caras para descartarlo.

Pero hará que no los dejen entrar porque su identificación es falsa.

Bueno, ahora que lo mencionas, podríamos hacer eso con Aluxes alias Alexis...

Ya envidio a Alexis, va a conocer a mi ídolo televisivo.

No interrumpas más, Ópalo, que por tu culpa casi no hemos avanzado hasta el momento.

OK, ya me callo...

Como les decía, ahora vamos a usar alias en Alexis para asignarle una edad acorde con sus capacidades actuales.

Que son prácticamente nulas, ¡ja, ja, ja!

Pues, ahí sí que no tengo argumentos para contradecirte, je, je.

Entonces iremos a la clase Game_Actor para agregarle el dato de la edad a Alexis y por ende a todos los demás actores también.

¿No habrá manera de que un actor como Alexis me deje entrar a verla a mi Jenny?

Esa serie ya ni siquiera se graba en un estudio de filmación...

Y ahora te atreves a romperme el corachonchito...

OK... les dejo aquí un extracto del contenido de Game_Actor en XP.

Código:

class Game_Actor < Game_Battler
  attr_reader   :name                     # name
  attr_reader   :character_name           # character file name
  attr_reader   :character_hue            # character hue
  attr_reader   :class_id                 # class ID
  attr_reader   :weapon_id                # weapon ID
  attr_reader   :armor1_id                # shield ID
  attr_reader   :armor2_id                # helmet ID
  attr_reader   :armor3_id                # body armor ID
  attr_reader   :armor4_id                # accessory ID
  attr_reader   :level                    # level
  attr_reader   :exp                      # EXP
  attr_reader   :skills                   # skills
  def initialize(actor_id)
    super()
    setup(actor_id)
  end
# más código aquí
end

Si recuerdan las lecciones anteriores...

¡Ay! Cómo no me voy a acordar...

Ahí hablamos de la herencia de una clase de otra clase madre o superclase o superclass, además mencionamos el uso de super y super(). También estaba lo de inicializar una clase con initialize. Bueno, aquí vale todo eso que se dijo en aquel entonces.



Continuemos con la parte del código que nos interesa...

Código:

class Game_Actor
  def initialize(actor_id)
    super()
    setup(actor_id)
  end
end

¡Ahora sí te atrapé haciendo las cosas mal!

¿Mal? Pues no, no hay nada malo, es más es lo que debemos hacer para evitarnos errores. Veras, no es bueno volver a decirle cuál es la clase madre o superclase (Game_Battler), en especial si no nos acordamos de cuál es.

¡Ay sí tú, mister sabiondo! Ahora también me vas a decir que se le pueden meter cosas a Game_Actor incluso fuera del initialize ese del que tanto hablas.

Ya que lo mencionas... sí, se puede y de hecho lo vamos a hacer dentro de un rato.

¡Ahora soy todo un profeta makero!

No es para tanto, Ópalo... Seguimos con incrustar nuestro alias en ese script modificado. Lo haremos justo así:

Código:

class Game_Actor
  alias mi_alias_de_game_actor_initial initialize
  def initialize(actor_id)
    mi_alias_de_game_actor_initial(actor_id)
  end
end

¿Te ocurre algo, Ópalo? Es como si anduvieras perdido...

Nah, estoy bien...

Como pueden ver allí, usé alias con un nombre de método que recién me inventé seguido del nombre original del método, que ahí es initialize.

Y se nota que se te fundió el foco, ¡ja, ja!

Gracias, mi amigo risueño...

El verdadero punto es que no importa cómo lo llamen, casi cualquier nombre es válido para sustituir el contenido original del script Game_Actor.

Y aquí viene la parte en la que le dejo todo el grafiti que yo desee.

No exactamente, mi rojizo amigo. No puedes usar ni un número ni una raya abajo _ al inicio de ese nombre de método. Tampoco puedes repetir nombres con 100% de exactitud, pero si le agregas una letra o un número en alguna parte del nombre, eso también será válido, pero no sería apropiado.

¿No te han dicho que eres un aguafiestas?

Ya perdí la cuenta... Vayamos a lo importante, dentro del método con el nombre de initialize hemos borrado super() y setup(actor_id) a propósito.

¡Y tú me llamas delincuente a mí!

Err, no, eso lo hice para evitar que se repitan partes viejas del código sin necesidad alguna. Sería como ir a darle el número de identificación y la experiencia a una persona pero dos veces seguidas.

En el caso de Alexis ni dos veces bastarían para que lo recordara, ¡ja, ja, ja!

En todo caso lo evitaremos para no atrasarnos y ver por más rato la ventana con un simplón fondo negro al arrancar el juego. ¿Notaron que también le pasé un argumento a mi nuevo método?

¿Lo hiciste? ¡Ah sí, porsupuesto que lo hiciste con (actor_id)!

¡Qué bueno que lo mencionaste! Sucede que si el método original recibía uno o más argumentos, debemos pasarle la misma cantidad de argumentos al alias de ese método.

Ay, es justo como cuando me sueño que le doy de comer a mi bebita con cuchara mientras me mira mi adorada Jennifer...

Pfffft. Mejor no me hubieras contado nada de eso, Ópalo. Ya hasta que me da cosa solo de pensar en eso.

El punto sería que si no le pasamos los argumentos requeridos por el método original, pues, se nos cae el juego.

¡Te aseguro que no vivirás para contarlo! Ni tu ni nadie me quitará el chance de interactuar con mi Jenny virtual en mi juego.

Se los advertía para que no se sorprendan si les llega a suceder, mi celoso amigo.

El siguiente código incluye ya nuestra variable para la age o edad de Alexis y compañía.

Código:

class Game_Actor
  alias mi_alias_de_game_actor_initial initialize
  def initialize(actor_id)
    mi_alias_de_game_actor_initial(actor_id)
    @age = 16
  end
end

¡Y ahora corro a publicar la edad real o mental de Alexis en mi cuenta de tuitersh!

No tan rápido, mi amigo troll.

Ya sabía que no podía ser tan sencillo...

Puede serlo, pero para eso necesitamos hacer un paso más fuera del método initialize.

Código:

class Game_Actor
  alias mi_alias_de_game_actor_initial initialize
  def initialize(actor_id)
    mi_alias_de_game_actor_initial(actor_id)
    @age = 16
  end
  def age() @age end
end

Ahora así con el método definido como age sí podemos publicar su edad a los cuatro vientos.

Lo he estado pensando y creo que no he visto algo así en el maker...

Pues, me alegra que estrenes ese cerebro para variar. Sí, hay otra forma para definir nuestro método age y sería con attr_reader.



Esto necesita que hagamos una pausa de tanto alias y entremos de lleno en los attr_ lo que sea para que aprendan a hacer las cosas más rápido (para Uds. no para la máquina, aunque nosotros no notaremos la diferencia).

Ah bueno, porque ya estaba considerando que te habías ganado una paliza cortesía de tu amigo del alma Ópalo.

O_O Bueno... attr_reader nos sirve para reemplazar la creación de un método como def age. El resultado será este:

Código:

class Game_Actor
  alias mi_alias_de_game_actor_initial initialize
  def initialize(actor_id)
    mi_alias_de_game_actor_initial(actor_id)
    @age = 16
  end
  attr_reader :age
end

Con solo esa línea hacemos lo mismo sin buscar arrobas ni digitar un end específico para el método.

¡Me lo hubieras mostrado antes!

Bueno eso sucede porque automáticamente viene incluido en todas las clases, llámese Game_Actor, Sprite o la que sea.

Aunque eso igual me deja la duda sobre el uso de los otros dos...

Cierto, en el caso de attr_writer sucede esto:

Código:

attr_writer :age
def age=(age) @age = age end

Ambos son idénticos, sirven para asignarle un valor a @age. En otras palabras creamos el mismo método dos veces seguidas...

¿Y cuándo piensas tú que vas a usar la cabeza?

Era un simple ejemplo... En fin, nos queda aclarar el uso de attr_accessor...

¡Yo me la sé! Es para utilizar accesorios, ¿No es verdad?

Para nada, mi ignorante amigo marino. En realidad viene de access o acceso, o sea, nos permite acceder al valor de @age y también darle un valor n cuando gustemos.

Entonces aprovecharé para poner que Alexis tiene solo un año.

¡TE AYUDO CON ESO! Solo mira el siguiente código.

Código:

$game_actors[1].age = 1

Con solo eso ya lo habrías conseguido. Eso sí, para que funcione deberás incluir el attr_accessor para ahorrarte una línea de código. Así debe verse el script.

Código:

class Game_Actor
  alias mi_alias_de_game_actor_initial initialize
  def initialize(actor_id)
    mi_alias_de_game_actor_initial(actor_id)
    @age = 16
  end
  attr_accessor :age
end

Ya con eso y $game_actors[1].age = 1 ya tienes lo que se necesita para pedirle la edad y cambiársela por la que gustes, como el 1 que mencionaste.

¡Genial! Ahora sí que me siento bien respaldado.

Solo recuerda que debes pegar lo de su nueva edad hasta después de haber ingresado en la opción de Nuevo Juego, si utilizas el script Scene_Title por defecto o alguna variante de la comunidad makera.

Pero ni sé dónde ir a buscarlo...

Eso lo puedes encontrar en el editor de scripts, justo en esa clase Scene_Title en el método llamado command_new_game. No olvides usar el alias que vimos el día de hoy y de preferencia coloca la edad debajo de tu nombre de alias del método.

¿Tengo que hacerlo yo solito?

OK, te ayudaré un poco con eso...

Código:

class Scene_Title
  alias mi_alias_de_title_nuevo_juego command_new_game
  def command_new_game
    mi_alias_de_title_nuevo_juego
    $game_actors[1].age = 1
  end
end

¡De la que me has salvado, mi amigo scripter! Eh, y ¿a dónde lo pego?

Pues, podrías dejarlo en una nueva sección del editor DEBAJO de la sección de Scene_Title, no importa qué tan abajo esté la nueva sección.

Entonces ya me puedo despreocupar de cometer errores y ver bugs raros.

Este, eso todavía no es 100% cierto, mi amigo de rojo. Sucede que aún puede aparecerte un bug...

¿Cómo? ¿Pero de qué me estás hablando? ¿Cuál bug es ese?

En realidad ya lo debes de conocer si has jugado algún demo o juego completo hecho con el maker. ¡Es el temidísimo bug del F12!

Ya olvidé la cantidad de veces que he querido meterle una patada al maker por culpa de eso. Si tan solo hubiera una forma de arreglarlo, el mundo sería más feliz.

Bueno digamos que la hay, o al menos es lo segundo mejor que puedes hallar por estos lares makeros. Se trata del $@.

Te seré sincero, NO sé qué esperas que haga con eso.

Código:

class Scene_Title
  alias mi_alias_de_title_nuevo_juego command_new_game unless $@
  def command_new_game
    mi_alias_de_title_nuevo_juego
    $game_actors[1].age = 1
  end
end

Nota cómo lo coloqué en nuestro más reciente alias en forma de una condición gracias a unless. Si lo recuerdan, unless en inglés significa "si no" o "a no ser" y $@ está ahí para que RGSS o incluso el propio Ruby verifiquen si ya creamos un alias con ese mismo nombre.

¿Qué tal si me aclaras por qué lo ocupo si me funcionó antes sin eso?

Es que la primera vez que corres el juego sin presionar el F12, todo sale bien. Incluso puedes guardar la partida y cerrar el juego sin inconvenientes. Lo malo viene si apretas el condenado F12 mientras ya estabas jugando, sin embargo, una vez que colocaste ese unless $@ al final de la línea, ya no debes preocuparte porque salte un error ahí. Para evitarlo en los demás lugares donde exista un alias, deberás verificar que también lo tengan o se lo tendrás que añadir.

No, me da pereza y requiere de mucho esfuerzo.

Bueno, entonces solo te queda sufrir por ese condenado botoncillo...

¡NOOO! Te digo que sí me tomaré mi tiempo para agregarles eso a los molestos alias.

Bien dicho, mi querido amigo.

Comencé leyendo sin darme cuenta que en realidad era un tutorial para hacerlo uno mismo. Antes de hablar del scripting, debo decir que me parece ingeniosa y divertida la forma en la que vas hablando con Ópalo en el trascurso del post, me sacó más de una sonrisa dentro de todo lo tedioso que parecía para una mente como la mía (que poco sabe de programación).

¿Se puede realizar el mismo procedimiento, agregando un "alias" que no tenga un valor numérico, sino texto? No sé, quizás algo con el estado de ánimo que esté relacionado con las respuestas que vas dando en el transcurso del juego (esto último, claro, nos pediría agregar condiciones para que dicho valor aparezca, pero yo solo quiero referirme a que aparezca texto y no números xD)

En cuanto a lo del F12 (mi favorito en su época), no sabía que la solución era simple. ¿Cómo demonios Enterbrain no se dio cuenta de eso?

Bueno su pregunta es algo ambigua.  
No deja claro por qué dice que lo quiere para texto y no para un valor numérico.

Alias no es específico ni para una cosa ni para la otra ni para una tercera, etc. Simplemente es para todo lo que se le ocurra, puede agregar cuantas cosas desee.

Las condiciones es un tema por aparte, también dependerá de lo que realmente necesite configurar para su juego según las variables que requiera agregar y modificar. Vea el alias como una sustitución de método y no meramente de valores o no comprenderá su verdadero uso y su alcance.

Debo agregar que alias es una vía que se inventaron para no tener que pegar todo el código del método original cada vez que uno deseara solo agregar cosas y no quitarle. Lo que pasa es que hay varios motivos por el que se lo puede emplear en uno u en otro método. Sólo les presenté un caso para no atiborrarlos con toda esa información.

Pero te pemiso de atiborrarte de comida, ja, ja!

Es Enterbrain después de todo. No se podía esperar más de ellos.

¿Qué son las Constantes?
¡Pues que yo voy a aparecer en tus tutoriales!

Bueno eso podría ser cierto, pero me refería a cosas como que todos los días debemos respirar para seguir con vida.

En Ruby y RGSS eso se refiere a las palabras escritas con mayúsculas, al menos la inicial.

Las clases y módulos (class + module) siempre tienen como mínimo una constante.
¿La tienen? ¿Acaso respiran como nosotros?

Eh no, no lo hacen, pero no existirían sin una constante en especial, su propio nombre. Este nombre propio debe iniciar con una mayúscula.
Ah, pero si yo no me enojo porque me escriban el nombre como ópalo.

Bueno tú no te molestas, pero Ruby sí lo hace.
¡Condenado gruñón que es Ruby!

Debe serlo por obligación, no por gusto. Es la manera que tiene de verificar que no se trata de una variable o de un método. Es por eso que Window, Window_Base, Window_Help, Window_Item, Sprite, Sprite_Character, Scene_Map, Scene_Menu, entre muchas otras, comienzan con mayúscula.

Así como nosotros necesitamos respirar, Ruby y RGSS necesitan un orden rígido para la nomenclatura de las Constantes que permita distinguir clases y módulos de todo lo demás.
¿Y eso qué importa?

Importa más de lo que crees, es gracias a esa constante que podemos llamar a nuestra clase o nuestro módulo desde donde nos dé la gana.
¡O sea que los podemos llamar a medianoche para molestarlos!

Eh, pues, hazlo a la hora que gustes si te soy sincero. En todo caso también tienen otro uso algo parecido al anterior.
¿Con qué nos vendrás esta vez?

Es sencillo en realidad, las Constantes también sirven para almacenar valores específicos, invariables, inmutables durante el desarrollo de sus juegos. Se mantendrán tan sólidos como una roca.
¿Acaso Ruby piensa filmar una de esas patéticas películas de acción con la Roca?

Ni creo que sepa nada de ese tal Dwayne... Mejor les dejo un ejemplo.

Código:

module MiJuego
  MAX_DE_HEROES_POR_EQUIPO = 4
  NOTA_MINIMIA_PARA_PASAR_EXAMEN = 70
end

En nuestro juego fijaríamos el máximo de héroes a conformar un equipo en 4 héroes. De usar dicha constante en Game_Party, podríamos exigirle al juego que cumpla esa regla cada vez que agreguemos a un héroe via comando de evento.
Sí, muy bonito, pero me enoja que me hicieras recordar mi triste infancia en la escuela con la otra constante.

Ah, lo dices por el 70... Bueno es que hay lugares donde exigen una nota mínima de 70 de 100 posibles. Eso también sería un buen ejemplo de una constante en esos centros educativos.

De hecho, los nombres de las clases y módulos hacen justamente lo mismo pero con todo su contenido, es decir, con sus Constantes, sus variables, sus métodos.

¿Qué son las variables?

Eso me suena a los días en que llueva a cántaros y no puedo salir a divertirme con mis amigos porque salen huyendo del agua

Ahora que lo mencionas, no los culparía por usar la cabeza para no mojarse.

Pero sí, el cambio del clima se podría considerar una variable, ya que no podemos asegurar que todos los días serán cálidos o nublados o lluviosos o tendrán rayería extrema.

En Ruby y por ende en RGSS hay 5 tipos de variables:

• Variable de Bloque - sin símbolo en RGSS, en Ruby 2.x puede ser & en cierto punto del script.
  
• Variable Local - sin símbolo
  
• Variable de Instancia - @
  
• Variable de Clase - @@
  
• Variable Global - $
  

Por alguna extraña razón algunos olvidan varias de estas o nunca las conocieron...
¡Déjalos que vivan en su ignorancia! Capaz que son más felices así que tratando de comprender algo que está fuera de su alcance.

(Como podría ser tu caso, mi amigo Ópalo...) En fin, Empecemos por la más común, la variable local. No tiene ninguna cosa que la identifique más que ser una palabra o varias unidas por _. Su alcance o rango de acción, en inglés scope, es del método que la llamó o el lugar donde la creaste. El 99% de las veces esta se desvanece en cuanto se termina de ejecutar el contenido de ese método.
Pero mi amor por mi Jennifer no se desvanece porque se acabe un episodio de Alias.

Como que nunca lo superarás, mi amigo rojizo... Ahora sigamos con la variable de @instancia. Esta igual tiene un valor dentro de un método que definamos al gusto, pero seguirá existiendo en el siguiente método de la misma clase o mismo módulo. Digamos que se le permite saltar a lo Frogger (el juego de la ranita y los troncos y cocodrilos) para mantenerse con vida. Sin embargo, en cuanto llega al último end que cierra la clase o el módulo, pues, es como que la rana hubiera llegado al otro extremo de la pantalla y se acabara ese escenario.
¡Vaya que debes ser viejo como para haber jugado algo que los jóvenes como yo desconocemos! ¿No habrás jugado rayuela también?

Sí, muy chistosito, Ópalo. Pasemos a las variables de @@clase. Como ven solo se diferencian de la anterior, en lo gráfico, en que tienen no una sino dos arrobas.
Es que esas glotonas tienen dos estómagos en vez de uno como la gente normal.

Bueno digamos que es algo así, ya que existen no solo dentro de métodos sino que también fuera de ellos.
¡Entonces llamemos a los cazafantasmas!


Eh, sí, como los fantasmas pueden traspasar las paredes de las definiciones de nuestros métodos, pero eso es porque debemos crearlas no dentro de un método sino dentro de la clase, fuera de los métodos. Es así:

Código:

class Humor
  @@chistoretes_de_opalo = 0
  def sumar_chistorete() @@chistoretes_de_opalo += 1 end
end

Así cada vez que Ópalo le copie el estilo a Wecocio de contar chistoretes bien malos, le sumaremos 1 a esa variable.

Código:

humor_de_opalo = Humor.new # siempre debemos iniciar la clase

 ¿Qué le dijo un globo a otro globo? ¡Cuidado con el cactusssssss! ¡Pero qué genio soy para contar chistes!

Código:

humor_de_opalo.sumar_chistorete #=> @@chistoretes_de_opalo = 1

Bien merecido se tiene ese punto.

Sigamos con la lección. Ahora hablaremos de la variable $global. De hecho es la más amada por los novatos en el scripting.
¡Claro porque es mi amiga del alma!

Pero no debería serlo, esa variable es una verdadera glotona, como 100 veces más que tú, Ópalo.
¿Cómo?  Ella jamás me ganaría en una competencia para ver quién se come más perros calientes.

Qué saludable dieta... Lastimosamente las variables $globales no tienen ninguna consideración porque una vez que aparecen, no te las quitas de encima hasta que terminas de jugar. Es como tener a tu propio acosador personal echándote su aliento en el cuello a lo Psicosis.
Disculpa que ya tengo que agarrar un tren que me lleve lejos de aquí...

No hace falta, solo debes de evitar que se acumulen, aunque en el maker ya sobran las $globales... Se los advierto porque a muchos les pasó que se quejaron de lag o de tardanza en cargar el juego o de muchas otras cosas y cuando uno revisa el código nota que sobran las condenadas $globales. Como se las puede usar donde sea, la gente simplemente se abusa.
No les tendré compasión a los abusivos.

Qué bien... Bueno nos queda la más rara de las variables, la variable de bloque. Son muy parecidas a las locales, pero son de uso más restringido.
¿Acaso son como los químicos más peligrosos?

No exactamente, lo que pasa es que solo pueden existir dentro de bloques o iteradores como each (o sea "cada (cosa)") o for o times (en español es "veces") o while (en español es "mientras") o until (en español es "hasta"). Fuera de esos bloques "dejan de respirar" y se van al otro mundo.
Pobrecitas esas variables...

La única manera de hacer que vivan un poco más es que no se use una así sino una variable externa como la local, pero casi siempre terminas creando al menos una variable de bloque.

¿Por qué puede ser que la gente olvida las variables de @@clase?

Pues me imagino que se debe a que no las entienden.
Son unas incomprendidas, sé bien lo que se siente.

No son muchas las diferencias entre @@clase y Constante, pero las hay sin duda.

• Las de @@clase son modificables en cualquier momento, las Constantes no deben cambiar nunca.
  
• Las Constantes pueden ser llamadas fácilmente desde cualquier parte sin agregar nada, las de @@clase necesitan que les creemos algún método propio para acceder a ellas. No se cuenta con un attr_ lo que sea como sucede con las de @instancia.
  

La cuestión es que si deseamos sumar los chistoretes contados por Wecocio y por nuestro gran amigo Ópalo, pues, la variable de @@clase nos puede ayudar con eso. 
Con una constante no podríamos hacer eso sin provocarnos serios dolores de cabeza.
Pero si con una variable de @instancia podríamos hacer lo mismo sin problemas.

Casi lo mismo, pero jamás sería igual. Es que al crear una nueva instancia de la clase Humor para que le llevemos la cuenta a Wecocio, se nos reiniciaría el valor, volveríamos a empezar de 0, literalmente. Con una variable de @@clase no nos ocurriría esto porque le pertenece al esqueleto de la clase, no a cada copia de ella.
Entonces las clases ya empezaron a celebrar Halloween ¡desde setiembre!

Código:

humor_de_opalo.sumar_chistorete #=> @@chistoretes_de_opalo = 2

No tenías por qué ser tan sarcástico.

¿Qué es la clase?

Yo sé, es el peor lugar para los chicos que no son populares...


Eh, sí tú lo dices, Ópalo. Yo me refería a que es algo que engloba el esqueleto de algo que podemos copiar una y otra y otra.... y otra vez.

Ya veo, ¡entonces vas a llenar tu barrio con esqueletos para asustar a los más pequeños!

No, sería más como desempolvar la fotocopiadora y rellenar el toner para que le saquemos copia a un formulario, sería útil las veces que queramos usarla para tener pequeñas o grandes variantes entre copia y copia.

Como que las nubes se están arremolinando sobre mi cabeza...


No, estás confundido, pero presta a atención a lo siguiente. Si tienes una receta para hacer una bebida gaseosa, puedes sacarle jugo fabricando un millón de la misma bebida o también puedes sacar diferentes sabores basados en un mismo patrón como que todas sean burbujeantes.

Por supuesto que lo haría, yo me tragaría litros de litros de cola sin ayuda.

De acuerdo, Ópalo, solo ten cuidado con la diarrea

Como ya habíamos visto se crean colocando de primero la palabra class, que es clase en inglés. Ya aprendimos a definir métodos de dos maneras distintas, pero ahora nos ocuparemos de aprender a usarlas correctamente. Para eso nos faltaría un elemento más que nos permitirá detectar mejor cuándo no debemos usarlas o eso no nos conviene.


¿Qué es el módulo?

Espero que no me digas que es el cubículo lúgubre y triste donde muchos como yo malgastamos el día cuando vamos a ciertas clases o a la oficina.

Más bien es una especie de clase recortada, no tiene lo mismo que lo que hay en una clase. Esto sería la carencia de poder sacarle copias.

Ah eso es porque se te dañó la fotocopiadora, ¿no es verdad?

O_o? No, para nada, Ópalo. Es que el módulo no debe copiarse, solo puede haber uno...

¡Oh sí! ¡Genial! Recuerdo con cariño esa serie en la que un espadachín debía batirse en duelo con muchos porque al final solo puede haber uno de ellos.

Eh, sí, solo digamos que ya no hay cupo para más combatientes y solo queda el único sobreviviente con ese nombre en especial...

De hecho en los módulos podemos crear métodos iguales a los de la clase, pero solo si los vamos a incrustar en alguna clase específica.

¡Cómo en un cartucho de super nintendo!


Algo así sería...

Código:

module MiModulo
  def un_metodo
    # Algo de código
  end
# Código va aquí
end

class MiClase
  include MiModulo
  # A partir de aquí ya podríamos llamar a todos los métodos sueltos y a todas las
  # Constantes existentes en MiModulo como si siempre hubieran existido ahí.
end

A este uso de los Módulos en Ruby le llamamos Mixin de Mix e in, mezclar dentro por así decirlo. Generalmente por una variable o una constante no vale la pena crear un Módulo.

Sin embargo no todo es lo que parece en los módulos...

¿Acaso hay algún ultra secreto qué develar en los módulos?


No realmente, es solo que los métodos también tienen derecho a tener sus propios métodos.

No me caen nada bien los renegados como esos, se la pasan en puras manifestaciones de día y en juergas por la noche.

(Me pregunto de quién sacarían la idea...) Lo que pasa es que a veces es útil que los tengan como en el caso de Marshal.

Código:

variable = Marshal.load(archivo) # Carga

Marshal.dump(variable, archivo) # Guardado

De nada nos serviría tener cientos de métodos solo para ocuparnos de lo mismo. En casos así, el módulo es nuestro aliado.

Solo imaginen que en alguna parte de Ruby alguien creó el módulo Marshal y le añadió un método llamándolo Marshal.load o self.load, Marshal.dump o self.dump más sus argumentos en un rincón muy lejano.

Código:

module Marshal
  def self.load(archivo, otras_cosas_inusuales)
    # código para convertir en objetos lo que son bits puros y nada legibles por nosotros
  end
end

Esa imitación de Marshal les dará una idea de cómo crear esa clase de métodos en sus propios módulos. En ustedes queda escoger la mejor opción de cómo usar cada método.

No es recomendable meterse con módulos que ya trae Ruby como Marshal.

¿De veras tenías que venir a molestarnos?


Pero con solo eso no puedo cargar mis archivos, entonces ¿de qué me sirve?

Tranquilo, Ópalo. Para eso solo necesitas agregar un poco más de código como el siguiente:

Código:

File.open('miarchivo.rxdata', 'rb') do |file|
  miprimeravariable = Marshal.load(file)
  misegunddavariable = Marshal.load(file)
end

Nota: file escrito así no es igual a File, las minúsculas y mayúsculas se cuentan por aparte...

Bueno, ya con eso puedes abrir tu archivo personalizado como el de las partidas guardadas.

¡Eso ya es un motivo para arrancar con la fiesta!

(Y llamabas juergueros a los demás...) Pero hay un detalle que deben conocer y que es conveniente como inconveniente a la vez.

Ya me imaginaba que nada podía ser tan perfecto...

Para nuestra conveniencia, en todos los RGSS incluyeron la opción de carga simple de un archivo (cuando contiene un Array o un Hash).

Código:

$variable = load_data("archivo.rxdata")

De esa manera podemos ahorrarnos mucho código, si son tan vagos como para no agregar dos líneas más...

No me quejo. ¡Todo sea por la patria makera!

Es solo que ese se creó para archivos que fueras a comprimir en tu proyecto. Para otros como las partidas guardadas no nos sirve para nada. Ahí no queda más que hacerlo a la antigua y con la paciencia del caso.

Y nos tenías que aguar la fiesta, ¿verdad scripter de corazón de hielo?

Si recuerdan el ejemplo de carga con muchas líneas, ahí pueden ver un buen uso de una clase para algo no tan común para un makero promedio.

¿Yo me acuerdo de eso?


Bueno, File sí se puede necesitar mútiples veces dependiendo de la cantidad de archivos que ocupemos cargar o guardar en disco duro. No siempre lo vamos a echar todo en un único basurero, así como clasificamos la basura por su cualidad de reciclable o no reciclable.

Yo a veces ni me fijo y se me va una lata con los envases de plástico o al revés o igual lo echo todo en una bolsa de cosas ordinarias.

Y eres todo un ejemplo para la comunidad...

Sí, lo sé. Yo soy así de especial.

En fin, deben saber las opciones para leer texto común como en los txt de notepad o notepad++ y las de los archivos binarios o que solo el programa sabe leerlos apropiadamente.

"a" - Significa append o agregar al final del archivo. Puede ser bueno para logs de errores o no...
"w" - Significa write o escribir en el archivo. Es bueno cuando no queremos que se quede nada anterior.
"r" - Significa read o leer el archivo. Es bueno para leer solo los archivos de texto comunes.
"b" - Significa binary o binario. Es útil en combinación con otra opción para guardar o cargar los archivos comprimidos o serializados de RGSS, o sea, los rxdata, rvdata, rv2data.

Y si le ponemos "i" es que se lo insertamos en...

Ejem, por favor ignoren a nuestro acuático amigo. Se los digo por su propio bien scriptero.

Así un combo como el de "rb" nos permitió antes leer un archivo en la carpeta actual y "wb" nos permitiría escribirlo. Si deseamos leer algo en la carpeta Data de nuestro juego, pues, se lo incluimos de una vez:

Código:

File.open('Data/miarchivo.rxdata', 'rb') do |file|
  miprimeravariable = Marshal.load(file)
  misegunddavariable = Marshal.load(file)
end

Es posible usar File.new para crear un archivo antes inexistente, pero File.open es tan útil que en la práctica solo se usaría este.

Como que le robaron las espaldas a new, je, je, je.

Solo queda aclarar una cosa más. Si en cierta ocasión solo ocupan cargar una parte de un archivo con contenido múltiple. que no sea incorporado a la futura distribución de su juego, pueden solo cargar esas mismas partes que requieren e ignorar el resto como si no existiera.

Entonces no siempre necesito cargar todo lo de la partida guardada...

Eso es muy cierto, si lo quieres los nombres de los archivos spritesde los personajes, puedes parar justo después de haberlos obtenido. Digamos que sus datos se guardan como en un Array o una regla que va de 0 centímetros a 100 o más todavía. Ahí el orden es lo que importa.

Ahora sí me la pintaste bien fea porque me encanta ser un desordenado.

¿En serio? No me lo habría imaginado, mi estimado amigo rojizo...

Definiciones No Muy Técnicas

A continuación les aclararé las diferencias entre las cadenas de textos mejor conocidas como strings y los símbolos o symbols.

Yo me la sé, la primera son esos muros de texto que se hicieron tan populares en los foros de la vieja escuela.

O_o? Pues, no me refería a nada de eso, pero sí estaría constituida por una casi interminable cadena de texto donde lo único que hay dentro son caracteres y más caracteres incluyendo los espacios en blanco y los saltos de línea. Las strings en Ruby siempre irán delimitadas por comillas simples ' o dobles ", aunque hay un tercer y cuarto métodos que serían un HEREDOC y un %Q(cualquier texto incluyendo saltos de línea).

Comillas Simples ' '

¡Son los mismísimos bocadillos o tentempies!

Eh, no, solo es una cadena de texto que no permitirá que se interprete su contenido como algo más que su valor nominal o literal, o sea, una a seguirá siendo una a al igual que una @ seguirá viéndose como una @.

Comillas Dobles " "


¿Serán las comidas que te comes normalmente más la que te tragaste por comelón?

No, Ópalo... Se tratan de las cadenas de texto que sí permiten que se interprete su contenido tanto de manera literal como interpolada, es decir, con interpretación o reemplazo de su contenido. Esto suele ser muy útil en casos como las etiquetas que imprimes en los menúes donde el número de pociones varía o no sabes cómo rayos se llamará x héroe luego de horas de juego.

¡Lo hubieras dicho antes! Ahora entiendo que son como los virus, se insertan donde más les conviene y se mantienen ocultos hasta que de pronto ves que no te levantas de la fiebre que te provocan.

Pues, no, no son "tan" malvados esos reemplazos, siempre que no lo hagan via internet o bajando archivos de fuentes u orígenes desconocidos... De contrario no debería de pasar nada así de serio solo por cambiar "#{@variable}" para que salga como "10" o "Este artículo se llama %s" para que con un método especial como sprintf salga "Este artículo se llama Super Poción".

HEREDOC

doc = <<-DISCURSO
Este es solo un simple ejemplo de un discurso sin sentido y exageradamente aburrido.
Lo más seguro es que se caigan dormidos y se pongan a roncar.
DISCURSO

doc = <<-'HORA'
La hora no es lo más importante, aunque ya son las #{Time.now}.
HORA

En el último caso, no hubo interpolación o reemplazo porque se rodeó a HORA con comillas simples, si las eliminan, verían la hora actual y esta se iría actualizando tantas veces como corra el script. Su función es clara, es para texto asquerosamente extensos.




¡Qué curioso! Ópalo no supo qué inventar para desviarnos del tema... En fin, ahora seguimos con... ¡los símbolos!

¡Cierto! El símbolo era un dúo o trío de canciones alegres...

Disculpa, Ópalo, pero no estamos para hacerle propaganda gratuita a agrupaciones que ni se merecen la fama.

Symbol o símbolo en Ruby es todo aquello que comienza con : o dos puntos. Ejemplos de esto serían:

:simbolo :otro_simbolo :"Mi nuevo símbolo"

Los dos primeros son los más comunes, mientras que el tercero es una cadena de texto congelada o símbolo.

En versiones mucho más recientes de Ruby se congelan todas las cadenas de texto al empezar a correr los scripts, aunque no es imposible hacerle cambios a las cadenas.

Entonces ¿para qué se molestan en congelarlas?

Pues, se supone que eso agiliza el cargado y la ejecución del script.


Esto es sencillo en realidad. Las cadenas de texto son modificables por naturaleza, Uds. pueden cambiarlas un trillón de veces si así lo desean. Los símbolos no lo permiten.

Eso de los símbolos me recuerda los tatuajes de mis amigos los pandilleros, no querrían quitárselos por nada.

Bueno ahora que lo dices, podríamos decir que hay algún parecido entre los símbolos y los tatuajes, porque la idea es que no se deshagan ni se boten... :S

Lo único es que las cadenas de texto congeladas o incluso los símbolos normales pueden ser transformados en texto con una simple línea de código.

symbol = :simbolo
symbol.to_s

Eso sí, deben asignar dicho símbolo a una variable con el nombre que deseen darle.

Entonces le pondré :maracuya


Una fruta... Sí, vaya nombre tan descriptivo es el que escogiste, Ópalo.

Otra cosa que deben saber es que en Ruby los símbolos son irrepetibles, o sea, no pueden existir copias de :simbolito, porque :simbolito hay solo uno.

Porque solo quedará un :inmortal ¿no es verdad?

Eh sí, ya solo te falta la cola de caballo y una espada ancha o una katana...

Las cadenas de texto sí pueden copiarse y se las considera como cosa aparte, algo así como que cada una tiene su propio ID. Aun así pueden ser comparadas entre sí y resultar iguales si contienen los mismos caracteres.

Sí, sería algo así como cuando me topo a dos gemelas.

Eh sí, supongo que puede pasarte, mi manchado amigo...

Como última nota les cuento que deben recordar que Ruby no fuerza a las variables o valores a ser convertidas en texto como ocurre en otros lenguajes como Javascript. Para transformar números o símbolos hay que usar to_s como lo vieron en el ejemplo anterior y en el caso de arrays o arreglos o listas se necesitaría join.

Código:

[0, 1, 2].join
"012"

[0, 1, 2].join(" ")
"0 1 2"

Ahí join puede utilizarse sin parámetros o con uno que sea una cadena de texto que irá repitiendo las veces que sean necesarias.

Pero yo quería a mis gemelitas bien pegadas a mí...

Ejem, pues, ni modo, mi amigo Ópalo. La vida es así de dura con todos nosotros.

En esta mini lección de hoy veremos cómo rebajarle algunos puntos de vida o mana o lo que sea que se nos ocurra al eterno idiota de Alexis.

Sería aún más divertido si no fuera porque ese imbécil igual cae en todas las trampas que le tiendan.

Sí, bueno, algunas cosas ya son inevitables.


Como recordarán la forma en que se diseñó la base de datos del XP y otros engines...



OK, como casi todos la recordarán, esta empieza con los valorosos héroes, con la única excepción de Alexis, que defenderán a los desvalidos de los malvados monstruos y políticos corruptos que ponen en peligro las tristes vidas de los NPCs de sus juegos.

Tanto que casi podría llorar en cualquier momento.

Bueno a esos héroes el maker los llamó Actors o Actores en español. Ellos son quienes soportarán tanto castigo como les sea posible para alcanzar su noble meta...

 A no ser que se les atreviese el necio de Alexis con sus discursos pro derechos de los monstruos.

Derechos mis.... Ejem, mejor pasemos a lo que nos atañe hoy.

¿Cómo llamamos a un héroe en el equipo o party?

¿Qué cómo lo hacemos? ¡Pues por teléfono!

=_= Eh, sí, claro... Pero desde el punto de vista del maker eso sería algo más directo y sin conversaciones necias...

Código:

lider = $game_party.actors[0]
segundon = $game_party.actors[1]
relleno_1 = $game_party.actors[2]
relleno_2 = $game_party.actors[3]

Si utlizan el VX o VX Ace, deberán digitar members en lugar de actors. Se preguntarán por qué rayos se dio ese cambio en versiones posteriores a XP.

¡Sí, yo lo hice!

De acuerdo, opcionalmente les dejo aquí la razón tras ese pequeño embrollo. No hace falta que lo sepan...


Explicación dizque Técnica

Y todo se debe a la idiota forma en que definieron los scripts originales, los del XP. En ese tiempo les dio por nombrar a los héroes actors en el script y los miembros de una tropa de malvados y asesinos monstruos members (miembros en inglés). Luego los años los hicieron notar que al tener que procesar cosas comunes y diferentes entre héroes y malvados demonios, era mejor darles un mismo nombre en vez de recordar dos nombres distintos solo para designar a cada grupo. Al final de cuentas ambos se diferencian por las variables globales $game_party (representante oficial del equipo) y $game_troop (agente exclusivo de los monstruos), así que no les afectaba en nada que tuvieran un método con el mismo nombre.


Como ya le asignamos a lider el valor del primer héroe del equipo, podemos usarlo como si fuera un sobrenombre de este en la casilla de llamado a script o en un script personalizado que ustedes crearan con el fin de aprender más de RGSS (1 o 2 o 3). A esto se le llama asignación por si ya no lo recordaban.

Err... Ah sí claro que lo recuerdo, ¡cómo se me iba a olvidar!

Espero que así sea, Ópalo. Ahora querrán saber cómo acceder a sus puntos de vida. Eso es bastante fácil, para representarlos se creó una variable de instancia con un nombre muy corto derivado de la palabra hitpoints o puntos de vida o de daño que pueden recibir. En el caso de lider sería...

¡No lo digas! Déjame que yo se los cuente, es lider.hp

Así es, mi pupilo rojizo. ¡Qué bueno que puedes hablar algo de inglés! Solo no lo relaciones con el insulto y todos estaremos bien.



Esa también me la sé, profe. ¡Se los restamos!

¡Muy bien, muchachito, muy bien! ¿Y cómo se traduce eso a código de Ruby exáctamente?

Tenías que ridiculizarme ante toda mi querida audiencia, ¿no es así, profe?

No es es eso, mi pobre amigo marino. La ignorancia tiene cura y es, pues, estudiar. Aquí les dejo la solución:

lider.hp - 100

Con eso obtenemos el total de puntos de vida de Alexis menos esos 100 puntos.

Ya estamos un paso más cerca de liquidar a ese capirote andante.

O_o? ¿En serio? Y yo que creía que se darían cuenta de que el cambio no se dio, que fue tan fugaz como los fuegos artificiales.

¿De qué me estás hablando? ¿No acabamos de bajárselos de un tajo?

Nope, no lo hicimos, solo hicimos la resta común y corriente pero el scripting no es como hacerlo con papel y lápiz.

Ya sabía yo que esto era demasiado bueno para ser verdad...

Tienes mucha razón, verán que ahí la resta no se guardó en ninguna parte así que desapareció en cuanto el juego la leyó y siguió con la siguiente línea. Incluso si la escribimos así:

nuevos_pv = lider.hp - 100

Igual desaparece en milisegundos. Apuesto que desean hacerlo algo permanente.

¡No tienes ni que preguntarlo! ¡Sólo ve y házlo!

OK, OK, entonces háganlo así:

lider.hp -= 100

Y Alexis ya habrá perdido esos míseros 100 puntos de vida.

En secreto le bajaré como 1000 para salir de dudas.

¿Y puedes explicarme cómo le hice para asegurarme que fuera una resta permanente, Ópalo?

¿Cómo voy a saberlo? Nunca he visto que menos sea igual que otra cosa.

Bueno por lo general tendrías razón, pero eso solo es un modismo de Ruby, conocido como syntantic sugar (probablemente azúcar sintáctico en castellano), para hacer la resta con consecuencias inevitables. Será más fácil de entender si lo ven así:

lider.hp = lider.hp - 100

De hecho eso es justo lo que hace Ruby al interpretar la intención suya de "menos igualar" algo. También podríamos hacer lo mismo con la suma...

¡No lo haré! ¡Ni en un millón de años!

Como quieras... Para aplicarlo a los puntos de magia o mana sería digitando no hp sino sp en XP o con mp en versiones posteriores. tp o Technical Points del ACE igual pueden sumarse o restarse si así lo desean.

Para obtener los puntos máximos de vida, usen:

lider.maxhp en XP
lider.mhp en ACE

Lo mismo se repite para puntos máximos de mana.

lider.maxsp en XP
lider.mmp en ACE

Como ustedes ya aprendieron a sumar, restar, multiplicar o dividir en la escuela primaria, me saltaré todos esos ejemplos y me limitaré a informarles con qué símbolos se representan las dos últimas operaciones aritméticas.

* para multiplicar y / para dividir y como bono les dejo % para el módulo o resto de la división.

Entonces así fue como pudieron crear técnicas como Demi en Final Fantasy que le bajan a la mitad los puntos de vida a héroes como Locke o Sabin.

Sí, así es. Lo hicieron con algo tan básico como aplicar una división a los puntos de vida actuales del héroe en cuestión.

Bueno, amigos, ¡será hasta la próxima!

En esta oportunidad les hablaré más sobre las condiciones porque me he topado a alguno que otro que no está tan bien familiarizado con eso como debería para que obtengan los resultados deseados.

if - significa "si", el que no se tilda y no es afirmación por naturaleza.
unless - significa "si no" o "a menos que"
case - lo podemos interpretar nosotros los humanos como "en el caso de"
¿Y qué? ¿Yo ya no cuento?

O_o? Para nada quise decir eso. Solo se trata de compararlo con algo que los humanos comprendemos por naturaleza porque dependemos del habla para comunicarnos la mayoría de las veces.

Usen if si desean que la condición se aplique como lo haríamos de hablar literalmente.

(Cambien el print que uso abajo por msgbox o msgbox_p si utlizan VX Ace.)

Código:

if opalo.esta_triste?
  print "Pobrecillo..."
elsif opalo.esta_gruñon?
  print "¡Qué amargado! ¡Vaya chupe un limón ácido para que se le quite la amargura!"
else
  print "Ni idea de cómo se sentirá Ópalo hoy..."
end

La gente siempre me desea lo peor...

Solo bromeaba para hacerlo más comprensible, no te lo tomes tan en serio... :S

Por cierto allí elsif alias "o si..." sirve para indicar otra condición con un valor propio a comprobar.

En cambio else u "o" u "o si no" u "o en cualquier otro caso" nos ayuda con cualquier excepción o chequeo que nos falta al dar un valor por defecto o asignar una acción a ejecutarse si no se pudo hacer todo lo anterior.

case no es más que un if que comprueba la identidad de lo evaluado o comprobado con lo que buscamos como ocurre aquí:

Código:

case opalo.edad
when 0,1,2,3,4
  print "Es un bebito."
when 5,6,7,8,9,10,11,12
  print "Es un niño."
when 13,14,15,16,17,18,19
  print "Es un adolescente"
else
  print "Supongo que es un adulto..."
end

Como vemos ahí, case existe porque nos hace más sencillo comparar cosas con valores usando una escritura más sencilla y legible. when se usa para definir cada caso o grupo de casos a evaluar. when significa "cuando" como en "cuando es (igual a)".

También viene otra lección importante, mis jóvenes padawan o aprendices o médicos brujos o doctores en pasantía...
¡Qué va! Yo no pasaba la prueba ni para ser padawan. Me gusta ser demasiado inquieto.

Por qué será que te creo, Ópalo...

Bueno la lección trata de usar algo que por naturaleza no retorna un valor boolean, o sea, true o false alias verdadero o falso. Lo único a tener en cuenta en Ruby y solo en Ruby es que nil también hace de false en esas pruebas, aunque se puede especificar como caso aparte como cuando les hablé de el dispose de las ventanas. Otra curiosidad rubyesca es que en Ruby todo objeto distinto a nil y a false es considerado true.

Sí, hasta evaluar a Ópalo daría true por defecto.
¿¡Quieres decir que soy true porque soy verdadero!?

O_o? Eh sí, supongo que de alguna moteada forma tienes toda la razón.

Código:

if opalo
  print "Es porque soy yo, ¡su inmejorable amigo Ópalo!"
else
  print "Nunca leerán esta línea."
end

Si ya le hubiéramos asigna a esa variable el objeto que representaría a Ópalo, solo veríamos siempre esa primera línea y jamás la primera. Si jamás creamos esa variable y no le asignamos algo, solo veríamos la segunda o nos tiraría error.
Ya te quieres cargar al Maker, ¿no es verdad?

Eh, no, más bien es para que ustedes no lo terminen haciendo.

En Ruby es común llamar a métodos que deben retornar solo un true o false o nil por un nombre terminado en ? como en el caso de los héroes y mostruos con su hp0? que quiere decir muerto?
Tranquilo, siempre te dirá que es falso, estoy aquí vivito y coleando.

No creas que no lo he notado hasta ahora... =_=

Igual se puede comprobar con variables o métodos que llaman a esas variables, pero deben asegurarse de que estas retornan algo. Por lo general las que siempre retornan nil, ya sea con return o return nil no les van a servir de nada. Es que jamás cambiarían su resultado. :S
¡O sea que siempre me verían la cara de tonto!

¿Acaso tenías otra cara?
¡Qué chistosito estás hoy!


Pues, no deberías inspirarme tanto.

Hay gente que crea condiciones así...

if variable == false

o lo ponen con == true o == nil


Les aconsejo que por legible que sea no deben de usarlo porque eso los obliga a ser igual de específicos en los demás casos, o sea, tendrían que agregar o un else para todos los demás casos o hacer otra comprobación con == true y con == nil. No es práctico (ni tampoco muy elegante para pros como ustedes).
Es que genios como nosotros podemos vivir sin tanta palabrería.

O_o? Si tú lo dices, trataré de creerte.
¡Pues harías bien en creerme!

Por cierto debo citar otros datos interesantes.

!= significa !== o "no es igual a".
!variable significa variable == false , o sea, falsa. También se usa para obtener su opuesto en asignaciones.

Código:

encendido = true
encendido = !encendido
print encendido

#=> false

#=> es una simple notación para decirles a ustedes que eso verían en pantalla en una consola o terminal (a lo DOS) o en una ventana emergente. en el caso de nil, su opuesto sería true. (¡Solo en Ruby!)

Nos queda el caso de ? que mencione en el título. No se define solo con ese símbolo, es solo que su nombre completo en inglés es ternary condition y siempre se formatea así:

Ejemplo de la lógica tras el ternary condition:

"variable o método que retorna un boolean" ? variable o método a ejecutar si es cierto : variable o método a ejecutar si no es así

Ejemplo en código:

Código:

print estomago_lleno ? "Estoy satisfecho." : "Sigo con hambre..."

En el caso de nuestro marino amigo, de seguro que la respuesta siempre sería falsa y solo lo leeríamos quejarse del hambre que padece.
¡Qué vergüenza! Pero no puedo evitar que las tripas rujan a cada rato.

Qué pena por ti... En fin, llegó la hora de irnos a comer un emparedado o una empanada o una arepa, así que vete a saciar tu hambre.
Mejor aprovecho para irme a comprarme comida antes de que te arrepientas.

Bueno mientras te vas, recuerda que no uses un método que termine en un bucle for ni each (for loop and each loop) como chequeo de condiciones, a no ser que veas claramente que hay un return con un valor boolean, o sea, true o false.