キノコの自省録

日々適当クリエイト

UnityアセットのFungusをスクリプトから制御するTips

前回の続きです。

kinokorori.hatenablog.com

今回は、

の2本立て。

Scriptからトリガーを発火させる

前回、Flowchartを2つ用意して、Flowchartそれぞれにコライダを設定して、Unityちゃん接触時のセリフを変化させました。 前回の方法は、Flowchartがコライダを持っており、コライダにPlayerなどが接触した際に会話ダイアログを出すというものでした。

f:id:kinokorori:20190508003149p:plain
美味しそうなキノコとマズそうなキノコ

もう少し柔軟に、スクリプトから任意のタイミングでFlowchartブロックを実行させたい場合、FungusMessageを利用するのが一番良いと思います。

Messageによる起動

今回は1つのFlowchartで、スクリプトから起動するFlowchartブロックを切り替えるようにしたいと思います。今回の画面はこんな感じにします。前回と同じようにオブジェクト2個ですが、 Flowchartではなく、普通のGameObjectにSpriteとRigidbody, Colliderを設定したものです。

f:id:kinokorori:20190510010349p:plain
オブジェクト2個

キノコに接触した時にキノコのセリフ、右側の女の子(みさき)に接触した時にみさき用のセリフを表示します。そのために、Flowchartに独立した2つのブロック(KinokoBlock, MisakiBlock)を用意します。

f:id:kinokorori:20190511004012p:plain
KinokoBlock

f:id:kinokorori:20190511004051p:plain
MisakiBlock

どちらもExecute On EventはMessage Receivedに設定し、KinokoBlockはメッセージをkinoko, MisakiBlockはメッセージをmisakiにします。それぞれに実行時のセリフ(Say Command)も適当に設定します。

メッセージの送信

Flowchartにメッセージを送信するスクリプトを用意します。コアとなる要素だけシンプルに書くと、こんな感じになります。

public class FungusMessenger : MonoBehaviour
{
    public Fungus.Flowchart flowchart = null;
    public string message = "";
    private void OnCollisionEnter2D(Collision2D collision) {
        if (flowchart && collision.gameObject.tag == "Player") {
            flowchart.SendFungusMessage(message);
        }
    }
}

Fungus.Flowchartオブジェクトを介して、SendFungusMessageメソッドでメッセージを送信しているのがミソです。

このFungusMessengerスクリプトを、キノコ用GameObjectと、みさき用GameObjectにAddし、変数flowchartと変数messageをそれぞれ設定します。 Flowchartは、先ほどのブロックを2つ作ったやつです。

f:id:kinokorori:20190511005630p:plain
Sprite用GameObjectにスクリプトを設定

※IsEnter, IsExit, IsStayの3つのBoolean変数は、上のコードには書いてません。

デバッグプレイ

キノコに接触。kinokoメッセージがFlowchartに送信され、FlowchartがKinokoBlockを発火させ、Sayダイアログを表示します。

f:id:kinokorori:20190511005924p:plain

みさきに接触。同じようにmisakiメッセージがFlowchartに送信され、FlowchartがMisakiBlockを発火させ、Sayダイアログを表示します。

f:id:kinokorori:20190511010047p:plain

メッセージについての補足

このメッセージ送信は、FlowchartのInspectorで設定して投げるようにすることも可能です。こちらのやり方はFungus公式動画でも紹介されています。

f:id:kinokorori:20190511014004p:plain
Flow -> Send Message

この機能をスクリプトから利用したということです。ところで、上記ドロップダウンメニューでは、メッセージ送信先を2種類選択できます。

  • Same Flowchart
  • All Flowcharts

今回利用したのはSame Flowchartです。つまり、上記方法だと、メッセージは自分自身のブロックのみ受け取ることができます。もし、他のFlowchartに投げたい場合は、All Flowchartsに相当する機能を使用する必要があります。 All Flowcharts機能も、もちろんスクリプトから利用できます。正直こちらの方が簡単です。これだけで動きます。

Fungus.Flowchart.BroadcastFungusMessage("misaki");

SendFungusMessageと異なり、BroadcastFungusMessageはStaticメソッドです。要するに、Flowchartインスタンスを必要としません。

