think of the source code as a reference, rather than a fully working demo.

it’s christmas week, so it’s unlikely i’ll be posting anything gaming related. i’m sure most of you will be far too busy to be reading blogs anyways so have a great break. whereever you are, and hopefully santa will get you lots of games to play!

so without further ado, here is the source code: clickie

welcome to the fifth and last installment of the series. yes, i know it’s all a bit sudden, but when you see this week’s code you’ll see that there’s very little left to discuss. there will be a break between the next series of posts that form chapter three (galactic mail) of the game maker’s apprentice.

i’ll post the odd tech demo to show you what i’m up to, and as soon as i’ve made sufficient progress i’ll start posting again – so stay tuned!

last week we learnt how to deal with bullets and how to have a multitude of them on screen. this week we’re going to add the missing ingredient and enable collision detection. oh, and whilst we’re at it, we’ll also enable scoring!

first off, let’s look at the function that provides collision detection, which is lifted from linux format’s space invader and racing games.

def Intersect(s1_x, s1_y, s2_x, s2_y):
    if (s1_x > s2_x - 32) and (s1_x < s2_x + 32) and (s1_y > s2_y - 32) and (s1_y < s2_y + 32):
        return 1
    else:
        return 0

you can tell it's been lifted because i've not bothered to rewrite it to take into account the various shapes and sizes of the sprites (the offset is still 32 as the sprites were 32x32 pixels). all this function does is compare the position of the first sprite against the second sprite, so, after the offset (32 pixels) has been factored in, if the two overlap a collision has occurred.

so to see if any of our demons have collided with the dragon, here's what our code would look like.

    # iterate through demons
    for index, demon in enumerate(demons):
        :
        code to check if its time to remove demons from the list removed for brevity
        :

        if Intersect(demon.x, demon.y, dragon.x, dragon.y):
            quit = 1
            break

        :
        code to render the demons
        :

the baby dragon code pretty much does the same thing, except your score is incremented if a collision occurs.

the dragon's fireball has to test for collisions with both demons and baby dragons all within the same loop. furthermore if a collision occurs, it would be nice to make the former demon/baby dragon vanish, this one caught me out the first time around.

    # same for fireballs
    for index, fireball in enumerate(fireballs):
        if fireball.x > 640:
            del fireballs[index]

        for index2 in range(0, len(demons)):
            # NEW: 05/12
            if Intersect(fireball.x, fireball.y, demons[index2].x, demons[index2].y):
                del demons[index2]
                del fireballs[index]
                score += 100
                break

        for index2 in range(0, len(babies)):
            # NEW: 05/12
            if Intersect(fireball.x, fireball.y, babies[index2].x, babies[index2].y):
                del babies[index2]
                del fireballs[index]
                score -= 500
                break

        fireball.x += 10
        fireball.render()

as you can see from the code, you have to iterate through all the demons and baby dragons to see if any of them collided. you may have also noticed that i've switched from walking the list and instantiating each object. instead, i've use the method employed by linux format code, of going through the list and testing objects in place, referencing them by their subscript (index). this was done more for my amusement, rather than for the sake of efficiency. i'm pretty certain that sprite groups would simplify this operation through the use of group collision detection.

finally we get onto the topic of scoring. again, nothing major here. i amended the display.set_caption code so it became a formatted string and placed the score there. when a demon collides with the dragon, the last line of the program kicks in and displays the final screen to the console session that launched the game.

whilst this isn't how the game maker's apprentice displays the score, i lacked the "know how" to create a high score routine. i will have one for the next series of agd posts.

let's do one final comparison of the reference game maker and pygame versions of the game.

first is the reference video:

next is the pygame version:

unfortunately, i've just discovered that the utility i used to compress the videos before i uploaded them to youtube is too aggressive. therefore it's impossible to see the score changing in the title bar, so you'll just have to take my word for it that this video is different from previous pygame video.

whilst the pygame version is no where near as smooth or as functional as the game maker version, it's a pretty good facsmilie of it. it did take long to create, i'd hazard a guess that if each post equated to a day's work, and if we exclude the intro post, it took me four days to write something that could've been done in ten minutes in game maker.

i'm certain there's python coders out there who could write a mind blowing game in the time it took me to replicate the look and feel of the game maker game, but i'm not one of those guys. yet.

whilst working on this series of posts, i've come to appreciate how easy it is to write games in game maker. it takes away the management of trixsy things like controls, multiple sprites, collision detection, sound and scoring. instead you just get on with game design, be it difficulty level or level design. this means you've got a better chance of realising a product instead of giving up half way because of technical difficulties.

i hope you've enjoyed this series of posts as much as i've enjoyed writing them and i look forward to you joining me for the next series. until next time, keep it surreal!

prev (bullets) | about | next (???)

last week we animated our moving sprites exploding the individual frames in an animated gif, placing them in separate files, and flicking through them rapidly.

this week we’re looking at how to make the game a bit more interesting by getting the boss to fire demons at us. to avoid this becoming some dodging bullets matrix-style game, our dragon in turn has mastered the art of hadoken, so can return fire, er, balls. to spice things up a bit (read: game play improvement) the boss can also fire baby dragons at us. shooting these guys will incur a scoring penalty (scoring will feature in a later post).

the dragon’s fireball is fairly trivial, so we’ll skip it for now and go straight to the boss and discuss the properties of his munitions. the boss will fire two types of bullets, either a demon or a baby. the game maker’s apprentice defines that there’s a 1 in 50 chance of a demon being fired.

if random.randint(1,50) == 50:
	# create a new demon
    demon.x = boss.x - 10
    demon.y = boss.y - 10

the demon has a possible starting direction of sw, w or se.

	# which direction is demon going nw(1), w(2), sw(3)?
    demonDir = random.randint(1,3)
    if demonDir == 1: # nw x-,y-
		demon.dy = 1
    if demonDir == 3: # sw x-,y+
        demon.dy = 0
    # no check for 2, because at the end of the day we're always going west

the demon will move along the screen at rate of 10 pixels per frame going towards the rightmost side of the screen. because the demon can veer towards the top or bottom of the screen, we need to make sure when it reaches the edge of the screen it changes direction (bounces).

	demon.x -= 10

    if demon.dy:
        demon.y += 10
    else:
        demon.y -= 10

    if demon.y > 290:
        demon.dy = 0
    if demon.y < -10:
        demon.dy = 1

so how does our demo look now?

looks good eh? or does it? upon closer inspection you will notice that some of the demons seem to vanish before they even get close to the dragon. it didn't take me long to realise that the demon object was being reused everytime it was being fired! this makes for great ammo economy for the military, but a crap gaming experience for us.

realising the error in my code, i needed to find a way to spawn multiple bullets from the same class. luckily our demons aren't too complicated; they have a fixed speed and their x-axis starting position is always the same. this means they move at a constant speed one after the other. at the moment (we've not yet broached the topic of collision with the dragon or his fireballs) they move in an orderly queue, but to avoid confusion with the python term "queue", here we'll use the term "list".

i'm not going to teach you about python lists, queues and whatnots. there are loads of people who do this better than i ever could. instead i'll tell you what you need to know coming from a structure language background like perl, batch and c.

i should probably point out that by now i'd stopped looking at the linux format code for pyinvaders, and whilst the code may look similar it isn't.

whilst i don't think you need to initialise an array (pythonically known as a list) i think it makes for easier reading. you just need to create an empty list i.e. demons = []

to add an item to the list, call the append method i.e. demons.append(demon_object). yes dorothy, you can append objects with no fancy incantation in python as you would a scalar (simple) variable type.

you can get the number of items in a list using the len keyword i.e. len(demons).

finally, to delete an item from a list you can use the del keyword and specify the index (position) of the item in the list. i.e. del demons[5]. before someone carps about the fact that you can delete an item by specifying its name i.e. ldell list['x'] i haven't found out how you do this with an object. so if you know please post a comment and share the knowledge.

also i've refrained from using the pop function (fifo) or push(?) pop(-1) (lifo) because whilst the current code's behaviour is a queue, when we enable collisions we'll start to see random removal of items from the list i.e. items will disappear out of sequence.

now, i could leave it at that, for most coders. you'd be able to track the current index by incrementing a counter as you looped through the list. but, i must share this code i found. it allows me to walk list whilst tracking the index. check out the test code below (it's a proof of concept script) to see what i'm harping on about:

for x in range(0,30):
	num = random.randint(1,3)
    if num == 3:
		print "%d: ADD bullet" % x
        bullets.append(Bullet())

    for index, item in enumerate(bullets):
        if item.x < 10:
        	item.x += 1
        else:
			print "%d: DEL bullet" % x
            del bullets[index]

        print "%d: bullets: idx:%d -> val:%d " % (x,index,item.x)

don't get too tied up in the specifics of the bullet class, its only got one method that initialises the single variable called x. instead, look at the for/in loop and the enumerate keyword. basically the for/in loop is the same as the the foreach in perl and php. enumerate returns two items, the first is the current index and the second is the object reference.

i remembered the nightmare of trying to learn passing object references and values in java when i was in uni. in python its seems so much more straightforward, all you need to know is that when you've obtained an object from the list through the for/in loop you are now dealing with that object. you can tweak it to your heart's content, and then when you step to the next item in the list, you have packed it away (along with its mods) until you go through the list again.

