次ログ

次ログ

JavaFXで作ったツールとか公開したり、イラスト配布したり音楽配布したりしてるかもです。

物語におけるキャラ同士のやり取りをシーケンス図で整理する

はじめに

FF6みたいに複数のチームを切り替えながら操作するシーンであったり 世界崩壊後の仲間が散り散りになったシーンで、 キャラ同士のやり取りの整合性をキチンと取りながらストーリーを考えるにはどうすればいいだろう。

って考えた時に、シーケンス図を書くと割といい感じに整理できることに気づいた。 Twitterに数カ月前にちょろっとだけ載せたけれど、 せっかくだったのでキチンと整理して公開しておこうと思った次第。

目次

わかりにくいストーリーの例

あるところ日、青年田中は精霊祭の日に神のお告げを聞いた。 その日、田中は町をでた。100年に一度復活を遂げる魔王を倒すために。 田中は最初の町で魔王の手先を倒した。
田中は2つめの町で魔王の手先と対峙した、しかし敵は強かった。
その時、偶然居合わせた山田と鈴木が助けてくれて、協力して敵を倒した。
山田と鈴木の話を聞くに、彼らの故郷は魔王の手下に滅ぼされたそうだ。

なんやかんやあって、いい感じにストーリーが進んで海の神殿についた。 そこには封印された勇者が眠っていた。
田中はそのとき、なんかすごいパワーが覚醒して封印を解き放った。 おまけに敵も復活したけれど、いい感じに倒せた。
山田と鈴木は勇者が居眠りぶっこいていたせいで故郷を滅ぼされたことに激昂して問い詰めた。 勇者は魔王に単身挑んだものの返りうちにされたこととか諸々説明して無罪放免。

あとはなんかいい感じに魔王を倒してハッピーエンド。


適当に書いたからすごくわかりにくいけれど、わかりにくいことが伝わったなら十分。 ストーリーを思いついた順番に説明してもいい感じに伝わるわけがない。 そんな時こそシーケンス図。

たぶんわかりやすくまとまったストーリー図の例

f:id:jiroron666:20190120083038p:plain
シーケンス図

こうしてみると、キャラが裏でどういうことしてたのかがよくわかる。 プレイヤーが操作可能になるまえから、物語は始まっていた。 これがシーケンス図のパワー。

シーケンス図ってなんぞや

Wikipediaを読めばわかる

シーケンス図 - Wikipedia

UML図の一種なのでUML図のリンクも貼る。

統一モデリング言語 - Wikipedia

もともとはシステム設計をする時のデータのやり取りや オブジェクトの振る舞いを定義するためのモデリング言語であって ゲームのシナリオを整理するためのものじゃない。

こんな複雑な図を書けというのか?

PlantUMLを使うとすごく簡単に書ける。

Open-source tool that uses simple textual descriptions to draw UML diagrams.

手軽にWebブラウザ上で試したいなら以下のサイトがすごく便利。

sujoyu.github.io

テキストファイルとして管理できるのでGitHubとの相性も良い。 ちなみに前述の図は以下のテキストから生成されている。

@startuml img/chara_seq.png

title 仲間が全員合流するまでの行動

actor 田中 as tanaka
actor 山田 as yamada
actor 鈴木 as suzuki
actor 勇者山勇者太郎 as hogeyama
actor ラスボス as last_boss

activate last_boss

last_boss -> last_boss : 復活した
last_boss -> last_boss : 世界侵略を開始
activate hogeyama
hogeyama -> hogeyama : 100年の眠りから目覚める
note right : ほげ山は過去の勇者とかそのへん
activate yamada
hogeyama -> last_boss : 一人で戦いに挑む
yamada -> suzuki : 一緒に遠方の街に\n買い出しにでかける
deactivate yamada
activate suzuki

last_boss -> yamada : 手下だけ向かわせて故郷を焼き討ちにかける

suzuki -> yamada : 故郷に戻ってきた
activate yamada

