Articulo: Los limites de la saga Final Fantasy

Introduccion

Hay mucha gente que adora los llamados "Limites" de la saga Final Fantasy, que aunque existieran anteriormente en el 6(algo que no muchos saben) tuvieron mas peso y repercusion tras la VII entrega, las cuales les dio nombre como tales, y desde entonces continuaron en esta gananado popularidad y visibilidad.

Sin embargo, este sistema esta muy lejos de ser perfecto en la mayor parte de juegos donde se incorpora, y es curioso que los mejores juegos a nivel jugable, siendo los clasicos y sobretodo el V, que no los llevaban, o el caso del 6 donde eran testimoniales, son los mas pulidos y balanceados. Suelen estar bastante rotos y desequilibrados en casi todos los juegos de la saga, por desgracia.

Los juegos y los diversos limites
Los ataques de desesperacion del VI no eran muy importantes ya que solo ocurrian en el estado critico de PV de un personaje y tenian una baja posibilidad de hacerlo y ademas solo salian al atacar, aunque fueran poderosos y dependieran de cada personaje. Debido a esto eran mas equilibrados que lo que veriamos luego, pero quizas tambien tuvieron una excesiva poca visibilidad, aunque tambien dependiera de como hubiera haber estado diseñado el juego de base, como era este caso.

En el 7 es donde cobraron mas peso y eran una buena idea pero mal ejecutada, basandose en una barra de limite que se llena segun el daño recibido y habiendo varios niveles de estos a ir consiguiendo. Estos se desarrollan por enemigos matados totales incluyendo aqui los de las magias, sin especializar ni limitar en ese camino como consecuencia, y ademas te dan el turno al tenerlo y se llenan con el daño y son superpoderosos, es como recompensarte por hacerlo mal continuamente, salvandote el culo constantemente, y sin gastar casi recursos para ello y las barras de limite nunca se paraban o se vaciaban.

Ademas debido a su desequilibrio entre el resto de elementos del juego y tal se usaban mucho mas y al elegir entre el estado alterado que afectaba a los mismos, habiendo uno que reducia el daño recibido y el augmento del medidor del limite y la precision y otro que hacia lo contrario, por supuesto, no habia ni por donde pensar que era mejor de usar y se llevaba siempre el estado Hiper, estando bastante mal hecho todo el sistema.

Tras eso se fijo la tendencia de usar limites en la saga poderosos y mucho mas visibles. Cuando salio el 8, se volvio a usar el sistema del 6 en el cual se debia tener baja la vida para que estos te salieran, solo que en este caso la vida no era tan poca, habia muchas mas posibilidades y estos eran mas poderosos y muy variados. Aunque el VII tenia algun superlimite final, aqui se multiplicaron ya desde su temprana aparicion y teniendo algunos aun mas poderosos, como el mitico Summum, que uno perdia la cuenta de las veces que atacaba.

No solo eso se creo una magia Aura que permitia obtener la opcion mucho mas facilmente y con estados de vida altos, aunque sin contrapartida negativa para los mismos tampoco, ademas de que si le dabas a esperar suficientes veces tambien te aparecia el comando de limite tarde o temprano. Con esa combinacion uno diria que el juego seria mucho mas dificil para compensarlo, pero de eso nada, y tampoco lo compensaba que hubiera algun jefazo opcional con montonazos de vida, que estaba particularmente roto vamos.

En el IX se cambio la rutina, si, seguian siendo mas poderosos pero se reduceron bastante. Con el sistema de trance habia una barra que se llenaba por cada ataque recibido, asi que el control o el abuso del mismo no era muy factible desde esa forma de verlo, ademas de incluir el estado zombie el cual eliminaba tu trance por primera vez de forma efectiva. En cuanto a su poder era menor, mejoraba la capacidad de ataque fisico, curaba al personaje y le daba resistencias a los estados alterados, pero tambien duraba mientras te quedara trance suficiente, gastando este por cada accion que haciamos, que tampoco eran tantas.

Tambien permitian acciones especiales, por ejemplo, el mago negro podia lanzar dos magias, habian habilidades nuevas para el ladron mas poderosas, se podia invocar varias veces, el salto de la Dragonera tenia un efecto mas brutal, entre otros casos similares. Sin duda el juego esta mas pulido, quedando entre algo intermedio comparandose con el VI que era mucho mas circunstancial, en este caso tenia mas peso e interes pero sin abusar tanto. Pero tampoco era perfecto, quizas el nulo control estrategico del trance era un poco exagerado y ademas de algun detalle adicional.

Pero sin embargo con el 10 se llego a la cumbre de los limites rotos y poderosos. En este juego se volvia al medidor del VII, solo que ahora podiamos elegir diversas formas de llegar a ellos, como atraves de curar aliados por ejemplo. Teniendo algunos de potencia similar, hay mas que añadir, ya que aqui, se permitia cambiar de personajes en batalla, asi que podias acumular los turbos de cada personaje, aunque no lo usaras tanto o casi y solo lo sacaras para eso cuando los necesitaras.

¿Suena brutal verdad hasta que punto degenero? Pues aun hay mas, si señores, ya que las invocaciones, llamadas eones, podian ser llamadas al combate en si y tambien tenian sus turbos y barras, y de nuevo, podias acumular y usar todos los turbos de los eones, los cuales ademas acababan abundando bastante, pudiendo tener sobre 10 turbos acumulados y luego aun mas, entre estos y los protagonistas. Solo usando esos turbos te cargabas a TODOS los jefazos de la historia principal y unos cuantos de los extra... y aun te solian sobrar. En definitiva, el peor de todos los juegos en este aspecto, clarisimamente.

Conclusion
En mi opinion y como conclusion, creo que los limites son una buena idea pero muy mal ejecutada en casi todos los casos, estando hiper rotos. Los dos casos en los cuales funcionan mejor son el VI y el IX, pero en los dos tienen menos peso, aunque mas en el 9, tambien sin duda alguna y comparten estilo.

¿Se puede crear un sistema de limites mas poderoso y al estilo del resto que funcionen bien y lo hagan de forma equilibrada? Desde luego, se deberian hacer muchas rebajas para que tenga un nivel decente y que luego estos tengan mas handicaps reales y mas penalizacion real al elegirlos.

Pero el problema es que casi parece que no sea esto lo que se busque, sinceramente, el sistema de batalla y la jugabilidad han ido caiendo poco a poco en calidad e interes, y quizas se busca mas una experiencia mas espectacular aunque no lo hayan pensado muy bien, y su resultado sea aun peor.

De todas formas yo creo que si se podrian crear sistemas mas justos y espectaculares, pero sin tanto abusos y 0 pensar tan brutales, tanto para el diseñador como el jugador, claro esta, sin embargo, no se ve ese interes tampoco desde la mayoria del publico, el cual esta mal acostumbrado, entre otras cosas.

Articulo: Como funcionan los atributos en el RMXP y algunos consejos

Introduccion
Este articulo es una traduccion mia del de Crystalgate escrito aqui http://rpgmaker.net/tutorials/532/ y del cual el autor me dio permiso para hacerla. Realmente acaba de aclarar el tema de los atributos del programa de forma mas completa.

Cuando alguien habla acerca de los estados del RMXP, siempre habra alguna respuesta imprecisa. Nunca falla, casi nunca alguien que pregunta sobre los estados no recibira una respuesta imprecisa. La razon para esto es probablemente una combinacion de que los estados del RMXP son un lio y que el manual no ayuda mucho. En fin, espero que este tutorial arroje luz en como funcionan los atributos del programa.

Los estados
ATK:
Este influencia el daño de los ataques tipicos y las habilidades que pueden ser colocadas para tener el daño modificado por este tambien.

El daño medio para un ataque standard es:

Daño = (ATK del atacante  - [PDEF/2 del defensor]) * (20+La STR del Atacante) / 20

El daño puede ser hasta un 15% mas alto o bajo que el medio.
 
El daño medio para habilidades es:

Daño = (Poder de la habilidad + [ATK del atacante*Habilidad del ATK-F/100] - [El PDEF del objetivo*Habilidad del PDEF-F/200] 

- [La MDEF del atacante*MDEF-F de la habilidad/200]) * (20 + [STR del atacante*STR-F de la habilidad/100] + 

[DEX del atacante*DEX-F de la habilidad/100] + [AGI del atacante*AGI-F de la habilidad/100] + [INT del atacante*INT-F de la habilidad/100]) / 20

El daño puede ser hasta el valor del procentaje de variabalidad de la habilidad o menor que la media.

