headers
Karl von Laudermann | 1 Oct 07:54
Favicon

Re: Eyeing The Button

On Sep 29, 2005, at 6:50 PM, Jason McIntosh wrote:

> Question: Now that we're alpha, should I clear my throat and mention
> Volity there? Or should I hold off until beta? (Or am I an idiot who
> should have done this two years ago?)

I would say to hold off until beta, but I know I tend to be naively  
conservative, so don't listen to me. :-)

--

-- 
                 Karl von Laudermann
                 karlvonl <at> rcn.com
                 http://www.geocities.com/~karlvonl/
                 Richard's PBeM Server ID: karlvonl

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Permalink | Reply | 2 comments |
headers
Jason McIntosh | 3 Oct 00:05
Picon

First release of Testbench, a game UI development tool

I just whipped up an initial release of Testbench, an SVG UI file
development tool that Zarf put together a few weeks ago. It can help
you create and fine-tune your game's
SVG/ECMAScript UI files or bundles offline, letting you simulate
incoming RPCs and notifying of you outgoing ones.

The release is available from Volity's SourceForge site under the
"javolin-testbench" package. Direct download link:
http://prdownloads.sourceforge.net/volity/Testbench-0.1.zip?download

Currently it's just a stand-alone Java jar file with an attached
README. For full documentation, visit:

http://www.volity.org/wiki/index.cgi?Testbench

QUICKSTART
At your command line, type:

java -jar Testbench.jar [ui_file]

ui_file can be a single SVG file or a ZIP archive built according to
Volity rules. Consult the full documentation for more information.

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

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 3 Oct 06:05
Picon

Game Finder implemention proposal

Andy came up with what I feel is a pretty cool idea for implementing
the game finder. (This being the disco-driven protocol that helps
players find interesting parlors and open tables. See the [[gane
finder]] wiki page for a full refresher.)

Basically, we'd run it as a Web application on volity.net. It would
have an HTML-based view for Web browsers, and Javolin could either use
the same (or slightly modfied) HTML view or a separate Luxor-XUL view
(strictly one or the other, which we'd decide in subsequent
discussion) (or maybe even an SVG view?! but I digress). In either
case, when the user clicks a "start a table at this parlor" control or
a "join this table" control, they end up downloading a tiny file
containing a pointer that Javolin can read. (Think how Real Audio
works.) Through MIMEy magic, the file is automatically fed to Javolin
(note the possibility that Javolin would simply feed it to itself),
which then does the right thing.

The advantage to this method is that we can decouple the development
and design of the game finder from that of Javolin -- or any other
client. The effect would be somewhat similar to the relationship
between Apple's iTunes application and the iTunes music store: the
latter can swap around whatever it wants to within itself, and Apple
doesn't need to re-release a new iTunes version every time it happens,
so long as the two programs still speak the same "Hey, start
downloading this song" protocol.

I think this is important because, as far as I can tell, the two major
UI components that Javolin users will spend most of their time with
are table windows and the game finder. The finder will be Javolin's
"home page", the spot where players look to see what's currently
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Orleans | 3 Oct 06:34
X-Face

bug tracker protocol

Oops, I sent this to the wrong address a few days ago, and it didn't
bounce back until now. 

------- start of forwarded message -------
To: volity-dev <at> lists.sourceforge.net

I submitted three new Javolin bugs, one in the "features" group.  I
left the priority at the default level (5); obviously some of them are
more important than others, but I don't think that should be the
submitter's decision.  I also left them unassigned.  I suggest that
bugs be assigned by a developer relatively soon after they arrive, and
that the appropriate priority level be determined at that point,
though of course both can be adjusted later.

--dougo <at> place.org
------- end of forwarded message -------

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Permalink | Reply | 1 comment |
headers
Andrew Plotkin | 3 Oct 06:58

Re: bug tracker protocol

On Mon, 3 Oct 2005, Doug Orleans wrote:

> Oops, I sent this to the wrong address a few days ago, and it didn't
> bounce back until now.

The mailing lists have been lagging all weekend.

> I also left them unassigned.  I suggest that bugs be assigned by a 
> developer relatively soon after they arrive, and that the appropriate 
> priority level be determined at that point, though of course both can be 
> adjusted later.

I've mostly been filing bugs that I expect to handle myself, so I've been 
setting priorities at file time. However, I'm leaving them unassigned if 
I don't expect to handle them "soon". This is on the notion -- entirely 
hypothetical, but it doesn't make it false -- that someone may jump in and 
pick up a bug while I'm working on the bugs that *are* assigned to me.

I guess what I'm actually saying is that I don't want a protocol where 
bugs are reassigned away from me, and I also don't want a protocol where 
someone has free time and can't find anything to do with it. :)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

-------------------------------------------------------
This SF.Net email is sponsored by:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McIntosh | 3 Oct 07:59
Picon

ECMAScript API docs, and a sound suggestion

I'd like to get the ECMAScript API documented, including all the
functions, objects and classes that a good ES-using Volity client must
define for the use of its UI files. I have started a Wiki page about
it, rather incomplete, especially where that mysterious "info" object
is concerned.

