kblocks: separate the game logic and the display logic?

[Dapeng Zhang]

Hi Mauricio,
Hi Arturo,

In past a few days, we analyzed the source code of KBlocks. Here is the
"class diagram" in UML (the screen shot of "dia").

http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks.png

We found that the game logic and display logic are mixed together. For
example, KBlocksScene is such a class.

In order to develop the two-player mode, I wonder if we could first
isolate the game logic, which will result in some significant changes on
the class view. If it is acceptable, I will send the proposed class
diagram in next a few days.

What do you think?

Regards

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

On Thu, Oct 8, 2009 at 10:25 AM, Dapeng Zhang
<zhangd@...> wrote:

> In past a few days, we analyzed the source code of KBlocks. Here is the
> "class diagram" in UML (the screen shot of "dia").
>
> http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks.png
>
> We found that the game logic and display logic are mixed together. For
> example, KBlocksScene is such a class.
>
> In order to develop the two-player mode, I wonder if we could first
> isolate the game logic, which will result in some significant changes on
> the class view. If it is acceptable, I will send the proposed class
> diagram in next a few days.
>
> What do you think?

Hey, very cool. Please go for it. I am interested in your proposal to
isolate this inside the QGV framework, could be something useful in
the future for other games and projects.

Regards,
Mauricio Piacentini
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Fri, 9 Oct 2009 12:37:26 am Mauricio Piacentini wrote:

> On Thu, Oct 8, 2009 at 10:25 AM, Dapeng Zhang wrote:
> > In past a few days, we analyzed the source code of KBlocks. Here is the
> > "class diagram" in UML (the screen shot of "dia").
> >
> > http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks.png
> >
> > We found that the game logic and display logic are mixed together. For
> > example, KBlocksScene is such a class.
> >
> > In order to develop the two-player mode, I wonder if we could first
> > isolate the game logic, which will result in some significant changes on
> > the class view. If it is acceptable, I will send the proposed class
> > diagram in next a few days.
> >
> > What do you think?
>
> Hey, very cool. Please go for it. I am interested in your proposal to
> isolate this inside the QGV framework, could be something useful in
> the future for other games and projects.
>

Yes indeed.

Believe it or not, I have been tinkering with QGV in the last few weeks ...
but not for KGoldrunner!  Although QGraphicsScene, from which one inherits,
is just a descendant of QObject, it does not seem to be completely independent
of QGraphicsView.  For example, it does coordinate transformations, but
apparently only into a wider "canvas" measured in pixels from the top left.

Many 2-D games need to have their own coordinate system, even if is only
(row number, column number) in a tiled grid, and the game logic needs to
be completely independent of how many pixels represent an object on the
physical screen IMO.  I like the OpenGL approach, where the scene is of
infinite extent in whatever coordinates you like and you only have to define
the boundaries of the view.

All the best, Ian W.



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

[Arturo Silva]

Dapeng Zhang wrote:

>
> Hi Mauricio,
> Hi Arturo,
>
> In past a few days, we analyzed the source code of KBlocks. Here is the
> "class diagram" in UML (the screen shot of "dia").
>
> http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks.png
>
> We found that the game logic and display logic are mixed together. For
> example, KBlocksScene is such a class.
>
> In order to develop the two-player mode, I wonder if we could first
> isolate the game logic, which will result in some significant changes on
> the class view. If it is acceptable, I will send the proposed class
> diagram in next a few days.
>
> What do you think?

hehe, I'm actually more of a fan really.  But thank you all the same
for directing that to me as well.  ^^

I agree, please go for it.  They don't call it the KDE "playground"
for nothing.  As long as there already exists a working and stable
version of Kblocks to fall back to (which of course there is in this
case), you're free to experiment as much and as often as possible, and
I wish you all the luck for it.  ^__^


--Arturo "C-quel" Silva
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dapeng Zhang]

Hi Mauricio,

We created a google document for the design.

