▲

Rust를 떠나 Unity로: 게임 개발 방향 전환 이야기

 (deadmoney.gg)
5P by GN⁺ 17시간전 | ★ favorite | 댓글 1개
  • Architect of Ruin 개발팀은 초기에는 Bevy 엔진과 Rust로 개발을 시작했지만, 실용적 문제로 인해 Unity와 C#로 전환함
  • Rust와 Bevy의 장점에도 불구하고, 협업, 고수준 추상화 필요성, 빈번한 API 변화, AI 학습 효율성 저하, 모딩 한계 등이 문제가 됨
  • Unity를 시험 삼아 3가지 핵심 기능을 이식했으며, 3일 만에 성공적으로 검증하고 6주 동안 전체 포팅을 완료함
  • 전환 이후 코드량이 줄고, 개발 속도가 향상되었으며, 생태계 툴 활용까지 가능해져 개발 만족도가 크게 높아짐
  • Rust와 Bevy에 대한 애정은 여전히 크지만, 프로젝트에 필요한 요구사항을 충족시키기 위해 현실적인 선택을 했음을 강조함

Bevy와 Rust에서의 초기 개발

  • Bevy ECS 모델과 Rust 특유의 컴파일 타임 체크를 즐기며 빠른 리팩터링과 안정성을 경험함
  • 타일맵, 스켈레탈 애니메이션, 커스텀 렌더링 파이프라인 등을 Bevy로 직접 구현
  • Bevy 커뮤니티의 열정과 활발한 토론 문화에서 많은 영감을 얻음

Emergent Problems: 예상보다 심각했던 문제들

  • 협업 문제 : Rust 초심자인 팀원에게 Rust의 복잡함이 학습 장벽으로 작용해 기여 속도가 저하됨
  • 고수준 추상화 부족
    • 게임플레이 아이디어를 코드로 빠르게 옮기는 데 어려움이 발생함
    • 빠른 프로토타이핑에 필요한 유연성이 부족했음
  • 빈번한 API 변경 : Bevy의 빠른 발전 속도로 인한 API 불안정성과 업데이트마다 발생하는 회귀 버그에 지침
  • AI 학습 지원 부족 : C#과 Unity는 AI 보조 학습이 잘 되었지만, Rust와 Bevy는 정보가 부족해 생산성 저하를 초래함
  • 모딩 한계 : Rust/Bevy 환경에서 안정적인 스크립팅 및 ABI 호환성 확보가 어렵다고 판단함

전환 결심: Unity 실험

  • Unreal, Unity, Godot, Bevy 유지, 자체 엔진 개발을 비교 분석
  • Unity가 학습성, 생산성, 협업 용이성, 모딩 가능성 측면에서 가장 높은 점수를 받음

10% 실험

  • 타일맵, 캐릭터(Spine), UI 구축 3개 핵심 작업을 3주 이내 테스트
  • 결과적으로 3일 만에 3개 과제를 완료, 전환을 결정함

포팅 과정과 결과

  • 6주간 모든 시스템과 콘텐츠를 Unity로 재구현
  • 코드량 감소, 보일러플레이트 제거, 개발 속도 증가를 경험함
  • AI 학습 지원 향상 및 Unity 생태계 툴(AStar Pathfinding 등) 적극 활용 가능

이후의 삶

  • Architect of Ruin은 현재 Unity 기반으로 개발 중이며, 빠른 아이디어 반영과 높은 생산성을 유지하고 있음
  • Rust와 Bevy에 대한 깊은 존경은 변함 없지만, 프로젝트에 적합한 선택이 필요했음을 강조함
  • 향후 Unity 기반 구현 세부사항과 포팅 경험을 추가 공유할 예정임

결론

  • 시작 시 공정한 옵션 평가 실패를 인정함
  • 시간을 투자해 방향을 바꿨지만, 결과적으로 더 많은 시간을 벌었다고 평가
  • 개발 비전 실현을 위해 본능을 넘어선 현실적 판단이 중요했음을 깨달음
▲
GN⁺ 17시간전  [-]
Hacker News 의견

  • Rust로 게임 프로젝트를 진행하다 실패한 사례가 또 발생함. 이는 안타까운 일임

    • Rust로 메타버스 클라이언트를 거의 5년 동안 개발 중인데, 너무 오래 걸리고 있음
    • 다른 사람은 C#/Unity로 비슷한 프로젝트를 2년 이내에 진행함
    • Rust 3D 게임 개발 사용자 기반이 매우 작음
    • Rust로 AAA 타이틀을 개발한 사례가 없고, 성능 문제를 해결한 사람도 없음
    • 사용 중인 스택은 Rend3/Egui/Winit/Wgpu/Vulkan인데, Vulkan을 제외하고는 버그가 많음
    • 이벤트 루프를 소유하려는 다양한 크레이트가 너무 많음
    • 크레이트가 몇 달마다 리팩토링되어 API가 깨지는 경우가 많음
    • Rust에서 역참조가 어려움
    • Rust는 단일 소유자와 역참조를 위한 일관된 방법이 필요함
    • Rust의 트레잇은 객체가 아니며, 객체 계층 구조를 구성하는 데 적합하지 않음

  • 상업용 게임 엔진이 게임 개발을 장악한 이유에 대한 좋은 교훈처럼 들림

    • 게임을 만들기 위해 해야 할 일이 많지만, 대부분은 이미 해결된 문제임

  • Rust를 C++의 대체로 좋아하지만, 대부분의 프로젝트에 C++이 적합하지 않다고 생각함

    • 많은 사람들이 Rust를 더 효율적이라고 생각해서 선택하는 것 같음

  • Rust 게임 개발은 개척지 개발과 같으며, 많은 작업이 필요함

    • Rust는 아직 준비가 안 되었음

  • Rust를 좋아하지만, 빠른 반복이 어려움

    • Bevy를 사용해봤지만 Godot로 돌아감

  • 프로젝트에서 Rust 대신 Go로 전환했으며, 반복 속도가 더 빨라짐

    • 코드가 더 취약하지만, 프로젝트의 성격상 올바른 선택이라고 생각함

  • Rust 생태계의 높은 변동성은 예상치 못한 단점임

    • 크레이트가 자주 버려지며, 이는 Rust를 주로 사용하고 싶어하는 사람들 때문이라고 생각함

  • 한 개발자는 C로 게임 엔진을 만들고, Lua로 게임을 개발함

    • 게임 엔진과 게임의 명확한 분리가 있음
    • 'Sapiens'라는 게임이 Steam에서 성공적으로 출시됨

  • Rust로 작업하는 것은 거의 항상 더 어려움

    • 이는 개인적인 경험에 기반한 의견임

  • 프로젝트의 목표는 코딩을 하지 않는 형제가 기여할 수 있도록 하는 것이었음

    • 최신 버전으로 계속 업그레이드해야 한다고 느낌
    • Unity를 사용하는 스튜디오는 특정 버그가 수정되지 않는 한 버전을 자주 업그레이드하지 않음
답변달기