Joust

It has been a while since my last post. Since last time I have been playing around with learning Java and a dash of Unity. I have also installed Coder on my Raspberry Pi (and can't really see the point, to be honest). Mainly, I have been working on resources for my new A Level Computing group. Work has to come first!

However, I have had time for a little tinker this week. I decided to brush off some old sprites and have a go at recreating Joust, an old arcade game from the 80s. I'm doing it in Python/Pygame, using an object-oriented method.

I have the following classes:

playerClass: A class which will only really contain the player sprite

platformClass: a class for platforms, which can have different positions and image attributes. I know the platforms in Joust don't move, but this allows me some flexibility to re-use code if I need it.

I can foresee the need for:

enemyClass: the enemies will need to be able to think for themselves a little. Not sure how, yet.

eggClass: when you hit an enemy, it turns into an egg. It needs to roll around, come to a halt and eventually hatch if left alone.

lavaClass: ? To detect if the player or an egg has landed in the lava?

Anyway, I may not get that far. At the moment I have been concentrating on the control and "feel" of the player sprite. It needs to have momentum, be affected by gravity and respond properly to the player's "flap" command. It needs to detect when it is close to a platform, and switch between walking and flying as appropriate. When flying, it needs to bounce off the sides of platforms. I think I have done most of this so far. At present I have only populated the level with one platform, and the player seems to behave itself around that platform. I haven't programmed what happens if it approaches a platform from below yet.

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.