Create-ivity

Lacking inspiration?

Recently there have been some threads about ‘how to get inspiration’ on the Gamedev.net forums. Sometimes it feels as if every good idea is already taken, and that every addition or twist you come up with turns out wrong.

That was written in a game design board, but I’ve also seen it come up many times on level-design forums. Take Counter-Strike for example: so many custom maps have been created that there’s virtually no original setting left. Or Half-Life 2: try to come up with an original physics-based puzzle for once. That’s harder than it looks.

Here’s how I handle it

Continue reading How to get inspiration…

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.

I promised to write about that ‘other game’. It’s a school project focussed on AI. Me and a friend are writing a turn-based strategy game similar to Advanced Wars, and some other friends are writing AI applications that can connect to our game. We’ve chosen for a Flash-based front-end, connected with a Neko-based back-end that handles the connections with the other AI apps. From there, it’s simply watching those AI agents duke it out against each other.

As for Aural Fighter, it’s slowly becoming better and more playable. I haven’t done much on it last week due to being ill, but I’ve done some things nonetheless. Most of the missile weapons are now working: the guided missiles and splash damage missiles are pretty fun to play with and they’re quite powerfull. I’ll tweak the exact values once I can playtest some of the later levels, but for now, it’s fun to blow up waves of enemies with splash damage missiles.

The first level is nearing completion, too. I only need to do some art for it and add several more enemy waves. I’m also working on the first endboss, which is going to be component-based. I’ll probably write some more on that in a later post.

It’s time for another progress update about Aural Fighter. Though college is taking quite some time these days, I’m trying to spend as much time as possible on this game. This week, I’ve started work on an in-game level editor and I’ve drawn some enemy fighters and made a Python script that allows me to easily create new enemy types by simply editing a text file. This data is converted into HaXe code, so while it’s easy to modify some values, it’s also compiled as code, which means it doesn’t need to be parsed at run-time.

I’m thinking about doing different sets of enemies, each with a distinct style. This screenshot shows some of the first set I’ve been working on. It’s all still early work, but comments are welcome.

Breaking away blocks now actually works! I had to implement some pathfinding to pull it off: I’ve used vertices as nodes and edge lengths as path costs, to find the block with the smallest enclosing, from a given start and end vertex (the intersection points). It does the job quite nicely now:

I’ve ported this game to C++, using Haaf’s Game Engine, partly because it ran too slow in Python (after quite a bit of shooting around, of course), and partly because I needed a solid debugger for further progress. The whole project is now quite a bit past it’s prototyping stage anyway: I know what kinds of issues I need to solve, and I know how I can solve most of them:

• removing any leftover edges in the old shape - a few comparisons between the two blocks should tell which edges have become obsolete
• making some other edges border edges - again, just a few comparisons
• making sure the new block doesn’t have it’s edges inverted - in some cases, new blocks have inverted edges, and I don’t know yet how I’ll solve this
• determining when a loose path should become part of the new block - this one is more tricky, but I think comparing angles between edges should suffice
• determining the surface of the new block - tricky, I think I’m going to triangulate the shape and take the sum of the surfaces of the resulting triangles
• determining the center of the new block - again, tricky, but triangulating the shape and taking the average center should do the job
• and finally, some debugging here and here…