coincidentally, the proof of concept code i've given above is pretty much the same code i used for the demons. there's the testing code to see if we need to add a new demon to the list. then there's the for/in loop which walks through the list, checking to see if demons have to be removed from the list because they've gone off screen. if they haven't then their x axis is updated.

the directional code to determine y starting position w, sw, nw is placed with the testing code. and the change direction code is placed within the for/in loop.

let's have a brain break here and see how our video looks now.

first off for reference the game maker version

and now pygame version, hopefully this is an improvement from the previous.

the baby dragons are a rarer event and only occur with a 1 in 100 chance. they only move in one direction from right to left, and their offset is based on the boss's y position. finally to add the trickiness element, we make them marginally slower than the demons by making them move 8 pixels per frame (compared to the demons' 10 pixels per frame.)

the dragon's fireball is almost identical to the baby dragon's in so far as it moves in one direction towards the right of the screen and is triggered by the spacebar. the speed is the same as the demon's.

rather than waste valuable reading inches i'll add a link to the full source code here. you'll also find the earlier version of this code where we have a single demon being fired repeatedly.

so whilst i'm happy with the progress, the game itself is not very playable at the moment. the keyboard events stop as soon as you press a key. and there's a distinct lack of collision detection. as with the slight jittery animation last week, i'm going to park the lack of non-blocking keyboard control. i can see the seasoned games developers shaking their heads and tutting alot, but for now the lack of collision detection is preventing this from being a decent game.

so tune in next week for our next installment!

prev (animation) | about | next (collisions)

Lou bought me a new game for the Wii called Trauma Center: Second Opinion. It’s a game about surgery which combines memory and skill. The memory comes in the form of a series of procedures you have to do i.e. make an incision, extract or drain, etc. The skill is like the board game Operation where you have to pull bits of glass out of a wound using forceps or re-arrange bone fragments.

It does help if you’ve had a few goes of Wii Play as you will be required to rotate and tilt items around. On the whole the on-line game review sites (IGN and GameSpot) got it right, this game is fab. You can feel the tension mounting as the clock ticks down and as the vitals of your patient falls. I also think your assistant yelling you when you screw up certainly adds to the atmosphere!

So far each operation lasts five minutes, I can tell you that you will feel drained in some of the later procedures. My favourite surgical tools are the forceps, which you have to squeeze the trigger button and main button on the Wiimote to activate. I would’ve chosen the defibrillator if it hadn’t been so hard to operate as pushing the nunchuck and Wiimote towards the screen to make contact was great fun.

My only gripe about the game is the limited dialogue and the copious amount of text to read rather than getting in voice actors. I can appreciate that by only having a few key phrases they could localize this game fairly quick and without great cost, but it makes the game feel dated, luckily there is a skip button which bypasses story line and operation briefing.

So far I’m usually completing an operation after failing once. Usually I work out what I’ve forgotten and remember it for the 2nd attempt. Which for difficulty level seems okay for me.

I’ve included a YouTube video that gives you an idea of gameplay below, you won’t see it if you’re using a news reader like bloglines or google reader. So view it directly on my website.

Until now.

Metroid Prime 3 appears to push all the right buttons. There’s heavy use of the Wiimote and Nunchuk. And the graphics are as colourful as a level created on Unreal Tournament where the designer has done too much acid. And according to the review below, it appears to be the perfect balance in terms of gameplay and challenge.

Methinks I shall be saving up lunch money for this title. This is all for the sake of research you see, can’t create a blockbuster game if I have no peers to compare against.

I so did not see this one coming, for my birthday Lou got me a Wii! I think I must’ve gone on about it so much, the only way she could get me to shut me up was to buy me one!

\m/ I have to say the Wii rocks hard like Black Sabbath! \m/

The Wii remote when utilised wisely in a game like say WiiSports’s tennis, bowling and boxing is a simply amazing way to control game play.

As with any new technology that I get, I have to find out its hackability so I will be updating this blog on my progress. My planned projects for the Wii console are:

• Playing home brew games without modding the console.
• Review Wii Flash games that are actually worth playing.
• Using the Wii as a media player with the Mac streaming audio and video.

I’ll also be reviewing any of the Virtual Console titles I buy (so far its just Metroid for the NES) and websites that work well with Opera’s implementation of their browser on the Wii (AKA The Internet Channel). I guess you can work out what I spent my first 1000 Wii points on ^_^

For now here’s me and Lou’s Miis (gaming avatars).

I used Lee Chaolan, here’s the end I got:

^____^