公立はこだて未来大学2020年度システム情報科学実習
グループ報告書
Future University Hakodate 2020 System Information Science PracticeGroup Report

プロジェクト名
クリエイティブA.I.
Project Name
Creative A.I.

グループ名
シナリオ班
キャラクター会話班
視覚班
音響班
システム班
Group Name
Scenario Group
Character conversation Group
Visual Group
Audio Group
System Group

プロジェクト番号/Project No.
51

Creative AI

プロジェクトリーダ/Project Leader
大田翔貴 Shoki Ota

グループリーダ/Group Leader
福元隆希 Takaki Fukumoto
大田翔貴 Shoki Ota
齋藤慎悟 Shingo Saito
荻野永和 Towa Ogino
青山美月 Mitsuki Aoyama

グループメンバ/Group Member
天野太一 Taichi Amano
山本聖也 Seiya Yamamoto
元満丈寛 Takehiro Motomitsu
高橋利孔 Riku Takahashi
西谷秀市 Shuichi Nishiya
北清敦也 Atsuya Kitase
齋藤慎悟 Shingo Saito
大田翔貴 Shoki Ota
村井大輝 Hiroki Murai
青山美月 Mitsuki Aoyama
荻野永和 Towa Ogino
森本大翔 Hiroto Morimoto
小原大地 Daichi Obara
大場有紗 Arisa Oba
福元隆希 Takaki FukumotoGroup Report of 2020 SISP

2Group Number 5

Creative AI

指導教員
村井源 迎山和司 田柳恵美子 平田圭二 角薫
AdvisorHajime Murai Kazushi Mukaiyama Emiko Tayanagi Keiji Hirata Kaoru Sumi
提出日
2021年1月14日
Date of Submission
January. 14, 2021

Group Report of 2020 SISP

3Group Number 5

Creative AI
概要
本プロジェクトは,ロールプレイングゲーム(以下RPGとする)を構成する様々な要素のなかから,シ
ナリオ,キャラクターの会話,ビジュアルデザイン,音響,システムの5つの要素について,本来であれば人間が行う創造的な作業を代替できるような人工知能システムの開発を目的としている.また,成果物を統合し完成したRPGの評定を行うことが望ましい..
プロジェクトのメンバーは各要素に対する人工知能システムの開発を行うために,シナリオ班,キャ
ラクター会話班,視覚班,音響班,システム班の5つのグループに分かれて作業を行った.
現在,ゲームの統合を終え評価実験,学外活動について検討を行っている.

キーワード：人工知能,プログラミング,自動生成,RPG(*文責：福元隆希)

Abstract
This project’s goals are to develop and to assess artificial intelligence systems that are able to do creative works, which people should do when they produce computer role-playi
ng games, about scenarios, conversation of characters, visual designs, audio and game systems.
In addition to these goals, this project’s other goal is to integrate a completed computer role-playing game, and we hope to evaluate each artificial intelligence system.
Project members belong to either of five groups, Scenario team, Character-conversation tea
m, Visual team, Audio team or System team, and work each team to develop artificial intell
igence system for each component.
Recently, we finished the game integration. We are considering an evaluation experiment an
d academic conferences presentation.

Keyword：artificial intelligence, programing, automatically generation, computer role-playing game(*responsibility for wording of article：Takaki Fukumoto)Group Report of 2020 SISP

4Group Number 5

Creative AI
目次
第1章 はじめに1.1 背景1.2 目的1.3 課題第2章 プロジェクト学習の概要
2.1 課題の設定
2.2 到達目標
2.3 課題の割り当て
2.3.1 シナリオ班
2.3.2 キャラクター会話班
2.3.3 視覚班
2.3.4 音響班
2.3.5 システム班

第3章 中間発表までの開発
3.1 シナリオ班
3.1.1 世界観設定
3.1.2 引き継ぎ3.1.3 分析
3.1.3.1 物語論と構造パターン
3.1.3.2 作品選定
3.1.3.3 分析方法
3.1.3.4 作品の傾向
3.2 キャラクター会話班
3.2.1 データ収集
3.2.1.1 作品の選定

Group Report of 2020 SISP

5Group Number 5

Creative AI
3.2.1.2 収集方法・制限
3.2.2 データ分析方法の検討
3.2.3 自動生成アルゴリズムの検討
3.3 視覚班
3.3.1 自動生成の概要
3.3.1.1 方法の検討
3.3.1.2 分割作業
3.3.2 コンセプトアート
3.3.2.1 キャラクター
3.3.2.2 マップ
3.3.3 モデリング
3.3.4 アセット
3.4 音響班
3.4.1 データ収集
3.4.2 分析作品の検討
3.4.3 音響特徴量を抽出するプログラムの検討
3.4.4 感情特徴量の決定
3.4.5 後期への課題
3.5 システム班
3.5.1 それぞれやったこと
3.5.1.1 ゲームの基礎部分
3.5.1.2 マップ

第4章 中間発表
4.1 概要4.2 制作物
4.2.1 ポスター
4.2.2 動画Group Report of 2020 SISP

6Group Number 5

Creative AI
4.3 評価4.4 課題と検討
4.4.1 キャラクター会話班
4.4.2 視覚班
4.4.3 音響班
4.4.4 システム班
4.4.5 全体

第5章 成果発表までの開発
5.1 シナリオ班
5.1.1 カテゴライズ
5.1.2 データ収集
5.1.3 分析
5.1.4 メインシナリオ
5.1.5 データフォーマット
5.1.6 他の班との作業
5.1.6.1 キャラクター会話班
5.1.6.2 視覚班
5.1.6.3 音響班
5.1.6.4 システム班
5.1.7 自動生成するクエスト
5.1.8 アルゴリズム作成
5.2 キャラクター会話班
5.2.1 データ収集
5.2.2 データ分析
5.2.2.1 分析方法
5.2.2.2 分析結果
5.2.3 プログラム

Group Report of 2020 SISP

7Group Number 5

Creative AI
5.2.4 自動生成アルゴリズム
5.2.5 会話文の変換結果
5.2.6 成果発表に用いたデモンストレーション
5.3 視覚班
5.3.1 自動生成
5.3.1.1 自動生成の概要
5.3.1.2 データの分類
5.3.2 イラストデザイン
5.3.2.1 キャラクターイラスト
5.3.2.2 マップ
5.3.3 モデリング
5.3.3.1 人型素体モデル
5.3.3.2 主人公,ヒロイン
5.3.3.3 ミニドラゴン
5.3.3.4 小物類
5.3.3.5 敵キャラクター
5.3.4 アセット
5.4 音響班
5.4.1 データ収集
5.4.2

データ分析

5.4.3 学習させるまでの過程
5.4.4 ニューラルネットワークの実装
5.4.5 コード進行の自動生成
5.4.5.1 マルコフ連鎖
5.4.5.2 Songleを用いたコード進行分析
5.4.6 楽曲制作
5.4.7 他班との連携
5.4.7.1 シナリオ班

Group Report of 2020 SISP

8Group Number 5

Creative AI
5.4.7.2 システム班
5.5 システム班
5.5.1 他班との統合
5.5.1.1 シナリオ班
5.5.1.2 キャラクター班
5.5.1.3 視覚班
5.5.1.4 音響班
5.5.2 アクション
5.5.3 マップ
5.5.4 RPG要素

第6章 成果発表
6.1 概要6.2 制作物
6.2.1 ポスター
6.2.2 Webサイト
6.2.3 動画
6.3 評価6.4 課題と検討
6.4.1 シナリオ班
6.4.2 キャラクター会話班
6.4.3 視覚班
6.4.4 音響班
6.4.5 システム班

第7章 プロジェクト内のインターワーキング

第8章 まとめGroup Report of 2020 SISP

9Group Number 5

Creative AI
8.1 プロジェクト全体の成果
8.2 各グループの成果
8.2.1 シナリオ班
8.2.2 キャラクター会話班
8.2.3 視覚班
8.2.4 音響班
8.2.5 システム班
8.3 今後の課題と展望
8.3.1 全体
8.3.2 シナリオ班
8.3.3 キャラクター会話班
8.3.4 視覚班
8.3.5 音響班
8.3.6 システム班

参考文献

Group Report of 2020 SISP

10Group Number 5

Creative AI
第1章 はじめに1.1 背景人間は古来,創造性を用いて多くの革新的な芸術作品を生み出してきた.例を挙げるのであれば,文芸や美術,音楽やデザインなどである.これらは,人々が真にゆとりと潤いを実感できる心豊かな生活を実現していく上で不可欠なものである.
ゲームは物語,視覚表現,⾳楽表現,操作性, 没⼊感などを兼ね備えた総合芸術である.つまり, 「⾯⽩い」ゲームを⼈⼯知能で作ることができれば,創作のかなりのジャンルは網羅できたことになる.
現在,世界中でもゲームを自動生成する取り組みが行われている.成功例[1-1]としては, ダンジョ
ンの自動生成や, 一定数アイテムを入手して帰ってくるなど単純な作業を繰り返す,いわゆる”お使いクエスト”と呼ばれるものの自動生成が挙げられる.今年度,本プロジェクトが挑戦するのは,RPGのシナリオ,モブキャラクターの会話,キャラクタービジュアル,BGMの選択などの要素を人工知能を用いて自動生成することである.
(*文責：天野太一)
1.2 目的本プロジェクトの目的は, オリジナルの作品を創作できる人工知能システムを実現すること,そして,様々な創造的要素を持ち,需要に対する人手不足という背景のあるゲーム制作を通して人工知能の創造性を検討することである.今年度はストーリーが破綻していないゲームシナリオを生成し実行できるシステムの開発と, そのための適切な視覚化表現, 音響効果の構築,モブキャラクターとの会話を対象として取り上げた. ゲームは必ず決まっているストーリーが進行するのではなく,プレイヤーの意思で,プレイヤーが選択した選択肢によって,キャラクターとの友好度などが変化しストーリーが分岐する. また,馬場は,ゲームをすることでユーザは達成感や没入感,爽快感などの情感を感じると述べている[1-2]. 加えてゲームは, 美しい映像, 盛り上がる音楽など, さまざまなエンターテイン
メント要素を含んだコンテンツである.そのため,人の心を動かすオリジナル作品を創作できる人工知能システムを実現するうえで, ストーリー, 映像, 音楽のすべてに心を動かす要素が含まれている,
また,様々なユーザ体験を生み出すことのできるゲームを取り上げるのが最適であると考えた. 最終的には, 人が遊べるRPGを完成させる予定である.
(*文責：荻野永和)
1.3 課題目的を達成するために解決するべき課題は以下の通りである.

·

分析対象とするゲーム作品の大枠の決定·自動生成する際の分析方法の決定·

シナリオの構成の分析·分析したシナリオを元にした自動生成の実装·

泣ける構成を分析し,自動生成するプログラムの制作

Group Report of 2020 SISP

11

Group Number 5

Creative AI·

会話の分析や収集·

モブキャラクターの会話のトピックを作成し,会話文の自動生成の実装·

ゲーム内UIの制作·

モブキャラクターの行動パターンの決定·

ゲーム内要素の統合·

ゲーム内のキャラクターやステージの分析·

3Dモデルの作成·

コンセプトアートの制作·

自動生成に必要な顔のパーツのデータの収集·

音響特徴量の抽出·

シーンにあったBGMの選択,自動生成·

コード進行決定アルゴリズムの制作··各班で自動生成した3Dモデル,雰囲気にあったBGM,モブキャラクターの会話,容姿,メイ
ンシナリオの統合
キャラクターのアクション,カメラワーク

本プロジェクトでは, 分析対象とするゲーム作品の大枠の決定, 自動生成する際の分析方法の決定, シナリオの構成の分析,分析したシナリオを元にした自動生成の実装, 泣ける構成を分析し,自動生成するプログラムの制作, 会話の分析や収集, モブキャラクターの会話のトピックを作成し,会話
文の自動生成の実装, ゲーム内UIの制作, モブキャラクターの行動パターンの決定, ゲーム内要素の統合, ゲーム内のキャラクターやステージの分析, 3Dモデルの作成, コンセプトアートの制作, 自動生成に必要な顔のパーツのデータの収集, 音響特徴量の抽出,シーンにあったBGMの選択, 自動生成,
コード進行決定アルゴリズムの制作, 各班で自動生成した3Dモデル, 雰囲気にあったBGM, モブキャ
ラクターの会話, 容姿,メインシナリオの統合, キャラクターのアクション, カメラワークのシステ
ムを課題とした.
(*文責：元満丈寛)Group Report of 2020 SISP

12Group Number 5

Creative AI
第2章 プロジェクト学習の概要
2.1 課題の設定
本プロジェクトは,「⾯⽩い」ゲームを⼈⼯知能で作ることが目的である.ゲームには様々なジャンルがある.初めに,どのジャンルのゲームが「面白い」ゲームをつくるために適切かを話し合った.その結果,プロジェクトメンバー全員がイメージしやすい,RPG形態のゲームが採用されることとなった.
そして,RPGを「面白い」と感じさせる要素について議論した結果,「泣けるシナリオ」,「モブキャラ
クターとの会話」,「状況によって選択されるBGM,SE」,「アクション要素」という5つの意見が上がった.我々は,それらを「面白い」ゲームを作るための課題と設定し,それぞれ5つの班に分かれてゲームを作成した.
(*文責：森本大翔)
2.2 到達目標
本プロジェクトの達成目標は,人工知能を使用しゲームを作ることである.ゲームの要素ごとに5つの班に分かれアクションRPGを作る.
シナリオ班は感動するシナリオを目指して「泣けるシナリオ」,キャラクター会話班は物語に深みを持たせるために「モブキャラクターとの会話」,視覚班は魅力的なキャラクター作りのために「モブキャラクターの容姿」,視覚班はより物語の世界観やシーンの雰囲気に合う「BGMやSEの選択」,シ
ステム班は他班の製作したゲームの要素を1つにまとめ,より快適にゲームをプレイさせることを目的とした.
また,シナリオの自動生成システムでは,生成されたシナリオが面白いかどうか,矛盾がないかどうかなどをアンケートで回答してもらい,その結果を分析をし,音響班では,BGM,SEがそのシーンに合っているかどうかのアンケートを実施する予定である.
(*文責：青山美月)
2.3 課題の割り当て
2.3.1 シナリオ班
シナリオ班では,プロジェクトの役割としてゲームクエストのシナリオを自動生成することを課題としている.シナリオの自動生成に必要な,シナリオの構造分析,自動生成アルゴリズム,データベースの作成を一年を通して行っていく.また,シナリオ班は「泣ける」シナリオの自動生成を今年度の目標としている.しばしばシナリオが存在する創作物の評価に「感動」という言葉が利用される.しかし,
感動は心が動かされた状態と定義され,観測することは難しくそれゆえに定量化もまた困難である.一方,「泣ける」ということは様々な心の動きの結果であり,過程を観測することはできずとも「泣く」という事象を観測することができる.人の涙を引き出す物語データとして集めることで「泣ける」シ
ナリオを自動生成することが可能であると仮定し,この目標を設定した.今回,制作するシナリオはRPGのクエストシナリオであるが,クエストシナリオも物語の1つととらえ,シナリオの構造分析にRPGだけ
でなく,他のゲームや漫画,小説,アニメも分析対象とする.またのデータをラベリングする手法として物語論の考え方を取りいれることでデータ収集を容易にし,システムとしての実現可能性を高める.
(*文責：福元隆希)Group Report of 2020 SISP

13Group Number 5

Creative AI
2.3.2 キャラクター会話班
キャラクター会話班では,ゲームに登場する会話文を自動生成することを課題としている.課題を実現するために,実際のゲームに登場する会話文を収集し,事前に定義した属性に分けたキャラクターごとに会話文を分析する.その後,分析した結果を用いて,自動生成アルゴリズムの実現を目指す.モブキャラクターはゲーム内の世界観を構成する上で,重要な要素である.しかし,モブキャラクターの会話
文を人間が用意しなければいけない.そこで本年度は,モブキャラクターの会話文を自動生成することを目標としている.
(*文責：髙橋利孔)
2.3.3 視覚班
視覚班では,主にゲームのビジュアル要素のデザインを行っている.ビジュアル要素はゲームを楽し
むうえで必要なものであり,ストーリーやキャラクターの魅力を引き出す重要な要素になりうる.そこで,キャラクターや背景などのデザインや3Dモデルの作成を行い,これを表現する.ゲーム内には多くのキャラクターが登場するが,モブキャラクターが占める割合は多い.それらのモブキャラクターを限られた作業量で作成できるようにするため,AIにモブキャラクターの顔を自動生成してもらうアルゴ
リズムの作成も行う.AIにデザインを任せることで作業量を大きく軽減することができる.自動生成に必要な顔のパーツのデータの収集やプログラムの作成を行うことによって実現していく.
(*文責：山本聖也)
2.3.4 音響班
音響班ではゲームの各シーンでプレイヤーがゲームに没入感を感じてもらえるように音楽を設定する作業を人間ではなく人工知能に学習させ,実現することを目標に活動を行っている.ゲームの中でシーンに合ったBGMやSEを自動生成し,挿入することでゲームがより引き立てられると考えた.
今回は,人工知能に学習させるためのデータを収集し,感情特徴量の設定や音響特徴量を抽出することで,ゲームに使用されている音楽を分析し適切な音楽が出力できると考えた.また,人工知能にコー
ド進行を学習させることでさらに適切なBGMをゲーム内に実装できると考えた.具体的には,マルコフ連鎖を用いることにした.
課題の割り当てとして,感情特徴量の分析・決定,学習させるためのデータ収集・分析,音響特徴量を抽出するプログラムの仕組みの学習,BGMの自動選択,コード進行の自動生成に分けて成果発表までの期間,活動を行った.
(*文責：元満丈寛)

2.3.5 システム班
システム班では,各班の作った人工知能によって生成された「泣けるシナリオ」,「モブキャラクタ
ーとの会話」,「モブキャラクターの容姿」,「雰囲気にあったBGM」や,そのほかゲームに必要な3Dモデル,メインシナリオを1つのゲームに統合すること,直感的で操作が容易なゲームにしより多くの人に楽しくゲームをプレイしてもらうことを目指した.
具体的には,マップ上の適切なポイントで,セリフダイアログやBGMを出したり,変えたり,消したり,といったことを全てテキストファイルから読み取り,ゲーム内に反映させた.

Group Report of 2020 SISP

14Group Number 5

Creative AI
そして,アクションRPGらしい直感的で痛快なゲームシステムを作り上げるためにUIや,キャラクタ
ーのアクション,カメラワークのシステムなど良いものになるように検討して行った.
(*文責：青山美月)

Group Report of 2020 SISP

15Group Number 5

Creative AI
第3章 中間発表までの開発
3.1 シナリオ班
3.1.1 世界観設定
世界観とはゲームを構成する要素として欠かせない部分である. 世界観を決めることで, シナリ
オ, 音響, 視覚などの芸術的要素に自然とまとまりが生まれ, 全体のイメージ共有が容易になる. よって, ジャンルがRPGに決定した後の各班との話し合いの中で, 世界観を一刻も早く決めるべきではないか, という意見から, プロジェクトの作品の世界観を決める流れに至った. 世界観を決める際に, どのような方法を用いれば, 全員が平等に意見を交わせるか, といった観点から話し合った結果, 各班で意見交流をし, グループリーダーが全体で意見を発表するという形になった. 視覚班から
は「人類文明が滅んだ後の世界」といった意見や, シナリオ班からは「プレイヤーの感情を揺さぶるために, 人や何かの生死に関わる一本の物語」という意見があった. 加えて, 「無難に中世ファンタ
ジーも良いのではないか」という意見もあった. また, 「ジャンルはRPGのため, シナリオがしっかりしている方が良い」, 「プレイヤーの感情に訴えかけるシナリオ」など, いくつかの要望もあった. そこで話し合いを円滑に進めるべく, Google driveなどを利用し全員の意見を並べ, シナリオ班
が希望を見て, なるべく全員の意見を反映する努力を心がけ, 世界観およびシナリオの基本的な流れを決定することになった.
シナリオ班で, 全員の意見を反映する努力を心がけ, 話し合いを進めた結果, 世界観はシナリオ班が目標とする「泣ける」シナリオを実現させるため, 人や何かの生死が必然的に存在し, 違和感なく物語に溶け込めるであろう, 「人類文明が滅んだ後の世界」に決定した.
シナリオの基本的な流れを決定する上で, 人類が滅んで数世紀後の世界になった時, もし人類に生き残りがいたらどこに隠れ, 生き延びるかという観点から, 人間は地下シェルターに町を作り, 暮ら
しているという設定を設け, 話し合いを進めていった. 他班からの意見を取り入れながら, 決定したシナリオの基本的な流れは以下の通りである.
内容：襲ってくる敵(姿形は未定)がいる.
目的：別のシェルターに行く. 加えて, 目的達成のための謎解き要素を取り入れる.
スタート：シェルター.
エンディング：別のシェルターに着くと, ラスボスが現れ, 主人公たちは勝利するが, ラスボスは自爆してしまい, 中立な町にいる生物もしくは機械生命体に助けられる.
決定したシナリオの基本的な流れを全体に共有した後, 他班から「より詳細な世界観の設定を知りたい」といった意見や, 「敵のビジュアル, 武器, シェルター内の設定, 主要キャラクターの設定など, よりイメージが湧くものが欲しい」という意見から, 改めて世界観設定の内容及び, その他の設定を深めていくこととなった. 設定を深めていく際, シナリオ班でDiscordを用い, 話し合いを行った. まず初めに, 人類が滅亡した理由やヒロインの裏設定を考えた. 人類が滅亡した理由は, 元軍事用ロボットを管理していた知能を持った機械生命体が反逆を起こしたという設定に決定し, ヒロイン
はシェルターを襲われ, ミニドラゴンを連れて旅をしていたという設定も加えた. その裏設定を基に, 詳細な情報を加えたシナリオの基本的な流れは, 以下の通りである.
1：主人公が, シェルターの維持装置であるコアの様子がおかしいのに気づく.

Group Report of 2020 SISP

16

Group Number 5

Creative AI
2：ヒロインがやってくる.
3：主人公とヒロインが会話をし, コア自体が限界だとヒロインに教えてもらう.
4：別のシェルターにもらいにいかなければならなくなる.
5：目的地に行くための関所を越える.
・関所での謎解きの後, 中ボス戦で勝つが, ヒロインが殺されそうになるのをミニドラゴンが庇い,死亡する. そして, ミニドラゴンの力がヒロインに継承される.
6：別のシェルターにたどり着く.
・クエストをある程度こなすとコアを渡すイベントが発生する.
・第一章のボスに襲われる(知能を持った人間型の機械).
・主人公たちは, ボスに勝利するが, ボスには知能があり, 死にたくないと懇願する. しかし, 情報を残さないためのシステムによって, 爆発し消滅してしまう. そして, 主人公及びヒロイン, 都会の街にいた一部の人は機械と人間が共存している街に助けられる.
また, その他の設定は以下の通りである.
・主人公
シェルターの維持者である. シェルターの維持装置であるコアの不良によって外に出る必要があ
る. 武器：近接武器, 防具：敵を倒して得たポイントをステータスに変換.
・ヒロイン
ドラゴンを秘密裏に育てる種族が集まっているシェルター出身である. 学者が多いシェルターからやってきた女の子であり, ミニドラゴンを連れている. 戦闘では前半はサポート, 後半はミニドラゴ
ンの力を受け継ぎ, 戦闘に参加する.
・ミニドラゴン
戦闘に参加し, 戦闘方法は火を吐く. 科学の力で伝説の生物が蘇った.
・敵基本的に自律的に動く元軍事用のロボットである. 生物の心臓を自らのエネルギー源とする.
・初期シェルター
田舎のようなイメージである.
・シェルターの維持装置コアを用いている.
・たどり着くシェルター

Group Report of 2020 SISP

17

Group Number 5

Creative AI
サイバーで都会なイメージである. ロボットの攻撃を防衛し, 進化していった
・人間と機械の共存するシェルター
畜産・漁業(川)または, 養殖が盛んに行われ, 一次産業で生きている. 機械は年老いた家畜の心臓を糧にしている. 人間もロボットも生きるために共存を選んだ.
・中継地点
回復地点であり, ヒロインとの会話イベントにも利用可能な場所である.
シナリオ班では上記のように簡単に情報をまとめた後, プロジェクトメンバーの物語のイメージがより湧き上がるよう, 詳細な情報を加えた「バックグラウンドストーリー」を作成した. バックグラ
ウンドストーリーは, 基本的にシナリオや作中で表沙汰にはならない設定が記されているが, より一層, シナリオを深めていくために重要な資料であり, 加えて, 他班とのすれ違いをなくしていくために有効であると考え, 前期の活動で用いることに決定した. バックグラウンドストーリーでは, まず初めに, 世界観, ロボット・機械生命体の設定, コアの設定, ドラゴンの設定, シェルターの設定など物語に深く関わる環境的要素について決定した. 環境的要素の決定した設定は以下の通りである.
・世界観
2601年, 人間は地球上の資源を使い果たし, 新たなエネルギー源を求め, 宇宙でコアの原料となる
宇宙エネルギーを発見した. それ以来, 人類の文明発達はコアを主要に著しく進歩した. しかしながら, コアの価値は時が経つにつれて, 世界全体で重要視されていった. また, 政府は昔からの伝承として伝わりし, ドラゴンの存在に関する研究を水面下で進め, コアの力と科学の発展によって, ドラ
ゴンの復元を成し遂げていた. 加えて, 軍事用の自律移動式ロボットを開発し, 知能を持つ機械生命体を使用し, ロボットの管理を行っていた. だが, 2652年にロボットの管理権を持つ機械生命体が反逆し, 軍事用ロボット及び, 人型で知性があるロボットが暴走したことをきっかけに, 人類が滅亡の危機へと追いやられた. 人類は, 核兵器の攻撃に備えるために設備されていたいくつかの核シェルタ
ーに逃げ, 隠れて生活することになる. それから, 500年の月日が経ち, 人類が恐怖に怯えたロボッ
ト・機械生命体からの襲撃は人類史に大きな爪痕を残した.
・ロボット・機械生命体の設定-自律移動式ロボット
自律移動式ロボットは, 元々軍事用の様々な形態のあるロボットである(例：ダイオウグソクムシ型, 狼型, ドローン型, ゴーレム型など). 基本的には太陽電池からエネルギーを手に入れることが出来るが, 人間の心臓から大きなエネルギーを得ることが出来るため, 人間を優先的に襲う. また,エネルギーを得る条件として, 動物の心臓でも代用はできるが, 人間だけを襲うようにプログラムされているため, 機械生命体などから上位命令を受けない限りは動物を襲わない.
-機械生命体
機械生命体は, 人型で知性や感情を持っている. 自律移動式ロボットとは異なり, 学習するため,物語において主人公達の強敵になる. また, 武器を用いて戦闘する. システム上, 情報漏洩の防止のために機械生命体の生命活動が脅かされる状態に陥ると自爆するようにプログラムされている. 自律移動式ロボットと同様な条件でエネルギーを手に入れることが出来る. ちなみに, シェルターCを襲った機械生命体は, シェルターCの住民の手によって多くの仲間(自律移動式ロボット)が殺され, 復Group Report of 2020 SISP

18

Group Number 5

Creative AI
讐の機会を狙っていた. しかし, 主人公とヒロインとの戦闘に負け, プログラムの指示で自爆を余儀なくされる. だが, 機械生命体は死ぬことは望んでおらず, 主人公とヒロインに助けを求めるが自爆してしまい, シェルターCの住民及び主人公, ヒロインを巻き込み, 消滅してしまう.
・コアの設定コアは特別な容器に宇宙エネルギーを注入することにより, 動作する. 宇宙エネルギーを注入したコアを用いることで, 莫大なエネルギーを生み出すことができる. コアの容器の大小で, 入れることのできる宇宙エネルギーの量が決まっており, 大きいものほど, コアの寿命が長い. 宇宙エネルギー
は固体・液体・気体のいずれにも当てはまらない未知のエネルギー(例：光のようなもの)である. コ
アはシェルターのエネルギー源として, 非常に重宝されており, シェルターの最深部で専門的な技術者により, 管理・運用されている.
・ドラゴンの設定
ドラゴンは白亜紀に地球上に生息していた翼竜(プテラノドンなど)と, 植物食恐竜(トリケラトプ
スなど)の化石をかけ合わせた状態で, 恐竜復元技術とコアによって復元したものである. 復元した
後の姿・性質は, 伝説で言い伝えられているドラゴンに非常に似ているため, そのまま, ドラゴンと名付けられた. ドラゴンの存在は政府によって, 秘匿されており, ドラゴンの復元・育成・繁殖は,数十名の科学者によって, 秘密裏に進められてきた. 人類が滅亡危機に陥った後も, ドラゴンは科学者と一緒にシェルターに移され, 研究は世代をまたいで行われている. 性格は, 植物食恐竜のような温厚な性格を持っており, 雑食である. 加えて, 身の危険を感じると火を吹き, 凶暴で野性的な一面も見せる. 高い知性を持っており, 知性を持っている人間に懐きやすい. また, ドラゴンは死に直面すると, 心を通わせた知性の高い人間と契約し, 自らの力を継承することができる. ちなみにヒロインが連れているのはドラゴンの子ドラゴンである. 子ドラゴンでも, 成体ドラゴンとの能力差はそれほど変わらない.
・シェルターの設定
人類が核兵器の危機に襲われた時のために事前に用意された核シェルターを利用している. 人類の脅威を核兵器と想定しているため, 一次放射線や爆風, 散らばった放射性降下物やそこから発せられる二次放射線による被爆を避けるため, シェルター内はコンクリートで覆われ, 深さ5~85mに作られている. 加えて, 深さは, 地域によってばらつきがある. 防火・遮蔽・気密などの機能があり, 最低
限, 自給自足の生活が送ることができるような環境が整っている. 2601年にコアが発見されたことにより, 核シェルターの維持装置にコアが用いられるようになった.
-シェルターA(主人公出身シェルター)ロボット・機械生命体からの襲撃は風化した伝承となり, 外の危険性を知りつつも, シェルター内で500年も安全に過ごすことができているため, シェルターの人間はすっかり安心しきってしまっている. 人口は10～30人ほどの小さな規模であり, コアの容量は500年分の大きさで宇宙エネルギーが枯渇しそうな状態になっている. 経済生活の基礎を農業としており, 住民の多くが農業を営んでいる. ほぼIT農業を取り入れており, 水やりや複雑な肥料配合を自動で行っている. また, シェルター
内では, 昇降エレベーターやIT制御盤(自動の水やり/肥料配合をコントロールする), コアの管理を行う維持管理局がある. 維持管理局では先祖代々の仕事をある家系(ちなみに主人公がその家系)が継いでいる. シェルターの出入り口の昇降エレベーターは地上の洞窟などの奥の空間に設置されており, 洞窟から地上に出る際は頑丈な扉があり, 生体認証で, 人間の瞳の特徴を感知し, 開けることができる.

