５月公開のフォントエディタのコード読んできたけど、フォントデータのインデックス配列と生データ配列で分かれて(どっちも文字列)、インデックスから描画文字検索して、データ配列からビット有効な位置に描画している感じ。 フォントサイズも数も自由に指定できるので、これが大容量になるとキャッシュより先に圧縮と展開（＋キャッシュ）を考えないといけないかもです。（れいさんの行っているプチコンのフォントならこっちって言ってる方法） キャッシュ先は今のインデックスとデータ配列を更新する感じでいけそうかも。 とはいろいろ実装しようとすると完成が遠ざかるので、プチコンならまずは完成してからでいいかも。 完成させてみて、ほんとにキャッシュが必要かとか、他に実は遅いところがあったりかみつかるかも（GFILL引数は演算回数的に一回変数に入れたほうがいいかも？）

れいさんの説明のキャッシュについては、展開後のデータが大容量などで全部メモリに入らない（か入るかわからない）ようなもの、身近なところだとMP3ファイルや映像ファイルの再生で使われていたり。 再生するのに必要な分をメモリに展開しておくけど、１小節後とか１分後とか次のチャプターとかを再生するときに、指定された再生位置がメモリにあれば使うし、なければファイルからメモリに展開するし。 モノによっては次に再生する位置が決まってるからキャッシュしておいて、読み込み遅延無く再生してくれるのもあるけど、 映像編集とかリアルタイムに音や映像加工するソフトはいろいろ工夫してるので一概には言えないのも。

ストレージというプチコンで使われてない単語を出しただけで困る人がいるって考えたり、キャッシュの仕組みが難解って言っているのにストレージが難解って考えるほうがトンチンカンだと思うんですがどうですかねー？ 「早さよりも複雑な展開の式を考えなくても」と書いてあるように、高速化のキャッシュが難解であることが理解されてると思うんですがどうでしょう？ 前に書いたのに注釈をいれると。 高速化のために使うキャッシュの目的だと、大容量でアクセスが遅いところ（ストレージ）にあるデータを、小容量でアクセスが早いところ（キャッシュ）に覚えておくのが目的 アクセスが遅いところにおくのは高速化のためのキャッシュじゃないです これが独断の憶測だと思うならどうぞ「キャッシュ　ストレージ」あたりで検索して調べてください。（スマホ系のは方向性違うで注意）

そもそもキャッシュもパソコンベースの話だったり（そっちのほうがトピック内容的に難解）

高速化のために使うキャッシュの目的だと、大容量でアクセスが遅いところにあるデータを、小容量でアクセスが早いところに覚えておくのが目的。 プチコンでデータを持てるエリアっていろいろあって、どれが早いか遅いかはあると思うけど、変数が一番早いのはイメージ付くはず。 ほしけんさんのは、やたら長くて多いDATA文を文字列変数に入れて、描画するたびにそのやたら長くて多い文字列から切り出してるので重たいというイメージ。 キャッシュの処理は見てないけど、１文字データの配列に入れてるからアクセスが早くなるというイメージ。 データとして頻繁に出てくるのが決まっていればキャッシュがあれば早いけど、 データとしてランダムならキャッシュがあってもあんまり早くならないイメージ。 ※ひらがなカタカナだけキャッシュしておいて、漢字はストレージからってのでもいいと思いますよ

みんなで作るゲームだし、今のプログラムのベースで問題無さそうなら、マップ定義の拡張とMAPREADを誰かにスクロールとイベント系を作ってもらうのもありだし、 １画面システムをベースにするなら、ゲームデザインをそうしてもいいとおもうのです（昔のゲームだと初代ゼルダとかイースとかハイドライドとか１画面ゲームは結構ある） ※マップ用の配列はあるので、その配列は新MAPREADからしか更新されないなら、ほかにマップ用配列を参照している人は問題なく動くはず

バトルシステムがどうなるか分からないけど、バトルシステムとしては主人公たちのステータス、仲間（兵士？神獣？）たちのステータス、敵たちのステータス、装備品（武器種類、防具種類）、バトルシステムに影響する特定のパラメータや攻撃手段などなど、 プログラムとして実装しなくちゃいけない配列変数がそろそろ必要な予感がします。 ゲームとしては主人公たちのパラメータで敵たちのパラメータを操作して、何かを得たりして主人公たちのパラメータが変わる流れなので、そろそろ必要なパラメータを話し合った方がよさそうかもです。