http://docs.google.com/Doc?docid=0ARNiC8-1Cr5UZGc5cGdmbTNfM2R3NDdtaGc2&hl=de

Actually, we did not touch the QGV framework.

The basic idea is to separate "game" and "GUI". A set of classes are
created for preparing data for the display. Consequently, the "GUI"
classes will be only for displaying something.

If you think the proposal is fine, we will go on for the next step. The
goal is to have a single game according to the design. There will be
something new in svn this time.

regards

dapeng

Mauricio Piacentini wrote:

> On Thu, Oct 8, 2009 at 10:25 AM, Dapeng Zhang
> <zhangd@...> wrote:
>
>  
>> In past a few days, we analyzed the source code of KBlocks. Here is the
>> "class diagram" in UML (the screen shot of "dia").
>>
>> http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks.png
>>
>> We found that the game logic and display logic are mixed together. For
>> example, KBlocksScene is such a class.
>>
>> In order to develop the two-player mode, I wonder if we could first
>> isolate the game logic, which will result in some significant changes on
>> the class view. If it is acceptable, I will send the proposed class
>> diagram in next a few days.
>>
>> What do you think?
>>    
>
> Hey, very cool. Please go for it. I am interested in your proposal to
> isolate this inside the QGV framework, could be something useful in
> the future for other games and projects.
>
> Regards,
> Mauricio Piacentini
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel@...
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>  

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

[Dapeng Zhang]

hi,

I noticed that google requires to login. Sorry.

Here is the document

http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks_newDesign.pdf

cheers

dapeng


Dapeng Zhang wrote:

> Hi Mauricio,
>
> We created a google document for the design.
>
> http://docs.google.com/Doc?docid=0ARNiC8-1Cr5UZGc5cGdmbTNfM2R3NDdtaGc2&hl=de
>
> Actually, we did not touch the QGV framework.
>
> The basic idea is to separate "game" and "GUI". A set of classes are
> created for preparing data for the display. Consequently, the "GUI"
> classes will be only for displaying something.
>
> If you think the proposal is fine, we will go on for the next step. The
> goal is to have a single game according to the design. There will be
> something new in svn this time.
>
> regards
>
> dapeng
>
> Mauricio Piacentini wrote:
>  
>> On Thu, Oct 8, 2009 at 10:25 AM, Dapeng Zhang
>> <zhangd@...> wrote:
>>
>>  
>>    
>>> In past a few days, we analyzed the source code of KBlocks. Here is the
>>> "class diagram" in UML (the screen shot of "dia").
>>>
>>> http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks.png
>>>
>>> We found that the game logic and display logic are mixed together. For
>>> example, KBlocksScene is such a class.
>>>
>>> In order to develop the two-player mode, I wonder if we could first
>>> isolate the game logic, which will result in some significant changes on
>>> the class view. If it is acceptable, I will send the proposed class
>>> diagram in next a few days.
>>>
>>> What do you think?
>>>    
>>>      
>> Hey, very cool. Please go for it. I am interested in your proposal to
>> isolate this inside the QGV framework, could be something useful in
>> the future for other games and projects.
>>
>> Regards,
>> Mauricio Piacentini
>> _______________________________________________
>> kde-games-devel mailing list
>> kde-games-devel@...
>> https://mail.kde.org/mailman/listinfo/kde-games-devel
>>  
>>    
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel@...
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>  

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

On Mon, Oct 26, 2009 at 3:38 PM, Dapeng Zhang
<zhangd@...> wrote:
> hi,
>
> I noticed that google requires to login. Sorry.
>
> Here is the document
>
> http://allheim.informatik.uni-freiburg.de/~zhangd/KBlocks_newDesign.pdf
>

You obviously put a lot of thought into this, so I believe you should
implement it and see if it works ok in practice, and leads to code
that is more maintainable and easier to expand in the future. The
design document should probably be added to the repository as well, so
in the future people can have a look at it to understand how it works.

Regards,
Mauricio Piacentini
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dapeng Zhang]

