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

Object tracking in Python

Some more progress. Since last time, I have discovered that there are always at least 3 ways of doing anything graphical in Python.

In this case, I was looking for ways of analysing an image and looking for specific objects. I'm doing this based on colour, as it seems easiest. Python has a function called Pixelarray which will take an image and convert it into a 2D array of individual pixel colours. For example:

Pixel[0][0] = (255,0,0) would mean that the pixel on row 0 and column 0 (top left of the image) is coloured red (the three numbers in the brackets represent the amount of red,  green and blue in the colour)

This is fine when you are wanting to change the colour of an individual pixel, but it doesn't work quite as well if you are wanting to READ the colours. For that you need some extra tweaking.

My program here has a small calibration sequence which waits for you to press space and then grabs and remembers whatever colour appears under the blue cross at the top of the screen.
Then it switches to a black-and-white display which discards all colours except the target colour.

Then, it starts tracking the object by searching for solid blocks of the target colour. Due to the grainy nature of cheap video cameras (especially under poor light conditions), lots of speckling occurs which may include colours close to the target colour. My program tries to discard those speckles by focusing on blocks where at least 90% of the pixels are the target colour. It essentially scans the whole image quickly, then when it finds a potential block it starts counting how many neighbouring pixels match.

There are software libraries that do this sort of thing much more cleverly, but I don't understand them. This seems to work for now.

The robot arm lives!

I got around to finishing off the robot arm today, and played around with the software that comes with it. It's not terribly easy to use, as it's quite difficult working out which motors to operate in order to move it where you want it to go. Also, I'm not very happy about the accuracy of the thing. Telling it to move a particular motor for 1 second in one direction followed by 1 second in the opposite direction does not result in it being back at the starting position. There's no feedback, so it can't tell where it is. I'll have to allow for the inaccuracies when programming it, which is a bit annoying. I know it was only 40 quid, but still.

 

Meanwhile the vision experiments are going well. I'm quite impressed by the speed of Python's manipulation methods. I should be able to knock up some interesting Augmented Reality things too.

Finally making some progress with the vision thing

Well, after a lot of messing around I stumbled across a far better way of doing the computer vision element for my OXO project. Pygame (which is a set of Python add-ons designed to handle graphics better than standard Python) has a camera module which, while it's not designed to work with Windows cameras, can be tweaked to do what I want far more quickly than the Python Image Library I was using last night. Now I can grab and analyse video at a much higher frame-rate, as you can see in this video:

I always feel like somebody's watching me

A tough night of tinkering. I decided to play around with the vision part of my OXO project. Specifically, I wanted to see if I could get Python to grab an image from a webcam and analyse it for objects.

I started off by googling "Python grab webcam image", which led me to install OpenCV, a high-end computer vision package. To be honest, I wasted loads of time playing with this, unable to get it to work.I couldn't find a binary, so I had to try to compile my own from source files, which is something I have no real experience of doing. After several frustrating hours I gave up and tried a different tack.

Pythom has some built-in image analysis libraries called PIL, which does some of the work for you, and there's a third-party add-on called VideoCapture which will allow you access your PC's webcam.

A bit of fiddling around and I eventually managed to get a way of quickly analysing all the pixels in an image and identifiying the ones I'm interested in. Here, for example, is it finding similar skin colours in a snapshot of me:

So, with this in mind it should not be too hard to identify a nought or cross on a sheet of paper, especially if it's a different colour.

Now it's half past midnight, so I must go to bed.

Arm news

Oh, the robot arm is mostly built, by the way. Whether it will work or not remains to be seen.

Game avoidance

I'm on holiday, which used to mean I had long, lazy days entirely at my disposal, unfettered by the need to offer entertainment, sustenance and attention to my delightful children.  Not any more. When I am off school, so are my kids. Work just becomes a different type of work, albeit one with people you love.

