クォータニオンとは何ぞや?:基礎線形代数講座

みなさん、はじめまして。技術本部 開発技術部のYです。

ひさびさの技術ブログ記事ですが、タイトルからお察しの通り、今回は数学のお話です。

#数学かよ って思った方、ごめんなさい(苦笑)

数学の勉強会

弊社では昨年、有志による隔週での数学の勉強会を行いました。ご多分に漏れず、コロナ禍の影響で会議室に集合しての勉強会は中断、再開の目処も立たず諸々の事情により残念ながら中止となり、用意した資料の配布および各自の自学ということになりました。

勉強会の内容は、高校数学の超駆け足での復習から始めて、主に大学初年度で学ぶ線形代数の基礎の学び直し 、および応用としての3次元回転の表現の基礎の理解といった感じです。

「線形代数」とは、微積分と並び理工系の科学・技術の諸分野で基礎中の基礎として用いられる数学の分野で、ゲームでは主に3DCGの技術的基礎として応用されています。昨今のAIブームでも一時期話題になりました。 タイトルにある「クォータニオン」とは、日本語では「四元数」と訳され、ゲームではキャラや背景などを3次元回転させるときに応用されるもので、勉強会の中では最後に出てくるラスボスであり少し難しい数学の概念です。

勉強会の趣旨は、この「クォータニオン」を数学的にきちんと理解することを えさ ゴールとして、そのために(実際はそれだけでなくさまざまな技術の基礎となっている)「線形代数」の基礎をきちんと学び直そうということでした。

なぜ数学?

ゲーム開発においても分業化・専業化の流れは著しく、ゲームアプリケーション(みなさんに遊んで頂いているゲームそのもの)を開発する際、いわゆるゲームエンジンや各種ライブラリを用いるのが当たり前になっています。これらエンジンやライブラリは、ゲーム開発者にさまざまな機能を提供し効率よく開発できるようにすることが役割であり、極端な話、三角関数を全く知らなくても3Dゲームを作れる時代になっています。 しかしながら例えばゲーム固有の表現のためにシェーダー(画面を描画する機能)をカスタマイズしたい場合や、当然のことながらエンジンやライブラリそのものの開発者は、ある程度のさまざまな数学の知識が必要となります。技術的に高度なことをしようと思うとなおさら深い理解が必要です。

このように数学や物理学は、ゲーム業界のみならず理工系のさまざまな分野で、科学者・技術者を根元から支える基礎となり重要な武器となっています。

資料を公開します

今回、この勉強会用に用意した資料「基礎線形代数講座:線形代数 回転の表現」を一般に公開いたします。全8講、本文が全部で140ページのPDFで、各講は以下のような標題です。

  • 第1講 イントロダクション
  • 第2講 初等関数
  • 第3講 ベクトル
  • 第4講 行列 I:連立一次方程式
  • 第5講 行列 II:線形変換
  • 第6講 行列 III:固有値・対角化
  • 第7講 回転の表現 I
  • 第8講 回転の表現 II

線形代数 基礎の本質的な部分をできるだけ簡潔に分かりやすく学べるように全体を組み立ててみました。各項目を学ぶ順番や手法、一部は定義すら一般的なものと違う(例:行列式)こともあります 。いわゆる「大人の学び直し」ではあるのですが、内容はガチの数学となっています。 記事の最後に公開先へのリンクを張っておきますので、興味のある方は参考にして頂ければと思います。

特に学生の方で、この資料で線形代数を学んでみようと思われた奇特な方がいらっしゃれば、言うまでもないことですが読んだ後改めて講義で指定されている教科書を読んでみましょう。きっとこれまで以上に理解が深まることと思います。

この記事では、その中から「クォータニオン」の導入部分である、第8講の第2節までをそのまま引用します。導入部なので内容は平易となっていますが、複素数・行列・三角関数に関するある程度の知識がないと理解は難しいと思われます。ぜひ紙と鉛筆を用意して、ご自身でも図や式を書いたり計算したりしながら、じっくり読んでみてください。

基礎線形代数講座からの引用

【第8講】回転の表現II


【8-1】はじめに

本講では、4種の3次元回転の表現の最後としてクォータニオンについて学ぶ。クォータニオンは日本語では四元数(しげんすう)と訳されるもので、1843年にハミルトンにより発見された複素数を拡張した代数体系であり、3次元の回転の表現としても多くの利点を備えている。
その性質から特に計算機を用いる場合にも他の表現手法に比べ優位な点が多く、近年 宇宙機を始め、3DCGやCV、ロボット工学等々さまざまな分野で応用されている。一方で他の表現手法に比べるとやや抽象的でその本質(4次元空間に埋め込まれた3次元回転)が捉えづらい面も否めない。本講では、拡張の元になった大きさ1の複素数の積による複素平面内での回転の復習から始め、ハミルトンによる発見に至るまでの過程*1をたどる事でクォータニオンを導入し、その性質を分かりやすく解説する。


●おさらい
任意の複素数 $ x+iy $ に大きさ $ 1 $ の複素数 $ \cos\theta+i \sin\theta $ を掛ける事は複素平面内での $ \theta $ 回転を表していた。実際 \[ (x'+iy')=(\cos\theta+i\sin\theta)(x+iy)=(x\cos\theta-y\sin\theta)+i(x\sin\theta+y\cos\theta ) \] この式で、$ 1 $ と $ i $ をベクトルの基底としてみると、 \[ x→x'=x\cos\theta-y\sin\theta,\ y→y'=x\sin\theta+y\cos\theta \] という線形変換と見ることができて、行列形式で書けば \[ \begin{eqnarray} \left[ \begin{array}{c} x' \\ y' \\ \end{array} \right]=\left[ \begin{array}{cc} \cos\theta & -\sin\theta\\ \sin\theta & \cos\theta\\ \end{array} \right] \left[ \begin{array}{c} x \\ y \\ \end{array} \right] \end{eqnarray} \] となり、すなわち複素平面である $ 1-i $ 平面での $ \theta $ 回転を表している事がわかる。

これの本質は、$ i $を掛けるという事:基底 1 と $ i $ との閉じた代数が、$ 1-i $ 平面内で一回りする回転に相当していることにある。
f:id:sgtech:20210601193226p:plain:h160


【8-2】クォータニオンの導入:ハミルトン劇場

[8-2-1] 拡張複素数で複素( 3次元)空間を回したい

ハミルトンは複素数を拡張して、虚数単位 $ i $ の他に独立な別の虚数単位 $ j $ を導入 $( i^2=-1,\ j^2=-1,\ \overline {i}=-i,\ \overline {j}=-j)$、$ 1,i,j $ の 3つの元で $ 1-i $平面、$ 1-j $平面、$ i-j $平面それぞれの回転を表現できないか?と考えた(つまり複素平面を複素空間に拡張できないか?ってこと) 。
f:id:sgtech:20210601193336p:plain:h160

「独立な異なる虚数単位 $ i,j $」に違和感がある人もいると思う。新しい代数として拡張していっているので、うまく拡張できさえすればあとは「慣れ」ではあるのだが「複素数」を以下のように解釈することで別の虚数単位を導入するという拡張も違和感が減るかもしれない。
おさらい*2:2行 2列の行列 $ \begin{eqnarray} I= \left[ \begin{array}{cc} 0 & -1\\ 1 & 0\\ \end{array} \right] \end{eqnarray} $ を考えると(この行列は 上の おさらいで出てきた 2次の 回転行列で $ \theta=\pi/2 $ としたものでもあることに注意)、 $ \begin{eqnarray} I^2= \left[ \begin{array}{cc} -1 & 0\\ 0 & -1\\ \end{array} \right] = -E \end{eqnarray} $ ( $ E $ は単位行列 )となる(つまり 2乗して -1)。また行列 $ Z=xE+yI\ (x,y∈\Bbb R ) $ を考えると、 $ \begin{eqnarray} Z = \left[ \begin{array}{cc} x & -y\\ y & x\\ \end{array} \right] \end{eqnarray} $ なので、$ Z = O $ となるのは $ x=y=0 $ のときのみ(つまり $ E $ と $ I $ は線形独立)。この行列 $ Z=xE+yI $ に対し $ E $ を $ 1, I $ を $ i $ に対応させることで、複素数 $ z=x+iy $ に対応させる事が可能となる。
ここでさらに別の行列 例えば $ \begin{eqnarray} J = \left[ \begin{array}{cc} 1 & -\sqrt{2}\\ \sqrt{2} & -1\\ \end{array} \right] \end{eqnarray} $ を考えると、$ J^2=-E $ を満たし、この $ J $ を含め $ E,I,J $ が線形独立であることは容易に確かめられる。このような「複素数の拡張」(上の $ J $ の事)がうまく行くかどうかは別にして「違和感」のない表現もやろうと思えば可能ではある。


以下、ハミルトンがクォータニオンを発見するまでの過程*3をたどってみよう。
ハミルトン:$ 1-i $平面と $ 1-j $平面の回転は当然できた。

f:id:sgtech:20210601193421p:plain:h160
でも $ i-j $平面がうまくいかない。 $ i\times j $ の扱いがどうにもこうにも…
とりあえず $ i\times j $ を $ ij $ として回るようにはできたけど*4、この $ ij $ って本来 $ i $ にならないと $ i-j $平面にはならない。でも $ ij = i $ としてしまうと $ i $ を掛けても $ -j $ にならずに $ -1 $ となってうまく回らない。どうしたものか・・・
(ちなみに後に別の数学者により、このような $ 1,i,j $ による 「複素数の拡張」(三元数に相当)は、うまく行かない事が証明されている。)


[8-2-2] 4次元? マジか 4次元??

ある日運河のほとりを歩いている時(実話*5)にひらめいた: もう一つ虚数単位を導入して $ i\times j=k $ としてみよう。実数単位 $ 1 $ と虚数単位 $ i,j,k $ で 4次元になるけど、うまくいくかも・・・
回転面は $ 1-i, 1-j, 1-k $平面, $ i-j, j-k, k-i $平面の6面になるのか。3次元回転をうまく取り出すには、$ i-j, j-k, k-i $平面の回転がこんな風になるといいのかな?
f:id:sgtech:20210601193503p:plain:h160

●$ i $ を掛けると?:想定図のように $ j-k $平面を回すため、$ ij=k $ としてみよう

f:id:sgtech:20210601193724p:plain:h160
お、$ j-k $平面だけでなく $ 1-i $平面も同時に回るんだ。そりゃそうか。しかもそれぞれの平面内で回りそうだ。
角度 $ \theta $ の場合として「大きさ」1の $ (\cos \theta+ i \sin \theta) $ を、4次元に拡張した「複素数」$ (w+ix+jy+kz) $ に( $ i^2=-1,\ ij=k, \ ik=-j $ に注意して)掛けてみよう:
\[ \eqalign{ (w'+ix'+jy'+kz')=(\cos\theta&+i\sin\theta)(w+ix+jy+kz)\\
=&w\cos\theta+ix\cos\theta+jy\cos\theta+kz\cos\theta\\ &+iw\sin\theta-x\sin\theta+ky\sin\theta-jz\sin\theta\\ =&(w\cos\theta-x\sin\theta)+i(w\sin\theta+x\cos\theta)\\ &+j(y\cos\theta-z\sin\theta)+k(y\sin\theta+z\cos\theta) \tag{8-2-1}\\ } \]
確かに $ w-x $平面( $ 1-i $平面:下から2行目)と $ y-z $平面( $ j-k $平面:下から1行目)がそれぞれの平面内 で同時に別々に回っている*6

