Closed ValdemarGr closed 2 months ago
Thanks for your suggestion. This was also suggested during Sanctum League itself. Back then, I wasn't really confident that I could get it working consistently, but I guess I could look into it and actually play around with it this time. But that'll have to wait until dust settles a bit: I'm still waiting for concrete recombination information to update my simulator, and I want to play more of the league of course.
I'm in between builds right now and can't get the Sanctum thing out of my head, so I started playing around with the idea.
detecting rooms | detecting connections |
---|---|
As a second step, I need to figure out how to abstract that into actual pathing/connections.
I don't really interact with sanctums, so I have a few questions on the basics (just to make sure I got them right):
it's always eight rooms per floor, right?
is the first choice on a new floor always between three rooms (except on the very first floor)?
I did a bit of playing around and ended with this algorithm, which only uses the paths:
I use DBSCAN to cluster the pixels for the paths and intersections of regressions over the path.
The trick is to dilate the paths such that I can de-noise since only highly connected clusters can be paths.
The least squares term in the regression ensures that it should follow the trend of the path very well.
This collection of constants is what I am using currently:
I end up with this as the output:
8 rooms and 3 on non-start floor.
That looks crazy, nice job. I was going to try something different:
locate the rooms first in order to get the number of rooms per "column"
(ignore the first room, I'll use the client.txt log-file to get the correct arrangement)
in each column, start from the "outside" (i.e. top/bottom room) and work towards the center
count the exits. since you know the room number/arrangement in the next column, you'll automatically know how the outer-most rooms connect without having to actually trace the pathing
the closer you get to the center, the more likely it is that pathing becomes apparent by process of elimination (since paths can't cross)
if counting exits is ambiguous, do actual tracing
I didn't have time to actually test step 2, but it sounds doable in theory (to me at least). If I have some time, I'll do the testing tomorrow.
I actually got it to work. It spits out a JSON-string, representing columns and the contained rooms. For each room, it lists x and y-coordinates for the overlay I'm going to implement, as well as entrances and exits (all this might change depending on how well the overlay works and whether I need anything else).
I changed my plan and took inspiration from slime molds (of all things):
let it detect rooms first, set the boundaries
pixel-check the pathing and "lay bread crumbs" for each positive check
trace the crumbs and find out where the trail started and ended (i.e. which boundaries the trail is touching)
Out of curiosity, how fast is your implementation? Mine takes about 4 seconds at 1440p (img-snippet is 1152x800), which has to be done once at the beginning of the floor. The data then remains in memory and feeds into the overlay.
Mine does 1 second at 3440x1440, but it runs in Scala. It is probably significantly faster than AHK because of the runtime.
I have a bunch of optimizations I can do, so I think I can get it down to less than 200 ms, since my clustering currently is very naive ($$O(n^2)$$).
I think the algorithms for path clustering we use are equivalent (slime mold discovery and DBSCAN with optimizations).
If the tracing is what takes long you can consider doing a (simple) linear regression after the first bunch of pixels since that should point to the room in the same direction.
$$\hat{\alpha} = \bar{y} - (\hat{\beta} \bar{x})$$
$$\hat{\beta} = \frac{\sum_{i=1}^{n}(x_i - \bar{x})(yi - \bar{y})}{\sum{i=1}^{n}(x_i - \bar{x})^2}$$
$$\textit{room} = \textit{min}_{r \in R_x} \hat{\alpha} + \hat{\beta} x$$
The paths can overlap with the rooms, so you have to account for that. An early linear regression avoids this issue since it only needs to be confident in the direction to terminate. Here is an example:
Thanks a lot for your inputs and your worst-case example, much appreciated. I have to admit that stuff goes waaaay over my head. As for the example: I managed to use your screenshot for calibration and testing, and my prototype connected that busy area in the center correctly.
I had already implemented some leeway to make it "jump" to distant markers. I just need to tweak it so that the leeway is smaller on the x-axis in order to prevent the tracing from jumping onto a different path altogether. The top-most path to room 5_2 almost connected to the one underneath towards the end because the corner occluded so many pixels. (I just realized that it wouldn't make a difference in this specific situation since both paths lead to the same room.)
I tried making it faster by means of "sparseness" (i.e. only scanning every nth line) but refrained from it for the sake of accuracy/consistency. I can still trim the areas that are scanned because they still have rather large buffer zones, but that's something for later stages.
I got some initial UI/UX testing done today and could need some feedback (colors, transparency levels, and other stylistic considerations are all subject to change):
I decided to activate the sanctum overlay by briefly holding TAB, similar to some widgets (notepad sticky-notes, alarm, main toolbar), and it will hide again if you let go
it will only activate while you're in sanctum-related content
you can tap space to "lock" it so it won't disappear when letting go of TAB (you'd use this when entering and scanning a new floor)
once the map has been scanned, semi-transparent rectangles will be overlaid on top of each accessible room:
the number-values represent how many rooms are accessible from a given room
my initial plan was: whenever you hover over a room, only those subsequent rooms which are accessible will be shown and the rest would be hidden, but that caused too much flashing and became annoying
you can left-click a "desired" room to highlight it green, and the overlay will highlight the path(s) that lead to it, so you don't accidentally miss it:
you can right-click an "undesired" room to highlight it purple, and the overlay will highlight rooms you mustn't enter, otherwise you'll be funneled into that specific room (the map in the screenshot doesn't really have a good example):
EDIT: you can also place both colored markers at the same time
Hey. Thats pretty cool!
Do you think it could be a good addition to not count rooms that had been banned (purple)? Does the path to node feature exclude banned rooms?
The "show path to node" seems very useful for reveal type strategies.
I think I personally would like the reachability paths of a room drawn, since this is probably the most universally useful thing. You usually always want to take the path that allows you to see as many rooms as possible, but sometimes the "best" path is blocked by a bad affliction, or maybe a good room is on an non-optimal path.
For optimal route planning (given you have the full room revealed), you'd probably want to with a something like a weighted sum. For example:
coins = 0.7
shop = 1.5
shrine = 0
pact = 0.9
Now there are numerous ways to compute this weighted sum, it could be forall rooms, compute the sum of the room types multiplied with the weight, say for coins -> coins -> shop -> shrine:
(coins + coins + shop + shrine)/4 = (0.7 + 0.7 + 1.5 + 0)/4 = 0.725
But there are also other considerations, such as, do I have enough coins for the shop and so on. It gets pretty gnarly and user-specific.
Room types don't matter for most players after the first couple of sanctums.
In this picture I take blue path since it has same room number as green (R: 12), because it has a tainted pact (the hands) since those can contain divines on floor 4. My point is that selecting the best route for every circumstance is a huge undertaking so making it easier for the user to plan the path might be the best for version 1 of the tool; give the tools and numbers for planning, but not necessarily do the plan.
Do you think it could be a good addition to not count rooms that had been banned (purple)? Does the path to node feature exclude banned rooms?
Yes that makes sense, good idea. Counting the connecting rooms was the last thing I implemented yesterday, so it doesn't interact with anything else yet. For simple testing, both markers and their paths use the same logic (with purple taking precedence), so purple paths simply overlap a green path. But it'll be easy to make a purple path completely cut it off instead, which would be the next step.
I think I personally would like the reachability paths of a room drawn, since this is probably the most universally useful thing. You usually always want to take the path that allows you to see as many rooms as possible, but sometimes the "best" path is blocked by a bad affliction, or maybe a good room is on an non-optimal path.
Drawing the paths has a nice ring to it, but I'd have to figure out how to do that efficiently in AHK (probably draw a transparent bitmap and overlay that) and it would also probably become quite "busy" on lower resolutions (I have to keep everything resolution agnostic). I therefore chose the number-tags as a possible alternative.
I photo "chopped" your screenshot to show what I currently have in mind, what it would look like, and how it could be used:
I personally would check for bad/brick afflictions first: let's pretend the room above the pact has deceptive mirror, so I'm going to ban it
then I'd look for anything special: since I now know that tainted pact is potentially good, I'll mark it green
looking at the overlay, I gain the following insights:
I can safely reach my desired room without running into banned ones
my desired room has the potential of 6 accessible rooms
the alternative path ends in 6 accessible rooms as well, so I don't lose out in that regard
I now have to weigh which is more beneficial: the pact room or the benevolent and radiant fountains right ahead
the overlay is built around being adaptable on-the-fly, so you can (re-)plan your moves with every room you advance (since you only have to scan once, at the start of the floor)
A few small updates:
you can now ban multiple rooms (the banned rooms themselves have a thin white border, the connected rooms you have to avoid don't)
rooms that become inaccessible due to banning are highlighted black
room-count now adapts to banned/inaccessible rooms
There's light at the end of the tunnel. If I find enough time tomorrow, I might be able to release an initial testing version. I have added another little option to manipulate the overlay: you can middle-click rooms to mark the room you're currently in, and the overlay will cull unnecessary information:
https://github.com/user-attachments/assets/2c3d63ed-96ae-4cfe-93db-15d79454e5ac
It's primarily for readabilitity / easier parsing / glance-value when transitioning between rooms:
look at map, pull up overlay
pick next room & middle-click it
clear room
look at map, pull up overlay, and it only shows rooms that are still relevant/accessible
You can also hold middle-click and hover back and forth between multiple rooms to show and compare their respective reachability paths. I'm still hesistant to implement the full reachability tree, so I guess this could be another possible alternative to that.
At this point I would ask "is there anything else you'd want it to do?", but you've shown that you actually already have access to more elaborate techniques and possibilities. So instead: "Is there anything else I could implement that's useful to the average Sanctum runner?"
I think the features for an initial version are there. More elaborate or specific features will probably become apparent from "daily" usage of the tool; adding too many features to the initial version might be an instance of premature (feature) optimization.
v1.55.0 is now live. I had to delay it for a day because there were some unforeseen issues at lower resolutions that needed some ironing out.
I had to go into more detail than usual in the release notes because this feature can only perform well if the user sets it up correctly, which I feel is almost never the case.
You can give it a whirl if you like.
v1.55.0 is now live. I had to delay it for a day because there were some unforeseen issues at lower resolutions that needed some ironing out.
I had to go into more detail than usual in the release notes because this feature can only perform well if the user sets it up correctly, which I feel is almost never the case.
You can give it a whirl if you like.
Been trying to calibrate as best as I could but it still fails the scan on last row of rooms:
@knot2006 The issue is the icon of dark pact rooms. During calibration, you must have caught some pixel-colors that are also present in that icon:
The teal cross signals that the tool recognized a "loose end" there and cannot complete this specific path. You have to reset the pathing calibration by long-right-clicking the calibrate paths
button, then redo it.
It would be nice if the tool could show the room reachability for any room. It takes a half minute or so to plan out the optimal path when having All Seeing Eye.
For every next room, a room reachability tree could be drawn with distinct colors. I suppose on hover could also be a implemented, but from my observations it seems that the hover effect ingame might overlay some of the sanctum map in a way that makes image analysis hard.
Furthermore, counting the number of unknown rooms for a given reachability tree would also be a very nice feature.