Re: [pygame] Perhaps a port for this into Pygame?

[andrew baker <failrate@xxxxxxxxx>]

I just use tuples of integers.  It approaches human-readable format,
and I'm leaving it abstract.  By changing my palette files, I change
the values of the integer elements, which makes it easy to change
graphics across all maps by editing a single value.  The design of my
engine is abstraction and data-driven design.  For example,  when
objects collide, they don't exchange object references, they pass each
other lists of name, value paired tuples, the name is used as a key to
match a dictionary of executable Python statements.  I'm thinking of
doing something similar for the collision map (currently, it's
basically just 0 or 1, block or non-block).


On Sun, 26 Dec 2004 15:24:44 -0800 (PST), Jasper Phillips
<jasper@xxxxxxxx> wrote:
> 
> On Thu, 23 Dec 2004, Quest Master wrote:
> 
> > I was talking to some of my friends about Python and Pygame, and
> > though they seem quite interested, they're "hardcore" RPG makers. What
> > does this mean?
> >
> > Well, they whine about the lack of a proper map editor and map format.
> > I told them it's quite easy to do this and not a true pain as it would
> > be in other languages, but all they had to reply was a "Meh."
> >
> > So I searched into some map formats SDL has ports for, and I came
> > across this: http://membres.lycos.fr/edorul/SDLMappye.htm
> >
> > Apparently, it's a good map editor (Mappy) and the library (SDLMappy)
> > draws the maps efficiently too. Haven't dug up THAT much on it, but
> > yeah.
> >
> > I was wondering if anybody was interested or up for doing something of
> > this kind, or if anything similar was available.
> 
> The game I'm working on does something along these lines with
> Python/Pygame/PyOpenGL/Pyui, although with only a crude interface without
> much gui.  Then again it's allows 3D, animation, full alpha, ties into the
> underlying game mechanics and UI events, etc.
> 
> http://gazler.com/users/jasper//1221154839_screen.jpg
> http://gazler.com/users/jasper//1221155402_screen.jpg
> 
> Here's a sample of the data file (for a simpler map):
> 
> carteString = '''\
>       0     1     2     3     4     5
>           . . .       . . .       . . .
>          . r4  .     . r8  .     . r5  .
>     . . .   _   . . .   _   . . .   _   .
> 3  .     . p4  . cap4. p4  . r1  . p1  .  3
>   .   %   . . .   +   . . .   ^   . . .
>    .     .     . p4  .     ~ p1  . cap1.
>     . . .   %   . . .   _   . ! .   ^   .
> 2  .     .     .     . p4  ~     ! p1  .  2
>   .   %   . . .   $   . . .   _   . . .
>    .     .     . p3  .     #     !     .
>     . . .   $   . . .   +   . ~ .   ^   .
> 1  .     # p3  =     = p2  . t1  ~ p1  .  1
>   .   _   . . .   ^   . . .   _   . ~ .
>    #     ~ cap3. p2  . r6  . p2  ~ r2  #
>     . ~ .   _   . . .   _   . . .   _   .
> 0  = r3  . p3  . r7  . p2  . cap2. p2  =  0
>   .   _   . . .   _   . . .   _   . . .
>    . p3  .     . p3  .     . p2  .
>     . . .       . . .       . . .
>       0     1     2     3     4     5      '''
> 
> symbolToTerrain = {
>                     '_' : Plains,
>                     '@' : Fertile,
>                     '+' : Desert,
>                     '^' : Mountains,
>                     '$' : Forest,
>                     '%' : Water,
>                     '~' : River,
>                     '=' : Roads,
>                     '#' : Bridge,
>                     '!' : Cliff,
>                   }
> 
> The symbols in the center of each hex are for hex terrain, the symbols on
> the edges are for boundary terrain, while the other symbols are names that
> are used to identify the hex for adding features it contains, etc.
> 
> Anyway, I can vouch that it's pretty straightforward.  All told it's under a
> thousand lines of Python.
> 
> -Jasper
> 
> 


-- 
Andrew Ulysses Baker
"failrate"