Slashdot Mirror

I find their choice of RPC as the middleware layer surprising. I would imagine that a vast majority of events in a MMP game need to be passed on to a fairly large subset of players, for example, anytime someone moves, attacks, casts a spell, etc. the people visual or audio range of that player need to be informed. RPC is better suited to one-to-one interactions, not the one-to-many interactions we get in MMP games. It seems to me that a distributed publish/subscribe system like Elvin, SIENA or even Mercury (a pub/sub system specifically designed for MMP games!), or a LINDA-style shared memory system would be much more appropriate.

Have a look at elvin for example. You run a publish server, the things you mentioned are instrumented (also apps like CVS) to publish events, users subscribe to only those events they're interested in and are then notified when these happen. One notification mechanism is tickertape, but there are others of course.

Ralf

Have a look at elvin for example. You run a publish server, the things you mentioned are instrumented (also apps like CVS) to publish events, users subscribe to only those events they're interested in and are then notified when these happen. One notification mechanism is tickertape, but there are others of course.

Ralf

Have a look at elvin for example. You run a publish server, the things you mentioned are instrumented (also apps like CVS) to publish events, users subscribe to only those events they're interested in and are then notified when these happen. One notification mechanism is tickertape, but there are others of course.

Ralf

From DSTC is the Voyager robot, powered by a GPL'd Java API. </PLUG>

From DSTC is the Voyager robot, powered by a GPL'd Java API. </PLUG>

(Disclaimer: I work for DSTC ...)

(Disclaimer: I work for DSTC ...)

Ralf

Ralf

I saw Dean Jackson's presentation at the OzeWAI 2002 Conference [ozewai.org]. From what I could see, he was using Mac OSX, and Python XSLT tools to produce his PowerPoint like SVG slides. In this format, one should be able to configure completely different behaviour, look and feels for any of the desired end media formats. Without a file format based in structured markup, this becomes much more difficult to address. For this purpose, this is far more flexible.

I have tried SwiftMQ, in which the main engine is free, but add ons are at a modest cost. What I would like to see are JMS implementations on top of Spread or Elvin. The OpenJMS and JBossMQ are okay, but still lag behind the commercial vendors, but are quickly catching up.

First off, I watched one of the news reports via videophone and I was quite impressed by the audio clarity and the video quality. M$'s NetMeeting can't even compare at the same data rate.
MPEG4 is an outgrowth of H.263.
The reason H.263 is chosen over MPEG4 and other similar streaming codecs is because the latency from video capture to transmission of the encoded image is better under H.263. During some informal testing, latency of H.263 video conferencing on a LAN was well under 2 seconds. The best I could do with Real's RealProducer using their G2 codec was around 4-5 seconds. The best I could do with Microsoft's Media Encoder with the MPEG4 codec was around 7-10 seconds.
Because of the way that MPEG2 and MPEG4 take advantage of the time domain to achieve higher compression also makes them unsuitable for 'live' 2-way video.
Here are some links to chew on:
http://myhome.hananet.net/~soonjp/vclinux.html
http://archive.dstc.edu.au/RDU/staff/jane-hunter/v ideo-streaming.html
http://mpeg.telecomitalialab.com/
The H.263 spec is available at http://www.itu.org for a fee.

XPath is a partial query language for XML - it can read, but it has no way of updating the document.

There's also the issue that XPath is very much an XML tool, with a tight binding between semantics and structure (which is the whole thing that I'm saying about XML in the first place). If you have a graph represented in XML, then it's hard to write XPath expressions that can traverse it. If you have RDF stored in XML (which has several possible serialisations for the same semantic content) then it's possible to write XPath that expands these, but it's hard, error-prone, and generally unworkable.

There's still a lot of thought out there that XSLT can translate magically between schemas. Some groups see XML Schema as improving this (Hunter & Lagoze, WWW10). Although Alison Cawsey's paper from WWW 9 shows just why this approach doesn't work. I've abandoned my own work in this field for similar reasons; even though I managed to build something workable, I just never trusted it to be reliable.

• DTDs suck.
• XML Schema doesn't suck.