This week, however, I enjoy the benefits of working at a school whose half-term holidays are out of sync with my kids' school. I can drop them off and then spend six hours doing whatever the hell I want. I could go for a walk, read a book, watch a film, or play one of my many games that are piled up in a sort of entertainment "in-tray". X-Com is my current nemesis and I have to say it is kicking my ass at every encounter.

But this morning was different. I got an email asking me to look at something for work: a new feature for the music database website. It's not something I have to do, as I stopped officially supporting that thing ages ago, but still I find myself drawn back to it, like how George Lucas won't stop meddling with Star Wars until he has annoyed everyone in the universe.  (Don't go away thinking I am equating my music database to Star Wars. I'm not. My music database is way less entertaining than Episodes 4, 5 and 6, and only slightly more interesting than Episodes 1, 2 and 3)
.
The thing is, the work was interesting, and involved learning how to do something I didn't know before. I decided to use it to teach myself a bit of Ajax, which is a programming technique rather than a cleaning product, and to play around with my new local PHP testing server. Tinkering is fun and, in many ways, it IS a game. You have a goal (get the thing working), obstacles to overcome (things don't work so you have to find out where they are going wrong) and rewards (the satisfied feeling that you are making progress, both in the project and in your own knowledge). I certainly find it less frustrating than X-Com, because I'm pretty sure my Music Database is not out to get me, whereas those aliens definitely are. The green-blooded bastards.

Nocturnal Noughts And Crosses

Last night I woke up at 3am with my brain buzzing. Maybe it was because I had gone to bed early, but I could not stop thinking about a cool new project.

"What if," I imagined, "I got a robot arm and taught it how to play noughts and crosses? That would be good on Open Morning at school, and maybe the A level kids would get a kick out of tinkering with it."

I picture a large sheet of paper with a grid on it, a pupil drawing noughts with a thick marker pen, and a computer watching it with a camera before making its own move.

So, as I couldn't sleep I started googling and found one of these cheap robot arms from Maplin. It seems that some people have worked out how to program them in Python, and it doesn't look too tricky. In theory, making an arm draw a cross on a page should be manageable, and if it has trouble handling a pen then it could at least pick up and move a cross-shaped object on a table.

The trickier bit would be making the computer aware of what was happening. I think it's possible to get Python to read an image from a webcam, and it should be possible to write a piece of code to look for a circle drawn on the page.

So that should keep me occupied for a while. I bought the arm today. I'll report back when I have some news.

Android A-go-go

Been a while since I last posted, but the tinkering continues. As we're now offering Computing as a GCSE, we get to teach cool stuff like mobile app development.

The first thing we did today was a simple "virtual pet" app, which is basically the tutorial for creating Android apps using MIT App Inventor. If you fancy doing some beginners' apps, that's not a bad place to start. We also started on a Whack-A-Mole type game, which introduces graphical sprites and timers. It's a simple game, but quite fun to make. I'm not sure how advanced you can get with App Inventor, but some of the demos on the site look very interesting.

We also had the first meeting of what looks destined to be named "Code Club", where kids get together  at lunchtime each week and make cool things. First they're trying to decide what to make (web-based app or mobile "thing"), then I'll try to help them make it a reality. I can't wait, even if it means I have to learn Java.

How much have the Olympics cost you?

Quick one today. A bit of maths and some tinkering around with Flash movieclips have produced this:



It is designed to run from the start of the Olympic opening ceremony until the end of the games, and works out how much it has cost the individual taxpayer so far. Grumpy? Undoubtedly. Accurate? Probably not.

Creating Harmony

Last week I did some work on a new project, which came about from a conversation in the staff room. At school, we have a system where pupils stay with the same group of peers for three years. In years 7,8 and 9, the form doesn't change (although the form tutor does).

When they reach year 10, we muddle the forms up and re-assign pupils. Not sure why, we just do. Maybe it's because we change from five forms to six, so we need to redistribute the pupils. However, because we're nice, we don't just assign people to form randomly. We allow them to influence the procedure. Having said that, it might be fun to do it by drawing coloured balls from a big sack. Or maybe we could let a magic hat decide.

