Kritaの右ペイン（ドッキングパネル）に編集履歴を出すなど

あんまりKritaの日本語の記事が増えませんね、ということで、ちょっと投稿。

下の画像のように、Kritaの右ペインにあるメニュー群を、ドッキングパネルと言います。

右ペインと言いましたが、場所は右固定ではありません。下に表示させたり、フロートさせたりもできます。 編集履歴をはじめ、かなり色々な機能があります。ここに追加・削除するには、

このような感じで、設定メニューから変更できます。編集履歴は下から3番目ですね。

しかし、もっと簡単な方法があります、何かのドッキングパネルのタイトルバーを右クリックすると、

こんな感じで変更できます。アニメーション系弄るときは、何度も表示したり消したりするので、右クリック使った方が楽です。

ちなみに、項目は順番が表示する度に入れ替わりますので、目的の項目を探すのにちょっと難儀することがあります。

※Docking Panelは、昔はDockerだった気がします。クジラのアレと被るので変えたんですかね。

ビザンチン将軍問題のどうでもいい小噺

最近プライベートが忙しくて時間が取れないため、ブログネタもなく更新が滞っていましたので、一つしょうもないお話を。

ビザンチン将軍問題

ブロックチェーンの技術などを追っかけて行くと、ビザンチン将軍問題というコンセンサス問題に出くわすことがあると思います。 今回のエントリーはこの問題自体のお話ではないんですが、一応簡単に解説を。

一堂に会して多数決を取る場合は下のような感じで決を採るため、全員が同じ結果を認識します。

ところが、決定権を持つ人が各所に散らばっている場合、コンセンサスが正しくとれない場合があります。

例えば、意思決定権を持つ人が5人いて、賛成グループと反対グループが2:2に分かれたとします。つまり、残りの一人がキャスティングボートを握っています。 そして、決定権保持者はバラバラな場所にいて、直接的に意思確認ができません。

この最後の一人が二枚舌外交をやらかして、Yes側にはYesだよと言い、No側にはNoだよと言うと、 Yes側の人たちは賛成多数で可決したと思って賛成行動をとりますが、No側には否決されたと思い、否決の行動をとります。

結果的に、お互いが本当だと信じている事実が異なるため、衝突が発生します。

この問題を、意思決定権を9人の将軍が持つとして、攻撃か撤退かを決めるとしたモデルで説明したのがビザンチン将軍問題です。

ビットコインのブロックチェーンでは、ブロックチェーン台帳の記録があっちとこっちで違うよ、とならないように、ナカモトコンセンサスという仕組みを採用しています。

将軍

今回はこの問題自体の話ではなく、「将軍」についてです。この問題を説明したブログなどを巡回すると、

1. オスマン帝国に包囲されたコンスタンティノープルのビザンチン将軍たちが、攻撃か撤退かを決める
2. ビザンツ帝国を包囲した敵軍の将が、ビザンツ帝国を攻撃するか撤退するかを決める
3. 敵の都市を包囲したビザンチン将軍たちが、攻撃するか撤退するかを決める
4. 敵の国を滅ぼそうとするビザンチン将軍たちが、攻撃するか撤退するかを決める

という感じで、バリエーション豊かです。一体どれが原典と同じなんでしょう。

答え3

結論を言います。答えは３です。

以下は原典です。

https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf

We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger.

敵の都市の外でキャンプしてるビザンツ帝国軍によるコンセンサス問題ということです。これでスッキリ。

うーん、本題の方が短くなってしまいました。

ビザンツ帝国とは

こちらも一応説明を書いておきます。

ビザンツ帝国は別名東ローマ帝国で、前身は古代ローマ帝国です。古代ローマ帝国も3世紀になると、広大な土地を一人の皇帝が治めることが段々と難しくなり、分割統治システムが導入されるようになりました。最初は四分割（テトラルキア）だったのが、コンスタンティヌス帝の亡き後あたりから、東と西の2分割システムに落ち着き、395年には完全に分離しました。その東側が東ローマ帝国です。西ローマ帝国側は476年に滅亡しましたが、東ローマ帝国は1453年のコンスタンティノープルの陥落まで続きました。

