イカガカの要素技術（伺か Advent Calendar 2016）

もう2017年も半ば過ぎ、ここらで停滞しているWebベースウェア「イカガカ」の要素技術について一旦軽くまとめてみようかと思います。

なおこれは本来伺か Advent Calendar 2016 17日目の枠に入るはずの記事でした（ぉ

イカガカは2014年末から2015年初頭にかけて精力的に開発していたですが、その後は仕事とかで忙しくなったのもありユーザーの目に見える進捗はありませんでした。
現在は初期に手探りで作ったコードが色々とイケてなかったのを改めて書き直している感じです。

さて、イカガカはそもそも「デスクトップマスコットソフトウェア(伺か)をブラウザ上で実現する」というなかなかニッチなことをするソフトウェアです。
Windowsデスクトップ用アプリケーションであるmateria.exeやssp.exe等に渡すのと全く同じnar(キャラクターデータ)をブラウザに放り込んでそのまんま動いている背後では、デスクトップ用のものとほとんど別の技術が動いています。
その辺の技術やライブラリについてざっくりまとめることで、現状を伝えられたらと思います。

1. シェル描画系
2. さくらスクリプト
3. surfaces.txt
4. SHIORIサブシステム
5. SHIORIプロトコル
6. ファイルシステム
7. ベースウェア
8. デスクトップ・スマートフォン対応
9. 技術・ライブラリの一覧
10. まとめ

シェル描画系

cuttlebone
そもそもイカガカはシェル＆バルーン描画ライブラリ「如何か」としてduxcaさんによって作られたのが最初です。
その後自分が参入してベースウェア機能をつけたのを「イカガカ」と呼び始めたので、描画ライブラリは現在cuttleboneという名前になっています。

描画については、SSPがGDI=Win32APIを直接使って色々なんとかしているのに対し、cuttleboneはブラウザのDOM APIとcanvasを使って同等の機能を実装しようとしています。
基本的にクリック判定＆レイヤー付き2次元アニメーションが出来ればいいのでまあ頑張ればおおかた再実装可能かとは思うんですが、アニメーションや着せ替えの仕様とかは複雑で大変そうです。
canvasで主に非透過pngの色抜きとelementの合成を行い、その他レイヤー管理とかバルーンとかはDOMでやってるかんじです。

助かった点としては、フォント指定(\f)の色指定や位置移動(\_l)の移動単位などSSP拡張さくらスクリプトのいくつかは、HTML/CSSでの指定と同じ種類のものを使っていて実装がしやすかったあたりがあります。
一方でフォント描画方法としてGDIのSetROP2をそのまま使う感じの指定があったりするのは現状では互換が難しそうなので悩ましい感じです。

なおイカガカ専用というわけではなく、ライブラリ単体をサイトに設置してシェルのプレビューするとかにも使えるようなので、興味あればのぞいてみて下さい。

react-ukagaka-shell-pixi
一方もう一つ、react-ukagaka-shell-pixiというプロジェクトもやっています。シェルを全部VirtualDOM的かつWebGLで描画するのを目標としています。

cuttleboneはもう現状でもかなりの仕様が動くんですが、遅い箇所などもあったりAPIの癖などもあるので、そのあたりを新規に作り直したら……という実験です。
またこちらは低レベルの描画に近いので元々のGDIっぽい描画の指定もすんなり実現できるかもしれません。

現状バルーンの文字描画についてはおおむね出来ているんですが、シェル系やアニメーションの考慮がまだ全く無い感じです。

課題
cuttleboneのAPIが色々と密結合で現在作成中のベースウェア部分と整合がいまいちなあたり、react-ukagaka-shell-pixiはシェル系の合成メソッドを実現するためのアーキテクチャが思いついていないあたりが課題だと思っています。

前者はその辺のインターフェース設計をやったことある人……？（ぽなさん……？）
後者あたりはシェルやら描画やらreact-pixiについて造詣が深い人がいると捗りそう……。
reactでやるのがむりだったら捨てるのもアリですが、まだ方法を考えたいです。

さくらスクリプト

伺かの動作は独自のマークアップ言語、さくらスクリプトというものが司っています。

これについては元々雑に正規表現で扱ってたんですか、パーサー「sakurascript」と時間に沿って実行をするライブラリ「sakurascript-executer.js」を作りました。

課題
単純に未対応スクリプトが結構あります。これはまあ正規表現を書けって話ですね。
ただパーサー未対応とは別にシェルの方で未対応って言うのもあってこっちは悩ましいです。

surfaces.txt

シェルの描画そのものをするのも大変ですが、伺かにおいて最も大変なことの一つはsurfaces.txtの取り扱いではないでしょうか。
独自形式で複雑な仕様である上に、SSPがかなり寛容に取り扱うおかげで「記述仕様としては誤っているが動いている」というゴーストが結構存在します。
この「誤った記述」の場合記述の場合どのように解釈するかというのが全然分からなかったりしてなかなかつらいところです。

「如何か」時代のduxcaさんも悩んでいたみたいなのですが、自分がイカガカをベースウェアとして開発する前に作っていたsurfaces_txt2yamlというライブラリが（本来想定された用途とは違うのですが案外）役立ち、これを改変したものがcuttleboneで現在使われています。

課題
surfaces_txt2yamlはかなりテキトーに作ってあり、控えめに言ってあまり使い勝手が良くはないです。
使い勝手の良いsurfaces.txtのパーサー・ビルダーが出来れば伺かサーフェスビルダーなんかの夢も広がって良さそうなので、これとは別にどなたかやってみませんかね？

