PyGame Progression

For those still waiting for my post-STS132 launch post, you’ll have to wait a few more days. I’m almost done writing it, but then I’ll need to go through and add links and pictures and all that good stuff, which should take a while. For now, though, a quick detour away from studying for the GRE (yes, I am actually studying, as much as it may seem that I’m not) and other recent events in my life.

Red Mars – Part 3
Remember this post? Well, behind the scenes, I’ve done quick a bit of work on the game. My initial plan was to have the movement (just movement) be a mix between The Legend of Zelda and Pokémon, since I liked the free-range movement of Zelda and the smooth scrolling of Pokémon. Well, I finally figured it out!

I just had a “Eureka!” moment while porting Ground Assault 83 (Note: link isn’t to the TI-83 version… Check Sicode’s website), a game I didn’t really play back in high school but more used it to help my TI-BASIC programming skills for some other games. I think it was the first one where I actually went in and looked at the coding, changing a few things here and there to see what would happen, and figuring out the mechanics of TI-BASIC programming. I thought it would be a fun little challenge to port it directly to PyGame, plus I could then try to develop an AI for it afterward. Just something that popped into my head to do.

Since the movement for that game is grid-based, I was already working with the mechanics for the Pokémon movement system, albeit in a simpler form (i.e. no animation). After fusing with moving things around on the game board, I decided that I should probably just work on my actual game to figure out those things, since I’d be encountering similar difficulties. After a few minutes, I had it… or, at least I was close. I was more concerned with the changing background while keeping the sprite centered, so I took out any collision detection I had implemented previously.

Once that was done, I decided to figure it out with the free-range motion scheme I’ve been using. Movement was fine, but collision detection? It wasn’t working, so I looked back at what the collision detection algorithm I had written would actually check. There was my problem: since the character sprite was simply sitting in the middle of the screen, he would never encounter the rectangles I use to mark impassible terrain, even though the terrain appeared to be moving around. I added a handful of lines to the actual movement section to update both the background screen and the relative position of the character in reference to the rocks, and I had it!

Not bad for a night’s work, and all I had to do was create two new variables…

For those interested (Not the full code, since much isn’t related at all to the problem at hand. This is really all I needed to change in the program: the addition of two variables and updating both those variables and the player’s position relative to the rocks. I also had to change my screenblit command, done so by simply adding the x_shift/y_shift offset to the location of the individual sprite rectangles):

x_shift = 0
y_shift = 0
[...]
    if MOVE_DOWN:
        y_shift -= MOVE_SPEED
        player_position.top += MOVE_SPEED
        for rock in rocks:
            if collision_detect(player_position, rock):
                y_shift += MOVE_SPEED
                player_position.top -= MOVE_SPEED
Advertisements

Comments are closed.