赤宿 = Red Inn

赤宿 = Red Inn

素人の試行錯誤と2Dローグライク制作 (GUI)

Top

 2Dゲームを作るブログです。素人のブログですので、内容の真偽にお気をつけください。

目次

 カテゴリの記事一覧に飛べます。

 DevLog DevRef Env Self

過去に作ったゲーム

ウディタローグライク

 遊ぶほどのものではなく、スクリーンショットだけで十分です。

  • 羊山ゴートの冒険 [2013/8]  一作目。ウディタではゲームの流れを直接記述できたのが良かった。

  • ツギハギの行方 [2015/8]  二作目。UIは良くなったが、ゲームと呼べない完成度。

現在

 C# + FNA + Nezローグライクゲームを制作中。Caves of Qud作者のスピーチで解説されたアーキテクチャを真似ているところ。

やにわにメタル10選

 前回に続き、メタルバンドのメモの第2弾。ゲ制ブログですけれども許して。。

 相変わらず、有名どころばかりを巡回していく。

Black / Doom

1. Behemoth - Poland | 1991 ~

 これはカウントせざるを得ないというバンド。ブラックメタルらしいのだが、僕の中ではPOPということになった。『これはメタルだ』という先入観を忘れた頃に、良さに気づけたように思う。

 最新作は11枚目。常に最新作が最も良いタイプのバンドかもしれない。最新アルバムのタイトルは、 I love you (even if you were) at your darkest と補完できそう。

2. Evoken - America | 1992~

 doom / funeral. 一度良いじゃないかと認めると、POPよりもポップに思えてくる。

 さっきから自分でも何を言っているのか分からないが……。深く馴染むということかもしれない。もっと聴き込めばさらにハマれそう。

Major

3. Avenged Sevenfold - America | 1999~

 元はメタル (パンク?) バンドだったA7X。ここらでカウントしておこう。

Melodic

 日本の人にはメロデスのウケが最も良さそう。

4. Elzevir - Russia | 2008-2010

 melodic | symphonic | folk. 早々に解散してしまったメタルバンド。キーボードが二人いて、音作りが非常に上手い。これは好きだろ、と呟いている間にアルバムを一周してしまう。もう一周しておくか。

 ギターの音が若干潰れがちかもしれない。さらに完成度を上げたアルバムが欲しかったが、その機会は永遠に来ない。

5. Insomnium - Finland | 1997~

 melodic | doom | progressive. 北欧メタルと言えば、僕はKalmahとInsomniumをイメージする。人によりけりなのだけれども。

 ロックのような一作にリンクした。歌詞がとても優しかったので。バンドの本領を知るには、別の曲の方が良いかも。

 アルバムでは、まだ最新作しか聞いていないが、メロデスとのギャップでdoomメタルのような傾向が目立つ。メロデスだけを聴きたいときは向かないバンドかもしれない。

 2019/10に新譜が出るらしい。一曲先行公開されており、大いに期待。私的には、コーラスをもっと出してみて欲しいが、たぶん控えめだろう。

Symphonic

6. Monolith - Canada | 2009 ~

 core | symphonic. 相性の良い組み合わせで、曲も良い。

Power

7. Heavenly - France | 1993 ~

 power. 大仰でコーラスが良い。Queenが好きな人などはすんなり入れそう??

 brea氏のcombo madでも使用されていた曲をリンクした。Heavenlyは比較的最近に活動を再開したようだが、新譜が出ることを期待しても良いのだろうか……?

8. Pathfinder - Poland | 2006~

 power | symphonic. このバンドは、ちょっと別格かもしれない。部分でもトータルでも他の追随を許さないようなところがある。

 新譜を頼みたい!!

Rock?

9. Kvelertak - Norway | 2007~

 スローテンポで8分音符メインという印象。アリだ。似たバンドも見たことが無い。

 まあにわかなんですが。

Tech

 アメリカで流行っていそうなテクニカルデスメタル

