On May 27, 2006, at 1:41 PM, Mark Steere wrote: > Please forgive the intrusion. I'm hoping a developer will take an > interest in programming one or more of my games for Volity. Woah, you're the guy who invented Tanbo? Cool.-- -- Karl von Laudermann karlvonl <at> rcn.com http://www.geocities.com/~karlvonl/ Richard's PBeM Server ID: karlvonl
On May 27, 2006, at 1:41 PM, Mark Steere wrote:
> Please forgive the intrusion. I'm hoping a developer will take an
> interest in programming one or more of my games for Volity.
Woah, you're the guy who invented Tanbo? Cool.
_______________________________________________ Volity-devel mailing list Volity-devel <at> lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/volity-devel
I have finally set up the parlor and referee APIs to deal correctly with external bot factories. I've also created a bot factory class, so you can run a bot factory. It's the same process as running a parlor, except that you're specifying a Bot class instead of a Game class. (All of this is the Python code. The Perl versions will come in due course.) See <http://www.volity.org/wiki/index.cgi?Bot_Factory> for the details of this stuff. I posted it on this mailing list a while ago -- no major changes since then. The "Request Bot" menu option in Gamut has been upgraded to support this stuff, although you won't see the difference right away -- except that the menu option is now properly dimmed out for (Python) parlors that have no bots! However, if we had a parlor that supported two bots, you'd see a submenu which allowed you to choose the bot of your desire. There is also a "Request Bot From..." menu option. This is the manual override -- analogous to the "New Table..." and "Join Table..." menu options. If you are developing a bot factory, you can use this menu option to enter its JID and bring a bot to your table. Eventually, the Volity web site will allow you to register a bot factory for any ruleset. --Z -- -- "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." * If the Bush administration hasn't thrown you in military prison without trial, it's for one reason: they don't feel like it. Not because you're patriotic.
Hello, As some of you may know from speaking with me on devchat, I started working on a rather massive undertaking for a game implemented on the volity framework. While initially I became quickly infatuated with volity's overall design, as I proceed with the implementation, I am becoming rapidly more disillusioned with certain aspects of the Volty/ Gamut projects. On the back-end, volity is almost perfect. A reasonable choice of languages in which to implement the server, a clean rpc implementation making client/server communication easy and sensible, and a full environment for managing every aspect of a game from setup to tear-down and everything in-between. Writing the game logic side of the design is a dream, and one couldn't ask for more. On the front-end, the picture is not so pretty. The developer is currently locked into a single technology, and a single solution. Gamut with SVG and ECMAScript is your one and only option. For the current selection of games, this option has proven more or less sufficient, and games like Fluxx and Aquarius even go beyond the call, pushing the limits of the environment to their edge. Sadly, however, that edge is the line, and pursuing anything beyond that line becomes a near impossible task. The limitations seem to sit primarily in the svg mandate. In a world dominated by Flash and AJAX, with WPF and WPF/E looming ominously and threatening to crush any competition in that way that only a Microsoft technology can... we are being forced into using 'that other tech.' We have a cutting edge game development environment, shining with a near perfect infrastructure, and the whole thing is limited by what is, ultimately, a comparatively third-rate technology. Don't get me wrong, I'm not knocking SVG entirely. For certain things, it is the cream of the crop. For web delivery of lightly- dynamic, high quality vector graphics I would argue that it beats out even flash. However, we are ultimately concerned with creating an application, a program for an end user, not high quality images with some interactivity. We need something that provides a framework in which to create a proper end-user environment, complete with a fully capable user interface that is as dynamic as it is rich. Sadly, SVG just can't cut it. Sure, SPARK is a bit of a step in the right direction, and the carto.net code is a good leap... but we are still putting ourselves in an environment where it takes 30+ lines of javascript and 5-10+ lines of SVG just to put a button on the screen, and have it do something when you click it. God forbid you should want that button to work cleanly in all of the big-3 SVG renderers (batik, mozilla, adobe) in which case you can expect twice that much code. Writing even a basic user interface quickly becomes an absurd task, let alone trying to tackle a contemporary, rich, "UX" focused application. What is there to be done? I suppose that we must tackle a fundamental question of "What is Volity, really?" Is it the game server libraries and bookkeeper code? Is it the underlying protocol? Is it the end-user application? Is it all of these things together? Is it none of them? I would argue that Volity, itself, is purely the protocol on which all of these things are actually built. That protocol, the back-end, the guts, the heart and soul of Volity... is the most well refined and singular part of the whole system. In this sense, the bookkeeper is already an "implementation of Volity." The parlor libraries are "built on the Volity protocol"... There are multiple implementations in different technologies of the parlor libraries (frivolity and the py version), and it is feasible (although unlikely) that there could be multiple implementations of the bookkeeper in different technologies as well. It is then only logical to assume that we should support multiple implementations of the end-user component as well, built on technologies outside of SVG. I would like to see a pure AJAX implementation front-end. WPF? XUL? Heck, why not have a front-end that provides an environment for OpenGL based UI files scripted with Lua? Pygame scripts as UI? So long as we are stuck with SVG, we are limited by that glass ceiling just above the quality of the games we already have. Why limit ourselves at all? Why not see how far up we can go? --Arti </rant>
Artifex <artifex <at> artife.cx> writes: > Sure, SPARK is a bit of a step in the right direction, and the carto.net code > is a good leap... but we are still putting ourselves in an environment where > it takes 30+ lines of javascript and 5-10+ lines of SVG just to put a button > on the screen, and have it do something when you click it. God forbid you > should want that button to work cleanly in all of the big-3 SVG renderers > (batik, mozilla, adobe) in which case you can expect twice that much code. > Writing even a basic user interface quickly becomes an absurd task, let alone > trying to tackle a contemporary, rich, "UX" focused application. Personally, I'd write a domain specific language and have that generate the code to render cleanly in all SVG implementations. > In this sense, the bookkeeper is already an "implementation of Volity." The > parlor libraries are "built on the Volity protocol"... There are multiple > implementations in different technologies of the parlor libraries (frivolity > and the py version), and it is feasible (although unlikely) that there could > be multiple implementations of the bookkeeper in different technologies as > well. It is then only logical to assume that we should support multiple > implementations of the end-user component as well, built on technologies > outside of SVG. I would like to see a pure AJAX implementation front-end. > WPF? XUL? Heck, why not have a front-end that provides an environment for > OpenGL based UI files scripted with Lua? Pygame scripts as UI? Google compiles Java to Javascript, why not follow that same path? AJAX is really just xmlrpc and a streaming server connection, how is that so different from the existing Volity RPC? > So long as we are stuck with SVG, we are limited by that glass ceiling just > above the quality of the games we already have. Why limit ourselves at all? What about adding X3D and SMIL to the mix? -- -- I've tried to teach people autodidactism, | ScannedInAvian.com but it seems they always have to learn it for themselves.| Shae Matijs Erisson
Andrew Plotkin wrote: > I meant to get around to this months ago... I have thrown up the > definition of a deck-of-cards resource: > > <http://www.volity.org/resources/carddeck/poker.html> I have a feature request for the poker deck spec. In the spirit of the existing "aspect-ratio" metadata, which describes the largest useful width of a visible card, I'd like to have metadata describing the *smallest* useful width of a visible card: the width of the index (assuming an index at the left edge). Some games may need to cram a lot of cards in, and the deck designer should (and should want to) provide this hint to the game UI designer. The card index is an important feature of a poker deck and worth supporting explicitly (though not all e-decks will have them, of course). If restricting the index to the left edge of the cards seems too limiting, you could be more general and use a vector rather than just a width; the vector represents the offset from the current card to where the deck designer would put a card "on top of it" to conceal all but the index. (That's harder to support, but should handle almost any index position; meanwhile a game can always ignore the hint if it doesn't want to lay out the cards NE-SW or whatever the deck recommends.) Zero vector means "no index on these cards, do whatever you like". -- Dan Efran Martian Ambassador efran <at> wunderland.com http://www.efran.org/embassy/
On Tue, 6 Jun 2006, Dan Efran wrote: > Andrew Plotkin wrote: >> I meant to get around to this months ago... I have thrown up the definition >> of a deck-of-cards resource: >> >> <http://www.volity.org/resources/carddeck/poker.html> > > I have a feature request for the poker deck spec. > > In the spirit of the existing "aspect-ratio" metadata, which describes the > largest useful width of a visible card, I'd like to have metadata describing > the *smallest* useful width of a visible card: the width of the index > (assuming an index at the left edge). Some games may need to cram a lot of > cards in, and the deck designer should (and should want to) provide this hint > to the game UI designer. The card index is an important feature of a poker > deck and worth supporting explicitly (though not all e-decks will have them, > of course). Good point. > If restricting the index to the left edge of the cards seems too limiting, > you could be more general and use a vector rather than just a width Hm. Well, a vector isn't enough information for *every* case. The index has a width and a height (which you could represent as a vector, but isn't really one, since you can distribute the cards vertically *or* horizontally, ignoring the other measurement.) We then also need to know whether the index is northwest, northeast, southwest, or southeast. For Fluxx, where the index is the whole left edge, you can usefully say that the index height is 1.0, and it's either northwest or southwest. But it might be easier for game designers if we just say "this deck stacks from west to east". I can imagine decks where there's important information on *two* edges, and you *have* to stack diagonally. (At that point you do treat the width/height as a vector, of course.) But this will not be common. So, how to represent this? I guess the UI is more likely to have a hardwired direction for stacking the deck, and want to know what spacing to use. So how about this: stack-spacing: north 0.1 (meaning that this deck can be stacked from north to south -- index is on the north side -- with a spacing of 0.1) A common-style poker deck would have two of these entries, since it can usefully be stacked vertically or horizontally: stack-spacing: north 0.1 stack-spacing: west 0.15 --Z -- -- "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." * If the Bush administration hasn't thrown you in military prison without trial, it's for one reason: they don't feel like it. Not because you're an American.
On Tue, 6 Jun 2006, Artifex wrote: > On the front-end, the picture is not so pretty. The developer is > currently locked into a single technology, and a single solution. > Gamut with SVG and ECMAScript is your one and only option. For the > current selection of games, this option has proven more or less > sufficient, and games like Fluxx and Aquarius even go beyond the > call, pushing the limits of the environment to their edge. Sadly, > however, that edge is the line, and pursuing anything beyond that > line becomes a near impossible task. (We discussed this on devchat on Tuesday afternoon, so most of what I'm going to say here is what I said then.) I think things are not as utterly limited as that. There are SVG widget sets in progress. (And the fact that there are still portability problems between SVG libraries is not an issue for as long as there's only one SVG Volity client!) What we've found, in the past year, is that the Volity client is the weightiest piece of software in the system. I think that's inherent to the problem of writing a Volity client. That is, a second Volity client (even one based on a web browser rather than a stand-alone application) would also be a whole lot of work. Now, most of that effort has *not* gone into the SVG interface. One of our original plans was to have an XHTML/Javascript game interface, co-equal with the SVG/Javascript one. This got sidetracked when we were unable to find a free XHTML Java class that supported JS. (Flyingsaucer, which we are using for the Finder and Help windows, does not support JS.) XHTML should be the easiest way to manage game interfaces (including buttons, selection lists, text input, etc.) Particularly if XHTML and SVG can embed each other -- which should be possible. Unfortunately this definition of "easy" doesn't include the fact that the library isn't there yet. (Yes, I have seriously considered writing a JS bridge for Flyingsaucer and donating it. I haven't gotten there yet.) (Similarly, Shae mentioned SMIL animation, but Batik doesn't support SMIL. The Batik project pages are ambivalent whether it ever will.) > Sure, SPARK is a bit of a step in the right direction, and the > carto.net code is a good leap... but we are still putting ourselves > in an environment where it takes 30+ lines of javascript and 5-10+ > lines of SVG just to put a button on the screen, and have it do > something when you click it. sXBL is already supported by Batik (http://www.w3.org/TR/2004/WD-SVG12-20041027/binding.html). This lets you put most of that work into a library, effectively, and invoke it easily where needed. > What is there to be done? I suppose that we must tackle a > fundamental question of "What is Volity, really?" Is it the game > server libraries and bookkeeper code? Is it the underlying protocol? > Is it the end-user application? Is it all of these things together? > Is it none of them? We've always said that Volity is the protocol. > I would like to see a pure AJAX implementation front-end. WPF? > XUL? Heck, why not have a front-end that provides an environment for > OpenGL based UI files scripted with Lua? Pygame scripts as UI? It would be great if these things existed. However, we (and I'm just talking about the core Volity team here) have to consider where we are and what are resources are. If I come in tomorrow and say "Okay, AJAX-based web browser client. I'm on it. Somebody order me a pizza" then I estimate it would be four-to-six months before I had something functioning on the level that Gamut is now. (I know last night you expressed the opinion that it would be less work; but this is my estimate.) We would, to a large extent, be starting over. At the moment, we can't afford to start over. The least-effort path to making new UI technologies available is to embed them into Gamut, as they become available. We can afford that. In the meantime, we can work on other parts of the system (like the website, and more SVG games). Sticking with Gamut, and thinking in terms of more Gamut modules, also has the side advantage -- which is a big one right now -- of "one client for all games". It is legal under the Volity protocol for a client program to only handle a subset of games (or a single game). But the Volity *network* (volity.net) gains value fastest if everybody can play everything. I think it would be dumb for us to split that right now. (Another point: AJAX/browser stuff is here now. But what will be here in six months? As a general principle, I'd rather be ahead of the curve than playing catchup.) We hope -- we *really* hope! -- to reach the point where Volity is ticking along by itself, and we can focus on long-term plans. At that point, we will certainly reconsider all the technologies we're using. That point is not now. But again, when I say "we", I mean myself, Jason, and Andy. If an AJAX client project forms up, we'd be thrilled. --Z -- -- "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." * Making a saint out of Reagan is sad. Making an idol out of Nixon ("If the President does it then it's legal") is contemptible.
Andrew Plotkin wrote:
> I can imagine decks where there's important information on *two* edges,
> and you *have* to stack diagonally. (At that point you do treat the
> width/height as a vector, of course.) But this will not be common.
So are you proposing not to support that case? You seem to be saying
that. I'm not sure if it's an important case or not; certainly it's rare.
> So, how to represent this? I guess the UI is more likely to have a
> hardwired direction for stacking the deck, and want to know what spacing
> to use. So how about this:
>
> stack-spacing: north 0.1
>
> (meaning that this deck can be stacked from north to south -- index is on
> the north side -- with a spacing of 0.1)
>
> A common-style poker deck would have two of these entries, since it can
> usefully be stacked vertically or horizontally:
>
> stack-spacing: north 0.1
> stack-spacing: west 0.15
That'd work.
-- Dan Efran
Martian Ambassador
efran <at> wunderland.com
http://www.efran.org/embassy/
On Wed, 7 Jun 2006, Dan Efran wrote: > > Andrew Plotkin wrote: >> I can imagine decks where there's important information on *two* edges, >> and you *have* to stack diagonally. (At that point you do treat the >> width/height as a vector, of course.) But this will not be common. > > So are you proposing not to support that case? You seem to be saying > that. I'm not sure if it's an important case or not; certainly it's rare. I don't want people to stumble into saying it by accident. I suppose it's worth adding to the spec in the form: stack-spacing: northwest 0.1 0.14 --Z -- -- "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." * You don't become a tyranny by committing torture. If you plan for torture, argue in favor of torture, set up legal justifications for torturing someday, then the moral rot has *already* set in.
RSS Feed8 | |
|---|---|
1 | |
3 | |
1 | |
2 | |
2 | |
2 | |
6 | |
4 | |
37 | |
17 | |
25 | |
47 | |
21 | |
37 | |
24 | |
16 | |
19 | |
55 | |
70 | |
16 | |
58 | |
115 | |
103 | |
3 | |
3 | |
2 | |
14 | |
9 | |
5 | |
10 | |
2 |
