42 Seoul - 006_so_long

🎮 so_long : 데이터의 시각화와 상호작용(Interaction)의 시작

42서울에 들어오면, 가장 흥이 나는, 의욕이 나는 과제가 무엇인가? 라고 한다면 바로 이 과제가 꽤나 상위권의 과제가 아닐까 싶다.

알고리즘의 추상적인 세계에 머물렀던 이전 과제들과 달리, so_long은 우리의 코드가 만들어낸 결과물을 처음으로 시각적이고 동적인 ‘세계’로 구현해내는 과제다.

이 프로젝트의 본질은 단순한 2D 게임 제작을 넘어, 메모리상의 정적인 2차원 배열 데이터가 어떻게 사용자와 상호작용하는 그래픽 인터페이스로 변환되는지를 이해하는 데 있으며, 이를 직접 눈으로 본다는 뿌듯함은, 게임의 개발의 로망을 가진 남자들이라면 상당한 설렘, 그리고 동시에 42서울의 원시 그래픽 라이브러리를 써본다는 점에서 꽤나 지옥을 맛보는(…) 과정이였다.

이는 상태(State), 입력(Input), 그리고 렌더링(Rendering) 이라는 GUI 애플리케이션의 세 가지 핵심 요소를 처음으로 다루는 경험이다. 삭막한 터미널을 벗어나, 프로그램의 내부 상태가 스크린 위의 픽셀로 실시간 투영되는 것을 보며, 우리는 비로소 ‘계산’을 넘어 ‘상호작용’의 영역으로 첫발을 내딛는 과제라 할 수 있겠다.

🎨 MiniLibX: 복잡성을 감추는 추상화 계층

so_long의 기술적 중심에는 MiniLibX가 있다. 이 라이브러리는 운영체제마다 다른 복잡한 그래픽 시스템(Linux의 X11, macOS의 AppKit 등)을 단순한 API로 감싸놓은 42라는 부트캠프가 자체적으로 갖고 있는, 추상화 계층(Abstraction Layer)이다. 이를 통해 우리는 로우레벨의 윈도우 시스템을 직접 다루는 대신, 게임 로직 자체에 집중할 수 있다.

지금 생각해보면 그래픽스와 관련한 로우한 개념, 코드를 만약 만졌다면 수개월 공부로도 쉽지 않았겠지만, 그걸 뛰어넘게 만들어줬다는 점에선 아주 훌륭한 선택이었다고 본다. (물론 유지보수가 안되어, 진짜 버그가 너무 많았다)

핵심은 이벤트 기반 아키텍처(Event-Driven Architecture)를 이해하는 것.

• mlx_loop: 이 함수는 프로그램의 제어권을 가져가 무한 루프를 돈다. 이는 명령을 순차적으로 실행하고 종료되던 기존의 프로그램과 다르다. 프로그램은 이제 사용자의 키보드 입력, 마우스 클릭, 창 닫기 버튼 등 외부에서 발생하는 비동기적 이벤트(Asynchronous Events)를 수신 대기하는 ‘반응형 시스템’이 되어 바쁜 루프(busy loop)를 돌게 된다.
• mlx_key_hook, mlx_hook: 특정 이벤트가 발생했을 때 호출될 함수(콜백 함수 또는 핸들러)를 미리 등록하는 행위. 이를 통해 “W 키가 눌리면 move_player_up 함수를 실행하라” 와 같은 이벤트와 로직의 연결고리를 만들게 된다. 이러한 이벤트들이 들어올 때, 그 종합적인 상태들을 모아서, 맵과 캐릭터, 이미지의 상호작용을 만드는 것, 그것이 이 과제의 핵심 개념이었다.

🗺️ .ber 파일: 세계의 설계도를 해석하다

.ber 텍스트 파일은 기본적으로 42 과제에서 정한, 일종의 약속이었다. 게임 월드의 초기 상태를 정의하는 ‘설계도’이다. 이 설계도를 해석하여 인게임 데이터 구조로 변환하는 과정은 다음과 같은 단계로 이루어진다.

1. 파싱 (Parsing) 및 역직렬화 (Deserialization): get_next_line을 활용해 텍스트 파일을 읽고, 이를 char ** 와 같은 인-메모리 2차원 배열로 변환한다. 이는 파일에 직렬화되어 저장된 데이터를 프로그램이 이해할 수 있는 구조로 바꾸는 과정이다.
2. 맵 유효성 검사 (Validation): 파싱된 맵이 게임의 근본적인 불변 규칙(Invariants)을 만족하는지 검증한다.
   • 구조적 규칙: 직사각형 형태, 벽(1)으로의 완전한 둘러싸임.
   • 구성 요소 규칙: 플레이어(P) 1개, 출구(E)와 수집품(C) 각각 1개 이상의 존재.
   • 경로 유효성 규칙 (심화): 단순히 구성 요소의 개수를 세는 것을 넘어, 플레이어가 모든 수집품을 거쳐 출구에 도달할 수 있는 유효한 경로가 존재하는지를 검증해야 한다. 이는 일반적으로 DFS(깊이 우선 탐색)나 BFS(너비 우선 탐색) 같은 그래프 순회 알고리즘을 사용하여 맵 데이터 자체를 하나의 그래프로 보고, 시작점에서 목표 지점까지의 도달 가능성(Reachability)을 판별하는 방식으로 구현된다. 이 검증이 누락되면 플레이어가 절대로 클리어할 수 없는 맵을 허용하게 된다.