つまりこういうこと
\begin{eqnarray} \left[ \begin{array}{c} w' \\ x' \\ y' \\ z' \\ \end{array} \right]=\left[ \begin{array}{cccc} \cos\theta & -\sin\theta & 0 & 0\\ \sin\theta & \cos\theta & 0 & 0\\ 0 & 0 & \cos\theta & -\sin\theta\\ 0 & 0 & \sin\theta & \cos\theta\\ \end{array} \right] \left[ \begin{array}{c} w \\ x \\ y \\ z \\ \end{array} \right] \end{eqnarray}


●$ j $ を掛けると?:想定図のように $ k-i $平面を回すため、$ jk=i $ としてみよう

f:id:sgtech:20210601193756p:plain:h160
およ。さっきの $ i $ を掛けて $ j-k $平面をうまく回せる条件:$ i\times j=k $ と合わせると、$ ij=k,\ ji=-k $ となって、なんと積は可換じゃなくなる! まあしょうがないか…。

角度 $\theta$ だと同様に:
\[ \eqalign{ (\cos\theta&+j\sin\theta)(w+ix+jy+kz)\\ =&(w\cos\theta-y\sin\theta)+j(w\sin\theta+y\cos\theta)\\ &+k(z\cos\theta-x\sin\theta)+i(z\sin\theta+x\cos\theta) \tag{8-2-2}\\ } \]
ん、これも別々に回っている。

●残り $ k $ を掛けると?:想定図のように $ i-j $平面を回すため、$ ki=j $ としてみよう

f:id:sgtech:20210601193844p:plain:h160
これも角度 $\theta$ だと同様に:
\[ \eqalign{ (\cos\theta&+k\sin\theta)(w+ix+jy+kz)\\ =&(w\cos\theta-z\sin\theta)+k(w\sin\theta+z\cos\theta)\\ &+i(x\cos\theta-y\sin\theta)+j(x\sin\theta+y\cos\theta) \tag{8-2-3}\\ } \]

●とりあえず分かったこと

虚数単位 $ i,j,k $ に対して積を $ ij=k, ji=-k, jk=i, kj=-i, ki=j, ik=-j $ として $ w+ix+jy+kz $ に左から $ \cos\theta+i\sin\theta $ を掛けると、$ 1-i $平面, $ j-k$平面が同時に $ \theta $ 回転 する。$ j,k $ で回しても同様。でもこのままだと$ 1-i $平面で余計な回転が発生し、最終的に実現したい純粋な 3次元の回転を切り出せない。何かうまい方法はないのだろうか?

つまりこうなって欲しい
\begin{eqnarray} \left[ \begin{array}{c} w' \\ x' \\ y' \\ z' \\ \end{array} \right]=\left[ \begin{array}{cccc} 1 & 0 & 0 & 0\\ 0 & 1 & 0 & 0\\ 0 & 0 & \cos\theta & -\sin\theta\\ 0 & 0 & \sin\theta & \cos\theta\\ \end{array} \right] \left[ \begin{array}{c} w \\ x \\ y \\ z \\ \end{array} \right] \end{eqnarray}


●そういえば非可換だった*7

非可換なので、右から掛けたらどうなる?
右から $ i $ を掛けた場合:
f:id:sgtech:20210601193947p:plain:h160
なんと $ 1-i $平面は同じ向きで、$ j-k $平面は逆向きに回る!じゃあ $ -i $ だとその逆になるだろう。

右から $ -i $ を掛けた場合:
f:id:sgtech:20210601194024p:plain:h160
これなら、左から $ i $ を、右から $ (-i) $ を掛けることで $ 1-i $平面の回転だけを無くせそう。


●というわけで

左から $ i $ 右から $ -i $ を掛けた場合:
f:id:sgtech:20210601194059p:plain:h160
$ j-k $平面は2倍回りそうだけどw やってみよう。
\[ \eqalign{ (\cos\theta&+i\sin\theta)(w+ix+jy+kz)(\cos\theta-i\sin\theta)\\ =&(\cos\theta+i\sin\theta)\{(w\cos\theta+x\sin\theta)+i(-w\sin\theta+x\cos\theta)\\ &+j(y\cos\theta-z\sin\theta)+k(y\sin\theta+z\cos\theta)\}\\ =&w\cos^2\theta+x\sin\theta\cos\theta-(-w\sin^2\theta+x\sin\theta\cos\theta)\\ &+i(-w\sin\theta\cos\theta+x\cos^2\theta)+j(y\cos^2\theta-z\sin\theta\cos\theta)\\ &+k(y\sin\theta\cos\theta+z\cos^2\theta)+i(w\sin\theta\cos\theta+x\sin^2\theta)\\ &+k(y\sin\theta\cos\theta-z\sin^2\theta)-j(y\sin^2\theta+z\sin\theta\cos\theta)\\ =&w(\cos^2\theta+sin^2\theta)+ix(\cos^2\theta+\sin^2\theta)\\ &+j\{y(\cos^2\theta-\sin^2\theta)-z(2\sin\theta\cos\theta)\}\\ &+k\{y(2\sin\theta\cos\theta)+z(\cos^2\theta-\sin^2\theta)\}\\ =&w+ix+j(y\cos2\theta-z\sin2\theta)+k(y\sin2\theta+z\cos2\theta)\tag{8-2-4} } \]
最後は倍角の公式を使った。これで $ j-k $平面 だけを回せた!
めでたしめでたし。2倍回るけどw

こうなった
\begin{eqnarray} \left[ \begin{array}{c} w' \\ x' \\ y' \\ z' \\ \end{array} \right]=\left[ \begin{array}{cccc} 1 & 0 & 0 & 0\\ 0 & 1 & 0 & 0\\ 0 & 0 & \cos2\theta & -\sin2\theta\\ 0 & 0 & \sin2\theta & \cos2\theta\\ \end{array} \right] \left[ \begin{array}{c} w \\ x \\ y \\ z \\ \end{array} \right] \end{eqnarray}


・・・ハミルトン劇場 終


このあと第8講は

  • 【8-3】クォータニオン:定義と諸性質
  • 【8-4】クォータニオン:3次元回転の表現
  • 【8-5】 [▼]付録 1:一般的な4次元の回転について
  • 【8-6】付録2:成分表示における4次元内積の不変性について
  • 【8-7】 [▼A]付録 3:オイラーの公式と代数的補間式 について

と続きます・・・。

公開先

「基礎線形代数講座」は、開発技術部の技術資料一般公開先でもある、SlideShare サイトにて公開しています。

www.slideshare.net

セガでは共に技術力を高め合い研鑽していていける方を募集しています。 興味がある方は下記サイトにアクセスして下さい。

recruit.sega.jp

*1:あくまで筆者の想像(妄想)による過程であり、史実に基づいたものではありません。

*2:詳細は第5講 付録2参照

*3:くどいですが、筆者による想像(妄想)です

*4: $ 𝑖\times 𝑖𝑗=𝑖^2𝑗=−𝑗 $ ってこと

*5:運河を渡る橋に $ 𝑖^2=𝑗^2=𝑘^2=𝑖𝑗𝑘=−1 $ と刻んだとの事

*6:ちなみに 4次元では 2本の直交する基底で張られる (回転 )面を、基底を共有せずに 2面とることが できる( 3次元ではできない)。この場合 $ 1−𝑖 $平面 と $ 𝑗−𝑘 $平面 は原点のみで交わっている事に注意。

*7:ハミルトン卿ご自身は、この積の非可換性(当時初?)あまりお気に召さなかったらしい

アーケードゲームを支えるデバッグ術

ブログ読者のみなさん、はじめまして。
株式会社セガのベテランプログラマー阿部です。

このエントリーではデバッグ手法のあれこれについての体験談と、デバッグをテーマに一昨年に実施されたプログラマー向け新人研修の概要をお伝えしたいと思います。

EXE ファイルのデバッグ

同僚が作った EXE ファイルが手元にあり、あなたはこれを Windows で起動しようとしています。
起動してみたところ何も反応がなく、しかもそれは想定外のことでした。
「何コレ、動かないんだけど」とあなたが同僚に文句を伝えると、同僚はあなたに返します。
「こっちでは動いてるよ」

 

困りましたね。
あなたの手元には EXE のソースコードも無ければ、Visual Studio もありません。
こんな時、どうするのが正解でしょうか?

実はこんな状況でもやれる事がいくつかあるんです。
わたしなら プロセスのメモリダンプ を取って、同僚に渡します。

 


プロセスダンプがあれば、同僚はプログラムがどこまで進んだのかを Visual Studio で把握することができるようになるのです。
プロセスダンプの取得は ツール不要で Windows デスクトップから操作可能 なので、この方法は一番気軽に試せることでしょう。

 

f:id:sgtech:20201124210821p:plain

プロセスダンプの取得

あるいはその前に Sysinternals Suite に含まれる DebugView の出力を確認してみると、プログラムに埋め込まれた OutputDebugString() から 何らかの手掛かりが得られるかもしれません。
もし EXE ファイルと PDB ファイルが揃っていて 別の PC 開発環境があるなら、イーサネット経由でリモートデバッガをアタッチしても良いでしょう。
PDB ファイルが無いとしても 仮に EXE が .NET アセンブリなのであれば、ILSpy などの逆アセンブラーが使えるかもしれません。

 

こういう知識は「持っているかどうか」がとても重要 で、仕事の速いプログラマーほど よりたくさんの手段を自然と身に着けているような気がしています。
社内には SYS ファイル(デバイスドライバー)をデバッグできるプログラマーとかもいて、もうリスペクトしかないです。

イーサネット絡みのデバッグ

ネットワーク上のゲームサーバーと通信するクライアントプログラムを書いて、これをアーケードゲーム機で起動させたとします。
ゲームサーバーとの通信が「たまに成功しないことがある」という場合は、どうデバッグしたら良いのでしようか?

近年のアーケードゲーム機は PC アーキテクチャーをベースに設計されることも多く、セガでも Windows を搭載した機種が多数リリースされています。
コピーガードやリバースエンジニアリング防止を目的として、多くのアーケードゲーム機ではデスクトップ画面を開くことはできず、ネットワーク経由でのログインやプロセスへのアタッチもできません(外界からは ロックダウン されています)。

 

「たまに失敗」という場合は、ソースコードレビューで判明するバグがあるとは考えにくいです。
そこでわたしなら、 イーサネットを流れるイーサフレームを Wireshark でパケットキャプチャーする ことから始めてみます。

 

f:id:sgtech:20201124210834p:plain

フレームの測定


