HAL 연구소 직원이던 당시(24세) 명함 한장 달랑 들고 닌텐도 패미컴 서드파티가 되기 위해 무작정 찾아감.
아타리의 '자우스트'라는 게임을 패미컴으로 이식가능한 소스코드를 짜오라고 일을 받음.
이와타 사토루 : ㅇㅋ 2개월 안으로 해옴.
닌텐도 : (....2개월만에 되겠니?)
하지만 이와타 사토루는 해냈다.
닌텐도의 고참 엔지니어마저 놀랄 정도의 성과였다.
사실 이와타 사토루는 HAL연구소 아르바이트 시절 비슷한 작업을 해 본적이 있었다.
남코의 아케이드 게임 ‘갤럭시안(Galaxian, 1979)’을
허가 없이 코모도어 PC로 이식해 ‘스타 배틀(Star Battle, 1981)’이라는 이름으로 내놓았던 것이다. (물론 나중에 남코의 라이선스를 받긴 했다)
<자우스트(Joust, 1982). '벌룬 파이트'의 원형으로 꼽히는 게임>
이 후 이런저런 닌텐도의 일거리를 맡으며 직원이 10명도 안되던 HAL 연구소는 닌텐도의 핵심 서드파티 회사로 급성장했다.
-----------------------------------------------------------------------------------------------------------
닌텐도 : (서드파티들에게) 얘들아, 우리 골프게임좀 만들자 누가 만들래.
서드파티 : .....ㅈㅅ 넘 어려움..
골프라는 스포츠는 18홀을 돌며 공을 친 횟수, 풍향, 공이 날아간 거리 등을 모두 계산해야 하는데
‘패미컴’의 성능으로는 완전한 골프 게임을 만들기가 쉽지 않다는 이유였다.
이와타 사토루(HAL연구소) : 우리가 함.
막상 이와타 사토루도 개발을 시작하니 생각보다 많은 시행착오를 겪어야 했다
가장 큰 골칫거리는 게임의 용량 그 자체였다.
이와타는 스스로 데이터 압축 기법까지 만들어 가며 18홀의 코스 데이터를 패미컴 롬 카트리지 하나에 쑤셔 넣는데 성공했다.
패미컴 ‘골프’는 240만장 이상이 꾸준히 팔려 나가며 일본에서 가장 잘 팔린 스포츠 게임으로 등극했다.
어지간한 회사도 손을 내젓던 패미컴용 ‘골프’ 게임 개발을 이와타 사토루가 시원하게 해결하자
닌텐도 내에서도 이와타 사토루는 명성을 날리기 시작했다
닌텐도 연구개발진이 골머리를 썩이던 프로그래밍 문제를 뚝딱 해결하거나,
자신이 파악하고 있던 ‘패미컴’ CPU 관련 테크닉을 역으로(!) 닌텐도에 알려주기도 했다.
-----------------------------------------------------------------------------------------
닌텐도는 아타리의 자우스트라는 게임을 기반으로 벌룬파이트라는 게임을 만들기 시작했다.
아케이드와 패미컴 용 개발이 거의 동시에 진행되었다.
아케이드 버전은 SRD가 담당했고, 패밀리 컴퓨터 버전은 이와타 사토루가 맡았다.
SRD는 1979년 설립 이후 이런 저런 게임 제작 및 이식을 해 온 만만치 않은 실력의 회사였다.
완성된 ‘벌룬 파이트’는 더욱 놀라웠다.
‘벌룬 파이트’ 아케이드 버전이 1984년 11월,
패미컴 버전이 1985년 1월 말 출시되었는데
아케이드 버전보다 패미컴 버전의 화면 움직임이 더 부드러웠다.
상식에 비추어 보면 오히려 아케이드 게임을 하드웨어 성능의 제약이 심한
패미컴으로 이식했을 때 그래픽이나 음악 등 많은 부분을 깎아내야 했다.
닌텐도와 SRD 모두 깜짝 놀랐다.
이와타 사토루의 노하우를 배우러 SRD에서 ‘벌룬 파이트’를 담당했던 나카고 토시히코가 직접 찾아왔다.
물론 이와타는 친절하게 자신의 기술을 전수해 주었다.
--------------------------------------------------------
패미컴 마더2 개발 중..(4년째 개발중인데 진척이 없음)
이와타 사토루 : 지금까지 하던대로 하면 2년. 내 말대로 처음부터 하면 6개월.
이토이 시게사토(마더 기획) : 그게 되겠니?...
그런데 그것이 실제로 일어났다.
이와타 사토루는 1개월만에 맵을 스크롤 하는 기본적인 기능을 짜 왔는데 단지 그것 만으로도 ‘마더2’ 팀이 모두 놀랐다.
그래픽도, 시나리오도, 사운드도 어느 정도 갖춰져 있었지만 프로그래머의 탈주로 프로젝트가 몽땅 꼬여 있었는데,
이와타 사토루는 그걸 하나하나 풀어 가기 시작하고 있었다.
이 정도는 시작에 불과했다.
이와타 사토루가 ‘마더2’를 살릴 수 있었던 가장 큰 이유는 혼자 프로그래밍을 모두 떠맡아 했기 때문이 아니라,
개발자들이 다 함께 ‘마더2’ 개발에 참여할 수 있도록 개발 환경을 조정했기 때문이다.
이메일로 각자의 개발 진행 상황을 공유하고, 수정할 필요가 있으면 바로 네트워크에서 수정해 공유하도록 시스템을 구성했다.
이와타 사토루의 호언장담 그대로 4년간 표류하던 ‘마더2’는 그의 개입 후 단 6개월만에 전체적인 게임의 틀이 완성되었다.
-----------------------------------------------------------------------------------
게임프리크 ( 포켓몬 금/은 개발중..당시 프로그래머 4명)
닌텐도 사장 : 얘들아 금/은 개발중이니? 적/녹 해외판도 만들어.
게임프리크(당시 프로그래머 4명..그마저 금/은 개발중) : 앙 다메다메......젯타이 무리데스.............
이와타 사토루 : 적/녹 현지화를 위한 게임 분석 완료. 코드 분석 완료. 내 말대로 하라.
그렇게 적/녹 해외판이 만들어졌다.
포켓몬 적/녹의 코드는 어셈블리어였다.
또 이와타 사토루는 혼자서 적/녹의 코드를 분석 후 C언어로 재작성해 닌텐도64로 재이식하였다.
포켓몬 스타디움 개발 당시 닌텐도64의 미국산 그래픽 처리 칩을 닌텐도 직원들이 다루기 어려워 해서
이와타는 직접 미국으로 건너가 그래칙 최적화 코드를 짜 닌텐도에 건내주었다.
이시하라 츠네카즈 : 얘들아 금/은에 관동지방도 넣어라.
게임프리크(당시에도 용량 부족으로 허덕이던 중 ) : 앙 다메요....젯타이 무ㄹ..........
이와타 사토루 : 여기 데이터 압축 도구를 한번 만들어 봤어.
그렇게 포켓몬 금/은에는 관동지방이 들어갈 수 있게 되었다.
---------------------------------------------------------------------------------------------
이번엔 용량도 성능도 있어도 반갈죽
그리고 마더2에는 복돌이를 엿먹이는 기능이 들어갔지
이 아조씨가 지금의 소드실드를 봤으면 무슨생각을했을까
진짜 천재라 그런 꼴 보기전에 영면하심
사토루: 뭐? 플스2급 그래픽 3년동안 만들었는데 포켓몬이 반이 줄었다고??? 개발기간동안 딸친거냐?
직접!
최종보스전 막타치기 직전에 세이브를 날려버린다는 전설의...
포켓몬대신 개발팀의 60%를 반갈죽
그는 게임계의 신이었습니다 ▶◀
프로그래머는 안된다는말을 하면 안된다고 했다더라 무서운사람
저 당시의 이식이라는건 요즘 처럼 여러 소스는 동일하게 쓰고 엔진만 수정하는게 아닌 크레파스를 던져주고 유화 그림을 베껴 그리라는 그런 식임. 근데 그걸 뚝딱 뚝딱 해냈으니 레알 천재인거.........
어케한거옄ㅋㅋ
이번엔 용량도 성능도 있어도 반갈죽
게임프릭 ㅈ밥세퀴들이였네
원래부터 기술도 능력도 없는애들이었어
기술력으론 좁밥 맞음
가진 기술력에 비해 ip가 너무 잘팔렸는데, 돈방석에 앉고도 기술력에 투자를 ㅈ도 안한 적폐 게임회사 인디게임 제작사 제외하면 게임프릭보다 개발, 기술력 딸리는 게임회사 없을거임 ㄹㅇ
이 아조씨가 지금의 소드실드를 봤으면 무슨생각을했을까
액숀구리
진짜 천재라 그런 꼴 보기전에 영면하심
빡쳐서 욕했겠지
액숀구리
사토루: 뭐? 플스2급 그래픽 3년동안 만들었는데 포켓몬이 반이 줄었다고??? 개발기간동안 딸친거냐?
골프채가져와
액숀구리
포켓몬대신 개발팀의 60%를 반갈죽
역시 천재
잡스가 아이폰 11보는 기분
살아있었으면 애초에 그딴 물건이 안나왔음
이 ㅂㅅ들은 개발기간덩안 뭐한거지? 했겠지
그아저씨 능력과 성향을 생각하면.. 절대 그럴것 같진 않고.. 어떻게든 좋은 작품이 나올만한 분위기를 조성해주지 않았을까?
그는 게임계의 신이었습니다 ▶◀
성도지방에 관동추가가 됬다는걸 알았을때 온몸에 소름돋았었자
제노블레이드시리즈와 모노리스를 우리에게 남겨주셨죠ㅠㅠ
최적화의 신이네
폐인킬러
프로그래머는 안된다는말을 하면 안된다고 했다더라 무서운사람
안된다는 말을 하면 안된다라..결국 안된다는 말을 하고 말앗군..
그리고 마더2에는 복돌이를 엿먹이는 기능이 들어갔지
누구...
최종보스전 막타치기 직전에 세이브를 날려버린다는 전설의...
하하 그땐 젊었지
직접!
쵸쿠세츠!
저랬던 포켓몬이 바로 반갈죽ㅋㅋ 시1발놈들아 가관이마
저 벌룬파이트는 아이스클라이머와 쌍벽을 이루는 우정파괴겜이다
동물의 숲 아이디어 찬성한것도 이분이라던데
진짜 천재...
솔직히 게임 프로그래머로썬 이 사람과 나샤 지벨리라는 투탑 천재가 레전드지 나샤 지벨리는 게임 전체를 하드웨어의 버그로 제조해서 이식을 불가능하게 하는 대신 시스템으로 구현 불가능한 걸 억지로 잔뜩 쑤셔넣은 천재임
다만 나샤 지벨리는 자신의 노하우를 다른 사람에게 가르쳐주지는 않았지 대단한 사람이긴 했는데 그것이 그의 한계였나봐
그 밑 단계라면 소닉팀의 나카 유지라던가 있긴 함. 근데 뭐 이와타 사토루랑 비비면.....
파판 개발자?
난 크리스 소이어도 만만치않은거같던데
파이널 판타지 패미컴 시절의 개발자 당시 패미컴이라는 하드웨어로썬 불가능한 동작을 구현해낸 천재 프로그래머 다만 그가 구현해낸걸 어떻게 구현해냈는지를 다른 사람들에게 알려주지 않아서 파이널 판타지 초기작들의 이식이 어려웠다고 해
그럼 다른 사람이 짜논 코드를 해부 분석하는거 되게 빡셈?
자기가 짠것도 주석없으면 해석 정말 어려워 프로그램 리버스 엔지니어링 가능하면 상당한 실력의 고수야
다른사람 소스코드 구조는 설명이 없으면 유지보수가 어려워 당장 내 소스도 석달 지나면 까먹는데 뭘... 그리고 옛날에는 다른 개발자들이 알아먹기 어렵게 짰다더라 요즘 소스들은 다른 개발자들이 알기 쉬운 구조로 짜는데...
에이 석달씩이나... 보름이면 쌉가능ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ ㅠㅠ
루리웹-1664351404
그건 현대식 일반 소스 코드고요 저 시절에는 메모리도 운영장치도 작았기 때문에 내부에 소스코드를 전부 넣지 않고 어셈블리식 직접 처리, 기계어 비트 처리를 전부 때려박아서 했어요. 나카 유지가 짜고 까먹은 소닉의 물리엔진 코드 해독에 괜히 4년이나 걸린 게 아님.
3는 어려운 정도가 아니라 이식이 아예..
루리웹-1664351404
슈퍼마리오의 물리엔진 처리에 들어가는 소스코드가 4kbit인가 그래요. 소닉은 16비트 중에 4비트+보수 1비트를 물리엔진 처리에 할당하는데, 이 소스 코드를 넣을 곳이 없어서 스프라이트의 등록순서와 이름, 관계를 이용해서 차리한 부분이 많다고 합니다, 포켓몬의 경우 일부 사용하지 않고 다른 창으로 링크해주는 아이템의 설명란에 스프라이트 연산 코드를 쑤셔넣은 경우도 있어요.?
저 시대의 코드는 특히 말도 안 되는 용량에 소스코드를 박아야 해서, 같은 종이에 3색 볼펜으로 다른 이야기를 사로 다른 색으로 매번 다르게 적어넣은 다음 그걸 흑백복사한 걸 해석하라 수준의 문제입니다. 드럽게 어려워요....
룰웹에서 존 카멕이 너무 취급이 안좋음... 게임프로그래머로써의 천재를 논할땐 카멕도 빼면 안됨..
"게임"프로그래머 로는 천재 까진 아닌데 "엔진"프로그래머 로 천재.
루리웹-1664351404
도대체 무슨 소리를 하는 지 전혀 모르겠네요.... 유지 보수를 고려하지 않는 시대 게임에 무슨 유지 보수입니까, 기계 단위 프로그래밍을 한번도 안 건드려보신 거 같은데, 어셈블리어보다 하위로 작성된 언어는 말씀하시는 것처럼 작동 안 합니다. 애플 2만 건드려봐도, 운영체제의 최적화를 위해서 강제로 허프만 압축된 코드가 산더미에요. Mc16과 모킹버드만 해도 기존 os에 강제개입하는 부분이 다르고요.
루리웹-1664351404
필요한 부분을 읽고 어쩌고는 전부 고급 프로그래밍 언어, 최소 c언어 이후 단계의 이야기에요: 모듈화도 이루어지지 않은/그럴 수도 없던 시절을 이야기하는데, 말씀하시는 양산 코더들이 존재할 수 있는 통합개발 이후, 적어도 롤랜드 c 이후의 개발과 그 이전의 개발은 얼개부터 다를 수밖에 없습니다.
루리웹-1664351404
게임계에서 실제 통합개발툴이 사용된 건 세가는 드림캐스트 이후, 소니는 ps1 후반부, 닌텐도는 게임큐브부터입니다, 그 이전엔 이식을 하려고 해도 철저하게 머신마다 사용하는 연산이 달라서 불가능했어요. 오죽하면, 버쳘온 개발 이후에 제안서와 프로그램 스킴이 실수로 파기돼서, 아케이드판을 새턴으로 이식할 때 모델링 데이타어ㅏ 모션 데이타 이외를 아케이드판을 굴려가면서 짠 게 괜히 일어나겠습니까.
루리웹-1664351404
모듈화야 처음 짜는 단계엔 존재하죠. 그걸 실행단까지 모듈인 채로 보존 가능하게 짜게 된 건 굉장히 최근입니다. 실제 실행 프로그램 단계에서는 모듈이 파편화되어서, 해석하는 게 엄청나게 어려워요. 혹시 이런 오래된 프로그램의 샐비지나 리프로그래밍 안 해 보셨나요? 설마 이런 프로그램이 실행단에서도 개발처럼 모듈이 딱딱 남아서 굴러갈 거라고 생각하신다면, 멀리 가지 마시고 애플 2 어셈블리 모듈 가상머신은 쉽게 구할 수 있으니 구해서 테스트해 보세요. 절대 그렇게 안 돌아갑니다, 저런 파편화된 프로그램을 재조합하는 건, 흰 종이에 검은 펜으로 한 번, 빨간 펜으로 한 번, 파란 펜으로 한 번 모두 3번 다른 텍스트를 적고, 이 종이를 흑백카피한 뒤 16등분해서 랜덤하게 재조립한 물건을 보고, 원본 텍스트를 조합하는 것만큼 어렵습니다. 원 제작자도 천재지만? 해석자도 상당히 천재여야 가능해요.
루리웹-1664351404
애플 2 베이직 해보셨다면, 애플 2에서 모킹버드가 어떻게 작동하는지 모르실 리가 없으실 텐데요?
루리웹-1664351404
1980년대에 실제로 개발을 해보셨습니까? 1990년대에 실제로 현역으로 개발을 해보셨는지요? 저도 못해봤습니다. 하지만 저의 작은아버지는 당시에 현역 프로그래머여서 제가 프로그래밍 배울때 작은아버지에게 이야기를 당시의 프로그래밍에 대해 많이 배웠습니다. 딱 잘라 말할게요. 가독성과 설계를 우선으로 잘 짜여진 시스템을 최우선으로 프로그래밍 하려면 디바이스의 성능이 받쳐줘야 가능합니다. 당장 2000년에 제가 프로그래밍을 배워서 2004년에 KFX F/A-50 전투기 개발에 참여할 당시만 해도 디바이스 성능이 받쳐주지 않아서 성능최적화 관련 코드가 들어가야했습니다. 성능최적화를 하다보면 요즘이야 그래도 아름다운 코드가 만들어지면서 최적화가 되죠. 옛날에는 어땠는지 아세요? if문 안쓰고 3항 연산자 썼고, for 루프 안쓰고 while 루프 썼습니다. 당장 GCC 컴파일러나 파이썬 컴파일러 뜯어보세요. 내부 코드가 어떻게 짜여져있는지... 그리고 그걸 파악할수나 있는지요. 컴파일러의 기본지식이 있어도 GCC 컴파일러의 구조를 파악하는건 엄청 어렵습니다. 최적의 바이너리를 만들어내는 컴파일러만 봐도 당장 이런데 1980년대 1990년대 소스는 더 심했습니다.
루리웹-1664351404
이렇게 비추폭탄 받고도 뭘 모르시는거 같은데, 말씀하시는건 지금 현대 컴퓨터 성능에서는 통하는 이야기입니다. 근데 20년전 컴퓨터는 어떨까요? 심지어 30년전 40년전은요? 당신이 이야기한 논리는 옛날 컴퓨터 기반에서는 안통합니다. 뭐 돌아가야지 개발을 하던 말던 할거아니에요. 심지어 본문의 이와타가 현역으로 개발을 할때는 화면에 print로 글자를 어떻게 가독성 있게 찍느냐로 연구하던 시절이에요. 당연하게 있던 함수들이 존재하지 않던 시절입니다. 예를 들자면 print 함수가 (어디 까지나 예입니다) 당시에는 없어서 만들어 쓰던 시절이란겁니다. 같은 기능을 두고도 개발자마다 서로 구현이 다른데 심지어 지금은 기본적으로 있는 함수가 당시엔 없어서 만들었다구요. 그리고 사람들이 이야기하는건 분석이 불가능이 아니라 어렵다에요. 분석은 시간 있으면 가능하죠 당연히. 근데 스파게티처럼 꼬인 소스를 얼마나 시간을 들여서 분석하느냐가 문제죠. 실전에서는 분석은 보통 3일, 길어야 보름을 넘기지 않습니다. 그 시간안에 당신이 맡은 소스코드가 아무리 복잡해도 단시간에 분석해야해요. 그런데 누가 그렇게 시간을 준대요? 그래서 지금은 분석하기 쉽게 누구나 알아보기 쉽게 소스코드를 짜죠. 시간이 많은 해커들과는 다릅니다. 근데말입니다. 20년전만 하더라도 소스코드는 최대한 복잡하게 짜는게 미덕이었습니다. 변수이름도 개떡같이 a, b, c 이렇게 해놓고 알아먹기 힘들게 짰다 이예기에요. 우리나라만 해도 20년전 모습이 이랬는데 해외라고 다를줄 아세요? 그리고 20년전의 기술서적에서는 이렇게 적혀있었어요. C에서는 3항연산자가 if문보다 빠르고 while 루프가 for 루프보다 빠르다고요. 지금은 개소리 맞구요. 20년전에는 맞는 이야기였어요. 그만큼 20년전 컴퓨터 성능이 나빴습니다. 성능을 끌어올리기 위해 어셈블리를 다이렉트로 쓰기도 하고 코드 자체의 실행시간조차도 줄여가면서 개발했던 시절이 불과 20년전입니다. 30년, 40년전은 어땠을거 같애요? 그 흔한 print문 같은 당연한 함수를 직접 만들어 써야 했다면요? 그리고 그게 성능에 영향을 준다면? 그리고 코드를 최대한 복잡하게 짜는게 당시의 개발 트렌드였다면요? 사람들이 예기하는 논점은 지금의 개발 트렌드가 아니에요. 40년전의 개발트렌드에요. 저만해도 20년전에는 개발트렌드가 그랬는데 40년전은 더 하면 더 했지 덜하진 않았어요.
루리웹-1664351404
끝까지 주장을 굽히지 않으니시 더는 할말이 없군요. 평생 그렇게 남을 깔보며 사세요. 유지보수는 어디까지나 초짜나 하는거라고 깔보면서요. 당신이 40대를 넘어가면 과연 어떻게 개발일을 하실지 궁금하군요. 분석과 신규개발은 별개입니다. 뭐 이걸 수준의 차이라는 잦대로 재고 계시는데 할말이 없군요.
루리웹-1664351404
개발 경력이 얼마나 되서 얼마나 많은 환경에서 경험을 가졌는지는 모르겠지만 , 남이 짠 소스가 품질이 천차만별인데, 그렇게 극단적으로 이야기하니 당연히 비추 폭탄이죠.
루리웹-1664351404
보편적이란게 말이 안되는게, 분명 보편적이라고 생각하는 상황도 있지만 아닌상황도 별로 없지 않으니 하는 소리에요. 실제 작업하다보면 전혀 그렇지 않은 상황도 많고, 기존 남이 짜논 코드에 뭔가 기능 얹는게 얼마나 끔찍할수 있는 상황인데 터무니 없이 남이 짜논 코드 이해못하면 그건 담당하게된 사람 이 실력이 없다는 식으로 이야기하는게 문제죠. 유지보수라는 범위의 정의도 회사마다 다 다르고, 진짜 왠갖 케이스가 다 있는데 그러면 유지보수가 더 난이도 높은 상황도 당연히 있겠죠. 개발하다 보면 이게 공감가는 사람이 훨씬 많을거라고 생각하는데요??
루리웹-1664351404
저 분이 개발하실때 쓴 시퓨는 60헤르츠 짜리 입니다. if안쓰고 3항연산자를 쓰시고 for문이 아니라 while 쓰신 건 속도와 메모리 사용량 때문에 문인 것같네요. https://kr.mouser.com/ProductDetail/Texas-Instruments/TMS320C40GFL60?qs=C%252BCPuz7QWnE7f5x62sOXBw%3D%3D
너무 일찍 가셨음 ㅜㅜ
포켓몬은 거대 IP가 된게 문제지. 안사서 망해야 하는데 현재 상태로는 피카츄가 똥싸는 것만 있어도 사람들이 사갈껄.
완전 공감
생각해보니 아인슈타인같은 천재가 진짜 개쩌는 천재라 오래 남는거지 이런 사람들도 천재라니까...
천재는 단명
RIP.. ㅠㅠ
결국 과거의 포켓몬들은 닌텐도가 살렸던거냐
이와타 사토루가 살린거지
에디슨회사에 온 초호화 선박 선원 선원: 선박에 전기 시스템이 고장낫어요 발전기 고장인거같아요 안돌아요!! 에디슨: 지금 as기사들 전부 출장중인데 흠 아참 너 누구라고햇지?? 오스트리아 대학에서 전기학 배웠다고햇나?? ?????:네 에디슨: 니가가서 고쳐봐 고치면 정직원 시켜줄게 (어차피 대형 발전기 복잡해서 못고치는거 암 하지만 선박회사에 밑보이지않을려고 고치는 시늉만하다가 내일아침에 as 기사 보낼생각) ????:네 제가 갓다올게요!!! 다음날아침 ???: 고치고왔습니다 에디슨: 너 근데 누구야???
역시 직류보단 교류지!
테슬라였나?
하지만 초고압으로 가면 교류보다 직류가 낫다... 라는게 함정이지
ㅅㅂ 저때보다 기기는 비교할수없이 좋은데도 소실은 왜 그모양 ㅡㅡ
저거 안보여? 게임프리크는 명작을 낼때도 기술도 능력도 없어서 손빌려서 내는거?
계네는 최신 게임엔진으로 바꾸는 비용조차 아까워서 구형 엔진 그대로 쓸놈들이야 애초에 게임 프리크가 하는 말보면 예네는 근본적으로 뭔가 잘못되어있어 프리 카메라가 없는 게임 찾기도 힘든 시대에 프리카메라가 지원된다는걸 자랑스럽게 말할정도면 사고 방식부터가 10년 이상 뒤쳐진 상태라는 말밖에 안되
고정 카메라 시점도 잘만 쓰면 리소스 절약하고 연출의 매력도 극대화할 수 있지만 (사진 찍는 호러 게임 령 제로 등) 겜프릭은 스카이애로 브리지 이후로 퇴보 일색
최근에 루이지 맨션이 시점 전환을 마음대로 못하긴 하지
본문에는 없지만 닌텐도64 초기에 다들 개발이 서투를때 하드웨어를 분석해서 아예 개발툴이랑 코드 최적화 작업도 했었음. 실제로 슈퍼마리오64 발매후 서드파티에서(코나미로 기억) '마리오의 움직임은 우리들로는 재현할수 없다, 최적화 명령어가 따로 있는게 아니냐' 식으로 발언했었음. 그때 당시엔 몰랐는데 지나고 나니 이와타가 개발 최적화에 관여한게 거의 99퍼 확실한듯.
포켓몬 스타디움 사진 위에 말이 이 내용 아닌가요??
본문에는 포켓몬 관련 작업만 언급되어있고 저는 64런칭 초기부터 최적화 영향력을 컸다고 적을려고 했는데 폰으로 대충 적다보니 주어가 빠졌네요.
하지만 그는 국가코드를 집어 넣었지
대난투 관련 일화도 있는데, 대난투 제작한 사쿠라이랑 친해서 그런지 거의 막장으로 상황 만들어놓고 수습하라는것도 나옴. 새 콘솔로 대난투 개발중이라고 언질해놓고 정작 사쿠라이 본인은 들은적도 없는데 뭐냐고 그러니까 니가 안하면 전작 그냥 단순이식 해야겠네 하고 비꽛다는 일화나 이번 스위치도 죽기전 유언으로 마지막으로 한번만 더 진행해 달라고 부탁한거나
전설적인 프로그래머이자 한 사람의 게이머였던 분이였는데 너무 일찍 떠나심...
골프겜 겁나 어렵던데
너무 일찍 가셨어...
또 있다. 마더 3가 닌64로 만들던 중에 취소됐다가 몇년 후에 이와타가 GBA로 만들어 보자고 해서 최초기획 12년 만인 2003년에 GBA로 나옴
그리고 위 유가 죽쒀서 자기가 싼 똥 직접 치운다면서 죽기 전까지 잡고 있던 프로젝트가 스위치
저 이와타 사토루가 천재라고 인정한 사람은 이미테이션 게임 만들던 사람(나카무라 코이치)이다...
게임 기획보단 프로그래밍 테크닉 부분을 평가했을듯. 나카무라는 무려 고등학생때 상업게임 만든 사람이고, 당대 최고의 드퀘 시리즈 핵심 프로그래머였으니... 이와타 자신도 남이 문제를 가져오면 해결해주는 것에 보람을 찾는 천상 프로그래머라 요즘 생각하는 참신한 기획과 장르를 개척하는 만능 개발자와는 좀 거리가 있음.
나카무라 관련 썰 중에 한 번 플레이한 게임을 코드를 다시 짜서 똑같이 만든다던가 드퀘 페미컴판 용량 오버됐다고 불려가서 즉석에서 코드를 새로 짰다던가 하는 전설이 있음...
아이고 하늘에서 피눈물 흘리겠네 ㅠㅜ
직접아조시...
패미컴이ㅕㄴ 2mb넣었다고 자랑할때 아니냐?? ㄷㄷㄷㄷㄷㄷㄷ
개인적으로 천재 프로그래머라면 딱 떠오르는 사람은 존 카멕.
위에도 적고 내려왔는데 룰웹에선 카멕은 너무 저취급받음..
파판3 그 이란인가 사우디던가 아죠씬줄 알았더니.. 이분도 레전설 그 자체 ㄷㄷ
둘다 현실인데 난 그분이 더 함 머리속에 모든게 들어있던거나 남들이 풀지 못 해서 이식이 못 나왔던 거 하며
개발+PM+영업 = 수명...