headers
Jason McIntosh | 18 Dec 19:13
Gravatar

Eights SVG

I have published a new SVG UI for Crazy Eights, intended to serve as a 
model for more sophisticated UI files. Not optimally pretty, but it 
does the job. At the moment, it's primarily lacking card-play 
animation, so cards blink into place when played, instead of sliding 
smoothly into the discard pile; I have yet to get the hang of 
script-based animation.

The file does, however, manage to demonstrate simple user feedback, 
such as the onmouseover actions attached to the cards in hand, the use 
of color in the scorecard to indicate whose turn it is, and the 
presence of eye candy (a "Loading..." message) during the interval 
between the player clicking "start game" and the client receiving and 
rendering all the setup information.

It's registered with the bookkeeper, so if you build Javolin (via CVS) 
and create a table at eights <at> volity.net/volity, the file will 
automagically load. It's also checked into CVS under the games-ui 
module, and you can just look at the thing yourself by downloading it 
from http://volity.org/games/eights/svg/eights.svg . The comments point 
out some places I had trouble with; any of y'all that know ECMAScript 
better than me (not saying much) should feel free to make repairs.

The big mess at the start is an SVG font definition for the suit 
symbols, which I ripped off from an Apple typeface. Then the file goes 
on to define 55 <symbol> elements for the whole deck (inlcuding two 
jokers and the card back) before going on to the eights-specific 
symbols and functions. For the sake of laziness, they're all in the 
same file, but I see a future where UI files will instead pull in 
common components like card decks , and perhaps even function 
libraries, through external entity references (an XML feature that lets
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 20 Dec 00:04
Gravatar

Roadmap

I've created a project roadmap (of sorts) through the long-neglected 
task manager on Volity's SourceForge site. See: 
https://sourceforge.net/pm/?group_id=91751

Click on the project names to see the tasks I've declared under each, 
with due dates, dependencies, and assigned developers. Note how I've 
added Javolin 0.1 and Javolin 0.2 as separate, chronologically 
sequential projects. If this new approach to the task list works, I 
plan on treating every future project/version combination as a separate 
project, each one ending with a "release" task.

The whole thing carries us through May Day of next year. By then, if 
all goes according to plan (uh oh), we should have an implementation 
(server- and client-side, as appropriate) of just about every major 
feature discussed over the last year (even seats, to a degree... more 
on that in a separate email), with definitive documentation for the 
whole mess.

Doug and Karl, I assigned you to a lot of stuff in the Javolin 
projects, but tried to pace things sanely. Please let me know how 
reasonable you feel the date ranges are.

For my part, I'll be tying up Frivolity (where I've got most of the new 
features half-coded already), but largely working on a new RFC-style 
codification for "Volity 1.0" -- documentation, that is, for the 
platform itself, with its attendant protocols. (Is one monolithic 
document the way to go, with this? I can't think of a reason not to, 
right now.)

As always, if you have a SourceForge account and wish to tinker with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 20 Dec 04:25
Gravatar

Seats

The "seats" I mentioned in the previous post are a much simpler idea 
than the discussions we were having some months ago. They're actually 
more of a solution to the game-observation problem than anything else. 
Basically, I'd like to copy Yahoo Games' approach, by letting every 
person at a table toggle between "seated" and "standing". A standing 
player is at the table, able to communicate with the other players and 
(if the game is underway) able to receive public-level game events from 
the referee, but is not actually playing. (In which case "player" may 
technically become a misnomer, but whatever.)

Players tell referees when they're standing or sitting via RPC 
requests, and the ref responds by updating the other players through 
RPC.

For practical purposes, this gives us three possible "positions" a 
player may have, with respect to a table:
- Standing, not playing
- Seated, but not ready to play
- Seated and ready to play (or actually playing)