10. INFERI - America | 2006~

 tech | melodic | epic. 神々しさがちょっと特別な気がする。

以上/その他雑談

 あまり多くのバンドを聴くことはできない。前回と併せた20のバンドを聴きこむだけでも、数年はかかりそう。人生で手が及ぶ範囲って、あまりに狭いものですね。せめて深掘りするしかない。

 まだ聴いていないメタルとしては、progressiveやグルーブ重視のものがある。ハマったらまた記事(メモ)を書くかも……?

ソフト的環境の改善

 溜まってきたので投稿。

Utils

P2K

 Pocketに登録したwebページ(〜20個)を、電子書籍にしてKindleに送ってくれるサービス。情報蒐集で非常に役立つ。

z

 ディレクトリ移動に役立つCLIツール。自動的なブックマーク機能が手に入るようなもの。

Terminal

 色周りは、MacのTiled型WMを開発している人dotfilesからコピーした。使用ソフトが変わったため、Macの環境の記事も更新。

tmux

 噂のteminal multiplexer。GNU Screenとよく比較されている。

 複数のタブを持つ複数のセッションを作成できて、さらにその寿命は(個々の)ターミナルから切り離される。

 初期の操作が合わなかったため、unbind-key -aで全てのキー設定を解除し、一つずつ自分で設定してみた。自分だけが使うなら、これが最も効率が良いはず。

Kitty (termianl)

 見た目は↓のように。なお、なぜかVim以外でマウス操作が出来ない(macOS)。

f:id:samba_4e:20190727222402p:plain
Kitty terminal

 ※画面下部のタブっぽい部分はtmuxのタブの表示

 iTerm2より、動作も見た目も改善されて大満足。

# ~/.tmux.conf
set-option -t 0 escape-time 0

Else

qutebrowser

 この頃、Macさんのキーボードやトラックパッドが反応しなくなって焦った。どうもFirefoxがリソースを使い過ぎ、マシンが熱くなり過ぎたせいの気がする。

 代わりのブラウザが必要で、qutebrowserを見つけた。キーボード操作をメインにした、Chronium系のブラウザらしい。一応Vimが基になっている。

f:id:samba_4e:20190727222154p:plain
qutebrowser

 意外に実用的なブラウザだった。動作は安定しており、UIがリッチで、簡素な設定ファイルを利用する。メモリ使用量も多くない。

 メディアの対応に制限があり、pdfや動画は再生できない。動画はmpvに渡して再生してもらえば十分だと思う。Twitterは不便だろうけれど。

 設定にはどうしても数時間かかる。プラグインには対応していない。『greasemonkey scripts』でサイトの配色を変えられるらしいが、僕はやり方が分からなかった。でも十分。

にわかにメタル10選

 やはりゲ制となんの関係も無い記事。

 聴き始めて二年弱くらい? 人にお勧めできるバンドをリストした。おそらくベタ過ぎる10選。

Bands

 一応一万円以上のヘッドフォンを使って聴くことをお勧めしたい。

Pop

 メタルというよりもロック。商業的に成功しているらしい。

1. Ghost - Sweden | 2006 ~

 レトロな雰囲気のバンド。曲が良い。

www.youtube.com

2. Khemmis - America | 2012 ~

 doom metal が元ネタ。名前からしてセンスが良い。

www.youtube.com

Clean

 デスボイス無し。

3. Theocracy - America | 2002 ~

 power | progressive | christian.

 思い出補正もあるけれど、今でも一番盛り上がるバンドだと思う。

www.youtube.com

Technical

 デスメタルサブジャンル。音数が多い。

 音質的には優しいものが多く、しかしライブでは他のメタル同様に激しい音になる。

4. Obscura - Germany | 2002 ~

 technical. 多弦ギターにフレットレスベースと変態感が凄い。そしてコンスタントに曲が良い。

www.youtube.com

5. The Black Dahlia Murder - America | 2001 ~

 black | technical. こちらも常に曲が良い。どこを切り取ったってプロだし、最新のアルバムが最も出来が良い。

