程序化生成建筑时最让人头疼的问题不是生成不出来，而是生成出来的东西不像建筑：窗户悬在半空、楼梯通向墙壁、悬挑部分没有任何支撑。这些问题说明算法只做到了形状的随机组合，没有继承建筑应有的内在逻辑。要解决这类问题，核心思路是把建筑的结构规律、功能关系和空间规范提取成参数与规则，让生成过程在约束框架内进行，而不是任由随机数摆布。
为什么程序化生成的建筑总是不合理
先分析问题的根源。绝大多数建筑生成算法的本质是对几何体的随机拼接或变形，比如随机堆叠盒子、随机切割体块、随机布置门窗贴图。这类方法在视觉层面可以做出丰富变化，但它对建筑本身一无所知。真实建筑是高度约束的产物：柱网决定开间，开间决定窗户位置，楼层高度决定楼梯踏步数量，功能分区决定走廊走向。这些约束如果不在算法中显式表达，随机过程必然产出违反常识的结果。
举个典型例子，很多开发者生成高层建筑时会随机决定每层的窗户数量和位置，结果某层的窗户恰好压在下一层的结构柱上，或者相邻两层的窗户完全错位，看起来像地震后的残骸。真实建筑中立面窗户几乎总是上下对齐的，因为它们受到内部柱网和承重墙的约束。这类问题不是调参能解决的，必须改变生成模型本身。
常见的不合理可以归为几类：结构不合理，如悬挑过大、支撑缺失、构件穿模；功能不合理，如房间没有门、走廊是死路、卫生间出现在客厅中央；尺度不合理，如门只有半人高、楼梯坡度接近垂直。分类的意义在于，每一类问题都对应不同的规则注入手段，后面会分别讨论。
参数化建模：用参数约束体量与比例
参数化建模的思路是把建筑描述为一组参数及其关系，而不是一堆自由几何体。比如一栋办公楼可以由以下参数描述：开间宽度、进深、层高、层数、核心筒尺寸、窗墙比。参数之间建立依赖关系后，随机变化只能在合法范围内发生，生成结果自然不会离谱。
一个简单的参数结构可以这样定义：
class BuildingParams:
def __init__(self):
self.bay_width = 4.5 # 开间宽度，米
self.depth = 8.0 # 进深，米
self.floor_height = 3.6 # 层高，米
self.floors = 12 # 层数
self.core_size = 6.0 # 核心筒边长，米
def validate(self):
# 结构合理性检查：高宽比不宜过大
total_h = self.floors * self.floor_height
total_w = self.bay_width * 6
if total_h / total_w > 6:
return False
# 核心筒必须能放进进深范围内
if self.core_size >= self.depth - 1.0:
return False
return True参数化建模的关键在于建立参数之间的推导链，而不是让所有参数独立随机。层高决定了楼梯的踏步数量，开间宽度决定了每间布置几扇窗，窗洞高度受层高减去结构梁高的限制。通过这种派生关系，一个参数变化会自动带动相关参数调整，几何永远不会自相矛盾。
另一个重要技巧是引入合法取值域。参数不应该是任意的连续随机数，而应该从真实建筑常用值中采样。层高在住宅中通常是2.8到3.2米，办公楼是3.6到4.2米，厂房则高得多。把采样空间限制在这些区间内，即使不做任何额外检查，生成结果也已经接近真实。取值域可以做成可配置的表，方便生成不同风格和用途的建筑。
规则注入：把建筑逻辑变成可执行的约束
参数化解决了体量层面的问题，但房间内部布局、门窗开口、构件连接这些细节还需要更细粒度的规则。规则注入的做法是维护一套规则库，生成过程每做一步决策都要查询规则库是否允许，或者由规则直接驱动下一步生成。
规则通常分三类。第一类是硬约束，违反即无效，比如所有房间必须可达、门窗不能与承重柱重叠、楼梯必须连续到顶。第二类是软约束，影响评分但不一票否决，比如走廊长度不宜超过规范上限、南向房间最好多开窗。第三类是风格规则，控制外观特征，比如某地区民居偏好的屋顶坡度范围、立面材质的分段逻辑。
实现上可以用生成后验证加回溯的方式：先随机生成一个布局方案，跑一遍规则检查，不通过就回退到上一个合法状态重新分支。对于房间布局这类组合问题，也可以直接用规则驱动的生长算法，从入口开始，每个房间按照相邻关系规则向外扩展：
def generate_floor_layout(rules, entrance):
layout = Layout()
queue = [entrance]
while queue:
room = queue.pop(0)
layout.place(room)
# 根据规则决定哪些房间可以与当前房间相邻
neighbors = rules.allowed_adjacency(room.type)
for ntype in neighbors:
pos = layout.find_valid_slot(room, ntype)
if pos is None:
continue
new_room = Room(ntype, pos)
# 硬约束检查：不重叠、必须留出交通空间
if layout.check_overlap(new_room):
continue
if not rules.check_corridor_access(layout, new_room):
continue
queue.append(new_room)
return layout门窗和构件的规则同样重要。生成窗户时不应在墙面上随意开洞，而是先根据结构体系划分柱网，柱间形成开间，窗户在开间内居中布置并上下层对齐。楼梯的规则更严格，一段楼梯的踏步数由层高除以踢面高度得出并取整，梯段长度由此确定，平台上方的净空高度必须满足两倍层高差的要求。这些计算写进规则库后，生成的楼梯永远是可以实际行走的。
规则的来源可以是建筑设计规范、真实户型的统计分析，或者根据游戏需求自行设定。建议把规则数据与算法分离，用配置文件存储规则，这样调整生成风格时不需要改代码，也便于团队成员共同维护。
从可行性检查到分层生成架构
当建筑复杂度上升，单一的生成函数会变得难以维护，推荐采用分层生成架构。底层是结构层，生成柱网、承重墙、楼板和核心筒，这一层约束最严格；中间是功能层，在结构框架内划分房间和交通空间；最外层是表现层，布置门窗、装饰、材质和细节。上层生成完全依赖下层提供的数据，比如功能层布置房间时必须避开结构层的柱位。
分层的好处是每一层的规则简单清晰，问题容易定位。如果生成结果出现窗户穿柱，那一定是表现层没有读取结构层数据，检查这一层的数据传递即可，不需要在所有代码里翻找。同时分层也让多样化变得容易：保持结构层不变，只替换表现层的风格规则，就能用同一套骨架生成完全不同外观的建筑群。
最后一点实践建议是建立自动化的合理性评估。把硬约束写成验证脚本，批量生成几百栋建筑后自动检查违规率，用这个指标驱动算法迭代。这比肉眼逐个检查高效得多，也能在调整随机参数时量化对比不同方案的质量。参数化建模提供合法的变化空间，规则注入守住合理性的底线，两者结合之后，程序化生成的建筑才能既丰富多样，又经得起细看。