0

So I've been making a game using Python, specifically the PyGame module. Everything has been going fairly well (except Python's speed, am I right :P), and I've got a nice list of accomplishments from this, but I just ran into a... speedbump. Maybe a mountain. I'm not to sure yet. The problem is:

How do I go about implementing a Camera with my current engine?

That probably means nothing to you, though, so let me explain what my current engine is doing: I have a spritesheet that I use for all images. The map is made up of a double array of Tile objects, which fills up the display (800 x 640). The map also contains references to all Entity's and Particles. So now I want to create a a camera, so that the map object can be Larger than the display. To do this I've devised that I'll need some kind of camera that follows the player (with the player at the center of the screen). I've seen this implemented before in games, and even read a few other similar posts, but I need to also know Will I have to restructure all game code to work this in? My first attempt was to make all object move on the screen when the player moves, but I feel that there is a better way to do this, as this screws up collision detection and such.

So, if anyone knows any good references to problems like this, or a way to fix it, I'm all ears... er.. eyes.

Thanks

JS.
  • 14,781
  • 13
  • 63
  • 75
tanishalfelven
  • 1,186
  • 2
  • 10
  • 21
  • I know you said you'd read a few posts, but I think [this](http://stackoverflow.com/questions/14354171/add-scrolling-to-a-platformer-in-pygame) one is particularly useful. – Harvey May 15 '14 at 06:36

2 Answers2

4

You may find this link to be of interest.

In essence, what you need to do is to distinguish between the "actual" coordinates, and the "display" coordinates of each object.

What you would do is do the bulk of the work using the actual coordinates of each entity in your game. If it helps, imagine that you have a gigantic screen that can show everything at once, and calculate everything as normal. It might help if you also designed the camera to be an entity, so that you can update the position of your camera just like any other object.

Once everything is updated, you go to the camera object, and determine what tiles, objects, particles, etc. are visible within the window, and convert their actual, world coordinates to the pixel coordinates you need to display them correctly.

If this is done correctly, you can also do things like scale and otherwise modify the image your camera is displaying without affecting gameplay.

In essence, you want to have a very clear distinction between gameplay and physics logic/code, and your rendering/display code, so your game can do whatever it wants, and you can render it however you want, with minimal crossover between the two.

So the good news is, you probably don't need to change anything about how your game itself works. The bad news is, you'll probably have to go in and rewrite your rendering/drawing code so that everything is drawn relative to the camera, not to the world.

Community
  • 1
  • 1
Michael0x2a
  • 58,192
  • 30
  • 175
  • 224
0

Since I can't have a look into your code, I can't assess how useful this answer will be for you.

My approach for side scroller, moveable maps, etc. is to blit all tiles onto a pygame.Surface spanning the dimensions of the whole level/map/ etc. or at least a big chunk of it. This way I have to blit only one surface per frame which is already prepared.

For collision detection I keep the x/y values (not the entire rect) of the tiles involved in a separate list. Updating is then mainly shifting numbers around and not surfaces anymore.

Feel free to ask for more details, if you deem it useful :)

Patric Hartmann
  • 738
  • 7
  • 24