Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[magikarcher]

I am working on a Roguelike that is written in Pygame. I don't really have a goal in mind yet, but I am just going to implement one feature at a time. I have been using Python for about 2 years now, but never really focused on programming a whole lot. Does anyone here have experience with Pygame or Python in general? I managed to program a small dungeon, a player character, and movement, but I am having some graphical problems with the movement. If you were to run the attached program (and move with 'WASD') you would notice that your character gets printed on top of the rest of the map, and isn't removed after he has moved on, so this leaves a trail of '@'s. If someone could look this code over and get me on the right path to fixing it, that'd be great.


http://pastebin.com/H3vaJw9a

[Ari Rahikkala]

Consider using libtcod. It would make things like drawing on the console and getting input without busy-waiting on it easier. There seems to be a fairly decent tutorial up for it at RogueBasin.

[magikarcher]

I tried libtcodpy, but I didn't like it a lot, I might give it another go though. 1.5.1 and 1.5.0 do NOT work at all for me. I am gonna just use the year old 1.4.1 then.

[Ari Rahikkala]

Ah, apparently you can just .wait() on input in pygame, which makes it... not that difficult, then. (there's a slight difference in that .wait() returns a single event rather than a list of events, but that only simplifies the code)

Anyways, to actually answer the original question, move map1 = Map() inside the main loop. (edit: Well, actually, that does make the code work, but it's probably not what you want. It's more likely you'll want to introduce the wall and floor objects once and be done with them, and then remove the player from their old position and insert them in their new position every time they move)

[Dasleah]

The 'leaving a trail' problem is a common one. You need to separate out the various elements of your drawing code. What's happening now is you're telling it to draw an @ at a particular point, wait for input, and then draw him at another point. The vital element here is that you aren't drawing back where he used to be, and it'll just leave the old @ there.

Typically you'd want something like this:

Code: [Select]

renderLoop():
     while 1:
          getInput()
          check to see if this input is valid
               if it isn't, oh no, print something and call renderLoop() again
               actually this is probably better spun out into the actual getInput() function i dunno
          if it is valid, hoorah:
               move the character in the 'entities' layer
               do whatever with anything else - AI, changes to the 'map' layer or whatever
               get a combined form of the 'map' layer, entities layer (this is your 'viewport' or visual layer, the only one that gets drawn)
               draw that combined layer
     if 1 != 1:
          shiiiiiit
          throw a spaz
There are doubtless more efficient and better ways to do this, but I like the 'think of everything as a layer like in Photoshop' approach. You keep everything as separate as possible, move / alter them only in the layers that make sense, and then the final step is rendering it all to the layer that you actually see, which exists entirely independent of all the other layers and exists only to provide visual output.

[Bricks]

The only other option, as far as I know, is to keep track of "dirty" tiles and only update those.  Ultimately, for a turn-based game, it's not that big of a deal, but considering how costly pathfinding and FoV algorithms can be, its not a bad idea.