How the map labels are classifiedReport

English：How the map labels are classified　·　Other

The rules behind the icons, label sizes and filter chips on the 259 map locations. One shape cannot answer three questions, so shape says only what the game itself draws, colour says how the locals see you, and what you can resupply gets a layer of its own.

# How the map labels are classified

The map on the front page carries 259 locations, and each one has three things attached to it: an icon, a name label, and a category. This page is about how those three were decided, and about the times I overruled myself.

There is a page here at all because classification got one genuinely sharp question put to it, and my first answer was wrong.

It started as a complaint

The village/town classification looks off, and Flotsam Village's own icon isn't that either. Do we even need a separate "village" category?

Flotsam Village has village in its name, this site filed it under Town, and the marker the game draws on the world map is neither. Three sources, three answers.

What I did at the time was add a "Village" category and file it there, but that was only treating the symptom.

The test is user purpose

What turned the direction around was this:

I'm curious, from a user-purpose point of view, is the classification right now? … Too many categories is meaningless fragmentation, too few and it all blurs together.

Those two words, fragmentation and blurring, fix the scoring rule. A classification is there to let someone make a decision at a glance on the map, not to describe the world. So the question to ask about a classification is "if you see this shape, will you do the right next thing", not "is it faithful to the name".

So the first thing I did was list what each category actually provides in-game, and check whether the categories line up with the functions. Function is measured by the kinds of vendor present in a settlement: bar and lodging, general store, weapons and armour, food, skeleton limbs. Five of them.

The game has its own classification, and it is better than ours

Then came the line that went straight through the methodological flaw in my table:

I remember cities and towns being different in-game, there's a really big ICON, the kind where you can tell at a glance there are a lot of shops inside.

Half of that is right, and the half that is right is more useful than my classification was.

Kenshi's UI resources contain an imageset called Kenshi_MapMarkers, and the game draws only eight markers on the world map: Town, Village, Outpost, Camp, Workcamp, SmallPlace, Ruin, Nest. Town's sprite is 105×79, the largest of the set, which is the big ICON that means a lot of shops inside.

Matching all 259 locations against the official map one by one gives this function profile:

Both ends are absurdly clean. A Town nearly always sells something and a Ruin nearly always sells nothing, and the single exception among 113 Ruins is Free Settlement, a living settlement built inside a ruin. SmallPlace is a clear case of small and empty.

But one part of that memory needs correcting: the big ICON does not separate city from town. All 17 of this site's Cities are Town, and so are 9 of its 24 Towns. The city and town line is the wiki's, and the game does not draw it.

Our categories do not line up with the official markers

The same 259 locations, cross-tabulated:

Only two categories are clean: City, where all 17 are Town, and Ancient site, where 83 of 85 are Ruin. The worst are Town, with 24 spread across four official markers, and Outpost, with 58 spread across five.

Neither side is wrong about this. The wiki categories say what a place is in the world, the game's markers say what scale it is on the map, and those were never the same axis. Forcing one shape to carry both produces what we have, where every cell is mixed.

The decision: three channels

Looking at a dot on the map, a player wants three things:

1. What kind of place is this, in scale and character?
2. Will the people here attack me?
3. What can I resupply here?

I tried compressing all three into one shape, and had four competing proposals score each other. The verdict was consistent, which is that they do not compress. Every version sacrifices one of the other two, and the sacrificed one is usually the dangerous one, since a "well-stocked" icon that does not tell you the city sits in hostile territory sends a new player straight to prison.

So it splits into three orthogonal channels:

The third channel is the newest, and it came from this:

it has to become a vector the system can compute with and actually use

That line also broke the classification deadlock. Whether you can resupply somewhere was never the shape's job, because it is a quantity that moves as data fills in, while a shape has to stay stable or every rebuild breaks the spatial memory a reader has built for that shape over there. Pulled out into its own layer, the shape can go back to what it is good at, which is copying the game.

All seven of this site's categories stay (City, Town, Outpost, Village, Camp, Ruin, Ancient site), on articles and on the filter chips. They are useful text labels, they just no longer carry the burden of showing capability at a glance.

Label size is part of the classification too

Could the place-name labels have slightly different sizes, but uniform within each category?

"Uniform within each category" is the important half, because it turns type size from decoration into a second classification channel. The current steps:

Three self-imposed constraints:

• Only upward, never downward. The smallest step stays at the original 46, so no place name is smaller than it was before. Important places stand out by growing, not by shrinking everyone else.
• Keep the range under 1.30×, so the map does not read as randomly jumping sizes.
• Same category, same size, always. Size is a function of category, not decoration on an individual place.

Classification only helps if the position is right

However good the categories are, an icon in the wrong place is wasted. The requirement here was blunt:

Can you first make them line up exactly and be exactly the same size?

The original coordinates were read off the name text, and the marker is drawn about 39 px above it, so every icon sat noticeably low. The fix was to measure the true marker centre point by point with FFT normalized cross-correlation, and to size icons from the sprite's native dimensions. The median residual is now 0 px, with 86% vertical and 97% horizontal inside ±3 px.

And once, this:

The X and Z being almost identical is implausible, can you filter for that case and adversarially verify whether they really do overlap?

That found 5 overlapping marker pairs, three of them 0.0 px apart, which is literally the same point. The cause was cross-correlation claiming one marker for two adjacent locations. Switching to one-to-one assignment, where each marker can be claimed by exactly one location, took it to zero, and a build-time check now fails loudly on any duplicate coordinate so it cannot creep back quietly.

How I guard against my own hallucinations

a place name plus three languages, four columns, so there's no hallucination

The trilingual place-name table exists for that sentence, and it is generated rather than written. All four columns (English original, Traditional Chinese, Japanese, region) are pulled straight out of the map build, and any mismatch fails the build. The check runs both ways, scanning the Chinese and Japanese columns for leftover Latin and the English column for stray CJK. Checking only one direction is a mistake I have made, since an earlier version scanned zh and ja but never en, and 95 Chinese place names sat on the English map undetected.

The other line is an inclusion rule:

it only qualifies if it's real in-game data, or something players are bound to misread from the wording, not if it's a bug in your own code

That line is drawn on the misread-mechanics page, but it governs the whole site: our bugs are not Kenshi's traps. Writing our own mistakes up as "the game is cruel here" makes readers defend against something that does not exist.

Known gaps

• 100 of the 259 locations have no article yet. 94 of them are numbered series (Hive Village #2–#8, Ravaged Hamlet #2–#9 and so on), and only six are genuine orphans: Holy Mine, Infested Lab, Red Sabre Hideout, Reprogramming Workshop, Ruined Tower, Swamped Lab.
• Vendor data covers only 163 locations, and the other 96 map points have no shop data at all. "None" in the function table above means verified zero, and excludes those 96 unchecked ones. The two must never be reported as one number.
• The loot index covers only 80 place names. Of 113 Ruin markers, 35 have a loot record and the remaining 78 have no record, which is not the same as having nothing. That is why I did not adopt the proposal to hide ruins without loot by default, since it would bury 78 points, and once buried nobody fills in their data, so the error reinforces itself.
• Ruin and Ancient site are hidden by default, which is 116 points, purely to cut visual noise. I know it is a trade, because it also hides 36 places with known loot.
• The eighth official marker, Nest, is unused here. If nest-type locations are ever added, the shape channel needs one more slot.

See also

• Commonly misread game mechanics (the section on markers not matching place names)
• LogoCat (site creator) (the judgement rules for compiled articles)
• All Locations — Trilingual Index (the four-column table for all 259 names)
• Sources and Licensing
• Disclaimer and Lore Reliability