セーブコードについてみんなで話し合う場所1

OryzaeA

retro_funny wrote:
ゲーム内の実績などをセーブするのってどうやればいいんでしょうか

クラウド変数に進行状況とユーザーID(数値変換要)を保存しておく方法と、進行状況を(暗号化して)パスワードにする方法の2種類が考えられますね。
「セーブ」でプロジェクトを検索すると、参考にできるプロジェクトが見つかると思いますよ。

hikaru-222

このフォーラムの中全部見ましたが、改ざんされず、チートをされないセーブコードを作ることはかなり難しいようですね。
中身で、チート報告の機能を作ってユーザー自身に対策してもらう、等も考えましたが、その場合、チート報告を乱用する人が現れたりしそうです。
他のかたも仰ってましたがとてつもなく長いセーブコードを作成、複雑な暗号化を掛ければ、大抵の人はチートをする気がなくなるでしょうし、そのプログラムの解読をする労力を掛けてまでScratchのゲームでチートをするのが疑問です。
パソコンを常に動かし、データを送り、必要なときだけ送ってもらうタイプの、サーバー構築方式は採算度外視な気がします。(否定ではないが)
クラウドに制限が掛かってる以上、様々な方法を検討に検討を重ねました(首相)が、ふっかつのじゅもん式ではないと、Scratchで作るセーブコードはきついですね;;
議題自体はとても良いもので、かなり見てて参考になりました

Jinenjo_000

VRFを使えばゲームの進行状況、入手アイテム、ガチャの抽選結果などの不正が難しくなるかもしれません。
こちらのVRF を使ったゲーム処理の安全なリモート委譲という記事が参考になります。

hikaru-222

VRFは、仮想ルータを作成したり、ゲームデータの送受信が早くなったり、操作が正しいか確かめられるいい技術ですね。
ただやはり、稼働させるサーバが必要になるみたいですね。

クラウド変数は256文字が限度ですが、普通に256文字超えて、プロジェクトページに戻って確認しても、ちゃんと使えるんですが大丈夫なんですか?

Jinenjo_000

>> #444
ユーザーに公開鍵さえ登録してもらえば、セーブコードをロードするときの検証はローカルでできるかなと思っていましたが…
少なくとも24時間サーバーを稼働させる必要はない気がします。

hikaru-222

よく読んでみました。
うまく組み込めば、Scrachの1プロジェクト内で証明を完結させることもできなくもなさそうですね。
24時間稼働なしでもどうにか作ることは可能かもしれません

choriss55

https://scratch.mit.edu/projects/732379763/
この作品のようにsha256を利用してみるのもありかなと思いました。
時間のあるときに自分でも実装してみたいと思います

tesu2067

初書き込み失礼します。(最初の1Pから5Pくらいまでしか読んでないので既出が多いと思います)
まず、単純に不正なコードの拡散を防ぎたいなら電話番号制限を使用すればいいと思います(回避方法はかなりあるので気休めにもなりませんが)
クラウドに保存するのはやはり難しいようですね….
私が思いつくもので一番有効的だと考えるは、管理者の端末でクラウド変数を常時更新しておき、セーブコードを発行する時にクラウド変数が更新されているか?(中を見るとクラウド変数は無効になる)
をチェックして問題なければセーブコードを発行する。　セーブコード自体の仕組みは、ユーザーネームの文字に応じて暗号化の仕組みを変える(ユーザーネームを数値に変換し、その数値を暗号化に使用するような仕組み)
というのはどうでしょうか。

inoking

「電話番号制限」とは何ですか？

tesu2067

#449
個人的な連絡先を伝えることを防ぐために10桁以上の数字をコメントすると全てXに変わる仕様の事です(分かりづらかったですね)

inoking

それは「ミュート」機能のことですが
セーブコードとどう関係しますか？

tesu2067

#451
HP100 MP50 経験値700 レベル10の状態でセーブをし
「100.50.700.10」のように出力され、コメントすると
「XXX.XX.XXX.XX」のようになります。(実際に検証をしました)

Last edited by tesu2067 (March 2, 2024 05:48:32)

inoking

やっと意図が分かりました。
「単純に不正なコードの拡散を防ぎたいなら電話番号制限を使用すればいい」
というよりも
コメントでのコード拡散は単純にはできないようになっている。
ですね。

sub_luke0814

思いましたが、セーブコード暗号化するとき例えば

データABCは数字
データA、データB、データCを
↓
データAデータBデータC　と繋げて
↓
数字を1→Bのようにしますよね？
そしてそれをリストで管理しますよね。
じゃあそれを中を見るやリミックスボタンに触れたときに消せば、チートを防げると思います。

作って見た
https://scratch.mit.edu/projects/975587061/

Last edited by sub_luke0814 (March 4, 2024 07:31:31)

Jinenjo_000

@choriss55 さん
#1 にこれまでの議論をまとめてもらえませんか？
#74, #87, #92, #389 など

sei6sei

もうなんだか色々見てきましたが、メモリマップが一番手っ取り早いと思います。

sub_luke0814

メモリマップとはなんですか？

choriss55

Jinenjo_000 wrote:
@choriss55 さん
#1 にこれまでの議論をまとめてもらえませんか？
(略)

挙げてもらった箇所に関するまとめを#1に箇条書きしました。不備等があればお知らせください。

choriss55

ミスにより削除

Last edited by choriss55 (April 4, 2024 10:27:56)

newmomizi_txt

授業中に突然アイデアを思いついたのでメモ&共有。過去に出ていたらごめんなさい。

セーブコードを共有するのを防ぐ方法としては、「そもそもセーブコードを1回しか使えない、中断セーブ方式にする」というものがあります。
クラウド変数をビットフラグ列と見なして、セーブ時にランダムなビット(0のもの)を選んで1に変え、セーブコードにそのアドレスを含めます。
ロード時には該当するビットが1であることを確認した後0に戻す、というようにすれば、同じコードを複数回使用することはできなくなります。

ここで、2^8504 < 10^2560 < 2^8505なので、クラウド変数を全て使用した場合8504のセーブデータが同時に存在できることになります。

true/falseのフラグの代わりに、「絶対に0になることのないチェックサム値」を用いれば、パスワードの捏造も同時に防げそうです。保存できる数は減ってしまいますが。

Discuss Scratch