# テストゲーム

最初のテストゲームで何を行うかを記述します。

## ログイン画面

まずログイン画面を表示します。これは別levelではなく全て一つのlevelで行います。確かにlevel(map)を作成して使い分けたほうが便利です。宇宙や地上、ボスのmapをゲーム進行に応じて切り替える方法です。

しかし、このゲームは現実の反映を目指しています。すべての世界はつながっている。世界は一つ。それがこのゲームの信念です。ですから、ログイン画面も本level上で行うことにします。

## ログイン処理

ユーザーは`yui.syui.ai`の`record(ai.syui.game)`に作成されます。`did.plc.xxx`という形式になります。

oauth認証することで、データを個人アカウントにexportする仕組みを作りましたが、今は破壊しています。ゲームデータを保存するjson(lexicon)がなかなか定まりません。これは[frontpage](https://github.com/likeandscribe/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で実現できます。

しかし、このような機能は現時点では実装されていないと思います。

## ゲームプレイ

ボスと行く場所が用意させています。アイテムがドロップします。それを拾わないとアイテムボックス(アカウント)に反映されません。

ドロップするアイテムはランダムになっています。最初に拾えるのは、コインとカードです。

アイテムボックスはいつでも確認できます。

上には家があり、机の上に手持ちのアイテムがあれば表示します。