SHIORIサブシステム

SHIORIサブシステムはまさにゴーストの根幹ですが、ここが最も黒魔術を使っている部分です。
なぜならここは伺かの仕様では「こういう入出力を持ったWindowsのDLL」という定義、つまり自由なプログラムが書ける箇所なので、そのプログラムをそのままブラウザで動くようにしないとコストが高すぎる箇所だからです。

幸いにしてPC上で動くプログラムをブラウザ上でも動くように変換するEmscriptenという黒魔術的技術が存在するので、それを使って主要なオープンソース汎用SHIORIサブシステムである「華和梨8」、「華和梨7」、「里々」、「YAYA」、「文5」に関して動作するようにできました。

これはもともとUNIX系OSで伺かを動かそうというninix-ayaプロジェクトの為にWindowsに依存しないコードベースが各SHIORIに存在したのが大きく、少数のパッチをあてるだけですんなり変換できました。
なので自分が現状作業したのはその少数のパッチ当てとkawari.jsにあるようなEmscripten用Makefileの作成くらいです。

ただやはり黒魔術を使う最も自由な仕様の部分なのでまだまだ課題も多いです。

課題1（比較的簡単そう）
1つめの課題は、現在も更新を続けている里々やYAYAの更新に自動追従が出来ていないあたりでしょうか。

CIとかでカジュアルに更新をかけていく仕組みを作りたいですね。

課題2（やや難しそう）
2つめの課題は、SHIORIのプラグイン機構「SAORI」に対応していない点です。

これはDLLからのDLL呼び出しという機能を実現せねばなりません。Emscriptenにおけるこのあたりの仕様について追っていく必要があります。
またそれを実装したとして、呼び出すSAORI DLLもクローズドソースなものが多いのでそちらの実装工数もバカになりません。
現状はこのインターフェースをつぶすことで動作させている状況です。

おそらく現行のイカガカについてここが最も要望が多く、かつヘルプが欲しいところであります。
自分がSAORIを使ったことがないのでSAORIの利用状況なども把握しておらず、目処が立っていません。

課題3（かなり難しそう）
3つめの課題は、クローズドソースな栞、特に主要に使われているSHIORIのうち「美坂」のみクローズドソースなのでエミュレートの目処がたっていない点です。

ninix-ayaではPythonで独自に実装することで回避していたようですが、少なくともこれをJavaScriptに置き換えるなどの作業が必要です。
おそらく新規ゴーストのほとんどは美坂を使っていないようですが、やはり昔のゴーストを動かしたいものです。
いまのところ優先度は高くないですが、よろしければご協力お願いいたします。

またその他の新しいSHIORIサブシステムについてはJavaScriptへの変換が出来れば対応することが出来ますので、イカガカに標準で入れたい場合は言って下さい。
ゴースト独自のSHIORIを使う等の場合も、descript.txtにJavaScript版の指定を追加するなどで使えるようにしたいと思っています。

課題4（ものによっては目処が立たない）
4つめの課題は、汎用言語SHIORIへの対応です。

SHIORI独自言語ではなく汎用言語によるSHIORIサブシステムへの対応は是非したいと思っていて、むしろそれを推していきたいんですが、RubyやPythonなどをブラウザ上で動かすというのはなかなか難しいところがあります。

一応lua.vm.jsなどをはじめとしてJavaScriptで動かそうというプロジェクトは各言語にあるんですが、やはりなかなか難しいようです。
よしんば言語レベルで対応できたとしても、イカガカはnarをそのまま動かすのを目標としています。ファイルシステムのエミュレーションなど課題は尽きません。

汎用言語の中でもJavaScriptなら動くのでは？というのも難しい問題で、narをそのまま動かすにはファイルシステムのエミュレーションをしたうえでnode.jsの仕様にあるrequireを動作させなければ実用的ではありません。
このrequire対応についてはbrowserfs-module.jsというのを作ってかなり力業で対応したのですが、まだテストをする時間を取れておらず、本当に動くのかは未知数です。

これはイカガカに限らず、デスクトップアプリケーションをいかにブラウザ上で動作させるかという問題なので、ご興味ある方は是非ご協力下さい。

SHIORIプロトコル

SHIORIプロトコルは前述のSHIORIサブシステムとベースウェアの通信仕様です。
これがないとDLLを変換してもSHIORIサブシステムを動かすことは出来ません。

このSHIORIプロトコルのパーサー・ビルダーはベースウェアであるイカガカだけではなく、SHIORIサブシステム側でも使うものなので、それ用に複数の言語で実装しました。

- JavaScript: ShioriJK
- Ruby: Shioruby
- C: cshioriの中のcshiori.hとcshiori.c
- Go: shiori.go

各言語でSHIORIサブシステムを作る場合はご活用下さい。

なおJavaScript版は最初にはりきって作ったので、HTTPのようにチャンクで渡ってきても処理できるようなのもパーサーに含まれていたりします（SHIORIプロトコルの仕様にはない）。

参考までに、拙作のSHIORIサブシステムとしては

- JavaScript: MiyoJS, SanaJK
- Ruby: Sana(紗凪), sana-mvcbase
- C: cshiori

等があります。

SHIORI/2.x / SHIORI/3.x 両対応
またSHIORIにはSHIORI/2.xとSHIORI/3.xというバージョンがあります。
イカガカで対応しているSHIORIサブシステムの中でも、華和梨7と文5は古いSHIORI/2.xで通信をする必要があるので、標準のSHIORI/3.xと両対応する必要があります。