PDEF:
El PDEF reduce el daño de los ataques estandards y habilidades con un PDEF-F mas alto que 0. Para ataques estandard, un PDEF igual al del ATK de los atacantes reducira el daño a la mitad(ignorando el redondeo que ocurre si el PDEF es un numero raro) y si el PDEF es el doble que el ATK de los atacantes se negara por completo el daño. Con esos dos ejemplos como guias, tienes que ser capaz de estimar el daño que el PDEF tendra con otros valores.
 
MDEF:
La MDEF reduce el daño de las habilidades con una MDEF-F mayor que cero. Normalmente, eso significa hechizos pero el RMXP no te fuerza a solo eso. De todas formas si designas las magias como las default, una MDEF igual al Poder de la habilidad reduce el daño a la mitad(ignorando algun redondeo) y una MDEF que sea el doble que el poder de la magia nega completamente el daño.

EVA:
La EVA influencia las posibilidades de evadir ataques fisicos y habilidades con un EVA-F mas alto que cero. Para ataques estandard la posibilidad de evadir es (8*AGI del objetivo/DEX del atacante + EVA del objetivo).
Para magias, coge esa posibilidad y multiplicalo por el EVA-F de la habilidad y dividelo por 100.

Normalmente las posibilidades de evadir ataques standard es de un 5-10% mas alto que el EVA.

STR:
La STR influencia el daño standard de ataques y habilidades con una STR-F mayor que cero. Mira el ATK para la formula exacta. Notad que el daño que hace es proporcional al STR+20, asi que es mejor pensar en que la STR como si fuera 20 puntos mayor que como es en realidad cuando comparamos cuan poderosos son los personajes, especialmente si usas los atributos bajos.

DEX:
La DEX afecta a la precision de los ataques fisicos y de habilidades que tienen un EVA-F mas alto que cero, la posibilidad de tener un ataque critico fisico y tambien afecta al daño que hacen las habilidades con un DEX-F mas alto que cero.

Comprueba la EVA para ver como se calcula la posibilidad de evadir. Nota que mientras la DEX afecta a cuan preciso eres, lo hace bastante mal. Teniendo una DEX elevada reduce la cantidad de AGI del objetivo que influencia la evasion, pero no cuanta influencia tiene la EVA en ella. El problema es que usualmente la EVA tiene la mayor influencia en la evasion. Tal como esta montado, si tienes que hacer un ladron con un 80 de DEX y un luchador con 40 de DEX, el jugador no va a apreciar que el ladron es mas preciso.

Las posibilidades de tener un ataque critico son (4* La DEX del atacante/AGI del objetivo). Esto solo funciona para ataques standard.

Normalmente, a menos que crees habilidades basadas en la DEX, es atributo es bastante flojo.

AGI:
La AGI afecta al orden del turnos, a las posibilidades de evadir ataques y habilidades con un EVA-F mayor que cero, la posibilidad de sufrir ataques criticos, la posibilidad de escapar en batalla y ademas afecta a las habilidades con una AGI-F mayor que 0.

El orden  de los turnos es la funcion mas importante de la AGI. El orden es decidido cogiendo la AGI del personaje y añadiendo un valor aleatorio que va del 0 al (10+AGI/4)-1. Nota que si vas pensando en usar bajos atributos, el 10 en la ecuacion vuelve el orden de los turnos muy aleatorios. Un truco que puede usar es añadir 40 a la AGI actual de los personajes y compararlas. Entonces, si un personaje tiene una AGI de 1 y otro de 2, piensa en ellas como una de 41 y 42, asi evitas esa aleatorizacion excesiva.

La posibilidad para causar o sufrir ataques criticos esta influenciada por la EVA y la DEX. De todas formas, no pienses en que ninguna de esas funciones añada mucho valor al atributo AGI.

La capacidad de escapar es de (50* media de la AGI de los personajes/media de la AGI de los enemigos).

INT:
La INT afecta al daño de las habilidades con una INT-F mayor que 0. Tipicamente, eso significa que lo que hace la INT para los magos es lo mismo que la STR para los luchadores.

Consejos para crear los atributos
El primer consejo es: no uses bajos atributos. El algoritmo no esta penasado para eso como en los mas antiguos. Teniendo 5 STR en vez de 3 no tiene casi ningun efecto en comparacion con lo que hace una STR de 50 envez de 30. Ademas el orden de los turnos sera muy aleatorio, un personaje con una AGI de 40 es siempre mas rapido que uno de 20, pero con unos de 4 vs 2 no se nota apenas quien es mas rapido.

El segundo consejo es que no dejes a la MDEF crecer demasiado rapido a menos que tengas un monton de magias de calidad. Pon que en el inicio un enemigo tiene 10 de MDEF y al final 200. Los personajes deberan entonces augmentar su mejor hechizo rapidamente, posiblemente despues de cada mazmorra. Si haces la PDEF augmentar rapido, los personajes tendran una necesidad de actualizar sus armas rapidamente, pero tipicamente es mas sencillo de darles nuevas armas en cada pueblo que nuevas magias. Hay formas de sortear este problema, pero si conoces como van, no necesitas estos consejos para empezar.

Finalmente la EVA no escala como otros atributos. Un accesorio que da +10 STR es mas valioso al principio cuando tienes 30 de ella, que al final con 150 por ejemplo. Eso pasa con todos menos la EVA, 30 eva te hace tan evasivo en el final del juego como al principio.

Conclusion
Es muy tipico que los juegos no tengan los estados creados de forma adecuada. Piensa un paso mas alla de "Si quiero hacer un ladron mas habilidosos que un luchador, entonces le doy un 50% de DEX adicional" y considera tambien los efectos en las mecanicas que van a tener tus decisiones.

Articulo: Sistema de guardado

Introduccion
En un videojuego el sistema de guardado es vital para que este funcione como es debido. En general hay bastantes opciones entre las que elegir, pero es cierto que hay algunas opciones e ideas que son imprescindibles en un juego. En este articulo hablaremos sobre el guardado y su historia en general y como es mejor o peor a la hora de implementarlo a la hora de crear un videojuego.

Los sistemas de guardado penalizadores no son fruto de limitaciones tecnicas
Años atras, los juegos no solian incluir el guardado, tanto los arcades de recreativa, como sus versiones para consolas o ordenadores, o la enorme mayoria de juegos que eran por el estilo o que no lo necesitaban, los cuales eran obviamente la enorme mayoria de ellos.

Las excepciones eran unos pocos generos en los ordenadores como los rpg, simuladores o aventuras, asi como los sistemas de passwords en consolas, los cuales tampoco eran muy extendidos, y permitian continuar los juegos desde cierto punto del juego poniendo una combinacion de simbolos o imagenes.

No fue hasta la llegada del Zelda de NES en 1986 el cual permitia entre otras revoluciones el poder guardar partida gracias a su chip con pila que tenia el cartucho, aunque siempre reempezabas desde el mismo punto del mapa o de la mazmorra. Hay quien piensa que los sistemas de guardado prohibitivos y penalizadores son cosa de limitaciones tecnicas pero nada mas alejado de la realidad ya que estos son muy posteriores a juegos donde se permitia en cualquier lugar.

Por ejemplo, desde casi sus inicios en el genero RPG en PC ya existia el guardado en cualquier lugar(Wizardry II en 1981, el primero tenia guardado prohibido en las mazmorras), sin embargo cuando salio Dragon Quest en 1986, el sistema que usaba era de prohibir el guardado tanto en mapamundi como mazmorra y de que al morir conservabas inventario y experiencia pero perdias la mitad del dinero y volvias al punto de guardado. 6 años despues salio este sistema, da un claro ejemplo de que no tiene nada que ver.

Ademas 1 año despues saldrian el primer Final Fantasy y Phantasy Star, en el primero no conservabas nada y no regresabas atras al morir y el segundo permitia guardar en qualquier momento, aunque en este caso es entendible ya que es un juego con mucho de aventura y laberintos de horas en primera persona larguisimos donde no importa tanto este punto, aunque tampoco haya que abusar, pero sirve como clarisimo ejemplo de lo dicho, aunque hoy en dia quizas pondrian un sistema de guardado rapido, del cual hablo mas tarde.

En fin queda claro que no esta relacionado una cosa con la otra, de hecho hoy en dia se conservan aun algunas mecanicas de esos juegos para bien sin duda.

Diferencias entre tipos de juegos
Cuando jugamos a un videojuego como es un arcade tradicional(el tipico juego de 20m-1h) es muy evidente que no se necesita de guardado ya que en su formula de juego no vas a necesitarla, puesto que son juegos muy cortos con jugabilidades intensas y grandes dosis de penalizacion y sistemas de guardado prohibitivos.

