합쳐진 건물이 커졌다는 걸 어떻게 보여줄까

건물 진화가 일어난 위치를 보여 주기

건물이 합쳐져 높은 단계가 되어도 변화가 조용히 지나가면 무엇이 달라졌는지 놓치기 쉽습니다. 성장하는 도시에서는 진화한 건물에 도약과 확대, 착지 링을 더하고 발전도 숫자도 함께 움직이도록 했습니다.

진화 연출은 1.1초 동안 진행하며 최대 크기는 원래의 116%입니다. 착지 반동이 끝나면 원래 크기로 돌아옵니다. 일반 건물 생성과 다른 표현을 사용해 새로 생긴 건물과 조합으로 진화한 건물을 구분했습니다.

숫자가 연속으로 바뀌는 경우도 다뤘습니다

발전도는 0.65초 동안 현재 값으로 차오르고, 증가량은 1.3초 동안 위로 떠오릅니다. 연출 중 새 증가가 들어오면 최신 값으로 이어가며, 감소할 때에는 이전 증가 표시를 해제합니다. 변화가 겹칠 때 오래된 숫자가 남지 않도록 한 처리입니다.

Text의 폰트와 색, 크기, 위치는 씬에 저장했습니다. 코드는 동적 숫자와 일시적인 연출을 갱신하며 기존 UI 위치는 유지합니다.

사용자가 제공한 수정 전 화면입니다. 표시된 Batches 1,545와 삼각형 2.0M은 변경 전 값이며, 개선 후 측정값이 아닙니다.

도로 묶음은 연출과 별도 작업입니다

렌더링 부담을 줄이기 위해 원본 도로의 사본을 프로젝트 소유 폴더에 두고, 배치가 바뀔 때 도로 메시를 재질별로 묶도록 했습니다. 애니메이션 건물과 파괴 충돌체는 제외했습니다. 읽을 수 없거나 지원하지 않는 메시 구성은 기존 렌더러를 유지합니다.

이 작업은 드로우 콜을 줄이려는 변경이며, 삼각형 수를 줄이는 LOD를 적용한 것은 아닙니다. 이전 합성 메시를 정리하는 처리도 포함했습니다.

구현 검증과 성능 측정을 구분했습니다

독립 시나리오 51개와 타임라인 샘플 1,101개에서 도약의 시작·끝 높이, 중간 확대, 최종 크기 복원 등을 검사했습니다. Unity 참조 컴파일과 씬 연결 검사, 외부 원본 파일 해시 대조도 통과했습니다.

다만 실제 Play에서 연출을 보고, 도로 합성 전후의 Batches·FPS·메모리를 비교하지는 않았습니다. 합성 자체에 드는 CPU 비용도 측정해야 합니다. 화면 효과를 구현한 결과와 성능 개선을 입증한 결과는 분리해서 남깁니다.

시간에 따른 높이와 크기를 분리하기

편집 시 확인한 공개 소스의 GrowthFeedback.EvolutionLift는 정규화한 시간에서 도약 높이의 비율을 구합니다. 아래 발췌는 현재 공개 커밋의 코드이며 줄바꿈만 정리했습니다.

public static float EvolutionLift(float t) =>
    t <= 0 || t >= .7f
        ? 0
        : (float)Math.Sin(t / .7f * Math.PI);

이 함수만 보면 시작과 0.7 이후에는 높이 비율이 0이고, 그 사이에는 사인 곡선으로 올라갔다 내려옵니다. 실제 거리나 전체 연출 시간은 호출하는 쪽에서 연결하는 값이므로, 이 반환값을 Unity 단위 높이나 초로 바로 읽으면 안 됩니다.

높이와 크기를 나눠 계산하면 건물이 땅 아래로 내려가거나 마지막에 확대된 채 남는 문제를 따로 검사할 수 있습니다. 보고서에서 시작·끝의 높이와 최종 크기 복원, 중간 시간의 양수 크기를 확인한 이유도 여기에 있습니다. 수학적 경계 조건이 통과한 다음에는 실제 카메라에서 도약과 착지가 과하지 않은지를 눈으로 확인해야 합니다.

작업 근거

• 개발 기록 원문

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