KR101772584B1 - 게임 파일의 온라인 렌더링을 위한 방법 및 장치 - Google Patents

Abstract

대응하는 게임 및 게임 시스템을 필요로 하지 않고 게임 파일에 기록된 액션을 보이게 해주기 위해 게임 파일을 오디오/비디오 파일 포맷으로 자동으로 렌더링하는 방법 및 장치.

Description

게임 파일의 온라인 렌더링을 위한 방법 및 장치{METHOD AND APPARATUS FOR ONLINE RENDERING OF GAME FILES}

본 발명은 게임 내의 후속의 재생을 위해 게임 내의 액션을 기록할 수 있는 비디오 게임에 관한 것이다. 더 구체적으로, 본 발명은 게임 없이 후속의 재생을 위해, 그러한 기록을 취득하고, 그것을 렌더링하고, 그 결과를 오디오/비디오 파일로 캡처한다.

오늘날 비디오 게임들에서, TV로 방송되는 스포츠에서와 같이, 인기있는 특징은 "즉시 재생(instant replay)"이다. 이 특징은 방금 실황으로 일어난 플레이 또는 이벤트를 플레이어(들) 또는 시청자에게 다시 보여지게 해준다.

TV로 방송되는 스포츠들의 경우, 액션을 촬영하는 카메라들 각각으로부터의 비디오 신호는 기록되고 아마도 압축된다. 즉시 재생을 달성하기 위해, 그 기록들 중 하나 이상이 재생된다. 원래 선택되었던 것 외에 재생용으로 다른 카메라가 선택된다면, 시청자는 동일 플레이 또는 이벤트를 다른 관점에서 경험할 수 있다. 어떤 스포츠들에서는, 실황의 이벤트에 존재하는 심판 또는 레프리가 "즉시 재생" 기술을 이용할 수 있지만, 이는 그들 자신의 게임의 경험 이외에 유리한 위치에서 플레이 또는 이벤트를 검토하는 방법으로서이다.

비디오 게임들에서는 기술이 다르다. 비디오의 기록은 계산적으로 막중한 부담이어서 게임 콘솔의 하드웨어에 의해 지원조차 되지 않는 경우도 많으며, 오디오 및 비디오 그래픽의 렌더링이 전용 칩들에 의해 수행되고 그 칩들의 출력은 캡처를 위해 메인 프로세서에 액세스될 수 없을 수 있다. 또한, 계산의 리소스들을 최대로 이용하는 것이 일반적으로 비디오 게임의 본질이므로, 잉여의 용량이 사용되지 않은 채 남아 있는 경우는 거의 없다. 따라서, 가능한 경우라도, 나중의 재생을 위한 비디오의 캡처는, 원래 게임 플레이어의 관점으로부터조차도 게임의 다른 특징들, 예를 들면, 그래픽 복잡성, 플레이어의 수, 게임 오브젝트의 수 등을 심각하게 제한할 것이다.

이러한 제한을 극복하기 위해, 현대의 많은 게임들은 대신 "게임 파일"을 캡처할 것이다. "게임 파일"은 하나 이상의 시점(예를 들면, 게임의 시작시의 초기 상태, 또는 플레이 동안 어떤 중간 상태에서의 체크포인트)에서의 게임 상태를 나타내는 데이터, 및 게임 내의 이벤트들의 원래의 시퀀스를 재생하기 위해 필요한 타임스탬프형 또는 주기적 데이터를 포함한다. 그러한 타임스탬프형 또는 주기적 데이터는 예를 들면, 게임 콘트롤러 버튼의 프레스(press)들을 나타낼 수 있을 것이다. 이것은 게임이 실질적으로 결정론적일 것을 필요로 한다. 즉, 특정 상태로부터 시작하여, 특정 시간들에 적용된 특정 입력 이벤트들에 의해 게임의 결과는 정확히 동일하거나 또는 거의 동일할 것이다.

단일 플레이어 게임에서, 결정론적 게임에 영향을 줄 수 있는 유일한 이벤트들은 플레이어에 의해 입력된 이벤트들이다. 그러한 입력 이벤트들은 버튼 프레스 및 해제, 또는 주기적 조이스틱 판독 또는 조이스틱 위치 갱신 등의 단순한 콘트롤러 입력을 포함할 수 있다. 입력 이벤트들은 더 복잡한 콘트롤 입력들을 처리한 결과로서 생성될 수도 있다. 예를 들면, 복잡한 콘트롤 입력은 플레이어를 지켜보는 카메라로부터의 비디오의 분석일 수 있다. 즉, 플레이어의 움직임의 비디오가 분석될 경우, 시스템은 미리 정해진 제스처(예를 들면, 손 흔들기) 또는 값(예를 들면, 플레이어의 신체가 기울어진 각도)을 인식할 수 있으며, 이것은 입력 이벤트를 생성한다. 복잡한 콘트롤 입력의 다른 예는 플레이어의 음성을 감시하는 마이크로폰으로부터의 오디오 입력이다. 즉, 음성 인식 알고리즘의 적용은 말한 명령, 또는 플레이어의 음성의 강세의 레벨을 인식할 수 있어서, 인식된 명령 또는 강세 값이 입력 이벤트가 된다.

멀티-플레이어 게임에서, 플레이어들 각각에 의해 생성되는 입력 이벤트들은 기록될 수 있다. 플레이어들 모두가 동일 콘솔 상의 별도의 콘트롤러들을 갖는 경우, 이것은 통상적이다. 그러나, 서로 다른 플레이어들이 통신 채널(예를 들면, 적외선 링크, Bluetooth (TM), 유선 또는 무선 로컬 에어리어 네트워크, 전화 네트워크 또는 인터넷)을 통해 접속된 별개의 콘솔들을 갖는 분산형 멀티-플레이어 게임에서는, 콘솔들 간에 보내진 메시지들만을 기록하는 것으로 충분할 수 있다. 어떤 분산형 멀티-플레이어 게임들에서, 각각의 플레이어로부터의 입력 이벤트들은 대응하는 콘솔에 의해 처리되고, 그러한 입력 이벤트들은 게임 내의 오브젝트들의 상태에 변경을 초래하고, 그 후 공유된다. 게임 내의 오브젝트들에의 변경을 나타내는 데이터가 입력 이벤트들을 나타내는 데이터보다 작기 때문에, 또는 모든 플레이어들로부터의 입력 이벤트들을 처리하는 것이 지나치게 큰 부담이기 때문에, 그러한 구현 선택이 이루어질 수 있다. 예를 들면, 조이스틱 입력이 겨냥을 위해 이용되는 경우, 현재 선택된 타겟을 결정하는 것은 비용이 많이 드는 계산일 수 있어서, 현재 선택된 타겟을 계산하기 위해 참가하는 모든 콘솔들을 필요로 하고 현재의 조이스틱 값을 교환하는 것 대신에, 조이스틱이 부착된 콘솔이 타겟을 결정할 수 있고 타겟의 아이덴티티를 다른 콘솔들에 보낼 수 있다. 미가공 입력 이벤트들을 보낼지, 또는 사전에 처리된 오브젝트 갱신들을 보낼지는 구현상의 결정이며, 게임 어플레케이션 내에서도 변화될 수 있다(즉, 어떤 경우들에서는 오브젝트들의 갱신들이 보내지고, 다른 경우들에서는 미가공 입력 이벤트들이 보내진다).

따라서, 게임 파일에 기록될 타임스탬프형 데이터는 플레이어들로부터의 입력 이벤트들, 또는 다른 게임 참가자들로부터 콘솔에 의해 수신된 메시지들, 또는 그들의 혼합을 나타낼 수 있다. 이러한 종류의 게임 파일은, 예를 들면, 워싱톤주 레드몬드 소재의 Microsoft, Inc에 의해 발표되어 2007년 9월에 시작한 Halo 3 (TM)에서 이용된다.

