logame team mailing list archive

[Benjamin Klüglein <scheibenkaes@xxxxxxxxxxxxxx>]

2009/9/23 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.
>

That would be also perfectly fine with me. Maybe we can think of levels as
'plugins' which could reside in zipped files in a later version, this would
save disk space and would make it easy for users to add new levels
 independently from the main program.


> >
> >         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 :)
>

Ah yes I didn't think about that. Let's forget about that until version 2.0
:-)


> >
> >         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.
>
I'm really looking forward to the level editor. I'll hopefully have fixed
the jumping issue 'til then.

>
> >
> >         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.
>

In the meantime I think that my idea wasn't maybe a really good one. It
would be better if we place enemies with your editor, to have more control
about what's going on.

But if a enemy passes out he could randomly drop collectables. E.g. in one
out of ten times a defeated enemy drops something you can collect.


>
> Thanks for your comments,
>
> Paul
>
>
>