25 Sep

UTF-8 with BOM

When localizing DragonScales 3 we experienced a baffling issue with an internal tool whose purpose is simply to replace text in a group of files. Those UTF-8 encoded files contain messages loaded by the game from the very beginning. However, after running the tool, the game started crashing when reading such files. By using an old buddy, fc /B, we found out that our tool was “injecting” a few extra bytes at the start of the file: EF BB BF. In short, the tool was altering the encoding of files from UTF-8 to UTF-8 with BOM. That was the cause for the crashing, as our game expects the files to be UTF-8 encoded without BOM.

What’s this BOM, anyway? Simply put, it’s just a sequence of bytes (EF BB BF) used to signal readers about the file being UTF-8 encoded. It seems such mark might be useful in some specific contexts, with some specific programs. Not our case, so we had to remove the BOM with a little batch script like this:

for /r ".\DE\scenes" %%i in (*.*) do (
  copy %%i .\tmp.txt /Y
  sed -i '1s/^\xEF\xBB\xBF//' .\tmp.txt
  attrib -R .\tmp.txt
  move /Y .\tmp.txt %%i
)

In this snippet we remove the BOM via sed. Files are those under a fictitious directory, .\DE\scenes. Those copies and attribs help to circumvent some problems with permissions of files created by our sed version on Windows.

27 Aug

Resizing multiple image files with ImageMagick

For the first DragonScales post I had several PNGs with a 1920×1200 resolution. Nevertheless, the ideal width for images in this blog is about 600 pixels:

DragonScales Logo (Black background)

DragonScales Logo (Black background)

This is a frequent issue when publishing images here. Thereby I recur to ImageMagick in order to resize sets of images. ImageMagick’s command line tools are excellent and indispensable tools for our work. For instance, on Windows command prompt, it’s enough to type:

forfiles /M *.png /C “cmd /c convert -resize 31% @file resized_@file”

That way all of the images will have resized versions, at 31% their original size, yielding a 600-pixels width approximately. Very useful. And ImageMagick is a great piece of software.

25 Feb

RenPy: Games, Rationale and The Power of a Well-Crafted Engine

More than 1 year after releasing NagiQ, I’d like to share a few bits of our experience with NagiQ, and of course, with the engine we used to build it: RenPy. First, we want to express our gratitude to RenPy’s author, PyTom, and to all of the RenPy contributors, including the kind people of the RenPy forums, who are always ready to provide useful feedback and answer our questions.

RenPy is a wonderful engine. What I like the most about RenPy is its robustness and cross-platform wonders. It feels like it might run anywhere and without ever crumbling. In fact, we released NagiQ for Windows, Mac and Linux, and deployment was incredibly easy: RenPy smoothly abstracted the differences among operating systems, and the game runs and behaves exactly the same way on all these 3 platforms. Besides, I think that several games built with RenPy have found their way into Steam and Google Play. I especially recommend RenPy for people creating its first game (NagiQ, developed in 2011, was our first title), because RenPy allows you to focus on what really matters for your game (gameplay, spaces, visuals and story.) As suggested, abstraction is a key concept for RenPy: abstraction is everywhere, it’s high-level and indeed powerful. For instance, right now I’m thinking of RenPy’s ATL, which is a very powerful way for showing displayables and applying several visual transformations (rotation, zoom, etc.) to them. And that’s sweet, really sweet. More so if you’re submitting games to publishers for the first time.

I don’t know of an engine better than RenPy for creating visual novels, and generally speaking, games in which pairs (image, text) are first-class citizens for scene design. NagiQ isn’t a visual novel, but a word game. As a word game, NagiQ is mostly based on simple images and strings. Handling images and strings with RenPy is a breeze. And not just strings. In RenPy you can show images and play music with a single line of code. A single line. You work fast, and you work safe. Further on, you might apply a tiny bit of ATL for achieving a richer presentation.

As RenPy is open-source, you can browse and study its code. You’ll end up learning quite a lot. Furthermore, knowing how things are done internally will allow you to find pathways for implementing any specific feature you might need. For example, several publishers require special handling of the quit message (Alt+F4 on Windows, CMD+Q on Mac OS X.) By knowing RenPy internals you’ll be able to handle this message as needed.

Overall, organizing your game’s scenes in RenPy is pretty straightforward. And you can even use neat transitions between scenes with a single line of code too. Normally, you’ll want a splash scene, a main menu scene, a level selection scene, and of course, the scenes implementing your main gameplay. Several of these scenes might require a lot of UI components whose creation is a piece of cake with RenPy. You’ll have the valuable help of Screens and Screen Language, which will simplify implementation and handling of your game’s screens.

RenPy is extensible. For the levels of NagiQ we required boards made of clickable cells. For doing that, we created a custom Board class in Python. And, again, RenPy proved golden: you can extend RenPy as you wish. We coded our Python class and integrated it to a RenPy scene pretty easily.

Summarizing, RenPy promotes creativity. It’s a very flexible and dynamic system, which doesn’t impose tight restrictions on the way you show and structure your content. The powerful ATL and the Screen Language are dreamy features, an outstanding support for unbounded creativity.

In retrospective, RenPy was indeed the best choice for building NagiQ: it was such a fun experience. And that’s what really matters. Long life to RenPy.