[Kde-games-devel] Kapman sprite system (also, connecting-tiles systems)

[Thomas Gallinari]

As I said in a previous mail, we do not have a lot of time to spend on
Kapman for now, just be patient if we don't answer instantaneously
please !



You want feedback from maintainers, here it comes! ;)

IMO Mauricio and Eugene are two important artists of KDEGames, and they
both deal with IDs, as other artist seem to do. This is for me a
sufficient reason to keep the existing system that is used in Kapman.



Another reason for that, is that a tile based maze will be a huge
change in the game, and moreover you seem to be ready to develop an
animation library (that is a very good point!). I don't think that it
is necessary to make the amount of work bigger than it needs to be.



There is a last important thing to me: I (and Pierre-Benoit) agree to
let you working on Kapman since (I'm going to repeat myself) we don't
have time for now (and after all, the trunk is frozen). But we never
said that you could replace all our code by yours, (including code
formatting and so on)! Please be moderated and take our work and the
other developers advice in account before running to your computer and
refactor the whole Kapman, I could not work with you otherwise!



Thanks for your understanding.



Regards.


--

Thomas GALLINARI

--- En date de : Mer 10.12.08, Matthew Woehlke <mw_triad at users.sourceforge.net> a écrit :
De: Matthew Woehlke <mw_triad at users.sourceforge.net>
Objet: Re: [Kde-games-devel] Kapman sprite system (also, connecting-tiles systems)
À: kde-games-devel at kde.org
Date: Mercredi 10 Décembre 2008, 20h48

Mauricio Piacentini wrote:
> Well, Matthew, it is difficult to argue with you. You asked for 
> feedback, we gave it.

Feedback from Thomas/Pierre-Benoit would be nice :-).

Yes, I've made up my mind w.r.t. not id'ing everything. I never saw an 
advantage to that approach, and frankly, it drives me nuts when I go to 
do artwork. Within that framework are questions like, does the hinting 
system sound sane, does the .desktop layout sound sane, etc.

And, to be fair, I guess no one has complained about the hinting (and 
Eugene had a positive comment), so...

As for the separate files, there were more complaints, and I'm 
considering them. I'm not convinced (yet) about trying to put hashed 
mazes in with everything else, but I will try to keep things so that 
everything /else/ can be in one file, since I see no major disadvantage 
there. So that feedback is also appreciated.

As you may have noticed, the 'id everything' is a bit of a sore spot
for 
me, though :-).

> But it seems like you already have a plan laid 
> out, so maybe it is better to execute it, and if games pick it up then 
> we can start embracing the shared classes, no problem! I am against 
> restricting what people want to code by any sort of "group
policy".
> 
> But in order to implement your goals, I think the Kapman maintainers 
> have to agree with it. If they do, no problem!

True, which is one reason I'm asking for feedback. And if not... as you 
said in your other thread, I'd have to start a wholly new project. 
Unfortunately, there would be a strong motivation for me to write 
another Kapman, for several reasons:

- I've written a pac-man clone before
- I already have artwork completed
- It's a not-horribly-complicated game that touches the technologies I 
need to exercise, namely tile systems and sprite animation

...and because I can't think of anything else offhand I'd be motivated 
to do. Obviously, because there is Kapman already I'd rather /not/ 
duplicate it.

> For the games I am 
> maintaining I prefer to keep the ID system for now, as it seems better 
> to render individual tiles, and I do not want to make existing themes 
> obsolete right now.

A "compatibility mode" might be interesting, but anyway, I
wouldn't 
suggest anything more than to take that one game at a time. For Kapman 
anyway I would probably do the work to convert all the existing themes 
(of which there is, ah... one) myself.

FWIW, for mahjongg tiles and card decks, what I remember of the themes 
is that the work would be almost zero; those are mostly aligned already, 
and inkscape can very easily and quickly clean up the small errors.

> I do not think QSvgRenderer (or KSvgRenderer) allows this directly, does 
> it? The API allows to map the whole SVG to a Rect on the Painter, but I 
> think it does not allow choosing a rect in the SVG to render. By 
> contrast, I was talking about the render method that takes an ID as a 
> parameter, and allows optimized rendering of just this bit (as the SVG 
> is already parsed and kept in the renderer object.)

Like I said, I did it before in Kapman... It apparently used to work. I 
don't know why it would no longer be working? I guess we'll find out.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Who wants to sing?" -- Orcs (Warcraft II)

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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20081210/715a78cf/attachment-0001.htm