これについては内部的にはSHIORI/3.xで扱いつつ、SHIORI/2.xとの変換レイヤーをもうけることにしました。

2.xと3.xの変換をかけられるshiori_converterと、リクエストとレスポンスとをひとまとまりとして扱って、そのまとまりを2.xか3.xとして扱うshiori_transactionを噛ますことでスムーズに判定＆変換ができます。
さらに実際にSHIORIサブシステムを呼ぶところを司るshiorifでこれらを透過的に扱えるようにしています。

課題
shiori_converterはうさださくらの資料と華和梨8の実装などを参考に結構手探りで作ったので、バグがあることが予想されます。
あとRequest 3.x→2.x、Response 2.x→3.x以外の変換は現状必要ないので実装していません。

ただ基本的に新しいゴーストには関係ないところなので、あまり問題ではない感じです。

ファイルシステム

一般にデスクトップアプリケーションと同等機能をブラウザで動かすという場合に一番障害になるのがおそらくファイルシステムでしょう。なぜならファイルシステムという概念がブラウザにはそもそも存在しないからです。
「データを保存できる場所」としてLocalStorageやIndexedDBなどいくつかの場所は存在するのですが、ローカルのファイルシステムには基本的にアクセスが不可能です。
というわけで、とくにSHIORI等がファイルシステムを前提として動いている伺かを移植するためには、何らかの方法でファイルシステムをエミュレートしてやる必要があります。

これについてはBrowserFSというファイルシステムをエミュレートするライブラリを利用したうえで、NanikaStorage（名前が微妙）という伺かベースウェアのファイル操作を担うライブラリを噛まして実現しています。

NanikaStorageは一般のファイルシステムにも使えるので、ベースウェア操作のエミュレートをしたい場合などにも使えるかも知れません。

課題
まあ、遅いです。イカガカでのゴースト起動の遅さはこことSHIORI初期化とシェル初期化です。
IndexedDBと言うところから読み出してメモリーに全部コピーして転送する＆書き戻すみたいなことやっているので泥臭いしバグい。

ブラウザの非同期ファイルシステムAPIとEmscripten FSのうまいつきあい方を知っている方はいませんかね？

ベースウェア

さて、これら要素技術を組み合わせて「伺かベースウェア」として動作させる存在が必要です。

現在デモで動いている旧バージョンは単体のゴーストを動かすNanikaと複数ゴーストを管理するNanikaManagerがベースです。

現在作り直し中なのはghost-kernel.jsで、色々試行錯誤しながら作っています。

Webサイトくらいならイベント駆動といってもサーバーならHTTP通信、ブラウザならユーザー操作のそれぞれ1つなので簡単ですが、伺かベースウェアではシェル（ユーザー入力）、さくらスクリプトの時限実行、毎秒毎分ごとのイベント発行、ユーザーや他ゴーストからのコミュニケート、SSTPによる外部通信など色々な入力ソースがあるので複数入力ソース用のイベント管理ライブラリlazy-event-router.jsを作ったりしてなかなか大変です。
自作が目的ではないので、そういう複数入力ソース用のイベント管理ライブラリで良いのがあったら教えていただけると助かります。

課題
シェルのインターフェースが定まっていないのでそことのつなぎが止まっていること、イベント駆動の管理の良いアーキテクチャが手探りで色々変わっていることなどの要因で、まあ全く安定していませんし、物量も多いです。

ここに関しては不安定すぎてまだヘルプを請えるような状態でもないので難しいところです……。

デスクトップ・スマートフォン対応

さて、そうして組み上げたイカガカは現状PCブラウザ上で動く事を第一目標としていますが、これを逆にデスクトップアプリケーションにしたり、あるいはスマートフォンで動かすなどにはもう一工夫必要です。
課題は山積みです。

デスクトップアプリケーション
そもそもデスクトップにはSSPがあるじゃんって話なんですが、WineをインストールしなくてもLinuxやMacで動くと嬉しいですよね？（たぶん）
あとイカガカのライブラリ群を使ってゴーストエディターとかデバッガーが出来るといいなとも思っています。

過去にはnode-webkit(現nw.js)でサンプルを作ったことがあるんですが、現状だとelectronのほうが知見が多そうなのでそちらでやろうかと考えています。

ブラウザと違って、ファイルシステムをエミュレートせずに実FSを使う、またWindowsでは普通にDLLを読み込んで使うなどが出来るので、そのあたりの対応が必要です。

スマートフォン
イカガカのベースウェアはもともとスマートフォンに脅威を感じてはじめたプロジェクトなんですが、現状スマホでいい感じに伺かを使うというのはなかなか難しいところです。

そもそも「デスクトップ」が存在しないのでたぶんアプリとして切り替えるしかなく、大分体感が変わります。
またマウス前提で作られたUIをどうタッチ対応するか、などの考慮も必要です。
ブラウザを立ち上げてタブ切り替え、というのはなかなか手間がかかるので、出来ればCordovaなどでアプリにしたいところですね。

また、そもそもホームアプリに伺かを含んでしまってデスクトップ相当を乗っ取ってしまうという逆転の発想も試してみたいところです。

DOMLauncherやHTMLauncherなどのブラウザ技術でランチャーが作れるものが存在するらしいので、そのあたりをいじると出来そうな気はしますね。

この辺言っているだけで全く着手など出来ていないです。スマホ対応とか新体感で面白そうなのでおすすめです。