그러한 "게임 파일"이 주어지면, 즉시 재생은 동일한 게임 프로그램을 실행하는 마찬가지의 콘솔에서 달성될 수 있다. 게임 파일에 기록된 게임 상태는 원래의 플레이에서 일어났던 콘솔에서의 게임 상태를 되살리기 위해 이용된다. 그 후, 플레이어 콘트롤들 또는 다른 콘솔들로부터의 실제 입력 대신에, 타임스탬프형 데이터가 게임 엔진에 공급된다. 이것은 실시간으로 일어날 수 있고, 이 경우에 오디오 및 비디오의 재생은 플레이어가 원래 보았던 것과 동등하지 않다면 그와 유사하거나, 또는 게임 콘솔이 감속된 클록을 이용하여 재생할 수 있고, 이 경우에 재생은 슬로우 모션으로 될 수 있다.

일반적으로, 게임 파일들은 거꾸로 재생될 수 없는데, 왜냐하면 게임 모델의 본질이 거꾸로 실행될 수 없기 때문이다. 어떤 구현들에서는, 되감기 기능을 지원하기 위해, 게임 파일들은 중간 체크 포인트들을 포함한다. 각각의 중간 체크 포인트들은, 게임 파일의 재생이 시작될 수 있는, 초기 상태의 것과 유사한, 게임 상태를 포함한다. 중간 체크 포인트들에 의해, 되감기 기능은 플레이어가 게임 파일을 항상 처음부터 시작할 필요없이, 하나의 액션을 반복적으로 재생할 수 있도록 제공될 수 있다. Halo 3 (TM) (op. cit.)에서, 중간 체크 포인트들은 수 초마다 게임 파일에 포함된다. 따라서, 게임의 기록을 검토할 때, 사용자는 수 초의 시간상의 해상도로, 파일 내의 임의의 지점으로 순방향 또는 역방향으로 스킵할 수 있다.

어떤 구현들에서는, 특히 Halo 3 (TM)의 경우에, 게임 파일의 재생 동안, 사용자는 원래 플레이어가 경험했던 것과는 다르게 카메라 위치를 변경하는 옵션을 갖는다. 예를 들면, 원래 플레이어는 플레이어의 캐릭터의 제1 인물 시점(POV)에 설정된 카메라를 가지고 플레이하였을 수 있다, 즉, 게임은 플레이어 자신의 캐릭터의 눈을 통해 보여졌을 수 있다. 그러나, 재생시에, 카메라는 다른 캐릭터의 POV로부터, 또는 플레이어의 캐릭터의 뒤에서부터 액션을 보는 것으로 스위칭될 수 있다. 어떤 구현들에서는, 카메라는 액션 위에서 날 수 있는데, 캐릭터에 매이거나(tethered), 캐릭터를 향해 가리키도록 제약되거나, 또는 둘 다이거나, 또는 둘 다 아닐 수 있으며, 어디로든 자유롭게 날 수 있고 자유롭게 가리킬 수 있다.

게임 파일에 대해서는 사소한 편집만이 적당하다. 예를 들면, 원래 카메라 위치의 오버라이드가 재생 중에 기록될 수 있고 편집된 게임 파일 내에 포함될 수 있다. 이 오버라이드가 원래 기록된 카메라 위치를 대체할지, 또는 오버라이드가 원래 카메라 위치와는 별개인 것인지를 결정하는 것은 구현의 문제이며, "원래 카메라 위치 이용" 옵션은, 나중에 사용자가 원래 카메라 위치 기록의 부분이 편집된 버전보다 더 선호된다고 결정한 경우에, 제시될 수 있다.

사운드 또는 비디오 기록에 있어서, 편집자는 재생 또는 복사를 위해 요구되는 기록의 특정 세그먼트를 식별하기 위해, 기록 내의 "인-포인트" 및 "아웃-포인트"를 지정하는 능력을 갖는다. 마찬가지로, 인-포인트 및/또는 아웃-포인트가 게임 파일에 지정될 수 있다. 이것은 15분 동안 실행할 수 있는 완전한 게임 파일을 갖고 있는 사용자가 관심 있는 부분을 식별할 수 있게 해준다. 따라서, 15분 게임 파일 내에 7분 2초에, 공유할 가치가 있는, 장관의 30초 이벤트가 일어났다면, 선택된 관심 부분만을 실질적으로 보여주기 위해 편집된 클립의 재생을 지시하는 인-포인트 및 아웃-포인트가 지정될 수 있다. 따라서, 인-포인트 및 아웃-포인트를 설정함으로써, 게임 파일에 의해 나타낸 실황의 게임 플레이의 구간은 전체 세션일 수 있거나, 또는 관심의 특정 구간일 수 있다.

Halo 3 (TM)을 포함하여, 어떤 구현들에서는, 편집된 게임 파일들은 게임 파일의 개시로부터 특정 인-포인트에서의 또는 그 바로 직전의 중간 체크포인트까지의(중간 체크포인트를 포함하지는 않음) 임의의 게임 상태들과 이벤트들을 탈락시킴으로써 원래 파일보다 작게 만들어질 수 있다. 인-포인트 전에 중간 게임 상태가 없다거나, 또는 인-포인트가 설정되지 않았다면, 파일의 개시는 이러한 방식으로 클리핑되지(clipped) 않는다. 또한, 편집된 게임 파일은, 아웃-포인트 후에 일어나는 이벤트들 및 중간 게임 상태들이 있다면 이들을 모두를 탈락시킴으로써 단축될 수 있다. 이전의 예에서는, 15분 게임 파일이 겨우 약 30초 길이인(또는 후술하는 바와 같이 약간 더 긴) 편집된 게임 파일로서 저장될 수 있었다.

대응하는 이전의 게임 상태(초기 게임 상태이든, 또는 중간 체크포인트이든)의 정밀도보다 큰 정밀도를 갖는 시간 또는 프레임 넘버로서 인-포인트가 지정되는 것을 허용하는 어떤 구현들에 있어서, 게임 콘솔은 지정된 인-포인트 직전의 게임 상태에서 재생을 시작하지만, 인-포인트에 도달할 때까지 비디오를 블랭크(blank)로 그리고 오디오를 묵음으로 유지한다. 이러한 이유 때문에, 게임이 5초마다 중간 체크포인트를 저장하게 된다면, 상기의 예에서 편집된 게임 파일은, 선택된 인-포인트 및 아웃-포인트가 30초 떨어져 있더라도, 30 내지 35초 상당의 분량의 데이터를 포함할 것이다.

따라서, 편집된 게임 파일은 "클리핑된 게임 파일"로서 저장될 수 있고, 단지, 인-포인트 직전 및 아웃-포인트 직전인 중간 게임 상태들과, 최초 보유된 게임 상태의 것에서부터 아웃-포인트에서의 것들까지 사이에 있는 게임 이벤트들을 포함할 수 있다. 그러나, 모든 면에서, 클리핑된 게임 파일은 여전히 게임 파일이고, 후속의 편집을 포함하여, 마찬가지의 방식으로 취급될 수 있다. 재생시에, 결과의 클리핑된 게임 파일은 여전히 원래 게임 파일과 닮았으나, 재생은 도중(액션의 중간에서)부터 시작할 수 있다. 감소된 크기는 스토리지를 덜 차지하고, 업로드 및 다운로드 시간이 감소되기 때문에 공유하기에 더 용이하고 비용이 덜 든다.

게임 파일의 재생 동안 카메라의 유리한 위치를 변경하는 능력은 세련된 즉시 재생 메커니즘을 제공하여, 플레이어가 그 자신의 플레이를 검토하여, 왜 특정 전략이 성공했는지 또는 실패했는지를 결정하게 해준다. 관심 있는 액션에 빨리 이르도록 인-포인트 및 아웃-포인트의 설정을 부가하는 것(게임 파일들의 클리핑을 포함할 수 있거나 또는 포함하지 않을 수 있음)은 다른 사람들에게 퍼포먼스를 유익하거나 재미있게 보여주는 양호한 방법을 제공한다.

그러나, 게임 파일들의 단점이 있는데, 즉, 그들을 검토하기 위해, 사용자는 적당한 게임 콘솔 및 게임의 카피를 갖고 있어야 한다는 것이다. 이것은 즉시 재생을 위해 게임 파일들을 이용하고 있거나, 또는 이미 자신의 게임을 소유한 다른 플레이어들과 게임 파일들을 공유하고 있는 플레이어들에게는 괜찮으나, 그렇지 않다면 오락의 즐거운 형태일 수 있는 것에 대한 시청을 심각하게 제한한다.