yamada -> yamada : 壊滅した故郷を目の当たりにする
yamada -> yamada : last_bossの手先を撃退する
yamada -> yamada : 魔王討伐のたびにでる
last_boss -> hogeyama : 返り討ちにして、\n海底神殿に封印する
deactivate hogeyama
suzuki -> yamada : 同行する
deactivate suzuki

=== ゲーム開始 ===

activate tanaka
tanaka -> tanaka : 年に一度の精霊祭に参加する
hogeyama -> tanaka : 封印されながらも根性と神通力で語りかける
tanaka -> tanaka : 始まりの街をでる
tanaka -> tanaka : 最初のボスを倒す
tanaka -> tanaka : 第二の街に到着する
tanaka -> tanaka : 第二の街を襲っている魔物と対峙する
yamada -> tanaka : 戦いに参加する

deactivate yamada
deactivate suzuki
tanaka -> team : チーム結成
deactivate tanaka
activate team
team -> team : なんやかんやある
team -> team : 海底神殿につく

team -> hogeyama : 田中のなんかすごいフォースで\n封印を解く
activate hogeyama
team -> team : 一緒にボスも復活
hogeyama -> team : 共闘でボスを倒す
hogeyama -> team : チーム加入
deactivate hogeyama
team -> team : なんやかんや
team -> team : ラスボス城に到達
team -> last_boss : 決戦に挑む
team -> last_boss : 勝利
deactivate last_boss


deactivate team

@enduml

すごく簡単というわけではないけれど、 パワーポイントよりは簡単なはず。

以上

MV顔グラ差分素材 いろいろ

Twitterにあげるだけあげて載せてなかったやつを全部

ダウンロード

ここに記載の連番とzipファイル名は一致します。

https://github.com/jiro4989/dist-illust/releases

イメージ

actor020

f:id:jiroron666:20190105180424p:plain f:id:jiroron666:20190105180447p:plain

actor021

f:id:jiroron666:20190105180510p:plain f:id:jiroron666:20190105180538p:plain

actor022

f:id:jiroron666:20190105182021p:plain f:id:jiroron666:20190105182041p:plain

actor023

f:id:jiroron666:20190105180603p:plain f:id:jiroron666:20190105180624p:plain

actor024

f:id:jiroron666:20190105180641p:plain f:id:jiroron666:20190105180702p:plain

actor025

このこ

jiroron666.hatenablog.com

actor026

この人

jiroron666.hatenablog.com

利用規約

次郎のイラストの利用規約

余談

液晶タブレットの代わりとしてMedia Pad M5 ProというAndroidタブレットを買ったけれど結構描きやすかった。 ただし、この記事のキャラは普通に全部板タブとKritaで描いたころのやつなので、タブレットで完成したものはまだ一つもない。

ちょいちょいズームが変なとこ行ったりするけれど、見ながら描けて良い。 遅延はあるけれど、まだ許容できる。

Scrapboxから戻ってきました

はじめに

お久しぶりです。次郎です。 はてなブログに復帰したという記事です。

GitHubPagesに移行したあと、また移行してScrapboxを使っていたのですが、結局戻ってきました。 戻ってきた理由と、これからについて書きます。

戻ってきた理由

主に集客的な側面からです。

ScrapboxWikiであってブログではなく、 集客の側面については意図的に排除しているとの記事を見かけまして戻ってきました。

別に集客には特にこだわりもなかったですし、今も余り興味ないのですが 絵の配布、ついては別だったので、それのためだけに戻ってきました。

使われるための絵

今まで、たまに絵を書いて、気に入ったものがあったら公開して配布できる形にしてきました。

Scrapboxでも同様のことを行っていたので すが、Scrapboxよりははてなブログのほうがより効果的に人の目につくのでは、と考え ました。

もともと僕は自分がゲームを作る時に自分が使うように絵を書いて、 ゲームが完成するまで潜ませとくのがもったいなくて公開するようになったのですが 最近はゲームを作る熱が冷めて、何かの実装か絵だけを書くような感じになりました。

書いた絵をより使ってもらえるように、よりひと目につきやすいとこに置いとこう、という感じです。

まぁ、Wikiサービスをブログとかの代わりに使っていたのが、 本来の用途とアンマッチしていた感じ...でしょうか。

とはいえ、Scrapboxを使っているから人が集まらない、ということは絶対になくて 実際Scrapboxのサービス製作者のプロジェクトは色んな人に閲覧されています。 単純に、僕の発信力、影響力が弱い、というだけです。

戻ってくる == Scrapboxを使わない というわけではない

Scrapboxは引き続き使います。 が、メインで告知する環境にはしないというだけです。

依然として思考するためのサービスとしてScrapboxは非常に素晴らしいので 引き続きScrapboxに技術的なメモは残していきます。

これから

じゃあこっちでは何を書くのか、というとイラストの配布やツール配布とかだけにしようと思ってます。

このブログも、以前は技術の記事とイラストの記事が混在していて それぞれカテゴリが全然違うものだったので、このブログの立ち位置がわからなく感じてました。

Scrapboxに移行してから技術用とイラスト用でプロジェクトを分けていて、 イラスト配布用のプロジェクトの機能だけをこのブログが引き継ぐ形になります。 よって、ゲームとイラストに関連した情報のみになる予定です。

引き続き技術系の情報はScrapboxに書きます。あちらのほうが居心地が良いので。

しっかりとした情報として公開したいものは、多分Qiitaに書くのかなぁと思います。 Qiitaだと情報が間違ってる場合に指摘してもらえるので。

GitHubPagesにブログ移転します。

GitHubPagesにブログを移転します。 移転先は下記。

jiro4989.github.io

配布イラスト一覧は下記 次郎の配布イラスト一覧

はてなブログはエンジニアの利用率が結構高い印象です。 一番のメリットはMarkdown記法に対応していることだと思ってます。 僕もMarkdownが使えるから、ということでFC2から移ってきました。

他にもメール送信で記事の投稿ができるので スクリプトと連携して自動化したり Vimで記事を書いたりできる。 SEO対策もしっかりされてますし、 はてなブックマーク数やスター数が表示されるのも結構便利だったんですが 投稿後に記事を修正するための編集ページが重たかったり もろもろ不満もありました。

github.ioのドメインと柔軟性の高さ、 ブログ記事の更新履歴を残せる、 管理がやりやすい、 エディタが選べる、コマンドラインと相性が良い、自動化が簡単など いろんなメリットから移転を決意しました。

移行こちらのブログはおそらく更新しません。 イラストの配布についても新しいブログの方に告知していきます。

以上です。

自分が今まで書いたイラストの書いた時期と枚数を集計する

概要

集計の勉強がてらにbashawkで自分が今まで書いたイラストの枚数と傾向を集計して分析します。

目的

自分の絵師としてのモチベーションの傾向を分析し、未来の活動指針を決定するため。 というのは大嘘でbashawkで集計の練習がしたかったからです。

成果物は月単位、年単位で集計したグラフです。 本目的の達成は、上記のグラフを作成し可視化することをもって完了とします。

コード

成果物

