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.

There's something wrong with what the Collaborative .zip file did to the Mac VM. Needs a new one this weekend. Stand by...

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!
[Read More!]

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.)
[Read More!]

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.
[Read More!]