ただし、オーバーヘッドが増大することが予想されるので、同じFlowchartに対してメッセージを投げるなら、SendFungusMessageを用いた方が経済的でしょう。

キノコ接触有無で、みさき用セリフを変える

もう少し発展させて、キノコに接触したかどうかで、みさきに接触した時のセリフを変えます。

接触したかを覚える

接触したかどうかを、Flowchartの変数で判断することにします。以下のように、variableにbool型でkinoko_foundを追加します。

f:id:kinokorori:20190511020038p:plain
variableにkinoko_foundを追加

キノコ用のスクリプトをFungusKinokoMessengerにして、以下のような感じで実装します。SendFungusMessageの後に1行追加しただけです。

public Fungus.Flowchart flowchart = null;
public string message = "";
public class FungusKinokoMessenger : MonoBehaviour {
    private void OnTriggerEnter2D(Collider2D collision) {
        if (flowchart && collision.gameObject.tag == "Player") {
            flowchart.SendFungusMessage(message);
            flowchart.SetBooleanVariable("kinoko_found", true);
        }
    }
}

※サンプルのためにこんな書き方をしています。設計的にはNG。

最後に、MisakiBlockに条件を足します。kinoko_found==trueの時、追加でセリフを表示します。

f:id:kinokorori:20190511020812p:plain

正直この辺、Mechanimでお馴染みだと思います。用意されているメソッドや変数も大体一緒です。flowchartオブジェクトを介して操作できます。

実行

f:id:kinokorori:20190511021103p:plain
2つ目のセリフ

今回の例の場合、単純にキノコのSay表示の後に、kinoko_found=Trueすればいいだけなので、スクリプトを書くまでもなかったりします。

f:id:kinokorori:20190511021439p:plain

ゲーム作っていると、そんな単純な条件だけに納まることは少ないと思いますので、そういう時にうまく利用すると良いでしょう。

ライセンス

f:id:kinokorori:20190508004005p:plain

この作品はユニティちゃんライセンス条項の元に提供されています

Unity Fungusで看板に接触した時に出すメッセージを実装してみる

会話ウィンドウなどのメッセージ回りに何か良いものないかな、と漁っていた時、この記事読んでFungusが面白そうだったので、色々弄ってみました。

【Unity】ゲームのちょっとした会話場面にFungusを使ってみる - まともな開発者になりたい

とりあえず今回は看板とかヘルプオブジェクトとか、何かに接触した時に表示されるウィンドウのFungusでの実装について紹介します。

準備

AssetストアからFungusをImportして、SayDialogとFlowchartを作成します。 詳しくは上記リンクにて。

物体接触時にトリガーを発火させる

まず、Flowchartに対して、SpriteやRigidbodyなどの物体設定を行います。Flowchartの子に分割しても構いません。 つまり、FlowchartにRigidbodyを設定して、ColliderとSpriteは子に配置するとか。

f:id:kinokorori:20190508001416p:plain

見ての通りKinematicで普通に物体設定しているだけです。ステージ上はこんな感じ。このキノコにこはく(Unityちゃん)が接触すると、Unityちゃんがしゃべるようにします。

f:id:kinokorori:20190508001518p:plain

次に、Flowchartのデフォルトブロックを選択し、以下を設定します。

  1. Execute On EventにMonoBehaviour->Collision2Dを設定
  2. Tag Sizeを1にして、Element 0にUnityちゃんのTagを設定
  3. Fire OnをNothing以外に設定
  4. CommandsにNarrative->Sayを追加し、セリフを設定

f:id:kinokorori:20190508001647p:plain

2を設定しないと、何にでも(つまり床にも)接触判定してしまいます。

これでOK。Play!

f:id:kinokorori:20190508002130p:plain
美味しそうとは思いませんが……

Unityちゃんがキノコに接触すると、セリフを表示します。

IsTrigger時の注意

看板とかヘルプオブジェクトの場合、コライダーは透過的(要するにIsTrigger)であることが多いと思います。ところがIsTriggerにすると、メッセージが表示されなくなります。

Execute On Eventをよく見ると、Collision2DとTrigger2Dがちゃんとわかれています。なので、IsTriggerを設定する場合はTrigger2Dを設定しましょう。

※実はかなり長い間気づきませんでした……

f:id:kinokorori:20190508003149p:plain
確かに不味そう

メッセージ表示中に一時停止したい場合の注意

Time.timeScale=0にすると、FungusのFlowchart諸共止まります。要するにTime.timeScale=0は使えません。 UpdateやFixedUpdateなどの処理をブロックするなど、頑張って手で止める必要があります。

1シーンにたくさんの看板オブジェクトを配置する場合は

1看板に1Flowchartを配置することになります。Flowchartなので、処理ブロックが順々に遷移するというのが基本ですが、看板オブジェクトの場合、接触した時に内容を表示してフローが終わります。 ある看板と別の看板のフローは別、と考えた方が自然ですので、Flowchartを看板の数だけ用意するのが良いと思います。

もし、1Flowchartでやるなら、Collisionを利用せず、MessageReceivedを使用するのが一番素直です。これについては次回紹介します。

f:id:kinokorori:20190508004005p:plain

この作品はユニティちゃんライセンス条項の元に提供されています

【日記】インプットとアウトプットのバランスを大事に

去り行く平成を見つめつつの雑記。

インプットとアウトプットのバランス

平成の世を生きたソフト屋の自分が、ソフトの勉強する上で特に頭に入れていたのは、インプットとアウトプットのバランスでした。 インプットは要するに本を読んだりして知識を入れる作業で、アウトプットは自分の作りたい作品を実際に制作する作業です。

これってソフトウェアに限らず、イラストレーターなどでもよく言われる話ですが、 インプットをし過ぎるとインプット過多で何も入らなくなり、かといってアウトプットばかりし過ぎると、注目されることばかりに目が行き、雑な作品を生み出してしまうという結果を生んでしまいます。 成長のためにはバランスが大事ということです。

平成15年頃と比較すると、大分成長しました。育成方針は間違っていなかった気がします。 わかりやすい結果では雑誌に載る、Web上で紹介される、地上波TVで紹介される、何らかの賞を受賞する、お金をゲットするといったところ。 それ以上に目に見えない結果の方が大きいと感じています。

具体的には「考える力」です。

一般企業人はインプット過多

突然ですが、一般企業人は大抵インプット過多です。過剰です。 凄く勉強するんです。資格を取ったりもするんです。でも、活用の仕方がわからない。 知識として知っているはずなのに、引き出しから全く出てこない。

一般企業の場合、日々の業務をこなしていれば、まあまあ評価はされます。 それでも何かしらステップアップを目指す場合、プライベートで何かしらの勉強をする必要があります。 ただ、これが割と罠で、勉強時間が成長に比例することにはならず、能力が頭打ちになります。 でも、勉強すると何かしらの安心感があるのか、ただひたすらに勉強します。出来ないから本を読もう、みたいな。

ちなみにこの場合の勉強とはインプットのことです。 本を読むとか、教わりに行くとか、問題を解くとかですね。資格試験も大体そう。 実経験とインプットがリンクしないと、インプットが定着しません。

f:id:kinokorori:20190430192517p:plain:w80

一時期、技術派遣の後輩の面倒を見てたことがありました。 その子は勉強熱心ではある一方で、自分の意見をもっておらず、意見を求めると必ずフリーズするという子でした。 自分で考える、自分で意見を述べるということが出来ないためか、勉強時間の割には、あまりインプットが身についていない様子でした。

考えさせる簡単な課題を何度か出したことがあるのですが、結果は全滅。 何か作品を世間に出す経験をしてみたら?と言ってはみたものの、うすーい反応が返ってきただけでした。

元々の考える力がないので、どんなにインプットを強くしても、決まった仕様を決まった通りに作るコーダーにしかなれません。 アウトプットを考える力がないということは、他人に正解を作ってもらうしかないので当然です。

ちなみにその子は現在、神秘主義に傾倒しているようで、なんだかよくわからない占いのみがこの世の真実を解き明かすことができるようです。 おそらく、今もこれからも単純作業者でしかないでしょう。

アウトプットするって

多くの一般企業人はインプット過多、というよりアウトプットをしたことがないと言った方が正確なような気がします。

