"Visual Workflow" 태그의 게시물 3개 게시물건

플레이어가 죽습니다. 사망 사운드가 재생됩니다. 래그돌이 활성화됩니다. "You Died" UI 팝업이 나타납니다. 게임이 자동 저장됩니다. 분석 이벤트가 발생합니다. 리스폰 타이머가 카운트다운을 시작합니다. 하나의 이벤트 OnPlayerDeath에 여섯 개의 다른 시스템이 응답합니다. 하지만 질문 하나 — 이게 어디에 문서화되어 있나요?

코드에 없습니다. 프로젝트 관리 도구에도 없습니다. 어떤 다이어그램에도 없습니다. 딱 한 곳에 존재합니다: 원래 설정한 사람의 머릿속. 그 사람이 6개월 전에 팀을 떠났다면, 아무 데도 존재하지 않습니다.

이것이 이벤트 기반 아키텍처의 더러운 비밀입니다. 시스템을 디커플링하기 위해 채택합니다. AudioManager가 UIManager에 대한 참조가 필요 없다는 걸 축하합니다. 하지만 비용에 대해서는 절대 이야기하지 않습니다: 실행 흐름이 보이지 않게 됩니다. 그리고 보이지 않는 것은, 정의상, 시각적으로 디버깅할 수 없습니다.

모든 게임은 기본적으로 거대한 조건의 더미입니다. "적이 면역이 아니고 AND 플레이어에게 화염 버프가 있고 AND 랜덤 크리티컬 체크를 통과할 때만 화염 데미지를 준다." 프로토타이핑할 때는 콜백에 if문 하나 넣고 넘어갑니다. 30초. 동작함. 생산적인 느낌.

그러다 프로토타입이 프로덕션에 들어갑니다. 30초짜리 if문들이 번식하기 시작합니다. 하나가 다섯이 되고, 다섯이 오십이 되고, 오십이 "두 번째 보스의 루트 드롭률을 제어하는 조건이 대체 어디있지?"가 됩니다. 그리고 디자이너가 뒤에 서서 데미지 임계값을 0.3에서 0.25로 바꿀 수 있냐고 물어보고 있고, 당신은 리컴파일이 필요하다고 설명하고 있습니다.

if-else 지옥에 오신 것을 환영합니다. 인구: 3개월 넘게 유지된 모든 Unity 프로젝트.

화요일 오후 3시. 디자이너가 다가와서 말합니다. "저기, 플레이어가 50 이상 데미지를 받을 때 화면 흔들림을 좀 더 강하게 할 수 있어요? 그리고 히트 사운드 전에 0.5초 딜레이 넣어주세요. 아, 독 효과 틱도 2초 대신 1.5초로 바꿔주세요."

세 가지 변경. 디자이너 입장에서는 15초면 결정할 수 있는 내용입니다. 하지만 실제로 벌어지는 일은 이렇습니다: Scene 뷰를 닫고, IDE를 열고, 로딩을 기다리고, 데미지 핸들러를 찾고, 메서드 안에 묻혀있는 화면 흔들림 강도 값을 찾아 변경합니다. 그다음 오디오 딜레이를 찾는데 — 그건 다른 클래스에 있습니다. 변경합니다. 그리고 독 코루틴을 찾는데 — 또 다른 클래스에 있고, 틱 간격은 WaitForSeconds 호출 안에 있습니다. 변경합니다. 세 파일 모두 저장하고, Unity로 돌아가서 리컴파일을 기다리고, 테스트합니다.

8분 후, 디자이너가 말합니다. "아, 흔들림은 원래가 나았어요. 그리고 독은 1.8초로 해볼 수 있을까요?"