logame team mailing list archive

[Paul Elms <paul@xxxxxxxxxxxxxx>]

Hi,

On Sun, 2009-09-20 at 22:10 +0200, Benjamin Klüglein wrote:
> Hi, sorry for the delay.
> 
[snip]
>         The information for each level is taken from two files; a
>         single game
>         wide tiles.yaml file that lists each type of tile's
>         characteristics and
>         its image file, and a specific level.yaml file.  All tiles
>         used in the
>         game must be listed in tiles.yaml so the game knows about
>         them.  At
> 
> What about a tile.yaml per level? So we could create different themes
> (per level), say one level takes place outside in the winter, one in a
> cellar. In each case it would be good to have different tile sets. 

I like the idea of having tile sets, so how about we use the tiles.yaml
file to list tiles that are more generic and could be used anywhere and
then have a tiles.yaml.d directory in config/ where tileset.yaml files
could be placed.  ie: if tiles.yaml looks like:
Tiles:
    red: [red.png, solid, deadly]
    green: [green.png, solid, safe]
    blue: [blue.png, liquid, deadly]

then winter_tiles.yaml in config/tiles.yaml.d/ would look like:
WinterTiles:
    icicle: [icicle.png, solid, safe]
    ice_spike: [ice_spike.png, solid, deadly]
    snowy_ground: [snow_ground.png, solid, safe]
    etc...

where WinterTiles would become the name of the tileset.  Loading all
yaml files from a single directory would be easy enough.  I would like
to keep all tile image files in a single location though ie:
media/images/tiles/ it's just simpler.

>  
>         present there are only 3 test tiles (red,green and blue).
>          Each tile has
>         a .png image which needs to be in media/images/tiles/ and can
>         be any
>         size.  Each tile also has some characteristics listed in
>         tiles.yaml,
>         such as whether it is solid (can be walked on, but not
>         through) or not
>         (background decoration tiles or things like water) and if it
>         is safe or
>         deadly (like water or spikes).  If anyone has any more ideas
>         for other
>         characteristics, please shout:)
> 
> That's a good idea, so they could be also be animated. I first thought
> of a having all tiles in one file, your attempt is much better. :-)

The tiles could be animated, but that would take a bit of redesign as at
present all the tiles are only blitted once, and obviously animated
tiles would need to be blitted every frame.  We can work on that later
when we have got static backgrounds working :)  

>  
>         Collision detection between the tiles and player_1 is
>         detected, but I
>         still need to write the code that will use it together with
>         the tile's
>         characteristics, to act on the player.
> We got to think of a good way to introduce gravity, so that the player
> is falling when he's not walking on solid ground. 

Once I have a basic working level editor (hopefully in the next few
days), I plan on making a simple sample level with a floor and blocks to
jump onto etc..  We can then work out gravity and proper jumping as well
as collision detection of Enemies and Shots with the scenery.
> 
>         
>         The level.yaml file (only testlevel.yaml at present) holds all
>         data
>         about a level, its name, the path to the background image, the
>         tile
>         types used in the level with their positions on the background
>         image,
>         and the enemies and collectable types, positions and other
>         data.  This
>         file is hand editable, but listing the locations of all tiles,
>         enemies
>         and collectables by hand would be nearly impossible for a
>         complex level,
>         so my next task is to write a level editor that will
>         create/modify
>         level.yaml files.
>  
> Yes, maybe we could also generate the enemies/collectables randomly,
> depending on some settings.

I like this idea, but rather than having completely random locations the
level designers could allocate the locations with a probability (using
the level editor) that the collectable/enemy will spawn there.  This
would mean that enemies and collectables don't spawn in impossible
locations and also be less scripted while playing.

Thanks for your comments,

Paul