イーサネットを観測することで、最初にまず以下を見極められると期待しています。

  • ケース1: 想定通りにパケットが流れていない(送信失敗)
  • ケース2: 想定外のパケットが流れている
  • ケース3: 想定通りのパケットが流れている(送信成功)

その結果、クライアントのコードが悪いのか、OS 側スタックのネットワーク設定が悪いのか、上流のネットワークが悪いのかを絞り込める、という算段です。

 

f:id:sgtech:20201124210838p:plain

問題を切り分ける


なお 「上流のネットワークが悪い」という結果だった場合は、キャプチャーの測定範囲を変更して 問題の機器を特定 していきます。
過去には、全国ゲームセンターにあるルーターが原因ということもありました。

ルーターが IP パケットのチェックサムを再計算するときに、特定条件下で計算ミスが起こるため、
ルーターのさらに上位にあるネットワーク機器でパケットがドロップされていた

というもので、本来ならばルーターファームウェアを修正し更新版を配信することになります。

 

通信エラーだけではありません。
TCP 通信において 「スループットが足りない」という場合、ここでもパケットキャプチャーから始めるのは良い選択の1つ です。
測定結果から、次に挙げるような点検箇所がいくつか見つかることでしょう。

  • SYN パケットに時間が掛かっている
    → コネクションプールを導入するか、セッションクローズしないプロトコルを採用する
  • リクエストからレスポンスまでの間隔が圧倒的に長い
    → サーバー処理でスワップアウトやスロークエリが発生していないか確認する

周辺機器絡みのデバッグ

広く使われている キャラクター表示器 は、シリアルポートから送信されたアスキー文字や SJIS をドットマトリクスとして表示してくれます。

 

f:id:sgtech:20201124210830p:plain

キャラクター表示器(VFD)

ある日「キャラクター表示器の表示がおかしい」という報告をもらって現地確認に行くと、見慣れない文字列が確かに表示されていました。
プログラムから制御しているというのに、 プログラム内に存在しない文字列が表示されてしまうのはおかしい ですね。
この表示器を含めて、多くは RS232C という低速でレガシーなシリアルポートを使って接続しています。
RS232C 通信は物理層での冗長性に乏しいため、ひょっとすると外的要因でポートに電気的なノイズが乗ってしまい、パケットが化けてしまったのかもしれません。

 

ということで早速 RS232C を測定しました。
RS232C の測定には ロジックアナライザーという測定機器を使います 。
RS232C 接続を構成するラインをプローブすれば、各ラインの Hi/Lo をタイミングチャートとして確認できるようになります。

 

f:id:sgtech:20201124210826p:plain

研修で使用した ZEROPLUS 製 ロジックアナライザー

f:id:sgtech:20201124210842p:plain

測定結果のタイミングチャート

実際測定してみると、タイミングチャート上はプログラムからの出力がそのまま反映されており、異常な部分は見つかりませんでした(結局その後の調査で 別の原因が見付かりました)。

 

同じ手法は USB 機器にも使えます。
USB 機器の場合は USB 対応のプロトコルアナライザーを導入することもできます(実は USBPcap + Wireshark という別の選択肢もあります)。

ゲームセンターに設置されるアーケードゲームは、ゲームパッドに縛られない、多彩なユーザーインターフェースが特徴の1つになっています。
さらにユーザーインターフェースだけでなく、キャビネット上の電飾や可動部のモーターなど さまざまな周辺機器がつながっており、それらをすべてプログラムで制御しています。
そういった周辺機器としては、既製品を採用することもあれば、新規に設計することもあります。
ここにもデバッグの機会が大いにあります。

デバッグスキルブートキャンプ

ここまでいくつか紹介したように、「プログラムのデバッグに使えるもの」にはツール(ソフトウェア)だけでなく、測定機器(ハードウェア)も重要な一端を担っていることが理解いただけたかと思います。
また大学や専門学校などで 「プログラミングをマスターする機会」はあっても、「デバッグをマスターする機会」は無いのが実情 です。

わたしが所属する技術本部では、これらの背景を踏まえてプログラマー向け新人研修が実施されました。
デバッグスキルにフォーカスしたハンズオン研修、題して「デバッグスキルブートキャンプ」です。

学生時代に触れる機会が少ないであろう測定機器にも触れながら バグを正しく観測する技術 を習得し、 printf デバッグ だけでは決して成し得ない、バグの根本原因に辿り着く 貴重な体験を重視としたカリキュラム になっています。

 

開催形態は以下の通り。
他の新人研修とは異なり、新人プログラマーが実務に少し馴染んだ年末年始に開催されています。

  • ハンズオン重視: 当日フラっとやってきて学べればよい
  • 予習・宿題は原則ナシ: 「座学 20min、ハンズオン 75min」とか「座学 10min、ハンズオン 45min」とか
  • 開催時期はプロジェクト配属後6か月後から
  • 開催ペースは毎週1回、計9回(9ネタ)ほど

 

本来なら社内に広く展開して必修化した方が社員みんなの為になるのですが、測定機材の都合もあって一部組織内での開催にとどまっているのが現状のようです。
各回資料は社内公開されていますが、そのうち一冊の本に体系化されたらイイなと密かに期待しています。


f:id:sgtech:20201124210850j:plainf:id:sgtech:20201124210854j:plain

f:id:sgtech:20201124210845j:plain

 

黒子に徹する、裏方系エンジニア

デバッグの世界とデバッグスキルブートキャンプについて紹介しました。
最後にわたしが所属する技術本部について紹介します。

技術本部にはいろいろなキャリアの開発者が在籍しており、 ゲーム体験・感動体験を下支えする何か を日々開発しています。
わたし自身を例に挙げると 以下のような感じです。

  • ゲームを開発するためのライブラリを作ったり
  • コンバーターとか自動化ツールを作ったり
  • Windows Embedded を使いこなして、アーケードゲーム機向けの OS をビルドしたり
  • 開発者向けグループウェアを管理したり

近隣のデスクには ちょっと違う種類の仕事をしている人がいますね。

  • データベースとか VM をいじる人
  • 基板回路を設計する人
  • Maya 上のメッシュモデルをあれこれする人
  • ルーターとか「目新しいユーザーインターフェースデバイス」をいじめる人(w)など

千人規模の社内開発者を支える技術本部にはいろいろな仕事があって、それぞれに奥が深そうです。
そして ゲーム自体のおもしろさを追求するのとは違った立ち位置で、ゲーム周辺にある様々な問題を解決 しています。

 

わたしもゲーム開発を後押しする裏方系エンジニアに転身したことで、結果的にはいろいろなテクノロジースキルを身に着けることができました。
「開発したゲームで世界をあっと言わせる!」という部分に自信を持てなくても、「技術のことなら何でも任せて!」という自信に満ちたプログラマー/ソフトウェアエンジニアなら、セガでキャリアを積むのも悪くないと思いますよ。

ということで、現場で成長をつづけながら「縁の下の力持ち」として共に働ける仲間を求めています。

 

recruit.sega.jp


-----

©SEGA
記載されている会社名、製品名は、各社の登録商標または商標です。

 

ペルソナ5 ザ・ロイヤルの開発中、自動プレイでバグを検出してみた話

ごあいさつ

初めまして、株式会社アトラスのプログラマー埜渡です。
Tech BLOGにお邪魔させていただきます。

今回は、弊社のタイトル「ペルソナ5 ザ・ロイヤル」(P5R)の開発中に、自動プレイを実装してバグの検出を行った経緯とその結果についてのお話をさせていただきます。
ゲーム本編の実装についてのノウハウというよりは、デバッグ作業での工夫についての内容になります。

ただ、触れる内容といたしましてはP5Rのゲームの中身に関する事が多いため、未プレイの方はプレイしてから読んでいただけると、より理解が深められると思います。

p5r.jp 

自動プレイ実装のきっかけ

自分が入社した頃の一昔前のバグの検出といえば(現象発生時の記録を残すために)開発機をビデオデッキに繋ぎながらプレイをして、発見したら詳細な手順をバグシート(紙)に書いて報告をしているような方法でした。

最近では開発環境自体に録画機能が備えてあったり、バグ報告もWebベースでチケット管理したりとだいぶ環境が変わってきました。

報告方法が変わってきただけでなく、検出方法も人が何時間も粘ってプレイして出す方法から、機械的にテストできるものは自動化をするような動きに変わってきています。

弊社タイトルのP5Rは平均プレイ時間がおよそ100時間ほどとなっており、勤勉に日々の業務時間フルにプレイしても、クリアまでに3週間近くかかってしまう計算になります。

f:id:sgtech:20200918095440p:plain

そんなことも背景にあったため、なんとかして少しでもプレイして確認する時間を増やしたい、できればエンディングまで通しで確認できる仕組みを作りたいという考えから人手を介さずともゲーム本編のテストをしてくれるような自動プレイを実装しようと思い立ちました。

自動プレイを実装するにあたって

自動プレイを実装するにあたって、いくつか問題となる事がありました。

  1. 専用の作業時間を用意していなかったため、他の人に作業をお願いはできない
  2. 同様の理由で自動プレイ自体の調整・修正作業に多くの時間は費やせない

1.についてですが、例えばプランナーやデザイナーに自動プレイ用に何かを対応作業をしてほしいというお願いをしようにも、そもそもの担当箇所の実装や調整作業で手一杯なため、追加の作業はお願いできないという状況にありました。

2.についても、自分自身が日常・ダンジョンパート(プレイヤーを操作して自由に移動するパート)という担当箇所を持っていたため、自動プレイの実装をした後にプランナーやデザイナーの仕様変更に合わせた調整をするための時間が十分にあるわけではありませんでした。

 

そんな事もあり、実装する仕組みとしては

  • データ作成の時間が無いため、自動プレイのための専用データはなるべく用意しない
  • 細かい対応する時間が無いため、仕様変更や調整に対応できるような仕組みでの実装を試みる

このようなコンセプトを持って、自動プレイの実装作業を開始しました。

また、実装の目標として

  • 人手を介さずとも、ゲーム開始からエンディングまで自動でプレイできる
  • ランダム要素を増やしなるべく多くの箇所をチェックできるようにする

こちらを達成できるようなものを目指し作成を開始しました。

実装してみたもの

実装内容の説明の前にゲームのシステムを軽く説明させていただきます。

ペルソナシリーズの特徴的なシステムとして、カレンダーシステムがあります。

f:id:sgtech:20200918095455p:plain

カレンダーシステム

こちらはゲーム内1年間の日々を過ごす事でゲームが進行していく仕組みになっています。
極端な話ですと、毎日家に帰って寝るだけの自堕落な生活をしていてもエンディングへ近づく事はできます

f:id:sgtech:20200918095520p:plain

果報は寝て待つ

・・・が、流石にそれだけでゲームが進行するはずもなく、一定期間にダンジョンをクリアしてボスを倒すようなことはゲームクリアするために必要となります。
また、ただ寝るだけの生活ではバグの検出としては不十分なのでなるべく色々なイベントを発生させるようにもしたいという考えがありました。そのためには自室のベットへまっしぐら・・・ではなく様々な場所へ移動するための仕組みが必要となります。

 ここで問題となったのが、どのようにしてプレイヤーキャラを目的地に移動させてゲームを進行させていくかです。