Anyway, pupils get to choose up to four people who they would like to be placed with. They also get to choose one person who they would rather NOT be placed with. The challenge is to place 100+ pupils into 6 forms, keeping the most people happy and making sure everyone has at least one preferred classmate.
It takes a teacher about 4 hours to do this job. It's a bit like filling in a sudoku. Just when you have one thing right, you realise that you have created a new problem. Sounds like a job for a computer!

I decided to see if a computer could do it more quickly. As with all computing tasks, the first part is to think about some general rules. I decided on the following:

We would measure how successful an arrangement is by giving it a score. If a person is in the same class as their chosen pupils, the arrangement scores one point per match. If they are in the same class as someone they have chosen to avoid, the arrangement loses two points. Using this scoring system, we can measure any given arrangement and compare it to see if it is better than a different arrangement. We can also grade it against the "perfect" score, which is where every person has everyone they requested. At this stage, I had no idea how easy it would be to find this perfect score, or if it is even possible.

I then started thinking about how to go about testing different arrangements. Computers are fast, so it might be possible to do a "brute force" method and test every possible combination. However, the numbers get very big very quickly. The first person has a choice of 6 forms, so does the next, and the next, leading to a possible 6^100 combinations. This is not feasible to compute in a reasonable time.
So a completely dumb loop through every combination would take too long. I needed a smarter method of testing candidate arrangements. I decided on the following algorithm:

1. Take a random pupil.
2. Look at each form and test to see how "harmonious" it would be with the new pupil (scored as previously described). If there's an obvious best choice, put them in there so long as it is not full (each form has a maximum number of pupils).
3. If there is more than one best choice, or the best choice is full, choose again based on class size. Put them in the smallest form.
4. Take another random pupil and repeat until all the pupils have been assigned.
5. Once all pupils have a form, assess the "harmony score" of the whole year group.
6. If it's better than any arrangement we have seen so far, keep a record of the form arrangements.
7. Wipe all the forms and repeat until we have either found a perfect arrangement or we give up

After I programmed it, I set it loose on the real data from last year's options. I entered all the names and the options for the actual Year 9 group and started off running the program for 1,000 attempts. On each attempt, it picked pupils at random, so there was an equally good chance of hitting a workable combination at any time. It didn't find a perfect arrangement, though. It couldn't even find an arrangement where everyone had at least one preferred classmate. I tried it again for 10,000 loops with no luck. I even set it going for 100,000 loops, and it couldn't find a perfect outcome. It was close, though. In just a few minutes, the program had managed to find a solution where all but three pupils were happy, and many of them were very happy indeed because they had all their preferred classmates. I worked out that a human could look at the solution and do some manual shuffling so that the last 3 people were happy. At the least, it would shave a significant amount of time off the 4 hours the job had previously taken.

Then I ran the program again, and it found a great solution almost straight away. And the next time, it did it again! Because it's picking randomly, it could find a solution quickly, or it could take a while. I'm sure there's a more efficient way of doing the job, but for the moment it looks like the program can definitely make a contribution here. It just needs tidying up and a decent interface so that pupils can enter their preference directly. I've even thought of a name: Harmoniza.

WGHS Rooms App Early stage

Some progress on my little app for booking rooms at school. It has a login screen and currently returns a list of upcoming room bookings...

...which is just a specially formatted web page.

Oh, and it has an icon.

Yeah, it's not going to be out-selling Angry Birds, but the important thing is to learn how it's done!

Fixing the logins and playing with app development

Well, it seems that I made a bit of a mistake when I set up the login cookie system on my Rooms Booking site. Whenever you switched computers and tried to log in, it was creating a strange limbo state where you were logged in, but couldn't do anything. Confusing. Anyway, I think it's fixed now. If you move computers, you will have to log in again. Solved.

I have also been working on an Android app to access the database. I'm not sure if anyone would use it, but really it's just an exercise for me to learn how to create a data-linked app. Screen-shots will appear as they happen.

Playing with logins

