mozukichiの投稿 - Crieit

個人ゲーム開発の壁

2021-12-01T07:00:08+09:00

個人で初めてゲーム開発をしようとしたときに障壁になりそうなものを個人的メモとしてまとめてみます。

障壁になりそうなものについて単に思いついたものを羅列して書いたもので、それぞれの対処法は未調査、または未整理であるため、ここで対処法について詳しくは記述しません。

個人ゲーム開発の障壁となりそうなものは、以下のものです。

ゲームアイディア発想の壁とメンタルブロック
技術選定の壁
プログラミング学習の壁
プログラム設計の壁
デバッグの壁
パフォーマンスチューニングの壁
グラフィックデザインの壁
作曲の壁
物語創作の壁
プロジェクトマネジメントの壁
ゲームデザインの壁
マーケティングの壁

ゲームアイディア発想の壁とメンタルブロック

ゲームを作ろうとしたはいいものの、どのような内容のゲームを作るべきかが思いつかない、という問題です。

すでに作りたい内容が明確に構想できている場合は、ここの問題はスキップされます。

この問題に対して先人らはよく「作りたいもの作ればいいじゃん」とか言いますが、その作りたいものが何かわからない、というような状況がありそうです。さらに「作りたいものが無いなら、そもそもゲーム開発なんてできない／ゲーム作りは向いてない」などと追い打ちをかけられることもあります。

すでに世に出ているゲームの模倣をする、という方法も取れますが、その場合「ゲームアイディアの発想」以外の取り組みの練習にはなりそうですが、肝心の「ゲームアイディア発想」自体はスキップされ、その能力を養う機会を損失しそうです。

また、ゲームアイディアを発想してみたものの、自らの冷静で客観的な評価として否定される（”自分の中のもう一人の自分”や"自分の中の他人”が否定的な評価をささやき、そのゲームを作ることをやめさせる）問題があります。このような「自分の行動を制限しようとする思考」は、通称「メンタルブロック」と呼ばれています。（もう一人の自分が「そんなゲーム作ってどうするんだ？」「どのゲームのどこがおもしろいんだ？」などとささやいてくる）

技術選定の壁

ゲーム開発の技術的な知識がほとんど無い状態だと、何を使ってゲーム開発すべきかがわからない場合があります。

この場合、Webで情報を検索してみたり、質問サイトで相談する、という方法がとれます。そして、（下書き執筆開始の）2020年12月執筆時点では、個人ゲーム開発で使用する技術としておそらく一番多くおすすめされるものが Unity というゲームエンジン兼各種エディター、ツールで、次点で Unreal Engine がおすすめされるでしょう。

たまに素のプログラミング言語（とその処理系）から、Unity のようなツール群を使わずにゲーム開発をしたい、という（学習者の技術投資の価値観としての）ケースがありますが、その場合は、各種プログラミング言語とその処理系、実行環境との相性などの特徴から選定を行う必要があるため、迷いが発生しやすいです。

昨今、ゲーム開発企業の現場から「Unityの表面的な部分しか使えないより、もっと奥深い部分を理解して使いこなせる人材がほしい」という声も聞かれるため、もし個人でゲームを作ろうとする理由が就職のためである場合に、Unity 以外の選択肢を選ぼうとする理由が生まれる可能性はあります。

「Unity でも深く学べば、奥深い仕組みの部分も学べるんじゃないか」という意見もありそうですが、Unity が持つ機能の一部はブラックボックス（中身が見えないもの）であり、むしろ、「奥深く中身を見なくてもゲーム開発ができるようにするためのツール」であるため、やはり、Unity についてのみ学習することは、その奥深い、コンピューターに近い部分の仕組みや、レンダリングの仕組みや手法、その特性などを学ぶ機会を失う可能性が否めません。

プログラミング学習の壁

多くの開発環境では、プログラミング言語を駆使する必要があるため、プログラミング言語についての学習を行う必要があります。しかし、この段階でつまづくケースがあります。（Unity では C# というプログラミング言語を駆使する必要があります）

多くの場合、学習の順序、段階をスキップしているがゆえに起こる問題が多いように思います。例えば、プログラミング言語の文法の学習をスキップして、作ろうとしているゲームの機能の実装方法を調べて（「〇〇の作り方」などと検索して）得られたプログラムの断片をコピーして作ろうとすると（いわゆる「コピペプログラミング」と呼ばれる方法）、コンパイルエラーや意図しない動作への自力での対処が難しく、このような状況に陥ると「ゲーム開発は難しい」「わからない」などの感想を強く持ち、ゲーム開発をあきらめる理由が強化されます。

かと言って、プログラミング言語の文法をいちからじっくり学ぶ方法をとっても、いつまで経っても動くゲームを作ることができず、学習が飽きてしまうという問題が指摘されることがあります。そのため「プログラミング言語の学習と、ゲームの実装の両方を、ほどほどにバランスよく進める」という助言がされることもありますが、どうやったらほどほどにバランスが良いのかの指標が具体的に提示されることは少ないため、なかなか迷いやすい部分にはなりそうです。

「自分は今、どの部分の知識が足りていないがゆえに、今の問題に直面しているのか」が可視化されれば問題に対処しやすいですが、現時点ではそれを可視化するための良い方法が普及しているとは言い難いため、救われない人が多くいるのではないかと想像します。

学習のガイド役となるような（いわゆるメンター的な）存在が身近にいて、学習をガイドしてくれるなら救いの道があります。このガイド役は「学習者がいま問題に直面しているのは、どの部分の知識が足りていないからなのか」について分析（広義のカウンセリング）をして、どの部分の知識が足りていないのかを知り、その不足を補うための（"処方箋"のような）具体的な対処法を提示する必要があります。

この分析をせずに無理に助言をしようとする場合、その多くは「説教」のようになってしまうでしょう。

プログラム設計の壁

