wip deepseek
This commit is contained in:
Vendored
+5
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"chat.tools.terminal.autoApprove": {
|
||||
"dotnet build": true
|
||||
}
|
||||
}
|
||||
@@ -53,6 +53,17 @@
|
||||
<LastGenOutput>Settings.Designer.cs</LastGenOutput>
|
||||
</None>
|
||||
</ItemGroup>
|
||||
<ItemGroup>
|
||||
<Content Include="knowledge_default.md">
|
||||
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
|
||||
</Content>
|
||||
<Content Include="knowledge_corona.md">
|
||||
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
|
||||
</Content>
|
||||
<Content Include="knowledge_units.json">
|
||||
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
|
||||
</Content>
|
||||
</ItemGroup>
|
||||
<Target Name="CustomAfterBuild" AfterTargets="Build">
|
||||
<ItemGroup>
|
||||
<_FilesToMove Include="$(OutputPath)*.dll" />
|
||||
|
||||
+15
@@ -28,5 +28,20 @@ A deterministic rule that checks LLM claims against Operation Facts and known ga
|
||||
### Validation Issue
|
||||
A machine-detected problem in an LLM claim, such as a direct contradiction, weak evidence, missing alternative, or impossible timeline.
|
||||
|
||||
### Game Knowledge
|
||||
Domain knowledge about the game or mod that the AI may use during analysis, such as unit capabilities, faction rules, map geometry, build restrictions, and known exceptions. Game knowledge may be used both to shape prompt guidance and to power deterministic validation.
|
||||
|
||||
### Knowledge Scope
|
||||
The applicability boundary of a piece of game knowledge. A mod is a game version and defines its own complete knowledge set. Within a mod, scope can be global (applies to all factions and maps on that mod), faction-specific, or map-specific. There is no separate "mod scope" because the mod IS the top-level scope selector — the replay's mod determines which knowledge set is loaded.
|
||||
|
||||
### Knowledge Set
|
||||
A named collection of game knowledge entries for a specific game version (mod). Each knowledge set is self-contained and complete for its mod — there is no cross-set inheritance or conditional sharing. The set is organized hierarchically by scope: `global/` entries apply across all factions and maps; `factions/{name}/` entries are scoped to a faction; `maps/{id}/` entries are scoped to a map. The replay's mod name directly selects which knowledge set to load (e.g., `"default"` for base game, `"corona"` for the Corona mod).
|
||||
|
||||
### Knowledge Entry
|
||||
The smallest reusable unit of game knowledge within a knowledge set. A knowledge entry has an identifier, a set of predefined tags, and a text description (markdown). It is the unified format used both for prompt rendering and for validation queries. Scope is inherited from the entry's path position within the knowledge set (global, faction, or map), not stored in the entry itself.
|
||||
|
||||
### Knowledge Tag
|
||||
A predefined label attached to a `KnowledgeEntry` to enable querying by validation logic. Tags belong to a finite taxonomy covering capabilities (e.g., `builder`, `pack`, `unpack`, `amphibious`, `returnToProducer`), types (e.g., `infantry`, `vehicle`, `aircraft`, `naval`, `structure`), combat roles (e.g., `antiInfantry`, `antiVehicle`, `antiAir`, `antiNaval`, `antiStructure`), and special power references (e.g., `specialPower:PackReplaceSelf`).
|
||||
|
||||
### Revision Pass
|
||||
(Partially implemented) A hidden LLM request that receives the prior draft, validation issues, and relevant Operation Facts, then produces a corrected analysis without exposing apology or correction chatter to the user. Currently, validation issues are detected and logged, but no automatic revision pass is triggered. The revision logic still needs to be wired into `AIChatPanel`.
|
||||
|
||||
@@ -540,12 +540,7 @@ namespace AnotherReplayReader.Utils
|
||||
|
||||
// Check 3: UnitId used as builder vs claim
|
||||
var isBuilderInReplay = factIndex.BuilderUnitIds.Contains(unitId);
|
||||
var claimLooksLikeBuilder = claim.Claim.IndexOf("MCV", StringComparison.OrdinalIgnoreCase) >= 0
|
||||
|| claim.Claim.IndexOf("基地车", StringComparison.OrdinalIgnoreCase) >= 0
|
||||
|| claim.Claim.IndexOf("Nanocore", StringComparison.OrdinalIgnoreCase) >= 0
|
||||
|| claim.Claim.IndexOf("纳米核心", StringComparison.OrdinalIgnoreCase) >= 0
|
||||
|| claim.Claim.IndexOf("builder", StringComparison.OrdinalIgnoreCase) >= 0
|
||||
|| claim.Claim.IndexOf("建造者", StringComparison.OrdinalIgnoreCase) >= 0;
|
||||
var claimLooksLikeBuilder = ClaimLooksLikeBuilder(claim.Claim);
|
||||
if (claimLooksLikeBuilder && !isBuilderInReplay)
|
||||
{
|
||||
issues.Add(new AIValidationIssue(
|
||||
@@ -651,5 +646,31 @@ namespace AnotherReplayReader.Utils
|
||||
}
|
||||
return result.ToImmutableArray();
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Check if a claim text describes a builder unit (MCV, Nanocore, etc.).
|
||||
/// Uses structured knowledge (knowledge_units.json) when available, falls
|
||||
/// back to heuristic string matching for backward compatibility.
|
||||
/// </summary>
|
||||
private static bool ClaimLooksLikeBuilder(string claimText)
|
||||
{
|
||||
// Primary: structured knowledge lookup
|
||||
var structured = StructuredKnowledge.Instance;
|
||||
if (structured is not null)
|
||||
{
|
||||
foreach (var entity in structured.AllEntities)
|
||||
{
|
||||
if (entity.HasTag(KnowledgeTag.Builder) &&
|
||||
claimText.IndexOf(entity.AssetName, StringComparison.OrdinalIgnoreCase) >= 0)
|
||||
{
|
||||
return true;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Fallback: heuristic string matching
|
||||
var keywords = new[] { "MCV", "基地车", "Nanocore", "纳米核心", "builder", "建造者" };
|
||||
return keywords.Any(kw => claimText.IndexOf(kw, StringComparison.OrdinalIgnoreCase) >= 0);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -23,6 +23,27 @@ namespace AnotherReplayReader.Utils
|
||||
AiPromptSettings? promptSettings = null)
|
||||
{
|
||||
var defaultPrompt = BuildDefaultSystemPrompt(replay, players);
|
||||
|
||||
// Try loading from knowledge_{mod}.md file (generated by tools/expand_knowledge.py).
|
||||
// If the file exists, use it instead of the built-in string.
|
||||
var modName = replay.Mod.ModName?.ToLowerInvariant();
|
||||
var knowledgeModName = modName switch
|
||||
{
|
||||
"corona" => "corona",
|
||||
_ => "default",
|
||||
};
|
||||
var knowledgePath = Path.Combine(AppContext.BaseDirectory, $"knowledge_{knowledgeModName}.md");
|
||||
if (File.Exists(knowledgePath))
|
||||
{
|
||||
var factionNames = players
|
||||
.Select(kv => ModData.GetFaction(replay.Mod, kv.Value.FactionId).Name)
|
||||
.Distinct()
|
||||
.ToArray();
|
||||
var mapId = Path.GetFileNameWithoutExtension(replay.MapPath);
|
||||
var knowledge = KnowledgeSet.ForMod(knowledgeModName, AppContext.BaseDirectory);
|
||||
defaultPrompt = knowledge.RenderAsPrompt(factionNames, mapId);
|
||||
}
|
||||
|
||||
return ComposeSystemPrompt(defaultPrompt, promptSettings);
|
||||
}
|
||||
|
||||
|
||||
@@ -0,0 +1,582 @@
|
||||
using System;
|
||||
using System.Collections.Generic;
|
||||
using System.Collections.Immutable;
|
||||
using System.IO;
|
||||
using System.Linq;
|
||||
using System.Text;
|
||||
using System.Text.Json;
|
||||
|
||||
namespace AnotherReplayReader.Utils
|
||||
{
|
||||
/// <summary>
|
||||
/// Predefined tag taxonomy for KnowledgeEntry.
|
||||
/// Tags bridge prompt rendering and validation logic.
|
||||
/// </summary>
|
||||
internal static class KnowledgeTag
|
||||
{
|
||||
// ── Capability tags (what a unit can do) ──────────────────────
|
||||
public const string Builder = "builder";
|
||||
public const string Pack = "pack";
|
||||
public const string Unpack = "unpack";
|
||||
public const string Amphibious = "amphibious";
|
||||
public const string Transport = "transport";
|
||||
public const string ReturnToProducer = "returnToProducer";
|
||||
public const string Cloak = "cloak";
|
||||
public const string ToggleWeapon = "toggleWeapon";
|
||||
|
||||
// ── Type tags (what a unit is) ────────────────────────────────
|
||||
public const string Infantry = "infantry";
|
||||
public const string Vehicle = "vehicle";
|
||||
public const string Aircraft = "aircraft";
|
||||
public const string Naval = "naval";
|
||||
public const string Structure = "structure";
|
||||
public const string Hero = "hero";
|
||||
public const string Production = "production";
|
||||
public const string Defense = "defense";
|
||||
public const string Superweapon = "superweapon";
|
||||
|
||||
// ── Combat role tags (what a unit fights) ─────────────────────
|
||||
public const string AntiInfantry = "antiInfantry";
|
||||
public const string AntiVehicle = "antiVehicle";
|
||||
public const string AntiStructure = "antiStructure";
|
||||
public const string AntiAir = "antiAir";
|
||||
public const string AntiNaval = "antiNaval";
|
||||
|
||||
/// <summary>Create a special power reference tag.</summary>
|
||||
public static string SpecialPower(string powerName) => $"specialPower:{powerName}";
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// The scope kind of a knowledge entry within a KnowledgeSet.
|
||||
/// Scope is determined by the entry's position in the hierarchy,
|
||||
/// not stored in the entry itself.
|
||||
/// </summary>
|
||||
internal enum KnowledgeScopeKind
|
||||
{
|
||||
Global,
|
||||
Faction,
|
||||
Map
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Identifies which scope a knowledge entry belongs to.
|
||||
/// </summary>
|
||||
internal sealed record KnowledgeScope(KnowledgeScopeKind Kind, string? Name = null)
|
||||
{
|
||||
public static KnowledgeScope Global { get; } = new(KnowledgeScopeKind.Global);
|
||||
public static KnowledgeScope Faction(string name) => new(KnowledgeScopeKind.Faction, name);
|
||||
public static KnowledgeScope Map(string id) => new(KnowledgeScopeKind.Map, id);
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// The smallest reusable unit of game knowledge.
|
||||
/// Id is unique within a knowledge set; tags enable validation queries;
|
||||
/// text is the markdown description used for prompt rendering.
|
||||
/// </summary>
|
||||
internal sealed record KnowledgeEntry(
|
||||
string Id,
|
||||
ImmutableArray<string> Tags,
|
||||
string Text)
|
||||
{
|
||||
public bool HasTag(string tag) => Tags.Contains(tag, StringComparer.OrdinalIgnoreCase);
|
||||
public bool HasAnyTag(params string[] tags) => tags.Any(HasTag);
|
||||
}
|
||||
|
||||
// ── Structured game entity knowledge ───────────────────────────────
|
||||
|
||||
/// <summary>A special power with its observable name and description.</summary>
|
||||
internal sealed record SpecialPowerInfo(string Name, string Description);
|
||||
|
||||
/// <summary>
|
||||
/// Structured knowledge about a game entity (unit or building).
|
||||
/// Buildings omit <see cref="Tier"/> and <see cref="ProducedBy"/>;
|
||||
/// the <c>structure</c> tag distinguishes them from units.
|
||||
/// </summary>
|
||||
internal sealed record EntityKnowledge(
|
||||
string AssetName,
|
||||
string DisplayName,
|
||||
string Faction,
|
||||
string? Tier,
|
||||
ImmutableArray<string> Tags,
|
||||
ImmutableArray<SpecialPowerInfo> SpecialPowers,
|
||||
ImmutableArray<string> ProducedBy,
|
||||
string Text)
|
||||
{
|
||||
public bool IsBuilding => HasTag(KnowledgeTag.Structure);
|
||||
public bool IsUnit => !IsBuilding;
|
||||
public bool HasTag(string tag) => Tags.Contains(tag, StringComparer.OrdinalIgnoreCase);
|
||||
public bool HasSpecialPower(string name) =>
|
||||
SpecialPowers.Any(sp => string.Equals(sp.Name, name, StringComparison.OrdinalIgnoreCase));
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// In-memory index of structured game knowledge loaded from knowledge_units.json.
|
||||
/// Used by validation to query unit capabilities deterministically.
|
||||
/// </summary>
|
||||
internal sealed class StructuredKnowledge
|
||||
{
|
||||
public ImmutableDictionary<string, EntityKnowledge> EntitiesByAssetName { get; }
|
||||
public ImmutableArray<EntityKnowledge> AllEntities { get; }
|
||||
public ImmutableDictionary<string, ImmutableArray<EntityKnowledge>> EntitiesByFaction { get; }
|
||||
|
||||
private StructuredKnowledge(
|
||||
ImmutableDictionary<string, EntityKnowledge> byAsset,
|
||||
ImmutableArray<EntityKnowledge> allEntities,
|
||||
ImmutableDictionary<string, ImmutableArray<EntityKnowledge>> byFaction)
|
||||
{
|
||||
EntitiesByAssetName = byAsset;
|
||||
AllEntities = allEntities;
|
||||
EntitiesByFaction = byFaction;
|
||||
}
|
||||
|
||||
// ── Query helpers ────────────────────────────────────────────
|
||||
|
||||
public ImmutableArray<EntityKnowledge> EntitiesWithTag(string tag) =>
|
||||
AllEntities.Where(e => e.HasTag(tag)).ToImmutableArray();
|
||||
|
||||
public ImmutableArray<EntityKnowledge> EntitiesWithSpecialPower(string power) =>
|
||||
AllEntities.Where(e => e.HasSpecialPower(power)).ToImmutableArray();
|
||||
|
||||
public EntityKnowledge? GetEntity(string? assetName) =>
|
||||
assetName is not null && EntitiesByAssetName.TryGetValue(assetName, out var e) ? e : null;
|
||||
|
||||
public bool IsKnownBuilder(string? assetName) =>
|
||||
GetEntity(assetName)?.HasTag(KnowledgeTag.Builder) == true;
|
||||
|
||||
public bool EntityHasSpecialPower(string? assetName, string? powerName) =>
|
||||
assetName is not null && powerName is not null &&
|
||||
GetEntity(assetName)?.HasSpecialPower(powerName) == true;
|
||||
|
||||
// ── Factory ──────────────────────────────────────────────────
|
||||
|
||||
private static readonly Lazy<StructuredKnowledge?> _lazyInstance = new(() => LoadFromFile());
|
||||
|
||||
public static StructuredKnowledge? Instance => _lazyInstance.Value;
|
||||
|
||||
/// <summary>Look up the display name for an asset name.</summary>
|
||||
public string? GetDisplayName(string? assetName) =>
|
||||
GetEntity(assetName)?.DisplayName;
|
||||
|
||||
private static StructuredKnowledge? LoadFromFile()
|
||||
{
|
||||
var path = Path.Combine(AppContext.BaseDirectory, "knowledge_units.json");
|
||||
if (!File.Exists(path)) return null;
|
||||
|
||||
try
|
||||
{
|
||||
var json = File.ReadAllText(path, Encoding.UTF8);
|
||||
using var doc = JsonDocument.Parse(json);
|
||||
var root = doc.RootElement;
|
||||
|
||||
if (!root.TryGetProperty("factions", out var factions))
|
||||
return null;
|
||||
|
||||
var allEntities = new List<EntityKnowledge>();
|
||||
var byFaction = new Dictionary<string, List<EntityKnowledge>>(StringComparer.OrdinalIgnoreCase);
|
||||
|
||||
foreach (var faction in factions.EnumerateObject())
|
||||
{
|
||||
var factionName = faction.Name;
|
||||
if (!byFaction.ContainsKey(factionName))
|
||||
byFaction[factionName] = new List<EntityKnowledge>();
|
||||
|
||||
// Buildings
|
||||
if (faction.Value.TryGetProperty("buildings", out var bldgs))
|
||||
{
|
||||
foreach (var b in bldgs.EnumerateArray())
|
||||
{
|
||||
var ek = new EntityKnowledge(
|
||||
GetString(b, "assetName") ?? "unknown",
|
||||
GetString(b, "displayName") ?? "",
|
||||
factionName,
|
||||
Tier: null,
|
||||
GetStringArray(b, "tags"),
|
||||
ParseSpecialPowers(b),
|
||||
ProducedBy: ImmutableArray<string>.Empty,
|
||||
GetString(b, "text") ?? "");
|
||||
allEntities.Add(ek);
|
||||
byFaction[factionName].Add(ek);
|
||||
}
|
||||
}
|
||||
|
||||
// Units
|
||||
if (faction.Value.TryGetProperty("units", out var units))
|
||||
{
|
||||
foreach (var u in units.EnumerateArray())
|
||||
{
|
||||
var assetName = GetString(u, "assetName") ?? "unknown";
|
||||
var ek = new EntityKnowledge(
|
||||
assetName,
|
||||
GetString(u, "displayName") ?? "",
|
||||
factionName,
|
||||
GetString(u, "tier"),
|
||||
GetStringArray(u, "tags"),
|
||||
ParseSpecialPowers(u),
|
||||
GetStringArray(u, "producedBy"),
|
||||
GetString(u, "text") ?? "");
|
||||
allEntities.Add(ek);
|
||||
byFaction[factionName].Add(ek);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return new StructuredKnowledge(
|
||||
allEntities.ToImmutableDictionary(e => e.AssetName, e => e, StringComparer.OrdinalIgnoreCase),
|
||||
allEntities.ToImmutableArray(),
|
||||
byFaction.ToImmutableDictionary(
|
||||
kv => kv.Key,
|
||||
kv => kv.Value.ToImmutableArray(),
|
||||
StringComparer.OrdinalIgnoreCase));
|
||||
}
|
||||
catch (Exception ex)
|
||||
{
|
||||
System.Diagnostics.Debug.WriteLine($"[AiKnowledge] Failed to load knowledge_units.json: {ex.Message}");
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
private static string? GetString(JsonElement el, string prop) =>
|
||||
el.TryGetProperty(prop, out var v) && v.ValueKind == JsonValueKind.String
|
||||
? v.GetString()
|
||||
: null;
|
||||
|
||||
private static ImmutableArray<string> GetStringArray(JsonElement el, string prop)
|
||||
{
|
||||
if (!el.TryGetProperty(prop, out var arr) || arr.ValueKind != JsonValueKind.Array)
|
||||
return ImmutableArray<string>.Empty;
|
||||
var result = new List<string>();
|
||||
foreach (var item in arr.EnumerateArray())
|
||||
{
|
||||
if (item.ValueKind == JsonValueKind.String && item.GetString() is { } s)
|
||||
result.Add(s);
|
||||
}
|
||||
return result.ToImmutableArray();
|
||||
}
|
||||
|
||||
private static ImmutableArray<SpecialPowerInfo> ParseSpecialPowers(JsonElement el)
|
||||
{
|
||||
if (!el.TryGetProperty("specialPowers", out var arr) || arr.ValueKind != JsonValueKind.Array)
|
||||
return ImmutableArray<SpecialPowerInfo>.Empty;
|
||||
var result = new List<SpecialPowerInfo>();
|
||||
foreach (var item in arr.EnumerateArray())
|
||||
{
|
||||
if (item.ValueKind != JsonValueKind.Object) continue;
|
||||
var name = GetString(item, "name") ?? "";
|
||||
var desc = GetString(item, "description") ?? "";
|
||||
if (!string.IsNullOrWhiteSpace(name))
|
||||
result.Add(new SpecialPowerInfo(name, desc));
|
||||
}
|
||||
return result.ToImmutableArray();
|
||||
}
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// A named collection of game knowledge entries for a specific game version (mod).
|
||||
/// Entries are organized by scope; the set is self-contained and complete for its mod.
|
||||
/// </summary>
|
||||
internal sealed class KnowledgeSet
|
||||
{
|
||||
private readonly ImmutableArray<(KnowledgeScope Scope, KnowledgeEntry Entry)> _entries;
|
||||
|
||||
public KnowledgeSet(IEnumerable<(KnowledgeScope Scope, KnowledgeEntry Entry)> entries)
|
||||
{
|
||||
_entries = entries.ToImmutableArray();
|
||||
}
|
||||
|
||||
// ── Query helpers ────────────────────────────────────────────
|
||||
|
||||
public ImmutableArray<KnowledgeEntry> ByScope(KnowledgeScopeKind kind, string? name = null) =>
|
||||
_entries
|
||||
.Where(e => e.Scope.Kind == kind
|
||||
&& (name is null || string.Equals(e.Scope.Name, name, StringComparison.OrdinalIgnoreCase)))
|
||||
.Select(e => e.Entry)
|
||||
.ToImmutableArray();
|
||||
|
||||
public ImmutableArray<KnowledgeEntry> ByTag(string tag) =>
|
||||
_entries
|
||||
.Where(e => e.Entry.HasTag(tag))
|
||||
.Select(e => e.Entry)
|
||||
.ToImmutableArray();
|
||||
|
||||
public ImmutableArray<KnowledgeEntry> ByAnyTag(params string[] tags) =>
|
||||
_entries
|
||||
.Where(e => e.Entry.HasAnyTag(tags))
|
||||
.Select(e => e.Entry)
|
||||
.ToImmutableArray();
|
||||
|
||||
// ── Prompt rendering ─────────────────────────────────────────
|
||||
|
||||
public string RenderAsPrompt(IReadOnlyList<string> factionNames, string? mapId)
|
||||
{
|
||||
var sb = new StringBuilder();
|
||||
|
||||
foreach (var entry in ByScope(KnowledgeScopeKind.Global))
|
||||
{
|
||||
sb.AppendLine(entry.Text.Trim());
|
||||
sb.AppendLine();
|
||||
}
|
||||
|
||||
foreach (var faction in factionNames)
|
||||
{
|
||||
foreach (var entry in ByScope(KnowledgeScopeKind.Faction, faction))
|
||||
{
|
||||
sb.AppendLine(entry.Text.Trim());
|
||||
sb.AppendLine();
|
||||
}
|
||||
}
|
||||
|
||||
if (mapId is not null)
|
||||
{
|
||||
foreach (var entry in ByScope(KnowledgeScopeKind.Map, mapId))
|
||||
{
|
||||
sb.AppendLine(entry.Text.Trim());
|
||||
sb.AppendLine();
|
||||
}
|
||||
}
|
||||
|
||||
return sb.ToString().Replace("\r", "");
|
||||
}
|
||||
|
||||
// ── Built-in factory ─────────────────────────────────────────
|
||||
|
||||
/// <summary>
|
||||
/// Create a built-in KnowledgeSet for a given mod name.
|
||||
/// Loads text from <c>knowledge_{modName}.md</c> and structured entries
|
||||
/// from <c>knowledge_units.json</c>. The flat text's unit/building
|
||||
/// sections are stripped and replaced by structured entries for rendering.
|
||||
/// </summary>
|
||||
public static KnowledgeSet ForMod(string modName, string? baseDirectory = null)
|
||||
{
|
||||
var searchDir = baseDirectory ?? AppContext.BaseDirectory;
|
||||
var entries = new List<(KnowledgeScope Scope, KnowledgeEntry Entry)>();
|
||||
var structured = StructuredKnowledge.Instance;
|
||||
|
||||
// 1. Load flat text from knowledge_{modName}.md
|
||||
var flatPath = Path.Combine(searchDir, $"knowledge_{modName}.md");
|
||||
string? flatText = null;
|
||||
if (File.Exists(flatPath))
|
||||
{
|
||||
flatText = File.ReadAllText(flatPath, Encoding.UTF8);
|
||||
}
|
||||
|
||||
// 2. If structured data is available, strip unit sections from flat text
|
||||
// and add structured entries as faction-scoped KnowledgeEntry.
|
||||
if (structured is not null && flatText is not null)
|
||||
{
|
||||
var cleaned = StripUnitSections(flatText, structured);
|
||||
entries.Add((KnowledgeScope.Global, new KnowledgeEntry(
|
||||
$"knowledge-text-{modName}",
|
||||
ImmutableArray.Create("rule"),
|
||||
cleaned)));
|
||||
|
||||
foreach (var kv in structured.EntitiesByFaction)
|
||||
{
|
||||
var factionName = kv.Key;
|
||||
var sb = new StringBuilder();
|
||||
sb.AppendLine($"# {factionName}");
|
||||
|
||||
// Buildings (entities with structure tag)
|
||||
var bldgs = kv.Value
|
||||
.Where(e => e.IsBuilding)
|
||||
.ToImmutableArray();
|
||||
if (!bldgs.IsEmpty)
|
||||
{
|
||||
sb.AppendLine("## 建筑与升级");
|
||||
foreach (var b in bldgs)
|
||||
{
|
||||
sb.Append("- ");
|
||||
sb.Append(b.DisplayName);
|
||||
sb.Append('(');
|
||||
sb.Append(b.AssetName);
|
||||
sb.Append(")：");
|
||||
sb.AppendLine(b.Text.Trim());
|
||||
}
|
||||
sb.AppendLine();
|
||||
}
|
||||
|
||||
// Units (entities without structure tag) by tier
|
||||
var units = kv.Value
|
||||
.Where(e => e.IsUnit)
|
||||
.GroupBy(u => u.Tier ?? "")
|
||||
.OrderBy(g => TierOrder(g.Key));
|
||||
foreach (var tier in units)
|
||||
{
|
||||
var label = tier.Key switch
|
||||
{
|
||||
"基础" => "基础单位",
|
||||
"T2" => "T2 单位（需要T2升级）",
|
||||
"T3" => "T3 单位（需要T3升级）",
|
||||
"T4" => "T4 单位（需要T4升级）",
|
||||
_ => tier.Key,
|
||||
};
|
||||
sb.AppendLine($"## {label}");
|
||||
foreach (var unit in tier)
|
||||
{
|
||||
sb.Append("- ");
|
||||
sb.Append(unit.DisplayName);
|
||||
sb.Append('(');
|
||||
sb.Append(unit.AssetName);
|
||||
sb.AppendLine(")");
|
||||
|
||||
// Type info from tags
|
||||
var typeTags = unit.Tags
|
||||
.Where(t => t is "vehicle" or "infantry" or "aircraft" or "naval" or "structure" or "hero" or "amphibious")
|
||||
.Select(TagDisplayName);
|
||||
if (typeTags.Any())
|
||||
{
|
||||
sb.Append(" - 类型: ");
|
||||
sb.AppendLine(string.Join("、", typeTags));
|
||||
}
|
||||
|
||||
// Special powers
|
||||
if (!unit.SpecialPowers.IsEmpty)
|
||||
{
|
||||
foreach (var sp in unit.SpecialPowers)
|
||||
{
|
||||
sb.Append(" - 技能: ");
|
||||
sb.Append(sp.Name);
|
||||
if (!string.IsNullOrWhiteSpace(sp.Description))
|
||||
{
|
||||
sb.Append(" — ");
|
||||
sb.Append(sp.Description);
|
||||
}
|
||||
sb.AppendLine();
|
||||
}
|
||||
}
|
||||
|
||||
// Produced by
|
||||
if (!unit.ProducedBy.IsEmpty)
|
||||
{
|
||||
var producerNames = unit.ProducedBy
|
||||
.Select(name => structured.GetDisplayName(name) ?? name)
|
||||
.ToImmutableArray();
|
||||
sb.Append(" - 生产: ");
|
||||
sb.AppendLine(string.Join("、", producerNames));
|
||||
}
|
||||
|
||||
// Remaining description
|
||||
if (!string.IsNullOrWhiteSpace(unit.Text))
|
||||
{
|
||||
sb.Append(" - 描述: ");
|
||||
sb.AppendLine(unit.Text.Trim());
|
||||
}
|
||||
}
|
||||
sb.AppendLine();
|
||||
}
|
||||
|
||||
entries.Add((KnowledgeScope.Faction(factionName), new KnowledgeEntry(
|
||||
$"structured-{factionName}",
|
||||
ImmutableArray.Create("faction", "structured"),
|
||||
sb.ToString().TrimEnd())));
|
||||
}
|
||||
}
|
||||
else if (flatText is not null)
|
||||
{
|
||||
entries.Add((KnowledgeScope.Global, new KnowledgeEntry(
|
||||
$"knowledge-file-{modName}",
|
||||
ImmutableArray.Create("rule"),
|
||||
flatText)));
|
||||
}
|
||||
else
|
||||
{
|
||||
entries.Add((KnowledgeScope.Global, new KnowledgeEntry(
|
||||
"knowledge-unavailable",
|
||||
ImmutableArray.Create("rule"),
|
||||
$"# 注意\n\n游戏知识文件 knowledge_{modName}.md 未找到。\n\n")));
|
||||
}
|
||||
|
||||
return new KnowledgeSet(entries);
|
||||
}
|
||||
|
||||
private static int TierOrder(string tier) => tier switch
|
||||
{
|
||||
"基础" => 0,
|
||||
"T2" => 1,
|
||||
"T3" => 2,
|
||||
"T4" => 3,
|
||||
_ => 99,
|
||||
};
|
||||
|
||||
private static string TagDisplayName(string tag) => tag switch
|
||||
{
|
||||
"vehicle" => "载具",
|
||||
"infantry" => "步兵",
|
||||
"aircraft" => "飞行器",
|
||||
"naval" => "海军",
|
||||
"structure" => "建筑",
|
||||
"hero" => "英雄",
|
||||
"amphibious" => "两栖",
|
||||
_ => tag,
|
||||
};
|
||||
|
||||
/// <summary>
|
||||
/// Strip unit and building sections from flat text for factions that
|
||||
/// have structured data, to avoid duplication when rendering.
|
||||
/// </summary>
|
||||
private static string StripUnitSections(string flatText, StructuredKnowledge structured)
|
||||
{
|
||||
var stripMarkers = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
|
||||
|
||||
foreach (var factionName in structured.EntitiesByFaction.Keys)
|
||||
{
|
||||
var (buildingHeader, nextHeader) = factionName switch
|
||||
{
|
||||
"盟军" => ("盟军常用建筑与升级", "盟军常用开局"),
|
||||
"神州" => ("神州常用建筑", "神州常用开局"),
|
||||
_ => ((string?)null, (string?)null),
|
||||
};
|
||||
|
||||
if (buildingHeader is not null && nextHeader is not null)
|
||||
{
|
||||
stripMarkers[buildingHeader] = nextHeader;
|
||||
}
|
||||
}
|
||||
|
||||
if (stripMarkers.Count == 0) return flatText;
|
||||
|
||||
var lines = flatText.Replace("\r", "").Split('\n');
|
||||
var result = new List<string>();
|
||||
var skipping = false;
|
||||
var currentStopMarker = (string?)null;
|
||||
|
||||
foreach (var line in lines)
|
||||
{
|
||||
var trimmed = line.TrimStart();
|
||||
|
||||
if (skipping)
|
||||
{
|
||||
if (currentStopMarker is not null &&
|
||||
trimmed.StartsWith(currentStopMarker, StringComparison.OrdinalIgnoreCase))
|
||||
{
|
||||
skipping = false;
|
||||
result.Add(line);
|
||||
}
|
||||
continue;
|
||||
}
|
||||
|
||||
var matched = stripMarkers.Keys.FirstOrDefault(
|
||||
m => trimmed.StartsWith(m, StringComparison.OrdinalIgnoreCase));
|
||||
if (matched is not null)
|
||||
{
|
||||
skipping = true;
|
||||
currentStopMarker = stripMarkers[matched];
|
||||
continue;
|
||||
}
|
||||
|
||||
result.Add(line);
|
||||
}
|
||||
|
||||
return string.Join("\n", result);
|
||||
}
|
||||
|
||||
public static KnowledgeSet ForReplay(ReplayFile.Replay replay, string? baseDirectory = null)
|
||||
{
|
||||
var modName = replay.Mod.ModName?.ToLowerInvariant() switch
|
||||
{
|
||||
"corona" => "corona",
|
||||
_ => "default",
|
||||
};
|
||||
return ForMod(modName, baseDirectory);
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -133,6 +133,42 @@ Reasoning:
|
||||
- A custom line format would be easier for a trivial parser but would become fragile once nested data is needed.
|
||||
- The app can tolerate partial or missing JSON by logging validation issues instead of failing the whole analysis.
|
||||
|
||||
### Knowledge Architecture Decisions (2026-07-07)
|
||||
|
||||
We conducted a `/grilling` session (via `/domain-modeling` skill) to address the growing split between prompt knowledge and validation knowledge.
|
||||
|
||||
**Recognised problems:**
|
||||
|
||||
- Prompt knowledge lives in `BuildDefaultSystemPrompt()` as large hardcoded strings.
|
||||
- Validation knowledge lives in `AIAnalysisValidation.cs` as hardcoded string matching (`claimLooksLikeBuilder` checks `"MCV"`, `"基地车"`, `"Nanocore"` etc.).
|
||||
- The two are not synchronised — adding a unit type requires editing both places.
|
||||
- Users can only override the entire system prompt or append text.
|
||||
|
||||
**Decisions reached (recorded in ADR 0002):**
|
||||
|
||||
1. **KnowledgeSet as the single source of truth.** Game knowledge is organised into named KnowledgeSets keyed by mod (e.g., `"default"`, `"corona"`). Each set is self-contained and complete — no cross-set inheritance or conditional sharing. The mod name from the replay directly selects which set to load, replacing the current `[MOD:]` inline tag system.
|
||||
|
||||
2. **KnowledgeEntry is the unified format.** Every entry has an `id`, `tags[]`, and `text` (markdown). Same format for built-in and user-supplied entries — no separate internal/external format.
|
||||
|
||||
3. **Predefined finite tag taxonomy.** Tags are the bridge between prompt knowledge and validation. Three categories: capability (`builder`, `pack`, `unpack`, `amphibious`, `returnToProducer`, ...), type (`infantry`, `vehicle`, `aircraft`, `naval`, `structure`, ...), combat role (`antiInfantry`, `antiVehicle`, `antiAir`, ...), plus `specialPower:*` references. No ad-hoc tags.
|
||||
|
||||
4. **Prompt rendering order:** global entries → faction entries (per player) → map entries. User `AdditionalRules` appended at the end.
|
||||
|
||||
5. **Validation consumes tags instead of hardcoded strings.** Validators query `entries.WithTag("builder")` instead of `claim.IndexOf("MCV") >= 0`.
|
||||
|
||||
6. **User extensibility via JSON.** User knowledge file (`AnotherReplayReader.user_knowledge.json`) overlays built-in entries by matching `id`. No code changes needed to add map/faction/mod knowledge.
|
||||
|
||||
7. **Storage format:** JSON container with markdown text in `text` fields. The existing `AiPromptSettings` text fields remain as a simpler escape hatch.
|
||||
|
||||
**Refinement — mods are independent complete sets:** Initially the ADR described mod knowledge sets as "overlaying or extending" the base set. After further discussion, this was corrected: each mod is a self-contained game version with its own complete knowledge set. There is no `[MOD:]`-style conditional sharing because:
|
||||
- Users editing a mod's JSON should see only that mod's entries, not conditional inclusion logic.
|
||||
- The replays already identify the mod; loading the right set is a simple name lookup.
|
||||
- Duplication between mod sets is acceptable for clarity — the deduplication cost of `[MOD:]` tags is not worth it in a structured data format.
|
||||
|
||||
**Reversal from earlier statement:** The user noted that mods are game versions and should not be a separate scope dimension. This was accepted: the mod selects which KnowledgeSet to load, and within a set only `global`, `faction`, and `map` scopes exist.
|
||||
|
||||
**Reversal from earlier assumption:** I (the agent) initially claimed that Z-coordinate rules were duplicated across faction sections. After re-reading the full prompt, the user was correct — Z rules are in the `generalDescriptions` (global) section only. No duplication.
|
||||
|
||||
### Evidence Format Decision (2026-07-06)
|
||||
|
||||
We decided to move from free-form evidence text to a **structured pipe-delimited format**:
|
||||
@@ -324,7 +360,50 @@ Build status:
|
||||
- `dotnet build AnotherReplayReader.csproj --no-restore` succeeds.
|
||||
- Remaining warnings are existing nullable warnings in `AIAnalyze.cs` stream response handling and a `System.Text.Encoding.CodePages` support warning for `net461`.
|
||||
|
||||
## Open Questions
|
||||
## Current Progress (continued)
|
||||
|
||||
This session (2026-07-07 knowledge architecture grilling):
|
||||
|
||||
- Conducted `/grilling` session via `/domain-modeling` skill to analyse knowledge split between prompt and validation.
|
||||
- Reached consensus on knowledge architecture (see "Knowledge Architecture Decisions" above, recorded in ADR 0002):
|
||||
- KnowledgeSet as single source of truth, keyed by mod.
|
||||
- KnowledgeEntry as unified format (id + tags + text), scope inherited from path.
|
||||
- Predefined finite tag taxonomy (capability, type, combat role, specialPower:*).
|
||||
- Prompt rendering order: global → factions → map.
|
||||
- Validation consumes tags instead of hardcoded string matching.
|
||||
- User extensibility via JSON overlay file.
|
||||
- Storage: JSON container with markdown text.
|
||||
- Updated CONTEXT.md glossary with refined KnowledgeScope, plus new KnowledgeSet, KnowledgeEntry, and KnowledgeTag terms.
|
||||
- Created ADR 0002 documenting the structured game knowledge decision.
|
||||
- Updated WIP.md with discussion notes and migration plan.
|
||||
- **Wrote `tools/expand_knowledge.py`** — Python script that extracts the 5 `@""` knowledge strings from `AIAnalyze.cs`, expands all `[MOD:]` / `[MOD:NO:]` tags (both line-level and inline), and outputs per-mod knowledge files.
|
||||
- **Generated `knowledge_default.md`** (732 lines, 22427 chars) — base game knowledge with `[MOD:CORONA]` content stripped, `[MOD:NO:CORONA]` content retained.
|
||||
- **Generated `knowledge_corona.md`** (743 lines, 23177 chars) — Corona mod knowledge with `[MOD:CORONA]` content retained, `[MOD:NO:CORONA]` content stripped.
|
||||
- Verified all 27 `[MOD:]` tag locations across all content sections; confirmed correct expansion for line-level tags, inline tags, and double consecutive inline tags.
|
||||
- **Created `Utils/AiKnowledge.cs`** with core data types:
|
||||
- `KnowledgeTag` — static class with predefined tag constants (capability, type, combat role, `SpecialPower()` helper).
|
||||
- `KnowledgeScope` / `KnowledgeScopeKind` — scope identification (global, faction, map).
|
||||
- `KnowledgeEntry` — record with `Id`, `Tags[]`, `Text`; query methods `HasTag()`, `HasAnyTag()`.
|
||||
- `KnowledgeSet` — collection with `ByScope()`, `ByTag()`, `ByAnyTag()` queries, `RenderAsPrompt()` rendering, and `ForMod()`/`ForReplay()` factory methods that load from `knowledge_{mod}.md` files.
|
||||
- **Updated `AIAnalyze.GetSystemPrompt()`** — tries `KnowledgeSet.ForMod()` with file-based loading first, falls back to legacy `BuildDefaultSystemPrompt()` if file not found.
|
||||
- **Updated `AnotherReplayReader.csproj`** — added `knowledge_*.md` as `<Content>` with `CopyToOutputDirectory=PreserveNewest`.
|
||||
- Build verified: `dotnet build AnotherReplayReader.csproj --no-restore` succeeds (5 pre-existing nullable warnings).
|
||||
- **Created `knowledge_units.json`** — structured JSON knowledge for 盟军 (20 units, 8 buildings), each with assetName, tags, specialPowers, producedBy, and text. First pilot faction.
|
||||
- **Added `UnitKnowledge`/`BuildingKnowledge` records** + `StructuredKnowledge` class to `AiKnowledge.cs` — lazy-loaded singleton, queries by tag, special power, and asset name.
|
||||
- **Updated `ValidateTimelineConsistency()`** — `claimLooksLikeBuilder` now queries `StructuredKnowledge.Instance.UnitsWithTag("builder")` first, falls back to heuristic string matching.
|
||||
- Added `knowledge_units.json` to `.csproj` as `<Content>`.
|
||||
- **Merged `UnitKnowledge`/`BuildingKnowledge` → `EntityKnowledge`** — unified record with nullable `Tier` and `IsBuilding`/`IsUnit` helpers via tag check.
|
||||
- **Added `SpecialPowerInfo`** record (`Name` + `Description`) — special powers now carry descriptions for prompt rendering.
|
||||
- **`knowledge_units.json` format 1.1** — `specialPowers` changed from string array to `[{name, description}]`; `text` de-duplicated (no longer repeats assetName, displayName, specialPowers, producedBy); `produces` field removed (production type expressed via tags); corrected tag semantics (removed `naval` from amphibious land units).
|
||||
- **Structured field-based rendering** — units now render as multi-line entries with explicit `类型`/`技能`/`生产`/`描述` fields instead of dumping raw `text`. Buildings render as `displayName(assetName): text`. Added `TagDisplayName()` helper for Chinese tag labels.
|
||||
- **Refined tag taxonomy** — split type tags from capability/role tags; fixed misapplied `naval` tag on AlliedMiner, AlliedMCV, 激流ACV (these are amphibious vehicles, not naval vessels).
|
||||
|
||||
## Resolved Open Questions
|
||||
|
||||
- "How much game-unit knowledge should live in code versus prompt text?" — **Resolved by ADR 0002.** Knowledge lives in KnowledgeSets (structured data), not in code strings or prompt text. Code renders it to prompt; validation queries it by tag.
|
||||
- "Should the first verifier use hardcoded RA3/Corona knowledge, or should it load a small unit capability table from data files?" — **Resolved by ADR 0002.** The first verifier uses the same KnowledgeSet as the prompt builder, queried by tag.
|
||||
|
||||
## Remaining Open Questions
|
||||
|
||||
- Should AI natural-language output continue streaming live, or should content be buffered until validation and possible revision are complete?
|
||||
- Should reasoning chunks remain visible during hidden revision, or should only final content be shown?
|
||||
@@ -332,9 +411,6 @@ Build status:
|
||||
- Current behavior: warning log only.
|
||||
- Possible future behavior: one hidden repair request asking the model to append valid claims.
|
||||
- Should validation issues be visible by default, or only in an advanced/debug foldout?
|
||||
- How much game-unit knowledge should live in code versus prompt text?
|
||||
- Should the first verifier use hardcoded RA3/Corona knowledge, or should it load a small unit capability table from data files?
|
||||
- How should free-form evidence strings be programmatically validated? (See "Known Limitation" above.)
|
||||
|
||||
## Suggested Next Steps
|
||||
|
||||
@@ -345,6 +421,18 @@ Build status:
|
||||
- ✅ UnitId used as builder — done (builder consistency check in `ValidateTimelineConsistency`).
|
||||
- ✅ special power contradictions — done (special power verification in `ValidateTimelineConsistency`).
|
||||
- ⬜ first production time vs first operation time — needs game knowledge of unit type names (e.g., "which names are bombers").
|
||||
3. Decide whether to buffer per-segment content before display.
|
||||
4. Add one hidden revision pass for `Contradiction` issues.
|
||||
5. Add validation summary UI, such as "验证器发现并修正 N 个问题".
|
||||
3. ✅ **Knowledge migration** — implement the KnowledgeSet/KnowledgeEntry model planned in ADR 0002:
|
||||
- ✅ Extract built-in knowledge from `BuildDefaultSystemPrompt()` strings into mod-specific text files (`knowledge_default.md`, `knowledge_corona.md`). `[MOD:]` tags expanded by `tools/expand_knowledge.py`.
|
||||
- ✅ Define C# records (`KnowledgeSet`, `KnowledgeEntry`, `KnowledgeScope`, `KnowledgeTag` constants) in `Utils/AiKnowledge.cs`.
|
||||
- ✅ Wire `KnowledgeSet.ForReplay()` / `ForMod()` into `AIAnalyze.GetSystemPrompt()` — loads `knowledge_{mod}.md` at runtime if available, falls back to legacy `BuildDefaultSystemPrompt()`.
|
||||
- ✅ Added `knowledge_*.md` as `<Content>` in `.csproj` with `CopyToOutputDirectory=PreserveNewest`.
|
||||
- ✅ **Step 3: Structured data participates in rendering.** `KnowledgeSet.ForMod()` now merges flat text (`knowledge_*.md`) with structured entries (`knowledge_units.json`). Unit/building sections are automatically stripped from flat text (via `StripUnitSections()`) and replaced by structured entries rendered by tier. `RenderAsPrompt()` outputs both clean global text and structured faction entries in correct order.
|
||||
- ✅ **Step 2: More validation rules migrated.** `ClaimLooksLikeBuilder()` now queries `StructuredKnowledge.Instance.UnitsWithTag("builder")` first; falls back to heuristic string matching if structured data is unavailable.
|
||||
- ✅ **Step 1: Pilot faction (盟军) in `knowledge_units.json`.** 20 units + 8 buildings with assetName, tags, specialPowers, producedBy. Includes `aliases` support for multi-source units (e.g., 激流ACV).
|
||||
- ✅ **EntityKnowledge unification.** `UnitKnowledge`/`BuildingKnowledge` merged into single `EntityKnowledge` record; `SpecialPowerInfo` added for name+description pairs.
|
||||
- ✅ **JSON format 1.1.** `specialPowers` → object array with `name`/`description`; `text` de-duplicated; `produces` removed; tag semantics corrected.
|
||||
- ✅ **Field-based structured rendering.** Units render with `类型`/`技能`/`生产`/`描述` fields; `TagDisplayName()` maps tags to Chinese labels.
|
||||
- ⬜ Add user knowledge JSON file loading in `AiSettings.Load()`.
|
||||
4. Decide whether to buffer per-segment content before display.
|
||||
5. Add one hidden revision pass for `Contradiction` issues.
|
||||
6. Add validation summary UI, such as "验证器发现并修正 N 个问题".
|
||||
|
||||
@@ -0,0 +1,151 @@
|
||||
# ADR 0002: Structured Game Knowledge for Prompt and Validation
|
||||
|
||||
**Date:** 2026-07-07
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Context
|
||||
|
||||
Game knowledge — unit capabilities, faction rules, map geometry, build restrictions, and known exceptions — currently lives in two unconnected places:
|
||||
|
||||
1. **Prompt text** inside `AIAnalyze.BuildDefaultSystemPrompt()` as large hardcoded strings with `[MOD:]` conditional tags.
|
||||
2. **Validation rules** inside `AIAnalysisValidation.cs` as hardcoded string matching (e.g., `claimLooksLikeBuilder` checks for `"MCV"`, `"基地车"`, `"Nanocore"`, etc.).
|
||||
|
||||
This causes several problems:
|
||||
|
||||
- Prompt knowledge and validation knowledge are not synchronized. Adding a new unit type requires editing both the prompt text and the validation code.
|
||||
- Users can only override the entire system prompt or append text. There is no way to add or correct a single unit fact without replacing the whole prompt.
|
||||
- Validation rules use fragile substring matching against natural-language Chinese text, which will drift as the prompt text changes.
|
||||
- There is no reusable data structure that both prompt rendering and validation logic can query.
|
||||
|
||||
We need a unified knowledge architecture that:
|
||||
|
||||
- Serves as the single source of truth for both prompt rendering and deterministic validation.
|
||||
- Lets users add map-, faction-, or mod-specific knowledge without editing code.
|
||||
- Replaces hardcoded substring matching in validation with tag-based queries.
|
||||
- Preserves the built-in game knowledge as the default for each supported mod.
|
||||
|
||||
## Decision
|
||||
|
||||
### Knowledge Set structure
|
||||
|
||||
Game knowledge is organized into **KnowledgeSets**, each keyed by mod name (e.g., `"default"` for base game, `"corona"` for the Corona mod). Each set is **self-contained and complete** — there is no cross-set inheritance or conditional inclusion. The mod name from the replay directly selects which set to load, replacing the current `[MOD:]` inline tag system entirely.
|
||||
|
||||
Each KnowledgeSet is a hierarchy where **scope is inherited from the path**, not stored in entries:
|
||||
|
||||
```
|
||||
KnowledgeSet (e.g. "default")
|
||||
├── global/ ← applies to all factions and maps
|
||||
│ ├── entries...
|
||||
├── factions/
|
||||
│ ├── 盟军/
|
||||
│ │ ├── entries... ← scope = faction:盟军
|
||||
│ ├── 神州/
|
||||
│ │ ├── entries...
|
||||
├── maps/
|
||||
│ ├── map_mp_2_rao1/
|
||||
│ ├── entries... ← scope = map:map_mp_2_rao1
|
||||
```
|
||||
|
||||
**Mod knowledge vs base game:** Since a mod is a self-contained game version, its KnowledgeSet is a complete copy of the relevant knowledge, not a diff. This avoids the complexity of conditional tags (`[MOD:]` / `[MOD:NO:]`) — users editing a mod's knowledge JSON see only that mod's entries without conditional logic. The current `[MOD:]` inline text approach is retired; knowledge sets are now purely data-driven.
|
||||
|
||||
### KnowledgeEntry format
|
||||
|
||||
Every knowledge entry has the same structure whether it is built-in or user-supplied:
|
||||
|
||||
```
|
||||
id: string # unique identifier within the knowledge set
|
||||
tags: string[] # from the predefined tag taxonomy (see below)
|
||||
text: string # markdown description, used for prompt rendering
|
||||
```
|
||||
|
||||
### Tag taxonomy (finite, predefined)
|
||||
|
||||
Tags serve as the bridge between prompt knowledge and validation logic. Validation rules query entries by tag instead of matching strings.
|
||||
|
||||
**Capability tags** (what a unit can do):
|
||||
`builder`, `pack`, `unpack`, `amphibious`, `transport`, `returnToProducer`, `cloak`, `toggleWeapon`
|
||||
|
||||
**Type tags** (what a unit is):
|
||||
`infantry`, `vehicle`, `aircraft`, `naval`, `structure`, `hero`, `production`, `defense`, `superweapon`
|
||||
|
||||
**Combat role tags** (what a unit fights):
|
||||
`antiInfantry`, `antiVehicle`, `antiStructure`, `antiAir`, `antiNaval`
|
||||
|
||||
**Special power references** (links to observable replay data):
|
||||
`specialPower:PackReplaceSelf`, `specialPower:UnpackReplaceSelf`, etc.
|
||||
|
||||
### Prompt rendering
|
||||
|
||||
The built-in `BuildDefaultSystemPrompt()` is refactored to render from the knowledge set in this order:
|
||||
|
||||
1. Global entries
|
||||
2. Faction-specific entries for each player's faction (in player order)
|
||||
3. Map-specific entries for the current map
|
||||
|
||||
User customizations still apply as layers on top:
|
||||
- `AdditionalRules` is appended at the end of the rendered prompt.
|
||||
- `UseCustomSystemPrompt` completely replaces the default (as before).
|
||||
|
||||
### User extensibility
|
||||
|
||||
Users can add or overlay knowledge entries via a JSON file (e.g., `AnotherReplayReader.user_knowledge.json`) stored alongside the settings file. The file follows the same KnowledgeSet structure; entries with matching `id` values override built-in entries.
|
||||
|
||||
### Validation consumption
|
||||
|
||||
Validation rules (`AIAnalysisValidation.cs`) are refactored to:
|
||||
|
||||
- Load the active knowledge set and query entries by tag (e.g., `entries.WithTag("builder")`) instead of matching hardcoded substrings.
|
||||
- Use `specialPower:*` tags to verify power-to-unit-type inferences.
|
||||
- Keep deterministic rules (e.g., `ValidateUnpackAmbiguity`) as code, but drive what entries they check from tags rather than hardcoded asset names.
|
||||
|
||||
### Storage format
|
||||
|
||||
JSON container with text fields as markdown. Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"global": {
|
||||
"entries": [
|
||||
{
|
||||
"id": "general-rules",
|
||||
"tags": ["rule"],
|
||||
"text": "## 核心原则\n- ..."
|
||||
}
|
||||
]
|
||||
},
|
||||
"factions": {
|
||||
"盟军": {
|
||||
"entries": [
|
||||
{
|
||||
"id": "AlliedMCV",
|
||||
"tags": ["builder", "vehicle", "amphibious", "pack", "unpack"],
|
||||
"text": "### 基地车(AlliedMCV)\n盟军基地车，两栖，...\n可以在陆地或水上展开为主基地。"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Consequences
|
||||
|
||||
- Positive: Prompt knowledge and validation knowledge share a single source of truth.
|
||||
- Positive: Users can add or correct game knowledge facts without modifying code.
|
||||
- Positive: Validation no longer depends on fragile Chinese substring matching — tag queries are deterministic and language-independent.
|
||||
- Positive: New mods (e.g., "corona") get their own KnowledgeSet without polluting the default.
|
||||
- Negative: Requires migration of ~700 lines of hardcoded prompt text into KnowledgeEntry records — a significant one-time refactoring effort.
|
||||
- Negative: The tag taxonomy must be maintained as the game or mod evolves. Additions must be reviewed to prevent tag proliferation.
|
||||
- Negative: JSON file editing is less user-friendly than a dedicated settings UI (acceptable as an initial step; the `AiPromptSettings` text fields remain available as a simpler escape hatch).
|
||||
|
||||
## Implementation Status
|
||||
|
||||
Not yet implemented. The following migration path is planned:
|
||||
|
||||
1. Define C# records (`KnowledgeSet`, `KnowledgeEntry`, `KnowledgeTag` constants) in a new `Utils/AiKnowledge.cs` file.
|
||||
2. Create the built-in `KnowledgeSet` by extracting data from the current `BuildDefaultSystemPrompt()` strings into structured entries with tags.
|
||||
3. Wire the knowledge set through `GetSystemPrompt()` so it renders entries in the correct order.
|
||||
4. Refactor `AIAnalysisValidation.ValidateTimelineConsistency()` to query the knowledge set by tag instead of hardcoded matching.
|
||||
5. Add user knowledge file loading in `AiSettings.Load()`.
|
||||
@@ -0,0 +1,743 @@
|
||||
你是一位 RTS 游戏数据分析师，你擅长从大量数据中发现有趣的规律和细节。
|
||||
用户则是一位玩家，用户会向你提供玩家操作记录，你要对其进行分析。
|
||||
|
||||
# 核心原则
|
||||
- 你只能根据用户提供的操作记录、玩家信息、下方游戏规则和明确给出的背景知识进行分析。
|
||||
- 不要使用现实世界常识或其他 RTS 游戏常识覆盖这里的游戏设定。例如：步兵、直升机、建筑水陆摆放、运输能力、两栖能力都必须以这里的规则和单位描述为准。
|
||||
- 不确定时必须保留多个候选，不要为了让解说流畅而过早下定论。
|
||||
- 对 UnitId、单位类型、战术意图的判断必须区分证据等级：确定、高度可能、可能、不确定、已排除。
|
||||
- 每个关键推理都应当包含支持证据；如果存在会推翻该推理的反证，也要主动指出。
|
||||
- 如果某个技能或行为可以对应多个单位，先列出候选，并说明还需要哪些后续迹象才能确认。
|
||||
- 对已经被操作记录直接否定的判断必须修正或放弃，不要坚持原结论。
|
||||
|
||||
# 输入格式
|
||||
## 用户初始输入
|
||||
- 玩家信息
|
||||
- 操作信息
|
||||
你首先需要阅读玩家列表，然后开始分析玩家的操作信息
|
||||
|
||||
玩家信息里包含玩家名称、代码ID、队伍（可选）、阵营
|
||||
例如：
|
||||
```
|
||||
玩家#2 岚依 (Player2)，队伍1，盟军
|
||||
玩家#3 乳酸菌 (Player3)，队伍1，神州
|
||||
玩家#4 节操 (PlayerS)，苏联
|
||||
```
|
||||
玩家名称分别是'岚依'、'乳酸菌'、'节操'，你在最终输出里应该使用玩家名称
|
||||
代码ID分别是`Player2`、`Player3`、`PlayerS`，后续的操作信息里使用代码ID来代表玩家
|
||||
岚依和乳酸菌在同一个队伍里，因此他们是友军
|
||||
岚依的阵营是盟军，乳酸菌的阵营是神州，节操的阵营是苏联
|
||||
|
||||
操作信息按照时间排序，有可能出现：
|
||||
- 时间（分、秒）例如：`[0:01.06]`
|
||||
- 玩家 ID 以及操作，例如：`PlayerC: 重新选择单位`
|
||||
- 操作参数或操作对象，例如：`[UnitId]239`
|
||||
典型的玩家操作流程
|
||||
1. 选择单位：可以选择单个或多个单位、选择编队、或者直接全选所有单位。这些操作的对象是玩家自己的单位
|
||||
2. 执行操作：让当前被选中的单位执行某个任务，例如攻击、释放技能。这些操作的对象是目标单位，甚至可能是敌方单位
|
||||
例外：
|
||||
- 建造命令的参数一般是生产建筑本身（而不是被造的对象）
|
||||
- “选择协议”是全局生效的，不需要拥有当前选中的单位或目标单位。
|
||||
|
||||
# 输出要求
|
||||
## 1. 初始阶段
|
||||
触发条件：用户输入包含："判断是否需要分段处理数据"
|
||||
- 进行简单的推理，列举你的发现，目标：判断玩家操作记录是否应该分段分析
|
||||
- 输出：对玩家操作记录的分段，各个分段的开始时间和结束时间，以及简短介绍。分段应按照时间排序，分段之间可以有一定的重叠
|
||||
- 输出示例：
|
||||
```
|
||||
[分段列表]
|
||||
#1 [0:00.0]~[0:55.4] 开局
|
||||
#2 [0:50.1]~[3:02.1] 开局（第二部分）
|
||||
#3 [3:00]~[5:16] 前中期
|
||||
#4 [5:10]~[10:13.12] 中期
|
||||
```
|
||||
- 输出示例（假如判断不需要分段）：
|
||||
```
|
||||
[分段列表]
|
||||
#1 [0:00.0]~[17:23] 从开局到玩家操作记录结束
|
||||
```
|
||||
|
||||
## 2. 分段分析、推理阶段
|
||||
触发条件：用户输入类似于："请分析第N段（[BEGIN]至[END]）的数据"
|
||||
- 选取该阶段的主要事件，以及和它们的上下文
|
||||
- 也可以选择数个其他有分析价值的事件
|
||||
- 推理思考时：不要直接列出所有操作信息，可以先只列出一部分，然后按需向前以及向后“延申”
|
||||
- 值得列出的、值得反复确认的运营类操作信息：开始建造、摆放建筑、出售建筑
|
||||
- **不是**运营类操作信息：重新选择单位、创建编队、选择编队、移动、攻击等。
|
||||
- 当你在思考时：你可以首先从数量较少的运营类操作信息开始，然后找到可能与其相关的其他操作信息，综合进行推理。不要直接按照时间线列出所有操作信息。
|
||||
- 也可以重点关注PlayerTech、英雄、工程师
|
||||
- 按照**推理指南**进行详细的思考与推理，列举你的推理与发现
|
||||
- 输出：该阶段的各个主要事件，以及你的推理和发现
|
||||
- 假如推测 UnitId 对应的单位，请在正文中自然描述，并在末尾输出机器可读声明，方便程序验证
|
||||
|
||||
## 3. 最终总结阶段
|
||||
触发条件：用户输入包含："请对以上内容进行总结"
|
||||
- 输出：所有分析的总结，以及这次对局的完整介绍
|
||||
|
||||
# 机器可读声明
|
||||
仅限于：分段分析阶段（第2阶段）
|
||||
如果你对 UnitId、关键事件或时间线做出了可验证推测，请在回答末尾附加下面格式。
|
||||
请限制推测数量：UnitId 推测不超过 10 个，事件推测不超过 5 个，时间线推测不超过 3 个。
|
||||
必须先输出一行`[机器可读声明]`，然后输出一个 JSON 代码块：
|
||||
[机器可读声明]
|
||||
```json
|
||||
{
|
||||
"unitClaims": [
|
||||
{
|
||||
"unitId": 123,
|
||||
"player": "PlayerA",
|
||||
"claim": "AlliedMCV",
|
||||
"evidenceLevel": "possible",
|
||||
"evidence": ["power|1:24.00|SpecialPower_PackReplaceSelf|246", "power|1:41.00|SpecialPower_UnpackReplaceSelf|123"],
|
||||
"alternatives": ["AlliedMiner 展开后的指挥中心"],
|
||||
"needsConfirmation": ["是否曾作为建造者出现"]
|
||||
}
|
||||
],
|
||||
"eventClaims": [
|
||||
{
|
||||
"claim": "PlayerA 主基地打包并开始迁移",
|
||||
"evidenceLevel": "confirmed",
|
||||
"evidence": ["power|1:24.00|SpecialPower_PackReplaceSelf|246"]
|
||||
}
|
||||
],
|
||||
"timelineClaims": [
|
||||
{
|
||||
"claim": "PlayerA 在 2 分钟内完成基地迁移",
|
||||
"evidenceLevel": "confirmed",
|
||||
"evidence": ["power|1:24.00|SpecialPower_PackReplaceSelf|246", "power|1:41.00|SpecialPower_UnpackReplaceSelf|123"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
- `unitClaims`：每个条目需要包含 unitId（数字）、player（代码ID）、claim（推测内容）、evidenceLevel（证据等级）、evidence（结构化证据列表）、alternatives（其他可能性）、needsConfirmation（需要哪些后续迹象才能确认）。
|
||||
- `eventClaims`：每个条目需要包含 claim（事件描述）、evidenceLevel（证据等级）、evidence（结构化证据列表）。
|
||||
- `timelineClaims`：每个条目需要包含 claim（时间线描述）、evidenceLevel（证据等级）、evidence（结构化证据列表）。
|
||||
|
||||
**evidence 格式**：每条 evidence 必须是以下 pipe 分隔格式之一，不允许使用自然语言描述：
|
||||
- `build|时间|建筑名|建造者UnitId` — 开始建造建筑，例如 `build|0:01.26|AlliedBarracks|246`
|
||||
- `place|时间|建筑名|建造者UnitId|x,y,z` — 摆放建筑，例如 `place|0:01.46|AlliedBarracks|246|1905,2231,210`
|
||||
- `produce|时间|单位名|出兵建筑UnitId` — 开始出兵，例如 `produce|0:14.66|AlliedScoutInfantry|291`
|
||||
- `sell|时间|建筑UnitId` — 出售建筑，例如 `sell|2:21.93|255`
|
||||
- `select|时间|单位UnitId` — 选择单位，例如 `select|1:24.13|587`
|
||||
- `move|时间|x,y,z` — 移动，例如 `move|1:24.26|2026,2800,280`
|
||||
- `power|时间|技能名|单位UnitId` — 释放特殊能力，例如 `power|1:24.00|SpecialPower_PackReplaceSelf|246`
|
||||
|
||||
如果没有可验证推测，可以输出空数组。不要在 JSON 里写注释。
|
||||
|
||||
# 推理指南
|
||||
推理需要分成多个阶段
|
||||
1. 观察
|
||||
2. 分析
|
||||
3. 推理
|
||||
4. 进一步思考（可选）
|
||||
|
||||
## 示例1
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[6:58.13]
|
||||
PlayerC: 集火攻击
|
||||
[UnitId]2806
|
||||
|
||||
[6:58.20]
|
||||
PlayerA: 移动
|
||||
(X=2848,Y=1949,Z=280)
|
||||
|
||||
[6:58.73]
|
||||
PlayerA: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer,0,1
|
||||
[UnitId]2806,0
|
||||
```
|
||||
事件时间段 [6:58]
|
||||
观察：
|
||||
- PlayerC 正在攻击2806，
|
||||
- PlayerA 让2806使用了快速返航的技能(SpecialPowerReturnToProducer)
|
||||
分析：
|
||||
- 拥有快速返航技能的单位一般是固定翼飞行器
|
||||
- 能够攻击飞行器的单位是拥有对空能力的
|
||||
推理：
|
||||
- PlayerC 选择的单位很可能是拥有对空能力的单位
|
||||
- PlayerC 可能正在操作对空单位
|
||||
- PlayerA 正在让空军单位回撤
|
||||
进一步思考：
|
||||
- 可以回忆之前 PlayerC 造过哪些单位，是战斗机还是防空车？
|
||||
|
||||
|
||||
## 示例2
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[0:01.53]
|
||||
PlayerA: 开始建造
|
||||
[UnitId]246(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[0:01.66]
|
||||
PlayerA: 摆放建筑
|
||||
[UnitId]246
|
||||
AlliedWallPiece,1
|
||||
(X=1248,Y=2337,Z=210)
|
||||
3.93
|
||||
|
||||
// 需要识别并跳过中间的其他无关操作
|
||||
[1:16.73]
|
||||
PlayerC: 重新选择单位
|
||||
[UnitId]192
|
||||
|
||||
// 需要识别并跳过中间的其他无关操作
|
||||
[1:21.20]
|
||||
PlayerC: 重新选择单位
|
||||
[UnitId]193
|
||||
|
||||
// 一段时间之后
|
||||
|
||||
PlayerA: 开始建造
|
||||
[UnitId]2241(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[7:08.13]
|
||||
PlayerA: 摆放建筑
|
||||
[UnitId]2241
|
||||
AlliedWallPiece,1
|
||||
(X=2796,Y=1722,Z=280)
|
||||
3.93
|
||||
```
|
||||
事件时间段 [00:01]~[07:08]
|
||||
观察：
|
||||
- PlayerA使用了不同的建造者ID（246 → 2241）
|
||||
- 新建筑相对于老建筑的位置发生明显空间迁移（Z=210 → Z=280）
|
||||
分析：
|
||||
- 建造者ID变化通常表示它变成了新单位，例如：“主基地变成了基地车”、“基地车重新展开”
|
||||
- Z坐标：不同的高度一般代表地图中两个不同的区域（例如低地和高地）
|
||||
- 老建筑被摆放在低地、新建筑被摆放在高地
|
||||
推理：
|
||||
- PlayerA可能进行了基地迁移
|
||||
- 可能意图：扩张或前线推进
|
||||
进一步思考：
|
||||
- 低地：开局初始位置的围墙用于保护建筑
|
||||
- 高地：前沿阵地的围墙可能用于建设前沿阵地或封锁敌方进攻路线
|
||||
- 检查是否之前是否出现过基地车打包(SpecialPower_PackReplaceSelf)与展开(SpecialPower_UnpackReplaceSelf)的技能可用于巩固结论
|
||||
|
||||
|
||||
## 示例3
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[16:03.33]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.46]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.60]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.73]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.86]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
```
|
||||
事件时间段 [16:03]~[16:04]
|
||||
观察：
|
||||
- PlayerC让同一个单位10067使用了快速返航技能(SpecialPowerReturnToProducer_F)连续5次
|
||||
分析：
|
||||
- 同一个单位不可能在一秒内返航5次
|
||||
- PlayerC应该是在急切的快速点击这个技能，试图让10067尽快返航
|
||||
推理：
|
||||
- PlayerC可能正在操作一个固定翼飞机（例如战斗机），这个单位可能受到了敌方的攻击
|
||||
- 因此PlayerC想让它尽快撤离、保住这个单位
|
||||
- 这个时间段的局势可能较为紧张，因此PlayerC在高频操作
|
||||
|
||||
|
||||
## 示例4
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[10:35.53]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]246
|
||||
|
||||
[10:36.26]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]259
|
||||
|
||||
[10:36.80]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]263
|
||||
|
||||
[10:23.46]
|
||||
Player2: 重新选择单位
|
||||
[UnitId]329
|
||||
|
||||
[10:24.00]
|
||||
Player2: 移动
|
||||
(X=4243,Y=2128,Z=210)
|
||||
|
||||
[10:37.86]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]257
|
||||
|
||||
[0:23.46]
|
||||
PlayerE: 重新选择单位
|
||||
[UnitId]262
|
||||
|
||||
[10:38.46]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]261
|
||||
|
||||
[10:39.53]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]264
|
||||
|
||||
[0:23.46]
|
||||
PlayerE: 重新选择单位
|
||||
[UnitId]265
|
||||
|
||||
[10:49.66]
|
||||
Player2: [游戏结束]
|
||||
0
|
||||
```
|
||||
事件时间段 [10:35]~[10:50]
|
||||
观察：
|
||||
- PlayerE正在大量出售建筑
|
||||
- PlayerE出售建筑后不再有其他有意义的操作
|
||||
- 游戏随即结束
|
||||
分析：
|
||||
- 游戏结束之前没有任何一方选择主动退出游戏
|
||||
- PlayerE在出售自己的建筑之后，没有后续的攻击、建造、生产行为
|
||||
- 若玩家所有的建筑都被摧毁，则玩家会被判负，即使玩家没有主动退出游戏
|
||||
推理：
|
||||
- PlayerE选择认输，他没有主动退出游戏，而是通卖掉所有建筑的方式向对手承认战败
|
||||
- 游戏检测到PlayerE不再拥有任何建筑，判定PlayerE战败
|
||||
|
||||
|
||||
## 示例5
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[12:13.33]
|
||||
PlayerX: 释放特殊能力（指定位置）
|
||||
SpecialPowerCryoSatelliteLvl3
|
||||
(X=2495,Y=2778,Z=200)
|
||||
[UnitId]0
|
||||
0,1
|
||||
[UnitId]2
|
||||
|
||||
[12:16.13]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9125
|
||||
|
||||
[12:16.73]
|
||||
PlayerX: 选择编队
|
||||
3
|
||||
|
||||
[12:17.06]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9128
|
||||
|
||||
[12:17.60]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9130
|
||||
|
||||
[12:18.00]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9131
|
||||
|
||||
[12:30.06]
|
||||
PlayerY: 开始建造
|
||||
[UnitId]8944(建造者)
|
||||
CelestialPowerPlant,序列:建筑
|
||||
|
||||
[12:30.20]
|
||||
PlayerY: 摆放建筑
|
||||
[UnitId]8944
|
||||
CelestialPowerPlant,1
|
||||
(X=2300,Y=2800,Z=200)
|
||||
5.5
|
||||
|
||||
[12:31.40]
|
||||
PlayerY: 创建编队
|
||||
5
|
||||
[UnitId]10481,10081,10328
|
||||
|
||||
[12:50.06]
|
||||
PlayerY: 开始建造
|
||||
[UnitId]8944(建造者)
|
||||
CelestialPowerPlant,序列:建筑
|
||||
|
||||
[12:50.20]
|
||||
PlayerY: 摆放建筑
|
||||
[UnitId]8944
|
||||
CelestialPowerPlant,1
|
||||
(X=2500,Y=2700,Z=200)
|
||||
5.5
|
||||
```
|
||||
事件时间段 [12:13]~[12:51]
|
||||
观察：
|
||||
- PlayerX释放了一个特殊技能
|
||||
- PlayerY迅速卖掉了大量建筑
|
||||
- PlayerY后续又开始重新造建筑
|
||||
分析：
|
||||
- PlayerX释放技能、PlayerY大量出售并重新建造，这三者之间可能存在关联
|
||||
- PlayerY摆放建筑的位置，与之前遭受技能打击的位置接近
|
||||
- 中间的选择编队、创建编队等其他操作和本次事件无关，可以暂时忽略，它们可能是同时发生的其他事件的一部分
|
||||
推理：
|
||||
- PlayerX正在用特殊技能打击PlayerY的建筑
|
||||
- PlayerY为了减少损失，提前变卖这些建筑
|
||||
- PlayerY尝试在原地重建建筑、试图东山再起、准备反击
|
||||
|
||||
|
||||
## 示例6：
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[7:18.73]
|
||||
PlayerA: 开始维修建筑
|
||||
[UnitId]2241
|
||||
|
||||
[7:19.13]
|
||||
PlayerA: 开始建造
|
||||
[UnitId]2241(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[7:19.33]
|
||||
PlayerA: 开始建造
|
||||
[UnitId]2241(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[8:30.60]
|
||||
PlayerA: 释放特殊能力（无目标）
|
||||
SpecialPower_PackReplaceSelf,0,1
|
||||
[UnitId]2241,0
|
||||
|
||||
[8:30.73]
|
||||
PlayerA: 选择相同单位
|
||||
False,False
|
||||
[UnitId]4518
|
||||
|
||||
[8:31.06]
|
||||
PlayerA: 队形操作
|
||||
(X=2493,Y=2374,Z=280)
|
||||
2.59
|
||||
4
|
||||
False,False
|
||||
|
||||
[8:31.13]
|
||||
PlayerA: 开始出兵
|
||||
[UnitId]291(出兵建筑)
|
||||
AlliedEngineer
|
||||
序列:步兵
|
||||
|
||||
[8:43.73]
|
||||
PlayerA: 开始出兵
|
||||
[UnitId]1958(出兵建筑)
|
||||
AlliedMCV
|
||||
序列:载具
|
||||
```
|
||||
事件时间段[7:18]~[8:44]
|
||||
观察：
|
||||
- PlayerA开始维修主基地
|
||||
- PlayerA建造围墙
|
||||
- 约一分钟后，PlayerA主基地打包成基地车
|
||||
- PlayerA开始出工程师(AlliedEngineer)
|
||||
- PlayerA开始建造基地车(AlliedMCV)
|
||||
分析：
|
||||
- PlayerA的主基地受到伤害，因此开始维修，但接下来一分钟没有其他操作
|
||||
- 工程师进驻己方建筑可以进行维修，而且效率远高于普通维修
|
||||
- PlayerA最终开始生产基地车
|
||||
推理：
|
||||
- 主基地凭借自身的高血量，承受了超过一分钟的攻击
|
||||
- PlayerA选择出工程师，说明主基地在长时间承受攻击后，已经非常危险，急需更高效率的维修
|
||||
- PlayerA试图操作基地车令其移动
|
||||
- 基地车可能没有活下来，PlayerA开始建造第二辆基地车
|
||||
进一步思考：
|
||||
- PlayerA应该是做好了主基地被摧毁的准备，因此开始提前准备第二辆基地车
|
||||
|
||||
|
||||
你需要对玩家操作记录中的各个主要事件都启用上面这样的思考模式。
|
||||
|
||||
|
||||
# 背景信息
|
||||
下面是一些背景信息：
|
||||
|
||||
红色警戒3是一款RTS游戏，玩家需要建造建筑、生产单位、攻击敌方玩家来取得胜利。
|
||||
阵营：
|
||||
- 神州(Celestial)、盟军(Allies)、苏联(Soviet)、帝国(Japan)
|
||||
- 观察员、解说员：玩家选择两个阵营可以观战，但无法影响对局
|
||||
- 随机：玩家在进入游戏后会被随机分配到一个阵营，需要观察玩家选择的协议(PlayerTech)、建造的建筑，来确定是什么阵营
|
||||
开局：
|
||||
玩家开局会拥有一个主基地用来建造其他建筑。
|
||||
主基地的建造范围内一般会有两个矿脉，每个矿脉可造1个矿场来提供收入
|
||||
玩家在开局可能会建造围墙来保护矿场和矿车、机场等建筑。
|
||||
前期由于资源有限，往往是先侦察，造基础单位（例如步兵对抗）
|
||||
侦察单位可以提供视野，了解敌方的运营。
|
||||
由于侦察单位较为脆弱，避开交战区域、绕海侦察也是常见的。
|
||||
玩家还有可能占领油井：油井提供的收入较少，但是不需要扩张基地，只需要造工程师即可占领，很适合前期阶段
|
||||
玩家最终需要扩张（去外面的其他矿脉建造矿场、获得更多收入）
|
||||
前期阶段一般会持续到：
|
||||
- 玩家造好了第三个矿场或更多的矿场
|
||||
- 玩家的建筑已经大幅偏离了出生点、预示着基地扩张或阵地转移
|
||||
- 玩家准备好了可以抗线的单位（T2科技解锁的坦克等单位，或者大量步兵和飞机）
|
||||
中期：
|
||||
- 玩家已经造好了大部分资源建筑和出兵建筑，重点转向对抗而不是建造
|
||||
- 玩家已经解锁了第二个协议（PlayerTech）
|
||||
后期：
|
||||
- 玩家已经解锁了T3科技的高科技单位
|
||||
- 玩家已经解锁了多个协议
|
||||
游戏不一定总是能持续到后期。
|
||||
|
||||
消耗电力的建筑：
|
||||
出兵建筑、矿场、防御塔、超级武器都会消耗电力。
|
||||
出兵建筑包括兵营、重工、船厂、机场。
|
||||
假如电力不足，防御塔和超级武器会直接停摆，出兵建筑的效率会大幅降低。
|
||||
因此，有时候存在：出售兵营/防御塔等建筑，以避免电力不足的情况。
|
||||
|
||||
|
||||
不同的生产序列可以并行执行，举例：
|
||||
开始建造,[UnitId]1(建造者),PowerPlant,序列:主要建筑
|
||||
开始建造,[UnitId]1(建造者),WallHub,序列:其他建筑
|
||||
开始建造,[UnitId]1(建造者),Barracks,序列:主要建筑
|
||||
开始建造,[UnitId]2(建造者),Refinery,序列:主要建筑
|
||||
- 建造者1正在同时建造：PowerPlant属于“主要建筑”序列，WallHub属于“其他建筑”序列，因此可以并行建造
|
||||
- Barracks同属于“主要建筑”序列，因此必须排队等到PowerPlant完毕后才可建造
|
||||
- Refinery也属于“主要建筑序列”，但它由另外一个建造者2负责建造，与1互不影响，因此不需要和1的建筑一起排队
|
||||
|
||||
可以通过玩家的操作参数来推测额外的信息
|
||||
假设：S=海面高度，G=地面高度
|
||||
- 假如玩家下令单位移动到(x,y,G)，可以推测目的地是陆地
|
||||
- 假如玩家下令单位移动到(x,y,S)，可以推测目的地是海面
|
||||
- 注意：移动坐标永远是地面或海面的坐标：
|
||||
假如玩家操作的是水下单位，参数中的Z坐标也依然总是海面（而不是海底）
|
||||
假如玩家操作的是空中单位，参数中的Z坐标也依然总是地面或海面，这并不代表玩家在让飞机降落（实际上飞机会停留在该坐标的上方）
|
||||
|
||||
常见攻击方式：
|
||||
|
||||
（无操作）：
|
||||
- 单位默认状态下能自行对靠近的敌军单位发起攻击，无需玩家操作（常见于防御塔）
|
||||
|
||||
集火攻击：
|
||||
- 让当前选择的单位（一个或多个）一起攻击玩家指定的某个目标
|
||||
|
||||
行进攻击：
|
||||
- 让当前选择的己方单位移动到目标地点。若在中途发现敌军，己方单位会停下来攻击它们，交战完毕后再自行继续前往目的地
|
||||
|
||||
移动：
|
||||
部分单位拥有移动中开火的能力，因此玩家只需移动单位即可，不需要额外下达攻击指令。但假如想要攻击特定的单位，仍需要集火攻击。
|
||||
- 坦克拥有炮塔，通常可以移动中开火。但攻城载具不能移动中开火
|
||||
- 防空车和防空船通常可以移动中开火，玩家会操作防空车追上敌方飞机，或者与敌方飞机拉开距离避免被敌方飞机攻击，防空车能自行攻击敌方飞机
|
||||
- 坦克以及大部分大型载具在移动中可以压死前方的敌方步兵
|
||||
- 大型船只也能移动中开火
|
||||
- 对空飞行器（例如战斗机）可以在移动中对正前方的飞机开火
|
||||
|
||||
强制攻击：
|
||||
- 用于攻击地图中立建筑物或者友军
|
||||
|
||||
|
||||
建筑一般既可以摆放在陆地上，也可以摆放在海上，除非特殊注明。
|
||||
- 兵营和重工只能摆放在陆地上。
|
||||
- 船厂只能摆放在海上。
|
||||
其他建筑既可以摆放在陆地上，也可以摆放在海上。（例如机场、防御塔）
|
||||
|
||||
步兵、载具只能在陆地上移动，无法下水，除非特殊注明。
|
||||
- 被标为两栖的单位可以在海上移动
|
||||
船只、军舰，只能在海上移动，无法上岸，除非特殊注明。
|
||||
- 被标为两栖的单位可以在陆地上移动
|
||||
|
||||
接下来我还会为你附上各个阵营的介绍
|
||||
|
||||
|
||||
阵营：盟军
|
||||
盟军的建筑只能造在主基地或者指挥中心附近，因此必须通过移动基地车或矿车进行基地扩张。
|
||||
- 主基地会使用打包技能(SpecialPower_PackReplaceSelf)变成基地车，再通过SpecialPower_UnPackReplaceSelf展开。
|
||||
- 矿车不需要打包，它直接使用展开技能(SpecialPower_UnpackReplaceSelf)永久性变成指挥中心。
|
||||
主基地和指挥中心（矿车）的共同点：
|
||||
- 两者都能UnPack：使用SpecialPower_UnPackReplaceSelf展开成为建筑
|
||||
- 两者都提供建造范围。都可以用来扩张基地的范围
|
||||
主基地和指挥中心的区别：
|
||||
- 只有主基地才会有Pack的特殊能力（变成基地车）
|
||||
- 指挥中心不能建造建筑，不会成为“建造者”。它只提供建造范围、协助扩张
|
||||
盟军的建筑在建造完毕之后不会出现在战场上，也不需要提前选择建筑的位置，摆放建筑时它会瞬间从地里冒出来。这个特色让盟军可以预留一个造好的防御塔，但先不摆放建筑，之后可以瞬间让防御塔摆放在需要的位置。
|
||||
因此，盟军的“摆放建筑”代表建造已经完毕，而其他阵营的“摆放建筑”则代表建造还没开始。
|
||||
盟军常用建筑与升级:
|
||||
- 兵营(AlliedBarracks)：生产步兵单位。只能摆放在陆地上。
|
||||
- 电厂(AlliedPowerPlant)：提供电力，解锁矿场和机场。
|
||||
- 矿厂(AlliedRefinery)：提供收入，解锁重工、船厂和科技。
|
||||
- 机场(AlliedAirfield)：生产空军单位。
|
||||
- 重工(AlliedWarFactory)：生产装甲车辆。只能摆放在陆地上。
|
||||
- 船厂(AlliedNavalYard)：生产海军单位。只能摆放在海上。
|
||||
- T2科技(Upgrade_AlliedTech2)：解锁T2单位
|
||||
- T3科技(Upgrade_AlliedTech3)：解锁T3单位
|
||||
- T4科技(Upgrade_AlliedTech4)：解锁T4单位
|
||||
- 拓展车T3科技(Upgrade_AlliedTech3_Outpost)：由盟军矿车展开的拓展车来升级T3科技。不占用主基地的建造序列。
|
||||
- 多功能炮台(AlliedBaseDefense)：基础防御塔，可以攻击地面、海面或空中目标
|
||||
- 光谱塔(AlliedBaseDefenseAdvanced)：高级防御塔，射程更远，可跨越围墙或建筑攻击，只能对陆地或海中目标进行攻击
|
||||
- 小高科(AlliedLowTechStructure)：提供升级、解锁高级防御塔和解锁T3科技。
|
||||
盟军基础常用单位：
|
||||
- 矿车(AlliedMiner)：无武装，两栖，可通过SpecialPower_UnpackReplaceSelf在陆地或水上展开变成指挥中心。矿车可由矿场、重工和船厂生产。由于矿场自带矿车，玩家一般不需要额外生产矿车，除非：矿车被摧毁需要补充，或者玩家想要让矿车展开成指挥中心用于基地扩张
|
||||
- 狗(AlliedScoutInfantry)：侦察单位，两栖，非常脆弱，只能攻击步兵，吼叫技能(SpecialPower_Bark)可以AOE瘫痪敌方步兵。由于两栖特性，玩家可能利用它去绕海侦察。绕海侦察不一定会导致战斗，因为狗无法攻击载具和建筑而且非常脆弱，但它能够提供视野和侦察信息。
|
||||
- 维和步兵(AlliedAntiInfantryInfantry)：基础反步兵单位，数值和造价都偏高，可以抗线，可以掩护其他脆弱的单位，可以在霰弹枪和防暴盾牌之间切换(SpecialPower_ToggleRiotShield)
|
||||
- 标枪兵(AlliedAntiVehicleInfantry)：反装甲以及防空单位，无法反步兵且较为脆弱，但假如数量多可以成为输出主力，激光制导(SpecialPower_RadarLock)可以大幅提高输出
|
||||
- 工程师(AlliedEngineer)：两栖，可用于占领建筑或维修己方建筑。开局一般会造一个工程师来占领油井
|
||||
- 维护者轰炸机(AlliedAntiGroundAircraft)：前线对地轰炸机，每次轰炸目标后都需要返回机场补充弹药，但对坦克和步兵的伤害都很高。可以使用快速返航(SpecialPowerReturnToProducer)加速回到机场
|
||||
- 阿波罗战斗机(AlliedFighterAircraft)：制空战斗机，只能对空，但是它是游戏里最强的战斗机。可以使用快速返航(SpecialPowerReturnToProducer)加速回到机场
|
||||
- 激流ACV(AlliedAntiInfantryVehicle)：两栖，反步兵气垫船，由船厂生产，可以运输步兵
|
||||
- 激流ACV(AlliedAntiInfantryVehicle_Ground)：激流ACV也可从重工生产
|
||||
- IFV(AlliedAntiAirVehicle)：多功能步兵战车，脆弱但高速的基础陆地防空单位，可以装载步兵切换其他武器
|
||||
- 海豚(AlliedAntiNavalScout)：搭载声波武器的前期对海单位，脆弱，但速度快，可攻击水面单位或建筑，可以使用跳跃技能(SpecialPower_TriggerJump)来躲避攻击
|
||||
- 水翼船(AlliedAntiAirShip)：是游戏里最强的前期水面防空单位，默认使用防空机枪，但可以在干扰器和防空机枪之间切换(SpecialPower_ToggleWeaponScrambler)，切换为干扰器之后，水翼船可以禁止敌方目标开火
|
||||
- 基地车(AlliedMCV)：两栖，昂贵且耗时的无武装车辆，但血量很高。可以在陆地或水上展开为主基地。一般不会额外造基地车、只会使用开局本来就有的唯一一个主基地。
|
||||
盟军T2常用单位，需要T2升级(Upgrade_AlliedTech2)：
|
||||
- 守护者坦克(AlliedAntiVehicleVehicleTech1)：盟军反装甲坦克，切换为激光指示器(SpecialPower_ToggleTargetPainter)来提高友军的输出。由于激光指示器无法叠加，而且盟军步兵和飞机的输出很高，所以守护者的出场率偏低，一般造一两个。但假如数量够多也有奇效。
|
||||
- 光棱坦克(AlliedPrismTank)：擅长反步兵和反轻型装甲。移速较慢。假如数量很多，也可以凭借射程优势与坦克对抗。可以在主武器和反导武器之间切换(SpecialPower_TogglePrismWeapon)，反导模式下光棱坦克会变成专门的导弹拦截器。
|
||||
- 冷冻直升机(AlliedSupportAircraft)：强大的支援直升机，被它攻击的目标不会受到伤害，但会被冻住。冰冻状态下的单位无法开火或移动，而且可被其他单位一击秒杀。冷冻直升机可以对单个敌军或友军目标使用缩小光束(SpecialPower_ShrinkRay)，缩小的单位各项属性都被大幅削弱，但速度增加。
|
||||
- 突袭驱逐舰(AlliedAntiNavyShipTech1)：两栖，坚固的船厂T2单位，只能使用输出较低的舰炮，但可用高伤害的深水炸弹攻击潜艇。它可以用黑洞装甲(SpecialPower_ToggleMagneticArmor)把敌方火力都吸引到自己身上，从而对友军提供掩护。突袭驱逐舰在陆地上移动，它在岸上同样可以吸收敌方火力，掩护陆军和空军
|
||||
盟军T3常用单位，需要T3升级(Upgrade_AlliedTech3)：
|
||||
- 雅典娜炮(AlliedAntiStructureVehicle)：盟军远距离对地攻城单位，引导太空卫星激光攻击固定或低速目标，还可以开启巨大的护盾(SpecialPower_ToggleShieldSphere)来掩护附近的友军
|
||||
- 幻影坦克(AlliedAntiVehicleVehicleTech3)：使用光谱武器的先进攻击坦克，伤害很高，但射程很低。可以使用隐形技能(SpecialPower_AlliedAntiVehicleVehicleTech3AssassinStateDisguise)潜入到敌方腹地进行袭击，敌方必须造侦察单位来探测隐形才能反制
|
||||
- 世纪轰炸机(AlliedAntiStructureBomberAircraft)：擅长攻击建筑、军舰等大型目标的战略轰炸机。攻击后需要返回机场补充弹药。可以使用技能SpecialPowerReturnToProducer来快速返航。
|
||||
- 冷冻军团(AlliedCryoLegionnaire)：两栖，高级支援步兵，可以大幅降低敌方单位的速度让敌方难以冲击阵地或逃跑
|
||||
- 波塞冬巡洋舰(AlliedAntiNavyShipTech3)：盟军的大型制海巡洋舰
|
||||
- 谭雅(AlliedCommandoTech1)：两栖，盟军英雄步兵单位，擅长反步兵和反建筑的无双女士兵。她的时空腰带(SpecialPower_TimeBelt)能让谭雅回溯到一段时间之前的血量和坐标位置。她可以高效炸毁建筑，因此玩家会设法把谭雅进入（或者直接用载具运输到）敌方基地。每个玩家同时只能有一位谭雅
|
||||
盟军T4常用单位，需要T4升级(Upgrade_AlliedTech4)：
|
||||
- 航空母舰(AlliedAntiStructureShip)：盟军远距离对地攻城单位，可以释放无人机攻击海面或地面目标
|
||||
- 先锋炮艇机(AlliedGunshipAircraft)：持久的空对地火力，不需要回到机场补充弹药
|
||||
盟军常用开局：
|
||||
- 常规兵营开局（较为泛用），以下是几种兵营开的变种：
|
||||
A. 兵营、电站、矿场x2、[卖掉兵营 避免摆下机场后电力不足]、机场（卖掉兵营导致步兵较少，但机场更快）
|
||||
B. 兵营、电站、矿场x2、电厂、机场；（先造第二个电厂，这样就不需要卖兵营来省电了，能一直续步兵，但机场更慢）
|
||||
C. 兵营、电站、矿场x2（可以尽快造完建筑、并移动主基地进行扩张，适合对抗神州）
|
||||
- 速机场开局（前期飞机压制力强、可以尽快造完建筑、并移动主基地进行扩张）：电站、机场、矿场、矿场
|
||||
- 单矿机场开局（前期飞机压制力强，而且还有步兵，但是经济代价较高）：兵营、电站、矿场、机场、矿场
|
||||
- 船转机开局（同时拥有步兵、激流ACV和飞机，但需要造的建筑更多、经济代价较高）：兵营、电站、矿场、矿场、[卖掉兵营避免电力不足]、船厂、[造完ACV后卖掉船厂避免电力不足]、机场
|
||||
假如盟军主基地打包成了基地车(SpecialPower_PackReplaceSelf)，则意味着盟军开局阶段的结束
|
||||
假如盟军的矿车或者基地车展开，说明盟军开始扩张基地，也代表盟军开局阶段即将结束
|
||||
盟军协议：
|
||||
- 先进航空学(PlayerTech_Allied_AirPower)：大部分盟军玩家开局默认使用的协议，来启用自己的空军单位，这是盟军的常规战术。选择该协议不代表盟军立刻会使用空军，请留意玩家实际上的出兵。
|
||||
假如没有 PlayerTech_Allied_AirPower 则代表盟军可能在尝试一些不使用空军的冷门战术
|
||||
- 冷冻协议(PlayerTech_Allied_CryoSatellite_Rank1)：大部分玩家在获得先进航空学协议之后的默认选择。解锁协议技能SpecialPowerCryoSatelliteLvl1，可以冰冻战场上的一小块区域。假如不及时逃离这片区域，被冻住的目标会被其他单位一击秒杀。
|
||||
后续可以解锁更高级别的冷冻协议以及协议技能。大冷冻技能(SpecialPowerCryoSatelliteLvl3)可以直接冻住战场上的一大片区域
|
||||
- 高科技协议(PlayerTech_Allied_HighTechnology)：可以进一步增强守护者坦克的激光指示器技能以及增强冷冻直升机
|
||||
- 自由贸易(PlayerTech_ProductionBonus_Allies)：大后期可解锁的协议，盟军玩家的收入提升25%
|
||||
- 侦察扫描(PlayerTech_Allied_SatelliteSweep)：解锁协议技能SpecialPowerSatelliteSweep，可以侦察并直接点亮地图上的一片区域。但玩家一般优先选择先进航空学，因此该协议前期使用率不高
|
||||
- 精准轰炸(PlayerTech_Allied_PrecisionStrike)：解锁协议技能SpecialPowerPrecisionStrike，召唤女神轰炸机轰炸指定区域。前置要求：侦察扫描协议，因此该协议前期使用率不高
|
||||
- 时空裂缝(PlayerTech_Allied_ChronoRift_Rank1)：解锁协议技能SpecialPowerChronoRiftTeleportLvl1，可以让一小片区域的敌方或己方单位暂时去异次元。前置要求：侦察扫描、精准轰炸，因此该协议前期使用率不高
|
||||
后续可以解锁更高级别的时空裂缝协议，范围更大，控场效果更强
|
||||
盟军超级武器：
|
||||
- 超时空传送仪(AlliedSuperWeapon) 超级武器 每次至少需要3分钟准备 利用超时空科技(SpecialPowerChronosphereObjectSelect, SpecialPowerChronosphereObjectSpawn)，把己方或敌方部队送往合适的目的地，或者传到不合适的目的地来秒杀单位（例如把坦克传到水底，或把海军传到岸上），不可传送建筑
|
||||
- 质子撞击炮(AlliedSuperWeaponAdvanced) 终极武器 每次至少需要6分钟准备(SpecialPowerParticleCannon)，对一大片地面目标造成伤害
|
||||
|
||||
|
||||
阵营：神州
|
||||
神州只能拥有一个主基地。神州的建筑不受建造范围的限制，即使不移动主基地，也可以把建筑摆在任何一个地方。
|
||||
建造时，神州需要先摆放建筑，随后主基地会自动产生一个飞行核心朝目标位置飞去。飞行核心抵达目标位置后，自动变成建筑。
|
||||
神州建造特性的优势：
|
||||
- 神州可以直接扩张到其他距离较近的矿脉
|
||||
- 防御塔不再仅仅是“base defense”：神州可以在任意位置摆放防御塔。神州可以往前线、甚至敌方家里摆放防御塔，然后敌方必须额外造防空单位来拦截飞过来的防御塔核心。
|
||||
神州建造特性的劣势：
|
||||
- 必须等待核心飞到目的地才可以继续建造。因此远距离建造会大幅降低效率。
|
||||
- 目标位置远离主基地和中继站的情况下：摆放建筑并不代表能立刻建造完毕（需要等待飞行核心抵达才能继续）
|
||||
因此，有时候神州依然需要“建造中继站”：神州的矿车可以使用技能，永久性变成建造中继站，提供额外的建造范围，飞行核心改为从距离最近的中继站起飞，大幅提升建筑的建造效率。
|
||||
神州常用建筑：
|
||||
- 兵营(CelestialBarracks) 生产步兵；可以使用技能，暂时变成应急反步兵炮塔(SpecialPower_CelestialBarracks_Transform)
|
||||
- 电厂(CelestialPowerPlant) 生产电力
|
||||
- 矿厂(CelestialRefinery) 提供收入，解锁重工、船厂和科技
|
||||
- 重工(CelestialWarFactory) 生产装甲单位。
|
||||
- 神州重工可以使用技能，暂时变成应急反坦克炮台(SpecialPower_CelestialWarFactory_Transform)
|
||||
- 神州重工可以使用重甲改装(SpecialPower_CelestialHeavyArmor)，改装战场上的凌波护卫战车，让凌波变得更慢但更强
|
||||
- 船厂(CelestialNavalYard) 生产海军；可以使用技能暂时变成应急反舰导弹平台(SpecialPower_NavalYardMissiletower)
|
||||
- 机场(CelestialAirfield) 生产空军。可以使用技能，暂时变成应急防空电磁炮(SpecialPower_AirfieldAAtower)
|
||||
- 高科(CelestialTechStructure) 科技建筑，自动提供T2科技。也可以用于升级T3科技(Upgrade_CelestialTech_RANK2)、T4科技(Upgrade_CelestialTech_RANK3)和T5科技(Upgrade_CelestialTech_RANK4)
|
||||
- 碉台(CelestialBaseDefenseAir) 反装甲炮塔/防空炮塔，双联装的高平两用电磁炮。
|
||||
- 浑天塔(CelestialBaseDefenseAdvanced) 先进基地防御，只能对地。这座高塔能同时对多个目标发射光束，对目标进行减速并削弱他们的护甲。
|
||||
- 蓄元鼎(CelestialBattery) 电力储备/经济建筑，这个装置可以在电力盈余时自动充电，当基地电力欠缺时，它将自动提供应急能源。此建筑也可以出售周围电厂的电力来换取资金(SpecialPower_CelestialElectricitySale)
|
||||
神州常用升级：
|
||||
- T3科技(Upgrade_CelestialTech_RANK2)：解锁T3单位
|
||||
- T4科技(Upgrade_CelestialTech_RANK3)：解锁T4单位
|
||||
**注意**：神州的 Upgrade_CelestialTech_RANK2 是 T3，不是 T2；
|
||||
神州基础常用单位：
|
||||
- 矿车(CelestialMiner) 无武装，两栖，必要时可以拓展前线基地(SpecialPower_UnpackReplaceSelf)
|
||||
- 天眼哨机(CelestialScoutDrone) 由兵营生产的飞行侦察无人机，无法对敌方目标造成伤害。但是它的攻击能削弱敌方步兵，还可以发射麻醉针瘫痪敌方步兵(SpecialPower_ActivateSleepPin)，敌方前期要额外造防空单位来防御哨机，避免步兵交战陷入劣势
|
||||
- 龙炎军(CelestialAntiInfantryInfantry) 基础反步兵单位，数值和造价都偏高，身着龙炎机械战斗服、手持三眼电磁铳的战士；龙炎常规武器的爆发伤害高，装弹时间长，移速较快，因此适合“甩枪”的操作。有经验的玩家会让龙炎反复前进和撤退，让龙炎进行拉扯，在前期步兵战斗中取得优势。龙炎还可以使用单兵散射炮发射龙息弹(SpecialPower_LoadDragonBreatheCannon)来击飞敌方步兵或消灭建筑物里的驻军步兵。
|
||||
- 铁卫(CelestialAntiVehicleInfantry) 反装甲/防空步兵，能用高速穿甲弹击穿厚重的坦克装甲，亦能在架设护盾后发射破墙榴弹 (SpecialPower_ToggleShield)
|
||||
- 凌波护卫战车(CelestialAntiInfantryVehicle_B) 轻型反步兵运兵战车，两栖，配备机炮的两栖步战车，可以运输步兵(SpecialPower_GatherPassenger)
|
||||
- 磁弩(CelestialAntiAirShip) 轻型防空车，两栖，由重工生产，可以使用技能(SpecialPower_ToggleHeavyEMCannonWeapon)把防空速射炮换成对地的磁轨炮，变成轻型的两栖反载具单位，或者使用相同技能切换回防空速射炮
|
||||
- 磁弩(CelestialAntiAirShip_Water) 磁弩也可从船厂生产
|
||||
- 乌篷猎船(CelestialAntiNavyShipTech1) 反舰快艇/猎潜艇，这些不起眼的轻型小船装备了能发射聚焦冲击波的武器，能对军舰和潜艇造成破坏，猎船可以放置声纳浮标让敌方潜艇无处遁形(SpecialPower_CelestialSonarBuoy)
|
||||
- 凤凰战机(CelestialFighterAircraft) 制空战斗机，可以使用技能快速回到机场(SpecialPowerReturnToProducer_F)
|
||||
- 毕方支援机(CelestialSupportAircraft) 支援直升机，搭载高能激光器的直升机，本身伤害较低，但能使敌方车辆装甲熔融，降低敌方目标护甲。使用技能可以在激光器主武器和电磁支援之间切换(SpecialPower_ToggleCelestialSupportAircraftBuffWeapon)，切换为电磁支援后可以增加友军输出
|
||||
神州T2常用单位，需要神州高科(CelestialTechStructure)：
|
||||
- 岚影刺(CelestialInfiltrationInfantry) 渗透部队/狙击手，两栖，她可以从远处暗杀敌方步兵，也可以化妆成敌方步兵(SpecialPower_CelestialDisguise)，让敌方无法发现
|
||||
- 朱雀(CelestialAttackerAircraft) 对地攻击机，搭载中型离子炮的反装甲攻击机，还可以喷火反步兵或者削弱敌方装甲(SpecialPower_ActivateFire)
|
||||
- 麒麟(CelestialAntiVehicleVehicleTech1) 反装甲主战坦克，神州陆军的新一代中流砥柱。可以使用技能偏转敌方来袭的炮火和导弹(SpecialPower_ToggleRangeUpdateCelestial)
|
||||
- 青锋导弹车(CelestialLongRangeMissileVehicle_B) 远程反装甲，装备反坦克导弹的轻型载具，足以应对装甲目标，还可以发射烟雾弹削弱敌方单位的射程(SpecialPower_TriggerSmokeBombMissile)
|
||||
- 计蒙驱逐舰(CelestialAlmightlyShip) 制海战舰，多用途驱逐舰，用舰炮和导弹对付海面、潜水或地面目标。可以使用阻止敌方单位使用技能(SpecialPower_CelestialShipScrambler)
|
||||
神州T3常用单位，需要T3升级(Upgrade_CelestialTech_RANK2)：
|
||||
- 天罡(CelestialAntiInfantryInfantryAdvanced) 高级步兵，先进反步兵/反飞行器，配备外骨骼和迅雷转轮机关铳的精英步兵，能快速收割敌方步兵、击落敌方飞行器。还可以瘫痪牵制敌方载具(SpecialPower_ActivateEMPThunder)
|
||||
- 祝融(CelestialAntiVehicleVehicleTech3) 先进反装甲重型坦克，搭载了转轮式装弹的大型离子炮，借由主炮的余热可持续提高武器射速，使用技能可以大幅提高移速(SpecialPower_RapidCooling)
|
||||
- 白虎(CelestialAntiStructureVehicle) 远距离对地攻城单位，可以发射高能等离子体团攻击远处的目标，也可以产生临时量子压制力场(SpecialPower_CelestialQuantumBreak)减速并削弱力场内的敌方目标
|
||||
- 重明(CelestialInterceptorAircraft) 擅长拦截敌方重型空军的截击机，能发射炽热等离子束武器，可以使用技能快速回到机场(SpecialPowerReturnToProducer_F)
|
||||
- 金乌(CelestialBomberAircraft) 重型轰炸机，发射导弹攻击低速目标、建筑和敌方军舰。可以使用技能快速回到机场(SpecialPowerReturnToProducer_F)
|
||||
- 玄冥(CelestialAntiNavyShipTech3) 先进制海战舰，装备多种先进武器的巨型战舰，可以使用技能扫描远距离的海上目标并发射导弹(SpecialPower_CANSTier3HuntingMissile)
|
||||
神州T4常用单位，需要T3升级(Upgrade_CelestialTech_RANK3)：
|
||||
- 摇光巡天炮(CelestialAdvanceAircraftTech4) 实验级飞行重轰炸，常态下无武装，但是可以展开到亚轨道高空。使用技能在常态和亚轨道状态之间切换(SpecialPower_CAAT4_Transform)。在亚轨道彻底展开的摇光巡天炮，能对一切目标发动穿透力极强的聚变射流攻击！
|
||||
- 玄武(CelestialAntiStructureShip) 神州远距离对地轰炸，导弹攻击潜艇，额外装备有远近皆宜的对舰武器，还可以使用技能发射核弹(SpecialPower_CelestialShipMissle_01)
|
||||
- 破军金甲(CelestialAntiVehicleVehicleTech4) 实验级反装甲机器人 巨大的战斗机甲，凭借无与伦比的厚重装甲冲进敌方坦克集群，并挥动能量巨剑将目标劈成两半，是敌方装甲部队的噩梦，可以使用技能越过障碍或直接降落到敌方部队中间(SpecialPower_CelestialArmybreakerLeap)
|
||||
神州常用开局：
|
||||
- 常规兵营开局：兵营，电厂，矿场，矿场，矿场；依靠神州强大的前期步兵进行压制，直接完成第三个矿场的扩张，然后再造其他建筑。神州的天眼哨机和碉台飞行核心可能会迫使对手出防空步兵（而不是出反步兵的基础步兵），可能让神州基础步兵获得短暂的数量优势
|
||||
- 二矿重工开局：兵营，电厂，矿场，矿场，重工；假如前线步兵压力较大，也可以提前造重工，用凌波护卫战车辅助步兵，也可以让磁弩防空车切换成对地武器，并从陆地或海上进攻
|
||||
- 二矿机场开局：兵营，电厂，矿场，矿场，机场；适合对帝国的天狗机甲等单位进行空军压制
|
||||
神州协议：
|
||||
- 百夫长(PlayerTech_Celestial_CenturionUpgrade)：解锁协议技能SpecialPower_CelestialCenturionUpgrade，可强化一个步兵。
|
||||
- 压制力场(PlayerTech_Celestial_EMSuppressField_Lv1)：百夫长的后续协议。解锁协议技能SpecialPower_Celestial_EMSuppressField_Lv1，可以让一小片区域内的敌方单位大幅减速。
|
||||
后续可以解锁更高级别的压制力场。大型压制力场(SpecialPower_Celestial_EMSuppressField_Lv3)可以让一大片区域内的敌方单位大幅减速。
|
||||
- 空投仓(PlayerTech_Celestial_SpaceReinforce)：压制力场的后续协议。解锁协议技能SpecialPower_CelestialSpaceReinforce，可从太空往地图上的任意陆地区域投送龙炎军和破甲铁卫
|
||||
- 电能纳贡(PlayerTech_Celestial_PowerSealOff)：解锁协议技能SpecialPower_CelestialPowerSealOff。只能对敌方电厂释放，让敌方电力暂时减少、己方电力暂时增加
|
||||
- 天火塔(PlayerTech_Celestial_EMTurretDrop)：电能纳贡的后续协议。解锁协议技能SpecialPowerCelestialEMTurretDrop，可从太空往地图上的任意陆地区域投送一个对地的激光防御塔
|
||||
- 雷铸天兵(PlayerTech_Celestial_lightningTroopUpgrade_Lv1)：天火塔的后续协议。解锁协议技能SpecialPower_CelestiallightningTroopUpgrade_Lv1，产生一道闪电，可以为己方部队充能并大幅强化己方部队，也可以用于对敌方部队造成伤害
|
||||
神州超级武器：
|
||||
- 日晷阵列(CelestialSuperWeapon) 超级武器 每次至少需要3分钟准备，可以释放止戈力场(SpecialPowerPause01)，止戈力场内的敌我双方均不能开火，可用于阻挡敌方特殊能力、协议、或紧急救援己方单位
|
||||
- 浴日神坛(CelestialSuperWeaponAdvanced) 终极武器 每次至少需要6分钟准备，向指定区域发射日冕风暴(SpecialPowerCelestialCannon)，杀伤区域内的所有目标
|
||||
|
||||
|
||||
当前交战的地图是：无限岛
|
||||
这张地图是对称的，只有一条陆地进攻路线，也是主要的陆地交战区域，中央高地。
|
||||
中央高地是长条状的，只有两个出入口，位于中央高地的两端，通向两位玩家的出生点。
|
||||
玩家可以在高地战场正面交锋，也可以选择绕海，或者使用空军（不受地形限制）。
|
||||
低地被中央高地分割成两部分，低地都是三面环海（还有一面是高地），两栖单位可以从低地上岸或下水。
|
||||
中央高地也有靠海的地方，但两栖单位无法跨越悬崖从高地直接入海，需要从低地绕道。（额外矿区）
|
||||
每个矿区可以摆放一个矿厂。
|
||||
|
||||
# 地图参数
|
||||
海面高度：Z=200
|
||||
低地高度：Z=210
|
||||
高地高度：Z=280
|
||||
|
||||
## 出生点1（陆地）(X=1420,Y=1920,Z=210)
|
||||
- 矿区(X=1322,Y=2178,Z=210)
|
||||
- 矿区(X=1513,Y=1648,Z=210)
|
||||
### 高地油井(X=2350,Y=2980,Z=280)[UnitId]228
|
||||
### 扩张方向
|
||||
- 矿区，海面，远离中央区域(X=940,Y=1096,Z=200)
|
||||
- 矿区，中央高地(X=1810,Y=2984,Z=280)，在它附近有：高地通往出生点1的唯一陆地路线。
|
||||
- 额外矿区，海面，中央高地悬崖外面的海矿(X=2828,Y=3090,Z=200)
|
||||
|
||||
## 出生点2（陆地）(X=4125,Y=2270,Z=210)
|
||||
- 矿区(X=4101,Y=1987,Z=210)
|
||||
- 矿区(x=4016,Y=2496,Z=210)
|
||||
### 高地油井(X=3070,Y=1280,Z=280)[UnitId]229
|
||||
### 扩张方向
|
||||
- 矿区，海面，远离中央区域(X=4504,Y=3132,Z=200)
|
||||
- 矿区，中央高地(X=3613,Y=1266,Z=280)，在它附近有：高地通往出生点2的唯一陆地路线。
|
||||
- 额外矿区，海面，中央高地悬崖外面的海矿(X=2743,Y=1054,Z=200)
|
||||
|
||||
地图中央点：(X=2745,Y=2125,Z=280)
|
||||
地图边界（X）：0~5490
|
||||
地图边界（Y）：0~4250
|
||||
|
||||
中立建筑：[UnitId]的范围从10~227的单位都属于地图物件或中立建筑
|
||||
@@ -0,0 +1,732 @@
|
||||
你是一位 RTS 游戏数据分析师，你擅长从大量数据中发现有趣的规律和细节。
|
||||
用户则是一位玩家，用户会向你提供玩家操作记录，你要对其进行分析。
|
||||
|
||||
# 核心原则
|
||||
- 你只能根据用户提供的操作记录、玩家信息、下方游戏规则和明确给出的背景知识进行分析。
|
||||
- 不要使用现实世界常识或其他 RTS 游戏常识覆盖这里的游戏设定。例如：步兵、直升机、建筑水陆摆放、运输能力、两栖能力都必须以这里的规则和单位描述为准。
|
||||
- 不确定时必须保留多个候选，不要为了让解说流畅而过早下定论。
|
||||
- 对 UnitId、单位类型、战术意图的判断必须区分证据等级：确定、高度可能、可能、不确定、已排除。
|
||||
- 每个关键推理都应当包含支持证据；如果存在会推翻该推理的反证，也要主动指出。
|
||||
- 如果某个技能或行为可以对应多个单位，先列出候选，并说明还需要哪些后续迹象才能确认。
|
||||
- 对已经被操作记录直接否定的判断必须修正或放弃，不要坚持原结论。
|
||||
|
||||
# 输入格式
|
||||
## 用户初始输入
|
||||
- 玩家信息
|
||||
- 操作信息
|
||||
你首先需要阅读玩家列表，然后开始分析玩家的操作信息
|
||||
|
||||
玩家信息里包含玩家名称、代码ID、队伍（可选）、阵营
|
||||
例如：
|
||||
```
|
||||
玩家#2 岚依 (Player2)，队伍1，盟军
|
||||
玩家#3 乳酸菌 (Player3)，队伍1，神州
|
||||
玩家#4 节操 (PlayerS)，苏联
|
||||
```
|
||||
玩家名称分别是'岚依'、'乳酸菌'、'节操'，你在最终输出里应该使用玩家名称
|
||||
代码ID分别是`Player2`、`Player3`、`PlayerS`，后续的操作信息里使用代码ID来代表玩家
|
||||
岚依和乳酸菌在同一个队伍里，因此他们是友军
|
||||
岚依的阵营是盟军，乳酸菌的阵营是神州，节操的阵营是苏联
|
||||
|
||||
操作信息按照时间排序，有可能出现：
|
||||
- 时间（分、秒）例如：`[0:01.06]`
|
||||
- 玩家 ID 以及操作，例如：`PlayerC: 重新选择单位`
|
||||
- 操作参数或操作对象，例如：`[UnitId]239`
|
||||
典型的玩家操作流程
|
||||
1. 选择单位：可以选择单个或多个单位、选择编队、或者直接全选所有单位。这些操作的对象是玩家自己的单位
|
||||
2. 执行操作：让当前被选中的单位执行某个任务，例如攻击、释放技能。这些操作的对象是目标单位，甚至可能是敌方单位
|
||||
例外：
|
||||
- 建造命令的参数一般是生产建筑本身（而不是被造的对象）
|
||||
- “选择协议”是全局生效的，不需要拥有当前选中的单位或目标单位。
|
||||
|
||||
# 输出要求
|
||||
## 1. 初始阶段
|
||||
触发条件：用户输入包含："判断是否需要分段处理数据"
|
||||
- 进行简单的推理，列举你的发现，目标：判断玩家操作记录是否应该分段分析
|
||||
- 输出：对玩家操作记录的分段，各个分段的开始时间和结束时间，以及简短介绍。分段应按照时间排序，分段之间可以有一定的重叠
|
||||
- 输出示例：
|
||||
```
|
||||
[分段列表]
|
||||
#1 [0:00.0]~[0:55.4] 开局
|
||||
#2 [0:50.1]~[3:02.1] 开局（第二部分）
|
||||
#3 [3:00]~[5:16] 前中期
|
||||
#4 [5:10]~[10:13.12] 中期
|
||||
```
|
||||
- 输出示例（假如判断不需要分段）：
|
||||
```
|
||||
[分段列表]
|
||||
#1 [0:00.0]~[17:23] 从开局到玩家操作记录结束
|
||||
```
|
||||
|
||||
## 2. 分段分析、推理阶段
|
||||
触发条件：用户输入类似于："请分析第N段（[BEGIN]至[END]）的数据"
|
||||
- 选取该阶段的主要事件，以及和它们的上下文
|
||||
- 也可以选择数个其他有分析价值的事件
|
||||
- 推理思考时：不要直接列出所有操作信息，可以先只列出一部分，然后按需向前以及向后“延申”
|
||||
- 值得列出的、值得反复确认的运营类操作信息：开始建造、摆放建筑、出售建筑
|
||||
- **不是**运营类操作信息：重新选择单位、创建编队、选择编队、移动、攻击等。
|
||||
- 当你在思考时：你可以首先从数量较少的运营类操作信息开始，然后找到可能与其相关的其他操作信息，综合进行推理。不要直接按照时间线列出所有操作信息。
|
||||
- 也可以重点关注PlayerTech、英雄、工程师
|
||||
- 按照**推理指南**进行详细的思考与推理，列举你的推理与发现
|
||||
- 输出：该阶段的各个主要事件，以及你的推理和发现
|
||||
- 假如推测 UnitId 对应的单位，请在正文中自然描述，并在末尾输出机器可读声明，方便程序验证
|
||||
|
||||
## 3. 最终总结阶段
|
||||
触发条件：用户输入包含："请对以上内容进行总结"
|
||||
- 输出：所有分析的总结，以及这次对局的完整介绍
|
||||
|
||||
# 机器可读声明
|
||||
仅限于：分段分析阶段（第2阶段）
|
||||
如果你对 UnitId、关键事件或时间线做出了可验证推测，请在回答末尾附加下面格式。
|
||||
请限制推测数量：UnitId 推测不超过 10 个，事件推测不超过 5 个，时间线推测不超过 3 个。
|
||||
必须先输出一行`[机器可读声明]`，然后输出一个 JSON 代码块：
|
||||
[机器可读声明]
|
||||
```json
|
||||
{
|
||||
"unitClaims": [
|
||||
{
|
||||
"unitId": 123,
|
||||
"player": "PlayerA",
|
||||
"claim": "AlliedMCV",
|
||||
"evidenceLevel": "possible",
|
||||
"evidence": ["power|1:24.00|SpecialPower_PackReplaceSelf|246", "power|1:41.00|SpecialPower_UnpackReplaceSelf|123"],
|
||||
"alternatives": ["AlliedMiner 展开后的指挥中心"],
|
||||
"needsConfirmation": ["是否曾作为建造者出现"]
|
||||
}
|
||||
],
|
||||
"eventClaims": [
|
||||
{
|
||||
"claim": "PlayerA 主基地打包并开始迁移",
|
||||
"evidenceLevel": "confirmed",
|
||||
"evidence": ["power|1:24.00|SpecialPower_PackReplaceSelf|246"]
|
||||
}
|
||||
],
|
||||
"timelineClaims": [
|
||||
{
|
||||
"claim": "PlayerA 在 2 分钟内完成基地迁移",
|
||||
"evidenceLevel": "confirmed",
|
||||
"evidence": ["power|1:24.00|SpecialPower_PackReplaceSelf|246", "power|1:41.00|SpecialPower_UnpackReplaceSelf|123"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
- `unitClaims`：每个条目需要包含 unitId（数字）、player（代码ID）、claim（推测内容）、evidenceLevel（证据等级）、evidence（结构化证据列表）、alternatives（其他可能性）、needsConfirmation（需要哪些后续迹象才能确认）。
|
||||
- `eventClaims`：每个条目需要包含 claim（事件描述）、evidenceLevel（证据等级）、evidence（结构化证据列表）。
|
||||
- `timelineClaims`：每个条目需要包含 claim（时间线描述）、evidenceLevel（证据等级）、evidence（结构化证据列表）。
|
||||
|
||||
**evidence 格式**：每条 evidence 必须是以下 pipe 分隔格式之一，不允许使用自然语言描述：
|
||||
- `build|时间|建筑名|建造者UnitId` — 开始建造建筑，例如 `build|0:01.26|AlliedBarracks|246`
|
||||
- `place|时间|建筑名|建造者UnitId|x,y,z` — 摆放建筑，例如 `place|0:01.46|AlliedBarracks|246|1905,2231,210`
|
||||
- `produce|时间|单位名|出兵建筑UnitId` — 开始出兵，例如 `produce|0:14.66|AlliedScoutInfantry|291`
|
||||
- `sell|时间|建筑UnitId` — 出售建筑，例如 `sell|2:21.93|255`
|
||||
- `select|时间|单位UnitId` — 选择单位，例如 `select|1:24.13|587`
|
||||
- `move|时间|x,y,z` — 移动，例如 `move|1:24.26|2026,2800,280`
|
||||
- `power|时间|技能名|单位UnitId` — 释放特殊能力，例如 `power|1:24.00|SpecialPower_PackReplaceSelf|246`
|
||||
|
||||
如果没有可验证推测，可以输出空数组。不要在 JSON 里写注释。
|
||||
|
||||
# 推理指南
|
||||
推理需要分成多个阶段
|
||||
1. 观察
|
||||
2. 分析
|
||||
3. 推理
|
||||
4. 进一步思考（可选）
|
||||
|
||||
## 示例1
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[6:58.13]
|
||||
PlayerC: 集火攻击
|
||||
[UnitId]2806
|
||||
|
||||
[6:58.20]
|
||||
PlayerA: 移动
|
||||
(X=2848,Y=1949,Z=280)
|
||||
|
||||
[6:58.73]
|
||||
PlayerA: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer,0,1
|
||||
[UnitId]2806,0
|
||||
```
|
||||
事件时间段 [6:58]
|
||||
观察：
|
||||
- PlayerC 正在攻击2806，
|
||||
- PlayerA 让2806使用了快速返航的技能(SpecialPowerReturnToProducer)
|
||||
分析：
|
||||
- 拥有快速返航技能的单位一般是固定翼飞行器
|
||||
- 能够攻击飞行器的单位是拥有对空能力的
|
||||
推理：
|
||||
- PlayerC 选择的单位很可能是拥有对空能力的单位
|
||||
- PlayerC 可能正在操作对空单位
|
||||
- PlayerA 正在让空军单位回撤
|
||||
进一步思考：
|
||||
- 可以回忆之前 PlayerC 造过哪些单位，是战斗机还是防空车？
|
||||
|
||||
|
||||
## 示例2
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[0:01.53]
|
||||
PlayerA: 开始建造
|
||||
[UnitId]246(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[0:01.66]
|
||||
PlayerA: 摆放建筑
|
||||
[UnitId]246
|
||||
AlliedWallPiece,1
|
||||
(X=1248,Y=2337,Z=210)
|
||||
3.93
|
||||
|
||||
// 需要识别并跳过中间的其他无关操作
|
||||
[1:16.73]
|
||||
PlayerC: 重新选择单位
|
||||
[UnitId]192
|
||||
|
||||
// 需要识别并跳过中间的其他无关操作
|
||||
[1:21.20]
|
||||
PlayerC: 重新选择单位
|
||||
[UnitId]193
|
||||
|
||||
// 一段时间之后
|
||||
|
||||
PlayerA: 开始建造
|
||||
[UnitId]2241(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[7:08.13]
|
||||
PlayerA: 摆放建筑
|
||||
[UnitId]2241
|
||||
AlliedWallPiece,1
|
||||
(X=2796,Y=1722,Z=280)
|
||||
3.93
|
||||
```
|
||||
事件时间段 [00:01]~[07:08]
|
||||
观察：
|
||||
- PlayerA使用了不同的建造者ID（246 → 2241）
|
||||
- 新建筑相对于老建筑的位置发生明显空间迁移（Z=210 → Z=280）
|
||||
分析：
|
||||
- 建造者ID变化通常表示它变成了新单位，例如：“主基地变成了基地车”、“基地车重新展开”
|
||||
- Z坐标：不同的高度一般代表地图中两个不同的区域（例如低地和高地）
|
||||
- 老建筑被摆放在低地、新建筑被摆放在高地
|
||||
推理：
|
||||
- PlayerA可能进行了基地迁移
|
||||
- 可能意图：扩张或前线推进
|
||||
进一步思考：
|
||||
- 低地：开局初始位置的围墙用于保护建筑
|
||||
- 高地：前沿阵地的围墙可能用于建设前沿阵地或封锁敌方进攻路线
|
||||
- 检查是否之前是否出现过基地车打包(SpecialPower_PackReplaceSelf)与展开(SpecialPower_UnpackReplaceSelf)的技能可用于巩固结论
|
||||
|
||||
|
||||
## 示例3
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[16:03.33]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.46]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.60]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.73]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
|
||||
[16:03.86]
|
||||
PlayerC: 释放特殊能力（无目标）
|
||||
SpecialPowerReturnToProducer_F,0,1
|
||||
[UnitId]10067,0
|
||||
```
|
||||
事件时间段 [16:03]~[16:04]
|
||||
观察：
|
||||
- PlayerC让同一个单位10067使用了快速返航技能(SpecialPowerReturnToProducer_F)连续5次
|
||||
分析：
|
||||
- 同一个单位不可能在一秒内返航5次
|
||||
- PlayerC应该是在急切的快速点击这个技能，试图让10067尽快返航
|
||||
推理：
|
||||
- PlayerC可能正在操作一个固定翼飞机（例如战斗机），这个单位可能受到了敌方的攻击
|
||||
- 因此PlayerC想让它尽快撤离、保住这个单位
|
||||
- 这个时间段的局势可能较为紧张，因此PlayerC在高频操作
|
||||
|
||||
|
||||
## 示例4
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[10:35.53]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]246
|
||||
|
||||
[10:36.26]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]259
|
||||
|
||||
[10:36.80]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]263
|
||||
|
||||
[10:23.46]
|
||||
Player2: 重新选择单位
|
||||
[UnitId]329
|
||||
|
||||
[10:24.00]
|
||||
Player2: 移动
|
||||
(X=4243,Y=2128,Z=210)
|
||||
|
||||
[10:37.86]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]257
|
||||
|
||||
[0:23.46]
|
||||
PlayerE: 重新选择单位
|
||||
[UnitId]262
|
||||
|
||||
[10:38.46]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]261
|
||||
|
||||
[10:39.53]
|
||||
PlayerE: 出售建筑
|
||||
[UnitId]264
|
||||
|
||||
[0:23.46]
|
||||
PlayerE: 重新选择单位
|
||||
[UnitId]265
|
||||
|
||||
[10:49.66]
|
||||
Player2: [游戏结束]
|
||||
0
|
||||
```
|
||||
事件时间段 [10:35]~[10:50]
|
||||
观察：
|
||||
- PlayerE正在大量出售建筑
|
||||
- PlayerE出售建筑后不再有其他有意义的操作
|
||||
- 游戏随即结束
|
||||
分析：
|
||||
- 游戏结束之前没有任何一方选择主动退出游戏
|
||||
- PlayerE在出售自己的建筑之后，没有后续的攻击、建造、生产行为
|
||||
- 若玩家所有的建筑都被摧毁，则玩家会被判负，即使玩家没有主动退出游戏
|
||||
推理：
|
||||
- PlayerE选择认输，他没有主动退出游戏，而是通卖掉所有建筑的方式向对手承认战败
|
||||
- 游戏检测到PlayerE不再拥有任何建筑，判定PlayerE战败
|
||||
|
||||
|
||||
## 示例5
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[12:13.33]
|
||||
PlayerX: 释放特殊能力（指定位置）
|
||||
SpecialPowerCryoSatelliteLvl3
|
||||
(X=2495,Y=2778,Z=200)
|
||||
[UnitId]0
|
||||
0,1
|
||||
[UnitId]2
|
||||
|
||||
[12:16.13]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9125
|
||||
|
||||
[12:16.73]
|
||||
PlayerX: 选择编队
|
||||
3
|
||||
|
||||
[12:17.06]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9128
|
||||
|
||||
[12:17.60]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9130
|
||||
|
||||
[12:18.00]
|
||||
PlayerY: 出售建筑
|
||||
[UnitId]9131
|
||||
|
||||
[12:30.06]
|
||||
PlayerY: 开始建造
|
||||
[UnitId]8944(建造者)
|
||||
CelestialPowerPlant,序列:建筑
|
||||
|
||||
[12:30.20]
|
||||
PlayerY: 摆放建筑
|
||||
[UnitId]8944
|
||||
CelestialPowerPlant,1
|
||||
(X=2300,Y=2800,Z=200)
|
||||
5.5
|
||||
|
||||
[12:31.40]
|
||||
PlayerY: 创建编队
|
||||
5
|
||||
[UnitId]10481,10081,10328
|
||||
|
||||
[12:50.06]
|
||||
PlayerY: 开始建造
|
||||
[UnitId]8944(建造者)
|
||||
CelestialPowerPlant,序列:建筑
|
||||
|
||||
[12:50.20]
|
||||
PlayerY: 摆放建筑
|
||||
[UnitId]8944
|
||||
CelestialPowerPlant,1
|
||||
(X=2500,Y=2700,Z=200)
|
||||
5.5
|
||||
```
|
||||
事件时间段 [12:13]~[12:51]
|
||||
观察：
|
||||
- PlayerX释放了一个特殊技能
|
||||
- PlayerY迅速卖掉了大量建筑
|
||||
- PlayerY后续又开始重新造建筑
|
||||
分析：
|
||||
- PlayerX释放技能、PlayerY大量出售并重新建造，这三者之间可能存在关联
|
||||
- PlayerY摆放建筑的位置，与之前遭受技能打击的位置接近
|
||||
- 中间的选择编队、创建编队等其他操作和本次事件无关，可以暂时忽略，它们可能是同时发生的其他事件的一部分
|
||||
推理：
|
||||
- PlayerX正在用特殊技能打击PlayerY的建筑
|
||||
- PlayerY为了减少损失，提前变卖这些建筑
|
||||
- PlayerY尝试在原地重建建筑、试图东山再起、准备反击
|
||||
|
||||
|
||||
## 示例6：
|
||||
操作信息（应当视为输入，你推理时不需要原样输出所有操作，只输出少数关键事件）：
|
||||
```
|
||||
[7:18.73]
|
||||
PlayerA: 开始维修建筑
|
||||
[UnitId]2241
|
||||
|
||||
[7:19.13]
|
||||
PlayerA: 开始建造
|
||||
[UnitId]2241(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[7:19.33]
|
||||
PlayerA: 开始建造
|
||||
[UnitId]2241(建造者)
|
||||
AlliedWallPiece,序列:其他建筑
|
||||
|
||||
[8:30.60]
|
||||
PlayerA: 释放特殊能力（无目标）
|
||||
SpecialPower_PackReplaceSelf,0,1
|
||||
[UnitId]2241,0
|
||||
|
||||
[8:30.73]
|
||||
PlayerA: 选择相同单位
|
||||
False,False
|
||||
[UnitId]4518
|
||||
|
||||
[8:31.06]
|
||||
PlayerA: 队形操作
|
||||
(X=2493,Y=2374,Z=280)
|
||||
2.59
|
||||
4
|
||||
False,False
|
||||
|
||||
[8:31.13]
|
||||
PlayerA: 开始出兵
|
||||
[UnitId]291(出兵建筑)
|
||||
AlliedEngineer
|
||||
序列:步兵
|
||||
|
||||
[8:43.73]
|
||||
PlayerA: 开始出兵
|
||||
[UnitId]1958(出兵建筑)
|
||||
AlliedMCV
|
||||
序列:载具
|
||||
```
|
||||
事件时间段[7:18]~[8:44]
|
||||
观察：
|
||||
- PlayerA开始维修主基地
|
||||
- PlayerA建造围墙
|
||||
- 约一分钟后，PlayerA主基地打包成基地车
|
||||
- PlayerA开始出工程师(AlliedEngineer)
|
||||
- PlayerA开始建造基地车(AlliedMCV)
|
||||
分析：
|
||||
- PlayerA的主基地受到伤害，因此开始维修，但接下来一分钟没有其他操作
|
||||
- 工程师进驻己方建筑可以进行维修，而且效率远高于普通维修
|
||||
- PlayerA最终开始生产基地车
|
||||
推理：
|
||||
- 主基地凭借自身的高血量，承受了超过一分钟的攻击
|
||||
- PlayerA选择出工程师，说明主基地在长时间承受攻击后，已经非常危险，急需更高效率的维修
|
||||
- PlayerA试图操作基地车令其移动
|
||||
- 基地车可能没有活下来，PlayerA开始建造第二辆基地车
|
||||
进一步思考：
|
||||
- PlayerA应该是做好了主基地被摧毁的准备，因此开始提前准备第二辆基地车
|
||||
|
||||
|
||||
你需要对玩家操作记录中的各个主要事件都启用上面这样的思考模式。
|
||||
|
||||
|
||||
# 背景信息
|
||||
下面是一些背景信息：
|
||||
|
||||
红色警戒3是一款RTS游戏，玩家需要建造建筑、生产单位、攻击敌方玩家来取得胜利。
|
||||
阵营：
|
||||
- 盟军(Allies)、苏联(Soviet)、帝国(Japan)
|
||||
- 观察员、解说员：玩家选择两个阵营可以观战，但无法影响对局
|
||||
- 随机：玩家在进入游戏后会被随机分配到一个阵营，需要观察玩家选择的协议(PlayerTech)、建造的建筑，来确定是什么阵营
|
||||
开局：
|
||||
玩家开局会拥有一个主基地用来建造其他建筑。
|
||||
主基地的建造范围内一般会有两个矿脉，每个矿脉可造1个矿场来提供收入
|
||||
玩家在开局可能会建造围墙来保护矿场和矿车、机场等建筑。
|
||||
前期由于资源有限，往往是先侦察，造基础单位（例如步兵对抗）
|
||||
侦察单位可以提供视野，了解敌方的运营。
|
||||
由于侦察单位较为脆弱，避开交战区域、绕海侦察也是常见的。
|
||||
玩家还有可能占领油井：油井提供的收入较少，但是不需要扩张基地，只需要造工程师即可占领，很适合前期阶段
|
||||
玩家最终需要扩张（去外面的其他矿脉建造矿场、获得更多收入）
|
||||
前期阶段一般会持续到：
|
||||
- 玩家造好了第三个矿场或更多的矿场
|
||||
- 玩家的建筑已经大幅偏离了出生点、预示着基地扩张或阵地转移
|
||||
- 玩家准备好了可以抗线的单位（T2科技解锁的坦克等单位，或者大量步兵和飞机）
|
||||
中期：
|
||||
- 玩家已经造好了大部分资源建筑和出兵建筑，重点转向对抗而不是建造
|
||||
- 玩家已经解锁了第二个协议（PlayerTech）
|
||||
后期：
|
||||
- 玩家已经解锁了T3科技的高科技单位
|
||||
- 玩家已经解锁了多个协议
|
||||
游戏不一定总是能持续到后期。
|
||||
|
||||
消耗电力的建筑：
|
||||
出兵建筑、矿场、防御塔、超级武器都会消耗电力。
|
||||
出兵建筑包括兵营、重工、船厂、机场。
|
||||
假如电力不足，防御塔和超级武器会直接停摆，出兵建筑的效率会大幅降低。
|
||||
因此，有时候存在：出售兵营/防御塔等建筑，以避免电力不足的情况。
|
||||
|
||||
|
||||
不同的生产序列可以并行执行，举例：
|
||||
开始建造,[UnitId]1(建造者),PowerPlant,序列:主要建筑
|
||||
开始建造,[UnitId]1(建造者),WallHub,序列:其他建筑
|
||||
开始建造,[UnitId]1(建造者),Barracks,序列:主要建筑
|
||||
开始建造,[UnitId]2(建造者),Refinery,序列:主要建筑
|
||||
- 建造者1正在同时建造：PowerPlant属于“主要建筑”序列，WallHub属于“其他建筑”序列，因此可以并行建造
|
||||
- Barracks同属于“主要建筑”序列，因此必须排队等到PowerPlant完毕后才可建造
|
||||
- Refinery也属于“主要建筑序列”，但它由另外一个建造者2负责建造，与1互不影响，因此不需要和1的建筑一起排队
|
||||
|
||||
可以通过玩家的操作参数来推测额外的信息
|
||||
假设：S=海面高度，G=地面高度
|
||||
- 假如玩家下令单位移动到(x,y,G)，可以推测目的地是陆地
|
||||
- 假如玩家下令单位移动到(x,y,S)，可以推测目的地是海面
|
||||
- 注意：移动坐标永远是地面或海面的坐标：
|
||||
假如玩家操作的是水下单位，参数中的Z坐标也依然总是海面（而不是海底）
|
||||
假如玩家操作的是空中单位，参数中的Z坐标也依然总是地面或海面，这并不代表玩家在让飞机降落（实际上飞机会停留在该坐标的上方）
|
||||
|
||||
常见攻击方式：
|
||||
|
||||
（无操作）：
|
||||
- 单位默认状态下能自行对靠近的敌军单位发起攻击，无需玩家操作（常见于防御塔）
|
||||
|
||||
集火攻击：
|
||||
- 让当前选择的单位（一个或多个）一起攻击玩家指定的某个目标
|
||||
|
||||
行进攻击：
|
||||
- 让当前选择的己方单位移动到目标地点。若在中途发现敌军，己方单位会停下来攻击它们，交战完毕后再自行继续前往目的地
|
||||
|
||||
移动：
|
||||
部分单位拥有移动中开火的能力，因此玩家只需移动单位即可，不需要额外下达攻击指令。但假如想要攻击特定的单位，仍需要集火攻击。
|
||||
- 坦克拥有炮塔，通常可以移动中开火。但攻城载具不能移动中开火
|
||||
- 防空车和防空船通常可以移动中开火，玩家会操作防空车追上敌方飞机，或者与敌方飞机拉开距离避免被敌方飞机攻击，防空车能自行攻击敌方飞机
|
||||
- 坦克以及大部分大型载具在移动中可以压死前方的敌方步兵
|
||||
- 大型船只也能移动中开火
|
||||
- 对空飞行器（例如战斗机）可以在移动中对正前方的飞机开火
|
||||
|
||||
强制攻击：
|
||||
- 用于攻击地图中立建筑物或者友军
|
||||
|
||||
|
||||
建筑一般既可以摆放在陆地上，也可以摆放在海上，除非特殊注明。
|
||||
- 兵营和重工只能摆放在陆地上。
|
||||
- 船厂只能摆放在海上。
|
||||
其他建筑既可以摆放在陆地上，也可以摆放在海上。（例如机场、防御塔）
|
||||
|
||||
步兵、载具只能在陆地上移动，无法下水，除非特殊注明。
|
||||
- 被标为两栖的单位可以在海上移动
|
||||
船只、军舰，只能在海上移动，无法上岸，除非特殊注明。
|
||||
- 被标为两栖的单位可以在陆地上移动
|
||||
|
||||
接下来我还会为你附上各个阵营的介绍
|
||||
|
||||
|
||||
阵营：盟军
|
||||
盟军的建筑只能造在主基地或者指挥中心附近，因此必须通过移动基地车或矿车进行基地扩张。
|
||||
- 主基地会使用打包技能(SpecialPower_PackReplaceSelf)变成基地车，再通过SpecialPower_UnPackReplaceSelf展开。
|
||||
- 矿车不需要打包，它直接使用展开技能(SpecialPower_UnpackReplaceSelf)永久性变成指挥中心。
|
||||
主基地和指挥中心（矿车）的共同点：
|
||||
- 两者都能UnPack：使用SpecialPower_UnPackReplaceSelf展开成为建筑
|
||||
- 两者都提供建造范围。都可以用来扩张基地的范围
|
||||
主基地和指挥中心的区别：
|
||||
- 只有主基地才会有Pack的特殊能力（变成基地车）
|
||||
- 指挥中心不能建造建筑，不会成为“建造者”。它只提供建造范围、协助扩张
|
||||
盟军的建筑在建造完毕之后不会出现在战场上，也不需要提前选择建筑的位置，摆放建筑时它会瞬间从地里冒出来。这个特色让盟军可以预留一个造好的防御塔，但先不摆放建筑，之后可以瞬间让防御塔摆放在需要的位置。
|
||||
因此，盟军的“摆放建筑”代表建造已经完毕，而其他阵营的“摆放建筑”则代表建造还没开始。
|
||||
盟军常用建筑与升级:
|
||||
- 兵营(AlliedBarracks)：生产步兵单位。只能摆放在陆地上。
|
||||
- 电厂(AlliedPowerPlant)：提供电力，解锁矿场和机场。
|
||||
- 矿厂(AlliedRefinery)：提供收入，解锁重工、船厂和科技。
|
||||
- 机场(AlliedAirfield)：生产空军单位。
|
||||
- 重工(AlliedWarFactory)：生产装甲车辆。只能摆放在陆地上。
|
||||
- 船厂(AlliedNavalYard)：生产海军单位。只能摆放在海上。
|
||||
- T2科技(Upgrade_AlliedTech2)：解锁T2单位
|
||||
- T3科技(Upgrade_AlliedTech3)：解锁T3单位
|
||||
- 多功能炮台(AlliedBaseDefense)：基础防御塔，可以攻击地面、海面或空中目标
|
||||
- 高科(AlliedTechStructure)：解锁超级武器
|
||||
盟军基础常用单位：
|
||||
- 矿车(AlliedMiner)：无武装，两栖，可通过SpecialPower_UnpackReplaceSelf在陆地或水上展开变成指挥中心。矿车可由矿场、重工和船厂生产。由于矿场自带矿车，玩家一般不需要额外生产矿车，除非：矿车被摧毁需要补充，或者玩家想要让矿车展开成指挥中心用于基地扩张
|
||||
- 狗(AlliedScoutInfantry)：侦察单位，两栖，非常脆弱，只能攻击步兵，吼叫技能(SpecialPower_Bark)可以AOE瘫痪敌方步兵。由于两栖特性，玩家可能利用它去绕海侦察。绕海侦察不一定会导致战斗，因为狗无法攻击载具和建筑而且非常脆弱，但它能够提供视野和侦察信息。
|
||||
- 维和步兵(AlliedAntiInfantryInfantry)：基础反步兵单位，数值和造价都偏高，可以抗线，可以掩护其他脆弱的单位，可以在霰弹枪和防暴盾牌之间切换(SpecialPower_ToggleRiotShield)
|
||||
- 标枪兵(AlliedAntiVehicleInfantry)：反装甲以及防空单位，无法反步兵且较为脆弱，但假如数量多可以成为输出主力，激光制导(SpecialPower_RadarLock)可以大幅提高输出
|
||||
- 工程师(AlliedEngineer)：两栖，可用于占领建筑或维修己方建筑。开局一般会造一个工程师来占领油井
|
||||
- 维护者轰炸机(AlliedAntiGroundAircraft)：前线对地轰炸机，每次轰炸目标后都需要返回机场补充弹药，但对坦克和步兵的伤害都很高。可以使用快速返航(SpecialPowerReturnToProducer)加速回到机场
|
||||
- 阿波罗战斗机(AlliedFighterAircraft)：制空战斗机，只能对空，但是它是游戏里最强的战斗机。可以使用快速返航(SpecialPowerReturnToProducer)加速回到机场
|
||||
- 激流ACV(AlliedAntiInfantryVehicle)：两栖，反步兵气垫船，由船厂生产，可以运输步兵
|
||||
- 激流ACV(AlliedAntiInfantryVehicle_Ground)：激流ACV也可从重工生产
|
||||
- IFV(AlliedAntiAirVehicle)：多功能步兵战车，脆弱但高速的基础陆地防空单位，可以装载步兵切换其他武器
|
||||
- 海豚(AlliedAntiNavalScout)：搭载声波武器的前期对海单位，脆弱，但速度快，可攻击水面单位或建筑，可以使用跳跃技能(SpecialPower_TriggerJump)来躲避攻击
|
||||
- 水翼船(AlliedAntiAirShip)：是游戏里最强的水面防空单位，默认使用防空机枪，但可以在干扰器和防空机枪之间切换(SpecialPower_ToggleWeaponScrambler)，切换为干扰器之后，水翼船可以禁止敌方目标开火
|
||||
- 基地车(AlliedMCV)：两栖，昂贵且耗时的无武装车辆，但血量很高。可以在陆地或水上展开为主基地。一般不会额外造基地车、只会使用开局本来就有的唯一一个主基地。
|
||||
盟军T2常用单位，需要T2升级(Upgrade_AlliedTech2)：
|
||||
- 守护者坦克(AlliedAntiVehicleVehicleTech1)：盟军反装甲坦克，切换为激光指示器(SpecialPower_ToggleTargetPainter)来提高友军的输出。由于激光指示器无法叠加，而且盟军步兵和飞机的输出很高，所以守护者的出场率偏低，一般造一两个。但假如数量够多也有奇效。
|
||||
- 冷冻直升机(AlliedSupportAircraft)：盟军最强大的支援直升机，被它攻击的目标不会受到伤害，但会被冻住。冰冻状态下的单位无法开火或移动，而且可被其他单位一击秒杀。冷冻直升机可以对单个敌军或友军目标使用缩小光束(SpecialPower_ShrinkRay)，缩小的单位各项属性都被大幅削弱，但速度增加。
|
||||
- 突袭驱逐舰(AlliedAntiNavyShipTech1)：两栖，坚固的船厂T2单位，只能使用输出较低的舰炮。它可以用黑洞装甲(SpecialPower_ToggleMagneticArmor)把敌方火力都吸引到自己身上，从而对友军提供掩护。突袭驱逐舰在陆地上移动，它在岸上同样可以吸收敌方火力，掩护陆军和空军
|
||||
盟军T3常用单位，需要T3升级(Upgrade_AlliedTech3)：
|
||||
- 雅典娜炮(AlliedAntiStructureVehicle)：盟军远距离对地攻城单位，引导太空卫星激光攻击固定或低速目标，还可以开启巨大的护盾(SpecialPower_ToggleShieldSphere)来掩护附近的友军
|
||||
- 幻影坦克(AlliedAntiVehicleVehicleTech3)：使用光谱武器的先进攻击坦克，伤害很高，但射程很低。因此出场率不如雅典娜炮
|
||||
- 世纪轰炸机(AlliedBomberAircraft)：擅长攻击建筑等大型目标的战略轰炸机，可用来轰炸敌方基地。攻击后需要返回机场补充弹药。可以运输步兵并使用SpecialPower_EjectPassengersUntargeted让步兵跳伞。
|
||||
- 航空母舰(AlliedAntiStructureShip)：盟军远距离对地攻城单位，可以释放无人机攻击海面或地面目标
|
||||
- 谭雅(AlliedCommandoTech1)：两栖，盟军英雄步兵单位，擅长反步兵和反建筑的无双女士兵。她的时空腰带(SpecialPower_TimeBelt)能让谭雅回溯到一段时间之前的血量和坐标位置。她可以高效炸毁建筑，因此玩家会设法把谭雅进入（或者直接用载具运输到）敌方基地。每个玩家同时只能有一位谭雅
|
||||
盟军常用开局：
|
||||
- 常规兵营开局（较为泛用），以下是几种兵营开的变种：
|
||||
A. 兵营、电站、矿场x2、[卖掉兵营 避免摆下机场后电力不足]、机场（卖掉兵营导致步兵较少，但机场更快）
|
||||
B. 兵营、电站、矿场x2、电厂、机场；（先造第二个电厂，这样就不需要卖兵营来省电了，能一直续步兵，但机场更慢）
|
||||
- 速机场开局（前期飞机压制力强、可以尽快造完建筑、并移动主基地进行扩张）：电站、机场、矿场、矿场
|
||||
- 单矿机场开局（前期飞机压制力强，而且还有步兵，但是经济代价较高）：兵营、电站、矿场、机场、矿场
|
||||
- 船转机开局（同时拥有步兵、激流ACV和飞机，但需要造的建筑更多、经济代价较高）：兵营、电站、矿场、矿场、[卖掉兵营避免电力不足]、船厂、[造完ACV后卖掉船厂避免电力不足]、机场
|
||||
假如盟军主基地打包成了基地车(SpecialPower_PackReplaceSelf)，则意味着盟军开局阶段的结束
|
||||
假如盟军的矿车或者基地车展开，说明盟军开始扩张基地，也代表盟军开局阶段即将结束
|
||||
盟军协议：
|
||||
- 先进航空学(PlayerTech_Allied_AirPower)：大部分盟军玩家开局默认使用的协议，来启用自己的空军单位，这是盟军的常规战术。选择该协议不代表盟军立刻会使用空军，请留意玩家实际上的出兵。
|
||||
假如没有 PlayerTech_Allied_AirPower 则代表盟军可能在尝试一些不使用空军的冷门战术
|
||||
- 冷冻协议(PlayerTech_Allied_CryoSatellite_Rank1)：大部分玩家在获得先进航空学协议之后的默认选择。解锁协议技能SpecialPowerCryoSatelliteLvl1，可以冰冻战场上的一小块区域。假如不及时逃离这片区域，被冻住的目标会被其他单位一击秒杀。
|
||||
后续可以解锁更高级别的冷冻协议以及协议技能。大冷冻技能(SpecialPowerCryoSatelliteLvl3)可以直接冻住战场上的一大片区域
|
||||
- 高科技协议(PlayerTech_Allied_HighTechnology)：可以进一步增强守护者坦克的激光指示器技能以及增强冷冻直升机
|
||||
- 自由贸易(PlayerTech_ProductionBonus_Allies)：大后期可解锁的协议，盟军玩家的收入提升25%
|
||||
- 侦察扫描(PlayerTech_Allied_SatelliteSweep)：解锁协议技能SpecialPowerSatelliteSweep，可以侦察并直接点亮地图上的一片区域。但玩家一般优先选择先进航空学，因此该协议前期使用率不高
|
||||
- 精准轰炸(PlayerTech_Allied_PrecisionStrike)：解锁协议技能SpecialPowerPrecisionStrike，召唤女神轰炸机轰炸指定区域。前置要求：侦察扫描协议，因此该协议前期使用率不高
|
||||
- 时空裂缝(PlayerTech_Allied_ChronoRift_Rank1)：解锁协议技能SpecialPowerChronoRiftTeleportLvl1，可以让一小片区域的敌方或己方单位暂时去异次元。前置要求：侦察扫描、精准轰炸，因此该协议前期使用率不高
|
||||
后续可以解锁更高级别的时空裂缝协议，范围更大，控场效果更强
|
||||
盟军超级武器：
|
||||
- 超时空传送仪(AlliedSuperWeapon) 超级武器 每次至少需要3分钟准备 利用超时空科技(SpecialPowerChronosphereObjectSelect, SpecialPowerChronosphereObjectSpawn)，把己方或敌方部队送往合适的目的地，或者传到不合适的目的地来秒杀单位（例如把坦克传到水底，或把海军传到岸上），不可传送建筑
|
||||
- 质子撞击炮(AlliedSuperWeaponAdvanced) 终极武器 每次至少需要6分钟准备(SpecialPowerParticleCannon)，对一大片地面目标造成伤害
|
||||
|
||||
|
||||
阵营：神州
|
||||
神州只能拥有一个主基地。神州的建筑不受建造范围的限制，即使不移动主基地，也可以把建筑摆在任何一个地方。
|
||||
建造时，神州需要先摆放建筑，随后主基地会自动产生一个飞行核心朝目标位置飞去。飞行核心抵达目标位置后，自动变成建筑。
|
||||
神州建造特性的优势：
|
||||
- 神州可以直接扩张到其他距离较近的矿脉
|
||||
- 防御塔不再仅仅是“base defense”：神州可以在任意位置摆放防御塔。神州可以往前线、甚至敌方家里摆放防御塔，然后敌方必须额外造防空单位来拦截飞过来的防御塔核心。
|
||||
神州建造特性的劣势：
|
||||
- 必须等待核心飞到目的地才可以继续建造。因此远距离建造会大幅降低效率。
|
||||
- 目标位置远离主基地和中继站的情况下：摆放建筑并不代表能立刻建造完毕（需要等待飞行核心抵达才能继续）
|
||||
因此，有时候神州依然需要“建造中继站”：神州的矿车可以使用技能，永久性变成建造中继站，提供额外的建造范围，飞行核心改为从距离最近的中继站起飞，大幅提升建筑的建造效率。
|
||||
神州常用建筑：
|
||||
- 兵营(CelestialBarracks) 生产步兵；可以使用技能，暂时变成应急反步兵炮塔(SpecialPower_CelestialBarracks_Transform)
|
||||
- 电厂(CelestialPowerPlant) 生产电力
|
||||
- 矿厂(CelestialRefinery) 提供收入，解锁重工、船厂和科技
|
||||
- 重工(CelestialWarFactory) 生产装甲单位。
|
||||
- 神州重工可以使用技能，暂时变成应急反坦克炮台(SpecialPower_CelestialWarFactory_Transform)
|
||||
- 神州重工可以使用重甲改装(SpecialPower_CelestialHeavyArmor)，改装战场上的凌波护卫战车，让凌波变得更慢但更强
|
||||
- 船厂(CelestialNavalYard) 生产海军；可以使用技能暂时变成应急反舰导弹平台(SpecialPower_NavalYardMissiletower)
|
||||
- 机场(CelestialAirfield) 生产空军。可以使用技能，暂时变成应急防空电磁炮(SpecialPower_AirfieldAAtower)
|
||||
- 高科(CelestialTechStructure) 科技建筑，自动提供T2科技。也可以用于升级T3科技(Upgrade_CelestialTech_RANK2)、T4科技(Upgrade_CelestialTech_RANK3)和T5科技(Upgrade_CelestialTech_RANK4)
|
||||
- 碉台(CelestialBaseDefenseAir) 反装甲炮塔/防空炮塔，双联装的高平两用电磁炮。
|
||||
- 浑天塔(CelestialBaseDefenseAdvanced) 先进基地防御，只能对地。这座高塔能同时对多个目标发射光束，对目标进行减速并削弱他们的护甲。
|
||||
- 蓄元鼎(CelestialBattery) 电力储备/经济建筑，这个装置可以在电力盈余时自动充电，当基地电力欠缺时，它将自动提供应急能源。此建筑也可以出售周围电厂的电力来换取资金(SpecialPower_CelestialElectricitySale)
|
||||
神州常用升级：
|
||||
- T3科技(Upgrade_CelestialTech_RANK2)：解锁T3单位
|
||||
- T4科技(Upgrade_CelestialTech_RANK3)：解锁T4单位
|
||||
**注意**：神州的 Upgrade_CelestialTech_RANK2 是 T3，不是 T2；
|
||||
神州基础常用单位：
|
||||
- 矿车(CelestialMiner) 无武装，两栖，必要时可以拓展前线基地(SpecialPower_UnpackReplaceSelf)
|
||||
- 天眼哨机(CelestialScoutDrone) 由兵营生产的飞行侦察无人机，无法对敌方目标造成伤害。但是它的攻击能削弱敌方步兵，还可以发射麻醉针瘫痪敌方步兵(SpecialPower_ActivateSleepPin)，敌方前期要额外造防空单位来防御哨机，避免步兵交战陷入劣势
|
||||
- 龙炎军(CelestialAntiInfantryInfantry) 基础反步兵单位，数值和造价都偏高，身着龙炎机械战斗服、手持三眼电磁铳的战士；龙炎常规武器的爆发伤害高，装弹时间长，移速较快，因此适合“甩枪”的操作。有经验的玩家会让龙炎反复前进和撤退，让龙炎进行拉扯，在前期步兵战斗中取得优势。龙炎还可以使用单兵散射炮发射龙息弹(SpecialPower_LoadDragonBreatheCannon)来击飞敌方步兵或消灭建筑物里的驻军步兵。
|
||||
- 铁卫(CelestialAntiVehicleInfantry) 反装甲/防空步兵，能用高速穿甲弹击穿厚重的坦克装甲，亦能在架设护盾后发射破墙榴弹 (SpecialPower_ToggleShield)
|
||||
- 凌波护卫战车(CelestialAntiInfantryVehicle_B) 轻型反步兵运兵战车，两栖，配备机炮的两栖步战车，可以运输步兵(SpecialPower_GatherPassenger)
|
||||
- 磁弩(CelestialAntiAirShip) 轻型防空车，两栖，由重工生产，可以使用技能(SpecialPower_ToggleHeavyEMCannonWeapon)把防空速射炮换成对地的磁轨炮，变成轻型的两栖反载具单位，或者使用相同技能切换回防空速射炮
|
||||
- 磁弩(CelestialAntiAirShip_Water) 磁弩也可从船厂生产
|
||||
- 乌篷猎船(CelestialAntiNavyShipTech1) 反舰快艇/猎潜艇，这些不起眼的轻型小船装备了能发射聚焦冲击波的武器，能对军舰和潜艇造成破坏，猎船可以放置声纳浮标让敌方潜艇无处遁形(SpecialPower_CelestialSonarBuoy)
|
||||
- 凤凰战机(CelestialFighterAircraft) 制空战斗机，可以使用技能快速回到机场(SpecialPowerReturnToProducer_F)
|
||||
- 毕方支援机(CelestialSupportAircraft) 支援直升机，搭载高能激光器的直升机，本身伤害较低，但能使敌方车辆装甲熔融，降低敌方目标护甲。使用技能可以在激光器主武器和电磁支援之间切换(SpecialPower_ToggleCelestialSupportAircraftBuffWeapon)，切换为电磁支援后可以增加友军输出
|
||||
神州T2常用单位，需要神州高科(CelestialTechStructure)：
|
||||
- 岚影刺(CelestialInfiltrationInfantry) 渗透部队/狙击手，两栖，她可以从远处暗杀敌方步兵，也可以化妆成敌方步兵(SpecialPower_CelestialDisguise)，让敌方无法发现
|
||||
- 朱雀(CelestialAttackerAircraft) 对地攻击机，搭载中型离子炮的反装甲攻击机，还可以喷火反步兵或者削弱敌方装甲(SpecialPower_ActivateFire)
|
||||
- 麒麟(CelestialAntiVehicleVehicleTech1) 反装甲主战坦克，神州陆军的新一代中流砥柱。可以使用技能偏转敌方来袭的炮火和导弹(SpecialPower_ToggleRangeUpdateCelestial)
|
||||
- 青锋导弹车(CelestialLongRangeMissileVehicle_B) 远程反装甲，装备反坦克导弹的轻型载具，足以应对装甲目标，还可以发射烟雾弹削弱敌方单位的射程(SpecialPower_TriggerSmokeBombMissile)
|
||||
- 计蒙驱逐舰(CelestialAlmightlyShip) 制海战舰，多用途驱逐舰，用舰炮和导弹对付海面、潜水或地面目标。可以使用阻止敌方单位使用技能(SpecialPower_CelestialShipScrambler)
|
||||
神州T3常用单位，需要T3升级(Upgrade_CelestialTech_RANK2)：
|
||||
- 天罡(CelestialAntiInfantryInfantryAdvanced) 高级步兵，先进反步兵/反飞行器，配备外骨骼和迅雷转轮机关铳的精英步兵，能快速收割敌方步兵、击落敌方飞行器。还可以瘫痪牵制敌方载具(SpecialPower_ActivateEMPThunder)
|
||||
- 祝融(CelestialAntiVehicleVehicleTech3) 先进反装甲重型坦克，搭载了转轮式装弹的大型离子炮，借由主炮的余热可持续提高武器射速，使用技能可以大幅提高移速(SpecialPower_RapidCooling)
|
||||
- 白虎(CelestialAntiStructureVehicle) 远距离对地攻城单位，可以发射高能等离子体团攻击远处的目标，也可以产生临时量子压制力场(SpecialPower_CelestialQuantumBreak)减速并削弱力场内的敌方目标
|
||||
- 重明(CelestialInterceptorAircraft) 擅长拦截敌方重型空军的截击机，能发射炽热等离子束武器，可以使用技能快速回到机场(SpecialPowerReturnToProducer_F)
|
||||
- 金乌(CelestialBomberAircraft) 重型轰炸机，发射导弹攻击低速目标、建筑和敌方军舰。可以使用技能快速回到机场(SpecialPowerReturnToProducer_F)
|
||||
- 玄冥(CelestialAntiNavyShipTech3) 先进制海战舰，装备多种先进武器的巨型战舰，可以使用技能扫描远距离的海上目标并发射导弹(SpecialPower_CANSTier3HuntingMissile)
|
||||
神州T4常用单位，需要T3升级(Upgrade_CelestialTech_RANK3)：
|
||||
- 摇光巡天炮(CelestialAdvanceAircraftTech4) 实验级飞行重轰炸，常态下无武装，但是可以展开到亚轨道高空。使用技能在常态和亚轨道状态之间切换(SpecialPower_CAAT4_Transform)。在亚轨道彻底展开的摇光巡天炮，能对一切目标发动穿透力极强的聚变射流攻击！
|
||||
- 玄武(CelestialAntiStructureShip) 神州远距离对地轰炸，导弹攻击潜艇，额外装备有远近皆宜的对舰武器，还可以使用技能发射核弹(SpecialPower_CelestialShipMissle_01)
|
||||
- 破军金甲(CelestialAntiVehicleVehicleTech4) 实验级反装甲机器人 巨大的战斗机甲，凭借无与伦比的厚重装甲冲进敌方坦克集群，并挥动能量巨剑将目标劈成两半，是敌方装甲部队的噩梦，可以使用技能越过障碍或直接降落到敌方部队中间(SpecialPower_CelestialArmybreakerLeap)
|
||||
神州常用开局：
|
||||
- 常规兵营开局：兵营，电厂，矿场，矿场，矿场；依靠神州强大的前期步兵进行压制，直接完成第三个矿场的扩张，然后再造其他建筑。神州的天眼哨机和碉台飞行核心可能会迫使对手出防空步兵（而不是出反步兵的基础步兵），可能让神州基础步兵获得短暂的数量优势
|
||||
- 二矿重工开局：兵营，电厂，矿场，矿场，重工；假如前线步兵压力较大，也可以提前造重工，用凌波护卫战车辅助步兵，也可以让磁弩防空车切换成对地武器，并从陆地或海上进攻
|
||||
- 二矿机场开局：兵营，电厂，矿场，矿场，机场；适合对帝国的天狗机甲等单位进行空军压制
|
||||
神州协议：
|
||||
- 百夫长(PlayerTech_Celestial_CenturionUpgrade)：解锁协议技能SpecialPower_CelestialCenturionUpgrade，可强化一个步兵。
|
||||
- 压制力场(PlayerTech_Celestial_EMSuppressField_Lv1)：百夫长的后续协议。解锁协议技能SpecialPower_Celestial_EMSuppressField_Lv1，可以让一小片区域内的敌方单位大幅减速。
|
||||
后续可以解锁更高级别的压制力场。大型压制力场(SpecialPower_Celestial_EMSuppressField_Lv3)可以让一大片区域内的敌方单位大幅减速。
|
||||
- 空投仓(PlayerTech_Celestial_SpaceReinforce)：压制力场的后续协议。解锁协议技能SpecialPower_CelestialSpaceReinforce，可从太空往地图上的任意陆地区域投送龙炎军和破甲铁卫
|
||||
- 电能纳贡(PlayerTech_Celestial_PowerSealOff)：解锁协议技能SpecialPower_CelestialPowerSealOff。只能对敌方电厂释放，让敌方电力暂时减少、己方电力暂时增加
|
||||
- 天火塔(PlayerTech_Celestial_EMTurretDrop)：电能纳贡的后续协议。解锁协议技能SpecialPowerCelestialEMTurretDrop，可从太空往地图上的任意陆地区域投送一个对地的激光防御塔
|
||||
- 雷铸天兵(PlayerTech_Celestial_lightningTroopUpgrade_Lv1)：天火塔的后续协议。解锁协议技能SpecialPower_CelestiallightningTroopUpgrade_Lv1，产生一道闪电，可以为己方部队充能并大幅强化己方部队，也可以用于对敌方部队造成伤害
|
||||
神州超级武器：
|
||||
- 日晷阵列(CelestialSuperWeapon) 超级武器 每次至少需要3分钟准备，可以释放止戈力场(SpecialPowerPause01)，止戈力场内的敌我双方均不能开火，可用于阻挡敌方特殊能力、协议、或紧急救援己方单位
|
||||
- 浴日神坛(CelestialSuperWeaponAdvanced) 终极武器 每次至少需要6分钟准备，向指定区域发射日冕风暴(SpecialPowerCelestialCannon)，杀伤区域内的所有目标
|
||||
|
||||
|
||||
当前交战的地图是：无限岛
|
||||
这张地图是对称的，只有一条陆地进攻路线，也是主要的陆地交战区域，中央高地。
|
||||
中央高地是长条状的，只有两个出入口，位于中央高地的两端，通向两位玩家的出生点。
|
||||
玩家可以在高地战场正面交锋，也可以选择绕海，或者使用空军（不受地形限制）。
|
||||
低地被中央高地分割成两部分，低地都是三面环海（还有一面是高地），两栖单位可以从低地上岸或下水。
|
||||
中央高地也有靠海的地方，但两栖单位无法跨越悬崖从高地直接入海，需要从低地绕道。（额外矿区）
|
||||
每个矿区可以摆放一个矿厂。
|
||||
|
||||
# 地图参数
|
||||
海面高度：Z=200
|
||||
低地高度：Z=210
|
||||
高地高度：Z=280
|
||||
|
||||
## 出生点1（陆地）(X=1390,Y=1590,Z=210)
|
||||
- 矿区(X=1230,Y=1975,Z=210)
|
||||
- 矿区(X=1760,Y=1485,Z=210)
|
||||
### 高地油井(X=2280,Y=2770,Z=280)
|
||||
### 扩张方向
|
||||
- 矿区，海面，远离中央区域(X=870,Y=870,Z=200)
|
||||
- 矿区，中央高地(X=1740,Y=2760,Z=280)，在它附近有：高地通往出生点1的唯一陆地路线。
|
||||
- 额外矿区，海面，中央高地悬崖外面的海矿(X=2710,Y=2865,Z=200)
|
||||
|
||||
## 出生点2（陆地）(X=3980,Y=2190,Z=210)
|
||||
- 矿区(X=4030,Y=1760,Z=210)
|
||||
- 矿区(X=3540,Y=2290,Z=210)
|
||||
### 高地油井(X=2980,Y=1050,Z=280)
|
||||
### 扩张方向
|
||||
- 矿区，海面，远离中央区域(X=4390,Y=2910,Z=280)
|
||||
- 矿区，中央高地(X=3250,Y=1060,Z=280)，在它附近有：高地通往出生点2的唯一陆地路线。
|
||||
- 额外矿区，海面，中央高地悬崖外面的海矿(X=2650,Y=850,Z=280)
|
||||
|
||||
地图中央点：(X=2650,Y=1900,Z=280)
|
||||
地图边界（X）：0~5300
|
||||
地图边界（Y）：0~3800
|
||||
@@ -0,0 +1,269 @@
|
||||
{
|
||||
"format": "1.1",
|
||||
"description": "Structured game entity knowledge for prompt rendering and AI validation.",
|
||||
"factions": {
|
||||
"盟军": {
|
||||
"buildings": [
|
||||
{
|
||||
"assetName": "AlliedBarracks",
|
||||
"displayName": "兵营",
|
||||
"tags": ["structure", "land"],
|
||||
"text": "生产步兵单位。只能摆放在陆地上。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedPowerPlant",
|
||||
"displayName": "电厂",
|
||||
"tags": ["structure", "land"],
|
||||
"text": "提供电力，解锁矿场和机场。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedRefinery",
|
||||
"displayName": "矿厂",
|
||||
"tags": ["structure", "land"],
|
||||
"text": "提供收入，解锁重工、船厂和科技。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAirfield",
|
||||
"displayName": "机场",
|
||||
"tags": ["structure", "air", "land"],
|
||||
"text": "生产空军单位。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedWarFactory",
|
||||
"displayName": "重工",
|
||||
"tags": ["structure", "vehicle", "land"],
|
||||
"text": "生产装甲车辆。只能摆放在陆地上。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedNavalYard",
|
||||
"displayName": "船厂",
|
||||
"tags": ["structure", "naval", "sea"],
|
||||
"text": "生产海军单位。只能摆放在海上。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedBaseDefense",
|
||||
"displayName": "多功能炮台",
|
||||
"tags": ["structure", "defense", "land"],
|
||||
"text": "基础防御塔，可以攻击地面、海面或空中目标。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedTechStructure",
|
||||
"displayName": "高科",
|
||||
"tags": ["structure", "land"],
|
||||
"text": "解锁超级武器。"
|
||||
}
|
||||
],
|
||||
"units": [
|
||||
{
|
||||
"assetName": "AlliedMiner",
|
||||
"displayName": "矿车",
|
||||
"tier": "基础",
|
||||
"tags": ["vehicle", "amphibious", "unpack", "miner"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_UnpackReplaceSelf", "description": "在陆地或水上展开变成指挥中心" }
|
||||
],
|
||||
"producedBy": ["AlliedRefinery", "AlliedWarFactory", "AlliedNavalYard"],
|
||||
"text": "无武装。矿场自带矿车，一般无需额外生产，除非被摧毁或需要展开指挥中心。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedScoutInfantry",
|
||||
"displayName": "狗",
|
||||
"tier": "基础",
|
||||
"tags": ["infantry", "amphibious", "scout", "antiInfantry"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_Bark", "description": "AOE 瘫痪敌方步兵" }
|
||||
],
|
||||
"producedBy": ["AlliedBarracks"],
|
||||
"text": "侦察单位，非常脆弱，只能攻击步兵。两栖，可利用绕海侦察。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiInfantryInfantry",
|
||||
"displayName": "维和步兵",
|
||||
"tier": "基础",
|
||||
"tags": ["infantry", "antiInfantry"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_ToggleRiotShield", "description": "在霰弹枪和防暴盾牌之间切换" }
|
||||
],
|
||||
"producedBy": ["AlliedBarracks"],
|
||||
"text": "数值和造价偏高，可以抗线掩护其他单位。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiVehicleInfantry",
|
||||
"displayName": "标枪兵",
|
||||
"tier": "基础",
|
||||
"tags": ["infantry", "antiVehicle", "antiAir"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_RadarLock", "description": "激光制导，大幅提高输出" }
|
||||
],
|
||||
"producedBy": ["AlliedBarracks"],
|
||||
"text": "反装甲兼防空，无法反步兵。数量多时可成为输出主力。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedEngineer",
|
||||
"displayName": "工程师",
|
||||
"tier": "基础",
|
||||
"tags": ["infantry", "amphibious", "engineer"],
|
||||
"producedBy": ["AlliedBarracks"],
|
||||
"text": "可用于占领建筑或维修己方建筑。开局一般造一个占领油井。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiGroundAircraft",
|
||||
"displayName": "维护者轰炸机",
|
||||
"tier": "基础",
|
||||
"tags": ["aircraft", "antiGround", "returnToProducer", "bomber"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPowerReturnToProducer", "description": "快速返航回机场补充弹药" }
|
||||
],
|
||||
"producedBy": ["AlliedAirfield"],
|
||||
"text": "前线对地轰炸机，对坦克和步兵的伤害都很高。每次轰炸后需要返回机场补充弹药。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedFighterAircraft",
|
||||
"displayName": "阿波罗战斗机",
|
||||
"tier": "基础",
|
||||
"tags": ["aircraft", "antiAir", "fighter", "returnToProducer"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPowerReturnToProducer", "description": "快速返航回机场补充弹药" }
|
||||
],
|
||||
"producedBy": ["AlliedAirfield"],
|
||||
"text": "制空战斗机，只能对空，游戏里最强的战斗机。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiInfantryVehicle",
|
||||
"displayName": "激流ACV",
|
||||
"tier": "基础",
|
||||
"tags": ["vehicle", "amphibious", "antiInfantry", "transport"],
|
||||
"producedBy": ["AlliedNavalYard"],
|
||||
"aliases": ["AlliedAntiInfantryVehicle_Ground"],
|
||||
"alsoProducedBy": ["AlliedWarFactory"],
|
||||
"text": "反步兵气垫船，两栖，可运输步兵。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiAirVehicle",
|
||||
"displayName": "IFV",
|
||||
"tier": "基础",
|
||||
"tags": ["vehicle", "antiAir", "transport"],
|
||||
"producedBy": ["AlliedWarFactory"],
|
||||
"text": "多功能步兵战车，基础陆地防空单位，可装载步兵切换武器。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiNavalScout",
|
||||
"displayName": "海豚",
|
||||
"tier": "基础",
|
||||
"tags": ["naval", "antiNaval", "scout"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_TriggerJump", "description": "跳跃躲避攻击" }
|
||||
],
|
||||
"producedBy": ["AlliedNavalYard"],
|
||||
"text": "搭载声波武器的前期对海单位，速度快，可攻击水面单位或建筑。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiAirShip",
|
||||
"displayName": "水翼船",
|
||||
"tier": "基础",
|
||||
"tags": ["naval", "antiAir", "toggleWeapon"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_ToggleWeaponScrambler", "description": "在防空机枪和干扰器之间切换；干扰器禁止敌方目标开火" }
|
||||
],
|
||||
"producedBy": ["AlliedNavalYard"],
|
||||
"text": "水面防空单位。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedMCV",
|
||||
"displayName": "基地车",
|
||||
"tier": "基础",
|
||||
"tags": ["vehicle", "amphibious", "builder", "pack", "unpack"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_PackReplaceSelf", "description": "主基地打包变成基地车" },
|
||||
{ "name": "SpecialPower_UnpackReplaceSelf", "description": "基地车展开变成主基地" }
|
||||
],
|
||||
"producedBy": ["AlliedWarFactory"],
|
||||
"text": "昂贵且耗时，血量很高。一般只有开局自带的唯一一辆。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiVehicleVehicleTech1",
|
||||
"displayName": "守护者坦克",
|
||||
"tier": "T2",
|
||||
"tags": ["vehicle", "antiVehicle", "toggleWeapon"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_ToggleTargetPainter", "description": "切换为激光指示器，提高友军输出" }
|
||||
],
|
||||
"producedBy": ["AlliedWarFactory"],
|
||||
"text": "出场率偏低，一般造一两个辅助。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedSupportAircraft",
|
||||
"displayName": "冷冻直升机",
|
||||
"tier": "T2",
|
||||
"tags": ["aircraft", "support"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_ShrinkRay", "description": "缩小光束，削弱目标并加速" }
|
||||
],
|
||||
"producedBy": ["AlliedAirfield"],
|
||||
"text": "被攻击的目标被冻住无法开火或移动，可被一击秒杀。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiNavyShipTech1",
|
||||
"displayName": "突袭驱逐舰",
|
||||
"tier": "T2",
|
||||
"tags": ["naval", "amphibious", "antiVehicle", "antiNaval", "toggleWeapon"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_ToggleMagneticArmor", "description": "黑洞装甲，把敌方火力吸引到自己身上" }
|
||||
],
|
||||
"producedBy": ["AlliedNavalYard"],
|
||||
"text": "两栖。在岸上同样可以吸收火力掩护友军。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiStructureVehicle",
|
||||
"displayName": "雅典娜炮",
|
||||
"tier": "T3",
|
||||
"tags": ["vehicle", "antiStructure", "siege"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_ToggleShieldSphere", "description": "开启巨大护盾掩护附近友军" }
|
||||
],
|
||||
"producedBy": ["AlliedWarFactory"],
|
||||
"text": "远距离对地攻城单位，引导卫星激光攻击固定或低速目标。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiVehicleVehicleTech3",
|
||||
"displayName": "幻影坦克",
|
||||
"tier": "T3",
|
||||
"tags": ["vehicle", "antiVehicle"],
|
||||
"producedBy": ["AlliedWarFactory"],
|
||||
"text": "使用光谱武器，伤害很高但射程很低。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedBomberAircraft",
|
||||
"displayName": "世纪轰炸机",
|
||||
"tier": "T3",
|
||||
"tags": ["aircraft", "antiStructure", "bomber", "returnToProducer", "transport"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPowerReturnToProducer", "description": "快速返航回机场" },
|
||||
{ "name": "SpecialPower_EjectPassengersUntargeted", "description": "让步兵跳伞" }
|
||||
],
|
||||
"producedBy": ["AlliedAirfield"],
|
||||
"text": "战略轰炸机，擅长攻击建筑等大型目标。可运输步兵。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedAntiStructureShip",
|
||||
"displayName": "航空母舰",
|
||||
"tier": "T3",
|
||||
"tags": ["naval", "antiStructure", "siege"],
|
||||
"producedBy": ["AlliedNavalYard"],
|
||||
"text": "远距离对地攻城单位，释放无人机攻击海面或地面目标。"
|
||||
},
|
||||
{
|
||||
"assetName": "AlliedCommandoTech1",
|
||||
"displayName": "谭雅",
|
||||
"tier": "T3",
|
||||
"tags": ["infantry", "amphibious", "hero", "antiInfantry", "antiStructure"],
|
||||
"specialPowers": [
|
||||
{ "name": "SpecialPower_TimeBelt", "description": "时空腰带，回溯到之前的状态" }
|
||||
],
|
||||
"producedBy": ["AlliedBarracks"],
|
||||
"text": "英雄步兵单位，擅长反步兵和反建筑。可高效炸毁建筑。每个玩家同时只能有一位。"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,220 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Extract game knowledge strings from AIAnalyze.cs, expand [MOD:] tags,
|
||||
and write mod-specific knowledge files.
|
||||
|
||||
Usage: python expand_knowledge.py [--cs-path PATH]
|
||||
|
||||
Outputs:
|
||||
knowledge_default.md — base game (vanilla) knowledge
|
||||
knowledge_corona.md — Corona mod knowledge
|
||||
"""
|
||||
|
||||
import re
|
||||
import sys
|
||||
import os
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
# ── 1. Extract @"" verbatim strings from C# source ─────────────────────────
|
||||
|
||||
def extract_verbatim_string(text: str, start: int) -> tuple[str, int]:
|
||||
"""
|
||||
Extract a C# @"" verbatim string starting after '@"'.
|
||||
Returns (content, end_position).
|
||||
Handles "" as escaped double-quote.
|
||||
"""
|
||||
chars = []
|
||||
i = start
|
||||
while i < len(text):
|
||||
c = text[i]
|
||||
if c == '"':
|
||||
# Escaped quote "" → one literal "
|
||||
if i + 1 < len(text) and text[i + 1] == '"':
|
||||
chars.append('"')
|
||||
i += 2
|
||||
continue
|
||||
# End of verbatim string
|
||||
i += 1
|
||||
break
|
||||
chars.append(c)
|
||||
i += 1
|
||||
return ''.join(chars), i
|
||||
|
||||
|
||||
def find_strings(cs_path: str) -> dict[str, str]:
|
||||
"""Find all known knowledge string variables in the .cs file and return
|
||||
{variable_name: content}."""
|
||||
with open(cs_path, 'r', encoding='utf-8') as f:
|
||||
source = f.read()
|
||||
|
||||
known_vars = [
|
||||
'generalDescriptions',
|
||||
'alliedDescriptions',
|
||||
'celestialDescriptions',
|
||||
'infinityIsleVanilla',
|
||||
'infinityIsleCorona',
|
||||
]
|
||||
|
||||
results = {}
|
||||
for var in known_vars:
|
||||
# Look for: var {name} = @"
|
||||
pattern = f'var {var} = @"'
|
||||
idx = source.find(pattern)
|
||||
if idx == -1:
|
||||
print(f'[WARN] Could not find "{var}" in source')
|
||||
continue
|
||||
content, end = extract_verbatim_string(source, idx + len(pattern))
|
||||
# content still has the leading newline from @"\n...
|
||||
results[var] = content
|
||||
print(f'[OK] {var}: {len(content)} chars')
|
||||
|
||||
return results
|
||||
|
||||
|
||||
# ── 2. [MOD:] tag expansion ────────────────────────────────────────────────
|
||||
|
||||
def expand_mod_text(text: str, mod_name: str) -> str:
|
||||
"""Expand [MOD:...] and [MOD:NO:...] tags for the given mod.
|
||||
Mimics the logic in AIAnalyze.Process()."""
|
||||
lines = text.replace('\r', '').split('\n')
|
||||
result_lines = []
|
||||
skip_next = False
|
||||
|
||||
for line in lines:
|
||||
if skip_next:
|
||||
skip_next = False
|
||||
continue
|
||||
|
||||
stripped = line.strip()
|
||||
|
||||
# Line-level [MOD:xxx] (must be at start of line, possibly with leading spaces)
|
||||
# Check for [MOD:NO:xxx] first
|
||||
no_match = re.match(r'^(\s*)\[MOD:NO:([^\]]+)\]$', line)
|
||||
if no_match:
|
||||
indent, denied_mod = no_match.groups()
|
||||
if denied_mod.lower() == mod_name.lower():
|
||||
# [MOD:NO:corona] when mod is corona → skip content line
|
||||
skip_next = True
|
||||
# Either way, skip the tag line itself
|
||||
continue
|
||||
|
||||
# Check for [MOD:xxx]
|
||||
mod_match = re.match(r'^(\s*)\[MOD:([^\]]+)\]$', line)
|
||||
if mod_match:
|
||||
indent, entry_mod = mod_match.groups()
|
||||
if entry_mod.lower() != mod_name.lower():
|
||||
# This mod's content doesn't apply → skip content line
|
||||
skip_next = True
|
||||
# Skip the tag line itself
|
||||
continue
|
||||
|
||||
# Inline tags: process [MOD:xxx]content[/MOD] and [MOD:NO:xxx]content[/MOD]
|
||||
# Multiple inline tags can appear on one line (e.g. line 662)
|
||||
processed = line
|
||||
while True:
|
||||
# Find next [MOD: or [MOD:NO:
|
||||
tag_match = re.search(
|
||||
r'\[MOD:(NO:)?([^\]]+)\](.*?)\[/MOD\]',
|
||||
processed,
|
||||
re.IGNORECASE
|
||||
)
|
||||
if not tag_match:
|
||||
break
|
||||
|
||||
is_no = tag_match.group(1) is not None
|
||||
entry_mod = tag_match.group(2)
|
||||
inner_text = tag_match.group(3)
|
||||
before = processed[:tag_match.start()]
|
||||
after = processed[tag_match.end():]
|
||||
|
||||
include = False
|
||||
if is_no:
|
||||
# [MOD:NO:corona] → include if mod != corona
|
||||
if entry_mod.lower() != mod_name.lower():
|
||||
include = True
|
||||
else:
|
||||
# [MOD:corona] → include if mod == corona
|
||||
if entry_mod.lower() == mod_name.lower():
|
||||
include = True
|
||||
|
||||
if include:
|
||||
processed = before + inner_text + after
|
||||
else:
|
||||
processed = before + after
|
||||
|
||||
result_lines.append(processed)
|
||||
|
||||
return '\n'.join(result_lines)
|
||||
|
||||
|
||||
# ── 3. Assemble per-mod knowledge ──────────────────────────────────────────
|
||||
|
||||
def assemble_knowledge(strings: dict[str, str], mod_name: str) -> str:
|
||||
"""Assemble the full knowledge text for a given mod."""
|
||||
parts = []
|
||||
|
||||
# generalDescriptions — most is global rules, but has one inline [MOD:CORONA] tag
|
||||
# on the faction list line; process it to expand that tag.
|
||||
parts.append(expand_mod_text(strings.get('generalDescriptions', ''), mod_name).strip())
|
||||
|
||||
# alliedDescriptions
|
||||
allied = strings.get('alliedDescriptions', '')
|
||||
parts.append(expand_mod_text(allied, mod_name).strip())
|
||||
|
||||
# celestialDescriptions
|
||||
celestial = strings.get('celestialDescriptions', '')
|
||||
parts.append(expand_mod_text(celestial, mod_name).strip())
|
||||
|
||||
# Map description — mod-specific
|
||||
map_key = f'infinityIsle{mod_name.capitalize()}'
|
||||
if map_key in strings:
|
||||
parts.append(strings[map_key].strip())
|
||||
else:
|
||||
# Fallback: default map
|
||||
default_map = strings.get('infinityIsleVanilla', '')
|
||||
parts.append(expand_mod_text(default_map, mod_name).strip())
|
||||
|
||||
return '\n\n\n'.join(p for p in parts if p)
|
||||
|
||||
|
||||
# ── 4. Main ────────────────────────────────────────────────────────────────
|
||||
|
||||
def main():
|
||||
# Determine paths
|
||||
script_dir = Path(__file__).resolve().parent
|
||||
repo_root = script_dir.parent # tools/ is directly under repo root
|
||||
cs_path = repo_root / 'Utils' / 'AIAnalyze.cs'
|
||||
output_dir = repo_root
|
||||
|
||||
# Override via CLI
|
||||
if '--cs-path' in sys.argv:
|
||||
idx = sys.argv.index('--cs-path')
|
||||
if idx + 1 < len(sys.argv):
|
||||
cs_path = Path(sys.argv[idx + 1])
|
||||
|
||||
print(f'Reading: {cs_path}')
|
||||
if not cs_path.exists():
|
||||
print(f'[ERROR] File not found: {cs_path}')
|
||||
sys.exit(1)
|
||||
|
||||
# Extract all strings
|
||||
strings = find_strings(str(cs_path))
|
||||
if not strings:
|
||||
print('[ERROR] No strings extracted, aborting.')
|
||||
sys.exit(1)
|
||||
|
||||
# Generate per-mod files
|
||||
for mod_name in ('default', 'corona'):
|
||||
knowledge = assemble_knowledge(strings, mod_name)
|
||||
out_path = output_dir / f'knowledge_{mod_name}.md'
|
||||
with open(out_path, 'w', encoding='utf-8') as f:
|
||||
f.write(knowledge)
|
||||
lines = knowledge.count('\n') + 1
|
||||
print(f'[OK] {out_path.name}: {lines} lines, {len(knowledge)} chars')
|
||||
|
||||
print('\nDone. Files written to:', output_dir)
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
Reference in New Issue
Block a user