技術・ライブラリの一覧

以上で上げた以外にも、小物的に色々なライブラリを作りつつイカガカは構成されています。
現状イカガカに興味があってもどこからみたらわからない状態だと思うので、俯瞰の為に下記に簡単な一覧をあげておきます。
新しいものはTypeScript、古いものはES2015かCoffeeScriptで書いてある率が多いです。

---

ベースウェア本体関係

Ikagaka/ghost-kernel.js
ベースウェアで単体ゴーストを動作させるカーネル部分。
鋭意制作中です。

Ikagaka/named-kernel-manager.js
複数ゴーストを管理する部分です。今はまだほとんど実装がありません。

Ikagaka/ikagaka-application
たぶん将来的にブートストラップはここからやります。今はまだ何もありません。

Ikagaka/ukagaka-timer-event-source.js
ベースウェアが発行する時限イベント（OnSecondChange等）の元となるイベントソース。
ほぼsetIntervalしかしてないですが、モジュールとして切り出すのがきれいだと思ったのでこれだけでライブラリになっています。

Narazaka/lazy-event-router.js
複数のイベントソースを持つイカガカのイベント処理の為に作ったイベント管理ライブラリ。
他にそういういいのがあったら教えて下さい。

---

SHIORIサブシステム関係

Narazaka/shiorijk
SHIORIプロトコルパーサー・ビルダー・コンテナ。
ベースウェアでもSHIORIでも使えます。

Narazaka/shiori_converter.js
SHIORI/2.xとSHIORI/3.xを同義変換する為のライブラリ。
現状ベースウェア実装に必要なRequest 3.x→2.x、Response 2.x→3.xの変換のみ実装しています。

Narazaka/shiori_transaction.js
SHIORIプロトコルのリクエストとレスポンスをまとめて扱い、上記変換を便利にするライブラリ。

Ikagaka/ShioriLoader
SHIORIサブシステムをファイルシステムから種類判定してロードする為のライブラリ。
判定関数はプラグイン式で、デフォルトの判定はIkagaka/shioridetector-common_namesに書いてあります。

Ikagaka/shiorif
ロードしたSHIORIサブシステムと通信する為のライブラリ。
shiori_transaction.jsやshiori_converter.jsと連携して、SHIORI/2.x、SHIORI/3.xを変換しつつ透過的に扱えます。

Narazaka/nativeshiori
Emscripten変換したSHIORIサブシステムとCのインターフェースで通信する為に、メモリ管理や文字コード変換などを請け負うライブラリ。
イカガカ外でもEmscripten変換したSHIORIサブシステムを単体で扱いたい場合には重宝します。

Narazaka/WorkerClientServer
WebWorkersをクライアント・サーバー方式っぽく扱うラッパーライブラリ。
SHIORIプロトコルがクライアント・サーバー方式なので、SHIORIサブシステムをワーカーで使うために作成。
他の良い感じのがあれば教えて下さい。

Narazaka/single-file-worker.js
どこにスクリプトを置いてもWebWorkerが動かせるような仕組みにする為に、文字列で埋め込んだスクリプトを起動する為の仕組みです。
他の良い感じのがあれば教えて下さい。

Ikagaka/NativeShioriWorker
SHIORIをブラウザのWebWorker上で動作させるライブラリをつくるツール＆ライブラリ。魔術的な操作をやっているので、たぶん将来的には別の仕組みを作るんじゃないかと思います。
主にsingle-file-worker.jsを使う為に魔術的な変換をかますやつです。

各種SHIORIサブシステム
汎用SHIORIサブシステムをEmscriptenで変換したものです。
- 華和梨: Narazaka/kawari.js
- 華和梨7: Narazaka/kawari7.js
- 里々: Narazaka/libsatori.js
- YAYA: Narazaka/yaya.js
- 文5: Narazaka/aya5.js

各種SHIORIサブシステムのワーカー
上記をWebWorker上で動くようにしたもの。魔術的なNativeShioriWorkerを使っています。
- 華和梨: Narazaka/kawariworker.js
- 華和梨7: Narazaka/kawari7worker.js
- 里々: Narazaka/satoriworker.js
- YAYA: Narazaka/yayaworker.js
- 文5: Narazaka/aya5worker.js

---

シェル関係

Ikagaka/ukagaka-install-descript-info.js
narに含まれるinstall.txtと各種descript.txtのパーサー・コンテナ。TypeScriptの型定義も含んでいるので、プロパティが便利に参照できます。
ただしまだシェルくらいしか型定義が充実していないので整備する必要はあります。

Ikagaka/cuttlebone
シェル描画ライブラリ。従来からのもの。
IkagakaのグループにShell.js, Balloon.js, NamedManager.jsというのがありますが、これらはcuttleboneのコンポーネントです。

Ikagaka/react-ukagaka-shell-pixi.js
シェル描画ライブラリ。新規APIの実験。シェルの状態を持ったモデルと実際の描画とを別々にする思想の元設計されています。
react-pixiというものを使っていて、副作用を持たない描画ライブラリです。アニメーションについては都度更新をかける必要があります。
バルーンはある程度出来ていますが、まだシェル部分の多くが開発中です。

Ikagaka/ikagaka-shell-state
cuttlebone風のAPIを持ったシェルの状態モデルです。

Ikagaka/ikagaka-shell-loader
シェルをnarからロードするライブラリです。

Ikagaka/ghost-urn.js
シェルの新しいAPIを考える為のリポジトリです。

Narazaka/surfaces_txt2yaml
surfaces.txtをパースして構造化データにするツールです。これを直接ではありませんが、改変したものがcuttleboneで使われているとのことです。
元々はsiurfaces.ymlという構造化データからsurfaces.txtを作るsurfaces_yamlというツールの逆変換ツールでした。

---

さくらスクリプト関係

Ikagaka/sakurascript
さくらスクリプトパーサー・コンテナ。
これ単体はスクリプトをパースしてオブジェクトにするだけです。

Ikagaka/sakurascript-executer.js
さくらスクリプト実行機。
パースされたさくらスクリプトオブジェクト群のうち時間関係の部分を考慮して、その他のスクリプトを含んだイベントを時限発行してゆくものです。

---

ファイルシステム関係

Ikagaka/NanikaStorage
ベースウェアが行うファイルシステムの操作をラップするライブラリです。
narを展開する場所が分かるとか、シェルのフォルダだけ置き換えるとかがメソッド1発で可能です。ukagaka-install-descript-info.jsと連携してdescript.txtの中身なんかも簡単に取れます。

Ikagaka/NarLoader
narを読み込む部分です。jszipでzip展開して、NanikaStorageでnarの中身をファイルシステムのように読み出せるようになっています。

Narazaka/fso
イカガカ用ではありませんが、ファイルシステム操作の為に広く使っています。

jvilk/BrowserFS
同じくイカガカ用ではありませんが、ブラウザ上でのファイルシステムエミュレートの為に必須のライブラリです。

---

その他

Ikagaka/Ikagaka.demo
デモ用のWebサイト。旧バージョンのベースウェアシステムが元気に動いているイカガカのデモですが、SHIORIサブシステムの更新とかはこのリポジトリを細々と書き換えたりしています。

Narazaka/ikadoc
イカガカの現行仕様まとめのためのリポジトリでした。
今デモで動いている旧バージョンの情報としてはおおむね正しかったはずです。

まとめ

以上、ざっくり技術やライブラリについてまとめてみました。
こんな感じがおおまかな現状です。

全体的に仕様の大きさと異色の難度で大変なことになっていますが、部分的になら意外と出来ているもんです。
イカガカの作業中に作られた色々なライブラリを使って、周辺ツールを作ってみても有益だと思います。

その辺も含めて、イカガカは主に作業時間の不足による開発長期化で割と死んでるので、特に現状の2人の開発勢では対応できないことなど、なにかやってみたいって人がいるといいなって思ってます。

このほかにもSHIOLINKなどで汎用SHIORIサブシステムを作るなどもやっています。
今後10年戦えるベースウェアや周辺ツールを作って伺か文化を振興したい思いはあるので、なんか一家言ある人は色々言って下さい。

以上現状報告でした。

【伺か】イカガカ(如何か)の作業進捗とこれから

伺か Advent Calendar 2015もはやいもので20日目。
前日は潮留さんのseriko.use_self_alpha,1を使ったシェル作成でした。

さて、私奈良阪とduxcaさんの合弁によって昨年久々にmateriaとSSPではない第三のベースウェアとしてイカガカが作られました。
ですが、今年は仕事が忙しくてなかなか触れず開発が停滞していました。

このままフェードアウトして再びmateriaとSSPが次のベースウェアを待ち続ける展開にならぬよう、現状をいったん整理したいと思います。

前に内部技術よりのことは書いた気がするので、主にゴースト開発者、俗に言うデベ向けの記事です。

・イカガカとは
・用途に対しての進捗
・ゴースト(SHIORI)対応進捗
・シェル対応進捗
・バルーン(さくらスクリプト)対応進捗
・その他進捗
・概況
・要望募集
・以上

イカガカとは

まず改めてイカガカ(如何か)について説明します。
（「如何か」だとあんまりにも検索性が悪かったので「イカガカ」とカタカナ表記にしてみたものの、でも結局引っかからないという地獄）

イカガカは伺かのベースウェアです。

既存のベースウェアとしては、始祖であるmateriaとデファクトスタンダードであるSSPなどが有名です。
他にはCROW、DAEや、他OSならPocketDAE、偽林檎、ninix、Pocket Ghost、Aremodoki、Androidの伺か、Nanidroidなどがあります（ありました）。
イカガカもこれらと同じベースウェアの一種です。

既存のすべてのベースウェアは何らかのOSの上で動きますが、イカガカはOS上ではなくブラウザ上での動作を想定していることが特徴で、従来よりも幅広い用途を想定しています。

イカガカはまた、ninix、OpenDAE、Nanidroidなどと同じくオープンソースのベースウェアの一つです。

用途に対しての進捗

イカガカはブラウザ上での動作をベースとしています。
その上で、Electronあるいはnw.jsというライブラリを使ってデスクトップアプリケーションとしてもリリースしたいと考えています。

ブラウザでの用途としては、

・ユーザーとしてスマートフォンでいろいろなゴーストをインストールして携帯伺かとして楽しむ: △ いちおうイカガカのデモページで可能
・配布側として自分の配布サイトにゴーストをたたせる: × イカガカが手軽に配布できるようになっていない
・ブラウザ上でゴーストの開発ができるようにする: × イカガカをライブラリとして使う準備は割と整っているが

あたりかなと思っています。

ブラウザでの動作

メインラインで開発中。
スマートフォンでは若干パフォーマンスの問題がある。

・基本的な動作: ○
・配布に適した形式にする: × 優先度比較的高で検討中
・パフォーマンスチューニング: △ シェル描画ライブラリcuttleboneは着手しているっぽい

デスクトップでの動作

過去動作実績はある(nw.jsによる)。ただしアクティブにメンテされていない。
ブラウザでの動作が安定してから本格的に取りかかる予定。

・基本的な動作: △ 過去OKだったがメンテされていない
・配布に適した形式にする: ○ 仕組み上OK
・WindowsではネイティブのDLLを使う: ×
・実際のファイルシステムを使う: ×

ゴースト(SHIORI)対応進捗

主にゴーストに関する対応。
詳細は如何かのSHIORIイベント実装状況を参照のこと。
以下ざっくり

・栞 華和梨・里々・YAYA・華和梨7・文5: ○
・栞 美坂: × ninixのを借りてこられないかなと思案中
・栞 MiyoJS: × node.jsのrequireを借りてこられないかなと思案中
・SAORI: × 落ちる。作業者熱烈募集中。

・シェルやバルーンの抱き合わせインストール: ○
・起動と終了: ○
・時間イベント: ○ ただし見切れ重なり非対応
・コミュニケート・ユーザー入力: ○
・選択肢イベント: △ 基本的な対応 タイムアウトとHover/Enterには非対応
・マウスイベント: △ 基本的な対応 SSP拡張は未実装
・シェルとバルーン交代: × イベントなしで交代する
・インストールイベント: × イベントなしでインストールする
・バルーンイベント: ×
・キー入力イベント: ×
・消滅イベント: × 現状ゴーストをアンインストールできない。
・ファイル/URLドロップイベント: ×
・OnTranslate: ×
・トレイバルーン・ネットワーク更新・時計合わせ・メールチェック・ヘッドラインセンス・カレンダー・SSTP・通信・状態取得: そもそもブラウザでは実装が難しいため永遠に未実装があり得る

まだまだ非対応のものが多いが結構まともに動くゴーストが多いことを鑑みると、起動終了と時間と選択肢さえあればなんとかなるというのもまた真理っぽいです。
また基本的に実装しているものはSSP互換になるようにしています。

シェル対応進捗

主にシェルに関する対応。
ここはduxcaさんが主に作業しているcuttleboneライブラリが対応している。
以下ざっくり

・シェル交代・追加シェル: ○
・アニメーション: ○
・あたり判定: ○
・着せ替え: ○ ただし着せ替えメニューはまだない
・位置の保存: ×

ゴーストの対応より進んでいるイメージ。

バルーン(さくらスクリプト)対応進捗

主にバルーンに関する対応。
詳細は如何かのさくらスクリプト実装状況を参照のこと。
以下ざっくり

・バルーン交代・追加バルーン: ○
・基本的なスコープ・サーフェス・タイミング系コマンド: ○
・終了コマンド: ○
・位置調整(\l系): ○
・選択肢コマンド: ○
・選択肢マーカー変更コマンド: △ visitedと色反転以外はOK
・画像を貼る: ×
・フォント変更: △ outline・sub・sup以外はOK SSPと描画が異なる面がある
・サウンド:×
・オープン: ×
・executeとか: ×
・プロパティシステム: ×
・環境変数: ×
・位置の保存: ×

よく使われるところはだいたい終わっているイメージ。

その他進捗

おもにSSPが広げた混沌のお掃除。

・不正な形式のnar対応: △ 入れ子narはいけたり、install.txtが変なところにあったりすると落ちたり
・不正なsurfaces.txt対応: △ 警告を出して読むものの、SSPのわけのわからない解釈力には達していない

概況

全体として栞イベント対応が手薄で、フル機能のベースウェアとはまだ言いがたいところにいます。

ただこの実装機能内であれば十分動作します。
「アコとなかまたち」などはよく動いてくれるのでとりあえずインストールして和んでいます。

要望募集

これでは機能的に不満だという方もいるでしょう。
そういう方でもしJavaScriptに心得がある方がいれば、単機能だけでも結構ですので是非開発に参加してください。
幸いにもイカガカはオープンソースです。
どこをいじりたいという要望があればどこをいじればいいかできるだけ説明したいと思います……ので勝手に直してしまってください。
プルリクなりコピペなりあれば対応します。

また心苦しいのは、イカガカをまだ広く簡単に配れる形式にできていないことです。
個人的にはまだその前に実装すべき機能が目白押しだと思っているのですが、この感じの対応状況でも是非自分のサイトとかで使いたいという声が多ければ、そちらを先に対応することにします。
一応現状でもデモページに書かれているコードとjsファイルを丸っとコピってくれば動きますが、まあ複雑ですよね。

以上

だらだらと列挙しただけですが、イカガカの現状がわかっていただけたでしょうか。

ブラウザでゴーストが動いているのはデスクトップとはまた違った感覚があると思います。
もしこの仕様内でいい感じにご自分の産んだ、あるいは愛用のゴーストが動いたなら、ご報告くださるとやはり励みになります。

やや気長な感じにはなりますが、そんな新しい伺かの境地を実現するために頑張りますので、一応ご期待ください。
応援よろしくお願いいたします。

明日21日はシャジンさんの記事です。
ご期待ください。

ゴースト「ずん子on伺か」 東北ずん子賞受賞 (マスコットアプリ文化祭2014)

【マスコットアプリ文化祭 2014】
にさる12月11日に応募した拙作アプリ？
【ずん子on伺か】
が「東北ずん子賞」をいただいたようです。




これがひとえに「東北ずん子」と「伺か」、そのWebプラットフォーム「如何か」の今後の益々の発展への一助になればと思います。

東北ずん子ちゃん、シェル制作協力ななっちさん、如何か共同開発レゴキチさん、イベントを知らせてくれた華和梨メンテナのS.Satoさん、締め切りすぎても勇気をくれたプロ生ちゃんに感謝しつつ、ありがとうございました。

・受賞: プログラミング生放送勉強会 第32回 スライド https://onedrive.live.com/view.aspx?resid=623F2C273E554172%2111972&ithint=file%2Cpptx&app=PowerPoint&authkey=%21ALc4iHOyPFDihtM
・マスコットアプリ文化祭 2014 http://pronama.github.io/mascot-apps-contest/2014/
・ずん子on伺か http://narazaka.github.io/Ikagaka.demo.zunko/
・マスコットアプリ文化祭のずん子on伺か紹介ページ http://pronama.github.io/mascot-apps-contest/2014/works.html?id=163
・東北ずん子 http://zunko.jp/
・伺かWebベースウェア「如何か」 http://ikagaka.github.io/Ikagaka.demo/
・プログラマブル準AI 華和梨 http://kawari.sourceforge.net/
・プログラミング生放送 http://pronama.azurewebsites.net/

【伺か】Webベースウェアの作り方(伺か Advent Calendar 2014)

伺か Advent Calendar 2014の11日目。
主催が明日にとんずらしたので昨日に引き続き僕です。

さて、内容も昨日に引き続きWebベースウェアについてです。
だって土壇場変更であと40分だからな。ネタないからな。

「如何か」の独自性？

如何かがこれまでの「Web版伺かテスト」と違う点として、既存のnarが動かせることをお話したと思います。

これは繰り返しますが革新的なことであり、これがあるからこそ如何かは現状唯一の意味あるWeb版伺か互換環境の実装といえると思っているわけです。

ですがこれは実は如何かの専売特許ではありません。

……ってつまりどういうこと？

既存のnarを動かすということ

既存のnarが動かせることの実現への障害はつまるところ既存の栞が動かせることを実現することです。
伺かの「SHIORIサブシステム」の仕様は「WindowsのDLLと共有メモリ」に強く依存しており、これをWindows以外で動作させることは困難でした。
しかしLinux等で動かそうという先人の試み(ninix-ayaの華和梨ライブラリ等)からの流れで、Un*x的な共有ライブラリとしての実装に置き換える標準的な置換方法がオープンソース栞では普及しました。経緯はよくは知りませんが、里々とYAYAをメンテナンスしている整備班のおかげっぽい気はします。
さて、そんなわけでUn*xっぽい実装がなんとかなっていたゆえに、これをemscriptenでJavaScriptのライブラリにコンパイルすることは思ったよりすんなりいきました。


JavaScriptのライブラリ……？

栞JS

そうです。これらこれまで困難だった既存の栞が動かせることは分割されたライブラリとして提供されています。
如何かはそのライブラリの最初の利用者にしてその他のレイヤーの優れた実装者であったというだけです。

あれ以外のWebベースウェアは、作れます。

以下がそれらOSS栞をJavaScriptにコンパイルしたライブラリです。
・華和梨 kawari.js
・里々 libsatori.js
・YAYA yaya.js
・文5 aya5.js
・華和梨7 kawari7.js

これらはどれも同様の方法でライブラリ化されていて、同じメモリ確保や開放等の低級な動作を必要とします。なのでそのラッパーライブラリnativeshioriを提供しています。
・各種emscripten栞ラッパーライブラリ nativeshiori
文字コード変換まで面倒見てくれる優れものです。上記栞ライブラリをお使いの際はぜひご活用ください。

使用方法

SHIORIサブシステムの仕様は公開されていますので、ぶっちゃけnativeshioriにあるサンプルコードが全てです。
独自のWebベースウェアを作りたい場合は、仕様を参照して、適切にご使用ください。
以上！

えっ……そんだけ？

……だって、ねえ。

僕は如何かについて、栞についての作業とイベント発行に関しての作業をメインにやっているんですが、栞は山場の一つでしかありません。
僕は栞のJavaScriptライブラリ化を実現したとき、シェルの実装を思って絶望したのですから。

幸いにも、というか当然というか、シェルも含む「如何か」のあらゆるコンポーネントはそれなりの粒度でもってライブラリ化されています。「如何か」はオープンソースですし、たとい「如何か」の実装が部分的に気に入らなかったとしても、全てを作り直す必要はありません。
上記栞JSを含む「如何か」の資産を有効活用できることで、今後JavaScriptで別のベースウェアをつくるという試みも成功するよう、願っております。

こんなとこかな？

【伺か】ブラウザ上ゴースト実行環境「如何か」【on the Web】(伺か Advent Calendar 2014)

今日も今日とて1ヵ月ごとのFC2広告消し投稿やで。
あとこの記事は伺か Advent Calendar 2014の10日目(初日（ぉぃ)の記事だったりしますよ。
10日にたてられたカレンダーの主催が日和って11日から書くことにした隙を突いて初日を掻っ攫ってゆくスタイル。
その後色々あって11日も僕で、こちらです。

さて、現在修論のかたわらWebベースウェア「如何か」を@duxca(レゴキチ)さんと一緒につくっております。

「Webベースウェア」ってなんだって？

ほら、SSPとかmateriaとかCROWとか、あるいは何か on 林檎、偽林檎、ninixとか、あるやん。ベースウェア。伺かの。
あれのWeb版。

