Monday, March 30, 2009

SDK for RPG Maker

[The] future is upon us. Game designers can serve themselves up with some RPG Maker Kool-Aid as a handy tool to implement their vision. RPG wet dreams brought to you by a convivial and convenient tool, allowing its designers to deal with databases, maps, events and so forth without the hassles of programming the game from the ground up.

Designers can extend the existing engine according to their needs because the inner strength of RPG Maker comes from its powerful Ruby based engine. Yet, as a curious phenomenon, you cannot do everything that comes into your Ruby mind. The future is upon us... but not exactly.

Integrated Development Environment
Scintilla might be fine as an enhanced text editor but it's no replacement for a well-rounded Integrated Development Environment (IDE). Remember, RPG Maker only partially uses Scintilla. Things get from worse to worst when you just cannot do anything (or mostly) of the following...

(NetBeans, Eclipse, SciTE, vim, etc)
Project Management | Syntax highlight and completion | Refactoring
debugging | profiling | regression testing | RubyGems
Revision Control | Build Automation

RPG Maker succeeds with designers because it's easy-to-use and easier to create RPG games. Developers are however left dying on the road. RPG Maker does not support a complete software development life cycle (see here too). And that's probably why there are not so many commercial games based on RPG Maker VX/XP in spite of their userfriendly software and working right out-of-the-box engine.

Testing, Testing, ... someone listening? Debugging RPG Maker games is a mysterious process in which you have to deal with unexpected error pop-up windows or print outs of your own. You've got this state-of-the-art programming language but you're sent back in the 70s. Japanese might just be fan of John Travolta for what I know.

A serious indy developer would think twice before investing money in developing on such engine. It is extremely costly to develop and maintain an engine that is mostly human-tested. And human does make mistakes. Ruby provides many testing frameworks, for unit testing (xUnit style) or Behavior Driven Development (RSpec provides BDD support). None can be used directly within RPG Maker, and painfully outside.

Furthermore, and beyond regression testing, error messages should not be volatile as a pop-up window but rather available in a log. It's matter of being traceable. Most IDEs usually lists errors in a window pane. Ruby from command line would simply print out errors on stderr.

Profiling Code
Computers must have reached some new heights to allow game developers to live without a code profiler. How is it possible to find and fix bottlenecks and optimize code otherwise? A profiler is a software performance analysis tool and is fundamentally different from a Benchmark tool. Ruby has various tools for these respective tools, namely ruby-prof and Benchmark module. None of which are included in RPG Maker.

The One-Man Team
There is no such thing as a one-man team. Period. If you got a team, it is because you have more than one person working on a project, otherwise it's one-man effort and that's it. The point is that even being an indy developer means to have staff at one time or another. RPG Maker is unfortunately inadequate in many ways for team work.

RPG Maker is not designed with collaborative work in mind. There is no way to provide revision control of neither the source code nor its resources. It might be more trivial to manage external resources but it is limited to accessible files. Binary files can hardly be diff'd. Collaborative work also means a team working at the same time on a given project. By not integrating revision control within RPG Maker, it's hardly possible to always work on up-to-date resources, code and data. Integration and collision management are always manually managed, leaving the burden to preferrably only one person. Release process (see Build Automation below) also partially rely on revision control to track, manage, and fix defects in a software according to its version(s).

RPG Maker is not natively supporting revision system of choice, such as Subversion, CVS or so. Shame on Enterbrain.

Build Automation
Let's have a special word about Build Automation. This is something a software or game maker cannot live without. An automated build in the context of RPG Maker might mean to package a game, insert localized resources (documentation, texts, graphics and/or music, etc.), DRMizing your game or simply code sign it with your certificate. You would naturally consider using L10nTool to localize texts.

Fortunately, this can be mostly done outside RPG Maker using standard tools. Rake is mostly used by Rubyist, Ant is my current personal favourite, and Make could be used for the nostalgics. Rake is probably the best choice for indy developers leaning on RPG Maker.

It's however always interesting to know that build automation is fully integrated with IDEs nowadays. There are also few things that are not trivial to do without full integration, such as dynamically inserting scripts (or partially change databases) in RPG Maker according to build automation rules.

Ruby programmers are well familiar with RubyGems, the package manager for Ruby libraries. There are several thousands packages available online. They are called Gems for a very good reason: this is truly a treasure. Now, you've got a powerful Ruby-based product to make RPG games and you are prohibited to use RubyGems. Wankers! Why on earth Enterbrain wouldn't make it easy to use RubyGems, I'll never know...

Brave New World
Imagine a world where you would have everything listed here at the tip of your fingers. The real possibility to deliver high quality, well rounded, fully featured RPG games RPG Maker-based. Your games would finally get the treatment they deserve with SDK for RPG Maker. Real tools for real developers.

Your fantasies would also become true. You could spruce up your games with real-time image effects using RMagick. Or, yet, add physics with Chipmunk: Game Dynamics. Writing softwares like L10nTool would be a joyful ride in a park.

But, wait, that's not all!

You could easily create an online game with Ruby's networking feature. Perhaps, your MMORPG dream comes true. An RGSS Player as a server with a handful of databases and multiples RGSS Players as clients connecting to your virtual world. A world that can evolve.

Software Development Kit
An SDK would basically let you develop, test, debug, package and deploy your games within an IDE and a collaborative environment. Something along this line...

1 comment: