4.5 KiB
テストゲーム
最初のテストゲームで何を行うかを記述します。
ログイン画面
まずログイン画面を表示します。これは別levelではなく全て一つのlevelで行います。確かにlevel(map)を作成して使い分けたほうが便利です。宇宙や地上、ボスのmapをゲーム進行に応じて切り替える方法です。
しかし、このゲームは現実の反映を目指しています。すべての世界はつながっている。世界は一つ。それがこのゲームの信念です。ですから、ログイン画面も本level上で行うことにします。
ログイン処理
ユーザーはyui.syui.aiのrecord(ai.syui.game)に作成されます。did.plc.xxxという形式になります。
oauth認証することで、データを個人アカウントにexportする仕組みを作りましたが、今は破壊しています。ゲームデータを保存するjson(lexicon)がなかなか定まりません。これはfrontpageを改造して作りました。
こんなものがあればいいというのを述べますが、ユーザーが削除はできるけど、作成や改変できないlexiconです。oauth認証で他のユーザーが作成、改変できる許可を与えます。
ユーザーが削除はできるけど、作成や改変できないlexiconが必要。oauth認証で開発者がユーザーのその領域にrecord作成、改変できる許可を与えるもの。
現在、なぜゲームデータをyui.syui.aiに保存するのかというと、いくらでも値を変更できてしまうからです。もちろん、変更には知識が必要ですが、エンジニアやプログラマであればチートし放題ということです。
そのため私が管理するアカウントにデータを保存するしかありません。本来ならプレイヤーのアカウントに保存すべきものだと思います。
次に、webからのゲームプレイに関して注意点があります。そのため以下の仕様を実装します。
webからのゲームは1ユーザーしかプレイできませんし、誰でもアクセスすれば動かせてしまいます。そのため、botにゲームをプレイすることを伝え、そこでloginしているユーザーを確認し、空きがあればloginを成功させます。そして、10分経過後にlogoutします。logoutしたときにlimitが書き込まれます。1日に1回のloginに制限されます。
実際に現在loginしているユーザーしかログイン画面を通さないようにします。これである程度は別ユーザーにプレイされる可能性は減るでしょう。
atprotoに必要な機能
現在、本当に必要な機能を述べます。それは、oauthで他ユーザーからのlexicon(collection)への読み書き権限を設定(承認)する機能です。
例えば、プレイヤーをuser.bsky.socialとし、ゲーム運営をdev.example.comとします。
oauth認証をするとuser.bsky.social/com.example.dev/selfが作成され、そこにゲームデータが保存されます。user.bsky.social/com.example.devへの読み書き権限は以下の通り。プレイヤーはdeleteのみが可能で、post, putはできません。ゲーム運営はpost, putは可能ですが、deleteはできません。なお、ここへのpost, putはuser.bsky.socialのtoken(limit)によって行われます。もしゲーム運営であるdev.example.comのtoken消費により実行されると、すぐにlimitに到達してしまうからです。
| at://user.bsky.social/com.example.dev/self | post | put | delete |
|---|---|---|---|
| user.bsky.social | no | no | yes |
| dev.example.com | yes | yes | no |
- post, putは
user.bsky.socialのtoken(limit)による
このようにすることで、ゲームのアイテムボックスをatprotoで実現できます。
しかし、このような機能は現時点では実装されていないと思います。
ゲームプレイ
ボスと行く場所が用意させています。アイテムがドロップします。それを拾わないとアイテムボックス(アカウント)に反映されません。
ドロップするアイテムはランダムになっています。最初に拾えるのは、コインとカードです。
アイテムボックスはいつでも確認できます。
上には家があり、机の上に手持ちのアイテムがあれば表示します。