As to why DTDs are suck-worthy, then:

• They're expressed in their own syntax, which no-one understands.
  XML Schema is expressed in XML.
• Because XML Schema is in XML, it's machine-processable by a whole bunch of simple tools. It's trivial to write a database data-model -> XML Schema export tool.
• DTDs are poor on complex structures.
• DTDs don't do data-typing
• DTDs are very poor when complexity meets data typing. XML Schema can support structured types in a manner that's akin to a struct.

XML Schema is quite a good TR for datatyping within XML, but it's still very limited at expressing large-scale structure (this is an XML limitation, not an XML Schema one) and does nothing for semantics or ontologies.

We still need RDF, and RDF still needs schema expression languages that are smarter than XML Schema. Current practice seems to be that RDF Schema is dead, DAML is the way forward and DAML gets its low-level data-typing from from XML Schema. Incidentally, this is a very good example of why XML Schemas structured types are dead handy, and usefully different from the normal XML structure expression. There's a couple of interesting papers by Jane Hunter and Carl Lagoze on XML, RDF and various schemas that describe some of the issues involved in different schema requirements, different expression languages, and how to compare them.

Microsoft have done what they usually do with XML: Build an excellent implementation before the W3C got there, get flamed to hell by the Slashdot weenies, then bring it quickly back into line once there's a standard worth using. We all like to beat on Bill, but for a few things (and XML is a big one) Microsoft deserve a lot of credit for some really good work.

• - mail transfer agent (MTA);
• - mail delivery agent (MDA); and
• - mail user agent (MUA).

Perhaps some thought should be given to aligning the components in an analogous fashion. Has someone looked into comparison of the key attributes of the different IM system to see whether a similar structure could be nominated? For example, I would hazard

• - message session agent - handshaking/setup
• - message resolution agent - figuring out namespace conflicts
• - message distribution agent - multicast/AIM/etc
• - message client agent - the GUI thingy-a-bob

In fact spliting channels into a separate session control and others is what is suggested by BXXP framework.

LL

Human beings are social animals but we undertaken specific activities in specific spaces. (see Worlds). Now cell phones are associated with work (business) and communications. Is it worthwhile also turning it into a game-boy type of system? If a business saw a highly paid worker killing time playing with their Palm (OK stop sniggering in the corner) or cell phone I suspect that they will question your productivity or dedication. If you're driving, you certainly won't be playing at the same time and if you're taking the bus, then it's likely you're not going to be affording the pay/minute for on-line games. If you're at home, then you'd likely to already have a computer or sonsole handy.

I'm not knocking the idea but building a better mousetrap doesn't always lead to higher utilisation. One study revealed that the cheap wooden mousetrap significantly outsold a plastic box with pheromes because it ignored the fact that housewives didn't like throwing out an expensive looking box and the fact that if they saw a dead mouse in the wooden trap, they could get their husbands to dispose of the carcass immediately whereas they had to look in the box themselves. In short, the social circumstances may have subtle but significant factors in purchasing decisions.

So will people play games with strangers on their phones given the relative small screen-space, the low-battery life, and high relative costs?

LL

Ralf

Ralf

Ralf

http://archive.dstc.edu.au/~bill/carli n.html

JCSI is in Java. You'll need to download many a package from Javasoft before you'll get it to work.
--
http://www.wholepop.com/
Whole Pop Magazine Online - Pop Culture

Unfortunately I can't find a URL... anyone from Stanford reading this and can help?
http://www.dstc.edu.au/~ralf

How about a powersupply with a battery built in, so that a powerloss will switch to battery, which in turn can be detected (laptops tell you when they're on mains or bat) and which could then force an immediate shutdown. The battery for this type of powersupply wouldn't even need to be real big. 5-10 minutes would surely be enough. In other words, batteries out of ancient laptops would suffice...

Does anyone know of such a project already having been attempted? What is wrong with this idea? Would it be possible to build such an animal to just replace a normal power supply in a desktop box? Or does a desk top box just simply suck way too much juice for a battery to even cope for an immediate shutdown?

Ralf
http://www.dstc.edu.au/~ralf