확장팩 FFF 모음 정리 링크

오늘도 뒷부분은 기술적인 이야기가 많아서 오역 있을 가능성 높음

컴공아조시들 그냥 그런갑다하고 넘어가주셈

https://www.factorio.com/blog/post/fff-408

FFF #408 - 통계 개선, Linux 모험

게시자 Klonan, raiguard

2024-04-26

안녕하세요,

FFF의 세계에 다시 한 번 오신 것을 환영합니다.

통계 - Klonan

여러분도 저희만큼이나 생산 그래프가 성장하는 것을 좋아하시나요?

축전지 그래프

증기 발전에서 태양열 패널과 축전지로 전환할 때 추운 밤을 견딜 수 있는 충분한 용량이 시스템에 있는지 확인하는 것은 조금 까다롭습니다. 일반적으로는 밤이 될 때까지 기다렸다가 공장이 정전되는지 확인하고, 정전되면 태양열 패널과 축전지를 더 건설하는 방식으로 진행합니다.

축전지 충전 수준 통계를 확인하면 유용하고 편리할 것 같아서 이러한 정보를 추가했습니다:

이 정보가 더 중요한 이유는 풀고라에서는 야간에 번개로 인한 생산량을 예측하기 어렵기에 축전지 충전량 타임라인을 확인하는 것이 훨씬 더 중요하기 때문입니다.

과학 그래프

생산 GUI에서 과학 팩 소비량을 추적할 수 있지만, 생산성 모듈과 새로운 연구 생산성 기술 같은 것은 고려하지 않습니다.

그래서 생산 통계에 새로운 특별 항목을 추가하여 생산된 총 최종 '과학'을 표시합니다.

표면당 생산량

행성과 플랫폼으로 플레이 테스트하던 초기에는 모든 생산 통계가 전 맵 단위로 표시되어도 괜찮았습니다. 그러나 게임플레이를 점점 더 정밀하게 만들고 각 부분을 최적화하려고 할 때, 이는 상당히 개선이 필요해졌습니다.

예를 들어 플랫폼의 경우, 이동을 계속하기에 충분한 연료와 탄약을 생산하고 있는지 알아야 합니다:

그리고 특정 행성에서 특정 아이템이 여러 곳에서 제작될 때 충분히 생산되는지 확인할 때도 매우 유용합니다.

또한 '글로벌 통계' 보기로 전환하는 확인란을 추가하여 플레이어가 모든 가능성을 확인할 수 있도록 했습니다.

품질 그래프

더 깊이 들어가서 생산된 아이템의 품질을 기준으로 생산량을 분석하고자 합니다.

어떻게 생각하시나요? 2.0 버전에서 개선할 수 있는 다른 통계 개선 사항이 있나요?

리눅스 모험 - raiguard

지금까지 몇 번의 FFF에 출연했지만 공식적으로 제 소개를 한 적은 없습니다. 제 이름은 raiguard입니다. 저는 2017년 6월부터 팩토리오를 플레이해왔고, 2019년 3월 0.17 버전 출시 이후 게임 모드를 만들다가 2023년 3월에 드디어 WUBE에 합류했습니다. 회사에서 저의 주요 역할은 확장 프로그래밍과 Linux 지원, 그리고 모딩 커뮤니티의 관리자입니다. 저는 수년 동안 매일 Linux를 사용하면서 커스터마이징과 미니멀리즘의 블랙홀에 점점 더 깊이 빠져들고 있습니다.

"왜 대부분의 게임은 macOS와 Linux를 지원하지 않나요?" 인터넷에서 자주 듣는 질문입니다. 새로운 플랫폼을 지원하는 것은 단순히 플래그 몇 개를 변경하고 컴파일을 누르는 것 이상의 일입니다. Windows, macOS, Linux, Nintendo Switch는 모두 다른 컴파일러와 C++ 표준 라이브러리의 다른 구현을 사용하며 구현상의 문제, 버그, 기능도 다릅니다. 새 플랫폼에 맞는 CI를 설정하고, 새로운 컴파일러와 아키텍처를 지원하도록 빌드 시스템을 확장해야 하며, 팀에 해당 플랫폼에 관심을 갖고 적극적으로 유지 관리할 수 있는 사람이 한 명 이상 있어야 합니다. 비디오 게임의 경우 DirectX는 Windows 전용이므로 다른 그래픽 백엔드(Vulkan 또는 OpenGL)에 대한 지원도 추가해야 할 가능성이 높습니다.

