菜单
Build real-time strategy games as single-page HTML, CSS, and JavaScript apps. Use when creating or refining RTS mechanics, data-driven units and buildings, command routing, combat orders, capture and service systems, air units, fog of war, AI factions, HUDs, and browser-based RTS game loops.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Build a data-driven, attribute-controlled game menu system with concurrent gameplay and simulation, custom actions, and in-place value updates.
Diagnose and fix browser 3D rendering bugs that appear only on some phones or GPUs, especially in Three.js WebGL scenes using dynamic textures, shadows, lighting, and custom materials. Use when a model looks dark, black, missing, inverted, or otherwise wrong on one mobile device but fine on desktop or other phones.
Build browser-based Three.js 3D games with sane axis conventions, disciplined scene graphs, stable camera and lighting setup, procedural geometry patterns, and practical debugging habits. Use when creating or refactoring a Three.js game so transforms, materials, and coordinate systems stay understandable.
Build rendering, minimap, fog, and save systems for RTS games. Use when implementing backbuffer rendering, procedural sprites, minimap layers, fog-of-war visuals, JSON snapshots, restore pipelines, and browser RTS state persistence.
Design layered AI for real-time strategy games. Use when building RTS economy phases, scouting, enemy memory, tactical assignments, air doctrine, objective scoring, and non-cheating browser RTS opponents.
Implement movement, occupancy, and pathfinding for RTS games. Use when building grid traversal, traversal costs, reservations, spawn cells, approach cells, transport unloading, and formation-friendly browser RTS movement.
| name | rts-games |
| description | Build real-time strategy games as single-page HTML, CSS, and JavaScript apps. Use when creating or refining RTS mechanics, data-driven units and buildings, command routing, combat orders, capture and service systems, air units, fog of war, AI factions, HUDs, and browser-based RTS game loops. |
| argument-hint | Describe the RTS system, feature, or gameplay slice to build |
| user-invocable | true |
| disable-model-invocation | false |
Build robust real-time strategy games for the browser using vanilla HTML, CSS, and JavaScript.
This skill is for RTS work where the game lives primarily in one page and one runtime, with direct ownership of simulation, rendering, input, UI, and AI. It emphasizes patterns that transfer across many RTS designs rather than one specific title.
For single-page RTS games, prefer a self-contained structure:
<head>: metadata, manifest, icons, theme color, responsive viewport<style>: design tokens, HUD layout, responsive rules, touch affordances<canvas> or <svg> viewport plus HUD panels and modal overlays<script type="module">: constants, state, systems, simulation loop, rendering, input, AISuggested runtime sections inside the script:
Action panels, touch strips, and selection HUD controls should usually be created once and updated in place.
Do not rebuild command buttons every frame or on every lightweight selection refresh if you can avoid it.
Prefer this model:
This reduces:
If your HUD exposes numbered or lettered actions, stable positions matter.
Good examples:
Sell for a fixed final slotMove, Context, or similar core actions in predictable positions when practicalIf some selections need fewer actions, keep the slots but hide the unused ones so the DOM remains stable while the layout can still collapse cleanly.
HUD rebuild triggers should be explicit.
Typical triggers:
Separate high-frequency simulation updates from lower-frequency HUD refreshes where possible.
const ACTION_SLOTS = Array.from({ length: 9 }, (_, index) => ({
key: 'Alt+' + (index + 1),
element: null,
iconEl: null,
labelEl: null,
progressEl: null,
clickHandler: null
}));
function initActionHud(container) {
for (const slot of ACTION_SLOTS) {
const button = document.createElement('button');
button.type = 'button';
button.className = 'action-button is-hidden';
button.innerHTML = `
<svg class="button-icon" aria-hidden="true"><use href="#icon-context"></use></svg>
<span class="button-label"></span>
<span class="action-progress" hidden><span class="action-progress-fill"></span></span>
`;
slot.element = button;
slot.iconEl = button.querySelector('use');
slot.labelEl = button.querySelector('.button-label');
slot.progressEl = button.querySelector('.action-progress-fill');
button.addEventListener('click', () => {
if (button.disabled || typeof slot.clickHandler !== 'function') return;
slot.clickHandler();
});
container.appendChild(button);
}
}
function clearActionHud() {
for (const slot of ACTION_SLOTS) {
slot.clickHandler = null;
slot.element.className = 'action-button is-hidden';
slot.element.disabled = true;
slot.element.hidden = true;
slot.labelEl.textContent = '';
slot.progressEl.parentElement.hidden = true;
slot.progressEl.style.width = '0%';
}
}
function setActionSlot(index, item) {
const slot = ACTION_SLOTS[index];
if (!slot) return;
slot.clickHandler = item.onClick;
slot.element.hidden = false;
slot.element.disabled = !!item.disabled;
slot.element.className = 'action-button'
+ (item.active ? ' is-active' : '')
+ (item.danger ? ' is-danger' : '')
+ (item.disabled ? ' is-disabled' : '');
slot.iconEl.setAttribute('href', '#icon-' + item.icon);
slot.labelEl.textContent = item.label;
if (typeof item.progress === 'number') {
slot.progressEl.parentElement.hidden = false;
slot.progressEl.style.width = Math.round(item.progress * 100) + '%';
}
}
function refreshActionHud(selectionState) {
clearActionHud();
const items = buildActionsForSelection(selectionState);
const sell = items.find((item) => item.id === 'sell');
const regular = items.filter((item) => item.id !== 'sell');
regular.forEach((item, index) => setActionSlot(index, item));
if (sell) setActionSlot(ACTION_SLOTS.length - 1, sell);
}
Key point:
Touch strips should not duplicate every command if the action panel already exposes them clearly.
A good split is:
Select, Pan, and maybe MoveAttack, Gather, Repair, Capture, Build, Sell, or cooldown abilitiesThis keeps the touch HUD small and avoids maintaining two competing command surfaces.
Before writing systems, define what a player can mean by a click or tap:
ContextContextContextMove, Attack, Gather, Repair, CaptureWrite these as game rules, not implementation details. Example questions:
Context use broad selection hitboxes or strict command hitboxes?If these meanings are not explicit, regressions appear as “edge cases” later.
Keep unit and building capabilities in data tables:
const UNIT_TYPES = {
scout: { speed: 32, sight: 8, range: 22, infantry: true },
tank: { speed: 24, sight: 10, range: 40, vehicle: true },
fighter: { speed: 84, sight: 12, range: 86, flying: true, maxMissiles: 4 }
};
const BUILDING_TYPES = {
barracks: { size: [4, 3], queue: ['scout', 'engineer'] },
factory: { size: [4, 3], queue: ['tank', 'ambulance'] },
airfield: { size: [6, 3], queue: ['fighter'] }
};
Prefer flags and explicit fields over hard-coded conditionals scattered across the codebase.
Each unit should have an order object with a small number of clear states:
idlemoveattackattack-movegatherreturnrepaircapturesupportserviceguardstrikelanding, takeoff, waypoint, or other specialized statesFor special units, use dedicated orders instead of overloading generic ones. Aircraft especially benefit from explicit runway and mission states.
Keep three layers distinct:
This keeps command bugs local. For example, if a fighter behaves incorrectly in Context mode, fix the interpretation layer first before rewriting flight logic.
When units need multi-step behavior, prefer order composition over piles of flags such as isReturning, isLanding, isRearming, and isRedirecting.
Use nested or chained orders instead:
takeoff -> strikestrike -> return -> landingwaypoint -> guardservice -> resume previous logistics orderThis allows complex missions without exploding the number of top-level states.
Guideline:
nextOrder or equivalent continuation fields where neededThis pattern is especially valuable for aircraft, transports, and support units.
RTS games often have several distinct occupancy systems that should not be conflated:
Treat each as a separate subsystem with its own lifecycle rules.
Good practice:
For each building or unit, compute geometry once in a helper and give the fields stable names:
footprintspritehitvisualCenterfireBe consistent with rectangle shapes. If a rectangle uses x/y/right/bottom, do not later read left/top from it.
This is one of the most important RTS patterns.
Selection and command targeting often need different geometry:
Use separate helpers when semantics differ:
getSelectionTargetAtWorldPoint(...)getCommandTargetAtWorldPoint(...)getLandingTargetAtWorldPoint(...)Do not share one oversized hitbox for every interaction type.
When multiple large objects overlap or nearly overlap, do not return the first match from an array. Score candidates using distance to footprint or visual center and choose the best match.
If sprites are generated procedurally or drawn into canvases, derive tight visual bounds from the rendered result instead of hard-coding hit extents by hand.
This improves:
Even when exact alpha-derived bounds are too expensive to compute every frame, they can often be measured once at startup and reused thereafter.
One of the easiest ways to create serious selection and command bugs is to mix rectangle conventions.
Examples of incompatible shapes:
x/y/width/heightx/y/right/bottomleft/top/right/bottomChoose a small number of standard rectangle shapes and keep helper contracts explicit. If you must use more than one shape, convert between them in named helpers instead of reading mixed field names ad hoc.
For RTS games, it is often useful to keep both:
Use helpers to convert between the two and keep that conversion centralized.
Prefer a fixed simulation step with decoupled render timing. This keeps AI, combat cooldowns, pathing, and capture timers stable under fluctuating frame rates.
Keep a single authoritative runtime state object containing:
Use initializer functions like freshState() and entity spawn helpers to avoid drift between created objects.
Once your RTS has more than a small handful of units and buildings, repeated whole-array scans become a hidden performance tax.
Use spatial buckets, uniform grids, or another simple partitioning strategy so these queries operate on nearby candidates only:
Design the query API around intent, not storage details:
forEachNearbyUnit(...)forEachNearbyBuilding(...)findEnemyInRange(...)This keeps gameplay systems readable while still scaling.
If many systems need the same summary facts, compute them once and pass them around.
Examples:
Aggregation passes make AI reasoning easier to debug and reduce repeated filtering work.
Use this procedure whenever you add a new commandable behavior.
Context, explicit mode, keyboard, and touch workflows.Branching logic examples:
Also test these subtle command-routing cases:
Aircraft in RTS games usually need dedicated logic and should not be treated like fast tanks.
landedtakeoffguardwaypointstrikereturnlandingDifferentiate these two mission types explicitly:
Aircraft often need two distinct attack behaviors:
Do not reuse the same target-selection logic for both. A direct strike should feel disciplined; a loiter patrol should feel adaptive.
For repeated aircraft attacks, a useful pattern is:
Store run-local state such as:
Without stable per-pass state, aircraft often devolve into indefinite circular orbiting.
Split “can heal nearby” from “should chase as a support target.”
Example:
This avoids coupling proximity healing to pursuit behavior.
Support compatibility should be explicit:
Service should be a real order with:
For support units, logistics units, and aircraft, service should also answer these design questions explicitly:
Capture should be capability-based, not structure-name special-casing. If a building is hostile and the capturing unit has the required tech and role, it should generally be capturable unless the design explicitly forbids it.
When capture bugs occur, inspect both layers separately:
RTS AI benefits from layered decision-making rather than a single monolithic planner.
Give AI air units explicit doctrine:
Avoid issuing raw movement to aircraft if the design intent is patrol or attack.
For better-feeling RTS AI, maintain remembered enemy information rather than reading the whole game state directly.
A good memory model stores:
Then add memory reconciliation rules:
This makes recon, scanners, drones, and scouting systems tactically meaningful.
For expansion, harassment, recon, or resource races, score objectives rather than using a single static script.
Typical factors:
This helps AI shift naturally between economy, denial, recon, and attack play.
A strong browser RTS pattern is to render into a fixed or bounded backbuffer, then scale that output to the display.
Benefits:
If you use a pixel-art style, keep the simulation and UI crisp by controlling the render surface explicitly rather than drawing at arbitrary device resolution.
Good candidates for startup-time precomputation include:
Avoid recomputing expensive visual data every frame when it only changes on reset, resize, or visibility refresh.
For RTS save systems, snapshot authoritative state only, then recompute all derived caches on restore.
Authoritative examples:
Derived examples to rebuild after restore:
This is more resilient than persisting transient caches directly.
Give snapshots a version and handle mismatches deliberately.
When constants change between builds, consider upgrade logic instead of silent failure. For example, resource multipliers or production timings may need normalization during restore.
Mouse, keyboard, and touch should converge into the same command helpers whenever possible.
Prefer this layering:
This prevents three separate implementations of the same gameplay rule.
For browser RTS games that support touch and mouse together, assign meaning to the drag interaction itself:
Then let pointer type and HUD mode decide which drag mode is active. This is generally more robust than branching deeply on mouse versus touch inside core gameplay logic.
Keep command meaning visible to the player.
Update these whenever behaviors change:
If a behavior is subtle, it must be legible in the HUD. Otherwise players will interpret consistent rules as bugs.
When a gameplay bug appears, use this workflow.
Typical examples:
x/y versus left/topA feature is not done just because it compiles. Consider it complete when:
Context and explicit modesnpm run build or the project’s equivalent build step/rts-games Create a single-file browser RTS with harvesters, scouts, tanks, fog of war, and a minimal AI opponent./rts-games Add aircraft with takeoff, landing, loiter, strike, and return-to-airfield behavior./rts-games Design a context-command system for an RTS where fighters, harvesters, scouts, and ambulances all interpret clicks differently./rts-games Refactor my RTS hit-testing so selection, attack targeting, landing zones, and capture targeting use separate helpers./rts-games Add AI doctrine for air units that can loiter over objectives or commit to direct strikes./rts-games Review this RTS unit-order system for edge cases, regressions, and missing HUD feedback./rts-games Add save/load support to a browser RTS and design the restore pipeline so derived state is rebuilt safely./rts-games Design a support and logistics layer with ambulances, transports, service buildings, and occupancy rules./rts-games Add RTS spatial indexing for nearby-unit queries, threat scans, healing, and target acquisition.This first version is strong on single-page browser RTS architecture, aircraft, command routing, and playtest-driven debugging. The main areas that could be sharpened further are:
If you want, the next revision can specialize this skill toward one of those directions without making it title-specific.