Cellsprings Help: Springlet Programming

Springlets are Java rule(space) classes that "plug into" Cellsprings. With Cellsprings/DT and a Java compiler you can easily develop your own springlets. Be aware that this is something of a proof-of-concept feature - the design and implementation are pretty minimalistic. Though I use pretentious terms like 'API', we're really just trying to have fun here. (A true "production level" API would likely employ full-fledged Java beans.) That said, the feature is expected to prove quite useful. If you like Cellsprings but wish it could run some other type of 2D rule, now's your chance to make it do so.

Really, there's not much to it. First, you should familiarize yourself with springlet behavior using the springlet(s) already installed in Cellsprings. In particular, the HexagonalTotalistic springlet was written partially for tutorial purposes. The easiest way to load this springlet is to run some of its preset serializations on the Presets | Springlet-implemented Rules menu. So play around with it in the RuleTool - test modified parameters in the CA, load and save instances, and so on.

Cellsprings works with springlet rules and "regular" rules similarly, but the former are handled in a more generic and flexible manner. One important difference lies in the nature of their respective persistent storage formats. Rules of the built-in types are saved as CAR files, whereas "springlet instances" are saved as SER files. The latter are basically serialized classes, though the Cellsprings code loosely emulates the behavior instead of making use of Java's Serialization API. What serialization boils down to in the present application is that the file stores both the name of the springlet class and the specific rule parameter settings (and also instance comments). And unlike CAR files, springlet SER files are text files - indeed, they're in standard Java "property file" format. If you open one in a text editor you'll find they're not mysterious in the least.

Now, obviously, saving a springlet instance only makes sense if the springlet has been defined to accept user input. If the springlet is a hard-coded rule rather than a rulespace with runtime parameters, then there's no point in saving it. In that case the rule is fully specified by the class itself - all instances are identical. But normally, when writing springlets, you'll want to expose some of the data your algorithm uses to the user, and the Springlet API makes it very easy to do so. So on this model a springlet class represents a rulespace and a springlet instance represents a rule - a single point in that space. (The limited type of springlet mentioned earlier is also a rulespace in a sense, but a very boring space containing only one point.)

Having made a tour of springlet behavior from the user's standpoint, you're ready to check out the Javadocs describing the API and the HexagonalTotalistic springlet source code. As I say, there's not a lot to it. You subclass the Cellsprings 'Springlet' class and override a couple of methods. Everything you need to know is in the two resources just listed.

Some aids to compiling springlets are included in the Cellsprings/DT distribution. (Directories mentioned below are relative to the installation's base directory, which by default is named cellsprings.) The bin directory contains a batchfile and a shellscript that you can configure to compile your springlets on Win32 or Unix respectively. (Configuration is just a matter of editing a couple of paths.) For the scripts to work as written, your source files should reside in the src/springlets directory. You'll find that directory already contains another copy of the HexagonalTotalistic.java source file, which you can compile as-is to test your configuration and use as a template for your own springlets.

If you develop any springlets you'd like to share with other Cellsprings users, you're encouraged to submit them in source code form for installation online as part of Cellsprings/Web and redistribution with the desktop edition.

Have fun!