小規模のゲーム開発であれば、プログラム設計が雑でも”チカラ技"で完成させることができるかもしれないですが、中規模以上のゲーム開発となると、雑なプログラム設計では、ちょっとした機能追加や修正作業でもプログラムを変更する箇所が多すぎたり、データとロジックの不整合などによってプログラムのうまい変更方法を思いつけなくなったり（この場合は、たいてい作り直すのが早い）、プログラムの変更が意図しない機能に影響を与えて不具合を生んだり、などのような問題が起きます。

この分野に関しては「プログラムの一般化／抽象化／モデル化」「高凝集化」「疎結合」「関心の分離」「オブジェクト指向設計」などのキーワードで語られることがあり、高度なものになると「MVC」「MVVM」「双方向データフロー」「単方向データフロー」「クリーンアーキテクチャ」「リアクティブプログラミング」「ドメイン駆動開発」などのソフトウェアアーキテクチャの分野で説明されることがあります。

これらの分野は、自主的かつ積極的にプログラミング関連の情報を収集しているか、学習のガイド役の人がガイドをしない限り、学習しようとする機会が生まれないかもしれないです。

デバッグの壁

プログラミング初学者が、コンパイルエラー、実行時エラー、意図しない動作に遭遇したときの対処方法を積極的に学ぶ機会は少ないかもしれません。

コンパイルエラー、実行時エラーのエラー文の意味を解読するためにはプログラミング言語の文法を理解している必要があるため、そのエラーの対象となる文法の学習をスキップしている場合は、その解読ができません。（エラー文で検索して出てきた対処法を見よう見まねで組み込んでも、それは付け焼刃的なものになるでしょう）

また、実行時エラーや意図しない動作に対処する場合、何らかのデバッグテクニックや、いわゆる「デバッガー」というツールを駆使して、問題の原因を特定する必要があります。しかし、プログラミング初学者は「実行時エラーや意図しない動作の原因を特定するためにはデバッガーを使えば良い」ということ自体を知っていないケースがあり、たまたまデバッグ方法について上手に説明している教材に巡り合えたか、良いガイドがされた場合だけに成長が約束されます。

パフォーマンスチューニングの壁

ゲームを作ってはみたものの、メモリ使用量が多すぎたり、処理に時間がかかりすぎてフレームレートが低くなったりなどの問題が起こることがあります。

このようなとき、いわゆる「プロファイラー」と呼ばれるようなツールを使ってボトルネックを発見し、そのボトルネックを解消させる必要があります。

メモリ使用量や実行速度の問題が起きた時に「プロファイラーを使ってボトルネックを見つけて解消する」という方法を自体を知るには、かなりプログラミングについて調査、学習をしているか、良いガイドが必要になります。

グラフィックデザインの壁

自作でゲームを作るからには、グラフィック素材についても自作したい、と思うケースがあります。ゲームに近いグラフィックデザインに関する理論が確立されているのかどうかは筆者はわかりません。

お金に余裕があれば、上手な人に頼んだり、有償の素材を購入するという対処ができます。

フリー素材を使うという方法もあります。

作曲の壁

自作でゲームを作るからには、音楽素材（または効果音）についても自作したい、と思うケースがあります。音楽理論は長い歴史で確立されているので、学習しやすい分野ではあるかもしれないです。

お金に余裕があれば、上手な人に頼んだり、有償の素材を購入するという対処ができます。

フリー素材を使うという方法もあります。

物語創作の壁

物語要素を含めたゲームを作る場合、その物語を作る必要があります。

物語要素を含むゲーム作品では、その物語の内容はオリジナルである必要があるため、グラフィック素材や音楽のようにすでに提供されている素材を使う、というような方法はとれません。

良い物語を作るため方法論は長い歴史の中で割と確立されているようで、関連した書籍が多く出版されている印象がありますが、その書籍を購入するための資金と、その書籍を用いた学習をするための時間と心的リソースは必要になります。

プロジェクトマネジメントの壁

中規模以上のゲームを開発するような場合、プロジェクト管理を上手くやらなければ以下のような問題が起こります。

次に取り組むべき作業が何かわからない
どこまで作業をすれば良いのかわからない
いつ完成するのか見えない
今どのくらい作業が進んでいるのかわからない（残りの作業がどのくらいあるのかわからない）
仕様の何を直せばいいのかわからない（目指す品質・優先しない品質が何かわからない）

いわゆる「創作のモチベーション維持」がうまくできていない場合は、ここがうまくできていない可能性があります。

ゲームデザインの壁

思い描いたゲームの試作してみたものの、「思っていたものと違う」「どうも面白くない」というような場合はゲームの内容を上手く修正して良い内容に変えていく必要がありますが、具体的に何をどう変えたら良くなるのかがわからない場合があります。

ゲームの内容の良さに影響する要素は複数ありますが、それぞれで良さを生むようにするための方法はそれぞれで専門性があります。例えば、ゲームの競技ルールが良くないがためにゲーム展開が盛り上がりに欠けるようになってしまったり、視覚効果が貧弱でゲームプレイで高揚感が得られにくい、などあります。競技デザインと視覚効果デザインは専門性が異なります。

マーケティングの壁

これはすでにゲームが完成したあとの話になるが、「作ったゲームが知れ渡らない」「作ったゲームが良い評価を受けない」というような場合、マーケティングの視点でゲームの内容を見直す必要が出てくる。

ビデオゲームにおけるカタカナ語「ナラティブ」を別の言葉に置き換えて意味が通るか検証してみた

2020-10-28T16:56:12+09:00

2020/11/10更新

「形容詞」としているものは「形容動詞」であると指摘を受け、実際にそのとおりであったため「形容詞」を「形容動詞」に変更しました
「副詞」としているものは、正確には「形容動詞の連用形」であったため、そのように変更しました
松永伸司さんの氏名を誤って「松永真司」としていたので修正しました

乱用される言葉「ナラティブ」

かつて、ビデオゲームにおけるカタカナ語「ナラティブ」という言葉について、講演やSNS、ブログ等で説明が試みられ、多くの人がその意味を解釈しようと奮闘しつつも、一部の人は「理解した」と言い、また別の一部の人は「わからない」「混乱した」と理解ができない様相を呈するというような現象が起きました。