Thoughts? (The business about readiness/unreadiness: 
http://www.volity.org/wiki/index.cgi?Readiness)

As for the other definition of "seat" as a container for players, 
allowing several human players to play a single role (by sharing a 
seat), or swap out for each other: I've definitely warmed to the idea, 
but I don't think it's a must-have requirement before games are 
playable, and I think that designing the protocol for it (and 
everything that it effects) is more complicated than it might seem at 
first. Therefore, I'd like to officially make it the first thing I'm
(Continue reading)

Permalink | Reply | 4 comments |
headers
Roger Crew | 20 Dec 13:23
Picon

Re: Seats

>   As for the other definition of "seat" as a container for players, 
>   allowing several human players to play a single role (by sharing a 
>   seat), or swap out for each other: I've definitely warmed to the idea, 
>   but I don't think it's a must-have requirement before games are 
>   playable, and I think that designing the protocol for it (and 
>   everything that it effects) is more complicated than it might seem at 
>   first. Therefore, I'd like to officially make it the first thing I'm 
>   going to defer until Volity v1.1 -- that is, the version the core 
>   protocol we'll start to work on after everything on the current roadmap 
>   comes to pass, and all associated version numbers are locked in.

You have roles (*) in the game,
You have people filling those roles.

This is just an abstraction layer (i.e., game designer just has to
deal with roles).

I'll admit that my prior discussion of all the things this allows may
have gotten sidetracked onto unnecessary details, but the basic
concept isn't that complicated and it hardly changes the protocol at
all (except to do s/player/role in a bunch of places).

IMHO the one thing that you MUST have for 1.0 is a Reconnect Story
i.e., how does a player coming into a game in the middle assume a role
that has been abandoned (whether by someone else or a different
client-instance of the same person.  I say this because there will
inevitably be buggy clients and UIs, and if somebody gets wedged and
there's no way for him to recover without trashing the game instance
and starting over, that's going to turn people off.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jason McIntosh | 23 Dec 07:41
Gravatar

Re: Seats

On Dec 20, 2004, at 7:23 AM, Roger Crew wrote:

> You have roles (*) in the game,
> You have people filling those roles.
>
> This is just an abstraction layer (i.e., game designer just has to
> deal with roles).
>
> I'll admit that my prior discussion of all the things this allows may
> have gotten sidetracked onto unnecessary details, but the basic
> concept isn't that complicated and it hardly changes the protocol at
> all (except to do s/player/role in a bunch of places).

The one-to-one mapping, I could live with. Here are some of the hairs 
that start to grow when you allow several players in one role, though:

* Record-keeping becomes uncertain. It's easy to describe who played a 
game, and how their ELO scores should be adjusted, when there is a 
one-to-one player-to-role mapping. As soon as things get more complex 
than that, things get hairy fast -- if I played 90 percent of the game, 
and then you tapped in to take over the last couple of turns and took 
the victory, how should that score for us?

* There would also have to be some sort of security/permission 
mechanism to prevent one player from leaping into another player's role 
uninvited.

* There'd need to be a way to determine which actual players are 
allowed to "speak" for the role.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 24 Dec 22:17
Gravatar

Wiki now requires an editing password

The Wiki is now getting well and truly spam-hammered from multiple 
sources. Not wanting to play any tiresome dike-plugging games, I took 
the easy route and edit-locked the whole site; you now need to enter an 
administrative password under the Wiki's preferences page in order to 
make changes.

The password is the name of this project, in all lowercase letters. 
(But jmac, the name of the project is all over the place.) Yes, but I'm 
betting this is just obscure enough to make both spam-bots and their 
filthy human masters go bother someone else.

Just enter that name into the 'Administrator Password' field in your 
Preferences page (which is at 
http://www.volity.org/wiki/index.cgi?action=editprefs). If you have 
cookies enabled, it should be a one-time operation.

Those who haven't entered this password see a message on every page 
(where "Edit this page" would otherwise be) to contact me if they want 
to become editors.

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

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 27 Dec 03:27
Gravatar

Task list on iCal

I just built a shared .ics calendar based on the Volity task list. You  
can subscribe to it with iCal or Mozilla-calendar via this URL:

webcal://ical.mac.com/zendonut/Volity32Tasks.ics

Or just view it on the Web:

http://ical.mac.com/WebObjects/iCal.woa/wa/default? 
u=zendonut&n=Volity32Tasks.ics

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 0 comments |
headers
Roger Crew | 31 Dec 01:29
Picon

Re: Seats

>  > You have roles (*) in the game,
>  > You have people filling those roles.
>  >
>  > This is just an abstraction layer (i.e., game designer just has to
>  > deal with roles).
>  >
>  > I'll admit that my prior discussion of all the things this allows may
>  > have gotten sidetracked onto unnecessary details, but the basic
>  > concept isn't that complicated and it hardly changes the protocol at
>  > all (except to do s/player/role in a bunch of places).
>
>  The one-to-one mapping, I could live with. Here are some of the hairs 
>  that start to grow when you allow several players in one role, though:
>
>  * Record-keeping becomes uncertain. It's easy to describe who played a 
>  game, and how their ELO scores should be adjusted, when there is a 
>  one-to-one player-to-role mapping. As soon as things get more complex 
>  than that, things get hairy fast -- if I played 90 percent of the game, 
>  and then you tapped in to take over the last couple of turns and took 
>  the victory, how should that score for us?

First of all, record keeping is NEVER going to be certain.  
You never really know who's standing behind the workstation looking
over whoever's shoulder and giving advice.

The 90/10 issue is also a red herring.  If we're both playing the same
role, then, as far as the game itself is concernced, there can be no
distinguishing what you do from what I do.  It might well be that the
last two turns I played for you were absolutely BRILLIANT MOVES that
ended up deciding the game and that you would have lost if you hadn't
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Sugarbaker | 31 Dec 02:26
Picon

ES SVG lib? (was Re: Eights SVG)

Is it time to start thinking about a standard set of scripts to
provide to Volity UI writers? I'm thinking of basic things like
generating combo boxes, draggable things and drag targets, simple
sprites (on the level of "here are the shapes in your walk animation,
flip through them when i tell you 'walk' and stop when i tell you
'stop'"), grids (automagically spec out either a chessboard-like thing
or an RPG inventory-like thing, or a grid layout for something else
entirely)...

A casual cruise through google world has surprisingly not revealed any
ECMAScript libraries for simple UI widgets, although it seems like
such an obvious project that I could be wrong. Plenty for generating
SVG from Java and such, but nothing in pure ES. Such a library seems
both useful for Volity and likely to catch on with other projects as
well.

I don't have a completely firm grasp on SVG yet, but I do know the
DOM, and I feel up to this if I can get time. Are there any
Volity-specific needs that I'm overlooking?

On Sat, 18 Dec 2004 13:13:56 -0500, Jason McIntosh <jmac <at> jmac.org> wrote:
> I have published a new SVG UI for Crazy Eights, intended to serve as a
> model for more sophisticated UI files. Not optimally pretty, but it
> does the job. At the moment, it's primarily lacking card-play
> animation, so cards blink into place when played, instead of sliding
> smoothly into the discard pile; I have yet to get the hang of
> script-based animation.
> 
> The file does, however, manage to demonstrate simple user feedback,
> such as the onmouseover actions attached to the cards in hand, the use
(Continue reading)

Permalink | Reply | 1 comment |

Gmane