[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    [Kde-games-devel] Kapman sprite system (also,
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2008-12-10 4:28:49
Message-ID: ghngi2$5cg$1 () ger ! gmane ! org
[Download RAW message or body]

Ok, so in fiddling with Kapman graphics, I ran into some problems with 
the sprite system, mostly in the set of assumptions it makes (only one 
enemy graphic, number of animation frames or lack thereof), and the 
kdegames-wide item that has been the bane of my existence since 4.0, 
requiring every bloody thing to have an id.

So I came up with an action plan (README, attached), and applied it to 
the "simple" theme I am working on and will probably use as fodder to 
implement this and the tile system.

Let me say it again. I *hate* assigning id's to every blody thing. I 
also hate having to group, and I really, *REALLY* hate having to make 
invisible objects so that id'd things are the right size. As you'll no 
doubt see from the attached svg's, I very much prefer defining elements 
based on their position in the document. It's much easier (easier to 
make, easier to edit, leads to neater svg's, no invisible objects, no 
need to group)... and even allows tricks like frame re-use (check out 
where the second four of eight frames for the blink animation are ;-) ). 
Not to mention that for the enemies I have 22 id'd objects versus 80 I'd 
need otherwise (and for the player, I'd otherwise need 36, and I have a 
whole *2*).

Anyway, one question is obviously if I can convince people to see the 
light in this respect :-).

The other big question is on the animation system itself, if it looks 
sane, etc. Most of it is described in the README (which is written to 
describe the whole theme but is incomplete at the moment). Basically, 
it's magic-id to identify each sprite or block of sprites, with 
additional magic id's to give the animation parameters and other hints. 
Plus one magic id gives the size scale for everything. Obviously the 
colors aren't important, but I've consistently used blue for block 
identifiers, green for art hints (only one), and magenta for animation 
hints. And red for the scale-indicator.

I'm also throwing in the wall tiles for this theme so y'all can have a 
look at that. Seeing as how the tiles in this theme are all symmetrical 
(i.e. you could reduce them by around 65-75% by rotating/flipping) it's 
not a great example, but it should be fairly obvious where more 
complicated tiles would tend toward each tile being more distinctive. 
Anyway, it's using the same basic system, which is two id'd elements to 
give the tile size and spacing, one id'd element to give the tile 
system, and the rest needs no grouping, id's, or invisible elements.

So... thoughts? Especially from Thomas and/or Pierre-Benoit? It's a 
decent amount of work but will *really* open up new theming possibilities.

Implementation-wise, the first thing I plan on writing is obviously a 
class to import multiple frames from a so-laid-out SVG; this will be 
used both for the sprites and also the wall tiles. Then comes tile 
logic... :-) I'm not sure if I'll want to tackle improving the animation 
system or tying in a tile engine first; both are not changes to be made 
while in freeze. (Maybe I should start a work branch in playground?)

