Populating Worlds
From Croquet Consortium
Contents |
Approaches
There are three broad approaches to populating Croquet worlds (aka Islands).
Interactively
Some Croquet demos and applications provide a way to interactively add, remove, and position things within a world as you use it -- even with other users present. See, for example, Croquet Collaborative#Creating and arranging things
If you are connected to some persistent world (e.g., an application like the Croquet Collaborative that is designed to keep things around from one session to the next (modulo bugs!) you're done. Croquet also has a means of making an image of memory (The Core Model)) and this snapshot can be saved to disk. (E.g., in the KAT demo, this is under the Admin menu. In the SimpleDemo, it is under the Space menu.)
Programmatically
Depending on the implementation of TContact used by your application, the system may run a script under certain circumstances to build a world from scratch. After joining with the router, one participant (e.g., a "Master") sends the island a #new: message with the name of a subclass of BaseWorld as argument. This creates one instance of the class on the island, and the #initialize method of that class is assumed to build a space and everything in it. There's nothing magic about using BaseWorld. It's just a convenient way of defining a script such that everything is run in the context of the island, which is what we want.
Level Editors
Level editors lie in between the touchy-feely realm of interactive world building (with worlds "stored" in binary) and the real-men-write-programs realm of ASCII text scripts. For example, game engines are typically not flexible enough to build worlds from within them as they are used, and programming is considered too difficult for designers. So an editor is used to define some textual representation of the static state of a completed world. This has two advantages over the binary snapshot format:
- A human can read it and make small modifications.
- A well-designed format can be more immune to class evolution. For example, the results can be unexpected if the binary snapshot format is loaded into a system in which the "shape" of classes has changed (e.g., instance variables added or removed). (It is usually possible to load binary snapshots under the old definitions and then load in the new class definitions while the world is running. However, new instance variables will be nil because the #initialize method will not have been run.)
- It is easier to leave certain information out, and this makes such formats suitable for comparison by regression tests. For example, it may be that there there are hundreds of pieces of data that are all computed based on a single canonical input. A text format can be designed to just specify that single cannonical input. Secondary changes that don't matter can be ignored.
There is no such level editor in the current SDK. It probably makes sense to provide an XML format as a convenience, but it isn't a priority because the above techniques do work.
Bootstrapping and Joining
Different applications can use various combinations of these. For example, most of the Master/Participant pairs of demos are coded to have the master build a world programmatically.
The SimpleDemo has an explicit Space -> Load Space menu option that lets the user specify a snapshot filename from which it create a router/island as a new master.
The KAT uses a pluggable KConnectionStrategy. When someone joins the router for a world, the default connection strategy asks the router to supply the current definition of the world from another participant. If there isn't any, the default strategy gets a previously cached snapshot of the world. If there isn't any such file in the cache directory, it instantiates the subclass of BaseWorld named by the contact. (The connection strategy also handles other things, such as reconnecting when the network goes down.)
The choice of an appropriate mechanism depends on the circumstances of the application, and is closely related to WAN/LAN, Connecting and Discovery.
