earlier this week we bought a virtual private server (vps) with 34sp.com with the view of moving me and lou’s domains to it (our friends have been kindly hosting both). i thought it would be a good idea to keep a log of how we did it. now, normally this would be a very boring log, but almost immediately after firing up the vps i was shocked by how quickly the hackers started calling around. so instead of this log being used to track software installs, it will have a security twist to it.

in an impossibly perfect world, you’d stick a static content webserver in the dmz i.e. no cgi and push updates from production to it. but this ain’t, and i need to keep all my eggs in the one basket! so i’m going to try my best to keep the script kiddies out and make it worthless for the more seasoned hackers to do any poking around. seriously dudes, there won’t be financial or customer data on this server, it’s just a blog site!

so far i’ve achieved the following:

• lock down ssh:
  • disable root login (requires a non-root account to be used instead)
  • disable password auth (pub key only)
  • enable denyhost (becareful not to lock yourself out!)
  • move off port 22 (security through obscurity, but will stop most script kiddies)
• lock down mysql:
  • listen only locally (don’t switch to local socket files because tunneling a mysql connection won’t work)
• security auditing:
  • run scripts against secure and lastb logs (looking for suspect logins)
  • run chkrootkit nightly (checking for rootkit, would’ve its support bins were in a read-only environment so my rootkit doesn’t get patched by an anti-rootkit-script)

so back to the propagator..

from top to bottom: 3 x trays of parmex carrots, 1 x ’sweet chocolate’ sweet pepper, 1x ‘orange banana’ toms, 1 x ’serpette amelioree d’auvergne’ climbing pea and 1 x ‘n. napia’ pointy red sweet pepper.

we’ve had very poor luck with carrots so far, although having read a few blogs i think it’s safe to say we’re not alone. this time around we’ve went for the rounder ball-like variety. this is mostly because it would seem that the soil you need, to avoid getting forked carrots, has to be super fine soil, that has been sifted through a spider’s web, whilst saying a prayer to the angry carrot god TORRAC. the other seeds are having their second chance, as they either didn’t grow or didn’t ripen in time for harvest. further more after graduating from seedling to plants, the toms and peppers are being grown in the mini greenhouse so we can get a better crop. last year we found that the poor summer combined with the allotments windy disposition gave a small crop. although, but before i entirely blame it all on the elements, i should point out i didn’t stake out the plants or keep them to four trusses.

we’ve also started this years flowers:

left is blue lagoon (verbena x hybrida) and right is night phlox (zaluzianskya capensis).

lou also planted some bulbs (daffs?) in the garden, it’d be great if they end up flowering, but failing that they’re ready for next year it’s been very chilly outside, i do wonder what it will do the veg this year. it’d be great if we had a longer summer to make up, so fingers crossed!

by the time i reached halfway point i had to start walking (this was after i had set a good pace). i had the odd occasional bursts of energy flying past people, but by the end, my legs had become like lead and i was gasping for air.

i’m normally used to an 25-60 minute type running event and finding my rhythm. i had no such luxury in this event where the winning time is sub 5 minutes.

and in 8 minutes and 11 seconds it was all over. i had hoped for a sub 10 minute finish so i consider this a result. i tried to avoid dragging myself the stairs using the bannister, but having seen footage of the winner i now know this is acceptable in the sport of stair climbing! i was top 45% of the category which is a nice percentage to be in.

i was doubly pleased because i ended up raising over 200 pounds for shelter (they asked race entrants to raise at least 150 pounds). thank you to all my wonderful sponsors, you helped me stay true to my training and stopped me from giving up when it started to hurt a lot. did i meant it hurt a lot?

crazy event. mad props to alison for making the mistake of telling me about the event!

i ended up keeping some of the fleece (well actually wasn’t real fleece, more like that weed suppressing membrane) on two rows to warm the ground and force faster growth.

this time around we picked really obscure varieties, made further obscure because shozu failed to upload the photo above, which had the descriptions. so from memory and left to right we have: gypsy mixed with highland burgundy, skerry, salad blue, shetland black, gypsy mixed with highland burgundy and finally dunbar rover.

aren’t they great names? the taters are heritage varieties which can go from blue and purple insides, to black skins with blue rings in white flesh. we’ve had the shetland black before and really enjoyed them.

since my plan for main crops was postponed, i decided to prune the rasps. hopefully i wasn’t too harsh. i made a half arsed attempt to weed the area around them, but it needs more work.

there’s still so much to do and we’ve not made a start on any seedlings. but hey, i guess when you stick food in the grow, you’re technically in growing season eh?

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

Do not fear my protectionist approach to copyright.

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 32×32 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)

i noticed that in safari the next image is stuck all the way down the page, not sure why. but i thought i’d warn you!

the pigeons got at a lot of our winter crop. they ravaged the spring cabbage.

i’ve put netting around our sprouts as a precautionary measure, they’ve got to survive until we bring with us for christmas dinner. we’re hoping everyone gets at least two sprouts each!

i asked lionel (our resident plot guru) why the wildlife didn’t go for the romanesque, he thought it was because they couldn’t see them. something to do with contrast perhaps?

the beans are looking sorry, they’re not dead but scrawny looking. i wonder if this is an over winter behaviour?

another plotber whose name eludes me at the moment, told me that the lotty got done over recently. a gang broke through the front gate and broke into every shed. they brought a van and it looks like they only wanted machinery. i feel sorry for those people who had stuff nicked, i hope those thieving gits get caught.

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)