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)

whilst moving sprites is relatively easy to do, it would appear that animating them is trickier to do in pygame; there are no builtin animation routines. just to clarify what i’m looking for, if you give game maker an animated gif it will cycle through images. it’s small graces like this that make me appreciate how easier it is make games in that environment.

a quick search on “teh interwebs” revealed that i was not alone in wishing there was native support for animated gifs. i was even willing to switch to png format (the only other image format that support rudimentry animation) if it had pygame support! i came across someone who was toying around with the idea of using python imaging library (pil) to explode an animated gif into individual pygame image objects. i was starting to head towards this approach until i saw that [pil] wasn’t platform neutral and wasn’t nearly as easy to install as its stablemate pygame.

in the end i decided to go for the manual process of extracting the individual frame from the animated gifs. after a bit more research, i discovered this bash script that uses imagemagick to extract the individual frames and create new images based on them.

i revised the the sprite class’s render method to cycle through the frames by using this code written by jaime moreno. i like this code, because it doesn’t lock up the main loop whilst trying to animate the sprite.

def render(self):
	# A nice bit of animation code (cowMooDelay.py) written by Jaime Moreno
	self.pause += 1
	if self.pause >= self.delay:
		self.pause = 0
		self.frame += 1
		if self.frame >= len(self.frames):
			self.frame = 0
		self.bitmap = self.frames[self.frame]

		# own little bit to transparentimatize   each frame based on
		# the colour of the bottom left pixel
		self.colorkey = self.bitmap.get_at((0,self.bitmap.get_height()-1))
		self.bitmap.set_colorkey(self.colorkey)

	screen.blit(self.bitmap, (self.x, self.y))

next up is the sprite class method to preload the multiple frames, i modified the code to allow me to specify the number of frames in an animated sprite (during object initialisation). i also amended the file mask to match my gif splitting tool’s naming convention.

def loadFrames(self, numFrames):
...
	self.frames = []
...
		for i in range(1,numFrames):
			imgName = os.path.join("data",self.imgPrefix + "-10%d.gif" % i)
			tmpImage = image.load(imgName)
			self.frames.append(tmpImage.convert())

so as an example of initialising an animated gif i’ve used the dragon which has 6 frames of animation. the gif splitting turns this into Dragon-101.gif, Dragon-102.gif, … Dragon-106.gif. the object initialisation code would look like this:

dragon = Sprite(20, 200, 'Dragon',6)

finally i wrote a bit of code in the sprite class to avoid having to create a new class for sprites that are not animated. it’s a bit of a bodge, but the logic goes like this, during object initialisation if i specify the number of frames as 1 i.e.

fireball = Sprite(0,480, 'Fireball.gif', 1)

this triggers the loadImages() method to use the image prefix as the actual file name to load.

def loadFrames(self, numFrames):
...
	if numFrames == 1:
		imgName = os.path.join("data", self.imgPrefix)
		self.frames.append(image.load(imgName))

...

so how does my pygame port of evil clutches compare? here’s the game maker reference video.

and here’s the pygame port

as you can see, it’s slightly jittery, i gotta admit i’m stumped as to cause of this. for now its usable, i’ll post an update if i work out cause. if anyone knows why, please post a comment. so tune in next week when we have to take cover as the bullets start to fly!

prev (sprites) | about | next (bullets)

sprites are ludicrously easy to move around in game maker. place them in a room (the screen) and make sure the object sprite reacts to the edges by giving it an action i.e. move in the opposite direction, and badda bing! you have a moving sprite!

i knew vaguely that pygame had a sprite type object, but it was only when linux format did a feature on games development using the module that it all started to make sense.

i took their sprite class and tweaked it slightly to make the sprite transparent based on the color of the bottom left pixel as game maker does. also based on the chimp tutorial i converted the image to speed up blitting (screen drawing).

