게임아카데미게임·웹툰·AI 진로 상담
게임 회사 프로그래머 채용에서는 코딩 테스트와 함께 직접 만든 프로젝트를 봅니다. 수업 중에 자료구조와 알고리즘 문제를 꾸준히 풀고, 동시에 캐릭터 조작, 물…
직접 부르는 대신 방송하는 방식
학교 방송을 생각해 보면 쉽습니다. 교무실에서 '3학년은 강당으로 모이세요'라고 방송하면, 3학년 학생들만 움직이고 다른 학년은 하던 일을 계속합니다. 방송하는 선생님은 3학년 교실을 하나하나 찾아다닐 필요가 없습니다. 누가 들을지는 듣는 쪽이 정합니다.
이벤트 시스템이 없으면 코드가 서로를 직접 부릅니다. 플레이어가 맞는 순간, 플레이어 코드가 체력바 코드를 찾아 갱신하고, 사운드 코드를 찾아 효과음을 내고, 카메라 코드를 찾아 흔들라고 시킵니다. 플레이어 코드가 다른 모든 시스템을 알고 있어야 하는 구조입니다.
이벤트 방식에서는 플레이어 코드가 '맞았다'는 이벤트만 발생시킵니다. 체력바, 사운드, 카메라는 미리 이 이벤트를 구독(subscribe)해 두었다가 신호가 오면 각자 반응합니다. 이런 구조를 관찰자(옵저버) 패턴이라고도 부릅니다.
코드끼리 얽히지 않으면 생기는 장점
서로 직접 부르는 코드는 한 곳을 고치면 다른 곳이 깨지기 쉽습니다. 이런 상태를 결합도가 높다고 표현합니다. 이벤트 시스템은 이 결합을 느슨하게 만듭니다.
- 기능 추가가 쉬움: 업적 시스템을 새로 넣을 때 플레이어 코드는 그대로 두고, 업적 코드가 '적 처치' 이벤트를 듣게 하면 됩니다.
- 기능 제거가 안전함: 진동 기능을 빼도 이벤트를 보내는 쪽은 아무 영향이 없습니다.
- 역할 분담이 편함: UI 담당과 전투 담당이 이벤트 이름과 전달할 값만 약속하면 각자 작업할 수 있습니다.
- 테스트가 쉬움: 이벤트를 가짜로 발생시켜 체력바가 제대로 반응하는지만 따로 확인할 수 있습니다.
팀 프로젝트에서 이 장점이 특히 큽니다. 여러 사람이 한 코드를 동시에 고치면 충돌이 자주 나는데, 이벤트로 연결된 시스템은 각자 자기 파일만 수정하면 되는 경우가 많습니다.
게임에서 이벤트로 연결하기 좋은 순간
모든 것을 이벤트로 만들 필요는 없습니다. 이벤트가 잘 어울리는 것은 '가끔 일어나고, 여러 시스템이 함께 반응해야 하는 일'입니다.
| 이벤트 예시 | 반응하는 시스템 |
|---|---|
| 체력 변화 | 체력바, 화면 붉은 테두리, 위험 경고음 |
| 적 처치 | 점수, 퀘스트 진행도, 업적, 드롭 아이템 |
| 아이템 획득 | 인벤토리, 획득 알림, 효과음 |
| 스테이지 클리어 | 결과 화면, 저장, 다음 스테이지 잠금 해제 |
| 설정 변경 | 사운드 볼륨, 화면 밝기, 자막 표시 |
반대로 매 프레임 계속 바뀌는 값, 예를 들어 캐릭터 위치를 이벤트로 매번 알리는 것은 비효율적입니다. 필요한 쪽이 직접 값을 읽는 편이 간단하고 빠릅니다.
이벤트에 함께 담아 보낼 값도 미리 정해 두면 좋습니다. '적 처치' 이벤트라면 어떤 적인지, 누가 잡았는지, 어디서 잡았는지를 같이 보내야 퀘스트와 드롭 시스템이 각자 필요한 정보를 꺼내 쓸 수 있습니다. 나중에 값을 추가하면 모든 구독자를 고쳐야 하므로, 처음 설계할 때 넉넉히 생각해 두는 것이 좋습니다.
Unity와 Unreal에서 이벤트를 만드는 방법
Unity에서는 C# 언어가 기본으로 제공하는 event와 Action으로 이벤트를 만들 수 있습니다. 인스펙터 창에서 반응할 함수를 연결할 수 있는 UnityEvent도 자주 씁니다. 버튼의 클릭 칸에 함수를 연결해 본 적이 있다면 UnityEvent를 이미 써 본 것입니다.
주의할 점은 Unity에 'EventSystem'이라는 이름의 오브젝트가 따로 있다는 것입니다. 이것은 UI 클릭과 터치 입력을 처리하는 장치로, 이 글에서 말하는 일반적인 이벤트 구조와는 다릅니다. 이름이 같아 처음 배우는 사람이 자주 헷갈립니다.
Unreal Engine에서는 델리게이트(delegate)라는 기능으로 이벤트를 만듭니다. 블루프린트에서는 이벤트 디스패처(Event Dispatcher)를 만들고, 다른 블루프린트에서 바인딩해 반응하게 합니다. 이름은 달라도 신호를 보내고 구독한다는 원리는 같습니다.
처음 이벤트를 쓸 때 자주 생기는 문제
가장 흔한 실수는 구독 해제를 잊는 것입니다. 오브젝트가 사라졌는데 이벤트 목록에는 여전히 등록되어 있으면, 신호가 올 때 없는 대상을 부르다가 오류가 나거나 메모리가 정리되지 않습니다. 구독을 시작할 때 해제할 시점도 함께 정해 두는 습관이 필요합니다. 오브젝트가 꺼지거나 파괴될 때 해제하는 방식이 흔히 쓰입니다.
두 번째는 이벤트가 너무 많아져 흐름을 추적할 수 없게 되는 것입니다. 버그가 생겼을 때 '이 함수는 누가 불렀지?'를 찾기 어려워집니다. 이벤트 이름을 일관되게 짓고, 어떤 이벤트가 어디서 발생하는지 목록으로 정리해 두면 도움이 됩니다.
세 번째는 반응 순서에 기대는 것입니다. 여러 구독자가 있을 때 누가 먼저 반응할지 보장되지 않는 경우가 많습니다. 저장이 끝난 뒤에 결과 화면이 떠야 한다면, 순서를 이벤트에 맡기지 말고 단계를 나눠 명확히 처리해야 합니다.
작은 기능 하나로 연습해 보기
코인을 먹으면 점수 텍스트가 오르고 효과음이 나는 기능을 두 가지 방식으로 만들어 보세요. 한 번은 코인 코드가 점수와 사운드를 직접 부르게, 한 번은 '코인 획득' 이벤트로 연결합니다. 그다음 업적 기능을 추가해 보면 어느 쪽이 손댈 곳이 적은지 바로 체감할 수 있습니다.
기능이 늘수록 코드가 엉켜 손대기 무섭다면, 구조를 배워야 할 시점입니다. Unity로 게임을 만들어 보며 C# 코드를 깔끔하게 나누는 습관까지 기르고 싶다면, SBS아카데미게임학원 유니티3D(Unity) 과정 상담에서 지금까지 만든 프로젝트를 보여 주고 다음 단계를 의논해 보세요.
자주 묻는 질문
이벤트 시스템을 쓰면 게임이 느려지나요?
가끔 일어나는 일에 쓰는 정도로는 성능 차이를 느끼기 어렵습니다. 다만 매 프레임 수많은 이벤트를 보내면 부담이 될 수 있어 쓰임새를 가려야 합니다.
싱글톤으로 다 연결하면 안 되나요?
작은 프로젝트에서는 간단해서 많이 씁니다. 하지만 모든 코드가 싱글톤에 직접 의존하면 결합도가 높아져, 규모가 커질수록 이벤트로 나누는 편이 관리하기 좋습니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.