ログとコード読んでマップ移動がNPC会話で実装されてるのをいまごろ把握。 そうなると特定のところ（階段やマップ端）にいったときに何かしら実行される仕組みが必要かも（イベント） NPC26体制限はマップデータ定義によるものなので、NPCの数ぶん座標定義と、イベントの数ぶん座標定義するようにして、DATA文の終端管理するとよさげだけど 実装側のコードの変更量が結構大変そうなところです。 マップ作成を分担するのに、メイン側の開始の方で @MAPDATA_DEBUG ラベルが居れば呼び出すようにして、 マップのデバッグのためにマップ番号や開始座標などの指定をするようなデバッグ呼び出し処理があったほうがよさそうかも。 ＞ナナメ移動 ゲームとしてナナメ移動を入れるなら 0.6はぎりぎりなので0.4くらいがよさげ ナナメ移動を入れないなら、判定条件を厳しくしないといけない感じかもです。

複数マップで移動が出来ないとストーリーや世界観やマップが決まってきたときに、分担してマップやメッセージが作れなかったりもなので、 マップを歩いてたり、イベントなどで別マップに移動できるような仕組みをそろそろあったほうがよさげかも （マップファイルかメッセージ系かの定義どうするかや、マップ端で移動なのか、チップに乗ったらなのか会話中なのかとか） メニュー系も必要かもしれないけど、主人公用のステータス配列を必要そうなぶん用意しておいて、今後のバトルシステム実装のために準備しておくとよさげかも。 （メニューも呼び出し口あるし、他の人でも作れるはず） バトルシステム呼び出し口はあるので、バトルシステム案が複数あるなら、その案のバトルを他の人が作ることも一応可能な感じ。

コンパスのように書くのは、コンパスの針を中心として、コンパスの鉛筆まで距離が同じのまま、くるっと１週させる、という感じ。 なのでプログラムにすると、中心から距離を一定の位置を求める必要があって、コンパスを回す必要がある。 数学のお勉強として、中心から一定の距離をグラフを書く場合、高校数学で習う R=X^2*Y^2 の式が必要。 そしてこれをそのままプログラムには表すことができないので、高校数学で習う、角度から円の座標を表す三角関数の形式にする必要がある。 角度から三角関数を使ってXとYの値を求めて、角度を１週分ループするようにして、グラフの位置をずらすために（中学数学で習う）針の中心座標を加算してできあがり そしてそのプログラムはすでに だにえるさんが書いています。 そんな感じで円とコンパスとプログラムって高校数学のオンパレードなので、数学を勉強するとプチコンも楽しくなります。

プログラムでたいしたこと出来ないっていうのは、 変数代入などの データ制御 FOR-NEXT(WHILE-WENDなど)の ループ IF-THEN-ELSE-ENDIFの 条件判定分岐 GOSUB-RETURN の 呼び出し・戻り くらいしかできなくて画面表示(PRINTやLOCATE)の他に プチコン特有の処理で、画像(スプライト、BG)、音楽(MML)、ボタン・タッチ入力などなど（他にもいろいろ）くらいしかできないのです。 基本さえ覚えちゃえばプチコン以外でもプログラム出来るようになるけど、 最初の基本がほんと大変なので、いろんなプチコン初心者向けページを見ると、なんとなく理解してくるかも。

プログラムって思った以上にたいしたことできなくて、やりたい計算はやりたいようにプログラムを書かないといけないけど 数学系の計算なら命令が結構あるので、今回やりたい累乗の命令は POW 関数という感じです。 どんな命令があるかはプチコン３号公式ページの「命令表」から見れるので、眺めてみると実はこの命令あったんだってのがわかったりして良い感じです。 ちなみに累乗は「AをBの数だけ掛け算をするのを続ける。」と最初に書かれているそのもので、 これをプログラムに直すと、A を B回かけ算するのをFORで実行する、という感じになります A=2: B=4 C=1 ’計算のための初期値 FOR I=1 TO B C=C*A ' FORの数だけかけ算されるので累乗になる NEXT Bが4の時にCは 1*A*A*A*A の結果が入ります

「"A"を押したら文字が画面に出てくる」を分解すると 「"A"を押したら」「文字が画面に出てくる」にわけられて 「"A"を押したら」は「ボタンの状態がAを押していたら」になって ボタンの状態を取得するのに「A=BUTTON()」とすると A という変数にボタンの状態が入って 「～だったら」は「IF THEN」で、 「ボタンの状態がAを押していたら」は「IF A==#A THEN」となります(変数Aとボタン状態がAボタンを押してるかという意味の「#A」と比較して同じかどうか ) 「画面に文字を表示する」は「PRINT "文字"」でできるので 「"A"を押したら文字が画面に出てくる」は あきとさんのプログラムのとおりになるのです。