ゲームを進行させるというのは、ダンジョンパートであればギミックを解除しボスの元までたどり着く、日常パートであればNPCに話しかけてイベントを発生させたり、バッティングセンターに通ったりすることになります。
こういったイベントをこなしていくことで、ゲームオーバーになることなく日付が進行しエンディングを迎えることができます。

次に目的地へ移動する仕組みについてですが、真っ先に思いたものは人がプレイしたデータをリプレイまたはそのような操作をツール上で指定するといったものでした。
ただ、今回は先の「データ作成の時間が無いため、自動プレイのための専用データはなるべく用意しない」という事情もあり、実装することはできませんでした。

そのため専用データを必要としない、ルールベースの移動システムを実装することにしました。

ルールベースの実装基本方針として、付近のイベントヒットを探索し起動するという仕組みを実装しました。

ここでいうイベントヒットとは、ゲーム中アクセスすることでイベントが発生するような範囲のことを指します。

f:id:sgtech:20200918095444p:plain

イベントヒット例
  • NPCとのTalkヒット
  • 宝箱や扉のCheckヒット
  • エリア移動を行うGotoヒット
  • …etc

こちらを目標地点として移動することで、闇雲に移動するのではなく先述のゲームを進行させるイベントを発生するために移動することができます。

本実装ではプレイヤーキャラクターの前方範囲を中心に、直線距離で障害物に阻まれることなくたどり着けるものをランダムで検索しそちらを目標地点として移動させました。(画面写真プレイヤー前方の扇形範囲)

f:id:sgtech:20200918095449p:plain

イベントヒット探索

ただ、こちらだけでは付近にイベントヒットがない場合には移動に困ったためもう一つのルールを実装しました。

 もう一つのルールはヒートマップ(時限制の徘徊履歴)になります。(画面写真の赤いラインのブロック)

f:id:sgtech:20200918095500p:plain

ヒートマップ

歩き回ったプレイヤーの周囲(本作では100cm立方のブロック)に時間経過でクリアされる徘徊履歴をつけることで、ヒートマップがない場所=(少なくとも直近では)あるきまわっていない場所というルールができました。

こちらのルールを追加することで、イベントヒットが検索で見つからなかった場合には、付近のヒートマップが配置されていない場所(ブロック)を移動目標にすることで、未踏破部分を目指して歩き回ることができるようになりました。 

f:id:sgtech:20200918095508g:plain

自動プレイの移動例

蛇行した通路でも引っかかることなく、ヒートマップの存在しない未踏破部分へ移動し、イベントヒットを見つけた際には移動して調べる動作をしていることがわかると思います。

未踏破部分には今まで調べたことのないイベントヒットがある可能性が高く、そちらのイベントヒットにアクセスすることで、新たな未踏破エリアが増え、さらなる未踏破部分へと移動というループができ、より広く、より先の範囲を自動で移動できるようになりました。

 その他にも細かい調整はしたものの、大きくは先の2つの移動ルールでエリア内の未踏破部分を歩き回り、発見したイベントヒットを調べることができたため最終的にはダンジョンのボスまで到達することができました。

これまでの仕組みを実装したことで、日常パートではダンジョン最奥部のような目指す目的地は無いものの、同様のルールで様々なNPCや施設にアクセスするため、各種イベントを発生することができるようになりました。

ここまで実装できれば、プレイヤーキャラの移動箇所以外(バトルパートやイベントパートなど)はランダム入力でもなんとかゲームが進行ができ、最終的にはエンディングへ到達することができるようになりました

自動プレイで目的地として使用しているイベントヒットは、ゲーム内で使用するためのデータだったため追加のデータを必要とすることが(ほとんど)なく、ゲーム本編での調整による修正にも強いものとして実装することができました。

そのため開発中盤~マスターの直前あたりからは手の空いた筐体(退社時など)を利用して自動プレイを回すようにしていましたが、各種の調整作業が有ったとしても自動プレイ自体の調整は殆どせずに稼働させておくことができました。

運用した結果

今回実装した自動プレイでは、主にハングアップや進行不能となるような不具合の検出に重点を置いてチェックを行いました。

その結果として、上記のような最重要修正ランクバグの報告数のうち5%程は自動プレイで検出することができました
割合としてはちょっと少ないかなという印象かもしれませんが、こちらはバグチケットとして記録が残っているものに限っているため、報告が残っていない開発中盤時から発見できた不具合などを含めるともう少し多い割合貢献できていたと思います。

また自動プレイで検出できたバグは、人手で再現するのが難しいようなタイミングや方法でのものが多く、こちらが予想できないようなバグを発見することができたのも大きな収穫となりました。

  • バトルの特定タイミングでラッシュをすると進行不能
  • システムセーブ中にデータロードでハングアップ
  • 特定の手順とタイミングでペルソナ合体を行うとハングアップ
  • etc...

開発中盤から1台は自動プレイ用に常に稼働していた筐体がありましたが、そちらはほぼほぼ24時間フル稼働させていた結果、マスターアップ時点の累積プレイ時間は2000時間を超えるものとなっていました。(およそ250人日分の働き!!)

まとめ

今回の自動プレイの実装では、専用のデータを殆ど用意せずゲーム本編の調整があっても自動プレイの調整を行うことはあまりしないで済む方法として実装できました。

実装方法としてメリットが多いように思えるかもしれませんが、もちろんデメリットもありました。

  • ランダムでアクセスするためすべてのチェックを網羅できているわけではない
  • 同様の理由としてランダム操作が多く、複雑な条件のチェックができていない
  • キャラクターの移動効率は良くないため1周あたり300時間かかってしまった

これらは実際に運用してみて、今回の問題点・反省点と感じました。

 

今後の課題として、これらの問題を解消しより効率よく細部までのチェックを行える仕組みを考えていきたいと思っています。

 

アトラスではこのような取り組みに興味のある方を募集しています。もしご興味を持たれましたら下記サイトにアクセスしてみてください。

 

www.atlus.co.jp

 

©SEGA/©ATLUS

CEDEC 2020 セガグループによるセッション紹介!

皆さんこんにちは、毎年恒例のCEDECでのセガグループによるセッション紹介です!
株式会社セガ、第3事業部の麓です。

来月に今年はオンラインで開催されるゲーム業界最大のカンファレンス

CEDEC2020

https://cedec.cesa.or.jp/2020/

会期:2020年9月2日(水)~9月4日(金)
にセガグループ(および関連会社)から今年もいくつか登壇します!
今回で5回目となる、セガグループ関係者によるセッションと登壇者紹介に加え、ここでしか見れない講演者からのメッセージや、当日の資料からの抜粋等、紹介します。

 

デフォルメとリアルの両立を目指して ~新サクラ大戦のキャラクター作成事例~

セッション内容と講演者より

「新サクラ大戦」のキャラクター表現では、トゥーン的諧調表現とPBRのリアル質感表現の双方を混在させて使用することで、アニメ・漫画的なデフォルメ感とリアリティのある質感・存在感を両立させることを目標としていました。一見すると相反する組み合わせのようにも見えますが、適切な使いどころを分けることによって双方の良さを引き出すことを試みています。
また、複数のキャラクターデザインが混在する今作で、全体の統一感を出しつつ、元デザインの個性を活かして調整するという点についても課題の一つとなっていました。
今回はその制作手法とプロセスを紹介し、更にそこから判明した課題点を共有したいと思います。

講演者

株式会社セガ

ジャパンアジアスタジオ統括本部 第2開発2部 第1デザインセクション

デザイナー

柳瀬 遼平

09月03日(木) 11:00 〜 12:00レギュラーセッション

cedec.cesa.or.jp


スナップショット

f:id:sgtech:20200807164830p:plain

f:id:sgtech:20200807164842p:plain

f:id:sgtech:20200807164855p:plain

セッションについて一言

当セッションでは「新サクラ大戦」のキャラクターモデル表現のノウハウを紹介させて頂きます。

細かい技術の積み重ねで出来ているタイトルですので、その中で少しでも制作のヒントになる発見があれば幸いです。

よろしくお願いいたします。

「歌い出すSympathy」、PSO2のボーカルBGM制作談

セッション内容と講演者より

PSO2のBGMシステム「Sympathy」の仕組みやその使用例につきましてこれまでも講演を行ってまいりましたが、今回は各エピソードで制作した「ボーカル」を用いたBGMにつきまして制作事例をご紹介できればと思います。プロシージャルであり、インタラクティブである「ボーカル曲」は果たして作ることができるのか?そのためには作曲、編曲、作詞、レコーディングから、BGM制作ツール「MusicEditor」の改良まで、様々な要素についてチャレンジが必要でした。そのときの体験をご紹介できればと思います。

講演者

株式会社セガ

ジャパンアジアスタジオ統括本部 第2事業部 サウンドセクション

サウンドディレクター・クリエイター

小林 秀聡

09月03日(木) 11:00 〜 12:00(レギュラーセッション)

cedec.cesa.or.jp

スナップショット

f:id:sgtech:20200820152515p:plain

f:id:sgtech:20200820152511p:plain

セッションについて一言

具体的な内容は多めですが、完成までの流れを追って説明を入れることでわかりやすさを目指しました。

ご興味持って頂けましたら幸いです。

また、BGMツール「MusicEditor」を使用した実演(楽曲再生)も予定しております。

在宅勤務でスクラム!

セッション内容と講演者より

私達は、約半年前より新規プロダクトの開発を行っているスクラムチームです。
プロダクトの最初のリリースを目前に控えたある日、在宅勤務による開発を取り組む必要に迫られました。
セレモニーはどうするのか...スクラムを継続できるのか...
様々な不安がよぎりましたが、私達はスクラムを継続する選択をしました。
物理的に距離を乗り越えスクラムを継続した中での成果や気付き、そして失敗をお伝えできればと思います。

講演者

 

株式会社セガ

グローバルパブリッシング事業本部 DMS事業部 システム開発部 研究開発2課

課長/シニアエンジニア

横島 太志