www.youtube.com

Death metal

6. Heaven Shall Burn - Germany | 1996 ~

 german metal: ひたすら16分音符で進んでいくスタイル。

www.youtube.com

7. Kalmah - Finland | 1998 ~

 melodic | 自称swamp. ナイスガイ感が凄い。

www.youtube.com

8. Raptor - Canada | 2006 ~

 pagan metal. 曲によってはフォーク要素が強い。

www.youtube.com

9. Decide - America | 1987 ~

 無印のデスメタル。ややブラック。普通のメタルがいかに旨いか教えてくれる。

www.youtube.com

Brutal

10. MDMA - Spain | 2017 ~

 brutal. 間違いなくオススメできるバンドの一つ。チョコのような苦さに慣れればひたすら旨い。

www.youtube.com

Making a CLI Tool in Rust

 RustでCLIツールを作った際のあれこれ。環境の良さに感動した。

 これを読むより、普通にネットを調べた方が速くて詳しい……

Rust

 Rustそのものについてのメモ。一言で済ませるならば、仕様と良文のために『最も簡単な言語』。

 僕が『一番使える言語』を挙げるとすれば、Rustだという手応えがすでにある。通常のプログラミングはできるし、何か新しい分野の技術を身につけるとき、Rust周りが最も楽だと思うため。(前述の通り、ドキュメントと言語仕様が良い)。

言語機能/環境など

 環境構築はワンコマンドで、その後の更新はrustup updateのみで済む。

Documentation comments

 /////!markdown風に書ける。ドキュメント中のexampleに対してtestを実行できる呆れた整備具合の上、ソースから生成されるDocs.rs他のどの言語のドキュメントよりも見た目が良い

modulability

 2018からは非常に明快。メモとしては、

  • 1つの file/directory が1つの module に相当する
  • 可視性は最小でmodule単位
    • 同moduleからは全て見える
    • 外のmodule/crateから見えるのかをmod.rsで設定する
  • moduleには3つのスコープ?がある
    • crate::anything
    • ::external_crate::anything
    • self::anything
    • super::もあったな、そう言えば……
  • useself下へのre-exportingができる
    • use宣言のときは、selfは強制的に省略される
    • self::anythingmod宣言されていないとre-exportingできない
  • main.rs から見た lib.rs は外部のcrateという扱い
    • main.rs はミニマムにする
    • main.rsは、src/binもしくはbin/に置くと、lib側から区別しやすいと思う

 Rust2018からは、directory.rsdirectory/mod.rsの代わりにできる。

Error handling

 Errorが発生した場合は状況を返し、呼び出し元がErrorを処理する。単純で迷う必要が無い。

 errorで即終了する場合は、Result<T, E>を返す。errorが出ても一通り走査するなら、errorが出るたびVecに蓄えて、(SomeValue, Vec<Error>)を返せば安心。

Early return

 matchreturnが式であるため、Resultearly returnが書きやすい。それを自動的に書いてくれるtryマクロ、さらにtryマクロの構文糖衣: ?が非常に便利。

No exceptions

 Resultの使用が推奨されて、言語機能に『例外』が無い。簡素で本当によく出来ている。

 これも、関数型言語で発達したsum type (代数的データ型) のおかげということか? OCamlの本なども読みたいな

Error with context [調査中]

 たとえばParseError::UnexpectedTokenは、何をパースしているときのエラーだろうか? その情報を追加で埋め込めなければ、文字列をエラーに使う方法に劣る。

 調査中

Tests

 試しにlibを使ったコードを走らせてみたい。ならtest用modに#[cfg(test)]だ!

 手続き型マクロなどにより簡単に書ける。テスト用のフレームワークに煩わされることも無い。本の中でも普通に出てきて、ユニットテストなどの解説も得られる。

Traits

 継承が馬鹿らしくなる高級さ。もっとも、trait object (抽象的なインスタンス) が多用される場面では、継承の方が楽な気がする。要検討、要比較