この現象の経緯の概要を把握するためのまとめページとして「ビデオゲームにおける「ナラティブ」について言及されたページを時系列で並べた資料」というページを作成してあります。

実際、この「ナラティブ」について説明を試みようとしている文章では、この「ナラティブ」という言葉を多様な品詞（名詞や形容動詞、形容動詞の連用形）で用いていたり、品詞が同じでも、異なる意味で使用していたりなど、「ナラティブ」という言葉の乱用が認められます。

そこで、すでに「ナラティブ」について説明されている文の「ナラティブ」という言葉を、品詞を特定できる別の用語に置き換え、品詞が同じでも別の意味で用いている場合も別の言葉に区別して置き換えたときに、その意味が通る文になるのか、そして、その文は比較的わかりやすい文になるのかについて検証してみたいと思います。

「ナラティブ」をメタな単語として用いている文（例「ナラティブという言葉が登場した」）は検証の対象とせず、「ナラティブ」という言葉に何か特別な意味を持たせて使用しているであろう文（例「このゲームはナラティブだ」「ナラティブなゲーム」「ナラティブを活用する」）を検証の対象にします。

品詞の違い

最初に、ビデオゲームにおけるカタカナ語「ナラティブ」が日本語圏で最初に説明された文献として「【CEDEC 2013】世界で注目される概念「ナラティブ」とは何か？ - GAME Watch」を取り上げます。

まずは、どの品詞として使われているのかを洗い出してみたいと思います。

ナラティブとは、端的に言えば体験の中で形作られる体験者自身の物語のこと。

ナラティブを存分に活かした作品としては「ドラゴンクエスト」が挙げられるという。

ストーリー、自由度の偏りはナラティブを生まない

まず、これらは「ナラティブ」という言葉を名詞として使用しています。

ナラティブなゲーム

人から押し付けられたものではない、自分の決断として物語を進めていけるこの方法は、ナラティブな工夫の1つとなっており、クリエーター同士で「ドラゴンクエスト方式」と簗瀨氏は呼んでいたそうだ。

物語はふんだんにはあるものの、ナラティブな体験とは少し違う。

これらは「ナラティブ」を「名詞を修飾する語」としての形容動詞として使用しています。

この時点で「名詞」と「形容動詞」の2種類の使われ方があることがわかります。

さらに別の記事には、以下のような用法があります。

【GDC 2019】AIは感動的な物語体験をゲームで表現できるか？ GDCに見る最新トレンド | モリカトロンAIラボ

現実世界に適切なアイテムを配置して、それをナラティブに活用することで、より豊かな物語体験が演出できるようになると述べました。

「ナラティブに活用する」の「ナラティブに」は、動詞を修飾する形容動詞の連用形です。

「名詞」「形容動詞」「形容動詞の連用形」と、文法的にもかなり多様に使われていることがわかります。

意味を解釈してみる

「ナラティブとは、端的に言えば体験の中で形作られる体験者自身の物語のこと」の解釈

ナラティブとは、端的に言えば体験の中で形作られる体験者自身の物語のこと。

ここで「ナラティブ」は名詞として使われていて、ストレートに「ナラティブ」の意味を定義しています。その意味は 「体験の中で形作られる体験者自身の物語のこと」 としています。

一般的に「物語」と聞くと、何か具体的な情報媒体（本や映像、ゲームなど）上に表現されたものを連想します。しかし、ここで説明しているのは「体験の中で形作られる」と言っているので、具体的な情報媒体上に表現されたものではなく、記憶の中の”思い出”として生まれるものを「物語」と表現しています。

単に「物語」とだけ言った場合、それは「出来事の連なり」についての内容、またはその内容について表現されたものを指し、「記憶」を指していることがわかりにくくなります。

一般に、出来事についての記憶は「エピソード記憶」と呼ばれているため、ここでは「体験の中で形作られる体験者自身の物語のこと」は 「エピソード記憶」 と呼べるように思います。

記事で説明している「体験の中で形作られる体験者自身の物語のこと」の「体験」は、人生のあらゆる体験を指しているわけでなく、記事中では特にビデオゲームで遊ぶ体験を指していると思われます。なので、本記事では「ビデオゲームで遊ぶ体験の中で形作られる体験者自身の物語のこと」を 「ビデオゲームプレイのエピソード記憶」 と訳していきたいと思います。

「ナラティブなゲーム」の解釈

ナラティブなゲーム

ここでは「ゲーム」という名詞を修飾している「形容動詞」です。先程、「ナラティブ」は「体験の中で形作られる体験者自身の物語のこと」と説明していましたが、これを応用して「ナラティブなゲーム」の意味を「体験の中で形作られる体験者自身の物語的なゲーム作品」とむりやり訳しても、その意味がちょっとわかりません。

別の解釈として「体験の中で形作られる体験者自身の物語が作られるゲーム作品」、つまり 「ビデオゲームプレイのエピソード記憶が作られるゲーム作品」 として理解することはできそうです。しかし、プレイしたことのエピソード記憶が作られないゲーム作品というのは想像しにくく、どのようなゲーム作品であっても、プレイヤーが人であり、エピソード記憶能力に問題が無ければ、基本的にエピソード記憶が作られます。そのため、この解釈をしても、実質これは何も説明していない文になってしまいます。例えば「目で見ることのできるリンゴを「ビジブル・リンゴ」と呼びます」と言っているくらい無意味です。

現時点では、その意味がはっきりしないので、いったん置いておきます。

「ナラティブを存分に活かした」の解釈

ナラティブを存分に活かした作品としては「ドラゴンクエスト」が挙げられるという。

ここで「ナラティブ」は名詞として使われています。なので、先程の「ビデオゲームプレイのエピソード記憶」と置き換えることができそうです。実際に置き換えてみると、ここの文は 「ビデオゲームプレイのエピソード記憶を存分に活かした作品」 となります。これは直感的にもおかしいことがわかります。