Group Report of 2020 SISP

19

Group Number 5

Creative AI-シェルターB(ヒロイン出身のシェルター)人類史滅亡危機以前に政府が水面下でドラゴンの研究を行っていた研究員達の子孫達が住んでいる. 人類が滅亡危機におかれた後も, シェルター内で, ドラゴンの研究を続け, 人類文明の歴史をひも解いてきた学者が集まるシェルターである. ドラゴンと人間が共存している. 30～60人の住民がいる. 他のシェルターの知識もあり, 地上の状況や, 自律移動式ロボット・知能がある機械生命体への情報を持っている. シェルターAと同じように昇降エレベーターがあり, 地上に出るもしくは, 地上からシェルターに入るには人間の瞳の特徴を感知する必要がある. 稀に, 地上に出てフィールドワー
クを行っていた. フィールドワークに行ける学者はシェルター内での幹部から認められた者と限られているが, ヒロインは認められていないのにも関わらず, 深夜シェルターから抜け出した. その結果, フィールドワークに慣れていないヒロインは, シェルターに戻る際に, 機械生命体に見つかってしまい, 大規模な襲撃を受け, シェルターBの生き残りはヒロインとミニドラゴンだけになり, 実質滅亡に追い込まれた.
-シェルターＣ(最終目的地のシェルター)地上で単体行動をしている自律移動式ロボットを狙って資材にしているシェルター. 地上のロボッ
トを資材にするために, シェルター内から遠隔操作で地上の防衛設備を動かして倒し, 安全の確認を行った後, 回収している. 人口は200人～300人程度でコアの容量は4000年程と大きく, 自律移動式ロ
ボットを倒して, 資材を集めているため, 活気がある. 具体例としては, ロボットを資材にするための溶鉱炉, 多い人口を集約するための住宅街・商店街, 近未来的プランテーション, その他の産業施
設, コアや防衛設備の管理を行う防衛局がある. シェルターＣの住民はロボットを資材としてしか見ておらず, 普通に資材として利用するだけでなく, 現代のように鹿の頭を飾る・熊の剥製を飾るというような感覚で, ロボットの部品を飾る文化がある. その文化が生まれた経緯としては, 人類がロボット・機械生命体に追いやられた歴史に対して強い嫌悪感を抱いており, ロボットを倒すことや倒したロボットの部品を飾ることにより, 自己満足を得ていることがある. 主人公は, コアの動力源である宇宙エネルギーを得るために, 防衛局からのクエストを進めていくことになるが, 宇宙エネルギーをもらう直前または直後に, ロボットと機械生命体の襲撃を受け, シェルターＣは壊滅してしまう.
次に, バックグラウンドストーリーでは主人公及び, ヒロインの設定など, 物語の主要となるキャ
ラクターの性格や経歴を深めていった. 物語の主要キャラクターの決定した設定は以下の通りである.
・主人公の設定
名前：未定
一人称：僕または, 俺
性格：目の前で困っている人がいれば, 助け, 間違っているものには間違っていると断言できる. また, いつも自分に正直であり, 素直な人間である.
経歴：シェルターＡの出身. 昔からの決まり事で管理維持局に家族と共に務めている. 家族構成は,
母親と父親, 妹と自分の4人家族. 母親と妹は, IT制御盤の管理をしていて, 主人公と父親は, 昇降エレベーターとコアの管理を担っている. 幼少期から, 機械やコアについて興味があり, 趣味で, パ
ワーグローブ(パワースーツでもあり)などの開発を行っている. ある日, 昇降エレベーターのメンテ
ナンスを父親に任され, 行っていた際にヒロインが昇降エレベーターで降りてくる場面に遭遇する.
その際, 主人公は不審に思うも, ヒロインの傷ついた姿やシェルターに住まわせてほしいという想い

Group Report of 2020 SISP

20Group Number 5

Creative AIを受け, 主人公はヒロインを信用し, シェルターに住まわせようとするが, 他の住民がヒロインを信用しない. そこでクエストを通して住民のヒロインに対しての信頼度をあげることでヒロインを住まわせることができるようにする. ヒロインに対しての住民の信頼度が最大になった時, 固定イベントが発生する. イベントの内容としては, 以前からコアの調子が悪いことをヒロインに伝えると, エネ
ルギーが枯渇しそうで他のシェルターにもらいに行かなければいけないことを教わり, 仕事は家族に任せ, 案内役のヒロインとともに旅に出ることになる. エンディングでは, 機械と人間の共存した地
上にある町を知り, 誰もが幸せに生きていくためには共存が必要なのではないか, そのためにこれからどうするのかを葛藤していく姿を描いていく.
・ヒロインの設定
名前：未定
性格：好奇心があり, 生命に対して愛を持っている.
一人称：私
経歴：シェルターBにもともと住んでおりドラゴンの飼育をしていた. 家族構成は父親と母親, 自分の3人家族. 幼少期から外の世界やドラゴンについて興味があり, 勉学にも力を入れていた. フィー
ルドワークに参加したいとは思っていたが, 資格を持っておらず, フィールドワークに携わることは出来なかった. その反動から, 外の世界を知りたいという気持ちが膨れあがり, 資格がないのにもかかわらず深夜に外に出てしまった. その結果, 帰りにロボットに見つかってしまい, シェルターBが襲撃されてしまう. その際, 父親と母親にかばわれた事で襲撃から逃れ, シェルターBの最後の生き残りとなる. その後, 同じく生き残りのミニドラゴンとともに, 壊滅したシェルターBを出て, 世界を学びながら2年間外を彷徨い続ける. その果てにシェルターAを見つける.
前期の活動においては, 世界観の決定に加えて, 基本的なシナリオの流れを構築し, 不足している
情報を補うバックグラウンドストーリーを作成し, 他班との効率的なイメージ共有を実現することが可能になった. また, バックグラウンドストーリーで補えない部分に関しては, 随時話し合いを設け, お互いの理解を図ることができた.

(*文責：大場有紗)
3.1.2 引き継ぎ
現在の進歩として, 中間発表のために用意したデモシナリオでは, キャラクターの行動, 感情の推移, セリフなどをすでに明示的, もしくは暗示的に示している. しかし, シナリオテキストをそのま
まプログラムに通しても, コンピュータは内容を理解できず, 処理できない. 加えて, 後期の活動では「泣ける」シナリオの書き起こしを自動で行うために, 書き起こしの規則を定めなければならな
い. そのため, 今年度も昨年度と同様に, コンピュータでも, どのようなシナリオの構成要素が場面に存在しているか理解できるように, また, 誰が書いても同じような形式で書き起こせるような規則を決定する必要があった.
そこで, 前期の活動では, 「泣ける」シナリオを自動生成するための礎石として, 昨年度の「データフォーマット」の引き継ぎを行った. 昨年度と同様に, シナリオをコンピュータが理解できるよう, シナリオデータを定められた規則に従って, 成型する作業を「データフォーマット」と定義しGroup Report of 2020 SISP

21

Group Number 5

Creative AI
た. 昨年度は, 渡されたシナリオを, 1：場面に存在する要素をカテゴリーごとに分類, 2：カテゴリ
ーごとにタグ付けを行った. また, タグ付けの詳細については下記に示す.
・Event(フラグ名, マップ名, オブジェクト名, 1｜2｜3)
Event()は, そのイベントが起こるための条件・イベントの形式などを示している. 書いてある条件に合致しなければ(falseであった場合), イベントは発生しない. フラグ名では, フラグがtrueかを示す. cE1は発生, cE2_1, 2, 3は経過, cE3は結末を表している. マップ名では, 指定されたマップにいるかを示す. マップ名には, Map1~8のマップ番号を指定することが出来る. また, Map1~8のマ
ップ番号は, 各マップが対応しており, マップ番号の詳細は以下の通りである.
Map 1：孤児院前(koziin-mae)
Map 2：孤児院中(koziin-naka)
Map 3：地下室(Tikasitu)
Map 4：孤児院裏(Koziin-ura)
Map 5：初めの街アルトリーヨ(Arutori-yo)
Map 6：のどかな農村トフー(Tofuu)
Map 7：城下町オズ城下町(Oz)
Map 8：ダンジョン(Dungeon)
オブジェクト名では, 指定したオブジェクトを感知したかを示す. オブジェクト名には, OB1~9のオブジェクト番号を指定することが出来る. また, OB1~9のオブジェクト番号は, 各オブジェクトが対応しており, オブジェクト番号の詳細は以下の通りである.
OB1:ランドマーク1：町ごとに指定が異なる.
OB2:ランドマーク2：町ごとに指定が異なる.
OB3:町の家の中：家の中の特定の場所
OB4:アルトリーヨとトフーを行き来する場所：水辺付近
OB5:アルトリーヨとオズを行き来する場所：町の入り口付近
OB6:オズとトフーを行き来する場所：町の入り口付近
OB7:ダンジョンのスタート位置
OB8:ダンジョンの最深部
OB9:町の中のダンジョンに行く入り口
1｜2｜3では, どの表示形式で行うかを示す. 表示形式は以下の通りである.

Group Report of 2020 SISP

22

Group Number 5

Creative AI
1：立ち絵表示
2：一枚絵表示
3：テキストウィンドウのみの表示
・pMap
場所の宣言をするタグである. pMap1やｐ街などのように表す. 立ち絵のあるイベントの時に使用する.
・pT
一枚絵の宣言をするタグである. pT0, pT10などのように表す. 一枚絵で表すシーンの時に使用する.
・ｃ
フラグを表すタグである. ()内で0|1またはテキストを用いて管理する.
cC, cB, cE, cM, cI, cI0の種類があり, 各詳細は以下の通りである.
cC：操作可能かどうかを示す.
cB：この後にどの戦闘が発生するかを示し, ()内に名前を指定することが可能である.
cE：どのイベントのフラグが立ったか, もしくはおろすかを示す.
cM：どのマップに移動できるかを管理する.
cI：どのアイテムを取得したかを示す. ()内に名前を指定することが可能である.
cI0：どのアイテムを喪失したかを示す. ()内に名前を指定することが可能である.
・r
キャラクターを指定するタグである. r1で「1番目のキャラクター」を指定し, 立ち絵のあるイベントの時に使用する. また, キャラクターの向きや位置を指定する際には, d, fを用いる. 各詳細は以下の通りである.

d：キャラクターの向きを指定する. 左右のみ指定ができ, dE(East), dW(West)で表す.
f：キャラクターの位置を指定し, ()内に0~3を入れて管理することができる. 0は左手 前, 1は右手
前, 2は左奥, 3は右奥を示す.
・g
カット情報のタグである. g1はヒロイン, g2は主人公で固定されている. テキストウィンドウの左上部に表示されるキャラクター名の指定をする.

Group Report of 2020 SISP

23

Group Number 5

Creative AI・s?@
セリフのタグである. s1@と書くと, 「1番目のキャラのセリフ」を表す.
・w
座標移動のタグである. イベント後に, 指定したマップに移動するために使用する.
・z
シーンの終わりのタグである. 1つのイベントの中に, 複数のシーン(場面)があると見なしている.
これはその複数ある各シーンの終わりを表している.
・End
イベントの終わりを示す.
・e
感情を表す. []内に8種の感情を0. 0~1. 0で小数第一位までで表す. 感情の詳細は以下の通りである.
e[1, 2, 3, 4, 5, 6, 7, 8]
1：宗教的, 荘厳, 真面目
2：悲哀, 暗さ, 失意
3：感傷, 優しさ, 幻想
4：平穏, 満足, 鎮静
5：ユーモア, 奇抜, 優美
6：喜び, 陽気, 明るさ
7：興奮, 劇的, 激情
8：力強さ, たくましさ, 堂々
・#n
メインテキスト内とサブテキスト内に存在する. テキストの挿入場所, 内容を表す. サブテキスト
内の#nと#nの間にある内容をメインテキスト内の#nの場所に挿入する. #nには数字ごとにそれぞれ決まった種類の内容を記述するようにしている. 詳細は以下の通りである.
#0~#9：本文の内容である. 特に, #3は発生から結末へ挿入する文章が指定されている.
#10：依頼で要求されるアイテムの名前が入る#11：イベント中に登場する敵モンスターの名前が入る.

Group Report of 2020 SISP

24

Group Number 5

Creative AI#12：情報. 敵モンスターの弱点, アイテムの在処などが入る.
#13：依頼を達成した時に報酬として, 貰えるアイテムの名前が入る.
#14：依頼主の名前が入る. これはキャラクターの口調などに参照される.
#15：マップ(探索区域). イベントにおいて, どのマップを探索するのかを名称で指定する.
#16：マップ(開放区域). イベントを達成すると行くことが可能になるマップを名称で指定する.
#17：マップ(探索区域)数字. 探索先のマップをマップ番号で表す, 主にシステム側が使用する.
#18：マップ(開放区域) 数字. 行けるようになるマップをマップ番号で表す, 主にシステム側が使用する.
#19：どのマップで依頼が発生したのかを指定する, オブジェクト番号とペアにして使うことで依頼発生場所を特定する.
#20：どのオブジェクトで依頼が発生したのかを指定する, マップ番号とペアにして使うことで依頼発生場所を特定する.
データフォーマットの規則については, 大半は昨年度の規則を踏襲しつつ, 「泣ける」シナリオを自動で書き起こすために, より認知的負荷が低く, 簡単な管理にするべく, 主にシステム班と協議を進め, 新しいデータフォーマットの規則の簡単な見通しを立てた. また, 昨年度のデータフォーマットの規則を参照しながら, 今回のプロジェクトにおいて, 各班が求める要素を明確にするため, 随時
話し合いを行った.
(*文責：大場有紗)
3.1.3 分析
3.1.3.1 物語論と構造パターン「泣ける」シナリオの自動生成を行うためには,特徴を見つけ出すことができるほどのデータが大量に必要となる.データから特徴的な物語の構造パターンを見つけ出すことで「泣ける」シナリオ作
成をシステムに落とし込むことが可能となる.そこで,シナリオ班ではシナリオをシーンに区切り,各シーンにラベルを付ける方法として物語論の考え方を利用する.
(*文責：福元隆希)
3.1.3.2 作品選定
RPGだけでなく物語構造が存在するもの,その他のジャンルのゲーム,アニメ,小説,漫画などもデー
タ分析の対象とした.データ分析の対象とする作品の選定方法として,インターネットのサイト等で複数人に「泣ける」と評される作品に対してシナリオ班の中で合議し対象とするかどうかの決定を行った.その結果,アニメーション作品からは鉄拳のパラパラ漫画4作品[3-1,2,3,4],漫画からONE PIECE[3-5],RPGからFINAL FANTASY X/X-Ⅱ[3-6]など計11作品が対象となった.
(*文責：福元隆希)Group Report of 2020 SISP

25

Group Number 5

Creative AI
3.1.3.3 分析方法
シナリオの自動生成にあたり,アルゴリズムの作成に世間一般に「泣ける」と評価されている物語
作品の構造パターンのデータが必要であると判断した.そのために物語の構造が明示的に分かる分析
方法を取り,作品群の構造をデータ化することにした.
まず,物語全体をシーンを単位として分割し,どのシーンが泣けるシーンであるかを決定した.次に,KJ法を用いてそのシーンの泣ける要因を調べて分類し,カテゴリーとした.また,シーンに対して泣ける要因が適切に付けられない部分は,物語そのものではなく物語の叙述技法に泣ける要因があると考え,技法として別にカテゴリー分けした.最後に,泣ける要因のカテゴリーがどのような内容で成り立っているか,及びどのような手法で行われているかを考え,表にした.
この表を基に,他の作品群も同じようなカテゴリーで構成されているのか,分析を行った.表作成と同様に物語全体をシーンごとに分割し,泣けるシーンを抽出,抽出したシーンの泣ける理由をカテゴリ
ー分けし,技法が使われている場合は使われている技法をタグ付けした.この方法を用いることで,泣ける物語における所謂「泣かせどころ」がどのように出現するのか,またカテゴリーがどのように遷移しているかが分かりやすくなる.このデータを多数収集することで,泣ける物語の基本パターンを分析することができる.
(*文責：小原大地)
3.1.3.4 作品の傾向
前期時点で実際に分析を行ったのは,YouTubeに公開されている鉄拳作のパラパラ漫画作品「約束」,「お父さんは愛の人」,「母のサポーター」,「振り子」の4つである.これらの作品は物語が短く,泣ける物語の要素検討において適していた.また,オンラインでの活動であったため,合議を重ねる
上でインターネット上に無料公開されている物が適していた.これらの作品は特徴上台詞や地の文が存在しないため,一部の解釈をシナリオ班内で決定している.
これらの作品はそれぞれ3部構成となっている.それぞれについて泣けるシーンを分析した.「約束」は大きく分けて「父親の死」,「母子の葛藤」,「家族関係の修復」の場面に分かれている.泣けるシーンとして,父親の死の場面では,人物の死への悲しみのシーンがいくつか見られた.母子の葛藤のシーンでは,残された家族の葛藤や苦悩のシーンが続いていた.家族関係の修復の場面では疎遠になっていた家族が関係を修復し,信頼関係を築きなおすシーンが連続していた.
「お父さんは愛の人」は「父親との思い出」,「父親の認知症」,「父子の関係修復」の場面に分かれている.父親との思い出の場面に泣けるシーンは見られなかったが,父親の認知症の場面では娘がいくら心配しても伝わらないやるせないシーンが見られた.父子の関係修復の場面では父親の呟きによって父親の変わっていない人間性を感じられるシーンが連続している.
「母のサポーター」は「母の死と過去の再体験」,「母親の苦労」,「息子の感謝」の場面に分かれている.母の死と過去の再体験の場面では泣けるシーンは見られないが,母親の苦労の場面に移ると序盤からの流れを受けた母親の苦労や辛い人間の優しさのシーンが見られた.息子の感謝の場面では,再体験して思い出した過去の母親の苦労に対して感謝と後悔を感じるシーンが連続している.
「振り子」は「家庭の築きと崩壊」,「女の自我喪失」,「男と女の死」の場面に分かれている.家
庭の築きと崩壊の場面では泣けるシーンとして娘の生まれた幸せや家庭を崩壊させてしまった男の葛藤が見られた.女の自我喪失の場面では日常が失われた悲しみのシーンが見られた.男と女の死のシー
ンでは女が反応を示し,二人の関係が修復されたシーンが続いていた.

Group Report of 2020 SISP

26

Group Number 5

Creative AI
これらの作品に共通して,序盤には情報提示が多く泣けるシーンが少ないこと,中盤に何かを喪失す
る悲しみや辛さでの泣けるシーンが多いこと,終盤に失ったものや新しいものを獲得する喜びや安心での泣けるシーンが多いことがわかった.今後は分析対象を広げ,この泣ける物語構造がパターンとして別作品にも当てはまるかを検証する.
(*文責：小原大地)

3.2 キャラクター会話班
3.2.1 データ収集
3.2.1.1 作品の選定
キャラクターの会話の文体を自動生成するアルゴリズムを作成するにあたって,多くの会話データを用意する必要がある.本項では,会話データを収集する作品の選定について記述する.
会話データを収集する際に,多くの良質なデータを効率良く集めることが重要である.このことを念頭に置き,収集対象となる作品を選定した.
まず,選定対象作品としての条件を3つ決めた.
1つ目は,対象作品のゲームジャンルをRPGとすること.RPGであれば,多くの会話文のデータが集めることができると考えた.なぜなら,多くのRPGは物語進行の道中において,会話データを持つ多くのモブキャラクターが出現することを特徴としているからである.さらに,今回の収集対象となるデータはモ
ブキャラクターの会話データであるため,RPGは選定対象のゲームジャンルとして最も適している.
2つ目は,多くの作品があるシリーズ物であるということ.データ収集と分析において,データ形式として偏りをなくす必要があった.そのため,できるだけデータ形式に変更がないデータを収集することができるシリーズ物を選定条件とした.
3つ目は,多くの人に買われている作品であること.会話文を自動生成にするにあたり,しっかりとした会話文を出力する必要があった.そこで,多くの人に認められている作品,つまり,多くの人に買われている作品であれば,会話文がしっかりと出来ているものであると考えた.
以上の3つの条件を踏まえた上で,以下の作品を収集対象作品とした.
・Final Fantasy Ⅰ [3-7]・Final Fantasy Ⅱ [3-8]・Final Fantasy Ⅲ [3-9]・Final Fantasy Ⅳ [3-10]
・Final Fantasy Ⅴ [3-11]
・ドラゴンクエスト [3-12]・ドラゴンクエストⅡ 悪霊の神々 [3-13]
・ドラゴンクエストⅢ そして伝説へ… [3-14]

Group Report of 2020 SISP

27

Group Number 5

Creative AI・ドラゴンクエストⅣ 導かれし者たち [3-15]
・ドラゴンクエストⅤ 天空の花嫁 [3-16]
・ポケットモンスター 青 [3-17]・ポケットモンスター クリスタル [3-18]
・ポケットモンスター サファイア [3-19]
・ポケットモンスター プラチナ [3-20]
・ポケットモンスター ブラック [3-21]「Final Fantasy」シリーズは2020年11月までに全15作もののナンバリング作品を販売しており,シ
リーズ全タイトルの累計出荷数が1億5900万本以上を達成した大人気シリーズである.また,「ドラゴンクエスト」シリーズも2020年11月までに全11作もののナンバリング作品を販売し,シリーズ全タイ
トルの累計出荷数が8000万本以上を達成している大人気シリーズである.さらに,「ポケットモンスター」シリーズは2020年11月までに全33作品のメインシリーズ作品を販売し,2016年2月時点の25作品の累計販売本数は2億100万本を達成している.
今回は,各シリーズからナンバリングの若い順で5作品ずつを収集対象とした.
(*文責：大田翔貴)
3.2.1.2 収集方法・制限
データ収集するためには,収集するデータの種類や収集における制限を決めなければならない.なぜなら,複数人で行うため,全員が同じ意識で収集する必要があるからだ.本項では,収集の方法と設けた制限について記述する.
会話データを収集した際に,記録するソフトウェアはMicrosoft Excelを用いた.また,属性ごとの会
話の文体特徴を抽出するために,発話者の発話内容に加えて,発話者の性別と年齢の記録を行うこととした.
性別は男性と女性の2種類で,年齢は子供,成人,老人の3種類の計6種類となる属性を記録した.収集するキャラクターの属性を判別する方法は見た目で判別するものとし,その際の判別基準を設ける.性別は「髪の長さ」と「服装」に注目し,年齢は「背丈」,「姿勢」,「髪色」で判別を行った.例えば,
髪が長く,スカートを履いていたら,女性と判別する.また,背丈が大きく,姿勢として腰が曲がっていて,髪色が白い場合,老人と判別する.このようにして,性別と年齢の判別を行った.
収集方法は,マップ上に配置されているキャラクターに話しかけ,画面に表示された発話内容をExcelの1つのセルの中に入力した.
次に,データ収集における制限を4つ決めた.
1つ目は,収集対象はモブキャラクターの発話内容に限定する.なぜなら,自動生成する発話内容の発話者がモブキャラクターであるからである.また,主人公などのストーリー進行に関わるキャラクター
は,個性を出すために特徴的な文体を用いている可能性があるため,収集対象からは除外することになった.
2つ目は,モブキャラクターの中でも,イベントシーンに登場するモブキャラクターの発話内容は収集対象としない.なぜなら,イベントシーンでは,モブキャラクターでも特徴的な文体を用いている可能性があると判断したからである.
3つ目は,収集するモブキャラクターは性別と年齢が明確に分かるキャラクターに限定する.シナリ

Group Report of 2020 SISP

28

Group Number 5

Creative AI
オ上,被り物などで性別や年齢が分からないキャラクターが存在することがある.このような場合,正しい属性を収集することが不可能である.また,収集作品の特徴上,マップに表示されるキャラクター
はドットで表されているため,見た目で属性の判別が困難な場合がある.その場合は,グループのメン
バー全員で話し合い,属性を判別した.
4つ目は,収集する発話データの対象範囲は,1つ目の村から4つ目の村の前までとした.最後の村まで収集することになると,1つのゲームをクリアするまでやることとなってしまうため,時間が大幅にかかってしまうことになる.さらに,収集作品がRPGであるため,レベル上げの作業などに時間がかかってしまう.これらの事を踏まえたうえで話し合った結果,限られた時間で効率よく,多くの発話データを収集できるのは1つ目の村から4つ目の村の前までが最適であると判断した.
以上の4つの制限の下に,データの収集を行った.
(*文責：大田翔貴)
3.2.2 データ分析方法の検討
収集した会話文をCSVファイルとして保存し,プログラムを利用して品詞ごとに分解する.その後,各属性ごとに分解した品詞を集計し,KJ法を用いて分類を行う.分類した結果から,各属性での特徴的な語用を評価する.また,品詞ごとに分類する際に,地名やプレイヤーの名前,キャラクター名などの固有名詞は一般化できるように会話文に変更を加え,対応する語をプログラムに辞書登録させて分析を行う.
(*文責：髙橋利孔)
3.2.3 自動生成アルゴリズムの検討収集したデータを分析し会話文の自動生成アルゴリズムの実装を行う.会話文自動生成アルゴリズ
ムでは,ある文章を入力すると設定した話者属性に合わせた会話文に変化・生成する処理を行う.図3.
2.3-1は会話文自動生成アルゴリズムのイメージである.

図3.2.3-1 会話文自動生成アルゴリズム

図3.2.3-1では「今日はいい天気」という例文をアルゴリズムによって「今日はいい天気ね」のよ
うに文体特徴を変化させている.アルゴリズムの流れは,トピックである「天気」に対して,成人/女性という話者属性を加えることで成人の女性風の会話文を生成するというものである.他にも,成人/男Group Report of 2020 SISP

29

Group Number 5

Creative AI
性という話者属性を加えると「今日はいい天気だな」のような文章を生成し,老人/女性という話者属性を加えると「今日はいい天気ですね」のような文章の生成されることが期待される.後期では,始めに男性・女性で文体特徴が異なる会話文生成を行うプロトタイプの作成を行う.
(*文責：北清敦也)

3.3 視覚班
3.3.1 自動生成の概要
3.3.1.1 方法の検討
モブキャラクターの顔の自動生成を目的としている.自動生成された顔を原案として,人間の手でブラッシュアップしゲーム内で使用する立ち絵などを作成する.
自動生成の方法としては,漫画に登場するキャラクターから主に正面を向いたものの画像を集め,目や鼻などのパーツに分割する.その際,キャラクターの属性を決める要素も記録しておく.今回自動生成するモブキャラクターの属性としては,少女・女性・おばあさん,男の子・男性・おじいさんである.属性を入力するとその属性をもつ顔パーツを組み合わせて福笑いと同じ要領で自動生成を行う.実際に自動生成を行うプログラムの作成については後期に行う予定である.プログラム作成の際の課題として,収集した顔パーツの位置と縮尺がそれぞれのデータの中で統一されていない点が考えられる.
同じ大きさの透過画像を重ね合わせて,画像を生成する場合と,パーツごとに縮尺を変えて画像内に配置して生成する場合でデータの扱い方が異なるため収集したデータのフォーマットに高い統一性が必要である.属性を一つ入力すると複数の顔の画像が作成されるが,作成された画像の中からどの画像を使用するかなどの選考基準についてはまだ検討中である.また,選考基準をもとに画像を選考することまでを自動化するかについても検討中である.
顔の画像は収集したデータを組み合わせて生成するため,生成された顔に幅をもたせるためには多数のデータが必要である.顔パーツのデータ数を増やす方法として,photoshopのモーフィング機能などの仕様を検討している.モーフィングとはある2枚の画像の中間画像を作り出し,1枚めから2枚めに徐々に変化する映像を作成する技術である.photoshopのモーフィング機能で作成した中間画像として出力しデータの増量を測る.
データ増量の方法の2つ目としてGANを用いた方法が考えられる.GANとは敵対的生成ネットワークである.GANにはDiscriminator(以降,D)とGenerator(以降,G)の2つの人工知能が存在し,DがGの生成したものを評価しフィードバックを送り,Gはそれを受け再度Dに生成したもの評価させる.GはDの評価が最大になるまで続ける.この技術を用いてデータ増量を測る.しかし,Dの人工知能を作成するのに今回のモブキャラクターの顔を自動生成するために必要なデータ数より遥かに多いデータ数を必要とすることが課題である.
(*文責：齋藤慎悟)
3.3.1.2 分割作業
モブキャラクターの自動生成に必要なデータとして漫画のキャラクターの顔画像を収集し,それを顔のパーツごとに分割した.分割した顔のパーツは,髪,眉,目,鼻,口,輪郭の6種類である.正面を向いたキャラク－の画像を集め,顔の部分のみを500px×500pxの画像のできるだけ中心に来るように配置
して,レイヤー機能のあるイラスト作成ソフトを用いて顔パーツに分割した.

Group Report of 2020 SISP

30

Group Number 5

Creative AI
イラスト作成ソフトでの作業上のフローとして,キャンパスサイズを500px×500pxに設定し,顔がその中心になるように配置する.このとき元画像の縦横の比率が変わらないように注意する.画像を2値化し白黒画像を生成する.顔パーツをレイヤーに分けてそれぞれ保存する.
今回は少女・女性・おばあさん,男の子・男性・おじいさんのキャラクターを自動生成するため,それらに分類するための情報として年齢と性別が必要なため,共有可能なスプレッドシートにキャラク
ターの名前,性別,年齢の順で記入していく.データ集収終了後にGASを用いて,スプレッドシート上のテーブルをjsonファイルに変換し,自動生成に使用する.
データ収集する際にキャラクターの持つ主人公などのロール情報は今回使用しない.収集するキャラクターは人に限定し,キャラクターのロールや年齢,性別は限定しない.ただし年齢については設定上のものではなく,見た目から受ける印象でデータを入力している.複数の顔パーツを組み合わせて自動生成を実現させるためより多くの画像を生成するためには多数のデータが必要である.予定する期間で集めたデータ数が自動生成に必要な数に達しなかった場合には3.3.1.1で記載した方法を用いてのデータの増量を検討している.また,グループメンバーそれぞれで集めたデータの管理方法としては
現在google driveを使用しているが,3.3.1.1で記載した方法でデータ数を増やす事になった場合の管理方法や保存場所について検討する必要がある.
(*文責：齋藤慎悟)
3.3.2 コンセプトアート
シナリオ班が作成したゲームの世界観やキャラクター等のイメージを絵として表現することは重要である.文字や議論でプロジェクトメンバーがゲームに対して持つイメージを統一できたように思えても,既存知識や価値観によって想像される視覚的なイメージはメンバー毎に大きく異なるからである.実際のゲーム業界でもコンセプトアーティストという仕事が存在するように,シナリオライターとクリエイターの橋渡しをし,円滑に制作をすすめていくことが必須である.コンセプトアートに着手す
る前にシナリオ班やシステム班とよく話し合うことで文字だけでは汲み取れない細かな希望を受け取ることが出来たり,こちらからの提案が良いアイデアとして採用されたりなど,相互作用でどんどんイ
メージが練り上げられていった.今回我々はシナリオ班が作成した「キャラのバックグラウンドスト
ーリー」からキャラクターデザイン,「世界観設定」からマップのデザインを行った.
(*文責：西谷秀市)
3.3.2.1 キャラクター
シナリオ班が作成したバックグラウンドストーリーをもとにキャラクターデザインを行った.メイ
ンとなるキャラクターは主人公,ヒロイン,ミニドラゴンの3体である.数少ない人類が地下のシェルターで生活しており,シェルター毎に町の雰囲気や着るものに違いがあるという設定を踏まえ,奇抜になりすぎないもののアクションRPGらしい目を引くカラーリングになるようキャラクターデザインを制作した.簡単なラフを描き,視覚班やシナリオ班で確認をとったあと,ペイントソフトで1枚のキャラク
ターデザイン画を作成した.

Group Report of 2020 SISP

31

Group Number 5

Creative AI

図3.4.1.1-1 キャラクターデザイン画(*文責：西谷秀市)
3.3.2.2 マップ
視覚班のメンバーでゲームに必要となる様々な要素についてイメージを広げていくために画像を収集した.google keepに張り付けていくことで画像に「シェルター」「昇降機」「地上」等のラベルをつけてまとめた.
まず初めにゲームでプレイヤーが行動することになる「シェルター」や「地上」について,プロジェクトメンバのイメージを統一するために世界観に関する簡単なスケッチを制作した.

図3.3.2.2-1 世界観のスケッチ
主人公が暮らすシェルター（以下,シェルターAと呼ぶ）が第一のマップなので,早急にイメージを視覚化した.このゲームではシェルターといっても暗くて狭い閉鎖空間ではなく,人が暮らしを営むのに十分な機能を持った巨大な居住区といったイメージである.主人公は牧歌的な自然が広がる田園風景が特徴的なシェルターで暮らしている.google keepに集めた画像を見ながら,ヨーロッパの田園地
帯や建物を参考に,ゲームとしてワクワクするようなデザインになるようにも心がけて,シェルターAのマップデザイン画を制作した.

Group Report of 2020 SISP

32

Group Number 5

Creative AI

図3.3.2.2-2 シェルターAのマップデザイン画
続いてラスボス戦が行われる最後のシェルター（以下.シェルターCと呼ぶ）のイメージを視覚化した.シェルターCはサイバー感あふれる近未来的な街であり,シェルターAに比べるとよっぽど都市として発展している.

図3.3.2.2-3 シェルターCのマップデザイン画(*文責：西谷秀市)
3.3.3 モデリング
ゲーム内に登場するキャラクターや武器,その他小物類などを 3Dモデルにすることがこのモデリングという作業である.ゲーム内で実際に登場し,動作したり配置されたりするのはこの3Dモデルである
ため,その重要性は言うまでもなく高いものである.そのため3Dモデルの作成は正確かつ慎重に,また作成する数が多いため,ある程度の早さをもって行わなければならない.

Group Report of 2020 SISP

33

Group Number 5

Creative AI
3Dモデルの作成はBlenderというソフトを使って行った.今年の視覚班の中ではBlenderを過去に経験していたという班員がいなかったため,まずはBlenderの使い方を学習するところからのスタートとなった.3Dオブジェクトの変形・拡大・移動に加え,ショートカットのような基本的な動作などは班員各自で動画や本などを見て学習し,その他の発展的な技術については,はこだて未来大学4年迎山研究室の白石さんに適宜教えてもらいつつ学習を進めていった.
ある程度技術を習得し終わったところで,一度実践を兼ねて武器の3Dモデルの作成を行った.作成を試みたのは杖・剣・斧の3種類である.期限は1週間とし,各自で試行錯誤しながら武器のモデルを作成していった.1週間後に作り上げた3Dモデルを持ちより,白石さんを交えてモデルの改善点を話し合った.杖に関しては当初持つ部分を円柱からつくっていたが,自然物感を出すために持つ部分を歪な形状になるようにモデリングしていった.また杖の先端部分はポリゴン数がとても多くなってしまい,実際にUnityで表示するときに問題が起こる可能性があるため,ポリゴン数を減らしつつ形状を維持するため持つ部分と同じようにモデリングしていった.剣に関してはソリッドモデルにした際に陰影の状態がおかしいことが判明したため,モデルが崩れないようにしつつ分解し,ミラー機能を駆使して修正を行った.その後にも白石さんからの助言を受けながらモデルの細かな修正を行っていった.

図3.3.3-1 杖と剣の3Dモデル

その修正が終わった後,3Dモデルに色をつける段階に入った.3Dモデルの色付けはBlender及びペイ
ンターソフトであるSubstance Painterを使って行うが,その手順は複雑であり,中々理解しにくいものであった.この色付けにおいても先輩からの助言を受けながら進めていった.この段階では斧に加え,後からモデリングが完成したチェーンソーの2つに色付けを行った.斧はSubstance Painterを用いてテクスチャを貼り付けるという手法で色付けし,持ち手部分の木材の質感と,鉄部分の金属の質感を出すことに成功した.チェーンソーはBlenderで色付けを行ったが,こちらも問題なく色をつけることができた.Blenderでモデリングした後そのまま色付けを行うことができ,Substance Painterで読み込
み直すという手間がなくなるため,他のモデルにおいても大半はBlenderで色付けを行う方向性に決まった.

Group Report of 2020 SISP

34

Group Number 5

Creative AI

図3.3.3-2 斧とチェーンソーの3Dモデル(*文責：山本聖也)
3.3.4 アセット
ゲーム内に登場する全ての3Dモデルを作成することは不可能である.これは時間的な制約はもちろん,技術不足によるものもある.そのためゲームに登場する多くの部分でアセットを用いることにした.アセットとは「素材」のことで既に完成されているもののことを指す.上記の理由から,今回は無料で配布されているアセットを組み合わせて使用することにした.
アセットを使うことは時短の面でも手軽で簡単であるが,何でもあるものを使えばいいわけではな
いということに注意したい.ゲームには世界観やテーマがあり,それに適したものを選ばなくては,ゲームをプレイした際にプレイヤーが世界観に違和感を感じてしまう可能性が大きい.そのためアセットを選ぶ際には視覚班だけではなく,他の班の方々にも参加してもらい,一緒に選考を行った.複数の班の多人数で選ぶことで世界観のズレや違和感などをできる限り解消できると思われる.
話し合いを進めた結果,前期の間で使うことが予定されているアセットは,マップの情景や建物,敵
キャラ,人型のモーションとなっている.
(*文責：山本聖也)
3.4 音響班
3.4.1 データ収集
シーンに適したBGMを選択するための準備として,様々なジャンルからいくつかのBGMを収集した.収集したBGMは,著作権フリーものであり,これをテストデータとすることにした.
(*文責：荻野永和)
3.4.2 分析作品の検討
シーンに適したBGMを自動で選択するためには場面の傾向を取り,曲のBPMや曲調を分析して場面とB
GMの関係性を調べる必要があると考えた.
始めに音響班は音楽の基本について学ぶことにした.音響班の担当指導教員に,音楽に関する講義を開いていただき,音の構成や周波数などを学んだ.これにより,自動選択に必要な曲の構成や要素に関する知識を身に着けた.また,昨年度のプログラムの中身を先輩方から教えて頂きながら学習し,プログラムの改善点や引き継ぐ点を洗い出した.

Group Report of 2020 SISP

35

Group Number 5

Creative AI
その後分析する作品について検討した.分析対象として,シナリオ班が自動生成した物語に対して自動で選曲するために同系統の作品を分析することが一番良い分析結果が得られるのではないかと考えた.そこでRPG作品となる「ドラゴンクエスト」や「ゼルダの伝説」などの,世界観に則したゲームタ
イトルを選択した.これらのゲームは世界的に有名であり,様々なシリーズが登場しているのでさらに深い分析が行えると予想した.
(*文責：荻野永和)

3.4.3 音響特徴量を抽出するプログラムの検討
まず,昨年度の音響特徴量を抽出するプログラムを学習した.その後,抽出する音響特徴量について
メンバー間で話し合い, 昨年度に引き続きスペクトル重心,クロマベクトル,BPMに決定した.
(*文責：荻野永和)

3.4.4 感情特徴量の決定
ゲームの各場面やキャラクター同士の会話の中では,その場に適したBGMが流れるか, もしくは無音の状態になる.今年度は昨年度に引き続き,場面に合ったBGMを選択するために用いる感情特徴量を決定した.感情特徴量とは悲しい,明るい等のことで,具体的にはHevnerの八つの印象語群を用いて決定した.Hevnerの八つの印象語群[3-21]とは,意味の近い表現語を一つのグループにまとめ,計8グループ
で感情を示したものだ.今回は, 第1グループに「怖い, 冷静な, 宗教的な」, 第2グループに「暗い,憂鬱, 悲しい」, 第3グループに「夢のような, 感傷的な, 優しい」, 第4グループに「穏やか, 静かな, 抒情的な」, 第5グループに「優雅な, 滑稽, 奇抜な」, 第6グループに「明るい, 幸せ, 派手
な」, 第7グループに「爽快, 興奮, 衝動的」, 第8グループに「力強い, 雄大な, 重苦しい」をそれぞれ採用した. これにより,ゲームのシーンごとの感情量を読み取り,それを数値化することでシーンに適したBGMを選択する. データ分析の際に, 各シーンがどのような雰囲気であるかを数値化された
感情特徴量で表し, その時に流れているBGMを紐づけることで, シーンとBGMの関係性をcsvファイルにまとめる.

(*文責：荻野永和)

3.4.5 後期への課題
前期では,音響特徴量を抽出するプログラム,何を入力データとするかを検討した.また、分析する
ゲームについての話し合いを行った. 後期では,音響特徴量の抽出やニューラルネットワークを用い,実際にシーンに適したBGMを選択するプログラムを作成する他に,コード進行の自動生成にも挑戦した
いと考えている.コード進行の自動生成の手順についてはまだ詳しく検討していないが,まず音楽理論について学習する必要があると考えている.
.
(*文責：荻野永和)

Group Report of 2020 SISP

36

Group Number 5

Creative AI
3.5 システム班
3.5.1 それぞれやったこと
3.5.1.1 アクション
システム班では,ゲームを作成にあたり,ゲームエンジン,”Unity”を使用した.
前期では,アクションゲームにおける基本的な動作であるプレイヤーの移動/回避/攻撃を作成した.

Player_move.cs
プレイヤーを動かすためのスクリプト,Player_move.csを作成した.

プレイヤーの状態の制御●

public enum PlayerState

まず初めに,プレイヤーが今どういう状態か,またその状態を制御するために,enum型のPlayerStateを作成した.これはpublicであり,他のスクリプトからも参照出来る.実際に作成した状態は,{Normal,
Damage,Attak,AttackCoolDown,Attack2,Dodge,DodgeCoolDown,Dead}である.Normalはプレイヤーの待機,移動,Damageはダメージを受けている,Attackは攻撃1段階目,AttackCoolDownは攻撃後のクールダ
ウン,Attack2は攻撃2段階目,Dodgeはプレイヤーの回避,Deadはプレイヤー死亡の状態を表す.

●

private PlayerState state

実際にスクリプト上で状態を判断する変数は,PlayerState型のstateという変数である.

●

public void SetState(PlayerState tempState)stateはprivateであり,他のスクリプトからも制御できるように,SetStateという関数を作成した.
引数としてPlayerState型の変数を受け取り,stateを指定された状態にする.後述するanimatorのトリ
ガーの発火もここで行われている.

プレイヤーのアニメーションの制御
プレイヤーのアニメーションを制御する方法として,UnityのAnimatorを使用した.Animatorは,オ
ブジェクトのアニメーションを管理するものである.実際にAnimatorを制御するにはSetTrigger,SetB
oolという関数が使用された.

移動の制御Group Report of 2020 SISP

37

Group Number 5

Creative AI
プレイヤーを移動させるために,Unityの機能の一つであるCharacterControllerを使用した.Char
acterControllerは,カプセル型の当たり判定を設定し,それをスクリプトにより動作させるものである.このCharacterControllerを主人公に設定することで,プレイヤーの自由な動きが可能となった.

●

private float x,zfloat型の変数x,zで,キーボードの入力を受け取る.Unityの機能,Input.GetAxisを使用し,x方向には水平方向の入力(キーボード上ではa,d,←,→),z方向には垂直方向の入力(キーボード上ではw,s,↑,↓)を受け取る.これにより受け取った値を,Vector3型の変数moveDirectionに代入する.

●

private Vector3 moveDirection

moveDirectionにプレイヤーのスピードをかけ合わせたものが最終的な移動方向,移動速度になる.
主に,CharacterControllerを移動させる,CharacterController.Move()という関数に代入される.また
移動の停止の時にはこの値を0にする.

2つの異なる移動方法
移動方法に2つのパターンを用意した.WalkingとRunningである.Input.GetKey()でキーボードの
左シフトボタンを受け取り,それが押されている間プレイヤーは走る.

●[SerializeField] private float runSpeed,walkSpeed

走るときの速度は,float型の変数runSpeedとして定義されている.runSpeedはUnityの機能である[SerializeField]が使用されている.この機能は,Unityのインスペクター上で自由に編集することが出来るものである.これを使用することにより,速度の調整が容易となった.一方,Input.GetKey()でキーボードの左シフトボタンが入力されていないときは,同様にfloat型の変数walkSpeedを定義し,それを[SerializeField]として設定した.

回避の制御
●

[HideInInspector] public bool isDodge

プレイヤーの回避には,UnityのAnimator機能が役に立った.初めに,bool型の変数isDodgeを作成す
る.isDodge = trueの間は,後述する関数TakeDamageは無視される.isDodgeは,回避行動が始まるタイ
ミングで,true,回避行動が終了するタイミングでfalseになる.回避行動のタイミングは,Animationにイベントを付与することで判定した.回避するには,キーボードのスペースボタンを押す.Input.GetKe
yDown()でキーボードの入力を検知する.

攻撃の制御Group Report of 2020 SISP

38

Group Number 5

Creative AI
プレイヤーの攻撃には,前述のAnimatorとCharacterControllerが役に立った.Animatorによって,攻撃の開始されるタイミングを検知し,そのタイミングで武器の当たり判定をONにし,攻撃の終了にはOFFにするという動作を組み込んだ.攻撃するには,マウスを左クリックする.Input.GetKeyDown()でマウスの入力を検知する.さらに攻撃の2段目も作成した.stateがAttackCoolDownの間に再度マウスの入力をすると,攻撃の2段目が発生する.

ダメージを受けているときの制御●

public void TakeDamage(double damage,Transform enemyTransform)

この関数は,主に外部のスクリプトによって呼び出される.もし呼び出されたら,プレイヤーの動作を停止し,stateをDamageにする.さらに,後述するPlayerStatus.cs内のHPを減らす.HPがなくなった時は,後述するDeadという関数を呼び出す.

死亡時の制御プレイヤーの死亡はstateにより判断される.Update内の動作ほぼすべては,stateがDeadでないときにのみ行われる.プレイヤー死亡後の動作は未実装である.

●

public void Dead()

これは単に,stateをDeadにするためだけの関数である.主にTakeDamageによって呼び出される.

ステータス
主人公,敵,武器の3つにステータスを付与した.主人公は体力/基礎攻撃力/基礎防御力といった3つのステータスを持つ.敵は,体力/基礎攻撃力/斬撃防御力/打撃防御力といった4つのステータスを持
つ.武器は打撃攻撃力/斬撃攻撃力/銃撃攻撃力といった3つのステータスを持つ.主人公/敵が攻撃を受けた時には,それぞれのステータスが参照され,最終的にそれらが計算されて実際のダメージとなる.
体力の表示を分かりやすくするために,体力ゲージを作成した.体力ゲージは実際の内部の体力と連動して動き,体力が増えると,ゲージも増え,体力が減るとゲージも減る.

●

PlayerStatus.cs

プレイヤーのステータスを制御するためのスクリプトとして,PlayerStatus.csを作成した.プレイ
ヤーのHP,防御力,攻撃力といったものが設定されている.さらに,プレイヤーの体力ゲージの管理も行う.

Group Report of 2020 SISP

39

Group Number 5

Creative AI●

EnemyStatus.cs

敵のステータスを制御するためのスクリプトとして,PlayerStatus.csを作成した.敵のHP,防御力,
攻撃力といったものが設定されている.さらに,敵の体力ゲージの管理も行う.

●

WeaponStatus.cs

武器のステータスを制御するためのスクリプトとして,PlayerStatus.csを作成した.武器の攻撃力が設定されている.

●

Enemy_move.cs

敵を動かすためのスクリプト,Enemy_move.csを作成した.

敵の状態の制御●

public enum EnemyState

敵が今どういう状態か,またその状態を制御するために,enum型のEnemyStateを作成した.これはpub
licであり,他のスクリプトからも参照出来る.実際に作成した状態は,{Walk,Wait,Chase,Attack,Cool
Down,Damage,Dead}である.Walkは敵の移動,Waitは敵の待機,Chaseはプレイヤーを追いかけている,At
tackは攻撃,Damageはダメージを受けている,AttackCoolDownは攻撃後のクールダウン,Deadは死亡の状態を表す.

●

private EnemyState state

実際にスクリプト上で状態を判断する変数は,EnemyState型のstateという変数である.

●

public void SetState(EnemyState tempState, Transform targetObj = null)stateはprivateであり,他のスクリプトからも制御できるように,SetStateという関数を作成した.
引数としてEnemyState型の変数を受け取り,stateを指定された状態にする.後述するanimatorのトリ
ガーの発火もここで行われている.

敵のアニメーションの制御
敵のアニメーションは主に,Player_move.csと同じ方法で実装された.

Group Report of 2020 SISP

40

Group Number 5

Creative AI
移動の制御
敵の移動は,後述するSetPositionと密接に関係している.敵は初めに,SetPositionで,ランダムなある座標を設定する.そして,指定された座標の方向に敵を動かす.このとき,stateはwalkである.移動の処理はPlayer_moveと変わらない.そして,Distance関数によって,現在の位置と目的地との距離を計算し,もしその距離がある一定以下になると,敵は移動を停止し,stateがwaitになる.

●

public float waitTime = 3f;

敵は,stateがwaitになった後,waitTimeの時間が過ぎると再びstateがwalkに変更される.

●[SerializeField] private float walkSpeed

Player_moveと同じく,[SerializeField]として設定されており,Unityのインスペクターで容易に編
集できる.

攻撃の制御
Distance関数によって,現在の位置とプレイヤーの位置との距離を計算し,もしその距離がある一定以下になると,敵は攻撃を開始する. 攻撃開始の検知とともに,敵の攻撃判定を有効にする.攻撃開始の検知は,Player_move.csと同様に,Animationのイベントによって制御される.

ダメージを受けているときの制御
ダメージは,Player_move.csと同様の実装を行った.

SetPosition.cs
敵の目的地は,SetPosition.csによって設定される.

ランダムな地点への移動の実装
目的地は,敵を中心としたある大きさの円の中からランダムに決定される.これをEnemy_move.csに送ることで,敵のランダムな地点への移動を実装した.

プレイヤーの検知
敵にUnityのCapsuleColliderを設定する.これが敵の検知範囲となる.プレイヤーを検知するために,プレイヤーにはタグ”Player”が設定された.プレイヤーが検知範囲に入ると,この”Player”というタグによって,プレイヤーを検知し,その座標をEnemy_move.csに送る.

Group Report of 2020 SISP

41

Group Number 5

Creative AI(*文責：森本大翔)

3.5.1.2 マップ
システム班では,視覚班から受け取った設定画をUnity上でマップにするという作業も行った.現在,
2つのマップを作成している.マップ作成時には,Terrain機能を用いた.Terrain機能は,Unityの機能の一つで,地形を自由に創造することを支援するツールである.それらはUnity Asset Storeのアセット等を活用して作成された.
マップを作成するうえで,テクスチャやライティングを重視した.設定画の雰囲気をなるべく再現するために,テクスチャを選別し,設定画に沿った空気感を感じられるようなライティングを施した.
(*文責：森本大翔)

Group Report of 2020 SISP

42

Group Number 5

Creative AI
第4章 中間発表
4.1 概要2020年7月17日にWeb会議サービスであるZoomを利用して中間発表が行われた.中間発表を行うにあたって,事前にプロジェクトの活動内容が分かりやすいようにA3サイズのポスターと10分程度のプレ
ゼンテーション動画を作成した.そして,中間発表当日にブラウザ上でポスターと発表動画を評価者に見てもらい,その後のZoomミーティング内で20分間の質疑応答を6回行った.また,評価者に向けたアン
ケートを取り,評価を受けた.
(*文責：大田翔貴)
4.2 制作物
4.2.1 ポスター

図4.2.1-1 中間発表用ポスター

ポスターはA1サイズかつ日本語と英語のバイリンガルと定められており制作ソフトにはAdobe illu
stratorを使用し作成した. 中間発表の一週間前に制作を開始し, 内容は「プロジェクトの概要」「使用技術」「班員・担当教員」「各グループの説明」「後期の活動計画」とした. 全体的な色彩は白と黒を基調とし, グループごとに決めてあるイメージカラーを使用し役割の違いが明確になるよう配色した.
ポスター上部の目につきやすいところに本プロジェクトの概要や目的, 班員などの情報を明記し,空いたスペースには使用ソフトなどを表記する予定だったが著作権の都合上ロゴを使用できないので断念し, 文字だけの表記となった. 概要欄には目的, 目標を長すぎない文章にすることで見やすさと
読みやすさを優先した.
中央には各グループの説明をしており班の役割, 自動生成する内容などをそれぞれ表記しシステム班が統合するというのがわかるよう図解を入れた. 各班一つずつ自動生成する要素が一つありそれらを成果物としてシステム班がまとめることになっている.

Group Report of 2020 SISP

43

Group Number 5

Creative AI
最後に後期の活動計画として各班に最終発表までに行う内容を記載した. この欄も中央と同様に班ごとに色分けをしている.
反省すべき点は上半分の空白が少し乱れていて統一性に欠けるのと, 「各グループの説明」の欄が理解しにくいとの声があり, また説明欄の大きさに対して情報量が多くなって余白が減り, 文章が見にくくなってしまったのと, 各説明欄の英語表記が担当教員の欄にしか書いておらずバランスが非常に悪くなってしまった. そして全体的に白抜きの欄が多いのとシステム班のベースカラーが黄色なこともあり視認性に欠けていることに気づいた.
また音響班のみAIによる自動生成ではなくBGMの自動選択を目標としているが他の班が全て自動生
成なのに対し, 一つだけ自動選択になっていることに気づきにくくデザインを差別化すべきであった. 今後の展望の欄もそれぞれのベースカラーの上に白文字で表示したがそれぞれの項目の間隔が狭く, また日本語と英語を入れる必要があったため文字が潰れてしまい読みにくくなっていた.
後期の発表の際は上記の反省点をしっかり見直し, 本プロジェクトの活動を明確に伝えられるよう心掛ける.

(*文責：村井大輝)
4.2.2 動画
今年度は上記のようにオンラインでの中間発表となったため,10分程度の動画を作成することになった.
編集及び構成を担当するにあたり,まず動画の内容をどのようなものにするかを決定した.グループ
リーダーとの協議の結果,説明用のスライドを作成し,そのスライドを基にプレゼンテーション形式で説明を進めていき,最後に現状のデモムービーを流す形式に決定した.
スライドの作成はテンプレートを作成し,それを用いて班ごとにスライドと原稿を作成,統合と修正を行うことで一貫性のあるデザインを目指した.デザインカラーはポスターのものと統一した.統合と修正の際,スライドレビューを担当教員にお願いするほかは担当一人での対応となり質,時間共に十分でなかった点は失敗であり反省点である.
編集はVegas Pro 16.0を使用した.聞きやすさを最優先とし,映像の間に特に注意して伝わりやすいよう作成した.また,デモムービー部はシナリオ班,キャラクター会話班,視覚班の現状の成果と目標がわかる内容物を基にシステム班が制作したRPG,及び音響班が制作したBGMを使い,テロップや再生速度の調整などの編集を加えて伝えたい内容がしっかりと伝わるよう,またゲーム内容の映像ということもあり魅力的に伝わるように作成した.

(*文責：小原大地)
4.3 評価質疑応答を行った後に,発表技術と発表内容の項目に分け,10段階評価とコメントを回答してもらった.質疑応答は以下の通りであった.

Group Report of 2020 SISP

44

Group Number 5

Creative AI●

此方のプロジェクトで活動するにあたりなぜAIでなくてはならないと考えているのか.創造に関しては現在でも沢山の人間が日々生み出している.フリーゲームであり,書籍であり.人工知
能で生み出すことによって何を得られると考えているか.
○●

音や動きも自動生成するのか○●衝突はあるが,進捗報告会や苦労話などをしてお互いに理解を深めていこうとしている.

どのような開発体制でプロジェクトを行っているか.
○●

アクション面のキャラクターの動き,敵の動きを自動生成する予定はない.

5つの班での認識の差への対策は？
○●人工知能が出力したものを組み合わせる.

キャラクターの自動生成.. アクション要素の自動生成の実装予定は？
○●ディレクター等の役職を設けていく予定.

各班で自動生成アルゴリズムをどのようにゲームに組み込むのか.
○●

アクションRPG.

全体でどのように,ゲームを作っていくのか.協力していくのか.
○●

打撃ダメージ量でパラメーターを分ける予定.

成果物はRPGかアクションRPGか.
○●各々の想像性の違いをまとめるにはゲームが効果的であると考えている.人工知能に
創造性を代替するのではなく人間の創造性の拡張の土台とするために人工知能と創造性をテーマに活動している.

システム班が視覚班とともにアセット利用等でやっていきました.

最終的な統合で問題点が出ないようにするための対策はどのようにしているか.
○

フォーマットを決めてから行動しています.

Group Report of 2020 SISP

45

Group Number 5

Creative AI●

シナリオの自動生成はゲームの最中に生成されるのか,それとも自動生成したものに沿って開発するのか.
○●

世界観の設定がシナリオ班の担当であると書かれている.キャラクター会話の生成やマップの生成に関わってくるところだと思うのだが,そこを班の担当にして,なにか問題が起きなかったのかを知りたい.
○●

内容についても解析しようかと考えていたが,プロジェクト期間を考えた際に難しいので,先行研究のある年齢・性別による分類をやってみて内容については取り掛かれるようであれば行う予定.

音響班では特にどこを頑張りたいと考えいるか,またその頑張る部分をどのように評価する予
定か.
○

●

おそらく完成したシナリオに対して泣けるかどうかをアンケートに取る予定.

年齢・性別によって会話文の文末を変えることだけを目的としているのか.男性・老人なら昔話,女性なら家族の話などを優先的にしたりしないのか.
○●

後期の完成を予定している.

シナリオの評価はどのように行うのか.
○●

シンプルというのは,感動を表す中でという意味.個人差は生まれる部分であるので作品群としてなるべく複数のネット上のサイトで泣ける作品として紹介されているものを選び,シーンで泣けるかどうかについては班内の合議で決めている.なるべく客観的に泣けるシーンであるということを意識した.

メインストーリーはいつできるのか.
○●全体での話し合いで世界観を詰めていったが,上手く進まなかったので,シナリオ班が決定権を持って主導した.

泣くという表現は笑い泣きや怒り泣き,感動泣きがある.シンプルという表現にしっくりこな
かった.感動できる基準をどうやって分析しているのか.
○●

自動生成したものに沿って開発する.理由としてはゲーム制作に人手不足の問題があるという背景がある.

コード進行の自動生成を頑張りたい.評価についてはまだしっかりと決まっていない.

コード進行を自動生成するとのことだが,コード進行の使い方について予定はあるか.

Group Report of 2020 SISP

46

Group Number 5

Creative AI○●

シーンに応じたBGMを作るとのことだが,シーンを解析してそこに生まれる状況に応じてBGMを作るということでよろしいのだろうか.
○●

AIでシーンの状況を取得することが目標だが,シーンごとの感情量を測定する.感情量の測定についてはpythonを用いて0から1の数値で表す.

戦闘だったら激しい,人を助けるなら穏やかな.分析の過程が明確ではない.仕組みはわかるのだが実際に持って行き方が伝わってこない.
○●生成されたコード進行に対して,音響のメンバーでメロディをつけてそれをゲーム内で使う予定.

シナリオ班側からシーンに対して手動で.もとからあるBGMに関して選択する予定.

コード進行を自動生成するということでしたが,コード進行を曲から学習させるのか自分たちで組み込んでいくのか.
○

自分たちが良いと思っているコード進行をやっていく予定.

中間発表では,46人から評価を受けた.結果は表4.3-1に示す.
表4.3-1 中間発表での評価
評価点

発表技術

発表内容

1

0

0

2

0

0

3

0

0

4

0

0

5

3

2

6

4

2

7

10

9

8

14

12

9

7

12

10

8

9

平均

7.91

8.23

Group Report of 2020 SISP

47

Group Number 5

Creative AI

発表技術についてのコメントの一例を示す.
●

スライドが見やすく,発表はとても聞き取りやすかった.

●

始めに簡単な紹介を行っており,理解が深まった上で質問を考えられてよかったのではないかと思う.

●

最後に映像を示していたのでいいと思った.

●

画面共有でポスターを見せるのは,文字が小さすぎて毎回ズームしないといけないので簡単なスライドを作ってほしい.

●

ポスターではプロジェクトの魅力が伝わってこなかったが,動画がとても魅力的であった.

●

先を見通した計画性があり,質問の返答に曖昧さがあまり見受けられなかった.

●

実際に喋る練習と準備が足りていないと感じた.質問には,まず結論を答え,具体的な説明はその後からした方が混乱が防げると思った.

●

聞かれる可能性の高い内容については,事前に準備をしておくべきだと感じた.

●

司会進行の人がしっかり進行していたので,スムーズにいっていたように感じた.

●

質問が出なくなった時の対応が出来ていてよかった.

●

一部の動画の音声が聞き取りにくかった.

●

活動内容の紹介動画について,10分の目安を意識してもらいたいと思った.

●

司会者のミスを他のメンバーが補佐出来ていてとても良かったと思った.

発表内容についてのコメントの一例を示す.
●

開発基盤についてわかりやすくまとめられていた.コンセプトなどについてもまとめてあると良いと思った.

●

内容がしっかりと伝わる動画だった.

●各班の役割のスライドなど見やすくまた分かりやすかった.

●

後期に何をするかも明確に決まっており,成果が期待できると思う.

Group Report of 2020 SISP

48

Group Number 5

Creative AI●

AIに創造性を発揮させるというテーマにそって活動していた.

●「自動生成でつくるキャラクター」がとても面白いと思いました.

●

なぜAIを使い,どういう目標の一致でゲームになったのかなど.このプロジェクトの根本的な目標を知りたかった.

●

現段階でここまでの者が出来ているのはすごいと思った.今後の自動生成,自動選択などのAIらしい部分の発展を期待している.

●

前年に比べて,全体的にAI的要素が増えて,ビジュアルやシステムにおいてもクオリティが上がっているように感じた.

●去年の成果物を踏まえて新しい分野を起こしているのですごいと思った.

●

各グループが最終的にどこの作りこみ部分を努力するのか,あるいは目標が具体的だとさらに良いと思った.

●動画内のデモンストレーションによって内容がイメージしやすいと思った.

●

グループが細かく分割されながらも,独立して進むのではなく連携がなされている点が良かった.

●

プロジェクトとしての「活動上の問題（引継ぎ,議論の環境など）」でなく,分析や開発など,技術的な側面についての話を聞きたかった.

(*文責：北清敦也)

4.4 課題と検討
4.4.1 キャラクター会話班
今回の中間発表で,キャラクター会話班への質問として「年齢・性別に着目して,文末や助詞を変える事だけを目的としているのか.男性・老人であれば昔話を話したり,女性なら家族の話をするなど内容に踏み込まないのか.」が挙げられた.中間発表までの活動では,トピックはあらかじめ指定をして,文体特徴のみを変化させることで話者属性に合った会話文の自動生成を目標に活動していた.仮に文体だけでなく内容・トピックも自動生成によって変化させることができれば,より自然な会話文が生成できると考えられたため中間発表終了後にキャラクター会話班で再検討した.プロジェクトの残り期間と実現可能性を考慮し,後期も引き続き年齢・性別に着目した会話文の分析を進めて,内容については後期の進捗状況によっては取り掛かるという結論となった.

Group Report of 2020 SISP

49

Group Number 5

Creative AI(*文責：北清敦也)
4.4.2 視覚班
後期の活動は顔の自動生成を行うために5000人近くのキャラクターの顔パーツを分割し, 人工知能に学習させる. 顔パーツの元のキャラクターは様々な漫画からなるべく正面で映っている顔を切り抜
き, 画像編集ソフトで分割し, それぞれのパーツを画像データにして保存する手法をとる. 具体的にはパーツを輪郭, 髪, 目, 眉, 鼻, 口の六つに分割し元のキャラクターの精神年齢を5段階に分け,
子供, 青年, 老人に男女の区別をつけることで生成するものを差別化する.
また他にも, ゲーム中で使用するマップのデザインとそのモデリングを行いシステム班と連携し,ゲームに組み込む予定である. その際マップに設置するオブジェクトは一部アセットから用いる予定
であり世界観に合致するものを選別し, またキャラクターのモデリングが予定より早く完了すればオ
ブジェクトのモデリングにも着手していく予定である.
キャラクターのモデリングも同様, 視覚班でキャラクターデザインや三面図を作成しているのでそれらを使用しモデリングを行っていく予定である.
モデリングに関してはBlenderというソフトで行うがモデリング担当も使用経験は浅く, 学習と並行で進めていく. またキャラクターの動き（以下モーションとする）も同じくBlenderを使用し付けていく予定である. しかしモーション全てをオリジナルで作成できるかは未定であり, 間に合わない
場合はアセットから人型のモーションを使用することも検討している. それでもメインキャラクター
のうちの一体はドラゴン型で人型のモーションが流用できないものであり最終発表までに完成させる
ことを目標とする.
(*文責：村井大輝)
4.4.3 音響班
音響班の後期の課題として,特徴量の妥当性の再検討が上げられた.特徴量については前期の活動で決定したが,シナリオ等の分析が終わり次第,詳細の部分までの検討が必要になる可能性がある.
ニューラルネットワークについては, まだ手を付けていない部分なので,コード読みをしつつ勉強を進め, 動作と改善に尽力したい.
また,後期の課題としてコード進行の自動生成についても上げられる.これについては,前期の活動では詳細に話し合えていない事柄であるため,解析や学習法,評価などの手順についての検討をしていく予定である.
前期の活動を通して, 音響班は他班との連絡をほとんど取っておらず, お互いに進捗が分からない状態となってしまっているので, 後期からは班として孤立しないよう心がけたい. シナリオの感情量やゲーム内での音楽の再生など, これからは他班と協力しなければいけない機会が増えると思うので, 円滑に連携を取れるよう意識して活動していきたい.
(*文責：天野太一)
4.4.4 システム班
前期のシステム班は,データを共有する方法が効率的ではなかった.データに更新があるごとに,毎回大容量のデータファイルを共有する必要があり,無駄が多く発生していた.そのため,後期では,デーGroup Report of 2020 SISP

50

Group Number 5

Creative AI
タの更新に必要な部分のみを取り出し,その部分のみを共有するといった工夫が必要であると考えられる.
ゲームにおけるアクション要素のうち,攻撃や移動といった基本的な部分は完成している.しかし,敵のデータや細かい場所の調整といった部分はまだ手をつけれておらず,その部分に手を加えていく必要があると考えられる.
後期では,モブキャラクターのスケジューリングといった新しい要素にも挑戦していく傍ら,他班の成果物をゲーム内で実装するといった重要な作業がある.そのため,それらを並行して作業できるように,他班との円滑なコミュニケーションやデータのやり取りを模索する必要があると思われる.
(*文責：森本大翔)
4.4.5 全体
発表技術と発表内容について,それぞれの課題を検討する.
発表技術では,発表での準備が足りていない,画面共有でのポスターが見づらい,一部の動画の音声が聞き取りにくい,という意見があった.今年度は,例年とは異なる形態での発表となったので,例年通りの発表準備では不足があったと考えられる.そこで,発表を受ける側としての視点を持って確認を行うことで,分かりやすい制作物や発表ができるように,プロジェクト内での体制を見直していく.また,活発な意見の交換ができるように改善していく.
発表内容では,根本的な目標を知りたかった,各グループの最終的な作りこみや目標が具体的でない,技術的な側面の話が聞きたかった,という意見があった.各班での活動に焦点を当てて発表をした.
しかし,プロジェクト全体での目標を分かりやすく伝えることができていなかった.さらに,各班がプロジェクト全体でどの部分を担当するか,なにを課題として活動するかが発表内容からでは理解しにくい構成となっていた.一方で,中間発表では,プロジェクトでの活動を中心に共有したが,技術的な内容を求める声もあった.これらのことから,プロジェクト全体での目標や課題から,各班での目標や課題を理解しやすいようにまとめる必要がある.そのため,プロジェクト全体で目標課題を議論し,明確にしていく.また,理解しやすい構成にできるように改善していく.
(*文責：髙橋利孔)Group Report of 2020 SISP

51

Group Number 5

Creative AI
第5章 成果発表までの開発
5.1 シナリオ班
5.1.1 カテゴライズ
シナリオ班では,前期の活動の中で試験的に分析を行った鉄拳のパラパラ漫画である「約束」,「お父さんは愛の人」,「母のサポーター」,「振り子」の4作品に対してまず,なぜ泣けるのかという軸に
よって泣けるシーンの分類を行った.その結果,喜びや感激といった比較的明るい感情によって泣けるもの,一方で辛さや悲しさといった暗い感情によって泣けるといったシーン,そして明るい感情と暗い感情を内包して泣けるシーンの3種類に分割が可能となった.さらに,なぜ泣けるのかという軸で各シーンを掘り下げ,どうして泣けるのかという基準のもと各シーンについて話し合った結果,泣ける瞬間というのは登場人物の心境に共感して泣いている場合とコンテンツの利用者自身がシーンを見て泣いている場合が存在することが判明した.次に各シーンを分ける基準として,物語としてそのシーンが何らかの取得もしくは喪失をしているのかどうかという基準を用いて分類を行った.シーンにおける取得,喪失の考え方が非常に難しく,またシナリオ班の各メンバーによって取得,喪失したものへの考え方に差異などがあり,すり合わせと分類方法の決定に非常に多くの時間を要した.その結果として,取得,喪失,どちらもなかったシーンの3種類に分類することとなった.なお,何かしらの取得と喪失が同時に行われたシーンについては,同じシーンを2つに増やしそれぞれを取得と喪失に分けることとした.
シナリオ班では,この段階までで泣けるシーンの分類に対してなぜ泣けるのか,どうして泣けるのか,そのシーンは物語の中で何かしらの獲得もしくは喪失が起こっているのかという3種類の軸を用いて泣けるシーンを多角的に分類を行った.分類を終えた次の段階として,分類によってある程度似ている「泣ける」理由が同じような場所に分けられていると考え,泣けた理由が同じ,もしくは非常に近いと感じるシーンを1つにまとめ,まとめたものに対してラベルを付けていく作業を行った.その結果,ラベリング終了時に以下の14種類のカテゴリが設定された.
1.人物の苦しさ・辛さに共感
2.夢の実現
3.幸せへの共感
4.信頼関係に対する感動
5.再会した感動に共感
6.報われたことに共感
7.人物の葛藤に共感
8.余裕のない人の優しさに感動
9.感謝と後悔で泣いている人に共感
10.大変な人の苦労
11.自責の念への共感
12.報われないツラさに共感

Group Report of 2020 SISP

52

Group Number 5

Creative AI
13.日常の崩壊
14.人物の退場
これらのカテゴリを暫定的に用いてデータ収集を行うこととなった.
(*文責：福元隆希)
5.1.2 データ収集
データの分類において例外が存在する.シナリオ班では上記のカテゴリでは分類不可能なものや主観では分類が難しいといった例外については合議のうえで対応することをデータ収集における規則の1つとした.そのためデータ収集の最中に泣けるシーンを分類するためのカテゴリそのものが増えることがあった.
データ収集には昨年度に利用されていたRPG分析用フォーマットをもとに泣けるシーンを分析できるように新たなデータ収集用フォーマットを作成した.データ収集を行っていくうえで新たな問題点
や改良案が出るつど,収集用フォーマットの変更も行ってきた.
音響班に協力してもらい最終的に集まった泣けるシーンは297シーンとなった.
(*文責：福元隆希)
5.1.3 分析
データ収集がある程度終わった段階で私たちは集まったデータをもとに,再度泣ける理由のカテゴ
リについて検討を行った.上記に書かれているカテゴリには含まれない泣ける理由が新たに認められたことや同じカテゴリの中でもさらにシーンや泣ける理由に対して似ている似ていないという点が出てきたためである.例えば,新たに認められたカテゴリに努力が報われたこと対する共感が存在する.
そして新たなカテゴリが生まれることで今まで別のカテゴリに属していた物が新しいカテゴリに移動するなどシーンのカテゴリ間の移動なども見られた.さらに,カテゴリの抽象度を上げ,さらに広範囲の泣ける理由を取り扱い可能にするため,各カテゴリの統合なども行われた.一例として,人は努力が報われることに共感,感動し涙するが,努力が報われず悔しい思いや絶望する登場人物にも共感して涙を流す場合が確認できた.これは初期のカテゴリを決定するときでは,なぜ泣けるのかという点で明るい感情と暗い感情に分けられていたものである.しかし,登場人物が努力をしているという過程において一致している.その結果,努力というカテゴリの中に報われるや報われないといったなぜ泣けるのかという軸では正反対に属するようなシーンをサブカテゴリを通して同じカテゴリとして分類することが可能になった.他にも泣けるという共感に対する度合いの差異を取り扱うためのサブカテゴリが存在する.その一つの例が自己犠牲のカテゴリである.簡単に説明をするならば家族を守るために怪我をした場合と知らない誰かを守るために怪我をした場合では人の共感に差異が見られるということである.すなわち,行っている内容が同じ自己犠牲であるがその対象が異なることでコンテンツの利用者が受ける印象が変わり泣けるのか泣けないのかに影響を与えるということである.このようにカテゴリの再検討をおこなった結果,カテゴリは以下の図のようなった.

Group Report of 2020 SISP

53

Group Number 5

Creative AI

図5.1.3-1 カテゴリ,サブカテゴリ一覧

さらに一部のサブカテゴリには小カテゴリも設定されている.この小カテゴリには泣けるシーンにおける人物の人間関係などのサブカテゴリの中でさらにコンテンツ利用者の泣ける点に影響を与える
内容についてまとめている.例えば,カテゴリ:「夢」,サブカテゴリ:「肯定される」の小カテゴリには肯定してくる相手との関係性が属しており,「友人から」,「家族から」,「恩人から」,「共同体から」,「敵対関係者から」の5つがある.
また,分析を進めたことで,より泣けるシーンほどカテゴリが重複が存在していることが判明している.
(*文責：福元隆希)
5.1.4 メインシナリオ
シナリオ班では,ゲームに欠かせない要素である世界観・メインシナリオの作成を行った.世界観
は,シナリオ班が目標とする「泣ける」シナリオを実現させるため,人や何かの生死が必然的に存在し,違和感なく物語に溶け込めるであろう「人類文明が滅んだ後の世界」に決定し,メインシナリオの作成した.結果として,世界観で 4,621字,メインシナリオ 16,014字となった.
また,下図のようにゲーム内のストーリーは,メインシナリオであるプロローグ,中ボス戦,ラスボス
戦,エピローグと自動生成クエストを3つ組み合わせた構成となっている.

Group Report of 2020 SISP

54

Group Number 5

Creative AI

図5.1.4-1 メインストーリーの流れ(*文責：福元隆希)
5.1.5 データフォーマット
コンピュータは物語を読むことができない.そのため,物語をゲーム中に読み込むためには,シナリ
オのテキストに適切なタグを付加したデータフォーマットの作成が必要となる.データフォーマット
の作成のため,タグを定義した.タグは去年の成果物を利用し,基にして再検討,必要となるものを適宜追加する形で作成してシステム班に依頼した.制作の中でシステム班,及びシナリオ班と話し合いを重ね,双方の事情や実装作業もしくは代替作業に際する作業量,時間と期日を鑑みて現在の形に落ち着いた.
以下に定義したタグの説明を記述する.
●

Event(flag, object)｛｝X
与える変数
flag:cタグ
object:オブジェクト名の文字列
イベントを定義するためのタグである.フラグには後述のcタグを,オブジェクト名はシステム側で配置したオブジェクト名が入り,中括弧内に下記のタグを入れていく.

●

表示名,役職名Group Report of 2020 SISP

55

Group Number 5

Creative AI
キャラクターを定義するために使用する.表示名がテキストボックスに表示されるものであり,役職名で立ち絵やアイコンのフォルダを定義している.このキャラクターの定義時の行数を下記のタグで使用する.
●

eb[N0,N1,N2,N3,N4,N5,N6,N7]
与える変数
b:泣けるかどうかを表すブール値
N0:怖い,冷静な,宗教的なを表す実数値
N1:暗い,憂鬱,悲しいを表す実数値
N2:夢のような,感傷的な,優しいを表す実数値
N3:穏やか,静かな,叙情的なを表す実数値
N4:優雅な,滑稽,奇抜なを表す実数値
N5:明るい,幸せ,派手なを表す実数値
N6:爽快,興奮,衝動的を表す実数値
N7:力強い,雄大な,重苦しいを表す実数値
シーンの感情量を定義する.bには「泣ける」シーンであるかどうかが0もしくは1のブール値で与えられ,N0～N7にはそれぞれ（怖い,冷静な,宗教的な）,（暗い,憂鬱,悲しい）,（夢のような,感傷的な,優しい）,（穏やか,静かな,叙情的な）,（優雅な,滑稽,奇抜な）,（明るい,幸せ,派手な）,（爽快,興奮,衝動的）,（力強い,雄大な,重苦しい）の感情を0～1の大きさで設定している.このタグを音響班のBGM自動選択アルゴリズムにかけることで下記のmタグに変
換する.

●

mn
n:楽曲番号の整数値
BGMを定義する.nで指定した番号の楽曲をリストから再生する.このタグのみシナリオ班ではなく音響班が記述する.

●

c
フラグを表すタグ.フラグの種類ごとにタグが分かれているためそれぞれのタグで詳細は記述
する.

●

cC(b)
b:フラグに代入するブール値
プレイヤーキャラクターの操作可否を定義する.bには操作可否が0もしくは1のブール値で与
えられる.

●

cEn(b)

Group Report of 2020 SISP

56

Group Number 5

Creative AI
n:イベント番号を表す整数値
b:フラグに代入するブール値
イベントのフラグを定義する.nにはイベント番号が,bにはブール値が与えられる.
●cQn(b)
n:クエスト番号を表す整数値
b:フラグに代入するブール値
クエストのフラグを定義する.nにはクエスト番号が,bにはブール値が与えられる.

●

Questn(b), moden:格納箇所を表す整数値
b:フラグに代入するブール値
mode:出現する物を指定する文字列
クエスト時に出現する固有オブジェクトの出現・消失を定義する.nで格納箇所を指定し,bで消失,出現を0もしくは1のブール値で与える.modeにはhuman,item,enemyのいずれかが与えられ,それぞれクエスト用の人物,アイテム,敵を指定する.

●

pTn, mode
n:画像番号を表す整数値
mode:切り替え方法を指定する文字列
背景画像の表示を定義する.nで画像番号を与える.modeは無記述,FU,FO,BF,WFの五種類があり,それぞれそのまま表示,フェードイン,フェードアウト,画像切り替え時に黒画像にフェー
ドインフェードアウト,画像切り替え時に白画像にフェードインフェードアウトが指示でき
る.

●

rx
x:表示名定義の行数を示す整数値
立ち絵の表示を定義する.xには表示名定義の行数を与える.下記のf(n)と合わせて記述する.

●

f(n)
n:
立ち絵の表示位置を定義する.nには位置を左から順に0～3で与える.上記のrxと合わせて,r0,
f(0)のように記述する.

●

ix,nx:表示名定義の行数を示す整数値

Group Report of 2020 SISP

57

Group Number 5

Creative AI
n:表情差分を指定する整数値
アイコン表示を定義する.xには表示名定義の行数を与える.nには0～5の整数値が与えられ,それぞれ通常,喜,怒,哀,驚,独自表情の表情差分を指定する.
●

sx@「text」
x:表示名定義の行数を示す整数値
text:メッセージウィンドウに表示する文字列
テキストの表示を定義する.xには表示名定義の行数を与える.textに表示したいテキストの文
字列を与える.

●z
シーンの終わりを定義する.物語をシーンとして可視化するほか,立ち絵を一度消す役割があ
る.

●

end
イベントの終わりを定義する.

これらのタグをシナリオテキスト,及び自動生成用のクエストテキストにタグ付けすることで,ゲー
ムシナリオへの物語の読み込みと,自動生成した文章の読み込みを実現した.
また,今年度は昨年度の反省を活かし,オブジェクト番号やイベント番号,画像番号の定義を明確化することでシナリオの急な追加に備えると共に,データフォーマットの可読性を上げ,来年度への引継ぎを容易にした.具体的には以下の通りである.
●

オブジェクト番号
0番台:ポトナード内のオブジェクト
10番台:フィールドのオブジェクト
20番台:ゼイフォード内のオブジェクト
30番台:中間地点となっているオブジェクト●

イベント番号
0番台:ポトナード内のイベント
10番台:遺跡フィールドでのイベント
20番台:ゼイフォードでのイベント
30番台:中間地点でのイベント

●

画像番号

Group Report of 2020 SISP

58

Group Number 5

Creative AI
0番台:スチル画像
10番台:フィールドの背景画像
20番台:ポトナードの背景画像
30番台:ゼイフォードの背景画像(*文責：小原大地)
5.1.6 他の班との作業
5.1.6.1 キャラクター会話班
キャラクター会話班には,街や村にいるモブキャラクターの会話文について世界観を順守した内容にするように協力を頂いた.
(*文責：福元隆希)
5.1.6.2 視覚班
視覚班には,メインキャラクター,ボスキャラクターの立ち絵,3Dモデルやシナリオ中に利用するス
チル絵の用意などで協力を頂いた.
(*文責：福元隆希)
5.1.6.3 音響班
音響班には,データ収集に加え,シナリオ班の目的である「泣ける」シナリオ生成のために,人工知能を用いたBGMの自動選択に「泣ける」BGM選択の追加など,様々な面で協力を頂いた.
(*文責：福元隆希)
5.1.6.4 システム班
システム班にはキャラクター間の会話における表示方法やクエストを進行するための新たなシステ
ムなどで協力を頂いた.
(*文責：福元隆希)
5.1.7 自動生成するクエストシナリオ
RPGのクエストの自動生成では,複数のクエスト用メインテキスト,サブテキストを用意し,クエスト
用テキスト内における人間関係などの依存関係を考慮した自動マッチングを利用した.ゲーム内のク
エストの自動生成では960通りの組み合わせを実現した.

Group Report of 2020 SISP

59

Group Number 5

Creative AI

図 5.1.7-1クエスト自動生成の流れ(*文責：福元隆希)
5.1.8 アルゴリズム作成
上記のクエスト自動生成を行うために今回プログラミング言語としてPythonを利用した.Pythonのライブラリを利用することでメインテキストファイル,サブテキストファイルをランダムに選択することを容易にしている.
(*文責：福元隆希)
5.2 キャラクター会話班
5.2.1 データ収集
中間発表を終えて,本格的にデータ収集が始まった.収集期間は,後期の活動が始まるまでとした.グ
ループメンバーが3人であり,収集するゲームシリーズが3種類あったことから,各人1種類のゲームシ
リーズのデータ収集を担当した.
実際に収集を行った結果,「ポケットモンスター」シリーズは集めきれなかったため,分析データとして除外することとなった.
本項では,分析データとして扱うゲームシリーズごとにデータの収集結果を記述する.

・「ドラゴンクエスト」シリーズ「ドラゴンクエスト」では,197セル分の会話文を収集した.内訳は,男性151セル分,女性46セル分,
子供3セル分,成人148セル分,老人46セル分の会話文のデータだった.データ収集を行った場所はラダ
トーム城,ラダトームの町,ガライの町,マイラの町の4箇所である.また,ラダトーム城とラダトームの町は同じ地域であるため,1つの町とみなした.

Group Report of 2020 SISP

60

Group Number 5

Creative AI「ドラゴンクエストⅡ 悪霊の神々」では,165セル分の会話文を収集した.内訳は,男性133セル分,
女性32セル分,子供1セル分,成人108セル分,老人56セル分の会話文のデータだった.データ収集を行った場所はローレシア,リリザの町,サマルトリア城の3箇所である.
「ドラゴンクエストⅢ そして伝説へ…」では,376セル分の会話文を収集した.内訳は,男性269セル
分,女性107セル分,子供7セル分,成人272セル分,老人97セル分の会話文のデータだった.データ収集を行った場所はアリアハン城,レージ,ナジミの塔,ロマリアの4箇所である.また,ナジミの塔は道中に登場する建物のため,町とみなさなかった.
「ドラゴンクエストⅣ 導かれし者たち」では,341セル分の会話文を収集した.内訳は,男性268セル
分,女性73セル分,子供30セル分,成人276セル分,老人35セル分の会話文のデータだった.データ収集を行った場所は山奥の村,バトランド城,城下町,イムルの4箇所である.また,バトランド城と城下町は隣接しているため,1つの町とみなした.
「ドラゴンクエストⅤ 天空の花嫁」では,487セル分の会話文を収集した.内訳は,男性329セル分,
女性158セル分,子供69セル分,成人346セル分,老人72セル分の会話文のデータだった.データ収集を行った場所はストレンジャー号,ビスタの港,サンタローズの村,アルカパの町の4箇所である.また,ビスタの港は,規模と人口から道中の村と判断した.
以上,5作品から計1566セル分の会話文を収集した.内訳は,男性1150セル分,女性416セル分,子供110
セル分,成人1150セル分,老人306セル分の会話文のデータだった.

・「Final Fantasy」シリーズ「Final Fantasy Ⅰ」では,109セル分の会話文を収集した.内訳は,男性89セル分,女性20セル分,子供2セル分,成人71セル分,老人36セル分の会話文のデータだった.データ収集を行った場所はコーネリ
アの町,コーネリア城,プラボカの港,マト―ヤの洞窟,ドワーフの洞窟,エルフの町,エルフの城の7箇所である.また,コーネリアの町とコーネリア城,エルフの町とエルフの城はそれぞれ1つの町とみなした.マト―ヤの洞窟とドワーフの洞窟は中継地点のため,町とはみなさなかった.
「Final Fantasy Ⅱ」では,115セル分の会話文を収集した.内訳は,男性84セル分,女性31セル分,子供6セル分,成人90セル分,老人19セル分の会話文のデータだった.データ収集を行った場所は,アルテアの町,ガテアの村,フィンの町,パルムの町の4箇所である.また,ガテアの村は規模と人口から道中の村と判断した.
「Final Fantasy Ⅲ」では,99セル分の会話文を収集した.内訳は,男性67セル分,女性32セル分,子供4セル分,成人62セル分,老人33セル分の会話文のデータだった.データ収集を行った場所はウル,カズス,サスーン城,サスーンの4箇所である.また,サスーン城とサスーンは1つの町とみなした.
「Final Fantasy Ⅳ」では,113セル分の会話文を収集した.内訳は,男性86セル分,女性27セル分,子供5セル分,成人91セル分,老人17セル分の会話文のデータだった.データ収集を行った場所は,バロン
城,バロンの町,カイポ,ダムシアン,ファブールの5箇所である.また,バロン城とバロンの町は1つの町とみなし,ダムシアンは規模と人口から1つの町とはみなさなかった.
「Final Fantasy Ⅴ」では,148セル分の会話文を収集した.内訳は,男性132セル分,女性16セル分,
子供5セル分,成人103セル分,老人40セル分の会話文のデータだった.データ収集を行った場所は海賊のアジト,トゥールの村,風の神殿,カーウェンの町,ウォルスの町,ウォルスの城,ウォルスの塔の7箇Group Report of 2020 SISP

61

Group Number 5

Creative AI所である.また,ウォルスの町とウォルスの城とウォルスの塔は1つの町とみなし,海賊のアジトと風の神殿は道中に登場する建物のため,町とみなさなかった.
以上,5作品から計584セル分の会話文を収集した.内訳は,男性458セル分,女性126セル分,子供22セル分,成人417セル分,老人145セル分の会話文のデータだった.
（*文責：大田翔貴）
5.2.2 データ分析
5.2.2.1 分析方法
収集した会話文のデータを元に,データ分析を行った.データ分析の手順としては,以下の通りである.
●収集したデータに形態素解析を行う●

6属性ごとに使用されている語尾をカウントする●

解析したデータにカイ二乗検定を行う

データ分析では,まず先に,収集した会話分を分析しやすい形に出力する必要があった.python上で形態素解析器であるMecab[5-1]を使用し形態素解析を行った.形態素解析とは文を言語上の最小単位である形態素に分割し,それぞれの品詞や変化などを割り出すことである.たとえば,「これはペンです.」という文章に形態素解析を行うと,これ(代名詞),は(係助詞),ペン(名詞),です(助動詞)のようになる.
次に,6属性ごとに会話分で使用されている語尾をカウントしexcelファイルに出力した.カウントをする際にもpythonを使用した.後にカイ二乗検定を行やすくするために,行列の形に整形を行った.
最後に,作成したファイルに対して,カイ二乗検定を行った.カイ二乗検定とは仮説検定手法のこと
で,検定により話者属性ごとに,どの助詞・助動詞が有意に使用されているかという結果が得られた.
検定する際は,要素の登場回数が5未満の数が全体の20％未満のときに,有意な要素を求めた.
(*文責：北清敦也)
5.2.2.2 分析結果収集したデータに,カイ2乗検定を行った.検定にはブラウザ上で動作する,無償の統計ソフトである,js-STAR[5-2]のversion9.8.7.jを使用した.検定をかけて出力された結果をexcelに貼り直して,簡潔にした.以下に出力した結果を示す.▲が記されている要素は有位に多いということを表しており,▽が記されている要素は有位に少ないということを表している.

Group Report of 2020 SISP

62

Group Number 5

Creative AI
表5.2.2.2-1 カイ2乗検定の結果

6属性の語尾に着目して検定を行った結果,いくつかの特徴が抽出された.成人男性は,断定の「だ」
や確認・念押しの「な」などが有意に多かった.成人女性は確認・念押しの「ね」が有意に多かった.
男性の老人は,断定の「じゃ」や「ぞ」が有意に多かった.これらの特徴が各話者属性らしい会話分を構成するために必要な要素であると考えた.出力結果を踏まえて,自動変換アルゴリズムの生成とプログラムの作成に取り掛かった.
(*文責：北清敦也)
5.2.3 プログラム
モブキャラクターの会話を分析する上で,プログラミング言語のPythonを利用した.また,形態素解析をする際には,形態素解析エンジンであるMeCabを利用した.MeCabでは,形態素解析をする際に,新しい語を辞書として登録して,解析することができる.しかし,今回は助詞と助動詞が対象であり,充分に分析できることから,辞書での登録をしなかった.
プログラムは,動作が多くなることや分析途中での変更が考えられることから,振り返って動作を確認できるように,実行するファイルを分けて作成した.以下に,ファイル名と,プログラムの動作を記
す.

●

Morphological_analysis_out.py○

入力ファイル：DQ1.csv,DQ2.csv,DQ3.csv,DQ4.csv,DQ5.csv,FF1.csv,FF2.csv,FF3.cs
v,FF4.csv,FF5.csv○

出力ファイル：male_child.csv,male_young.csv,male_old.csv,female_child.csv,fe
male_young.csv,female_old.csv

Group Report of 2020 SISP

63

Group Number 5

Creative AI
○

●

●

●

実行内容：実際に収拾したゲーム内でのモブキャラクターの会話をまとめたデータか
ら形態素解析をする.データでは,性別と年齢の属性を記載しないことで,会話の継続を表した.そのため,性別と年齢の情報を保存し,空欄の際には,その情報を参照する.
その結果を,6つの属性ごとのファイルに分けて出力する.

Morphological_analysis_count.py○

入力ファイル：male_child.csv,male_young.csv,male_old.csv,female_child.csv,fe
male_young.csv,female_old.csv○

出力ファイル：male_child_count.csv,male_young_count.csv,male_old_count.csv,female_child_count.csv,female_young_count.csv,female_old_count.csv○

実行内容：Morphological_analysis_out.pyで出力された6つのファイルにおいて,それぞれのファイルごとに要素の合計を出し,6つのファイルとしてそれぞれを出力す
る.

Make_CSV.py○

入力ファイル：male_child_count.csv,male_young_count.csv,male_old_count.csv,female_child_count.csv,female_young_count.csv,female_old_count.csv○

出力ファイル：data_gender_and_age.csv○

実行内容：Morphological_analysis_count.pyにて出力された6つのファイルを形態素解析した要素ごとに1つのファイルにする.6つの属性での要素数の合計値を出す.

sorted_result_and_chi-square_tests_data.py○

入力ファイル：data_gender_and_age.csv,only_data.csv,sorted_data.csv○

出力ファイル：only_data.csv,sorted_data.csv,chi-square_tests_data.csv○

実行内容：data_gender_and_age.csvで集めた内容から,助詞と助動詞を抜き取り,onl
y_data.csvとして出力する.合計値から多い順にソートを行い,sorted_data.csvを出Group Report of 2020 SISP

64

Group Number 5

Creative AI
力する.カイ二乗検定を行う際に,登場回数が5未満の要素数が20％未満になるように
形態素解析した要素を選択する.結果は,chi-square_tests_data.csvとしてファイルを出力する.

●

collect_and_list.py○

入力ファイル：chi-square_tests_data.csv,DQ1.csv,DQ2.csv,DQ3.csv,DQ4.csv,DQ5.
csv,FF1.csv,FF2.csv,FF3.csv,FF4.csv,FF5.csv○

出力ファイル：male_child_con.csv,male_young_con.csv,male_old_con.csv,female_child_con.csv,female_young_con.csv,female_old_con.csv,male_child_con_list.cs
v,male_young_con_list.csv,male_old_con_list.csv,female_child_con_list.csv,fe
male_young_con_list.csv,female_old_con_list.csv○

実行内容：再度,収拾したゲーム内でのモブキャラクターの会話をまとめたデータを読み込み,それぞれにおいて,6つの属性のみに分け,会話データのみをそれぞれ,male_child_con.csv,male_young_con.csv,male_old_con.csv,female_child_con.csv,femal
e_young_con.csv,female_old_con.csvとして出力する.その後,そのファイルを利用して,形態素解析をもう一度行い,chi-square_tests_data.csvにある要素に当てはまる
会話文を抽出する.そして,会話文における語尾に当てはまるものに記号をつけてそれ
ぞれ,male_child_con_list.csv,male_young_con_list.csv,male_old_con_list.csv,female_child_con_list.csv,female_young_con_list.csv,female_old_con_list.csvとして出力する.
(*文責：髙橋利孔)

5.2.4 自動変換アルゴリズム
自動変換するアルゴリズムでは,語尾を変換するために,入力側で変換する語尾を指定するようにした.また,語尾となる語はひとまとまりとして考えたため,その語尾が終わりとなることを示す記号を付けるようにした.以下に,プログラムの入力ファイルと出力ファイル,実行内容を記載する.

●

入力ファイル：in_word_list.csv,end_word.csv,in_con_sentence.csv●

出力ファイル：out_con_sentence.csv●

実行内容：in_con_sentence.csvに話者の性別と年齢,語尾を変換したい会話文を記入する.in_word_list.csvでは,語尾について,話者の属性を考慮せずに,語尾の意味ごとのみでの登場回数を合計して保存している.end_word.csvでは,話者の属性と語尾の意味ごとに分類し,複数の語尾の登場回数をそれぞれ合計して,まとめて保存している.これにより,返還前の語尾をin_w

Group Report of 2020 SISP

65

Group Number 5

Creative AI
ord_list.csvを用いて探し意味を取る.このとき,語尾の意味が複数の場合には,語尾の意味ごとに,確率を求め,それを用いて意味の推定を行う.そして,この語尾の意味と話者の属性から,
end_word.csvを用いて,適合する語尾を探し,変換する.この動作をする際に複数の語尾がある場合には,語尾が選ばれる確率を求め,それを用いて変換後の語尾の決定を行う.
(*文責：髙橋利孔)

5.2.5 会話文の変換結果
以下に,変換前の会話文と,自動変換アルゴリズムによって語尾を変換した後の会話文を記す.語尾を変換した会話文のうち,文としての接続が不適切なものは,それぞれ修正を行い,最終的な成果とした.修正をした場合には,修正した会話文も記載する.

●

ゲーム内での地名：ポトナード○○

変換前の会話文■「ぼくしってるぞ。むかし、ひとは地上に住んでたんでしょ？おじいちゃんが言ってたぞよ！」■「おそとの世界はどんなふうになってるのかのう。」■「じいさんの世迷言がまた始まったのう。人が地上に住んでいるはずないのにね。与太話も大概にしてほしいよ。」■「コアが無くなってしまったら、私たちどうやって暮らしていけば、いいのか。」お姉さん■「おや、マキナかい。たまには一緒にお茶でものみませんか？」■「わしは知ってるんだよ。人は昔、地上に住んでいたと。それなのに、誰一人としてわしのいうことを信じない。こんなジメジメした場所ではなく、地上に住みたいとは思わんのかしら。」

変換後の会話文■「ぼくしってるよ。むかし、ひとは地上に住んでたんでしょ？おじいちゃんが言ってたよ！」■「おそとの世界はどんなふうになってるのかね。」■「じいさんの世迷言がまた始まったか。人が地上に住んでいるはずないのにな。与太話も大概にしてほしいぞ。」■「コアが無くなってしまったら、私たちどうやって暮らしていけば、いいのかしら。」

Group Report of 2020 SISP

66

Group Number 5

Creative AI

○

●

■

「おや、マキナかの。たまには一緒にお茶でものみませんかの？」■「わしは知ってるんじゃ。人は昔、地上に住んでいたと。それなのに、誰一人としてわしのいうことを信じない。こんなジメジメした場所ではなく、地上に住みたいとは思わんのかね。」

修正した会話文■「おそとの世界はどんなふうになってるのかな。」■「じいさんの世迷言がまた始まったか。人が地上に住んでいるはずないのにな。与太話も大概にしてほしいよ。」■「おや、マキナかの。たまには一緒にお茶でものみませんか？」

ゲーム内での地名：ゼイフォード○○

変換前の会話文■「あら、やだ。お兄さん。いい体してるじゃない。ん～食べちゃいたい。」■「ん？誰だ。お前、まさか機械生命体じゃないだろうね！」■「ここは、ロボットの資材で出来た街ゼイフォードだ。」■「機械は便利なんだけどねえ。私はあんまり信用できないのよ。」■「見てみろ。この大きなロボットの首を！わしのじいさんが取ってきたんだ。すごいだろう！」■「世界とか、シェルターとか……。なんで男の子って、滅ぼそうとするのか。そんなことしたっていいことないのに……。ほんと、バカみたい。」■「これ、ロボットのスクラップで作った花なの。あなたにあげるぞえ。」■「見てぞえ！このパーツかっこいいでしょ！今朝拾ったんじゃ！」■「全く、このポンコツロボットが！まともに動かないなら、スクラップにしてやるぞえ！」■「わしらの生きがいは、多くのロボットを破壊する事だ。早く、やって来んかねえ。」

変換後の会話文■「ん？誰だ。お前、まさか機械生命体じゃないだろうな！」■「ここは、ロボットの資材で出来た街ゼイフォードじゃ。」

Group Report of 2020 SISP

67

Group Number 5

Creative AI■「機械は便利なんだけどなあ。私はあんまり信用できないのよ。」■「見てみろ。この大きなロボットの首を！わしのじいさんが取ってきたんじゃ。すごいだろう。」■「世界とか、シェルターとか……。なんで男の子って、滅ぼそうとするのかしら。そんなことしたっていいことないのに……。ほんと、バカみたい。」■「これ、ロボットのスクラップで作った花なの。あなたにあげるね。」■「見てよ！このパーツかっこいいでしょ！今朝拾ったんだ！」■「全く、このポンコツロボットが！まともに動かないなら、スクラップにしてやるよ！」■「わしらの生きがいは、多くのロボットを破壊する事じゃ。早く、やって来んかねえ。」(*文責：髙橋利孔)

5.2.6 成果発表に用いたデモンストレーション
成果発表にあたり,どのような内容を行うのか理解を深めてもらうことを目的として,デモンストレーション用のプログラムを制作した.このプログラムを作成する上で,Google社が提供するColaboratoryとよばれるサービスを利用した.Colaboratoryでは,ブラウザから Python を記述し,実行できる.Co
laboratory上で動作するように書き換えたことで,大人数での共有を実現した.
(*文責：髙橋利孔)
5.3 視覚班
5.3.1 自動生成
5.3.1.1 自動生成の概要
前期の活動で収集した顔パーツを使用し,以下の2つの方法でモブキャラクターの顔の自動生成を行った.
●

顔パーツを福笑いのように並べて顔画像を生成する●

顔パーツにモーフィング処理を行い顔画像を生成する

1つめの顔パーツを福笑いのように並べて顔画像を生成する方法では,集めた顔パーツのy座標をそれぞれ以下の基準で与えた.
●

髪：髪の毛の一番高い位置と,生え際の真ん中あたりの位置の中点のy座標●

眉：左右の眉それぞれの一番低い位置の中点のy座標●

目：左右の瞳それぞれの中心点の中点のy座標●

鼻：鼻の一番高い点と低い点の中点のy座標

Group Report of 2020 SISP

68

Group Number 5

Creative AI●

口：口の左右の端の点の中点のy座標●

輪郭：顎の中心点

次に顔パーツのキャラクターを精神年齢5段階に分類した.1が最も低く,5が最も高い様に設定した.精神年齢ごとに分類する作業は班員それぞれの判断で行った.最終的に一つのキャラクターは以下のよ
うな構成の属性と情報を持つことになった.
●

●

性別
○

男性

○

女性

年代
○

●

子供

顔パーツ
○

髪画像
■

○

眉画像
■

○

口画像のy座標(口の左右の端の点の中点のy座標)

輪郭画像
■

●

鼻画像のy座標(鼻の一番高い点と低い点の中点のy座標)

口画像
■

○

目画像のy座標(左右の瞳それぞれの中心点の中点のy座標)

鼻画像
■

○

眉画像のy座標(左右の眉それぞれの一番低い位置の中点のy座標)

目画像
■

○

髪画像のy座標(髪の毛の一番高い位置と,生え際の真ん中あたりの位置の中点のy座標)

輪郭画像のy座標(顎の中心点)

精神年齢（5段階）

今回は,男性・子供・精神年齢（5段階すべて）と女性・子供・精神年齢（5段階すべて）の合計10種
類の顔画像を生成した.
福笑いの様に顔パーツを並べる工程では,条件に合う属性を持つ顔画像をランダムに並べて顔画像を生成する.ランダムに生成した顔画像の中から,漫画に登場するような自然な顔画像を得るため以下の条件を設けて顔画像を選別した.

Group Report of 2020 SISP

69

Group Number 5

Creative AI
髪画像のy座標 > 眉画像のy座標 > 目画像のy座標 > 鼻画像のy座標> 口画像y座標 > 輪郭パーツのy座標プログラム内では垂直方向の座標軸が逆なため,プログラム内での条件式の大小関係も逆になっている.
選別した画像の中からゲーム内で使用する,男性・子供・精神年齢(2)と女性・子供・精神年齢(4)の画像をそれぞれ1枚ずつ選び使用した.
2つ目の顔パーツにモーフィング処理を行い顔画像を生成するでは,収集した顔パーツを性格の明るさで5段階に分け,Adobe After Effects を使用しそれぞれにモーフィング処理を行った.性格の明るさは,1が最も暗く,5が最も明るいとした. モーフィングとはコンピュータグラフィックスの手法の一つで,画像Aから画像Bへの自然に変化する映像のことである.今回は明るさ1から明るさ5までの顔パー
ツにモーフィング処理を行い,各パーツ360枚の中間画像を作成した.
この方法では一枚の顔画像を生成するのに必要となる,属性と画像は以下のようになった.
●

●

性別
○

男性

○

女性

年代
○

子供

○

成人

○

高齢者

●

明るさ(5段階)●

顔パーツ画像(明るさ1~5までの中間画像を生成済み)
○

髪画像

○

眉画像

○

目画像

○

鼻画像

○

口画像

○

輪郭画像

モーフィング処理を行う際に各顔パーツの位置は最初の明るさ1のキャラクターに合わせて行っているため,プログラム上で各顔パーツの位置をしてすることは行っていない.プログラム上では,基準となる明るさを決めるスライダーと基準からの差を表すスライダーを用いて顔画像を生成している.
ゲーム上で使用する,男性・成人,男性・高齢者,女性・成人,女性・高齢者の顔画像をこの方法を用いGroup Report of 2020 SISP

70

Group Number 5

Creative AIて生成した.また,この方法は,はこだて未来大学4年迎山研究室の白石さんの協力のもと考案,開発を行った.
(*文責：齋藤慎悟)
25.3.1.2 データの分類
自動生成を行うための準備として,前期に行った顔パーツの分割作業に加えて,データの分類作業を行った.
性格の明るさを入力し顔画像を生成する方法では,ゲームの雰囲気にあう,または,使いたいパーツをもったキャラクターの画像を選び性別・年代・明るさごとに顔パーツを分類した.
精神年齢を入力し自動生成する方法では,集めた顔パーツの画像を全て性別・年代・精神年齢ごとに全て分類した.
また,データ収集に使用した漫画は以下である.
●

アルスラーン戦記,田中芳樹・荒川弘,講談社,2013~●

SKET DANCE,篠原健太,集英社,2007~2013●

ハイキュー!!,古舘春一,集英社,2012~2020●

バクマン。,大場つぐみ・小畑健,集英社,208~2012●

HUNTER×HUNTER,冨樫義博,集英社,1998~●

ふらいんぐうぃっち,石塚千尋,講談社,2012~●

ワールドトリガー,葦原大介,集英社,2013~2018●

暗殺教室,松井優征,集英社,2012~2016●

火ノ丸相撲,川田,集英社,2014~2019●

古見さんは、コミュ症です。,オダトモヒト,小学館,2016~●

攻殻機動隊 THE GHOST IN THE SHELL,士郎正宗,講談社,2013~2016●

咲-Saki-,小林立,スクウェア・エニックス,2006~●

三ツ星カラーズ,カツヲ,KADOKAWA,2014~2020●

終わりのセラフ,鏡貴也・降矢大輔・山本ヤマト,集英社,2012~●

食戟のソーマ,附田祐斗・佐伯俊・森崎友紀,集英社,2012~2019●

彼方のアストラ,篠原健太,集英社,2016~2017●

文豪ストレイドッグス,朝霧カフカ・春河35,KADOKAWA,2013~●

弁護士綾小路晴彦,梶研吾・那須輝一郎,日本文芸社,1994●

僕のヒーローアカデミア,堀越耕平,集英社,2014~

Group Report of 2020 SISP

71

Group Number 5

Creative AI●

魔女と野獣,佐竹幸典,講談社,2016~●

名探偵コナン,青山剛昌,小学館,1994~●

約束のネバーランド,白井カイウ・出水ぽすか,集英社,2016~2020(*文責：齋藤慎悟)

5.3.2 イラストデザイン
5.3.2.1 キャラクターイラスト
前期に製作したキャラクターデザインをもとにゲーム内で実装される主要なキャラクターの立ち絵
及びアイコンを制作した.アイコンは立ち絵の肩周りから上をトリミングして制作している.また,キャラクターの感情がより伝わるよう様々な表情差分を作成しており（怒り/通常/笑顔/悲しみ/驚き/
泣き顔等）.表情差分の数がアイコンの数となる.主人公は立ち絵が1枚,アイコンが5枚.ヒロインはス
トーリーの前半と後半で姿が異なるため立ち絵が2枚,アイコンが7×2=14枚.ドラゴンは立ち絵が1枚
アイコンが7枚.ラスボスはスカーフの有無で立ち絵が2枚,アイコンが2枚である.合計で立ち絵は6枚,
アイコンは差分含め合計28枚である.制作に掛かる時間は描画する対象に応じ変わるが,およそ1枚の立ち絵が2~3日であった.表情差分のための新たな表情の制作は1時間程度であり,アイコンは立ち絵の顔を切り取るだけである.なるべく手間を掛けないよう工夫した部分として表情差分は眉・目・口の組み合わせを複数個用意し,表現したい表情に合わせて表示・非表示を組み合わせて作っている.こうすることで,表情の数だけ新たにすべてのパーツを描き直さなくてもよいため,迅速にゲーム内へ実装する部品として満足するイラストをバリエーション豊富に制作することができた.

図5.3.2.1-1 メインキャラクターの立ち絵及びアイコン

ゲーム内でマップ上に配置されたモブキャラクターに話しかけた際に画面下部に表示されるモブキャラクターのアイコンを制作した.自動生成アルゴリズムにより出力されたモブキャラクターの顔画
像をキャラクターデザインとして用いる形で,ゲーム内に実装できるように人の手でリデザインしたアイコンをゲーム内で使用している.出力される顔画像はキャラクターの明るさで5段階のにバリエー
ションがあり,描画時に参考とするキャラクターデザインとして十分なクオリティがあったため,短期間での制作を行うことができた.モブキャラクターは男性・女性,子ども・成人・高齢の組み合わせで6種類である.加えてそれぞれのイラストには3つのカラーバリエーションを与えたため,モブキャラク

Group Report of 2020 SISP

72

Group Number 5

Creative AI
ターのアイコンは合計18枚である.自動生成アルゴリズムによりキャラクターデザインが既にある状態で制作を開始できるため,ほとんど模写をする形になる.これによりモブキャラクター1体のアイコ
ンイラスト制作に掛かる時間は3~4時間程度で済む.主要キャラクターと比較するとキャラクターデザ
インという工程が無いため,非常に少ない工程・時間でイラストが完成した.

図5.3.2.1-2 モブキャラクターのアイコン(*文責：西谷秀市)
5.3.2.2 マップ
前期に制作したシェルターAとシェルターCの中間となる地上エリアのマップデザイン画を制作した.地上は大まかに3つのバイオームになっており,「森」「草原」「砂漠」を順に進んでいく.砂漠エ
リアと草原エリアの中間に橋があり,そこで中ボス戦が行われる.
(*文責：西谷秀市)
5.3.3 モデリング
前期では主にBlenderの使い方,及びモデリングの練習に重きをおいて活動を行ったが,後期では実際にゲームに登場する3Dモデルの制作を進めていかなければならない.
(*文責：山本聖也)
5.3.3.1 人型素体モデル
まずは基本的な人型の素体モデルの制作を行った.後にこのモデルをもとにして主人公やヒロインのモデルなどを制作していく.前期が終了するあたりから制作にとりかかっていたが,頭の部分や目の部分が自然に見えるようにモデルを制作することが中々難しく後期が始まってからもしばらくこの素体の制作に時間がかかった.
素体モデルの形ができた後はボーンを入れる作業を先に行った.ボーンとはその名の通りモデルの骨のことで,モデルが実際に動くときに基盤となる骨組みである.今回はモーションもアセットを利用するため,アセットに合うようにボーンを入れていかなければならない.ボーンの入れ方に関してはこれも動画を見て学習し,実際に行った.ボーンを入れる際にはミラー機能が有効で,これにより左右対称に正確にボーンを入れることができた.また,Unityに持って行った場合に肘や膝があらぬ方向に曲がらないようにするために,若干正常な向きに曲げておくことでこれを回避した.

Group Report of 2020 SISP

73

Group Number 5

Creative AI
ボーンを入れた後はモデルとボーンをリンクさせ,ウェイトの重さを調整した.リンクとはボーンが動いた時にモデルがついてくるようにすることである.ウェイトとはボーンが動いた際にモデルがどの程度ついてくるかの値であり,想定外の箇所にウェイトが乗っていると思った取りに動いてくれな
くなるので,この調整作業は必須である.ここまで行い素体の3Dモデルは完成である.
またモブキャラクターの3Dモデルについては,制作する時間がとれなかったため,人型素体モデルをそのまま活用することとした.

図5.3.3.1-1 人型素体モデル(*文責：山本聖也)
5.3.3.2 主人公,ヒロイン
10月の初めころに人型の素体モデルが完成し,主人公とヒロインのモデルの制作にとりかかった.主人公とヒロインの3Dモデルはあらかじめ視覚班がデザインしていた三面図を用いて制作を行った.人型の素体モデルを中央に配置し,X軸Y軸に三面図を配置することで,三面図を参考にしながらモデリングを行うことができる.素体モデルから実際のキャラクターをモデリングする方法として,素体モデルの表面を変形させて制作する方法と,髪や服などの新たなオブジェクトを追加していく方法の2種類が提案されたが,今回は前者の素体のモデルの表面を変形させる方法でモデリングを行った.
まずは主人公の3Dモデルから制作を開始した.身体の上から順番に制作を始めたが,髪型のデザインがギザギザであることもあり,髪の変形が想定より難しく時間がかかった.髪の制作が終わった後は服の制作を始め,靴,腕の順番で進めていった.モデルの形が完成したあとは色付けを行い,上述のようにBlender上で色付けを行った.目の部分に関しては,瞬きの動作を入れるかどうかの議論があったが,時間の都合上今回は目の部分に色をつけるだけということに決定した.色付けが完了した段階で3Dモデルは完成である.
主人公の3Dモデルが完成したあとはヒロインの3Dモデルの制作にとりかかった.基本的な流れは主人公の3Dモデルの制作過程と同じである.主人公に比べてヒロインの髪はモデリングしやすく,主人公よりも短時間で制作することができた.

Group Report of 2020 SISP

74

Group Number 5

Creative AI

図5.3.3.2-1 主人公,ヒロインの3Dモデル(*文責：山本聖也)
5.3.3.3 ミニドラゴン
主人公,ヒロインの3Dモデルが完成した後,ミニドラゴンの3Dモデルの制作にとりかかった.ミニド
ラゴンはもちろん人型ではないため,キャラクターデザインの三面図を参考にして一から制作する必要がある.ミニドラゴンはまず頭部から生成し,次に胴体,手足,翼の順番で制作していった.かなりの作業量であるため,多くの時間を取ることが予想されていたが,班員の集中力が高かったことで,予定
よりかなり早くモデルを仕上げることができた.ミ二ドラゴンの色付けにおいてもBlenderで行い,キャラクターデザインを見ながら色を付けていった.次に主人公やヒロイン達と同じようにボーンを入れる作業を行うが,ドラゴンの動きのアセットはなかったため,ボーンにおいても一から考えて入れていく必要があった.ミニドラゴンの骨格を頭の中でイメージしつつボーンを追加していった.その後は同様に実際に動かしてみてウェイトの確認を行い,値の調整を行っていった.ここで実際にミニドラゴ
ンの口を開閉した場合に,モデルの衝突によって口内の色が自然なように見えないという問題が発生したため,動かしつつ色の調整を再度行った.
最後にアニメーションの制作を行った.ここでいうアニメーションとは,実際にUnityで登場させた
時に,動かずにいるときの待機モーションであったり,攻撃を仕掛けたときのブレスモーションのような指定された動きのことである.主人公やヒロイン達のアニメーションは人型のアセットを用いるため自分たちで制作する必要はないのだが,前述の通りドラゴンの動きのアセットはなかったので,ミニドラゴンの動きは自分たちで作らなければならなくなった.今回制作したのは,動かずにいるときに主人公の後方で翼を上下に動かして空中に浮いているアニメーションと,サポートとしてブレスを吐いてくれるときのアニメーションである.これらのアニメーションはBlenderのアニメーション機能を使って制作した.途中のシーンとそのフレームを設定するだけで,それらのシーンに至るまでの動きを補間してくれるので,自然な動きに見えるようにフレームを調節しながら制作を行っていった.アニメー
ションの制作が完了した段階でミニドラゴンの3Dモデルは完成である.

Group Report of 2020 SISP

75

Group Number 5

Creative AI

図5.3.3.3-1 ミニドラゴンの3Dモデル(*文責：山本聖也)
5.3.3.4 小物類
ミニドラゴンの3Dモデルの制作と同時に小物類の制作も進めていた.前期から制作を進めていた杖には色付けがなされた.ゲーム内に登場させたいもののうち,世界観が合わないなどの理由でアセットが見つからなかったものは自分たちで制作する必要があったため,例えば図5.3.3.4-1のような休憩所などを制作した.どちらもSubstance Painterでテクスチャを貼り付けてリアルな質感を出している.

図5.3.3.4-1 杖と休憩所の3Dモデル(*文責：山本聖也)
5.3.3.5 敵キャラクター
敵キャラクターのモデリングも行った.当初は敵キャラクターもアセットで補う予定だったのだが,アセットで補える数が思ったより少なく,急遽制作することになった.この敵キャラクターに関してはもととなるデザインなどは存在せず,完全にオリジナルでモデリングすることとなった.まずは制作する敵キャラクターの種類の検討を行った.ステージに森と砂漠があるため,RPGにおいてそのエリアでよく出てくるであろう敵キャラクターを想像して,そのほかに時間とスキルを加味して検討し,その結果虫型とゴーレム型の敵キャラクターを制作することに決定した.

Group Report of 2020 SISP

76

Group Number 5

Creative AI
最初に虫型の敵キャラクターのモデリングから開始した.どのような形状にするかを決めるために実際の昆虫の画像を検索し,構想を得た.今回はテントウムシを参考にしてモデリングを進めることを決め,頭部と胴体部分を分けてモデリングを始めた.この虫型の敵キャラクターに関してはどれだけ気味悪いかをテーマに掲げモデリングを行ったため,3Dモデルのあらゆる箇所にリアルさを出せるような工夫を凝らした.触覚はもちろんのこと,胴体の端の部分や足の関節部分を細かく作りこんだりなど様々な点にこだわりを入れた.武器やキャラクターのモデリングを参考にし,ミラー機能を駆使して制作を行った.モデリングが終わった後はボーンを入れる作業に入るのだが,システム班と相談したとこ
ろ足の動きだけ制作できれば後は動かせるということが共有できたため,足にのみボーンを入れることとなった.後はミニドラゴンと同様に,Blenderのアニメーション機能を用いて足が動くアニメーシ
ョンを制作した.色付けに関しては,虫型の敵キャラクターがそれほど複雑な色分けをする必要がない
ことと,Unityの方で簡単に単色で着色できることが明らかになったことを加味して,システム班に任せることとなった.
なお虫型の敵キャラクターは背中にトゲを生やした差分モデルも制作する予定であったが,他の敵キャラクターモデルの制作との時間の兼ね合いを鑑みて断念することとなった.

図5.3.3.5-1 虫の3Dモデル

2つ目はゴーレム型の敵キャラクターのモデリングだが,ゴーレムの構想が2つ出てきてどちらも魅力的な敵キャラクターになりそうであったため,ゴーレムは2種類制作することとした.
一つは全体的に丸い形状をしたゴーレムである.以下,丸型ゴーレムと呼称する.丸型ゴーレムはUV
球のオブジェクトを変形させてモデリングを行った.まずBlenderの中央に胴体となるUV球のオブジェ
クトを追加し,拡大して大きさを調整した.その後にY軸に合わせて半分にし,Y軸ミラーを施した.作業量を減らすためモデリングは半分のみに対して行い,頭の中の丸型ゴーレムのデザインの構想に近づけるように,メッシュを伸ばしたり,内側に押し込んだりして制作を進めていった.全体的に丸い形状であるため,前後がはっきり分かるよう,胴体の前面は隆々さを出した.丸型ゴーレムは首と頭部がないデザインであったが,襲ってくる際,攻撃の意志があるような表現をするために,胴体上部に頭部に見えるような部分を追加した.腕部や足部に関してもUV球のオブジェクトを変形させて制作し,胴体同様ミラー機能を用いることで片方のみモデリングを行った.腕部はゴーレムの攻撃力の高さを表現するため身体全体のバランスと比べ大きめにし,岩石でできている設定であるため,自然な岩のようなごつごつさをだすために注意してモデリングしていった.また自然的でありながらも先端部分には手のような印象を与える突起部分を追加した.腕部の中心部分には関節部分を作ることで,自然な攻撃モーGroup Report of 2020 SISP

77

Group Number 5

Creative AI
ションが行えるようにした.足部は胴体の大きさを強調するため小さめにし,腕部と同様にごつごつ感に注意しモデリングを行った.
もう一つのゴーレムは全体的な形状に歪さをもたせたゴーレムである.以下,歪型ゴーレムと呼称する.テーマに歪さを設定したのは,本来ならありえないような歪さをもった岩石が動くことで,視覚的な圧力や怖さを演出したいと考えたからである.歪型ゴーレムにおいても基本的な制作方法は丸型ゴーレムと同じで,UV球のオブジェクトを変形させてモデリングを行った.ただし,上述したように今回のゴーレムは岩石でできている設定なので,自然な感じとテーマである歪さを出すためあえて胴体部分にミラー機能は使わず,左右非対称になるように調整して制作した.胴体部分はトゲのような飛び出した部分があるだけでなく,あえて腰の部分は思い切り押しつぶして細めたりと多くの工夫を凝らした.腕部に関しては丸型ゴーレムと同様な理由で大きめにモデリングし,足部は丸型ゴーレムに比べて若干縦に大きくしたかったので少し長めにした.腕部と足部に共通して,丸型ゴーレムと同じようにごつごつ感を表現した.歪型ゴーレムにおいては頭部があるが,目や口のようなパーツは時間の都合上制作しないこととなった.
両方のゴーレムのモデリングが完了した後,ボーンを入れていった.どちらのゴーレムも人とは異なる構造をしているように見えるが,人型の動きのアセットを用いるため,主人公やヒロインと同じようなボーンの入れ方をした.次にウェイトを調整していくが,ここは人と違う部分があるため,動きを検証しながら丁寧に調整を進めていった.具体的には,丸型ゴーレムにない頭部の挙動や,腕部足部の関節の挙動である.ボーンを入れ終わったら色付けだが,虫型と同様Unity上で着色できるため,システム
班に任せることとなった.

図5.3.3.5-2 ゴーレムの3Dモデル(*文責：山本聖也)
5.3.4 アセット
前期で話し合いを行い,おおよそ使用するアセットを選考したが,後期で特に変更点はなかった.
マップの情景に関しては,登場するステージが決まった後,制作する過程でアセットを使用した.森,
草原,砂漠それぞれの情景を壊さないようにアセットを追加していき,シェルターAとシェルターCについても,登場する建物の多くの部分にアセットを使用した.敵キャラクターに関してはラスボス用として,ロボット型のアセットを使用した.他の敵キャラクターは視覚班で制作した3Dモデルを使用することとし,前期で敵キャラクターとしての使用を予定していたアセットは,世界観の統一の視点から見Group Report of 2020 SISP

78

Group Number 5

Creative AIて,成果発表時点でのバージョンでは登場しないこととなった.そのほかに3Dモデルを動かすためにア
ニメーションのアセットを使用した.使用したのは人型のアニメーション1種類である.これは主に動かす必要がある主人公,ヒロイン,ゴーレム型の敵キャラクターが全て人型のボーンが入っており,この1種類のアニメーションで上記のキャラクターを全て動かせるからである.
なおアセットの追加や調整などは全てUnity上で行うため,システム班に委託することとした.
(*文責：山本聖也)
5.4 音響班
5.4.1 データ収集
今年度は, 昨年度に収集されたフリー音源と今年度分析に使ったゲーム「NieR:Automata」[5-5]「ファイナルファンタジーX」[5-3]「ファイナルファンタジーX2」[5-4] の
合計 354個のデータを収集し, ゲームで分析したデータをニューラルネットワークで学習させた.
(*文責：荻野永和)
5.4.2

データ分析

今年度のシナリオ班の目標が泣けるシナリオの生成であるため,音響班のデータ
オ班と検討し,泣けるゲームを分析した.

分析もシナリ

具体的な作品名としては, 「NieR:Automata」「ファイナルファンタジーX」 「ファイナルファ
ンタジーX2」を分析した.
データ分析では各シーンについてシーンの詳細を記述し,前期に決定した感情の項目( 1.怖い,
冷静な, 宗教的な, 2. 暗い,憂鬱, 悲しい 3. 夢のような, 感傷的な, 優しい, 4. 穏やか,静かな, 叙情的な 5. 優雅な, 滑稽, 奇抜な 6. 明るい, 幸せ, 派手な 7. 爽快, 興奮, 衝動
的 8. 力強い, 雄大な, 重苦しい )に分類した.
分類方法は0から1の範囲の0.1刻みで数値化した.特に,感動するシーンについては感動する理由,
背景,内容を記述した.加えて,14個のカテゴリ( 人物の辛苦, 夢, 幸福, 絆, 再開, 努力, 葛藤,
感謝と後悔, 自責, 日常崩壊, 退場, 自己犠牲, その他 )に分類した.

·

NieR:Automata
NieR:Automataでは60個のシーンを分析し,流れているBGMから感動するシーンと普通のシーンに分類した.感動するシーンについては詳細をExcelに記載した.

·ファイナルファンタジーX
ファイナルファンタジーXでは234個のシーンを分析し,流れているBGM から感動するシーンと普通のシーンに分類した.感動するシーンについては詳細をExcelに記載した.

Group Report of 2020 SISP

79

Group Number 5

Creative AI·

ファイナルファンタジーX2
ファイナルファンタジーX2では130個のシーンを分析し,流れているBGMから感動するシーンと普通のシーンに分類した.感動するシーンについては詳細をExcelに記載した.
(*文責：元満丈寛)

5.4.3 学習させるまでの過程●

One-hotベクトルへの変換

学習させるまでの過程としては,曲の音響的な情報を調べるために「NieR:Automata」「ファイナルファンタジーX」「ファイナルファンタジーX2」の三作品の音響特徴量の抽出を行なった.そのデータをニューラルネットワークへの学習を容易にさせるためにデータの調整を行なった.抽出した.具体的には,BPMとスペクトル重心,クロマベクトルの0から1までの小数を6次元のOne-hotベクトルに変換した.ベクトルを6次元にした理由としては偏りを防ぎ,データが一様に散らばるようにするためである.感動するデータに関しても分析したExcelを元に泣けるシーンだけを取り出し,普通のシーンと同様に音響特徴量を抽出し,One-hotベクトルに変換した.

●

データの統合ニューラルネットワークでは学習する際のデータセットを作成する必要があるため,用意した以下の3つのデータを結合し作成した.

1.

分析した感情特徴量とシーンに対応する楽曲番号が記載されているCSVファイル

2.

One-hotベクトル変換した音響特徴量と対応する楽曲ファイルが記載されているC
SVファイル3.

昨年度使用した感情特徴量と音響特徴量,そして曲やシーンに対応する楽曲番号が記載されているCSVファイル

結合の手順としては,まず1と2を結合し,結合したものにさらに3のデータを加え結合した.感動するデータは以下の4と5のデータを結合し,データセットを作成した.

Group Report of 2020 SISP

80

Group Number 5

Creative AI
4.

感動するシーンの分析した感情特徴量と対応する楽曲番号が記載されているCSV
ファイル

5.

感動するシーンのBGMをOne-hotベクトルに変換した音響特徴量と対応する楽曲番号が記載されているCSVファイル

これらの二つのデータセットを用いてニューラルネットワークに学習させた.学習に使用したデータの数は合計で726となった.
(*文責：元満丈寛)
5.4.4 ニューラルネットワークの実装
楽曲を選択するシステムを制作するにあたり, システムの一部に3つのニューラルネットワークを用いた. このプログラムは昨年度に制作されたプログラムをベースにして, バグの修正と感動するシーンとしないシーンで動作が変わるようにプログラムを変更したものであり, 入力層8, 中間層のユニット数が5, 出力層6の3層で構成されている中間層1層のもので, 入力として感情特徴量を入力し,出力として音楽特徴量を出力する. テストデータはK分割法を用いて分割した. K分割法とは, 元データをk個にランダムに分割し, 一部を検証用, 残りでテストを行う手法のことである. ライブラリ
は昨年度同様Kerasである. Kerasとは、TensorFlowやCNTK, Theano上で動くライブラリの1つであり,認知的負荷が少なく, 簡単に計算グラフを構築できる. 活性化関数は中間層でReLUを用い, 結果の値が高かったところに1を立てonehotベクトルとしたReLUのメリットとして, 微分値が定数なので, 計算量を圧倒的に減らすことができ, 誤差逆伝播の計算効率が良いことの他に, 微分値が一定であることから, 誤差逆伝播による勾配の消失問題を防ぐことができる点が挙げれられる. また出力層では,分類問題に使われるsoftmaxを用いた. 損失関数はmean_squared_errorを用いた. また, epoch数は1000とし, EarlySoppingというコールバックを採用した. また, 今回は泣けるゲームを作るという目標のもと活動しているので, 昨年度から変更して, 入力データとして新たに泣けるかどうかを判別する
ベクトルを追加した. あるシーンが泣ける時は1, 泣けない時は0とする. それに併せてプログラム
も, ベクトルが1の時と0の時で動作が変わるように変更した.
(*文責：荻野永和)

5.4.5 コード進行の自動生成
楽曲制作の過程において, コード進行は重要な役割を持つ. コード (chord) とは日本語で和音のことであり, これは複数の音を同時に鳴らしたものである. 例えば, 「C」というコードは, イタリ
ア語の音名で言う「ド, ミ, ソ」の3つの音で構成された和音であり, 「Cm」というコードは「ド,ミ♭, ソ」の3つの音で構成された和音である. 他には, 「C7」というコードは, 「ド, ミ, ソ, シ♭」の4つの音で構成された和音であり, 「CM7」というコードは, 「ド, ミ, ソ, シ」の4つの音で構成された和音である. このような音の組み合わせで, 明るい響きや暗い響きなどの雰囲気を表現することができる.
また, コードには効果的な繋ぎ方がある程度限定されており, 作曲家はこれらを使って音楽を作成している. 3大進行と呼ばれてる, 「王道進行」「小室進行」「カノン進行」などがその例である.

Group Report of 2020 SISP

81

Group Number 5

Creative AI
コード進行とは, この和音同士の繋がりの総称である. 例えば, 王道進行はCメジャースケールにおける「F→G→Em→Am」の繋がりであり, 数々の楽曲に使用されている.
今回は, このコード進行を既存の楽曲から収集し, マルコフ連鎖を用いて生成する. そして, 生成
したコード進行をもとにゲーム内のBGMを作成する.

(*文責：天野太一)

5.4.5.1 マルコフ連鎖
マルコフ連鎖はPythonのライブラリで, シンプルで拡張可能なマルコフ連鎖ジェネレータであるmarkovifyを用いて実装した. 学習データのコード進行は13480楽曲から収集し, イントロ, Aメロ, サビ等のパートごとに分割した. それぞれのデータは楽曲のキーごとに分類し, テキストファイルに保存していった.
マルコフ連鎖は2階マルコフ連鎖を用いて実装した. これは, 次の状態が現在を含めた過去2個の状態履歴に依存して決定する確率過程である. コード進行は,markovify内の関数, markovify.make_sho
rt_sentenceを用いて20種類かつ100文字以内で生成した. 学習データは, 任意のキーのテキストデータを用いてプログラムを実行した.

図5.4.5.1 Dスケールで実際に生成したテキストデータ

このプログラムでは, 小節の概念が存在せず前後の繋がりしか考慮していないため, いくつかの不備がある. 例を挙げるならば経過音の認識ができない点だ. 例えば「Dm→G7→Em→Am」と1小節ごとに変わるコード進行があったとき, 「G7→Em」の間に「G/F」を入れたり, 「Em→Am」の間に「G#dim」を入れる等, コード進行をより滑らかに繋ぐことができる. しかし, このプログラムではこの経
過音の認識ができないため, 「Dm→G7→G/F→Em→G#dim→Am」というコードがあった時に, 先述のよ
うな経過音が挟まれていると解釈することもできるし, 1小節ごとに変わる計6小節のコード進行と解Group Report of 2020 SISP

82

Group Number 5

Creative AI
釈することもできる. これらを回避するためには小節上での移置も記憶させたり, 音楽理論的なアプローチも必要だったのではないかと考える.

(*文責：天野太一)

5.4.5.2 Songleを用いたコード進行分析
SongleのAPIを用いたコード進行分析も考えた.Songleとは, 音楽をより深く理解しながら能動的に音楽鑑賞が楽しめるサービスのことであり, 音楽理解技術で解析した内容（サビ, メロディ, コー
ド, ビート）を見ながら,楽曲中のサビ区間や繰り返し区間へ頭出しして聴くことができる. プログ
ラムはJavaScriptを用いて作成し, Webブラウザ上で動作するように作成した. Songle APIにはPlayerクラスのchordEnterイベントというものがあり, それを用いてSongleに登録されている楽曲をブラウザ上で再生しながらリアルタイムでコード進行を分析し, 逐次テキストファイルに分析したコード進行を書いていくというプログラムを作成した. また, 楽曲の再生中にサビに入ると, ここからサビであると分かるようにするためにコンソール上にサビと表示させるようにした. しかし,Songleには膨大な音楽データが登録されており,それらのデータを効率的に収集するプログラムを作成する時間が足りなかったため,Songleでのコード進行分析は断念した.
(*文責：荻野永和)

5.4.6 楽曲制作
2階マルコフ連鎖を用いて生成したコード進行を元に, ゲーム内のBGMの制作を行った. 作曲ソフト
はCubase10を用いた. 生成した20種類のコード進行から, 任意のコード進行を選択し楽曲制作を行った. 音源は, LENNER DIGITAL Sylenth1, XFER RECORDS SERUM, EASTWEST Symphonic Orchestra Gold
Complete, Symphonic Choirs Gold, を用いて楽曲作成を行った.
それぞれのBGMが再生される場所, 場面をイメージしながらメロディの制作や音作りを行った.
以下にそれぞれのBGMで使用したコード進行を記す.

オープニングのBGM（Dスケールで生成）
GM7 → Gm6 → F#m7 → Bm7 → Em7 → A7sus4 → F#m7 → Bm7 → GM7 → F#m7/B → Bm7 → A→ G → D → Asus4 → A
このコード進行は, 7thやsus4が多く使われており美しい進行だと感じたため採用した.

フィールドのBGM（Bmスケールで生成）Group Report of 2020 SISP

83

Group Number 5

Creative AI
Dm → Bb → F → C → C#dim → Dm → BbM7 → C → Dm → F → Bb → Dm/A → Em7-5 → A7
→ Dm → C/E → F → C
このコード進行は, 12番目のDm/Aと14番目のA7が経過音として使用している. 広大なフィールドのイメージに合致していると感じ採用した.

ボス戦のBGM（Bmスケールで生成）
Bm → F#7/A# → Bm7/A → Em79 → A7 → DM7 → B7sus4 → Bm7 → B7sus2 → Bm7 → Em7 → A
sus4 → Dsus4 → D → G → Gm
このコード進行は, 8つ目と10番目のBm7は経過音として使用した. sus4やsus2が使われており,響
きが美しく荘厳であると感じたためこのコード進行を使用した.

Bm7 → GM7 → A → F#m7 → Bm7 → A/C# → D → B7/D# → Em7 → F#m7 → A/G → F#sus4 → F#7 → GM7 C#m7/F#

このコード進行も荘厳さを感じたため採用した. 1小節ごとに変化するコード進行であるが, 数が15個しかないため変拍子感を演出している.

(*文責：天野太一)

5.4.7 他班との連携
5.4.7.1 シナリオ班
シナリオ班には, 物語のシーンにおいて8種類の感情特徴量の設定をお願いした. 設定して頂いた
感情特徴量は楽曲選択のプログラムで使用した. また, 「泣ける」シーンとそうでないシーンの分岐のためにe0, e1タグの作成をお願いした. これも, 同様に楽曲選択のプログラムで使用した. 作品分
析においても, 感情特徴量の分析について協力していただいた.
(*文責：天野太一)
5.4.7.2 システム班
システム班には, 最終的なゲームのBGMとSEの実装をお願いした. また, 依頼されたSEを作成した.
(*文責：天野太一)

Group Report of 2020 SISP

84

Group Number 5

Creative AI

5.5 システム班
5.5.1 他班との統合
5.5.1.1 シナリオ班
シナリオ班との統合作業ではまず,シナリオ班に物語上で必要になってくる演出内容を考えてもらい,その内容をできる限り再現できるようなスクリプトを書いた..
そして,イベントがマップ上のどの部分で始まるのか,またそれが場所なのか,キャラクターなのか,
中継地点のオブジェクトや,敵を倒したときなのか等の指示をシナリオ班にもらいオブジェクトを設置していった.
主に使ったScenarioRead.csスクリプト内の関数の説明は下記の通りである.

ReadScenario
読み込むtextDataにtextFile.textを入れデータフォーマットを読み込む.textDataの文字列を\n(改行)で区切りsplitTextの配列に入れ,splitTextの1行目を読んでいるとき(currentNum = 0のとき)にSearchEventHeadを呼び出し任意のイベントの始まりを探す.
そして,canEventがtrueまたは,canQuestがtrueでかつ,findobjectがtrue(近くにオブジェク
トが存在しているの意)のとき,kaiwaUIをtrueにしテキストボックスを表示さる.currentNum = (curr
entNum + 1) % splitText.Lengthをすることで,currentNum(現在見ている行数)にプラス1して次の行に進めるようにした. しかし配列の大きさを超えないようにsplitTextの配列の大きさで割った余りを使った.
splitText[currentNum] = splitText[currentNum].TrimEnd()ではTrimEnd()を使うことで末尾のスペースや,改行文字を消しエラーが出ないようにした.これ以降は以下の関数をテキストでデー
タに合わせて呼び出す.

●

ShowName(splitText, currentNum)を呼び出し名前を表示する.

●

IconAppear(splitText, currentNum)を呼び出しキャラクターアイコンを表する.

●

textDatasub = GetBetweenStrings(splitText[currentNum])でシナリオ班から受け取ったテキストデータから表示するべき文字だけを抜き出す.

●

SeparationPoint(splitText, currentNum)を呼び出しイベントの中のシーンの切れ目を作る.

Group Report of 2020 SISP

85

Group Number 5

Creative AI●

StopTime(splitText, currentNum)を呼び出してフィールド上の動きを止める.

●

ResumeTime(splitText, currentNum)を呼び出しフィールド上を再び動かし始める.

●

SetStillPicture(splitText, currentNum)任意の背景画像を表示する.

●

SetStandingPicture(splitText, currentNum)任意の場所に任意のキャラク
ターの立ち絵を表示する.

●

FlagManager(splitText, currentNum)フラグを新しく追加したり,上げ下げの変更をする.

●

QuestManager(splitText, currentNum)クエストで敵やオブジェクト,キャラ
クターをマップ上に表示させたり,非表示にしたりする.

●

SetMusic(splitText, currentNum)任意の曲を流す.

●

if (SearchEventEnd(splitText[currentNum]) == true) breakとし,SearchE
ventEndがfalseになるとイベントが終わり,読み取るのを終了する.

if (!characterName.Equals("") && characterName != null)からの部分では,データフォー
マットからキャラクターの名前を取り出し配列に入れ,画像や名前を配列の番号で管理できるようにした.
キャラクターの名前がないとき(ナレーションのとき)IconAppearとtextLabelをfalseにしてアイコンとテキストボックスの名前の部分を非表示にする.反対に,名前がある場合(キャラクターのセリフのとき)はIconAppearとtextLabelをtrueにしてアイコンとテキストボックスの
名前の部分を表示する.

ShowName
テキストデータのキャラクター名, 画像名をキャラクター名と画像名に分けて配列に入れ,配列の数で管理できるようにした.

Group Report of 2020 SISP

86

Group Number 5

Creative AI

IconAppear
この関数ではテキストデータ中のi0や,i1を見つけ,その数字に対応するキャラクターの画像を表示する.これはShowNameで入れた配列の数字に対応している.

SeparationPoint
テキストファイル中のzを探し,一度全ての立ち絵を非表示する関数です.これはイベント内のシーンを切り替えるタイミングで呼び出される.

StopTime
これはテキストデータ中のcC(0)というタグを認識すると,pauseScriptのPauseという関数を用い,マップ上の時間を止めシナリオに集中できるようにするためのものである.

ResumeTime
これはStopTimeの反対でテキストデータ中のcC(1)というタグを認識すると,pauseScriptのRe
sumeという関数を用い,マップ上の時間を戻しプレイヤーが操作できるようにする.

SetStillPicture
これはテキストデータ中のpT0や,pT1などのタグを認識すると,その数字に応じた画像を背景として表示する.
そしてFUを認識すると背景を表示するときにフェードアップで表示する.FOを認識するとその画像がフェードアウトしていく.WFを認識すると,背景を表示しているレイヤーより一つ上で真っ白の画像をフェードインさせすぐフェードアウトさせる.下の背景画像が見えなくなっている間に次の背景画像に切り替え,滑らかに切り替わったように見せる.BFでは黒い画像でWFと同じく上にかぶせ,その隙に下の画像を切り替え流ようにした.
フェードする時間はfadeFuncの関数内のalfa += (float * Time.deltaTime)のfloatの部分を変えることによって調節することができる.

SetStandingPicture
この関数はr0や,r1の数字で定義されるキャラクターの立ち絵の画像をf0,f1,f2,f3で定義される位置に表示する関数である.

Group Report of 2020 SISP

87

Group Number 5

Creative AI
FlagManager
イベントやクエストの進捗を管理するためにテキストデータ上でcEN(0),cEN(1)等を認識した
ときにイベントフラグの上げ下ろしし,テキストデータ上でcQN(0,)cQN(1)等を認識すると,クエスト
フラグの上げ下ろしをする.Nという任意の数字が名前のフラグがない場合はdictionaryにフラグとそ
れがtrueなのか,falseなのかをセットにして追加するようになっている.

QuestManager
この関数ではまずObjectStにその任意の数字 (クエストの識別の名前になっている数字)を入れenemy0(0),item1(1),human2(0)などという文字列を認識するとクエスト0や1,2の敵や,アイテム,人をunity上のマップの予め準備しておいた位置に表示させる.

SearchEventEnd
これはテキストファイル中のendを探し,currentNum(現在読みテキストファイルの行数),nameCount(Event宣言時の定義された名前とアイコンを一致させて,管理しているもの)を0に戻し,次回イベントを探すときにテキストの一番上から探すことができるようにした.
nextIsQuestの値によって次に読むのがサブのクエストファイルなのか,メインのイベントフ
ァイルなのかを選択する.ここはイベントが終了し,プレイヤーのアクション操作に切り替わる部分なので,SeparationPointの関数でもやったがエラーや,ミスを防ぐ意味でもう一度全ての立ち絵を非表示にしなおした.
そして最後に,kaiwaUIとIcon_objectをfalseにすることで,テキストボックスと表示されているアイコンを非表示にする.
(*文責 : 青山美月)
5.5.1.2 キャラクター会話班
キャラクター会話班との統合作業ではまず,キャラクター会話班から青年,少年,少女,老婆などのモブキャラクターの大まかな年齢と性別,そしてそのキャラクターのセリフ,出現する街の情報が送られてきた.システム班ではその情報をもとに,まずそれぞれの街で一箇所に固めないようにモブキャラク
ターのオブジェクトを配置した.
次に,mob_talk.csにてキャラクターのセリフと表示名,そしてアイコンを1つずつまとめて行った.mob_talk.csの挙動としてはUnity上でプレイヤーの近くのオブジェクト(モブキャラクター)の名前を検出する.そして,switchで名前ごとに分けてあるアイコン,セリフ,表示名を返しUnity画面上に表示する.
表示する際,日本語としておかしな部分で改行してしまうことがあったため,\nの改行文字を元の文章に入れてもらい改善した.
この改善の結果一度にテキストボックスに表示されるギリギリの文章だったものなどが,一度にテキストボックス中に表示できる上限を超えてしまった.そのため新しく,セリフ中の"/"の文字を認識

Group Report of 2020 SISP

88

Group Number 5

Creative AI
すると"/"以降の文章を一旦表示せず,次のテキストボックスに表示するようにした.今回はセリフに使わないであろう文字ということで"/"になったがmob_talk.cs中のcountSlash = CountKeyWord(kaiwaText, '/');
text_split = kaiwaText.Split('/');の部分のシングルクオーテーションで囲まれている部分を変更すればどのような文字でも構わない.
(*文責 : 青山美月)
5.5.1.3 視覚班
視覚班との統合は,主に2つの作業があった.一つ目は,視覚班が作成した3DモデルをUnity上で読み込み,それに当たり判定やアニメーションを付与することである.もう一つは,視覚班が作成した顔ア
イコンを使用し,それをキャラクターの会話部分で表示させることである.
視覚班が提供したこれらの素材が無ければ,このゲームはゲームとして成立しなかっただろう.
(*文責 : 森本大翔)
5.5.1.4 音響班
音響班との統合作業では送られてきた150ほどの楽曲をUnity上でBGMController.cs内のmusicLayoutという配列の中に手作業で入れた.
まず,ScenarioRead.cs内のSetMusic関数でm0や,m1などのタグを認識しその数字部分を取り出し,BG
MController.csにその数字を送るようになっている.
そして,BGMController.csでは,その数字と同じ数字の配列の中に入っている音楽を再生する使用である.どの曲も2分程度で終わってしまうためUnity上で曲をループさせながら流すようにした.
他には,急に曲が大音量で始まったり,急に曲がプツッと切れてしまうと耳に悪いし,ゲームに集中できなくなると考えたため,曲の開始はフェードインで徐々にボリュームをあげ,曲の終わりはフェー
ドアウトで徐々にボリュームをさげながら次の曲に切り替えができるようにした.
音響班からは他にもドラゴンの攻撃時のSEをもらい,アクション時に流れるようにしたり完成度の高いゲームになった.

(*文責 : 青山美月)
5.5.2 アクション
成果発表までの開発では,アクション要素にさらなる要素が追加された.

SetPosition.cs
SetPosition.csに大幅な変更があった.それまで,SetPosition.csは自分を中心としたランダムな円の中からある一点を指定し,その座標をEnemy_move.csに送るという仕様であった.しかし,この方法だGroup Report of 2020 SISP

89

Group Number 5

Creative AIと,途中で障害物があったり,移動が出来ない場所に座標が設定されてしまうと,敵がスタックしてしまうという問題が存在していた.そのため,Unityの機能の一つであるNavMeshAgentを使用した.NavMes
hAgentは,障害物を回避して,目的地に到着するルートを探索する機能である.この機能を使うことにより,敵は障害物を回避し,理想的なルートで目的地まで接近する.NavMeshAgentを使用するためには,マップに移動可能エリアを指定する必要がある.今回は,Unityの機能で,自動で移動可能エリアを設定した.

Enemy_move.cs
SetPosition.csの変更,さらに,敵の追加に伴って,Enemy_move.csも変更する必要があった.前期では,人型の敵1体のみであった.しかし,追加で4体の敵が追加されたため,それぞれに対応したAnimatorと処理を行った.

（*文責：森本大翔）
5.5.3 マップ
後期のマップ制作は前期に引き続き,視覚班からいただいた資料を元に街や,外の森等のフィールドの制作をした.フィールドの製作時には前期と同様にTerrain機能を用いてマップの高低差や,木々や草,フィールドのテクスチャを指定した.そして,Unity Asset Storeのアセットから適宜相応しい建物
や,岩等のオブジェクトを使いゲームの世界観にあうマップを制作した.
加えて後期では,キャラクター班の作った会話をさせるためのモブキャラクターを街のマップに置いたり,シナリオ班の作ったクエストや,イベントに必要な敵キャラクターや,オブジェクト,キャラク
ターをシナリオ班の指定の場所に配置した.
他には,マップ間の移動をしてもプレイヤーキャラクターをマップ移動前と同じように動かせるよ
うに,プレイヤーキャラクターや,会話のためのUI(テキストボックス等)他にもカメラ等を次のマップにも引き継げるようなシステムを実装した.
そのためにDontDestroy.csを作成した.DontDestroy.csでは基本的にはUnity上で次のシーンに内部のパラメータが全く同じオブジェクトをコピーしている.しかしこのままでは,シーン遷移のたびに該当するオブジェクトが増殖してしまうので,それを防ぐ目的でbool型のsingletonで管理している.
(*文責 : 青山美月)
5.5.4 RPG要素
後期からは,ゲームのRPG要素の開発を始めた.そのため,アセットを使用し,休憩地点でレベルアッ
プメニューを表示し,そして実際にレベルアップを行えるようにした.

PlayerStatus.cs
RPG要素を追加するため,PlayerStatus.csの変更を行った.プレイヤーのそれぞれのステータスをレ
ベルアップできるような変更を施し,さらに,経験値を追加した.経験値は,Enemy_move.csから変更できるようになっている.

Group Report of 2020 SISP

90

Group Number 5

Creative AI（*文責：森本大翔）

Group Report of 2020 SISP

91

Group Number 5

Creative AI
第 6 章 成果発表
6.1 概要今年度の一年間の活動を発表するため,2020年12月4日にオンラインにて最終成果発表を行った.成果発表では一回15分で前半45分,後半45分の1時間30分行った.参加者ははこだて未来大学の教員と学生を含め39名で,全員に10段階の評価アンケートを行ってもらった.はこだて未来大学以外の一般の方々にも参加していただいた.
進行の概要としてはまず,自分たちで作成した動画やプロジェクト紹介などを記載したウェブサイ
トを閲覧してもらい,参加者に内容の確認をしてもらった.そして次に発表時間になるとWeb会議サー
ビスであるZoomのブレイクアウトセッションに入室していただき,成果発表会を開始した.
成果発表会ではまず,司会進行がプロジェクトの概要を説明した.次に,質疑応答の時間をとった.質疑応答では,チャットや挙手ボタンで意思表示をしてもらいマイクをONして発言してもらった.質問が来た場合には質問された班が答え全体に対するものは,対応するメンバーが答えた.なお,質問がこなかった場合には各班からプロジェクト内での一年間の取り組みについて説明してもらった後,再度質疑応答の時間をとった.そして最後に終了時間になると司会からのアナウンスで成果発表会を終えた.
成果発表会終了後はプロジェクトのメンバーでアンケートの回答の分析などの振り返りも行なった.
(*文責：元満丈寛)
6.2 制作物
6.2.1 ポスター

図6.2.1-1 最終発表用ポスター

Group Report of 2020 SISP

92

Group Number 5

Creative AI
デザインは中間発表の際に提出したポスターをもとにプロジェクト内で変更した点を修正した. プ
ロジェクトの進行自体に大きな変更点はなく, ポスターも同様に発表内容は特に変更はしていない.
本項では順を追って変更した点を説明していく.
まず, ヘッダーおよびタイトル部分だがプロジェクト名の下に見出しとして本プロジェクトの概要を追加した. 概要欄でも説明は明記してあるがタイトルを一目見て本プロジェクトの内容が伝わりにくいと判断し前年度のポスターも参考にサブタイトルのような形で表記するほうが良いと判断した.
また概要や班員の欄も変更を加えている. 中間発表のポスターと比べて, 「各グループの役割」に図解を入れるためスペースが必要かつ, 概要にも図解があれば内容が伝わりやすくなるため班員の欄は横にして挿入しコンパクトにした. また前回とは違いサイトでの説明もあるので使用技術の項目は削除した. しかしAIとゲームの自動生成に関しては「AIが視覚, 会話, 音響, シナリオの要素を作成
し, ゲームに統合する」という意味で作成したが, あまり文字を使用しなかったせいで見た人全員に伝わるようなデザインとは言い難くもっと改良を重ねるべきであった.
そして「各グループの役割」だが前回は内容が伝わりにくかったと評価を受け, 内容は変えないま
ま上記の通りレイアウトを変更した. 前回は各班からの成果物をシステム班が統合するというのが伝わるように図解を入れていたが今回は簡潔に矢印でシステム班に繋ぎ無駄な情報は削除した.
また説明欄が全体的に白くて視認性に難があり, 各班のベースカラーで塗りつぶした説明欄の中に白文字が入るように変更したがシステム班のベースカラーが黄色なので逆に白文字が見にくくなってしまったのと, シナリオ班とキャラクター会話班のベースカラーである赤と青の彩度が高く刺激が強かったと評価フォームに記載があり反省するべき点であったと思う.
最後に「今後の展望」だが前回は各班最終発表に向けて開発内容を書いていたがこれらもサイトの方に記入してあるので今回はプロジェクト全体の展望を書いた. 今年は諸事情により学会での発表は厳しくオンラインでの発表になることに加えいずれもまだ検討中である.
ポスター全体の反省点を挙げるとすると, 提出直前に英訳が乱れていることに気づき, 日本語の説
明と照らし合わせたがそれでも誤訳が多く, 一部日本語と英語の内容に微妙な違いが生まれてしまった. 中間発表の時から変わってないはずの文章でも誤訳されているところがあったのでもっと前から気づくべきであった. 中間の際は全体的に白抜き部分が多く視認性に欠けるとあったが, 今回も似たような構成になってしまった.
(*文責：村井大輝)

6.2.2 Webサイト
中間発表時と比べ最終的な内容が多くなったこと,ポスターに書ききれない各班の詳細な活動内容を発表を聞きに来てくださった方々に見てもらいたいというプロジェクトの意志を踏まえ,このプロジェクトが1年間どんなことを行ってきたのかの詳細を見ることができるWebサイトの制作が決定した.WebサイトはGoogle Siteサービスを利用し制作を行った.
Webサイト内では全体の大まかな紹介を行う「ホーム」,そして各班の紹介ページに分かれている.
サイト内上部及び各ページの最下部にあるリンクをクリックすることでそのページに飛ぶことができる.

Group Report of 2020 SISP

93

Group Number 5

Creative AI「ホーム」のページでは,このプロジェクトの活動の紹介文,制作したゲームのデモムービー,最終
成果発表で制作されたポスターを見ることができるようにした.各班のページに関しては,最低限の枠組みを全員で共有した後,ページの内容を各班に委託し,それぞれ制作した.最低限の枠組みとは,各ページに共通する見出しと内容である.具体的には,班のメンバー,概要,創造性へのアプローチ,活動内
容,今後の展望について書いていった.
それぞれの班がページを書き終わった後にデザインの統一と,誤字の確認,著作権違反の確認の作業を行った.Webサイト内のデザインについては,サイト全体の色の調整や,制作したゲーム「LífsDropar」のロゴ画像の追加,サイト最上部にCreative AIのロゴの追加など,細かいものまで行った.他の確認作業については全員で確認することで確実性をもてるようにした.
最終成果発表を終えて,評価を確認したところ,とても好評であったことが分かった.ポスターなどで気になった部分を,直接ページに行って詳しく見ることができるという点が良かったようだ.反省点
は,「ホーム」ページにあるポスターをクリックした際に,リンクが切れていて拡大できなかったことである.それによりWebサイトからポスターが見られなくなってしまった.急遽対応を行ったが,発表を聞きに来てくださった方々に不便をかけてしまった.またどの班がどの活動を行っているのか,初めて見た人には分かりにくいという点があった.どこのページに飛べばいいのか分からないという声が確認された.このようなことを防ぐために,プロジェクトのメンバー全員でサイトのリンクを確認した
り,初めて見る人に優しい構成を考えることなどが考えられる.
(*文責：山本聖也)
6.2.3 動画
中間発表に引き続き,成果発表でも発表用の動画を作成することになった.成果発表に関しては,当初の予定では中間発表同様に動画を用いた発表を行う予定だったが,プロジェクトメンバーとの話し合いの結果,発表そのものにはWebサイトを用いて,Webサイト内に成果物のデモとして動画を掲載することに決定した.
構成を考えるにあたり,動画の時間を決める必要があったが,Webサイト全体を15分程度で見ることができるものにする必要があるため,Webサイト全体の文量が決まるまで構成を考えることも出来ない状況でかなり制作が遅れてしまった.Webサイトが校閲の段階まで入った時点で,メンバー数名と共にW
ebサイトを実際に読み,10分程度で読むことができると判断し動画時間を5分程度に決定した.成果発
表での評価として15分で内容が見れないという意見があったため,この点に関しては時間的余裕を持ち,より客観的な評価をするべきだったと反省している.動画時間が5分と短い物となったため,Webサ
イト内で解説している内容については簡易的に見せるのみとして,Webサイトに引き込める様な,成果物の魅力を伝える,デモ動画と言うよりはプロモーションビデオに近いような動画構成とすることにした.具体的には,メインシナリオのあらすじの紹介,特色である各班の自動生成部分の紹介,ゲームシ
ステムの紹介の順で構成した.
編集する動画は,プロジェクトメンバーが手分けして実際の成果物のゲームをプレイした様子を撮影したものをベースに,実際に使用している立ち絵やロゴなどを使用した.また,音響班がコードを自動生成して作成したBGMを利用して制作した.
編集にはVegas Pro 16.0を使用した.前述のように中間発表とは違い,魅力的に見える,この先の内容も見てみたくなるような動画を目指した.そのため今回は動画の動きをBGMに合わせる,映像構成に緩急をつけるなどの手法を用いて編集を行った.
(*文責：小原大地)

Group Report of 2020 SISP

94

Group Number 5

Creative AI
6.3 評価中間発表時と同様,質疑応答を行った後に,発表技術と発表内容の項目に分け,10段階評価とコメントを回答してもらった.回答者は学生と教員を含めて39名であった.質疑応答は以下の通りであった.

●Q.キャラクター会話班の収集作品がFFやドラクエといった会社一緒のものばかりだがバリエーションの幅狭くならないか.
○●

Q.webサイトのポスターが見れない.
○

●

●

●

○

A.シナリオ,視覚,音響,キャラ会話で順に回答.

○

コメント:自動生成というより,制作補助という感じ.ゲームクリエイターの作業を補助してくれるもの

Q.各自動生成の機能を使用する方はどのような人を対象にしているか.（大勢か個人か）○

A.ゲームクリエイター.

○

コメント:自動生成の機能を誰が使用するのか目安を立てたほうがいい.

Q.データ取集（分析）とか意外と泥臭い仕事多いがどうだったか.
A.各班が順に答えた.

Q.音響班への質問.使用BGMのループについてどのようなものを使っているか.
○●

A.対応しきれなかった.右クリックでリンクから開くことが出来る.

Q.RPGの自動生成でどこまで自動生成するのか.生成プロセスについてお尋ねしたい.また自動生成した場合,どの程度手直しが必要なのか.

○●

A.日本の作品でシリーズものの定番のため採用されている.ポケモンはやりかけになってしまった.(スクウェア社,エニックス社であるため別会社である.)

A.もともとループする音源を使っている

Q.2回マルコフ連鎖とはどのようなものか.
○

A.2つ前のコード進行から決める.

Group Report of 2020 SISP

95

Group Number 5

Creative AI●

Q.キャラクター会話の語尾変換プログラムについて変更前はどんな語尾が適しているか.「です」以外は対応しているか.
○●

Q.学会に出るのは班ごと,プロジェクト全体のどちらか.
○●

A.元の会話の語尾変換を行い,モブキャラクターごとに会話の変換を行う.

Q.システム班への質問.曲,シナリオの自動生成をまとめてゲームが出来たと思うのだが,自動生成を取り入れたことで開発中に起こった弊害等はあったか.
○●

A.泣ける話のデータは「ネットのサイト上にある多くの人が泣ける作品」をとってきた.その後シナリオ班内で協議し.収集の対象を決めていった.

Q.キャラクター会話班への質問.元の会話があればモブキャラクターごとに変換ができるのか.
○●

A.ゲームをしてもらい,各班のコンセプトについて今後,質問などに答えてもらうなどの方法で行っていく.

Q.シナリオ班への質問.泣ける物語ということだが泣けるの基準とはどのようなものか.
○●

A.検討中で未定.

Q.今後の展望に評価実験・アンケートとあるが,これは何に対するものか.
○●

A.リストの中の語尾なら対応している.

A.生成されたものがテキスト形式で出てくるため自動生成したものを読み込むシステ
ムを作ることが大変であった.

Q.紹介動画でデモがあったが,あのムービーのどのくらいの割合が自動生成なのか.
○

A.物語はクエストの部分のみ.メインシナリオは手打ちである.
会話はモブの会話文は元となるものが手打ちで,その語尾の変換を自動生成した.
視覚はモブの顔を自動生成.出力されたものを描き直してゲーム内で使用した.

Group Report of 2020 SISP

96

Group Number 5

Creative AI
音響はBGMの選択.BGMは人が作ったフリー素材を利用した.
システムは各班の結果の統合した.
○●

Q.年間スケジュールはどのようなものか.
○●

コメント:動画だけ見ているとどの部分が自動生成で,どのくらい役に立ったのかが分
かりにくかった.もっと分かりやすく見せる工夫をした方が良い.

A.各班が順に回答

Q.システムの部分で会話シーンを何で作ったのかが気になる.アセットとか使ったのか.
○

A.UIの部分のみアセットを使用.アイコンは視覚班.それらをスクリプトで制御している.
ファンガスを利用している.

●●

Q.ゲームの内容について,スタミナ制を導入していたが内部調整は手作業か.
○A.手作業.

○

コメント:非常によくできていると思う.頑張ってください.

Q.全体への質問. 泣けるシナリオは難しいと思うのだが,なぜ泣けるシナリオにしたのか.
○●

Q.実際に泣けたか.
○●

A.最初は方向性を全体で決めていった.「泣ける」「考えさせる」の2案が出て,どっちがデータ収集しやすいかなどを考えた結果,泣けるは定量化がしやすい等の理由から泣けるシナリオに決まった.

A.シナリオ班としては先の話が分かっているから明確に回答はできない.今後色んな人にプレイしてもらって評価実験などを行っていく予定である.

Q.実際にエンディングまで通してやったか.
○

A.シナリオの自動生成が詰まっており,クエストを最後まで通すことはできなかったが,ラスボスを倒すとこまではできた.1プレイ大体30分でクリアできるボリュームになっている.

Group Report of 2020 SISP

97

Group Number 5

Creative AI
最終成果発表では,39人から評価を受けた.結果は表6.3-1に示す.
中間発表の際は発表技術が7.91,発表内容が8.23であったため,ほとんど同じ評価結果となった.
回答者からのコメントについて発表技術に関しては,各班ごとに伝えたい内容が明確であること,司会進行がスムーズであったことが良い点として多くあげられる.これはサイトのページを班ごとに作っており,それを画面共有で参加者に見せながら発表を行ったことや,質疑応答に対する回答の用意及び,質問が来なかった際の対応をあらかじめ考えておいたことによるものと思われる.しかし,サイトのポスター画像を開くとリンクが切れていたことやサイト内のBGM再生時に音量の調節ができない等の意見も多く寄せられており,サイト制作の部分で発表を見てくださる方々への配慮が欠けていた部分もあった.
発表内容については,ゲームそのものに興味を持っていただけた旨のコメントが多く寄せられており,「実際にゲームをプレイしてみたい」,「自分もこのようなゲームを作ってみたい」などの嬉しい意見をいただくことができた.ただし,自動生成への取り組みに関し「目標と成果物のギャップが大きい」,「この技術を実際に誰に使用してもらいたいか(スコープ)がもっと明確であるべき」等のコメントもいただいた.

表6.3-1 中間発表での評価
評価点

発表技術

発表内容

1

0

0

2

0

0

3

1

0

4

0

0

5

1

1

6

4

4

7

9

6

8

11

11

9

7

8

10

6

9

平均

7.84

8.23

(*文責：西谷秀市)

Group Report of 2020 SISP

98

Group Number 5

Creative AI
6.4 課題と検討
6.4.1 シナリオ班
今回の最終成果発表を通して,自動生成したシナリオは実際に「泣ける」ものになっていたのかという質問があげられた.しかし,未だ評価実験等を行うことができていない状況である.,したがって,
今後の課題としてやはり評価実験を実施し自動生成したシナリオに対する周囲からのフィードバックを得ることがあげられる.現在,シナリオ班では音響班,システム班とともに自動生成したクエストシ
ナリオについての感想を,実際に完成したRPGを遊ぶよりも回答しやすい評価実験用フォームの作成を行っている.完成し次第,評価実験の実施を検討している.
(*文責：福元隆希)

6.4.2 キャラクター会話班
今回の成果発表では,「収集作品のバリエーションが少ないのではないか」という指摘を受けた.この指摘を改善するためには,今後の活動で,新たな作品も収集対象として収集していくべきだと考えた.また,自動生成をした際に必要な手直しについて質問された.手直しとして行ったことは,自動生成された語尾を違和感がないように配置することであったが,これは,今後の活動でデータの数を増やし,より精度を高めることで解決できると考えた.さらに,成果発表で聴衆の方に語尾変換を体験してもらうべくして作ったプログラムについて,不明な点を頂いたことに対して,プログラムの説明をより分かりやすいように改良が必要であると結論づけた.
(*文責：大田翔貴)
6.4.3 視覚班
中間発表で言及した通り自動生成のためのデータ収集を行いモブキャラクターの顔は生成することには成功した. しかし, そのままでは色は塗られていなく輪郭などもつながっていないので, ゲーム
で使用するにはまだ粗雑で人が手直ししなければならなく, 精度の向上にはより多くのサンプル収集
やパーツの座標設定を正確にする必要がある.
3Dモデリングの課題もいくつか課題が挙げられる, 3DモデルはいずれもBlenderでモデリングしたがUnity内でのレンダリングが上手くいっておらず全体的に暗くなってしまったのと, 登場人物のモデルに表情やまばたきを付けるところまでは行けず, ゲーム中ずっと無表情になってしまい多少違和感があった.
さらに主人公やヒロインの服なども物理演算を使用しモーションに合わせて動かすこともできたが服と足が干渉することなくUnityで動作させると処理が重くなるため断念した. そして敵キャラクタ
ーのモデリングに関してはBlenderの学習期間と自動生成関連に時間を取られ作成まで時間がかかってしまいBlender内でテクスチャを付けるのが間に合わずUnityからテクスチャのアセットを選び付けることになったのに加え, 9種類いる敵キャラクターの内, 7種類をテクスチャの張替えをして使い回しているのでもう少しモデルの種類を増やすべきであった.
また今回はUnityのアセットに頼ることが多かったのも課題である. 中間の際の検討ではできるだけオリジナルのモーションを作る予定だったが, 結果的に人型モデルのモーションはほとんどをアセットに頼るところが多く, オリジナルのモーションを付けたのはドラゴンと一部キャラクターのみであまり複雑な動きは付けられなかった.

Group Report of 2020 SISP

99

Group Number 5

Creative AI
モデリングも敵のキャラクターの二種類はアセットからダウンロードしたのに加え, ストーリー上重要なキャラクターも立ち絵などは新しくイラストを用意したが元はアセットから選んだものを使用することとなった.
(*文責：村井大輝)

6.4.4 音響班
課題としては,自動選択したBGMの適切性が挙げられる.適切にBGMが雰囲気にあうように選択されているシーンも見られたが,特に感動するシーンで普通のシーンの雰囲気のようなBGMが選択されているシーンが見られた.
原因としては,まず感動する教師データの不足が考えられる.今回分析した「NieR:Automata」「ファイナルファンタジーX」「ファイナルファンタジーX2」の3作品では感動するシーンは存在したもののその数は少なかった.一つのゲームで感動するシーンが限られていたため,感動する適切なBGMを選択させるにはより多くのゲームやアニメを分析する必要があると考えた.また,感動するシーンを分析していく上で必ずしもそのシーンにBGMが流れているとは限らなかった.BGMの選択でBGMが流れないシーンも考慮し適切な選択をさせる必要があると考えた.そのため,データを増やし,評価実験して適切かどうかを判定してもらうべきだと考えた. また,コード進行の自動生成ではコードの前後関係の繋がりは適していても,全体としてのコード進行としては少し不足している部分があると考えた.よって,コード進行の自動生成も改良や別の手法を試す必要があると考えた.
(*文責：元満丈寛)
6.4.5 システム班
今回の最終成果発表でいただいた質問の中に「どこまでを自動生成するのか」というものが上がっていた.システム班では,他の班の作った人工知能によって出力されたものを一つのゲームとしてまとめる,という面でゲームを自動生成したという見解である.また,シナリオ班の自動生成によって出力されたテキストデータを自動で読み取りゲーム内に反映させたという部分でもシステム班の制作物を通して,自動でゲームを作ったと言える.
他にも「どのような人を対象にしているか」という質問もいただいた.これに関してはシステム班
では対象を深く考えず作っていた部分が大きかったのだが,シナリオのセリフ部分や,アイコンを人力で入力する人に向けての自動生成を行った.今後の開発では,もっとゲームのどのような部分を作る人を対象にするかということを考えながらアイデアを出し,開発を行っていく予定である.
後期までの開発では敵キャラクターの攻撃力などのパラメーターは手作業だったが,大きさや形状,
色や,物質としてどのような物質(金属,皮等)でできているかなど,さまざまなパラメーターを入力し,体力や攻撃力などを出力する人工知能生成を検討している.
(*文責 : 青山美月)

Group Report of 2020 SISP

100

Group Number 5

Creative AI
第7章 プロジェクト内のインターワーキング●大田翔貴
私はキャラクター会話班で,主にデータ収集,データ分析,モブキャラクターの会話文の作成を行った.具体的には,選定した「Final Fantasy」シリーズの5作品からモブキャラクターの会話文データを収集した.その後,カイ二乗検定を行った結果に対して,属性ごとの会話文の傾向などを分析した.ゲームに登場するモブキャラクターの会話文はキャラクター会話班の全員で協力して作成した.
また,私はプロジェクトリーダーとして活動した.コミュニケーションの円滑化を図り,報告会を計画した.しかし,スケジュールの把握が上手くできず,実行には至らなかった.さらに,プロジェクトリーダーという立場にありながら,自分の積極性の無さを感じる場面が多々あった.これらはこのプロジェクト学習において出てきた私の反省点である.今後の活動はこの反省点を思い返しながら,積極的に活動していきたい.
(*文責：大田翔貴)●

齋藤慎悟
私は視覚班のグループリーダーとして,視覚班の活動や,他グループとの連携を円滑に行うために,スケジュールの調整などを行った.視覚班内での活動としては,自動生成の方法の考案
や実装などを行った.プロジェクト学習で身につけたスキルを今後の活動にいかしたい.
(*文責：齋藤慎悟)●

大場有紗
私はシナリオ班での活動において, 世界観の設定, メインストーリーの作成, データ収集,
データ分析, 「泣ける」クエストシナリオの自動生成を行った. 世界観の設定においては,
プロジェクトメンバーの意見を取り入れながら, シナリオ班で合議を重ね, 詳細な世界観のアウトプットを行った. 加えて, 世界観を主軸としてメインストーリーの作成を行い, グループメンバーにアドバイスをもらいながら, 改善を図った. また, データ収集および分析では, 選定した作品から泣けるシーンを抽出し, グループメンバーと話し合いながら, 14種類のカテゴリを設定した. その後, 分析結果を基に「泣ける」クエストシナリオの自動生成を行った. 今後は評価実験やアンケートを実施し, 自動生成したクエストシナリオが泣けるかどうかを調査し, 調査結果を踏まえた上で「泣ける」物語のデータ量の増加, 自動生成アル
ゴリズムの改善, 生成可能数の増加に努めていきたい.
また, 私はシナリオ班のグループサブリーダーを務めており, 提出物の確認および中間発
表や成果発表における連絡事項の発信を行った. プロジェクト内では議事録を務め, 担当のプロジェクト活動日における決定事項や課題についてまとめ, 共有を行った.
プロジェクト内での活動においての反省点としては, 全体の話し合いの際, 積極的に意見やアイデアを出すことが出来なかったため, 今後のプロジェクト活動だけに限らず, 他の場
面においても反省点を改善していきたい.
(*文責：大場有紗)

Group Report of 2020 SISP

101

Group Number 5

Creative AI●

北清敦也
私はキャラクター会話班での活動において,データ分析,データ収集,モブキャラクターの会
話文の作成を行った.「ドラゴンクエスト」シリーズの5作品から会話文を収集し,カイ2乗検定を行った.その後,検定結果に基づいて,会話文の語尾に着目して特徴を抽出した.中間発表
では,ナレーションの原稿作りとナレーションを担当した.
私は,グループサブリーダーを担当しており,全体会議での発言や,メンバーからの発案をまとめ,提案した.
プロジェクト内での活動においては,1年間通しで,議事録を担当していた.議事録についての反省としては,後で見返すことを考えて記録するという意識が足りていなかった.後期は議論の要点をおさえた記録を意識できた.
(*文責：北清敦也)●

森本大翔
私はシステム班で,主にアクション部分の作成,RPG要素の作成,マップの作製,視覚班の成果物の統合を担当した.さらに,キャラクター会話班,シナリオ班の成果物の統合にも貢献した.
前期では,アクションRPGゲームとしての土台を確立させた.そして,作成した土台を基に,他班の成果物を統合し,さらにアクション部分の洗練,RPG部分の洗練を行った.
最終的にゲームを完成させることが出来たが,重大なバグの問題が残っており,今後はバグをどれだけ減らせるか,という点が課題である.
(*文責：森本大翔)●

青山美月
私は,前期までの開発でスライドパズルのプログラムを作り,簡単なパズルの自動生成をすることができたが,本格的なにスライドパズルを作る後期になり,ゲームを作る上での優先順
位の高い他のシステムの開発中に追われ完成させることができなかったためゲームへ実装することができなかった.これはプロジェクト学習が終わってからまた個人的に再挑戦しようと思う.
中間発表においては,システム班の他メンバーと協力し説明のためのスライド作りを行なった.合わせて動画中で読み上げる原稿を作成し,音声を録音した.
後期の開発では,クエストやイベントシナリオを読み取り,ゲーム中に適切に表示するシス
テムの開発をした.他にもマップの作成,シナリオで使う背景画像の一部の撮影,オブジェクトに近づいた瞬間発火するクエストや,イベントシナリオが強制発火するスクリプトを書いた.
後期ではたくさんある作業を二人で効率よく分担できるように,まずあらかじめたくさんあるタスクの中から各個人がやりたいものを1から順位づけし共有した.次にそのタスクに手をつけたタイミングと,進捗が出たときや,行き詰まったタイミング,そしてタスクが終了したタ
イミングで報告をしあうことによって無駄がなくタスクをこなすことができた上,空いた時間にお互いに解決方法を考えることができた.次からはこの経験を生かして集団で開発をしていこうと思う.

Group Report of 2020 SISP

102

Group Number 5

Creative AI
また私は,システム班のグループリーダーとしても活動した.グループリーダーとしてシス
テム班のスケジュールや進捗を管理し他班との連絡を密に取ることで作業の遅れが出ないよ
う尽力した.しかし,全てをスケジュール通りにこなすことができずギリギリの開発になってしまった.今後はこの反省を生かしスケジュールを立てるときは楽観的はなくシビアに余裕を持って立てることの重要性を知った.特にゲームの制作ではテストプレイをし,バグをとるということに予想以上の時間と労力がかかるということを知った.今後の開発ではこの反省を生かし余裕のある開発をしていきたい.
(*文責 : 青山美月)●

