Create-ivity

I recently stumbled across Neko Media Engine, a SDL wrapper for haXe. I decided to port one of my Flash games to NME, to make it a stand-alone application. I got it up and running after modifying my framework for a few hours. It turns out that, with relatively few changes, my framework can be used for ‘normal’ games just as well. I’m starting to like haXe more and more now, especially with such libraries around.

The developer of NME, Lee Sylvester, has recently teamed up with Hugh Sanderson to create Neash: a Neko library that provides the Flash API for Neko applications. In other words, we’ll be able to use (almost) the same haXe code for both Flash and Neko applications… That sounds interesting!

Last week I started with my final internship. It’s, again, at Triangle Studios. This time, there’s no mobile games to work on though, but Nintendo DS titles. I’m working on something pretty interesting, but for now that’s about as much as I can tell.

As for spare-time development, I plan to release AI Wars next week after some minor fix-ups. I’m then going to continue work on the surprize I mentioned last month. After that, I’ll either do another small project in-between or I’ll immediatly take up work on Aural Fighter.

The framework I’ve been building for Aural Fighter has been tweaked and refactored all the way through AI Wars, the surprize project and a few other prototypes. I recently streamlined the rendering system: animated sprites are now simply a matter of creating a single sprite sheet and writing an animation data text file, rather than creating multiple numbered files. At compile-time, this animation data is compiled into the .swf file. The sprite loading process then attaches that data to the loaded sprite. There are still a few things I’m working on, such as color remapping and fading filters, but the framework is steadily moving towards a point where creating new games doesn’t require me to add new functionality anymore. Which means I can focus more on the actual games and less on the technology behind them. Which is good.

AI Wars is done

It’s finished. The Flash frontend and Neko backend are done, and my classmates have produced a nice AI client for demonstration purposes. The whole package is roughly 0.5 MB.

To make things a little easier, I’ve written a batch file that starts both the backend and the frontend. All that’s left then is connecting the AI clients and starting the game.

The gameplay

Continue reading AI Wars is looking for AI agents!…

Here’s a small image hinting at the surprize I wrote about in my last post. It’s a puzzle game, it’s almost completely finished and it includes an editor. I’ll post more info about it later, once it’s fully playable and polished.

Meanwhile, I’m finishing up AI Wars - it’s almost done now, except for a few communication issues. I’ve also written a few additional Python tools. Since I’m painting quite a few tilemaps for Aural Fighter, I figured a few tools wouldn’t hurt. Today I added one that takes an image, asks for the desired tilesize, and outputs a serie of unique tiles as separate images. It’s using Python Imaging Library (PIL) to load, compare and save the images. It then optimizes them, using PngOptimizerCL, the command line version of PngOptimizer. The tool took me about an hour or two to create, and it’s less than 100 lines of code. And, except for the optimization phase, it’s quite fast, too.

Something has bugged me for quite a while: Aural Fighter reacted slower and slower the longer I played it. I was absolutely sure it had to do with the rendering code, but even a bare-bone test game slowed down after a while. Confused, I ignored the issue for a while, but I realized I couldn’t release Aural Fighter with such an issue unresolved, so I just had to fix it.

But whatever I tried, nothing seemed to cause the problem. Finally, I decided to create a minimum piece of code that still reproduced the problem, to post on the HaXe mailing list. While doing so, I found out that the game only stopped respondeding after a lot of keypress events had happened, not just after some time. I was confused: was I handling input in a wrong way? It should be a perfectly normal method… but while stripping away unrelevant code, I finally figured it out: I had added another keyListener in a pre-loader frame, one that was never removed afterwards. This one started to intervene with the other keyListener. Removing it finally solved the problem.

On a side-note, I’ve added shadows to all enemy fighters and I’ve drawn a few new enemies and tiles. I’m also working on another game - as a school project - so Aural Fighter is proceeding slower as desired, but the experience I gain from that project should be pretty usefull for later games. I’ll write some more about that project later.