On Sun, Mar 7, 2010 at 6:47 PM, B W stabbingfin...@gmail.com wrote:
On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee ksch...@xepher.net 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.
cool, that sounds good.
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.
This sounds like 'portals' used in some 3d engines... and called rooms
in engines like the old duke nukem engine.
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...
That would be grand... I think :) Super surfaces might need to be
done at the C level so that various routines can work with either a
super surface or a surface efficiently. Can probably prototype a
pretty good version in python first... then move it to C if needed.
An official addon project could be good too. There's a number of
various add on libraries around, perhaps having an official one will
work better. I'm not sure.
But if your thoughts go in another direction, René, I would love to hear
more.
Gumm