본 발명은, 편집되었거나 또는 편집되지 않았거나, 앞서 논의된 것들과 같은 게임 파일들이 원격 서버에 업로드되는 것을 허용하며, 원격 서버는 게임의 재생을, 마찬가지의 콘솔 상에서든 또는 다른 식으로든, 그들이 기록되었던 게임의 외부에서 보기에 적합한 오디오/비디오 파일로서 렌더링할 수 있다. 특히, 렌더링된 파일은, 예를 들면, 인터넷을 통해 배포될 수 있고, 예를 들면, 퍼스널 컴퓨터 상에서, 예를 들면 웹 브라우저 내에서 시청될 수 있다. 결과적인 비디오 파일은, 그것을 다른 그러한 비디오 파일들과 결합하기 위한 비디오 편집 소프트웨어를 이용하여, DVD에 전송될 수 있거나(필요하다면 트랜스코딩을 포함할 수 있는 DVD 저작 소프트웨어를 이용하여) 또는 편집될 수 있고, 그리고/또는 오디오 트랙이 변경될 수 있다.

게임 파일로부터, 본 발명은 대응하는 게임 디스크(또는 카트리지) 또는 호환성 콘솔을 갖지 않는 개인들에게 배포될 수 있는 오디오/비디오 파일을 편리하게 제작하고, 따라서 단순한 오락 이상으로, 유사한 게임-내 위업을 시도하도록 다른 플레이어들을 환기시킬 수 있거나 교습시킬 수 있고, 플레이어가 아닌 사람들을 콘솔 및/또는 게임을 취득하도록 유도할 수 있는 보다 다기능의 오락 원천을 제공할 수 있다.

본 발명은 결과적인 비디오 파일의 출력 해상도들의 선택을 제공할 수 있다. 또한, 고급의 프리미엄에서만 이용 가능한 고급의 출력 해상도들을 갖는 소정의 실시예들에 있어서, 본 발명은 그의 기능들을 프리미엄 서비스로서 사용자들에게 제공하도록 구성될 수 있다.

본 발명의 양태들은, 유사한 참조 부호들이 유사한 부분들을 나타내는 첨부 도면을 참조하여 하기의 상세한 설명을 고려하면 명백해질 것이다.
도 1은 본 발명의 일 실시예의 블록도이다.
도 2는 렌더링 요청을 제공하는 업로드된 게임 파일을 나타내는 사용자 인터페이스이다.
도 3은 렌더링 요청 거래 동안 상세 사항을 수집하는 다이얼로그 박스이다.
도 4는 렌더링 요청 거래의 진행 또는 결과를 추적하기에 적당한 영수증이다.
도 5는 본 발명의 게임 파일 렌더링 처리의 플로우차트이다.

도 1을 참조하면, 게임 콘솔들(101 내지 104)은 개별적으로, 또는 LAN(도시 생략) 및/또는 인터넷(110)을 통해 게임 콘솔들(101 내지 104)이 서로 통신하는 멀티-노드 구성(100)에서 플레이할 수 있다. 멀티-플레이어 구성은 단일 콘솔에서 발생할 수 있거나, 또는 멀티-노드 구성에서 동작하는 콘솔들 사이에서 플레이하는 상이한 플레이어들에 의해 발생할 수 있거나, 또는 둘 다의 경우에서 발생할 수 있다. 멀티-노드 구성(100)에서, 참여하는 콘솔들 각각은 로컬 디스크, 카트리지, 또는 파일로부터의 것이든, 또는 그들을 링크하는 통신 채널을 통해 다운로드된 것이든, 플레이되는 게임 프로그램의 카피를 갖는다.

또한 콘솔들(101 내지 104) 중 임의의 콘솔은 또한, 높은 대역폭 가용성에 대한 신뢰성과 용량을 위해(이 특징들은 엄격하게 요구되지 않지만) 일반적으로 데이터 센터(121)에 유지되는 백 엔드 서버 시스템(120)과 인터넷(110)을 통해 통신할 수 있다.

백 엔드 서버 시스템(120)은 다른 서비스들 가운데에서도, 게임 로비를 제공할 수 있는 게임 네트워크 서버(122)를 포함함으로써, 특정 게임을 플레이하기 위해 준비된 하나의 콘솔(101)에서의 플레이어가 다른 콘솔들(102 내지 104)에서 마찬가지로 준비된 다른 플레이어들을 발견할 수 있다. 게임 네트워크 서버(122)를 통해 이용 가능한 다른 서비스들은 계정 유지보수, 게임 이력(예를 들면, 게임-내 성취의 리스팅), 높은 점수의 플레이어들을 식별하기 위한 리더 보드, 게임 관련 공고, 및 다른 플레이어들에 대한 인스턴트 메시징(instant messaging) 및 포럼 등의 소셜 네트워킹 특징들을 포함할 수 있다.

본 실시예에서, 파일 공유(123)에 대한 액세스는 게임 네트워크 서버(122)를 통해 얻어지지만, 다른 구현들도 생각된다. 파일 공유(123)는 스토리지(124)에 대한 액세스를 제공하는 전용의 서버이다. 파일 공유(123)와의 통신시에, 콘솔(101)은 파일 공유(123)에 의해 관리되는 정책들 및 규칙들에 따라서만 스토리지(124)의 게임 파일들을 업로드 또는 다운로드 또는 달리 관리할 수 있다. 예를 들면, 누구든 시청을 목적으로 게임 파일을 그들 자신의 콘솔에 다운로드할 수 있지만, 게임 파일을 업로드하는 플레이어만이 그 게임 파일을 삭제하거나, 그 게임 파일의 편집을 업로드하거나, 또는 그 게임 파일이 렌더링되도록 하는 것이 허가되는 것이 정책일 수 있다. 파일 공유(123)는 그러한 정책들을 실시할 것이다. 파일 공유(123)는 바람직하게 웹 서버 인터페이스(127)를 제공하는데, 웹 서버 인터페이스는 인터넷(110)을 통해, 예를 들면 PC 상에서 실행중인(101 내지 104와 마찬가지의 게임 콘솔에서도 실행될 수 있지만, 도시는 생략) 웹 클라이언트(150)에 의해 액세스될 수 있다. 하기의 논의로부터 알게 되는 바와 같이, 게임 파일은 오디오/비디오 파일로 렌더링될 수 있고, 이 파일도 파일 공유(123)에 의해 스토리지(124)에 저장될 수 있다. 그러한 비디오 파일들은 웹 서버 인터페이스(127)를 통해 웹 클라이언트(150)에게 가용적이지만 그 게임 파일은 그렇지 않다는 것도 또한 파일 공유(123)에 의해 유지되는 정책일 수 있다.

파일 공유(123)는 잡 서버(132)와 통신할 수 있는데, 후술하는 바와 같이, 특히, 높은 정도의 신뢰성과 가용성이 필요로 되지 않고 게임 파일들을 비디오 파일들로서 린더링하기 위해 이용되는 물리적 리소스들에 달리 작업이 맡겨질 수 있다면, 잡 서버는 데이터 센터(121) 내가 아니라, 본 명세서에 도시된 바와 같이 렌더링 센터(131)에 위치될 수 있다. 이것은, 왜냐하면, 게임 네트워크 서버(122) 및 파일 공유(123)에 의해 제공되는 서비스들과는 달리, 렌더링 잡이 처리 중에 또는 전송 중에 실패한다면, 영구적인 손실 없이 재시도될 수 있기 때문이다. 파일 공유(123)와 잡 서버(132) 사이의 통신은 전용의 인터페이스(125)를 통해 이루어지는데, 전용의 인터페이스는 인터넷(110)을 통해 잡 서버(132)에의 보안 통신 채널 또는 링크(126)(예를 들면, 보안 소켓 접속 또는 VPN 접속)를 채택할 수 있다. 보안 링크(126)의 이용은 두절 또는 비인가된 액세스에 대한 파일 공유(123)와 잡 서버(132) 둘 다의 노출을 최소화한다.