自分はアウトプットを常に念頭に置いて活動し続けていたので気づかなかったのですが、そもそもアウトプットをする人ってごく一部です。 ソフト屋なら(個人制作で)アプリを作る、(個人で)サービスを作るといったあたりですが、別にそこにこだわらずに書くと、 ゲームを作る、音楽を作る、イラストや漫画を制作する、文字(小説、詩など)を書く、電子機器を作る、造形をする、イベントを主催する、手工芸品を作成する、映画を撮る、アニメを作る、動画を作成するなど、まあ色々あります。

これを、

  • 単発で終わらないこと(繰り返すこと)
  • 作品レベルを意識して上げること
  • ちゃんと公開、もしくは利用すること

の条件を足すと、さらに減ります。

※上の条件がないと、インプットとのサイクルが回っていきませんので、XX教室行って終わりとほぼ変わらなくなります。

f:id:kinokorori:20190430192517p:plain:w80

統計取ったわけではないですが、やっている人よりやっていない人の方が圧倒的に多いはずです。

そもそも義務教育の段階からアウトプットはあまり重視されていないので、社会人になっていきなりやれと言われても困るはずです。 ただ、上述したように、インプットはアウトプットの経験に強く結合します。インプットを無駄にしないためにも、やってない人は何かしらアウトプットを出すことを真剣に考えた方が良いと思います。

さらに、アウトプットを出すということは、迫りくる困難に対して、自分で全部対処することになります。 例えばアプリ1本出すにも本当に大変です。コード書いてハイ終わりではありませんから。コードなんて体感10%くらいです。 まずどんなアプリにするか(プラン)から始まり、機能の取捨選択、UI/UX、配色、部品デザイン、アイコンデザイン、アプリ登録作業、バージョン管理、広告処理、多言語対応、そしてコーディングなどをこなす必要があります。

こういったことを全部「考える」ことになります。そして、上手くいかなかった部分を反省して、インプットフェーズにフィードバックします。次に何を勉強するか「考える」ってことです。 例えば音声処理アプリなんかを作って、フーリエ変換をちゃんと勉強したい、とか。使ってから勉強すると、めちゃくちゃ頭に入ります。

だからといって勉強もせずにアウトプットばっかりだしても、レベルが上がっていきません。なので、バランスが大事なんですね。

普段アウトプット的活動していないのに自分の考えを強く持っている人は、たまたま仕事で鍛えられたか、学生時代になんらか活動をしていると思います。天性もあるかもしれませんが。

経営者目線を持て

低賃金で働かせておいて何言ってやがるふざけるなと、ブーイングの大合唱となったこのワードですが、個人的には別の理由であまり好きではありません。

経営者目線というのはPL(Profit/Loss)に特化しがちです。純粋に金になるかならないかということですね。それ以外の価値を重視しません。 そんなことはそれこそ経営者に任せておけばいい話です。なんとなくその間抜けさを感じ取ってブーイングされている気がしないでもないですが。

言われたことをハイハイ聴くだけじゃなく自分の頭で考えろ、ということを言いたいんだと思うんですが、 それこそ詰め込み教育ばっかりやってる学校や社会にも責任の一端があるわけで、「自分の頭で考えろ(方法は知らん)」というのは随分とまあ無責任な放言です。 みんなYouTuberをやってみろという方が余程具体的で親切です。どうなんでしょうね、みんなYouTuberをやってみろって。面白いかもしれませんよ。だって動画編集や投稿って、大半の人がしたことないでしょう。

f:id:kinokorori:20190430192517p:plain:w80

平成最後のエントリーということで、適当なことを好き勝手書きました。 では令和で会いましょう。

Kritaの選択エリアに関するTips(移動と色域選択)

続々、Kritaの記事。今回は領域選択の移動と、色域選択についてです。 特に領域選択の移動は、かなり探し回りましたよ……。

色域選択をする

Photoshopでいうところの色域選択ですが、Kritaの場合、”選択”メニュー内ではなく、ツールボックスに専用ツールがあります。

f:id:kinokorori:20190409230611p:plain