En cambio si hablamos de uno moderno para comparar, se ha de decir reconocer que hoy en dia la formula de juego ha cambiado mucho, siendo aventuras muy largas y en las cuales se deben distribuir los segmentos jugables bastante mas espaciados, pero aunque a la vez, no augmentan en complejidad o interes ni dificultad(o estando en los extras o niveles de dificultad), de todas formas, es evidente que no se puede grabar en cualquier sitio porque sino el juego pierde la gracia y reto en casi todas las ocasiones.

En cuanto al ordenador se ha de decir que desde siempre ha tenido sistemas de guardado abiertos y donde poder guardar en cualquier sitio pero tampoco es que sean masivos ni nada asi y sobretodo ha pasado en unos generos, e incluso en estos hay una mezcla, no es extrapolable a todo, y aun asi se podria poner mas guardado prohibido combinado con el guardado rapido.

Repeticion y guardado
Los videojuegos basan su jugabilidad en la memorizacion por parte del jugador de niveles, enemigos, controles, habilidades, etc, etc, que formulan los videojuegos. Cuando uno se enfrenta a una situacion en un juego, la esta estudiando, y asi podra superarla, tanto quizas en esa ocasion como en la siguiente. A esto algunos le llaman anticipacion, es decir, saber de antemano que va ocurrir y poder solventarlo.

La anticipacion es esencial para que un videojuego funcione bien, tanto al jugarlo como al diseñarlo. Por eso se muere o se repite desde un lugar u otro en los juegos, y se debe hacer que el sistema de guardado funcione en consecuencia a esto. Casi nunca vas a necesitar guardar en cada tramo, pero sin embargo, si es necesario de poder hacerlo cada unos cuantos tramos, quizas sea al final de un conjunto de tramos, al terminar un nivel o un conjunto de niveles, dependiendo de la estructura del mismo. Tambien se debe pensar en torno a que estilo o genero pertenece, claro esta.

Un juego como el primer Crash Bandicoot(plataformas 2,5d) por ejemplo es el mejor de su saga de PSX, debido a que es el mas dificil y acertado, ya que el sistema de guardado va por conjuntos de niveles, debes conseguir un extra en los niveles sin perder vida y usa la misma formula siempre. En el 2, aunque mas pulido en algun detalle, se guarda en cualquier momento y se permite morir en los secretos, resultando asi ademas mucho mas corto. El 3, siendo mas largo que el anterior gracias a incorporar un secreto adicional equiparandose al primero tiene el problema de tener excesivos niveles variados que no son tan buenos como los clasicos. Un buen ejemplo de como el guardado y dificultad afectan a un juego.

Guardado Rapido
Para mi esta opcion deberia implementarse en todos los videojuegos, pero sin embargo no se ve casi nunca y eso que es muy util. Este sistema permite guardar en cualquier momento con la condicion de que cuando vuelvas a poner el juego este te obliga a cargar la partida de forma automatica y entonces el guardado se borra.

La ventajas de esto son evidentes, y es que permite tanto guardar cuando lo necesitemos, aunque estemos en una zona en la que no debamos hacerlo normalmente, por si nos cansamos o debemos dejar el juego por cualquier necesidad o urgencia, y a la vez mantiene la dificultad y el diseño de juego ya que realmente no podemos cargarlo 2 veces.

No hay muchos ejemplos de juegos que posean este sistema por desgracia, y la mayoria son rpgs donde es normal este hecho al ser largos asi como algunos juegos de consolas portatiles. El Unlimited Saga, o Final Fantasy 3 DS tienen este sistema, existiendo en unos pocos juegos mas para portatiles.

Sin embargo, esta opcion deberia estar implementada por defecto porque aporta a todos los videojuegos sin quitar nada, y aunque se pueda hacer trampa segun como, quien quiera hacerla lo hara con todo el sistema en si, asi que eso no vale tampoco como excusa. Tambien seria valido para arcades cortos, puesto que aun siendo mucho mas limitados en el tiempo requerido, se puede dar la situacion tambien.

Si usas el rpgmaker 2000 o 2003 para crear videojuegos no puedes hacer este sistema por engines de ninguna forma ya que no hay opcion de poder eliminar el guardado desde los eventos ni de cargarlo de forma automatica, si puedes detectar si se ha guardado la partida o no con interruptores pero no puedes cargarlo.

Desconozco si se puede con parches y tal aunque pienso que no, ya que modifican la estetica del sistema de guardado. En general se puede poner un sistema de guardado abierto permanente en estos juegos, avisar de que no se abuse y decir cuando se deberia de guardar, pero es complicado y molesta esta opcion tambien.

Con el XP en adelante si se puede con los scripts y de hecho ya existen varios por ahi para todas las versiones que usan Ruby, y de hecho yo tengo creado un script de guardado llamado Guardado Mejorado/Improved Save, que permite esto entre muchas otras cosas.

Autoguardado
Este sistema se basa en que el guardado se haga de forma automatica siempre que el jugador lo pueda hacer de forma normal y manteniendo el guardado manual(o pudiendo desactivarlo), de esta forma se ahorra tiempo y se evitan despistes tontos por parte del jugador. Puede ser mejor de tener una ranura de guardado unica y separada para este tambien para evitar problemas.

Sin embargo hay veces en las cuales quizas no querremos usar este sistema, por ejemplo, en los jrpg es tipico que en las iglesias o posadas se guarde partida. Esto es un detalle interesante pero a la vez hay el dilema de si compensa o simplemente podriamos dar el guardado permitido en toda la zona ya que el pueblo en si es un lugar seguro. El problema es que entonces se pierde un poco de ambientacion, tambien se pueden poner las dos cosas. Y hay algunas otras situaciones similares en varios aspectos mas.

Este sistema tambien puede estar calibrado por tiempo pasado o cada turno si el juego lo permite y es muy largo, como por ejemplo, algunos juegos de estrategia, se debe poner la opcion ahi.

En fin que es otra buena idea de diseño en general ya que el juego en si funciona bien en casi todos los juegos, aunque en los mas cortos probablemente no ya que no es como el anterior caso, no tiene interes en este caso en la mayoria de ellos.

De nuevo es imposible de hacerlo en el los rpgmaker antiguos y se han de usar scripts de los actuales, en mi Guardado Mejorado tambien esta la opcion.

Mi opcion
Yo en los videojuegos que creo no permito el guardado mas alla de los puntos de guardado asi como alguna pequeña excepcion. Aun asi, la formula varia, pero nunca permito el guardado en todos los lugares, ya que pienso que esto añade mas reto, tension e interes al juego, aunque use el guardado rapido siempre para mejorarlo, pero mantengo el autoguardado fuera por razones de ambientacion por ahora almenos aunque lo tenga programado. Pese a todo se que hay momentos donde se debe usar, pero no son los generos que creo por lo general, aunque si tenga alguno de estrategia en marcha.

Sin embargo tengo un proyecto que esta mas basado en los 8 bits donde este funciona como en los Dragon Quest, conservando la experiencia y tal y perdiendo la mitad de dinero y solo guardando en las iglesias, pero lo he mejorado y refrescado, habiendo objetos que poder cambiar en vez de per en vez del dinero, entre otras cosas.

Tambien es destacable la idea que tuve para los jefazos y es que en el juego se te muestra un menu antes de estos permitiendo guardar, ir al menu, combatir o rendirse y morir y volver al punto inicial. De esta forma, pese a ser un juego mas enfocado a solventar la mazmorra en si, el juego permite que haya mas juego con los jefazos a pesar de mantenerse el estilo original, siendo estos mas complejos y dificiles que en los juegos tipicos de este tipo.

Conclusiones
El sistema de guardado prohibitivo y penalizador es esencial en el videojuego y en general es muy recomendable de colocarlo en estos cuando los creamos practicamente siempre y dejando de lado algunos detalles. Tambien queda bastante claro que no es una limitacion tecnica. Finalmente se ha de añadir algunos detalles como el sistema de guardado rapido o el autoguardado cuando sea necesario, aunque este ultimo lo sea un poco menos.

Tutorial: Convertir juegos del 2k3 al 2k.

¿Tienes algun juego que por alguna razon quieras pasar del 2k3 al anterior rpgmaker? Pues si que es posible, yo lo he necesitado hacer y escribo esto como guia para quien lo necesite o lo que sea, pero se han de hacer algunas cosas adicionales:

