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, ...
...is 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.

RubyGems
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...

Sunday, March 29, 2009





This is an incredible work. PatrickBoivin pays attention to details and thoroughly executes his craft. He is a self-taught French-Canadian filmmaker from Montréal, Québec.




Friday, March 27, 2009

Onion

I have created a small RubyGem for Ruby's Array class in order to circumvent the complexity of nested arrays when gathering information from a specific format to another. This is used in a real project, namely L10nTool.

Onions have layers. Ogres have layers.

Onion, or Array Onion, allows peeling an array like an onion. It shreds one layer after another, from the outer inwards the inner nested array, according to the given depth. Infinite depth (or greater than current nested array depth) is equivalent to Array#flatten.

This is not the most stunning code one would have written but it fully passes its Unit Tests. Though some more tests have to be written. Also, it is an insignificant part of L10nTool. The export feature creates references for the import feature. These references are telling the import feature the location (id, accessors, etc.) and which database each translated text should be replaced at. Constructing cross references among multiple targets and databases, while abiding to the desired format, became easier with Onion.

That would perhaps be interesting for Hashes as well.
Difficult to say considering that it would be of no use for myself.

? ...why are you crying

Many reasons brought me to create a RubyGem and publish it in the open source community. Firstly, I would like to be more familiar with the process in general. Secondly, it's great to improve a piece of work to have peer reviews. Finally, hopefully, it will be helpful to others and give back to the community.

The project page is located at http://rubyforge.org/projects/onion/. It should be available on standard RubyGems server shortly.

All right, throw me stones little monkeys!

Wednesday, March 25, 2009

RGSS Player : A View on Its Implementation

[We] shall further elaborate on the implementation of a RGSS Player due to the popular demand. The overwhelming demand leaves me no other choice. Well, when your blog is as popular as mine, you really take a demand from a single individual seriously.

Enterbrain does not provide source code for its RPG Maker VX nor any other products as far as I know. Thus, the legitimate question arises on how one would port RPG Maker VX/XP RTP (Run Time Package) to another platform.

...truth to be told

Because it is important to respect the work of others and avoid legal nightmares, it does mean to completely rewrite the engine from scratch. This can be done using non-intrusive techniques (without reverse engineering per se) such as creating classes according to either RGSS{1, 2} specifications, writing tests to assess both RPG Maker and our own engines and make sure they have exact same behaviour, and so on.

Run Time Package

Run Time Package is mainly composed of a (1) RGSS Player, (2) Ruby Game Scripting System and (3) Ruby. This is packaged in a lovely executable (GAME.EXE) and dynamic link library (e.g. RGSS202E.DLL). Moreover, the RGSS Player has to be able to read the various databases available, scripts and decrypt encrypted archive (GAME.RGSS2A). Finally, SCRIPTS.RVDATA is loaded and executed once the RGSS Player is fully initialized. The graphics, audio, fonts, etc. bundled with RTP are cosmetic (and usually user-content) and does not affect the RGSS Player as long as they are available in a valid format supported by the engine.

? ...did you know

The Script Editor within RPG Maker VX uses partial features from Scintilla (SCINTILLA.DLL or SCILEXER.DLL) and let you edit SCRIPTS.RVDATA. The scripts deal with high level features of the game engine and, contrary to RGSS itself, its source code is fully available to the game designer. Concretely, it means that one can design a game using Enterbrain RPG Maker VX on Windows and would be able to run mostly unchanged on any platform a RGSS player is available.

{Ruby + RGSS}.exe
That's right. In a nutshell, the famous RPG Maker RGSS Player is RGSS classes on top of a Ruby interpreter embedded into executable files.
Consequently, one has to be able to reproduce RGSS classes and deal with low level programming {graphics, audio, decrypting, native GUI, etc.}, as well as being able to embed a Ruby interpreter in an EXE or DLL file.

There are few tools to create executable files with an embedded Ruby interpreter. Each have various limitations that might be problematic, such as, being limited to single or few target platforms, overly outdated, overly limited, still experimental, etc. My best guess is that RPG Maker uses Exerb.

It is really straightforward to implement a RGSS Player in principle but let's not forget that there are around 50 classes per RGSS specification, requires the ability to properly wrap up a Ruby interpreter into an executable file on the desired platform(s), writing hundreds tests, handling low level programming, which are different for each platform, and so forth. Ultimately, Ruby might also not be supported on some desired platforms, such as Nintendo Wii, AFAIK, and hence would require to port Ruby first.

