3Dモデルアニメーションソフト「エルフレイナ」のライセンス購入方法の変更(追加)について

今までエルフレイナシェア版のライセンスの購入方法については直接メールでのやり取りにおいて行っておりましたが、必ずしも即座に対応できるわけではありませんでしたので、今回、他サイトの販売サイト様のほうでもライセンスを購入できるようにいたしました。今回、以下の2つのサイトを追加いたしました。

どちらも購入できるものに変わりはありません。値段がちょっと違うのは、金額の設定範囲や手数料に違いがあるためです。一応最終的にかかる金額は、上記サイトを利用したほうが安くなります。詳しいことは購入ページに記載しましたのでそちらをご覧ください。


MonoGame 3.6 の UWP10 プロジェクトでキーボード操作を行うと遅延する

通常 Keyboard.GetState メソッドでキーボードの状態を取得すれば現フレームの段階でのキーの押下状態を取得できます。一度に複数のキーを同時に押しても問題ありません(キーボードの配線によってはキー同時押下の上限はあります)。

しかし、UWP10 のプロジェクトを作成し、Windows 10 の環境で実行すると、押下状態を瞬時に取得することはできず、段階的に1キーずつ取得されるような動作になってしまいます。しかも、しばらく押したままにして離すと、一定時間押下中判定のままになってしまい、その後これまた段階的に1キーずつ放すような状態の取得を行います。

ちなみに UWP8.1 のプロジェクトで同じ処理を行うとまったく問題はありません。

参考にその動作を録画してみたので、実際に見てみるとわかると思います。最初が UWP8.1 のプロジェクトでそのあとが UWP10 のプロジェクトでの動作です。

この件についてコミュニティで探してみると同じような報告があり、どうやら MonoGame 3.6 での Windows 10 用の実装に問題があるようです。3.6 リリース後に修正したとの書き込みがあり、とりあえず修正したものを使いたい場合は開発ビルド版を使ってくださいとのことですが、ダウンロードページでそれをダウンロードしようとしてもファイルが見つからないようでした (リンクミス?)。

とりあえずは現状で我慢するか、開発版を探す、UWP8.1 を使う、3.7 を待つのいずれかになりそうです。私はずっと UWP8.1 版を使っていたので気づきませんでした( ^ ^;)。


ゲーム開発デモ版 Ver 0.50 を公開しました

2017-10-21_ゲームデモ版0.50

最近全然投稿できていなくてかなり間が空いてしまいましたがなんとかやっています。

制作動画のほうも一応話すネタとかはあるのですが、収録するタイミングが全然取れなくてあちらの方も投稿が止まっている状態です。ただ、制作のほうはスローペースですが作っており、今回デモ版を公開するに至りました。

とはいうものの、Ver 0.50 は何をメイン機能として公開しようかと考えていたのですが、これといって押せるような機能はなく、プレイしてみるとわかるのですが見た目とかは Ver 0.40 と大して変わっていません。まあ正直なところゲーム基盤は大体できてきたかなーっていう感じで、後は微調整とかテストとかコンテンツ制作とかデータとか作りこんでいく段階になっているので、今後のバージョンもそんなに見た目とかは操作感とかは変わらないかと思います。

Ver 0.50 の公開が遅くなったのもこのせいで、どの段階で区切りをつけようかと考えていてずるずる伸びていってしまったので、とりあえず現状でいったん区切ろう、ということで今回公開しました。

ちなみにゲームについてですが、操作方法とかは Ver 0.40 と同じです。ステージも1つのみで開始時にゲーム難易度を選択できます。今回仲間メンバーの数をかなり増やしたので、Ver 0.40 のように 0 になることはほとんどなく、難易度も前よりは簡単になっていると思います。ただ、敵味方共に強い攻撃を使うことがあるので油断せずに戦ってください。

ゲームは以下のページから遊ぶことができます。いつものように Internet Explorer & Silverlight でプレイしてください。

