[Kde-games-devel] KSnake development for KDE 4.

[Luka Marinko]

On 4/7/07, Matthew Woehlke <mw_triad at users.sourceforge.net> wrote:
> Luka Marinko wrote:
> > On 4/2/07, Matthew Woehlke wrote:
> >> I don't know how KAtomic stores them, but how would you store what are
> >> effectively 1bpp raster images in SVG (that would make this purposeful)?
> >> Or would this allow custom level graphics?
> >
> > from KAtomic:
> > feld_03=..###########..
> > feld_04=..#..#......#..
> > feld_05=..#.3#......#..
> > feld_06=..#.##......#..
> > feld_07=..#.#..#.####..
> > feld_08=..#....#.2..#..
> > feld_09=..###.#.....#..
> > feld_10=..#1....#...#..
> > feld_11=..###########..
>
> Hmm... that would be easy to make with a text editor, but it's very
> inefficient. (Actually some form of RLE is probably best if you have to
> home-brew it, otherwise just use zlib.)

Its easy to read with KConfig, then just iterate over fields. And its
much easier to understand code, than bit manipulation, and keeping in
mind endianes .

While it is inefficient compared to having 1bit bitmap, I think that
all the levels together will not be  be bigger than 100-200kb
uncompressed. That's acceptable to me.   I'll think about how to pack
them if at all, once I implement/test and convert existing layers.

> Hmm, here's a thought. A few years back I wrote a Pacman clone. The way
> I wrote the level data was by adding a built-in level editor to the
> program. How hard would it be to do something like that, do you think?

I am creating an level viewer/editor first, to get get to know
QGraphicView and svg. First I thought about building it using python
bindings, but i can't get pyqt to work on latest qt_copy.  I don't
plan to integrate it into the game itself though. It will be
standalone program.

> (Say, there is no K-Man yet, is there? Maybe I should port mine... :-))

Well if you insist :)) , its probably too late for KDE 4.0 though.

> >> Nibbles-QB used for() loops, if you want to be REALY retro you could
> >> store levels via scripts that create the level... but I think nostalgia
> >> would be the /only/ advantage to that. ;-)
> >
> > Basic levels can be simple to do in for loops, but more advanced
> > levels, could be a pain. Not really sure it's worth it.
>
> "but I think nostalgia would be the /only/ advantage to that"...
> followed by a wink, which was the hint that I was kidding. :-) (Well,
> not about how QB did things, but that we should do it in KDE.)
>
> > hmm maybe we could have retro style theme (I used to play Nibles on
> > yellow/black monitor :) )
>
> That would be cool, although "nostalgia" for me means ff6060 walls,
> 000080 background, and ffff60 for player 1. Or you could do the Apple II
> version with Real Phosphor Effects. :-)

When I have svg support in, I guess there could be approximation of
this. Although I don't know about Real Phosphor effect.

> >> I would like to multi player support I think. At least for a second
> >> player. It would be REALLY cool if you could support some kind of
> >> network play, but at least two people at one keyboard would be nice.
> >
> > I was thinking about it as well, I just didn't want to jump to
> > quickly. What i have in mind is _not_ having both players on same
> > board, instead each one is in its own board, but actions (stuff you
> > pick up) can affect your opponent. This means more that one type of
> > apple(object).
>
> Hmm... I'd still want both-on-same-board (any reason that's any harder
> than AI snakes?), but your idea sounds really cool also. More
> competitive, less cooperative. (In fact, maybe you could call them
> "coop" and "versus" modes?)

It's not about harder, I just don't think it belongs in this game.
(Personally I don't like AI snakes either, will keep them as an
option).  Two players on the same board resembles tron like games, (
look at ktron ). And I don't want to add networking just for the sake
of adding networking.


Luka Marinko