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)