ほんとは UWP 版でプレイしてもらいたいのですが、こんな感じにデモ版のような感じで配布できるのかがわかっていないので様子見しています。Silverlight 版だとどうしてもカタついた動きになってしまうんですよね。


「ちーたんタッチボード Ver 1.01」を公開しました

今回はマイナーバージョンアップで不具合のみの修正となります。動作環境の変更や、ボード定義ファイルの変更、追加機能などは特にありません。

不具合修正

  • IsOneClickToggleRelease が true のトグルキーを指などで押下中に他のキーを押して離すと、トグルキーが解除されてしまう不具合を修正。(仕様変更にも見えますが、もともと決めていた仕様に合っていなかったので不具合としました)
  • 「00」のキーを押したときに 0 が2つ入力されないことがある不具合を修正

「00」キーの挙動についてはボードコンテナ定義ファイルの修正になりますので、アプリケーション側を更新しても不具合は解消されません。テンキー定義ファイルを直接修正するか、ボードパッケージをダウンロードして差し替えてください。


ゲーム開発デモ版 Ver 0.40 を公開しました

ブログや動画でもお伝えしていた通り、昨日ゲームの開発中デモ版 Ver 0.40 を公開しました。遊び方や改良点などは以前のブログや動画、また、ゲーム公開ページにも記載しているのでそちらをご覧ください。

ゲームは以下のページで公開しています。Silverlight を使用していますので Internet Explorer でアクセスしてください。

http://sorceryforce.net/ja/lab/gamedemoapp01ver0dec04

前にも記載した通り、パフォーマンスはそんなに良くないです。FPS が 60 を維持できない場合、特に移動中が少しがたつくかもしれません。移動中以外であれば、FPS が落ちても見た目はそんなにわからないと思います。

今回開発中バージョンということでそのままにしていますが、今後のバージョンでは負荷を下げるためになんらかの機能を省略するかもしれません。もちろん本リリースでは全機能を入れるつもりです。


しゃべりながらゲーム制作やってみます #32 命令とアイテム

前回の動画の Ver 0.40 紹介内容で残っていた「命令(クラスターコマンド)」と「アイテム」の紹介をしています。また、以前の投稿でのコメントにあった質問にも回答しています。

ゲームデモ Ver 0.40 についてはもう少ししたら公開できると思います。


しゃべりながらゲーム制作やってみます #31 Ver0.40 に向けて

約3か月ぶりの投稿、収録は5か月ぶりとかなり間が空いてしまいましたがやっと投稿できました。今回は Ver 0.40 に向けての追加した機能などを紹介しています。内容は動画や前のブログなどで説明しているのでそちらをご覧ください。


ゲームデモ版 Ver 0.40 公開予定について

最近は制作動画のほうの更新もなかなかできずにいたので情報公開がしばらくできていなかったのですが、一応プログラムのほうはちまちまと作っていました。Ver 0.40 は「この機能を入れる!」っていうような新機能はなかったのでどのあたりまで作りこむか迷っていたのですが、とりあえず各機能が問題ないレベルまで動くようになったのでそろそろ Ver 0.40 を公開しようかと思います。

現在のゲームイメージは下のようになります。

2017-04-21 22_17_57-ゲームデモ Ver 0.40 - β版開発室 - ソーサリーフォース - Internet Explorer

ゲームの操作方法や各説明についてはゲーム公開ページに載せる予定なのでここでは記載しません。

Ver 0.30 では2ステージから選択できていましたが、今回は1ステージのみとなっています。その代わり、ゲーム開始時に難易度を3種類から選択できるようになっています。ちなみに Ver 0.40 の難易度は過去3バージョンに比べるとかなり難しくなっていると思います。

難易度で「普通」を選択した場合でも、立ち回りをうまくしないとクリアが困難になる可能性があります。「簡単」を選択すれば相変わらず仲間が勝手にどんどん敵を倒してくれます。「難しい」を選択するとジリ貧状態まで追い込まれるので、作者自身がプレイしてもなかなか難しかったです。

