>>#40
今はクラウド変数が0.1秒に一度更新できるため、簡単にオンラインのアクションゲームが作れます。（ラグがあることを踏まえたうえで）
また、最近では、これのような十人以上のオンラインゲームも作られています。griffpatchさんのこの動画なども参考にすれば、作ることはできます。あとは、オンラインで、軽いプロジェクトについて考えて、作る必要がありそうです。（3dゲームなどは、そもそも重いため、オンラインにしてもラグがひどすぎる等）

サーバーと通信する系のオンラインゲームの開発をしたいのですが、
参考になるプロジェクトがあれば教えてほしいです。

今主流なのはP2Pで完結するやつですかね？

Scratchでは、サーバーを介さないとクラウド変数を変更できないためP2Pは実装できないかと。

存在するのは
①作成者がサーバーを用意し、更新するタイプ
②ユーザーがクラウド変数を更新するタイプ
だけだと思います。


追記
①のサーバーは、Scratchのサーバーではなくラズベリーパイなどで作られたデータ更新用のサーバーです。

データの流れ
①
ユーザー→Scratchのサーバー→更新用のサーバー→Scratchのサーバー（→ユーザー）
②
ユーザー→Scratchのサーバー（→ユーザー）

kouryou118103 wrote:

Scratchでは、サーバーを介さないとクラウド変数を変更できないためP2Pは実装できないかと。

存在するのは
①作成者がサーバーを用意し、更新するタイプ
②ユーザーがクラウド変数を更新するタイプ
だけだと思います。

2のことをプレイヤー同士の通信で完結するのでP2Pと呼んでました。
厳密な用語の意味としては正しくなかったですね

Scratch 1.4の隠し機能であるMeshを使うと、サーバーに決めたScratchとクライアントとなる複数のScratch間で直接通信ができます。できるのはメッセージの送受信と「すべてのスプライト用」変数の共有です。Scratch 1.4時代はこれとVPNを組み合わせてネットワーク対戦が行われていました。Meshはいまでも一部の中学校の技術科の授業で使われています。Scratch 3.0のMODであるSmalrubyにはこれとほぼ同じ拡張機能があります。

0.1秒の制限っていうのは送信時の制限なので、受信時は制限がない。
なので、受信側で値が衝突しないようにすれば、いくらでも早く更新できるってことを言っていますかね？

サーバーを複数用意して0.1秒を切っていますか？（と思ったらサーバー使っていないようでした）
そこまで速いと今度はスクラッチ側で受信できなくなりそうですが…

完全にサーバーありきな仕組みですが、
オンラインゲームにおけるセッション(ルーム?)の分け方を考えました。
サーバーありのオンラインゲームはあまり見かけないので既出かはわかりませんが…

セッションについて
大抵の場合、同じプロジェクトで遊んでいるプレイヤー全員のデータを全員が知る必要はない。
例えば、
- 人狼 → 10人以下でプレイするのでその他のプレイヤー(ルーム)の情報はいらない。
- バトロワ → 同じマッチングにいるのは30人程度で、その他のプレイヤー(マッチング)情報の情報はいらない。
- MMORPG → 一見全員分のデータが必要そうに見えるが、処理的に50人もいらない。（大体描画しきれない）

なので、人数ごとにセッションを分けられれば、余計なデータを処理しなくて済む&ラグが少なくなる。

セッションの割り当て方法
● サーバー
1) サーバーは待機中のクライアントをセッションに追加していく。
2) セッションが人数上限に達したら、サーバーはそのプロジェクトを新しいセッションのプロジェクトに更新する。
- 新しいセッションプロジェクトは、クラウド変数名を重複しないように変更し、
セッションに参加するクライアント名を参加リストに保存しておく。
3) 2で作ったセッションに参加できるクライアントに、プロジェクトの再読み込みを促す。

● クライアント
1) クライアントは待機中であることをサーバーに知らせる。
2) サーバーから、再読み込み命令が出るまで待機する。
3) 命令が来たらクライアントはプロジェクトを手動で再読み込みする。

想定事項
A) セッション参加中にプロジェクトを再読み込みすると、元のセッションに戻れない
- すでに次のセッションになっている可能性があるため
→
それを許容するゲーム設計が望ましい。
例えば、対戦ゲームならセッションに戻れなくてもいい。むしろペナルティを与える。
MMORPGならどのセッションに入っても、ほぼ同じなので関係ない。
→
マイクラのような何回も同じセッションに出入りする必要がある場合。
サーバーにセッションidを知らせて、後は同じ流れで目当てのセッションに参加する。
セッションidなどは、サーバー、クライアント共にわかるようにしておく必要がある。
この方法では前からこのセッションにいるクライアントのプロジェクトは古いため、データを同期するのはサーバーで少し工夫する必要がある。
→
また、キャッシュ保持の技術を使って、短時間ならセッションidを保持できるかもしれない。

B) 複数タブや、入退出の繰り返しなどで同じクライアントが複数セッションに参加してしまう
→ 古いセッションはもう読み込めないのであまり問題はないと思うが、サーバー側で配慮する必要がある。

セッション数の上限
おそらくない。（クラウド変数名が被らないようにするだけ）

使用技術・知識
・クラウド変数をwebSocketで操作する
・自動でプロジェクトを更新する (未確認)
・クラウド変数名が同じなら値は更新されるため、プロジェクトの新旧は関係ない。
・webSocketを新しく作れば、同じアカウントでもクラウド変数更新できる。（1つのアカウントですべて賄える）
・プロジェクトページを再読み込みすると、プロジェクトは毎回新しく読み込まれる。（キャッシュ関係ないみたい?）
- 「キャッシュが残っているので何回か再読み込み…」をしないで済む