1-Convertir el proyecto y reasingar recursos:
Abrir el proyecto del rpgmaker 2003 con el 2000 y guardarlo como tal, habiendo cambiado el ejecutable e ini de una carpeta de proyecto a otra. Si lo ejecutas ahora veras que es muy posible que los graficos se vean negros y te de errores, ya que hay algunos recursos del anterior rpgmaker que tienen nombre distinto, sobretodo los del rtp. Lo que deberas hacer es reasignar los archivos de nuevos en la base de datos, tanto en los tilesets, charas, enemigos, sistema, y en algunos eventos quizas.

2-El bug de los objetos:
En condiciones normales los objetos usables en combate salen antes que el resto pero por alguna razon el orden sale mal la mayoria de las veces cuando conviertes el juego. La solucion es si crees que te molesta mucho crear nuevos objetos por debajo de estos y luego ir rehaciendo los objetos, copiando textos y tal pero colocandolos en posiciones nuevas sin bug.

3-Problema con los textos del sistema:
Unos pocos de los textos de la parte de vocabulario del rpgmaker se convierten en textos raros. Deberas reescribirlos.

4-El bug de las curvas de atributos:
Al trasladarse las curvas de atributos de los personajes al nuevo juego estas estan bien en principio pero tienen un problema de fondo, que cuando intentes cambiarlas se buguean, quedandose en un punto estancado la curva y sin poder adaptarla al nuevo sistema.

Para esto necesitaras crear espacios de 0 ampliando la lista con espacios limpios. Luego coge un sitio y ve copiando todo lo que tiene el que esta bugeado. Cuando acabes solo deberas copiar el personaje que acabas de crear en la posicion que ocupaba antes. Nota que yo respalde los personajes bugeados por si acaso en otras ranuras.

5-Rebalancear el combate y otros detalles:
El juego tiene algun problema al equilibrar algunos detalles, por ejemplo, ahora la agilidad es menos util ya que solo influencia en quien empieza el turno practicamente. Tambien tendras que modificar algunos valores y alguna que otra opcion que desaparece como los eventos comunes en combate y algun otro comando o forma de activarlo, tambien los estados alterados no permiten bonificadores a los atributos, entre otras cosas. Finalmente deberas reasignar algunos condicionales en los grupos de enemigos principalmente.

Tutorial: Trucos o consejos al makear

Ahi van una lista de consejos a la hora de crear videojuegos con el rpgmaker que yo uso normalmente:

-Haz los mapas poco currados de forma temporal al principio, asi si lo has de cambiar luego no pierdes tanto tiempo. Yo solo defino el perimetro en lineas y luego lo voy modificando de forma escalada.

-En el XP/VX/Ace si estas editando scripts o la base de datos por un rato decente, sal y guarda el proyecto cada X rato. No seria la primera vez en la cual se me cuelga el ordenador y veo como al darle a a "aplicar" no guarda los datos realmente, lo has de hacer manualmente.

-Sino has de estar por un rato largo con el maker encencido pero sin usarlo, puedes cerrar el programa ya que si se cuelga o algo el proyecto se puede corromper. Esto pasa mas con el 2k, y aun sin que se cuelgue.

-En el XP y supongo que en el resto de modernos has de salir y guardar para testear las modificaciones del combate. Suele pasar que falle si solo guardas una vez, a veces necesitas multiplos guardados para cambiarlo, o incluso hacer saltar un combate. Nota que esto pasa con toda la base de datos. Al final es mas comodo de testear en muchas situaciones si coges el juego y creas un mapa para testear combates con un evento automatico en el que iras cambiando.

-Una guia del juego bien hecha esta bien para ayudar a balancear y pensar la jugabilidad. La guia puede ser muy precisa, mucho mas de lo que la harias normalmente, y simplemente la simplificas al ponerla en la version final o la quitas.

-Es muy util hacer un prototipo corto inicial para testear todas las mecanicas e ideas de tu proyecto. Lo puedes hacer aunque incompleto y mal mientras piensas el juego y diseñas.

-Procura hacer copias de seguridad de tus proyectos. Es util de subir archivos a un pendrive o a internet de tanto en tanto, yo uso gmail enviandome correos, pendrive y dvds, y hago cada x horas o dias en el propio disco.

-Deja espacios en la base de datos y pon etiquetas para que quede ordenado.

-Haz mejor los mapas en pequeñas partes siempre que puedas porque luego son mas faciles de quitar o retocar.

-Escribe tus ideas y piensa algo tu proyecto usando un documento de diseño. Como mas bien lo diseñes mas problemas te ahorras, un cambio de idea en un documento de diseño es borrar una linea, cambiarlo en un proyecto, pueden ser muchas horas...

-Usa el gemini script editor para editar scripts mejor, tiene autocompletar, pestañas y otras cosas, pero tambien tiene algun bug.

-El editor de scripts del maker si puede reemplazar en un texto seleccionado. Pero es automatico, con que tengas seleccionado algo, se hara todo de forma automatica alli.

-Revisa el manual, y los iconitos de ayuda ?, suelen llevar informacion util.

-Al hacer escenas muy largas dividela en varias paginas que se activen con distintos switchs y queden encapsuladas. De esta forma podras ir a una parte en concreto mas rapido y ahorrar tiempo.

-Los eventos comunes son muy utiles para ahorrar trabajo. Por ejemplo los uso para hacer los inicios y finales de las escenas con el cambio a negro para hacer desaparecer los personjes. Aqui entra a tu gusto pero automatiza al maximo los eventos, la gracia es que los puedes cambiar luego y el propio evento cambia en todos en los que los llames en vez de tener que ir haciendolos a mano.

En el 2k no hay en combate, deberas hacer primero un grupo de enemigos en el cual salen todas las paginas enemigas y luego usarlo de base para todos los demas. Yo uso una pagina para poner las variables, si se usan, y es util de tener un interruptor de testeo o no, para poder hacer que en un combate cualquiera que estes balanceando rapido

-Es utilismo de usar o ciclos o condiciones y eventos simples para encapsular codigos largos por partes, por ejemplo, una larga cadena de dar de objetos en algun momento del juego, pongamos mas de 20, si los tienes agrupados dentro de un condicional, los copias en un click copiando todo el condicional y sino pues nada. Yo uso aqui un interruptor que se llam siempre on o off, y que es el 0000, por comodidad.

-Un consejo sencillo para el lag y los engines, poner un esperar 0,0 segundos al terminar un proceso paraleo o automatico de esta forma, se ahorra mucho rendimiento, dando un respiro.

Tutorial: Usar graficos de baja resolucion en los nuevos rpgmakers

Nose a vosotros pero nunca me ha gustado el RTP de los nuevos ni los graficos que hace la gente en base a ellos. Se dobla la resolucion solo para complicarse y no lograr beneficios de ningun tipo.

Por eso trabajo con graficos de resolucion 320 x 240 con el ya que son mas faciles de hacer, quedan bien, y a la vez me gusta ese estilo pixelado. Ademas hay muchos mas rips por ahi sueltos.

Para hacerlo
-El rpgmaker pone un efecto de suavizado a las fuentes pero esto se usa poniendo fuentes especiales que esten basadas en bitmaps y no en fuentes tipicas. De esta forma no puede reescalr ni suavizar. Aqui es un buen ejemplo: http://www.dafont.com/bitmap.php

-Convertidor de archivos Devil Tools de Drago del Fato. Bajarlo aqui. http://rpgmaking.altervista.org/Uploads/DTSetup.zip .Es capaz de muchas cosas y hast aconvertir juegos enteros. Eso si esta en ingles.
La opcion de convertir juegos es Convert 2k folder to RMXP. A bajo veras Convertors, ahi sale cada recurso para pasarlo al XP. Cuando les das te pide el directorio de entrada y salida o los ficheros.

-Aprovechate de la ventaja del xp en por ejemplo los tilesets en que puedes poner tantas columas extra(aunque a patir de cierto numero no las usa) o filas, eso para trastear e ir haciendo esta my bien ya que te sorba el espacio. Idem con los colores.

-Obviamente la limitacion es que tengas que doblar algunas cosas. El truco esta en trabajr en pequeño y luego copiarlo para presentarlo. Se pierden unos segudnos pero no es tan rallante y aveces puedes editar en grade. Aun voy en busca de un editor que permita cambiar el tamsño de los pixeles o forzar tu propia cuadrcula, supongo que existra.

Articulo: Scripts vs engines en el rpgmaker

Con la aparicion del XP se añadio una importante herramienta al RPG Maker, herramienta denostada y infrausada por diversos grupos de usuarios en diversos sentidos. Yo empeze con engines cuando no habia nada mas y hoy en dia ya llevo sobre 40 scripts realizados. La verdad esque me gustaria que la gente los usara mas, que se crearan mas flexibles y que se aprendiera un cierto grado de RGSS para poder adaptarlos ni que sea.

