2016年6月の日記

ほとんどの検索項目は検索結果が0件なので寂しい。
当サイトの利用者が伸びない理由の一つが、検索の手ごたえのなさではなかろうか。
期間が過ぎてしまった過去のイベント情報を表示すれば、今はないけど将来はイベントがあるかもしれないとの期待から、利用が伸びるのではなかろうか。

当たり判定作成中。
浮遊状態で壁に当たったときの挙動を作りました。
斜め線に対応したのはもちろんのこと、ふにゃさんのときと同じ方式ですり抜け防止も行っています。
壁に当たると壁に沿って滑るように動きますが、このやり方を応用すれば壁で反射というのもできそうです。

氷の息が斜めの壁で反射するというのも実現できそうです。
これは、ふにゃふにゃのときに、やろうと思ったけど泣く泣く諦めた要素でした。
ふにゃさんのときは、反射はしたけど、斜めじゃないから出来たことでした。
それが、妥協なく実現できそうなのです。

よく考えたら、息が球状でしかも壁で反射するって変なんですが、ふにゃが攻撃に使う「息」は、エネルギー弾系属性ブレスなので、わりと跳ねるのです。
なんとかボールに出てきたなんとか人がよく使うなんとか波みたいな概念なのですが、ふにゃの息は弱いので、気を使いこなす戦士じゃなくても跳ね返せて、それこそ、何の能力も持たない壁でも跳ね返せちゃうのです。
なんか変な気もしますが、そういうものなのです。

当たり判定作成中。
今回はふにゃふにゃのとき以来の斜め線が復活するので、この辺りをもっとしっかり作り込もうと考えています。

第4話クリア。
ネタバレになっちゃうけど、ナユタ検事の法廷…これまで全部1日で判決が出てる…。
最終話ぐらいはきっちり日数使うんだろうけど…どうなるんだろう。

第3話クリア。
ナユタ検事は弁護側に生半可な慈悲をかけなくて、倒すべき敵として大変好感が持てます。

スプライトエディタ完成。
厳密にはテスト用プログラムの中に作った簡易的なエディタなので本当の完成からはまだ遠いのですが、エディタでないと入力が面倒な項目は滞りなく入れられるようになりました。
とりあえず、ふにゃさん仕様のふにゃのスプライトデータが記入完了。
これで思う存分ふにゃの動きをプログラミングできるってものです。

それから、ドラゴンクエスト10のプレイヤーイベントを検索および通知するサイトのベータ5を公開しました。
機能的には何も変わっていませんが、SSL対応しました。
これまでは全データが平文で流れていたのでセキュリティ上の不安がありましたが、暗号化通信に対応したので、これからはもう安心です。
本当に安心するにはプライバシーポリシーも作る必要もありますが、それはまた今度ということで。

スプライトエディタ開発中。
チップ情報をある程度入れられるようになってきました。
WPFのバインディング機能をできる限り使っています。
おかげで、C#のコードはかなり少なめです。

スプライトエディタのためのカスタムコントロール作成中。
WPFらしく依存プロパティとか積極的に使うようにしています。
とりあえずスプライトの切り出し範囲を表すチップを選ぶコントロールがいい感じにできてきました。

画像リソースの扱いを変更。
スプライトという扱いにしました。
そして、スプライトエディタの開発も開始。
単純なJSONのデータとはいえ、手打ちじゃ面倒なのです。

第2話クリア。
具体的なネタバレは控えますが、菜々野さんが大変良いキャラクターをしていました。
あと、どの場所でもいろいろ調べられるのが復活していたのも素晴らしい。

JSONによる画像情報の読み込み。
C#でもJavaScriptでも、ついでにPHPとかいろんな言語でも簡単に使えて、人間でも簡単に書けて、構造化も簡単な形式ということで、JSONにしました。
独自形式はもう面倒くさいですからね。
ステージデータとかはサイズが大きくなりそうなんで独自形式が必要になるかもしれませんが、簡単な情報はもうだいたいJSONで済ませちゃおうと思います。
最悪、別の形式を最終的に採用することになったって、コンバートもまた簡単です。

ゼルダの伝説ブレスオブザワイルド、発表されましたね。
PV以外の動画は長かったので見ていませんが、いっそこのままあまり情報を仕入れずに発売を待つのがいいかもしれませんね。

HTML5+JavaScript版をちょっと作ってます。
DuoCodeのおかげで、コア部分に関しては全く手直しなしで出来上がります。
表示に関しては完全にプラットフォーム依存なので1から書き直しですが。

浮遊の基本動作を実装。
ふにゃさんが40FPSだったのに対してfunyakは60FPSを前提にしているので、フレームごとのアクションの大きさはほぼ3分の2にしています。
角度の単位がyaneSDKと違っていた(一周512→360)ので、そのあたりの換算もしています。
あとは、浮遊状態と通常状態を別クラスに分けず、一つのクラスにまとめることにしました。
動きは全く異なるものの、基本的な要素は同じですからね。

funyak。
funyakはライブラリっぽい使い方をするので、ドキュメントコメントとか入れまくって、使いやすいように修正していました。
あと、いらなくなったプロジェクトを整理したり、主人公の動きをぼちぼち作り始めたり。

mifumitter。
ハッシュタグの扱いがおかしくなっていたので修正しました。

逆転裁判6。
第1話クリアしました。
4のあたりからそうだったんですが、第1話から結構長丁場ですね。

funyak。
DuoCodeによるJavaScriptへのコンパイルを試していました。
JavaScriptにコンパイルできるのはコードだけなので、普通にC#としても使えてJavaScriptにもコンパイルできるよう、コア部分のコードを共有プロジェクトに移しました。
共有プロジェクトにすることで、C#としてコンパイルしたDLLではなく、コードそのものを共通化できるのです。
コードファイルのリンクと違って、コードが増えても自動的に共有されるというのもうれしいところです。

逆転裁判6。
買いました。
とりあえずゲーム記にも反映させておきました。

主人公の表示などを作成。
その関連で、リソース管理やら座標の計算方法なども見直しました。

JavaScript版の開発の助けになるようなフレームワーク調査中。
phina.jsがかわいい(そういう問題ではない)。

ピラミッドの家買いました。
うん、ちっこいね。

画像リソース管理作成中。
正直、どうするか決まり切っていないので、あれこれ試しながら仕様を決めていくつもりです。

モンスター情報の機能追加のためアイテムの機能を分離。
しかし非同期処理でデッドロックが発生するなどのトラブルが発生。
UWPの非同期処理はまだまだ考慮すべきことが多そうです。

ロックしたり別のデスクトップに移動したりしていると動きが止まる模様。
UWPって何かと制約が多いですね。
ともあれ、アイテムのURLは一通り最新のものに更新できました。

TGWSDQX用のURL取得プログラムをUWPで書き直していました。
UWPにもウェブブラウザ的なコントロールは最新のEdge仕様になって搭載されていたのですが、従来のWebBrowserとはいろいろ勝手が異なっていて大変でした。
やっぱり非同期処理と、ソースの取得が難関でした。
非同期処理は、async、await、Dispatcher、AutoResetEventをバリバリ使うことで一応解決。
ソースの取得は、そのままではできないので、JavaScriptの任意のコードを実行できるevalをUWP側から呼んで解決。
source = await wb.InvokeScriptAsync("eval", new string[] { "document.documentElement.outerHTML;" });

昨日言っていた画像の扱いのうち、共通となる(はずの)切り抜き情報を実装していました。
元画像のどの範囲から切り抜くか、表示先にどの大きさで表示するか、表示の基準点はどこになるか、そのあたりのデータを持つようにしています。
実際に使うときは、インデックス番号か名前でこの情報か描画データを取得して、表示するという形になります。

画像の取り扱いについて検討中。

キャラクター画像とかはシンプルに1キャラクター1画像でいいんだけど、ステージ画像とかは、ユーザーの選んだ画像がドカドカ入り込んでくる。
普通の画像としてBMP、PNG、JPG、GIFは当然対応するとして、個人的にはSVGにも対応したい。
アニメーションGIFを取り込んだならアニメーションすることを期待するのが当然だから、できることならこれも対応したい。

複数の画像を仮想的に一つの画像のように扱うというのも考えたけど、そんなの付けたところで、ユーザーはついてこないし、開発者はそれを避けることができる。
何より、仮想的なリソースと物理的なリソースの管理を別々に行う必要が出てくるなど、仕組みの開発が大変になるので、実装する価値をあまり感じない。

画像は全体をひとまとまりとして使うわけではなく、一部を切り抜いて使う。
従来はこの切り抜き方を全部ハードコーディングしていたけど、この部分もデータとして外部に出したい。

一つの画像データと一つの切り抜き定義データ(このデータの中には個々の切り抜き情報が複数入る)を一組として取り扱うのがいいか。

ベータ4。
今回の更新内容は大きく2つ。

1. 画像資料のページへのリンク
2. ツイートボタンの設置

画像資料のページへのリンクの方が今回重要な更新です。
そもそもアンパンマンDBでは、画像は「記事内容の説明に必要だから」「引用」しているという形で用いています。
アンパネイターも例外ではなく、「提示するキャラクターを判別するのに重要な情報だから」使っています。
しかしながら、これまでの実装では、引用が認められるために重要な要件「出典の明記」が抜け落ち、ただ画像を表示しているだけでした。
これでは何か言われたときに何も言い訳できません。
そんなわけで、出典を明記できる方法が必要だったのです。

また、アンパネイターに表示される画像は、表示エリアの関係上、小さいです。
キャラクターが大写しになっている場面でもなければ、視認性はさほど良くはないです。
そのため、拡大画像を参照する手段も必要でした。

出典と拡大画像、その両方を兼ね備えているのは、画像資料ページです。
アンパネイターのページ本体に出典を記載して拡大画像へのリンクも設置するというのも考えたのですが、両方あるページがある以上、そちらを参照するだけで足ります。
であれば、アンパネイターのページにあれこれ書いてごちゃごちゃさせるよりも、シンプルに画像資料ページにリンクすればよいというわけです。
出典と拡大画像へのリンクは、画像があるときにだけページ下部に表示されます。

ツイートボタンの方は、単に宣伝目的でつけました。
たくさんの人が遊んで初めて楽しくなるものですからね。
文面は本家Akinatorを意識しています。

本当はツイートボタンの方が先にできていたのですが、画像の出典の問題が解決するまで積極的な宣伝はするべきでないと判断して、今回の画像の件と同時に公開することになりました。
後は、アンパンマンDBとの連携と、判明しているバグの修正が終われば、正式版としてリリースできそうです。