Hi Mauricio,

The first version of kblocks is ready at

http://allheim.informatik.uni-freiburg.de/~zhangd/kblocks_new.tgz

It should be a single game with exactly the same functionalities to the
old one.

The new structure sets a basis for the further developments for
multi-player and (AI) game engine etc.. The structure is specified in uml
in the "dia" directory in the package.

The main idea is to separate the game logic and the display. The resulted
GUI code is much smaller than before. For example, kblocksscene.cpp is
reduced from 887 lines to (KBlocksScene.cpp) 323 lines. Extra classes,
such as KBlocksItemGroup and KBlocksControl, are created for the data
processing and game logic.

I wonder if there is a problem we didn't see. For example, We use a
different way to name files...

What's your opinion for the next step? Shall I commit it to svn, or start
a new directory in svn, or whatever ideas in your mind?

dapeng



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

On Nov 27, 2009, at 4:43 PM, Dapeng Zhang wrote:
Hello,

> What's your opinion for the next step? Shall I commit it to svn, or  
> start
> a new directory in svn, or whatever ideas in your mind?

Either start a branch of kblocks somewhere in /branches/kblocks/
new_cool_AI_and_stuff/, or just put it in /trunk/playground/games/
kblocks-refactoring/ or something. Anyway, working within KDE's SVN  
will expose your work to other developers. Just don't break /trunk/
KDE/kdegames/kblocks/ for now.

Best regards, your UML diagrams made a lot of sense to me.

--
tadeusz andrzej kadłubowski
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dapeng Zhang]

Hi,

Tadeusz Andrzej Kadłubowski wrote:
> Either start a branch of kblocks somewhere in /branches/kblocks/
> new_cool_AI_and_stuff/, or just put it in /trunk/playground/games/
> kblocks-refactoring/ or something. Anyway, working within KDE's SVN  
> will expose your work to other developers. Just don't break /trunk/
> KDE/kdegames/kblocks/ for now.
>
> Best regards, your UML diagrams made a lot of sense to me.
>  

I committed to trunk/playground/games/kblocks-refactoring/

cheers

dapeng

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

> I committed to trunk/playground/games/kblocks-refactoring/
>

Just a quick note to let you know I will have a look at it asap, after
catching up with my email backlog. Thanks for your efforts with
KBlocks.

Regards,
Mauricio Piacentini
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Mon, Nov 30, 2009 at 11:23 AM, Dapeng Zhang
<zhangd@...> wrote:

> Hi,
>
> Tadeusz Andrzej Kadłubowski wrote:
>> Either start a branch of kblocks somewhere in /branches/kblocks/
>> new_cool_AI_and_stuff/, or just put it in /trunk/playground/games/
>> kblocks-refactoring/ or something. Anyway, working within KDE's SVN
>> will expose your work to other developers. Just don't break /trunk/
>> KDE/kdegames/kblocks/ for now.
>>
>> Best regards, your UML diagrams made a lot of sense to me.
>>
>
> I committed to trunk/playground/games/kblocks-refactoring/
>

Hi. I spent some time with the code and the app and have some feedback
to give you, and also some questions to the kdegames members regarding
it :)

First of all, congratulations. The implementation according to your
UML is cool, and there is the separation (as far as possible) of game
logic and some QGV internals. I found some minor issues that would
have to be corrected, though:

a) When you change difficulty, the game does not warn you that it will
be terminated, as the original KBlocks. You can switch from one to
another to test: start a game, select a new difficulty on the status
bar to test.

b) There is no message when you pause or resume a game. Also, the
state of the buttons in the interface is confused when you pause for
example and start a new one using the difficulty popup. I think this
is related to issue a somehow.

c) There is a caching problem with SVG elements and switching themes.
To test, start a game. Then go to configure and switch from egyptian
to oxygen, or vice-versa. Some element will not be updated. If you
scale the window then everything will be right. Tip: I believe this is
the old issue when you put elements in cache just with the name and
dimensions as keys, it might be good to add the theme name as well (I
believe we did this on KMines a while ago)

