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

[Matthew Woehlke]

Luka Marinko wrote:
> On 4/7/07, Matthew Woehlke <mw_triad at users.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)