건물을 촘촘히 놓으니 도로가 달라졌다

건물 간격과 도로를 함께 손봤습니다

성장하는 도시의 건물이 서로 멀리 떨어져 있어, 이어진 거리보다 모형을 따로 놓은 모습에 가까웠습니다. 건물 중심 간격을 20에서 16으로 줄이고, 건물마다 도로를 두르던 구성을 2×2 건물 블록의 공용 도로로 바꿨습니다.

사용자가 제공한 변경 전 화면입니다. 수정 후 도로와 화면 배치는 당시 직접 촬영하지 않았습니다.

도로 조각은 이웃 연결로 선택합니다

각 위치의 북·동·남·서 연결을 계산해 직선, 코너, T자, 십자, 끝길 에셋과 회전을 고릅니다. 건물을 새로 놓을 때뿐 아니라 파괴하거나 재건할 때도 기존 교차점을 다시 계산하도록 했습니다. 처음 배치만 맞고 도시가 바뀐 뒤에는 길이 끊어지는 일을 막기 위한 구조입니다.

방향 기준은 제공 에셋의 실제 차량 경로 끝점에서 확인했습니다. 겉모양만 보고 회전시키지 않고, 각 조각이 어느 방향으로 이어지는지를 기준으로 삼았습니다. 보행 경로와 차량 경로도 구분했습니다.

도시 바깥의 지면과 시점도 조정했습니다

지면에는 흙과 마른 풀의 차이, 그림자와 안개를 표현하는 프로젝트 소유 셰이더를 작성했습니다. 카메라는 하늘이 위쪽에 들어오는 27도 투시 시점으로 바꾸고, 도시 범위의 여덟 꼭짓점을 기준으로 거리를 조절했습니다.

버튼 글자가 보이지 않던 부분에는 기존 Text의 폰트 연결을 보완했습니다. 다만 변경 전 화면만으로 글자 누락의 정확한 원인을 확정하지는 않았습니다. 화면에서 관찰한 현상과 코드에서 수정한 항목을 구분해 기록했습니다.

연결 규칙은 검사했지만 화면 품질은 남았습니다

독립 시나리오 24개에서 도로 연결 조합, 이웃 성장에 따른 T자 전환, 음수 좌표의 블록 처리, 축소 후 코너 복구와 전멸 후 남은 도로 정리를 검사했습니다. Unity 참조 컴파일과 씬의 직렬화·참조 검사도 통과했습니다.

실제 Play와 수정 후 렌더는 당시 실행하지 않았습니다. 도로 접합부가 자연스러운지, 지면 셰이더와 하늘이 의도대로 보이는지, 버튼 글자가 읽히는지는 실행 화면으로 확인해야 합니다. 이번 결과는 배치 규칙과 씬 구성을 보완한 단계입니다.

네 방향을 하나의 연결 상태로 표현하기

공개 소스의 RoadTopology.Rotate는 북·동·남·서를 각각 1·2·4·8 비트로 표현합니다. 아래는 편집 시 확인한 현재 공개 커밋의 코드를 줄바꿈만 정리한 발췌입니다.

public static int Rotate(int mask, int turns)
{
    turns = ((turns % 4) + 4) % 4;
    return ((mask << turns) | (mask >> (4 - turns))) & 15;
}

회전 수를 0~3으로 정리하고 네 방향 비트를 순환시킵니다. 별도의 Resolve는 연결 수와 방향을 보고 도로 모양을 고른 뒤, 그 모양의 기본 방향을 몇 번 돌려야 하는지 비교합니다. 배치 규칙과 에셋의 기본 방향을 연결하는 작은 부분입니다.

이 방식은 새 도로 모양을 추가할 때도 기준을 명시하게 만듭니다. 직선이 남북을 향하는지, 코너가 북서로 연결되는지부터 실제 에셋과 맞춰야 합니다. 비트 계산이 맞더라도 에셋 방향을 잘못 가정하면 화면에서는 길이 어긋납니다. 그래서 논리 검사와 도로 접합부의 실제 화면 확인을 별도 항목으로 남겼습니다.

작업 근거

• 개발 기록 원문

• 편집 시 확인한 공개 C# 원문 · RoadTopology.cs