🏃‍♂️ 게임 루프: 입력, 상태 업데이트, 렌더링의 순환

게임의 실질적인 동작은 보이지 않는 게임 루프(Game Loop) 안에서 일어난다. so_long에서는 이벤트가 발생할 때마다 이 루프의 한 사이클이 동작한다고 볼 수 있다.

1. 입력 (Input): mlx_key_hook이 키 입력을 감지한다.
2. 상태 업데이트 (State Update): 입력에 따라 게임의 핵심 데이터, 즉 상태를 변경한다.
   • 플레이어의 다음 좌표를 계산하고, 벽(1)과의 충돌을 검사한다.
   • 이동이 유효하다면, 플레이어의 좌표(game->player_x, game->player_y), 움직인 횟수(game->steps), 남은 수집품 개수(game->collectibles) 등의 상태 변수를 갱신한다.
   • 게임의 모든 규칙과 로직은 오직 이 ‘상태’를 변경하는 단계에서만 처리되어야 한다.
3. 렌더링 (Rendering): 변경된 최신 ‘상태’를 기반으로 화면 전체를 다시 그린다. 렌더링 함수는 현재 플레이어가 어디에 있는지, 수집품이 어디에 남았는지 등의 게임 로직을 알 필요가 없다. 오직 전달된 상태 데이터를 시각적으로 표현할 책임만 가진다.
   • 애니메이션 (심화): 단순한 키 입력 기반 렌더링을 넘어, mlx_loop_hook을 사용하면 아무런 입력이 없어도 매 프레임마다 특정 함수를 호출할 수 있다. 이를 활용해 프레임 카운터를 두고, 특정 프레임마다 플레이어나 수집품의 이미지를 다른 이미지로 교체해주면 간단한 스프라이트 애니메이션을 구현하여 게임에 생동감을 불어넣을 수 있다.

✨ 성찰 및 배운 점

so_long은 C언어로 정적인 데이터를 동적인 상호작용의 세계로 이끌어내는 값진 경험이자, 이벤트 기반 루프라는 것이 어떤 식으로 애니메이션을 만들어내는 지를 배울 수 있었다. 특히 구조체를 본격적으로 쓴다는 점에서, 객체 지향적 구조의 일부를 맛본다는 차원에서 아주 흥미로운 과제였다고 생각한다.

• 상태와 뷰의 분리: 게임의 모든 데이터를 담고 있는 ‘상태(State)’와, 그 상태를 화면에 그리는 ‘뷰(View/Rendering)’의 역할을 분리하는 것이 왜 중요한지 체감했다. 이 원칙은 이후 MVC, MVVM 등 모든 현대적인 UI 프레임워크의 근간이 되는 것이었고, 배울 당시는 몰랐지만, 이후 많은 작업들 속에서 그 원리의 구조를, 본질적인 의미와 특징을 나름 이해하게 된 경험이었다.
• 이벤트 기반 패러다임의 이해: 프로그램의 흐름이 위에서 아래로 흐르는 것이 아니라, 외부 이벤트에 의해 비동기적으로 촉발되는 이벤트 기반 프로그래밍 패러다임에 대한 깊은 이해를 얻었다. 결국 어떤 루프 안에서, 어떤 것들을 어떤 순서의 이벤트로 나타내고, 특히 최종적인 렌더링은 맨 마지막에서 이루어지는 구조가 된다는 의미는 상당히 복잡하고, 또 디버깅 과정에서 경험한 쉽지 않은 일이었다고 생각이 든다.
• 알고리즘의 시각적 응용: DFS/BFS 같은 자료구조/알고리즘이 단지 이론에 머무는 것이 아니라, ‘플레이 가능한 맵’을 검증하는 등 실제 게임 개발에서 어떻게 실용적으로 사용되는지 직접 확인할 수 있었다.

내 코드가 만들어낸 작은 캐릭터가 맵을 돌아다니고, 아이템을 수집하며, 마침내 출구에 도달하는 일련의 과정을 지켜보는 것은 단순한 결과 확인을 넘어선 창작의 기쁨이었다. so_long은 나에게 코드가 어떻게 생명력을 얻어 사용자와 소통하는 ‘세계’가 될 수 있는지를 가르쳐준 프로젝트로 기억되며 지금까지 꽤나 기분 좋은 경험이었다고 생각이 든다.