예를 들면 콘솔(101)의 플레이어에 관련되는 게임을 완료한 후, 플레이어는 전형적으로 게임 네트워크 서버(122)를 통해, 파일 공유(123)와의 통신에 의해 게임 파일을 스토리지(124)에 업로드하기 위해 게임-내 인터페이스(도시 생략)를 이용할 수 있다. 콘솔(101)의 플레이어(또는 정책이 허용한다면, 다른 콘솔(102 내지 104)의 또는 웹 클라이언트(150)를 이용하는 다른 사용자)는 스토리지(124) 상의 업로드된 게임 파일이 오디오/비디오 파일로 렌더링되도록 요청할 수 있다(도 2와 관련하여 하기에서 더 상세히 논의됨). 요청에 응답하여, 파일 공유(123)는 렌더링을 특정하기 위해 필요한 임의의 상세 사항을 수집하는 것을 포함하여, 렌더링을 위한 거래를 개시한다(도 3과 관련하여 하기에서 더 상세히 논의됨). 게임 파일에 관한 설명적 텍스트, 예를 들면, 클립의 제목이 요청자로부터 접수될 수 있거나, 또는 그러한 정보가 게임 파일 및 그의 메타데이터의 속성들(예를 들면, 게임의 명칭, 환경, 플레이어들, 요청자 등)에 기초하여 자동으로 생성될 수 있다. 거래는 요청자의 계정과 연관하여 지불 또는 다른 청구 방법을 포함할 수 있다. 전자 영수증이 거래에 대해 제공되어, 도 4에 도시되고 하기에서 상세히 논의되는 바와 같이, 렌더링 처리의 현재 상태를 제공한다.

일단 플레이어 또는 사용자가 적당한 상세 사항을 제공했고 렌더링을 위한 거래를 행했다면, 파일 공유(123)는 게임 파일(또는 그것에 대한 레퍼런스) 및 렌더링 상세 사항을 포함하는 렌더링 잡을 보안 링크(126)를 통해 렌더링 시스템(130)에 보낸다. 도시된 구현에 있어서, 렌더링 시스템(130)은 잡 서버(132) 및 하나 이상의 렌더링 클러스터(140)를 포함하고, 각각의 렌더링 클러스터는 컴퓨터(141), 전형적으로는 PC를 포함하고, 컴퓨터는 잡 서버(132)에 의한 명령을 받아서 하나 이상의 콘솔(142)을 제어한다. 잡 서버(132)와 모든 컴퓨터들(141)(하나가 도시됨) 사이의, 그리고 컴퓨터들(141)과 콘솔들(142) 사이의 통신은 별개의 네트워크들을 통해, 또는 도시된 바와 같이, 하나 이상의 스위치(LAN(133)으로서 함축적으로 도시됨)에 의해 제공되는 단일 LAN(133)을 통해 이루어질 수 있다. 일반적으로, 콘솔들(142)은 실질적으로 콘솔들(101 내지 104)과 마찬가지이지만, 오늘날 상업적으로 가장 가용적인 콘솔들은 콘솔의 개발자 버전일 필요가 있다. 이것의 이유는, 일반적으로 소비자 콘솔들(101 내지 104)이 비인가된 부당 변경의 가능성을 감소시키기 위해 다양한 보안 특징들을 구현하거나 또는 외부 관리 특징들을 제거하기 때문이다. 그러나, 개발자 콘솔은 소비자 버전에서는 가용적이지 않은 원격 관리 및 콘트롤 설비를 제공하는 경우가 많다. 그러한 차이점을 갖는 2개의 제품의 예로는 Microsoft Corporation의 Xbox-360, 및 동 회사의 Xbox-360 개발자 콘솔이 있으며, 콘솔의 원격 콘트롤을 허용하는 텔넷 서비스가 Xbox-360 개발자 콘솔에 의해서는 제공되지만, 소비자에게 가용적인 Xbox-360 콘솔에 의해서는 제공되지 않는다. 콘솔들(101 내지 104)이 퍼스널 컴퓨터들로서 구현되는 구현에서는, 콘솔들(142)도 마찬가지로 퍼스널 컴퓨터들로서 구현될 것이라는 것을 유의한다.

잡 서버(132)는 렌더링 잡을 수신하면, 렌더링 잡을 하나의 렌더링 클러스터(140) 내의 컴퓨터(141)에 디스패치한다. 모든 렌더링 클러스터들(140)이 비지(busy)이면, 잡 서버(132)는 렌더링 잡을 큐에 넣을 수 있다. 렌더링 잡을 수신하면, 컴퓨터(141)는 렌더링 잡에 대응하는 게임 파일을 로딩하도록 가용의 콘솔(142)에 명령할 수 있고, 로딩이 완료되면, 예를 들면, 요청된 해상도 등의 연관된 상세 사항에 따라 게임 파일을 재생하도록 콘솔(142)에 명령할 수 있다. 콘솔(142)이 컴파일하면, 콘솔(142)로부터의 오디오 및 비디오 출력이 출력(143), 예를 들면, HDMI 접속을 통해 대응하는 캡처 카드(144)에 전송되고, 또한 컴퓨터(141)에 의해 동작되고 아마도 그 컴퓨터 내에 포함된다. HDMI 출력을 제공하는 Xbox-360 개발자 콘솔의 경우에, 이 목적에 적합한 캡처 카드(144)는 오스트레일리아 멜버른 소재의 Blackmagic Design에 의해 제작된 Intensity Pro이고, 그것의 현재 드라이버들은 동일 컴퓨터(141) 내의 다수의 캡처 카드들을 지원할 수 있다. 컴퓨터(141)는 대응하는 캡처 카드(144)를 적당한 해상도 및 파일 포맷(및 적당한 다른 상세 사항)으로 구성하고, 출력(143)으로부터 캡처된 오디오/비디오를 파일로 보낸다. 렌더링 잡을 실행함에 있어서, 컴퓨터(141)는 대응하는 캡처 카드(144)가 준비되고, 대응하는 콘솔(142)로부터의 출력이 게임 파일 내에 지정된 인-포인트에 도달할 때까지는 캡처하는 것을 보장한다.

콘솔(142)이 게임 파일의 아웃-포인트에 도달하면, 컴퓨터(141)는 캡처를 중지하도록 캡처 카드(144)에 명령하고, 결과적인 오디오/비디오 파일은 클로우즈되지만, 다만 게임 파일의 아웃-포인트 이후에 클로우즈된다. 결과적인 비디오 파일은 잡 서버(132)에 반환되고, 그 후 파일 공유(123)에 전송되어 스토리지(124)에 내재된다.

어떤 실시예들에서는, 렌더링 처리를 통해, 잡 서버(132)가 폴링 컴퓨터(141)에 의해 또는 컴퓨터(141)로부터 수신된 상태 변경 갱신들로부터 렌더링 잡의 상태를 추적할 수 있다. 그러한 갱신들은 파일 공유(123)에 도로 재중계될 수 있어서 거래 영수증(도 4와 관련하여 논의됨)에 나타낸 바와 같이 상태를 갱신한다.

컴퓨터들(141)과 잡 서버(132) 중 어느 하나 또는 둘 다는 성능을 최적화하기 위해 렌더링 잡들을 오더하고 디스패치하려고 시도할 수 있다. 예를 들면, 콘솔(142)이 게임 파일을 재생할 준비가 되면 특정 분량의 셋업이 필요하게 된다. 특히, 게임 파일에 의해 참조되는 환경 및 오브젝트들의 모델들이, 이미 존재하지 않는다면, 로딩되어야 한다. Halo 3 (TM) 제품 및 다른 제품들에 있어서, 환경 및 오브젝트들을 포함하는 모델, 텍스처, 환경음(environmental sounds) 등의 병합은 "맵"이라고 일컬어진다. 많은 상이한 게임 파일들이 동일 세트의 모델들(맵)을 참조할 수 있다. 컴퓨터(141)는 동일한 환경 및 오브젝트 모델들(즉, 동일한 맵)을 이용하는 모든 일련의 게임 파일들을 콘솔(142)에 제공함으로써, 각각의 후속의 렌더링을 위해 항상 환경 등을 로딩할 필요를 회피하여, 콘솔(142)의 이용을 최적화할 수 있다. 잡 서버(132)는 특정 환경을 이용하여 렌더링 잡들을 특정 렌더링 클러스터들(140)에 보내는 것을 선호함으로써 이 최적화에 기여할 수 있다.