Creo que solo benefician a la gente ya que ahorran tiempo a invertir en ciertas tareas que se pueden aprovechar para otras cosas.

Ventajas de los scripts
-Pueden hacer cosas que los engines no.
Esto es muy evidente. Con los scripts hay una libertad apabullante de opciones, mientras que los engines estan muy limitados.

-Son mucho mas faciles de compartir y reusar. 
Hay muchos scripts por ahi que solventan ya tus problemas y que no deberas resolver otra vez. Esto es una gran ventaja pero esque ademas los puedes adaptar a tu propio gusto.

-La experiencia que obtienes de scriptear puede ser util para otras cosas.
En general los engines para poco te sirven, excepto para aprender a programar luego, ya que aunque no lo parezca, la logica y estructura usada es muy similar y se usan muchas de las construcciones de la programacion. Yo no recomendaria aprender programacion antes de los engines pero no estancarse en estos.

-Mayor velocidad de proceso del sistema.
Los scripts son muchisimo mas rapidos que qualquier engine. Los engines se procesan como datos de la base de datos generales del rpgmaker, en el apartado de mapas, eventos comunes, etc, y ahi quedan guardados. El punto es que los eventos para empezar, deben ser leidos, analizados, interpretados y luego segun el comando que sea, ejecutar uno u otro codigo de script, haciendo ademas muchas cosas de forma mas ineficiente.

En ese sentido los eventos son utiles para las cosas que no son criticas ni complejas. No tendria sentido hacer escenas con scripts complejos por ejemplo, pero pasa lo mismo al reves.

-No son tan dificiles de hacer.
Probablemente el mayor miedo sobrevalorado sea el paso de algo grafico a algo escrito. Aun asi, y habiendo aprendido a programar en esencia atraves de el RGSS, no los considero tan dificiles. En realidad muchas cosas que haces con engines son iguales en la programacion, solo que con unas capacidades y prestaciones apabullantes.
Y tampoco tienes que ser un pro para valerte, con que puedas adaptar a tus gustos vas tirando, y eso ya son muchisimas opciones.

-La posibilidad de modificar los sistemas default o de otros en vez de crearlos de 0 cada vez.
Este tema es vital. Si yo quiero crear un sistema de habilidades parecido al del FFIX y lo quiero hacer con engines, debo hacer todo el sistema de 0, generando todo mi codigo, todo mi aprenentaje y mis sistemas cada vez.

En canvio con los scripts, mucho de ese trabajo es inexistente. ¿Porque? Este caso del FFIX es real y es que es lo que me paso a mi. Quise hacer una version del sistema de habilidades de este juego con cosas nuevas y tal, pero de base parecida. ¿Que hice? Busque un script que hiciera algo parecido para usarlo como base, y de hecho, al ser FFIX tan popular, habia un calco exacto de ese sistema.

Lo implemente y modifique y expandi luego. Con esto me ahorre un trabajo imenso que ya se habia currado el autor del script.

Pero esque esto se puede hacer practicamente con todo. Lo que se llaman 'scripts default' son sistemas abiertos, documentados y modificables que tu puedes usar como base. Si yo me pongo a hacer un menu de guardado no tengo que escribir toda la escena de 0, hacer todo el refresco, control de teclado, interfaz, utilidades... no. Cojo el script por defecto, lo estudio y lo adapto a lo que yo requiera. Este es sin duda uno de los aspectos mas importantes de los scripts, ya que si hubiera que haber hecho todos mis sistemas de mis proyectos de 0 por engines, habria tardado años y años solo programandolos, mientras que aqui he tradado horas.

Notad que esto no tiene NADA de malo. Hay mucha sensacion de orgullo enginer que creo que sobra, porque esos años que se tira la gente haciendo engines y que por scripts se tarda tan poco, se podrian haber dedicado a otras facetas del juego. Gracias a ese tiempo el juego podria haber tenido mejores graficos 100% personalizados o muchos sistemas mas por su mas facil implementacion. Nadie habla de vagancia y de no mover el culo.

-Mayor organizacion y claridad del codigo
Con el XP aun, que colorea los engines, pero con los antiguos, ni eso. Aun asi, al hacer engines se tiene todo muy desordenado y escrito de forma poco clara. Una vez aprendes a programar te parece lo contrario.

Ventajas de los engines
-Menor curva de aprendizaje
Obviamente los engines son mas faciles de tomar en primer momento. Aun asi, desde que aparecio el XP, creo que es absurdo eventear en general cosas complejas con este existiendo el RGSS. Creo que los eventos son utiles pero deberian servir de puente hacia los scripts para muchas, muchas cosas.

-Son mejores para cosas simples, como la jugabilidad, escenas, dialogos, mapas, etc
Obviamente nadie usara scripts para esto. Esa es la principal funcion de los eventos.

Algunos falsos topicos que desmentir.
-Los scripts son mas dificiles de testear
Al reves. Los scripts estan pensados para ser testeados y los engines no. Con los engines hay que hacer autenticas virguerias para ello si se lleva hasta cierto nivel de complejidad.

-Los scripts propician la clonicidad y el copy/paste y de que todos los juegos se vean igual
Es cierto que en el pasado al hacer un engine este quedaba normalmente por huevos distinto al de los demas. Pero esto no me parece algo bueno de por si, mas que nada porque con los scripts se puede hacer lo mismo. Me pregunto cuanta gente aprovecha de verdad las opciones que dan de por si los scripts o busca mas scripts por ahi que los tipicos, que los hay, a tropecientos millones, por cierto.

Y aun asi, como digo, es culpa del que adapta el script y de nadie mas. Con el tiempo que uno tarda a hacer engines, te da tiempo a aprender a modificar scripts(muy facil) para darles ni que sea la estetica que a ti te interese. Aun asi muchos usuarios que se lo curran con sus juegos esto ya lo estan haciendo, asi que me temo que el usuario que solo copia y pega scripts y recursos tampoco seria de los que hiciera engines.

-Los scripts propician la vagancia
Una de las cosas mas hipocritas que he oido por ahi. Osea, veamos, segun esta gente, la programacion deberia ser una experiencia cerrada y obligada de 0 cada vez reservada al maximo esfuerzo, porque sino no tiene meritors, ni interes, etc, etc.

Eso si esto lo dice gente que no solo no crea sus graficos y no los crea de 0, sino que encima normalmente los roba. Gente que es incapaz de esforzarse para pagar la licencia del programa. ¿Y de la musica y de los sonidos? Otro tanto que con los graficos.
Y no sabeis, no llegais a saber hasta que punto el RPG Maker es 'vago' segun vuestra definicion y cualquier cosa hecha con el lo sera. Y esto es porque la creacion del propio programa RPG Maker es una tarea tan y tan compleja que supera al trabajo hecho por ninguno de esos makeros. Pero eso si, SI existe gente que le encanta el reto de la programacion y que hace sus propios engines y editores para sus proyectos, y hasta empieza uno nuevo cada vez.

Pero claro, al tio que usa un script es un vago que no llega a personalizar su juego con ningun esfuerzo... y ellos si, por hacer cuatro engines. Porfavor. Incluso son incapaces de esforzarse a aprender a programar...

Lo principal es que no tiene nada que ver con los propios scripts. Es cada usuario el que decide cuanto esfuerzo invertir, por lo que que use scripts o cualquier otra cosa es lo de menos, no variara su interes.

Finalmente, como ya he dicho antes, cuanto mas tiempo se libera con los scripts, mas tiempo queda para todo lo demas, mejorando el juego en conjunto.
¿Como serian los juegos si cada persona tuviera que crearse su propio RPG Maker? No metamos esfuerzos intulies en busca de se sabe quien falso merito y dedicamonos a cuidar otros aspectos de nuestros proyectos con el tiempo que nos liberan estas herramientas.

Articulo: Escala de dificultad y sistemas a crear

Niveles de dificultad
Los niveles de dificultad permiten a un largo rango de usuarios jugar a tu juego: desde el novato al experto, pasando por el que quiere rejugar el mismo, etc.

Aun me sigo preguntando que cojones les costaba a gente de SE por ejemplo, hacer un sistema asi para sus FF, aunque solo modifique el poder de los enemigos(¡0% de diseño, pues!).

