四海のほとり

 D&B（ダンジョンズ＆ボヨヨンズ）Part1『脱出』は他の作品と同様にプログラミングの練習目的で作ったゲーム　単純な迷路脱出ゲーム　 →今すぐプレイ コンセプト プログラミングの練習が主目的なので公開しなくても良いのだけど、この作品は公開するという方向で考えていた気がする。 ただ、当初はもっとオリジナリティのあるルールに変更しなければ公開する価値は無いだろうと考えていたが、何度も動作検証をしているうちにシンプルなタイムアタックのゲーム性で公開したいと思うようになっていった。 当初は自由に敵の数を変更したりマップの広さやマップの複雑さを自分で指定できたりとかなり自由度の高い仕組みとなっていた。しかし、ゲーム性の中心をタイムアタックにしようと思った段階で自由にマップの広さを変えられたらタイムアタックにならないのでマップの広さはフロアーごとに固定し、複数のフロアーを用意してそれぞれに異なる広さや敵の数を設定するという仕組みとなった。 いつの段階だったかははっきりしないが、タイムアタックをゲーム性の中心にもってきた段階で、タイムスコアを集計してランキングを表示すればタイムアタックは盛り上がるのではないかと考えた。記録の残らないタイム表示ではスクリーンショットを撮って共有するといった方法でしか競う事が出来ないので、ランキングを表示する仕組みが必要な事は明白だった。 スコアを集計表示するためには各プレイヤーの結果を送信する必要が出てくる。 また、結果を蓄積した上で、集計し、上位ランキングをソートして表示する必要がある。 これらはユーザーのブラウザで動作するJavascriptだけでは実装不可能なのでサーバーサイドの仕組みが必要となる。今回はまともなサーバー構築は一切行わず、Googleスプレッドシートにデータを蓄積し、Googleスプレッドシートの関数で集計し、その結果を受診するというシンプルな仕組みを構築している。詳しくは D&B Part1『脱出』技術的なメモ に記す。 D&B Part1と、一作目から二作目を作るかのようなタイトルにしたのには一応理由があって、シンプルなタイムアタックで公開すると決める前にあった各種アイデアを実現した続編を作る前提で、今はとりあえずシンプルなタイムアタックの迷路脱出ゲームにすると自分に言い聞かせる必要があったからで