あるビデオゲーム作品をプレイしたエピソード記憶は、そのゲーム作品ができあがったあとに生まれるものなので、そもそも、そのビデオゲームプレイのエピソード記憶を、その作品の内容に活かすことはできません。

「ナラティブを活かした」という言い方なので「何かしらの手法を適用した」と解釈をすることができます。（その正体は不明ですが）そこで、本記事では「何かしらの手法」として「ナラティブ」という言葉を使っている箇所を一旦 「ナラティブ術」 と言い換え、手法であることがわかるような言葉に置き換えたいと思います。

「ナラティブな工夫」の解釈

自分の決断として物語を進めていけるこの方法は、ナラティブな工夫の1つとなっており、クリエーター同士で「ドラゴンクエスト方式」と簗瀨氏は呼んでいたそうだ。

ここで言う「ナラティブな工夫」の「ナラティブな」は形容動詞として述べらおり、その対象は「工夫」です。

「工夫」を形容する言葉の例として「賢い工夫」や「役立たない工夫」「簡単な工夫」「難しい工夫」などが挙げられ、これらは「ある工夫」についての属性や特徴を説明しています。同様に「ナラティブな工夫」といった場合についても、特定の「ある工夫」について詳しく説明したものであるはずです。

すでに解釈した「ビデオゲームプレイのエピソード記憶」という意味を適用しても、その意味がわかりません。

「ビデオゲームプレイのエピソード記憶が生まれるような工夫」と解釈できなくもないですが、ビデオゲーム作品であるならば、そのプレイの記憶は必然的に生まれるので、あえて工夫をするようなものではありません。

しかし、前述で一時的に「ナラティブ術」として置いた「何かしらの手法」という意味を適用すれば「ナラティブな工夫」という言葉全体を、その「何かしらの手法」として解釈できそうです。

引用文から該当の言葉を置き換えても「自分の決断として物語を進めていけるこの方法は、ナラティブ術の1つとなっており」となり、意味が通ります。

「ナラティブな体験」の解釈

物語はふんだんにはあるものの、ナラティブな体験とは少し違う。

ここの「ナラティブな体験」を「ビデオゲームプレイのエピソード記憶を作る体験」や「ナラティブ術の体験」と訳しても、その意味がいまいちつかめません。

先述の「ナラティブ術」（今は正体不明の何らかの手法）を適用したデザインを鑑賞したときの感覚、と解釈すれば、一応意味が通ります。

総括

ここまで書いてちょっと疲れたので、もう総括してしまいます。

取り上げた記事では、様々な意味で「ナラティブ」という言葉を用いており、そのナラティブの意味を厳密な理屈として解釈しようとすれば混乱してしまうような説明となっていました。

しかし、それぞれを「（今は正体不明の何らかの手法としての）ナラティブ術」に関連させると、意味が通るのではないかと考えます。

最初の

ナラティブとは、端的に言えば体験の中で形作られる体験者自身の物語のこと。

という説明も、上記ではいったん「ビデオゲームプレイのエピソード記憶」と解釈しましたが、「（今は正体不明の何らかの手法としての）ナラティブ術を適用したデザインを鑑賞したときのエピソード記憶」と解釈しなおせば、その特別な意味に少し近づけた気がしてきます。

「ナラティブな工夫」も、その術そのものを指し、「ナラティブな体験」についても、先述した通りです。

というわけで、当時一部で騒がれた「ナラティブ」論は、その全てがデザイン手法に起因する何か、と解釈したうえで、次回は松永伸司氏の『ナラティブを分解する』を読んでみたいと思います。

おつかれさまでした。

WSL 2 と Desktop Docker の開発環境を整えてみた

2020-08-31T17:17:10+09:00

本来自分はゲーム作りたい系の人なのですが、人生の大河の流れに身を委ねていたらWeb開発に貢献する必要が出たので、某Webシステムの開発に貢献するために、開発環境を整えたいと思います。本記事は、そのための開発環境を整える記録ただの日記です。

Web開発自体は、けっこうしばらくぶりなので（仕事でやっていたのが5年くらい前）、色々わかってないので調べながらになります。

最終的な目標となる環境は Node.js、Express、MongoDB の環境を整えることですが、今回は、とりあえず Docker が使える状態になるところまでやってみます。

自宅メインPCを最近新調していて、開発まわりの環境はほぼ整えていない状態で、ほぼ最初からやっていく感じです。メインPCの OS は Windows 10 Home です。

Windows Subsystem for Linux 2 (WSL 2) を利用するために Windows 10 をバージョンアップ

巷ちまたでは、Web開発する際はローカルの仮想環境上で環境を整えて、その上でWebバックエンドのシステムを動かして動作確認して開発するのが主流のスタイルだと思うので、それに倣ならいたいと思います。

で、Webバックエンド開発をする際、CUI（コマンドラインインターフェース）をよく使いますが、世に多くある技術情報は、Linux 環境が前提であるものが大多数です。Windows のコマンドプロンプトや PowerShell での開発情報は少ないので、できれば Linux 環境で開発したいです。