そんなわけで”ローマ”という名前がついてますが、東ローマ帝国の首都はコンスタンティノープル（今のイスタンブール）で、ローマが支配下にあったことはほとんどありません。領土は基本的にバルカン半島（ギリシア周辺）とアナトリア半島（今のトルコ）なので、当時はギリシアの影響が大きく、ギリシア人の国という見方もされています。オスマン帝国によるコンスタンティノープルの陥落は、キリスト教国家を揺るがす大事件でしたが、日本にとっても結果的に大きな影響を与えました。主なところでは鉄砲伝来と日露戦争です。はあ？と思う方は調べてみると面白いです。

ちなみにオスマン帝国がのちにトルコ共和国になるのですが、トルコ系民族、要するにテュルク系の人々は、ルーツがもっと東側にあるんですね。トルクメニスタンや、中国共産党による人権蹂躙が話題となっているウイグルあたりですね。オスマン帝国が東ではなく西を目指したため、現在の位置に落ち着いているんですが、地図を眺めるとこの辺もちょっと面白いです。

Ugee液タブでKritaの筆圧が死んだ場合の対処法

大掃除して液タブのUSBポートを差し替えたせいなのか、Kritaのバージョンを変えたせいなのかわからないですが、しばらくKritaで筆圧が反映されなくて大いに困ってました。 Ugee液タブのドライバ画面ではちゃんと筆圧出てるんですが、なぜかKritaで出ない現象です。

本当に大いに困ったので、備忘録として。

筆圧検知ドライバは2つある (Windows)

WindowsがデフォルトでサポートしているWindows Inkというドライバと、下記リンクからゲットできるUgeeのドライバの2つがあります。

Download- UGEE

ペン操作をWindows Inkに移譲する場合、下の赤線引いたチェックボックスにチェックを入れると良いです。

Windows Inkモード

Windows InkモードだとKritaでも筆圧がちゃんと働きます。働くんですが、以下の2点に難があります。

• ペン付属のボタン機能がカスタマイズできない（実質役に立たなくなる）
• ドラッグ操作がまともに動かない

ボタンに右クリックとか割り当てられないので、めちゃくちゃストレス溜まります。 ドラッグ操作の異常は、特にスライダ(ペンサイズなど)がちゃんと動かないので、タップ操作で合わせることになります。これもストレス。

なので、マウスで代用することが多くなってしまうので、作業効率めっちゃ下がります。

Ugeeドライバモード

上に貼ったキャプチャの通り、チェックボックス外すとUgeeドライバで筆圧（を含めたペン操作）が動作します。 Windows Inkに比べると、全然綺麗に動きます。最高です。筆圧以外は。

ということで、Kritaの設定を弄る必要があります。メニューバーの「設定->Kritaの設定を変更」を開くと、こんな画面が出てきます。

タブレットの設定にある、下のラジオボタンですが、これが2つ目に入っていると、筆圧が正常に機能してくれません。 いつの間にか2つ目のEXPERIMENTALな方が、自分の環境でOnになっていました。 ということで、上の画像のように、1つ目のWinTabに戻します。

変更時には、必ずKritaの再起動が必要です。Tablet Input API (changing this requires restarting Krita)とこっそり書いています。 再起動しないと反映されません……。罠が多すぎる。

自分の環境ではこれで元に戻りましたが、他のユーザはどうかわかりません（そもそもUgee + Kritaって結構レアな気もしますが）。 が、同じように直る可能性があるので、困ったら試してみてください。

Unity2Dなどのタイリングテクスチャ作成にKritaのラップアラウンドはいかが？

2Dアクションゲーム作っていると、タイル状の背景部品を並べて、地面や壁を表現することが多いと思います。

このタイルには、プリセットパターンみたいに、最初からシームレス（継ぎ目がみえない）に作られている画像を使えばいいのですが、それでは足りない場合、自分で画像を用意することになります。 ただ、これ結構難しくて、適当に描いても継ぎ目だらけになってしまいます。

