ロック画面入力コールバックの有効化¶
ホスト PC が Windows のロック画面に切り替わると、OS のセキュリティポリシーにより OS レベルのキーボードおよびマウス入力がブロックされます。リモート環境では画面と音声のストリーミングは可能ですが、実際のゲーム操作はできない状態になります。
従来は、リモートユーザーが Windows アカウントのパスワードを入力してロックを解除する必要がありました。ただし、この方法には PC 全体の制御権限が露出するリスクと、接続手順が煩雑になる問題がありました。
Remote Play Plugin は、Hive Console の Remote Play 設定で ロック画面を解除せずにプレイ 機能を提供します。この機能を有効化すると、キーボード、マウス、タッチ、ジョイスティック、ホイール、ズームなどのすべての入力イベントが ゲームコールバック に直接渡されます。
主な動作¶
- コールバックベースの配信: すべての入力イベントは
RegisterCallbackで登録されたコールバック関数にeventType: "Control"として渡されます。ロック状態に関係なく同じように動作し、ロック解除後もコールバック配信は維持されます。 - OS 入力経路の迂回: OS の
SendInput経路は使用されません。Windows のロック状態に関係なく、一貫した入力イベントを受信します。 - ゲームへの直接注入: ゲームはコールバックで受信した入力データを内部入力システムに直接注入し、ロック状態と通常状態の両方で同じ操作を処理します。
事前準備¶
この機能を適用する前に、以下を準備してください。
- Remote Play Plugin のインポート
- イベント受信用コールバック関数の登録
- 対応 SDK / プラグインバージョン:
- Remote Play Plugin 1.2.0 以上
- Hive SDK v4 26.4.0 以上
Warning
RegisterCallback によるコールバック登録なしで Hive Console の ロック画面を解除せずにプレイ 機能を有効化すると、すべての入力イベントが失われ、リモート操作が困難になります。必ず先にコールバックを登録してください。
Control イベントプロトコル¶
ロック画面を解除せずにプレイ 機能を有効化した後、コールバックで渡される入力イベントは チャットイベント と同じ JSON 形式で渡され、eventType の値は "Control" に固定されます。実際の入力種類は内部の controlType で区別します。
Envelope 共通構造¶
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "<Key | Click | Wheel | Zoom>",
"controlValue": {
"value" : "<controlType-specific-value>",
"action" : "<controlType-specific-action>"
}
}
},
"etc" : { }
}
| フィールド | 説明 |
|---|---|
version | "1.02.00" 固定 |
eventType | 常に "Control" |
eventValue.value.controlType | 入力種類。"Key" / "Click" / "Wheel" / "Zoom" の 4 種 |
eventValue.value.controlValue.value | controlType 別データ(座標、キーコードなど) |
eventValue.value.controlValue.action | controlType 別の状態またはアクション |
etc | 空オブジェクト |
controlType = "Key" - キーボード入力¶
キーボード単一キーの押下または解放状態を渡します。Web クライアントで発生したキーボード入力とジョイスティック入力はいずれも controlType に変換されます。
| フィールド | 値 |
|---|---|
controlValue.value | Windows Virtual-Key Code の 16 進文字列(例: "0x41" = 'A', "0x57" = 'W', "0x20" = Space) |
controlValue.action | "Down" または "Up" |
ジョイスティックの方向コードは、マッピング設定(WASD / DIRECTION)に従って単一キーイベントに分解され、controlType として渡されます。ゲーム側ではキー入力とジョイスティック入力が同じ形式に見えます。斜め移動もホストが 2 つの単一キーイベントに分解して送信します。
例 - 'A' キー押下
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Key",
"controlValue": { "value": "0x41", "action": "Down" }
}
},
"etc" : { }
}
例 - ジョイスティック上(WASD マッピング時の 'W' キー)
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Key",
"controlValue": { "value": "0x57", "action": "Down" }
}
},
"etc" : { }
}
controlType = "Click" - マウスおよびタッチ座標入力¶
マウスクリック、マウス移動、タッチ座標を渡します。Web クライアントで発生したマウス入力とタッチ入力はいずれも、GetClientRect() を基準としたゲームウィンドウのクライアント領域ピクセル座標に自動変換されて渡されます。
| フィールド | 値 |
|---|---|
controlValue.value | "x#y" 形式。単位は ゲームウィンドウのクライアント領域ピクセル座標(小数第 1 位)。Web クライアントの 0-1000 正規化座標がホストでピクセルに変換されて渡されます。 |
controlValue.action | "Down"、"Up"、または "Move" |
Note
タッチ入力の場合、Click タイプへの変換時に touchID 情報は保持されません。
座標変換の参考¶
curWidth / curHeight は、ゲームウィンドウの GetClientRect() を基準としたクライアント領域サイズです。そのため、ゲームではウィンドウ座標としてそのまま適用してください。
| Web クライアント位置 | 正規化座標(inbound) | ピクセル座標(curWidth=1053, curHeight=1585 の例) |
|---|---|---|
| 左上 | "0.0#0.0" | "0.0#0.0" |
| 右上 | "1000.0#0.0" | "1053.0#0.0" |
| 左下 | "0.0#1000.0" | "0.0#1585.0" |
| 右下 | "1000.0#1000.0" | "1053.0#1585.0" |
| 中央 | "500.0#500.0" | "526.5#792.5" |
例 - マウスクリック(Down -> Up)
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Click",
"controlValue": { "value": "526.5#792.5", "action": "Down" }
}
},
"etc" : { }
}
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Click",
"controlValue": { "value": "526.5#792.5", "action": "Up" }
}
},
"etc" : { }
}
例 - ドラッグ(Move)
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Click",
"controlValue": { "value": "645.1#681.7", "action": "Move" }
}
},
"etc" : { }
}
controlType = "Wheel" - マウスホイール¶
マウスホイールのスクロール動作を渡します。
| フィールド | 値 |
|---|---|
controlValue.value | "x.0#y.0" 形式。マウスカーソルの現在のピクセル座標(ゲームウィンドウのクライアント領域基準)。Web クライアントが送信したスクロール段階情報は失われます。 |
controlValue.action | "Up"(上へスクロール)または "Down"(下へスクロール) |
例 - ホイールダウン(マウス位置 1234.0 px, 567.0 px)
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Wheel",
"controlValue": { "value": "1234.0#567.0", "action": "Down" }
}
},
"etc" : { }
}
controlType = "Zoom" - ズームイン/アウト¶
カメラまたはマップ画面のズームイン/アウト動作を渡します。
| フィールド | 値 |
|---|---|
controlValue.value | 常に "1" 固定。Web クライアントが送信したスクロール段階情報は失われます。 |
controlValue.action | "In"(拡大)または "Out"(縮小) |
例 - ズームイン
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Zoom",
"controlValue": { "value": "1", "action": "In" }
}
},
"etc" : { }
}
例 - ズームアウト
{
"version" : "1.02.00",
"eventType" : "Control",
"eventValue": {
"value": {
"controlType" : "Zoom",
"controlValue": { "value": "1", "action": "Out" }
}
},
"etc" : { }
}
入力タイプ変換マッピング概要¶
Web クライアントが送信した元の入力タイプが、ホストのコールバックイベントに変換されるマッピング構造です。
| Web クライアント入力 | コールバック controlType | 主な変換 / 情報損失 |
|---|---|---|
| Key | "Key" | VK 16 進値をそのまま使用 |
| Joystick | "Key" | 方向コード -> WASD / DIRECTION マッピング -> 単一キーに分解 |
| Click | "Click" | 座標正規化 -> ピクセル変換 |
| Touch | "Click" | 座標正規化 -> ピクセル変換、touchID は未送信(重複する Down でマルチタッチを判定) |
| Wheel | "Wheel" | 段階情報 -> マウスピクセル座標に置換 |
| Zoom | "Zoom" | 段階情報 -> 常に "1" 固定 |
ステータス(Event)/ チャット(Message)イベントは、この Control イベントでは渡されず、既存のプロトコル仕様に従って別途渡されます。
ゲーム側の入力処理ガイド¶
Hive Console の Remote Play 設定で ロック画面を解除せずにプレイ 機能を有効化すると、Remote Play は入力イベントを OS の入力キューに送信せず、登録されたコールバックを通じてゲームに直接渡します。
そのため、コールバックで受信した入力イベントは、Unity Input System や Unreal Input Subsystem など、ゲーム内部の入力システムに直接渡して処理する必要があります。
この方式は、Windows のロック画面環境で SendInput や SendKey などの OS レベル入力注入が制限される問題を迂回するための構造です。入力イベントはゲームプロセス内部で直接ディスパッチされるため、ロック画面状態と通常状態を区別せず、同じ処理経路を使用することを推奨します。
つまり、ロック画面を解除せずにプレイ 機能を有効化した後は、このコールバックで渡されるすべての入力イベントを受信し、ゲームの内部入力システムに渡す方式で実装することが望ましいです。これにより、ロック画面状態に関係なく一貫した入力処理とリモートプレイ動作を保証できます。
- Unity:
InputSystem.QueueEventまたは独自の入力マネージャーでディスパッチ - Unreal Engine:
FSlateApplication::OnKeyDown / OnMouseButtonDownなどの Slate イベントでディスパッチするか、ゲーム独自の入力マネージャーを使用
ロック画面環境でのバックグラウンドレンダリングとオーディオ処理ガイド¶
Windows のロック画面環境で Remote Play を使用するには、ゲームがバックグラウンド状態でも正常に動作できる必要があります。多くのゲームエンジンはフォーカスを失ったりバックグラウンド状態に切り替わったりすると、CPU 使用量を抑えるためにレンダリングを停止またはフレームを制限し、オーディオ再生も一時停止します。リモートストリーミングを正常に維持するには、ゲームプロセスがバックグラウンドでも動作するように設定を変更する必要があります。
1. Remote Play 接続状態に応じた推奨ポリシー¶
ゲームは Remote Play の接続状態を確認し、リモートユーザーが接続中かどうかを判断する必要があります。推奨動作は以下のとおりです。
| 接続状態 | 推奨動作 |
|---|---|
| 未接続 | 既存のゲームポリシーを維持。バックグラウンド移行時にレンダリングやオーディオを停止可能 |
| 接続中 | バックグラウンド状態でもレンダリングを維持。バックグラウンド状態でもオーディオ出力を維持 |
接続状態は ステータスイベントコールバック(eventType: "Event"、value REMOTE_PLAY_CONNECTED / REMOTE_PLAY_DISCONNECTED)で判定できます。
2. バックグラウンドレンダリングの維持¶
ロック画面状態でも Remote Play が画面をキャプチャできるように、レンダリングループを継続して動作させる必要があります。確認項目の例は以下のとおりです。
- フレーム更新を停止しない
- レンダーループを維持する
- カメラレンダリングを維持する
- UI 更新を維持する
- バックグラウンドフレーム制限ポリシーを確認する
Warning
バックグラウンド状態でレンダリングが停止すると、Remote Play では最後の画面が送信され続けるか、黒い画面が表示される場合があります。
3. バックグラウンドオーディオ出力の維持¶
Remote Play はゲームプロセスから出力されるオーディオをキャプチャし、リモートプレイヤーに配信します。そのため、以下のようなバックグラウンドオーディオ遮断ポリシーを無効化する必要があります。
- Focus Lost 時のオーディオ一時停止
- Window Deactivate 時の Audio Engine 停止
- Background Mute 機能の有効化
Warning
バックグラウンド状態でオーディオ出力が停止すると、リモートプレイヤーはゲームサウンドを聞けなくなります。
エンジン別の確認事項と参考¶
Unity¶
Unity はデフォルトでバックグラウンド移行時に更新を制限する場合があります。ロック画面 Remote Play 機能を使用する場合は、以下のようにバックグラウンド実行を有効化することを推奨します。
フォーカス喪失時にオーディオを停止するカスタムロジックがある場合は、Remote Play の接続状態を考慮して例外処理してください。
Unreal Engine¶
Unreal Engine プロジェクトでも、フォーカス喪失時に Tick、レンダリング、またはオーディオ処理を制限する設定が適用されていないか確認する必要があります。特に以下の項目を確認することを推奨します。
- Background Tick の動作有無
- Focus Lost 時の Pause 処理有無
- Audio Mixer の動作有無
- バックグラウンド FPS 制限ポリシー
Remote Play 接続中は、バックグラウンド状態でも正常なゲームループが維持されるように実装する必要があります。
推奨動作シナリオ¶
- ユーザーが Windows のロック画面状態に切り替える
- Remote Play クライアントが接続する
- ゲームが接続状態を検知し、バックグラウンドレンダリングおよびオーディオ出力を維持する
- ゲームレンダリングを継続
- ゲームオーディオ出力を継続
- Remote Play Plugin が画面とオーディオを正常にキャプチャして送信する
- リモートユーザーがゲーム画面とサウンドをリアルタイムで受信する
- 入力イベントは Remote Play 入力
Controlコールバックを通じてゲーム内部の入力システムに渡される
必須確認の概要
ロック画面環境で Remote Play を正常に動作させるには、以下の 2 つの条件をすべて満たす必要があります。
- Hive Console の Remote Play 設定で ロック画面を解除せずにプレイ 機能を有効化し、入力イベントをゲーム内部の入力システムに渡す必要があります。
- Remote Play 接続中は、バックグラウンド状態でもレンダリングとオーディオ処理を維持する必要があります。
どちらか一方でも満たされない場合、画面停止、サウンド出力エラー、操作困難などにより正常に動作しない可能性があります。