Kirsle.net
Spiky blue-haired hero...
Spiky red-haired villain! And the debug-mode actor selector window.
I made some new character sprites (the ones pictured are temporary. I created a template spriteset and then hurriedly threw these guys together so I wouldn't have to show naked sprites in the screenshots).
The engine supports multiple heroes now (the blue and red haired guys are the singleton heroes), and multiple maps (each of the singleton heroes are on different maps), and it keeps track of what's happening on each map at all times.
Next on the to-do list: teleporting between maps (and when a singleton is the last one to leave a map, the map gets purged from memory and non-singletons left on it are forgotten about and reset if the map gets reloaded in the future), and animations.
After that: on-screen text and dialogs. Then shortly thereafter there will be a public alpha release of it that you can mess around with.
See other blog posts about my game engine: KAGE.
After my first blog post about it, I've already made a lot of progress. Here's a (very alpha) screenshot I took today:
What you're seeing here is a debug mode "actor selector" window. This is a screenshot on Linux so the actor window looks ugly as sin (it'd look nicer on Windows) -- but this is only available when the game's run in debug mode so you'll never see it as an end user. The game window itself looks the same on every platform.
The interactive bits of the game revolve around actors (things that do stuff, including the hero character and in-game NPC's). There are singleton actors that exist exactly once in the entire game world (this includes the hero(s) of the game), and the other actors may exist multiple times.
In the screenshot there is one singleton actor named "hero", and two dummy hero actors who aren't singletons but use the same sprites as the hero (simply because I didn't feel like making additional sprites yet).
The debug window there just lets you choose which actor you want to control, out of the list which shows every actor on every loaded map. And it works, and you can walk around as any of the three clones there.
I'm a day or two's work away from programming an event scripting system, which will make the game become more interactive than just walking around, and then I'll start trying to make an actual game with this engine. The rest of the details (weather effects and other nifty features like that) will come later, since I want to create a game and not just make an engine.
BTW, the graphics aren't going to suck as badly as in that screenshot. I'm using stock RPG Maker graphics just for development and will be replacing those, and programming an auto-tiling system so that the tiles will blend better and not be so square.
The type of game I'll be making with it will be a 2D RPG type game, with a top-down perspective (think: Zelda, SNES-era Star Ocean, etc.). I feel that this type of game offers the most flexibility, having a wide-open game world where you can move your character in two dimensions.
I'm programming it in Perl, because I know Perl better than any other language (with Java coming in second place, but I'll avoid getting Java involved if I can help it). ;) However, it's highly possible that I'll need to switch languages down the line, so I'm future-proofing what code I am writing just in case any major changes need to happen.
For example, I like the model employed by Sierra and LucasArts when they made their games based on AGI (Adventure Game Interpreter) and SCUMM (Script Creation Utility for Maniac Mansion), respectively. Their game engines were programmed in who-knows-what language (likely C), but the games themselves--the scripts for dialog and interactions within the game--used a new, home-made programming language. This way, the game engine can be reprogrammed in a different language, and the existing games can "just run" on the new engine without any modification.
This is how ScummVM is able to run old SCUMM games; they've just re-implemented the SCUMM engine, and the existing games can "just run" on ScummVM without requiring them to be modified at all.
So, my game engine will be similar, using a new scripting language, so that if I have to scrap Perl in the future and go to Java, all I need to do is re-implement the engine in Java, and what game code I have written will "just work" on the new engine.
Now, as for the Perl stuff... I'm future-proofing my code against other Perl modules, too.
The engine runs out of a core Perl module, and it uses multiple "front-end plug-ins" to actually interact with the user. They're divided into three categories: Graphics Front-end, Sound Front-end, and Filesystem Front-end.
Perl/Tk may be dated, and look ugly as hell on Unix, but if the Tk window only consists of a Canvas widget (which is what I'm planning for), you won't be able to tell. Compose a nice picture in a Canvas and it looks the same on all platforms.
Tk Canvas treats everything you draw in them as "objects", or sprites as far as my game will be concerned. It means that once you put an image in the canvas, you can move that image around later by its ID. SDL, on the other hand, is not sprite-based, but pixel-based, so to move a sprite you've already placed, you have to erase it and redraw it. Plus one for Tk.
Tk Canvas doesn't support layers, but it does support "implied layering"... that is, each object you place on the canvas gets an implicit Z-index that's one higher than the object you placed before it. This is the same as the default behavior in HTML. When you move sprites around after placing them, they'll either stay above or below other sprites, depending on the order the sprites were drawn. Therefore, by drawing sprites in the right order, layers can be simulated. SDL doesn't support layers either, so +1 for Tk here again.
At any rate, the graphics front-end won't be too integrated with the core game engine. Instead, it will register callbacks to the engine, so Tk will say "when you want me to draw a sprite, call this function of mine and I'll take care of it."
This way, the core engine just tells the graphics front-end what to do: what sprites to draw, where to move them to, etc. and the front-end just does as it's told. This way, the internals of Perl/Tk don't get caught up in the core engine; if I need to ditch Tk and use SDL instead, I just need to make SDL respond to the same commands from the core as Tk does and all is well.
Tk doesn't have any audio support of any kind. But fortunately, there are other Perl modules that can handle audio. For Windows computers, there is Win32::MediaPlayer, and for Linux there is GStreamer.
Win32::MediaPlayer and GStreamer both can play whatever codecs the user has installed. On Windows this means it can play mp3, wav, even midi music out-of-box. On Linux it means it can play wav, ogg, and other formats that aren't patented. If the Linux user installs MP3 support, though, GStreamer can play mp3 files too!
Similar to the graphics front-end, the sound front-end registers callbacks. When the core wants to play a sound effect, it calls a method in the sound front-end to do so, and the sound front-end does it.
If I stick with open audio formats, I can have an SDL audio front-end to get sound for Mac OS X too, since there isn't yet a Perl module to play sound natively on OS X.
With such an archiving algorithm, the game could store all its data files (images and scripts) into a read-only archive, which only the game knows the password to. This stops the players from getting in there and seeing sprites for characters in the game they haven't seen yet themselves, and especially to prevent them from modifying the game's script if they do manage to get into the archive.
(By the way, my game engine will probably be released as open source software, so you'll be able to make your own games with it; just stay out of my games' files!)
Until Archive::Tyd is completed though, the game will just read files off the filesystem directly. But the filesystem front-end is there so that in the future, I can replace it with one that reads files out of Tyd archives instead.
Anyway, I've already gotten a few hundred lines of code written, and the general framework for the engine is already working (abstracting away the graphics front-end from the core, for example). I've recently completed a tileset handling Perl module which I intend to use for it.
When I get more work done, and especially when there's a playable demo of the game engine, I'll probably make a small website for it as a subdomain of kirsle.net.
0.0028s.
