robocat and variants

For scripts to aid with computation or simulation in cellular automata.
Post Reply
HartmutHolzwart
Posts: 841
Joined: June 27th, 2009, 10:58 am
Location: Germany

robocat and variants

Post by HartmutHolzwart » December 30th, 2013, 9:48 am

This thread is on understanding. using and modifying the robocat software that Gabriel Nivasch created in 2004 to build the caterpillar spaceship.

Going from recent traffic in the pattern forum, 2014 could develop into the year of caterpillar-like ships. There were several mechanisms discussed that might be the basis for ships of various different velocities. Also a new tool for finding helices has been released.

So, depending on the case, more or less the parts were developed or seem liekly to be developed over time. Basic layouts have been designed

The big issue is then to put it all together and assemble a complete ship or first some prototypes as proof of concept.

Basically, this means solving a huge space-time 3D-puzzle. While Golly supports the assemblage of complex objecta via layers and scripting facilities, this still doesn't seem to be enough.

So the big challenge is to develop a tool that supports this whole process and is flexible enough to handle slightly different contexts.

In the first phase one should define the basic concepts and abstraction layers:

The lowest layer the are basic object, basic still lifes and small period oscillator (i.e. blonks), gliders and *WSS, pies, b-heptominoes or herschels.

Then there are glider syntheses, that create these basic objects.

More complex objects consist of several basic objects. These are either self-sustained once created or need defined support from other objects in some of their phases. They are created by syntheses and emit gliders or *WSS. An example would be the basic 17c/45 pi + blinker reaction.

There could be several layers of complex objects.

Maybe it's better to use a specific "engine object". Then there would be a concept of "tracks" on which these engines run.

There can be forward and backward rakes, catchers, throwers, helices and whatever piece might be necessary.

I'm completely open how this should be structured to be abstract enough to handle different contexts but concrete enough to allow assemblage algorithms that are finally the essence of such a tool.

Enough speculation! I would very much appreciate your comments and suggestions.

Regards,
Hartmut

Post Reply