많은 개발자가 Windows 시장 점유율을 한 번 보고 다른 플랫폼을 지원할 가치가 없다고 판단할 것입니다. 또한 Steam 데크와 프로톤의 급격한 성장으로 게임 개발자가 Linux 지원을 무시하기가 그 어느 때보다 쉬워졌는데, 이는 Valve가 게임을 실행할 수 있는 흑마법을 부리기 때문입니다.

팩토리오가 macOS와 Linux를 잘 지원할 수 있었던 것은 항상 이러한 플랫폼을 적극적으로 사용하고 지원 부담을 기꺼이 감수하는 사람이 있었기 때문입니다. Apple Silicon 지원이 그 좋은 예입니다. 오늘은 팩토리오의 Linux 지원을 유지하면서 겪었던 몇 가지 모험을 소개해드리겠습니다.

Wayland

팀에 합류한 후 제가 스스로 정한 첫 번째 임무는 게임에 Wayland 지원을 추가하는 것이었습니다. Wayland는 낡고 안전하지 않은 X11 시스템을 대체하기 위해 개발 중인 새로운 디스플레이 프로토콜입니다. 최신 Linux 배포판은 기본적으로 Wayland로 전환하기 시작했기 때문에 Factorio에서 이를 지원하는 것이 가장 중요합니다.

우리는 대부분의 저수준 시스템 상호 작용을 깔끔하게 처리하고 공통 인터페이스로 추상화하는 SDL 라이브러리를 활용합니다. SDL은 Wayland를 지원하므로 이론적으로는 Wayland를 활성화한 상태에서 SDL을 구축하기만 하면 "그냥 작동"합니다. 하지만 말처럼 간단하지만은 않습니다. Wayland는 XML 파일 형식의 "프로토콜"을 제공하며, Wayland-scanner 바이너리를 사용하여 C 프로그램 및 헤더 파일로 변환합니다.

당시 C++를 비교적 처음 접했던 저는 초기 솔루션이 복잡했고, 생성된 Wayland 프로토콜을 소스 트리에서 확인하여 SDL을 업데이트할 때마다 수동으로 다시 생성해야 했습니다. 몇 달 전, 다년간의 경험으로 무장한 저는 이 워크플로를 개선하여 빌드 프로세스의 일부로 파일을 자동으로 생성함으로써 SDL이 함께 제공되는 프로토콜 XML 파일로 항상 최신 상태를 유지할 수 있도록 했습니다.

Factorio는 1.1.77 버전부터 Wayland를 지원했지만, 사용자 환경에서 SDL_VIDEODRIVER=wayland를 설정하여 명시적으로 활성화해야 합니다. Factorio 2.0에서는 GUI에서 기본 설정을 선택할 수 있는 드롭다운을 추가했습니다:

데스크톱 디스플레이 스케일을 125%로 설정한 X11(왼쪽)과 Wayland(오른쪽) 비교.

Wayland에서 실행할 때 게임이 디스플레이의 기본 해상도에서 어떻게 렌더링되는지 확인하세요.

클라이언트 측 창 장식

Wayland 지원이 구현된 후 GNOME에서 실행할 때 창에 제목 표시줄과 닫기 버튼("창 장식 (window decorations)"이라고 함)이 없다는 버그 보고를 받았습니다. 대부분의 데스크톱 환경에서는 창이 원하는 경우 자체 장식을 제공할 수 있지만 서버 측에서 기본으로 구현하는 것을 대안으로 제공합니다. GNOME은 무한한 지혜로 모든 클라이언트가 자체 장식을 제공해야 하며, 그렇지 않은 클라이언트는 단순히 누락될 것이라고 결정했습니다. 저는 이 결정에 동의하지 않습니다. 팩토리오는 다른 플랫폼, 아니 다른 데스크톱 환경에서 장식을 제공할 필요가 없지만 GNOME은 그 인기를 이용해 프로그램이 자신의 특색을 따르도록 강요하거나 뒤처지게 할 수 있습니다.

이 문제를 해결하기 위해 또 다른 종속성인 libdecor를 가져와야 했습니다. 이 종속성은 잘 작동하고 SDL에서도 이를 지원하지만 비디오 게임에서는 애초에 창 장식을 제공할 필요가 없습니다.

이제 게임에는 장식이 있지만 테마가 일치하지 않습니다. 고마워요 GNOME!

창 크기 조정 플리커링

백 번 듣는 것이 한 번 보는 것만 못하다고 하죠?

https://cdn.factorio.com/assets/blog-sync/fff-408-seizure.mp4

 광과민성 경고: 이미지가 빠르게 깜박입니다. 

(역주 : 움짤 따올순 있는데 경고도 달려있는데 굳이 싶어서 링크드가셈)