「これまでも色々とブラウザでゴーストっぽいのを動かそうという試みはありました」って？レゴキチ/Webゴーストとか - 駄でべろぱの小ネタWikiとか？
違いますー。大半の有象無象の実験とは決定的に「如何か」は違うんです。

何が違うか、デモページを見ていただければわかります。

デモページ

→Ikagaka.demo




おわかりいただけただろうか？

既存のnarが動かせます。

既存のnarが動かせます。


大事なことなので2回言いました。

これが「如何か」を「Webゴースト」や「ブラウザで伺か」ではなく「Webベースウェア」と呼ぶ理由であり、またこれが伺かの「Web対応テスト」の再発明に終止符を打つものとして、信じて開発をする理由です。

のちに残るのは技術ではなくコンテンツです。
HTML5/CSS3つかいまくりこと「webさくら」も、開発窓を持つ「JavaScriptで動く何か。」も、SiReFaSo現役の「うじゅら＆うじゅう」も、伺かのWindowsべったり仕様の枷を捨てて携帯化をなんとかした功労者「まめフラスコ」も、なしえなかったゆえに、それらは決定打になりませんでした。

『プラットフォームとしての「伺か」がしたがえる膨大な既存のゴーストたちを動かすこと。』

これを「如何か」は達成しました。

方法としては単純で、単にCやC++のコードをJavaScriptのコードにコンパイルする新しくできたコンパイラ「emscripten」で既存の栞をブラウザで動作させただけです。
つまるところ時代による技術革新の勝利です。無論この方法が使えない栞(オープンソースでない・CやC++でない)を使っているゴーストはまだ動きませんし、SAORI等外部ツールを使ったゴーストもまだ動きません。さくらスクリプトとかイベントも未実装なのは当然動きません。それでもこれは大きな、決定的な一歩です。

僕がこの栞関連の作業を達成したあと、シェル関係について過去に旧如何かを作ってノウハウをもっていた@duxcaさんを知り、現在なんとなく共同で作業にあたることとなっています。

どのくらい動くの？

既存ゴースト対応！とはいうものの、どれくらい動くの？という疑問。あると思います。

大前提として、如何かは発展途上です。まー動かない機能もたくさんあります。まだゴーストの切り替えイベント対応してませんし、ブラウザの制約でネットワーク関係の機能は将来的にも実装されない可能性大です。
他よく使われるところとしては、着せ替えと3人目以降の挙動があやしかったりします。
栞としてはデモに書いてあるとおり、華和梨、里々、YAYA(機能制限あり)、文5、華和梨7なら動きますが、それ以外はまだ未対応です。SAORI使うとエラーはきます。

でも動きます。
よく使われるさくらスクリプトを重点的になんとかして、SakuraScriptPlayer.jsにあるさくらスクリプトは対応済みです。
執筆現在以下に対応済みです。
\0, \1, \h, \u, \p0 \p[0]
\s0, \s[0], \i0, \i[0]
\b0, \b[0], \c, \n, \n[half]=\n (temporary)
\w8, \_w[800], \_q, \t, \_s, \_s[0,1,2], \x
\q[], \__q[], \_a[], \*, \![set,choicetimeout,timeout], (\q[][]), (\q0[][])
\e, \-, \\, (\z)
\![open,communicatebox], \![open,inputbox,id,wait,text], (\__c)
\![raise]
\_u[], \_m[], \&[]
この範囲で結構なことができます。単純にしゃべるだけのゴーストなら十分といっていいと思います。
事実、アコとなかまたちver2.0はほぼ完璧に動きます。narをダウンロードして如何かに突っ込んでみてください。

「華和梨、里々、文5、華和梨7を栞にして、適切なシェルと場合によってはバルーンを使い、上記さくらスクリプトの範囲で記述されたゴースト」は、動きます。
この点強調しておきます。「ブラウザ上で満足に動くゴースト」はもう作れます。(それは同時にSSPでも満足に動くゴーストでしょう。)

またこのブラウザ対応はGoogle Chromeのエンジンをメインにしているので、Android版Chromeでも動作します。iOSはファイルの取り扱いの関係で今動かせなかったりするそうですが、ベースウェアとしての機能は動くはずです。

Androidの方はスマートフォンにゴーストのnarをダウンロードして、気がついたときにChrome立ち上げてつついたりするといいかもしれません。

今後

そして如何かは進化します。materia、SSPの良く使う機能をさらに実装すること、いずれはSAORI対応や、まだ見ぬ美坂等の栞対応も将来的に視野に入れています。
ベースウェアとしての起動機能、状態の保持なども順次作業していくでしょうし、スマートフォンのタッチ対応もより進んでゆくでしょう。

将来の用途として、これまでGIFアニメとかスクリーンショットPNGとかでやるしかなかった「ゴーストのプレビュー」を、ちゃんと動くサンプルで行うことも可能になるかもしれません。
CordovaなんかをつかってAndroid、iOSアプリにするなんてこともできるかも？不定形ウインドウを作れればLinux、Macなんかでデスクトップ上アプリとしてのクロスプラットフォーム対応もできるかも？
夢はひろがりんぐです。

その夢のために

デバッグがまだまだ必要です。
伺か界隈のみなさんの力をお貸しください。

具体的には、narをつっこんでなんか変だったらバグ報告してください(詳しくはデモページ)。
そういう地道な積み重ねが、ソフトを育ててゆきます。

なにとぞ、よろしくお願いします。


この記事は伺か Advent Calendar 2014の10日目の記事です。
11日はこちらです。