[Telepathy] GSoC idea: Gnome Games + Telepathy Tube

[Alban Crequy]

Le Fri, 20 Mar 2009 11:44:49 +0800,
Zhang Sen <zh.jesse at gmail.com> a écrit :

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

Abicollab has some explanations how they do undo in collaborative
editing:
http://www.abisource.com/wiki/AbiCollab#Problems_with_undo
It would be nice if you can undo your local moves when you are in a
different, not related area of the maze. The problem is, do we want a
maze to be solvable using the undo feature when you would be stuck if
the undo feature was not there?

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

There should be no code at all dedicated to deal with the different
CMs. The Sudoku application do not need to know if the contact's
protocol is jabber or link-local.

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

What happens if a box is pushed in 2 different directions by the 2
players at the same time? Like this:

 @$
  @

@ is a player, $ is a box. A player pushes the box to the right, the
second player pushes it to the top.

I guess you can decide that the initiator of the game can accept or
deny a move. Would the second player's UI update the view only if the
move is accepted by the initiator? In this case, the latency will make
the game less usable...

Or each player update his view immediately, but in case of conflict, it
needs to be resolved.

> [...]

Cheers,
Alban