Iterators & combinators

 traitのおかげで具体的な型を使用できて速い。コンパイル時に最適化も働く(for文に展開されるなど)。

 要調査: イテレータを含むコードの最適化の限界、遅くなる条件

Macros

 DIにも使える? (c.f. log) 詳しくなりたい。要検討

Ownership

 最大の難関。まだ問題になったことは無いが、いつかRustでゲームを作りたいなら、smart pointerと共に熟知しておくべきか。

x.mutable_func_A(x.mutable_func_B()); // error!

 案外ECSを使うだけで、この悩みからは解放されるかもしれないが……

Pure ECS

 通常ゲーム制作のフレームワークは、オブジェクトの管理法をE、EC、ECSのいずれかに分類できる。ところが、Rustは所有権のルールのために(&mutを二つ同時に作れない)、ECS以外の選択肢が実質的に存在しない。たぶん。

 コードの構築法として、RustのPure ECSはどうなのかが心底気になる。いつか試すはず。

 ……CLIツールと何の関係もない!

Lifetimes

 コピーを減らすために重要。文字列などは、ファイルのhandlerから寿命を分離するために、cloneが必須の気がするが……? 検討中

リソース

 ここからが本題。

公式

nursery

  • CLI book
    まずはコレを読む。confyが動かないのは僕だけ?

  • Cookbook
    一応挙げたけれど、信用できない点が多い。最新のツールが例と一致するなら、利用できるかも。

Editions

 2018 の改良が大きい。特にPath clarityの話は読んでおくべき。

 なおlib.rs#![warn(rust_2018_idioms)]を書いておくと、コンパイラが2018仕様のコードを推奨してくれる。e.g. traitオブジェクトをdyn Traitと書くように推奨される(dyn: dynamic)。

変更点のメモ

 2018以降にRustを使うユーザには不要な情報かもしれない。

  • deprecated (?)
    • extern crate が不要
    • #[macro_use]せずとも、マクロをuseの対象にできる
  • 追加
    • crate::something
    • ::external_crate::something
    • pub (keyword)
    • self::something は、前からあったっけ
    • module_name.rsmodule_name/mod.rsの代わりにできる
    • impl Traitもようやく安定

Else

  • 実践Rust入門
    未読。『自転車本』とか呼ばれるのだろうか。著者が著者だけに良さそう。いつか読みたい。

Editor support (language server)

 僕はVS Codeを使っている。Rustへのサポートは、機能的には十分だが、C#ほどのものは望めない。

  • 解析が遅く、それなりの頻度で待つことになる。
  • エラーがある間は自動整形が働かない
  • たまに補完が効かない
    • stdなどのソースへのジャンプもできず、メソッド探しのためにオンラインのドキュメントを読む羽目になる

環境変数

RUST_BACKTRACE=1

 エラーの発生位置の確認用。

Cargo

 Cargo本を参考にする。

ディレクトリからcargo runを実行する

$ cargo run --manifest-path 'path/to/Cargo.toml' -- <parameters>

cargo script

 実行ファイルの生成 → 実行 → 実行ファイルの削除 をやってくれるサブコマンドを追加。

aliases

 ~/.cargo/configにtomlで[alias]の項を書く。

main.rsを任意の位置に置く

 [package]下に次の内容を追加する。

[[bin]]
name = "your_project_name"
path = "where/you/like"

Impl CLI Tool in Rust

 作ってみた(非公開)

arguments/stdin/stdout

Argument parsing

 structopt(将来的には、structoptをmergeしたclap)を使う。自力でパースした方が力は着きそう: 任意の位置のオプションを許すなど。

stdin / stdout / stderr

 読み書きは lock しなければかなり遅いらしい。読み出しは buffering しなければ、メモリ使用量が増える。これは文字の読み書き全般に言える。

stdin

 標準ライブラリのドキュメントを読む。

