KAT

KidsFirst Application Toolkit

Distributed Systems Part 2: Off-Island Data

, ,

The Core Croquet model describes a complete independent simulation, in which changing behavior is automatically synchronized between all participants. The model is best thought of as describing replicated objects with behavior over time, rather than as older models of program and data (or state). The collection of objects in a given replicated simulation is called an “island.”

However, one of the nice things about the Croquet model is that it can co-exist with other models. It is perfectly reasonable to use a “data” model for immutable objects (which do not change their behavior over time).

Continue reading

Spontaneous Usage

, , , ,

bloggingfrominworld

One success metric that I’ve been shooting for is that I want a user to do something in Croquet that was not specifically intended by the authors of the space or software. It’s very cool to create something that is ideally suited for a particular usage, but it’s really something to create a meta-tool whose usage exceeds the sum of its designed parts.

This fellow Laurence apparently created his blog entry from within the Collaborative.

I had expected and hoped the first such spontaneous use to be something based on collaboration, or on usability or scalability. This was not. It was done because it was fun to do. That’s pretty cool, actually. Shows what I know…

“Turn me on dead man” (The Beatles)

,

The Collaborative for Croquet should be good to go, again. Get the new download.

We’ve lengthened the fuse on self-destructing deleted stuff and improved the error logging, and have not seen further “no such object” errors. (Except for one person who was using an older version. This beta release doesn’t check your version, but I could tell from the error report that it was something we fixed two versions ago.)

Also, the Macintosh VM that was included in the last download had gotten miscopied somewhere along the chain. Testing the new .zip confirms that it works on Mac and Windows. (Linux folks will have to test on their own.)

Anyway, this beta version still doesn’t have anything to reset itself if someone does manage to crash things, so if it takes longer than a minute or two to connect, let us know.

“Well, no one told me about her… She's not there…” (The Zombies)

, , , ,

Getting nothing but a red screen at CroquetCollaborative.org? Here’s why.

Croquet keeps track of everything ever created, so that anyone can tell each object to do stuff. Most of the demo applications in the current SDK keep track as long as they are running. That creates a problem for our KidsFirst Application Toolkit demo,
and its public space at the Collaborative for Croquet. The public space is meant to be a long-lived environment, in which you can come and create (or destroy) stuff and rearrange it, and come back later to see things as you left them (perhaps evolved by someone else).

So we resort to a very old programming technique. And if you’re a developer, we need your help!

Continue reading

The KAT

, , , , ,

Our KidsFirst project includes a great deal of what we’ve learned about Croquet. We’re making all the code available through the CroquetSource code repository, as part of the Contributions collection of code that will be distributed in the forthcoming Croquet release. (This repository is available to developers ahead of release, as part of what David Reed calls “Invention in public.” For info on updating, see this movie and this discussion thread. There will also be a new image distribution shortly.)

We call this code the KAT – KidsFirst Application Toolkit. It fits over all the other Croquet SDK code without changing it. All the KAT-specific classes begin with K – partly for the KidsFirst project that informs its development, and partly as homage to Alan. As the code matures, you may or may not see some of the KAT code migrate down to the base classes from which it inherits. (For historical reasons, the name of the Monticello package is “Wisconsin.” This may change.)

Continue reading

Digital Clutch

,

We’re getting some practical experience using Croquet away from of the confines of the lab and out on the wide open Internet. One problem we found is that our “outgoing” bandwidth (from each machine to the others) is often limited by, e.g., consumer Internet Service Providers. At my home, if I try to send more than about 30 KBytes/sec, my ISP kicks in a sort of governor in which it transmits the bits more slowly to keep my upload speed constant.

When this happens, it takes longer for the bits to reach the Croquet router that timestamps and redistributes them to all the participating machines. No participating machine, including our own, will act on this until it comes back to us from the router. So when the messages take longer to get to the router, they get timestamped for execution farther and farther from when they were sent. If we keep getting throttled, we end up falling further and further behind. It doesn’t take long before you do something and it seems like nothing ever happens in response. So you really don’t want to get your upload speed clamped.

Whenever we move the mouse around, the mouse position is sent along with a bunch of other stuff. When we send voice or video, much more data goes. This is fine on a high-speed Local Area Network, but not so good in the real world. We can and should send a lot less data. But how efficient is efficient enough? With different networks, there isn’t a single target number. The limits could even vary with the time of day or other traffic.

We’ve had some good preliminary results with a rather elegant solution.

Continue reading