There’s a nice video of Sims creator Will Wright explaining the new game he’s developing, called Spore. (An edited-down version of the video, concentrating on the game play, is here. (Thanks for the lead, John!)
Very cool stuff, and I think a nice addition to the set of collateral material that gets at some of the aspects of either Croquet or Brie. A very nicely done thing to compare against
The first real release of Croquet is nigh….
If the dominant medium of a culture defines it, what does it mean for us when TV is changing? How will it change, and how will that change us? A couple of MIT academics are discussing the former at here. Good reading, but missing the point.
Last week I described the network model we’re building for Croquet, and was asked about some security issues. I think the main security weaknesses to what I have described come from the ability to misrepresent oneself as the Introducer or as a machine responsible for a World, or to deny others access to a World or the Introducer by sending a bunch of messages to it that demand its attention. Part of the answer in both cases is to distribute the roles of Introducer and of Worlds among many machines
Today was my boss’s last day, and, ironically, my first anniversary. Julian Lombardi will be Duke’s Assistant Vice President for Academic Services and Technology Support. He’ll be responsible for the university’s IT customer service and development.
They made him an offer he couldn’t refuse.
I sometimes get asked about Croquet for computing devices with lower graphics capability, such as today’s phone/PDA/iPods. I think the train of thought is that there’s so much in Croquet that could be valuable independently of the immersive 3D environment, so shouldn’t that part be available on lesser machines?
I feel it is only worthwhile to initially build Croquet – all of Croquet and only one Croquet – on machines with the best commonly available graphics capability and also on those with no visual capability whatsoever!
There were some comments to a previous entry that I thought were worth calling attention to all by themselves. The general theme of these was that of user interface and how the role of media in storytelling can inform the design of new UI paradigms. Highly appropriate for Brie.
So I’m moving those comments here. I want to keep the original page for the my attempt to define the heart of Croquet independently of UI, applications, and software distributions.
4. HOW RELIABLE IS THE COMMUNITY?
(See part 1.)
None of the previous matters if the software isn’t useful, or if we are not allowed to use the software. The former is what we’re working on, but the latter is a very complex issue. Croquet is certainly not at critical mass. It could certainly go away. However, we feel it is immune at least from licensing plays such as those that have plagued the use of proprietary systems in higher ed, or those that have fractured the Java community. As the number of users in such systems grows, attempts for controlling proprietary lock-in have been very expensive. Croquet fights this in several ways: with an open source license in which all work on Croquet itself is available to anyone; with a P2P architecture that eliminates any advantage to “controlling the servers”; and with a dynamic language that eliminates any advantage to “controlling the release.” We feel that this last will be further strengthened by upcoming work in architecture and security, to be carried out here at UW. For the general health of the community, I look forward to upcoming announcements.
3. HOW WILL APPLICATIONS BE DEVELOPED?
(See part 1.)
It is not practical to expect users to develop applications in Squeak. There is too much to learn. But neither is it practical to expect users to develop applications in Java or ANY OTHER COMPUTER LANGUAGE. There is no way that any community of professional developers could possibly keep up with the demand that we hope for unique applications. No matter what language they used, nor even how many developers were available. There’s simply many more users — and user needs — than there are developers. As with scalability of load, we need another approach. The answer is the same: push the load to the edge of the network.
2. HOW MUCH USE CAN THE APPLICATION SUPPORT?
(See part 1.)
The architecture of Croquet is very different from that of, for example, J2EE applications. In a client-server application, one server or server “farm” must process each and every interaction initiated by the thousands or millions of users. The only thing processed on the end-user’s computer may be as little as the HTML formatting of the text and image results. Every single other computation must be handled on the big-iron servers. To double the number of users, the capacity of the servers must be doubled. It should be no surprise, then, that so much effort goes into trying to squeeze out each available computing cycle in such architectures.
When an application has state — that is, when results depend on previous results rather than simply generating static files — client-server does MUCH worse. The amount of storage required can go up much faster. In some cases the application state depends on the number of possible connections between users or between applications. The storage (and certain kinds of search-like operations) increases as the square of the number of users or applications (N^2, c.f. Metcalfe’s law). But we are particularly interested in allowing students and faculty to form their own ad-hoc groups among which to communicate and solve problems. A client-server architecture hosting such “group forming” applications would grow exponentially to the number of users (2^N, c.f. Reed’s 3rd law). With only a few users, this architecture would not work at all, no matter how (finitely) fast the servers, or what language the application is written in. (See Reed’s discussion for a surprisingly accessible treatment of value, saturation, and other issues.)