制作ノートでは軽く触れただけのデータ送受信について、忘れないように記録を残しておく。 → 制作ノート   データ送受信 今までの作品はJavascriptのみで作られていた。つまりクライアント側のみで動作するプログラムであり、サーバーにデータを送信したり、サーバーからデータを受信したりする処理は無かった。 今回、タイムアタックをゲーム性のメインに持ってきたかったので、タイムスコアをサーバーに送信して蓄積し、ランキングを受信して表示する事が必要になった。 真面目にサーバー環境を構築するという選択肢もあったのだが、試しにGoogleスプレッドシートにデータを送信して蓄積し、Googleスプレッドシート側でランキング集計用シートを作成し、受診時はシートの内容を取得するだけというシンプルな構成を作ってみた。 GoogleスプレッドシートにはQUERY関数というデータベースを操作するSQLのSELECT文のような関数が存在するので、集計用のシートを作成してランキングデータを表示するのは実に簡単だった。 データ蓄積用のシートをQUERY関数で参照するだけでランキング集計済みのシートが出来上がるのでApps Scriptでシートを取得して戻せばJavascript側で簡単に表示できる。 しかし、実は実装に苦労した。 Javascriptはブラウザのコンソールを見ていればエラーの原因がわかるのだけど、Apps Scirpt側でのエラーはコンソール上ではわからないのでブラックボックスのようになってしまう。 まぁこれはPostmanを利用することでAPI（Apps Scirpt）側のエラーがわかるようになって解決したのだけど、気づくまではけっこう大変だった。 （ブラウザのコンソールではApps Scirpt側のエラーは全てCORSエラーとして表示される。しかし、実際は返答がないだけでCORSエラーではない。ChatGPTやGeminiにエラーを分析させてもてんで見当違いな改善策が提示されるが、それはCORSエラーを改善しようとする内容だからであり、実際にはCORSエラーではないのだから解決しないのは当然であった） それと、今回タイムスコアの送信とランキングの受信のみなので大きな問題は発生していないけども、Apps Scirptからスプレッドシートへのアクセスにはタイムラグが結構ある。

 ゲーム制作中に表記をアルファベットにするかカタカナにするかで迷う事はよくある。 最近公開した“D&B Part1『脱出』”でもfloorの表記をアルファベットのままにするか、カタカナにするかで迷った。そしてゲーム内のタイム表記やFloor Clearといった表記はアルファベットのままとしたがハイスコア確認用のプルダウンメニューでは総合や最近と並べた時にカタカナの方が自然だという事でフロアー１、２というカタカナ表記とした。 しかし、Floorのカタカナ表記は「フロアー」「フロア」と長音のあるなしで表記揺れがあったので、アルファベットをカタカナにする規則、floorはカタカナでどの様に表記すべきかをGoogle検索で確認する事にした。 「フロアー」で検索するとこの様に「関連する質問」という通常のサイト検索結果とは別にGoogleが関連すると判断した内容が表示されていた。 　そこには「フロア　フロアーどっちが正しい？」という項目が存在し、開くとこの様に 「基本的に『フロアー』という言葉はありません。『フロア』が正解です。文部省の外来語の書き方で決められています」 と表示された。 これを見て、私は「え！？」とこの内容に大きく疑問を感じた。 　これはYahoo知恵袋にリンクしていたので内容を確認。 Yahoo知恵袋の記事 　Googleが引用した内容そのままの短い回答内容であった。 　文部省の外来語の書き方で決められているというが詳細が何も記されていないので調べることにした。 HOME > 国語施策・日本語教育 > 国語施策情報 > 内閣告示・内閣訓令 > 外来語の表記 > 留意事項その2(細則的な事項) 外来語の表記　留意事項その2(細則的な事項) ここを確認すると、「3　長音は,原則として長音符号「ー」を用いて書く。」とあり、その注３では 「注3　英語の語末の‐ｅｒ,‐ｏｒ,‐ａｒなどに当たるものは,原則としてア列の長音とし長音符号「ー」を用いて書き表す。ただし,慣用に応じて「ー」を省くことができる。」 と記載されている。 つまり、orで終わるfloorは長音符号を用いるのが原則であり、慣用に応じて省いてもよいということになる。 なので、Yahoo知恵袋の「ベストアンサー」は勘違いな回答であることがわかる。 しかし、質問者がフロア　

  『Smile Rversi』（スマイル☆リバーシ）−勝利よし、敗北なおよし− 　を公開してから一ヶ月ほど経過したので制作ノートを記す。 『Smile Rversi』はCPU対戦リバーシであり、初期段階ではプログラミングの練習目的で作ったCPUが弱くてなんの面白みもないゲームであった。 なんの工夫もないのもどうかと思い、最初に行った付加要素は『不揃い処理』であった。 よく見て貰うとわかるようにマスに対して石が中央に配置されず全てが微妙にズレている。 この手のゲームではマスに対して中央に石が配置されるゲームが多いが、人間は正確に中央には配置できないので不自然に見える。 なので、自然に見えるように工夫したのがこの『不揃い処理』である。 　ただ、この処理を作った時に思ったのは、自分としてはとても気に入っているけど、ほとんどの人は気づきもしないという事。 　プログラミングの練習目的で作っているのだから公開しなければならないわけではないし、弱いだけのリバーシなんて公開しても誰も遊ばないことは明白で、この不揃い処理を加えたところで遊びたいと思わせる要素には全くならない。 　でも、せっかく作ったのだからなんかの要素を付加して公開できないかな？　と思った。 　色んな可能性を考えている中で、前回の『早押し百人一首　十連‼』で音声を付与した途端、作品に色がついたような感覚を思い返していた。 　CPU対戦だからキャラクターに個性を持たせて、複数人用意してそれぞれにセリフを用意したらどうだろうかと連想が始まる。 　でもCPUは弱いし、リバーシにそれほど興味のない私がこれ以上強いのを作る気力はない。 　複数人CPU用意したって強くもなんとも無いリバーシを遊びたいと思う人がいるだろうか？ 　まてよ、逆に物凄く弱くして、敗けるのが難しいようにしたらどうだろう？　そう思って弱いCPUを作ってみた。 　うーん、弱いCPUといっても敗けること自体は出来る。 　これでいいのかなぁとまた悩んだ。 　そして、たどり着いたのが戦況を９段階に分けて状況に応じたセリフを用意する。勝利を目指すのではなく、状況に応じて変化するCPUキャラの表情の変化、セリフの変化を楽しむというコンセプト。 　これは勝利という目的を転換して、目的を楽しむに変えるという事になる。 　よく考えてみると友達とリバーシをするというのは先に友

  ２月に正式公開した『早押し百人一首 十連‼』について、今更ながら制作ノートを記しておく。 元々、百人一首の練習用プログラムの要望があったので『 百人一首（表示するだけ） 』(2023/05/27)を作成した。 後、ゲーム形式で練習したほうが面白いのでは？　と思って作成したのが『 早押し百人一首 』(2023/06/09) シャッフルせずに順番どおりに確認することも、シャッフルすることも出来るようにした。 それからだいぶ時間が経った後、際限がないので10回で終わるようにしてほしいという要望があった。 そこで作ったのが『 早押し百人一首 十連‼ 』(2024/02/08)であった。 基本的に10回で終わるので短時間に練習できるが基本コンセプト。自動でシャッフルし、シャッフルなしのモードは削除してシンプルにした。（なお、当初の早押し百人一首でも5連モードは途中まで作っていたが完成しないまま機能は公開しなかった。内部的には存在していたので、それをちょっと作り変えたので手間はほとんどかかっていない） どうせだからと10回の平均秒数を8段階に評価し、その段階に応じて最後に笑顔の女性を表示するようにした。 これらの画像はnijijourneyによって生成しているが、この時点ではキャラクターを固定化するのはとても難しかったので、同じような印象の女性というレベルで生成しているだけで同一人物に見えるかは微妙。 Ver1.10 正式公開当初、Ver1.00の時点では以上の特徴で終わっていた。 この後、2024/02/24公開のVer1.10では声優の JiRさま に読み上げ音声を収録してもらったので、私の作った中では初めて音声の入ったウェブアプリとなった。 音声が入ってみると、それまで無音でテキストを眺めるだけだった状況から一変して命が吹き込まれたように感じた。 後からお話を聞くと、競技かるたの読み方で百人一首を読むのは初めてだったそうで苦労して練習されたとのこと。 私は競技かるたに詳しいわけではないので、専門的な立場の人は違う意見かもしれないけど、私にとっては十分すぎる音声だった。とてもありがたかった。 それと、いままで作成したウェブアプリは全て私一人で作ったもので、もちろんプログラミングの練習、復習を目的としているのだからそれで当然なのだけど、『早押し百人一首 十連‼』はVer1

 プログラムばかり作っていて最近ブログを書いてないので、最近作ったプログラムについて記してみる。 昨日一般公開した『 早押し百人一首 十連‼ 』についてはおいておいて、1月末に公開した『 倉子ちゃん 』について記しておく。 倉子ちゃんはプログラムの練習用に作ったシンプルなパズルゲーム。 昨年から行っているプログラムの再学習を今年も引き続き行うという方針の元に作成している。 ゲームの内容はずばり往年の名作『倉庫番』を元にしたもので、非公開の初期版では『倉庫番』との相違点は殆どなかった。 ゲームのルールに著作権は存在しないとはいえ一般公開するにあたって『倉庫番』との差別化は必要だろうと思った。 そこで、いくつかの案を考えたのだが、基本的なゲームシステムが変わると手間がかかるので、荷物そっくりのダミー荷物を作り、ダミー荷物は触ると消えるというシステムを採用した。 これが最も手間がかからないアイデアだったし、ダミーを見極めて消してしまった後は普通の『倉庫番』と同じ感覚で遊べる。 この『倉子ちゃん』に限らないが、公開しているウェブアプリは全て素のJavascript(Vanilla JS)で作成している。 昨年の初め、ゲームを作ろうとして初めに選んだのはUnityというゲーム開発環境だった。 実に簡単にゲームを作れることがわかったが、肝心のモバイル向けウェブアプリに対応していなかったので、早々に使用をやめた。 その後は、Webアプリに特化したPlaycanvasの練習を行っていたのだが、各種チュートリアルや解説記事がPlaycanvasのバージョンによって動いたり動かなかったりして、Playcanvasのルールに振り回されるのが嫌になった。 そうして、結局Javascriptを基礎からやり直すことにして開発環境やライブラリの類は一切使わない方針へと転換した。 その後は毎週なんらかのプログラムを作り、公開する価値があるかもと思ったものは公開してきた。 『倉子ちゃん』もそうした多少は公開する価値のあるプログラムの一つで、必要以上に手間を掛けていない。 例えば右に動かした時に右向きに、左に動かした時に左向きになるとか、歩くアニメーションを実装するとか、そういう事はしていない。 そういうのはゲーム開発環境なら簡単に実装できるのだろうけど、一つずつ自分でプログラムを組むと結構時間のかか