OpenTTD 16 베타5노선보다 먼저,
운영 습관
OpenTTD 16.0-beta5의 실제 변경점과 안정판을 지키는 시험 방법을 짚고, 역·신호·환승을 하나의 교통망으로 설계하는 순서를 안내한다.
01 | 10월 24일 배포본은 정식 16이 아니다
10월 24일 공개된 OpenTTD 16.0-beta5는 운송회사를 처음부터 다시 만들라는 업데이트가 아니다. 기존 회사를 계속 운영할 사람과 다음 버전을 시험할 사람의 목적을 나누어 생각하게 하는 배포본이다. 10월 26일 확인한 공식 다운로드 구분에서 안정판은 15.3, 시험판은 16.0-beta5였다. 공식 시험판 페이지가 기록한 공개 시각은 24일 22시 37분 UTC다. 한국 시간으로는 25일 오전에 해당하지만, 배포본의 공식 날짜 표기는 24일이다. 날짜와 버전부터 분리해야 다른 사람의 서버에 접속하거나 변경 기록을 찾아볼 때 불필요한 혼선을 줄일 수 있다.
이번 배포본의 눈에 띄는 변화는 산업·화물 연결 창의 재설계와 기본 헬리콥터 Guru X2의 이용 가능 기간 연장이다. 역 이름표를 옮겼을 때 발생하던 문제, 언어와 글꼴 변경 후 창 크기가 어긋나는 문제, macOS의 마우스 커서 숨김 처리도 손봤다. 이 목록을 ‘철도 시스템 전체가 새로워졌다’고 부풀릴 이유는 없다. 베타5의 가치가 드러나는 곳은 오히려 작은 운영 동작이다. 산업의 다음 목적지를 찾아보고, 화면의 한글이 잘리는지 확인하고, 다른 사람과 같은 지도를 볼 때 상태가 맞는지 점검하는 일이다.
그렇다고 수정을 사소한 외관 변화로만 볼 수도 없다. 수백 대가 오가는 회사에서 플레이어는 실제 열차보다 정보 창을 더 자주 살핀다. 화물 연결을 이해하는 데 걸리는 시간이 줄면 다음 노선을 결정하는 방식도 달라진다. 반대로 정보가 잘 보여도 잘못된 환승 명령이나 짧은 대기선은 그대로 남는다. 이번 글은 새 기능의 목록을 늘어놓는 대신, 베타5에서 무엇을 확인하고 기존 운송망에서 어떤 판단을 바꿀지 연결해 읽는다. 아래의 실행 순서는 편집팀의 점검 제안이며, 실제 게임을 실행해 얻은 성능 측정이나 수익 보증은 아니다.
02 | 회사의 원본과 시험용 회사를 먼저 갈라놓기
새 버전을 살펴보는 첫 작업은 차량 구입이 아니라 저장 파일의 원본 보존이다. 공식 README는 손상되지 않은 과거 버전의 저장 파일을 이후 버전에서 불러올 수 있도록 보장한다고 설명한다. 여기서 방향을 바꾸어 읽으면 안 된다. 새 버전에서 다시 저장한 회사를 옛 실행 파일로 되돌려도 된다는 보장은 아니다. ‘불러올 수 있다’와 ‘돌아갈 수 있다’는 다른 말이다. 원래 파일은 그대로 두고 이름이 분명한 사본을 만드는 이유가 여기에 있다.
예를 들어 안정판에서 키우던 회사를 ‘서해운송_운영원본’으로 보존하고, 시험에 사용할 사본을 ‘서해운송_16베타5_시험’처럼 구분할 수 있다. 이름은 예시일 뿐 정해진 형식은 아니다. 중요한 것은 파일을 열 때 어떤 목적의 회사인지 알아볼 수 있고, 나중에 저장 대화상자에서 원본을 실수로 덮어쓰지 않는 것이다. 자동 저장을 믿고 원본을 생략하는 방식은 권하지 않는다. 자동 저장은 최근 상태를 편리하게 남기는 장치이지 서로 다른 버전의 실험을 설명해 주는 기록장이 아니다.
설치 폴더를 둘로 나누었다고 모든 설정과 콘텐츠도 자동으로 분리되었다고 가정해서는 안 된다. 각 운영체제의 설치 방식과 데이터 경로를 확인하고, 사용하는 기본 그래픽·NewGRF·시나리오 목록을 함께 기록하는 편이 낫다. 특정 확장 그래픽을 넣은 회사의 문제가 기본 게임에서도 발생하는지 알려면 비교할 조건이 있어야 한다. 처음부터 기존 회사의 확장 콘텐츠를 모두 빼는 식으로 고치는 것도 피해야 한다. 산업과 차량을 정의하는 콘텐츠를 바꾸면 비교 대상 자체가 달라질 수 있기 때문이다.
편집팀이 제안하는 순서는 세 단계다. 먼저 기본 구성의 작은 새 지도에서 창과 조작을 살핀다. 다음으로 중요한 회사의 사본을 열어 역·차량·명령이 예상대로 보이는지 확인한다. 마지막으로 충분한 관찰 후 시험판을 계속 사용할지 결정한다. 작은 지도의 성공은 대형 회사의 완전한 정상 동작을 증명하지 않고, 대형 회사가 한 번 열렸다는 사실도 장기 운행의 안정성을 증명하지 않는다. 이 두 한계를 알고 실험하면 ‘최신 버전이니 무조건 교체’와 ‘베타니까 볼 필요 없음’ 사이의 실용적인 길이 생긴다.
03 | 바뀐 산업 연결 창은 노선의 출발점이지 수익 계산기가 아니다
베타5의 공식 변경 기록은 산업·화물 연결 창에 작은 표시 모드와 탐색 기록을 포함한 재설계를 명시한다. 화면에 산업 관계를 더 잘 펼쳐 보이고 앞서 살핀 관계로 돌아갈 수 있는 변화다. 여기서 바로 기대할 수 있는 것은 탐색의 편의이지 생산량이나 운송수익의 일괄 상승이 아니다. 화물이 어느 산업으로 이어지는지 이해하는 창과, 그 화물을 실제로 실어 나를 회사의 설계는 분리해서 봐야 한다.
가령 지도에서 어떤 원료 생산 시설을 발견했다고 하자. 연결 창으로 가능한 소비처를 파악한 다음에는 실제 지도에 그 시설이 있는지, 건설할 역이 필요한 화물을 받을 수 있는지, 차량이 해당 화물을 운송할 수 있는지를 차례로 확인해야 한다. 연결 관계가 있다는 사실만으로 바로 운송이 성립하지 않는다. 철도를 깔기 전에 출발역과 도착역의 역할을 말로 설명해 보면 실수가 줄어든다. ‘이 역은 원료를 받아들이는 곳’인지 ‘생산된 물건을 실어 나르는 곳’인지가 명확해야 한다.
이번 변경을 시험할 때는 일부러 긴 산업 사슬을 따라가 보되, 처음부터 모든 사슬을 건설하지 않는 편이 좋다. 큰 표시와 작은 표시에서 같은 관계를 찾아보고, 여러 항목을 거친 뒤 탐색 기록으로 돌아가 보자. 화면 크기를 줄였을 때 긴 화물 이름이나 한국어 항목이 잘리는지도 별도로 볼 만하다. 이는 개발팀이 특정 한국어 문제를 확인했다는 뜻이 아니라, 창 재설계와 글꼴 수정을 함께 경험하는 이용자가 수행할 수 있는 점검이다. 확인되지 않은 문제는 오류라고 단정하지 말고 조건을 기록하는 단계에서 멈추면 된다.
노선 선택에도 간단한 기준을 둘 수 있다. 첫 운송은 관계가 짧고 목적이 명확한 구간으로 만들고, 두 번째 운송은 첫 노선이 실제로 받거나 내놓는 화물을 보며 정한다. 산업 연결도 전체를 한꺼번에 실현하려 하면 지도에 없는 연결까지 상상 속으로 메우기 쉽다. 창은 후보를 보여 주고, 지도와 역 정보는 그 후보가 가능한지 판단하게 한다. 플레이어가 두 정보를 왕복하는 과정 자체가 이번 개선의 활용처다. 연결 창을 거대한 설계도를 완성하는 도구가 아니라, 다음 질문을 정확하게 만드는 도구로 사용해 보자.
04 | 헬리콥터가 오래 남는다는 말의 정확한 의미
공식 배포 소식은 Guru X2 헬리콥터의 수명을 연장해 기본 게임에서 계속 이용할 수 있게 했다고 설명한다. 여기서 차량 한 대의 정비 상태, 모델의 판매 가능 기간, 노선의 경제성을 뒤섞지 않는 것이 중요하다. 오랫동안 구매 선택지가 남는다는 변화가 모든 헬리콥터 노선의 운영비를 낮추거나 기체의 속도를 높인다는 뜻은 아니다. 베타5 변경 기록에도 그런 일괄 성능 상향은 적혀 있지 않다.
이 변화가 반가운 이용자는 장기 지도를 즐기며 헬리콥터를 교통망의 한 부분으로 유지하려는 사람이다. 섬과 해안, 도심의 공간 제약을 고려해 만든 노선에서 선택지가 사라지지 않는다는 것은 회사의 형태를 보존하는 문제와 이어진다. 다만 특정 NewGRF가 항공기 목록이나 수명을 바꾸는 회사까지 같은 결과가 적용된다고 확대해 말할 수는 없다. 기본 차량과 확장 차량의 정의가 다를 수 있으므로, 구매 창에서 실제 남아 있는 모델을 확인하는 것이 우선이다.
시험 사본에서는 헬리콥터를 실제로 사용하는 노선을 따로 찾고 해당 모델이 구매 목록에서 어떻게 보이는지 살피면 된다. 헬리콥터 노선이 없는 회사라면 업데이트를 확인하겠다는 이유만으로 억지 노선을 만들 필요는 없다. 기존 교통망에서 해결하고 싶은 수요가 있는지부터 생각하자. 다른 수단이 충분히 연결하는 두 지점 사이에 새 항공편을 더하는 것과, 육상 연결이 어려운 지점을 이어 주는 것은 운영상 의미가 다르다.
공항 건설 안내는 위치를 고를 때 수용·공급 화물과 서비스 범위를 확인하도록 설명한다. 활주로나 착륙 시설을 놓을 공간만 확보했다고 승객이 자동으로 몰리는 것은 아니다. 주변 수요와 접근 교통을 함께 봐야 한다. 그래서 헬리콥터 변경을 읽는 가장 유용한 질문은 ‘이제 무엇이 제일 강한가’가 아니라 ‘내가 유지하려던 연결을 앞으로도 같은 수단으로 운영할 수 있는가’다. 오래 지속하는 회사의 재미는 가장 높은 숫자를 가진 차량만 반복 구매하는 것과는 다른 곳에도 있다.
05 | 역 이름표 이동과 글꼴 수정, 작은 동작을 따로 시험하자
베타5의 공지는 역 이름표를 옮긴 뒤 발생하는 네트워크 동기화 문제를 수정했다고 알린다. 상세 변경 기록에는 이름표를 이동했을 때 역의 서비스 범위가 갱신되지 않는 문제가 적혀 있다. 두 설명은 서로 다른 홍보 문구처럼 떼어 읽기보다, 이용자가 보는 현상과 수정 대상의 표현이 다르다는 점을 기억하면 좋다. 다만 그 기록만으로 모든 역 범위 문제나 모든 멀티플레이 동기화 오류가 사라졌다고 결론 내릴 수는 없다.
이 변경을 확인하려면 선로 확장, 역 철거, 산업 추가까지 한꺼번에 하지 않는 편이 낫다. 시험 사본의 같은 위치에서 이름표 이동 전후를 비교하고, 창의 정보와 지도 표시가 어떻게 바뀌는지 관찰한다. 이상이 보이면 어떤 역을 얼마나 옮겼는지, 어떤 조작 직후였는지부터 적는다. 원인을 모르는 상태에서 신호기를 싹 지우거나 역을 재건하면 문제를 발견한 조건도 함께 사라진다. 좋은 시험은 더 많은 버튼을 누르는 일이 아니라, 무엇을 바꾸었는지 설명할 수 있는 상태를 유지하는 일이다.
한국어 이용자에게는 글꼴 관련 수정도 읽을 가치가 있다. 변경 기록은 글꼴 탐색에서 전체 언어 코드를 사용하고, 대체 글꼴이 빠진 문자뿐 아니라 필요한 문자 전체를 갖추도록 선택하며, 언어 변경에 따른 글꼴 변경 후 위젯 크기가 잘못될 수 있는 문제를 고쳤다고 적는다. 이를 ‘한글 문제가 모두 해결됐다’고 번역하면 범위를 넘는다. 실제 체감은 운영체제, 설치된 글꼴, 선택한 언어와 화면 배율에 따라 확인해야 한다.
점검 대상은 긴 역 이름, 차량 이름, 구매 목록, 여러 줄이 들어가는 정보 창처럼 정해 두는 것이 좋다. 글자가 보이는지와 버튼이 눌리는지는 별개다. 문자가 정상이어도 줄 높이나 창 폭 때문에 항목이 겹칠 수 있고, 창의 크기가 알맞아도 일부 글자가 다른 모양으로 나타날 수 있다. 화면을 저장해 둘 때는 버전과 언어, 문제를 재현한 순서를 함께 남기자. 예쁜 스크린샷보다 문제를 다시 찾아갈 수 있는 설명이 수정 보고에 더 유용하다.
06 | 선로를 늘리기 전에 열차가 기다릴 장소부터 정한다
운송망을 읽을 때 첫 질문은 선로가 몇 가닥인가가 아니라 열차가 어디에서 멈추는가다. 공식 신호 안내는 경로 신호를 기본적인 선택으로 설명하며, 분기점을 막지 않고 기다릴 수 있는 곳에 설치하라고 강조한다. 경로 신호는 단순히 앞 구간 전체가 비었는지를 보는 방식과 달리 열차가 통과할 경로를 예약한다. 서로 충돌하지 않는 경로라면 같은 연결 구역을 활용할 수 있다는 점이 핵심이다. 이것은 열차를 아무 데나 세워도 된다는 허가가 아니다.
예시로 두 갈래 선로가 하나로 합쳐지는 합류점을 생각해 보자. 합류 직후 아주 가까운 곳에 정차 지점을 만들면, 그 앞에 멈춘 열차의 뒷부분이 아직 분기기 위에 남을 수 있다. 다른 열차는 목적지가 달라도 그 꼬리 때문에 진행하지 못한다. 이때 해결책을 무조건 신호 추가로 찾으면 오히려 잘못된 대기 지점을 늘리게 된다. 합류 전에서 기다리게 하거나, 합류 뒤에 한 편성이 온전히 들어갈 공간을 마련하는 쪽으로 생각해야 한다.
‘한 편성이 들어간다’는 말도 기관차 앞부분만 들어간다는 뜻이 아니다. 현재 운행하는 가장 긴 열차의 마지막 차량까지 연결 구역을 벗어나야 한다. 짧은 편성으로 처음 만든 선로에 나중에 긴 편성을 넣었다면, 승강장을 늘리는 것과 별도로 대기 공간을 다시 살펴야 한다. 이 과정에서 실제 게임의 길이 표시와 선로 배치를 함께 확인하면 된다. 숫자를 외워 모든 지도에 동일한 간격을 적용하는 방식보다 자신의 편성 기준을 정하는 편이 설명하기도 쉽다.
경로 신호와 단방향 경로 신호도 구별해야 한다. 공식 안내에 따르면 일반 경로 신호는 뒷면에서 통과할 수 있지만 단방향 경로 신호는 그러지 못한다. 방향을 통제하고 싶은 본선과 양방향 출입이 필요한 역 앞에서 같은 선택을 기계적으로 반복하지 말자. 먼저 열차가 어느 쪽에서 들어와 어디로 나갈지 손가락으로 따라간 다음 신호 종류를 결정하는 것이 낫다. 복잡한 교차로 그림을 복제하기 전에 작은 합류점 하나를 이해하는 일이 훨씬 오래 쓸 수 있는 지식이 된다.
07 | 승강장 개수보다 출입 방식이 먼저다
역을 확장할 때 가장 쉬운 선택은 승강장을 더 붙이는 것이다. 하지만 모든 승강장이 같은 좁은 입구를 공유하고 들어오는 열차와 나가는 열차가 계속 서로를 가로막는다면, 승강장 증설만으로 흐름이 좋아지지 않을 수 있다. 공식 역 안내는 종착형과 통과형의 차이를 설명한다. 종착형은 들어온 쪽으로 다시 나가고, 로로형은 한쪽으로 들어와 다른 쪽으로 나간다. 어느 것이 무조건 우월하다기보다 지형과 운행 목적에 따라 필요한 공간과 충돌하는 동작이 달라진다.
작은 지선의 종점이라면 종착형의 간결함이 장점이다. 반대로 여러 출발지의 열차가 계속 모이는 곳에서는 입구와 출구의 관계를 더 자세히 봐야 한다. 예를 들어 두 승강장이 있고 한 편성은 싣기를 기다리며 오래 정차하고, 다른 편성은 도착하자마자 내리고 돌아간다고 하자. 두 열차의 작업 시간이 다르다는 사실을 무시한 채 빈 승강장 수만 세면 대기의 원인을 잘못 판단한다. 관찰할 것은 열차가 승강장에 머무는 시간과 출입 선로를 점유하는 시간이다.
편집팀의 설계 제안은 역을 세 부분으로 나누어 종이에 적어 보는 것이다. 도착 열차가 기다리는 곳, 화물을 처리하는 승강장, 떠난 열차가 본선에 합류하기 전 머무를 수 있는 곳이다. 세 부분을 반드시 거대하게 만들라는 뜻은 아니다. 작은 역에서는 같은 공간을 번갈아 써도 충분하다. 다만 회사가 커졌을 때 어느 부분이 겹치는지 알아야 불필요한 철거를 줄일 수 있다. 출구를 늘려야 하는 역에 입구만 넓히는 공사는 돈과 땅을 쓰면서도 같은 문제를 남긴다.
주요 통과 열차가 일부러 정차역의 입구를 가로질러야 하는 배치도 다시 살펴볼 만하다. 역 안내는 필요 없는 통과 교통이 역을 방해하지 않도록 본선과 역의 관계를 설계하라고 설명한다. 여기서 ‘본선 분리’는 거대한 고속철도 같은 외형을 흉내 내라는 뜻이 아니다. 정차할 열차와 지나갈 열차의 선택 지점을 명확하게 만들자는 원칙이다. 흘러가는 열차 한 대를 따라가 보면, 정지 화면에서 멋있어 보였던 선로 중 어떤 부분이 실제 선택을 강요하는지 보이기 시작한다.
연습용 배치는 한 역에 열차 두 대만 넣고 시작할 수 있다. 먼저 한 대가 들어와 정차한 상태에서 다른 한 대가 어디까지 접근하는지 본다. 다음에는 첫 열차가 출발할 때 두 번째 열차의 입장이 어떻게 달라지는지 살핀다. 마지막으로 두 대의 역할을 바꿔 같은 관찰을 반복한다. 특정 도면의 처리량을 측정했다는 뜻이 아니라, 자신이 만든 역의 충돌 지점을 눈으로 찾는 절차다. 대기 중인 열차가 어느 지점에서 움직이기 시작하는지 설명할 수 없다면 승강장 추가보다 그 이유를 확인하는 일이 먼저다.
08 | 가까이 있는 정류장과 같은 역은 다르다
환승망을 만들 때 가장 먼저 확인할 것은 버스가 철도역 옆까지 도착하는지가 아니라 두 시설이 게임 안에서 같은 역으로 연결되어 있는지다. 공식 역 안내에 따르면 결합된 역은 이름, 화물의 수용 정보, 대기 화물의 풀을 공유한다. 실제 시설의 위치와 모양은 그대로여도 논리적으로 하나의 역이 되는 것이다. 반대로 지도에서 가깝게 보이는 두 정류장이 별개의 역이라면 플레이어가 기대하는 방식으로 화물이 옮겨지지 않는다.
도시 중심 버스 정류장과 외곽 철도역을 잇는 예를 들면 이해하기 쉽다. 도심의 승객을 모아 철도에 넘기려면 철도역 쪽 버스 정류장의 연결 상태를 확인해야 한다. 건설할 때 서로 붙여 결합하거나, 허용 범위 안에서 원거리 결합을 선택하는 방법이 있다. 공식 안내는 건설 시 Ctrl을 누른 클릭으로 결합할 기존 역을 고르는 기능을 설명한다. 다만 같은 이름으로 표시되었는지만 무심코 보고 끝내지 말고, 역 창에서 버스와 철도 시설이 함께 나타나며 의도한 화물을 공유하는지 확인하는 것이 좋다.
이 구분은 도시 공간을 해석하는 재미로도 이어진다. 도심에 큰 철도역을 억지로 넣는 대신 작은 버스망으로 수요를 모아 외곽에서 넘길 수 있다. 그렇다고 역을 최대한 넓게 늘리는 것이 언제나 정답은 아니다. 정류장이 어디를 서비스하는지와 차량이 실제로 어디를 오가는지가 따로 움직이면, 지도는 연결된 것처럼 보여도 운행은 불필요하게 돌아간다. 시설의 결합은 환승을 가능하게 하는 조건이지 좋은 배차를 대신하는 기능은 아니다.
역 서비스 범위 관련 문서는 현재 일부 설명이 오래되었다는 경고를 달고 있다. 따라서 과거 문서에 적힌 반경 숫자 하나를 모든 버전과 설정의 규칙으로 외우기보다, 건설 창의 수용·공급 정보와 현재 표시되는 범위를 확인하는 것이 안전하다. 베타5에서 이름표 이동 관련 수정이 있었다는 점도 이 습관의 가치를 높인다. ‘분명 옆에 세웠는데 왜 안 되지’라는 질문은 거리를 더 줄이기 전에 역의 결합, 받는 화물, 차량 명령이라는 세 갈래로 나누어 볼 수 있다.
09 | 수동 환승과 자동 목적지 배분을 섞어 읽지 않기
OpenTTD의 환승 설명에서 가장 자주 혼동되는 부분은 수동 환승과 Cargodist, 즉 승객·화물의 자동 목적지 배분이다. 공식 안내는 자동 배분을 사용하면 승객과 화물이 목적지를 갖고, 그 목적지로 이어지는 차량을 이용한다고 설명한다. 수동 방식의 일방향 집하 노선을 설명하는 문서를 읽고 그 명령을 자동 배분 회사에 그대로 붙여 넣으면, 원리를 이해하기보다 불필요한 제약을 더할 수 있다. 시작 전에 해당 화물의 배분 모드를 확인해야 하는 이유다.
수동 방식으로 도심 버스가 외곽 공항에 승객을 넘기는 단순한 사례를 생각해 보자. 공식 집하 안내는 공항에서 환승하고 빈 차로 떠나는 명령을 사용하는 예를 든다. 환승만 지정하고 적재를 막지 않으면 방금 내린 승객을 다시 태우는 동작이 생길 수 있기 때문이다. 명령의 목적은 승객을 그 장소에 남겨 다음 수단이 가져가게 하는 것이다. 반대로 중간 도시에서 기존 승객을 내리지 않고 새 승객만 더 태우려는 동작은 다른 명령의 조합으로 생각해야 한다.
자동 배분에서는 연결된 버스망과 철도가 보통의 정차 명령으로 이어지고, 목적지에 따라 환승이 처리될 수 있다. 다만 자동이라는 말은 빈 좌석과 대기 승객을 자동으로 없애 준다는 뜻이 아니다. 목적지가 있는 승객은 아무 열차나 타지 않을 수 있다. 역에 사람이 많은데 일부 차량이 빈 채로 떠나는 장면도 우선은 목적지와 다음 경유지를 살펴볼 이유가 된다. 모든 대기를 단순히 차량 부족이라고 판단하면 엉뚱한 방향의 노선만 증차하게 된다.
편집팀은 처음 배우는 회사라면 한 가지 방식을 선택해 작은 연결부터 이해하기를 제안한다. 수동 집하라면 출발지·환승지·최종 목적지에서 각 차량이 무엇을 내리고 무엇을 싣는지 말로 써 본다. 자동 배분이라면 역 정보의 다음 경유지와 연결 관계를 읽는 데 시간을 쓰자. 둘 중 하나가 초보용이고 다른 하나가 정답이라는 구분은 아니다. 목적지가 없는 화물을 플레이어가 넘기는 방식과, 목적지를 가진 화물이 연결망을 따라 움직이는 방식이라는 차이를 아는 것이 먼저다.
10 | 빨간 수익 숫자 하나로 환승망을 지우지 말자
연계 운송을 만든 뒤 마지막 구간의 차량이 적자로 표시되면 그 노선을 곧바로 없애고 싶어진다. 그러나 공식 설명은 집하 운송에서 중간 구간에 배분된 가상 수입 때문에 마지막 차량의 표시 수입이 음수가 될 수 있다고 설명한다. 화물이 최종 목적지에 도착하기 전에 중간 구간의 기여를 추정해 표시하고, 마지막에 전체 운송 대금을 계산하면서 차이가 드러나는 구조다. 한 차량의 숫자와 회사 전체에서 완성된 운송의 결과는 같은 질문에 대한 답이 아니다.
그렇다고 모든 적자가 장부상의 착시라는 뜻도 아니다. 우회가 지나치게 길거나 느린 구간에서 배송이 지연되면 실제 운송 가치가 낮아질 수 있다. 공식 화물 수입 설명은 화물 종류, 양, 출발·도착 사이의 거리, 운송 시간을 주요 요인으로 든다. 선로를 장식적으로 길게 돌렸다고 그 선로 길이만큼 운임이 늘어나는 것은 아니다. 지도에서 보기에 긴 여행과 계산에 쓰이는 출발·도착 관계를 구별해야 한다.
운영 판단에서는 두 가지 장부를 따로 읽는 편이 좋다. 하나는 차량별 표시 수입으로, 어떤 구간의 비용과 수입 배분이 어떻게 나타나는지 보는 것이다. 다른 하나는 실제 화물이 원하는 목적지까지 도착하고 회사의 운송 활동이 지속 가능한지 보는 것이다. 두 번째 질문 없이 첫 번째 숫자만 보고 지선을 지우면, 본선에 승객을 공급하던 연결을 없애 놓고 본선의 적재율이 떨어지는 결과를 맞을 수도 있다. 이 사례는 가능한 결과를 설명하는 예이며 모든 적자 지선을 보존하라는 조언은 아니다.
수정도 작게 해 보자. 우회 구간을 줄이는 안, 환승에서 대기하는 시간을 줄이는 안, 차량 크기를 바꾸는 안을 한꺼번에 적용하지 말고 하나씩 비교한다. 같은 기간을 관찰하되 산업 변화나 도시 성장처럼 비교 조건을 흔드는 요인이 있었는지도 함께 적는다. 플레이 시간이 길수록 수익 숫자 자체보다 그 숫자가 만들어지는 경로를 설명할 수 있는 능력이 중요해진다. 철도와 버스, 선박이 서로의 일을 나누는 회사를 만들었다면 평가 역시 한 대씩 끊어서만 해서는 부족하다.
11 | 같은 노선의 차량을 늘릴 때 명령도 같은 상태인가
교통망이 커지면 선로보다 명령 목록의 차이가 문제를 만든다. 같은 노선에 투입했다고 생각한 두 버스 중 한 대만 예전 정류장을 계속 방문하거나, 한 열차만 환승역에서 적재를 금지한 채 달릴 수 있다. 공식 명령 안내는 복사된 명령과 공유된 명령을 구분한다. 복사는 그 순간의 목록을 옮기지만 공유는 목록이 연결되어 있어 하나를 바꾸면 함께 쓰는 차량에도 반영된다. 두 기능의 이름이 비슷해도 운영 결과는 다르다.
공유 명령을 사용한다고 해서 개별 차량의 역할을 생각하지 않아도 되는 것은 아니다. 같은 정류장 순서를 반복하는 여러 차량에는 편리하지만, 일부만 우회하거나 별도 작업을 해야 한다면 먼저 공유 관계를 확인해야 한다. 시험용으로 한 차량의 명령을 바꿨는데 전체 노선의 차량이 따라 움직이는 상황을 피하려면 무엇이 연결되어 있는지 아는 것이 중요하다. 공식 안내가 공유 해제 절차를 별도로 설명하는 것도 이 때문이다.
편집팀의 관리 제안은 차량 이름을 멋지게 짓기 전에 노선의 역할을 짧게 정하는 것이다. 예를 들어 ‘도심 집하’, ‘외곽 간선’, ‘항만 연결’처럼 기능을 나타내면 명령 목록이 그 역할에 맞는지 비교하기 쉬워진다. 이름이 같은 차량끼리 자동으로 명령을 공유하는 것은 아니므로 이름표 자체를 기능으로 착각해서는 안 된다. 분류는 사람이 이해하기 위한 장치이고 공유 관계는 게임 안에서 확인할 대상이다.
차량을 추가한 뒤에는 구매 성공 여부만 보지 말고 한 바퀴를 완성하는지 살펴보자. 출발지에 도착했는가, 의도한 화물을 싣는가, 중간 정차가 불필요하게 끼어 있지 않은가, 돌아온 뒤 같은 순환을 이어 가는가를 순서대로 볼 수 있다. 이 관찰은 수익이 충분히 쌓이기 전에도 가능하다. 반대로 연간 수입을 기다리는 동안 잘못된 명령으로 계속 운행하게 두면 작은 실수가 큰 회사의 평소 모습처럼 굳어질 수 있다. 늘리는 속도보다 늘린 차량의 역할을 확인하는 속도가 따라가는 회사가 관리하기 쉽다.
작은 운영 기록도 도움이 된다. 노선 이름 옆에 마지막으로 변경한 역, 변경 이유, 확인할 차량 한 대를 적어 두면 다음 접속에서 바로 관찰을 이어 갈 수 있다. ‘차가 막힘’처럼 결과만 적기보다 ‘항만을 떠난 열차가 합류 직전에서 대기하는지 확인’처럼 대상을 좁혀 쓰자. 기록을 거대한 업무 문서로 만들 필요는 없다. 한 번의 플레이에서 끝내지 못한 질문을 다음 플레이의 첫 행동으로 연결할 정도면 충분하다. 이는 자동화 기능을 새로 설치하지 않고도 자신의 운송망을 더 잘 이해하는 방법이다.
12 | 멀티플레이는 버전 번호부터 합의하는 공동 시험이다
베타5의 네트워크 수정이 반갑더라도 혼자 설치한 최신 시험판이 다른 사람의 서버와 저절로 맞아지는 것은 아니다. 공식 멀티플레이 안내는 서버 목록의 호환 표시가 실행 버전과 NewGRF의 일치 여부를 나타낸다고 설명한다. 친구와 함께 시험한다면 ‘16을 쓰자’ 정도로 말하기보다 정확한 배포본 이름과 콘텐츠 구성을 맞추는 편이 좋다. 베타4와 베타5를 같은 ‘최신’이라는 단어로 부르면 대화는 쉬워져도 비교는 어려워진다.
이번 시험의 목적도 미리 정해 두자. 새 회사에서 자유롭게 경쟁하려는 것인지, 기존 공동 회사의 사본으로 특정 조작을 확인하려는 것인지에 따라 기록해야 할 것이 달라진다. 후자의 경우 한 사람은 역 이름표를 옮기고 다른 사람은 동시에 지형과 선로를 대규모로 바꾸는 식의 시험은 원인 분리가 어렵다. 재현하려는 조작을 정하고 다른 변화는 잠시 멈추면, 문제가 생겼을 때 무엇을 보고해야 하는지 훨씬 명확해진다.
동기화 오류가 발생했다고 해서 즉시 특정 이용자의 컴퓨터나 회선 탓으로 돌릴 필요는 없다. 오류 직전의 저장 상태, 실행 버전, 콘텐츠 목록, 참여자들이 수행한 조작을 모아야 한다. 공지가 한 종류의 동기화 문제를 고쳤다는 사실은 모든 원인을 배제하는 증거가 아니다. 반대로 오류가 한 번 보였다는 이유만으로 시험판 전체를 사용할 수 없다고 일반화하는 것도 성급하다. 관찰된 범위와 확인되지 않은 범위를 구별한 보고가 공동 작업에 도움이 된다.
공동 회사에서는 기술적인 일치만큼 운영 약속도 중요하다. 어느 사람이 어떤 역을 확장하는지, 본선을 잠시 막는 공사를 언제 하는지, 다른 사람의 공유 명령을 수정해도 되는지 정해 두면 혼란을 줄일 수 있다. 이는 게임이 강제하는 규칙이 아니라 협업을 위한 편집팀의 제안이다. OpenTTD의 재미는 각자 만든 선로가 하나의 망으로 이어지는 데 있지만, 연결이 많을수록 한 사람의 작은 변경이 다른 사람에게 미치는 영향도 커진다. 베타 시험은 그 영향을 서로 설명하는 연습이 될 수 있다.
13 | 화면을 참고할 때는 버전과 그래픽부터 읽는다
본문 화면은 OpenTTD 16.0-beta5와 OpenGFX 8.0으로 실행한 실제 게임의 모습이다. 배포본에 포함된 시연 지도를 게임으로 불러온 회사이며, 새로 건설한 경제 실험이나 완성된 운영 모범 사례는 아니다. 산업 연결, 집하 범위, 명령, 재무처럼 확인할 대상을 나누어 보면 비슷한 도시 위에서도 서로 다른 정보를 읽을 수 있다. 큰 도시와 많은 차량이 있다는 사실만으로 운영이 완결됐다고 판단하지 말자. 멋진 전체 풍경은 노선의 결과를 보여 주지만, 그 노선이 무엇을 싣고 어디에서 기다리며 어떤 규칙으로 움직이는지는 개별 창을 열어야 알 수 있다.
OpenTTD라는 이름이 같아도 화면 속 차량과 산업이 자신의 게임에 그대로 나타나는 것은 아니다. 기본 그래픽은 화면을 그리는 재료이고, NewGRF는 구성에 따라 차량이나 산업 등 게임에서 사용할 콘텐츠를 바꿀 수 있다. 이 글의 화면에는 추가 NewGRF가 없으며 OpenGFX 기본 그래픽을 사용했다. 다른 이용자의 멋진 역이나 차량을 따라 만들려는데 자신의 구매 목록에 없다면, 조작을 잘못했다고 단정하기 전에 그 저장 파일이 쓰는 세트부터 확인하자. 그래픽만 다른 경우와 실제 차량 규칙이 다른 경우를 구별해야 조언도 정확하게 적용할 수 있다. 친구의 회사와 자기 회사를 비교할 때도 기후, 시작 연도, 콘텐츠 구성을 함께 적어 두는 편이 좋다.
시연 회사의 숫자는 특히 조심해서 읽어야 한다. 열차가 차량기지만 왕복하는 공유 명령도 있고, 일부 차량에는 적절한 운송 명령이 부족하다. 큰 보유 현금이나 붉은 연간 손익은 이런 시연 상태에 붙은 값이므로 특정 운송수단이 우월하다거나 베타5가 적자를 만든다는 근거가 되지 않는다. 본문에서 제안한 환승 노선과 신호 대기 위치 역시 별도로 구성해 관찰할 설계 예시다. 촬영으로 확인한 창의 표시, 공식 변경 기록이 설명하는 수정 사항, 편집팀이 제안하는 운영 실험을 분리해서 읽는 것이 중요하다. 같은 이유로 헬리콥터 목록의 한 장만 보고 이전 버전과의 판매 가능 기간 차이를 측정했다고 말하지 않는다.
베타5를 계기로 다시 시작한다면 첫날의 목표를 거대한 전국망보다 한 개의 설명 가능한 연결로 잡아 보자. 왜 그 역을 골랐는지, 왜 그 지점에서 열차가 기다리는지, 환승한 화물이 왜 다음 차량에 실리는지를 말할 수 있다면 다음 확장은 훨씬 쉬워진다. 안정판의 회사를 지키면서 새 창을 시험하고, 새 기능과 오래된 운영 원칙을 구분하는 태도가 오래 즐길 수 있는 출발점이다. 업데이트의 번호는 앞으로도 올라가겠지만, 좋은 운송망은 결국 플레이어가 자기 회사의 움직임을 읽을 수 있을 때 완성된다.
댓글
댓글 쓰기