headers
Jason McIntosh | 18 Apr 01:21
Gravatar

Volity 2005 (again)

On Feb 1, 2005, at 2:45 PM, Jason McIntosh wrote:

> I expect to finish the next Frivolity release this weekend (on 
> schedule), after which I'll focus on helping the Javolin 0.1 release 
> happen.

Well, so much for _that_. My dayjob continued to kick my ass through 
mid-March, and then I got distracted by other things. While the other 
things were, in fact, directly related to the Volity project, they 
managed to keep me away from active technical development or management 
anyway.

Sorry to be coy about it; it's only plans and schemes for now, and I 
don't want to say anything about it on a public (and Web-archived) 
mailing list yet. If you're really curious, feel free to ask me about 
it off-list.

I can say this much: as part of our strange and sinister secret plans, 
Andy and I are going to push to complete the system this summer, enough 
so that a public beta, open to both game players and game developers, 
will exist by the end of this coming August. I'll be reworking the 
(once more completely out of date) task list appropriately, putting 
most of the demand on the two of us.

(To further the chances of our actually meeting this goal, Andy and I 
are rearranging things to give us more time to work on the project. I 
for one don't expect to put it down again.)

In the meantime: I have checked some big changes to Frivolity into CVS, 
implementing all the seat and readiness functionality discussed at the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Turner | 19 Apr 20:56

Semi-OT: Board game related podcast

http://www.boardgamegeek.com/geekspeak.php3

The most recent episode:
> In this episode Derk and I speak with Guido Teuber of Catan GmbH.
> We talk about his gaming background, playing games with his Dad
> (Klaus), playtesting Catan, and the business of games. We take a
> break and get a review of Fairy Tale from Ted Cheatham. We also get
> to talk with Guido about the Catan world and future developments.
> We also talk about mainstream vs. niche markets, and we finish up
> with the hook. A real fun episode with a lot of joking around.

--

-- 
Andy <turner <at> mikomi.org>

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
Permalink | Reply | 0 comments |
headers
Jason McIntosh | 20 Apr 06:30
Gravatar

New Javolin lists

I just created a couple of new mailing lists, one for Javolin 
devlopment and one for Javolin endusers. (Yes, I do expect to have 
Javolin endusers someday.) They're for discussions that are more about 
how the Javolin application works than about the Volity platform.

volity-javolin-dev: 
https://lists.sourceforge.net/mailman/listinfo/volity-javolin-dev

volity-javolin-user: 
https://lists.sourceforge.net/mailman/listinfo/volity-javolin-user

(Sorry for the cumbersome names; SourceForge insists that they start 
with "volity-".)

I've signed some of you up to the javolin-dev list already. If you 
don't get a test message from it shortly after you receive this one, 
then I probably didn't; in that case, feel free to sign up if you'd 
like.

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
Permalink | Reply | 0 comments |
headers
Doug Orleans | 1 May 03:55
X-Face

Re: How referees should respond to illegal plays

Jason McIntosh writes:
 > Secondly, fault packets simply can't hold very much data (so long as 
 > they stick to the XML-RPC standard); the code has to be numeric and 
 > therefore not immediately human-readable, and it can't contain any 
 > arguments.

That's not true, RPC faults have both an integer code and string.  And
I think it would be okay to insert our own subelements to the fault
XML (in the Volity namespace) if we really need something more
structured than a string.

 > That is, the ruleset would define a set of referee-to-client 
 > RPC requests that would handle every possible error condition.

I don't think I like this.  It's too asynchronous.  It seems natural
for an erroneous request to result in a fault response, but it would
be a pain to have to set up a handler for error "requests" that can
come at any time.  What do you propose should be the result of the
original request, if not a fault?  If you don't like using/extending
RPC faults, how about coming up with our own error structure that
would be returned as the (non-fault) result?

--dougo <at> place.org

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
(Continue reading)

Permalink | Reply | 17 comments |
headers
Jason McIntosh | 1 May 01:20
Gravatar

How referees should respond to illegal plays