(And yes, I do have theme ideas that would use everything described in 
the README.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
You are in a meadow. A huge red dragon stands before you.
 > FIGHT DRAGON
With what? You don't have any weapons.
 > RUN AWAY
You wisely exercise the better part of valor.

["README" (text/plain)]

Files
======

A Kapman theme consists of a number of files. These are:
- theme.desktop: contains the name, description, and definitions for the theme
- sprites.svg: contains all sprites (player, enemies, items)
- background.svg: [optional] contains artwork to be used as the window background
- status.svg: [optional] contains artwork to be used as the status line background
- walls.svg: contains the wall tile artwork (see also README-TILES in the kdegames \
                root)
- corridors.svg: [optional] contains the corridor tile artwork
- maze-<hash>.svg: TODO
- camp.svg: contains graphics for the enemy camp

Note that the file names are specified in the .desktop (which is usually named "<name \
of theme>.desktop", e.g. "simple.desktop", "classic.desktop"); the above are \
suggestions. Compressed SVG (.svgz) is also supported.

Backgrounds
============
Three different background may be used by Kapman.

background.svg is used for the entire window, and may be any size. It is scaled to \
fill the entire window, cropping as necessary to avoid distortion. It contains no \
id'd elements; the document size is used.

status.svg is used for the bottom of the window containing the level number, score, \
and lives remaining. If the file contains an element with the id "hint-stretch", then \
the graphic will be scaled to exactly fit the status area, allowing distortion. If \
the file contains an element with the id "hint-float" or "hint-tile", the graphic \
will be scaled only to the height of the status area; cropping the left and right if \
the status area is wider then the scaled graphic, otherwise repeating the graphic \
("hint-tile") or allowing the window background to show through on the left and \
right. Otherwise, if the file contains an element with the id "hint-align-top" or \
"hint-align-bottom", then only the bottom or top (respectively) will be cropped when \
scaling. Otherwise the top and bottom will be cropped evenly.

camp.svg may contain id'd single-graphic enemy camps in addition to tiles (see next \
section). These are assumed to be 1:1 scale with the element having the id "tile" and \
are scaled accordingly, and centered with respect to the camp in the maze. TODO \
(names).

Tiles
======
Three tile sets are used to draw arbitrary mazes; wall.svg, corridor.svg, and \
camp.svg.

camp.svg is used for drawing the enemy camp. If there is a match for a single-graphic \
camp id in the file, it will be used instead of tile drawing unless the file contains \
an element with the id "floor", in which case tiles relative to the element with id \
"floor" will be drawn in addition to the single graphic, treating enterances as walls \
for this purpose. Otherwise, tiles relative to the element with id "camp" will be \
used to draw the camp, considering enterances to be empty, and using wall tiles if \
there is no element with the id "camp". Enterances will be drawn using elements with \
the names "enterance<width>-<direction>" (for example, "enterance2-n" for a \
north-facing enterance two tiles wide). Single-graphic camps and enterances are drawn \
at 1:1 scale where the element with the id "tile" represents the width in \
document-pixels of one maze tile (only the width of the element is considered for \
this purpose).

Hashed Mazes
=============
In addition to tile-based mazes, Kapman allows whole

Sprites
========
Sprites are not id'd as such, but are rendered according to a tiled offset system, \
using a specially-id'd shape to direct the engine how to render each sprite. Actors \
except for "player-dead" may have four directional variations ("n", "s", "e", "w"). \
All sprites may have multiple animation frames. If no directional variants are found, \
Kapman will use the non-variant without rotation. If an element with the id \
"hint-<name>-rotate" is found, Kapman will only look for the "e" variant and will \
fill in the others by rotation; similarly if an element with the id \
"hint-<name>-flip" is found, Kapman will only look for "e" and "n" variants, and will \
fill in the others by flipping ("e" flipped horizontally to get "w", "n" flipped \
vertically to get "s").

The object with id "cell" determines the base size of all sprites. This object should \
be square (only the width will be considered), and corresponds to the size of one \
wall tile. Sprites may be larger or smaller than this, and will occuupy more or less \
than one tile correspondingly.

A sprite is identified by a specially id'd object (usually a rectangle), with the id \
"<name>[-<direction>]-<w>x<h>-<x>_<y>". For example, a 24x36 rectangle named \
"player-n-4x1-0_36" specifies the north-facing player, having 4*1 == 4 player frames \
of size 24x36, located 0 pixels to the left and 36 pixels below the top-left corner \
of the so-id'd rectangle.

The sprites are as follows. The actors are "player", "player-dead", "enemy1", \
"enemy2", "enemy3", "enemy4". Each enemy may also have the subtypes "-scared", \
"-blink" and "-dead"; to have all enemies share graphics, use \
"enemy-blink[-<direction>]", etc. The items are "pill", "energizer", and \
"bonus<number>" (e.g. "bonus1", "bonus2", etc.). Upon loading a theme, Kapman will \
search for bonus items as long as there is a suitably-id'd "bonus<number>", and will \
use as many as are found, one per level, repeating after all have been used once. The \
pill sprite may also make use of this system (i.e. "pill1", "pill2", etc), in which \
case each pill in a maze will be randomly assigned one of the available graphics \
(useful if you don't want the pills to all look the same).

Actors (the player and the enemies) except for "player-dead" may have their animation \
timing specified in one of two ways. The first way is movement-based, by using an id \
of the form "anim-<name>-move-<pixels>". For example, the id "anim-player-move-4" \
means that Kapman will only move the player in 4-pixel steps, incrementing one frame \
for each such movement. (This is intended to be used to produce aligned "walking" \
animations.) The other form, which is also used for items, is \
"anim-<name>-time-<ms>", which means that Kapman will increment one frame in the \
sprite's animation every <ms> milliseconds. For example, if the energizer has 8 \
frames, the id "anim-energizer-time-125" will cause the animation to repeat every \
1000 ms == 1 second. Note that actors using time-based animation are allowed to move \
independent of their animation. Kapman will update the position of such actors as \
often as possible. For either type of animation, Kapman may skip frames if it is not \
able to redraw fast enough. If no object id gives animation information, only the \
first frame of a sprite will be used. (This also means that you may omit the \
animation id for non-animating sprites.) If no "enemy<number>" animation hints are \
found, Kapman will also look for "anim-enemy-<...>". Similarly, when searching for \
animation data for enemy subtypes, Kapman will try "enemy<number>-<subtype>", then \
"enemy-<subtype>", then "enemy<number>', and finally "enemy".


["sprites.svgz" (image/svg+xml-compressed)]
["wall.svgz" (image/svg+xml-compressed)]

_______________________________________________
kde-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel


[prev in list] [next in list] [prev in thread] [next in thread]