マップエディタ作っちゃうと簡易RPGツクールになっちゃうので、 エディタ作成、エディタのファイル読み書き、ゲームシステムのファイル読み込みと、結構完成させるまで大変な感じです。 マップエディタを他の人が担当するのもありかもしれないけど、ゲームシステム側でマップエディタ側でマップファイルのデータ構造はちゃんと決めないといけないので、それはそれでまた大変な感じです。 今のマップデータ構成でもNPC会話以外に、マップ移動やシナリオフラグ管理（などなどRPGツクールで使ってるようなのいろいろ）は必要になるので、それをマップに置くのか、マップに置くなら定義どうするか、別ファイルなのか、いろいろ考えないといけないので、 まずは「複数マップで動けるようにする」を目標にしたほうがいいかもです

じつは参加宣言してなくて、プロジェクトがうまくいくように流れを見守っているだけで、ゲームの内容までは意見してないので、必要そうなのは話し合って決めるといいかもです。 （みんなでゲーム作ろう的なのはだいたい完成しないで終わるので、プチコンコミュではぜひとも完成させてほしいところなのです） 個人的に言えば、プチコンコミュニティだし、みんなプチコン触れるので、いまのままマップファイルやメッセージファイルに書き込んでもらうのもありだと思います 将来スロットで使うのが増えると思うので（音楽とか敵データとか）、メッセージはマップでしか使用されないので、マップとメッセージは同じファイルに統合するのも手かもです。

ちなみに、決まったことを書き込むお絵かき投稿をした方がいいかも 決まったこと以外書いちゃダメなので。 「まだ決まってないこと」も今の段階では決まってることなので、必要があるなら書き込みだけど、話し合わないといけないことは書いちゃだめで（「魔法が使える」じゃなくて「魔法が使えるかはいろいろ決まってから」な感じで） それ見れば何が決まってるかすぐ見れるし、何を決めないかわかるし、そこから新しく思いつくこともあるかもだし、 まずは だにえるさんのまとめ画像をコピペで、そのあと決まった事を追記するのがいい感じ みんながゲームの中に出てくるとか、バトルがFE風かDQ風かは未定だけど戦闘はあるとか、ゲームタイトルはストーリー決まってから決めるとか 流れでなんとなくそうなるだろうって暗黙の了解とか文章にしておくの大事です

BGMと絵を作る人が何人いるかだけど、ストーリーというか世界観は剣と魔法と姫と魔王の世界なら中世っぽい感じで、フィールドと魔王の手下と戦闘があるので、今決まっている事からでもBGMは依頼出来ると思う ストーリーが膨らんできたらそれらしい伏線を含めてさらに街やタイトル（平和な時代か、事件が起きた後か）もという感じで。 （チームのイメージ音楽作ってもらうのもありだと思いますよ） 絵もプチコン内蔵のキャラ（歩行４方向）を書き換える形なら、姫や兵士や主要主人公（参加者）なども書き始められそう 絵と音楽は行き当たりばったりで作れないので、何を作らないといけないかはまとめた方が良いかも

参照が使われる理由としては、配列１０００個を関数引数などにわたされたら、１０００個も関数の仮引数にコピーしなくちゃいけなくて大変なので、 配列１０００個の先頭のアドレス（と配列個数の２個）だけ渡せばそこから１０００個処理しても同じ事出来るので、ならば配列の方がデータ渡すの少なくて動作早くなる、という感じです。 文字列も文字の配列なのでだいたい同じ仕組みなのです。

すき屋の うな牛（うなぎ＋牛丼） の小分けの山椒パックに２つ付けられて１つ余ってどうしような今日この頃。 配列変数を [] なしで使うと参照になって、動作はMIKIさんの説明のとおり。 写真のコードだと 10行目の A%=B% で 3行目の READ A%,@D で読み込まれたデータはプログラム中からは誰もさわれない状態になっていて 11行目の RSORT でB%の参照先の配列がソートされて、同じアドレス(MIKIさんの説明のロッカー番号)の A%もソートされたように見えちゃっているという。 テストプログラムで動いて実際のプログラムで動かないのは、たぶんどこかで参照指定がまちがってる感じがします。

ストーリ（音楽、絵も）はプログラムから見ればただのデータ（DATA文などファイルに追加なのでコードの作り知らなくてもできる） ゲームシステムはプログラムから見ればロジック（新しくコードを書くのでコードの作り知らないと大変） 全体が動く基本プログラムを作るにも、ストーリーからシステムに必要なモノを話した方がよさそうかも。 （シナリオフラグ配列、バトルシステムによる敵と主人公のステータス配列、レベルアップによるステータス上昇のしくみ、どの情報をセーブするかなどなど） ※基本プログラムができあがればみんなで追加や修正ができそう