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

[Luka Marinko]

On 4/2/07, Matthew Woehlke <mw_triad at users.sourceforge.net> wrote:
> Luka Marinko wrote:
> > I also noticed that KSnake isn't getting much
> > attention. Since i quite like this kind of games (all the way back from DOS
> > nibbles) I decided to do something about it.
>
> Well, I don't play KSnake, so I decided to look before replying... one
> thing that could use some love is the controls, comma, utter lack of
> responsiveness (at least on my computer)! Anyone else have this problem?

Works fine here, but I'll take a look at controls code, since there were some
bug reports on bugs.kde.org as well

> > What I am planing on doing:
> > - first I intend to port graphic to the svg.
>
> Good, good. :-)
>
> > - Another problem is size of game area. By default size window is about 1/4
> > of the size of 17 inch monitor (1280x1024). even with svg graphic if you
> > maximize the window game will look odd, since everything will be too big.
> > So we need bigger levels, but if we just increase current level size, you
> > get more room to move in, and game gets easier as a result. So we also need
> > new levels :)
>
> In Nibbles (the Microsoft QuickBASIC version), levels were IIRC 78x~44
> (not counting the outer border which of course is solid, although
> perhaps you would like to add wrapping ala Pacman? :-)). I think that's
> a reasonable size. I don't think I would want to go bigger than that;
> big (and DETAILED! :-)) graphics are OK IMO.

I could do that, but then again, if we add multi player we could use
bigger levels :). I mainly just want to support runtime loadable
levels, plus having possibility to have more than one type of walls.
(and 1 bit per pixel level design is so 1980 :) ).

> > Current levels (and so is title screen and Level loading graphic) are stored
> > as 1 bit per pixel bitmap, stored in header files which get linked in at
> > compile time. I intend to change this to something that gets read at
> > runtime.
> > I had some discussion about this on #kdegames and one suggestion by
> > marktaff, is to store levels in svg (with help of clones and id naming
> > scheme), the other one is to store levels similar to how katomic stores
> > them. I welcome other suggestions.
>
> 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=..###########..

and yes this means i can use 254 different tiles, if the need arises.
What I would really like instead is to group a few levels together,
with perhaps a  common theme, so that you don't have 80 levels each
one adding horizontal line or two.

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

hmm maybe we could have retro style theme (I used to play Nibles on
yellow/black monitor :) )

> > - About gameplay,  I find enemy snakes and balls annoying so I would change
> > the default game style to be without them. I was thinking of providing a
> > few pre-configured game styles(This is just a few of top of my head,
> > suggestions welcome ):
>
> 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).

This needs some more thought put into it.

Thanks for your suggestions

Luka Marinko