GTA에서 저격할 때 달의 크기가 변하는 이유

 (insiderockstarnorth.blogspot.com)
1P by GN⁺ | ★ favorite | 댓글 1개

달의 크기가 변하는 이유

  • 게임 내에서 달의 텍스처를 제공받아 밤하늘에 적절한 크기로 배치함.
  • 나중에 4명의 아티스트가 달의 크기를 변경해달라고 요청함; 2명은 현실적인 크기를 원했고, 다른 2명은 영화 같은 크기를 원함.
  • 달의 크기를 게임 내에서 변경 가능하도록 제안함; 스나이퍼 라이플 작업 중이었기 때문에 플레이어가 달을 저격할 때 세 가지 크기(작음, 중간, 큼)로 전환되도록 설정함.
  • 아티스트들이 최종 결정을 내리지 않아 그대로 두었고, 이 기능은 게임 "SA"에도 남아 있음.

GN⁺의 의견

  • 이 글에서 가장 중요한 것은 게임 개발 과정에서 발생한 창의적인 해결책이 어떻게 게임의 재미 요소로 남게 되었는지를 보여준다는 점임.
  • 게임 개발자와 아티스트 간의 협업에서 발생할 수 있는 의견 충돌을 유연하게 해결한 사례로, 이러한 비하인드 스토리는 게임을 플레이하는 사람들에게 흥미로운 이야깃거리를 제공함.

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이런 게임 개발 뒷이야기가 좋음. 개발 과정의 흥미로운 유물 같음
    특히 좋아하는 건 Sonic 3D의 숨겨진 레벨 선택 화면: https://www.youtube.com/watch?v=ZZs2HUW9tDA

    • 좋아하는 이스터 에그들이 있음. 첫 F.E.A.R.를 플레이하다가 사무실 주방의 커피 머신에 낯선 브랜드명이 붙어 있는 걸 봤는데, 게임 크레딧과 대조해 보니 그 게임의 아티스트 중 한 명 이름과 맞았음
      그래도 제일 좋아하는 건 Deus Ex: Human Revolution에서 변기 옆 벽에 조개껍데기 세 개가 붙어 있는 걸 발견한 순간이었음
    • 이런 뒷이야기들이 정말 좋음. 재미있었던 것 중 하나는 Perfect Dark의 풍차가 실제로는 자동포/포탑을 스킨만 바꾼 것이었다는 점임. 움직임 구현을 쉽게 하려고 그랬던 듯함
      그래서 치트나 글리치로 너무 가까이 가면 풍차 전체가 돌아서 플레이어를 향해 발사함: https://www.youtube.com/watch?v=r00LITqBDEg
      Fallout 3의 열차 메커니즘도 착용 가능한 방어구 조각으로 구현됐음: https://www.pcgamer.com/heres-whats-happening-inside-fallout...
      Tears of the Kingdom의 Ascend 능력도 원래는 개발자 도구였는데, 동굴 이동을 훨씬 편하고 즐겁게 만든다는 걸 깨닫고 게임 내 능력으로 재활용됐음: https://www.gamespot.com/articles/zelda-tears-of-the-kingdom...
    • GTA에 거의 아무도 못 본 이스터 에그가 있음. 의미는 밝힐 수 없음. 희생이 있었음 :p
      https://www.reddit.com/r/gaming/comments/3ylmm4/comment/cyet...
    • 가장 좋아하는 건 최신 Pokemon 게임에 항상 완전히 렌더링된 바다가 들어 있어서 로딩 시간을 망치는데, 기억상 실제로 탐험되지는 않는다는 이야기임
    • 처음에는 이걸 영상으로 보여주는 게 꽤 짜증났음. 그냥 무슨 내용인지 말해주면 안 되나 싶었는데, 5초쯤 지나자 완전히 빠져들었음
      정말 볼 만함

  • 실제로 어떻게 보이는지 보고 싶다면 이 영상에서 확인할 수 있음:
    https://www.youtube.com/watch?v=GCcd6jEEKQU

    • 블로그 글에는 작음, 중간, 큼이라고 되어 있는데, 이 영상에서는 크기가 8개쯤 보임. 어쩐지 그게 더 웃김
      디자이너들이 게임 안에서 모든 선택지를 직접 봐야 했던 것 같음
    • 완전히 딴얘기지만, 오래전 이라크의 여름에 한 젊은이가 남긴 아련한 철학적 고찰이 떠오름: https://www.youtube.com/watch?v=fIhQllAP5uY
    • 그런데 왜 타원이지? 크기보다 그걸 먼저 고쳐야 하는 것 아닌가

  • 임시 수정만큼 오래 살아남는 코드는 없음

    • 첫 The Division을 출시했을 때, 누군가 코드 주석들을 모아 목록을 만들었는데 “Fix by”, “DO NOT SHIP THIS CODE”, “Temp fix”, “왜 이 코드가 동작하는지 모르겠음, 나중에 리팩터링” 같은 것들이 잔뜩 있었음
      읽어보니 꽤 웃겼음
    • The Codeless Code에 관련된 시가 있음:
      http://thecodelesscode.com/case/234?lang=nl
      심지어 달도 나옴
    • 같이 일하던 회사의 SRE가 뭔가에 temporary ___라고 이름 붙이는 게 그 코드를 아무도 건드리지 않게 만드는 최고의 방법이라고 하곤 했음
    • 임시 해결책보다 더 영구적인 것은 없음
      오래된 러시아 속담
    • 이건 소프트웨어에만 해당하는 얘기도 아님

  • 가장 이상한 건 이게 아무에게도 검증되지 않았다는 점임. 회사는 그냥 개발자를 믿었고, 개발자는 넣었고, 아무도 아무 말 안 했음. 그냥 동작했고 모두 만족했음
    웹 개발에서는 화면에 텍스트 하나 띄우는 것도 힘들어함. 정말 고생이 큼. 코드가 어떻게 보여야 하는지, 어떻게 동작해야 하는지 모두가 의견을 내고, 단어 하나하나를 죽도록 들여다봄
    그 내부의 고통 위에는, 아마 같은 고통을 거쳐 만들어졌을 거대한 추상화 계층들이 메가바이트 단위로 쌓여 있음. 아이러니하게도 웹 개발자 중 실제로 자신이 뭘 하는지 아는 사람은 거의 없고, 아마 4% 정도일 것 같음. 마치 자기 존재 이유를 정당화하려고 자세를 잡는 것처럼 보임

    • 그건 글쓴이가 의도한 것보다 더 많이 가정하는 듯함. 언급하지 않았다고 해서 검증 과정이 없었다는 뜻은 아님

  • 이런 설명일 줄은 몰랐음. 그냥 바보 같은 “달을 쏴라” 농담인 줄 알았음

    • 오늘 처음으로 진짜 웃게 만든 글이었음

  • 소프트웨어 일을 좀 해보니, 이런 질문의 답은 거의 항상 “더 중요한 일들이 있었다”임

  • PS1 시절 F1 게임을 만들고 있었음. 스튜디오가 트랙 텍스처 아티스트 한 명을 해고하고 싶어 했고, 브레이크 보드 뒤쪽에 있던 텍스처 하나를 문제 삼았음
    “이게 뭐야?”
    16x16 정도 되는 텍스처였으니 뭐라고 해도 됐을 텐데, 그는 “성기를 내놓은 졸라맨입니다!”라고 답했음. 스스로 탄약을 건네준 셈임
    달과 관련해서는, 한 번 데모/프로토타입을 만들고 퍼블리셔에 보내기 전에 가벼운 QA 사이클에 넣은 적이 있음. QA 중 한 명이, 맞는 말이긴 했지만 한숨 나오게도, 게임 배경 위치를 고려하면 달이 회전되어 보여야 하는데 달이 거꾸로라고 버그를 올렸음

    • 어차피 해고하려던 상황이고 그런 답을 했다면, 본인도 무슨 일이 벌어지는지 알고 끝까지 한 방 먹이고 나가기로 한 것 같음

  • 이것도 참고:
    https://news.ycombinator.com/item?id=9137736
    “그냥 오리를 빼세요”

    • 답은 아마 이거일 듯함:
      if(time() > 10_years_in_future)
      duck.enable();

  • 향수 차원에서, 치트 코드를 가능하게 하는 코드를 넣은 프로그래머나 팀과 악수하고 싶음

    • 그건 꽤 표준적이었고, 테스트에도 쓰였다고 봄
      예를 들어 맵을 날아다닐 수 있게 해주는 무적 모드는 빠른 이동의 원조였음
      요즘 컴퓨터는 워낙 강력해서 치트 코드가 하던 일을 사실상 다 하는 완전한 편집기를 둘 수 있지만, 예전에는 돈이 모자라 지을 수 없는 X의 건설을 테스트하려면 키 몇 개로 16진수 값을 바꿔 즉시 최대 금액에 가깝게 만들고 더 효율적으로 테스트했음
      치트 코드는 일반 플레이어가 우연히 찾기는 어렵지만, 플레이어가 쓰는 게 불가능하지는 않을 정도로 숨겨졌음
      논리는 아마 게임을 샀다면 모든 콘텐츠에 접근할 수 있어야 한다는 것이었음. 요즘은 게임이 너무 큰 사업이 되어서 모든 게 너무 진지해졌음
    • 운이 좋음. 같은 사람임 ;) https://insiderockstarnorth.blogspot.com/2023/11/the-trouble...
    • 이건 남겨뒀어야 했음:

      게임의 충돌 판정은 보통 시각적 폴리곤과 다릅니다. 충돌 검출은 비교적 느리기 때문입니다. 시각적 폴리곤이 10,000개인 건물도 충돌 폴리곤은 1,000개뿐일 수 있습니다. 그 결과 맵에는 보이지 않는 구멍이 생길 수 있습니다. 맵 아래로 떨어질 때 벌어지는 일이 바로 이것입니다.
      이 때문에 테스터들이 맵의 충돌 판정을 테스트하기가 매우 어렵습니다. gta4 때는 캐릭터가 애니메이션에 따라 맵 아래로 떨어질 수 있었고, 테스터들이 맵의 모든 부분을 직접 밟아볼 방법이 없어 특히 힘들었습니다.
      그래서 그들이 래그돌 총을 요청했습니다. Alexander Roger가 총알 대신 래그돌 캐릭터를 발사하는 특수 총을 만들었습니다. 테스터들은 맵을 돌아다니며 모든 건물과 언덕에 래그돌을 쏠 수 있었습니다. --https://insiderockstarnorth.blogspot.com/2023/11/bugs-bugs-b...

    • 학교에서 프로그래밍을 배우기 시작하고 디버깅이 무슨 뜻인지 제대로 이해하기 전까지는, 비디오 게임 공략집이 잠금 해제 방법을 알려주던 “debug mode”의 목적이 뭔지 이해하지 못했음
      치트 코드처럼 플레이어가 찾아서 즐기라고 넣은 줄 알았음. 나중에야 모델 뷰어, 이벤트 뷰어, 스테이지 선택 같은 것들이 전부 QA 팀을 위해, 혹은 QA 팀이 쓰려고 개발된 것이라는 걸 깨달았음

  • 이건 달 버전의 Jobs 계산기 앱 민담 같음

    • 다만 이쪽은 성공적으로 실행됐다는 차이가 있음
답변달기