09月03日(木) 18:00 〜 18:25(ショートセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200807163933j:plain

f:id:sgtech:20200807163937j:plain

セッションについて一言

在宅勤務、オフィス勤務、それぞれの在り方を模索されている方も多くいらっしゃるかと思います。

このセッションでは、どのようにリモートでスクラムを実践し、何が良く何につまずき、そしてどう改善していったのか発表させていただきます。

私たちも挑戦の最中ではありますが、皆様にとって何かのキッカケになれば幸いです。

 

「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム

セッション内容と講演者より

近年のゲーム開発におけるバグは、大規模化や開発期間の長期化によって数が増大し、内容も複雑化する傾向にあります。また、バグは見つけて修正するだけではなく、様々な作業フローが必要です。本講演では、バグのワークフローを探索・報告・選別・修正・修正確認のフェーズに分けた上で、「龍が如くスタジオ」で取り組んできた自動テストや開発環境の自動化技術を活用し、バグにまつわる作業フローを最大限自動化した全自動バグ取りシステムについて、実際に運用した「龍が如く7 光と闇の行方」での事例を交えてご紹介いたします。

講演者

株式会社セガ

第1事業部

QAエンジニア

阪上 直樹

 

開発技術部

ビルドエンジニア

粉川 貴至

09月02日(水) 18:00 〜 19:00(レギュラーセッション)

cedec.cesa.or.jp


スナップショット 

f:id:sgtech:20200818174259p:plain

f:id:sgtech:20200818174304p:plain

セッションについて一言
本講演では、手動でのバグの作業フローを整理した上で、自動化に至る過程を丁寧に説明しますので、
エンジニア以外の方にも得られる知見があると思います。
また、チケット管理システム以外に、Jenkinsやテスト自動化にも触れる予定です。
龍が如くシリーズの自動化の集大成となる講演を目指します!是非ご視聴ください!
 

ワーママ・ワーパパたちの「働き方」って改革できていますか? 4社事例から道を探ってみよう!

セッション内容と講演者より

2017年に始まったワーママ・ワーパパ(WM/WP)ラウンドテーブルから分離した、
企業規模を問わない4社合同の情報共有セッションです。以下内容を予定しています。
・各社の働き方情報共有
 (タイムテーブル実例、在宅勤務事情、男性育休の状況、勤務制度の活用状況など)
・各社WM/WPの働き方や悩みの紹介
・どうやったらより働きやすくなるかの試行錯誤状況の共有
・各社社内コミュニティの紹介や、その活動状況の共有
※例年ラウンドテーブルに続けて行われていた自費ランチ交流会は、後日改めての開催となりましたため、
 セッション内でご案内させていただきます。
※ワーキングペアレンツの働き方に関するアンケートへのご協力ありがとうございました。
 結果は本講演内でのご紹介、及び、後日Cedilの資料に掲載させていただきますのでご参照くださいませ。

講演者

株式会社セガ

ジャパンアジアスタジオ統括本部 第5事業部 第5開発2部 プログラムセクション

柳瀬 彩佳 

09月03日(木) 11:00 〜 12:00(レギュラーセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200817134258j:plain

セッションについて一言

4社の様々な働き方を紹介します。
昨年までのCEDECワーママ・ワーパパラウンドテーブルにて多く聞かれた、「子育てしながら働いていけるのか不安」「子育て中の部下のことを知りたい」という疑問への回答の1つに、また、同じく子育てしながら働く人の参考になれると嬉しいです。

 

スケジュール作成をもっと楽に!という動機から生まれた内製アプリケーション開発実例

セッション内容と講演者より

スケジュール作成アプリケーション『ScheduleCanvas』を内製で開発する中で得られた知見を共有します。

・必要な主な機能をピックアップし、何が重要だったかを説明。

・ツールの運用と開発を同時進行するためのノウハウ。

・アンケート結果と要望をまとめ、対応策やユーザー傾向を俯瞰。

・アプリケーション実装からガントチャート描画に関して

このツールはSEGA Techblogでも紹介していますが、ブログの内容を掘り下げて紹介します。

講演者

株式会社セガ

第3事業部 第3開発2部 テクニカルサポートセクション

テクニカルアーティスト:マネージャー

麓 一博

テクニカルアーティスト

清水 宣寿

09月03日(木) 13:30 〜 13:55(ショートセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200805141352p:plain

f:id:sgtech:20200805141356p:plain

セッションについて一言

今回ご用意したセッションは『ScheduleCanvas』の紹介だけではなく、内製ツールを開発するためにどういった対応が必要なのかを実体験を元にまとめて発表させていただきます。皆様が内製ツールを開発する時にちらっと思い出していただけるような、そんなセッションになることを目指しています。よろしくお願い致します。

 

Technical Artist Bootcamp 2020 :「ToolDev for TA」

セッション内容と講演者より

前半:今野「新卒からのTA推移」

「TAはベテランのアーティストやアートへの造詣が深いプログラマがなるもの」

この言葉は僕がTAになるにあたって何度も聞かされた言葉です。本当にそうでしょうか。

求めるTA像によりますが、決してそんなことはなく、むしろ経験の量に限らず技術面の知識はアーティストの武器になることを、実例を併せて紹介させていただきたいと思います。

後半:清水「TAブートキャンプ ツールのGUIを作ろう」

本セッションでは、C#とWindows Formsを使用してのツールのGUIの作り方を1から紹介します。

Visual Studio上でのプロジェクト作成からシンプルなGUIを作成し、任意の処理を動かすところまでの流れを解説します。

また、ツールにあって当然の機能として求められる「ドラッグ&ドロップ対応」「設定の保存」「プログレスバー実装」の実装方法の一例を紹介します。

講演者

株式会社セガ

第3事業部 第3開発2部 テクニカルサポートセクション

テクニカルアーティスト:マネージャー

麓 一博

テクニカルアーティスト

清水 宣寿 

09月04日(金) 09:45 〜 10:45(レギュラーセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200820093931p:plain

f:id:sgtech:20200820093925p:plain

f:id:sgtech:20200820093937j:plain

セッションについて一言

テクニカルアーティストに必要なスキルをブートキャンプ(基礎訓練)と言う形で学び、日々の業務に活かしていこうという趣旨のセッションにて、今回は清水からツールの作り方を基本的なところからを1セッションの半分の時間を使って解説します。
この講演でTAも皆簡単なツールは作れるようになって開発環境をどんどん効率化していきましょう。よろしくお願い致します。

 

技術同人作家になろう ~働き方改革時代におけるエンジニアのレベルアップの一例~

セッション内容と講演者より

近年、「技術同人誌」がIT業界を中心として劇的な盛り上がりを見せています。

「技術同人誌」は、IT技術だけに留まらず、科学や数学、工学系分野等非常に広範な技術内容を取り扱う同人誌の総称です。

このセッションでは、「元々blogで積極的に情報を発信していたエンジニア」と「プライベートでは全く技術情報を発信してこなかったエンジニア」の二人が、それぞれの視点から「技術同人誌」の執筆を通じて得られたものについて紹介します。

「技術同人誌」とblog・勉強会での講演・商業誌等の他の情報発信手段の比較についても実例を元に解説します。

また、ゲームエンジニアが「技術同人誌」を書くことで技術以外の視野が広がり、より広い意味でのレベルアップを果たすことができる点についても紹介します。

講演者

株式会社セガ

エンジニア

竹原 涼

山田 英伸

09月03日(木) 18:30 〜 18:55(ショートセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200817131827p:plain

f:id:sgtech:20200817131834p:plain

f:id:sgtech:20200817131843p:plain

セッションについて

「技術同人誌」という言葉を聞いたことはありますか?
「同人誌」なら聞いたことはあるけど「技術同人誌」って何だろう?と思う人の方が多いかもしれません
当講演では、この「技術同人誌」を通じて、私達がエンジニアとしてレベルアップした事例を共有します
気楽な形で聞ける内容にしようと思ってますので、「技術同人誌」って何だろうという方から、エンジニアとして行き詰まりを感じている方まで、お気軽にご視聴ください
そして、当講演を切っ掛けにゲーム業界にも「技術同人誌」が広がると嬉しく思います


・当講演は副業活動の一環です
・講演内容は個人の意見であり、株式会社セガの公式見解を示すものではありません

 

リギング・クロスオーバー ~ゲームと映像、それぞれのリグ制作事例

講演者

マーザ・アニメーションプラネット株式会社

デジタル本部 映像制作課

ショットワークチーム マネージャー

赤木 達也

09月02日(水) 18:00 〜 19:00(レギュラーセッション)

cedec.cesa.or.jp

 

今回紹介したセッションで聴講したい!と思ったセッションはありましたか?
多くのゲーム開発者から注目が集まるCEDECは、今年はオンラインで 9月2日(水)~9月4日(金)の間、開催されます。

CEDECに聴講して情報収集や交流をし、ゲーム業界の今を知り、業界の未来について語り合いませんか?
それでは皆さんCEDECでお会いましょう!

 

私達は将来CEDECに登壇してみたいと思っている、技術に興味のある方を求めています。
そんな貴方、以下にアクセスしてみませんか?

recruit.sega.jp

 

※複数社登壇の場合でもセガの社員のみ表記しています 
©SEGA

『D×2 真・女神転生リベレーション』でのビッグバナー画像制作事例

はじめまして。セガ 第4事業部・第4開発1部・TAセクションの村上です。

アーケード向けのゲーム開発におよそ10年間携わった後、現在ではスマートフォン用ゲーム『D×2 真・女神転生リベレーション』(以下、『D×2(ディーツー)』)に3D背景チームリーダー兼テクニカルアーティストとして参加しています。

『D×2』の3D背景制作に携わる一方で、制作工程における技術的なサポートも行っています。 

 

『D×2』は悪魔召喚・交渉・悪魔合体・3Dダンジョンなど『真・女神転生』シリーズが持つ醍醐味を踏襲しつつ、スマートフォン向けとして最適化された戦略バトルRPGです。

2.5周年を記念した「超・感謝祭」キャンペーンとイベントを開催中ですので、ご興味がありましたら公式サイトをご覧ください。

d2-megaten-l.sega.jp

 

『真・女神転生』シリーズとは皆様ご存知の通りアトラスさんが開発・販売されている25年以上の歴史を誇る「荒廃し、悪魔が跋扈する現実世界を舞台としたRPGシリーズ」です。

「メガテン」の愛称のほうが馴染み深いかもしれませんね。弊社の家庭用ゲーム機でもいくつものタイトルが発売されてきました。

 

つい最近「ゲームギア」が発売30周年になることを記念したミクロサイズの「ゲームギアミクロ」が発表されました。

全4色のうちの「レッド」には、なんと『女神転生外伝 ラストバイブル』と『女神転生外伝 ラストバイブルスペシャル』が同梱されます。

今まで上記タイトルをプレイする機会に恵まれなかったため、個人的に発売が待ち遠しいです!

60th.sega.com

 

さて少し時間を戻した2020年2月。『D×2』のファンミーティングが有楽町にて開催されました。

新型コロナウイルス対策にスタッフ一同細心の注意を払った上で、ご応募をいただいた皆様の中から抽選により約100名様にご来場いただきました。

app.famitsu.com

game.watch.impress.co.jp

 

当日会場にサービス2周年記念悪魔である英雄 マサカドと天魔 アスラおうを撮影できるビッグバナー(フォトスポット)をご用意したところ、ファンの皆様には大盛況でした。

この画像の制作工程を紹介したいとの依頼を受けまして、本記事では要点を絞り2部構成にしてお届けします。

前半

  • 画像の拡大変換ツールwaifu2x-caffeの使い方
  • waifu2x-caffeとAdobe Senseiの拡大性能を比較検証

後半

  • 拡大前の元素材画像のメイキング(UnityでのキャプチャーからPhotoshopでのレタッチまで紹介)

 

うーん、少し地味ですかね。知っていてもすぐに役立たない情報もあるかもしれません。

例えるなら弊社「メガドライブミニ」のヘッドホンボリュームは動かせますが、本体の音量は変わらないんです、ぐらい地味な話もあるかもしれません。

faq.sega.jp

 

それでもお1人でも役に立ったと言っていただけるように、作業効率が変わりそうなコツを取り揃えてみました!

前置きはほどほどに、地味~にお付き合いください。

 

 

フォトスポットってなに?

巨大なビッグバナーの前で撮影する場所

当日は『真・女神転生』シリーズの人気悪魔と一緒にファンミーティングの楽しい思い出を残せるフォトスポットができました。このフォトスポットに設置されている巨大な写真のことをビッグバナーと呼びます(スマートフォンでさっと撮影した写真で失礼いたします)。

f:id:sgtech:20200723200211p:plain

英雄 マサカド

f:id:sgtech:20200723200204p:plain

天魔 アスラおう

ビッグバナーの解像度はいくつなのか?

高さ2m、横幅4m

「えっ? 高さ2m? 横は4mもあるの!?」

最初にビッグバナーの大きさを聞いた時はビックリしました。

会場で見た実物は床から天井まで届く、文字通り「ビッグバナー」でした

 
ビッグバナーのスペック
  • 2m x 4m(高さ x 横幅)
  • 布地に印刷 ※ベルクロ(マジックテープ)で箱に貼り付け
  • 入稿はIllustratorフォーマット

 

「画像解像度いくつだろう・・・」と不安が頭をよぎりましたが、問題なく作業するには8K~16K解像度が限界ではないか?と予想しました。

※8K=7,680×4,320ピクセル

※16K=15,360 x 8,460ピクセル

 

印刷の密度表現としてはdpiが一般的ですが、ここではピクセルで考えてみます。

タイミング良くPhotoshopを起動していたので、数値入力欄で計算してみましょう。

f:id:sgtech:20200723200002g:plain

Photoshopの入力欄で数値の計算

例えば横幅を16,000ピクセルで作るとします。

横幅1m辺り約4,000ピクセル、横幅1mmだと約4ピクセルの面積となるでしょうか。

 

撮影対象となる悪魔モデルはビッグバナー画像の中央に大写しに立たせることになっていますので、撮影時のカメラまでの距離を考えるとなんとかなりそうです。

「きっと16Kでも大丈夫!」と自分を納得させることにしました・・・(ドキドキ)。

 

出力する画像解像度は16K

少し適当に決めた解像度に聞こえてしまいますが、それにしても16K・・・本当に大きいです。

拡大しても、拡大してもピクセルが見えない!

ちょっと大げさですが、普段はスマートフォン向けゲーム開発をしているだけにこんな気持ちになりました。

後でdpiを計算すると約100dpiでした。※一般的な印刷物は300〜400dpi。

 

PC用モニターは標準で72dpiなので、標準的なPC用モニターよりは細かくできました(Retinaディスプレイは除く)。16K解像度は結構妥当だったようです。

 

制作する画像解像度は8K

私の普段の業務は『D×2』の3D背景制作と技術サポートです。開発業務と平行してのビッグバナー制作のため、入稿締め切りギリギリのスケジュールでした。

『D×2』はアトラスさんの監修を経てリリースされていますので、監修に必要な営業日と修正にかかる時間も考慮する必要があります。
 
スピーディーなワークフローが求められるため「制作自体は8K解像度で作業し、入稿直前に16K解像度に拡大変換する」方法を選択しました。 
 
印刷される画像解像度を最終的に2倍に拡大することができれば、レタッチ面積を節約できるだろうと考えました。
また作業するPSDファイルサイズは8K解像度で経験上1GB~2GBになります。16K解像度で作業するよりも軽くできますね。
 

拡大変換ってなに?

例えばPhotoshopで画像の解像度を2倍に拡大してみます。おそらく拡大する前よりもボヤ~っとしていませんか?
 
数年前まではPhotoshopで拡大してもそれほど良い結果は得られませんでした。それはバイキュービック法やバイリニア法という簡単な補完方法による変換だったからです。
 
でも当時はそれが当たり前でした。
 
――――当たり前だったのですが、ここ数年のAdobe社の画像テクノロジーへの取り組みは目覚ましく、ついにはAdobe Senseiという新技術が生まれました。
 
現在はPhotoshopでもAIと機械学習によるキレイな拡大変換が可能となっています。
※拡大変換=アップスケーリングとも呼ばれます。
 
AI/機械学習による拡大変換は、縮小画像と解像度の高い元画像のペア(教師データ)を大量に学習した成果を生かして、ただ引き延ばすのではなく、不足情報を補っています。
 
機械学習の説明は、こちらの記事が大変参考になりました。

 

入稿前に拡大変換

waifu2x-caffeとは?

それではビッグバナー制作においては、どのように画像を拡大させたのでしょうか?
 
この流れだとAdobe Senseiを――――Photoshopを使う流れに見えますが・・・違うんです。
これからご紹介するツールwaifu2x-caffeを使用すると簡単に、かつキレイに拡大変換できます!
waifu2x-caffe
  • 画像変換ソフトウェア「waifu2x」のWindows用ツール
  • 「waifu2x」の変換機能のみをCaffeを用いて書き直した

「オレの嫁ね!」と、愛称で呼ばれて既に利用されている方もいらっしゃるかと思います。最近だとスマートフォン向けアプリにリリースされていたり、市販の画像最適化ツールにも搭載されていますね。

 

ゲーム開発の立場で考えると、Windows上で実行できるスタンドアローンツールというのが大変に嬉しいです(外部サーバーに開発データをアップロードするのは問題ありますから)。

 

この素敵なツールは下記からダウンロードして使うことができます。

github.com

 

waifu2x-caffeのダウンロードからインストールまで

Windowsへのインストールもとっても簡単です。

インストール方法
  1. lltcggie/waifu2x-caffeのダウンロードページを開きます。
  2. waifu2x-caffe.zipをクリックして保存します。 ※最新版を選びます

    f:id:sgtech:20200723203707p:plain

  3. ダウンロードしたZIPファイルを右クリック→「すべて展開」します。
  4. waifu2x-caffeフォルダ内のwaifu2x-caffe.exeを実行します。
    ※今回はGUI版を使用しますが、コマンドライン版も用意されています(waifu2x-caffe-cui.exe)。

    f:id:sgtech:20200723203710p:plain

  5. 「WindowsによってPCが保護されました」と警告が表示される場合は、「詳細情報」をクリックすると「実行」ボタンが押せるようになります。

    f:id:sgtech:20200723203715p:plain

  6. ウインドウが立ち上がったら、「cuDNNチェック」ボタンを押します。
    特にエラーがなければ、準備完了です。

    f:id:sgtech:20200723203727p:plain

 cuDNNについて

  • GPUを使って変換を行う(※Compute Capability 3.0 以上のNVIDIA製GPU)
  • 高速に画像変換できる
  • VRAM使用量を減らせる
以前のバージョンでは別途NVIDIAのサイトからdllをダウンロードする必要がありましたが、ver 1.2.0.3より同梱されることになりました。とっても便利になりましたね。

 

エラーが出たら?

もし「cuDNNチェック」で「GPUで変換できません」等のエラーが出た場合は、通常は指示に従いますが、ここではCPU変換にすることで解決してみます。

  1. 動作設定」ボタンを押します。

    f:id:sgtech:20200723203722p:plain

  2. 「使用プロセッサー」を「CPU」へ変更します。
    ※CPUは変換時間が遅くなりますが、確実に動作します。

    f:id:sgtech:20200723203719p:plain

 

便利なカスタマイズ

同じ「動作設定」にある「入力参照時固定フォルダ」 で入力パスを設定できます。起動のたびにデフォルトフォルダから変更するのが面倒になったら、カスタマイズしてみましょう。

f:id:sgtech:20200723203943p:plain

「入力参照時固定フォルダ」で入力パスをカスタマイズ

 

waifu2x-caffeの使い方

設定のポイントは2つだけ

詳しい使い方はフォルダ内の「README」ファイルを読んでいただくとして、今回のビッグバナー制作における設定をご紹介します。

f:id:sgtech:20200723203733p:plain

『D×2』ビッグバナー画像の変換設定

使い方

  1. 入力パスの「参照」ボタンを押して、変換する画像を選択します。
    ※出力パスは自動で設定されます。
  2. 「変換モード」はそのままにします。※「ノイズ除去と拡大」
  3. ノイズ除去レベル」を選びます。※今回は「レベル2」
  4. 「拡大サイズ」を選びます。
  5. モデル」を選びます。※今回は「写真・アニメ(UpPhotoモデル)」
  6. 「実行」ボタンを選んで、変換開始です。 

    f:id:sgtech:20200723203738p:plain

 

このように数クリックで変換できてしまうこともwaifu2x-caffeの魅力ですね。

「実行」ボタンを押してしばらく待つと拡大された画像が作成されます。8Kから16K解像度への拡大もGPU変換なら短い時間で終了します。

 

ノイズ除去レベル

ノイズの具合が、質感に大きく影響している印象があります。ここはしっかり設定したほうが良いですね。

まずは「レベル1」を選んで一度変換し、結果を確認することをオススメします。

「レベル1」の結果を見た上で
  • 質感が失われ過ぎていれば「レベル0」で変換する。
  • ノイズが強ければ「レベル2」で変換する。

適切なレベルを設定することで、さらに良い結果を得られると思います。

 

モデル

ビッグバナー画像では「写真・アニメ(UpPhotoモデル)」を選んでいます。
※「写真・アニメ(Photoモデル)」より高速かつ同等以上の画質で変換できます。

アニメやイラスト系の画像では「2次元イラスト」モデルを選びますが、目的に合わせて「UpRGBモデル」「Yモデル」など最適なモデルを選べると良いですね。

 

結局どれくらいキレイになるの?

「オレの嫁(waifu2x-caffe)」と「アドビ先生(Adobe Sensei)」を比較

ところでどれくらいキレイに拡大変換できるのか、気になりませんか?

そこでwaifu2x-caffeとAdobe Senseiをビッグバナー画像を使って比較してみました。いったいどちらの拡大変換がよりキレイな画像になるのでしょうか? 私も楽しみになってきました。

 Adobe Sensei (Photoshop)
  • 人工知能(AI)とマシンラーニング(機械学習)
  • 「イメージ」→「画像解像度」のダイアログにある再サンプルから「ディテールを保持 2.0」を選ぶ
    ※Photoshop CC 2018からの新機能

 

waifu2x-caffeとAdobe Senseiの検証

ベース画像(8K解像度)はそのままの大きさ、100%表示です。

比較画像(16K解像度)は見やすくするため実際よりも200%拡大表示しています。

それでは英雄 マサカドの口元から比較してみましょう。 

ベース画像

f:id:sgtech:20200723200040p:plain

100%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減0%)

f:id:sgtech:20200723200044p:plain

化粧の質感は残っているが、エッジ処理に問題があり

200%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減50%)

f:id:sgtech:20200723200049p:plain

エッジはスムーズ、化粧の質感はノッペリ

200%表示

waifu2x-caffe

写真・アニメ
(UpPhotoモデル)

ノイズ除去レベル2

f:id:sgtech:20200723200052p:plain

化粧の質感を保ちつつ、エッジをスムーズにするバランスが良い

200%表示

waifu2x-caffeの結果が一番良いですね。Adobe Senseiの挽回なるか?

次は天魔 アスラおうの鎧装飾を比較してみましょう。

ベース画像

f:id:sgtech:20200723200008p:plain

100%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減0%)

f:id:sgtech:20200723200012p:plain

四角いドットが残ったまま

200%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減50%)

f:id:sgtech:20200723200016p:plain

エッジはスムーズ、質感は若干失われた

200%表示

waifu2x-caffe

写真・アニメ
(UpPhotoモデル)

ノイズ除去レベル2

f:id:sgtech:20200723200019p:plain

エッジはスムーズ、質感も問題なし

200%表示

ここでもwaifu2x-caffeの結果が一番妥当ですね。Adobe Sensei頑張って!

 

最後は天魔 アスラおうの背景です。段差のエッジとピンク色の背景との境界を比較してみましょう。

ベース画像

f:id:sgtech:20200723200023p:plain

100%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減0%)