stdout / stderr

 print!, println!, eprint!, eprintln! で書き込める。

 毎回flushするため遅い、という話があり、lockしてからwrite!などで書き込むと速そう。

I/Oの存在を確かめる

 atty crateに頼る。

pub fn any_pipe() -> bool {
    !::atty::is(::atty::Stream::Stdin)
}

Colorized output

 ansi_termColour::Red::paintするなど

Logging

 インタフェイスとして、log crateを使用する。ライブラリ側 (lib.rs)はdebug!などのマクロでログを書き、ログは『レベル分け』ができる。

 ログの実装はバイナリ側(main.rs)でログに任意の実装を与えられる(?)。RUST_LOGを設定することで、表示するログのレベルを設定できる。

coding

Error handling

 主流なerror handlingのcrateよく変わり、今も実験中みたい。僕はひとまず、Error型をBox<dyn ::std::error::Error>にする杜撰な方法で間に合わせている。だがこの方法は古い。

 deref coersionのおかげで、returnのためのBox::newは不要となっている。

歴史

 crateの流れとしては、error-chaing -> failure (-> snafu) らしい。snafu以外はnurseryから出ている。最近は、stdErrorを改善している最中だとか。

 snafuの人は、Stack Overflowでも大活躍していて、僕も間接的にかなり助けられている。The bookで調べられないディテールを情報化し、整備し、検索性も高めているわけで、言語の価値を高めている人だと言えそう。

 いっそidiomatic rustの本を書いてほしいな。

regex, tabling, etc.

 crateがある。regexは、文字クラス[]エスケープについて、sedと細部が違った。よくテストした方が良さそう。

String

 コピーを減らしたい。lifetime付きの&strの使用と、既存のStringの変更を考えたい。

byte offset, unicode offset

 文字列ではなく、バイト列として読み書きした方が速い? ronのソースを読んで調べたい。

buffering

 少数のStringに少しずつ読み出す。

With New Architecture

 イベントを多用した新規アークテクチャの進捗

Development

 前回の記事の通り、あらゆる変更をイベント経由で行うことにした。キャラの行動も変更の一種として理解し、イベントとして処理する。

 ViewやSystemをstoreすることで、Engineを拡張していった。クラスや関数に属性を付けて、自動的に追加させても良いかもしれない。ViewとSystemは、context以外状態を持たないため、hot swapが楽そうだと思う。DLLにする必要があるのかもしれないが……。

 今後は、Tiledマップを繋いだり、外部ファイルにスクリプトを置いたり、ronC#で実装する予定。

Implementations

 基礎的な処理を追加していく。

MeleeAttack(通常攻撃)

 MeleeAttackHitGiveDamageという変換を経る。ログを足すなら、LogSystemを追加するだけで済むと思う。LogSystemには、イベントと外部ファイルのテキストを関連づけるロジックが入る。未実装。

 HACK: ネストしたイベントの処理結果をネスト元のイベントに伝えるために、イベントの基底のフィールドを利用する。要検討

Death event handling

 GrimReaperSystem(死神システム)が処理する。ここ重要、中二的な意味で。

 entityの削除によって、スケジューラのindexがずれないように注意する。また、entityのコレクションに対してforeachで巡回するコードからネストして死亡イベントを処理する場合、即座にentityを削除すると、例外が出ることに注意。

 僕の場合は.ToArray()でコピーを作って回避した。lazyな検索は必要無いと判断したため。強制的にArrayを返すことだってできる。

 ただし.ToArray()を忘れると、キャラの削除が起こった時に死ぬ。たとえArrayにしていても、死亡したEntityにアクセスすると死ぬ。

 被ダメージなどのアニメーションが終了するまでEntityを削除しないのが重要なのだが、これも方法を検討中。数秒後に削除予約、といういい加減な方法でも十分な気はする。

DungeonSceneComponent

 ダンジョン生成のアルゴリズムとして、KarceroNuGetパッケージを入れた。.csprojファイルに参照を追記すれば、即座に利用できるようになる。

 参照は自分で書いてもいいが、dotnetコマンドで追加することもできる。VSでは、GUIからも入れられるはず。