ちなみに私が各難易度をクリアした結果は下のようになりました。神プレイを狙ったわけではなくとりあえず1回クリアしてみたものです。

2017-04-22 19_09_10-OneNote

2017-04-22 19_02_53-OneNote

2017-04-22 18_50_07-OneNote

「易しい」「普通」はそれなりの結果でクリアできたと思いますが、「難しい」はクリアに27分もかかってしまいました。敵の数に対して仲間が圧倒的に少ないので余計に時間がかかります。

今回のデモ版のクリア条件はすべての敵を倒すことです。ボスはいません。しかも敵は赤色と黄色がいるので、片方だけ攻めているともう一方に攻撃される可能性もありますので、マップを見て現在の状況を把握する必要があります。

ゲームのパフォーマンスについてですが、60FPS を出すのが結構難しい状態になっています。私の環境でゲームの設定を変えずにプレイした場合、敵の数が画面内に多くなったりすると40FPS ぐらいまで落ちてしまいました。試しに GPD WIN でプレイした場合は 20FPS でした。

一応負荷軽減対策としてゲーム開始前のオプションでユニットの配置数を変えることができるようになっています。もしまともにプレイできないようであればユニットの配置数を減らしてプレイしてみてください。逆にもっとユニットを出したい場合は増やしてみるのもいいかもしれません。

2017-04-22 21_15_23-OneNote[3]

ちなみにパフォーマンスがでない理由についてはよくわかっておりません。おそらくですが、ゲームプログラムが Internet Explorer を介して動いているため、その分余計なオーバーヘッドがかかっているのではないかと思っています。ちなみに UWP でも同じプログラムを使って動かしていますが、こちらの方は2倍程度高速に動いている感じです。

一応パフォーマンスを改善できる点はまだあるのですが、今後もまだ機能を追加するものがあるので、そちらの負荷が上がったときに改善しようと思っております。今回も開発版なのでそこまで最適化を行っているわけではありません。

今後の予定について

プログラムのほうは動作確認を残しているだけなので、早いうちに公開できると思います。その前に今回のバージョンに向けての制作動画を2本撮ったので、先にそちらの方の編集を行って公開した後にゲームを公開しようと思っております。

ちなみに Ver 0.40 になってもいまだに Game Demo  というタイトルなのですが、今はシステム構築がメインなので、Ver 0.50 公開あたりまではたぶんこのままだと思います。コンテンツなどは後半に行う予定です。


Windows 10 Mobile のアプリケーションは起動に20秒以上かかると起動せずに落ちる

Windows 10 Mobile のアプリケーションで起動時にファイル操作を「同期処理」であれこれやっていて結構時間がかかっているのですが、Visual Studio からデバッグ実行している限りでは問題なく動作し、W10M から単体でアプリケーションを起動すると、起動が完了する前に落ちてしまいます。

最初この現象の理由がわからずデバッグ実行での確認もできないので悩んでいました。例外をキャッチしてログを出すようにもしていたのですが、何でもないような処理のところでプログラムが落ち、例外もまったく発生しませんでした。

しかし、何回かやっているうちに気づいたのですが、ログの出力時間を確認したら最初のログの時間と落ちるタイミングの時間の差が20秒であることに気づきました。試しに Task.Delay.Wait で待機させるようにしたらもっと前の処理で落ちることを確認できました。

Windiws Phone 7 か 8 あたりでも、処理に時間がかかって UI? に処理を戻さないとアプリケーションが落ちるという話は聞いたことがあるのですが、このことをしばらく思い出せなくて盲点でした。デバッグ実行では落ちないし、例外も発生しないので気を付けなければいけませんね。

余談ですが、ファイルアクセス処理はファイルがあるかどうかのチェックだけでも1回あたり1秒ぐらいかかるので非同期処理のほうがいいですね。


