Re: GSoC idea: Gnome Games + Telepathy Tube

["Thomas H.P. Andersen" <phomes gmail com>]

On Fri, Mar 20, 2009 at 04:44, Zhang Sen <zh jesse gmail com> wrote:
> Thanks to all, for the great hints you gave :)
>
> On Thu, 2009-03-19 at 17:31 +0100, Thomas H.P. Andersen wrote:
>> Sudoku should be fairly easy to do I think since transformations
>> (filling in/removing a number) does not depend on the previous state
>> of the board. Lag and locking should not be big problems in sudoku.
>
> Yes, that makes it easier. But the undo/redo feature needs some
> thinking. Roughly we can make undo/redo only works locally, no matter
> collaborative mode or competitive (also single-player mode).

Oh yes. The joy of undo in collaborative applications :) I have a few
papers about that laying around if you need more material about that.

>> Features I would like to see:
>> - Ultra simple start. Just drag 'n drop a friend from IM app, or fetch
>> a list of online IM friends to show inside the game. Easy set up of a
>> game on LAN would be really nice too.
>
> The drag 'n drop is cool! Let me first find out how the general
> drag/drop works :)
> For LAN games: two connection managers provide tubes; gabble handles
> jabber case and salut handles link-local. So just like what empathy
> does, the contact list can be of two parts, one for jabber(maybe also
> msn in the future?) and one for 'People Nearby', people can choose
> respectively.
> When dragging and dropping, we can also know if the contact is from
> gabble or salut. This should be quite transparent and there shouldn't be
> much code dedicated to deal with the different CMs.
>
>> - Game modes (collaborative / competitive)
>
> Good idea, but how should the competitive mode be like? We can let a
> player win if (s)he fills more (different weight with each filed).
> However, even in collaborative mode, we can also record who fills more
> and give a grade finally.
>
> Adam's idea is that players still have different puzzles but compete for
> speed (telepathy is only there to display the other's game), right? This
> also works, and we can develop an algorithm to calculate grades based on
> time and difficulty. This mode of competition is common with tetris
> games but I think it's less fun for sudoku, which lacks action and fancy
> stuff. E.g. people generally don't like to watch a guy playing sudoku.

Maybe the players can play the same sudoku but only see that the other
player has filled in something but not what number.This way you can
still get stressed as your opponent gets ahead but not just copy his
results.

> So what about we have just one mode: people complete (or collaborate) to
> finish the puzzle and in the end, players' credit/contribution is
> displayed?

Sure. We can move on to more game types later if needed.

>> - Awareness UI. In collaborative mode it would be nice to have a
>> "shadow" of the other players focus to avoid both players working in
>> the same area.
>
> Cool, I would include this.
>
>> - Scoring: How would one win in competitive mode? Sudoku can already
>> find a difficulty rating for each field depending on how obvious it
>> is. Some sort of penalty for guessing wrong too?
>
> Sure this difficulty rating can be used, good idea!
> The rating system can be that, all changes to a filed are considered and
> become part of final score. A filed has 3 state: None, Right, Wrong. So
> we can add award and penalty to every state change. I need further
> thinking into this, because there are issues of network delay, judging
> which filling is the final one.
>
>> - Versioning. How to implement this to best prevent that future
>> versions become incompatible.
>
> Do you mean a newer sudoku tries to connect to one of older version? We
> can check version or check tube capacity if tubes are to be made
> optional.

Yes. Basically making sure we announce the version we are running.
Also trying to make the protocol general rather than specific for the
implementation. This is all pretty vague but it is good to keep in
mind that future versions may want to do things differently
internally.

>> I think that doing multiplay in sudoku is both very innovative and
>> fun. However most of the games are in C and I would have liked a
>> general solution that could be used in all the games. Perhaps you can
>> even manage both? :)
>
> Yes a general solution would be great, I will surely stick with gnome
> and gnome-games in the future, but I don't know if I can finish both
> tasks within a summer ;)
> I think we can implement an interface similar to GGZ's, so existing
> network games won't need big change and others can be changed in the
> same manner.
>
> Cheers,
> Zhang
>
>