Explorer Cards lets you turn EF-Map's extended hover label into a map layer, so a whole constellation of EVE Frontier systems can show their details at once. Instead of hovering one star, reading its card, then hovering the next, you switch the layer on and the info cards appear next to the stars, tracking them as you pan, rotate, and zoom. It is a power-user layer, off by default, that you dial in to exactly the density and detail you want.
The interesting part is not the feature itself. It is how it came from connecting an old, shelved technical experiment to a real workflow a player was already doing by hand. This is the honest version of how that happened, including the parts that only got good after a lot of tuning.
The player workflow that triggered it
A player named Breitius Maximus shared a screenshot that made the whole thing obvious. He had gone through a cluster of systems one at a time, hovered each star long enough to bring up EF-Map's extended hover card, captured each card, and pasted them next to their systems in an image. The result was a hand-built comparison sheet: several stars, side by side, with their orbital zones and system details laid out so he could compare them at a glance.
That is a lot of manual work, and it is exactly the kind of thing that tells you a feature is missing. When a player is willing to screenshot and paste a dozen cards by hand, they are not doing it for fun. They are working around a gap. The information they wanted was already in EF-Map. It just could not be shown for more than one system at a time.
From one hover card to many cards
EF-Map has had an extended hover card for a while. Rest the pointer on a star for a moment and a compact card expands with the things that matter for exploration: star type and temperature, a planet-type breakdown, the outermost orbit, external temperature, the region, and the color-coded orbital zones. That card draws on the same detailed system data we wrote about in what EF-Map knows about EVE Frontier solar systems.
Once you see Breitius's screenshot, the question writes itself: why can that card only exist for one star at a time? If the data and the styling already exist for a single hover, showing the same thing for a scoped set of systems is a presentation problem, not a data problem.
There was also some history here. Earlier in EF-Map's development we had looked into scene-anchored labels for region names, the idea being that a label would sit in the 3D scene and move with the camera. At the time that region-label use case felt too niche to justify the work, so it was shelved. Breitius's workflow is what made that shelved capability worth building, because now there was a concrete job for it to do. The old technical idea and the real player need finally lined up.
Why CSS2D labels fit this problem
EF-Map's star map is built with Three.js, a WebGL 3D engine. Almost everything you see, the stars, the connections, the backdrop, is drawn on a WebGL canvas. Text is the awkward exception. Crisp, readable labels are something the browser is already very good at with plain HTML and CSS, and reinventing that inside WebGL is a lot of effort for a worse result.
Three.js ships a helper for exactly this called the CSS2DRenderer, and its companion object type, the CSS2DObject. In plain terms: a CSS2DObject ties an ordinary HTML element to a point in 3D space, and the CSS2DRenderer takes care of positioning that element on screen wherever that 3D point currently projects to. The label is real HTML and CSS, so it gets the browser's crisp text rendering, but it behaves like it lives in the scene. As the camera moves, the card stays pinned to its star.
That is a good fit for Explorer Cards for a few reasons. Because the cards are HTML, they reuse the exact markup and styling the extended hover card already uses, down to the orbital-zone colors, so a card in the layer looks like the card you get from hovering. We pulled the card-building logic into a single shared piece so the hover card and Explorer Cards cannot drift apart. The renderer also sorts labels by distance to the camera, so a nearer system's card naturally stacks above a farther one, and cards can fade with distance so the far edge of a cluster recedes instead of fighting for attention. The map's sense of depth, which we tuned in the parallax backdrop work, carries through to the labels.
The trade-off is honest: HTML labels are heavier than points in a buffer, so you cannot put one on all 24,500 systems at once and expect the map to stay smooth. That constraint shaped the whole design. Explorer Cards only ever considers systems that are actually on screen, and you set a ceiling on how many cards appear. The layer is meant to be scoped and dialed in, not switched on across the entire galaxy.
The polish that made it usable
The first working version came together fast. That is the misleading part. A layer that renders a pile of cards on the map is a starting point, not a finished feature, and it took a series of small, deliberate decisions before it stopped feeling like a demo and started feeling like a tool. This is the same audit-and-iterate loop we described in the AI workflow behind EF-Map: the code came together quickly with AI assistance, and then a human review-and-tune loop did the work of making it good.
The decisions that mattered:
What turned a demo into a feature
- Off by default. This is a power-user layer. Turning it on for everyone would clutter the map for people who never asked for it, so it stays off until you open the panel and enable it.
- Current constellation as the default scope. When you do turn it on, a constellation is the right amount of the map to describe at once for real exploration work. Not one system, not the whole region.
- Scope follows the selected star. If you have a system selected, current constellation and current region mean that star's constellation and region. That matches what you expect. If nothing is selected, the layer follows wherever the camera is looking.
- The selected system's small label yields to its card. When a system already has an Explorer Card, showing its little name label on top of it too was just visual noise. The card takes over, the way the extended hover card already does.
- Fewer controls, not more. An early build had a toggle for interaction hints on the cards. On a reference layer that was clutter, so it came out. Explorer Cards are for reading, not for teaching you the controls.
- Readable card widths. Compact cards needed a minimum width so a card showing only orbital zones did not collapse into a tall, thin sliver. Small thing, big difference in whether a screen full of cards reads cleanly.
None of these are clever. They are the difference between a feature that technically works and one that feels right, and the only way to find them was to build the thing, look at it honestly, and keep adjusting.
User control and performance boundaries
A core part of EF-Map's design approach is that the person using the map decides how busy it gets. Explorer Cards leans hard on that. Rather than pick one "correct" density and hide the rest, the layer gives you the controls and sensible defaults, then gets out of the way.
You can choose the scope (systems in view, the current constellation, or the current region), the card size (full, compact, or ultra compact), and a maximum number of cards. You can fade distant cards, reduce overlap between them, and pick which pieces of information each card shows, from just the essentials up to the full breakdown. If you want a dense wall of detail for a serious comparison session, you can have it. If you want a light scatter of names and zones while you fly, you can have that instead.
The boundaries are built in rather than bolted on. Only systems on screen are ever candidates for a card, the total is capped by your maximum, and closer systems win the limited slots. That keeps the layer from turning the map into an unreadable mess, and it keeps a scoped view from quietly trying to label the entire galaxy. We are deliberately not going to quote a magic number of cards here, because the honest answer is that it depends on your machine and your settings. The point is that you hold the dial.
Why this matters beyond orbital zones
Orbital zones were the workflow that triggered Explorer Cards, but the layer is not really about orbital zones. It is a general way to hang per-system information in the scene and have it track the map. The card content is just the extended hover card today; the same rails could carry other kinds of per-system readouts in the future without rebuilding the labeling machinery.
That is the quiet win. The shelved region-label experiment was a technique looking for a job. Explorer Cards gave it one, and in doing so it turned scene-anchored labels into a reusable pattern that EF-Map can reach for the next time a map overlay needs to say something about a lot of systems at once. It sits alongside the other exploration tooling, like the System Finder and Name Visualizer, as another way to read the EVE Frontier map at the scale you actually work at.
Closing note, and credit where it is due
Explorer Cards exists because a player did something tedious by hand and showed us the result. Breitius Maximus did not file a feature request. He built the comparison sheet he needed with screenshots and a paste tool, and that was a clearer specification than any request could have been. Our job was mostly to recognize the workaround for what it was and to connect it to a capability we had already half-built and set aside.
If you fly in EVE Frontier, open EF-Map, find Explorer Cards under Tools Library in the Map Visuals group, select a system, and turn the layer on for its constellation. Then tell us what is missing. The best features here tend to start as something a player was already doing the hard way.