잡 서버(132)가 개발자 콘솔들(142)의 어레이와 직접적으로 또는 간접적으로(예를 들면, 컴퓨터(141)를 통해) 통신하는 렌더링 시스템(130)의 하드웨어 구성은, 품질 보증 테스트 베드로서의 용도를 위해 콘솔 게임 개발시에 통상 알려져 있다는 것을 주목할 만하다. 그러한 구성의 보통의 동작은 개발중인 게임의 새로운 구축들(builds)이 표준화되고 자동화된 수많은 테스트들(그러한 테스트 런을 하기로 하는 메커니즘은 잘 알려져 있어서 본 명세서에서는 상세히 설명하지 않으며, 따라서 도면에 도시되지 않음)을 자동으로 받도록 해준다. 새로운 구축의 임의의 실패들은 컴퓨터(141) 또는 잡 서버(132)에 의해 자동으로 검출되고, 개발자의 주의를 끌 수 있어서, 실패를 야기하는 문제가 분석될 수 있고 해결될 수 있다. 동일한 테스트 시퀀스를 반복함으로써 실패가 재발될 수 있기 때문에, 게임 파일도 비디오 캡처도 필요 없다. 그렇더라도, 그러한 시스템에 캡처 카드들(144)을 도입함으로써, 테스트 설비는 렌더링 시스템(130)의 구현을 제공하는 이중 목적의 플랫폼으로 변환된다. 이 변환은 시스템을 여전히 테스트 센터로서 이용 가능하게 둠으로써, 이 리소스들의 매우 효율적인 이용을 가능하게 해준다. 예를 들면, 잡 서버(132)는 특히 심각한 개발 기간 동안 품질 보증 잡들을 우선시하도록 지시될 수 있기 때문에, 렌더링 잡이 완료되기를 오래 대기하도록 초래할 수 있다. 다른 때에는, 예를 들면, 후원되는 시합들 또는 마케팅 이벤트들 동안에는, 렌더링 잡들이 더 높은 우선 순위를 받을 것이다.

비디오 출력의 상이한 해상도들이 렌더링 잡에 지정될 수 있다면, 다수의 옵션들이 이용가능하고 정책에 따라 수동으로 또는 자동으로 선택될 수 있다. 예를 들면, 렌더링 잡이 고화질의 출력을 지정하면(예를 들면, 출력이 1080 해상도 선을 갖는 경우), 더 낮은 해상도의 출력들(예를 들면, 720 또는 480 출력 선을 갖는 출력들)도 제공될 수 있다. 그러한 더 낮은 해상도들이 명시적으로 요청되어야 하는지, 그리고 그들이 동일한 게임 파일의 연속적인 재생들로서 렌더링되는지, 또는 고화질 출력 파일이 컴퓨터(141) 또는 다른 디바이스에 의해 수행되는 별도의 화상 스케일링 처리에 의해 축소되는지는 구현 및 정책의 문제이다.

그럼에도, 결과적인 모든 비디오 파일들 및 연관된 속성들(예를 들면, 제목, 설명 등)은 스토리지(124)에 배치되어 웹 클라이언트(150) 및 아마도 콘솔들(101 내지 104)(오디오/비디오 파일들이 콘솔들에서 플레이되기에 적합하다면)에 이용 가능하게 된다. 대안적으로, 또는 부가적으로, 결과적인 파일들은 사용자에 의해 생성되는 미디어의 공유 서비스들, 예를 들면, 캘리포니아주, 샌 브루노 LLC 소재의 YouTube에 의해 운영되는 웹사이트인 YouTube.com에서 제공되는 서비스들에 자동으로 게시될 수 있다. 자주 있는 경우로서, 외부 공유 서비스들이 특정의, 제한된 해상도로 한정된다면, 일반적으로, 렌더링 센터(131)에 의해 제공되는 최저의 해상도 포맷이 외부 서비스에 제공되어야 한다.

이제 도 2를 다시 참조하면, 사용자 인터페이스(200)가 도시되는데, 이 사용자 인터페이스는 게임 파일이 오디오/비디오 파일로 렌더링되도록 요청하는 거래를 발생시키기 위해 콘솔들(101 내지 104) 또는 웹 클라이언트(150)에 제시될 수 있을 것이다. 인터페이스(200)는 사용자(즉, 플레이어)가 로그인될 것을 필요로 할 수 있으며, 그것의 성공적인 완료는 표시되는 사용자네임(201)에 의해 나타내어진다. 소셜 네트워킹 상태 및 특징들이 열거될 수 있는데, "친구들 온라인" 카운트(202)를 예로 들 수 있다. 사용자의 계정을 안전하게 유지하기 위해 서명 버튼(203)이 제공될 수 있다. 상위 레벨 메뉴(210)가, 예를 들면, 다른 가용의 서비스들을 액세스하기 위해 제공될 수 있다. 화면 이름(221) 및 그 플레이어의 점수 및 성취를 포함하여, 플레이어의 이력(220)의 개요가 표시될 수 있다. 플레이어의 이력에 관련된 더 상세한 사항은 파일 탭(231)을 포함하는 서브 메뉴(230)를 통해 액세스될 수 있다. 파일 탭(231)은 파일 공유(123)의 스토리지(124) 내의 오브젝트들에 대한 액세스 및 관리를 제공한다. 파일 공유(123)에 게임 파일을 업로딩하는 것은, 예를 들면, 콘솔들(101 내지 104)에서 플레이되는 게임 내에서부터 일어날 것이고, 따라서 인터페이스(200)에는 나타내어지지 않는다. 그러나, 파일 공유 메뉴(240)는 이미 업로드된 게임 파일들에 대한 메뉴 항목(242)(도 2에는 현재 선택 아이콘(241)에 의해 선택될 수 있는 것으로서 도시됨)과 렌더링된 비디오들에 대한 메뉴 항목(243)(도 4에 이르기까지는 선택된 것으로서 도시되지 않음)을 포함한다.

메뉴 항목(242)이 선택되면, 업로드된 게임 파일들에 관한 정보가 게임 파일 리스트(260)에 나타내어진다. 게임 파일 리스트(260)의 내용은 필터 바(250) 내의 툴들, 예를 들면, 타입 선택기(251), 데이터 선택기(252), 및/또는 키워드 텍스트 입력 박스(253) 등을 이용하여 필터링될 수 있다. 엘리먼트들(251 내지 253)에 의해 선택된 필터 기준은 서브밋 버튼(254)에 의해 부과될 수 있으며, 그것은 게임 파일 리스트(260)의 결과들을 지정된 필터 기준에 일치하는 게임 파일들만으로 좁힐 것이다.

본 예에서, 게임 파일 리스트는 엔트리들(261 내지 263)로 구성된다. 게임 파일 리스트(260)의 표시 영역에 판독 가능하게 맞는 것보다 많은 엔트리들이 발견되면, 스크롤 바들 또는 페이징 콘트롤들(모두 도시 생략)이 제공될 것이다.