$ dotnet add package Karcero
$ cat <path_to_csproj>
...
    <ItemGroup>
      <PackageReference Include="Karcero" Version="0.4.0.0" />
    </ItemGroup>
...

 ダンジョン生成やキャラ配置のコードは、専用のSceneComponentに置いた。

StairSystem

 主人公が階段の上に移動したら起動する。変更をイベント経由で行う仕組みのおかげで、この手の処理を挟むのは楽のはず。

 主人公の判定には、Playerコンポーネントを使う(これはただのタグ)。主人公の移動を検知する方法は、間接的な表現になった。

 具体的には、PosChangeというprimitiveなイベントを購読し、そのcontextを見てフィルタリングする。(.causeWalkで、.entity.has<Player>()であるPosChangeイベントを対象とする。)さらに、移動先に階段があれば起動する。長いな。修正するかも。

Events just for observation

 初めからWalkInto(entities)のようなイベントを発行しても良い。ただ、そうした観測のための恣意的なイベントを作るのは面倒に思う。すべての変更をイベント経由で行うメリットは、柔軟な設計にあるわけだし。

 ただし、恣意的なイベントを用意した方が、処理効率は良いと思う。

Some tests

Multiple heroes

 UIが行動を注入するキャラを、複数作ることができた。他キャラの操作や、憑依なども表現できるだろう。期待通り。

Too many entities

 600体くらいまで安定して動かせた。意外なことに、画像だけでなく、内部処理が重いみたいだった。イテレーションというやつか。

 現状、1フレームで全キャラの行動決定をする仕組みになっており、多数のキャラを処理するためには、並行処理が必要になりそう。

 それでも、2, 3倍程度の数しか扱えないのだろうけれど。

Note

 処理負荷に関する基本的なセンスが足りない。1/60 = 0.0167 秒に走らせられるコードの量は、どれくらいなのだろうか。要検討

Experience

 至極私的な話。地味な改善が積み重なって、色々噛み合うようになってきたと感じる。

利便性の向上

 設定ファイルを書くと、急速に実力が上がる。

Vim-like key bindings

 zz, z<Enter>, <C-i>, <C-o>, gd, .. 地味に使えるコマンドが増えた。

.gitconfig

 設定ファイルを書いてみた

Speed++

 マシンの扱いがこなれて来た。英語を摂取するスピードも増したし。情報を探し続ける必要がある状況に変わりは無いが、その作業が前よりも楽。何と言っても、時間をかければ前進できる状態にある。これは、リサーチを続けた何よりの成果。

Atom's plugins

 既存プラグインの改変は簡単だった。Coffee Scriptはセンスのある言語な気がする。Python風のインデント、Ruby風のフィールド表記、関数的な式指向。でも、型付けが動的だ。

Git

 Pro Gitがある以上、役立つものではないけれどメモ。

ssh-add path/to/ssh

 GitHubとの接続用。PCを再起動する度に稼働させる必要がある。稼働させるのを自動化したい。要検討

ハッシュ値について

 要検索 c.f. blockchain

rebase/cherry-pick

 commitはスナップショットを作る。スナップショットを比較して、差分(パッチ)を作ってcommitにするコマンドがある。それがcherry-pickrebase

  • cherry-pick パッチを取って適用する。
  • rebase 現在のbranchを分岐点で切り離してパッチにし、他の分岐先に一つずつ適用する。もしくは、パッチ内容を改変して、元の箇所に適用し直す。

 rebaseは、cherry-pick+branch -Dみたいなイメージかな? tldrによるgit rebaseの説明も良かったので参考にした。

 パッチを使わずに、一つずつファイルをcheckoutしてコミットすることもできる。また、rebaseは、以前の履歴をsquashしたりと、履歴の改変全般に使えそう。