最低限の確認しかしていないのでまだ机上の空論ですが、これができればいくらでも人数が増やせそうです。

ターボワープでオンラインゲームを作っている者です。
質問です。

例えばですが、
　0102030405　みたいな文字列がクラウドに入っていたとして、

この文字列の02の部分を、88とかに変えたいとき、

　01を 変数1 にメモ、
　030405を 変数2 にメモ、

変数1 と 88 と 変数2 をくっつけてクラウドへ提出
というやり方を使っていたのですが、

もちろんオンライン　ほかの人もいるという事なので、
この方法だと自分がデータを送っている間にほかの人がデータを書き換えてしまって、自分のメモが古くなってしまい、
クラウドにデータを送った時点で他の人のデータを過去の物に書き換えてしまうという不具合が起きてしまいます。

一つのクラウド変数に複数のデータを複数人で扱う時、ほかの人の分を破壊したり、
いるはずの人がいなくなったりしない方法を知っている方
教えてください！お願いします

#50
この辺りで、「複数人がほぼ同時に書き換えを行ってしまいデータの整合性が取れなくなってしまう問題」の解決策について話し合っていました。
もしかしたら参考になるかもしれません。
https://scratch.mit.edu/discuss/post/7444528/

なぜかクラウドリストの同期ができません
https://scratch.mit.edu/projects/1147886963/

tomato_curry wrote:

なぜかクラウドリストの同期ができません
https://scratch.mit.edu/projects/1147886963/

「☁ クラウド変数」という名前になっているだけなので、通常の変数になってしまっています。
「クラウド変数 (サーバーに保存)」にチェックを入れて、クラウド変数を作成し、通常の変数をクラウド変数に置き換えれば、正しく動作するはずです。

僕はクラウド変数使ってもダメなんすよ（・_・）

投稿ミスなので削除します。

私質問がありまして、答えていただけると嬉しいです。

1：スク友が、時差を利用してそのプロジェクトで今遊んでいる人の経度が分かるプログラムを作っていましたが、その情報をクラウド変数で共有することはOKなのでしょうか？コミュガを見ている限りだとグレーゾーンだと思いますが、クラウドショック時のQ&Aには書いていなかったので、聞きたいです。
2：@TimMcCool様のアモアスで、チャットがあると思いますが、私には定型文型チャットと、クラウドショックで禁止された単語を選んで分を作るセーフチャット（言い方が違ったらすみません）の中間を行くようにしか思えないのですが、大丈夫なのでしょうか。有名なプロジェクトなので、もしかしたらスクラッチチーム公認なのかなぁと…。

#55
1番に関しては、時差は地域単位(だいたい国単位だけど、アメリカ合衆国は4つに別れてる)で固定になっているので、かなり大まかな経度しか取得できないと思います

#55
＠TimMcCool様のAmong Usのチャット機能を確認したところ、あれは定文型チャットです。
またスクラッチチーム公認の作品ではないです。

例えば、日本と同じ時差(UTC+9)を採用している国は、

* 韓国
* 北朝鮮
* パラオ
* 東ティモール
* ロシア (一部)
* インドネシア (一部)

があります。これは大した情報ではありません。
むしろプロフィールの国、およびその人が使用している言語の方が、出身国を特定する情報としては使いやすいでしょう。

(ちなみにガチで出身国を隠したい人は、表示言語を英語、タイムゾーンをUTCに設定するぐらいは普通にします)

最近クラウド変数を勉強しています。そこで、クラウド変数についての2つの疑問が生じたので、それについて回答が欲しいです。
まず一つ目は、大きい数での「~~ずつ変える」の使用についてです。

change [クラウド変数 v] by (0)」

前提として、大きい数を保存しているクラウド変数に「~~ずつ変える」を使用すると、e+で丸められてしまうという問題が生じます。
そうなると、大規模な人数を保存するとe+で丸められてしまうことになります。
それの解決策として、その場でクラウド変数に入れる数字を作成し、「~~にする」で入れるということが考えられます。

set [クラウド変数 v] to []」

しかし、同時に「~~にする」が使用されると、衝突によってデータが消滅する可能性があります。
そうなると送信速度が2分の1ぐらいに減ってしまうのではと思いました。
皆さんはどのようにこの問題を解決していますか？
もう一つ目はクラウド変数を変更する際のサーバーの言語についてです。
僕自身はpythonを使用しているのですが、Node.jsやGoを使用することもあるらしく、websocketでクラウド変数の値を変えることも簡単にできることを知りました。そこで、シチュエーションによってどういう言語を使い分けるか大体でいいので教えてください。

スクラッチ外のサーバーを使用する場合、衝突の問題は比較的簡単に解決できると思います。

衝突によってデータが消失する（したように見える）のは、スクラッチ側（クライアント側）だけです。
サーバー側には、必ずデータが送られてきます。

なので、すべての通信はサーバーを仲介に通して、やり取りするのが一番安定すると思います。
クライアントがデータを受け取れない場合は、それを検知してサーバーが同じデータを再送するようにします。

そしてこれが一番大事な考え方だと思うのですが、
「データが受け取れない場合がある」のは仕様と捉えて、データが受け取れなくても動くような設計にしておくのがいいと思います。
もしデータが受け取れなくて破綻するような設計なら、それは設計自体が間違っているかもしれません。

サーバーがいちいち再送するのは負荷が高いので、絶対に失敗したくないここぞと言う時にだけ、再送するような設計がいいと思います。
クラウド変数は通信速度に限りがあるので、なるべく少ない通信量で済むように工夫が必要ですね。