Finally! She bumps into walls (sorta)!

Would you like to know how I did it?

Ok.

So, in the level class that is being used to hold the level sprites I use the collision detection algorithms that come with Pygame.

level_bumps = spritecollide(sprite,self.walls,False)
 
Now, it isn't quite as simply as it sounds, mostly because all it does is give a list of all the sprites of a given group that intercept with a given sprite (that last argument is whether or not I want to destroy the sprites afterwards... which is no).  While this does make things easier on me (meaning that I don't have to program checking for when one pixel loves another pixel), I still have to program what should be done when two sprites collide.  After all, any sauvy reader should be able to point out that the floor is made up of sprites.

At the moment, the functionality is for walls that are not corners, as the video points out.  Still, there was an interesting way that I achieved this.  Though the power of objects!

So, first, we capture those sprites that meet another sprite:


def checkCollision (self,sprite):  level_bumps = spritecollide(sprite,self.walls,False)  for items in level_bumps:     items.onCollision(sprite) 

Notice that weird function?  Yeah, that doesn't come with Pygame.  I added those using a class that is a subclass of Sprite that I made that simply has that function.  Whether it does anything depends on whether or not I bothered to fill anything in to the overloaded class that would be, say, a wall.

Here is what it looks like for a wall by the way:

def onCollision (self,sprite):
        offset = 5
        if self.orientation == NORTH:
            relocate = self.rect.bottom+offset
            sprite.rect.top = relocate
        elif self.orientation == SOUTH:
            relocate = self.rect.top-offset
            sprite.rect.bottom = relocate
        elif self.orientation == EAST:
            relocate = self.rect.right+offset
            sprite.rect.left = relocate
        elif self.orientation == WEST:
            relocate = self.rect.left-offset
            sprite.rect.right = relocate

The result?  Well, you can see the video, can you?

Just when I thought it was over...

The horror!  The walls are trying to bind me again!!!

She's Out!

Well, there was a series of funny problems, starting here:

I swore, I banged my head against the keyboard, and cried.  Then I learn that the fix was only one line long:

pygame.key.set_repeat(100,100)  

Now it works!

It ain't over yet.

Her Immuration will be over soon!

Also, an idea as to what it would look like in motion.  I'll let you know when its fix and she's properly moving.

She's been Immured!

But its coming along at least!

A moment of dirty programming

It could have more to do with the fact that when I was formally schooled in the ways of programming that the teaching language at my college was Java, and Java can be a nit-picky little bastard at times that comes with object oriented practices and static casting drilled into would-be programmers that has me feeling a little... well, off.

At the moment it revolves around the concept of dynamic type-casting.  While in Java you had to tell the complier specifically what type of value a variable was going to store (static typing), the Python interpreter simply assumes what a variable's type is based on how it is being used on a given line (dynamic typing).  Not the first language to be this way, but for the most part, as par instruction from school, its usually a good idea to, even in a dynamically typed language, to not have a variable be reassigned from being a number to a string for example.  The fear being of using the variable in a point of the program as string when the algorithm requires an integer or a float.

Course, today, its using an integer as a boolean.  Here's the naughtiness:

    def parseEvent (self,event):
        if event.type == KEYDOWN:
            if event.key == K_UP:
                self.direction = "back"
                self.moveDown(-1)
                self.motion ++
            elif event.key == K_DOWN:
                self.direction = 'front'
                self.moveDown(1)
                self.motion ++
            elif event.key == K_LEFT:
                self.direction = 'left'
                self.moveAcross(-1)
                self.motion ++
            elif event.key == K_RIGHT:
                self.direction = 'right'
                self.moveAcross(1)
                self.motion ++
        elif event.type == KEYUP:
            self.motion = 0

    def update (self):
        if self.motion:
            self.image = self.sprite_images[direction+"_"+"walk"+self.motion%2]
        else:
            self.image = self.sprite_images[direction+"_standing"]

So, to explain.  The variable motion is a counter that is measuring state, which, when redrawing the sprite, is used to determine which arch in the walking motions are to be drawn.  If motion equals zero then it is assumed that the character isn't moving at all, and therefore the sprite frame for standing still is drawn.

So, as you see, the motion variable is being used as a boolean.  Maybe not as bad as other examples floating around, though a piece of me can see that this was a bizarre solution to the problem involving redraw.

Lets talk about states

... but first!  Complete sprite sheet!!!

Second, there is an algorithm being planned for the movement.

Now, when the player presses a key on the keyboard or clicks/moves the mouse or tap/swips a touchscreen the machine recieves an event from the interupt prompts.  Detail at the moment on this mechanism isn't that important, just that these events determine things in the game like the direction that the character is facing.

For the purposes of this, the states are going to be for determining which lovely image of Arianna would be used for the motion.  Now, I have thought this through.


There will be a direction variable and a boolean for movement.  The sprite will not only move if the boolean is true, but the animations will cycle in accordance to the direction.  Else the stationary images are used and the sprite does not move.

I'll show you what I have when it comes.