Zh/Working with instances: Difference between revisions

From Valve Developer Community
< Zh
Jump to navigation Jump to search
(Created page with "{{LanguageBar|Working with instances|使用实例}} {{portal2}} 在制作《传送门2》地图时使用实例（Instances）能大幅提升效率——从谜题原型设计到最终发布，整个过程如虎添翼！官方创作工具提供的标准实例几乎涵盖地图制作所有元素：从基础物件如地板按钮，到复杂机关如方块生成器，甚至非游戏元素如观察室。 == 实例是什么？ == 实例是地图构建时引用的VMF文件，...")
 
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{LanguageBar|Working with instances|使用实例}}
{{LanguageBar|Working with instances|title=使用实例}}
{{portal2}} 在制作《传送门2》地图时使用实例（Instances）能大幅提升效率——从谜题原型设计到最终发布，整个过程如虎添翼！官方创作工具提供的标准实例几乎涵盖地图制作所有元素：从基础物件如地板按钮，到复杂机关如方块生成器，甚至非游戏元素如观察室。
{{portal2}} 在制作《传送门2》地图时使用实例（Instances）能大幅提升效率——从谜题原型设计到最终发布，整个过程如虎添翼！官方创作工具提供的标准实例几乎涵盖地图制作所有元素：从基础物件如地板按钮，到复杂机关如方块生成器，甚至非游戏元素如观察室。


Line 8: Line 8:
== 何时该用实例？ ==
== 何时该用实例？ ==


实例的核心优势在于：**一次修改，全局生效**。若调整了按钮或门的造型逻辑，无需逐个修改地图中的副本（告别手动复制粘贴！）。尤其适合以下场景：
实例的核心优势在于：'''一次修改，全局生效'''。若调整了按钮或门的造型逻辑，无需逐个修改地图中的副本（告别手动复制粘贴！）。尤其适合以下场景：
* 重复的游戏机关（按钮/门/传送装置）
* 重复的游戏机关（按钮/门/传送装置）
* 复杂几何结构
* 复杂几何结构
Line 16: Line 16:
== 从零创建实例 ==
== 从零创建实例 ==


**原点规则**：地图原点(0,0,0)将作为实例的基准点。例如将按钮底部置于原点，可确保实例放置时与地板完美贴合。
*原点规则：地图原点(0,0,0)将作为实例的基准点。例如将按钮底部置于原点，可确保实例放置时与地板完美贴合。


### 参数化设计
通过{{L|func_instance_parms}}实体实现动态配置：
1. 在实例中声明带`$`前缀的变量（如`$box_type`）
2. 关联到实例内实体的对应属性（如方块的"Cube Type"值）
3. 主地图通过func_instance的"Replace"字段实时修改参数


### I/O交互桥梁
若需与主地图交互，添加命名为`proxy`的{{L|func_instance_io_proxy}}实体：
1. 为每个需接收的输入创建对应输出："OnProxyRelay"
2. 主地图通过"instance:<实体>;<指令>"格式通信


> **命名技巧**：实例内需直连的实体建议以"@"开头命名（如"@elevator_core"），主地图可直接对其发送指令——Valve电梯系统大量采用此方案。
*'''参数化设计'''<br>
通过{{L|func_instance_parms}}实体实现动态配置：
1. 在实例中声明带`$`前缀的变量（如`$box_type`）
2. 关联到实例内实体的对应属性（如方块的"Cube Type"值）
3. 主地图通过func_instance的"Replace"字段实时修改参数
 
*'''I/O交互桥梁'''<br>
若需与主地图交互，添加命名为"proxy"的{{L|func_instance_io_proxy}}实体：
1. 为每个需接收的输入创建对应输出："OnProxyRelay"
2. 主地图通过"instance:<实体>;<指令>"格式通信
 
> 命名技巧：实例内需直连的实体建议以"@"开头命名（如"@elevator_core"），主地图可直接对其发送指令——Valve电梯系统大量采用此方案。


=== func_instance_parms与实体命名的关键细节 ===
=== func_instance_parms与实体命名的关键细节 ===


当实例实体名称被参数化时，主地图的I/O必须指向**最终合并名称**（VBSP编译时自动生成）。命名规则如下（假设采用"前缀模式"）：
当实例实体名称被参数化时，主地图的I/O必须指向''最终合并名称''（VBSP编译时自动生成）。命名规则如下（假设采用"前缀模式"）：
> (func_instance的Fix Up Name值)-(实例实体原名)
> (func_instance的Fix Up Name值)-(实例实体原名)


例如：若实例内实体名为`button_trigger`，主地图func_instance的Fix Up Name设为"Lobby"，则主地图中该实体名为"Lobby-button_trigger"。
例如：若实例内实体名为"button_trigger"，主地图func_instance的Fix Up Name设为"Lobby"，则主地图中该实体名为"Lobby-button_trigger"。


== 技术深潜 ==
== 技术深潜 ==
{{Note|Hammer编辑器需保存地图后实例才会显示}}
{{Note|Hammer编辑器需保存地图后实例才会显示}}


### 核心特性
'''核心特性'''
* **解包实例**不受贴图锁定影响
* 解包实例不受贴图锁定影响
* 使用{{code|func_instance_origin}}的实例选择框可能显示异常
* 使用{{code|func_instance_origin}}的实例选择框可能显示异常
* {{code|replace}}参数顺序无关
* {{code|replace}}参数顺序无关
Line 48: Line 50:
* 嵌套实例需"代理桥接"才能在I/O自动补全中显示
* 嵌套实例需"代理桥接"才能在I/O自动补全中显示


