[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[pygame] Free Graphic Tileset / Automatic Use of "Coast" Tiles
- To: pygame-users@xxxxxxxx
- Subject: [pygame] Free Graphic Tileset / Automatic Use of "Coast" Tiles
- From: Kris Schnee <kschnee@xxxxxxxxxx>
- Date: Thu, 26 Apr 2007 18:15:44 -0400
- Delivered-to: archiver@seul.org
- Delivered-to: pygame-users-outgoing@seul.org
- Delivered-to: pygame-users@seul.org
- Delivery-date: Thu, 26 Apr 2007 18:15:54 -0400
- Reply-to: pygame-users@xxxxxxxx
- Sender: owner-pygame-users@xxxxxxxx
- User-agent: Thunderbird 1.5.0.10 (Windows/20070221)
I came across a set of graphic tiles at
<http://lostgarden.com/2006/02/250-free-handdrawn-textures.html> that
are well-suited for 2D tile-based games, and which are free and
professional-quality. It looks like someone involved with PyWeek already
discovered them, but I was happy enough to find these that I thought it
worth pointing them out here. They're almost perfectly suited for my own
project.
Still thinking about how to use them automatically on my game's
currently-jagged maps -- or more generally, in any tiled game. Rather
than manually place all the coastline pieces I'd like a function to
replace bits of transition areas with the appropriate tiles where they
exist. The tiles' naming convention involves "G0 S0 [direction]" for a
transition from "Grass 0" to "Stone 0," and I don't think there's a
reverse transition as it'd be redundant.
So I would make a dictionary listing what images to use for any terrain
transitioning to any other. Then for every tile:
-Look at its four orthogonal neighbors.
-If it borders > 1 terrain type besides itself, shrug and work with just
the first other terrain detected because these tiles can't handle, say,
water to sand to grass in one tile.
-Form a tuple such as (0,1) to show the direction of change; (0,0) means
the tile is surrounded by others like itself.
-Look up the appropriate tile using the dictionary's "get" function, and
replace the default terrain tile with a transition tile if one is found.
(This system would automatically cope with incomplete tilesets, eg.
one-tile-wide paths and missing "a to b" transitions.)
Although I haven't actually tried coding this method yet, it strikes me
that it would look nice, but shift the apparent terrain half a tile up
and left because it'd look for transition tiles starting at (0,0). That
is, if you have water in the north and sand to the south, this algorithm
would look at the tiles just north of the sand, say "oh, there's a
transition here," and draw water/sand transitions, filling part of the
tile with sand when the map says it's full of water.
Even if the result looked fine, it'd cause me gameplay trouble. My
handling of terrain assumes that the point (0.0,0.0) is at the
upper-left edge of a tile, you're considered to be on tile (0,0) if your
exact coordinates are less than (1.0,1.0), and there are graphics and
(soon) gameplay effects of being on a particular terrain, like an
overlapping translucent tile when you're on water. So these inaccurate
transitions would cause bad effects, like registering you as standing on
lava when you seem to be half a tile away.
I thought about offsetting the tiles by half a tile to correct for this,
but the above method wouldn't actually work as I sketched it out. In the
water-to-sand example, the southmost water tiles would become "water
fading southward to sand," sure, but then the sand tiles just south of
that would become "sand fading northward to water," creating messed-up
tidal pools. I think.
The moral is that using these tiles properly, and automatically, is
tricky. Is there an obvious better way to make sure the transitions are
right and that they accord with the gameplay effects of terrain?
Kris