La escala de dificultad ha ido variando con el tiempo
Antes lo normal era un juego dificil para los estandares actuales. Los juegos faciles existian pero para el jugador de hoy seguirian siendo duros, como Golden Axe o Super Mario Bros. Idem con los dificiles.
Pero si se ha de usar una media para representar la dificultad en los videojuegos, actualmente, algo no cuadra.
-Extrema.
-Dificil.
-Media.
-Facil.
-Paseo.
En muchos juegos actuales, o en la vision que dan de los mismos los medios, la escala de dificultad es ridicula, porque basicamente el rango dificil y extremo contiene los niveles medio, dificil y extremo completos.
Se deberia cambiar esto y permitir realmente a la gente usar niveles de dificultad con todos los rangos completos.

Publico objetivo de tu juego
Al hacer los niveles de dificultad y el reto general debes pensar cual es el publico objetivo de tu juego. Normalmente para los jugadores indie el reto deberia ser mayor, porque suele ser como poco gente mas experimentada que la mayoria y con una cierta veterania.

Sistema de dificultad
No solo se trata de hacer sistemas de dificultad que escalen el poder de los enemigos y quizas, tus propios recursos. En general esta aproximacion jode a la gente que quiere jugar con algo de reto, porque el resto de elementos no se hacen de forma escalable: puzzles, variabilidades, exploracion, busquedas, ayudas de interfaz o control, etc, que estan todos pensadas para dificultades simples.
Otro detalle es desbloquear patrones de IA, de ataque o habilidades de los enemigos que los hagan mas y mas peligrosos a cada momento.
En los monkey island 2 y 3 se crearon niveles de dificultad. Cuando elegias uno u otro variaba el nivel y complejidad de los puzzles.

Escalando y creando los niveles
La mejor forma es ir diseñado desde un nivel base que tendra todas las complejidades de diseño añadidas(no solo % de atributos o vida), como puzzles o exploracion. Si este nivel base es el dificil pues sera el nivel que usaras como base y en el que mas testearas y jugaras y pondras mas empeño y complejidad, sin preocuparte de que tus jugadores vayan a frustrarse, porque para eso existen los demas niveles, a los que iras haciendo progresivamente recortes.

Tras el nivel base se puede crear uno extra que esta vez si que ya use solo una mejora en % respecto al anterior.

Nivel de dificultad personalizado
He estado planteandome esta opcion. La de usar un menu donde selecciones la dificultad poniendo valores que multiplican y escalan la dificultad. Por ejemplo:
-Atributos enemigos: Del 0 hasta el 999% de variabilidad a aplicar. Explicando que el dificil tiene por ejemplo, 150.
-Puzzles: Facil/Normal/Dificil: Obviamente en este caso no se puede escalar nada con formulas, pero permitira a personas que no les gustan los puzzles poder jugarlos en modo facil.
Hay un pequeño ejemplo de este sistema que yo haya provado: Centurion, defender of rome, analizado en este mismo blog. En el se permitia modificar la dificultad del combate, y del manejo del mapa general, y de los minijuegos del mismo, todo por separado. Yo en particular baje la dificultad de los minijuegos, pese a estar jugando en dificil, para poder centrarme sin problemas en las cosas que mas me gustaban.
Quizas un problema que pueda exisitir, pudiendo dar y configurar cualquier valor, es el de la falta de testeo, pero eso deberia advertirse en el simple menu de personalizar la dificultad.

Cambiar la dificultad durante el juego
Hay juegos que permiten esto, como por ejemplo, muchos juegos de rol occidentales, como el TES o el Deus Ex.
Sin embargo esto tambien puede verse como un poquillo de 'trampa', pero hay casos donde esta bien:

-Cuando alguien empieza en nivel facil o normal, se aburre y tendria que reempezar para jugar con reto y mas diversion.
-Al reves. Algun listillo empieza su partida y quiere bajar el reto porque esta siendo masacrado.
-Gente que necesita pasar ciertos retos porque no puede, se le acaban las ganas y le aburre o se queda bloqueado.

En los dos primeros casos no veo problema alguno. El dilema esta en el tercero y hasta que punto esto es permitir trampas dentro del juego. Esto queda a conciencia del creador pero en general prefiero dar libertad completa al jugador y que sea este, bajo su propia conciencia, el que permita o use una u otra cosa, por una u otra razon.

Mi opinion
En mis proyectos uso un sistema facil, normal y dificil. Aviso de que el facil tiene una dificultad entre FFVI y FFVII, el normal una de FFV y el dificil una similar a los RPG de la NES.
En el manual introduzco con ciertas pistas a usar para los novatos, que pueden usar para facilitarles las cosas. Ademas aviso de que la forma optima de juego es el modo dificil, pues es el mas completo de todos y no solo mejora por %.

Y solo me queda elegir si poner un nivel mas o el nivel personalizado. Creo que me decidire por este. Estoy planteandome si usar o no el sistema personalizado y el cambio de dificultad durante el juego, pero lo mas probable es que si lo permita. Finalmente suelo hacer que el nivel de dificultad mas alto tenga mas contenidos tanto argumentales y jugables y teniendo un final alternativo para  homenajear los tiempos en que solo unos pocos podian ver el final de un videojuego.

Articulo: Escenas saltables

Robando el tiempo por defectos de diseño
Esto es algo que casi no se ha visto, y que personalmente, me jode un monton, sobretodo en muchos RPG. El sistema de escenas saltables permite a la gente sudar de un dialogo o escena y avanzarlo rapido(sea por una u otra razon).

He encontrado algunos juegos que usaban ese sistema, como el FFX si no recuerdo mal, advance wars, y las aventuras graficas con sus opciones de dialogos rapidos y de saltar dialogos.

Algunos ejemplos
-Jugando al FFIV original, mas dificil, mientras subia de nivel en el tramo final, trataba de combatir de tanto en tanto con el jefazo, para pulir la estrategia y llevar un buen combate al limite de sus posibilidades cada vez.

¿El problema? La escenita, el discursito, y el power of love, como no. El poder de la amistad almenos, que salvaba el mundo y tal y cual. Nose si llegaria a 10 minutos.

¿Cuantas veces tuve que tragarme eso? ¡Cuanto tiempo malgastado!
Y eso pasa muchas veces mas. Y no solo con monstruos finales, puede pasar en mazmorras, o porque se te apago la consola, o lo que sea....

-Cuando rejugue a FFVII para pasarmelo por su sistema jugable me aburrian sus interminables escenas, sobretodo al hablero jugado tantas veces ya. Nota que jugue con un reto especial y entonces me di cuenta de cuan increiblemente toca huevos resultaban las escenas obligatorias para la gente que quisiera retarse jugablemente con tus juegos.

Mi opcion
En los viejos rpg makers, queria usar un engine para esto, probablemente usando un sistema de preguntas o respuestas que saltara a un evento o mapa alternativo. Si, era mucho trabajo y muy poco integrado dentro de la mecanica del mismo, aun asi es una opcion.

Esto se ha simplificado con el XP, ahora uso un script de creacion propia que crea un modo saltar escenas activable por una tecla. Cuando esta en el, se esquivan todos los sistemas de dialogos, graficos, etc, y solo se procesa la parte logica, por lo que se salta toda la escena pero si se aplica la jugabilidad.

Artculo: Tutoriales

Jugaba yo a otro juego del maker con interminables tutoriales, que te dicen desde como se usa un objeto en el menu a todos los comandos de batalla. Todo ello en un ambiente de lentitud constante, con una jugabilidad poco menos que absurda: en los 30 primeros minutos de juego, no vemos mas que aburrida exploracion, tutoriales y el tipico minijuego cutre de infiltracion (¡Este que no falte nunca!).

Viva los manuales. O los manules in-game, me da igual. O los diseñadores que son capaces de ofrecer tutoriales de forma divertida. O escalar la jugabilidad y dificultad de forma que no sean necesarios.

Puedo entender los tutoriales en un simulador o un juego muy complejo, como son algunos RPG, estrategicos, etc... ¿Pero en un juego del maker? ¿O casi qualquier videojuego al uso?

Pero veamos... si la jugabilidad y la mecanica suele ser tan mascada que es la cosa mas redundante del mundo, pero eso no es lo peor, el principal fallo es que la gente que juega a juegos Indie o de tipo maker, son gente que por cojones conocen el genero. Incluso diria que bastante expertos. ¿Entonces porque tratan como a tontos a sus jugadores? ¿Y ni siquiera los permiten saltar?

Un juego comercial es otra cosa, aunque aun me sigo cagando en esta moda de los tutoriales obligatorios, pero bueno, tienen otro mercado objetivo y no dependen tanto de la paciencia del jugador, ya que pagas por ellos.

