--===============1065357991==
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="E/DnYTRukya0zdZ1"
Content-Disposition: inline


--E/DnYTRukya0zdZ1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 21, 2003 at 09:30:19AM +0200, Adam Hunt wrote:
> I was just thinking about how you want to generalize monopd so that other
> board games could be served.  It seems to me that board games can be
> represented perfectly as finite state machines.  Maybe all you need is a
> server that has a FSM at it's core running a model for whatever game.=20
> This would allow for games to be designed in something like Umbrello and
> the resulting UML code (which happens to be XML) could be used by the
> server.
> =20
> I'm a bit sleep dep'ed right now so if this makes no sence I appologize.=
=20

It makes sense, but it might be overgeneralization. And the server would
still need a model to communicate objects, decisions, dialogs and events
with clients.

Also, while the states might be finite, it's definitely not a small number,
not even for Monopoly alone, with its trades, auctions, chance cards.. those
concepts alone introduce a far more complex possible set of states than
chess for example, for which the permutation of states is limited to he
number of possible ways to have up to 32 tokens in play on at 64-square
board (still a large number though). And Monopoly has a dynamic number of
starting players. Furthermore, since it's possible to have a situation where
all players get richer (no Monopolies) each turn, I'm questioning the finite
state concept for the one board game I've always supported. ;-)

Instead, what I'm trying to do is to have some preformatted behavior macros
for common board game objects and to calculate the state based on what
happens in the game. Monopd is what it is for historical reasons: a
Monopoly-server being generalized for other board games.. starting from a
generalized concept and then implementing states would probably be a
completely different project.

I'm not worried about generalization of the engine code that much, though.
It's a challenge, but I'm giving priority to supporting SVG in the Atlantik
client at the moment: I can't be motivated to support board properties I
can't depict in the client. ;-)

Once Atlantik can properly render SVG boards and identify squares on it, I
will probably continue generalization in the following order:

- support a simple game with *custom* token placement instead of one where
  tokens move based on throwing dice.. three in a row seems like a perfect
  simple game for this. Tokens aren't really generalized yet (they are
  implied from player properties such as position, but that's no biggie to
  fix/improve), but once I can do three in a row I'm pretty sure Othello and
  Go would be quite easy to implement, although those games add limitations=
 on
  where tokens can be placed and have effects directly after placement.
- support a more complex game like chess, which doesn't let you place
  tokens, but move them according to certain rules.
- support path/borders (Game of Life and Ludo require this, and I want to r=
emove
  hardcoded with linked lists anyway)

But again, my engine ideas have been stalled a long time due to the lack of
a nice way to depict boards of various shapes. Now that I've decided on SVG,
that will hopefully change..

As for FSMs.. I'm afraid the design of board game logic in UML would be
complex enough to require a motivated developer and - I'll be honest - I
don't think that's me, I'm quite happy improving monopd step by step in its
existing ways. ;-) (trying to write down functionality of board games in UML
sounds boring once you've already coded one in C++, I'd hate to "properly"
design a Monopoly game heh.. starting with a "there's 40 squares and you can
walk around but not do anything" server might have slowed me down, but at
least it kept the project fun for me and didn't turn it into vaporware!)
=20
Rob
--=20
Rob Kaper     | "In the name of sheer pity, won't someone operate on
cap@capsi.com | Chairman Arafat and put that poor cancer into a cleaner
www.capsi.com | environment? -- Rick Brookhiser

--E/DnYTRukya0zdZ1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/lPJutppIl2G1SjcRAgjkAKCMgzdTJYJiyDwOacfwu12hc6XgMQCfVa7F
ZTY3nCNkymAzfMzkgWClr/E=
=imN0
-----END PGP SIGNATURE-----

--E/DnYTRukya0zdZ1--

--===============1065357991==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
atlantik-devel mailing list
atlantik-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/atlantik-devel

--===============1065357991==--