Currently, game-level errors (i.e. illegal moves) are handled by RPC 
faults. For example, if you try to play the three of clubs when you're 
not holding it, the referee responds not with a positive RPC response 
packet but with a fault, containing a numeric error code defined by the 
ruleset.

I concluded a while ago (encouraged by developer feedback) that this is 
actually incorrect behavior. For one thing, RPC faults should probably 
be reserved for lower-level errors, such as malformed RPC requests. 
Secondly, fault packets simply can't hold very much data (so long as 
they stick to the XML-RPC standard); the code has to be numeric and 
therefore not immediately human-readable, and it can't contain any 
arguments.

One developer suggested replacing the faults with a standard "illegal 
play" referee-to-client RPC request, whose arguments would be a text 
string identifying the error (from a list of possible strings defined 
by the ruleset) and an optional argument list.

On thinking about this a bit, I propose something simpler: much as 
table configuration is now defined by the ruleset (see 
http://www.volity.org/wiki/index.cgi?Table_Configuration), so is error 
handling. That is, the ruleset would define a set of referee-to-client 
RPC requests that would handle every possible error condition. Rather, 
every possible _class_ of error; the arguments would contain the 
specifics, and it would be up to the receiving UI to pass this 
information to the human player as best it can.

So, the Eights ruleset would add seven RPC requests, perhaps with these 
names (based on the list currently at
(Continue reading)

Permalink | Reply | 18 comments |
headers
Jason McIntosh | 1 May 21:37
Gravatar

Re: How referees should respond to illegal plays

On Apr 30, 2005, at 9:55 PM, Doug Orleans wrote:

> Jason McIntosh writes:
>> Secondly, fault packets simply can't hold very much data (so long as
>> they stick to the XML-RPC standard); the code has to be numeric and
>> therefore not immediately human-readable, and it can't contain any
>> arguments.
>
> That's not true, RPC faults have both an integer code and string.

The string isn't really data in the way that the code is, though. It's 
meant to be a human-readable string for passing directly to the user. 
But in taking advantage of this, the referee is overstepping its 
limits, I think. We last year decided that referees make all their 
in-game communication in the form of ruleset-defined RPC requests, but 
here they are passing a string?

The specific objection I've heard from two different people is that, as 
UI authors, they want total control over what the player sees when they 
try to do something illegal. If it's left to an RPC fault, then control 
stops at the client without getting passed to the game UI. (In the case 
of Javolin right now, this takes the form of a dialog box that displays 
the string.)

>   And
> I think it would be okay to insert our own subelements to the fault
> XML (in the Volity namespace) if we really need something more
> structured than a string.

I really want to avoid doing any XML-level diddling in any part of
(Continue reading)

Permalink | Reply | 9 comments |
headers
Doug Orleans | 2 May 00:05
X-Face

Re: How referees should respond to illegal plays

Jason McIntosh writes:
 > On Apr 30, 2005, at 9:55 PM, Doug Orleans wrote:
 > 
 > > Jason McIntosh writes:
 > >> Secondly, fault packets simply can't hold very much data (so long as
 > >> they stick to the XML-RPC standard); the code has to be numeric and
 > >> therefore not immediately human-readable, and it can't contain any
 > >> arguments.
 > >
 > > That's not true, RPC faults have both an integer code and string.
 > 
 > The string isn't really data in the way that the code is, though. It's 
 > meant to be a human-readable string for passing directly to the user. 
 > But in taking advantage of this, the referee is overstepping its 
 > limits, I think. We last year decided that referees make all their 
 > in-game communication in the form of ruleset-defined RPC requests, but 
 > here they are passing a string?

It's not "passing" anything, it's returning a fault response to the RPC request.

 > The specific objection I've heard from two different people is that, as 
 > UI authors, they want total control over what the player sees when they 
 > try to do something illegal. If it's left to an RPC fault, then control 
 > stops at the client without getting passed to the game UI. (In the case 
 > of Javolin right now, this takes the form of a dialog box that displays 
 > the string.)

This is easy to change in the Javolin client library.  The "rpc"
ECMAScript function could be made to raise an ECMAScript exception
when it gets an RPC fault, instead of calling the ErrorHandler that
(Continue reading)

Permalink | Reply | 8 comments |

Gmane