Warcraft 1, 2, StarCraft 모두 2의 거듭제곱 단위 맵 크기를 사용했음
덕분에 느린 386/486 CPU에서도 나눗셈·곱셈 대신 시프트 연산으로 속도를 확보할 수 있었음
맵 렌더링, 스프라이트, 폰트, 안개 효과 등은 수천 줄의 어셈블리로 처리했고, 나머지는 C로 작성된 이식성 높은 코드였음
Blackthorne의 경우 SNES, Genesis, DOS 버전이 각각 다른 어셈블리로 수작업 포팅되었고, PC 버전은 VGA Mode X를 위해 10만 줄의 렌더링 코드를 매크로로 생성했음
이런 경험 덕분에 Blizzard에서는 “어셈블리는 너무 많은 개발 시간을 잡아먹는다”는 교훈을 얻었음
Comanche: Maximum Overkill은 전부 어셈블리로 작성된 보텍스 기반 헬기 시뮬레이터였는데, 보호 모드로 포팅이 너무 힘들어 이후 버전부터 폴리곤 렌더링으로 전환했음
Reddit 사용자가 StarCraft 골드 마스터 소스코드를 발견했지만, Blizzard 굿즈와 교환하며 반환한 게 아쉬움
EA는 Command & Conquer 시리즈 소스코드를 공개했는데, Tiberian Sun과 Red Alert 2는 빠져 있었음
StarCraft도 역사 보존 차원에서 공개되었으면 좋았을 것 같음
어릴 적 Comanche와 Settlers 1을 처음 봤을 때 DOS 텍스트 모드에서 그래픽이 나오는 게 마법 같았음
그때부터 게임에 완전히 빠져들었음
혹시 Lost Vikings에도 참여했다면, 어린 시절의 즐거움을 줘서 고맙다는 말을 전하고 싶음
혹시 데모씬(demoscene) 활동도 했는지 궁금함
Blizzard에 있을 때 소스코드 서버를 잃어버리고 백업도 없던 사건이 있었는데, 그 시기에 있었는지 궁금함
나는 WC3 출시 즈음 컨설턴트로 잠시 있었음
Maximum Overkill은 정말 수백 시간을 플레이할 만큼 놀라운 게임이었음
글에서 언급된 것처럼, 디자이너와 프로그래머가 동일인일 때 훨씬 인상적인 결과물이 나오는 것 같음
대기업의 계층적 구조로도 결국은 인력으로 밀어붙이면 뭔가 나오긴 하지만, 진짜 창의적인 결과는 한 사람의 머리에서부터 완성되는 경우가 많음 AI 개발 도구의 미래도 이런 ‘1인 개발 시대’로 회귀할지도 모른다는 생각이 듦
게임 디자이너도 여전히 수치적 특성을 고려해야 함
좋은 디자이너일수록 연산 효율이나 정밀도 같은 요소가 게임 밸런스에 영향을 준다는 걸 알고 있음
요즘은 이런 걸 무시하는 개발자도 많지만, 그게 게임 품질 저하의 숨은 원인이 되기도 함
예전엔 나도 이런 미세 최적화가 중요하다고 생각했지만, 현대 CPU의 파이프라인 구조를 공부하고 생각이 바뀌었음
지금은 덧셈 1사이클, 곱셈 3사이클, 나눗셈 12사이클 수준이고, 동시에 여러 연산을 병렬로 처리함
예전 펜티엄 시절엔 46사이클이 걸렸고 클럭도 100MHz였음
지금은 메모리 레이아웃이 훨씬 중요함 — 캐시 미스 한 번이면 100~1000사이클이 날아감
int[]로 연산하는 게 Monster[]보다 훨씬 빠름
나는 csgrs CAD 커널을 개발 중인데, 숫자 계산은 아직도 풀리지 않은 문제라고 느낌
속도, 정확도, 저장 크기, 복잡도 사이의 트레이드오프가 존재함 Toward an API for the Real Numbers 같은 논문은 이런 문제를 단계적으로 해결하려는 접근을 제시함
부동소수점 오차, 구간 산술, 심볼릭 연산 등 다양한 방법이 있지만, 결국 트레이드오프를 이해하지 못하면 문제에 물림
상업 게임은 대량 생산되는 제품이므로, 디자이너가 기술적 제약을 이해하는 건 산업 디자인 감각으로서 큰 장점임
예를 들어 Fumito Ueda는 『Shadow of the Colossus』에서 기술적 실현 가능성을 세심히 고려했고, Doom도 창의성과 기술의 결합이었음 관련 인터뷰 참고
게임 품질은 단순히 효율적인 런타임 성능이 아니라 재미와 완성도의 문제임
버그, 스토리 일관성, 몰입감이 더 중요함
물론 프레임 드랍이 심하면 품질 저하지만, 타깃 하드웨어에서 부드럽게 돌아간다면 개선은 다른 부분에 집중해야 함
ARM Cortex-M4 기반 제품을 개발할 때 커스텀 난수 생성기를 만들었음
Thumb-2 명령어로 상수를 즉시 로드할 수 있게 조정해 메모리 스톨을 피했음
덕분에 빠르고 효율적으로 난수를 사용할 수 있었고, 테스트도 모두 통과했음
하지만 나중에 Cortex-M0로 바뀌면서 이 코드는 폐기되었음
기술적 제약을 게임플레이 요소로 전환하는 부분이 흥미로웠음
『젤다의 전설』의 Blood Moon 시스템이 떠오름
“/8 대신 >>3을 쓰면 나눗셈을 절약할 수 있다”는 설명은 현대 컴파일러에서는 사실이 아님
타입이 맞다면 컴파일러가 자동으로 시프트 연산으로 최적화함
단, 부호 있는 정수(signed) 의 경우는 C 표준의 반올림 규칙을 맞추기 위해 추가 연산이 들어감
“이진수에서 왼쪽 시프트는 두 배가 된다”는 설명을 보고 놀랐음
2026년에 이런 기본 개념이 새삼스러울 정도로 낯설게 느껴지는 게 신기함
Hacker News 의견들
Warcraft 1, 2, StarCraft 모두 2의 거듭제곱 단위 맵 크기를 사용했음
덕분에 느린 386/486 CPU에서도 나눗셈·곱셈 대신 시프트 연산으로 속도를 확보할 수 있었음
맵 렌더링, 스프라이트, 폰트, 안개 효과 등은 수천 줄의 어셈블리로 처리했고, 나머지는 C로 작성된 이식성 높은 코드였음
Blackthorne의 경우 SNES, Genesis, DOS 버전이 각각 다른 어셈블리로 수작업 포팅되었고, PC 버전은 VGA Mode X를 위해 10만 줄의 렌더링 코드를 매크로로 생성했음
이런 경험 덕분에 Blizzard에서는 “어셈블리는 너무 많은 개발 시간을 잡아먹는다”는 교훈을 얻었음
Comanche: Maximum Overkill은 전부 어셈블리로 작성된 보텍스 기반 헬기 시뮬레이터였는데, 보호 모드로 포팅이 너무 힘들어 이후 버전부터 폴리곤 렌더링으로 전환했음
EA는 Command & Conquer 시리즈 소스코드를 공개했는데, Tiberian Sun과 Red Alert 2는 빠져 있었음
StarCraft도 역사 보존 차원에서 공개되었으면 좋았을 것 같음
그때부터 게임에 완전히 빠져들었음
혹시 데모씬(demoscene) 활동도 했는지 궁금함
나는 WC3 출시 즈음 컨설턴트로 잠시 있었음
글에서 언급된 것처럼, 디자이너와 프로그래머가 동일인일 때 훨씬 인상적인 결과물이 나오는 것 같음
대기업의 계층적 구조로도 결국은 인력으로 밀어붙이면 뭔가 나오긴 하지만, 진짜 창의적인 결과는 한 사람의 머리에서부터 완성되는 경우가 많음
AI 개발 도구의 미래도 이런 ‘1인 개발 시대’로 회귀할지도 모른다는 생각이 듦
게임 디자이너도 여전히 수치적 특성을 고려해야 함
좋은 디자이너일수록 연산 효율이나 정밀도 같은 요소가 게임 밸런스에 영향을 준다는 걸 알고 있음
요즘은 이런 걸 무시하는 개발자도 많지만, 그게 게임 품질 저하의 숨은 원인이 되기도 함
지금은 덧셈 1사이클, 곱셈 3사이클, 나눗셈 12사이클 수준이고, 동시에 여러 연산을 병렬로 처리함
예전 펜티엄 시절엔 46사이클이 걸렸고 클럭도 100MHz였음
지금은 메모리 레이아웃이 훨씬 중요함 — 캐시 미스 한 번이면 100~1000사이클이 날아감
int[]로 연산하는 게 Monster[]보다 훨씬 빠름
속도, 정확도, 저장 크기, 복잡도 사이의 트레이드오프가 존재함
Toward an API for the Real Numbers 같은 논문은 이런 문제를 단계적으로 해결하려는 접근을 제시함
부동소수점 오차, 구간 산술, 심볼릭 연산 등 다양한 방법이 있지만, 결국 트레이드오프를 이해하지 못하면 문제에 물림
예를 들어 Fumito Ueda는 『Shadow of the Colossus』에서 기술적 실현 가능성을 세심히 고려했고, Doom도 창의성과 기술의 결합이었음
관련 인터뷰 참고
버그, 스토리 일관성, 몰입감이 더 중요함
물론 프레임 드랍이 심하면 품질 저하지만, 타깃 하드웨어에서 부드럽게 돌아간다면 개선은 다른 부분에 집중해야 함
Thumb-2 명령어로 상수를 즉시 로드할 수 있게 조정해 메모리 스톨을 피했음
덕분에 빠르고 효율적으로 난수를 사용할 수 있었고, 테스트도 모두 통과했음
하지만 나중에 Cortex-M0로 바뀌면서 이 코드는 폐기되었음
기술적 제약을 게임플레이 요소로 전환하는 부분이 흥미로웠음
『젤다의 전설』의 Blood Moon 시스템이 떠오름
“/8 대신 >>3을 쓰면 나눗셈을 절약할 수 있다”는 설명은 현대 컴파일러에서는 사실이 아님
타입이 맞다면 컴파일러가 자동으로 시프트 연산으로 최적화함
“이진수에서 왼쪽 시프트는 두 배가 된다”는 설명을 보고 놀랐음
2026년에 이런 기본 개념이 새삼스러울 정도로 낯설게 느껴지는 게 신기함
“컴파일러가 2의 거듭제곱 곱셈을 시프트로 바꾸지 않는다”는 말은 오래된 농담임
2000년대에도 이미 컴파일러가 그런 코드를 보면 하품할 정도로 당연히 최적화함
재미있게 읽었음. RCT 관련해서는 아래 자료들도 추천함
대형 스튜디오에서 기술적 제약을 게임의 특징으로 승화시키는 게 가능한지 궁금함
스토리텔링에서도 장애물이 이야기를 흥미롭게 만들듯, 1인 개발자는 기술적 한계를 창의적 요소로 전환할 수 있음
예를 들어 버그나 글리치를 미니게임으로 재해석하는 식의 접근이 떠오름
RCT의 경로 탐색(pathfinding) 부분을 보며 Marcel Vos의 유튜브 영상이 생각났음
그는 RCT의 내부 동작을 깊이 파헤치는 영상들을 많이 올림