Re: [pygame] super surface... a surface made up of many smaller surfaces

[B W <stabbingfinger@xxxxxxxxx>]

On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee <kschnee@xxxxxxxxxx> wrote:

On 3/5/2010 10:40 AM, René Dudfield wrote:

However, sometimes we would like to operate on a whole bunch of
smaller surfaces stuck together.

I've done several projects using a full-screen scrolling tilemap. That is, sprites walking around on a blanket of 2D tiles drawn from an array as big as 1000x1000 referencing a set of 50x50 tiles. That wasn't practical to do using a Pygame Surface, due to the size, so each frame the system figured out the range of all visible tiles (based on the POV character's location) and drew those. It wasn't very efficient, but it did work, and it's an example of a surface built from many actual Surface objects. (Will link to code if you want.)

I did something very similar with Gummworld. The supersurface was not a single Pygame surface, rather a virtual surface made of a 2D array of sprites each with its own image. The Pygame drawing surface was the visible display; only I found that Group.draw()-ing all the terrain sprites and allowing Pygame to automatically crop them was in larger cases more efficient than cropping the drawing scope in Python. Still, it did indeed waste memory having all those sprites, each with their own image, outside the display area. The level design was rectangular, and if the map is irregular then large portions of the supersurface could possibly have many unused sprites; which led to a crude sparse map implementation, where an array cell with a None value would be ignored. It's a simple paradigm in which the special cases tend to center around conserving memory and CPU.

That initial attempt got me thinking about a room paradigm. A level is analogous to a building or a floor with rooms connected by exits. Rooms don't necessarily have walls, and exits are not necessarily visible. They are just internal geographic and navigational elements, respectively. An exit links two rooms. Exits can be visible objects such as a door or portal or
an invisible line on the ground. Using an exit changes the interactive context from
room A to room B. If you choose so, your room could scroll. With some drawing savvy neighboring rooms could scroll seamlessly. The player might not even notice that an exit was used and there was a room change.

Though the room paradigm seems elegant to me and potentially memory-efficient, it presents its own significant challenges: resource management (real-time loading and garbage cleanup); game hiccups from resource management; spacial relationship of rooms and exit "hot spots"; interacting with objects through an exit; room linkage errors.

So on the one hand we have a level structure that is easy on the programmer and harder on the machine; on the other a structure that's easy on the machine and harder on the programmer. I know others have solved such issues, and there are game engines that provide a display/resource/world/etc. management framework so you can focus on game intelligence, content, and world design. But they are systems and languages unto themselves, and if I don't like an aspect I can't always change it. That is why I was happy to find Pygame.

But not for the first time I am thinking it would be awesome to have some higher level toolkits, somewhere comfortably between Pygame and a full-blown game engine. It seems many of us have put a lot of time and effort into such toolkits, with varying degrees of success. I am wondering if the supersurface would fit better as an "official-like" Pygame add-on. It might even trigger a series of integratable toolkits that offer standard ways of solving higher level problems like I've seen suggested: scenes, tiling, transitions, map scrolling, path-finding. =) *cough* Me and my grand schemes...

But if your thoughts go in another direction, René, I would love to hear more.

Gumm