f:id:sgtech:20200723200028p:plain

エッジの輪郭がにじむ

200%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減50%)

f:id:sgtech:20200723200031p:plain

エッジのにじみは改善、あと一歩

200%表示

waifu2x-caffe

写真・アニメ
(UpPhotoモデル)

ノイズ除去レベル2

f:id:sgtech:20200723200036p:plain

エッジのにじみが一番抑えられている

200%表示

最後もwaifu2x-caffeの結果が一番でした。

 

以上で「口元」「鎧装飾」「背景」の3つの比較が終了しましたが、ビッグバナー画像を元に検証した拡大性能に関しては「オレの嫁」――――waifu2x-caffeとの相性が良い結果となりましたね!

※検証を行ったバージョン:waifu2x-caffe (1.1.8.3)、Adobe Sensei (Photoshop CC 2019)

 

上記検証ではwaifu2x-caffe一択ですが、Adobe Senseiの「ディテールを保持 2.0」が活かせるケースもあります。

例えば「テクスチャーデータを簡単に拡大できる」ところですね。数世代前のゲームを移植する際にテクスチャーがHD化されていないこともあります。

この機能をバッチ処理することで、テクスチャーのHD化を低コストで量産できるかもしれません(弊社内で事例があると聞きました)。

 

「ディテールを保持 2.0」が使えない場合は?

