アカウント名:
パスワード:
ガチャで確率操作が行われていないことをユーザーが検証可能にすべきだと思います。
技術的には特に難しくはなく、
とすることで、どの乱数が「当たり」なのかは暗号鍵が無ければ分からないことから、ソシャゲー運営者による不正な操作を防ぐことができます。また、暗号化された対応表データはソシャゲー事業者側にもわたっているので、乱数の発生後にユーザーが対応表を書き換えることもできません。
ユーザーがガチャを引くたびに行う、対応表の作成・暗号化・暗号化された対応表データの送信の方式については、標準化して RFC にして、ユーザーはオープンソースの信用できるアプリを使えば良いと思います。ここらへんのデータのやり取りは、アプリ間連携（Intent など）で自動化できるので、ユーザーの手間はインストールするアプリが1つ増えるだけです。
こうすることで、今まで不透明だったガチャが透明になり、ユーザーは安心して納金できるし、それによりガチャ事業者も潤います。まさに、Win-Win ではないでしょうか。
ユーザが後で渡すカギを細工して「もらった番号があたり」に解読できるような手法を編み出すことが考えられますね。
ハッシュ入れとけとか最初に業者からnonce的なものを渡すとか(どうせ範囲とか確率とか要るし)になるんですかね
電子データに実体的なものを見すぎなんじゃないかなあ
Androidならともかく、iOSでそれを実装するのは骨が折れる気がする。
あと10連ガチャとかを何度も回す人からしたら「んな面倒なことやってられるか」としか思われないよ。
さすがにユーザの操作は増えないでしょあるとすればプラットフォームかゲームSDKに装備されるんだろうし気にするほどTATが長くなることもないんじゃないすか
その処理を組み込むコストはどこから持ってくるの？人件費はただだと思ってる？その処理を組み込む過程で生まれたバグが原因で、大量のカードを盗まれたりして損害を受ける可能性もコストに転嫁されるけどそれはどうするの？ユーザー側で処理が増えることによって、ゲームのレスポンスが下がるとユーザーが離れるけどそれについてはどう考えてる？これらのデメリット全て合わせても、「ユーザーは安心して納金できるし、それによりガチャ事業者も潤い」のメリットの方が高いとか思ってる？透明性がどうこう言ってるのなんてプレイヤーの極一部だよ。殆どソシャゲで課金なんてしない層が騒いでるだけ。
# 大抵の問題はデメリットを無視すれば「僕の考えた最強の解決手段」は正しいよ
そもそも、そんな仕組み導入したって、検証できるユーザーはごく一部のエンジニアだけだし。ユーザーの安心には程遠い。ユーザーが安心できると言いつつ、全くユーザーの負担を考慮してない。で、仮に技術的に出来たとしても、ゲームがアップデートされる度に適切に処理されているかユーザーが検証するとか有り得ないし。企業はクライアント側のコードを公開しないといけないし、ユーザーはそのコードと配布されてるバイナリが一致して、そのコードに抜け道が無くネットワーク上に流れるデータにも細工されてない事を毎回検証しないといけない。最近はゲームでも通信が暗号化されてるから、パケット捕まえるだけでは解析出来ないし。
>透明性がどうこう言ってるのなんてプレイヤーの極一部だよ。殆どソシャゲで課金なんてしない層そりゃ透明性に疑問を抱いている人はプレイしないか課金しないだろうから当然。比較すべきは透明性に疑問を持たず射幸心のまま課金しているユーザーの数と、透明性に疑問を持っていてプレイしてない、もしくはごく少額しか課金していないユーザーの数の割合だろそれなら無視できるほどのごく一部だと言い切るのは難しいと思うがな
> ユーザー側で処理が増えることによって、ゲームのレスポンスが下がるとユーザーが離れるけどそれについてはどう考えてる？演出だなんだを色々仕込んでるから、スキップしたとしても然程ではないだろ。表を全送信だと抽選空間が広い時にちょっと時間掛かるけど、表を固定してインデックスをシャッフルするためのキーを表の代わりに使えば似たようなことは出来るし。損害を受けるとかに関してはそもそもチートやバグがが乱用されるまでノーガードだったりするから攻撃側も防衛側も今更だろう。
コストは透明性とペイすると思った事業者がやればいい。透明性を上げたいやつは開発コストをオープンなライブラリでも書くことで補填でもすればいい。
むり。複雑にすればするほどバグは入り込みますね。あとは分かるよね?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
ガチャで確率操作が行われていないことをユーザーが検証可能にすべき (スコア:2)
ガチャで確率操作が行われていないことをユーザーが検証可能にすべきだと思います。
技術的には特に難しくはなく、
とすることで、どの乱数が「当たり」なのかは暗号鍵が無ければ分からないことから、ソシャゲー運営者による不正な操作を防ぐことができます。また、暗号化された対応表データはソシャゲー事業者側にもわたっているので、乱数の発生後にユーザーが対応表を書き換えることもできません。
ユーザーがガチャを引くたびに行う、対応表の作成・暗号化・暗号化された対応表データの送信の方式については、標準化して RFC にして、ユーザーはオープンソースの信用できるアプリを使えば良いと思います。ここらへんのデータのやり取りは、アプリ間連携（Intent など）で自動化できるので、ユーザーの手間はインストールするアプリが1つ増えるだけです。
こうすることで、今まで不透明だったガチャが透明になり、ユーザーは安心して納金できるし、それによりガチャ事業者も潤います。まさに、Win-Win ではないでしょうか。
Re:ガチャで確率操作が行われていないことをユーザーが検証可能にすべき (スコア:2)
ユーザが後で渡すカギを細工して「もらった番号があたり」に解読できるような手法を編み出すことが考えられますね。
ハッシュ入れとけとか最初に業者からnonce的なものを渡すとか(どうせ範囲とか確率とか要るし)になるんですかね
Re: (スコア:0)
電子データに実体的なものを見すぎなんじゃないかなあ
Re: (スコア:0)
ユーザーがガチャを引くたびに行う、対応表の作成・暗号化・暗号化された対応表データの送信の方式については、標準化して RFC にして、ユーザーはオープンソースの信用できるアプリを使えば良いと思います。ここらへんのデータのやり取りは、アプリ間連携（Intent など）で自動化できるので、ユーザーの手間はインストールするアプリが1つ増えるだけです。
Androidならともかく、iOSでそれを実装するのは骨が折れる気がする。
あと10連ガチャとかを何度も回す人からしたら「んな面倒なことやってられるか」としか思われないよ。
Re:ガチャで確率操作が行われていないことをユーザーが検証可能にすべき (スコア:2)
さすがにユーザの操作は増えないでしょ
あるとすればプラットフォームかゲームSDKに装備されるんだろうし
気にするほどTATが長くなることもないんじゃないすか
Re: (スコア:0)
その処理を組み込むコストはどこから持ってくるの？人件費はただだと思ってる？
その処理を組み込む過程で生まれたバグが原因で、大量のカードを盗まれたりして損害を受ける可能性もコストに転嫁されるけどそれはどうするの？
ユーザー側で処理が増えることによって、ゲームのレスポンスが下がるとユーザーが離れるけどそれについてはどう考えてる？
これらのデメリット全て合わせても、「ユーザーは安心して納金できるし、それによりガチャ事業者も潤い」のメリットの方が高いとか思ってる？
透明性がどうこう言ってるのなんてプレイヤーの極一部だよ。殆どソシャゲで課金なんてしない層が騒いでるだけ。
# 大抵の問題はデメリットを無視すれば「僕の考えた最強の解決手段」は正しいよ
Re: (スコア:0)
そもそも、そんな仕組み導入したって、検証できるユーザーはごく一部のエンジニアだけだし。
ユーザーの安心には程遠い。ユーザーが安心できると言いつつ、全くユーザーの負担を考慮してない。
で、仮に技術的に出来たとしても、ゲームがアップデートされる度に適切に処理されているかユーザーが検証するとか有り得ないし。
企業はクライアント側のコードを公開しないといけないし、ユーザーはそのコードと配布されてるバイナリが一致して、そのコードに抜け道が無くネットワーク上に流れるデータにも細工されてない事を毎回検証しないといけない。
最近はゲームでも通信が暗号化されてるから、パケット捕まえるだけでは解析出来ないし。
Re: (スコア:0)
>透明性がどうこう言ってるのなんてプレイヤーの極一部だよ。殆どソシャゲで課金なんてしない層
そりゃ透明性に疑問を抱いている人はプレイしないか課金しないだろうから当然。
比較すべきは透明性に疑問を持たず射幸心のまま課金しているユーザーの数と、透明性に疑問を持っていてプレイしてない、もしくはごく少額しか課金していないユーザーの数の割合だろ
それなら無視できるほどのごく一部だと言い切るのは難しいと思うがな
Re: (スコア:0)
> ユーザー側で処理が増えることによって、ゲームのレスポンスが下がるとユーザーが離れるけどそれについてはどう考えてる？
演出だなんだを色々仕込んでるから、スキップしたとしても然程ではないだろ。
表を全送信だと抽選空間が広い時にちょっと時間掛かるけど、表を固定してインデックスをシャッフルするためのキーを表の代わりに使えば似たようなことは出来るし。
損害を受けるとかに関してはそもそもチートやバグがが乱用されるまでノーガードだったりするから攻撃側も防衛側も今更だろう。
コストは透明性とペイすると思った事業者がやればいい。
透明性を上げたいやつは開発コストをオープンなライブラリでも書くことで補填でもすればいい。
Re: (スコア:0)
むり。
複雑にすればするほどバグは入り込みますね。
あとは分かるよね?