merge

 怖くないGitというスライドが良かった。見た目がハイセンスで説明も良い。

 一点分かりにくかったのは、rebaseによってconflictが発生する例。このrebaseは、履歴改変としてのrebaseであり、直前まで説明されていたrebase(もいでパッチにして生やす)とは、やや趣旨が違うと思う。

 なお、masterをrebaseするのは問題だが、別の分岐をrebaseして、masterからコミットを生やすのは無問題のはず。下の『rebaseしてみた』で確かめた。

 備考としては、『push/pullできるのは、元branchからfast-forward mergeできるcommitだけ』。それが分かっていればrebaseも怖くない。

 あと、topic branch (feature branch) をdev branch にmergeするときは、squashして履歴を束ねている。

else

  • git addは深い階層にあるファイル名も補完してくれて便利がいい
    • シェルのパス補完も再帰的にしたい
  • working tree と index を表す記号があれば、diffの理解が楽だと思う
    • e.g. git diff <old> <new>という書式において、<old> = index, <new> = <working tree>が初期値であると理解できる

rebaseしてみた

 まあそうなるよね、という当たり前の確認。

$ mkdir rebase_test ; cd rebase_test
$ git init
Initialized empty Git repository in /Users/<user_name>/Desktop/dev/git/rebase_test/.git/

$ vim test.md # echoにすればよかった
$ cat test.md
The first commit
$ git add test.md
$ git commit --message 'init'
[master (root-commit) 951de41] init
 1 file changed, 1 insertion(+)
 create mode 100644 test.md

$ git branch A
$ git branch B

$ git checkout A
$ vim test.md
$ git add test.md
$ git commit -m 'write from A branch'

$ git checkout B
$ vim test.md
$ git add test.md
$ git commit -m 'write from B branch'

$ git lol --all
     0  * ab17f8e write from B branch (HEAD -> B)
     1  | * 5958773 write from A branch (A)
     2  |/
     3  * 951de41 init (master)

$ git rebase A
First, rewinding head to replay your work on top of it...
Applying: write from B branch
Using index info to reconstruct a base tree...
M   test.md
Falling back to patching base and 3-way merge...
Auto-merging test.md
CONFLICT (content): Merge conflict in test.md
error: Failed to merge in the changes.
Patch failed at 0001 write from B branch
hint: Use 'git am --show-current-patch' to see the failed patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

$ cat test.md
The first commit
<<<<<<< HEAD
Written in the A branch
=======
Written in the B branch
>>>>>>> write from B branch

$ vim test.md # 競合を解決
$ cat test.md
The first commit
Written in the A branch
Written in the B branch

$ git add test.md
$ git rebase --continue
Applying: write from B branch
$ git lol --all
     0  * c91416f write from B branch (HEAD -> B)
     1  * 5958773 write from A branch (A)
     2  * 951de41 init (master)

 branch Bをもぎ、branch Aの頭につけた。Aのハッシュ値5958773は変わっていない。

