Porting an RPG to Flash: Part I – Introduction

(Originally written on 7th April 2010, mostly)

Coming up for two years ago now, I decided to make a Flash version of one of my old games, an RPG called Return of the Etirites. And for some reason I decided to document the process in a sort of blog-like style, even though back then I didn’t have a blog to publish it on. But now I do, and it might be of interest to someone… so here it is. I’ll talk a bit about how the original game from the old DOS days was put together, and how I updated it to run in a web browser.

What is Etirites?

Return of the Etirites was my attempt at an old-school 2D RPG, very much influenced by Mystic Quest on the Gameboy (I loved that game!). I originally wrote it for my brother’s 13th birthday back in 1998.

It ran on MS-DOS. The original version still works very well in DOSBox… in fact it still ran on Windows at least up until XP.

Disclaimer: I designed it and wrote the script in maths class when I was 16 and it shows. I also drew all the graphics myself despite having no real talent for it and that shows too. Even by the not-very-high standards of ancient 8-bit-style RPGs, the plot is laughable. Some of the characters and monsters and locations are loosely based on real people and places, some not. I’ll leave you to guess which are which.

If you still want to play it despite those warnings, the Flash version (the version I’m writing about creating here) is online here. Eek, I can’t believe I just shared that with the world!

Why port it to Flash?

At the time Flash seemed like a good way of putting together fun little 2D games that anyone could run easily, just by visiting a webpage, and I liked the idea of getting into that. Flash is declining in popularity now due to the upcoming HTML 5 and the fact it doesn’t work on some modern machines (notably iPhones and iPads), but I suspect it’ll still be around a little while longer yet – last time I looked at HTML 5 it didn’t seem ready for creating moderately complex games in.

I decided to convert a game I already had to Flash rather than starting from scratch so that I wouldn’t have to grapple with thinking of an idea, designing levels, drawing graphics, all of that stuff at the same time as learning a new programming environment. Because I designed Etirites I already knew it inside out and had access to all the game content, so it was a lot easier for a first Flash project than making a brand new game.

Inside the original game

As I said, the original game ran on MS-DOS, and like most DOS games it accessed the hardware directly for most purposes rather than going through an operating system like modern games do. It ran in the old low resolution VGA mode (320×200 with 256 colours) and reached 70 frames per second on most computers with very smooth scrolling – I’m still rather proud of that. The source code consisted of about 16,000 lines of C (compiled with the DJGPP compiler) and 4,000 lines of i386 assembly (assembled with NASM, after some pre-processing by a tool of my own making). None of the original source code will be re-used in the port; the whole thing will have to be rewritten in ActionScript 3, the Flash programming language, but having access to it will be very useful for seeing exactly how things work.

(I couldn’t mention DJGPP without commenting on the fact that the website that hosts it, Delorie Software, is the only site I know of that still looks pretty much exactly the same now as it did when I started using the internet in 1997!!).

So that’s the code. The data files (assets, if you prefer) – graphics, tunes, maps, etc. – of the original game are almost all in custom formats, so one of the first things I need to do is work out how I’m going to convert them all to Flash-friendly formats. The original game packs everything into one single .DAT file (also a custom format… a bit like a Zip file but without the compression), but luckily I still have the individual files that go into it. This is what’s in there:

  • Various .LEV files. These are the tile maps for the area backgrounds, telling the game engine where there should be ground, walls, trees, water, etc. This is a custom binary format, but a very simple one: just a width and a height followed by an array of bytes specifying the tiles.
  • Various .LSG files. Most of the graphics are in this format. It’s a custom binary format that can have multiple graphics per file. It has very simple RLE compression and all the graphics are in 256 colours, in the standard VGA palette. Both movable sprites and background tiles are in this format. For the sprites, colour 0 represents transparency. I seem to remember I created these using my own graphics editor program called “VGAEdit”.
  • charset.dat. This is the game’s font, a simple 8×8 monochrome bitmap for each character. The format is the same as a Spectrum character set, and probably the same as various other old computers too.
  • etirite.pal. This is a copy of the RGB values (each ranging from 0-63) for the standard VGA palette.
  • Various .LSM files. This is the music, stored in a sort of simplified MIDI format. I seem to remember it’s mostly the same as MIDI but the timing information is simpler. The game code contains drivers that can play this on Adlib/SoundBlaster FM synths (badly!), or via general MIDI (better).
  • A couple of .TIF files. These contain the bigger graphics. One is the game map, the other is the crossed swords graphic for the menu screen. I can’t remember why these aren’t in LSG format like all the others. Possibly the LSG format had some size limitation on the graphics and they were too big.

Hmmm…. so what do we do with all those?

Data Conversion

The graphics will need to be converted to a standard format that Flash can use. PNG is probably the best one as it’s better than JPEG for storing pixel-art-type graphics. For the LSGs I will write a program to convert them to PNG, putting all the frames from each LSG into a PNG side-by-side. A simple C program using libpng should do the trick. The palette file will come in useful for translating them from 256 colour indexed mode to standard 32-bit RGBA. I will probably write a similar program to convert the character set to a PNG, since it would be nice to have the game’s original fancy font in the Flash version.

Hopefully the trusty Gimp (god how I wish they’d change that name) can open the TIFFs and save them as PNG… if not, I can look at how the original game code reads them and use that to make my own conversion program.

One thing that strikes me is that 320×200 is a very low resolution these days, if I leave the game at that size it’ll appear as a tiny box on most people’s screens. Even 640×400 would be much better, but doing a simple scaling up would look awfully pixellated. Maybe one of those nice up-scalers that a lot of old machine emulators use could help? I could try incorporating one into the graphics conversion program and see how it looks, scaling all the graphics up to maybe double their original size. Of course if it “mostly” works I could manually tweak the ones it doesn’t look so good on.

The music… somehow I need to get it into MP3 format for Flash. Probably the easiest way is just to record the output from the original game (running on DosBox using general MIDI) and then encode that into MP3… saves faffing about with the complexities of the LSM format which I don’t really fancy doing.

The .LEV files could maybe be left as they are and I could write ActionScript code to read them directly, as they’re very simple and there isn’t really a standard format (that I know of) for that sort of thing anyway. Apparently Flash can read binary data so it should work, but if it turns out to be impossible I could write a simple converter to turn them into text files, or to embed them in the source code, or something.

That just leaves the palette file which won’t be needed anymore once the game is running in glorious 32-bit true colour!

There is other data hard-coded into the source code (for example the story sequences, the area information including what objects start where, and the frame sequences for animations) but I’ll get to that in due course.

Next time: the actually nitty gritty of the data conversion!

One thought on “Porting an RPG to Flash: Part I – Introduction

  1. Pingback: Porting an RPG to Flash: Part II – Starting the data conversion | GCat's Technical Stuff

Leave a Reply