게임 파일 리스트(260)의 각 엔트리는 제목(270), 작성 날짜(272), 저자의 화면 이름(273), 등급(271), 다운로드 카운트(275), 기간(276), 및 게임 타입(277, 277', 277")을 포함할 수 있다. 게임 파일은 아이콘(281)에 의해 나타내어질 수 있지만, 아이콘은 임의의 렌더링 잡이 발행되기 전에 필요하기 때문에, 아이콘(281)은 임의의 게임 파일(도시 생략)에 범용이거나, 또는 특정 환경을 이용하는 임의의 게임 파일에 범용일 수 있으며, 아이콘(281)에 대해서는 맵 속성(278)에 의해 식별되는 "The Pit" 맵이다. 따라서, 게임 파일 엔트리들(261, 263)이 공통의 맵 속성들(278', 278")(둘 다 "Valhalla"임)을 갖는 본 예에서, 그들의 대응하는 아이콘들(281', 281")은 동일하다. 그러나, 엔트리(262)가 상이한 맵 속성(278)("The Pit")을 갖기 때문에, 그의 아이콘(281)은 상이하다. 본 명세서에 나타내지는 않았지만, 아이콘들(281, 281', 281")이 게임 타입 속성들(277, 277', 277")에 의해 대안적으로 또는 추가적으로 차별화될 수 있다.

또한 게임 파일 리스트(260)의 각 엔트리는, (버튼(274)(본 예에서는 "Halo 3")에 리스트된 대응하는 게임 내의 후속의 재생을 위해 연관된 게임 파일을 콘솔(101 내지 104) 내로 끌어들이기 위해) 예를 들면, 다운로드 게임 파일 버튼(274) 등의 콘트롤들을 수반한다. 작성 날짜(272)는 원래 게임 파일이 기록되었던 날짜, 즉, 게임이 최초로 플레이되었던 날짜이지, 파일이 (편집되었다면) 편집되었던 날짜도 아니고 파일이 업로드되었던 날짜도 아니라는 것을 유의한다. 이러한 다른 날짜들도 나타내어질 수 있거나, 또는 예를 들면, "더 상세한 사항" 버튼(279)을 통해 이용 가능할 수 있다. 마지막으로, 파일 렌더링 버튼(280)이 연관된 게임 파일을 렌더링하기 위한 거래를 개시하기 위해 제공된다.

파일 렌더링 버튼(280)은 프레스되면, 도 3에 도시된 바와 같이, 상세 다이얼로그 박스(300)에 의해 사용자로부터의 더 상세한 사항을 요청하여 거래를 개시한다. 다이얼로그 박스(300) 내에서, 게임 파일 속성 디스플레이(362)는 도 2의 인터페이스(200) 내의 대응하는 엔트리(262)와 실질적으로 유사하다. 따라서, 제목(370 & 270), 작성 날짜(372 & 272), 등급(371 & 271), 저자(373 & 273), 다운로드 카운트(375 & 275), 기간(376 & 276), 게임 타입(377 & 277), 및 맵(378 & 278) 간에 대응성이 있다. 편의상, 다운로드를 위한 다운로드 버튼(374)(버튼(274)과 유사함)과, 더 상세한 사항을 위한 상세한 사항 버튼(379)(버튼(279)과 유사함)도 존재한다. 본 예에서는 해상도 선택 버튼들(302, 303)이 새롭게 제시되는데, 이들은 둘 다 압축 비디오 파일 포맷이 Microsoft Corporation에 의해 권장되는 Windows Media Video (WMV)에서 각각 표준 화질과 고화질을 위한 것이다. 다른 상세 사항은 대안적인 프레임 속도들, 또는 대안적인 파일 포맷들(예를 들면, MPEG4) 등의 선택(도시 생략)을 포함할 수 있다. 다음 버튼(305)은 거래를 확인하고, 예를 들면, 버튼들(302, 303)에 의해 선택된 상세 사항과 함께 게임 속성 디스플레이(362)에 의해 식별된 게임 파일의 렌더링 잡을 서브밋한다. 요청자가 렌더링을 하지 않고 거래를 취소하기를 원한다면, 나가기 박스(301)가 클릭될 수 있고, 다이얼로그 박스(300)가 클로우즈될 것이다.

청구할 또는 징수할 지불금이 있다면, 그것은 다이얼로그 박스(300)에 제공되는 상이한 선택들에 대해 상이할 수 있다. 이러한 경우, 하나의 선택(예를 들면, 버튼(302)에 의해 선택 가능한 표준 화질 렌더링)에 대해서는 충분한 크레딧이 가용적이지만, 요청자가 다른 선택들(예를 들면, 버튼(303)에 의해 선택 가능한 고화질 렌더링)에 대해서는 충분한 크레딧을 갖고 있지 않다면, "나는 미닛(minutes)이 더 필요합니다" 버튼(304)이 가용의 크레딧의 가용 수를 증가시키기 위한 처리를 개시할 수 있다. (도 3의 예 및 버튼(304)에서, "크레딧"이란 개념에 이용되는 용어는 "미닛"임을 유의한다.)

일단 다이얼로그 박스(300)에 의해 거래가 서브밋되면, 요청자에게 도 4에 도시된 바와 같은, 영수증 인터페이스(400)가 제시된다. 영수증 인터페이스(400)에서, 상부의 엘리먼트들(201 내지 204, 210, 220, 230, 및 231)은 인터페이스(200)에서와 마찬가지로 남는다. 그러나 파일 공유 메뉴(440)(240이 아님)에서, 선택된 항목 아이콘(441)은 파일 공유 메뉴 항목(442)이 아니라, 활성화될 렌더링된 비디오 메뉴 항목(443)을 나타낸다. 따라서, 게임 파일 리스트(260)를 보는 것 대신, 렌더링된 파일 리스트(460)가 보이게 된다.

렌더링된 파일 리스트(460)에 있어서, 각각의 렌더링된 파일은 엔트리(462) 등의 엔트리에 의해 나타내어진다(도 4에는 하나의 엔트리만이 도시됨). 렌더링된 파일 엔트리(462)는 제목(470 & 270), 작성 날짜(472 & 272), 저자의 화면 이름(473 & 273), 등급(471 & 271), 다운로드 카운트(475 & 275), 기간(476 & 276), 게임 타입(477 & 277), 및 맵 속성(478 & 278)을 포함하여, 게임 파일 엔트리(262) 중 대응하는 것들과 일치하게 남아 있는 많은 엘리먼트들을 포함한다. 그러나, "더 상세한 사항" 버튼(479)이 프레스될 때 나타나는 많은 상세 사항은 렌더링된 파일에 특정적이다(일부는 또한 원래의 게임 파일에도 대응할 수 있음). 많은 상세 사항이 렌더링된 파일에 특정적일 것이다. 렌더링 요청(490)은 게임 파일 엔트리(262)로부터 렌더링된 오디오/비디오 파일을 제작하기 위한 요청에 대응하는 거래 번호를 나타낸다. 요청의 날짜(491), 완료 날짜(492)(또는 도 4에 도시된 바와 같이 완료 예상 날짜), 거래 상세 다이얼로그 박스(300)에 요청된 해상도(493), 사용자네임(201)에 의해 나타내어진 플레이어의 계정에 대해 평가되는 요금(494)(본 예에서는, 청구의 통화가 "미닛"이라는 것을 재차 유의한다), 및 현재 상태(495)가 포함되고, 현재 상태로서 "현재 필름을 렌더링 중임"은 "곧 시청" 레이블이 있는 비활성화된 콘트롤(474)로서도 표현된다. 어떤 정황에서는, 렌더링 요청의 상세한 사항은 상세한 사항 버튼(479)을 프레스하지 않고, 예를 들면, 다이얼로그 박스(300)로부터 거래를 보낸 직후에 표시될 수 있다는 것을 유의한다.

현재 상태(495)가 "렌더링 완료"(도시 생략)이면, 콘트롤 버튼(474)이 활성화되어 "지금 시청"(도시 생략)이 읽힐 것이다. "지금 시청"(도시 생략)을 나타낼 때 콘트롤 버튼(474)을 프레스하면, 렌더링된 파일의 다운로드 및 재생을 선택된 해상도로 개시할 것이다.

어떤 경우들에서는, 렌더링 잡이 실패할 수 있어서, 그러한 경우에 현재 상태(495)는 "실패"일 것이고 사용자는 지원(support)과 접촉하도록(도시된 바와 같이) 지시될 수 있거나, 또는 렌더링 요청을 다시 서브밋하도록(도시 생략) 지시될 수 있다. 대안적으로, 렌더링 잡이 미리 정해진 분량의 시간 내에 완료 상태에 도달하지 않는다면, 렌더링 잡은 자동으로 재시도될 수 있거나, 또는 운영자에게 통지될 것이다.

대안적인 실시예에 있어서, 등급(471) 및 다운로드 카운트(475)와 같은 통계는 대응하는 게임 파일의 등급(271) 및 다운로드 카운트(275)와는 별도로 추적될 수 있다.

본 발명의 대안적인 실시예에 있어서, 도 1에 도시된 것과는 달리, 개개의 콘솔(101) 또는 멀티-노드 구성(100)의 콘솔들(101 내지 104) 중 하나가 인터넷(110)을 통해 렌더링 시스템(130)과 직접 통신할 수 있다(이러한 직접 접속은 도시되지 않음). 본 실시예에서, 파일 공유(123)의 기능들과 사용자 인터페이스(200, 300, 400)의 기능은 콘솔(PC일 수 있음)에서 실행하는 게임에 의해 제공될 것이다.

도 5는 렌더링 시스템(130)에 실시된 예에 관한 것으로서, 온라인 렌더링 시스템에 의한 렌더링 처리(500)의 플로우차트이다. 렌더링 처리(500)의 초기 상태는 개시(501)시에 도시된 바와 같이, 실황의 플레이로부터 게임 파일이 캡처되는 것이다. 게임 파일은 502에서 인터넷(110)을 통해 렌더링 시스템(130)에 의해 접수된다. 일 실시예에서는, 503에서 게임 파일을 렌더링하기 위한 오더가 접수되며, 오더는 도 3과 관련하여 논의된 바와 같은 상세 사항을 포함한다. 그러나, 다른 실시예에서는, 그러한 상세 사항이 미리 정해져 있어서, 렌더링하기 위한 오더가 암시될 수 있고, 503에서 오더를 접수하는 것이 불필요하다. 502에서 접수된 게임 파일 및 503에서 접수된 오더(필요하다면)에 응답하여, 504에서 게임 파일의 렌더링이 렌더링 시스템(130)에 의해 실시되며, 505에서 렌더링 시스템(130)은 렌더링한 오디오/비디오 출력을 미디어 파일로서 캡처한다. 그 후, 505에서 캡처된 미디어 파일은 506에서 인터넷(110)을 통해 요청자 또는 다른 사람들에게 제공된다. 507에서 렌더링 처리(500)는 종료한다.

이러한 모든 시스템들에 있어서, 시스템의 특별한 특징, 사용자 인터페이스들의 세부 사항, 및 처리들의 성능은 본 발명의 시스템을 구현하기 위해 이용되는 아키텍처, 선택된 서버들의 운영 시스템, 선택된 네트워크의 대역폭 및 다른 성질, 및 기입된 소프트웨어 코드에 의존할 것이다. 당업자가 본 명세서에 기술된 처리들을 구현할 수 있도록, 그리고 본 발명의 범위를 실시하기에 적합한 코드 및 사용자 인터페이스를 제공할 수 있도록 하기 위해 그러한 프로그래밍의 상세 사항을 기술할 필요는 없을 것이다. 본 발명의 원리를 구현하기 위해 필요한 소프트웨어 설계 및 프로그래밍의 상세 사항은 본 명세서의 설명으로부터 용이하게 이해될 것이다. 본 명세서에서 특정적으로 예시되고 설명된 본 발명의 기술된 실시예들의 다양한 추가적인 변형들은, 특히 본 발명의 교시의 관점에서, 당업자에게 명백할 것이다. 본 발명은 본 발명의 사상과 범위 내에 들어오는 변형들과 실시 형태들을 모두 포괄하고자 한다. 따라서, 본 발명의 바람직한 실시예들이 개시되었지만, 본 발명은 거기에 한정되지 않고 청구항들의 범위 내에서 달리 실시될 수 있다는 것을 이해할 것이다.

Claims (20)

1. 인터넷에 접속되는 적어도 하나의 게임 시스템, 및 상기 인터넷에 접속되는 하나 이상의 수신자 컴퓨팅 디바이스에 의해 사용되는 컴퓨터에 의해 구현되는 방법으로서,
   상기 적어도 하나의 게임 시스템은 게임을 플레이하도록 구성되고, 상기 방법은,
   a) 렌더링 시스템에 의해 게임 파일을 상기 인터넷을 통해 자동으로 접수하는 단계 - 상기 게임 파일은 상기 게임에 의해 기록되고, 상기 게임이 상기 적어도 하나의 게임 시스템 상에서 플레이된 때 상기 게임의 기록된 실황의 플레이의 구간을 나타내며, 상기 렌더링 시스템은 상기 적어도 하나의 게임 시스템과 상이함 -;
   b) 상기 렌더링 시스템에 의해 상기 게임 파일을 오디오 및 비디오로서 자동으로 렌더링하는 단계;
   c) 상기 렌더링 시스템에 의해 상기 오디오 및 비디오를 오디오/비디오 파일로서 자동으로 캡처하는 단계; 및
   d) 상기 렌더링 시스템에 의해 상기 하나 이상의 수신자 컴퓨팅 디바이스에 상기 오디오/비디오 파일을 상기 인터넷을 통해 자동으로 제공하는 단계 - 상기 오디오/비디오 파일은 상기 게임 이외의 것에 의해 플레이 가능함 -;
   를 포함하는 컴퓨터에 의해 구현되는 방법.