저는 Sway 창 관리자를 사용하는데, 이 창 관리자의 특징은 떠다니는 창 크기를 마지막으로 제출한 프레임 크기로 자동으로 조정한다는 것입니다. 이로 인해 그래픽 스택의 문제가 드러났습니다. 게임이 창 크기 조정에 제대로 반응하는 데 3프레임이 걸린다는 것입니다. 그 결과 Sway는 수많은 크기 조정 이벤트를 보내고 Factorio는 오래된 프레임 버퍼 크기로 대응하면서 위에서 캡처한 혼란이 빠르게 진행되었습니다.

이틀 내내 그래픽 코드를 들여다봤지만 왜 이런 문제가 발생하는지 설명할 수 없었기 때문에 이 작업은 여전히 진행 중입니다. 이 문제는 Wayland에서 Sway로 게임을 실행할 때만 발생하므로 우선 순위가 높지는 않지만 너무 재미있어서 공유하지 않을 수 없었습니다.

동적으로 연결된 라이브러리

C++ 프로그램에서 라이브러리를 로드/포함하는 방법에는 세 가지가 있습니다:

- 소스 바이너리에 포함시키는 방법(정적 링크).

- 프로그램이 시작될 때 시스템이 라이브러리를 로드하도록 하는 방법(동적 링크).

- 프로그램 시작 후 명시적으로 로드하는 경우("동적 로드" 또는 "런타임 링크"라고 함).

SDL, FontStash, Lua 등 많은 라이브러리가 정적으로 링크되어 있지만 Factorio 1.1에는 동적으로 링크되는 라이브러리도 많이 있습니다:

rai@tantal ~/games/factorio

$ ldd bin/x64/factorio

        linux-vdso.so.1 (0x00007ffc123b1000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc182f70000)

        librt.so.1 => /lib64/librt.so.1 (0x00007fc182f6b000)

        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc182f5a000)

        libX11.so.6 => /lib64/libX11.so.6 (0x00007fc182e13000)

        libXext.so.6 => /lib64/libXext.so.6 (0x00007fc182dff000)

        libGL.so.1 => /lib64/libGL.so.1 (0x00007fc182d78000)

        libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007fc182d71000)

        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007fc182d64000)

        libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007fc182d57000)

        libasound.so.2 => /lib64/libasound.so.2 (0x00007fc182c43000)

        libpulse.so.0 => /lib64/libpulse.so.0 (0x00007fc182bf1000)

        libpulse-simple.so.0 => /lib64/libpulse-simple.so.0 (0x00007fc182bea000)

        libm.so.6 => /lib64/libm.so.6 (0x00007fc182b07000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc182b02000)

        libc.so.6 => /lib64/libc.so.6 (0x00007fc182920000)

        /lib64/ld-linux-x86-64.so.2 (0x00007fc182f91000)

        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fc1828f5000)

        libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fc1828c2000)

        libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fc18280a000)

        libXrender.so.1 => /lib64/libXrender.so.1 (0x00007fc1827fc000)

        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007fc1827f4000)

        libpulsecommon-16.1.so => /usr/lib64/pulseaudio/libpulsecommon-16.1.so (0x00007fc18276f000)

        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007fc18271a000)

        libXau.so.6 => /lib64/libXau.so.6 (0x00007fc182714000)

        libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007fc182694000)

        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007fc1825a1000)

        libasyncns.so.0 => /lib64/libasyncns.so.0 (0x00007fc182599000)

        libgsm.so.1 => /lib64/libgsm.so.1 (0x00007fc18258a000)

        libFLAC.so.12 => /lib64/libFLAC.so.12 (0x00007fc182524000)

        libvorbis.so.0 => /lib64/libvorbis.so.0 (0x00007fc1824f5000)

        libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x00007fc182448000)

        libopus.so.0 => /lib64/libopus.so.0 (0x00007fc1823ec000)

        libogg.so.0 => /lib64/libogg.so.0 (0x00007fc1823e2000)

        libmpg123.so.0 => /lib64/libmpg123.so.0 (0x00007fc182385000)

        libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x00007fc18230d000)

        libcap.so.2 => /lib64/libcap.so.2 (0x00007fc182303000)

        liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fc1822df000)

        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc1822ac000)

        libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fc1821f0000)

        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc1821cc000)

이 라이브러리 중에는 각각 Wayland와 PipeWire를 위해 더 이상 사용되지 않는 X11과 PulseAudio가 있습니다. 동적 종속성이 누락되면 게임이 실행되지 않기 때문에 호환성 악몽이 발생합니다. 이것은 분명히 안 될 것입니다!