About music

 ゲ制と何の関係も無い記事。

 二年前に良いヘッドフォンを買った価値があった。メタルを聴く毎日を過ごしている。モニタリング・ヘッドフォンといって、何の音が鳴っているのか分かりやすいけれど、聴き疲れしやすい種類らしい。

 安いヘッドフォンでは、エレキギターが分かりにくかった。何かノイズが鳴っている、程度にしか聴き分けられない。音程なんて分からない。エレキギターを弾く人ならば、元の音を想像できるのかもしれなけれど。

 ヘッドフォンを変えれば、演奏が大体分かった。特にバンドは分かりやすかった。細部を聴く耳は無いのだけれど、『何が起こっているのか』を大体把握できたなら、分かりやすく『ヒーロー』たちを認識できる。

 自分でも、Dominoで80曲くらい打ち込みをしてみた。普段良いアルバムを聴いているため、酷さが際立って聴こえる。それに、ブリッジミュートも無しに80曲作ったって言ってもねぇ。カッティングばかり。今はエイリアンメタルな曲を作っている。ブラストビートが聴きたい。聴きたい曲を自分で組んだり、見たいイメージのために打ち込むこともある。大体芋っぽくなって笑ってしまう結果になるが。意外と感性は修正が効かない。自分全般が変わりにくい。

 打ち込みに使用しているGM音源のショボさが辛い。DAWの初期音源よりは、わざとらしさが少ない気がして妥協している。良い曲と良い演奏は区別できない気がしてならない。それでも一応、見たいものや作りたいものになるから、必要最低限は満たされるけれど。

 Obscuraのライブに行ってみた。テクニカルデスメタルは、アルバム音源よりも、ライブの方が音が激しくて良いかもしれない。攻撃的で音数が多いというなら、ひたすら旨いジャンルな気がする。

 ライブ後、耳鳴りが酷かった。難聴を恐れて、今後は耳栓を持っていくつもり。ヘドバンのノリについて行けないので、壁際で石になって観ている。そっとしておいてくれるとありがたく、それには意外と人徳がいる。慈悲のようなものが。放っておいてくれてありがとう?

 宣伝の一種なのか、フルアルバムをyoutubeに上げているバンドが多い。アルバムがyoutubeに無い場合は、大体bandcampで販売している。安くてありがたい。かつて、DMCのサウンドトラックが6,000円くらいしたが、あれは高過ぎた……。

 日本の曲は大体民謡でクセが強い。合わなくても普通だと思う。現代なら趣味が分散する方が普通か。曲は良いのに歌が苦手なことがあり、日本語をクールに思えないところがある。

 僕の場合は、ヘッドフォンのおかげで、メタルが分かりやすい音楽だと分かった。最初にiTunesでメタルについて検索し、Theocracyを聴けたのは運が良かった。猿のようにアルバムをかけたし、今後も何度も聴くだろう。その後、シンフォニックデスメタル、パワーメタル、スラッシュメタル、テクニカルデスメタル、ブルータルデスメタルデスメタルブラックメタル、フォークメタル、デスコア、ペイガンメタルと守備範囲が広がった。メタルが知らない人からすれば、何を言っているのかさっぱり分からないかもしれないが。僕の音楽フォルダは、メタルのサブジャンルの方がその他の大分類よりも多くなった(最終的に、Popとメタルのサブジャンルのみになった)。

 今Theocracyを聴くと、ギターの音が野暮ったい。Mixの影響だろうか。もう少しブルータルな方が好みだとも思う。でも、やっぱり曲がいい。

 今はNordheimがストライク。好みが変わったのか、僕の中で、TheocracyはPopに近くなってしまった。

 かつてのPopは民謡枠。なおPopを聴いていると、どうしてもドラムの音数を増やして欲しくなる。

 最近のボーカロイドは、民謡的Popとダンス・ミュージックが目立つ気がする。作者で選んで聴くようになるのは自然な流れか。メタルの人が見つからないため、ほとんど聴くことが無い。昔注目した曲をもう一度聴くため探しに行くと、他にも色々活動されているみたいで良かった。やはりやる人はどこかで活動している。自分を省みて、うん……。

 近所の人から、かつてロックやメタルをやっていたけれど、結局ブラジル音楽が好きだと見つけた、という話を聞いた。クラシック演奏的な基礎が無いことを後悔されているとか。悲しくも修正が効かない。

 僕が今メタルを聴いているのは、分かりやすくて旨いから。大して好きなのか分からないし、好みも変わり続けている。実はそのほうが普通なんだろう。僕も、あの人のブラジル音楽的な発見ができればいいのだけれど。

 と言いつつ、100回聴くであろうアルバムを3枚見つけた。最初にメタルを聴いたときは、強く影響を受け、何か風景を思い描かずにはいられなかった。今は中毒性の高いコーヒーみたいな位置付けで、意識しないと映像なんて出てこない。

 だからどうというわけではないが、初期の感動をたまには思い出した方が良い気がする。