What?! Harmoniza is evolving?!

It's half term and I have been away. However, I have been tinkering a bit. I made a program that models 2D collisions between balls (link to come) and I have made some significant improvements to Harmomiza, ahead of its proper launch.

Previously, Harmoniza used a big chunk of luck to find the best arrangement of groups. Leaving it running for a long time gave you better results, but only because the longer you left it the more likely it was to stumble upon a good solution. The new version uses an evolution algorithm. It still uses the same semi-random method to find a base solution, but then switches to a system which makes small changes and tests them to see if they make an improvement. If the new form lists are better, they are saved and the process continues from there. If  the "mutated" version is no better, it is discarded. This means that leaving the program running allows the score to "ratchet" up. Already it is giving good results in less time than before, and is much better than the pen-and-paper method.

I think we're ready to go live!

Coupla three things...

It has been a while since the last post, so I though I had better fill you in on some of the cool things I have tinkered with recently.

This post is about new Dudegame bits, my Harmoniza system and a little Logic Gates widget.

Read Me

A few new developments to the Dudegame now, some of which are obvious, some of which happen behind the scenes. If you want to check out the Python source code, click the new link in the right-hand column.

First of all, we have a health bar. I wondered how to show the player's life ebbing away when he touches monsters. Should it be a health bar getting smaller? A simple number? Maybe a face gradually turning into a skull?

In the end I decided on the classic: hearts. And, just to make it a little different, hearts which can be split in half. See how it works in the video below.

I have also added an interactive object: a signpost. I originally created a single class of interactive objects which could be customised to behave in a number of different ways: signposts, talking people, switches, moveable blocks etc
Since then I have decided to create each type of object as a separate class. I think that will make it easier to maintain later as I add more types. The signpost type has been implemented in the video.

Finally, I worked out a simple method of layering to maintain the pseudo-3D effect of the screen. Monsters placed higher up the screen appear to be behind you, and objects lower down appear in front. This has not been applied to the other interactives, but it should not be hard to transfer the same principle.

Dude meets Blob

I have knocked up a little blob creature in Fireworks and added it to my game. This one is a Blob monster, because I thought that would be the easiest to draw and animate. I have implemented collision detection, but at the moment nothing happens when you touch the Blob.

(And yes, I am aware of the irony when I say "my guy has no life")
I need to develop some sort of life gauge to indicate Dude's state of health.

Monster pathfinding

I once wrote an algorithm which enabled a computer character to find its way through a maze. I didn't really know what I was doing at the time, but I got the idea when I heard about some research into robots that work together to solve problems. I came up with the idea of a character that replicated itself throughout a maze until it found the exit, then sent a message back through all its clones to the origin point, and then highlighted the path. Not necessarily the best path, but a path nonetheless.

Then I heard about a bit of research which showed that if you put a blob of slime mould in a maze, it eventually grows into a shape that shows you the most efficient path through the maze. Here's a video which is in German, but looks quite cool:

I didn't know it, but I had stumbled upon something similar to the A* Pathfinding algorithm, which is a commonly used method for giving computer characters some form of artificial intelligence.

Think about a game where a monster is trying to get you. The monster might just walk towards you all the time, but what if there is a wall in between you and the creature? Should it just stop, or should it try to get around the obstacle to get at you? If so, which direction should it go? And what if it's not just a single obstacle, but the monster is trying to navigate a field of obstacles to get to you?

This sort of thing goes on all the time in games. Think about a game like Starcraft, where you click a point on a map to send troops, and they have to walk around rocks or lakes to get there. Pathfinding has to happen often, and it must happen quickly. It looks like the A* method is popular and powerful, but I don't think I can use it my Dudegame because my maps are not simple grid systems. They have obstacles all over the place, and not in regularly spaced intervals. I could rework the mapping system, and make all the obstacles fit to regular patterns, but I don't want to. I think for now I'll just use dumb monsters that either follow a preset path or just move blindly towards you. I don't think Zelda had clever monsters, and that seemed to work out OK.

8-way movement

Just a quickie:

Dude now has different animations for each direction of travel. This seems to work well in the new version of the program.

Little top-down adventure engine: Dudegame!

In the interests of sharing, here is something I made which was prompted by our Code Club at school. They asked if they could make a top-down RPG game in the style of Pokemon or Zelda, so I though I'd better look into how to do it. Doing so has helped me understand Sprites a lot more clearly, so I should be able to go back and make better progress with the fishing game I started earlier in the year (I was having trouble with animation slowing everything down, and I think I know what I was doing wrong now).

Dudegame is really just a set-up for a game engine, and allows you to create any number of "rooms" which represent the different screens of a Game-boy style game and navigate around them. I have tried to make it as flexible as possible, to allow for expansion and customisation wherever possible.

Each "room" is stored as an object, and contains a number of invisible "obstacles" which designated areas that the player cannot enter. By positioning these carefully over the prerendered backgrounds, I can give the illusion of a 3D environment, so you can walk in front of this house and the rocks, but not through them.

I have also implemented two kinds of "portal", which allow the player to move from one room to another. Standard portals are placed at the edges of the room, so the player can go to the next screen and reappear on the other side.
Special portals would be placed over the door in rooms like the example, so you can be whisked away to an interior room.

I have done some basic animation on the main character. He is called "Dude", which is a suitably mundane name. (Fun Fact: the character of Guybrush Threepwood in the Monkey Island games was so called because he was originally created in a graphics package that saved images as "brushes", and his graphic was called the "guy-brush")

Dude has some animation frames on his arms and legs, but only faces forwards. That's not a hard thing to change, so that may be the next update.

Next big addition has to be monsters. There will be a few different types: ones that move in a set path, ones that more randomly (avoiding obstacles) and ones that move towards the player. The last one is harder, as some sort of path-finding will be needed to avoid obstacles.

Then we need to add a weapon for Dude. Then interactive elements (signs, for example), then friendly interactive NPCs. And monster projectiles. And an inventory. And some sort of quest.

Or, as seems more likely, I'll get distracted by something shiny and forget about it.

Here's a link to all I have done though. Feel free to use it:

Dudegame source files