KSnake development for KDE 4.

For some time now, I wanted to (had an itch) to help develop
KDE. But since
most of my programming to date has been on server side (C,
Java, PHP,
python), never found enough time to to learn GUI programming
or C++. Now I
have some more time, and decided to finally do it.

So after reading a few blog's, and kde wiki's I decided that
best place to
start are probably the games. 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.

What I am planing on doing: 
- first I intend to port graphic to the svg.

- 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 

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.

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

1.Pick up given number of apples(depends on the level)
before you can move
to the next level (less time you spend doing and higher the
level  - higher 
score) 

2.Pick up as many apples as possible, each time you do you
grow or speed
increases, you don't advance to next level. (How long do you
last 
)
(probably needs dedicated levels)

3.Survive against enemy snakes, survive some amount of time
against killer
snakes (maybe balls also), you _don't_ grow (so you can't
box yourself in
someplace  ).

In general I think this is the sort of the game that
shouldn't complicate
too much, it should be quick to load, and quick to play. 

-Sound: I  listen to my ogg's and mp3's ), so I
have no plans in that
regard. (thats said phonon api is nice, if there is demand
for music/sound
in games)

Maintainer: KSnake currently has no maintainer. Since I am
so new/fresh I
don't think I am capable of being one just jet. So what do
we/I do ? Is
there someone willing to at least temporary take over ? or
perhaps just
move it to playground, until it's up to speed ?

While I am sure I can learn to do everything myself, I will
take any help 
I can get, weather this is in form of pointers, suggestions,
graphics,
comments, 
code or tips&tricks.

PS: I am not directly subscribed to this group, I read it
through gmane-news
gateway. (KNode rox's )
-- 
Luka Marinko <luka.marinkogmail.com>


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

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?

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

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

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. 

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

-- 
Mathew
(sorry, .sig file is on the other computer)

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

On 4/2/07, Matthew Woehlke <mw_triadusers.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
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

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

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?

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

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

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

-- 
Mathew
(sorry, .sig file is on the other computer)

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

On Sat, 7 Apr 2007 01:00 pm, Matthew Woehlke wrote:
> Luka Marinko wrote:
> > from KAtomic:
> > feld_03=..###########..
> > feld_04=..#..#......#..
> > etc.
> >
> 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.)
>
KGoldrunner also uses something like that, 1 byte per tile
and a few hundred
bytes per level.  It's not all that inefficient compared to
all other things.

> 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?
>
KGr has an editor of course and it was not that hard to
write.  I used
it to copy, by hand, all the levels my son composed on the
Apple II
years ago.  The code got a bit large and tedious though when
I included
stuff to resequence levels and copy them between games.

> (Say, there is no K-Man yet, is there? Maybe I should
port mine... )
>
Why not ...   The more
the merrier, I say!

All the best, Ian W.

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

On 4/7/07, Matthew Woehlke <mw_triadusers.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
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

Luka Marinko wrote:
> On 4/7/07, Matthew Woehlke <mw_triadusers.sourceforge.net> wrote:
>> Luka Marinko wrote:
>>> On 4/2/07, Matthew Woehlke wrote:
>> 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.)
> 
> 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.

Ok. FTR if I were going to compress stuff I would a: use
zlib if it's 
easily available, or b: use a byte-wise RLE. The latter
would be 
something like 7 bits to represent the tile (think you need
more than 
127 tiles?) and one rle bit. If the RLE bit is set, the next
byte is a 
repeat count minus 2 (we know it repeats at least once, so
it makes 
sense to map 0->2, 1->3, etc), otherwise the block
does not repeat. Runs 
longer than 257 are represented by simply having a second
run of the 
same block. For the sort of data being stored, this is
pretty efficient, 
and the algorithm is very simple (and I don't think
endianness matters 
here?)

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

That works too. The point was that if there is a level
editor other than 
KWrite, the internal storage format has less need to be
human-readable.

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

No worries, I wouldn't be able to port it for 4.0 anyway.
 I
might 
try to port it, though, since I already have a working
version, it just 
needs to be ported from OpenGL+WinAPI to QT+KDE. Also the
graphics are 
much simpler, so I can do them myself without taking months
just for the 
graphics. (And I could drop it into playground as-is, since
it runs 
as-is right now.)

>> 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 want to say the BSOD screen saver has an example,
basically you can 
see the individual pixels as dots. (I imagine making them
fade out would 
require support in the code.) Anyway I'm still just tossing
around ideas 
I found amusing. 

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

Well, since I remember playing 2-player ("coop")
Nibbles back in the old 
QuickBASIC days, I guess I'll have to disagree with you
there. 

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

No worries, networking might be a touch overkill anyway.

-- 
Mathew
(sorry, .sig file is on the other computer)

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