そこでKritaのラップアラウンドモード。 最初、ラップアラウンドモードは継ぎ目の確認に使う程度だと思ったんですが、違いました。

ラップアラウンドなしで描く

草と土のタイルを適当に描いてみました。単品だと良い感じなように見えますが……。

タイルで確認するとこんな感じ。継ぎ目が見えてますね。ショックです。ゲームに使えません。

大抵の場合、単色に逃げるか、良さげなタイル画像を探しに行くことになります。

ラップアラウンドモードに切り替える

ということで、Kritaのラップアラウンド使って修正してみます。ラップアラウンドモードはWキーを押すか、以下のメニューから選択すると切り替わります。

選択すると、エディタ上の画像がいきなりタイル状に並べられます。結構ぎょっとします。

ラップアラウンドモードの良いところは、右にはみ出した部分は、タイルの左に描かれることです。 ↓は、ラップアラウンドモードで、わざと境界またいで描いた猫です。トーラス構造とかドーナツ形状とかパックマン形状とか。

当然上下も繋がっています。

実際に修正してみる

この機能で、先ほどの草と土のタイルを修正してみます。修正前の画像を、単色レイヤーのみにするとこんな感じです。既に、草の部分にギャップが見えます。

ラップアラウンドモード状態にして、草ブラシで適当にギャップを埋めます。「適当に」というしかないです。ペンタブでガシャガシャやるだけ。

結果が↓。継ぎ目が見えなくなりました。

同じ要領で、草部分の影レイヤーと光レイヤーを適当にガシャガシャ描きます。適当にガシャガシャやっただけで、以下の通りです。継ぎ目が消えました。 ちゃんとタイル状に並べています。

同じ要領で、土部分の模様を、ラップアラウンドモードで適当にスプレーしていきます。出来たのが以下の画像です。

実際にタイル状に並べていますが、全く継ぎ目がわからないと思います。これならゲームに使えます。メデタシメデタシ。

ということで、Kritaのラップアラウンドモードは地味に強力なので、タイル作成に困っていたら、使ってみてはいかがでしょうか？

Unity2Dアクションでスクロール速度の異なる背景を実装する

アクションゲームなどで、前景のスクロールに対して、後景がちょっとスクロールする遠近感のある背景、みたいなものを見かけると思います。格好いいですよね。例えばこんな感じです。

手前の線路のスクロール速度と比較すると、ゆっくりと山や雲が移動しています。要するに多重スクロールです。

オートスクロール（シューティングなど）の場合は、公式でのチュートリアル紹介があります。

Beginning 2D Game Development - Unity Learn

オートスクロールなので、カメラが動くのではなく、背景が自動で動くんですね、これ。 プレイヤーキャラクターに合わせて背景が動く場合、ちょっとどうやったものか悩みました。 特に2Dだと検索全然引っかからないので……。

ということで、Unity2Dで実装したので紹介。

スクロール

今回スクロールする背景は、

1. プレーヤーと同じ速度でスクロール
2. プレーヤーと共にスクロールするが、速度は遅い
3. スクロールしない

の３構成とします。

オートスクロールとの違い

前述の通り、オートスクロールはこういう感じで、固定カメラに対して背景を動かします。プレーヤーは画面中央に配置して、そのプレーヤー自体は動かしません。

オートスクロールの背景

これで表現する場合、公式チュートにあるように、Updateの度に背景を移動させていきます。 単純に、(A)は速度x1.0、 (B)は速度x0.2、(C)は速度0というように、移動速度に差を付ければ表現できます。

プレーヤーと共に移動するアクションは、カメラ自体がキャラを追いかけて移動します。背景は移動させません。

プレーヤースクロール

背景(A)はプレーヤーとカメラがくっついてくるのでそのままでOKですが、背景(B),(C)の表現には工夫が必要です。

この撮影方法は、カメラ用語で”フォローパン”と言います。動く被写体をカメラが追いかけるという撮影方法です。付けパンとも言います。

実装

そういうわけで、どうするかと言いますと、カメラを３つ用意します。

• 1カメラ……プレーヤーと共に移動する背景透過カメラ =背景(A)
• 2カメラ……プレーヤーと共に移動するが、速度の遅い透過カメラ =背景(B)
• 3カメラ……不透過の固定カメラ = 背景(C)

1カメは、たぶんメインカメラとして実装済みだと思います。 2カメ, 3カメの場所ですが、ゲームと無関係な位置、要するに1カメが使わない場所に配置します。リアルでもカメラ合成すると思いますが、その要領です。

忘れがちですが、2Dといっても3Dを応用してるんですよね。

カメラのプロパティ

具体的に、Unityのカメラプロパティをどう弄るかの話に移ります。調整が必要なのは、赤で印を付けた２つ、Clear FlagsとDepthです。

カメラプロパティ

• 1カメ, 2カメは背景を透過します。なので、Clear FlagsをDepth Onlyに設定します。
• 3カメは背景を透過しません。なので、Clear FlagsをSolid ColorかSkyboxに設定します。

Depthはカメラの描画順に関係します。1カメ > 2カメ > 3カメとしたいので、Depth設定をそのように弄ります。 例えば、1カメのDepthを0とした場合、2カメを-1, 3カメを-2にします。

カメラのスクリプト

1カメのスクリプトは各所で紹介されているので省略。公式のリンクを置いておきます。

Movement Basics - Unity Learn

3カメはスクリプト不要です。 2カメのスクリプトは、こんな感じです。

using UnityEngine;
using System.Collections;

public class MiddleCameraController : MonoBehaviour {

    private GameObject player;
    private Vector3 startPlayerOffset;
    private Vector3 startCameraPos;
    private static readonly float RATE = 0.12f;

    // Use this for initialization
    void Start() {
        player = GameObject.FindGameObjectWithTag("Player");
        startPlayerOffset = player.transform.position;
        startCameraPos = this.transform.position;
    }

    // Update is called once per frame
    void Update() {
        Vector3 v = (player.transform.position - startPlayerOffset) * RATE;
        this.transform.position = startCameraPos + v;
    }
}

何をしているかと言うと、プレーヤーと2カメの初期位置をStartで覚えておき、Updateでプレーヤーの初期位置からの移動差分*0.12を、2カメの初期位置に足し算しています。 0.12はなんとなくなので、背景に合わせてお好みで。

※当然ですが、背景(A)と背景(B)は、絵のない部分は透過状態にしておきます。

※uGuiのImageを使うのは、uGuiの本来的な使い方ではありません。ナシです。

【日記】2018年振り返り

2018年も最後ということで、1年の振り返り。

ウィッチクライド受賞

ウィッチクライド自体は受賞の半年以上前にリリースした作品ですが、「出して終わり」という状態になっていました。 受賞と言う形で区切りがついたのは良いことなんですが、AppStore任せでリリース戦略を全く考えていない雑さ加減がよく表れてしまいました。

スマホアプリもかなり飽和気味なので、ゲームを出すときにスマホOnlyというのは、今後やらないと思います。 まあウィッチクライドの場合は、リリースが2年遅れたせいでもあるんですが。 今の状況だと、マネタイズが出来ないどころか、メリットがありません。

ハードウェア遊び

フィギュアの土台にRaspberryPiを仕込んだ智絵里アラームを作成しました。 これもアラームだけじゃなくて、マイク入れて会話出来るようにしようと思ったんですが、なんかやる気が失せてしまいました。 I2Sのマイクまで買ったんですけどね。

この記事はその調査の名残です。記事としては結構人気があるようなので、まあ良し。

RaspberryPiでGPIO(I2S)を使ってマイクから録音する - キノコの自省録

お絵描き

昨年末に買って放置していた液タブの再チャレンジを6月から開始して、健忘になるまで結構頑張ってました。 頑張ったおかげで、本当にかなり上達しました。大分光明が見えてきました。

ウィッチクライドの時、イラスト制作の工数が完全にネックで、イラストのせいでリリースが遅れたといってもいいレベルです。 液タブのおかげでスピードと完成品質はかなり上がりました。今ではもう液タブなしでのイラスト制作は全く考えられないです。

【アイドルマスターシンデレラガールズ】「ニーハイの日」イラスト/kinokorori [pixiv]

Kritaにも大分慣れました。Kritaは日本の記事がほとんどないので、何かあったらまたポツポツ投稿しようと思います。

会社の仕事とか

何度かエントリー書きましたが、４～９月くらいまで、酷いプロジェクトに参加してました。 そのプロジェクトでは久々にAndroidを割と触っていたので、せめて何か勉強になるものをと思い、Kotlinをよく書いてました。 そこまで深堀はできませんでしたが、なんとなーく理解。

今のところ、Androidをガリガリ触る予定はないのですが、Androidに舞い戻った場合はKotlinを積極的に触ろうと思います。

他のプロジェクトではNode.jsだったりAngularだったりReactだったり。この辺は今時ですね。 少し大きめのサバクラシステムになると、流石にプライベートで触れられる機会がないので、こういうところは会社の仕事は有難い。

健康

健忘にかかったのは衝撃的でした。今は全く問題ないですが、それでも恐怖感はあります。

今やってること

Unityで2Dアクション作ってます。完成しても、たぶんこのブログでは触れないです。ちなみに初Unityです。

やはりというかなんというか、イラスト工数がとんでもなく重い。具体的にはアニメと背景。 背景をそのまま真面目に描くと工数死する、しかし手を抜くと一気に安っぽくなる。 ということで3Dの力を借りようと、Blenderも弄ってます。 Unity3DならTerrain使えますが、2Dだとそうもいかないので。といってもBlenderもほとんど初心者。

キャラのアニメーションは、自分で身体を動かして、適当な3Dモデルを動かしてみて、理解したら液タブで描く、みたいなことをやっています。 1枚のイラストを描くのと違い、結構誤魔化しが利かないですね。歩くなどの日常動作は特に。アニメーターは凄い。

初Unityなものの、コーディングの部分はC#ということもあり、特に問題なさげ。今のところ困ってません。

来年リリース出来るといいなあと思いつつ、本年もお疲れさまでした。

記憶喪失になりました

10月下旬に突如として記憶喪失にかかりました。そのおかげで、この1か月くらいかなりバタバタしてました。

10月21日の15時～21時くらいまでの記憶がありません。結構長いですね。 ちなみに、22時に救急搬送されました。いつ検索したのか、搬送される前、ブラウザに健忘とかてんかんとかのページを開いて、頑張って読もうとした形跡がありました。

21時に意識が戻ったと言っても、しばらく記憶がまだらで、覚えていたり覚えていなかったり、翌日になっても記憶が定着しなかったりと、なかなか散々でした。

また、発症後、しばらくは11時～15時くらいまでの記憶も思い出せませんでした。徐々に思い出した、って感じです。

病名

一過性全健忘です。健忘の中でも、過去のことを忘れるのを逆行性健忘、新しいことを覚えられないのを前向性健忘と言うようです。 ここはどこ？私はだれ？というのは逆行性健忘ですね。自分がかかったのは前向性健忘の方です。

発症した15時ころ、電車に乗ってどこか出かけていたらしいのですが、気づいた21時ころには自宅にいました。いつどうやって帰ってきたのか全くわかりません。 前向性健忘なら、知っていることは普通に行動できるということなんでしょう。たぶん。

ただの物忘れとは、もう決定的に違うんだなーという感想です。 物忘れの場合、「あーそうだったー」という感じで思い出すことができますが、エピソード自体ごっそり消えているので、思い出すもなにもありません。「無」です。

なにが引き金？

1週間前に強烈に頭を打ったとか、お絵描き頑張りすぎたとか、過去エントリで書いたダメプロジェクトのせいとか、いくつかあるものの、正直よくわかりません。

発症した時にどこかぶつけたとかもなさそうで、一体何が引き金になったのか不明。案外なんでもないことでも発症するもんなんでしょう。

今は

今は概ね平常通りです。が、集中力が低下していて、少し難儀しています。単に疲れているだけかもしれないですが。