This weekend I have been experimenting with Google's login methods, so you can log my web sites using your existing Google username and password. I have it working, but I'm not sure whether it's worth implementing right now. At the moment you don't actually have the option to create an account for the Music Database or Room Booking database. I have to create them for you. It might be nice to have an account creation option, and using Google login (or Facebook Login, which seems to work the same) would be a quick way of doing it.

I have also tinkered with the fishing game, adding a second type of fish (clownfish), but I seem to have caused more problems than I solved. I think my code needs to be optimised, because it started slowing down when I started animating the new fish. Still need to learn more about sprites and the best way to animate them.

Shop's open

The fishing game will have a shop where you can upgrade your gear (better boat, better harpoon, better gun etc). So today I did a quick animation which appears at the end of each level. To test it, I have put it at the start of the game. Also, in this version you'll see the harpoon which doesn't return as soon as it grabs a fish. This harpoon will let you get several fish in one shot!

Updated source code (wave12.py)

Points: we got em

Just a quick bit of coding tonight. The starters of an "attract" screen (which is currently a simple blue screen, but is really just a placeholder for a proper title screen) and a scoring system. 10 points each for these boring brown fish, but the program has the ability to assign different point values to the different breeds of fish.

Oh, and now we have a sea bed, so we can put other goodies on the ground, waiting to be snagged.

Gotcha!

OK, so a little bit of coding before bed. Now the harpoon responds appropriately when it has caught a fish, retracting at a fairly nippy speed back to the boat, carrying the fish.

The main challenge here was getting the harpoon and fish to communicate with each other. They're separate objects which don't share scope. I solved it by making the harpoon do all the work. It detects the fish, tells the fish it has been caught, then tells it to track it all the way back. It even tells the fish when they have reached the boat, so the fish knows when to disappear. Stupid fish.

Updated Source Code (wave9.py)

Fishing Game: Now with fish.

So, after a burst of programming at 5am this morning, I have managed to make my boat's harpoon move as it should, as well as adding fish to the game.

As this is a learning experience, I have tried yet another way of handling graphics for the fish. Each fish will be animated, with at least 2 frames of animation. I could do this by storing each frame of animation separately (called fish1.bmp, fish2.bmp etc), but I have decided to organise them using sprite sheets. This is a large image containing several different frames of the same picture. When you want to use it, you tell the program to grab the appropriate section of the larger image.

You might not be able to tell, but the
two frames are slightly different.

I am hoping that this will also cut down on disk accessing, and may be more efficient.

So, I have created a class of fish which is quite adaptable. It should enable me to have lots of different fish which have different appearances, sizes, speeds, numbers of frames and score values. I can set my program to generate these fish as frequently as I wish, so later levels can be teeming with targets. Later levels will include fish which lose you points (such as endangered species) or damage your boat, (like an electric eel or a shark).

Beginners' harpoons will only be able to catch one fish before returning, but later upgrades will let you plough through a whole load of fish in one go!

Updated source files

Give me your details!

I just made a change to the music database. For what seems like for ever, the password reminder function has not been working. I know this, because I get an alert every time someone tries to log in unsuccessfully, and I see the same people trying to log into the system time and time again with the wrong passwords. I sometimes want to shout "it's fluffykitten38! Don't you remember?!"

I used to have access to a file with all my users' school email addresses, so entering them en masse was easy. I don't get that any more, so most users do not have an address in the system, which is fine until they need a password reminder. So I decided to persuade them to give me an address.

So now, when you log in, you'll be asked to enter a valid address. And if you don't enter one, you'll be prompted to every time. It might be annoying at first, but at least it will solve some problems.

Fishing game: harpoon added

Today I limited the movement of the harpoon turret to 45 degrees left and right, and created a basic harpoon. When you press space, this harpoon appears at the barrel of the gun and rotates to an appropriate angle. It doesn't move yet.

