metagamesector-discuss Mailing List for Metagame-Sector

no release this weekend.

I'm bogged down with issues about message-passing over the internet. 
I'm trying to implement a Producer-Consumer model on both the Client and
Server side with XML-RPC.  Right now, I'm trying to wrap my head around
how that'll work with GTK.

some recent thoughts: 
- maybe I should package up all the View... Objects into "families" or
something.  ie, if i'm using the GTK MapView, then i'll probably be
using the GTK SectorView as well. another way of doing it would be to
give them all the same name, and do a 'from specificView import *' at
the top -- less code that way, and easier to change.

- a text-view could be done with curses, can't spend the time now to
learn it.

- could make a 'FreeBoard' game, where any player can do anything to any
item, and ALL requests are exposed through menus

- have each map notebook have a menu across the top.

andy

> Thanks for the reply, I'll probably keep track of your revisions and
> play with it again when you get around to the graphs.  In truth,
> my game is node-based, which are logically, but not visually, 
> equivalent to sector-based games.  Think Go.

First of all, just for the sake of talking about the same thing, I
differentiate between the types of Maps thusly:

Grid: sectors have a maximum of four neighbors, and all sectors have
four neighbors except for corner and side sectors

HexMap: like grid, but 6 instead of 4

GraphMap: no rules.

I looked up Go on the internet, and it could be done by making a new
View class for Grid, or by making a new View class for Sector.  (I've
separated everything logical from everything visual already)  

Does that make sense?

> 
> My initial goal with QUB was to create:
> - the image of a board
> - images for the two types of pieces
> - a package which allowed for arbitrary numbers of pieces to be placed
>   on the board

if that's all you want (if you want all the rules to be enforced by the
players), that's basically what the 'example' application does.  except
that there's a bug right now when you delete a piece.  but if that bug
was cleaned up, you could do this:

start 'example'
create 2 players,
start the game
after each player places one piece he ends his turn.
if a piece is surrounded, that player has to delete it.

> 
> QUB, which allows the PLAYERS to control the game needs no further
> functionality for at least 30-40% of board games.  
> 
> (Pieces which flip, stacking pieces, cards, are all another story of 
> course. I'm ignoring that for now.)
> 
> QUB does not allow you to create such a thing.  You must define
> relationships, behaviors, sets, etc. to play a game.  You can't
> just say "the board" "this set of pieces".  It seemed that
> to create the game I describe I would have to define several 
> description files and learn their overly complicated API.
> When you add to that the difficulty of setting up the system 
> itself, it is just not worth it.

so are you saying that QUB doesn't let you play simple thing like you
describe?  it forces you to put more complexity into the game?  IMHO if
a user wants to sacrifice features for simplicity, he should be able to.

> In fact, I found their approach of interface made it far more 
> difficult to use than a library where you overload and/or
> replace things, which would of course also allow you include
> all sorts of additional things like robot players, game logic,
> scoring, and so on.

cool.  Well hopefully this weekend will bring a new version of MGS with
that bug taken care of and internet communication working.

ttyl.
andy

Hey Davide,  how about signing up for the Metagame-Sector list and we
can move this conversation onto that.  That way everyone interested can
see what we're talking about.

You can sign up here:
http://lists.sourceforge.net/lists/listinfo/metagamesector-discuss


> I'm currently working with XML-RPC to do my networking functions.  The
> game server contains all the data, and a player basically has to send
> every command to the server, so cheating will be hard.
I think that sushi has alrady solved this problem. If you want, we can 
do a project mergirg: sushi-server is only the "switcher" and a python
API 
implements the players, the artifacts. So a Dungeon Master can easly
write a 
script that assign 50 xp point to all the players .... 

Unfortunately, this week is pretty busy for me, so I probably won't be
able to do new work until the weekend.  I guess what I should do firstly
is download and try out OpenRPG and QUB, and try and see the strengths
and weaknesses of those two projects.  Then I'll take a look at the
Sushi code and try to determine whether it would make sense to use that.

> We needs an easly extendible API that allow players to do a complete 
> characters tracking.

What do you mean here by "tracking"?  Do you mean having a data
structure for a Dungeons&Dragons style Player-Character (which is
probably nothing more than stats & inventory), and an appropriate set of
functions, like Attack(), Die(), Cast(), etc.?  For something like that,
I would subclass MetagameSector's Unit class.


> First of all we need to create a fast and small server 
> and client (and I think that sushi "fit this shoes").

like I said above, I'll take a look at Sushi this weekend.

> Then we need a program 
> that allow players to choose the right server on the net (and you are in the 
> right way...). 

Yeah, this is something that I could get a quick version 0.1 done on the
weekend.

Thanks for the reply, I'll probably keep track of your revisions and
play with it again when you get around to the graphs.  In truth,
my game is node-based, which are logically, but not visually, 
equivalent to sector-based games.  Think Go.

I can implement my game with sectors, but the canonical representation
is with nodes.

Do you think your system would allow for that? just curious.  

> I haven't had any experience with QUB other than browsing the website. 
> what makes it so difficult?

(overly long answer maybe)

My initial goal with QUB was to create:
- the image of a board
- images for the two types of pieces
- a package which allowed for arbitrary numbers of pieces to be placed
  on the board

QUB, which allows the PLAYERS to control the game needs no further
functionality for at least 30-40% of board games.  

(Pieces which flip, stacking pieces, cards, are all another story of 
course. I'm ignoring that for now.)

QUB does not allow you to create such a thing.  You must define
relationships, behaviors, sets, etc. to play a game.  You can't
just say "the board" "this set of pieces".  It seemed that
to create the game I describe I would have to define several 
description files and learn their overly complicated API.
When you add to that the difficulty of setting up the system 
itself, it is just not worth it.

In fact, I found their approach of interface made it far more 
difficult to use than a library where you overload and/or
replace things, which would of course also allow you include
all sorts of additional things like robot players, game logic,
scoring, and so on.



__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Hi.

Arbitrary graphs have not yet been implemented.  The plan is currently
to get client-server over the internet working (going to try to learn
XML-RPC and implement something by sunday).

Then I'll probably finish off the HexMap stuff, and after that Arbitrary
Graphs (they're needed for my Risk Clone).

I welcome the input, as I want the direction of what to implement next
to be driven by (potential) users of the framework.

I haven't had any experience with QUB other than browsing the website. 
what makes it so difficult?

sjbrown

You mention arbitrary graphs in the php file, but i didn't see graph or
arbitrary as an item with grep.  Can you give me the 2 cent description
of this arbitrary graph support?  

I've been wanting to make up a board
game but haven't wanted to learn enough gui to make the board.. which
is sort of geodesic dome shaped.. some hexagons and some pentagons.

Thanks.  Looks like a great project!
Just try to keep it simpler than the horrifying QUB.

-josh


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/