csv形式で出力してLibreOfficeでグラフ化しました。 (コードの方ではcsv形式で出力するようにはしていないので、 スクリプト呼び出し時に| tr '[:blank:]' ','しました。

年単位での集計結果

f:id:jiroron666:20180325213600p:plain

月単位での集計結果

f:id:jiroron666:20180325213603p:plain

考察

2016年のころ、僕はまだ大学4年生でした。 大学4年は卒論の提出と就活が終わってしまえばあとはひたすら暇になるので その時間をイラストとプログラミングに最大に使っていたことがよく統計に現れているように思います。

2016年1月〜3月は冬休みでしたし、卒業研究も就活もまだ本腰でなかった時期なので その時間はひたすら絵を書いていたみたいですね。

しかし僕って2011年から絵を書いていたんですね...。 意外と結構期間が長いものです。

最近はめっきり絵を書く熱は冷めてしまって、プログラミングの熱ばかりあがっていますが、 それでもこれからも、年に1,2枚くらいは何かしら書くと思います。

アクセスログの処理時間を集計する単純なコード

概要

最近Bashで集計をすることが多いです。集計作業楽しいです。 と同時に、Clojureという言語にも興味ができたので、せっかくなので 簡単な集計作業を両方の言語でやってみたというだけの話です。

目的

access_log というログファイルが存在します。 ログのデータはすべて行単位ですが、共通することは行の一番最後の数値は アクセス時の処理時間です。

このアクセスログの時間を集計して、合計秒と行数を出力したいです。

作成したコード

下記を参照。 ClojureBashのコードです。

まとめ

集計作業のコード量の短さや読みやすさ、手軽さはやっぱり BashAwkのほうが断然上だなぁ...と。 Awkとかはもろに集計のための言語なんでかなり便利。 Clojureに集計やらせるもんじゃないかな...。 でも大量の便利関数群をまだまだ把握できていないので、 それらを駆使したらもっと短くシンプルになるのかも?

個人的にはBashClojureってなんか似ているような気がします。 BashのパイプとClojure関数型言語の性質が似てて、 コードを書いていてパズルを解いているような感じがしてコーディングがすごく楽しい。 逆にGoだとClojureほどコーディングが楽しくなかったり... 実装自体は複雑な機能がないので、つまづくこともあまりなく高速で実装できますが 味気ない感じがどうもあります(気にするべきじゃないのかもですが)。

余談

集計作業を行うとき、今まではなんとなくPythonとかでやっていたのですが、 そこまで複雑ではない処理だったらむしろPythonよりもBashAwkのほうが 短く素早く実装できるなぁと実感しています。

シェルのコードをPythonに置き換えるような話をちらほら聞く中 時代を逆走するようにBashAwkの勉強を最近はしています。 でも使ってみるとかなり便利なので、これからも勉強しようと思います。

作業記録 2018-02-18

作業記録 2018-02-18

Clojure + JavaFX

断念。Clojureが変数の再代入を許可しない制約のせいか知らないけれど、何かと問題に 直面。直面した大きな問題は下記。

  1. ListViewにFile型を入れられない。ListViewはJavaではGenerics指定するクラス ClojureListView<File>指定と同等のものが見つからなかった
  2. FXMLを使わない方法でstartしようとするもなぜか(.lookup root "#id")でnilが返っ てくる。lookupで対象を絞り込むことすら叶わなかったので諦めた。
  3. ScriptとしてのClojureを呼び出す方法の場合も同様でListViewの型にString以外指定 できないため断念。

とにもかくにも動的型付けとJavaFXの静的型付けが喧嘩をしている印象。どうしたもんか 。

スクリプトとしてのClojure

JavaFXないでJavascriptClojureを使うことが可能。Clojureは正式には対応していない ので、専用のライブラリを入れる必要があったが、たしかに動作した。注意点は、 <fx:script source="/script/event.clj" />とかって指定をする場合は、FXMLのrootの一 番最後のタイミングでロードするようにしないと、fx:idで定義されているコンポーネン トが未定義扱いされてアクセスできなくなる。

LightTable

Clojureの開発環境としてよく候補に上がるものらしい。使ってみた感触としては...。微 妙極まりない。まずフォントサイズの融通が利かないし、補間もほとんど聞かない。Web の記事の情報だとリアルタイムでClojureのコードの変更が反映されるとかって話だけれ ど、僕の環境では全然そんなことはなかった。うーーん。十中八九設定がうまく行ってな いだけなんだろうけれど、第一印象が良くなかったツールにこだわってもしょうがなかっ たので早々に設定は諦めて他のツールを探すことにしました。

Spacemacs + CIDER

Twitterでぼやきながら書いていたところアドバイスをいただきました。以前VimEmacs の間の子ということで一瞬だけ使ってどういう理由があってか結局Vimに戻ってしまった 経緯を思い出しながら再度インストールし直し。Clojureを書くようになってからinit.el を読むとそのコードの意味が何となく理解できるようになった。結局ClojureGUI作成は ほぼ断念しているけれど、「読める」ようになっただけでもでかい収穫だなぁと。

Spacemacsの第一印象は「随分リッチな見た目だなぁ」。Vimと双璧をなす古くから存在す るエディタとは思えないくらい今風の見た目にチューニングされていた。ただ起動直後に インストールしている拡張機能の更新を毎回探しに行くようで、起動直後からすぐにコー ディングできないのはマイナス。個人的にはエディタは不要になったらすぐ閉じるタイプ の人なのでこのローディングは結構重い。AtomといいVSCodeといい、最近のエディタは開 きっぱなしが前提なのかな。

使い勝手としては、確かにVimの操作がほぼできる。:tabeでタブを開けないのが気になっ たけれど、C-w + lとかで画面分割も普通にできるし、ファイル移動もお手の物。コマン ド名の補間機能まであるし、内部ターミナルまで実装されているとやりたい放題でVimと は本当に違うなぁと。(といってもこれはSpacemacsというよりEmacs自体の機能だったか な)ただVimもdein.vimを入れてかなりいじくり回しているので、ほぼほぼ自分のVimEmacsの違いはなくなってきてるが。

Webの記事を参考に操作を試すも、SPCをAlt+Mと読み替えないといけなかったり、ところ どころVimキーバインドで設定が上書きされていて使えなかったりと、やはり弊害も多 い。メインエディタを乗り換えるには高い壁があるなぁ、と。Vimを勉強し始めた頃は Youtubeで使っている人の動画を眺めたりとかしていたが、SpacemacsもYoutubeで使って みた動画を視聴して「どれくらい強力なのか」を目で見てみないと、すぐにVimに戻って しまいそうだ。というか、もう戻ってしまった。

流石に3年ほど慣れ親しんできたエディタから簡単に乗り換えるのは叶わず。だけれど、 実のところSpacemacsはめちゃくちゃ興味がある。VimのVimScriptのような酷い言語と違 ってこちらは非常に統一感があって柔軟性がある。Vimは非同期処理が苦手(できないわけ ではないが)ということで、どうしてもUI的に無理がある部分もあるが、Emacsは割となん でもできるらしい。どれだけ強力なのか、設定の仕方はどうすれば良いのかなどを理解し てどこかのタイミングで乗り換えてしまいたい。

Clojureのコミュニティ

Clojureのことをぼやきながらコードを書いていたら全く今まで関係のなかった方から度 々アドバイスを頂いた。日本でClojureがどれだけ流行っているのか知らないけれど、意 外と使っている人がいるのだろうか...。Kotlin + JavaFXの件をぼやきながらコードを書 いているときだと全然そういうこともなかった。単純に自分がClojureにハマって愚痴を こぼしている頻度が高かっただけかな。

Kotlin + JavaFX

以前から作成を続けていたTKFMのKotlin移植。今日はツクールのバージョンの違いをリソ ースファイルに吐き出していたものを読み込んでUIに反映するところを実装した。思いつ きで出力パネルをタブ化して、タブの切り替えで出力を変更できるようにした。突然の実 装の変更だったので、影響範囲がでかくて色々苦労した。当初予定していなかったstatic 変数の参照を辞める必要が出たので、コンストラクタに渡したりする必要が出ても~大変 。とはいえなんとか変更はできて、マウスクリックで反映された。

基本的な動作はほぼほぼ実装が終わったので、あとはショートカット周りの操作系と、画 像出力系くらいかなぁ。あとウィンドウの位置とか画面幅の設定とかその辺をConfigファ イルに吐き出す処理も必要になる。あと前から考えていた画像自動生成機能を実装したい ので、どこかのタイミングでタブを追加してしまわないと。タブごとに全く異なる機能な ので、変更してもそこまで影響はないと考えているけれど、レイアウトとか変わっている 部分でもあるので、早めにタブだけ追加しないと。

Chocolatey + Vim

ヘルプ開いたらKaoriyaVimじゃないんでドキュメントが普通に英語だった...。そりゃそ うか。

-- 次郎 (Jiro) Github : https://github.com/jiro4989 Blog : 次ログ - http://jiroron666.hatenablog.com/ Twitter : https://twitter.com/jiro_saburomaru/