f:id:sgtech:20200723204004p:plain

おかしいぞ? 本来はここにあるはずなのに、選べない場合は・・・

f:id:sgtech:20200723203959p:plain

「ディテールを保持 2.0 アップスケールを有効にする」をオン

(Photoshop CC2018以降であれば)環境設定→「テクノロジープレビュー」の「ディテールを保持 2.0 アップスケールを有効にする」をオンにします。

 

前半まとめ

というわけで前半はビッグバナーの解像度、拡大変換ツールwaifu2x-caffeの紹介、Adobe Senseiとの比較を行いました。ここからは画像を拡大変換する前の「元素材ができあがるまで」のメイキングについてご紹介していきます。

 

メイキング:拡大前の元素材の作成手法

全体のワークフロー

それでは全体の工程を確認していきましょう。 1~5までの工程がありますが、このメイキングでは「1. Unity~」と「2. Photoshop~」にフォーカスした内容となります。

ビッグバナー制作全体ワークフロー 

f:id:sgtech:20200723200218p:plain

  1. Unityでキャプチャーする
    ・8K解像度
  2. Photoshopで作業をする
    ・合成
    ・レタッチ
  3. waifu2x-caffeで画像を拡大する
    ・8K→16Kに拡大変換
  4. Photoshopで入稿用画像を作成する
    ・RGB→CMYK変換
    ・色調補正
  5. Illustratorで入稿データを作成する
    ・印刷業者側から提供されたテンプレートファイルに入稿用画像を読み込む
    ・側面デザインや権利表記等などIllustrator上の作業を行う
 

まずはUnityから

Unityのキャプチャー環境

『D×2』はUnityをゲームエンジンとして採用し、開発が行われています。

悪魔モデルと背景シーンは3Dで作成されているため、Unityでカメラを作成することで色々な角度から悪魔モデルと背景シーンをキャプチャーすることができます。

 

用意するデータは

  1. 悪魔モデル
  2. バトルステージ用の背景シーン ※ゲーム中にロードされる
  3. キャプチャー用のシーン ※ゲームには含まれない

です。

シーン内にどのデータが入っているのかは、リストにして下記にまとめました。

背景シーン(バトルステージ用)

  • 背景モデル
  • (背景内の)バトル開始位置
  • バトル開始位置に付随するフォグやライト等の環境設定
  • 悪魔モデルの質感調整等パラメーター


 
キャプチャー用シーン

  • 悪魔モデル
  • キャプチャー用バトル開始位置
  • キャプチャー用カメラ
  • キャプチャー用ライト

 

シーン内のバトル開始位置と連動して背景環境を変更させる仕組みとなっています。そのため同じ背景シーンでも、バトル開始位置によってはガラリと雰囲気が変化します。

f:id:sgtech:20200723200426g:plain

バトル開始位置を切り替えるとシーンの雰囲気や見た目も変わる

この仕組みを流用してキャプチャーのためのカメラのポジションやライティング環境を作り、キャプチャー用シーン内に保存しています。

マメなセーブデータが大切だ!ということを『真・女神転生』シリーズのザコ敵に全滅させられた経験から学んでいますので、うっかりミスで「あの背景をキャプチャーし忘れた!」と問題が発生しても、すぐ同じ環境を復帰できるように備えています(ああ、当時のトラウマが・・・)。

 

キャプチャー

キャプチャー用カメラのベースはバトル時のカメラと同じなのですが、画面をキャプチャーするコンポーネント(スクリプト)がアタッチされています。

画面のキャプチャーはフリーツールが多数ありますが、『D×2』では独自の描画方式を用いているのでフリーツールや標準機能では正しくキャプチャーできません。そのためキャプチャーツールは独自実装となっています。

 

カメラの背景色ですが「Background」をPhotoshopで抜きやすい色に変更しているだけです・・・横着ですね。背景エフェクトをキャプチャーする場合は「Background」を黒色でキャプチャーしています。

f:id:sgtech:20200723203647p:plain

「Background」カラーを抜きやすい色に変更

 

動きのあるポーズはTimeline機能を使う

特定のポーズでキャプチャーしたい場合では、Timeline機能を使っています。

※Timeline機能=シネマティクスやカットシーンを作ることができる

f:id:sgtech:20200723203953p:plain

Timelineを利用したキャプチャー

Timeline機能を使うとライティング、パーティクルエフェクト発動のタイミングも自由に組み合わせることができます。

「再生開始から◯◯フレーム目のアニメーション」をキャプチャーすることで、同じポーズとカメラアングルを再現しています。 

 

猛将 マサカドのレタッチ画像の制作では、「カメラ」「猛将 マサカドのモデル」「攻撃のアニメーション」をTimeline機能で読み込んでキャプチャーしました。この猛将 マサカドの攻撃アニメーションは何度見ても迫力があってカッコイイですね!

f:id:sgtech:20200723200224p:plain

猛将 マサカド「マサカドチャレンジ」 ※クリックすると大きい画像で表示

 

撮影舞台の紹介

英雄 マサカドのビッグバナー撮影の舞台は専用の「チャレンジクエスト」ステージ(いわゆるボス戦)です。

海上の歌舞伎舞台をイメージしていて、奥には三重塔が英雄 マサカドを見守るように佇んでいます。

f:id:sgtech:20200723200153p:plain

英雄 マサカド専用の「チャレンジクエスト」ステージ

『真・女神転生Ⅲ-NOCTURNE』にマサカド公が登場する場面がありますが、アトラスさんからの提案により篝火と鳥居の要素をオマージュとして取り入れています。

 

ここからはPhotoshop

レタッチの方向性は?

Photoshop上にて、以下のように作業を進めていきます。

背景
  1. 空、遠景、近景、エフェクトの合成
  2. レタッチ
  3. 色調補正
キャラクター
  1. 影とライティングの合成
  2. レタッチ
  3. 色調補正

 

英雄 マサカドは「格式の高さ」、そして天魔 アスラおうは「壮麗さ」をキーワードとして写真に収めた際に格好よく見えるような、写真映えするような方向性となっています。

 

記事ボリュームの都合上、ここでは英雄 マサカドのレタッチ工程を中心に進めていきます。

まずはゲーム画面の背景だけのスクリーンショットを確認してみましょう。

f:id:sgtech:20200723200158p:plain

ゲーム画面の背景スクリーンショット(参考用)

ゲーム中は迫力ある背景だと思ったのですが、スマートフォンのカメラで撮影するにはやや物足りないですね。

 

空を高解像度化

屋外の背景で空が見えているようであれば、空から作業を始めます。

画像全体のトーンを空を見ながら決めやすいですし、光がどのように射し込むかイメージできます。

また、単純に絵としてのクオリティーが上がりやすい印象もあります。

実は空の元画像素材は8K解像度には足りていませんでした。

先程Photoshopでの作業と書きましたが、この空だけは先にwaifu2x-caffeを使って4倍に拡大します。

f:id:sgtech:20200723204013p:plain

異なるノイズ除去レベルで4倍拡大した画像を2枚用意

変換してみるとノイズ除去レベル2ではノイズが残り過ぎ、3だと完全にノッペリしていましたので、この2枚を合成して画質をコントロールすることにしました。

 

もし元画像の地平線が傾いていれば「切り抜きツール」の「画像上に線を引いて画像を角度補正」を使います。

f:id:sgtech:20200723203619p:plain

余白を自動的に補正する設定

自動で傾きを修正してくれるので便利ですね。

f:id:sgtech:20200723203623p:plain

「画像上に線を引いて画像を角度補正」で水平線に沿って線を引く

この時に「切り抜いたピクセルを削除」オフ、「コンテンツに応じる」オンに設定します。

本来であれば傾きを修正すると空白が生まれてしまいますが、Photoshopがいい感じに埋めてくれます。

ポイントになるのは「コンテンツに応じる」という機能です。

 

こうして拡大された空をレイヤーマスクを使ってゲーム中の空に合成していきます。

f:id:sgtech:20200723200057p:plain

ゲーム中の空

f:id:sgtech:20200723200101p:plain

合成した空

空を変えただけですが、ずいぶんと雰囲気が変わります。

 

遠景と画像の切り抜き

ここからは三重塔と橋を合成していきます。

三重塔の画像をPhotoshopで読み込み、塔の形状で抜く作業をしていきます。

f:id:sgtech:20200723203703p:plain

選択範囲から「色域指定」

 

選択範囲メニューから「色域指定」を選んで、抜きたい色を削除するのが一番簡単な方法ですが、フチに1ピクセルほど微妙に色が残る場合がありますので注意が必要です。

f:id:sgtech:20200723203654p:plain

フチに色が残ったケース(極端な例)

f:id:sgtech:20200723203650p:plain

