Create-ivity

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.

Level 1, but now with updated art. It’s still not really final - the large trees could use some work, the jungle borders are still somewhat flat and the water is too obviously tiling - but it’s definitely moving in the right direction. It took me quite some work to make sure the enemies were sticking out enough from the background. I’m using more saturated and bright colors for them, while I try to keep the background darker and less saturated. It surely takes some testing to get right.

So, that’s what I’m working on now, and the more I do it, the more I get the hang of it. Pixeling is fun and with my in-game editor in a usable state, creating these levels is actually quite enjoyable. Let’s hope it shows in the final product!

Nibbler was my first Flash game, and more or less served as a learning project. I’ve made it public on various sites however, and closely monitored how people reacted to the game. Here I present you a little postmortem. I’ve gone through the development and publishing process once now, so why not learn from it?

The good…

The game was polished. I’ve spent some time tweaking the menu’s, making it all look consistent, stylish and, well, just trying to think of all things that a Flash game needs, like a pause and mute button, and so on. This was noticed, luckily - although it also looks like I could make some things more obvious, like which hotkeys map to what actions.

I’ve actually finished it. I’m a perfectionist by heart, and that’s why I’ve only released a handfull of levels in over 6 years of amateur level-design. Auch. For this game, I was determined to just get it done. I wasn’t happy with all of the levels, and I wanted the game to be longer, containing more gameplay elements, but at some point I decided enough was enough.

Continue reading Nibbler postmortem…

It’s been a while since my last update, but that’s because I’ve been busy. Aural Fighter is moving along nicely, even now that school has started I managed to continue development at a steady pace. Behold, the main menu (including flying aircraft for decoration):

I’ve also been working on the collision system a bit - I’m rolling my own routines rather than the standard movieclip hittest functions, because all I need are some basic rectangle-rectangle tests. No real problems here: I’ve done it before and I did it again, everything’s working fine. So, I can now blow up some enemies or blow myself up by crashing into them. Fun!

However, I started running into some performance issues. Nothing bad, it seems it was most troublesome on my own system, but the game just wasn’t playing 100% smooth. After some research I found another approach at rendering the game: using BitmapData objects as surfaces instead of movieclips for everything. It’s a bit more low-level, but much more how I’m used to work with 2D, so I quickly wrote a small rendering framework around it. It works like a charm. Too bad there’s no neat way to compare the performance, but at least it feels a bit smoother now. It runs fine on the other systems I tested it on, too, so I guess it won’t be a problem.

I’ll soon move into the art phase: large parts of the logic are done and dealt with, except for a few menu’s and the weapon selection system, so after that, it’s creating tiles, levels, enemies and scripting enemy waves. Yay! :)

In other words, I’m working on a second Flash game, and here’s a screenshot of the progress so far:

As you can see, it’s a top-down scrolling shooter. The above is still rough, visually, but that’s why it’s an alpha version. Your fighter will have several weapon slots, so you can use various weapon combinations. Later on in the game, you’ll be able to fit more specialized weapons on your ship, after a bit of costly re-engineering. Heavier weapons drain energy faster however, so your shields won’t recharge as fast when you’re equipped with 4 white star cannons, if at all. I’m still thinking out the exact dynamics for this however, so we’ll see. More news coming up soon, I hope. If my last school year isn’t too demanding, of course.

PS: If you’re interested in playtesting this game once it’s in a more playable state, don’t hesitate and leave a comment here with some contact information, or, if you prefer that, you can e-mail me through my portfolio’s contact page. If you’ve got some idea’s or suggestions, you’re welcome too. Thanks! :)