http://www.volity.org/wiki/index.cgi?ECMAScript_API

You'll notice a rather thorough definition of a heretofore undiscussed
"Audio" class. This another recent Andy idea I like, so I hammered out
the details and left trembling notes in italics where I'm not sure how
feasible certain things are. I was on the fence about how "1.0" of a
feature this is, since at this point I want to be cautious about
feature creep, but I decided that sound and music is a very important,
if easy to overlook, part of any sort of computer game. Thoughts,
refinements, refutations welcome.

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

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Permalink | Reply | 3 comments |
headers
Andrew Plotkin | 3 Oct 18:51

Re: Game Finder implemention proposal

On Mon, 3 Oct 2005, Jason McIntosh wrote:

> Basically, we'd run it as a Web application on volity.net. It would
> have an HTML-based view for Web browsers, and Javolin could either use
> the same (or slightly modfied) HTML view or a separate Luxor-XUL view
> (strictly one or the other, which we'd decide in subsequent
> discussion) (or maybe even an SVG view?! but I digress).

That sounds reasonable.

An advantage you didn't mention: all the world's parlors will be discoed 
by just one entity -- the web app -- instead of being discoed by every 
Javolin running out there.

> The advantage to this method is that we can decouple the development
> and design of the game finder from that of Javolin -- or any other
> client. The effect would be somewhat similar to the relationship
> between Apple's iTunes application and the iTunes music store: the
> latter can swap around whatever it wants to within itself, and Apple
> doesn't need to re-release a new iTunes version every time it happens,
> so long as the two programs still speak the same "Hey, start
> downloading this song" protocol.

For the devil's melody, I'll note the differences.

The ITMS is a very user-driven application, which is what HTML is best at. 
The display updates when you click something.

Volity's game browser is driven from both sides: you can change what 
you're viewing, but what you're viewing is also changing spontaneously, as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Plotkin | 3 Oct 19:34

Re: ECMAScript API docs, and a sound suggestion

On Mon, 3 Oct 2005, Jason McIntosh wrote:

> I'd like to get the ECMAScript API documented, including all the
> functions, objects and classes that a good ES-using Volity client must
> define for the use of its UI files. I have started a Wiki page about
> it, rather incomplete, especially where that mysterious "info" object
> is concerned.
>
> http://www.volity.org/wiki/index.cgi?ECMAScript_API

You missed some of the functions defined in [[SVG_UI_File_Strategy]].
I threw localize(), message(), and literalmessage() onto the page.

Javolin's info object supports just two fields: "seat", as documented, and 
"nickname". The latter is assignable-to -- that is, a UI file can say
    info.nickname = "Doofus";
to change your MUC nickname. I don't know whether that's a feature or
a misfeature. :)

I haven't run into any other pieces of information that the UI needs. But 
I have only written two UIs.

I always had the vague assumption that info would give a view of the seat 
chart: say, info.seats returns the list of seats (under the same criteria 
as Javolin's display, i.e., don't list empty non-required seats) and the 
seat objects give you the player list.

I guess we should support info.show_table, info.record_games, and 
info.language.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason McIntosh | 3 Oct 20:13
Picon

Frivolity (Perl-based Volity server software) v0.5.1 released

Just released Frivolity 0.5.1, which fixes several bugs found in
0.5.0. Anyone tooling around with 0.5 should upgrade, either by
downloading the package from SourceForge
(http://prdownloads.sourceforge.net/volity/Volity-0.5.1.tar.gz?download)
or performing a CVS update.

The code is a little cleaner too, and there's a new
Volity::WinnersList package that helps you create the winners lists
that proper game records need. (The docs for its use are in
Volity::Game as well as Volity::WinnersList.)

I hope this to be the last Frivolity release before that tutorial I
keep talking about...

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

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Permalink | Reply | 0 comments |
headers
Andy Turner | 3 Oct 21:07

Re: ECMAScript API docs, and a sound suggestion

On Mon, Oct 03, 2005 at 01:34:42PM -0400, Andrew Plotkin wrote:
> I do not like your audio API. Having methods that are both getters and 
> setters -- bleah. Since Javascript supports object fields which are 
> dynamic (like "nickname", above) we should do it that way:
> 
>   val = audio.url;
>   audio.url = newval;

I agree.

> I don't think we need play(float) to start a sound in the middle. However, 
> we *do* need a way to start a sound playing in "repeat forever" mode. 
> (Background music.)

Make this another attribute?  I don't imagine they'll be any call for sounds
that may be both repeat forever and play once.

> Games frequently need to blast out multiple instances of a sound -- 
> possibly overlapping. Your audio object can't do that. A game *can* create 
> multiple audio objects with the same URL. Is that sufficient, or do we 
> want to avoid the overhead cost of setting the URL and alt on each one?
> 
> (A way to avoid that would be to have just one audio object, and then 
> audio.play() returns an *audio instance* object. The latter would have a 
> stop() method; the former would not. This is not necessarily the right 
> way, just a way. We could also just have a clone() method.)

When I was reading the paragraph before this one, this is exactly
what came to my mind.  I think i prefer the audio instance style. 
I'd also suggest that instances should not have a play method.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane