브라우저 네이티브 게임이 본격화되고 있다: 오픈소스 전투 프로젝트가 보여주는 것

이 조사를 시작할 때는 흥미로운 브라우저 전투 실험 몇 개 정도를 찾을 것으로 예상했다. 하지만 실제로는 훨씬 더 넓은 생태계가 있었다. 록온 타기팅, 분기형 콤보 트리, 퍼펙트 패링, 회피 무적, 자세 시스템, 공중 공격, 보스의 예고 동작, 모션 워핑, 히트 스톱, 무기끼리의 물리적 충돌, 게임패드 지원, 터치 조작, 결정론적 시뮬레이션까지 갖춘 실제 3인칭 액션 프로토타입들이 존재했다.

중요한 결과는 바로 이것이다. 이제는 단순히 웹페이지 안에서 렌더링되는 작은 게임에 그치지 않는다. 일부 프로젝트는 기존 액션 게임과 같은 공학적 문제를 풀고 있으면서도 URL로 배포되고 곧바로 플레이할 수 있다.

웹 개발자인 내게 특히 흥미로운 부분도 여기에 있다. 예전의 게임은 설치 프로그램, 대용량 다운로드, 패처, 런처가 중심이었고, 게임을 발견한 뒤 실제로 손대기까지 지연이 있었다. 브라우저는 이 경로를 크게 압축한다. 링크를 열고, 에셋을 로드하고, 바로 플레이를 시작하면 된다.

이번 조사는 브라우저에서 플레이 가능한 빌드와 공개 소스 코드를 모두 갖춘 프로젝트에 집중했다. Unity WebGL 내보내기는 의도적으로 제외했다. 단순히 웹으로 내보낸 게임이 아니라 웹 기술을 중심으로 만들어진 게임을 살펴보고 싶었기 때문이다.

가장 인상적이었던 프로젝트들

유용했던 프로젝트들이 모두 같은 이유로 뛰어난 것은 아니었다. 어떤 프로젝트는 콤보 시스템이 가장 깊었고, 다른 프로젝트는 3인칭 아키텍처, 더 깔끔한 전투 시뮬레이션, 혹은 더 설득력 있는 물리적 타격감이 강점이었다.

결과가 예상 밖이었던 이유

놀라웠던 점은 단순히 그래픽이 좋아 보였다는 것이 아니다. 완성도 높은 장면을 렌더링하는 것은 게임 개발의 한 부분일 뿐이다. 눈에 띈 프로젝트들은 입력 버퍼링, 전투 상태 전환, 타깃 선택, 공격 이동, 애니메이션 타이밍, 히트 감지, 적의 반응, 방어 판정 구간, 카메라 동작, 타격 피드백처럼 그럴듯하게 속이기 어려운 시스템을 실제로 구현하고 있었다.

여기서 중요한 구분이 생긴다.

• 애니메이션 타이밍은 전투 타이밍과 같지 않다.
• 렌더링 프레임레이트는 시뮬레이션 레이트와 같지 않다.
• 충돌이 발생했다고 해서 자동으로 유효한 타격이 되는 것은 아니다.
• 애니메이션이 반드시 이동의 권한을 갖는 것은 아니다.
• 시각적인 접촉과 체감되는 충격은 같은 것이 아니다.

이런 구분은 가장 뛰어난 프로젝트들에서 반복해서 나타났고, README에 어떤 렌더러 로고가 있는지보다 더 중요했다.

Voxel Musou: 브라우저 전투에도 실제 기술 문법을 만들 수 있다

Voxel Musou는 브라우저 전투가 더 이상 버튼 하나에 공격 애니메이션 하나를 연결하는 방식에 머물 필요가 없다는 것을 가장 분명하게 보여주는 사례 중 하나였다. 소스는 mike007jd/voxel-musou에서 공개되어 있다.

이 프로젝트는 단순한 선형 콤보 대신 긴 기본 공격 연계와 차지 분기를 사용한다. 아키텍처 측면에서 중요한 이유는 시스템을 다음처럼 모델링할 수 있기 때문이다.

current move + buffered input + combat state -> next move

특수한 조건문을 계속 늘려가는 방식보다 캐릭터 액션 게임의 기반으로 훨씬 낫다. 공중 공격, 특수 시퀀스, 여러 캐릭터의 기술 구성, 보스 행동, 히트 스톱, 대규모 적 무리와의 전투도 보여준다.

더 넓게 적용할 수 있는 공학적 교훈은 기술을 데이터로 만들고 전환을 명시적으로 만들어야 한다는 점이다. 그렇게 되면 새 캐릭터를 추가할 때마다 전투 컨트롤러 전체를 다시 작성할 필요가 없다.

Long Wind: 현대적인 브라우저 액션 게임에 가장 가까운 사례

Long Wind는 3인칭 이동에 약공격과 강공격, 록온, 가드, 퍼펙트 패링, 회피 무적, 자세 압박, 처형, 띄우기와 넉다운 반응, 투사체, 보스, 여러 적 유형을 한데 결합하고 있어 종합적인 참고 자료로 특히 강했다. 소스는 jbang2004/long-wind에서 공개되어 있다.

개별 기능 하나하나가 전례 없어서 가치 있는 것은 아니다. 이 기능들이 하나의 브라우저 네이티브 액션 프로토타입 안에 함께 존재한다는 점이 중요하다. 입력에서 타깃 선택, 공격 상태, 애니메이션, 접촉, 반응, 히트 스톱, 카메라 피드백까지 전체 흐름을 추적하기에 좋은 참고 자료가 된다.

모션 워핑은 웹 데모가 자주 무시하는 문제를 해결한다

Samurai Third-Person Template ThreeJS가 특히 흥미로운 이유는 고전적인 3인칭 근접전 문제를 다루기 때문이다. 소스는 achrefelouafi/SamuraiThirdPersonTemplateThreeJS에서 공개되어 있다.

제작된 공격 애니메이션은 타격이 접촉 프레임에 도달할 때 목표가 특정 거리에 있을 것을 가정한다. 실제 게임에서는 목표가 완벽한 위치에 있는 경우가 거의 없다. 캐릭터가 제자리에서 애니메이션만 재생하면 게임에서는 피해가 적용되더라도 칼이 눈으로 보기에는 빗나갈 수 있다. 반대로 캐릭터를 알맞은 위치로 순간이동시키면 공격이 인위적으로 보인다.

모션 워핑은 더 나은 해법을 제공한다. 공격 중 회전과 이동을 조정해 정확한 순간에 캐릭터가 예상된 접촉 위치에 도달하도록 한다.

중요한 구분은 다음과 같다.

animation intent != movement authority

캐릭터는 제작된 애니메이션의 시각적 의도를 유지하면서도, 실제로 어디로 이동할지는 게임플레이 컨트롤러가 계속 권한을 가질 수 있다.

충돌 감지와 타격 유효성 판정은 서로 다른 문제다

Stick & Steel은 상당히 다른 전투 모델을 실험한다. 소스는 Rabneba/stick-steel에서 공개되어 있다.

검을 주로 피해 볼륨을 가진 애니메이션으로 취급하는 대신, 이 프로젝트는 무기에 물리적인 존재감을 부여한다. 접촉 속도, 무기 방향, 신체 부위, 가드, 무기 충돌, 넉다운, 무장 해제가 모두 중요하다.

가장 다른 프로젝트에도 옮겨 쓰기 쉬운 교훈은 모든 액션 게임이 완전한 물리 기반 무기를 써야 한다는 것이 아니다. 핵심은 이것이다.

충돌은 두 물체가 닿았다는 사실만 알려준다. 그것이 의미 있는 타격이었는지는 알려주지 않는다.

설득력 있는 전투 시스템에는 접촉 속도가 충분했는지, 방향이 맞았는지, 무기의 올바른 부위가 닿았는지, 타이밍이 적절했는지, 대상 상태가 유효했는지를 판단해 피해로 인정할지를 결정하는 두 번째 계층이 필요한 경우가 많다.

전투 판정을 중앙화하면 복잡한 방어를 이해하기 쉬워진다

Hollowmere는 소스가 euuuuuuan/hollowmere-public에 공개되어 있으며, 화려한 시각 효과보다 소프트웨어 아키텍처 측면에서 눈에 띄었다.

전투 시뮬레이션은 렌더링과 분리되어 있고, 방어 판정은 중앙화되어 있다. 이는 회피 시스템, 패링 시스템, 피격 반응 시스템, 애니메이션 계층이 같은 공격의 명중 여부를 각각 다르게 판단하는 액션 게임의 흔한 실패를 피하게 해준다.

더 깔끔한 사고 모델은 다음과 같다.

incoming attack -> evade | parry | hit

렌더러는 결과를 보여줘야지, 전투 판정을 별도의 버전으로 새로 만들어서는 안 된다.

전투가 커질수록 이 구분은 더 중요해진다. 결정론적 시뮬레이션과 명시적 상태 전환은 화려한 기능은 아니지만, 복잡한 전투를 더 쉽게 테스트하고 디버깅하고 확장할 수 있게 한다.

게임 필은 장식이 아니라 공학 시스템이다

Fabled Revolutions는 소스가 ericrius1/FabledRevolutions에 공개되어 있으며, 타격을 묵직하게 느끼게 하는 효과를 분리해서 보여주기 때문에 특히 유용하다.

논리적으로 올바른 전투 시스템도 약하게 느껴질 수 있다. 충돌이 정확하고 올바른 프레임에 피해가 적용되어도, 결과는 여전히 두 모델이 서로를 통과한 것처럼 느껴질 수 있다.

체감되는 충격은 짧게 지속되는 효과 여러 개가 겹치면서 만들어지는 경우가 많다.

• 히트 스톱.
• 카메라 흔들림이나 킥.
• 무기 궤적.
• 충돌 파티클.
• 피격 플래시.
• 넉백.
• 애니메이션 반응.
• 타이밍이 잘 맞는 사운드.

여기서 또 하나의 유용한 구분이 나온다. 전투의 정확성과 전투의 손맛은 같은 것이 아니다. 브라우저 게임에는 둘 다 필요하다.

전투 품질을 가늠하는 핵심 지표는 렌더러가 아니었다

조사에서 나타난 흥미로운 패턴 중 하나는, 최고의 전투가 최신 렌더링 API를 사용했는지 여부로 결정되지 않았다는 점이다.

Three.js는 여러 차례 등장했다. 어떤 프로젝트는 WebGPU 관련 렌더링 기술을 사용했고, 다른 프로젝트는 기존 WebGL 기반 스택을 사용했다. 물리 엔진, TypeScript, JavaScript, Vite, WebAssembly, 다양한 렌더링 방식이 조사 전반에 걸쳐 등장했다.

하지만 정교한 전투는 더 일관되게 아키텍처에 의존했다. 고정 스텝 시뮬레이션, 명시적 상태, 신뢰할 수 있는 타기팅, 합리적인 애니메이션 제어 권한, 데이터 기반 기술, 중앙화된 피해 판정, 좋은 타격 피드백이 더 중요했다.

웹 개발자에게는 고무적인 결과다. 모든 사용자가 최신 그래픽 스택을 쓰게 될 때까지 기다리지 않아도 본격적인 전투 설계를 실험할 수 있다.

브라우저 배포가 조건을 바꾸는 이유

브라우저에는 그래픽과 거의 관계없는 장점이 있다. 배포 마찰이 매우 낮다는 점이다.

기존 게임은 발견에서 상호작용까지 여러 단계를 두는 경우가 많다. 스토어 페이지를 찾고, 큰 패키지를 다운로드하고, 설치하고, 실행하고, 업데이트를 기다리고, 때로는 의미 있는 플레이에 도달하기 전에 계정까지 만들어야 한다.

브라우저 게임은 그 경로를 링크 하나로 줄일 수 있다.

이는 프로토타입을 공유하고 테스트하는 방식을 바꾼다. 개발자는 빌드를 게시하고 URL을 보내 상대가 즉시 같은 버전을 실행하게 할 수 있으며, 피드백을 받은 뒤 테스터에게 새 패키지를 수동으로 설치하라고 요구하지 않고 다음 반복 버전을 배포할 수 있다.

이 장점은 실험적인 게임과 인디 개발에서 특히 중요해진다. 브라우저는 단순한 런타임이 아니라 배포 시스템이기도 하다.

브라우저가 여전히 밀리는 부분

이번 조사로 브라우저가 네이티브 게임 플랫폼을 대체했다고 확신하게 된 것은 아니다. 실제로 대체하지 못했다.

중요한 제약은 여전히 남아 있다.

• 대용량 에셋 페이로드.초기 다운로드가 매우 크면 즉시 접근이라는 장점도 더 이상 즉각적으로 느껴지지 않는다.
• 메모리 압박.브라우저는 다른 탭과 운영체제와 함께 동작해야 하며, 메모리 동작은 전용 네이티브 프로세스보다 예측하기 어렵다.
• 모바일 발열 한계.기술적으로 동작하는 3D 게임도 긴 세션에서는 심하게 스로틀링될 수 있다.
• 브라우저 차이.그래픽, 오디오, 포인터 락, 전체 화면 동작, 컨트롤러, 성능 특성이 완전히 동일하지 않다.
• 셰이더와 에셋 준비.파이프라인을 신중하게 설계하지 않으면 컴파일이나 업로드 작업 때문에 눈에 보이는 멈춤이 생길 수 있다.
• 오프라인 및 로컬 영속성 제약.대규모 로컬 설치와 파일은 네이티브 애플리케이션이 더 직접적으로 제어할 수 있다.
• 경쟁형 게임의 보안.클라이언트가 웹 애플리케이션이면 본격적인 안티치트와 적대적 클라이언트를 전제로 한 설계가 훨씬 어려워진다.

이 제약들이 중요한 이유는 오늘날 브라우저 게임이 가장 강한 영역을 규정하기 때문이다. 즉시 접근, 빠른 반복 개발, 크로스플랫폼 배포, 관리 가능한 에셋 및 런타임 예산의 이점을 크게 받는 게임이 여기에 해당한다.

AI는 프로토타입에서 URL까지의 루프를 크게 줄인다

여기서 AI가 중요한 이유는 문장 하나를 마법처럼 완성도 높은 게임으로 바꿔주기 때문이 아니다. 더 현실적인 장점은 반복 개발 속도다.

현대 게임 개발에는 각각은 작지만 합치면 비용이 큰 작업이 많다. 상태 머신 설정, 디버그 뷰 제작, 테스트 작성, 적 행동 실험, 기술용 데이터 형식 설계, 입력 코드 리팩터링, 셰이더 프로토타이핑, 물리 버그 조사, 임시 콘텐츠 연결 등이 그렇다.

AI는 이런 루프의 상당수를 줄일 수 있다. 웹 배포와 결합하면 작업 흐름은 유난히 직접적이 된다.

idea -> prototype -> deploy -> open URL -> test -> iterate

브라우저는 이미 배포를 빠르게 만든다. AI는 같은 루프의 구현 측면도 더 빠르게 만들 수 있다.

중요한 단서는 빠른 생성이 감각이나 검증을 대체하지는 않는다는 점이다. 생성된 전투 컨트롤러가 구조적으로 잘못될 수 있다. 애니메이션 타이밍에는 여전히 사람의 판단이 필요하다. 물리는 여전히 디버깅해야 하고, 성능도 측정해야 한다. AI는 아이디어를 시도하는 비용을 낮출 뿐, 어떤 아이디어가 좋은지 결정해야 할 필요를 없애지는 않는다.

이것이 웹 개발자에게 의미하는 것

웹 개발과 게임 개발의 경계는 점점 덜 경직되고 있다.

이제 본격적인 브라우저 게임은 익숙한 웹 도구를 사용하면서도 전통적인 게임 엔지니어링 개념을 요구할 수 있다.

• 고정 시뮬레이션 스텝.
• 상태 머신.
• 입력 버퍼링.
• 애니메이션 그래프.
• 공간 쿼리.
• 물리.
• 프레임 예산.
• GPU 리소스 관리.
• 오디오 타이밍.
• 결정론적 시스템.

동시에 브라우저를 대상으로 하는 게임 개발자는 웹이 이미 매우 잘하는 것도 얻는다. URL, 즉시 배포, CDN 전달, 빠른 업데이트, 텔레메트리, 계정 시스템, 반응형 인터페이스, 마찰 없는 공유가 그것이다.

이번 조사는 내 관점도 바꿨다. 이제 브라우저 게임을 네이티브 게임의 단순화된 버전으로만 보지 않는다. 브라우저는 즉시 배포, 빠른 반복 개발, 점점 더 본격화되는 3D 기능, 방대한 기존 개발 생태계라는 서로 다른 강점을 가진, 계속 역량이 커지는 게임 플랫폼으로 보인다.

웹은 다른 곳에서 만들어진 게임을 표시하는 데만 더 능숙해지는 것이 아니다. 점점 더 본격적인 게임 시스템을 직접 설계하고, 구현하고, 테스트하고, 배포하고, 플레이할 수 있는 공간이 되고 있다.