No entiendo esta mania de copiar las cosas malas de lo comercial, solo para darle el mismo aire conseguido a tu juego, y mas en este contexto. La gente se creera que le da un estilo mas guay, pero solo hace que joder a los jugadores. ¡Tutoriales siempre opcionales! De hecho yo no los integrare en el propio juego en si, sino que formaran una parte del menu de ayuda o sera del estilo la Casa de los Novatos en los FF, que siempre me ha gustado bastante.

No todo debe explicarse, ni guiarse al jugador en ello. Se debe invitar al jugador a interactuar y experimentar. Y el manual debe ser una documentacion currada sobre todos los aspectos del juego, como si de uno comercial se tratase. Ademas, permite narrar tambien atraves de el, con contenio que ambiente bien y desarrolle la historia, en ese aspecto, es muy recomendable de mirar manuales de juegos antiguos que eran geniales. Y ya se que es un poco palo usar PDF mientras se juega, pero para eso se pueden imprimir o usarlos in-game.

A veces me olvido de porque ya no me gustan los videojuegos actuales... pero es poner uno y sufrir sus tutoriales(Algunos de ellos han llegado a superar la mitad del juego)para recordarlo..., es tan tedioso y aburrido, y lo hace parecer tan absurdamente complejo... ¡Y eso que me he pasado arcades dificilismos! ¡Reptiendo niveles docenas de veces! En fin.

Pero los tutoriales no los aguanto...me superan. Quiero diversion aqui y ahora, directa e intensa, o que me dejen saltarlos. Suerte que juegos como Shadow of the Colossus e ICO no tienen ni uno... no es casualidad que sean practicamente los unicos juegos que me han gustado de la pasada generacion.

En definitiva este caso es similar a las escenas. Adapta el juego a tu publico y da las maximas opciones y flexibilidad para el mismo, no obligues a la gente a tragarse tutoriales eternos y haz que sean opcionales y revisitables, asi como currate un buen manual. Esta es la mejor opcion, sin duda.

Articulo: Reinventar la rueda

Creadores de videojuegos o creadores de engines
Hay un fallo en el que veo caer a mucha gente y esque la gente parece estacanrse al tratar de crear su propio 'Engine'. Con engine me refiero al conjunto de programacion al completo que le permite al sistema funcionar.
Si estas con un plataformas, hacerlo de 0: colisiones, mapeado, tiles, objetos, fisicas, etc... y luego mucha gente trata ademas de publicarlo en plan framework o engine para otra gente, sin embargo...

Pygame
Estuve mirando los proyectos de Pygame, y.... ¿cuantos hay completos? ¿Un 1%? ¡Ni creo que llegue!
El 99,99% de ellos estuvieron reinventando la rueda una y otra vez, escribiendo de 0 engines completos que publicaban para los demas, cada vez, etc, etc. Hay muchas librerias y frameworks, tambien. Esto se ve facil al ser todo codigo abierto.

Me baje una larga serie de proyectos, muchos abandonados, que podria usar para mis fines la verdad. Hay muchas librerias, directamente, aunque muchas de ellas de nuevo, incompletas y con varios equivalentes.

Creo que recolectando y reusando codigo todo abria ido mucho mejor.

Cuando reinvetar la rueda
Reinventar la rueda es util cuando:
-Estas aprendiendo: es vital. Aunque no estoy de acuerdo en hacer ejercicios chorra, hacer pequeños proyectos y clones y sistemas es necesario para tener la base necesaria para lo demas.
-Reto: Hay gente que hace autenticas virguerias programando y lo quiere demostrar.
-Ofrecer tu vision o version: Hasta cierto punto puedes pensar en crear tus propios sistemas a tu estilo o segun tus ideas.
-Gusto: Cualquier valor subjetivo que quieras darle.

Mi opinion
Yo siempre reuso o mejoro. La unica razon de no reusar es porque lo hago por reto o por aprender. De hecho tengo un pequeño proyecto de engine y proyecto simple en pygame que voy haciendo, aunque no totalmente de 0, ojo. Pero si quiero aprender a hacer algunas cosas que no se hace y por el ligero reto.

Cuando me dedico a scriptear para el Rpg Maker Xp siempre busco algun script y si lo hay lo aprovecho y si no me sirve almenos lo uso de base y lo mejoro. Y luego publico todo lo que hago, para resarcir a la escena, y en mi gusto personal, intento que sea todo hiperflexible y configurable.

Osea.. aparte del uso del ACBS, genial sistema de batalla, yo por ejemplo tenia en mente hacer un sistema de habilidades en algo similar al del FFIX, solo que con algunos cambios o mejoras. ¿Que hice? Busque un script de ese sistema y lo use de base. Me ahorre un monton de tiempo aunque reconozco que he tenido algunos problemas en la adaptacion, pero me da igual, compensa.

Lo importante es disintguir: ¿programas para crear videojuegos o para mejorar o disfrutar programando?

Y siendo una pregunta con muchos matices y grados, yo almenos lo que quiero hacer son juegos(me gusta programar, por eso), donde al final , la programacion es una parte bastante menor del todo, y donde liberar tiempo en un campo me ayuda en la creacion en conjunto.

Siempre genero otros retos o necesidades, sin embargo, que debo programar yo mismo(tengo sobre 30 scripts para el rpgmaker, algunos muy complejos, aparte de subproyectos en ruby y python), y como me gusta... pero procuro ser lo maximo practico siempre si puedo.

Tutorial: De los eventos a la programacion RGSS

Esta es la primera version de un tutorial un tanto diferente de RGSS pues su objetivo es servir de puente entre los eventos y los scripts. No es manual completo de RGSS, Ruby, o lo que sea, sino que va explicando paso a paso las direncias entre los eventos y la programacion usando los equivalentes existentes en los eventos para que sea mas facil de aprender.

Al final del mismo haras tu primer script Fisher Price paso por paso.

Bajar

Cualquier sugerencia u error, comentadmelo.

La idea es que saliera una seguna parte en el futuro que explicara como hacer scripts mas complejos y sobretodo, con graficos, y añadiera conclusiones sobre su uso. Equivalentes al SMP, SBP, etc, tan tipicos con engines.

pd: Este tutorial esta en formato odt y doc. El formato odt es una alternativa libre y gratuita al doc y lo puedes usar descargando el programa OpenOffice tambien gratuito y libre.

Articulo: Documentos de diseño para crear videojuegos

Que es:
Es un documento donde se diseña el juego antes de hacerlo. De esta forma, al plantearlo y pensarlo, se ahorra tiempo y se mejora la calidad, a la vez que te permite presentar tu idea a tus productores o a quien sea.

Los documentos de diseño constan, por ejemplo, de:

-Introduccion inicial.
-Analisis del proyecto, situacion en el mercado, etc.
-Personajes
-Argumento
-Guion
-Jugabilidad

Sus beneficios son:
-Ahorra esfuerzo: Aunque en un principio pueda parecer lo contrario, los documentos de diseño ahorran mucho trabajo. Cuando se improvisa sobre la marcha totalmente se suelen cometer muchos errores, se hace mucho trabajo que luego quizas se tenga que desechar, o que simplemente se parchee bajando la calidad del juego, quizas hasta se deje el juego a medias por no tener mas ideas.

-Mejora la jugabilidad: Si tu juego es terriblemente simple, quizas no importe tanto (por ejemplo, vas creando a cada paso enemigos y habilidades sin mas), sin embargo a la que empiezas a tener un poco de complejidad, tienes que poder planificar el set de caracteristicas de cada personaje a lo largo de la aventura y en conjunto, para poderlo hacer verdaderamente equilibrado.

-Mejora el guion: Improvisar una historia tiene muchas consecuencias negativas, esto se puede hacer quizas con historias cortas, pero sino se nota claramente. Hay muchas cosas que pensar y reflexionar sobre una historia que solo pensaras en ella si la valoras en conjunto, desde el ritmo, tipo de narrativa y diversos estilos argumentales.

-No recorta la improvisacion y creatividad: Primero, si tu documento de diseño lo creas tu, siempre seran ideas tuyas improvisadas en otro momento distinto a la creacion del juego, asi que de base es similar. Un juego poco improvisado yo diria de aquel que se buscan muchas referencias, modelos y estudios para planificarlo, y que requiere mucha conceptualizacion, y tiene muchas demandas externas. Por ultimo, yo almenos no pongo hasta la ultima gota de ideas, sino que dejo un buen trecho para todo el proceso creativo directo con el programa.

Yo vario tambien el tipo de documento segun el estilo de cada juego. Por ejemplo, tengo proyectos muy tecnicos que tendran muy poca improvisacion, pero tambien tengo otros donde dibujo muy por encima cada seccion y luego voy creando a cada paso, el proyecto con el que estoy ahora lo cree especialmente para poder trabajar de forma mas fluida, aunque esto no significa que no tenga un documento bastante profundo.

