FinderScope
- 5 Devlogs
- 39 Total hours
A constellation identification game.
A constellation identification game.
not sure if it’ll show but it was 10hrs of stuff then 4 HOURS OF BUGFIXING AND TRIAL AND ERROR GAHHHH
ok heres what i did
localStorage.if you get one wrong, the streak’s gone, no mercy at ALL. also made it so a correct guess auto-advances to a new round after 2 seconds instead of just sitting there waiting for you to click new round like some kind of caveman.
THE BIG ONE
so quiz mode and learn mode were both using this rough relative distance method to figure out neighbours, which is fine until you realise it’s not actually how constellations work. constellations aren’t just the shape with lines and dots lol, they’re officially bounded regions of sky (yes, actually, the IAU drew borders around all 88 of them in 1930).
so I went and found the real boundary data and pulled it from d3-celestial, same open source star chart project I got the line/star data from originally. every constellation now has its actual official border drawn around them so when you’re learning you know what parts are actually part of it (trust me, this helps when you’re learning)
but other than that, wth did this even do?
BTW I genuinely thought the octans clutter thing from ages ago was a bug, but the south pole is just actually that crowded with tiny constellations. I think you can tell I prefer the north.
also had a scary moment where NOTHING was rendering and learn mode wouldn’t even switch, I thought I’d broken something major, but turned out to just be a memory issue from having so much boundary data loaded so I restarted vscode and it sorted itself out 💀
what’s next
changing some of the names and shapes, I need to find out which ones are actually used widely cause some in the dataset I use are super weird (peep the video!)
the duplicate constellation entry (serpens has two parts sharing one id, still not dealt with)
I really really really want to add a speedrun mode!!
ok so essentially what has happened in the last day is:
styling wise, rather than defaulting to a generic dark mode, the canvas is framed like a viewfinder. I just thought it would look nice tbh, there’s not much else going on there other than the stars.
I kept the blues that I already used in the canvas itself (#5a8dee for target, #2e3d5c for neighbours) and just extended them into the actual UI instead of picking a new palette.
the fonts are basically the same as the rest of my projects but icl i might change that
when I was first making the learn mode today, I gave it the northern/southern/all split, quiz mode didn’t, so pickRandomConstellation now pulls from whatever hemisphere’s selected instead of the full 89. changing it mid-quiz rerolls immediately rather than waiting for the next round too.
I also added a show ans button for testing cause even I don’t know them all lmao (only the northern ones so far, and like 3 southern!) so will probably remove this later
additionally, I also kept testing and editing parameters for the projection to make it as smooth as possible.
what. a. day.
and yes im tired as hell its nearly midnight i’m off to bed
accidentally sank 6 hours into this one but it’s the session that where you feel like looking through something instead of staring at a flat projection 
turns out this was already sorted from v1, the x-axis flip that was in there from the start so I didn’t have to touch the projection maths, just double checked that north stays up on canvas and left it alone.
the real work was making that hold up once the camera can move anywhere, not just the handful of fixed constellation centres it used to snap to.
the camera is now a proper mutable cameraRA/cameraDec instead of being locked to target.center. dragging works out a small angular delta per mousemove event using a small-angle approximation (fine since consecutive drag events are tiny steps, not one big jump), and shifts the camera opposite in ra and dec so the sky moves with your cursor like a map, not like a first-person look-around.
findInView had to change too since “who’s a neighbour” used to be based on the target’s fixed centre, now it’s based on wherever the camera’s actually pointing.
clamped cameraDec to ±89.5° so dragging into a pole doesn’t divide by zero and send the camera into deep space 💀
added touch support alongside mouse since drag is the kind of interaction that should just work on mobile too.
I wanted the zoom to actually feel like looking through a scope rather than a bounding-box crop, so this session was about two things: a fixed camera FOV, and pulling in neighbouring constellations so there’s context around whatever you’re meant to be naming.
v1 fit the canvas to the target constellation’s own bounding box, which meant every constellation filled the frame regardless of its real size on the sky. Crux and hydra looked the same scale, which defeats the point of a “how much can you see” difficulty system.
So, I fixed it by switching to a constant angular field of view instead. stereographic projection has a neat closed-form relationship between angular separation from centre and projected radius: rho = 2 * tan(theta / 2). so i just pick a FOV in degrees, work out what radius that maps to, and scale the canvas to that instead of to the data.
for each constellation, check every vertex’s angular separation from the target’s centre (reused the same cosc term from the projection maths, just wrapped in acos instead). anything with at least one vertex inside a 55° radius gets pulled in and drawn dim, target stays bright and thicker so there’s no ambiguity about what to actually guess.
I tested both of these in node before touching canvas, specifically against Oct and UMi since anything near the celestial poles is where stereographic maths tends to fall apart.
octans pulls in 37 neighbours at the current radius because it’s so close to the pole. Everything nearby just looks angularly closer than it would elsewhere on the sky. That’s fine for now, but medium/hard difficulty will look like a mess down there unless i either shrink the include radius near the poles specifically or cap how many neighbours actually get drawn.
Firstly - yes, I have 6 hours on this, because I switched ideas midway (so essentially 2 hours of work gone lol)
i was mid-attempt at memorising all 88 constellations using some app, got through easy mode fine, then hit a paywall the second i wanted the other two difficulties. so, obviously, I’m building my own cause nobody should have to pay for something as simple as this.
the idea is a constellation naming quiz. it zooms into a random constellation somewhere in the sky, you guess what it’s called, and there’s three difficulties depending on how many of the surrounding constellation lines you get to see (all of them, just the neighbours, or none). eventually there’ll be a learn mode too that splits northern/southern sky and gives you the actual mythology name alongside the IAU one.
started with v1 today: just getting one constellation to render and project correctly, no game logic yet.
turns out there’s no NASA-style API for “here’s every constellation’s star positions and line segments,” so i pulled from d3-celestial, an open source star chart project on github. grabbed:
constellations.lines.json — RA/dec coordinates for every line segment in all 88 constellationsconstellations.json — names, including an en field with the actual mythology name (canis major → “great dog”, that kind of thing)wrote a python script to slim both down into one dataset per constellation: id, name, en, a precomputed centre point, and the line coordinates. centre point was its own small problem — you can’t just average RA values because of the 0°/360° wraparound, so i averaged everything as unit vectors on the sphere instead and converted back. way cleaner.
the actual hard part. “zoom into a random constellation” means taking a patch of sky centred wherever that constellation sits and flattening it onto a canvas. went with a stereographic projection, standard formula, centred on each constellation’s precomputed centre.
tested the maths in node before touching canvas at all — ran orion through it and checked the projected bounds didn’t blow up or do anything weird near the pole. glad i did that first, would’ve been a nightmare to debug visually.
canvas side just auto-fits whatever bounding box comes out of the projection, so it works whether the constellation is tiny (like crux) or sprawling.
some of the constellation names/lines from the dataset are a little wrong — going to go through and fix those manually rather than trying to patch it in code.