フリンジ削除でフチを削除

レイヤーメニューから「マッティング」→「フリンジ削除」で1ピクセル削ってしまうと安心です。

 

背景だと上記で大抵は問題ないのですが、木々のある背景や複雑な形状のキャラクターでは繰り返し調整可能な「レイヤーマスク」を使う方がより良い結果を得られます。

選択レイヤーに「レイヤーマスク」を追加し、マスクの「属性」にある「色域指定」を使います(「反転ボタン」を押すと選択を逆転できます)。

f:id:sgtech:20200723203658p:plain

レイヤーマスク「属性」の「色域指定」と「選択とマスク」

次に「選択とマスク」を使いながらエッジの処理を調整することができます。※以前のバージョンでは「マスクの境界線」

f:id:sgtech:20200723203743p:plain

「選択とマスク」を使用してエッジを微調整

 

空気感の演出として、レイヤースタイルや修正を加えていきます。

「カラーオーバーレイ」は空気感を演出できる便利な機能ですね。

f:id:sgtech:20200723200318p:plain

三重塔を追加

f:id:sgtech:20200723204034p:plain

レイヤースタイルの「カラーオーバーレイ」を選んで、三重塔に空気感を追加

f:id:sgtech:20200723200323p:plain

フォグと橋を追加して遠景の完成

ゲームからキャプチャーした素材だけでは足りなかったので、雲ブラシでフォグを描き足しました。

 

近景と水面反射

歌舞伎舞台、鳥居を合成していきます。

遠景のレタッチによって鳥居のシルエットがハッキリしました。この状態であればキャラクターを追加しても背景に埋没する心配はいらなさそうです。

f:id:sgtech:20200723200328p:plain

歌舞伎舞台と鳥居を追加

8K解像度ではライトマップの精度が荒い箇所がいくつも見つかりました。またアンビエント・オクルージョンも物足りないと感じたため、地味な作業ですが修正します。

 

歌舞伎舞台中央には水面があります。映り込むと美しさが増しますので、三重塔と空の水面反射を追加していきます。

レイヤーを選択して、フィルターメニューから「スマートフィルター用に変換」します。これでフィルター効果を何度でも修正できるようになりました。

f:id:sgtech:20200723203630p:plain

フィルター→「スマートフィルター用に変換」

 

編集の「自由変形」→「垂直方向に反転」で上下反転させますが、若干タテに伸びるように変形させた後に、フィルター→「ぼかし」→「ぼかし(移動)」を実行します。ぼかし表現をタテ方向(90度)に加えていきます(「距離」はケースバイケースで調整します)。

f:id:sgtech:20200723203626p:plain

フィルター→「ぼかし」→「ぼかし(移動)」で90度のぼかし

f:id:sgtech:20200723203441p:plain

水面反射として三重塔を追加

水面への映り込みは若干暗くなるように「トーンカーブ」で暗めに調整します。

 

次に空の反射を追加しますが、水面がツルッとしてしまいました。

f:id:sgtech:20200723203445p:plain

空の反射も追加

 

手っ取り早く調整する方法として、レイヤースタイルの「ブレンド条件」を使っていきます。

下になっているレイヤー」のスライダーを左右に動かして、ピクセルの明るさを基準にしながら、選択中のレイヤーより下になっているレイヤーを合成します。

f:id:sgtech:20200723203450g:plain

「ブレンド条件」で明るい部分だけの反射を残す

このままだと合成が荒いままなので、一度「Alt(Windows)/Option(Mac)」キーを押しながらスライダーをクリックします。

1つだったスライダーが2つに分割されます。隙間を空けるようにスライダーを移動させると、スムーズに境界が合成されます。

※スライダーは左右両端にありますので、目的に応じて使い分けます。

 

さらにレイヤーマスクを追加して、合成する範囲をコントロールしても良いかもしれません。

f:id:sgtech:20200723200340p:plain

近景の完成

 

エフェクトと色調補正

Unityでエフェクトごとにキャプチャーした画像を基本的には描画モードを「スクリーン」で合成していきます。炎だけ、煙だけと要素に分けてキャプチャーするため、キャプチャー枚数は背景よりもずっと多くなります。

f:id:sgtech:20200723200149p:plain

エフェクトは描画モードを「スクリーン」で合成

f:id:sgtech:20200723200249p:plain

背景の完成
※クリックすると大きい画像で表示

それでも足りないエフェクトはブラシで描き足します。色調補正を重ねて背景の完成です。

 

リテイクに強いゴミを消す方法

少し脱線しますが、フォトバッシュやレタッチ作業をしていると画像から不必要なゴミを消したい場合もあります。

定番というと「スポット修復ブラシツール(修復ブラシツール)」「コピースタンプツール」が思い浮かびますが、今回はCC 2019から追加されたマイナー(?)だけど便利な方法をご紹介したいと思います。

スマートフォンで撮影した実物のビッグバナー写真からエフェクトやシミなどを削除してみます。

f:id:sgtech:20200723203530p:plain

火の粉や鳥、印刷のシミを削除するには・・・

f:id:sgtech:20200723203536p:plain

削除したい範囲を囲み・・・

 

メニューから編集→「コンテンツに応じた塗りつぶし」を選びます。
※CC 2019より以前のバージョンでは編集→塗りつぶし→「コンテンツに応じる」ですが、新規レイヤー作成はできません。

f:id:sgtech:20200723203543p:plain

「新規レイヤー」を選ぶと、修正箇所を別レイヤー化できて便利

 

CC 2019からはプレビューで確認しながら調整できるようになり、出力先として「新規レイヤー」が選べるようになりました。このままデフォルト設定で適用します。※意図した結果にならないケースでは、「サンプリング領域」をブラシで塗り直します。

「サンプリング領域」と選択範囲を調節するだけで結果が変わるため、一気に修正できてリテイクに強い便利な機能となりました。

f:id:sgtech:20200723203547p:plain

囲った箇所を一気に修正

 

一方でブラシのストロークで修正できる「スポット修復ブラシツール」も捨てがたいです。

ああ、元画像を直接修正しない方法があれば・・・スマートオブジェクトでも修正できれば・・・。分かります。

実は「スポット修復ブラシツール」の「コンテンツに応じる」を選んでから「全レイヤーを対象」にチェックを入れることで解決できます。

f:id:sgtech:20200723203616p:plain

「スポット修復ブラシツール」の「全レイヤーを対象」を選ぶ

新規レイヤーを作成すれば、ストロークした修正箇所のみ新しいレイヤーに分けることができます。

 

ここまでポイントなっているのは「コンテンツに応じて◯◯」という機能です。Photoshop CS4からバージョンが上がるごとに対応が増えている機能ですが、こちらで詳しく使い方をフォローされています。

blogs.adobe.com

 

キャラクターのライティング

ここからは背景に英雄 マサカドを立たせて、基本的にはキャラクターのライティング調整を優先していきます。

その理由として悪魔モデルはモデリングと質感のクオリティーが非常に高いレベルにあるため、大きい修正をする必要性を感じられないからです(アトラスさんの監修も通っていますし)。

ちなみに下記画像のポーズは元のイラストのマサカド公を再現しています。イラストと見比べても再現性バッチリで、モデリングチームとアニメーションチームの熱意が伝わってくるかのようです。

向かって左側に立っている英雄 マサカドがゲーム中のリアルタイムライトでキャプチャーした画像です

 

まずは影の調整をしてみましょう。

左側の画像をベースにブラシを使用してアンビエント・オクルージョンを追加していきます。

f:id:sgtech:20200723200304p:plain

ベースのキャプチャー画像(左側)

アンビエント・オクルージョン追加後(右側)

夕日のバックライトに合わせて手のひら、袖の下、洋服の重なり部分、足首周りにしっかりと影を落とします。

 

ここからはラィティングの調整をしていきます。作り込んだモデルの立体感とPBRマテリアルによる繊細な質感をさらに引き出すことを目標とします。

基本はキーライト、フィルライト、バックライト(リムライト)があれば対応できます。顔周りが暗かったり、余計な影が顔に落ちているケースではフェイス用ライトを何個か追加してキャプチャーしておきます。

 

最終的にPhotoshop上で合成するため、Unity上でのライト調整はそこそこで大丈夫です。

1ライトにつき1枚キャプチャーしておくと、調整がしやすくなります。

f:id:sgtech:20200723200308p:plain

フロントライト(左側)、フィルライト(右側)

ベースの画像を1枚目として数えると、フロントライト、フィルライトの追加を行ったので合計3枚キャプチャーしたことになります。

 

意外と少ないキャプチャー枚数なのは屋外だったからかもしれません。もし屋内であれば光源が多数あるケースが多いため、キャプチャー枚数も増えていたでしょう。

以前はMayaでディフューズ、スペキュラーなどレンダリング要素別に出力していたことに比べると、とってもシンプルな手法ですね。

 

英雄 マサカドを取り囲むように篝火が配置してありますので、照り返しを感じられるように「トーンカーブ」を使って色調補正します。

f:id:sgtech:20200723200313p:plain

ベース(左側)、レタッチ完了後(右側)

足元には水面反射と影を追加し、注目される箇所を優先して修正します。

顔は注目度が高いので、瞳や歯の辺りは丁寧に手を入れています(口の中までクッキリと映る解像度なんです)。

 

最後に背景とキャラクターをなじませ、全体のバランスを調整をしてレタッチの完成です。

f:id:sgtech:20200723200238p:plain

英雄 マサカドのビッグバナー完成画像
※クリックすると大きい画像で表示

新生ホーム画面背景にそびえ立つ天魔 アスラおうのビッグバナー画像も上記と似たような工程を経ています。

f:id:sgtech:20200723200138p:plain

天魔 アスラおうのビッグバナー完成画像
※クリックすると大きい画像で表示

この後の作業工程ですが、記事前半でご紹介したwaifu2x-caffeを使った拡大変換へとつながっていきます。ここまで長かったですね・・・長文にお付き合いいただきまして、ありがとうございました!

 

まとめ

というわけで『D×2』ビッグバナー制作事例いかがでしたでしょうか?

  • waifu2x-caffeを使って入稿用画像を拡大変換する。
  • waifu2x-caffeの方がPhotoshop (Adobe Sensei)よりもキレイな拡大結果を得られる可能性がある。
  • Photoshopの「コンテンツに応じる」機能はどんどん使ってみる。

辺りがポイントでした。

ちょっとしたツールの使い方の違いで作業効率が地味に変わることもあります。今回の記事が皆様にご活用いただける内容でしたら幸いです。

 

セガではこのような取り組みに興味のある方を募集しています。もしご興味を持たれましたら下記サイトにアクセスしてみてください。

www.sega.co.jp

 

最後は『真・女神転生』シリーズ定番のセリフでしめたいと思います。

『コンゴトモヨロシク』お願いいたします。

 

©SEGA/©ATLUS

セガ・セガロゴ、ゲームギア、ゲームギアミクロ、メガドライブミニは株式会社セガまたはその関連会社の登録商標または商標です。

記載されている会社名、製品名は、各社の登録商標または商標です。

Powered by はてなブログ