d) Copyright information on some files is not quite right. I would
prefer if you keep the copyright of the original author (me) and add
yours on a second line. I understand you probaby started a new
template project and some of this info was lost, no biggie.

As for replacing the current KBlocks with this one after 4.4 ships: I
would agree with this if you take over maintainership for this code,
maybe with someone as a backup. I ask you to take over maintainership
as I feel that the current code is easier for me to maintain: it has
no known bugs, fewer files, fewer classes, and I do not mind the
logic/presentation mix for simple games like this, which was supposed
to be single player only by design. This has maybe to do with my
background, which is not in computer science or engineering.

So, hard question :) Are you planning to stay around at least until
4.6 ships, and take care of KBlocks until then? If you are, then
welcome! I believe you just need to correct the issues above and then
you can move the refactoring to trunk after 4.4 ships, and start
implementing your AI and multiplayer ideas as well.

People, comments?

Best regards,
Mauricio Piacentini
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Dapeng Zhang]

Hi Mauricio,

We are going to check a) b) and c) as soon as possible. Many thanks for
your testing.

For d), of course the original author(s) should be listed. Actually, I
got some support from the University. A student is doing the coding job.
He doesn't notice the copyright issue, and only listed himself. This is
of course wrong.

Yes, I'm planning to stay around as a maintainer.  There will be a
"formal" version in svn by the end of Jan... So far, the source package
in svn is only a start of the student.

It would be very nice if you could stay around, giving comments and so on...

best...

dapeng

Mauricio Piacentini wrote:

> a) When you change difficulty, the game does not warn you that it will
> be terminated, as the original KBlocks. You can switch from one to
> another to test: start a game, select a new difficulty on the status
> bar to test.
>
> b) There is no message when you pause or resume a game. Also, the
> state of the buttons in the interface is confused when you pause for
> example and start a new one using the difficulty popup. I think this
> is related to issue a somehow.
>
> c) There is a caching problem with SVG elements and switching themes.
> To test, start a game. Then go to configure and switch from egyptian
> to oxygen, or vice-versa. Some element will not be updated. If you
> scale the window then everything will be right. Tip: I believe this is
> the old issue when you put elements in cache just with the name and
> dimensions as keys, it might be good to add the theme name as well (I
> believe we did this on KMines a while ago)
>
> d) Copyright information on some files is not quite right. I would
> prefer if you keep the copyright of the original author (me) and add
> yours on a second line. I understand you probaby started a new
> template project and some of this info was lost, no biggie.
>
> As for replacing the current KBlocks with this one after 4.4 ships: I
> would agree with this if you take over maintainership for this code,
> maybe with someone as a backup. I ask you to take over maintainership
> as I feel that the current code is easier for me to maintain: it has
> no known bugs, fewer files, fewer classes, and I do not mind the
> logic/presentation mix for simple games like this, which was supposed
> to be single player only by design. This has maybe to do with my
> background, which is not in computer science or engineering.
>
> So, hard question :) Are you planning to stay around at least until
> 4.6 ships, and take care of KBlocks until then? If you are, then
> welcome! I believe you just need to correct the issues above and then
> you can move the refactoring to trunk after 4.4 ships, and start
> implementing your AI and multiplayer ideas as well.
>
> People, comments?
>
> Best regards,
> Mauricio Piacentini
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel@...
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>  

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

On Mon, Dec 14, 2009 at 7:23 AM, Dapeng Zhang
<zhangd@...> wrote:

> Yes, I'm planning to stay around as a maintainer.  There will be a
> "formal" version in svn by the end of Jan... So far, the source package
> in svn is only a start of the student.
>
> It would be very nice if you could stay around, giving comments and so on...

Great! I am going to stay around, and will be able to help you guys
with the transition, to be done after 4.4 is branched.

Regards,
Mauricio Piacentini
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel