What Do We Do as a QA Engineer?: Welcome to the Testing World for Game Development

Hello.
I'm Naoki Sakaue. I work as a QA engineer in "Ryu Ga Gotoku Studio" of SEGA Games. I have been creating the video games of "Ryu ga Gotoku/Yakuza" series about 10 years.
In the following article, I will explain the role of a QA engineer and playback the game development history of "Ryu Ga Gotoku Studio".

What Do We Do to Test the Games?

Before we go on to the main topic, let me explain what a QA in the game development is. QA stands for Quality Assurance. When we use a word "QA" in the game development, it usually means the work itself but also the departments or the project teams, depending on the organization. The basic purpose of QA in the game development is to find bugs and make sure if the games are working correctly in required quality.

Then, what do we do when we use a word "Test" in the game development? In most cases, it means to play the games manually to find bugs and fix them. (Unit testing and smoke testing which are well-known in the software development are also held in the game development, and I will explain them later in this article.)

The games under development are checked by people called a "QA Tester" to see if there is no bugs left in the games, the products are well followed by the specification documents, the games meet the product standard, and the games are come up fun as the final products. Their works cover a wide range, such as a simple testing of crashing a wall to find collision bugs, finding failures triggered by a complex procedure or specific timing, and a physical testing of plugging or unplugging cables.

It is likely that people think of game testing as just a simple process of finding bugs, but it is only a step to QA and not a goal. The main purpose of game QA is to assure that the games are working correctly in required quality.

So, this process is very important that the games cannot be made into the final products without it!

Works of a QA Engineer

Recently, as the game development is getting bigger and bigger in size, it’s becoming more and more difficult to test and develop the games manually. To solve such problems by engineering technology, a new profession called a "QA Engineer" (like me) was born. What is required for a QA engineer might differ by organization. At our office "Ryu Ga Gotoku Studio", the QA engineers make efforts to automate the environment of the game development and QA and to increase its productivity every day.

At our studio, to improve the productivity of the game developing environment, we automate build and convert of game assets, and improve efficiency for the workflow of issue tracker (Trac/Redmine/JIRA etc.). In some offices, people called a "Build Engineer" do these jobs. But at our studio, the QA engineers usually take these roles, and sometimes ask for help from other engineers of our team or different departments, depending on the situation.

In this article, I will mainly explain the game testing on my work and can give you only a brief explanation of the automation technology for the game developing environment. So, if you are interested in the automation technology and want to know further information, please check out the following link of Japan Symposium on Software Testing in Tokyo 2016 (JaSST'16 Tokyo).

What Do We Do to Debug Faster for "Ryu ga Gotoku/Yakuza" Series?: High-Speed Workflow to Fix Enormous Bugs (JaSST'16 Tokyo) (Japanese) 

(2009-) Automated Playtesting

From here, I will move on to the next topic "Automated Testing", which is one of the main works of a QA engineer. I will explain how we came up with a new profession “QA Engineer” at “Ryu Ga Gotoku Studio” through a history of “Ryu ga Gotoku/Yakuza” series.

We have been releasing "Ryu ga Gotoku/Yakuza" series every single year in Japan, and the latest title which was released this year is the 14th. To release the mass scale games in such a high speed, at “Ryu Ga Gotoku Studio”, each one of engineers and a team as a whole always have been thinking what we can do to automate the game developing environment and to enhance its productivity. This spirit gave a birth to automated playtesting!

When we had started developing games for PS3 generation, we had developed our original automated playtesting system “AutoTest” and started operating it. This is a system which enabled PC and development machines to run through automatically throughout the midnight, so that they can detect errors even after the engineers left the office.

In the following figure (Figure 1), "AutoTest" gets the latest build and starts to play the game automatically, and Player AI (like bot) can emulate pushing buttons and play the game automatically.

Figure 1: The Architecture of "AutoTest" System

At the beginning, we tried to make the player in the game move randomly. We made them crash into a wall to find collision bugs.  And then, we gradually expanded the area of automated testing, and now that we can clear the main story of the games with the replay data on the basis of playing the games in manual testing! Therefore "AutoTest" can expand the area of automated testing.

We kept brushing up the functions of "AutoTest" even further. In the game of “Fist of the North Star: Lost Paradise”, "AutoTest" cleared the main story all by itself. For “Fist of the North Star: Lost Paradise”, we made additional functions to automated testing which can cope with widely varying situation, and now that it enables us to find various types of bugs. For example, "AutoTest" can select the bot AI that mashes the decide-button during dialogue scenes, and changes to the battle’s bot AI when it attacks enemies (Figure 2). It can select bot AI that meets the circumstance of the game.

Figure 2: "AutoTest" Demo (Fist of the North Star: Lost Paradise)

Furthermore, an effective cooperation system is built up between manual testing and automated testing, so that "AutoTest" can take charge of testing numerous combination steps that can be hardly handled in manual tests.

You may think that the more the automated playtesting finds various patterns of bugs efficiently, the better works we accomplish as a QA engineer. But it is preferable that AI technology concentrates on removing only easily-find-bugs out, while we take our time to find more complex bugs, because we always want to focus on improving quality of our games and create the best and the most fun games ever before. The automated playtesting does support and help the manual testing, but not all the process of game testing can be easily replaced by the automated testing.

(2013-) The Birth of a QA Engineer and the Acceleration of Automated Testing

We have been improving and adding new functions to the automated environment for the game development and QA every time we release "Ryu ga Gotoku/Yakuza" series at our studio “Ryu Ga Gotoku Studio”. But on the one hand, it contributes to speed up the game development and improve the game quality, on the other hand, maintaining the automated environment increased the burden on developers. Therefore, I stepped forward and started to take in charge of the QA engineering since the development of "Ryu ga gotoku Ishin!" which was released in 2014 in Japan.

It was a wise decision to assign an exclusive QA engineer in a developing team that it carried out a great evolution to QA engineering technology at unbelievable speed on a daily basis. We reorganized the original developing environment and started integrating the systems in order to manage and maintain them easier. We also expanded the functions of “AutoTest”, and moreover we implemented the new functions for log analysis which I will explain in the next paragraph. QA engineering technology of “Ryu Ga Gotoku Studio” is still continuing evolving and it accelerates its speed even today.

(2015-) Analysis of Testing Result

At our studio, we assigned an exclusive engineer and we can now handle and manage the automated testing much easier. But there, we faced another new problem. Other than "AutoTest", we use Jenkins for automated testing. (Of course we use it as a continuous integration tool.) But it can only tell us either the result of the test is a success or a failure. We wanted the results in much more detail. so we started to analyze the logs of testing since "Ryu ga Gotoku KIWAMI" (Released in 2016 in Japan/The English version is "Yakuza Kiwami") and "Ryu ga Gotoku 6: Inochi no Uta" (Released in 2016 in Japan/The English version is "Yakuza 6: The Song of Life").

The following graphs (Figure 3 and 4) show the visualization of heap maps which are created by collecting usage of VRAM (Video RAM/Graphics Memory) (Figure 3) and collision errors in "AutoTest" (Figure 4).

Figure 3: Heat Map for Usage of VRAM (Fist of the North Star: Lost Paradise)

The heat map below visualizes the usage of VRAM in the city of "Eden".
Red is high usage, and X is NG (over 100% usage). 

Figure 4: Collision Error Map in Very Huge "Wasteland" (Fist of the North Star: Lost Paradise)

As a result of making the “AutoTest” play the games, defects other than easily-found-bugs, such as warnings, were found, just like when we play the games by ourselves. And also it can check the game performance for us. By collecting the logs and visualizing them, we can now save a lot of time and fix bugs much faster with high accuracy.

Moreover, we analyzed logs of manual playtests and could get feedback of game level design. It enabled us to create more fun games. The following graphs (Figure 5 and 6) are examples of feedback of game level design to analyze logs of manual tests (Figure 5) and "AutoTest" (Figure 6).

Figure 5: The Game Over Points of Manual Playtesting (Yakuza 6: The Song of Life)

We visualized points where player’s HP is zero in manual tests. We could make use of it for game level design.

Figure 6: Item Drop Odds of Automated Playtesting (Fist of the North Star: Lost Paradise)

We measured odds of items that the enemies dropped in automated playtests. We confirmed the item odds are correct and the enemies can drop the rare items for game level design.

If you want to know about our automated playtesting and playlog analysis in more detail, please take a look at the following link of Japan Symposium on Software Testing in Tokyo 2018 (JaSST'18 Tokyo)

Automated Playtesting and Playlog Analysis to Create More Fun Games for "Ryu ga Gotoku/Yakuza" Series (JaSST'18 Tokyo) (Japanese)

(2018-) Thought of Test Pyramid and QA Engineering in the Future

No matter how efficiently we became to analyze the result of automated testing, we can never stop improving the QA environment. Nowadays, AI technology is a big trend everywhere around, and the efficiency of the automation technology and the log analysis in the game development which have been based on our experience are expected to make much more progress with an effect of AI technology.

In Computer Entertainment Developers Conference 2018 (CEDEC 2018) in Japan, I joined a session "On the Future of QA and AI: How to Implement AI into Game Development Correctly" as a panelist. In the article below, I will follow up on the test pyramid which I had explained in CEDEC 2018.

The test pyramid is often used to show the execution of automation efficiency. In system software or web development, the test pyramid is desired to be like the figure below (Figure 7).

Figure 7: Test Pyramid of System and Web Development

UI Testing	The product testing. It is high cost and difficult to automate.
Integration Testing	Testing if the combination of individual functions and modules work correctly.
Unit Testing	Testing of individual functions and modules. It is the lowest-cost testing in this test pyramid.

By increasing the ratio of lower-cost unit testing and automating it, it is possible to cut cost and improve efficiency. Then what about the test pyramid in the game development? In most cases, it is likely to be a pyramid below (Figure 8).

Figure 8: Test Pyramid of Game Development (Real)

Manual Playtesting	Testing to be played by hand.
Smoke Testing	Simple testing to check if the games launch and the individual modules work correctly. The shorter the time, the better testing. (about a few minutes)
Engine and Library Testing	Testing if samples of the engine and the library work correctly when they are developed in the company.
Assets Testing	Individual testing if the game assets (the models, the textures and the motions etc.) work correctly.

As you can see from the figure above (Figure 8), the pyramid is upside down and very unbalanced. The ratio of the manual testing at the last stage of the game development is very high, which means it is inefficient and high costs. In the game development, these testing relies on human resources that it is difficult to increase personnels in a short period of time, especially under such a current circumstance of labor shortage.

And because of its data-driven architecture in the game development, it always seems to be very buggy by data(assets). Sometimes the number of these bugs is even greater than that of programming bugs.

So, we incorporated unit testing before final testing. You may think “Why do we need unit testing in the game development?”, but once you know that it can detect errors and check consistency of individual assets before the final tests, you may easily imagine how extra works and retake-costs we can eliminate by having unit testing.

We have been trying to make further efforts to fix the inverted triangle to a well-balanced triangle. For example, except for “AutoTest” and log analysis which I have already explained, we strengthen detecting errors in assets-converting and increasing smoke testing.

Figure 9: Test Pyramid of Game Development (Ideal)

With the ideal pyramid above (Figure 9), you may wonder why we had started to automate playtesting which is highest-cost testing first.

There are two reasons for it. Because the results of unit testing in the games can be observed only in the graphics output, it is difficult to determine if the result is a success or a failure. And the other reason is that the members of the development teams accept errors of automated testing as errors we must fix.

The second reason is especially important. In a testing process, once an error is found, the error must be fixed right away. But if the errors which automated testing found are not trusted by the developers, they would have a question such as “Do we really encounter the same errors in the product?”, and that these bugs would be possibly ignored and thus left over in the games. In this case, we will end up in just wasting time and labor. We should build the test environment exactly like the product which surely ensures the reliability of automated testing. It is important to raise the organization culture that every time the automated testing finds errors, we must fix them immediately.

At “Ryu Ga Gotoku Studio”, every team member recognizes the need of the “Automated Playtesting” and trusts the system, thus we are able to keep increasing the ratio of low-cost automated testing. If you are willing to try the automated testing, my advice for you is to build automated playtests which enable a player in the game move randomly by mashing buttons, and then gradually share them with your teammates.

Conclusion

As you can see from this article, QA engineering is very essential technology in the game development now, and it is desired and expected to evolve greater in the future.

Talking about my career, I first started working as a game programmer, and then experienced game development and QA as a developer. That’s why I can easily tell what is exactly desired for QA and what should be automated in the game development. In addition, I can suggest the concrete solutions for automation of the game development and seek for better productivity. In this sense, I believe that I’m making the most of my career. If you are interested in QA, a QA engineer would be a good choice for whom already have experienced game creating as a programmer.

We have been trying to make a comfortable environment also for developers. If you are interested in our jobs, please knock the door and contact us any time. We are always waiting for you here at SEGA.

SEGA Careers (Japan)

Reference

• How Do We Create the High-End Video Games within 10 Months?: The Foundation of Technology for "Ryu ga Gotoku/Yakuza" Series (CEDEC 2010) (Japanese)
• What Do We Do to Debug Faster for "Ryu ga Gotoku/Yakuza" Series?: High-Speed Workflow to Fix Enormous Bugs (JaSST’16 Tokyo) (Japanese) 
• Automated Playtesting and Playlog Analysis to Create More Fun Games for "Ryu ga Gotoku/Yakuza" Series (JaSST’18 Tokyo) (Japanese)
• On the Future of QA and AI: How to Implement AI into Game Development Correctly (CEDEC 2018) (Japanese)

* The game screenshots in this article were taken under development. It is different from the products.

 ©SEGA

ゲーム音楽って面白いんです！

はじめまして、セガゲームスでサウンドクリエイターをしております小林と申します。
1998年に入社し、主に「ファンタシースター」シリーズでサウンドの制作に携わっています。
今回はゲーム音楽の面白さ！をできるだけ伝えられればと思っています。

【目次】

• 最初に作った音楽は？
• 本格的に関わった「ファンタシースターオンライン」
• インタラクティブミュージック・・？
• 「SYMPATHY」システムを使用した「PSO2」
• 目的を持った音楽を！
• PSO2のサウンド表現
• 「感動体験」を！

最初に作った音楽は？

---

最初の頃に作曲として参加した作品は「ぐるぐる温泉」というパーティーゲームのBGMでした。ぐるぐる温泉というゲームはたくさんのミニゲームがあり、それに好きなBGMを鳴らして遊ぶというもので、自分も何曲か作りました。
（フュージョン的なBGMや、ボサノバ風なものも作りました）

ここで、このゲームにおけるBGMのテーマや役割について考えてみましょう。

• ゲームの内容に沿ったもの、というよりは「なるべく色々なジャンルの音楽を！」というテーマ
• どの曲でも好きなゲームで聴けることにより、様々な組み合わせでゲームを楽しめる、という役割

などでしょうか。ここでのまとめは

遊ぶたびに、任意の曲を好きなようにBGMとして使うことができる

ということになるのかと思います。リアルタイムでプログラムを実行し、内容を反映できるゲームならではの利点だと思います。

本格的に関わった「ファンタシースターオンライン」

---

私の中でもエポックメイキングなプロジェクトだったのがこの「ファンタシースターオンライン（PSO）」です。PSOはオンラインのアクションゲームで、当時のコンシューマーゲームとしては新しいことをしていたと思います。
そこで、サウンドでもなにか新しいことをできないかと思っていました。

まず、なるべく簡単にゲームの仕様をまとめてみると、下記のように考えられます。

• 壁や扉に区切られた部屋が組み合わさってマップができています。
• マップを移動するとエネミーが出てくるので攻撃し、倒します。

ここで、BGMがどう関わるか考えてみましょう。

1. マップをスタートするとBGMが鳴る
2. 敵が出てくると別のBGMが鳴る
3. 敵を倒すと元のBGMに戻る

普通のBGMアサインの仕方であれば、上記の場合２曲で足りると思います。それぞれの状況で２曲を鳴らせば良いだけで、現在でも多くのゲームで使用されている手法です。
ただ、それだと普通で面白くないと思っていたのと、当時のサウンドディレクターからも「２曲が「自然に」変わるような方法はないだろうか？」というアイデアがありました。

そこで考えたのが下記の方法です。

• 楽曲A、楽曲Bをいくつかの「パート」に区切り、パートの中も２～４小節単位で区切れるようにする（フレーズとしておきます）
• パートごとに、「楽曲A→楽曲B」「楽曲B→楽曲A」へのファンファーレ的なものを作っておく
• 楽曲A、楽曲Bを、フレーズ単位で細切れにして、それを連続的に再生する
• 敵が出る、倒し終わるなど、場面の変化時に、「フレーズの終わるタイミング」で「ファンファーレ」を鳴らし、次の楽曲に連結する

いきなり複雑になってきました。今度は図解にしてみましょう。

こうしてみると更に違いがわかると思います。
そしてPSO方式の場合、技術的にも通常には無いものが必要になってきました。

• それぞれのフレーズを、決められた順番・時間通りに再生する仕組み
• 状況の変化に応じて、必要なフレーズを連結し、それぞれの楽曲へ変化させる仕組み

また、楽曲の変化タイミングについても考えてみるとより表現を豊かにできます。

• 敵が出現する、倒し終わることで楽曲が変化する
• 敵がいるマップから避難すると楽曲が変化する、等

上記はすべて特殊な内容だったため、一から仕組みを作る必要がありました。当時プログラマー向けに書いていたBGM挙動についての 仕様書の一部が下記になります。

 

これをステージごとに、全部手作業で設定してもらっていました。当時は苦労をかけてしまいましたが、開発チームがBGMシステム案に理解を示してくれたおかげで実現できました。やはり実現のためにはプログラマーの力が必要で、ゲームにおけるプログラマーは非常に重要な役目を担っています（本当にありがとうございます！）

ここで、PSOにおけるBGMのテーマや役割について考えてみましょう。

• ゲームの内容＆世界観に沿った楽曲を！というテーマ
• ゲームの状況に応じて、必要な音楽を動的に再生・変化させて、場面を演出する役割

というものになるかと思います。「ぐるぐる温泉」のときは指定された内容の楽曲を提供するのみでしたが、ここでは

• 「必要な音楽を動的に再生・変化させて、場面を演出する」役割になるように「設計」し
• そのための仕組み、方法についても「設計」

しています。このように、ゲーム音楽を作るサウンドクリエイターのひとつの特徴と言えるのが、この

「設計（プランニング）」

なのです。そして、このプランニングによってゲーム音楽はもっと面白くできるのです！

また、プランニングのための作曲テクニックも、その実現のためには重要です。

例えばPSOの場合は、「楽曲A」「楽曲B」が「自然」に切り替わり、連続性を持たせるように設計していますが、そのためには楽曲そのものにもひと工夫必要です。

• 楽曲A、楽曲Bは、違って聴こえつつも、近しい関係であるようにする
  →　平行調、同主調などで作曲を行う
• 戦闘中（楽曲B）は緊張感を増すように、楽曲Aよりもテンポを早くする
  →　PSOのときは、再生する１フレーズの長さが各ステージで固定されていたため、基本的に楽曲Bは楽曲Aの2倍のテンポで作っていました。（2倍であれば、同じフレーズの長さで小節数が2倍になるだけで、合わせやすい）
• 楽曲A←→楽曲Bがスムーズに移動できるように、ファンファーレを工夫する
  →　その先の楽曲に繋がれるように作曲を行う（ファンファーレと呼んでいますが、AB楽曲それぞれのイントロ＆エンディング部分を作っている感じです）

このように、 個々のゲームがそれぞれ持っている目的に対して、

• どのような音楽を作るのか
• それがどのようにゲームに関わっていくのか
• 関わることによって、どのような結果をもたらすのか

などのことを考えて、楽曲そのものや、その鳴らし方を含めて考え、作っていくのがサウンドクリエイターなのかと思います。面白いのが、上記の順番は場合によって変化もして「こういう風に関わっていくからこういう曲を作りたい」という考え方もアリです。（PSOはこの考え方だと思いました）

また、元からのBGM仕様（プランナーが制作する）もあります。「この場面でこの音楽がほしい」といったものから、「ここでこう変化させたい」など、一段と細かい要望もあり、それらをより具体的な形にしていくのもサウンドクリエイターの仕事です。

もちろん、すべてのプロジェクトでこのようなことはできないかもしれませんし、あるいは必要ないかもしれません。ただ、それぞれのゲームで表現できる可能性というものはいくらでも考えられると思います。そこが面白いと思います！

インタラクティブミュージック・・？

---

「インタラクティブミュージック」という言葉がございます。大雑把な説明をすると「ゲームプレイに応じて変化するミュージック」というべきでしょうか。そういう意味では、例えばメガドラ版ソニックでも、水中にいるソニックが息苦しくなってくると曲が変わる（そして空気を補充できると曲が戻る）というギミックがありますが、これもインタラクティブミュージックだと思います。

またPSOでは、切り替わった先の楽曲が、変化のタイミングによって任意の場所に変化する、という意味では毎回楽曲の内容が変化していくというところでインタラクティブミュージックと呼べるかもしれません（PSOの場合は「シームレス」とも呼ばれています）。

そして現代のインタラクティブミュージックは、更に（それどころかめちゃくちゃ）高度に作られています。更にADX2やWwiseなど、「ゲームサウンドのための」システムも提供されていて、素晴らしい作品が作られています。
そしてここからは、現在進行中の「PSO2」についてお話しましょう！

「SYMPATHY」システムを使用した「PSO2」

---

「SYMPATHY」システムとは何でしょう？それはPSO2における「インタラクティブミュージック」「プロシージャルミュージック」システムの総称です。

これからの内容は、過去２回にわたって行われたCEDEC講演の内容も含まれています。

www.4gamer.net

www.famitsu.com

PSO2開発当初、PSOで行ったBGMシステムについて社内でも評価があり、それをより拡張した形で表現できないか、と提案があったため、私が基礎を設計し、プログラマーの方にシステムやツールを作ってもらいました。

まずは、PSOでやっていた

• それぞれのフレーズを、決められた順番・時間通りに再生する仕組み
• 状況の変化に応じて、必要なフレーズを連結し、それぞれの楽曲へ変化させる仕組み

をツール化し、サウンドクリエイターが直接制作できるようにする環境作りです。
これは「Sympathy MusicEditor」というツールで可能になりました。
更に、PSOでは制限されていたフレーズの長さについても、楽曲A、Bで独自にできるどころか、フレーズ単位で変更が可能になったため、変拍子の楽曲も制作可能になりました。
また、従来の内容に加え、新たに様々な仕組みも追加しています（現在も追加中です！）
（SYMPATHYシステムの根幹は、CRI*1のADX2を元にしています）

ここで、新しく「プロシージャルミュージック」という言葉が出てきました。「プロシージャル」とは、決められたものではなく、その場の条件によって作られる内容が変わる、といった意味で、音楽でプロシージャルを行う＝「楽曲の自動生成」を目指したものになります。

PSO2のプロシージャルミュージックの概念としては下記になります。

• 「パート」＞「楽章」＞「フレーズ」という単位を用意する
  →　PSOで使用した、細切れにした楽曲（クリップ）は「フレーズ」に入ります
• 「パート」に３種類の役割（「メロ」「サビ前」「サビ」）を持たせ、それぞれを毎回自動的に再構成させる。
• また、各役割のパートは多めに作っておき、そこから毎回選ばれることによって内容に変化を持たせる。
  （例１）
  　メロパート１・メロパート２・サビ前パート・サビ１・サビ２
  （例２）
  　メロパート１・メロパート３・サビ３
  　（更に、「楽章」「フレーズ」単位でもシャッフル可能）

上記の仕組みにより、毎回内容が変化するBGMの制作が可能になりました。

また、連続的に楽曲を変化させるための手助けとして「ライン」という仕組みも追加しました。パート・楽章・フレーズが横軸の動きであるならば、ラインは「縦軸」の動きと言えます。
この機能により、例えば

1. 毎回同じパートを再生していてもメロディを変化させたり、
2. 状況に応じてプログラムから直接指定して再生することもできます。

１の場合は、あるメロディ楽器にアドリブ演奏をさせたい時に、１小節ごとに作曲したフレーズを切り分けてアサインさせ、毎回違ったアドリブ演奏をさせる、ということをしていました。
２の場合は、ボス戦でボスのHPが下がったときに、曲の位置は変えないで曲調を変化させる（全体を半音上げたり）ときに使ったりしています。

というように、より多くのことができるようになりました。

目的を持った音楽を！

---

「目的を持った音楽」とは何でしょう？実は、私が重要視しているものの一つになります。
例えば、PSO2ではボス戦でHPが減少するとBGMが変化したり、更に強力なボスの場合は、最後にテーマ曲が鳴ったりします。
上記のように曲が変化すると

• あともうちょっとでボスが倒せるぞ！
• ボスの攻撃が厳しくなるから気をつけないと！
• （テーマ曲が鳴って）イヤッッホォォォオオォオウ！

という感じ（になるであろうことを祈る）に、プレイをする人はより気分が盛り上がりつつ、ボスの「状況」も知ることができます。この、「『状況』を知らせる」ことが私は大事なことだと思っています。というのはゲームは「状況」の連続であり、更に状況を有利に進めることが目的であるため、そこに音楽の表現が加わることによって、より大きな感動を与えられたり・音楽に役割を持たせることができるのではないか、と思っているからです。

ただ上記もいわば当たり前の話で、当然のごとく多くのゲームで表現されています。また状況に合わせたサウンドの表現で、究極的に完成されているのが「映画」や「ミュージカル」ではないかと自分は思っていますが、ゲームもその表現を追っている印象を感じています。ただそれを突き詰めるほど、芸術のレベルまで高められた技術、楽曲が必要になります。実際にそれを実現できているプロジェクトも少なくありませんが、だからこそ自分は表現力を高める努力もしつつ「ゲームだからできる表現」もできないかと思っています。
ここからは、PSO2のサウンド表現について過去の事例をご紹介しましょう。

PSO2のサウンド表現

---

※過去のCEDECで講演された内容が含まれています

１．惑星ハルコタンのフィールドBGM

PSO2はジャンプもできるアクションゲームでしたが、この新しい惑星のフィールドでは建物の「屋根」に乗ることができ、より立体的なアクションが可能になりました。これは自分の中でもかなり衝撃的だったので、これに音楽をぜひ絡ませたいと思いました。そこで考えたのが下記です。

• 「地上にいる状態」、「屋根に登っている状態」で「楽曲A・B」の合計4種類の楽曲を用意する
• 「地上」「屋根」はラインで分けておき、プログラムの指示で状況に応じて変化させる
• 既存の機能（敵登場時の変化）も作動する。

この場合は、プログラムのほうは状況に応じてラインを指示するという対応のみでしたが、楽曲の方では程よい連続性・変化を楽しめるように、下記のような作曲を行いました。

• 楽曲B（戦闘状態BGM）で
  →　地上時はパーカッション・オーケストラ風なアレンジ
  →　屋根上時は、ドラム・ギターと言ったロック風なアレンジ
  に制作した
• 楽曲Bのメロディ部分については、同じ内容で「フルート」「ギター」の音色で用意し、独自のラインを用意してその都度ランダムに音色が変わるようにした
  （メロディ部分・伴奏部分・リズム部分は独自のラインを持っています）

 ©SEGA

また、この曲でポイントだと思っているのは

• 「プレイヤーの（縦の）位置状況」を「楽曲」で知らせている
• メロディがそのままで、プレイヤーのアクションによって楽曲のアレンジを変化させられる

というところだと思います。

２．ブリュー・リンガーダの「リング」を含めたBGM

「ブリュー・リンガーダ」というボスがいるのですが、大きなリングを２つ持っており、これを飛ばしても攻撃してきます。リングはプレイヤーの後ろに回ることもあり、常に見えているわけではなく、注意が必要です。

ここでも、この印象的な敵の攻撃にサウンドを絡めたいと思いました。そこで考えたのが下記のようなものです。

• リングから鳴る持続的なSEについて、弦楽器（ストリングス）のフレーズをアサインしてもらう。このフレーズはその場で鳴っているBGM（ブリュー・リンガーダ用BGM）のどの時間軸で鳴っても問題ないような音で作っておく
• SYMPATHYシステムには、「フレーズの再生タイミングに合わせて特定のSEを再生する」という機能があり、これを利用して、リングの持続SEが再生されるタイミングを楽曲に合わせる

上記のような設計によって、

• リングの位置を音で知ることができる
• リングの攻撃があると、楽曲にストリングスのフレーズが追加され、それが位置の変化によって縦横に変化する

という、楽曲にもプラスの変化があり、プレイヤーにも状況を伝えられる、という効果を狙っています。

 ©SEGA

また、リングが２つなので、ストリングスのフレーズも「ハモる」ようにできています（フレーズ内容も複数用意し毎回ランダム）
更に、この仕組みは「ブリュー・リンガーダ戦BGM」でしか使えないのですが、実はブリュー・リンガーダ自身は他の場所・任意のBGMが鳴っているところでも出現することがあり、そこで気を利かせたプログラマーが「リンガーダ専用BGM以外のシチュエーションでは普通のSE（純粋な効果音）が鳴るようにもしておきますね」と対応してくれて、感謝の涙を流した覚えがあります（泣。

３．「クーナ」登場に合わせて、カラオケ状態のBGMにボーカルがタイミング良く入る

「混沌に惑う白き都」というクエストで、PSO2のアイドル「クーナ」が途中から一緒に参加して戦ってくれるようになるのですが、制作当初から、BGMはクーナの歌（終わりなき物語など）にしたい、という要望がプランナー側から出ていました。
その上で、クーナが一緒に戦っているときとそうでないときで、音楽でも状況を伝えられないか、と考え下記のようにしてみました。

・基本のBGMはカラオケにして、クーナが登場しているときだけボーカルが入るようにする

仕組みとしては、

• カラオケで１つのライン
• ボーカルで１つのライン

を用意して、ボーカルのラインは、プログラム側でクーナが出ているときだけ鳴るように指示してもらいました。

ただ、上記で仕組みとしては完成ですが、歌のメロディというのは、必ずしも小節の切れ目で終わっていない場合があります。そこで、サウンドデータの方でそれを吸収してみました。

この画像は、実際のMusicEditorの画像の一部ですが、「Beat（拍）」という箇所の値が、色々な数字になっていると思います。元の楽曲自体は４分の４拍子ですので、Beat: 11＝２小節と３拍など、一見中途半端に見えます。

実は、そうなっているのはメロディのフレーズに合わせてフレーズを区分けしているためです。画像で、一番上に並んでいるブロックがカラオケが入っているラインなのですが、データは中途半端なタイミングで区切られているものの、隙間なく連結されて再生されるので違和感はありません。

一方、その下の２行で交互にデータが入っている部分がボーカルになります。（本当は１行にしても問題は無いのですが、見てわかりやすいように２行に分けています）

SYMPATHYシステムの利点として、独立した波形データを連結して再生できるということがあります。このボーカルデータは、実は長いボーカルデータを切って並べているのではなく、予めフレーズごとに切り分けたボーカルデータに、後からミキシングを施しています。

どういうことでしょう？ボーカル曲といえば、例えば声にエコーが入ったりしていると思います（カラオケでも歌うときにエコーを入れることがあると思います）。仮に、ひと続きになったボーカルを切った場合、エコーはずっとかかっていますので、あるフレーズを切り出したときに、直前のフレーズのエコーがかぶってしまいます。

今回の場合は、エコーをかける前のボーカルを切り分けて、個々のボーカルごとにエコーをかけ、それをSYMPATHY上で連結しています。

この利点としては、ボーカルの入り方、終わり方がとても自然にできるということで、なおかつ連続して聴いている分には普通の歌と変わりありません。 

 SYMPATHYシステムは見かけ上４本のストリームデータを同時再生できるようになっていますが、実は上記の仕様を満たすために裏では２倍の、８本のストリームを同時再生しています。

この、フレーズに「余韻（エコー）」をつけるというのは非常に効果が高く、この「余韻」によって、フレーズ同士の連結をスムーズにするだけでなく、任意のフレーズ同士を自然に連結することも可能にしています。

その他のサウンドシステムはストリームデータを扱うものが主ですが、手間はかかるものの、このシステムによる自由度の高さはSYMPATHYシステムならではだと思います。

「感動体験」を！

---

上記以外でも、PSO2では色々なことにチャレンジしていて、それは今も続いています。ゲームにしかできない音楽表現、それは場面に合ったものであったり、何らかの目的を持ったものかもしれません。それがクリエイターのアイデアを元に、さらに色々なクリエイターの協力を得て一つの形になったとき、「感動体験」を呼べるものができるのだと思います。
そしてセガグループのミッションこそ「感動体験を創造し続ける」になります。自分はこのテーマが大好きです。そして、ゲームだからこそできる「感動体験」をこれからも創造し続けられるよう、頑張りたいです。
小林なりの「ゲーム音楽は面白い！」だったかもしれませんが、少しでもその楽しさが伝わったでしょうか・・？ゲームだからできる音楽をセガで作ってみたい！という方はぜひ、セガゲームスの採用情報へアクセスを！

*1:CRI・ミドルウェア：は、日本のミドルウェアの研究開発・販売を行う企業で、主流となっているのは動画、音声データの効率圧縮ツールおよびその展開ソフト（ライブラリ）です。

QAエンジニアってどんな仕事？～ゲーム開発におけるテストの世界～

はじめまして。 

セガゲームス「龍が如くスタジオ」専属QAエンジニアの阪上と申します。 

今回は、QAエンジニアという職種の紹介とゲーム開発におけるテストの話を、「龍が如くスタジオ」での開発の歴史を振り返りながらご紹介したいと思います。

目次

ゲームのテストって何をするの？ 

本題に入る前に、QAエンジニアのQAとは何なのかを説明しておこうと思います。QAは 「Quality Assurance」の略で、日本語では品質保証という意味です。ゲーム開発においては、ゲームが正しく動作しているか、バグがないか、ゲームが製品クオリティに達しているかなどを検証する仕事・部門・チームのことを指します。

QAがわかったところで、ではゲーム開発でテストとは何をするのかというと、ゲームを実際にプレイして、バグを見つけて修正することを指すことが多いです。（システム開発等で行われている単体テストやスモークテストなどもありますが、こちらは後半で説明します。） 

発売前のゲームをプレイして、バグがないか、仕様書通り動作するか、製品としての基準を満たしているか、ゲームとして面白いかどうかを検査する仕事を、テスターやデバッガーと呼ばれる職種の人が担当します。 壁にぶつかって抜けないかをテストする単純なものから、複雑な手順やシビアなタイミングで起こる不具合を見つけたり、物理的にケーブルを抜き差しするテストなど、その仕事は多岐に渡ります。 

ゲームのテストというと、バグを見つけるだけの仕事と思われがちですが、バグを見つけることは過程であって、最終的にゲームが正しく動作していることを確認した上で、品質や面白さを保証することが最終的な目的です。 

つまり、この工程がないと、ゲームは完成しないというくらい重要なものになります。 

QAエンジニアの仕事内容 

近年のゲーム開発は、大規模化の一途をたどっているため、先ほど説明しましたテストや開発そのものをすべて手動で行うことが困難になりつつあります。このような状況をエンジニアリングのアプローチから改善するために生まれたのが、私のようなQAエンジニアという職種です。組織によって具体的な業務内容には違いがあると思いますが、「龍が如くスタジオ」では、開発環境やQAの自動化・効率化を行うことを日々の仕事としています。

開発環境については、ビルドやデータコンバートの自動化、Redmine等のチケット管理システムのワークフローの効率化などを行っています。これらを仕事とする人を、より細分化してビルドエンジニアと呼ぶ場合もありますが、「龍が如くスタジオ」では、QAエンジニアである私が兼任したり、各ツールの担当者や他部署の協力を得るなどして、これらの自動化を行ってます。 

今回はテストの話が中心ですので、開発環境の自動化については簡単な説明にとどめていますが、詳しく知りたい方は、ソフトウェアテストシンポジウム 2016 東京（JaSST'16 Tokyo）の講演資料をご覧ください。 

「龍が如く」の高速デバッグ術～そびえ立つバグの山を踏破するための弾丸ワークフロー～（JaSST'16 Tokyo） 

(2009年～) 自動プレイテスト

ここからは、QAエンジニアの主な仕事の一つであるテストの自動化について、「龍が如く」シリーズの開発の歴史とともにご紹介したいと思います。

「龍が如くスタジオ」は、大規模なゲームを高速でリリースするために、個々やチーム全体で開発環境を積極的に自動化・効率化していこうとする組織風土がありました。このような環境だからこそ生まれたといえるものの一つが、自動プレイテストです。

PS3世代のタイトルを開発するようになったころから、オートテストという独自の自動プレイテストを開発し、運用を始めました。 開発メンバーが帰ったあとの開発環境（PCや開発機）を利用して、深夜に自動的にゲームをプレイして、エラーを検知するシステムです。  

下図のような仕組みで、最新ビルドのゲームを取得した上で自動的にゲームを起動して、QA専用のプレイヤーAI（ボットのようなもの）がゲームパッドの疑似入力を行い、実際にゲームを自動でプレイします。

オートテストの仕組み

 ※図中の「エラー送信」は、「龍が如くスタジオ」独自のクラッシュレポート機能です。

ランダムにプレイヤーを移動させ、壁にぶつかり続けてコリジョン抜けを探すところから始めて、現在は、事前に用意したパス（操作手順をコマンド化したもの）に従ってゲームのメインシナリオをクリアすることもできるようになり、より広範囲のテストをオートテストで行えるようになりました。

オートテストの機能はその後も進化を続け、「龍が如くスタジオ」制作の「北斗が如く」（2018年発売）では、下図のようにメインシナリオをクリアするテストを行っていましたが、会話中は○ボタンで会話を進め、敵とバトルになった場合はバトル用のボットAIに切り替えて戦うなど、ゲーム内の状況に合わせたきめ細かい自動テスト機能を追加し、様々なバグを検出することができるようになっています。

オートテストの動作例（北斗が如く）

また、上記に加えて、組み合わせが多すぎて手動でテストしきれないものをオートテストが専任で行うなど、手動テストとの協力体制ができつつあります。 

このように、自動プレイテストの取り組みは、近年のAIの台頭によって、AIに取って代わられる仕事と見られることがありますが、オートテストはあくまで手動テストの補助を目的としています。簡単に見つかるバグはできるだけAIにまかせて、手動テストでは、より複雑な条件のバグを探したり、ゲームの品質や面白さの向上に注力してほしいという思いで、日々オートテストの改良を続けています。 

(2013年～) QAエンジニアの誕生と加速するテスト環境の自動化

このように、「龍が如スタジオ」では、シリーズの開発を重ねるごとに、開発とQA環境の自動化が進んできたわけですが、開発のスピードアップやゲームの品質向上に貢献する反面、自動化した仕組みの維持が開発チームの負担となってきたため、「龍が如く 維新！」（2014年発売）の開発から、私が専属でQAエンジニアリングを担当することになりました。

専属のQAエンジニアを開発チームに置くことで、今までの自動化環境を維持しやすいように整理した上で一元管理したり、前述のオートテストの機能拡張や後述するログ分析などの新機能を実装することができるようになり、このころから、「龍が如くスタジオ」のQAエンジニアリング技術が劇的な進化を始めます。

(2015年～) テストの結果分析

テストを自動化して、QAエンジニアを専任化しましたが、それで終わりではありません。自動化のツールとしてよく使われているJenkinsでは、テスト結果の成功・失敗がわかりますが、自動テストの結果をもっと詳しく知りたいという要望が寄せられるようになりました。そこで、「龍が如く 極」（2016年発売）での試験運用を経て、ドラゴンエンジンでの開発となった「龍が如く6 命の詩。」（2016年発売）より導入したのがログ分析機能です。 

下図は、オートテスト実行中のゲーム内のVRAM（Video RAM、グラフィックスメモリ）の使用量を収集し、ヒートマップで見える化したものになります。

VRAMヒートマップ（北斗が如く）

エデンという街のVRAM使用率を、ヒートマップで見える化したもの。

赤くなっているところが使用率が高く、Xが100%を超えているので修正必須な地点。

コリジョン抜けマップ（北斗が如く）

荒野という広大なマップのコリジョン抜けを見える化したもの。

ゲームを自動でプレイしているわけですから、明確なエラー（例外やASSERT）以外の警告レベルの不具合も、通常のゲームプレイと同様に発生しますし、パフォーマンス計測も可能です。 これらをログとして収集し見える化することで、問題箇所を探す手間が省けるので、修正を正確かつ迅速に行えるようになりました。 

さらに、手動テストのプレイログも分析して、ゲームバランスの調整に使ったりと、まさにゲームの品質（面白さ）の向上にも活用できるようになりました。 以下は、手動テストやオートテストのログを分析して、ゲームバランスの調整に活用した事例です。

プレイヤーがゲームオーバーになった場所（龍が如く6 命の詩。）

手動テストでプレイヤーのHPが０（ゲームオーバー）になった地点を可視化して、ゲームバランスの調整に活用。

アイテムドロップ率（北斗が如く）

敵が落とすアイテムのドロップ率を計測し、仕様通りの確率でアイテムを排出しているか、レアアイテムが本当に排出されているかをオートテストを使って計測。

今回ご紹介したオートテストとログ分析は、ソフトウェアテストシンポジウム 2018 東京（JaSST '18 Tokyo） で講演させていただいたときの資料でより詳しく説明していますので、 ご興味がある方はご覧ください。（オープンソースを組み合わせて構築しているので、気軽に試すことができます。） 

無料で始める！「龍が如く」を面白くするための高速デバッグログ分析と自動化（JaSST'18 Tokyo）

(2018年～) テストピラミッドの考察とQAエンジニアリングの未来

自動化して結果を分析できるようになっても、QA環境を快適にする取り組みには終わりがありません。 現在は、どの業界でもAI活用がトレンドですが、今まで行ってきた自動化やログ分析を基礎として、AIを活用したさらなる自動化・効率化が期待されています。 

先週開催されたCEDEC 2018では、「次世代QAとAI 〜ゲーム開発におけるAI活用に正しく向き合うために〜」というセッションに、QAの今後の進化、AIの活用の未来というテーマで、パネリストとして参加させていただきました。今回は、CEDEC 2018で紹介したテストピラミッドについて、フォローアップしたいと思います。  

テストピラミッドとは、テストを自動化・効率化する上で、その考え方のベースによく使われています。一般的なシステムやWeb系の開発では、以下のようなテストピラミッドになることを理想としています。 

一般的なテストピラミッド

UIテスト	最終的な製品に近いテストのことで、高コストで自動化するのが難しいテスト。
結合テスト	機能ごとに実装したものを結合して、問題がないか動作確認等を行うもの。
単体テスト	ユニットテストとも呼ばれる機能ごとのテスト。一番低コスト。

より低コストな単体テストを増やして、自動化することで、コストを抑えつつ効率化することができるようになります。 では、ゲーム開発のテストピラミッドはどうなるかというと、 現状は以下のような状況にある場合が多いのではないでしょうか。

ゲーム開発のテストピラミッド（現実）

手動プレイテスト	人が実際にゲームをプレイするテスト。
スモークテスト	ゲームの起動や各モードが正しい動作しているかを簡易的に調べるテスト。最新ビルドをリリースする時に最低限の動作を保証するためのテストなので、なるべく短い方がいい。（1～5分程度）
エンジン・ライブラリテスト	ライブラリやエンジンを社内開発している場合は、サンプル等が正常に動作しているかをテストする。
データテスト	モデル・テクスチャ・レベルデザインなどのデータファイルが正しくゲーム内で動作するかを個別にテスト。ゲーム内で動的に描画テストを行ったり、コンバートの時に静的チェックを行う。

上図では、最終的な製品に近い状態での手動テストの割合が高く、高コストなので、ピラミッドのバランスが非常に悪くなっています。 高コスト体質な上に人に依存するテストなので、昨今の人手不足によりスケールアップが困難になる恐れがあります。 

また、ゲーム開発では、データドリブンな仕組みを採用している場合が多いため、データのバグが非常に多い構造になっています。（場合によってはプログラムのバグよりも多いことがあります。） 

単体テストと言われると、ピンとこないかもしれませんが、一つ一つのデータの不具合や整合性のテストを、 最終的な製品のテストの前に検出できれば、手戻りコストを含めてどれだけの手間が減るかは想像に難くないと思います。  

「龍が如くスタジオ」では、今回ご紹介したオートテストとログ分析以外にも、データコンバート時のエラー検出の強化やスモークテストを増やすなどの改良を加えて、逆ピラミッドから以下のような正しいピラミッドになるように、日々改善を行っています。 

ゲーム開発のテストピラミッド（理想）

ここまで読み進めていただいた方なら、もしかしたら理想のピラミッド図を見て、疑問に思われるかもしれません。 なぜ一番高コストであるプレイテストを自動化することから始めたのか？ 

これは、「ゲームという特性上、単体テストでの結果が画像出力しかない場合が多く、画像の差分は閾値（しきいち）が安定しないので成否の判定が難しいこと」、「自動テストのエラーをエラーとして開発メンバーに受け入れてもらうこと」の二つの理由があります。

特に後者が重要で、エラーが出たらそれを修正してもらう必要がありますが、自動テストのエラーに対する信頼性が低いと、「このエラーは製品でも起きるの？」と言われて修正されないまま放置されてしまい、テスト自体の意味もなくなってしまいます。 まずは自動テストを通常のゲームに限りなく近い状態で実行することで信頼してもらい、そして自動テストのエラーは即時修正するというチーム文化を作ることが重要です。 

「龍が如くスタジオ」では、自動プレイテストをチームに受け入れてもらった上で、現在進行形でより低コストな自動テストを増やしているところです。 自動テストを一から導入することをお考えの方は、ランダムにプレイヤーが動く自動プレイテストを作ってみて、チームのメンバーにみてもらうところから始めてみてはいかがでしょうか。 

まとめ

このように、QAエンジニアリングは、ゲーム開発とQAにとってとても重要な技術で、 今後さらなる技術向上と成長が望まれている分野であることが、おわかりいただけたのではないかと思います。 

私は元々ゲームプログラマからキャリアをスタートしましたが、ゲームの開発やQAを開発者の立場で経験したことで、 何を自動化すればいいのか、どういったことが望まれているのかが具体的に分かるので、その経験は非常に役立っています。 そういった意味で、QAエンジニアは、ゲームプログラマやテスターの方にとって入りやすい職種だと思います。

また、QAエンジニアが開発現場にいることで、開発する側にとっても快適な環境を目指して日々改善しておりますので、ご興味がありましたら、セガで一緒に働いてみませんか？ 

採用情報 | セガ企業情報サイト 

参考資料 

• 10ヵ月でHDゲームを開発する方法 ～龍が如くを支えたテクノロジ～（CEDEC 2010）
• 「龍が如く」の高速デバッグ術～そびえ立つバグの山を踏破するための弾丸ワークフロー～（JaSST'16 Tokyo） 
• 無料で始める！「龍が如く」を面白くするための高速デバッグログ分析と自動化（JaSST'18 Tokyo）
• 次世代QAとAI 〜ゲーム開発におけるAI活用に正しく向き合うために〜（CEDEC 2018）

※この記事は、JaSST'18 TokyoとCEDEC 2018、セガの社内勉強会であるSDC（SEGA Developer's Conference）の講演内容をベースに作成しました。 

※本記事で使用しているゲーム画像は、すべて開発中のもので製品とは異なります。

英語版はこちら

 ©SEGA

CEDEC 2018 セガグループセッション紹介

皆さんこんにちは！
セガゲームス、開発サポート部の麓です。

毎月お送りしているSEGA Tech blogも読んでいただいている皆さんのおかげを持ちまして来月でまる2年。
これからもセガグループが持っているいろいろな技術の種を紹介していきたいと思っています。

そして今回で三回目となるCEDEC登壇者の紹介です。

来月にパシフィコ横浜で開催されるゲーム業界最大のカンファレンス
CEDEC 2018　会期：2018年8月22日(水)～8月24日(金)
に今年もセガグループから多くの登壇者が名前を連ねています！
それでは今回もセッションと登壇者紹介に加え、ここでしか見れない講演内容の見どころと、当日の資料からの抜粋を(セッションとラウンドテーブルに限り)紹介します。

セッション

---

モバイルタイトルにおける横断的な機械学習によるレベルデザイン支援システムの構築と運用

セッションの内容

セガゲームス開発統括部で実際に開発・運営中のタイトルに導入した、レベルデザイン＆デバッグを自動化とAIにより支援するシステムの概要紹介と、そのシステム構築フロー、運営ワークフローを説明します。
3タイトル4事例を紹介しながら実際のシステム紹介に加え、導入する際に重要なこと、各タイトルでどのように運用されているか等も紹介します。
・事例１：「Ｄ×２ 新・女神転生 リベレーション」におけるクエスト難易度調整支援
・事例２：「Ｄ×２ 新・女神転生 リベレーション」におけるマップ設計支援
・事例３：「コトダマン」におけるデッキ調整・報酬設定支援
・事例４：新規タイトル事例(予定)
また現在検討中のユーザー動向を利用したより高度な支援システムの構想をお話しします。
株式会社セガゲームス　開発統括部　ディレクター／シニアプログラマ　松田 剛
8月22日(水) 11:20 〜 12:20

資料スナップショット

講演内容についてのコメント

機械学習の導入が各業界で進んでおりますがゲーム業界でもその流れが進んでおります。
本セッションでは実際にセガゲームスで使用されている機械学習の活用例とそのワークフローの
紹介を通じて、より面白いゲームを制作するための創意工夫の一環を知っていただけると思います。

---

「Ｄ×２ 真・女神転生リベレーション」におけるアニメーション制作事例〜184体の魅力ある悪魔アニメーションを少人数＋アウトソーシングで短期間で制作するヒント～

セッションの内容

「Ｄ×２ 真・女神転生リベレーション」におけるアニメーション制作事例を通し大量のユニーク体格のキャラクターのアニメーションアセットを少人数・短期間でどのように外部の協力会社と共に制作したかの実例となります。アニメーションをアウトソーシングする際の会社選定の基準、ワークフロー、発注仕様、チェックバックやリグの考え方について事例を交えながら解説致します。また本作でのデザイン要件、Unityでのアニメーションについて苦労した点とその解決法についても解説したいと思います。また業務効率化に繋がったツールについてもいくつか紹介させて頂く予定です。アニメーション制作をアウトソーシングする際のヒントになればと思います。
株式会社セガゲームス　開発統括部アート＆デザイン部TAセクション　リードテクニカルアーティスト　亀川 祐作
8月22日(水) 16:30 〜 17:30

資料スナップショット

講演内容についてのコメント

弊社のモバイル向けゲーム開発では内部は少人数でアセットの量産部分を外部スタジオに依頼する事は日常的となっております。内製とはまた違う苦労があり
特にアニメーション制作を外部に出すという事は比較的難度が高いと考えております。自身も模索しつつやっている部分もありますので、本セッション内容が
最適解だとは考えておりませんが、何か一つでもヒントになれば幸いです。

---

Ｄ×2真・女神転生リベレーションでの新しいＵＩデザイン制作方法の試みと発見

セッションの内容

Ｄ×2真・女神転生リベレーション開発時にＵＩデザイン組織を担うこととなり、
組織の新しい方向性とＵＩデザインの表現幅を広げるため、新たにユーザーテスト法とアイトラッカーカメラを交えた調査をプロジェクトに導入いたしました。テストから見えてきたアプリゲームでのＵＩルールの研究結果や、被験者に制作中のデザインをふれてもらいライブ中継することで、プロジェクト単位でデザイン表現をチャレンジする方法を本作品の表現の説明を踏まえつつ紹介致します。
株式会社セガゲームス　開発統括部アート＆デザイン部　UIデザインチームリーダー　良知 将範
株式会社セガゲームス　株式会社セガゲームス　開発統括部　デザイナー　山崎 陽平
8月22日(水) 14:50 〜 15:50

資料スナップショット

講演内容についてのコメント

ＵＩデザインの表現幅を広げるため、ユーザーテストと
アイトラッカーカメラを交えた調査をプロジェクトに導入いたしました。
テストから見えてきたアプリゲームでのＵＩルールの研究結果や、
プロジェクト単位でデザイン表現にチャレンジする方法を表現の説明を踏まえつつ紹介致します。

---

プロシージャルゲームコンテンツ制作ブートキャンプ Part 2 実践

セッションの内容

最近日本のゲーム業界でも導入が増えてきたプロシージャル法によるゲームコンテンツ制作。業界を代表するゲーム会社4社から、それぞれの製作現場で実践しているプロシージャル手法によるゲームコンテンツ制作実例を紹介します。
このセッションは2コマ連続のセッションの第2部で、プロシージャル法を使ったより実践的な中~上級の講演内容です。
株式会社セガゲームス　第一CSスタジオ　リードアーティスト　伊地知 正治　他
8月23日(木) 11:20 〜 12:20

資料スナップショット

講演内容についてのコメント

GDC2017でSideFX社より発表されたVertexAnimationTextureという手法を実際に龍が如く極２という製品に使用したエフェクト制作の流れを説明させて頂きます。
この手法はテクスチャに座標や角度などのアニメーション情報を焼き込んでシェーダに計算させ物理破壊、ソフトボディ、流体などの表現を現状で最も高速に描画させるものです。またHoudiniならではのワークフローも効率的で再シミュレーションからデータ生成まで数秒でイテレーションをかける事が出来ます。他にもHoudiniを使用したエフェクト制作のTipsをご紹介致します。まさにHoudiniはエフェクトアーティストにとって福音ともなる技術ですので是非ご聴講下さい。

ラウンドテーブル

---

プロダクション分野のプラクティスの中で開発における生産性向上のためのツールにフォーカスして議論するラウンドテーブル

セッションの内容

プロダクション分野のプラクティス（手法・技法）の中で、生産性向上に繋がる取り組みについてのラウンドテーブルを行います。
※議論の範囲を限定するために、この回では開発工程でのツールに特化した話題のみ扱います。
「生産性の向上を支援するツール」、「生産性を可視化・計測するツール」、「効果のあった事例」、「効果は測定できていないが導入した例」、「ツールで解決したい課題」にまつわるトピックを参加者それぞれが持ちより、情報共有や発展性のある議論を目指します。
ラウンドテーブルを効率的に進めるため、以下のレギュレーションを設定します。
[トピックの分類]
・生産性の向上を支援するツール
・生産性を可視化・計測するツール
・効果のあった事例
・効果は測定できていないが導入した例
・ツールで解決したい課題
[レギュレーション]
1. トピック登録：
生産性向上のためのツールに関する議題をお持ち下さい。
セッション会場内にホワイトボードを用意しますので、そちらに議題をお書き下さい。
2. 優先入場
議題を事前に登録して頂ける方は優先入場可能とします。セッション開始時間前に入室する事ができます。
聴講のみ希望もしくはその都度発言の方は、セッション開始時間直前に入室可能となります。
3. 進行
提出して頂いた議題を基に、議論を進めます。
4. 議題・議事録の公開
提出して頂いた議題と、議事録は後日CEDEC Digital Libraryに公開予定です。
株式会社セガゲームス　開発技術部　ビルドエンジニア　粉川 貴至
株式会社セガゲームス　開発技術部　プログラマー　竹原 涼
8月23日(木) 13:30 〜 14:30

講演内容についてのコメント

過去のCEDECでも何度かプロダクション分野のラウンドテーブルを開催している粉川です。
（どういう話題が扱われるかイメージしづらい方は、CEDiLで過去のラウンドテーブルの議事録を確認してみてください。）
今回は「生産性向上のためのツール」と少し視点を変えたテーマになっていますが、
働き方改革⇒生産性向上⇒自動化・効率化⇒ツールによる解決や課題（⇒ビルドエンジニア・QAエンジニアの活動）
と話題が繋がっていくイメージでこのテーマを設定させて頂きました。
いつものように自動ビルド・自動テストや構成管理ツール周りの話題が集まるのか、
生産性という観点から今まで考えなかった切り口の話題が出るのか、
それは当日集まったみなさん次第です。
ご参加、お待ちしています！

---

若手テクニカルアーティストの育成とその役割について話すラウンドテーブル

セッションの内容

本ラウンドテーブルは、昨年度の「若手テクニカルアーティスト（以下、TA）の業務効率改善への貢献、育成について話すラウンドテーブル」についての議論に続くものです。
TAとはベテランのアーティスト、プログラマが行う業種であるものというもの認識がありました。しかし、その需要からTA業務を行う若手を育成する動きが見受けられます。
そこで、各社で育てられた若手のTA複数名をラウンドテーブルへと参加していただき、どのような業務を割り当てる事がTAとしての知見を深め、育成に繋がるかをラウンドテーブルと言う形で突き詰め共有し、業界への貢献へとつなげていきたいと考えています。
本ラウンドテーブルは次の２つの議題を主に話し合う予定です。
　◆若手TAの活用事例
　　：若手としてTA業務を行う者たちは、どんな成果を上げることが出来るのか、
　　　どのような業務を割り振ることが成長につながるのか等について議論を行う
　◆若手TAの育成に向けての活動
　　：実体験をもとにした育成への工夫や、その成果。
　　　育成に着手したいがそれを実行できない会社などの理由やその対策などを議論する。
開場後、ラウンドテーブル開始までに、「若手TAの活用事例」について先行して議題を１、2個募集します。話したい話題がある人はぜひご意見ください！
株式会社セガゲームス　オンラインコンテンツ事業部　開発サポート部　エンジニア　清水　宣寿　他
8月23日(木) 10:00 〜 11:00

講演内容についてのコメント

昨年度のCEDECで「若手テクニカルアーティストの業務効率改善への貢献、育成について話すラウンドテーブル」で登壇させていただいた清水です。
昨年に引き続き、今年も若手テクニカルアーティスト（以下、TA）の育成についてのラウンドテーブルを開催できることになりました。
当日会場にお集まりいただいた参加者の皆さまと共に、若手TAの育成や活用事例などについて話し合いませんか？
一緒に「若手TAが担うべき役割とは何か？」について議論を交わし合いましょう。
皆様のご参加をお待ちしています。

---

【ラウンドテーブル】ワーママ・ワーパパたちの働き方改革を共有しよう！そして、何か新しい行動を興してみよう！

セッションの内容

※こちらのラウンドテーブルはタイムシフトパス以外のすべての受講パスで受講可能です※
2017ラウンドテーブル、「WM（ワーキングマザー）開発者の悩みとその解決策を共有しよう！－ワークライフバランス実現のためのTIPS」 参加後、セガで行ってきた、セガWMたちの動きに関して共有します。
セガでのその後１年の動きを説明後、前回同様、５～７人程度のグループに分かれて、皆さんの会社では、この１年でどのような動きがあったか、働きかけを行ったか、等、情報の共有をしていただきます。
（できれば、１グループに最低１人は男性に入っていただきたいと思っています。男性の皆さん、どうぞ、躊躇せず輪に入ってきて下さいね！大大大歓迎です！）
その後、グループごとに発表。
他社事例の情報を共有し、各自、自社へ持ち帰り。
それぞれの会社で、何か新しい１アクションを興していただきたいと思っています。
業界の、これからの働き方改革に繋げていきましょう！
勇気を共有できるようなラウンドテーブルにしたいです。
※ラウンドテーブル後は、希望者を募りランチ交流会の開催を検討中。（自費）
　CEDECでの出会いを、大切に繋げてきたいです。
　「夜の交流会には参加できないけど、ランチタイムなら！」
　という方は是非に！
株式会社セガゲームス　IP＆ゲーム事業部 開発統括部 企画開発運営部　茂呂　真由美
株式会社セガ・インタラクティブ　第二研究開発本部　デザイナー　鈴木　こずえ
8月23日(木) 11:20 〜 12:20

講演内容についてのコメント

貴方は、職場に何を望みますか？

会社が変わるのは時間がかかることかも知れません。
しかし、誰かが動かないと、変わることはありません。

弊社も、働き方改革については、まだ手探りな状況です。

職場環境改善のため、私たちにできることは何でしょう？
一緒に考え、協力し、それぞれ自社を成長させていきませんか？
後に続く、後輩たちのためにも。

昨年度スクエニさん主催のラウンドテーブル、「WM（ワーキングマザー）開発者の悩みとその解決策を共有しよう！－ワークライフバランス実現のためのTIPS」の続編として開催します。この流れを止めずに躍動させたいです。

ラウンドテーブルの結果をそれぞれの職場に持ち帰り、新しい行動を興す、最初の一歩の手助けになると嬉しいな、と思い、企画しました。

「ラウンドテーブル」ですので、テーブルについてディスカッションに参加していただきます。貴方の悩みや、貴社での動きなどを、是非教えて下さい！
「どうしても見学だけしたい」という方は、テーブルトークが聞こえる場所までご移動下さいね。（離れて見ていても、会話が何も聞こえないので…）

ラウンドテーブル後は、希望者を募りランチ交流会の開催を検討中。（自費）
CEDECでの出会いを、大切に繋げてきたいです。
「夜の交流会には参加できないけど、ランチタイムなら！」
という方は是非に☆
ランチは、雰囲気変えて、ざっくばらんに交流したいですね♪
貴方とお話しできることを、楽しみにしています。

パネル・ディスカッション、他

---

オンラインゲームのこれまでとこれから　～国内主要オンラインゲームのスタッフが送るパネルディスカッション～

セッションの内容

CEDECは今年で20周年を迎えます。
ゲーム業界もこれまで長くの年数を重ねてきましたが、ここ20年の歩みの中で忘れてはいけないジャンルがあります。
それが「MMORPG」に代表されるオンラインゲームです。
1997年にMMORPGの先駆けである『Ultima Online』がサービス開始となり、その後、国内でも様々なオンラインゲームが開発されました。
オンラインゲームといえば、これまでにない広大なステージ、とことんやり込める奥深さとコンテンツ量、そして何より、遠く離れた他のプレイヤーとのつながり。
これらの魅力的な要素を備え、多くのオンラインゲームがユーザーを虜にしました。
あれから20年が経ち、現在のゲーム業界はスマートフォンアプリが話題の中心になりつつありますが、その中でも、長年サービスを続け、まだまだユーザーの心を掴んで離さない多くのオンラインゲームがあります。
そのような魅力あふれるオンラインゲームの主要タイトルに関わるスタッフを一同に会し、これまでのオンラインゲームの開発・運営、これからのオンラインゲームの未来を、熱く語ろうではないか！というパネルディスカッションとなります。
●講演概要
◇各タイトル、登壇者の紹介
◇主要テーマによるディスカッション
・オンラインゲームの企画から立ち上げ
・オンラインゲームの開発・運営秘話　～直面する課題と解決に向けて～
・オンラインゲームが業界にもたらしたもの
・オンラインゲームとユーザーとのつながり
◇皆さんから事前に募集したテーマに応じたディスカッション
・聞きたい疑問質問、話してほしいテーマなどを募集します！
◇さいごに
・これからのオンラインゲームの未来
株式会社セガゲームス　オンライン研究開発部　『PSO2』シリーズプロデューサー　酒井 智史　他
8月22日(水) 13:30 〜 15:50（休憩含む）

---

ゲームグラフィックス20年の進化とこれから

セッションの内容

本セッションはTRY-Zの西川善司氏をモデレータ、ゲストに株式会社セガゲームスの厚孝氏、ソニー・インタラクティブエンタテインメントの山田裕司氏をお迎えしてゲームグラフィックスの20年を振り返り、その進化とこれからの期待を語るトークセッションです。20年とは世代を跨ぐ月日です。CEDECには幅広い年齢層の開発者が参加していますが、若い人にとってはレトロなゲームがむしろクールという価値感もでてきています。壮年の世代にとっては青春のハードかもしれません。各時代ごとに当時の制約を超える工夫や発明があり、限界を突破する進化を続けてきました。その進化の内容やきっかけを知ることは、今の開発にも生かせる大きな刺激となることでしょう。内容はグラフィックス寄りの話題を基本軸としていますが、映像表現、カメラ演出、アニメーションなど幅広く取り扱います。
株式会社セガゲームス　コンシューマコンテンツ事業部 第1CSスタジオ アドバンスト・テクノロジー開発チーム　チームマネージャー　厚 孝　他
8月23日(木) 13:30 〜 14:30

---

次世代QAとAI 〜ゲーム開発におけるAI活用に正しく向き合うために〜

セッションの内容

近年、AI分野の研究は大きく進捗しており、様々な業界で活用事例が増えてきました。こうした流れはゲームドメインにおいても起こっており、各社様々な試みが進んでいます。このパネルディスカッションは、ゲーム業界全体でどのようにAIと向き合うべきかを考えるきっかけになることを目的としております。

今回はAIの適応領域の中でも、特に開発・運用の品質管理に関わるユースケースにフォーカスし、話を展開していきたいと思っています。AIというと大きな期待値が先行してしまいがちですが、本セッションでは、モバイル・コンシューマ領域で実際にAI活用に取り組んでいるメンバーを集め、「現在の課題は何か」「AIに何ができて何ができないのか」「導入する際の障壁はなにか」といった現実的な目線で議論を広げていきます。
株式会社セガゲームス　第1CSスタジオ　リードプログラマー　阪上 直樹　他
8月22日(水) 17:50 〜 18:50

---

ここまでで紹介したセッションのなかに聴講したい！と思ったものはありましたか？
弊社だけでなく、多くの高レベルな講演の集まるCEDECは、8月の22～24日はパシフィコ横浜　会議センター(神奈川県横浜市西区みなとみらい)で開催されます。
それでは皆さんCEDECでお会いましょう！

私達は将来CEDECに登壇してみたいと思っている、技術に興味のある方を求めています。
以下にアクセスして一緒に働いてみませんか？
採用情報 | セガ企業情報サイト

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

ゲームサウンドクリエーターの役割

こんにちは。
セガゲームス開発技術部の塚越です。
主に戦国大戦や三国志大戦などのサウンド制作を担当して来ました。

これまでのこのブログの記事ではプログラマやテクニカルアーティストの方の記事が多かったため、そちらに興味の強い読者の方が多いかもしれません。
またゲームに必要不可欠なサウンドであってもあまりサウンドデザイナーと関わることがなく、何をやっているのか知らないという方も居ることでしょう。
そんな方達にぜひ知ってほしい、ゲームサウンドクリエーターの役割を簡単に解説していきます。

サウンドクリエーターの役割

サウンドクリエーターには実は色々な役割があります。
その中からいくつかの例を紹介していきます。

• 世界観やビジュアルから音の方向性を考える
• 音楽を作る
• 効果音を作る
• 音声を収録して編集する

この他にも色々な仕事があり、ゲーム内容や部署による違いなどもありますが、サウンドクリエーターがどんなことを考えてどのように仕事をしているのか、少しでも知っていただければと思います。

1.世界観やビジュアルから音の方向性を考える

いきなりですが少し想像して見てください。
音楽や効果音があるゲームの世界観や映像の質感にあっていない場合どう感じるでしょうか？
音ばかり気になってしまってそのゲームに没頭できなかったり、主人公に感情移入できなかったり、ということが起こりそうです。

音楽や効果音、ボイスでプレイヤーの感情が動かされるものであって欲しいものです。
そのためには世界観や映像の質感などをきちんと取り入れた音になっていなければいけません。

いきなり本番のデータを作り始めるのではなく、プロデューサーやディレクタ、ビジュアルデザイナーと相談をしながらどのようなサウンドスケープ（音の風景）にしていくのかを考えいくのか、まずはいわば音のコンセプトを考えていくことが重要となります。

ゲームのジャンルや取り扱っている題材などで何が重要な音になるのかが変わってきます。

方法は実に簡単です。
スマホなどで製作中のゲームをムービーで撮影します。
その後Apple Logic Pro XやSteinberg Cubase ProなどのDAWアプリケーション（Digital Audio Workstation）で、そのムービーに試しに作った音を置いていきます。そうすることでどんな音が必要か、どんな音楽なら心が動くか、を探っていくことができます。
さらにそれをチームの皆んなで試聴してもらい意見を交わし、この提案と修正を繰り返して行きます。
またその中で、サウンド再生の仕組みを考えたり実験したりする際にはプログラマの助けが必要不可欠です。

少し時間がかかってしまいますが最初にこの作業ができるのとできないのとでは、仕上がりに差が出てくるのです。
このようなコンセンサスがないまま作り進めていけば、いびつでチグハグな音になってしまうのは想像に難くないですね。

2.ゲームのBGMを作るとは

最近のゲーム音楽はゲーム中とサウンドトラックで聴くのとでは違う場合があることにお気づきでしょうか？
実はゲーム中ではゲームのプレイによって状況が変化するのとともに音楽が追従し変化しているのです。
このような手法はインタラクティブミュージックと言ったり、アダプティブミュージックと言ったりしますが、言葉は違えどほぼ同じことを指しています。

BGMは聞く人にどういう気持ちになってほしいかをダイレクトに伝えることができる手段の一つです。
例えば『ファンタシースターオンライン２』を思い浮かべてみてください。
フィールドで敵が居ない時は静かな音楽ですが、敵と戦闘状態になると激しい音楽へと音楽的に自然に変化しますね。*1*2
この様にBGMは気持ちを切り替えていたり、場面転換を気づかせたりという役割を担っています。

これは昔のゲームであっても実は使われている手法で、制限時間が近くなると音楽が早くなったり、水で溺れそうになると違う音楽が流れたりしていました。
それが今ではとても音楽的で自然な流れで行われるようになったのです。

インタラクティブミュージックの手法の例

このため、作る曲の量はとても増えましたし、プログラマさんとの連携もとても大切です。
ゲーム中のどのパラメータが変化したら音楽をどの様に変化させるかという設計図をしっかり作るところからがゲームのBGMづくりが始まっているということなのです。

3.効果音を作る

効果音を作るのには大まかに２つの手法があります。
1.　現実にある音を使う
2.　シンセサイザーで作る

現実にある音を作るには、現実にある音を使うというわりと当たり前と思われる手法を使います。
効果音の素材集の様なものを使ったりもしますが、フィールドレコーディングやフォーリーレコーディングをしたものを集めて使うこともあります。*3*4

現実にはない音を作るには、シンセサイザーを使って作るしかありません。

「プニョっ」とした音や、「ギュイーン」とした音など、想像でしかない音を効果音として形にします。
レーザー銃を想像してみてください。
実際本物のレーザーが「ビィーーーー」などと音はしませんが、ゲーム中では音がないと寂しいですよね。

ゲーム中の効果音には大切な音と、そこまで大切ではない音、全然大切ではないけど雰囲気を作る音がありますので、バランスを取りながら作って行くことになります。
※大切ではないからと言っていい加減な音は作りませんよ。

実際に音を作っていくプロセスを説明しますと

• 音のイメージを具体的に思い描く（頭の中で音を鳴らすイメージです）
• その音の要素を分解しDAW上でシンセサイザーや実際の音を使い再構築していく

という手順で作っていきます。

現実音に忠実な簡単な音は誰が作っても同じ音（近い音）になりますが、想像上の音や演出の入った音はとてもクリエイティブで、作るのに時間がかかります。*5

ディレクターやエフェクトデザイナと相談しながら作っていくことが多く、密なコミュニケーションが求められます。

DAWで効果音を作っている画面

4.音声の収録〜編集

近頃のゲームはスマホゲームでもよく喋りますよね。
この音声を収録したりゲームで使えるように編集したりするのも仕事です。

収録現場ではどの様な演技をして欲しいのかを声優さんに伝え、ゲームディレクターやシナリオライターが思い描いている演技に近づけるということもします。
それに加えてノイズが入ってしまっていないかなどを常にチェックしながら、台本も追って行くのでかなり気を使う仕事です。

ゲームの種類にもよりますが、5千〜数万のセリフを収録するのが最近では普通です。
こうなると何日もかかって収録することになりますので、演技のブレがないか、掛け合いがある部分に不自然さがないかなど確認することも多くなります。

また、ゲーム中でしっかりと聞こえる様にするために音量の調整をしたり、チェックを漏れたノイズを除去したりという編集作業があります。
ノイズが残ってしまうと、音量の調整でノイズが大きく聞こえてしまったり、不自然さが強調されてしまうため地味ですが大切な作業です。

近年ではiZotope RX6などのノイズ除去作業に優れたツールが出てきたため、少しくらいのノイズであれば演技重視でOKにしてしまうことも増えました。このソフトが出る以前のノイズ除去は波形を拡大してノイズ部分を特定し、全て手作業で修正するといった大変苦痛を伴う作業でした。
ですからなるべく収録現場でノイズを混入させずに収録するといったことが重要だったわけです。

RXによる音声の修正

まとめ

ここまで紹介した仕事以外にも多数の役割がありますが、長くなってきましたので今回はこの辺で終わります。なんとなくサウンドデザイナーの仕事をご想像いただけたでしょうか。
サウンドデザイナーはこれら全ての仕事を少人数で行なっています。また、ディレクターやデザイナー、プログラマーとの関わりをより強く意識する部門でもあります。

またサウンドは色々な感情（燃える、ドキドキする、爽快になる、優しい気持ちになる、暗い闇を感じる、など）と密接に関わっています。
サウンドデザイナーは自然に、時には主張して色々な感情を刺激する様に設計しています。
次にゲームをプレイする時には音に少し注目（注耳）してみてください。

(C)SEGA

*1:参考1：CEDEC 2012 2012年8月20日 Phantasy Star Online 2におけるプロシージャルBGMシステム

*2:参考2：CEDEC 2015 2015年8月27日 それからのPSO2BGM：プロシージャルを利用したオーダーメイドな場面表現・サウンドツールとプログラムの連携による簡略化

*3:フィールドレコーディング：簡単に言えば外に音を録りに行くことです。山奥や工場など色々なところへ出かけ目的の音を録音します。

*4:フォーリー：足音やものが当たる音をなどを専門に取ることができるスタジオを使った録音です。靴の質感や地面の素材などによって変化する足音を録ることができます。

*5:本当に現実音に忠実に音を作ろうとするととても複雑にレイヤーを重ねて周りの状況の変化に応じた変化を再現する様な作り方もありますが、とても大変な作業です。