ux: pressing escape once resets, then if reset, exits the puzzle.
bug: reset isn't maintaining the generation.
Make the conduit player white with a text shadow instead of a colors contrast.
I hate to do it, but I need to copy debug_grids{} into map.grid() and ungeneralize it -- it's getting waaaay too complicated now that it's the actual rendering engine. grids{} and debug_grids{} themselves are still useful packages, idk where to put them though. I guess I could just leave them in the project for the time being
There needs to be UX Stuff for entering rooms, unlocking doors, etc and maybe some basic room descriptions and then also all the stuff the infoplates have.
Orientation should no longer be relevant. Swap to an @ instead.
Coordinate system so the generation remains the same regardless of where you approach from. -- can scrap if need be.
You should be able to save the game -- like on a puzzle this doesn't need to save the whole cache, it could just save the viewports and regenerate it on load. However it'll definitely save your keys / completed puzzles (so you can't get the same key over and over) and your location in the infinite gallery.
Info plate stuff. Display fractal dna (and maybe stuffabout adjacent rooms) and let you play arbitrary seeds in the room. Also show help.
In pouch there'd be a gallery node as well as a puzzle node for chats/forums/etc.
Each puzzle should have a timer and there should be a high scores table, plus a "personal best" thing.
Two bugs in one: You can hop railings from a staircase, and railings can spawn on stairs -- easy fix here, just prevent it if it's a stair. Need to be able to easily replicate though. [0,0,4] in seed 463066135395 seems to create it. [1,-1,0] is even worse.
This thing sure has been renamed a lot -- need to update the subdomain to whatever the final name is.
NOTE: There's not a lot of sense doing this until after the paintings upgrade -- each type is probably going to require its own range of settings, particularly around color transitions.
Altered Generation
Generalize the shit out of gen{} -- have different ways of generating starting conditions, more fractal logic, more variables (and a bigger range).
For the origin, set these parameters to what the Conduit project is currently doing.
Rooms however should set the parameters really randomly. Give yourself a bunch of keys so you can test different layouts easily.
This project will get the new painting types into the omega exhibition, though a lot of stuff will be faked out in version 0.
Basic Stuff
Painting Types
For now, the red type loads a fixed painting from a fixed red album. This should run through the new fractalicious code and load the painting into the puzzle accordingly. Make sure this works, including the scaling algorithm pulling from the canvas, etc.
Change it so it's a random painting from the specified album.
Different rooms should pick different albums.
Fake out the blue folder and it works similarly.
The yellow folder should just contain a bunch of royalty-free images of earth. Could get this one up to 100% -- don't have plans for a lot of these.
The black folder works similarly to the yellow folder. For now, throw in some random surrealist/horror images, they don't have to be royalty-free at the moment.
Add a loose end about fleshing these type image concentrations out.
Green Paintings
Create a library for sticking random shapes in a set image space -- will be useful elsewhere. This should include a shaping{} and a shaping_filter{} that actually filters pixels out of each rectangle. Similar to how shatterloop dungeons work, but saner. Color data and color like settings, borders, etc should be in there as well, as the input is an obj. Size ranges are also part of the obj.
Create filters for circles, squares, rectangles, stars, etc.
Green paintings pepper a bunch of shapes throughout the canvas. Idk what the color settings are.
Change this so they actually pepper through a larger canvas and scaling brings more of it into focus, the way image paintings work.
Orange Paintings
(( Finish whatever needs to be done to the teseel/manifold project to make it portable and returning an image obj. )).
Import what I'm assuming is tessel without the skew heuristic.
Orange paintings should randomize the shit out of everything and return a few numbers.
Rooms determine some of the higher-level settings, like the base and color set, etc.
Base color hues should be set outright rather than being distributive -- the room will set a few colors distributed from one another on the hue spectrum but largely random beyond that.
Metamorph
(( Finish the metamorph project in whatever capacity is a bunch of effects that would be useful on earth images. Don't worry about quality, that would make the runtime too great on the game probably. ))
Import metamorph stuff somehow -- basically the metamorph and prismize effects.
Yellow paintings should metamorph the chosen image in some random metamorphic way -- I think the image stays random per painting (they're not super different) but the metamorph effect differs from room to room, with the paintings applying different settings to it.
(( Finish the metamorph project in whatever capacity makes surrealist paintings have simplistic polar transforms where they're all still very visible )).
Itemize out the polar effects and settings that are actually useful for surrealist paintings.
Black paintings determine the settings, while the room determines the effect and actual painting. Add a loose end about floors or whatever dictating the painting or w/e level of discretion I want herein.
Red and maybe green paintings run the image through color filters, though this is optional, and the option is dictated by the room. Or whatever discretion makes sense.
Blue paintings should invert the black/white spectrum in various ways. Idk what this looks like or if it's even viable.
Cropping
I'll (probably) need a separate checklist for this, but red and blue paintings should actually take a crop of my art rather than the whole thing, to add variety. I want to keep yellow and black images as the full thing however.
This update should get the new paintings in to 99% status (other than the actual content, which will be a project in itself).
Seed rooms and their adjacent rooms together (in north-south or west-east of the equivalent vertical orientation) to determine where the exit is -- on passageways this gives you an x or y coordinate while stairs give you both. This should make overall mapping make a bit more sense.
Create floors{} to handle floors as well as nodes{} to handle 3d nodes. Most of my work is going to run through floors{}, however.
Each node has an x/y/z coordinate, and each floor has that along with a floor. So have nodes.gen(3dcoord) to begin the generative process. For now this should just run through floors.gen(3dcoord,floor=0).
Separate out the grid test functions from the actual map, as I'm going to need the grid test functions to test the navigational framework. Otherwise package it back into a sane package.
The node should determine the size of the maze, which.. idk, maybe 100x100 for now. In here generate some 3x3 red squares, idk how many and will need to try this a few times to figure out the right layouts. The shapes package created in the map update should be *very* useful herein.
Create a single yellow tile somewhere, which the node determines.
Red squares should be bordered by blue squares and *these* are what connect, which should simplify the hell out of everything honestly.
Connect red squares to one another with blue tiles. The sanest way to do this is to connect the Centerpoints to each other first, then offset it randomly to one of the edges. Blue tiles shouldn't replace red tiles. Connect also to the yellow tile a couple different ways. Use the stair steps algorithm here, and also idk how many connections I want -- it might differ depending on the node along with other stair stepping settings.
Map out all the spaces bounded exclusively by tiles rather than the floor border -- selmagic{} should be helpful here, and I think that's basically already in package format.
These spaces should somehow turn into rectangles, probably via some kind of shaving algorithm.
These rectangles should then use the shape _filter{} package to turn into random green-tile geometric shapes. Make sure these are still connected to blue rooms and/or red rooms.
Do this a few times to get different layouts / settings and make sure everything works appropriately like in my notes.
Figure out the algorithm for red floor connectors and green floor connectors.
When generating the location of red cubes in a node, generate also the location of cyan transports and indicate these a bit different in the map. The coord needs to stay the same in floor jumps.
Green jumps are a bit more tricky -- I guess if you fall within the range generate the floor up and/or down temporarily and distribute jumps where green rooms match. If there are no matches, add an orange door between the two floors to be rendered at a different step. Again, green-cyan tiles shoild be indicated a bit different.
Make sure the required orange doors appear -- their location should be absolutely random and just stick them somewhere in the existing tiles. Ideally there's more than one that link floors together in the case of a green bypass.
Other orange doors should appear fairly randomly -- a good way to do this is to seed the floors together and see if they have an orange link, and if so then orange doors can be created appropriately.
Define tiles in some kind of x/y "edge" -- probably some range around the maximum.
Each node should have a connection to adjacent nodes via some amount of orange doors that fall on the edges-- vertical edges are easier, they're just the top and bottom floors. Indicate these types of orange doors a bit differently than the rando jumps ones.
Index the total amount of orange doors and promise each floor some amount of orange keys based on proportions of the total/2.
Each floor should be promised 2 cyan keys in a random location. If it's the origin cube on floor 0, put the cyan key somewhere in there but not in the actual root origin. Probably somewhere totally handcrafted.
This should get the overall layout in place -- the next project is turning this data into room data.
Each room compares its coord to the meta-mwta level location, and this determines where its exits are. Make everything unlocked for now so I can test this out easily.
Upfloor jumps should do what you expect, and also everything should go to the exact same coordinate between room jumps assuming that's not working yet.
Inter-node jumps should instead be indicated differently and also should do what they're supposed to do, shifting/resetting the coordinate system in the process.
Orange doors within the same node will also work a bit different -- make sure these are doing what they're supposed to, and also I might need another checklist for their functionality as it's a bit weird.
New doors distribution
On each floor, there are two blue doors that go out into the blue square. These are always locked. Every other exit shouldn't exist.
Red rooms should have red locks between them, however they can also be unlocked, except the origin square where everything is locked.
Blue rooms are gated between each other by red or blue doors, with a higher percentage being unlocked than the red cubes (but a lot still varying probably).
Blue room to green room connections are gated by green doors. These are never unlocked.
Green room to green room connections are gated by green doors. These are sometimes unlocked.
I'll handle yellow room stuff all at once for sanity.
Key distribution
Each red square gets promised two blue keys, with more being possible but rare. The origin exclusively has 2 and they won't be on the root room. Everything else is a red key.
Blue rooms contain a mix of red, blue and green keys, with green keys being rarest. Make sure there isn't a green key into some ways in on any of the branches from the origin for game progression purposes.
Green rooms contain a mix of green and yellow keys.
Distribute cyan and orange keys pretty randomly in each floor (and rarely), but allow for promises established in previous generation steps. Make sure these don't conflict with game progression near the root room.
When generating green rooms, assign each one a yellow transport and note its angle and distance relative to the yellow room.
Yellow transports are always locked by yellow doors and look a bit differently from other doors but are essentially like staircases. Make sure rooms with a yellow transport *and* Both up and down stairs still work navigation-wise.
The yellow room splays out each yellow door according to its distance and angle. If there's an overlap, make a promise to send you to a random door in that direction.
The yellow doors should do what you expect, including the promise established in the previous point.
Make sure unlocking transport doors from either side unlocks it from the other side too.
Yellow rooms should have yellow doors connecting them to whatever they're connected to in the map.
The Centerpoint should be a special door that jumps up the next level of scale. This is where things start to become a serpentine clusterfuck.
Upscaling
Each yellow room has cyan doors that allow you to go up or down to the limits of the node. Idk how the layout here influences yellow room transports but just make sure things are still accessible.
When you upscale, generate a yellow room nowhere in particular (depending on what the engine looks like).
So level 0 yellow rooms allow you access to the green rooms and other floors of the node. This has already been established, now we're talking about level 1 yellow rooms.
Each NxNxN of Nodes should be in a kind of "chunk". There will be 3 yellow rooms in this space, corresponding to the three arises of travel, the x and y rooms spacious g out in that kind of grid. I have no idea how I'm setting this up yet but I want -5 on one side and +5 on the other with squares allowing subvector transport. Having there be 10x10 exits is helpful for my own sanity as scaling is then understandably logarithmic. If that isn't possible in the existing mapping engine, then build a new one where it does work - yellow rooms don't have anything else in them so this is perfectly fine. Would prefer to keep it on the same engine however, even if I have to downscale tiles a bit to accomodate.
Each center goes to another level of this mapping along the same axis, so as you cross center rooms the scale increases logarithmically. This should proceed until it hits the arbitrary limits defined by the ship. The ship should be cubic for my own sanity, and heck that fits into the Lore better anyway.
Not sure how you change axises, but want this to be UX friendly in some way other than selecting the axis every single fucking time.
Regardless though every transport on this system is gated by yellow doors that unlock in both directions and visibly unlock on all three arises.
The Centerpoint transport of a node only appears on a single floor, which maybe isn't floor 0 so high-level yellow room exits are very definitely two-way.
The game seed should influence Aleph quettan placement and literally nothing else -- the game is complicated enough to navigate as is, and I want to promote social mapping.
Again, not sure what the actual limits of the ship are but the Aleph quettan should be a 3d shape somewhere inside a cube of some size somewhere very far and random in the ship. Should use some kind of selmagic thing to expand out from a center node randomly without filling the cube entirely. So the first clue helps you find this rectangle, and the second identify the correct node.
Nodes which are marked as Aleph quettan should appear differently in the transport networks but still be gated behind yellow doors.
While the door layout is the same, every single painting in Aleph quettan Nodes are black.
The generation of everything should be very different as well, though I'm not sure what that looks like yet. Making it kinda creepy is key however. Non-aleph Nodes inside the cube should maybe be different as well.
The clue structure looks like this:
Location of the Aleph cube
Location of the exact Aleph quettan node (pulled randomly from the set of nodes that are Aleph quettan inside the Aleph cube. This Nodes generation should also be different.
Location of the floor within that node -- I want this particular section to have way more floors than normal so this is more important. And again that specific floor will appear different.
Room coordinate where the painting is -- this room has a single painting which kinda takes up the whole room or something equally weird.
Location of the Aleph quettan's core inside the painting -- unlike every other painting this one appears at some deep scale somewhere so you can't just find it outright.
Coordinate Systems
Coordinates are named in various places -- on your maps, interfaces, journal buttons and ultimately the Clue system. They look like the following:
Nodes are assigned in 3d space via z:x:y so like the center node is 0:0:0. Some far-flung node might be 567:-222:73742. I think the Aleph quettan should be in a 100x100x100 area, in which case the clues could be assigned as 2355--:-61907--:72489-- or something like that. That implies that the cube runs along 235500 to 235599 on the x axis, etc. Node locations are prefixed by A.
Room coordinates are assigned floor:x:y and prefixed by B.
Painting coordinates are way trickier because scale isn't as clean as floor. Maybe a zooming thing that assumes 10-size chunks, so like 4:5,3:6,8:9 would mean the 4:5 chunk and then the 3:6 chunk etc, the problem is scaling is 2x, not 10x. They're also prefixed by C.
So an Aleph quettan location might be A235591:-6190732:7248902 B3:-51:92:-7 C4:5,3:6,8:9. That looks pretty intense and I kinda love it.
Each of these strings are like "words" and the clue structure is similar to Crazy Diamonds-- you get the real word and a bunch of fake words from some fixed set and determine the real word by drawing comparisons. In CD you'd get like AGIF, FANP, KAGM and you can see that A is correct. Idk what the math is on these but I should explore it to make sure I'm allowing for enough possibilities.