### 组件解析
'''组件解析'''
**func_instance_parms** 
*func_instance_parms
通过{{code|parm<num>}}模式添加额外参数（对应{{code|replace<num>}}字段），无描述文本但顺序自由
    通过<code>parm<num></code>模式添加额外参数（对应<code>replace<num></code>字段），无描述文本但顺序自由


**func_instance_io_proxy**  
*func_instance_io_proxy   
编译/反编译可能将{{code|OnProxyRelay}}输出添加数字后缀（如OnProxyRelay1）
    编译/反编译可能将{{L|OnProxyRelay}}输出添加数字后缀（如OnProxyRelay1）


### 设计哲学
'''设计哲学'''
实例本质是**封装预制件**（类似Unity的Prefab/虚幻引擎的Package），具有三大优势：
<br>实例本质是封装预制件（类似Unity的Prefab/虚幻引擎的Package），具有三大优势：
1. **统一管理**：修改实例源文件，所有引用自动更新
*统一管理：修改实例源文件，所有引用自动更新
2. **模块化开发**：如装饰物集只需创建一次，全图复用
*模块化开发：如装饰物集只需创建一次，全图复用
3. **跨工程协作**：预设库共享（通过实例化→解包流程）
*跨工程协作：预设库共享（通过实例化→解包流程）


> **性能提示**：复杂实例编辑时频繁点击"Edit Instance"前务必保存地图！
> 性能提示：复杂实例编辑时频繁点击"Edit Instance"前务必保存地图！


=== 解包妙用 ===
=== 解包妙用 ===

Latest revision as of 05:19, 26 June 2025

English (en)中文 (zh)Translate (Translate)

传送门2 在制作《传送门2》地图时使用实例（Instances）能大幅提升效率——从谜题原型设计到最终发布，整个过程如虎添翼！官方创作工具提供的标准实例几乎涵盖地图制作所有元素：从基础物件如地板按钮，到复杂机关如方块生成器，甚至非游戏元素如观察室。

实例是什么？

实例是地图构建时引用的VMF文件，编译时会与主地图合并。一个实例VMF可以简单到仅含单个刷子，也可复杂到包含完整谜题机关及其逻辑实体与输入/输出触发器。

何时该用实例？

实例的核心优势在于：一次修改，全局生效。若调整了按钮或门的造型逻辑，无需逐个修改地图中的副本（告别手动复制粘贴！）。尤其适合以下场景：

  • 重复的游戏机关（按钮/门/传送装置）
  • 复杂几何结构
  • 精密的实体或I/O系统（如地图过渡）
  • 高频复用的物件组合

从零创建实例

  • 原点规则：地图原点(0,0,0)将作为实例的基准点。例如将按钮底部置于原点，可确保实例放置时与地板完美贴合。


  • 参数化设计
通过func_instance_parms(en)实体实现动态配置：
1. 在实例中声明带`$`前缀的变量（如`$box_type`）
2. 关联到实例内实体的对应属性（如方块的"Cube Type"值）
3. 主地图通过func_instance的"Replace"字段实时修改参数
  • I/O交互桥梁
若需与主地图交互，添加命名为"proxy"的func_instance_io_proxy(en)实体：
1. 为每个需接收的输入创建对应输出："OnProxyRelay"
2. 主地图通过"instance:<实体>;<指令>"格式通信

> 命名技巧：实例内需直连的实体建议以"@"开头命名（如"@elevator_core"），主地图可直接对其发送指令——Valve电梯系统大量采用此方案。

func_instance_parms与实体命名的关键细节

当实例实体名称被参数化时，主地图的I/O必须指向最终合并名称（VBSP编译时自动生成）。命名规则如下（假设采用"前缀模式"）： > (func_instance的Fix Up Name值)-(实例实体原名)

例如：若实例内实体名为"button_trigger"，主地图func_instance的Fix Up Name设为"Lobby"，则主地图中该实体名为"Lobby-button_trigger"。

技术深潜

Note.png注意:Hammer编辑器需保存地图后实例才会显示

核心特性

  • 解包实例不受贴图锁定影响
  • 使用func_instance_origin的实例选择框可能显示异常
  • replace参数顺序无关
  • 添加$varname会自动创建参数槽
  • 嵌套实例需"代理桥接"才能在I/O自动补全中显示

组件解析

  • func_instance_parms
   通过parm<num>模式添加额外参数（对应replace<num>字段），无描述文本但顺序自由
  • func_instance_io_proxy
   编译/反编译可能将OnProxyRelay(en)输出添加数字后缀（如OnProxyRelay1）

设计哲学
实例本质是封装预制件（类似Unity的Prefab/虚幻引擎的Package），具有三大优势：

  • 统一管理：修改实例源文件，所有引用自动更新
  • 模块化开发：如装饰物集只需创建一次，全图复用
  • 跨工程协作：预设库共享（通过实例化→解包流程）

> 性能提示：复杂实例编辑时频繁点击"Edit Instance"前务必保存地图！

解包妙用

通过顶部菜单"Instancing→Collapse Instance"可解包实例：

  • 将预设转化为普通实体（脱离实例关联）
  • 适用场景：导入基础结构→解包→自定义贴图
  • 避免污染原始实例库

扩展阅读

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Zh/Working_with_instances&oldid=483552"