2. 제1항에 있어서,
   상기 렌더링 시스템은 잡 서버 및 복수의 렌더링 클러스터를 포함하고, 각각의 렌더링 클러스터는 상기 게임 파일을 상기 오디오 및 비디오로서 렌더링하도록 구성되는 상이한 게임 콘솔 및 컴퓨터를 포함하고, 상기 방법은
   상기 렌더링 시스템에 의해 렌더링 잡을 상기 인터넷을 통해 자동으로 접수하는 단계;
   상기 잡 서버에 의해 상기 복수의 렌더링 클러스터 중 선택된 렌더링 클러스터의 컴퓨터에 상기 렌더링 잡을 보내는 단계; 및
   상기 선택된 렌더링 클러스터 내의 컴퓨터에 의해 상기 선택된 렌더링 클러스터 내의 상기 게임 콘솔을 명령하여 상기 게임 파일을 로딩하고 재생하여, 상기 게임 파일을 상기 오디오 및 비디오로서 자동으로 렌더링하는 단계 - 상기 선택된 렌더링 클러스터 내의 컴퓨터는 상기 오디오 및 비디오를 상기 오디오/비디오 파일로서 자동으로 캡처함 -
   를 더 포함하는, 컴퓨터에 의해 구현되는 방법.
3. 제2항에 있어서,
   상기 하나 이상의 수신자 컴퓨팅 디바이스에 상기 오디오/비디오 파일을 상기 인터넷을 통해 자동으로 제공하는 단계는
   상기 렌더링 시스템에 의해 상기 오디오/비디오 파일을 저장하는 단계; 및
   상기 하나 이상의 수신자 컴퓨팅 디바이스에 상기 오디오/비디오 파일을 상기 인터넷을 통해 다운로드하는 단계
   를 더 포함하는, 컴퓨터에 의해 구현되는 방법.
4. 제1항에 있어서,
   e) 상기 렌더링 시스템에 의해 오더를 자동으로 접수하는 단계 - 상기 오더는 상기 게임 파일을 렌더링하기 위한 상세 사항을 포함하고, 상기 게임 파일의 자동 렌더링은 상기 오더에 응답하여 상기 오더에 따라 수행되고, 상기 게임 파일에 대하여 렌더링된 상기 오디오 및 비디오의 자동 캡처는 상기 오더에 따라 수행됨 -
   를 더 포함하는 컴퓨터에 의해 구현되는 방법.
5. 제4항에 있어서,
   상기 상세 사항은 해상도를 특정하는, 컴퓨터에 의해 구현되는 방법.
6. 제4항에 있어서,
   상기 상세 사항은 오디오/비디오 파일 포맷을 특정하는, 컴퓨터에 의해 구현되는 방법.
7. 제1항에 있어서,
   접수된 상기 게임 파일은 편집된, 컴퓨터에 의해 구현되는 방법.