Normalmente escribo lo siguiente:
-Guion a nivel de resumen amplio: Esto es decir, nada de "entraron en la mazmorra y luego fueron al pueblo", esto es poquisimo, se tiene que definir y pensar mucho mas, en estos tambien incluyo las secciones jugables.

-Todas las caracteristicas del juego, sistemas, etc...

-Cada personaje, sus habilidades y mejoras.

Luego una cosa importante:
-Reflexion sobre los valores jugables del juego. Una buena ayuda es escribir una guia de tu propio proyecto, esto hace que como creador deduzcas y planifiques mas facilmente todos los tramos jugables, sabiendo crear una curva de aprendizaje adecuada.

-Reflexion sobre el argumento y arte del juego. Que significan para ti lo que has creado, que influencias, como se desarrolla, etc... me ayuda a profundizar y definir las ideas del juego.

Que no uso:
-Escribir los dialogos en el documento. Supongo que puede tener su utilidad, pero la verdad esque del papel al videojuego hay mucho trecho, crear dialogos abstractamene cuando luego dependen por completo de los recursos tecnicos del programa se me hace extraño e inutil. Si se trata de un juego con una narracion muy muy literaria, como por ejemplo una aventura grafica o conversacional, pues entonces si...

Mis documentos de diseño:
El proyecto que mas he diseñado tiene casi 300 de word paginas de documentos de diseño, eso si, tras 3 años de desarrollo del proyecto, ya.

He podido replantear el proyecto 1000 veces en 1000 aspectos distintos sin perder mas tiempo que cambiar unas lineas, y eso era porque estaba en fase de diseñado y prototipado, aun. Han habido cambios gigantes y puedo seguir mejorandolo todo sin perder tiempo. 

Algunos ejemplos:
Aventuras graficas de sierra y de al lowe:
http://www.allowe.com/gamedesign/index.htm

Articulo: Empezando a programar videojuegos

¿Como empiezo?
Normalmente la gente recomendara aprender C, o C#, o incluso C++, y apuntarte a algun lugar.

No recomiendo en absoluto que empiezes con C o Java. Empieza trasteando con programas que no requieran programacion(o si, pero opcional o simple) para crear videojuegos, como el rpgmaker xp, adventure game studio, construct o el game maker. O si me apuras qualquier editor de mapas de fps o rts, o creando algun mod para algun juego.

Estos ademas tienen lenguajes de script que te resultaran mas faciles de aprender y manejar que librerias profesionales como puede ser SDL o XNA, pero igual te introduciran bien en todos los asuntos importantes.

Trasteando con eso aprenderas la complejidad de un videojuego en su totalidad(graficos, musica, guion, diseño, jugabilidad...) a la vez que iras captando rutinas de programacion, aunque sea de forma grafica.

Aprendiendo tu primer lenguaje
Luego pasate a un lenguaje accesible y simple con el que aprender desde 0. Mucha gente empieza con Python y Pygame o C# y XNA, aunque otra alternativa seria Ruby y Gosu, los cuales forman en conjunto para mi la mejor opcion para empezar, y sin dejar de ser potentes en ningun aspecto.

Notad que hoy en dia hay una nueva libreria muy potente, rapida, basada en objetos, en desarollo, con mejores prestaciones que sdl y muy portable tambien(esta para casi todos los lenguajes que puedan interesaros), se trata de SFML, de hecho es hasta mas sencilla aunque haya menos tutoriales y codigo hecho de antemano, aun asi, tiene un desarrollo activo y eso cuenta mucho tambien y posiblemente acabe desplazando bastante a SDL y los que se basan en ella(como gosu o pygame) el futuro. Tan sencillo como buscar la version para tu lenguaje favorito, aunque es preferible python porque hay mas gente detras.

Tras eso y cuando hayas aprendido orientacion a objetos y toda la pesca, puedes pasarte a c++ sin demasiado problema. Y tambien toquetear con 3d, aunque no dejas de poder hacerlo en todos ellos.

http://slav0nic.org.ua/static/books/python/beginning-game-development- ​with-python-and-pygame-from-novice-to-professional.9781590598726.29808​ .pdf

Libro gratuito de python y pygame.

En general no necesitas estudiar un ciclo de informatica para desarrollar videojuegos. El 99% de lo que dan ahi es inutil para tu proposito, y la programacion que dan es pobre y orientada ha hacer aplicaciones y sobretodo webs.

Nose si te pediran si o si el titulo o algo, pero sino fuera asi yo gastaria mi tiempo en bajar una coleccion de libros y tutoriales de internet y empezar a apendrer a saco.

Ya en eso puedes provar tambien con Unity, Cryengine y Unreal Engine 3, 3 engines decentes y muy potentes para indies.

Rendimiento de los distintos lenguajes, ¿Importante?
No te dejes engañar por la potencia tecnica y rendimiento de lenguajes como C o Java. Un programa en Ruby, el lenguaje de script mas lento, funcionara sin ningun tipo de lag o problema en casi qualquier equipo. Muy compleja y pesada ha de ser una aplicacion para que no vaya a funcionar en uno de estos lenguajes, la verdad, y si puedes hacer las cosas mas simples sin tener que gastar tanto tiempo, mucho mejor.

Que tenga un alto rendimiento es util para cuando este alto rendimiento es necesario. Nadie va a escribir un Sistema Operativo en python o un Game Engine con el pero otra cosa es escribir un juego amateur o qualquier otra aplicacion que sustente sus tareas mas complejas en librerias ya compiladas y optimitzadas en C o C++.

Entonces no tiene ningun sentido usar otro lenguaje por su rendimiento, porque todo lo mas pesado es hecho por librerias que tu no gestionas.

C++ se usa en el ambito PROFESIONAL porque ahi cuenta el rendimiento al limite, no a un chaval que acaba de empezar programando y no tiene ni idea y quiere hacer juegos indies para enseñar a sus amigos. Se debe elegir la mejor herramienta para cada cosa, cojones.

¿De que te va a servir programar un buscaminas con un manejo de la memoria 100% optimo y estructuras de datos personalizadas, acceso a bajo nivel y toda la pesca? ¿Para hacer un buscaminas necesitas todo eso? ¿Y gastar todo el tiempo extra en aprenderlo, manejarlo y escribirlo?

La enorme mayoria de programas que un amateur vaya a escribir no necesitan un lenguaje realmente rapido. Y los lentos ofrecen millones de ventajas a cambio de esto. Y python es uno de los mejores para aprender porque es un lenguaje donde las cosas solo se hacen de pocas formas, tiene identacion obligada, etc...

Ventajas de los lenguajes nombrados
-Mas simplicidad y accesibilidad, que no falta de potencia, excepto quizas de librerias, donde nadie compite con C++. Son lenguajes ideales para empezar y para que los amateurs trasteen. Lenguajes como ruby estan hechos con el karma 'Un lenguaje orientado al programador y no a la maquina'.

-No has de compilar, excepto con c#. Este proceso es lento y a veces puede dar problemas. Con los lenguajes de script puedes testear de forma immediata.

-La sintaxis. La sintaxis de lenguajes como ruby o python(el que mas ruby, y el que menos c#), es mucho mas accesible, flexible, bonita y rapida, por lo cual la hace mas interesante para aprender. Ademas python es recomendable por su identacion obligatoria y su lema de hacer las cosas de una forma, por lo cual te aseguras bastante mejor de educar bien desde el al principio al chaval.

-Biblioteca estandard mas amplia. El que menos es python. Lenguajes como C tenian 4 funciones muy cutres de forma base. Esto quiere decir por ejemplo, que debes reescribir codigo y herramientas a cada paso.

-Diseño moderno. Muchos lenguajes antiguos tienen decisiones en diseño que otros nuevos han solucionado mejor. No es que sean perfectos pero en ruby para copiar un objeto es tan simple como: objeto.clone, o copy, mientras que en Java primero has de implementar una interfaz, que luego te enteras que no va porque la hicieron de pena y no es usada, y se usa el constructor de copia, y implementarlo cada vez y tal y cual... teniendo que escribrir cada asignacion de atributos siempre, aunque vayas a hacer una copia total en el 99% de los casos, vamos un desastre, y cosas asi hay muchisimas.

-Manejo de memoria automatico. En C/C++ debes manejar tu de forma manual la memoria del programa. Esto quiere decir mucho mas esfuerzo y complejidad, a la par que mas bugs y problemas de seguridad. El bonus es el rendimiento, que dudo que resulte necesario.