「昭和元年度」は存在するのか?

年度と和暦が関係するシステムを構築するうえで気になる点がありいろいろ調べていったのですが、せっかくなので考えをまとめたものをブログに上げてみたいと思います。

ちなみにここではシステム屋目線で考えたものであり、実際に昭和元年度が存在するかどうかの答えは書いていません。おそらく仕様上そう表現すべきかどうか決めごとに落ち着くのではないかと思います。

前置きはこれぐらいにしておいて、まずは「平成元年度」について書いてみます。平成に改元されたのは「1989/1/8」で、下の表は西暦と和暦、年度と和暦年度を並べたものです、和暦年度という表現が正しいかどうかはわかりませんがここではそう表現させていただきます。また、年度については一般的に使われる会計年度として扱っています。

年月日 和暦 年度 和暦年度
1989/01/07 昭和64年 1988 昭和63年度
1989/01/08 平成元年 1988 昭和63年度
1989/03/31 平成元年 1988 昭和63年度
1989/04/01 平成元年 1989 平成元年度

年度について、3月末までは前の年として扱われ4月~12月末の間は西暦の年と一致することになっています。

1/8に年号が平成になるので、和暦年度も平成になっていいように思えますが、そうすると 1/8~3/31 の期間は「平成零年度」となってしまいます。平成零年なんてものは存在しないので、1989/3/31 までは前の年号である「昭和63年度」を使うのが正しいです。

このことをシステム的に考えて仕様にすると

  • 4/1~3/31 の期間の和暦年号は 4/1 時点の和暦年号で表現する

になると思います。

では本題の「昭和元年度」について考えてみます。平成のときと同じように表にまとめたのが以下のものです。

年月日 和暦 年度 和暦年度
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 までのたった7日間だけが昭和元年になります。そして 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 だとどう表現するんだろうを思って実際にやってみました。

まず、Excel で和暦表記を行うには、セルの書式をユーザー書式にして「ggge"年度"」とすると和暦表示になります。下図は単純に日付をそのまま書式設定で表示したものです。

2017-02-08 13_23_29-Book1 - Excel

改元したタイミングで年号の表記が切り替わってることが分かります。もう一度書きますが、上図は西暦をそのまま和暦表示しただけなのでの結果は間違いです。

これを実際に西暦から年度に変換して和暦表示するわけですが、ネットで探してみると以下の式を使う方法がありました。

  • ①=EDATE(A1,IF(MONTH(A1)<4,-12,0))
  • ②=EDATE(A1, -3)

上記の式を使用した結果が下図になります。

2017-02-08 13_33_03-Book1 - Excel

①は昭和から大正に戻ったりしているので明らかに間違いになります。②についても「昭和64年度」となっていたり、1927/3/25から昭和元年度が始まったりしているのでやはり正しくありません。これは指定した年月日から月だけを計算しなおしているので改元の日だけがずれたりして結果がおかしくなってしまうのです。

正しく表現するのであれば、最初の平成元年度の時に記載した「4/1」に統一するのがいいと思います。

  • ③=IF(MONTH(A2)<4,DATE(YEAR(A2)-1,4,1),DATE(YEAR(A2),4,1))

2017-02-08 13_34_56-Book1 - Excel

以上の Excel の結果からみると直接和暦年度を表現するような機能はなく、年度を自分で計算して和暦表記するような形になるようです。和暦年度の表現について「これだ!」と納得するようなものがなく一応自分の考えでまとめてみた形になりますが、もし意見等があればコメントいただければと思います。

ちなみに余談ですが、2019年の改元予定では改元日が2019/1/1になるようなので、元年度のパターンでいうと平成元年度と同じになりそうです。和暦や年度の扱いで恐怖されている方もいるかもしれませんが、平成元年度のパターンは1パターンしかないので仕様の検討では少しは楽になりそうですね。