class Sprite:
	def __init__(self, xpos, ypos, filename):
		self.x = xpos
		self.y = ypos
		self.bitmap = image.load(filename)
		self.bitmap = self.bitmap.convert() # faster blitting apparently...
		self.dy = 1 # going down

		# set transparency based on bottom left pixel
		self.colorkey = self.bitmap.get_at((0,self.bitmap.get_height()-1))
		self.bitmap.set_colorkey(self.colorkey)

	def set_position(self, xpos, ypos):
		self.x = xpos
		self.y = ypos

	def render(self):
		screen.blit(self.bitmap, (self.x, self.y))

the only improvement i made to sprite loading was keeping file handling os neutral by using os.path.join

backdrop = image.load(os.path.join('data', 'Background.bmp'))
backdrop = backdrop.convert() # another tweak
hero = Sprite(20, 200, os.path.join('data','Dragon.gif'))
boss = Sprite(500, 200, os.path.join('data','Boss.gif'))
fireball = Sprite(0, 480, os.path.join('data','Fireball.gif'))

as with all pygames there is an infinite loop that wraps the game ticks (steps in game maker) until the game stops, there’s no point placing sample code, just know that it exists and the rest of the code detailed is looped within it.

next we get to the movement for the hero (yes, the code hasn’t changed much from the lxf samples, i’ll rewrite by the next post to make things a little more clearer). pretty bog standard stuff, once you know how keyboard input works. i also added an event if the user presses escape as this quits the game in game maker.

	for ourevent in event.get():
		if ourevent.type == QUIT:
			quit = 1
		if ourevent.type == KEYDOWN:
			if ourevent.key == K_DOWN and hero.y < 370:
				hero.y += 5
			if ourevent.key == K_UP and hero.y > 10:
				hero.y -= 5
			if ourevent.key == K_ESCAPE:
				quit = 1
			if ourevent.key == K_SPACE:
				fireball.x = hero.x + 100
				fireball.y = hero.y + 10

next up is the boss. (though i get the feeling these actions should be wrapped up in the actual boss sprite class – watch this space.) very basic checks to determine if the sprite is going up (decrement the y position) or down (increment the y position) and when we toggle a flag to change direction when we reach the top or bottom of the screen.

	if boss.dy:
		boss.y += 5
	else:
		boss.y -= 5

	if boss.y > 350:
		boss.dy = 0

	if boss.y < -50:
		boss.dy = 1

finally update the dragon's fireball position, refresh the display.

	fireball.x += 10

	boss.render()
	hero.render()
	fireball.render()

	display.update()
	clock.tick(60)

as a point of reference i will include video posts of how the game should look in game maker and what i have so far been able to reproduce in pygame. so first up is the game maker demo:

and next is the pygame version:

eagle eyed viewers will note that the pygame version doesn't have animated sprites. that's because pygame doesn't do "animated" gifs, but fear not readers we've made this the topic of next week's post!

prev | about | next (animation)

assembly seemed too much like hard work. srsly.

in later years i tried using gui-based tools such as graphic adventure creator (by incentive software), shoot ‘em up construction kit (by sensisoft) and 3d construction kit (also by incentive software).

despite being a little more friendly, i still struggled to come up with anything playworthy. i had this nagging feeling that despite the tutorial booklets and in the case of the 3d construction kit a vhs video, the leap from making a basic box to a full blown game appeared to be missing.

cue modern day.

whilst idly surfing, i came across yoyogame’s game maker, which eventually lead me to a book co-authored by the creator of game maker, imaginatively titled the “game maker’s apprentice”. after browsing the book a few times, i came to the conclusion that this is exactly the type of introduction to games development that i needed.

it uses object oriented (oo) concepts and event driven programming to create a game from scratch. combine it with the actual game maker application – which quietly hides all the sharp edges such as sprite animation, memory management and collision detection – and you suddenly have a gentle but effective way to create games.

in order for me to learn something, nay, for me to grok it, i have to be given a specific task or problem to apply my knowledge to. so, as an added challenge, i will also be learning to port the demo games provided in the book into python using pygame (a module that is a wrapper to sdl.)

during the brief period since i’ve started messing around with python i now see it was a wise choice, its oo-ness enabled the oo concepts in game maker to port over easier versus a functional based language (runs from the burning fuse.)

so grab a seat, engage your seat belt and let’s makes games!

prev | about | next (bullets)