8. 인터넷에 접속되는 복수의 게임 시스템, 및 상기 인터넷에 접속되는 적어도 하나의 수신자 컴퓨팅 디바이스에 의해 사용되는 시스템으로서,
   상기 복수의 게임 시스템 중 적어도 하나의 게임 시스템으로부터 게임 파일을 상기 인터넷을 통해 접수하도록 구성되는 적어도 하나의 컴퓨터 - 상기 적어도 하나의 컴퓨터는 상기 복수의 게임 시스템과 상이하고, 상기 게임 파일은 게임에 의해 기록되고, 상기 게임이 상기 복수의 게임 시스템 중 적어도 하나의 게임 시스템 상에서 플레이된 때 상기 게임의 기록된 실황의 플레이의 구간을 나타냄 -; 및
   상기 적어도 하나의 컴퓨터에 접속되는 게임 콘솔 - 상기 게임 콘솔은 상기 적어도 하나의 컴퓨터로부터 상기 게임 파일을 수신하고, 상기 게임 파일을 오디오 및 비디오로서 렌더링하도록 구성됨 -
   을 포함하고,
   상기 적어도 하나의 컴퓨터는 상기 게임 콘솔에 의해 렌더링된 상기 오디오 및 비디오를 오디오/비디오 파일로서 캡처하고, 상기 적어도 하나의 수신자 컴퓨팅 디바이스에 상기 오디오/비디오 파일을 상기 인터넷을 통해 제공하도록 더 구성되고, 상기 오디오/비디오 파일은 상기 게임 이외의 것에 의해 플레이 가능한, 시스템.
9. 제8항에 있어서,
   상기 게임 콘솔은 선택된 게임 콘솔이고, 상기 적어도 하나의 컴퓨터는 렌더링 잡을 접수하도록 구성되는 적어도 하나의 잡 서버 컴퓨터 및 복수의 렌더링 클러스터 컴퓨터를 포함하고, 상기 시스템은 복수의 렌더링 클러스터를 더 포함하고, 상기 복수의 렌더링 클러스터 중 각각의 렌더링 클러스터는 상기 게임 파일을 오디오 및 비디오로서 렌더링하도록 구성되는 게임 콘솔을 제어하도록 구성되는 상기 복수의 렌더링 클러스터 컴퓨터 중 적어도 하나의 렌더링 클러스터 컴퓨터를 포함하고,
   상기 복수의 렌더링 클러스터 중 선택된 렌더링 클러스터는 상기 선택된 게임 콘솔 및 선택된 렌더링 클러스터 컴퓨터를 포함하고,
   상기 적어도 하나의 잡 서버 컴퓨터는 상기 선택된 렌더링 클러스터 컴퓨터에 상기 렌더링 잡을 보내고,
   상기 선택된 게임 콘솔은 상기 선택된 렌더링 클러스터 컴퓨터로부터 명령 및 상기 게임 파일을 수신하고, 상기 명령은 상기 선택된 게임 콘솔을 명령하여 상기 게임 파일을 로딩하고 재생하여, 상기 게임 파일을 상기 오디오 및 비디오로서 렌더링하고,
   상기 선택된 게임 콘솔은 상기 명령에 응답하여 상기 게임 파일을 상기 오디오 및 비디오로서 렌더링하고,
   상기 선택된 렌더링 클러스터 컴퓨터는 상기 오디오 및 비디오를 상기 오디오/비디오 파일로서 캡처하는, 시스템.
10. 제9항에 있어서,
    접수된 상기 게임 파일은 클리핑된, 시스템.
11. 제9항에 있어서,
    상기 적어도 하나의 수신자 컴퓨팅 디바이스에 상기 오디오/비디오 파일을 상기 인터넷을 통해 제공하는 것은
    상기 오디오/비디오 파일을 저장하고, 상기 적어도 하나의 수신자 컴퓨팅 디바이스에 상기 오디오/비디오 파일을 상기 인터넷을 통해 다운로드하는 것을 포함하는, 시스템.
12. 제8항에 있어서,
    상기 적어도 하나의 컴퓨터는 상기 게임 파일을 렌더링하기 위한 상세 사항을 포함하는 오더를 수신하고, 상기 오디오/비디오 파일은 상기 상세 사항에 따르는, 시스템.
13. 제12항에 있어서,
    상기 상세 사항은 해상도를 특정하고, 상기 적어도 하나의 컴퓨터는 상기 게임 콘솔에 상기 해상도를 제공하도록 구성되고, 상기 게임 콘솔은 상기 적어도 하나의 컴퓨터로부터 상기 해상도를 수신하는 것에 응답하여 상기 해상도에서 상기 게임 파일을 렌더링하도록 구성되는, 시스템.
14. 제12항에 있어서,
    상기 상세 사항은 오디오/비디오 파일 포맷을 특정하고, 상기 오디오/비디오 파일은 상기 파일 포맷으로 제공되는, 시스템.
15. 제12항에 있어서,
    상기 오더는 상기 게임 콘솔이 상기 게임 파일을 수신하고 렌더링하도록 이용 가능할 때까지 대기 중인(held in a queue), 시스템.
16. 제8항에 있어서,
    접수된 상기 게임 파일은 편집된, 시스템.
17. 인터넷에 접속되는 복수의 게임 시스템에 의해 사용되는 시스템으로서,
    상기 인터넷에 의해 상기 복수의 게임 시스템에 접속되는 적어도 하나의 스토리지 디바이스 - 상기 적어도 하나의 스토리지 디바이스는 상기 복수의 게임 시스템으로부터 복수의 게임 파일을 상기 인터넷을 통해 수신하도록 구성되고, 상기 적어도 하나의 스토리지 디바이스는 별개의 디바이스이며 상기 복수의 게임 시스템 중 각각의 게임 시스템과 상이하고, 각각의 상기 게임 파일들은 게임에 의해 기록되고, 상기 게임이 상기 복수의 게임 시스템 중 적어도 하나의 게임 시스템 상에서 플레이된 때 상기 게임의 기록된 실황의 플레이의 구간을 나타냄 -;
    복수의 게임 콘솔 - 상기 복수의 게임 콘솔 중 각각의 게임 콘솔은 별개의 게임 콘솔이며 상기 복수의 게임 시스템 중 각각의 게임 시스템과 상이함 -; 및
    상기 복수의 게임 콘솔 및 상기 적어도 하나의 스토리지 디바이스에 접속되는 적어도 하나의 컴퓨팅 디바이스 - 상기 적어도 하나의 컴퓨팅 디바이스는 상기 복수의 게임 파일 중 각각의 게임 파일에 대하여 상기 복수의 게임 콘솔 중 하나의 게임 콘솔을 선택하고, 상기 게임 파일을 재생하기 위해 선택된 상기 게임 콘솔을 지시하도록 구성되고, 선택된 상기 게임 콘솔은 상기 적어도 하나의 컴퓨팅 디바이스에 상기 재생에 의해 생성되는 오디오 및 비디오 정보를 보내고, 상기 적어도 하나의 컴퓨팅 디바이스는 상기 재생에 의해 생성되는 상기 오디오 및 비디오 정보를 미디어 파일로서 캡처하고, 상기 적어도 하나의 스토리지 디바이스 상에 미디어 파일을 저장하도록 더 구성되고, 상기 미디어 파일은 상기 게임 이외의 것에 의해 플레이 가능함 -
    를 포함하는 시스템.
18. 제17항에 있어서,
    상기 적어도 하나의 컴퓨팅 디바이스는 사용자에 의해 생성되는 미디어 공유 서비스에 상기 미디어 파일을 게시하도록 더 구성되는, 시스템.
19. 제17항에 있어서,
    상기 복수의 게임 파일 중 제1 게임 파일은 제1 사용자에 의해 동작되는 상기 복수의 게임 시스템 중 제1 게임 시스템으로부터 상기 적어도 하나의 스토리지 디바이스에 의해 수신되고,
    상기 제1 게임 파일의 재생으로부터 캡처되는 상기 미디어 파일은 상기 복수의 게임 시스템 중 상이한 제2 게임 시스템을 동작하는 상이한 제2 사용자에 의해 다운로드 가능한, 시스템.
20. 제17항에 있어서,
    상기 시스템은 클라이언트 컴퓨팅 디바이스에 의해 사용되는 시스템으로서,
    상기 복수의 게임 파일 중 제1 게임 파일은 제1 사용자에 의해 동작되는 상기 복수의 게임 시스템 중 제1 게임 시스템으로부터 상기 적어도 하나의 스토리지 디바이스에 의해 수신되고,
    상기 제1 게임 파일의 재생으로부터 캡처되는 상기 미디어 파일은 상기 클라이언트 컴퓨팅 디바이스를 동작하는 상이한 제2 사용자에 의해 다운로드 가능한, 시스템.

Images