Windows 10 で使える（いつのバージョンからかは分からないけど）Windows Subsystem for Linux (略して WSL）という機能を用いれば、Windows 環境上に Linux 環境を作ることができるので、これを使います。
で、WSL にはバージョン1とバージョン2があり、どうやらバージョン2から、仮想環境を作る上での利点があるようなので、WSL 2 にしてみたいと思います。

「windows10 wsl2 インストール」でGoogle検索したら、Microsoft の公式の解説ページがあったので、これを見ながら試してみます。

➢ Windows Subsystem for Linux (WSL) を Windows 10 にインストールする | Microsoft Docs

解説ページにある「WSL 2 に更新する」の項目で、以下のような記述がありました。

WSL 2 に更新するには、次の条件を満たす必要があります。

バージョン 2004、ビルド 19041 以上に更新された Windows 10 を実行している。

Windows のバージョンを確認するには Windows ロゴキー + R キーを押します。次に「winver」と入力し、 [OK] を選択します (または、Windows コマンドプロンプトで ver コマンドを入力します)。お使いのビルドが 19041 より前の場合は、最新の Windows バージョンに更新してください。 Windows 更新アシスタントを入手する。

メインPCにインストールされている Windows のバージョンを確認してみたところ、バージョン2004未満だったので、更新しようと思い、「最新の Windows バージョンに更新してください」という文からリンクされている Windows の設定（[設定]→[更新とセキュリティ]→[Windows Update]）から、更新をしてみたけど、バージョン2004まで上がりませんでした。

調べてみると、「Download Windows 10」という Microsoft 公式ページから更新用プログラムをダウンロードしてインストールする必要があるようでした。

➢ Windows10 バージョン2004 ビルド19041に上げてみた - Qiita

このページを参考にして、Windows 10 のバージョンを上げてみたところ、うまくバージョンアップできました。

WSL 2の環境を整える

引き続き、Microsoft の公式ドキュメントに従ってWSL2の環境を整えます。

➢ Windows Subsystem for Linux (WSL) を Windows 10 にインストールする | Microsoft Docs

ドキュメントの「WSL 2 を既定のバージョンとして設定する」の項目にある、wsl --set-default-version 2コマンドを PowerShell で実行しようとしたところ、以下のようなエラーが発生しました。

> wsl --set-default-version 2
エラー: 0x1bc
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

「wsl "set-default-version" "0x1bc"」でGoogle検索してみたら、それっぽいページが見つかりました。

➢ Error 0x1bc when setting wsl default version · Issue #5651 · microsoft/WSL

Github の Microsoft 公式のWSLのリポジトリの issue です。（英語の読解スキルがまだまだ貧弱なので）Google翻訳して読んでいくと、カーネルエラーがどうのこうのって書いてありました。

公式ドキュメントにも、以下のような注意書きがありました。

このメッセージは、コマンド WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel を実行した後に表示されることがあります。リンク (https://aka.ms/wsl2kernel) に従って、WSL 2 で使用する Linux カーネルをコンピューターにインストールするためのドキュメントのこのページから MSI をインストールしてください。カーネルをインストールしたら、コマンドを再度実行すると、メッセージが表示されることなく正常に完了します。

ここで説明されているメッセージが出たわけではないのですが、カーネルがどうのって書いてあって関係しそうなので、ここにあるリンクに従って何かをインストールしてみます。

リンク先はここでした。

➢ WSL 2 Linux カーネルの更新 | Microsoft Docs

カーネル更新のインストールのようです。ここにある「x64 マシン用の最新の WSL2 Linux カーネル更新プログラムパッケージ」をダウンロードしてインストールしてみます。（使用しているメインPCは 64ビット環境です）

「wsl_update_x64.msi」というファイルがダウンロードされたので、インストーラーを実行します。

インストールはすぐに終わりました。

インストールが終わってすぐに、もう1回、PowerShell でwsl --set-default-version 2を実行してみます。

> wsl --set-default-version 2
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

エラーが表示されなくなりました。ふう……😓💦

Ubuntu をインストール

Microsoft 公式ドキュメントの流れに従い、Microsoft Store から Linux ディストリビューションをインストールします。開発に貢献する某システムの環境は Ubuntu で動作しているので、それに合わせて Ubuntu をインストールします。

Windows のアプリ一覧から Ubuntu を起動させ、初期セットアップを行います。

新しい Linxu ディストリビューションのユーザーアカウントの作成とパスワードの設定を行いました。

PoewrShell からwsl --list --verboseを実行して、Linux ディストリビューションに割り当てられている WSL のバージョンを確認します。

> wsl --list --verbose
  NAME      STATE           VERSION
* Ubuntu    Running         2

WSL 2で動いています。

Windows Terminal にも、Ubuntu が認識されました。

Docker のインストール

5年くらい前に私が仕事でWeb開発をやっていたときに使用していた仮想環境のためのツールが Vagrant だった記憶があります。しかし、昨今の流行は Docker というツールのようなので、それを使ってみたいと思います。（流行情報の追跡だけはちまちましている）

「wsl2 docker」でGoogle検索して、以下のQiitaの記事が出てきたので、これを参考にして作業してみたいと思います。

➢ Windows 10 Home で WSL 2 + Docker を使う - Qiita

タスクマネージャーから確認※できる CPU の Virtualization が Enable になっていないといけない、ということなんですが、今の自分の環境で確認してみたら「仮想化」という様に日本語になっていました。そして、この項目は「有効」となっていたので問題なさそうです。

※タスクマネージャーの起動は Ctrl + Shift + Esc というショートカットキーを使うと便利です

参考記事には WSL 2 の設定についても書かれていますが、これはもう完了しているので、Docker のインストールからの部分を参考にします。

今や Docker は GUI で操作できるようなので、Docker Desktop for Windows を導入します。2020年8月7日時点での Stable 版（安定版）のインストーラーをダウンロードしてインストールします。インストーラーのウィンドウのタイトルバーに「Installing Desktop Docker 2.3.0.4 (46911)」と書いてあり、ここで初めてバージョンを確認できました。

インストーラーの Configuration で Enable WSL 2 Windows Features にチェックがついているのを確認して [OK] ボタンを押すと、インストールが開始されました。インストールが完了すると「Installation succeeded」と表示され、「Close and log out」ボタンを押すと、Windows から強制的にログアウトしました。

Windows の再ログインすると、Docker の GUI が起動しました。

チュートリアルをしてくれるみたいなんですが、一旦スキップします。

Desktop Docker の設定（ギアのアイコン）の General で「Use the WSL 2 based engine (Windows Home can only run the WSL 2 backend)」にチェックが入っているのを確認します。確認すると、すでにチェックが入っていましたが、項目全体が薄灰色になっていて、チェックが外せないようでした。英語のカッコ書きで「Windows Home は WSL 2 バックエンドだけで動作する」って書いてあるので、WSL 2 が前提になっている状態なのでしょう。

設定の Resouces の WSL INTEGRATION の「Enable integration with my default WSL distro」にチェックが入っているのを確認します。確認したら、問題なくチェックが入っていました。

この WSL 2 での Docker を使えば、Hyper-V を使わなくても仮想環境が作れる、というのが利点のようなんですが、Hyper-V というのが BIOS 的な何か、というくらいの理解しかしていません。

これで、とりあえず WSL2 と Docker が使えるようになりました。

「ビデオゲームの内容を考えて決める」という行為は、具体的に何について考えて決める行為なのかを考えてみたい

2019-12-01T07:00:13+09:00

記事のタイトルが物々しい表現になっていますが、本文はゆるい感じで書きます。油断すると物々しくなるかもしれないです。論理的な誤りや曖昧な表現ができるだけ入らないようにしようとするためです。ただ、文体が物々しくなってしまっては、その文章を読むための認知負荷が高まってしまい、意図せず読者を限定してしまうので、それは避けたいところです。というこの文自体が物々しくなってしまっています。

言い換えます。なんか難しいっぽい感じで書いても、「ゲームを作りたい！」と思っている多くの人に内容を届けられにくくなるので、ゆるふわっぽい感じで書きたいです。（「誰のための文章なのか」ということをよく考えたいです）（ゆるふわっぽく書けるとは言っていない）（ここでいう「ゆるふわっぽく」とは「曖昧な概念を使う」ということではないが、「ゆるふわ」自体が曖昧な概念でありパラドックスを生む）

内容の不備があったらご指摘いただけると幸いです。

「デザイン」「ゲームデザイン」という言葉について

念のため説明しておきますが、本記事における「デザイン」という言葉の意味は「設計」つまり「ものごとの内容を考えて決める行為、またはその成果物」として用います。

よって本記事における「ゲームデザイン」という言葉は、「ゲームの内容を考えて決める行為、またはその成果物」を単純に指し、「ゲームデザインとはかくあるべきである」「本物のゲームデザインとはこうである」のような説得的定義は含みません。（「偽物のゲームデザイン」ってなんだろう🤔）

「期待される成果が生まれるゲームデザイン行為、またはその成果物」を指す場合は「良いゲームデザイン」という言葉を用います。

いきなりゆるふわ感のない説明でごめんなさい。

「ゲームの内容を考えて決める」という行為が具体的に何について考えて決めることなのかを知りたい

「よし、ゲーム作るぞ」と意気込んだはいいものの、ゲームの実装をする前に「どのような内容のゲームにするのか」を考えて決める必要があります。

これは、実装前にゲームのすべての仕様を決めてから実装に取り掛かる場合だけでなく、実装をしながら仕様を決めていくような場合であっても「とりあえず、次に何を実装するのか」を考えて決めなければ、その「とりあえず次に実装するもの」の実装に取り掛かることができません。そのため「ゲームデザイン（ゲームの内容を考えて決める）」という行為において「具体的に何を考えて決める必要があるのか？」という問いに答える内容は、ゲームデザイン行為への指針となり、経験と勘に頼らないゲームデザインを行うための道具となります。

物事を具体的に捉えようとする場合、その物事を構成している要素が何なのかを明らかにすることが、その物事を詳しく知ることの手がかりとなります。つまり、その対象を”分解"します。

ということで、「ゲームデザインは、何をデザインする行為で構成されているのか」という”分解”を行うことが「ゲームデザインとは、具体的に何を考えて決めることなのか」について明らかになることに繋がりそうです。

まずはその取っ掛かりとして「ゲームを構成する要素」の分解を試みた事例から、それをデザイン要素として捉えることができるのかについて考えてみます。

ゲームを構成する要素の分解を試みた事例を評価する

ゲームを構成する要素の分解を試みた事例があり、それぞれが今回の目的である「ゲームデザインは、何をデザインする行為なのか」を詳しく知るための枠組み（要素の集まり）として利用可能かどうかを検証します。

ゲームデザインの枠組みとして利用可能かどうかを評価する基準

達成したいことは「ゲームの内容を考えて決める、という行為が、具体的に何を考えて決める必要があるのかを明らかにして、ゲームデザイン行為の円滑化を促すこと」です。わかりやすい言い方をすると「ゲームの内容を考えて決めるときに、何をすればいいのかわからなくなって迷わないようになること」です。

そのために必要なゲームデザインの枠組みを評価する基準として、以下のものを考えます。

基準	説明
デザイン可能性	要素それ単体が具現化可能なデザイン対象であるかどうか
適度な粒度	デザインの対象として、実用的なレベルまで分解された粒度かどうか

要素がデザイン可能なものか

ゲーム制作は、デザイン（内容を考えて決める行為）をしたあとに実装、つまり具現化をします。例えば「制限時間3分で試合終了」というルールをデザインした（考えて決めた）あとに、実際にそのルールをプログラムで実装することができます。そのため、デザイン対象となる要素の内容を考えて決めたあと、その内容を実装、具現化することが可能であることが必要です。

もし、ゲームデザイン要素として挙げられている要素がデザインの対象ではなく成果物の「属性」や「性質」「特徴」を指している場合は、それ単体で実装、具現化をすることができません。例えば、極端な例を挙げると「面白さ」や「すごさ」のような概念や属性のような要素は、成果物の性質、特徴であって、デザインの対象ではありません。（「面白さ」や「すごさ」そのものを単体で実装できない）

要素が適度な粒度か

各要素がデザイン対象として適度な粒度かどうかを考えます。

デザイン対象となる要素の粒度が荒い（抽象度が高い場合）は、デザイン行為の際に「迷い」が発生しやすいです。「迷う」ということは、さらに分解されるであろう要素が曖昧に想像されるがゆえであると考えられます。例えば「雰囲気」をデザインする、と考えても「雰囲気に影響するのは外観？絵柄？音楽？文字？セリフ？書体？エフェクト？トランジション？ロード時間？操作方法？テンポ感？手触り感？エモさ？キャラクターの生い立ち？これら全部？それとも関係ないのもある？まったくわからん」というように、迷いと混乱が生まれます。

補足ですが「抽象的であること（具体化の余地があること）」と「曖昧であること（複数の異なる意味で捉えられること）」は、カッコ書きで示しているように意味が違い、上記の説明では「抽象的すぎるかどうか」を評価するという説明ですが、「曖昧であるかどうか」は説明していません。ただ、上記の例で示した「雰囲気」に関しては「曖昧である（人によってその意味・内容について異なる解釈をしている可能性がある）」という問題はあります。

次に、ゲームデザインの内容が強く制限されてしまうような要素は、粒度として「細かすぎる」（概念として具体的すぎる）と評価できます。例えば「プレイヤーキャラクターの髪の毛の色」という要素は「プレイヤーは髪の毛を持っている何か生き物のキャラクターである」という、すでにデザイン済みの制限をかけています。このような場合は、例えば「プレイヤーキャラクターはロボットにする」という対応ができませんし、さらに「プレイヤーキャラクターなる概念の存在しない、風景が移ろいゆくゲーム」のようなゲームもデザインできません。（実際、「シムシティ」なんかはプレイヤーキャラクターなんて居ませんよね）

「ビデオゲームを構成する3つの要素」

島国大和さんが「不毛ながらゲーム性の定義　島国大和のド畜生」というブログ記事の中で「ビデオゲームを構成する3つの要素」という項目を扱っています。

そちらで説明している構成要素とその内容の説明を表にしたものが以下のものです。

構成要素	要素がもつ共通な性質の説明（内包）	具体例（外延）
システム	ゲーム全体の仕組み	なし
フレーバー	ゲームの雰囲気周辺	「猿が踊る」「ロシア民謡が流れる」「世界観」
ボリューム	ゲームの物量	「全部で100面ある」「総プレイ時間200時間」「モンスターが151匹」「クエスト1000個」

この分類が、今回の目的である「ゲームデザインは、何をデザインする行為なのか」を詳しく知るための枠組みとして十分に利用可能かどうか、を考えてみます。

この枠組を素直に使う場合、ゲームデザインという行為は「システムをデザインする」「フレーバーをデザインする」「ボリュームをデザインする」という3つのデザイン行為が含まれることになります。

「システムをデザインする」とは何か

上記のブログ記事では「システムはゲーム全体の仕組み」と説明され、その一部に「ゲームのルール」がある、と説明されていました。ベン図を使って包含関係を示すと以下のようになります。

つまり「システムをデザインする行為」とは「ゲームのルールをデザインする行為」と「ゲームのルール以外のシステムをデザインする行為」の2つに分類されることとなります。

しかし、上記記事では「ゲームのルール以外のシステム」が何を指しているかの説明が無かったため、「ゲームのルール以外のシステムをデザインする行為」が何を意味するのかについて詳しく検証することができません。

TODO: ゲームのルールについて

「フレーバーをデザインする」とは何か

上記の「フレーバー」の説明は「ゲームの雰囲気周辺」となっており、具体例は「猿が踊る」「ロシア民謡が流れる」「世界観」が挙げられていました。

「ゲームの雰囲気周辺」という説明のみから何をデザインするのかを考える場合「ゲームの雰囲気となるもの」と「ゲームの雰囲気とならないもの」の境界を探ることになります。

ブログ記事では、対極の例、つまり「フレーバーが無い場合」の説明と思われる例として

インベーダーゲームも、敵も味方も四角形で表現したとしてゲームとしては成立するが物足りない。

を挙げています。つまり「敵も味方も四角形で表現した場合」は「フレーバーが無い」状態であるとして説明しており、実際の「スペースインベーダー」では、プレイヤーは「レーザーを撃つ砲台」、敵は「宇宙人」を模しているとされています。

例として挙げられる「猿が踊る」「世界観」「レーザーを撃つ砲台」「宇宙人」という具体例それぞれがもつ共通の性質として考えられるのは、それらが「虚構世界（フィクション）上のもの」であるという点です。つまり、少なくとも「虚構世界（フィクション）をデザインすること」は「フレーバーをデザインすること」に含まれると考えて良さそうです。

一つ、「ロシア民謡が流れる」に関しては排除して考えていました。「ロシア民謡が流れる」は「テトリス」の例であり、ゲーム中に流れるロシア民謡はBGMであるため、それは「虚構世界（フィクション）上の出来事」ではありません。もし、それが「虚構世界（フィクション）上の出来事として流れる音楽（例えば「音楽プレイヤーを持ったキャラクターが登場して、再生ボタンを押した」など）」であるならば、その音楽も「虚構世界（フィクション）」の要素として考えて良いです。

BGMは文字通り「それはBGMというものである」とするなら、ここで言う「フレーバー」を構成する要素は「虚構世界（フィクション）」と「BGM」となり、以下の図のようになります。

「虚構世界（フィクション）」と「BGM」の抽象度が異るためか、いびつな印象があります。

「ボリュームをデザインする」とは何か

「ボリューム」は「ゲームの物量」と説明されており、具体例として「ステージ数の多さ」「プレイ時間の長さ」などが挙げられています。

まず「あるデザイン対象の要素の種類の数をどの程度の量にするのか」という意思決定は「ゲームの内容を考えて決める行為」に含まると考えて良さそうです。

しかし、例で挙げられている「ステージ数」「モンスターの数」「クエストの数」は、それぞれ全く同じ内容のコピーが数多く作られるわけではありません。ここで言う「ボリューム」が意味するところとして重要なのは「その数」ではなく「様々な異なる種類がある」という点であると考えられます。そのため、ゲームデザイン要素の呼び名としては「ボリューム」というより「多様性（バラエティ）」とした方が、より体をなしていると考えられます。

ゲームデザインの枠組みとしての利用可能性

島国大和さんの「ビデオゲームを構成する3つの要素」で挙げられた内容から読み取れる、ゲームデザインの対象となる要素には以下のものがありました。

ゲームのルール
虚構世界（フィクション）
BGM
ボリューム（バラエティ）

次で、ゲームデザインの枠組みとして利用可能かどうかについて考えます。

デザイン可能性

「ボリューム（バラエティ）」に関しては、これはデザイン対象ではなく、デザインの成果物が持ちえる属性であるため、ゲームデザイン要素として利用できません。

ボリュームを「量」として捉えた場合は、成果物の「量」という属性となり、「量」そのものは（単独で）デザインできません。ボリュームをバラエティ（多様性）と捉えた場合も、成果物が様々な種類を持っているかどうかという「属性」であり、バラエティ（多様性）そのものは（単体で）デザインできません。

「ゲームのルール」「虚構世界（フィクション）」「BGM」は、デザイン対象であると言えます。

適度な粒度

それぞれの要素が適度な粒度であるか考えます。

もし、「ゲームのルール」を考えて決める必要に迫られた場合、ルールの何をまず決めたら良いのか、そもそもルールとは何か、という迷いが発生しそうです。「ゲームのルール」を手際良くその内容を決められる場合は、そのとき理解している「ルールを構成する要素」を基準に決めていると思われます。つまり「ゲームのルール」という概念は、デザイン対象の要素としてさらに分解できる余地を残していることになります。

「虚構世界（フィクション）」「BGM」も同様で「虚構世界（フィクション）を構成する要素」に分解できる余地を残しているように思います。ただ「BGM」に関するデザイン要素は、突き詰めると楽曲制作の専門的知識に関わる要素まで掘り下げられそうですが、あくまでゲームデザイン行為としての範疇としてのデザイン要素としても、まだ分解はできそうです。つまり、ゲームデザインという行為において「BGM」の何を考えて決める必要があるのか、という点です。

「ボリューム」は、そもそもデザイン対象ではないので、粒度を検証できません。

評価結果

「ビデオゲームを構成する3つの要素」（4つになりましたが）の評価結果は以下のようになります。

デザイン要素	デザイン可能性	適度な粒度
ゲームのルール	◯	✕
虚構世界（フィクション）	◯	✕
BGM	◯	✕
ボリューム（バラエティ）	✕	-

概ねデザイン可能性に関しては問題ありませんが、粒度がまだ荒いです。これは、この枠組みが優秀ではないということでなく、あくまでデザイン行為を円滑化するための枠組みとして利用するには難がある、ということです。

「Rules Of Play : Game Design Fundamentals」のシステム

ゲームにおける「システム」と呼ばれるものに関して、下田賢佑さんが解説をしていました。島国大和さんの「ビデオゲームを構成する3つの要素」の「システム」と同じものを指している言葉かどうかは明確ではないですが、枠組みとして利用可能かどうかを見ていきます。

ゲームデザイナーの仕事（２）〜ゲームプレイとゲームメカニクス〜｜下田賢佑｜note

こちらの解説は、「Rules Of Play : Game Design Fundamentals」(Eric Zimmerman / Katie Salen Tekinbas, 2003)という書籍で解説している内容に準拠したものになっており、システムを「形式的システム」「体験的システム」「文化的システム」の3つに分けており、それぞれ以下のような説明がされています。

システム	システムがもつ共通な性質の説明（内包）	具体例（外延）
形式的システム	なし	チェスのルールそれ自体
体験的システム	なし	プレイヤー間のインタラクション、またはプレイヤーの置かれた環境。プレイヤーの戦術的なインタラクション
文化的システム	なし	この世で行われる全てのチェスのゲームをオブジェクトと見なし、それらプレイの積み重ねが作り出すコンテクストが、時代環境との間に相互に影響を与える様

「形式的システム」が、いわゆる「ルール」に相当するようで、これ以外の「体験的システム」「文化的システム」に関しては、ゲームデザインによって生み出される成果物から発生する事象であり、直接デザインされる成果物ではないように見えます。よって、今回の目的として、この枠組そのものからは「ルール」という要素しか取り出せず、上記の「ビデオゲームを構成する3つの要素」の「システム」と対応します。

「ルール」をさらに分解する必要はありますが、ここでは一旦議論を止めて次に進みます。

「The 7 Elements of Game Design」

Graham Dolle さんが「The 7 Elements of Game Design」という記事を公開しています。

The 7 Elements of Game Design - Graham Dolle - Medium（英語）

タイトルを直訳すると「ゲームデザインの7つの要素」です。

ここで挙げられている要素とその説明を表にしたものが以下のものです。

要素	要素がもつ共通な性質の説明（内包）	具体例（外延）
Space（空間）	変化可能な要素としてのゲーム世界。逆に言えば、変化可能な要素の集まり	チェスにおける駒と盤面
Mechanics（メカニクス）	「空間」を変更または表示するために使われるルールと構造	「パックマン」における「ドットに触れると食べる」
Implicit Narrative（明示的物語）	デザインされた物語	「ウォーキング・デッド」シリーズのストーリー
Explicit Narrative（暗黙的物語）	ゲーム空間が変化するような一連のエピソードにプレイヤーがどのように反応し、どのように関与するかによって作られる物語	「マインクラフト」において、洞窟を見つけた話や、溶岩でいっぱいのゾンビ地獄があった話
Feedback（フィードバック）	ゲーム空間の状態の変化に応じて発生するイベント	銃を撃つときに画面が揺れたり、効果音が鳴る
Pacing（歩調）	デザイナーによってデザインされた通りにゲーム空間が変化、進行する意図的な一連の流れ	「マリオ」を通してプレイすると、メカニクスが増えていくにつれて、ステージは難しくなる
Interface（インターフェース）	ゲーム空間を図示する方法、およびプレイヤーによるメカニクスの実行方法	アーケードゲーム
Variety（多様性）

TODO