대부분의 로우레벨 시스템 호출, 오디오, 비디오에 SDL을 사용하고 SDL은 전적으로 런타임 링크에 의존하기 때문에 이러한 종속성의 존재는 저를 혼란스럽게 했습니다. 조사 결과 대부분의 종속성의 출처는 팩토리오의 알파 단계 대부분에 활용했지만 이후 SDL로 대체한 로우레벨 라이브러리인 Allegro인 것으로 밝혀졌습니다. 2.0 버전에서 Allegro의 유일한 용도는 SDL 오디오 백엔드에 문제가 발생할 경우를 대비한 보조 오디오 백엔드로서 사용되었지만, SDL 백엔드는 오랫동안 안정적이었기 때문에 제거할 때가 되었습니다. 이로써 게임에서 123,024줄의 코드가 제거되었고 동적 의존성이 대폭 감소했습니다:

rai@tantal ~/dev/wube/factorio (master)

$ ldd bin/FinalReleasex64Clang/factorio

        linux-vdso.so.1 (0x00007fff96ff2000)

        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd2df8a9000)

        libm.so.6 => /lib64/libm.so.6 (0x00007fd2df7c8000)

        libc.so.6 => /lib64/libc.so.6 (0x00007fd2df5e6000)

        /lib64/ld-linux-x86-64.so.2 (0x00007fd2df8d6000)

클립보드 문제

X11과 연동해야 하는 것은 Allegro뿐만이 아니었습니다. 2017년에 사용자가 큰 블루프린트 문자열을 게임에 붙여넣을 수 없다는 버그 보고를 받았고, Oxyd는 GUI 백엔드의 클립보드 핸들러에 X11 incremental 클립보드 전송 지원을 추가하여 이 문제를 해결했습니다.

SDL에 내장된 클립보드 기능을 활용하고 싶었지만 안타깝게도 SDL은 incremental 전송을 지원하지 않습니다. 따라서 세 가지 옵션이 있습니다:

- X11에 대해 계속 연결하여 사용자가 게임을 실행할 수 있도록 시스템에 X11을 설치해야 합니다(정적 연결을 엉망으로 만들고 싶지 않습니다).

- 런타임 링크를 수행하는 방법을 파악하고 이를 구현합니다.

- incremental 전송 코드를 SDL로 업스트림하여 SDL의 클립보드 기능을 활용하고 다른 SDL 기반 게임에서 우리 작업의 이점을 누릴 수 있도록 합니다.

짐작할 수 있듯이 저는 세 번째 옵션을 선택했습니다. 코드를 업스트림하는 작업은 현재 진행 중이지만 Factorio 2.0의 출시에 맞춰 완료될 예정입니다.

비동기 저장

팩토리오에서 게임이 멈추지 않고 백그라운드에서 저장되는 기능을 지원한다는 사실을 모르는 분들이 많을 것입니다. 이 기능은 숨겨진 설정에 숨겨져 있으며 macOS와 Linux에서만 작동합니다. 이는 플랫폼의 기능을 활용하여 게임을 개선한 좋은 예로, 단순히 Proton을 사용했다면 사용할 수 없었을 기능입니다.

비동기 저장은 포크 시스콜을 사용하여 기본적으로 게임을 복제하는 방식으로 작동합니다. 상호작용하는 기본 인스턴스는 계속 플레이하지만 새로 포크된 자식이 저장 프로세스를 실행하고 완료되면 종료됩니다. 수년 동안 사용해 왔지만 문제가 발생한 적은 없지만 해결되지 않은 몇 가지 문제가 있고 작동하려면 상당한 양의 RAM이 필요하기 때문에 설정이 숨겨진 상태로 남아 있습니다.

2.0에서는 이 기능을 숨겨진 상태에서 벗어나 홍보하고 싶습니다. Linux 또는 macOS에서 플레이하는 경우 비동기 저장(ctrl+alt+클릭 설정 -> "나머지" -> non-blocking-saving)을 활성화하고 발견한 문제를 보고해 주세요. 특히 프로세스 종료 시 발생하는 무작위 크래시 현상을 재현하는 데 관심이 있습니다. 미리 감사드립니다!

지속적인 개발

지금까지는 리눅스용 팩토리오를 최상의 상태로 만들기 위해 제가 해온 작업의 일부에 불과합니다. 아직 미해결 버그와 기타 문제가 많지만, 전반적으로 현재 상황에 만족하며 팩토리오의 리눅스 지원은 훌륭하다고 자신 있게 말할 수 있습니다.

항상 그렇듯이 평소와 같이 피드백이 담긴 텍스트 버퍼를 일반적인 장소에 제출하세요.