Today I am releasing an alpha version of a Java program I have been working on, with Dave Greene's input and advice, to help find ways of creating self-destructing patterns by presenting the problem as a (pretty hard!) puzzle game.

On WIndows XP, I run a JAR file by right-clicking, then Open with|Java(TM) Platform SE binary. You may have a different way of running Java programs on your platform. I'm sure people here can help if you run into trouble.

The program has a help button which gives a brief explanation of how to use the program. Here's what it says.

The aim is to completely destroy a pattern by placing (usually) one glider and a number of small still lifes called 'seeds'. Solutions will help Life research.

The main playing area shows the evolution of the current attempt. The currently-selected seed moves around with the mouse, and any effect it has on the evolution of the pattern is instantly displayed. Left-clicking will place the seed at its current position, and record the move in the tree on the right. You can't place seeds in the yellow 'quarantine zone'.

You can drag the pattern around by pressing and holding the right mouse button, and zoom in and out by rotating the mouse wheel.

On the right is the exploration tree. You can select any puzzle (initial pattern) from the tree, or any attempt you have made so far to solve it. The tree labels are arbitrary aides memoire.

You can change the current seed, start generation and number of generations by rotating the mouse wheel over the buttons on the right, or click to restore the default. Clicking the copy icon will save the current attempt to the clipboard in standard RLE format.

Hints:

Try to progress in small steps around the pattern.
Try to avoid creating red debris (versus pink debris) - it's inside the quarantine zone and harder to reach.
Boats can reflect gliders arriving on either side in the direction they're pointing, so any spare gliders can be redirected back towards another part of the pattern.

THIS IS AN ALPHA VERSION. You cannot save your attempted solutions yet. I'm working on it.
---------------------------------------------------------------------------------------------------------------------

Here's a good beginning to a Silver cleanup with a glider and 6 seeds destroying 7 stilll lifes. Less than 30 minutes' work.

The glider which heads NE to destroy an eater could be further perturbed near it to do more work. I am yet to exploit the other NE glider.

Dave Greene and I estimate that, in general, a ratio of one seed per still life is attainable. Can you do better? The puzzle requires a lot of patience, sometimes moving the mouse around slowly and methodically and looking for a good spot.

Attacking the catalyst from this angle to initiate the reflector's destruction has been the route that has yeilded most of my best attempts; I believe that a better setup may be found via another angle or method. (I achieved this in edit 2)

EDIT 1: Found one for the snark with only three seeds, but it's a bit longer, at 210 ticks:

EDIT 2: This game is fun and yet frustrating at the same time. (that's kind of a good thing)
Anyway, I got a snark destruction from only two seed still lives. And it's also the fastest so far - only 123 ticks:

igblan wrote:On WIndows XP, I run a JAR file by right-clicking, then Open with|Java(TM) Platform SE binary. You may have a different way of running Java programs on your platform. I'm sure people here can help if you run into trouble.

Multiple times while running the program I found myself adjusting the monitor so I could distinguish the pink cells from the white/grey ones. Maybe in the next version there could be an RGB color selection option for the cells?

This program is extremely helpful to me because I really like trying to find interesting ways of crashing gliders into things or placing still lives near them to cause something meaningful (for this game the main one is total pattern death), but it's really annoying to try in golly because it takes so long. Here it's extremely easy. So as an extension option I think it would be nice to allow for adding your own patterns. Since just drawing an important pattern and either manually describing it's use or not doing so at all is neither conveinient nor reliable I have a proposal for how that might be handled:
1. User draws the pattern in Golly with the rule LifeHistory
2. User runs all of it's possible meaningful inputs to get the active pattern envelope
3. User copies the pattern with it's envelope into the program.
4. The program then can just expand the envelope out two cells to get the quarantine region.

Some new puzzles are being added to the Seeds of Destruction alpha. They're all various pieces of the circuitry for a diagonal Geminoid self-constructing spaceship.

Here are some notes on the design and intended purpose of the puzzles:

Each puzzle is shown inside a region marked by a quarantine line. In general, seeds can be safely placed only inside that region.

The evolution of the pattern may touch or cross the bordering quarantine zone at the bottom or left sides of the puzzle, as long as no random ash is left when the reaction is complete.

Once the trigger glider has crossed the boundary at the top or right and entered the destruction zone, the evolution of the pattern should never touch or cross the quarantine zone at the top or right sides of the puzzle. Along the top and right sides will be an active copy of the replicator unit, plus any seeds around its edges -- so even small dying sparks that cross to the other side of those boundaries may invalidate the solution, by destroying something that needs to be kept safe.

The above two rules should not be broken, but may be bent!

If you understand how the Demonoid operates well enough to know that a given change will not make it impossible to destroy (or construct) the circuitry, you can make any adjustments you want! More detail on the Demonoid can be found on the Geminoid Challenge thread, so you can check the safety of a boundary crossing by adding two copies of your seeds to two adjacent replicator units in the full pattern. Here is a sample seeded replicator unit.

Below is a (relatively) quick summary of the Demonoid's design, avoiding most of the technical details:

The pattern for the first and largest "Demonoid Complete" puzzle is a complete replicator unit (RU) for a "Demonoid" self-constructing spaceship. It's modeled on Andrew Wade's Gemini spaceship from 2010, which was the first self-constructing pattern in Conway's Life and also the first spaceship to travel at an oblique angle.

The Demonoid travels diagonally, using two mirror-image RUs which reflect a stream of gliders back and forth between them. The gliders encode a construction recipe, which each RU uses to create an exact copy of itself, offset by 110 cells diagonally, using its single construction arm. The glider stream is then reflected into the newly-constructed pair of RUs so that the cycle can repeat.

The Demonoid's construction recipe is encoded in a single linear stream of gliders, replacing the twelve parallel streams in the Gemini spaceship. In self-constructing spaceship, there never needs to be more than one copy of the construction recipe. But the Demonoid's single-lane recipe is enormously easier to duplicate, so it will be a significant step toward a Conway's Life replicator (!).

Once the glider stream leaves the original RU pair, the circuitry is "dead" and serves no further purpose. For the Demonoid to be a true spaceship instead of just a very high-period puffer, the old RUs have to be destroyed completely, leaving nothing behind. In Andrew Wade's original design, destruction was done by one of the Gemini's three construction arms -- a special-purpose "destructor arm" pointing backward, which took several million ticks to shoot down all the still lifes in the parent circuitry, one by one.

The Demonoid design has an RU that's over two orders of magnitude smaller than the original Gemini's... partly because it has only one arm, aimed toward the next construction site. It would be difficult to reach back to the parent RU with it, so a quicker and more efficient destruction method would be better. Hence the Seeds of Destruction Puzzle Game!

Here's a sample solution to one of the puzzles, just as a target to improve on. 15 seeds, including the initial turner, can clean up the "Demonoid Common" puzzle. A lot of the seeds are very close to the catalysts they clean up, though, so there's lots of room for improvement. I'd say the job can certainly be done with a dozen or fewer seeds, just with minor changes to this recipe.

There's a zone violation at the top of the puzzle, but this is one of those cases where the rules can be bent: I didn't place any seeds in the corresponding location opposite the violation, so there are no actual forbidden overlaps during a replicator-unit destruction cycle. I checked this by pasting multiple copies of the seeds into the proof-of-concept Demonoid pattern, and triggering the first two seeds after all the construction gliders had gone by.

EDIT: Be careful if you're pasting solutions for the Top, Singular, or Complete puzzles on top of the proof-of-concept -- there's a block just northwest of the five yellow blocks, which changes position because it's used as a switch. It needs to be in its initial position if you're actually doing a full test run of the circuitry, but in its final position by the time the trigger glider hits the seeds you've added.

Extrementhusiast wrote:EDIT: Full desired result... uses seven blocks total. Can it be improved?

I just remembered that Stephen Silver's old two-blocks-plus-beehive constellation can perfectly well be converted to Blockic; all you need is a Blockic LOM seed, and that's four blocks maximum, maybe as low as two (?). So here's a five-block LWSS seed -- six blocks if you suppress the extra glider:

There is a serious bug in the latest version relating to savegames, found by Dave Greene.

If you add more than one branch to the exploration tree immediately below a puzzle - ie if you try more than one initial seed - and exit and restart the game, only half of the branches for that puzzle will be loaded. Eg if you try two different initial seeds for Demonoid Complete, and continue exploring them, when you restart the game, the second branch will be missing.

I know the fix, but my version control discipline is rather lax, so I won't be able to release it until the current dev version is stable.

In the meantime:

(1) Make a copy of any savegame falling foul of the bug; you will be able to recover it with the next version.
(2) Either avoid multiple level-1 branches in new savegames, or use the Copy Down button to make copies of the second and subsequent branches.

Adding a single block turns a snark into a (one-time) 90 degree reflector. Since it still takes a second block to stop the remaining glider this is still a two block solution. The second block has a degree of freedom for placement.

BlinkerSpawn wrote:This 15-seed solution for Demonoid Bottom can definitely be improved, but as an upside is four-fifths blockic:

This reminds me: I have to get the Seeds of Destruction Game recompiled with some more up-to-date puzzles. There's now a Demonoid replicator unit design with only half as many still lifes as the design in the current Game. Some attempts have been made at self-destruct circuitry for the new Demonoid, but it really needs a more concentrated effort -- and then I think it will be time to put together a recipe for the best version.

Attached is source code from Paul Chapman for the latest Seeds of Destruction game. It has some really nice new features and also one nearly show-stopping bug. You can define your own seed objects by copying them from Golly and using them in the Game just like other seeds (though you can't rotate them yet). You can paste new puzzles in, but then when you solve them the button doesn't work to copy the solutions out as RLE... so you have to take a screenshot or count pixels by hand (!). It's an easy fix, very likely, but I haven't had the time (or the familiarity with Java, really) to tackle it.

I'd also like to add quite a few keyboard shortcuts, especially to be able to rotate seeds without moving the mouse off to the corner.

There are lots of other possible new features I've been thinking of -- select a small area and try all possible orientations of all possible seeds, for example, and sort out and display the ten with the smallest population... But I think neither Paul Chapman nor I are likely to continue development of the SODGame application that far. If anyone would like to take over the project and run with it, please give it a try!

While we're on the subject of updating, here are some things I would like improved (although some may be because I use it mainly for syntheses):

Having all (sub)trees closed by default (as it gets really annoying when I have to roll the mouse wheel literally 140 times to get from one end to the other, and the scroll bar goes past things TOO quickly, as in five and a half lines per pixel, when the default window size is about 34 lines)

Being able to delete (sub)trees (if you click when or where you don't mean to)

Putting in all four phases of the glider

Having multiple nameable sandboxes or nameable sandbox folders

Making the number of generations more precise (so that I don't have to keep rephasing everything)

Possibly making the random word vocabulary larger (as I literally got "sampan" twice in a row, and have noticed repeats on many other occasions)

Properly referring to the tub as T4, and not T3

Adding in blinkers

Overall: It's a great concept (and is pretty much what I needed), but there are many small things wrong with it that irritate me. (7.5/10)

Excellent idea. The instant result showing is very convenient. I bet this will cause an influx of solutions to destroy these puzzles.
The thing is, though, that I use a laptop with no mousewheel. Could you make a way to change the still life without a mousewheel?

Extrementhusiast wrote:While we're on the subject of updating, here are some things I would like improved (although some may be because I use it mainly for syntheses):

Having all (sub)trees closed by default (as it gets really annoying when I have to roll the mouse wheel literally 140 times to get from one end to the other, and the scroll bar goes past things TOO quickly, as in five and a half lines per pixel, when the default window size is about 34 lines)

Amen to that first item -- it's impressive how quickly the tree gets unwieldy, even though it's really nice to have a record of everything that's been tried, without having to save and load awkward snapshots all the time. Pretty much all of the other items have also been pain points for my use of the tool, as well.

My workaround for oversized search trees is to start over with a clean sandbox periodically, by copying the jar file to a different folder when I start a new project (or else just move the old .sod file into a backup folder).

Seems as if it would make sense to convert the save file format to an editable text format, so that there would be at least one way to edit any aspect of the search tree (add new puzzles, delete useless old puzzles or branches, put in multiple sandboxes with different names, etc.) This would be more or less the same design philosophy as Golly's preferences file: it would be nice to have a beautiful clean GUI way to change all the advanced settings in GollyPrefs, but in the meantime a text editor is a darn good approximation...!

I've made a very minor patch to SoD, which fixes the bug with copying user-added puzzle solutions out of the game. I haven't touched anything else yet, because it's really late at night here and I don't want to stay up another two hours working on little things. I can deal with those later, when it's actually still a reasonable hour.

I haven't tested on any other machines, but it works on my 64-bit Windows 8.1 laptop.