同一レイヤー、もしくはレイヤーグループの(近似)色を選択状態にします。閾値はツールのオプションから変更できます。 Photoshopの色域選択がメニューにあるおかげで、ない!ない!と探し回ってしまいました。

f:id:kinokorori:20190410212725p:plain

上の絵では、ジャケットのレイヤーグループに対して色域選択をしています。 ジャケットの上に花びらや草がかかっていますが、レイヤーが異なるために無視されています。

選択領域を移動する

選択領域の移動もちゃんとできます。冒頭の通り、選択領域の移動はかなり探し回りました。

Photoshop出身者だと、選択領域を移動させるツールがあるんじゃないかと思ってしまいがちですが、ツールで移動させることはできません。

選択メニュー、または選択系ツール使用中にキャンバス上で右クリックすると、”グローバル選択マスクを表示”というチェック項目があります。 まず、ここにチェックを入れます。

f:id:kinokorori:20190415005951p:plain

次に、なんらかの領域選択をすると、selectionという選択領域レイヤーが生成されます。

f:id:kinokorori:20190415230612p:plain

リボンを選択したところです。右側のレイヤーリストにselectionという特殊レイヤーが生成されているのが確認できます。このselectionレイヤーを選択して、移動ツールを使うと、こんな感じで移動できます。

f:id:kinokorori:20190415230627p:plain

通常のレイヤーと同じ扱いですので、移動だけじゃなく、拡大縮小を始めとした変形も可能です。 ただ、変形は普通の選択モード(Local selection mask)でもある程度出来るんですよね。移動したい場合はグローバル選択マスクを使うより他に手はないと思います。

ちなみに、今回利用したイラストの全貌はこちら。

【小日向美穂】「ラブレター」/「kinokorori」のイラスト [pixiv]

Kritaの右クリックで登場するメニューをカスタマイズする

引き続きKritaのTips。

右クリックメニュー?

Kritaでは、キャンバス上で右クリックすると、こんな感じのメニューが表示されます。

ポップアップパレット
popup palette

これ、ポップアップパレットと言います。ほとんどの機能は見たままなので説明不要だと思いますが、ブラシの切り替え方法だけはちょっと癖があります。

※ちなみに私はドッキングパネルのブラシプリセットからドラッグ&ドロップして登録しようとしてたりしました。それでは登録できません。

ブラシの表示切替

そもそもここに表示されているブラシは何かというと、選択されたタグのブラシ群を表示しています。 ポップアップパレットの右下にある小さいボタンを押すと、タグリストが表示されます。 ここから表示したいタグを選ぶと、ブラシが切り替わります。 この例で表示しているパレットは、”kinoko”という名前の私が勝手に付けたタグのブラシ群です。

タグの編集

要するに、タグを編集すれば、ポップアップパレットに表示するブラシも切り替えられるっていう寸法です。 タグの編集は、ドッキングパネル(右ペイン)のブラシプリセットから行うことができます。

タグの編集を行いたいブラシ上で、右クリックを押すと、ポップアップメニューが表示されます。 そこから、「タグに登録」を選択し、登録したいタグを選択します。なお、既に登録されているタグは表示されません。

赤丸付けてちょっと書いていますが、プルダウンメニューもタグ由来です。そのタグに登録されているブラシを表示しています。

とりあえず、今回はサンプルとして、このe)Marker_Chisel_Smoothブラシをkinokoに登録してみます。 登録後、キャンバス上で右クリックすると……

無事、先ほどのブラシがポップアップパレットから選択できるようになりました。

一見面倒くさそうに見えますが、意外とそうでもありません。適当にタグを新規作成して、自分が良く使うブラシをポイポイ放り込んでおけばOKです。

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

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

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

f:id:kinokorori:20190407000013p:plain

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

f:id:kinokorori:20190407000359p:plain

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

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

f:id:kinokorori:20190407000447p:plain

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

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

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

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

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

ビザンチン将軍問題

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

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

f:id:kinokorori:20190328203602p:plain

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

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

f:id:kinokorori:20190328203848p:plain

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

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

f:id:kinokorori:20190328204142p:plain

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

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

将軍

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

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

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

答え3

結論を言います。答えは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年のコンスタンティノープルの陥落まで続きました。

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

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