ARC Raiders asks players to make expensive decisions quickly. A raider heading topside may need to know whether an item is worth the inventory slot, which machine drops a missing component, what map condition is live, how a quest chain unlocks, or which materials are still needed for the next workshop tier. The answer often spans several systems, and the cost of getting it wrong can be an entire run.
That decision pressure became the starting point for Raiderism, a live ARC Raiders database and field companion. We built it to connect items, weapons, ARC machines, quests, traders, crafting, maps, events, builds, progression tools, guides, and current coverage in one searchable product.
The challenge was not simply publishing another game wiki. Raiderism needed to combine stable reference data, personal progress, and live-service information without blurring the difference between them. It also needed to be fast enough for a second-screen lookup and structured enough for deeper planning between raids.
Items, machines, quests, recipes, skills, blueprints, sources, and visible dataset versions.
Map-condition timers, 24-hour rotations, limited events, Trials, and current updates.
Loot links to machines, recipes, workshop tiers, quests, traders, maps, and guides.
Quest progress, blueprints, workshop plans, haul lists, builds, and a Raider record.
The problem: extraction decisions cross several systems
An extraction game turns ordinary database facts into tradeoffs. Weight competes with value. A rare component may be useful for a recipe, a workshop upgrade, a quest hand-in, or none of those things. An ARC machine is not only an enemy entry; it is a set of weak points, behaviors, map sightings, and possible salvage. A map is not only an image; its value changes with hourly conditions and limited events.
Publishing those facts as isolated pages would force players to assemble the answer themselves. A list of items cannot explain what to keep. A countdown cannot explain why the active condition matters. A quest list cannot show what becomes available next.
We designed Raiderism around a connected question: what does the player need to know or do next?
| Surface | Immediate question | Context Raiderism connects |
|---|---|---|
| Item catalogue | Should I keep this? | Weight, value, value per slot, recipes, sources, and upgrades |
| ARC dossiers | How do I fight it? | Weak points, behavior, sighted maps, salvage, and conditions |
| Contract board | What unlocks next? | Prerequisites, handlers, objectives, hand-ins, and haul needs |
| Event timers | Where should I deploy? | Current conditions, local time, next rotation, and map details |
| Planning tools | What should I prepare? | Skills, loadout weight, workshop costs, blueprints, and needed items |
A database built as a relationship graph
The foundation is the ARC Raiders item catalogue. At the time of this case study, it contains 229 catalogued entries across weapons, ammunition, healing, gadgets, shields, backpacks, augments, modifications, materials, keys, trinkets, and other categories.
The catalogue supports name search, category and rarity filters, a detailed-data filter, and sortable columns for weight, value, and value per inventory slot. That last measure matters in an extraction game: the most expensive object is not necessarily the most efficient thing to carry.
More important, the table is only the entry point. An item record can connect to:
- Crafting inputs and outputs
- ARC machines that can be salvaged for it
- Recipes that consume it
- Workshop tiers that require it
- Quest hand-ins
- Traders, blueprints, and related guides
For example, the ARC Circuitry record explains its weight, value, stack size, crafting path, salvage sources, recipe uses, and workshop requirements. A player can move directly from the component to the Queen or Rocketeer that drops it, then into the machine dossier, relevant maps, and broader field guidance.
That is the core information-architecture decision behind Raiderism: records are modeled as part of a graph, not filed as independent encyclopedia entries.
Machine dossiers designed for the fight itself
The ARC machine database covers the hostile machines players encounter on the surface. Each dossier is built around the decisions that matter during a fight: armor, verified weak points, observed behavior, known map sightings, salvage, and the reliability of the available evidence.
The Queen field dossier, for example, connects its Harvester condition and known maps with target locations, attack patterns, and a linked salvage manifest. When a value such as health or a damage multiplier is not documented reliably, Raiderism does not manufacture precision. It explains the gap.
That restraint is part of the product. A confident-looking number can be worse than an honest unknown when a player is planning around it. Raiderism distinguishes verified locations, documented behavior, estimates, and unavailable values so readers can judge the evidence rather than trusting a polished card blindly.
Turning quest chains into a progress system
ARC Raiders contracts are dependencies, not a flat checklist. Raiderism’s contract board organizes quests by handler and chain depth, beginning with the shared opening contract and branching into later assignments.
Players can mark a contract complete directly in the dependency survey. Progress is stored on the device, newly available contracts become visible, and completed hand-ins fall away from the aggregated haul list. Individual dossiers retain objectives, prerequisites, rewards, required items, and connections to the responsible trader.
This makes the quest database useful in two modes:
- Research mode: inspect a contract, its objectives, and its place in the chain.
- Progress mode: record what is complete and let the rest of the planning system update around it.
The same pattern extends to workshop tiers and blueprints. The database explains the system; the tools remember the player’s state.
Live map conditions in the player’s own timezone
Static maps are useful for landmarks and routes, but ARC Raiders changes the value and danger of a deployment through rotating conditions. Night Raid, Harvester, Matriarch, Hurricane, Hidden Bunker, Uncovered Caches, and other conditions can alter visibility, loot, enemies, or access.
The ARC Raiders event timers show what is live across Dam, Buried City, Spaceport, Blue Gate, Stella Montis, and Riven Tides. They also show what comes next and translate the official rotation into the player’s local timezone.
A 24-hour schedule lets players compare maps without opening six separate pages. Condition explanations sit beside the schedule, while each entry links into the relevant survey map. The product moves naturally from when to deploy, to where, to what the condition changes.
This was a distinct technical problem from publishing evergreen database records. Timers require trusted schedule data, timezone conversion, clear live/upcoming states, and interfaces that continue to make sense when a map has no special condition active.
Separating rotations, limited events, and Trials
Not every live-service surface runs on the same clock. Raiderism keeps three ideas separate:
- Map conditions rotate hourly and affect a specific deployment area.
- Limited events have opening and closing dates, rewards, phases, and event-specific requirements.
- Trials operate as a weekly challenge and ranked progression system.
The events archive gives one-off and recurring events full briefing pages with dates, objectives, requirements, practical field notes, source links, and related news. The Trials section explains scoring, thresholds, ranks, resets, and the current season without forcing that information into the event-timer model.
Preserving those different cadences makes every page easier to understand and gives search engines a focused, stable destination for each intent.
Tools that turn reference data into a field kit
The Raiderism tools collection closes the loop between research and preparation. Some tools encode a plan into a shareable URL; others save progress locally on the device, with no account required.
The skill builder enforces prerequisites and branch gates while keeping the result shareable. The loadout builder rolls up equipment weight and ammunition. The workshop planner calculates cumulative material costs across station tiers. The blueprint tracker stores unlocked plans locally. The needed-items tool combines outstanding workshop, quest, and blueprint requirements into one shopping list.
Together, these surfaces turn the same source data into different decision views. Players do not have to re-enter a material requirement in several calculators because the underlying records already know how the systems relate.
A local-first Raider record
Many game companions require an account before they provide personal value. Raiderism takes a lighter approach for progression features. Quest completion, workshop tiers, and blueprints can be stored locally, then summarized in a personal Raider profile.
This reduces friction and avoids collecting credentials for a task that does not need them. It also keeps the architecture honest: public facts remain server-rendered and indexable, while personal state stays on the player’s device.
Shareable tools use URLs where collaboration matters. Persistent trackers use local storage where privacy and speed matter. Choosing the state model per workflow is more useful than forcing every feature into one account system.
Current coverage connected to evergreen records
ARC Raiders changes with patches, seasons, expeditions, store updates, crossovers, Trials, and community discoveries. Raiderism combines its reference database with current ARC Raiders news, practical field guides, official videos, and a creator intelligence feed.
Those layers are deliberately connected. A patch note can lead to the machine, item, event, or tool it affects. An ARC dossier can lead to a weak-points guide. A live event can link to its announcement and primary sources. The homepage acts as a current operations board while the underlying database remains useful between updates.
This creates a healthier content model than treating news and reference pages as separate websites. Timely coverage earns attention now; structured records continue answering questions after the headline has passed.
Trust through versioning, sourcing, and honest gaps
Game databases often create a false sense of certainty. Old numbers remain visible after a patch, copied values lose their original source, and blank fields are quietly replaced with guesses.
Raiderism exposes the game version and dataset version throughout the product. Record pages link to their sources. The homepage shows when the dataset was compiled, and undocumented values render as an em dash rather than invented precision.
This approach creates a clear maintenance contract:
- The player can see which game version the data represents.
- The source of an important claim remains inspectable.
- A missing value is visibly different from a zero.
- A patch can update and reseed the versioned dataset without rewriting the information architecture.
Trust is not an extra label added after the database is built. It is a property of the schema, editorial workflow, interface, and release process working together.
Search architecture for a large, changing world
Raiderism contains several kinds of search intent: an item name, an ARC machine, a quest objective, a map condition, a workshop material, a skill, a blueprint, a guide, or a current event. Putting everything behind one client-side search box would make much of that information difficult to discover and crawl.
We paired global command search with stable category and detail routes. Descriptive headings, breadcrumbs, server-rendered content, contextual internal links, and focused page titles give players and search engines clear paths through the same graph.
An item can lead to its recipe, its salvage source, and the workshop tier that consumes it. A machine can lead to its map, loot, and combat guide. A quest can lead to its handler, prerequisite, and required haul. Those relationships are useful navigation first, but they also create the kind of coherent internal linking that a large database needs to grow in search.
What we learned building Raiderism
The central lesson was that a live-service database needs three different kinds of truth:
- Reference truth: versioned facts about items, machines, recipes, quests, skills, and traders.
- Operational truth: what is live, what happens next, and when a time window closes.
- Personal truth: what this particular player has finished, unlocked, or still needs.
Combining those truths in one product does not mean storing them the same way. Public reference data should be sourced and crawlable. Operational data should reveal its schedule and timezone. Personal progress should remain fast, private, and easy to update.
That is the same systems thinking we bring to custom software platforms: the data model, state model, interface, content strategy, and search architecture have to reinforce one another. Raiderism works because a database record is not the end of the experience. It is the beginning of the next useful decision.
Explore Raiderism
Raiderism is live and continuing to evolve with ARC Raiders. Players can research loot, compare weapons, study ARC weak points, follow contract chains, inspect maps, check current conditions, plan a build, track progression, and prepare the exact haul they need before going topside.
Raiderism is an unofficial fan resource and is not affiliated with or endorsed by Embark Studios. ARC Raiders is a trademark of Embark Studios AB. All game assets and intellectual property are the property of their respective owners.
