Re: [Bontz-team] development plan, tile system

[Chuck]

i would prefer all tiles to be the same size, so if you could shrink the
water into tiles the same size as everything else it would be appreciated!

you say "we can rework them later if needed"...well, i think i WILL have to
rework the way i animat sprites, certain parts of it are just too
restrictive, such as the current limitation of only one animation per
directory.  though the animations still can have multiple tracks, so there
are possible ways to work around that, but i think it would be better all
around if we could have multiple animations per directory.  and i should
probably allow naming of tracks instead of just using track numbers.  if we
can name tracks, then we don't have to worry that the tracks appear in a
specific order within the animation.  for instance we could name a track
"walk-e" and then we wouldn't have to care what track number it is.
currently "Walking East" i believe has to be the first track.

also something that has yet to be fixed/done, we seriously need some sort of
memory manager,  currently in an animation if a frame is used more than once
it needs to be loaded into memory each time it is used.  i would prefer if
we could load it only once.  for instance maybe rework the animation files.
at the top of the animation files list each file and a numerical probably
auto incrementing starting at 0 id for that file.  then instead of listing
the filenames in the animations, we could list just this ID number, and if
it were 0 based we could pull it directly from an array.  this way we only
load a particular frame only 1 time no matter how many times it is used in
the animation.  i just thought of this, so i hope it will work, i will have
to try it out.  we should keep this in mind for the map system as well, try
conserve memory by sharing resources that are used multiple times.

i also need to simplify the animation file as it still contains remnants the
transparency color key which we used before i figured out how to do alpha
transparency.  .

i think it is going to be a while before we get the tile system going as all
the base classes appear that they need/should be reworked.  i know you have
wanted a tile system for a long time,  i am sorry, but you will probably
need to wait a bit longer.


and...man you write long emails!

----- Original Message ----- 
From: "Owen Swerkstrom" <address@hidden>
To: <address@hidden>
Sent: Tuesday, July 15, 2003 9:06 AM
Subject: [Bontz-team] development plan, tile system


> > would you prefer tiles or text?  i can work on
> > either, but probably not
> > both at the same time.
>
> Let's go from the ground up, getting the tiles going
> first.  For the sake of the fish race we probably
> don't need scrolling, but you might prefer to tackle
> that all at once, I'll leave it up to you.  Text can
> wait, for sure.  Does the following order of tasks
> make sense to you?
> + multi-layered backgrounds made from tiles
> + system for having sprites atop those tiles
> + system for scripting movement of those sprites
> + text system for messages and menus
>
> That will actually take care of the whole minigame.
> Stuff to keep in mind during the tile work would be
> that we'll want to specify "can walk here", "can't
> walk there" and "this is a door to xyz map" etc for
> the main game, though we certainly don't need to worry
> about implementing that stuff yet.  Just so it's
> possible to add.
>
> > i am still thinking on how i want to define a map.
> > how to place the
> > tiles, portals/doorways that linke to other maps,
> > placement of objects,
> > and npc's and so on.
> >
> > the map needs multiple layers, and probably allow
> > for varying degrees of
> > elevation of the land, and non-crossable terrain.
> >
> > any good ideas for that?
>
> I know very little about how you're going to want to
> load in each graphic and how SDL likes to deal with
> them, but maybe something like:
> ---start of example---
> #00 is always "nothing"
> 01=tile/outdoor/grass-a.png
> 02=tile/outdoor/grass-b.png
> 03=tile/outdoor/grass-c.png
> 04=tile/outdoor/grass-d.png
> 05=tile/outdoor/water/,70
> #a possible way to specify to loop-animate a folder?
> #or maybe
> 05=tile/outdoor/water/info
> #and have it learn how to animate based on that?
> 06=sprite/npc/shmoe/info
> #would/could an info file contain movement patterns?
> 07=maps/snobville2003.map,14
> #"door" type spot? the ,14 is to where within the map
>
> layer 0  #bottom layer - water
> 05 05 05
> 05 05 05
> 05 05 05
> 05 05 05
>
> layer 1 #next up - grass
> 01 02 04 03 01 02 04 03 01 02
> 04 03 01 02 04 03 01 02 04 03
> 01 02 04 03 01 02 04 03 01 02
> 04 03 01 02 04 03 01 02 04 03
> 01 02 04 03 00 00 00 00 00 02
> 04 03 01 02 00 00 00 00 00 03  #see the crappy lake?
> 01 02 04 03 00 00 00 00 00 02
> 04 03 01 02 04 03 01 02 04 03
> ---end of example---
> all just ideas, and it reminded me of something
> slightly ugly: the water stuff is bigger than the
> other tiles, and to boot it's twice as wide as it is
> tall.  should we be able to deal with different-sized
> tiles or should I chop everything up into 64x64
> pieces?  maybe something like...
> ---start of example---
> layer 0
> tile/water/info
> 0,0 256,0 512,0
> 0,128 256,128 512,128
> 0,256 256,256 512,256
> 0,384 256,384 512,384
>
> layer 1
> tile/outdoor/grass-a.png
> 0,0 256,0 64,256
> tile/outdoor/grass-b.png
> 64,0 320,0 64,192
> tile/outdoor/grass-c.png
> 192,0 448,0 64,64
> tile/outdoor/grass-d.png
> 128,0 384,0 64,0
> ---end of example---
> well i got sloppy/lazy on the layer 1 stuff but you
> can see where I was going with that.  That's about all
> the ideas I have for now.  I kind of like this latter
> one, as theoretically we can put things anywhere, not
> just at multiples of 64x64.  It's harder to visualize
> by looking at the text though.  Also, for "can't walk
> here" stuff, maybe that's all in an "info" file too?
> that way the map file could just point to an info
> file, knowing to place the sprite/prop/whatever it is
> at some given location, and the info file could
> describe how to actually display/animate it and what
> bits of it should block player movement.  is it
> sensible to put that extra stuff in the info file?
>
> > ok, it doesn't matter to me, what do you want me to
> > do first?  a text
> > engine or tiles?  it almost sounds that a text/menu
> > engine may be a bit
> > easier than tiles
>
> I'm sure it will... but what the hell, let's get the
> tiles in and done, we can totally rework them later if
> we find out we didn't plan well enough.  (I'm sure
> you're really glad to hear that :^)
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
>
> _______________________________________________
> Bontz-team mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/bontz-team