Some sort of Moon Sandcastle

[eternaldensity]

Because everyone needs a moonbase made of sand.

[pickten]

Oh, this is an interesting possibility. I can think of a couple possible ways to get players to the moon.

First: Either through Controlled Hysteresis, Rosetta, or through "quests" (preset dragon fights), unlock a tower. This "tower" has a bunch of levels either built or explored by some mechanic, at the top of which is the moon.

Second: Players must craft a rocket to the moon with various parts such as "fuel" (Blackness? Vacuums?), "Hull" (Gold? This sort of violates the point of Gold, though), and "defenses" (I keep picturing this being dragons strapped onto the ship, but that's just silly)

Third (boring): Construction from blackprints.

In terms of what happens once there, I have no earthly (pun not intended) idea.

[eternaldensity]

Maybe you need to create some kind of special blackness vacuum dragon (with Rosetta's help) to fly you to the moon.

[EPSIL0N]

I don't have any concrete mechanics in mind at the moment but figured I would throw out my two cents.

First idea was "would we want to do something with infinite bonemeal or vacuums?" I haven't personally gotten to either of them but I was under the impression that infinite bonemeal is not that far off even without exploitive spamming once the code is changed to actually allow those big numbers rather than force the low upper limit and that infinite vacuum is probably not much further after that.

The other thing that comes to mind is if we are going to make this a multistep process we could go for something that might take a very long time from start to finish but the start of which wouldn't be hidden behind a huge NP gate. 4.0 added a lot of stuff but I think the vast majority of the new content was hidden at or past the 'End of Time'.

[charmsRace]

I vote for a puzzle tower! Get it? "Moon logic" =p

What kind of puzzles? Hmm, maybe Lights Out? 24? Sokoban? Oh, how about "calcudoku"/"mathdoku"? In general, things that can be played on a grid.

New Boost category: Lunar Tech.

Maybe, once Ceiling Broken is unlocked for the first time, the player gains a natural trickle of Moondust (new stuff). That starts pretty early on. As it accumulates, it can be constructed into a new floor of the tower, upon solving a puzzle. The tower is connected to whichever NP you choose to build the first floor at, I guess. It can be moved later, once you unlock Space Elevator or something, and you get something nice for moving it to NP 0 once you can. What's the point of traversing the Moon Tower? To get starstuff! Loading the Glowitzer with starstuff and firing it at another stuff multiplies it by 1.5 or so. There should be some sort of limiter in order to prevent unintended infinites. Maybe it tracks, for each stuff, how high stardust has most recently boosted it, and it can't be used on that stuff until you reach 1.5 that level on your own. Something like that. It can also be fired at certain non-stuff values like total Pope decrees, the Stealth streak, Ritual streak, rifts into shortpix for safety blanket, dragon hatchlings frozen, total pope uses, locked vaults opened, &c., each subject to that limitation. The idea is that this is something that can be done in parallel with everything else, and it can be used to speed up various grinds in bursts. E.g., you might get 2/3 of what you need to boost This Sucks from 3000 -> 4000, then use the howitzer to cut off the end of the grind. It's a big boost, but it still has to be used smartly or it's pretty much wasted.

Also, I vote that the moon towers NPs be positive imaginary numbers.

How do you get starstuff? Well, there will be some sort of sensor that tells you that there's a piece floating at, say, NP 3+6i, similar to how maps work. You build up the tower like normal five units (the first floor is 0+1i), then launch an EVA to retrieve the piece. This entails delegating some drones to the purpose, which can be constructed in some way similar to how dragons are hatched. You also need to fuel them with something, depending on how far out from the tower they're going. They do all this automatically once you deploy them; you don't need to waste your ONGs inside the tower. In this example, they would return 6 NP after you deploy them.

I don't think it would be a huge stretch to introduce one new tool after all this time: drones can be dedicated to collecting moondust instead of EVA missions. Various boosts ensue.

After collecting enough starstuff yourself, you can unlock the Grapple Mortar. This lets you fire down from the tower to the "ground" (real NPs) below, zipline down, and collect any starstuff pieces on the way. Yes, this entails some trigonometry. Do it enough times yourself, and you'll unlock something to do the math for you.

You can navigate within constructed floors of the tower freely without waiting for ONGs. Building a new floor takes 1 NP, but you don't need to be present if you tell drones to do it. At various floors of the tower, you'll have the opportunity to build different facilities. On floor 10, maybe, you unlock the drone workshop, so you don't have to build the tower yourself. At 25, you build airlocked elevators, so you can deploy drones out of the tower. At 50, you can construct a remote control interface so you can deploy drones from outside the tower. At 100, you can construct an AI to run the tower for you, and automatically construct, repair, and deploy drones. Maybe this AI could eventually even be the auto-Redundaclicker that has been kicking around the github for a while. It clicks one RK per NP, which can be upgraded (slowly). At 250, you can construct the zipline hub, which is where you use the Grapple Mortar. You can use to get starstuff quickly, and the AI can use to air drop to you whatever starstuff it's collected in your absence (at your command). At 500, you unlock a Stellar Refinery, which refines large amounts of starstuff into μSols. These are also ammo for the Glowitzer, and they work the same, but the boost factor is 2.0 (and so is the limit factor). 1000: Lunar Throne, doubles the Pope bonus. At 2000, maybe you finally reach the damn moon, and god only knows what happens.

Maybe there's other ammo you can get! When you fire Moondust at a stuff, you get one of it. You can only do this once per 3 NP, or something. This would be useful for supplementing the beginning of, say, Flux Crystal or Pane production, or

Possibly you eventually unlock a tiny particle collider, powerable by μSols, which can create Antiquanta (Glowitzer ammo). The more stuffs you have set to 0 at a given mNP, the more efficient the conversion. I like that because we have reasons to set Sand and Castles to 0, but not really other stuffs. Antiquanta can be fired to set a value to zero. I can think of a few situations where this might be useful, like setting currently hatching eggs to 0 so you can fiddle with the nest linings and fledge from cryo. Also, there are times it would have been nice to vaporize a fledged clutch of dragons without putting new ones there instead. There could be an unlockable autofire setting, but I'm not sure what it might be used for. Maybe, when it's on, it sets all stuffs to zero, but gives a massive Pope-style boost to another value. Again, the idea is to narrowly focus on lessening certain grinds. So you might turn this on for the TS grind or the Ritual grind or the Safety Blanket grind, if you're willing to sacrifice progress on along other tracks. Looking at my own stuff stats, there really aren't any I would tremendously regret setting to zero; most of one's progress in this game is in the form of boosts, not just the stuff numbers themselves.

Maybe, you could set it to autofire at a chosen tool. Then, when you install an Gravitometric Stasis Chamber in your moon tower, your Tool Factory can start crafting negative numbers of that tool. Let's say it only works on, say, drones. Then, instead of moondust, tool drones create more Antiquanta, while nothing else makes anything. It's like a Vacuum Cleaner for every stuff except Antiquanta. Essentially, you're sacrificing everything else to make large amounts of one resource. Then, another moon tower installation crafts together ridiculous amounts of μSols and Antiquanta to get Tachyons. These can be loaded into the Glowitzer for a massive 3x boost to a value, but it's quite hard to make them. It's up to the player to determine when it's smart to save up for a tachyon and when it's faster to just suck it up and wait.

We'd have to be careful when considering whether being able to multiply a stuff by 1.5-3 might be broken. A bit more detail on the limiting system I mentioned: Say you fire some Starstuff at Blackprints, taking you from 120 to 180. Then, even if you spend those 180, you can't fire anything at Blackprints again until you get 180*1.5 = 270 of them. If you fired a Tachyon at 1,000,000 Vacuum, you'd get 3,000,000, and you can't fire at Vacuums again until you reach 9,000,000. I'd call this an "afterglow" effect. After blindly running up against this limit a few times and being informed via notifications, you'll unlock a Geiger Counter, which will track the limits on all stuffs currently capped. 1.5 is a solid jump, but unless it pushes you over the edge to afford some other boost to that stuff, it's sort of pointless.

This is all off the cuff, so it's really rough. There are probably some pretty bad ideas in here, but there are some that I think are pretty cool. I like the feeling of constructing a "base", almost like a home for the player. One thing I'm wary of is introducing another five stuffs (Moondust, Starstuff, μSols, Antiquanta, and Tachyons) after the large number introduced in 4.0. Maybe we could pare it down to three or two somehow.

Even if nothing else here is workable, I think the philosophy provides a good outline: SCB is overdue for non-endgame content. The Moon Tower, not requiring ONGs, is something that can be built in parallel with whatever else you're doing, after a bit of series overhead. It provides progress boosts to whatever other tracks you're working on, and is sort of a general-utility track. It doesn't do almost anything as straightforward as "this number grows twice as fast", at least not without sacrifice. It takes a certain degree of savvy to benefit much from it.

Anyway, thoughts?

[eternaldensity]

Even if nothing else here is workable, I think the philosophy provides a good outline: SCB is overdue for non-endgame content. The Moon Tower, not requiring ONGs, is something that can be built in parallel with whatever else you're doing, after a bit of series overhead. It provides progress boosts to whatever other tracks you're working on, and is sort of a general-utility track. It doesn't do almost anything as straightforward as "this number grows twice as fast", at least not without sacrifice. It takes a certain degree of savvy to benefit much from it.

Sounds good, and I think you're right about what SCB needs next. Or at least it seems convincing to me!

[pickten]

Yeah. That's very true.

Anyways, in terms of the tower idea: I do like this, though balancing may be tricky as you mentioned. In terms of puzzles, I'd not suggest Lights Out, because I'm working on the next variegation step, and currently about 3/4 of what I have is a Lights Out variant and it would be incredibly hard to change it (the grid is made up of boosts). In terms of other kinds of puzzles, we have to be careful to make it something that can actually be implemented. 24 is a good idea, as is sokoban. I'd suggest probably not a pencil-and-paper puzzle, because most require number-input and/or function best on large sizes.

In terms of the mechanics: I don't think it would be too unreasonable to add all 5, provided they each have significant amounts of content (which seems to be the case given the new tool and facilities). Tachyons/Sols/Antiq seem to come much further down the road than the first two, so they could come later. Also, in terms of generally keeping the number of stuffs low, I'm going to be busy for quite a while expanding on variegation, so I think it won't be a problem as that starts to take shape. Finally, regarding accidental infinities/breaking progression, I cannot think of anything which would seriously be at risk, especially given the growing requirements, but I'm not at all sure.

[charmsRace]

Thanks for the feedback!

All right, no Lights Out. I'll think about how to do something else!

Currently, tower construction mechanics are complete except for the puzzle component, and the Glowitzer is almost complete (what a nightmare).

I'm pretty shaky on being able to actually implement complex NP, though. Most of the tatPix code is fairly impenetrable to me. I was wondering whether you had the time or interest to do it, since you're responsible for the alt.-story code in the first place. The tricky thing is that we need to store two NP data in one (real and imaginary part). It's no problem if it doesn't happen right away.

[pickten]

I can certainly implement Complex NPs, but the easiest way seems to me to just ignore the fact that it has to do with nps at all, and do a separate Molpy.ImNPnum variable, which is reset on storyline change, since nothing is ever really going to work with that or know it exists except tower/moon content. You wouldn't even really have to deal with the stuff that went into the TaT implementation. If there's also separate storyline-like logic, then it's worth adding on to the TaT stuff, but from your description, there didn't seem to be much.

Regarding the whole question of the puzzle, the more I think about it, the more sokoban variants seem reasonable, especially looking at puzzlescript and all the cool variants on there. The one tricky thing is making it clear to the user.

[charmsRace]

Mmk, that sounds doable. In that case, how exactly do I go about declaring a new variable to be saved? It looks like it just needs to be put in the right place in Molpy.GamenumsToString() and Molpy.GamenumsFromString(), but I want to be really careful when screwing with save data. I see that Molpy.currentStory is a derived quantity and not a saved one.

PuzzleScript is a super cute thing that I've fooled around with a little bit in the past. The real question to me is how to generate puzzles instead of hardcoding them...

[pickten]

w.r.t. new vars to be saved: That sounds right. Should I still do it?

w.r.t. generating puzzles, it depends on if we want to use a variant, and, if so, what. The most obvious idea is to just staple a few prebuilt puzzles together, like Logicats, but that seems weak and boring. What seems better would be as follows:

First, start with a few elementary puzzles (Note that it suffices to use the 0-move and 1-move puzzles in order to generate all possible puzzles)

Then, we note that the following transformations don't affect solvability:

• Given two puzzles, translate so as to have the same start location, require that boxes/targets/filled targets don't overlap each other, then take the intersection
• Given two puzzles, append the latter to the solution of the former.
• Surround the puzzle with walls
• Replace a wall by a box on a target
• Remove a wall
• move the character 1 space in any cardinal direction to an empty space

The intersection is defined as follows: Treating unused squares as walls, at every square, we have a wall if both had walls, empty if one is empty and the other is empty or a wall, and for any other combination, whichever of the two is neither empty nor a wall.

This second one is done as follows:

• Identify each box starting point in the second with a target of the first, preserving relative distances; translate the second puzzle accordingly.
• Require that the second puzzle has walls everywhere that is a in the second puzzle and is a wall or unused box/target in the first or is not part of the first puzzle.
• Remove all targets in the first identified with a box in the second with empty space.

In order to generate a puzzle "of complexity n", we do the following:

1. Start with the empty puzzle (@)
2. Perform n runs, where each run, we take a puzzle of complexity <n and stitch it together with our current with one of the two stitching operations above.
3. Perform some number of "surrounding" operations, .
4. Remove a bunch of walls with the penultimate and antepenultimate operations.
5. Move the character a couple times.

This definitely works, and, I believe, can generate literally all valid puzzles under the assumption that targets are just special empty squares, i.e. you cannot walk on filled targets and can move boxes off of filled targets. The big issue is that the generation function is not only slow (though it can be sped up by cutting down on the number of runs etc.), it also is probably skewed towards very boring/bad puzzles. If you want to tackle the complex NP stuff, I'll try to write an implementation of this (without a solver/player, though) soon-ish.

Edit: so far so good, got just about everything except intersect and extend, and that includes quite a good number of helpers.

Further edit: approximately 48 hours in. All logic is done, so I'm bugfixing; syntax errors are fixed, as are several (but not all) logic problems. Next is to Doing work on optimizations (at least some fine-tuning). Finally, I'll have package it for SB and commit.

Another edit: Getting there. Still some bugs left.

Edit again: 4.5 days in, having call stack errors :(. [fixed now] [nope, more edge cases left]

And again: a couple things seem broke (cannot gen anything with + or o), rest seems clean. Below is a sample of complexity 100 (genned wicked fast, too, albeit with small constraints, so speed is ok)

###########
#%_%_%____#
#%__%_%%%%#
#_%%___%%_#
#%__%___%%#
#__%_@_%__#
#%_%%__%%_#
#%_______%#
#____%____#
#__%_%%_%%#
###########

another edit: getting silent discards of all errors despite strict mode, which is frustrating as all hell. 1 week in, now.

9 days: closer? It can now use + and o, but now is spitting out junk as well. See: (also, yeah, took out the trimmer for now, because it was over-eager, and unnecessary)

#########
#########
#########
####o####
####+####
##o+@+###
#########
##_######
#########

11 days: (seriously? ouch, me) Fixed a few more bugs, including one with rather large ramifications; still not done.

another edit: https://jsfiddle.net/pickten/jvkngLg6/ is my wip (still bugfixing...sigh). Let me know if you spot a bug.

21 days: This is getting ridiculous. I'm pretty sure it's almost working, though. Should have it done tomorrow at latest. Left is a nonessential bug and a big (but probably simple) logic error.

edit: nope, surprise last-minute bug+too much time back and forth w/o internet means I won't get enough time today.

again: so damn close, and I'm pretty sure intersects is now finally perfect (i.e. goes if able, withdraws otherwise, never messes computation up), but extend is having still more issues.

[charmsRace]

Whoah! That's a really impressive formal grounding for puzzles that I've never thought about. Truly fascinating. I don't think I'll really grasp many of the details until I see them put into practice, though.

How slow are we talking? It wouldn't need to be done very often (every time Moon Spire construction is begun, which is probably going to be around 1/hr at first and then less frequently as the tower climbs).

Okay, I've started implementing complex NP. Not as painful as I thought; it's going well.

[pickten]

The generator's almost done, now, with just one known bug left that should be fixed later today, hopefully. In terms of speed, generating puzzles of complexity 50 is nigh-instantaneous on average, but occasionally hangs for 2-3 seconds (when it produces large puzzles -- for some reason this is currently very much all or nothing). This is all without optimization, though: I'm thinking that, since the operations themselves are within reason in terms of speed, I can rewrite some of it so it runs simultaneously with the rest of the code. Specifically, whereas it currently does: "Generate 4 -> (Generate 2 -> (Generate 1, Generate 1, Generate 1), Generate 2 -> (...))", it could instead start with an (unsaved) list of the base cases, and, each mNP, perform an operation and add the result to the list, picking a random puzzle from the list when asked for a puzzle. This has the advantage of letting less common puzzles come up more, but, for better or for worse, serves as a savescum measure: for this to be a decent challenge (i.e. not solvable in < 3 pushes), we basically have to require something of complexity n (probably 50 or so) to be in the list before the puzzle can be presented (seriously, having less generates boring puzzles, often up to complexity 500 sometimes). I'm not sure, though.

Edit: finished bugfixing, now working on making the generated puzzles more interesting at smaller complexity.

Subedit: Some statistics on my testing: at complexity 50, I've run about 100-200 runs. Over all of those, one was impossible and I've no clue why -- however, it was only one at large complexity and a lot of testing, so it's probably a reasonable margin of error. I've not been able to reproduce it, since. In terms of how interesting they are, this is so far the only nontrivial puzzle generated:

%__________
_____%_____
______%___%
_____%+o_%%
__%_@+_%___
___%_o___%%
____%__%___
_____%_%_%_
___________

Sub-Sub-edit: Adding in some more primitives, after which it should be ready for use. Strictly speaking, those I'm adding aren't necessary, but they were incredibly unlikely to be produced, despite being incredibly common in human-made puzzles.

Final edit: Completely bugfixed, still about the same speed, still as boring. 100 is quite boring still, runtime is about 5-10 seconds at that level.

[pickten]

Incidentally, what all purpose helper functions already exist? I know flandom, and GLRsChoice, but are there things for the normal (i.e. non-js) sense of equality? If not, my implementation has a couple functions that might be worth exporting: neq, which tests for inequality (not equality, because I didn't realize I needed that as well, for a while), and Array.prototype.ind, which is a version of Array.prototype.indexOf. Do equivalent things already exist?