福元隆希
私はシナリオ班のグループリーダーとして主に計画のたたき台の立案や作業の割り振り,作業を円滑に進めるための司会等,プログラムの開発を行ってきた.しかし,後期にとある理由か
ら自動生成用クエストのテキスト制作が遅れ,シナリオ班の作業進捗に多大な影響を与えてしまった.ここに他のシナリオ班へのメンバーへ謝罪を記しておく.
また,グループ全体としては年間を通して司会として活動を行ってきた.毎回のプロジェク
ト学習の開始時にその日の全体の流れの確認や全体のスケジュールを通した今後の全体の予定確認などを行うことでプロジェクトのメンバーが自分が何をすればいいのかを考えられる
ように心がけてきた.しかし,後半に行くにつれてプロジェクト全体として意見を出す場での意見が減っていたので,もっと意見を出せるように場の雰囲気をよくするようなスキルを習得したいと考えている.
(*文責：福元隆希)●

髙橋利孔
私は,キャラクター会話班として,会話文の分析に用いるプログラムの開発と制作を行った.
分析に用いる際に,扱いやすいファイルが出力できるように,意識して制作した.具体的には,
カイニ乗検定のためのファイルを出力するときに,カイニ乗検定に必要なデータのみが出力されるようにした.また,カイニ乗検定後の語尾を調べるために,有意な結果があった助動詞を含む会話文をファイルとして出力した.また,語尾変換のアルゴリズムの開発と制作も行った.
課題としては,会話文の自動生成を目標としていたが,ゲームとしてまとめるために必要な期限との折り合いがつかず,語尾の自動変換のみという結果になってしまったことである.今後は,協力と連携をしっかりと心がけていきたい.また,「ポケットモンスター」シリーズの会
話文を収集しきれなかったので,実現可能な予定を立てることも身に着けていきたい.
(*文責：髙橋利孔)●

元満丈寛
私は音響班での活動で主に,データ分析,データの作成,昨年度のニューラルネットワークの改良を行った.

Group Report of 2020 SISP

103

Group Number 5

Creative AI
前期の活動では前年度のプログラムやニューラルネットの学習,感情特徴量の項目決めをメンバーと共に行った.そして,後期での活動の計画も協力し,立てた.中間発表では,前半の音響班の質疑応答を行い,スライドに音声を入れてわかりやすくした.
後期の活動では,まず,データの分析で「ファイナルファンタジーX」と「ファイナルファ
ンタジーX2」の合計360シーン以上分析した.分析では,動画を見ながら実際にプレイも行なった.「ファイナルファンタジーX」も「ファイナルファンタジーX2」もどちらもとてもやり込み要素が多く,それに加えシーンの詳細や泣けるシーンでは,泣いた理由・背景・内容・カテゴリに分類した.次に,データの作成では,他のメンバーが分析してくれた「NieR:Automata」そして,自分で分析した「ファイナルファンタジーX」と「ファイナルファンタジーX2」のシーンのデータから感情特徴量を取り出した.そして次に,今年度新たに分析した3作品のBGMであるサウンドトラックから合計200曲の音響特徴量を抽出した.音響特徴量の抽出では,昨年度のプログラムを参考にして,指定した楽曲のみを抽出するようなプログラムに改良した.そして,ニューラルネットワークの改良では泣けるBGMの選択を目標にe0,e1タグの分岐を実装した.実装では,シナリオ班から受け取ったテキストデータを読み取りそれぞれ,e0,e1で分岐させようと考えたが,思うようにできず苦労した.
プロジェクト内での活動においては,最終成果発表会で司会をつとめた.今後はプロジェク
ト活動の際に,積極的に発言し自分を意見が言えるように努力していきたい.
(*文責：元満丈寛)●

小原大地
私はシナリオ班での活動において,ストーリーの作成補助,データ収集,データ分析,システ
ム読み込み用のタグの作成,テキストの整形,「泣ける」クエストシナリオの自動生成を行った.ストーリーの作成補助として,テキスト全般の校閲や,システム上必要となる文章の追記などを行った.また,データ収集および分析では,選定した作品から泣けるシーンを抽出し, グループメンバーと議論の上,14種類のカテゴリを作成した.また,ストーリーのテキストをゲームシステムに読み込むために必要となるタグを,システム班に依頼,議論し決定した.決定したタグをテキストに適用し,フラグ管理を含めたテキストの整形も合わせて行った.これらをそれ
ぞれ組み合わせ,アルゴリズムを作成し「泣ける」クエストシナリオの自動生成を行った.
また,私はプロジェクトの発表用動画の制作担当を務め,中間発表では発表動画を,成果発表
ではWebサイトのトップページに掲載するデモ動画をそれぞれ作成した.構成から編集に至るまで,プロジェクトメンバーに意見を貰いながら一人で作成した.
プロジェクト内での活動においての反省点としては,新しい提案をプロジェクト内に浸透させることができなかったことと,動画の提出が期限間際になってしまったことが挙げられる.
オンラインでの作業の中,ツールの提案など様々な新しいことを試みたが,あまりうまく浸透させることができなかった.これは新しいことへの理解度やマネジメント力,コミュニケーシ
ョン能力の不足から来るものだと感じるため,今後は反省を活かしてより良い提案をしていきたい.また,動画の提出に関しては,編集する動画の元となるゲームシステムの完成にも時間がかかっていたため仕方ない部分もあるが,しっかりとした計画性を持つべきだったと反省している.
(*文責：小原大地)

●

荻野永和

Group Report of 2020 SISP

104

Group Number 5

Creative AI
私は音響班での活動において, 活動内容の決定, 分析に使う感情特徴量の決定, データ収集を行った. また、シナリオ班と連携して「NieR:Automata」というゲームの各シーンとその場面に流れているBGMの関係性を分析した.その他には, Songleというサービスを利用したり,BGMのクロマグラムを抽出してそれからコード進行を分析しようと試みたが, 他の開発により時間内に完成させることができなかった. なのでプロジェクト学習が終わった後に完成させたいと考えている。
中間発表や最終発表では, スライドの作成の他に, 発表原稿も作成した.実際に発表した
際には, 質疑に対して細かに応答するよう心掛けた.
音響班外での活動として, 1年間議事録を担当した. 他に2人が議事録を担当していたが, 3人の中でローテーションを組んで活動した. 反省点として、だんだん議事録に書く内容が粗くなっていったことが挙げられる. また, たまに自分が担当する日であることを忘れそうになったことが多々あったので, マネジメント力を身に着けるべきだと考えた.
また, 音響班のグループリーダーとして、グループ全体の統括, 議論の円滑化, グループ
週報の作成を行った.
プロジェクト活動内での反省点として, コミュニケーション能力不足によって自分の意見をしっかり使えることができなかった点, またスケジュールをしっかり立てて進めていくことができなかった点が挙げられる. 計画性を持って行動していれば, より多くの成果物を生み出すことができたと考えられるので、これらの反省を今後しっかり活かしていきたい.

(*文責：荻野永和)●

村井大輝
私は視覚班で一部のキャラクターデザイン, メインキャラクターのモデリング, 自動生成用のデータ収集, そしてプロジェクト発表用のポスター制作を担当した. キャラクターのデザインに関しては班員の一人が人間のデザインを担当していたため, クリーチャーデザイン
として一体のみ自分でデザインし, モデリングに使用する三面図も自ら制作した. モデリン
グに関しては今回のプロジェクトで初めてモデリングソフトに触れたため学習と同時並行で行いテクスチャやアニメーションにも触れた. ポスターについては反省すべき点が多く, 図解やイラストを入れたがわかりやすくなったとは言えず英訳も所々破綻しているところが多く入念に確認しておくべきだった.
(*文責：村井大輝)●

西谷秀市
私は視覚班での活動において,自動生成用のデータ収集・編集,キャラクターデザイン,マッ
プデザイン,立ち絵・アイコン制作等を行った.1年を通してシナリオを書くメンバーやシステ
ムを統合するメンバーと協力し,一からゲームを開発する経験が出来,満足している.特に意識した点は早めの制作を行うことであり,なるべくゲームの全体観をプロジェクトメンバー全員

Group Report of 2020 SISP

105

Group Number 5

Creative AI
が視覚的に把握できるよう努力した.チームで開発を行った経験を活かし,今後の活動に励ん
でいきたい.
(*文責：西谷秀市)●

天野太一
私は音響班の活動において, 主に昨年度の引継ぎ, ニューラルネットワークのプラグラムの修正, コード進行を自動生成するプログラムの作成, 学習元となるコード進行の収集, ゲーム内の一部BGM(Back Ground Music), SE(Sound Effect)の作成を行った. 昨年度の引継ぎ
は音響抽出, ニューラルネットワークのプログラムの実行を行った.
ニューラルネットワークのプログラムについてはWindows環境下でも正常に動作するよう修正し, バグの修正や一部パラメータの変更も行った. コード進行を自動生成するプログラム
は当初, 感情特徴量を入力しその感情にあったコード進行を生成するプログラムを実装予定であったが, 実装が現実的でなかったためマルコフ連鎖を用いて簡易的にコード進行を生成するプログラムを作成した. また, コード進行を収集するプログラムも作成し約13000曲から
コード進行を収集した.
ゲーム内のBGMの作成は, 自動生成したコード進行を元に行った. 当初はボス戦のBGMのみの作成であったが, 他の担当者の都合等によりオープニングのBGM, フィールドのBGMの作成も行った. ボス戦のBGMは, ボスのキャラクターデザインやボス戦フィールドのデザインから, 荘厳かつサイバーなイメージを持って作成した. 荘厳さはストリングスなどのオーケス
トラ音源を使用し, オープンボイシングも意識し表現した. サイバーな雰囲気はシンセサイ
ザーなどで作成した電子音を主に使用し表現した. オープニングのBGMは, 今年度の目標のひとつである「泣ける」ゲームを意識して, 感動出来るようなメロディーや音作りを意識した.
具体的にはBPMを遅くして音数は少なめ, ベル系の音で綺麗で少し寂しげな雰囲気を表現した. フィールドのBGMは, オープンワールドのゲームでの広大さや希望などの要素を意識して作成した. 広大さを表現するためにオーケストラ音源主体での作曲を行った. 作曲はおよそ1週間という短い期間で行うこととなってしまったので, 今後は計画的に作業を進めることができるよう心がけたい.
SEについては, システム班に依頼された場面に適するものを作成した. 実際に録音した音に様々なエフェクターを挿して作成した. 例えば攻撃時の斬撃音は, 金属同士のぶつかる音にリバーブを深めにかけ, サチュレーションやディストーションをかけ倍音を付加して作成した.
全体としては, 中間発表での仮BGMの作成やゲームのデバッグ作業, デモ動画の撮影を行った. 仮BGMは, 中間発表でのゲームのデモにBGMが実装されていなかったため作成することとなった. こちらも作業開始が発表前日と急になってしまったため, 計画的に作業を進めれるよう心がけたい. ゲームのデバッグ作業については, 作成したゲーム内でのバグを見つけ報告する作業を行った. デバッグと同時にデモ動画の撮影を行った. ゲーム内のデモ動画に使えそうなシーンを撮影し, 動画編集担当に渡した.
プロジェクト内では, 活動を円滑的に進めるためにコミュニケーションを積極的に取ることを意識した. 班内で出来る限り無言の時間が生まれないよう, 定期的に進捗を聞いたり,話を積極的に振るようにした. また, 客観的に意見を出すことも意識した. 前期の活動のほGroup Report of 2020 SISP

106

Group Number 5

Creative AI
とんどは班内での活動であったので, 後期の活動からは他班との連携を取ることも重視した.
他班との連絡や話し合い, 相談を主に行った. 互いの意見が食い違ってしまう場面も度々あったが, できる限りお互いに納得できるような最善策を取れるよう努力した. 反省点としては, 計画的に作業を進めることができなかった点が上げられる. 先述した作曲のタスクだけでなく, 作品分析などの本来自分がやるべき仕事をやりきることが出来なかったので, 予定の管理などを徹底していきたい. また, 全体での意見出しなどにあまり貢献ができなかったので, 今後はこのような場面でも貢献できるよう努力したい.
(*文責：天野太一)●

山本聖也
私は視覚班としてキャラクターのモデリング、自動生成のデータ収集を行った。3Dでのモデリングは初めてで慣れない部分もあったが、様々な技術を習得でき、良い経験になったと感じている。1年間でプロジェクトの進め方やメンバー間の連携方法など多くのことを学ぶことができ、満足のいく活動となった。
(*文責：山本聖也)

Group Report of 2020 SISP

107

Group Number 5

Creative AI
第8章 まとめ
8.1 プロジェクト全体の成果
人工知能は私たちの生活に浸透しつつあるが,未だ発展途中にある.人工知能に新たな可能性を見出すために,本プロジェクトでは,自動生成や自動選択システムの開発を行った.それに伴い,自動生成などで作り出される要素を取り入れたゲームの開発も行った.ゲームのジャンルは多くの要素を詰め込
みやすい,アクションRPGに決定した.
泣ける物語を分析し,プロットの自動生成を目指すシナリオ班,モブキャラクターの会話文を収集・分析し,性別と年齢に伴う語尾の自動変換を目指すキャラクター会話班,視覚要素のデザインを行うとともにモブキャラクターの顔の自の発表が円滑に進むように質疑応答や紹介をうまく工夫した.一方,反省するべき点としては,プロジェクト内での議論の際にうまく発言ができず自分の案やア
イデアを出すことがあまりできなかった.今後のプロジェクト活動やグループ動生成を目指す視覚班,シーンに合うBGMの自動選択とコード進行の自動生成を目指す音響班,それら4つの班から得られた成果をゲームに統合させるシステム班の計5つの班に分かれて作業を行った.
最終的に,5つの班の活動によって,1つのゲーム作品を作り上げることができた.現在,プロジェクトのWebサイトに公開するために,ゲームのデバッグなどの最終調整が進んでいる.
(*文責：大田翔貴)
8.2 各グループの成果
8.2.1 シナリオ班
シナリオ班では,メインシナリオや自動生成した「泣ける」クエスト,自動生成用のアルゴリズムに加え,ゲーム進行に必要なタグ,「泣ける」理由についてまとめたデータベースなどの様々な成果を得ることができた.
(*文責：福元隆希)
8.2.2 キャラクター会話班
キャラクター会話班では,事前に,性別と年齢のそれぞれの属性を考慮した会話文を作成し,自動変換アルゴリズムによって語尾を変換した.
(*文責：髙橋利孔)
8.2.3 視覚班
視覚班はモブキャラクターの顔の自動生成とゲーム内で使われる様々な要素の作成を行った.自動生成では,迎山研究室の白石さんの協力のもと行った,モーフィングを利用し,性格の明るさを軸にした自動生成と福笑いのように顔パーツを並べ,精神年齢を軸にした自動生成の2つの方法を検討,実装した.
性格の明るさを軸にした方法では性別,年齢の6通りの組み合わせでそれぞれ性格の明るさを36０段階で生成することができた.この方法では,男性・成人,男性・高齢者,女性・成人,女性・高齢者の顔画像を生成した.

Group Report of 2020 SISP

108

Group Number 5

Creative AI
精神年齢を軸にした方法では子供の年代のみ生成を行った.属性は年齢と精神年齢5段階で10通りとなった.10通りの属性それぞれ100,000枚の画像を生成した.そのなかから,自然な顔に見える画像を設定した条件のもと選別を行った(5.3.1参照).結果,各属性で平均約40%が自然な顔画像として選別された.各属性の入力画像の枚数と選別された画像の枚数は次のようになった.男性・精神年齢1では,目・眉・髪・口・輪郭の画像が12枚で,鼻が11枚,選別された画像は48,033枚であった.男性・精神年齢2では,全ての顔パーツの画像が10枚で,選別された画像は36,293枚であった.男性・精神年齢3では目・髪・口・鼻・輪郭の画像が10枚で,眉の画像が9枚,選別された画像は60,541枚であった.男性・精神年
齢4では,全ての顔パーツの画像が12枚で,選別された画像は38,724枚であった.男性・精神年齢5では,
目：髪・口・鼻の画像が13枚で眉・輪郭の画像が12枚,選別された画像が63,459枚であった.女性・精神年齢1では,全ての顔パーツの画像が8枚で選別された画像が5,104枚であった.女性・精神年齢2は目・髪・口・鼻・輪郭の画像が8枚で眉の画像が6枚,選別された画像が28,480枚であった.女性・精神
年齢3では,目・髪・口・輪郭の画像が8枚で眉の画像が7枚,鼻の画像が6枚,選別された画像は9,989枚であった.女性・精神年齢4では,全ての顔パーツの画像が7枚で選別された画像は38,886枚であった.
女性・精神年齢5では全ての顔パーツの画像が8枚で選別された画像は21,744枚であった.
また,この2つの方法について,自動生成した顔画像が自然な漫画の顔に見えるか調査するため,はこだて未来大学の学生10人にアンケートをとった.調査内容はゲーム内で使用した6人のモブキャラクタ
ーの顔画像について,以下のようにした.
1. 漫画のキャラクターのような自然な顔に見えるか.
2. キャラクターの性別はどのように見えるか.
3. キャラクターの年代はどのように見えるか.
4. キャラクターの性格の明るさはどのように見えるか.
5. キャラクターの精神年齢はいくつに見えるか.
設問4と設問5はキャラクターの性格の明るさと精神年齢がどのように見えるかをそれぞれの方法で出し分けをした.
調査の結果は次のようになった.男性・子供・精神年齢2では,どちらかといえば自然な漫画の顔に見ないが最も多く,精神年齢は2であるとい項目が最も多かった.性別と年代についてはそれぞれ全て
男性,全て子供である.という結果であった.女性・子供・精神年齢4では,どちらかといえば自然な漫画の顔に見えるが最も多く,年代は成人に見えるが50％,子供に見えるが50％であった.精神年齢は3と4が同率で最も多かった.性別については,全て女性に見えるであった.男性・成人では,どちらかとい
えば自然な漫画の顔に見ないが最も多く,性別,年齢はそれぞれ全て,男性,成人であった.明るさは4が最も多かった.男性・老人では,どちらかといえば自然な漫画の顔に見ないが最も多く,性別,年齢はれぞれ全て,男性,老人であった.明るさは,2と3がそれぞれ同数だった.女性・成人では,性別,年齢はそれぞれ全て,女性,成人であった.明るさは,2と3が同数で最も多かった.女性・老人では,性別が9割が女性で,1割がどちらとも言えないであった.年代は全て老人であった.明るさは4が最も多かった.
その他の作業として,自動生成されたモブキャラクターの顔画像をゲーム内で使用する立ち絵に書
き直し,主要キャラクターのデザイン,マップや敵キャラクターのイメージがの制作を行った.さらに
ゲーム内で使用される3Dの要素であるキャラクター,武器,敵キャラクターのモデリングを行った.マップ内で置かれる建物や自然造形物,主人公のキャラクターのモーションなどは視覚班でアセットを選考し,システム班に実装してもらった.
(*文責：齋藤慎悟)

Group Report of 2020 SISP

109

Group Number 5

Creative AI
8.2.4 音響班
音響班では, 昨年度のプログラムを修正し, 「泣ける」シーンとそうでないシーンで分類し楽曲を選択するプログラムを作成した. また, 既存の分析データに加え, 新たに3種類のゲームを分析し,
感情特徴量を与え音響特徴量を抽出した. さらに, マルコフ連鎖を用いてコード進行を生成するプロ
グラムを作成し, 生成したコード進行をもとにゲーム内のBGMを作成した.
(*文責：天野太一)
8.2.5 システム班
システム班では,各班が生成したものを統合し,「ゲーム」という形で完成させることが出来た.
(*文責：森本大翔)
8.3 今後の課題と展望
8.3.1 全体
当プロジェクトでは人工知能に創造性を持たせゲームに様々な要素として組み込んだ. 今回の最終発表の課題を挙げると, まず, 元々このプロジェクトはゲーム開発における人材不足と人工知能の研究への貢献を目的としているが, 今回の発表ではプロジェクト紹介文とサイトのトップページにしか記述がなく, 人材不足と研究への貢献に関してはあまり触れられていなかった. また人工知能は完成させたがゲーム自体は未完成であり, 用意はしているが組み込めていないシナリオがある他, モブキャラクターのモデルもサンプル用の物を使用しているのでゲームとしてはまだまだ完成していない箇
所が多い.
今後の展望としては情報処理学会と人工知能学会の二つの学会で発表する予定でありそれに向けてゲームの最終調整と原稿の準備をしている.
また毎年行っている秋葉原での発表も予定しているが今年は新型コロナウイルスの蔓延を防ぐため,オンラインでの開催となっており未来大学から参加することとなっている.
(*文責：村井大輝)
8.3.2 シナリオ班
今後,「泣ける」物語のデータ量を増やすことで仮説の正確性を高めていく.また,自動生成アルゴ
リズムを改善することで「泣ける」クエストシナリオ生成により適したものにしていく.さらに,クエスト自動生成用のテキストを増やして生成可能数を増やしていく予定である.また,メイン評価実験,
アンケートを実施し,自動生成したものが「泣ける」を実現しているのか.また,どのような人がどのようなパターンで「泣ける」のかといった調査を行い,学会等の学外活動の場においての発表を視野にいれている.
(*文責：福元隆希)
8.3.3 キャラクター会話班
我々は,話者属性に合わせて会話分の語尾を変換することに成功した.しかし,子供や老人の会話文のデータが比較的に足りないという課題があった.今後の展望は,データ量を増やして,語尾変換の精度の向上や意味内容の自動生成に取り掛かれるようにすることである.

Group Report of 2020 SISP

110

Group Number 5

Creative AI(*文責：北清敦也)
8.3.4 視覚班
自動生成された顔画像についてのアンケートで,モーフィングを使用した方法と,福笑いのようにして生成する方法の両方で半数以上が性別・年代において指定した属性での顔画像を生成することができた.また,指定した精神年齢も半数以上がそのとおり見えるという結果となった.しかし,自然な漫画の顔に見えるという割合は,モーフィングを使用した方法,福笑いのように生成する方法両方で5割以下となった.自然な漫画の顔に見える割合をあげるために,以下の事を改善すれば効果が得られると考えられる.今回は特に福笑いのように生成する方法について考える.1つ目は,データの数である.特に,福笑いを用いて方法では,顔パーツの数で組み合わせが決まるため,今回はデータの数がすくなくゲー
ム内で使用できそうな顔画像の選択肢がすくなかった.2つ目は,顔パーツの位置や拡大率をある程度定めることである.1つ目のデータの数に関係して,データである顔パーツの位置が作業者によってバ
ラバラであったため,髪より上に目があったり,口が輪郭より下になってしまう画像が生成されることがあった.作業前にテンプレートとなる顔画像を作成し,作業者はその顔画像に作業対象の画像を合わせて分割作業を行うことでこの改善できると考えられる.3つ目は,生成された顔画像のなかから,自然な漫画の顔にみえる顔画像を選別するために用いた条件式の改善である.今回は,髪,眉,目,鼻,口,輪郭のそれぞれのパートにy座標を与え,y座標の位置関係で顔画像を選別した(5.3.1).しかし,目の位置が極端に左右に偏っていたりしたことから,x座標による制御も必要だと考えられる.各パーツにy座標と同様にx座標を定義し,目と鼻の中心が輪郭の顎の頂点と重なるようにしたり,両目の中点の座標が目や鼻の座標と重なるような条件を加えることで,顔画像の選別の精度をあげる事ができると考えられる.
今後の自動生成の展望としては,選別の精度を高め,選別された画像の中からさらに詳細な条件,属性で顔画像を抽出することである.今回は性別・年代の他に精神年齢と性格の明るさを指定し顔画像を生成した.それに加え,さらに細かな感情などをもとに顔画像を生成することを検討している.また,目や口の状態,形などが精神年齢や明るさとどのような関係にあるかを明確にし,データ収集の際の対象画像の選考に役立てたい.
(*文責：齋藤慎悟)
8.3.5 音響班
今年度は, 泣けるゲームを生成するという目標を掲げ活動してきたが, 音響班は泣けるBGM収集が足りず, 結果AIで楽曲選択をする時に適したBGMを選ぶことができなかった. したがって今後はより多くの泣けるフリーBGMの収集をする予定である. また, 今回は音響特徴量をクロマベクトル, セン
トロイド, BPMの3つを用いて抽出したが, 楽譜や他の方法での音響特徴量の抽出ができるとより良い
結果が生まれると考えられるので, 音響特徴量の抽出方法を増やすことも課題として挙げられる. さらに, 評価実験をしてふさわしいBGMが使用されているかをアンケートで調査したいと考えている.
(*文責：荻野永和)
8.3.6 システム班
我々は,ゲームを完成させることは出来たが,本編にはまだバグが残っており,デバッグをしバグを減らす必要があると考えている.さらに.ゲームがユーザーに対しフレンドリーではないとも考えている. 具体的には,ゲーム開始時に操作方法の説明がなかったり,ステータスが明記されておらず実際にレベルアップしたかどうかを確認できないという点である.今後は,上記の問題を解決するために,ゲGroup Report of 2020 SISP

111

Group Number 5

Creative AIームスタート時に簡単なチュートリアルを実装したり,メニュー画面にステータスを表示する予定である.
(*文責：森本大翔)

Group Report of 2020 SISP

112

Group Number 5

Creative AI
参考文献[1-1] 斉藤勇璃, 白石智誠, 太田和宏, 根本さくら, 石川一稀, 宇田朗子, 小川卓也, 友広純々野,
中村祥吾, 山内拓真, 西川和真, 宍戸建元, 長野恭介, 蓬畑旺周, 稲垣武, 村井源, 迎山和司, 田柳
恵美子, 平田圭二, 角薫, 松原仁, シナリオ・視覚要素・音響効果を統合的に自動生成するゲームシ
ステムの構築, The 32th Annual Conference of the Japanese Society for Artificial Intelligen
ce, 4C2-GS-13-03(PDF), 2020
[1-2] 馬場哲治, ビデオゲームのゲーム性と技術の進歩, 2005
[3-1] 鉄拳, 約束, https://www.youtube.com/watch?v=XAa1CeX4dac&t=69s&ab_channel=%E9%89%84%E
6%8B%B3%E3%83%81%E3%83%A3%E3%83%B3%E3%83%8D%E3%83%AB(最終閲覧2021年14日)[3-2] 鉄拳, お父さんは愛の人,
https://www.youtube.com/watch?v=PLByXFDaMnU&ab_channel=%E9%89%84%E6%8B%B3%E3%83%81%E3%83%A
3%E3%83%B3%E3%83%8D%E3%83%AB(最終閲覧2021年14日)[3-3] 鉄拳, 母のサポーター, https://www.youtube.com/watch?v=VwZ9qIJmgtM&ab_channel=%E9%89%
84%E6%8B%B3%E3%83%81%E3%83%A3%E3%83%B3%E3%83%8D%E3%83%AB(最終閲覧2021年14日)[3-4] 鉄拳, 振り子,https://www.youtube.com/watch?v=d1lmCdabZws&ab_channel=%E9%89%84%E6%8B%
B3%E3%83%81%E3%83%A3%E3%83%B3%E3%83%8D%E3%83%AB(最終閲覧2021年14日)[3-5] 尾田栄一郎, ONE PIECE, 集英社, 1997[3-6] Final Fantasy X/X-Ⅱ HD Remaster, 株式会社スクウェア・エニックス, 2013[3-7] Final Fantasy ,株式会社スクウェア,1987.
[3-8] Final Fantasy Ⅱ ,株式会社スクウェア,1988.
[3-9] Final Fantasy Ⅲ ,株式会社スクウェア,1990.
[3-10] Final Fantasy Ⅳ ,株式会社スクウェア,1991.
[3-11] Final Fantasy Ⅴ ,株式会社スクウェア,1992.
[3-12] ドラゴンクエスト ,株式会社エニックス,1986.
[3-13] ドラゴンクエストⅡ 悪霊の神々 ,株式会社エニックス,1987.
[3-14] ドラゴンクエストⅢ そして伝説へ… ,株式会社エニックス,1988.
[3-15] ドラゴンクエストⅣ 導かれし者たち ,株式会社エニックス,1990.
[3-16] ドラゴンクエストⅤ 天空の花嫁 ,株式会社エニックス,1992.
[3-17] ポケットモンスター 青 ,任天堂株式会社,1996.
[3-18] ポケットモンスター クリスタル ,任天堂株式会社,2000.
[3-19] ポケットモンスター サファイア ,株式会社ポケモン,2002.

Group Report of 2020 SISP

113

Group Number 5

Creative AI[3-20] ポケットモンスター プラチナ ,株式会社ポケモン,2008.
[3-21] ポケットモンスター ブラック ,株式会社ポケモン,2010.
[3-21] K. Hevner, “Expression in music: A discussion of experimental stud- ies and theori
es,”
Psychological Review, vol.42[5-1] Mecab(最終閲覧:2021年1月14日）
https://taku910.github.io/mecab/[5-2] js-STAR(最終閲覧:2021年1月14日）
http://www.kisnet.or.jp/nappa/software/star9/index.htm[5-3] FINAL FANTASY X ,株式会社スクウェア , 2001
[5-4] FINAL FANTASY X ,株式会社スクウェア , 2003
[5-5] NieR:Automata ,株式会社スクウェア・エニックス , 2017https://github.com/jsvine/markovify[5-5]Songle(最終閲覧:2020年1月14日) https://songle.jp/

Group Report of 2020 SISP

114

Group Number 5