Volity.Net

To reply further (I'm another Volity person -- Jason and I are both looking at this thread):

The UI is pretty good. (We're using Swing.) I haven't had better luck with other cross-platform UI APIs, and they haven't been spectacularly faster either. Gamut may be slower than a native app, but it's not too slow, which is what matters.

It is, of course, possible to write a platform-native client using our API documentation. We would welcome this, but it would be a big job: the client is a big piece of software. It has to have full support for SVG and Javascript. Good open-source Java libraries exist for those -- that's a major reason we went with Java in the first place. It enabled us (a few programmers) to get this off the ground in a couple of years.

To make an entire Volity game yourself using our existing tools, you need to be comfortable programming Perl or Python in order to create the server-side game logic, and well as SVG and JavaScript to make the graphical user interface that players see and interact with.

SVG tends to be the trickier part, since it is new to most folks approaching Volity for the first time, and they tend to learn it on the fly. We've got two games running now (Hex and Y) that were made in just a few days each by someone who had never used SVG before; we've got an offline UI development tool (called Testbench) that makes this process relatively unstressful, if you're willing to put the effort into learning.

The real trick of Volity is that it doesn't do anything "special" with these languages or technologies. A game UI is simply an SVG document, so if you learn the basics of SVG from a book written by someone who has never heard of Volity, you'll learn almost everything there is to making a Volity game UI anyway. Then it's just a matter of programming according to our API, and off you go.

Now, to actually answer your question, ha ha: yes, you'd have to learn a couple of new programming languages. But they are neither obscure nor particularly hairy languages, and you'd have the full support of volity.org's mailing lists and wiki, and the devchat on the Volity Network.

Yep. Sorry if I went a little overboard on the techiness with my earlier reply! Volity Games floats in the twilight zone between the tabletop game market and the digital "casual game" market, and I've lately been talking to so many people that I sometimes forget which of the two audiences I'm addressing. I'll start to babble excitedly about SVG or whatnot even as everyone's eyes start to glaze over...

You can do either. Two of the games we have running how (Hex and Y) run on their developer's own server, but we are in the midst of setting up a system where you can host games with us.

What if I offer the game for a fee? How does that work?

The reason this thread is in the Game Publication forum is that the Volity Network is, beyond all else, a publishing platform for digital multiplayer games (whether or not these games might also happen to have print versions as well). We are trying to make it as easy as possible for a developer with programming resources - theirs or someone else's - to create and publish a multiplayer game that will become immediately visible to the system's userbase.

Anyone can publish free games with the tools and resources we have online now, and this costs nothing. Support for pay-for-play games is among the things we're working on right now, but I'd rather be demure on the specifics until we actually have the hosting and revenue-sharing systems up, and the fee structures in place.

Does it have the ability to zoom in on part of a board (since boards can be big and might seem tiny if viewed on a computer screen all at once).

The focus of our present libraries and tools tends more towards helping game hackers adhere to the Volity protocols, so they write game code without having to write all the boring stuff that isn't game code. Everything else is up to the developer.

Recent conversations are starting to englighten us that, while this makes the hardcore game hackers salivate, it can end up looking a bit too flexible to print-based publishers who might not know Python or JavaScript programming. So I suppose all of this is a very roundabout way of saying that we don't currently have any easily modular UI libraries for components like dice or zoom/pan controls, but we can have them, and we are starting to recognize it as a high priority. (You can actually see die and zoom/pan controls in action in games that we currently have online.)

Volity has a very different approach to being an online game platform than systems like Vassal or Lackey or Cyberboard. Beyond its higher flexibility, its offers a lot that they don't, like server-side rules enforcement, game recordkeeping, and automatic ELO-based player rankings. However, those other systems have the advantage of being a lot easier to get started with. We are very interested in increasing Volity's accessibility to all kinds of independent game developers, and truly appreciate the chance to learn about ways we can accomplish this.

I think that this is not strictly necessary for a lot of games. In fact, it would be nightmarish to implement for certain types of games.

I'd be interested to hear an example of what you'd consider a nightmarish ruleset to implement.

I'll note that the role of the Volity referee extends beyond rules enforcement, though that is its primary role while a game is active. By knowing the game's rules, it also acts as any game table's local authority for when and how a game has come to an end, making for cheat-proof (or anyway cheat-resistant) game records. The automatic production, storage and analysis of meaningful game records and player statistics are part of what makes Volity so cool, in my opinion.

I personally think you also need some old fashioned paper documentation (or at least PDF documentation). Wiki documentation can be painful to work with when you are trying to hunt around for some things. And including documentation in POD format is not particularly convenient either.

Well written documentation in PDF format with cross-links, etc. will probably be more convenient.

Agreed. Monolithic documentation is something I've wanted for a long time, but the core team's been too busy with other stuff to make the long doc file that I'd like to see. We do have something in the works with a couple of volunteers, but again I don't want to advertise features that we don't already have yet. (If anyone out there in BGDF-land wants to help with this, though, drop me a line...)

I must, however, defend the POD documentation as what Perl programmers will expect to find when learning a new library. Its is only the stuff specific to Perl programming that has attached POD stuff. Same argument applies to the pydocs attached to the Python libraries.

That really depends on your point of view. To a programmer, the Volity tools dramatically lower the barriers to getting a multiplayer game online; all you do is write the game logic and plug it into the framework that handles all the hairy network and player-handling stuff. Poof, you have a networked game.

I recognize, however, your point that a non-programmer, even a technically savvy non-programmer, may quickly feel overwhelmed at trying to grok Volity's technology.

200 hours?! Now I'm really curious what game you're thinking of!

Hm. Actually... given Veritas's forte, I be you're thinking of a CCG, aren't you? If so, this is an interesting problem, mostly because it presents a fascinating puzzle about how to break down all the cards' possible actions and effects into programmatic categories so that it doesn't take a month to get them all in.

We have already faced this with our implementation of Looney Labs' card game Fluxx, which (to use an increasingly cliched but in this case true description) is rather like a non-collectable CCG, featuring over 80 cards that all have different effects on the game's rules. It took maybe five days to create (though zarf would be the authority on this). The UI was what was really tricky.

Yes, that's the moral of the story I am taking away here.

We've had lots of success pitching the Volity idea on the digital side of the fence, where (unsurprisingly) there are a lot of gamer/programmers, and we've also found fans among code-savvy fans of print games (a group of which I count myself as a member). It makes sense that increasing our accessibility to non-programmer game publishers would be a good next step. And we're already starting to kick some ideas around...