今回はマイナーバージョンアップで不具合のみの修正となります。動作環境の変更や、ボード定義ファイルの変更、追加機能などは特にありません。
「00」キーの挙動についてはボードコンテナ定義ファイルの修正になりますので、アプリケーション側を更新しても不具合は解消されません。テンキー定義ファイルを直接修正するか、ボードパッケージをダウンロードして差し替えてください。
ブログや動画でもお伝えしていた通り、昨日ゲームの開発中デモ版 Ver 0.40 を公開しました。遊び方や改良点などは以前のブログや動画、また、ゲーム公開ページにも記載しているのでそちらをご覧ください。
ゲームは以下のページで公開しています。Silverlight を使用していますので Internet Explorer でアクセスしてください。
http://sorceryforce.net/ja/lab/gamedemoapp01ver0dec04
前にも記載した通り、パフォーマンスはそんなに良くないです。FPS が 60 を維持できない場合、特に移動中が少しがたつくかもしれません。移動中以外であれば、FPS が落ちても見た目はそんなにわからないと思います。
今回開発中バージョンということでそのままにしていますが、今後のバージョンでは負荷を下げるためになんらかの機能を省略するかもしれません。もちろん本リリースでは全機能を入れるつもりです。
最近は制作動画のほうの更新もなかなかできずにいたので情報公開がしばらくできていなかったのですが、一応プログラムのほうはちまちまと作っていました。Ver 0.40 は「この機能を入れる！」っていうような新機能はなかったのでどのあたりまで作りこむか迷っていたのですが、とりあえず各機能が問題ないレベルまで動くようになったのでそろそろ Ver 0.40 を公開しようかと思います。
現在のゲームイメージは下のようになります。
ゲームの操作方法や各説明についてはゲーム公開ページに載せる予定なのでここでは記載しません。
Ver 0.30 では２ステージから選択できていましたが、今回は１ステージのみとなっています。その代わり、ゲーム開始時に難易度を３種類から選択できるようになっています。ちなみに Ver 0.40 の難易度は過去３バージョンに比べるとかなり難しくなっていると思います。
難易度で「普通」を選択した場合でも、立ち回りをうまくしないとクリアが困難になる可能性があります。「簡単」を選択すれば相変わらず仲間が勝手にどんどん敵を倒してくれます。「難しい」を選択するとジリ貧状態まで追い込まれるので、作者自身がプレイしてもなかなか難しかったです。
ちなみに私が各難易度をクリアした結果は下のようになりました。神プレイを狙ったわけではなくとりあえず１回クリアしてみたものです。
「易しい」「普通」はそれなりの結果でクリアできたと思いますが、「難しい」はクリアに２７分もかかってしまいました。敵の数に対して仲間が圧倒的に少ないので余計に時間がかかります。
今回のデモ版のクリア条件はすべての敵を倒すことです。ボスはいません。しかも敵は赤色と黄色がいるので、片方だけ攻めているともう一方に攻撃される可能性もありますので、マップを見て現在の状況を把握する必要があります。
ゲームのパフォーマンスについてですが、60FPS を出すのが結構難しい状態になっています。私の環境でゲームの設定を変えずにプレイした場合、敵の数が画面内に多くなったりすると40FPS ぐらいまで落ちてしまいました。試しに GPD WIN でプレイした場合は 20FPS でした。
一応負荷軽減対策としてゲーム開始前のオプションでユニットの配置数を変えることができるようになっています。もしまともにプレイできないようであればユニットの配置数を減らしてプレイしてみてください。逆にもっとユニットを出したい場合は増やしてみるのもいいかもしれません。
![2017-04-22 21_15_23-OneNote[3]](http://blog.sorceryforce.net/wp-content/uploads/2017/04/2017-04-22-21_15_23-OneNote3.png "2017-04-22 21_15_23-OneNote[3]")
ちなみにパフォーマンスがでない理由についてはよくわかっておりません。おそらくですが、ゲームプログラムが Internet Explorer を介して動いているため、その分余計なオーバーヘッドがかかっているのではないかと思っています。ちなみに UWP でも同じプログラムを使って動かしていますが、こちらの方は２倍程度高速に動いている感じです。
一応パフォーマンスを改善できる点はまだあるのですが、今後もまだ機能を追加するものがあるので、そちらの負荷が上がったときに改善しようと思っております。今回も開発版なのでそこまで最適化を行っているわけではありません。
プログラムのほうは動作確認を残しているだけなので、早いうちに公開できると思います。その前に今回のバージョンに向けての制作動画を２本撮ったので、先にそちらの方の編集を行って公開した後にゲームを公開しようと思っております。
ちなみに Ver 0.40 になってもいまだに Game Demo というタイトルなのですが、今はシステム構築がメインなので、Ver 0.50 公開あたりまではたぶんこのままだと思います。コンテンツなどは後半に行う予定です。
Windows 10 Mobile のアプリケーションで起動時にファイル操作を「同期処理」であれこれやっていて結構時間がかかっているのですが、Visual Studio からデバッグ実行している限りでは問題なく動作し、W10M から単体でアプリケーションを起動すると、起動が完了する前に落ちてしまいます。
最初この現象の理由がわからずデバッグ実行での確認もできないので悩んでいました。例外をキャッチしてログを出すようにもしていたのですが、何でもないような処理のところでプログラムが落ち、例外もまったく発生しませんでした。
しかし、何回かやっているうちに気づいたのですが、ログの出力時間を確認したら最初のログの時間と落ちるタイミングの時間の差が20秒であることに気づきました。試しに Task.Delay.Wait で待機させるようにしたらもっと前の処理で落ちることを確認できました。
Windiws Phone 7 か 8 あたりでも、処理に時間がかかって UI? に処理を戻さないとアプリケーションが落ちるという話は聞いたことがあるのですが、このことをしばらく思い出せなくて盲点でした。デバッグ実行では落ちないし、例外も発生しないので気を付けなければいけませんね。
余談ですが、ファイルアクセス処理はファイルがあるかどうかのチェックだけでも１回あたり１秒ぐらいかかるので非同期処理のほうがいいですね。
年度と和暦が関係するシステムを構築するうえで気になる点がありいろいろ調べていったのですが、せっかくなので考えをまとめたものをブログに上げてみたいと思います。
ちなみにここではシステム屋目線で考えたものであり、実際に昭和元年度が存在するかどうかの答えは書いていません。おそらく仕様上そう表現すべきかどうか決めごとに落ち着くのではないかと思います。
前置きはこれぐらいにしておいて、まずは「平成元年度」について書いてみます。平成に改元されたのは「1989/1/8」で、下の表は西暦と和暦、年度と和暦年度を並べたものです、和暦年度という表現が正しいかどうかはわかりませんがここではそう表現させていただきます。また、年度については一般的に使われる会計年度として扱っています。
| 年月日 | 和暦 | 年度 | 和暦年度 |
| 1989/01/07 | 昭和64年 | 1988 | 昭和63年度 |
| 1989/01/08 | 平成元年 | 1988 | 昭和63年度 |
| 1989/03/31 | 平成元年 | 1988 | 昭和63年度 |
| 1989/04/01 | 平成元年 | 1989 | 平成元年度 |
年度について、３月末までは前の年として扱われ４月～１２月末の間は西暦の年と一致することになっています。
1/8に年号が平成になるので、和暦年度も平成になっていいように思えますが、そうすると 1/8～3/31 の期間は「平成零年度」となってしまいます。平成零年なんてものは存在しないので、1989/3/31 までは前の年号である「昭和63年度」を使うのが正しいです。
このことをシステム的に考えて仕様にすると
になると思います。
では本題の「昭和元年度」について考えてみます。平成のときと同じように表にまとめたのが以下のものです。
| 年月日 | 和暦 | 年度 | 和暦年度 |
| 1926/12/24 | 大正15年 | 1926 | 大正15年度 |
| 1926/12/25 | 昭和元年 | 1926 | ? |
| 1927/01/01 | 昭和2年 | 1926 | ? |
| 1927/03/31 | 昭和2年 | 1926 | ? |
| 1927/04/01 | 昭和2年 | 1927 | 昭和2年度 |
昭和への改元は 1926/12/25 になるので 1926/12/25 から 1926/12/31 までのたった７日間だけが昭和元年になります。そして 1927/1/1 からは昭和2年になるので和暦年度も 1927/4/1 からは昭和2年度になります。
では 1926/12/25～1927/3/31 の期間はどうなるのでしょうか。1927/4/1 から昭和2年度になるので、1926/12/25 からは昭和元年度でもいいような気がします。しかし、平成のときに挙げた仕様「4/1～3/31 の期間の和暦年号は 4/1 時点の和暦年号で表現する」とは一致しなくなります。もしこの仕様にあわせた形で表現するとなると「？」の期間は「大正15年度」になるので「昭和元年度」は存在しなくなることになります。
もちろんさらに条件を付け加えて「改元が 4/1～12/31 の期間に行われている間は改元された日から和暦年度を切り替える」としてもいいのですが、条件も少し複雑になりますし、平成といっしょに考えたときになんとなく条件に統一感がないようにも見えますので「大正15年度」の表記でもいいような気がします。実際には決めごとの話になりますし、大正15年度でも昭和元年度でも間違いではありません。
ネット上で書籍や資料を見てみると、どちらかで書いてあったり「大正15年度・昭和元年度」のように両方併記しているものもありました。
自分なりに考えをまとめてみましたが、やはりちょっと不安だったので Excel だとどう表現するんだろうを思って実際にやってみました。
まず、Excel で和暦表記を行うには、セルの書式をユーザー書式にして「ggge"年度"」とすると和暦表示になります。下図は単純に日付をそのまま書式設定で表示したものです。
改元したタイミングで年号の表記が切り替わってることが分かります。もう一度書きますが、上図は西暦をそのまま和暦表示しただけなのでの結果は間違いです。
これを実際に西暦から年度に変換して和暦表示するわけですが、ネットで探してみると以下の式を使う方法がありました。
上記の式を使用した結果が下図になります。
①は昭和から大正に戻ったりしているので明らかに間違いになります。②についても「昭和64年度」となっていたり、1927/3/25から昭和元年度が始まったりしているのでやはり正しくありません。これは指定した年月日から月だけを計算しなおしているので改元の日だけがずれたりして結果がおかしくなってしまうのです。
正しく表現するのであれば、最初の平成元年度の時に記載した「4/1」に統一するのがいいと思います。
以上の Excel の結果からみると直接和暦年度を表現するような機能はなく、年度を自分で計算して和暦表記するような形になるようです。和暦年度の表現について「これだ！」と納得するようなものがなく一応自分の考えでまとめてみた形になりますが、もし意見等があればコメントいただければと思います。
ちなみに余談ですが、2019年の改元予定では改元日が2019/1/1になるようなので、元年度のパターンでいうと平成元年度と同じになりそうです。和暦や年度の扱いで恐怖されている方もいるかもしれませんが、平成元年度のパターンは１パターンしかないので仕様の検討では少しは楽になりそうですね。
ユーザーさんからキーを離したときにだけ文字を入力したいけどどうすればいいかという質問がありました。
英字や数字などのキーは既定では物理キーボードの動作と同じく、押した瞬間に１文字打たれ、押しっぱなしにしていると一定時間後に連続で文字が入力されるという動作になっています。
この動作を変えたい場合はボード側の設定を変えることによって可能になっています。
ちーたんタッチボードでは各キーの動作を「Processes」パラメータで上書きすることによって動作を変えることができます。次のように設定するとキーを押して離したときだけ文字が入力されるようになります。
【例】Aキーを離したときだけ動作させるようにする
| [{"KeyType": "A","ExecuteTiming":"Released","PressRepeat":"Once"}] |
「KeyType」は対応するキーを識別する名前で、「ExecuteTiming」を「Released」にすると離したときだけ動作するようになります。ただし、これだけだと押下中の連続動作は残ったままになってしまうので、「PressRepeat」を「Once」にして１回だけ動作するようにします。
「ボード作成 Excel ツール」を使ってボードを作成する場合は「Processes」に入力して対象キーにまとめてコピーすればいいだけなので簡単です。使い方はホームページを参照してください。
一応標準キーボードに対してこれらの設定を行ったサンプルを OneDrive に置いておきます。使ってみたい方はダウンロードしてください。
JSON のエスケープ回りで仕様に沿っていない文字があったのでそのあたりを修正しました。変換実行のタイミングで文字を解析するため、変換後のJSONテキストはバックスラッシュかユニコードのどちらかでエスケープされるようになっています。混在したまま出力することはできません。どちらでエスケープするからは設定で変更できるようにしました。
また、設定項目が少し増えてきたので、ボタンを押して設定を表示する形に変更しました。モバイルだとテキストエリアが結構狭かったので若干広くなったかと思います。
あと多言語対応もしました。Ver 1.00 でしていると思ってたのですが、たまたま英語環境で実行してみたら日本語のままだったことに気づき、確認してみたらまったく対応されてませんでした。してると思ってたので公開している国を242か国すべてにしていたという…。
ストアで公開しているので、ダウンロード・インストールはそちらで行ってください。使い方などについては以下のページに乗せています。
サブアカウントからの動画の引っ越しに時間がかかってしまってなかなか公開できませんでしたが、ようやく #30 を公開いたしました。あと、今回からはメインアカウントのほうに動画を追加していきますので、サブアカウントの動画リストは #29 で終了となります。
今回は PC 上だけではなく、タブレットやスマフォでゲームを動かすことになっても問題ないように対応してみました。まだしばらくは Sliverlight での公開のみとなりますが、一応こんな感じでマルチプラットフォームで動かせるようにしていますよと説明しています。
最近はちーたんタッチボードの改修や動画の移行などやっていたため、ゲーム開発のほうは進んでいません。そのため、次の動画の公開は未定になっていますが、いろいろ落ち着いてきたのでゲーム制作と動画の収録のほうは少しずつ進めていきたいと思います。