Next time, we could have an overview of the possibilities offered with
an SDK for RPG Maker...

Wednesday, March 18, 2009

Of Mice and Men

So much for John Steinbeck.

Once upon a time, I had a mouse named Logitech MX 620. It was a long long time ago. A little while has passed after I purchased it in a local store but just enough to be unable to return the so-called four-legged living creature, that had actually no tail either. Unfortunately, I have encountered a problem for the first time with a Logitech mouse: the left click would sparsely double click on single click.

It's the instantaneous death of a brand name! It's difficult to trust a brand that has failed miserably in your hands.

Lenny, don't die on me please!

A brand new Logitech MX 1100 has been given to me as a present few days ago. So touching, isn't it? I sincerely hope that it will survive to my very own professional stress test: my daily usage in the workplace. Nevertheless, it is comfy and rich of features. It has DPI buttons, which let you adjust your mouse readings on the fly. I am not a big fan of huge mouse but it's so comfortable that it's difficult to complain about its size. Logitech says that this model is perfect for people who spend more than 8 hours on a computer. And it seems quite right on a first impression.

Did trust in the brand name came back?

I strongly believe that one has to closely monitor his or her favourite companies and have an appreciation regarding to quality of their products. My experience with hardware companies, from the inside, taught me that the inner guts are not necessarily as beautiful as the product has been advertised. You might just get the worst lemon in the world. The answer is: never trust a brand, be faithful to your needs only.

Now let's see how this mouse handles the pressure...

Tuesday, March 17, 2009

:) :) :)

Friday, March 13, 2009

Smalltalk

Smalltalk is an environment and programming language that has shaped modern computing ever since its creation in late 70s. One could go in length discussing its innovations and how they have influenced everybody, from developers to end-users including children. Truth to be told, perhaps you're in the entirely wrong domain of expertise if you don't know about Smalltalk1.

There are many commercial and open source implementations of Smalltalk. Each and every implementation has so-called common roots2 with a variable level of compatibility and are otherwise tremendously different.

VisualWorks is a commercial Smalltalk implementation to be noticed, it truly empowers your commercial applications. It's a solid, state-of-the-art and multi-platform Smalltalk. I also used to enjoy IBM VisualAge For Smalltalk... oh, time changes... and it was quite costly...

Whereas Squeak Smalltalk set the pace in the open source world with its wonderful, media oriented, experimental Smalltalk dialect. GNU Smalltalk deserves an honourable mention, powerful though mostly text-based (no UI).

What's up with Smalltalk anyway ?, shall you ask.

I'm lovin' it. Squeak is my favourite at the moment. It's great to transform a design into a working prototype. It is entirely self contained and allows you to do anything your wicked mind can conceive. Smalltalk is a totally reflective system usually written in itself, which means that you have complete control over your destiny.

Prototypes are more than often a specification nightmare, if only for their incompleteness. The very dynamic nature of Smalltalk makes it possible to grow an application through an incomplete specification. Moreover, instant results become not very far from reach. The early possibility to use your prototype is not only a great motivation but allows you to get in touch with human usability sooner.

Smalltalk community is pioneer in unit testing3 and every dialect includes a unit test frameworks as far as I know. Test driven development will give you the opportunity to make your prototype safe and sound. You can enter a test-fix-and-refactor phase as your prototype specification changes or yet whenever you pass from prototype to application.

bonus: a round and well written prototype can truly serve as foundation for an application.

Hold tight. It is still early for me to reveal (or unveil) my current projects using Squeak. Meanwhile, get in touch with Squeak Smalltalk or Scratch for fun4.

So long, Marianne.
  1. Therefore, hurry up to google it and make yourself knowledgeable. =)
  2. ANSI Smalltalk is the unifying de facto standard.
  3. SUnit is the inspiration for xUnit frameworks, thanks to Kent Beck.
  4. Scratch is written in Squeak Smalltalk.

Tuesday, March 10, 2009

RGSS Player for MacOS X

The idea is taunting me. It's beyond explanation. Perhaps even hopeless. Very little commercial games are based on RPG Maker XP/VX, reaching the incredible number of (5) five. And I do not have my very own game(s) based on either engines to fully benefit (and profit) from such venturous project. The maker and player fans would love it but they wouldn't pay for it, would they? The task at hands is tremendous. Consequently, the perspective of implementing a RGSS Player for MacOS X is borderline suicidal.