Thinking ahead, I could perhaps draw the chain from the harpoon to the boat as a simple line. That way I could draw it on the fly as it extends, re-drawing the line in each frame. This would allow the boat to continue bobbing up and down. The alternative is to freeze the boat in place until the harpoon has finished firing. This is what happens at the moment (the boat stops moving when a firing action is happening). I'll have to wait and see what works best.

Updated files

Fun with LEDs

A couple of weeks ago we went to the Bradford Media Museum to look at their new computer exhibition (good, but too small). While there, I spotted a cool rotating LED light thing (see video). I found it quite mesmerising, so I had a look at the circuit-board to see how it was made. I spotted that it was manufactured by picprojects.org, a group who encourage people to play around with little programmable computer chips called PIC microcontrollers.

The appeal of these chips is that they are very cheap, and seem to be quite versatile. You can use them for building little custom-made devices that flash lights, read sensors etc.

The downside is that they're not for beginners. You need to be handy with a soldering iron and, if you want to get the chip to do anything other than what it was pre-programmed to do, you need to get your hands dirty with some programming. From what I have seen, it's not easy programming either. These chips don't have a high-level language built in, so you're looking at something akin to Assembly language if you want to write your own programs.

That doesn't scare me though. I don't know much assembly yet, but I'm willing to learn. For starters, I wanted to get my hands on a little beginners kit and try it out, so I chose the LED mood board kit.

This thing has 9 LEDs and a bunch of resistors and capacitors, all of which need to be soldered together, and a pre-programmed PIC chip. Fix it all up, plug it in and away it goes, cycling colours through a bunch of sequences. You can write your own programs with an adaptor kit (to attach it to your PC), but I haven't done that yet.

Louis loves the light on its own, even as a bare circuit board. It's really bright, and lights up the room.

Hopefully I'll get around to programming it and then move onto the 5x5 monster, but not for a little while.

Fishing game: early stages

I'm playing around with Python, which seems to be a nice programming language. It's free to download and there are versions for all sorts of computers including PC, Mac and Linux. It is fairly lenient on syntax, with no silly semi-colons at the end of each line. You don't have to round off FOR loops or IF conditions with an EndFor or a curly bracket. It also seems to run fairly quickly and you can do lots of interesting things with it. People have written extensions to add extra functions, so it can be adapted to a huge variety of uses.

I have been working with a book called "Python Programming For The Absolute Beginner", which has covered the basics well. I'm now ready to try something a bit more challenging, so I have started a little game. This will be a "fishing" game, where you have to catch fish using a harpoon.

So far I have animated the water and created a boat which can be moved left and right using keys. There is a harpoon gun on the boat which can be rotated, and the boat bobs up and down as the waves move past.

I'll be creating fish which swim past under the boat, and you have to aim your harpoon at the fish. Different fish will give more points, and there will be fish to avoid such as sharks and electric eels. You'll be able to sell your catch to get better equipment such as a better boat, faster harpoon, stun grenade etc.

I've been getting used to object-oriented programming, which is quite a new concept for me. It's a way of organising your program by splitting it up into chunks which manage themselves. So, there's an object called Boat which has code to make it move, and bob up and down. Another object is the gun, and it need to contain code which allows it to rotate and follow the boat around.

Drawing the screen in Python takes some getting used to. There's a plug-in module called Pygame which handles the graphics, but you need to do quite a bit to get it working. In Small Basic you just have to say "here's a sprite", but in Python you have to say: "Create a sprite object. Open an image. Apply the image to the surface of the sprite. Copy the sprite's surface onto the screen's surface. Tell the screen to update itself."

You can also ignore sprites altogether and just draw the images directly onto the screen myself. In the example so far I have done both. The waves are drawn onto the screen manually, as is the gunbarrel. The boat and the gun-base are Sprites. I don't know which one I prefer. I don't even know why someone would do one rather than the other. If you know, please leave a comment.

So far, I like the way it's moving. The graphics are a touch ugly. Python doesn't seem to anti-alias, so the edges are quite rough. I'll work on tarting up the bitmaps later when I have it working properly.

Image resources are here.
Download the source code here.