読者です 読者をやめる 読者になる 読者になる

コピーガード

http://www.4gamer.net/games/036/G003691/20080508045/
海外でもそうなのかー、というか、FPSもプロテクトなんもなしなソフト多いのかー、という2点で意外。
exceptionは1.03パッチのダウンロード数が出荷数の3倍くらいでした。同人で出す以上コピーは覚悟の上だけど、買ってくれた人に申し訳ない気分になる。


同人でやってる内は今後作品出すとしてもプロテクションかける気はあんまりないんだけど、技術的に面白そうなので考えるだけ考えてみる。
とりあえず、やる以上は生半可なことはできない。脆弱なプロテクションはコピーされた上に正規ユーザーに不便を強いるだけの結果に終わる。


ユーザー識別と、不正ユーザーが実行できないようにする2つの仕組みが必要になるわけで、まずはユーザーをどう識別するか。
個別に詳細に検証しようと思ったけど、途中で面倒になってきたので以下全部箇条書き。


ID/passwordのアカウント方式
・おなじみの方式。
・PCが変わったりしても平気という利点があるが、それが同時にアカウントの共有が可能という欠点にもなる。(同じアカウントが同時に使われようとした時弾くようにしかできない)


マシン単位で識別する方式
・LANカードのMACアドレスとかを識別子にする方式。業務用ソフトはこの方式使ってるのが結構あった気が。
・PC変えたら再度オーソライズが必要なのが少々煩わしい
・偽装を防ぐ手立てが多分ない(送信する識別子を改竄することは可能だし、そもそもMACアドレスは変更可能だったはず)ので、ID/password方式のアカウント共有に相当することはこっちでも完全には防げない。けど、ID/password方式よりはいくらか強固。


以下、どのように不正ユーザーが実行できないようにするか。


単純な鍵認証
・起動時に認証サーバーから鍵となるデータを得、有効なデータを得られたときだけ起動する方式
・「有効なデータを得られなかったらエラー出して強制終了」する部分を潰されたら終わる。チェックサムとかで強化はできるが、それも潰せるので根本的対策にはならない
・あと、簡単にエミュレーションサーバ作れそう
・なので、サーバーと継続的に通信して、正常な応答を得られないとゲームが成り立たないようにする仕組みが必要


リソース(画像、モデル、音、スクリプト等のデータ)をサーバーに置く
・インストールした状態ではゲームの進行に必要なリソースの一部(全部でもいいけど)が抜けており、それらは必要になる度(ステージ変遷時とか)にサーバからダウンロードする、という方式。
・当然ながらデータはファイルに残さず、全てメモリ上で扱う
・通信部分を潰したらリソースが得られず、ゲームが進行できなくなり、そこそこ強固なんじゃないかと思われる
・ただ、これだけだと簡単にエミュレーションサーバ作れそうなので、通信データは日付とかを鍵にした暗号化をかけた方が良いかもしれない
・転送量がやや心配だが、それなりに現実的だと思われる


内部処理の一部をサーバーに委譲
・キャラクタ情報とかをサーバーに送って、サーバー側で進行処理やる方式
・例えばexceptionなら、毎フレーム全キャラ情報サーバーに送って衝突判定結果をサーバーから貰うとか
・サーバーと通信しないと完全に進行不能、かつエミュレーションサーバ作るのも困難で、非常に強力なプロテクトになり得る
・しかし、サーバーの負担が大きすぎる。現在のPCスペックではあまり現実的ではない
・また、毎フレームとか頻繁にやろうとすると遅滞が生じるのが避けられない


内部処理は全部サーバー側で
・ユーザー側は入力情報を送るだけで内部処理は全部サーバーで行い、画面は動画として送る方式
・副次的効果として、マルチプラットフォーム対応が楽になる。ブラウザから遊べるようにもできそう。
・理想的な方式だが、サーバーの負担が一番大きい。遅滞の問題も。現在のPCスペックではあまり現実的ではない
・タイトル忘れたけどこれやってた例が以前あったような


この方面にはあんま詳しくないので、もっといい方法があったり見当違いな記述が含まれてるかもしれんけど。
以上の思いつく範囲では、マシン単位で識別する方式にして、リソースをサーバーに置く方式のプロテクトかけるのが現状一番現実的かつそこそこ強固なんじゃないかと思われる。

だけどそれ以前の問題として、同人のパッケージ販売だとどうやってアカウントを有効化すればいいのかという問題が。商用ソフトみたいに一意のキーコードをCDケースにシールで張ったりできればいいけど、CDプレス屋でそれできるところあるのかしら。
あと、ユーザー数にもよるけど認証サーバは最低でも3つはミラーが必要そう。sakuraでのサイト運営経験的に、503は割とあっさり出る。Google App Engineで認証サーバプログラム作るのもいいかもしんない。(こういう使い方が許されるのかわからんけど)

まあ、まともなプロテクト入れようとしたら、技術面だけでなく流通面でも難しくなりそう。