Yet, the challenge is compelling.

Developing an emulator is like building robots. It's exciting. An emulator is a form of computer simulation that seeks to replicate exactly the behaviour of a given system. This can be built according to specifications and non-intrusive tests since it focuses on behaviour, which will certainly prevent regardlessly taking apart other's work.

Specifications outline that each RGSS{1, 2} system has more than 50 classes on top of existing Ruby classes. RGSS1 and RGSS2 have compatible classes but some things actually differ: the latter has new classes, new methods and sometimes different behaviour. Databases are only the outcome of these classes and straightforward once you have the classes defined. The fancy scripts included with RPG Maker, or yet even custom scripts, only require Ruby+RGSS to work.

Emulating RGSS would mean to comply to one or both specification by implementing its classes, low level specifics {graphics, audio, etc.}, regression tests and an entire release process to produce a shiny new and wonderful binary file, installer, etc. This is a tremendous work. It has to flawlessly run RPG Maker games on MacOS X after all.

An interesting outcome from such project is that it would eventually allow a more up-to-date approach to programming RPG Maker games, because it's a step away to create an SDK that can be used in your favourite Ruby IDE (NetBeans, Eclipse, SciTE, vim, etc). There are many features not available in RPG Maker's Script Editor, if only for syntax completion, refactoring, being able to easily use RubyGems, and running unit tests or RSpec.

Will this project ever see the light of the day ?

Thank you for asking, Miss Daisy! There is absolutely no certainty about an eventual release. However, designing prototypes, proof-of-concepts and custom softwares are usually my daily bread. I might write a prototype some day just for the kick. Though commercial demand could get things started. Right now, I am mostly taking notes related to this more-than-uncertain project.

Saturday, March 07, 2009

L10n Tool for RPG Maker

So much for a public life. I usually keep my projects for myself. Let's face it, I am a secretive person. Nevertheless, I have decided to present some pieces of an ongoing project for your own displeasure.

Rationale
The motivation behind this project is to provide localization (a.k.a. L10n) facilities in order to deliver a multilingual, or at least localized version of, any game produced with RPG Maker VX. This project has to seamlessly integrate a translation process and yet without any major changes in an implementation of a product based on RPG Maker. Therefore, L10n Tool for RPG Maker is the way to go.

Features
  • Import and Export RPG Maker Texts and Dialogues
  • Smart Extraction and Representation
  • Support standard gettext PO and POT file formats
  • PoEdit-based translation process
Editions
L10n Tool for RPG Maker is available in different editions according to the purpose of their target audience. These editions are shipped with the standard product.

Master Edition
This edition provides complete support for releasing a localized version of an RPG Maker based product. This includes, without limiting to, importing and exporting data and prepackaging localized products.

Translator Edition
This edition provides import features and Strings database support, allowing translators to fill in and test with ease their translation. It truly allows translators to test their translation live and without having to deal with the hassles of RPG Maker.

Release Edition
This edition provides runtime facilities in order to support in-code strings localization. A small script is inserted in your product to be able to retrieve translated data from Strings database, a customly built database. This is the only feature exposed to the end-users.

Effective Translation Process
The translation process is greatly improved by extracting and annotating data from RPG Maker databases (smart extraction and representation) and, then, use the outcome in an organized manner with a specialized Computer-Aided Translation (CAT) software. PoEdit is a CAT software providing a seamless translation workflow with a Translation Memory (TM). Translators can create reusable building blocks for their translation as they translate with the help of PoEdit's TM. The Translation Memory then suggest nearby or exact matches on untranslated sentences, marked to be reviewed by the translator. It is also possible to run a spell checker, which you definitively cannot do within RPG Maker. This will save tremendous amount of time and yet provide an ultimate quality translation. Bigger, faster, better.

Currently supports RPG Maker VX.
Possibility to support RPG Maker XP.

Disclaimer: L10n Tool for RPG Maker does not include an RPG Maker license; you have to buy your own copy. There is no official name for this product, it is however affectionately called L10nTool. Nothing to do with Enterbrain in any way at all. No affiliation to PoEdit whatsoever.

Customers
BlossomSoft is using L10n Tool for RPG Maker on their current hot title Eternal Eden [demo|buy]. Buy their game. =)