firestarters enemies: Android Threats and Priorities

What is confirmed about the opposition

FIRESTARTERS pits Kera against android enemies, but a complete current roster with verified health values, attacks and spawn rules is not yet documented here. The official store description establishes the android opposition without naming every type. Missing names remain pending confirmation (待确认), rather than being replaced by guesses.

A useful enemy guide must distinguish an observed behaviour from an assumed category. An enemy being close to you in one attempt does not prove it has a melee-only attack set. Likewise, surviving a hit once does not establish either health or a hidden resistance.

Identify the cause of a failed encounter

After a difficult attempt, ask what the enemy actually prevented you from doing. You may have lost a route, missed the next target or committed to an attack from an awkward position. These are different problems, and a generic instruction to attack the strongest enemy first does not resolve all of them.

Choose one opponent or one section of the encounter to observe on the next retry. Watch where you were when the problem began and whether a different approach changes the result. This is a proposed learning method, not a verified threat ranking.

Plan a target you can reach

The Softpedia preview describes learning enemy positions through repeat attempts while dealing with time pressure. That supports paying attention to travel between targets instead of treating all choices as damage comparisons. It does not provide a complete spawn script or prove every encounter is identical.

Before committing to a distant target, consider whether the route is one you can follow deliberately. If reaching it repeatedly leaves you disoriented, practise that route separately or compare a more accessible target. The movement guide provides exercises for that decision without claiming a universal kill order.

Compare tools without inventing weaknesses

Use the weapon guide to organise tests of the tools you currently have. Keep the encounter and route similar when comparing how reliably you can deal with an opponent. A different outcome may reflect positioning or execution, so it is not automatically proof of an elemental weakness.

Pending confirmation (待确认): type-specific damage resistance, exact health, stagger rules, attack intervals and guaranteed resource rewards. Avoid importing those systems from a different game with a similar name. If the current tutorial identifies a special response, follow that instruction and record the build when checking it.

What historical enemy names do and do not prove

The developer's February 15 demo notes mention Sufferers in a scoring adjustment, and the February 25 demo notes mention an Overseer medal exploit fix. These are historical names in demo patch history. Neither post supplies a complete current bestiary or justifies a launch-version farming strategy.

Do not convert an exploit fix into advice to repeatedly farm a particular enemy. The point of the later note is that the medal logic changed. Current rewards and any continued role for those enemy types require direct confirmation in the Early Access build.

Revisit familiar encounters before ranking threats

After a Story clear, use Arcade Mode to return to a familiar Storm. Compare one target-selection change at a time and note what actually improved. A reliable personal route is a better starting point than an unsupported enemy tier list.

A useful observation is more specific than a label

When an opponent causes trouble, write what happened before trying to name its entire role. Note the point where your route stopped working and the action you attempted in response. A description of that sequence is easier to verify than a guessed label such as tank, support or sniper.

Compare another attempt under similar conditions before deciding the behaviour is guaranteed. A target might be difficult to reach because of your approach rather than because it has an undocumented ability. Keeping those possibilities separate prevents a practical route problem from becoming an invented bestiary entry.

Leave room for a real current bestiary

A future roster should attach each name to an identifiable current source or reproducible observation. It should distinguish visible attacks, measured values and unresolved questions. Until those entries exist, the historical names above should remain limited evidence rather than placeholders for made-up attack patterns.

Read the scope of the Sufferer change carefully

The February 15 demo note specifically says Sufferer hits and kills contribute to Variety and Clean multiplier accumulation while still awarding no direct points and not counting for medals. That distinction matters historically: contributing to a multiplier is not the same as receiving a direct kill reward. It does not supply an enemy health value, a full attack description or a current strategy for Early Access.

The February 25 correction changes medal logic to stop Overseers being used for farming. A guide that repeats a pre-fix farming method without its date would reverse the meaning of the source. Treat the two notes as examples of why reward behaviour needs a build-specific explanation rather than as a launch-version reward chart.

Check names against the right game

Searches for Firestarters can return unrelated factions and older games. Before accepting a roster, verify the developer, the Steam app and the publication context. A convincing list of names is still useless if it belongs to a different title.

The target here is Studio Kerosene's FIRESTARTERS, Steam application 3733710. Neither familiarity with another arena shooter nor a similar title establishes a shared enemy set. This identity check is particularly important before translating a purported roster into another language.