Unity エディターの便利機能まとめ

どうも、solaです。

ここでは、Unity Editorの環境・設定・操作周りのちょっとした便利機能についてまとめていきたいと思います。思い出したり、新たに知った時なんかに随時追加していく予定です。

自分用の備忘録みたいなものですが、お役に立てば光栄です。

■フライトモード

エディターのシーンビュー(カメラ、ライト、その他のゲームオブジェクトが配置されている画面)上で、「マウス右クリックを押しながらWASDQEキー」の操作でフライトモードによる移動が可能になる。

よくあるFPSの移動操作と同じWASDがそれぞれ前進、左へ向く、後退、右へ向く。QEはそれぞれ左へスライド、右へスライドとなる。

 

■シーンビューの見た目とゲームモードの見た目を同じにする方法(現在のシーンビューの視点位置にCameraを移動する(位置と回転を合わせる)方法)

1.Cameraを選択する(メインカメラ)

2.Ctrlキー+Shiftキー+Fキーを同時に押す(Windows)  または、メニューから”GameObject”→”Align With View”を選択する

※必ずCameraオブジェクトを選択状態にしておくこと。それ以外のゲームオブジェクトを選択した状態で「2」を行うと、そのオブジェクトがシーンビューを見ている位置に移動してしまう。

 

■ゲームオブジェクトの変更をそのプレハブに適用する方法

プレハブをシーンに追加してから(ゲームオブジェクトとして実体化される)、そのゲームオブジェクトに変更を加えた場合(コンポーネントの追加、サイズの変更など)、該当オブジェクトを選択してからメニューの”GameObject”→”Apply Changes To Prefab”を選択することで、プレハブが更新される

 

■ゲームオブジェクトとプレハブのリンクを外す方法

プレハブから生成されたゲームオブジェクト(Hierarchy(ヒエラルキー))欄で青く表示)においてプレハブを削除すると、プレハブ(設計図)がなくなる(Missing)ため表示が赤くなる。その際、ゲームオブジェクトを選択してから”GameObject”→”Break Prefab Instance”と選択することで、プレハブとゲームオブジェクトのリンクを外すことができる。もちろん、表示が青い状態(=プレハブが存在)においても同じ操作でリンクを外すことが可能。簡単に言えば、プレハブからの実体化ではなく、ただのGameObjectになります。

 

つづく
<お約束の破壊による物語の発想法 : >


お約束の破壊が物語にドラマを生み出す

どうも、トイレで気張ってたり、風呂に浸かってたりするときに物語のネタがよく思い浮かぶsolaです。

物語の種みたいなものっていつやってくるか分かりません。基本的には、天から何か降りてくるのを待っている状態の私ですが、時には物語の発想法を試したりもします。

今回はそんな発想法から一つ紹介してみます。テーマは「お約束の破壊」です。

■展開のお約束を破壊してみる

展開というのは、物語の筋のことです。例えば「異世界に飛ばされた主人公が、そこで出会ったヒロインや仲間たちと協力して異世界を救う」とか「ゲームの世界に入りこんじゃって出られない」とか「洋館、孤島など閉ざされた場所で次々に人が殺されちゃう」とか「朝、通学路の途中でぶつかった美少女が実は転校生であーだこーだ」とか、そんな感じです。

漫画、アニメ、ライトノベル、ノベルゲームなんかにはありがちな展開ですね。こういったよくある展開ってお約束にあふれてます

例えば、異世界に飛ばされた主人公はたいてい普通の高校生です。なのに大人たちを巧みな話術で論破したり高度な戦闘スキル持っていたりハーレムを築いた上でお姫様と結ばれたりします。

孤島や洋館に人が集められると、なぜか唯一の交通路が封鎖されます。なぜか皆一癖あり怪しいです。探偵が必ずいます。人智を超えたトリックが目白押しです。

通学路の途中でぶつかった美少女転校生はたいていツンデレです。あと主人公はたいてい忘れていますが、幼少期にヒロインと出会っていて結婚の約束をしています。

「展開のお約束」のメリットとしては、いちいち説明しなくてもその世界にスッと入り込むことができること、読者が安心して(落ち着いて)物語を読み進められることなどが挙げられます。歌舞伎や落語なんかはお約束がたくさんあります。お約束があるからこそ、一体感・共有感が生まれるわけです。

デメリットとしては、「またかよ!」「◯◯のパクリかよ!」みたいな感じで最初から飽きられてしまうことですが、これは作り手の腕の見せどころでしょう。そもそも物語の展開なんて、帰納すれば既存の「物語の類型」にだいたい当てはまりますしね。

本題です。この「展開のお約束」を破壊することで、人を惹きつけるドラマが生まれることがあります。

以下、展開のお約束について、二つほどアニメのネタバレをしますので、まだ観ていない方は飛ばしてください。共感してもらうためにも、有名どころを挙げます。

 

一つ目は『魔法少女まどか☆マギカ』です。

アニメファンであれば、タイトルをパッと見ただけで「ああ、これは『魔法少女モノ』」だなと思う人が多かったはずです。魔法少女モノの展開のお約束は、「普通の女の子がある日、見たこともない可愛らしいしゃべる生き物と遭遇し、たいてい同時に超常的な敵の攻撃を受けます。で、その生き物に魔法の力を授けられ魔法少女に変身(決めポーズとともにひらひらした衣装に変化)し、ピンチを切り抜けます。そして同じような仲間の魔法使いとともに悪を倒す日々がはじまる」みたいな感じです。もちろん、全ての魔法少女モノがこのお約束を踏襲するわけではありません。とにかく、そのお約束を元にしていろいろなバリエーションが存在するわけです。

『魔法少女まどか☆マギカ』は、魔法少女モノのお約束を破壊することで話題をさらいました。「ある主要キャラが早期かつ凄絶に死亡」「魔法の力を授ける生き物こそが敵だった」「主人公がなかなか魔法少女にならない」「魔法少女として戦うと最終的に魔女(敵)になる」「戦闘手段が魔法でなく兵器類」……。もちろん、お約束を破ったことだけで話題になったわけではありません。脚本家によるセリフ、描写、ストーリー展開の妙や、可愛らしいキャラデザとPV(あくまで普通の魔法少女モノに見せていた)で巧妙に騙したことも大きいでしょう。しかし、魔法少女モノのお約束(魔法少女モノ特有のお約束でないものもありますが)を次々に破壊することで、視聴者に”驚き”を与え「これは一味違うぞ!」と思わせたことが成功の大きな一因と言えます。

二つ目は『がっこうぐらし!』です。

これは「日常系アニメ」と呼ばれる展開のお約束を破壊することで視聴者を惹きつけました。日常系とは、「かわいい女の子たち」が「学校を舞台」にして「何気ない楽しい日常」を送るまったりとしたコメディを指します。基本的にストーリー展開に大きな落差はありません。昨今のキャラクター重視の風潮や、のんびりと気を抜いて観ることができることもあり、大きな人気を誇るアニメジャンルです。

『がっこうぐらし!』はこのお約束を破壊しました。

学校での楽しい日常は、現実にたえられない主人公の妄想だったのです。実際は、ゾンビによって包囲されている状態での女の子たちのサバイバルモノでした。「日常系アニメ」の登場人物たちは、リアル世界と違って年齢より大分幼く描写されるのが常なのですが、それについても主人公が現実逃避のために幼児退行しているという解を与えているのが素晴らしいです。現在(2015年8月)放映中ですが、かなりの視聴者に衝撃を与えているようです。

他にも、ロボットモノやスポ根モノの名作にも存在します。またこういったお約束展開の破壊は文章で伝えやすいため、小説にも多いです。ネタバレばかりしてもしょうがないのでこの辺りで止めておきます。

 

とにかく、視聴者や読者が思い浮かべる「展開のお約束」を破壊し、予想を裏切る手法はかなり効果が高いと思われます。ただし、お約束を破壊すれば絶対にウケるわけではありません。逆に、見限られてしまったり、対して効果がないこともあります。

■キャラクター設定のお約束を破壊してみる

キャラクター設定には、いわゆるテンプレと呼ばれるものがあります。

ツンデレ、クール。料理下手なヒロイン。勉強できないけど真っ直ぐでへこたれないツンツン髪。言葉足らずですぐに手が出るので勘違いされているけれど実は優しくて、ヒロインだけは理解してくれている不良。お嬢様はたいてい高飛車ですが意外に純粋なところがあって主人公にツッコまれて顔真っ赤にします。頭脳キャラはメガネをしていてクイってしたり光ったりします。出世街道を外れた40代の刑事はやる気あふれる新人刑事と組まされます。……ちょっと違うものもありますが、とにかくキャラクター設定にはこういったお約束が存在します。

キャラクター設定のお約束のメリット、デメリットは展開のお約束とだいたい同じかと思います。他には、テンプレに沿っていればキャラクターを覚えやすいこともありそうです。ただ、当然なんですが、キャラクター設定はストーリーに大きく左右されます(現代的な物語はキャラクター重視ですが、基本的にはストーリーが主になります)し、通常、復数のテンプレを混ぜます。実際、まったく同じ設定のキャラを思い浮かべようとしてもなかなか出てこないのではないでしょうか。例えば同じツンデレキャラでも、メイン設定がツンデレなだけで、他にさまざまな副設定が付随しているはずです。

ともあれ、この「キャラクター設定のお約束」の破壊でも新たな発想を得ることができます。少年誌的な超ポジティブシンキング主人公が、実は当初から深い闇を抱えていてある事件をキッカケにそれが露呈するとか。頭脳キャラのメガネが光ったのに実は脳筋でしたとか。使える・使えないは置いておいて、こういった発想を試みることが物語に驚きを与える一助となりえます

■ルール設定のお約束を破壊してみる

物語にはたいていルールが存在します。例えば「リアル世界と同じ設定の探偵モノ・推理モノ」については「探偵自身(語り手)が犯人になってはいけない」「超能力や魔法(舞台に存在し得ないもの)がトリックや解決に使われてはいけない」「一度も登場していない人物が犯人ではいけない」というルールが暗黙的に存在していたりします。これらは物語中では語られることのない、ジャンルとしての絶対的ルールとも言えます。

さらに、少し観点が異なりますが、「山奥にある古い社には近づいていけない」とか「火、風、水、土の四元素からなる精霊魔法の行使の方法」とか「超能力者をレベルごとにわけて管理している」とか、創作者自身がその物語に向けて生み出したルールがあります。

そして、その創作者のルールが中心となる物語があります。「新世界より」、「デスノート」、「バトル・ロワイアル」、「ライアーゲーム」などです。どれも、主催者や神、統治者、それに準じる者によって細かく規定されたルールに則って物語が進行していきます。

ルールに沿うというのは物語を伝える上でかなり重要です。たとえば、リアルな人間同士が競う本格ボクシング漫画の世界に、実は異星人の戦闘民族で気合を入れると髪が逆だって地球を破壊できちゃう戦闘狂が登場するわけにはいきません(してもいいですが、ただのギャグ漫画になります。それはそれで面白くなるかも?)。それは、絶対に守らなければならないルールなわけです。

ここでいう「ル-ル設定のお約束」の破壊とは、そういった最低限遵守すべきルールとは別と考えてください。

わかり易い例を挙げると、「山奥にある古い社には近づいていけない」と物語の初期に村長に言いつけられたからといって、「はい、わかりました」と社に近寄らずに家に帰ってしまってはそもそもストーリー自体がはじまりません。社に近づいてこそ、ドラマが生まれるのです。

例えば、登場人物たちが「火、風、水、土の四元素からなる精霊魔法」で戦うストーリーだとします。主人公はいまいち精霊魔法が苦手でバカにされていましたが、実は四元素を凌駕する光魔法を行使する存在だったとか。例えば、管理者によってレベルごとに超能力者をわけていた都市で、管理できないほど強大な能力者が生まれ世界を滅ぼそうとする。それを止められるのはレベル分けのルール上無能力者とされていたレベル0の主人公だったとか。

ようは創作者自身が作った世界観上のルールを絶対とせず、それを超える存在を作ることでドラマをつくり出すわけです。

特に、上で挙げた「新世界より」や「バトル・ロワイアル」のようにルールが細かく規定された物語では、イレギュラーな存在がルールに逆らうことで物語を動かすことが常なわけです。

ちなみに、探偵モノで探偵(語り手)自身が犯人であることは、昔からタブーにされていますが、実際のところ、守っていない探偵小説も結構あります。

このルールのお約束の破壊については、後から考えてみれば当たり前に使う手法なんですが、創作初期の段階にて世界観の構築中などに、決めたルールを破壊したらどうなるか、なんてところに注目してみると、面白い発想が思いつくかもしれません

 

さて、今回は、「展開」、「キャラクター設定」、「ルール」のお約束を破壊するというネタの発想法について語りましたが、お約束の破壊はこれだけに限りません。いろいろと試してみてください。

最後に、お約束の破壊は万能ではありません。絶対に面白いドラマが思い浮かぶわけではないことに注意してください。お約束を順守して展開する物語にも傑作はたくさんあります。むしろ、だからこそ「物語のお約束」と認識されているとも言えます。

それでは。
<物語を伝えるための日本語基礎技術 : UnityEditorの便利機能まとめ>


文章における著作権について

どうも、solaです。

巷では、東京オリンピックのエンブレム周辺に関して、あるデザイナーが著作権を侵害しているのではないかという話題が取り沙汰されています。私はデザイナーではないので、それについて何かコメントをするつもりはありません。クリエイターのはしくれとして注目しているのみです。

さて、これまで編集やライターといった仕事を通じて、不特定多数の目に触れる文章に関わってきたので著作権に関しては細心の注意を払ってきたつもりです。

とはいえ、完璧に把握できているのかといえばそういうわけでもありません。

そんなわけで、今後のためにも改めて文章に関する著作権について勉強をしてみようと思います。

■著作権とは何か

文芸、シナリオ、論文、音楽、絵、彫刻、写真、ゲーム、ダンス、建築物、映画……などといった学術的・芸術的な作品=著作物を保護する権利が著作権です。

著作物とは「人間の活動として、感情やアイデア、思想を表現して生み出された作品」を指します。著作権は「その著作物の権利(財産権)を持っているのは創作した本人(著作者)ですよ」ということを保証しているわけです。当然ですが、著作者本人は著作物(作品)を自由に利用できます。

ちなみに、著作権はベルヌ条約と呼ばれる国際法を元にして各国の著作権法で保護されています(もちろん、ベルヌ条約を採択している国に限ります)。ベルヌ条約において、著作権の発生は無方式主義が義務付けられています。なんのこっちゃということですが、ようは著作権は創作された時点で発生するということです。どこかの機関に届け出で登録したり、コピーライトマーク(よく見る©ってやつです)をつけたりしなくても、生み出された時点で著作権は著作者に発生するわけです。

日本では著作権の登録が可能です。これは著作権の発生とは別物で、念の為、自分がその作品の著作者であると証明しておくというものです。万が一、著作権で争うようなことがあった場合に、対抗手段の一つになりうるわけです。また、コピーライトマークも著作権の発生とは別です。現在では方式主義(届け出、登録が必要)の国などで著作物を守るために慣例的に表記するものといった立ち位置です(この辺りは細かいので興味があれば調べてみてください)。

■著作権によって保護されないもの

次に著作権の対象にならないもの、つまり著作物に当たらないものをいくつか挙げてみます。これが論争の種になったりします。

・著作物の範疇にないもの

当然なんですが、前述の定義に当てはまらないものは著作権で保護されません。「こんにちは」という一般的なセリフ(表現)に著作権は発生しないのです。

・単なる事実の報道

「◯月◯日 ☓時☓分 ◯◯にて交通事故発生」みたいなものは著作物には該当しません。そこに思想や感情が介在しないためです。

ただし、事実を元にして、取材を行ったり考察されて書かれた新聞記事は著作物です。

・保護期間の切れたもの

著作者の死後五十年過ぎたものは著作権の保護の対象となりません(著作物によって異なります)。そんなわけで、古い小説が「青空文庫」などで無料で読めるわけです。

・引用がメインになると著作物と認められない

特に論文やウェブサイトでのハウツー記事に多いですが、他人の文章(著作物)の引用自体は認められています。

ただし引用として認められること(引用文の範囲が分かる、引用元の明記)と、引用されたもの自体がその作品においてメインでないことが重要です。

人様の著作物の引用がメインになってしまうと、そこには独創性がないとされ著作物とは認められません

ちなみに、編纂したものについては著作権が認められるものがあります。例えば、辞書。言葉や意味、フレーズは引用でありますが、配置などに独創性が認められるのです。

・アイデアやコンセプトは著作権で保護されない

料理のレシピそのもの(ハンバーグを作る手順)とか、小説のネタ(着想、発想、おおまかなテーマ)とかそういったアイデアやコンセプトのようなものは著作権保護の対象になりません。アイデアそれ自体は活動結果としての創作(作品)に当たらないというのが定説です。

料理のレシピを他人に伝えるために独自に文章を書き、写真を取ってまとめたものや、小説(あるいはシナリオ)にて実際に文章として表現されたもの(フレーズ)は創作物となるため、著作権保護の対象となります。

ようは、アイデア・コンセプトはOK、具体的な表現(フレーズ)はNGというわけです

小説、漫画、アニメなど、ネタや発想が似通っているものってたくさんありますよね。「物語の種類はシェイクスピアがすでに出し尽くしている」などという有名な言葉もあるくらいです。例えば「普通の高校生男子が異世界に飛ばされて、ヒロインとともに異世界を救う」なんて、SF小説、ライトノベル、漫画に昔からありふれているネタですよね。

とは言っても、何がアイデアで何が表現なのかについて、キッチリと区別することも難しいです。そんなわけで今まで何度も裁判が起こっています。その辺りは判例を調べてみると面白いですよ。判例を見るに、やはり原則として「具体的な表現の盗用」でなければ問題がないという方向のようです。

※アイデアとはいえ独創性の高いものであれば著作権とは別にして民事で訴えられることもありえます。

■何をもって著作権侵害とするのか

まず、著作権については親告罪です。つまり、盗作された側が訴えない限り罪にはなりません(正確には、訴えてかつ盗作と認められた場合に罪となる)。

そして、原告側は以下の三点について立証する必要があるのです。

1.類似性

似ているか似ていないかということです。前述のとおり、文章であれば具体的な表現(文章、フレーズ)を取り出し比較して類似性を指摘します。当然、創作部分(=著作物とされる部分)が似ているかどうかです。ばからしい例ですが、お互いの小説の中で「こんにちは」というフレーズがかぶっていてもそれはありふれた挨拶なので類似性は認められません。他のありがちな表現や一般的なフレーズも同じくです。

2.利用行為

私的利用は著作権違反にはなりません。商用利用、つまり盗作(が疑われる)でお金を儲けたり、もしくは盗作したものを無料で頒布することで、本来購入されるはずだった盗作元著作物の被害などを指摘します。どこまでが私的で、どこまでが商用利用なのかが、よく争点になります。

3.依拠性

一言で言ってしまえば、被告(盗作したと疑われている側)が原告(盗作されたと訴えている側)の著作物を知っていたかどうかということです。同じ時代の人間が同じアイデアで作った創作物なので、どうしても似てしまうこともあり、依拠性がなければ著作権違反とはなりません。なので、その作品を知っていて盗用したかどうかなどが争点になります。

これは判断の難しいところです。当然ではあるのですが、前述の「類似性」とも関わってきます。いくら「そんなもの知らない!」とつっぱねても、まったく同じ表現が何度も現れるのであれば、著作権侵害となる可能性が高まります。絵は分かりやすくて、トレースなどは言い訳ができません。それから原告側の作品が世界的に有名な場合、同じジャンルのクリエイターがそれを知らないとは思えないということで依拠性が立証されます(例えば、ディ◯ニーのミッ◯ーをほぼパクって新たなキャラを生み出した場合、まさかキャラ物を作るクリエイターがディ◯ニーを知らないわけがないというようなことです)。

さらっと説明しましたが本来はもっと細かく規定されています。著作権を侵害しているかどうかの判断はかなり難しいもので、いろいろな場所で議論されています。

■まとめ

今回、「文章」についての著作権を想定した記事となりました。著作物によっては、著作権での保護や扱いが他と異なる場合もありますので、文章以外のクリエイターも自分の創作物について一度調べてみるといいかもしれません。

TPPの件で著作物の非親告罪化が話題になっていますが、現状、著作権は親告罪です。訴えてそれが認められない限り罪とはならないわけです。アニメや漫画の二次創作なんかは、諸々の理由から許されている例ですね。

今回の記事はあくまで、著作権についての問題です。パクリ(とくに法的には問題ないが、アイデアなり見た目なり表現なりかなり似せているもの)問題についてはここでは語りません。ただ、クリエイターにとってこの辺りは悩みどころですよね。確実にパクられているけれども訴えにくかったり、逆にパクったつもりはないのにパクリ認定されたり……。それ以前に、法的に問題がなければパクってもいいの?ということも。クリエイターとして視聴者、読者、同業者といった世間に対して恥ずかしくない創作を心がけたいと思いつつ。

それでは。

物語を伝えるための日本語基礎技術

どうも、solaです。

「物語」と一言でいってもコンテンツの種類によってアプローチは異なります。例えば、小説は文字のみの物語です(挿絵は除外)。漫画は文字にプラスして、映像を用いた物語です。ドラマや映画にはさらに音楽が、ゲームにはゲーム性が加わります。

しかし、どんなコンテンツにおいても物語の基本となるのは「文章」です。小説は当然として、漫画のプロット、ドラマや映画の脚本、ゲームのゲームシナリオ、どれも文章がメインなのです。

というわけで,今回は物語の基本となる「文章」つまり日本語の作文技術について語ってみます。

■文体は作家によって千差万別

美文だとか悪文だとか、どの作家が文章力があるだとか、そういう話題って尽きませんよね。文章の書き方=文体は作家によって様々です。

ちょいと小説家を例にしてみます。

美文の有名どころとしては三島由紀夫がよくあがります。代表作を数冊程度読んだ程度の自分が語るのもおこがましいのですが、確かに美しい文体です。どことなく耽美的な表現だと思っていたら、ロマン主義あたりのフランス文学に影響を受けていたようです。詩的でかつ無駄のないスリムな文体です。

それから、太宰治。小中学生の読書感想文にもよく登場しますね。私もその頃に読み漁りました。同じ時代の作家の中で、特に読みやすい文体です。語りかけるような、口語調の文章が特徴です。

オノマトペや造語を散りばめた幻想的な文体が特徴の宮沢賢治。

東野圭吾氏といえば心理描写、風景描写、比喩表現などはほぼなく、とにかくストーリーを簡潔に伝える文体です。そのため、普段「小説」を読まない方にも受け入れやすいのかもしれません。

春樹節と呼ばれるしゃれた文体の村上春樹氏。人物描写や比喩表現がかなり特徴的でコミカルな伊坂幸太郎氏。年頃の女性の心の動きを美しく細かく描写する恩田陸氏。

伝奇物において、京極夏彦氏、奈須きのこ氏は誰が見ても一発で分かるほどに特徴的な文体です。

……長くなりそうなのでここまでにしておきます。

とにかく「小説」における文章の書き方=文体は、作家によって様々なわけです。そうして、美文とか悪文とか、文章力があるとかないとかいうのは、読者側の好みという側面もあります。とはいえ、作家の文体をひたすら真似ただけだと劣化したように感じてしまうこともあったりするので、やはりそこにプロの作家としての力量があるのでしょう。

■文章の書き方を学ぶことの意義

小説における文体の良し悪しは好みでしかないとはいえ、限度というものがあります。私自身の文章の巧拙は置いておくとして、例えばインターネット上に公開されている小説(第三者はもちろん、自身ですら推敲していないと思われるもの)の中には、酷いものになると何を伝えようとしているのか全く読み取れないものもあります。いくら自由とはいえ、最低限の「文章の書き方」は学ぶべきでしょう。自分なりの文体は基礎を学んでから身につけるとしましょう。その辺りは、絵や作曲など他の創作修行と変わらないと思います。

これは私が編集者として働いていた時に、研修で使った本の一つです(実際は旧版でした)。

日本語による文章の書き方を論理的に説明している数少ない本です。主にジャーナリスト、ライター向けの内容になっているのですが、物語にも活用できます。

「いや、自分が書きたいのは素晴らしい比喩表現と細やかな心理描写にあふれる独特な物語であって、簡潔で論理的な文章ではない!」という方もいるかもしれませんが、小説(物語)の基本は「物語の展開をわかりやすく簡潔に伝える」ことです。

■なぜ日本語を使った作文は難しいのか

日本語は、基本的に語順が自由で、助詞によって主語や目的語が決定します。さらに、修飾語(形容詞や副詞)についても自由に組み込むことができます。

日本語の自由さのせいで、伝わりにくい文章ができあがってしまいやすいのです。

今回は「語順」「助詞」「修飾語」についてさらっと解説してみます。

・日本語の語順

1.「私はあなたを愛しています。」

2.「あなたを私は愛しています。」

1と2、語順が異なりますが、どちらも意味自体は通じますよね(ちなみに述語=動詞は最後に来ます)。では、どちらの語順が読みやすい文章ですか?

ほとんどの人が、1の語順を選ぶのではないでしょうか。

英語などのヨーロッパ系言語・中国語の語順はSVO(主語→動詞→目的語)型です(”I love you.”のように)。それに対し、日本語はSOV(主語→目的語→動詞)型です。

つまり、日本語の語順は自由ではありますが、基本的な文型においては「1」のようなSOV型の方が伝わりやすいのです。

ちなみに、「愛しているんだよ! 君を!! この私が!!」みたいなドラマチックな語順はよくありますが、こういう表現(強調)による語順の変化は英語(SVO型)にも存在します。

・助詞

私は言語学者ではないので講義で習った程度のことしか知りませんが、日本語のようなSOV型言語では助詞が重要になってきます。助詞によってそれが主語なのか目的語なのかなどが決定されるのです。

1.「私本を読みます。」

2.「私本を読みます。」

「が」と「は」はどちらも、主語に使用する助詞です。しかし、1と2はニュアンスが全く違いますよね。このくらい短い文章だと使い分けも簡単ですが、長い文章になると助詞がぶれてしまうことが多々ありますので、助詞については常に気を使う必要があります

「私は彼アイスを食べます。」

さて、この文章にある助詞「と」ですが、通常ならば”with”つまり「彼と”一緒”にアイスを食べる」という風に読み取ると思います。しかし、万が一”and”という意味で読み取ると、「彼とアイスの二つを私が食べる」というカニバリズム発言になってしまうわけです。この例ではそう読み取る人はほとんどいないと思いますが、実際には助詞のせいで紛らわしい文章になることがよくあります。その場合、助詞を置き換える作業が必要です。この例では、「私は彼と一緒にアイスを食べます。」とするわけです。

助詞の置き換えにはもうひとつあります。

「受験ため勉強スケジュールをたてる。」

この文章、意味は通じても、なんだか「の」が連続していて読みにくく野暮ったい印象ですよね。

こんなときは、「受験勉強のためにスケジュールをたてる。」もしくは「受験勉強のスケジュールをたてる。」という風に同じ助詞を置き換えたり減らすように文章を書き換えます

・修飾語

「壊された我が家

さて、この文章において、壊されたのは「我が家」と「鍋」どちらでしょうか。語順の自由さが仇となってどちらも修飾しているように読み取れてしまいます。こんなときは語順を変えて、「我が家の壊された鍋」とすると、修飾語「壊された」が修飾するものが「鍋」のみとなります

日本語は修飾語を好きなように挟むことができるので、何も考えずに修飾語をつけると上記のように読み取り方によって意味の違う文章になりがちです。

ちなみに、修飾語の揺れについては「修飾する言葉にできるだけ近づける」ことを心がけると解決することが多いです。上記の例も、「壊された」を「鍋」に近づける(直前に置く)ことで解決しています。

 

もちろん、日本語の作文技法はこれだけには留まりませんが、こんな風にしっかりと基礎を学んでいくと伝わりやすい文章を書くことができるようになります。

日本人であれば、日本語を書いて読めてしまうということが当たり前(基本的に)であり、それが逆に日本語の作文技術を学ぶ機会を減らしているのかもしれません。絵や音楽ならば基礎から学ぶことが当たり前なんですけどね。

というわけで今回は、「自由に記載できる小説(またはゲームシナリオ)であっても、基礎的な日本語の作文技術は学んでおいて損はないですよ」というお話でした。

それでは。
<オブジェクト指向をマスターする手がかり : お約束の破壊が物語にドラマを生み出す>

オブジェクト指向をマスターするためのヒント

どうも、solaです。

今回はみんな大好き(?)オブジェクト指向プログラミングの話です。

オブジェクト指向に関しては、書籍にしろインターネット上にしろ、有益な情報が多いですが、いろいろな側面からあたることで理解も深まるので、私なりにオブジェクト指向プログラミングの概要について語ってみます。

ちなみに、簡潔に説明する(つもり)ために一般的でない説明だったり、言葉足らずな部分もあるかと思いますが、ご了承ください。

■なぜオブジェクト指向プログラミングは難しいのか

プログラミング初心者にとってなぜオブジェクト指向プログラミングが難しいのかというと、専門用語の多さもその一因でしょう。

クラス、インスタンス、オブジェクト、継承、カプセル化、ポリモーフィズム、インターフェース……どれもオブジェクト指向プログラミングにとって重要な仕様なのですが、プログラミング経験がない場合、「なぜそんなものが必要なんだろう」という、そもそもの部分で躓いてしまうことになるでしょう。解説書にはサンプルコードがついていることが多いのですが、それだけでは理解できません。実際に、意味のあるプロジェクトの中で実装していかないと、その仕様がなぜ存在するのか理解できないことのほうが多いはずです。

だからといって、初心者向けの説明によくある概念的な話も、それはそれで不明瞭で、じゃあ実際どうすればいいの?と混乱してしまう元になってしまうことが多いと思われます。

■結局のところオブジェクト指向プログラミングとは何なのか

オブジェクト指向とは、けっしてプログラミング初心者をふるいに落とすための試練ではありません。より複雑で高度になってきたプログラムを設計・実装・管理・メンテナンスしやすくするための手法なわけです。

プログラミングというのは「データとそのデータの処理」=「機能」を記述していく作業と言えます。

いくつか例を挙げてみます。

・プレイヤーキャラクタを移動する機能

「プレイヤーキャラクタの座標」データを、「特定量だけ動かす」処理

この処理は、十字キーの操作という入力情報によって呼び出され、結果として移動後の座標にプレイヤーキャラクタが表示されます。

・敵キャラクターに物理ダメージを与える機能

「プレイヤーの攻撃力」データと「敵キャラクターの防御力」データから「ダメージ量」データを計算して、「敵のHP」データから差し引く処理

この処理は「たたかう」というコマンド操作によって呼び出され、結果として敵のHPが減ります(実際に画面に表示されなくとも内部のデータは変更されています)。

・ゲームがはじまる機能

「ゲームの現在の状態」データを「タイトル画面状態」から「メインゲーム画面状態」に変更する処理

この処理はタイトル画面の「スタート」のクリックで呼び出され、結果としてメインゲーム(ステージ1-1など)画面が表示されます。

 

オブジェクト指向というのは、単にそれらデータとその処理=機能の切り分け方が従来の手法と違うだけのことなのです。オブジェクト指向的に設計していくことで、データの保護やメンテナンス性・再利用性を高めて、複数人での巨大プロジェクトや頻繁な更新作業、再利用などに有利になる……という触れ込みなわけです。

実際、”処理”の中身に関しては、従来の方法だろうがオブジェクト指向だろうが、同じようにコーディングしていきます

■どうやってオブジェクト指向を身につけていけばいいのか

私はオブジェクト指向が嫌いです。

なぜ嫌いなのかというと……

・個人作業ので複数人メリットの恩恵がない。

・従来の関数とかモジュール単位でも充分に再利用性があると思っている。

・オブジェクト指向はいちいち記述が冗長になり、全体の把握が面倒。

ざっとこんなところでしょうか。

でもオブジェクト指向、やってます。なぜなら私の使っているUnity(ゲームエンジン)やVisual C#(統合開発環境)がオブジェクト指向に基づいた設計になっているからです。使わざるを得ないってやつです。

逆に言えば、UnityとかVisual C#のようなエンジンや開発環境を使ってある程度勉強を進めている方は、すでにオブジェクト指向プログラミングへの入門を済ませているといっても過言ではありません。

すでに用意されているクラスからインスタンスを生成して、そのメソッドを利用したり、メソッドを追加したりしているわけです。意識せずとも、立派にOOP(オブジェクト指向プログラミング)しています

他のパラダイム(手続き型とか)から移行してきた私のような人間にとって、オブジェクト指向的な考え方に切り替えるのは結構大変でした。しかし、UnityやVC#からプログラミングに入ればオブジェクト指向もすんなり頭に入ってくると思います。現に、私自身もJavaやC++に挫折後、VisualBasicのおかげでオブジェクト指向を理解する取っ掛かりができたところがあります(こちらのページ参照)。

じゃあもうオブジェクト指向について学ぶこともないじゃないかというと、そうでもありません。いずれ高度なゲームなりツールなりを作っていく場合、エンジンや開発環境が用意しているクラスでは事足りず、独自にクラス設計を行うことになります。そのためにはオブジェクト指向的な考え方は避けて通れません

では、クラス設計について軽く見てみましょう。

■オブジェクト指向の概念的なお話

oopyou

よくある横スクロールアクションゲームをオブジェクト指向的な考え方でプログラミングしていくことを考えてみます。

はじめに、オブジェクト指向とは「オブジェクトと呼ばれるモノが互いにやりとりをする」ことでプログラムが進んでいきます。なんのこっちゃ分からないかもしれませんがそう思っておいてください。

上記1~10の数字がふってあるモノがオブジェクトと呼ばれるものです。オブジェクトはそれぞれ「データ」と「処理」を持っています

1はプレイヤーキャラクターです。データとして「座標」を持っています。処理としては「左右の移動」「ジャンプ」「死んだら残機数を1減らす」を持っています。

2は敵キャラクターです。データとして「座標」「得点」を持っています。処理は「ただ左に移動し続ける」「倒されたらスコアを+200する」とします。

3はアイテムブロックです。データとして「パワーアップアイテム(取ると大きくなる)を出せる状態かそうでないか」を持っています。処理は「アイテムを出せる状態であれば、プレイヤーキャラクターに下から叩かれた時にアイテムを出し、さらに自身をアイテムを出せない状態にする」とします。

4はただのブロックです。処理は「プレイヤーキャラクターに下から叩かれたときに破壊され、スコアが+10される」とします。

5はただの地面ブロックです。処理は「プレイヤーキャラクターが落下しないようにする」とします。

6はコインです。処理は「プレイヤーキャラクターが触れた場合に消え、コイン枚数を一枚増やし、スコアが+100される」とします。

7は残機数です。データとして「プレイヤーキャラクターの残り機数」を持っています。処理は「現在の機数を表示する」「プレイヤーキャラクターが死んだ場合、残り機数を1減らす」「0になったらゲームオーバー」です。

8は獲得コイン数です。データとして「獲得したコイン数」を持っています。処理は「獲得コイン数を表示する」「100になったら残機数を1ふやしコイン数を0にする」です。

9はスコアです。データとして「得点」を持っています。処理は「得点を表示する」「10000点に達したら残機数を1増やす」です。

10はタイムです。データとして「残り時間」を持っています。処理は「ゲームが進行している場合カウントダウンを続ける」「残り時間が0になったら残機数を1減らす」です。

※全てのデータや処理を抜き出すとわかりにくいので適当です。例えば実際は上記すべてのオブジェクトが「座標」をデータとして持っています。また、わかりやすさ優先ということで、実際にはそうは記載しないというものもあります。その辺りはご了承ください。あくまで一例ということで。

でもって、このオブジェクトたちがやりとりを行うことでゲームが進んでいくわけです。

例えば、1のプレイヤーキャラクターが上から2の敵キャラクターとぶつかったときに、敵キャラクターの「倒されたらスコアを+200する」処理と9の「得点を表示する」処理が実行されるというわけです。

つまり、「オブジェクト同士のやりとり」とは、ある条件のときにお互いの任意の処理を実行することと言えます。

ついでに、クラスの話もしておきます。クラスとはオブジェクトの設計図のことを指します。オブジェクト指向プログラミングにおいて最重要項目です。この図の1~10のオブジェクトはインスタンス(実体)と呼ばれるもので、クラス(設計図)から生成されるのです。

つまり、実際のオブジェクト指向プログラミングとは、クラス(設計図)を作り、その設計図を元にしてオブジェクトを生成(インスタンス化する)するわけです。

例えば2の敵キャラは最初から表示されておらず、ある程度マップを進んだ先で出現するとします。その場合、ある程度マップを進んだところで敵キャラクタのクラスを元にして敵キャラクタのオブジェクトを生成=画面に表示し、倒されたならオブジェクトが破棄=画面から消えるというわけです。

なぜ直接オブジェクトを記述しないで、わざわざクラス(設計図)を作ってからそれを元にオブジェクトをインスタンス化するのかということですが、例えば同じ敵キャラクタが複数出現することを考えてください。同じオブジェクトであれば出現数の分オブジェクトを記述するよりも、クラスを一つ記述しておいて、そこから出現数だけインスタンス化した方が楽です。そんなわけでオブジェクト指向ではクラスを作りオブジェクトを利用するときに生成するという仕様になっています。

上図の例では、画面上に表示されている=見えるものをオブジェクトとしていますが、画面に見えないものもオブジェクトとなりえます

例えば、通常のゲームは以下のように”ゲームの状態”が遷移します。

・タイトル画面 ―(スタートボタンが押される)→ メインゲーム画面(上図のようなもの) ―(死ぬ)→ ゲームオーバー画面 ―(残機が0の場合)→ タイトル画面に戻る

他にも、オプション画面(メニュー画面)、ステージクリア画面、エンディング画面などへの遷移も考えられますね。

ある意味で一番重要な「ゲームの状態を管理する」機能ですが、これを受け持つのが”目に見えないオブジェクト”というわけです。

ここではそれを「ゲームマネージャー」と名付けることにします。ゲームマネージャーはデータとして「ゲームの状態」を持っています。処理は「ゲームの状態に応じて画面上に必要なオブジェクトを配置する」「メインゲーム画面のステージを管理する」などゲーム全般の進捗管理を行う処理を多数持つことになるでしょう。

他にも目に見えないオブジェクト(クラス)は考えられます。例えば、ゲーム音楽を鳴らしたり止めたりする「サウンドマネージャー」、入力機器(パッドとかキーボードとか)によらずに入力情報を担保する「インプットマネージャー」などなど……。

とにかく、目に見えようが見えまいが、ゲーム(プログラム)に必要な機能を抜き出して、それぞれクラスとして切り分け組み上げていくこと、つまり「クラス設計」こそがオブジェクト指向プログラミングの肝となります。

ちなみに、ここで出したクラス、オブジェクトの内容ははあくまで一例です。クラス設計はプログラマによって千差万別です。

千差万別ではあるのですが、大前提として関連するデータと処理は同じクラスにまとめます。例えば、プレイヤーキャラクタのHPというデータや、プレイヤーキャラクターのHPを増減する(ダメージとか回復とか)という処理は、プレイヤーキャラクターのクラスに含めるわけです。当たり前といえば当たり前なんですが、この大前提を常に頭に入れておくことで堅牢なクラス設計が可能になります。

■オブジェクト指向の用語について

できるだけ専門用語を使わない方向で話を進めてきましたが、ここでオブジェクト指向の仕様についていくつか説明しておきます。わからないものは適当に飛ばしてください。

・プロパティとメソッド

言語の仕様にもよりますが、今までデータと呼んでいたものを「プロパティ」、処理を「メソッド」と呼びます。手続き型言語に当てはめれば、プロパティとは変数のことで、メソッドとは関数のことです。

・カプセル化

オブジェクト指向、クラスの重要な思想の一つです。例えば前項の図にあった3のアイテムブロックオブジェクトを振り返ってみてください。このオブジェクトはデータとして「パワーアップアイテム(取ると大きくなる)を出せる状態かそうでないか」を持っていますが、このデータを利用するのはこのアイテムブロックオブジェクトのみで他のオブジェクトからは一切このデータにアクセスする必要がないということにします。

(※ゲームの内容によっては、このデータに他のオブジェクトがアクセスすることもあります。例えばステージクリア時にマップ上全てのアイテムブロックの状態を取得して、全ブロックを叩いていればボーナススコアが入るようにする場合などです。しかしここでは、他のオブジェクトがこのデータにアクセスすることはないとします)

その場合、その仕様を知らない別のプログラマが(もしくは時間が経っていてそういう仕様だと忘れていた場合も)他のオブジェクトから「パワーアップアイテム(取ると大きくなる)を出せる状態かそうでないか」データを書き換えてしまうようなコードを書いてしまうと困りますよね。

そんなときには、カプセル化という仕様によってこのデータを守り、アイテムブロックオブジェクトからしか変更できないように制限することができます。

・継承

分かりにくくなるので前項の例では全く触れていませんが、オブジェクト指向には継承と呼ばれる仕様があります。どんな仕様かというと、あるクラスを元にして(親クラス)、そのデータや処理を引き継いたクラス(子クラス)を作ることができるのです。

例えば前項の図の、3:アイテムブロックと4:ただのブロックオブジェクトを振り返ってみます。この二つ、似ていると思いませんか? そう、どちらもプレイヤーキャラクターに下から叩かれることによって変化が起こります。違いといえば、叩かれた際に壊れるのか(ついでにスコアが増える)、壊れずにアイテムを出すのかだけです。

そんなとき、「ブロック」というクラスを設計し、「プレイヤーに叩かれたときの処理」をメソッドとして記述しておきます。そして、それを継承して、新たに「ただのブロッククラス」と「アイテムブロッククラス」を作り、それぞれが継承した、「プレイヤーに叩かれたときの処理」を上書きして(オーバーライドといいます)、それぞれ「叩かれたら壊れてスコアになる処理」、「叩かれたらパワーアップアイテムを出す処理」とするのです。

また、図には表示されていませんが、キノコ的な敵キャラだけでなく、カメ的な敵キャラも出したい場合も考え方は同じです。

なんでそんなことするの?と思われるかもしれませんが、同じ系列のクラスの親クラスが存在している(抽象化、汎化)ことで、拡張が楽になります。例えば、新しいブロック(叩くとワープする)や、新しい敵キャラ(花のお化けキャラ)を追加するのが楽になるのです。また、キノコ的な敵キャラ、カメ的な敵キャラは別クラスですが、「敵キャラクラス」が存在することであたかも同じもののように扱うこともできるのです。

この辺りは、実際にクラス設計をしていかないとわからないと思います。ちなみに、最初から親クラスを作り、それを継承して子クラスを作ることもあれば、逆にいくつかの子クラスに対して(機能追加の必要性から)その親クラスを作ることもあります。

その他、インターフェース、ジェネリック、デリゲートなどなど、いろいろな仕様があるのですが、これらは実際に使いながら覚えていったほうがいいです。

一つだけ言えるのは、どれもオブジェクト指向を便利にするためのものだということです。別に知らなくても困らないけれど、知っているとすっきりと設計できるとかそういうレベルの話なだけです。

■今後のために

というわけで、オブジェクト指向の概要について触れてみました。少しでもヒントになれば幸いです。ほかのサイトや書籍、そして実際に自分で設計をして、オブジェクト指向をマスターしていってください(マスターしてない自分が言うのもなんですが)。

オブジェクト指向に慣れてきたら、デザインパターンについても勉強してみてください。デザインパターンとは簡単に言ってしまえばプロジェクトのジャンル毎にこんなパターンで組むといいよというものです。

とにかく、勉強のポイントは、最初から気張ってなんでもかんでも吸収しようとせず、適当に無理せず、そして実際に手を動かしながら(コーディング)学んでいくことだと思います。途中で詰まろうが挫折しようが、いずれ理解できるはずです。

それでは。

<プログラミング独学法 : 物語を伝えるための日本語基礎技術>

ものぐさ文系脳のためのプログラミング勉強法

どうも、solaです。

今回は私の経験を元に、プログラミングを独学で身に付けるためのヒントなんかを語ってみようと思います。

初心者に向けた内容となっています。特に、プログラミングの勉強に一度は挫折してしまったけれど、それでも独学で身につけたいと思っている方(過去の自分のことです)やUnityなどのゲームエンジンをひと通り触っているが、プログラミングについてはよく分かってないので勉強したい方は是非ご一読を。

ちなみに、私のプログラミングとの付き合い方ですが、あくまでゲーム制作が目的であってプログラミングはその手段でしかありません。車輪の再発明はしませんし、面倒だったり難しい処理はライブラリ頼りです。テクニカルなコーディングは苦手で愚直な感じで組んでます。シミュレーションや解析、AI、昨今の3D技術、高度なアルゴリズムなんかも、さっぱりわかりません。スタンドアロンのゲーム制作において、処理(移動とか当たり判定とか、メッセージの文字送りとか、セーブとか……)について設計し実装することにおいてはほぼ問題ない程度のスキルレベルという自己評価です。

実際、どんなものを作ってきたのかというと、C++とDirectXで2DRPGやノベルゲーム、VBやC#+.NETでマップツール・アニメーションツールなどのゲーム制作関連ツール、それから現在公開しているモバイル向け3Dゲームが代表的な作品です。

前置きが長くなりましたが本題に入ります。

■プログラミング学習の段階

まずは、プログラミングを学ぶ段階を挙げてみます。最終目的はゲームプログラミングです。

1.プログラミング入門

プログラミングがどういうものかを学ぶ段階。

2.任意のプログラミング言語の文法、プログラミングの構築手法(手続き型や構造化やオブジェクト指向など)の習得

任意のプログラミング言語仕(変数、制御文、構築手法毎の文法(手続き型における関数、オブジェクト指向におけるメソッドなど))についてひと通り学ぶ。

3.一般的なアルゴリズム、プログラミング関連知識の習得(ハード、API、ライブラリなどなど)

4.ゲーム制作のためのプログラミング技法の習得

ライブラリの仕様、ゲームエンジンの仕様(クラス設計)、ゲームアルゴリズムの習得、デザインパターン(オブジェクト指向)、数学

今回の記事では、1と2をメインに、初心者向けの独学法について解説します。ちなみに、2,3,4は実際には平行して勉強を進めることが多いと思います。

■初心者に向けたプログラミング学習のヒント

1.まずはプログラミング言語を選択する。

日本語や英語、フランス語など世界中にたくさんの言語が存在するように、プログラミング言語にも様々な種類があります。C++、C#、Java、JavaScript……とにかくたくさん存在します。

個人的な見解ですが、初心者こそプログラミング言語を決めて勉強をはじめるべきだと思っています。プログラミング以前の概念的な知識、論理的思考の基礎知識、下地となるハード寄りの知識なども重要なのですが、それらを学ぶのは後回しにしたほうがいいです。

概念や小難しい前提技術の勉強はつまらないですし(人によりますが)、ある程度プログラミングを知らないと身につかないことも多いです。最初はとにかく、実際にコードを書いて動かしてみることが重要です。

では、どんな言語を選ぼうかということですが、これからプログラミングの世界に入るのであれば、C#をオススメしておきます。ちなみに、すでにゲームエンジンを使っていてこれからも利用し続ける予定ならば、そのエンジンに対応した言語を選ぶべきです。

ぶっちゃけてしまえば、言語なんてひとつ覚えてしまえば、他も比較的簡単に身につくので、メジャーなものであれば適当に選んでいいんじゃないかとも思っています

2.プログラミングなんて簡単なものなので気楽に構えること。

研究やビジネスで最先端の技術を追いかけるとか、プログラミング技術自体でご飯を食べていくとか、そういうレベルのものはここでは除外します。ゲーム制作が目的でかつ面倒な部分はゲームエンジン(それから、ゲームエンジンより面倒ですがDirectXなどのライブラリ)にまかせる場合、プログラミングを修得するのにセンスや高度な勉強はとくに必要ありません

ゲームや一般的なツールを作るためのプログラミング言語は、人間に分かりやすく設計されています(主にアメリカで発展してきたので英語ですが)。プログラミングというと、PCの画面に向かってなんだかよくわからん呪文のような言葉を書き連ねているイメージがあるかもしれませんが、しっかりと勉強すれば誰でも修得できるスキルなので、気楽に構えましょう

3.まずは書籍で勉強を開始する。

プログラミング学習の入口にはインターネットではなく書籍をおすすめします。特に初心者のインターネットでの学習においては、以下のような問題が考えられます。
・情報が氾濫しすぎていて取捨選択が難しい。
・更新が途絶えていたり特定情報に偏っていたりで一貫した学習がしにくい。
・プログラミング言語の仕様について網羅しているサイトの場合、講座ではなく辞典としての情報提供である場合が多い。

もちろん、初心者向けの有用な講座もたくさんあります。また、頻繁に更新のあるツールや最新IT技術については、書籍が出た時にはすでに情報が遅れていることが多く、インターネットにはかないません。

ただし、プログラミング言語に関しては、基本的にそこまで頻繁に更新されるものではないので、書籍で問題ありません。もちろん、プログラミング言語にもバージョンはあるので、あまりにも古い書籍を選択する場合はご注意を(とはいえ、基本を学ぶのであればそこまで気にするものでもありません)。

全くの初心者の方は、以下の基準で選んでみてください(あえて書籍の紹介はしません)。
・ページ数が少なめであること。どこでも読めるように。
・辞書的でないこと。プログラミングをするための準備(開発ソフトのインストールや設定)から説明されていること。
・とにかくまずは作ってみようという形式のもの。ただし、コードがどんな意味を持つのかがわかりやすく解説されているもの(こう書けばこう動く!だけでろくな解説がないものは避ける)。
・著者が日本人のもの。翻訳物は(最近はマシですが)内容自体はよくても表現や文章が微妙なものがあります。

注意事項ですが、「入門書」というタイトルの書籍には、プログラミング初学者ではなく、他の言語を習得済みでその言語について初めて学ぶ人向けのもの(つまりプログラミング自体は知っていることが前提)が結構あるので、中身をよく確認して「プログラミング自体がはじめて」の人向けの書籍を選んでください

そうして、プログラミングにある程度慣れた当たりで、プログラミングの文法について解説している本を読みましょう。これも好みだとは思いますが、C#の場合、以下は個人的に必読だと思っています。

4.わからない部分はとりあえず飛ばす。

いわゆる文法書、文法講座を読みこなす場合は、絶対に最初のページから理解していかなければならないんだ!と思い込まずに、縦横無尽に飛ばしたり戻ったりを繰り返してみてください。特に、オブジェクト指向に関する部分などは、実際にコーディングしてはじめて理解できるものも多いです。

詰まってしまった場合、他の書籍やインターネットで調べても良く分からなければ、その部分はとりあえず飛ばして次に行ってしまうのが得策です。

後のページの解説を読んだら詰まっていた部分が解消したなんてこともよくありますし。これだけは確実に言えますが、あきらめさえしなければいつか絶対に理解できます

5.手を動かしながら勉強する。

ただ書籍を読むだけでは身につきません。現状の知識内で構わないので、実際にコードを書いてください。むしろ、コーディングをしながら本を読むくらいの態度が重要です。

6.それでもプログラミングがよく分からない場合(その1)

ここまでプログラミングは簡単だと言ってきましたが、やっぱり一筋縄でいかない部分もあります。私自身も、ある程度自由にプログラミングできるようになるまでに、何度か挫折を味わっています。例えば書籍では解説されずにいきなり出てきた専門用語(ハードやIT技術の前提知識)がわからずに詰まってしまうこともありました。そんなときにおすすめするのが↓です。プログラミング以前の基礎知識についての解説本で、初心者のころにかなりお世話になりました

 

7.それでもプログラミングがよく分からない場合(その2)

勉強に詰まってしまった場合、他のプログラミング言語に浮気するのもひとつの手だと思います。私は、”Java(挫折)→C(挫折)→VisualBasic(理解できた!)”という過程を経て再びC言語に戻りました。Javaはオブジェクト指向に挫折(解説本の説明が概念的なものに終始しており具体的なコードを書けなかった)、その次に選んだC言語では、コンソール上でのプログラミングはできましたが、ウィンドウアプリケーション(ウィンドウの表示)がよく分からず(WindowsAPIやMFC辺りまで知識が及びませんでした)挫折。どうしようもなくなってVisualBasic(VB)に手を出しました。

VBはデフォルトでウィンドウアプリケーションの開発が可能です(面倒なコーディング抜きでウィンドウを表示できます)。そんなわけでVBを使うことで現代的なウィンドウズアプリケーションを簡単に実装し、ゲームを制作することができるようになりました。肝心のゲームアルゴリズムに注力することができたのです。一度理解してしまえば、他の言語にも応用できるので、過去に挫折したC言語に戻ったわけです。

今の時代であれば、入門で利用する統合開発環境の多くがウィンドウアプリケーションに対応していると思いますので、私のような挫折はないかもしれません。

ただし、例えばC#がよく分からなければ、似たような仕様ながら簡素なJavaScriptに乗り換えてみることもありだと思いますし、例えばオブジェクト指向が難しければ手続き型言語であるC言語を勉強してみるのもいいかもしれません

8.とりあえず概要だけ知っておく。詳細は使うときに調べればいい。

勉強を進めていくと、コンストラクタ、キャスト、インターフェース、デリゲートなどなど、難しい単語がたくさんでてきます。解説を読んでとりあえずどういうものかはわかっても、実際どういう時に使うのかさっぱりわからないことが多々あると思います。そんなときは、とりあえずその言葉と概要だけ覚えておいてください。いずれその機能が必要なときがきたら、詳細について調べればいいんです。最初から何もかも覚えようとしないほうが勉強も捗るかと思います。

ちょっと脱線して具体的な話をしますが(言葉の意味は分からなくて大丈夫です)、C#にはデリゲートという機能があります。機能自体は理解しやすいのですが、実際にどんな場面で使うかまで想像することは難しいと思います。このデリゲート機能、Unityにおいて、スクリプトからゲームオブジェクトのコンポーネントにアクセスする場合に多用します。コンポーネントにアクセスしたければこう書くんだと覚えてしまってもいいのですが、デリゲートについての知識があれば応用もききますし実際の使用例にあたることで、自分でクラスを設計するときに利用することもできるようになります。つまり、とりあえずそういうものがあるということだけ知っておき、実際に使用する(出会った)時に詳細を調べることでマスターすることが可能になるというわけです

9.動けばいいんだくらいに思っておく。

プログラミングの学習を続けていると、アルゴリズムというものに行き着きます。アルゴリズムとは直訳で「解法」のことです。よく使われる処理について、こういう風にコーディングするべきだというお約束だと考えておいてください。ものによってはテクニカルなコーディングになるので、ぱっと見では何をやっているのかよくわからないこともあります。よく分からなければ飛ばしてしまいましょう。とある機能のための実装(=コーディング)は千差万別なのです。

とにかく、書籍やインターネットで「◯◯な機能を実装するために☓☓のようにコーディングする」というような解説があっても、絶対にそれに従わなければならないわけではありません。自分なりに設計して実装し、動けばいいんだくらいに思っておくと気楽な場合があるかもしれません

10 コピペからは早々に脱出する。

「最初のうちは、意味がわからなくても他人のソースコードをコピペして動けばいい」という意見をよく目にします。これについて反対するわけではありません。ただ、何をやっているのか理解する努力をしながらコピペするべきです。

現在、インターネット上には様々なソースコードが存在しています。正直、コピペしてしまえば何の苦労もなく動いてしまうのですが、これに慣れてしまうと自分の足を引っ張ることになります。応用がきかなくなってちょっとした機能の追加で詰まってしまったり、参考となるソースコードがないと何も作れないなんてことにもなりかねません。

汚くてもいいので、自分なりに設計(その機能のためにどういう風にプログラムを組むか考えること)し実装(設計に合わせてコードを書く)していく作業に、できるだけ早い段階から慣れていってください

※ちなみにですが、コピペについては著作権に注意してください。基本的に、講座やTipsとして公開しているソースコードはOKのはずです(NGだと意味がないので)。

11.目的を見誤らない。

あくまで「ゲームを作る」ことが目的であることを忘れないで下さい。たとえ難しいアルゴリズムを取り入れようと、テクニカルなコーディングにこだわろうと、車輪の再発明(すでに組み込まれている処理をわざわざ書く)をしようと、同じように動くのであればユーザには分かりません。むしろ、ゲームデザインやテストのほうに時間をかけるべきです。※ただし、綺麗な設計、綺麗な実装は、今後のメンテナンスに有用です。

もちろん、プログラミング自体が目的だというのは悪いことではありませんし、そういう方たちの日々の研究のおかげで今の技術があります。

 

さて、ちょっと脱線した部分や相反する部分もありますが、とりあえずこんなところで切り上げたいと思います。

別の機会に、オブジェクト指向やゲームプログラミングの具体的な解説もしたいなあと思っています。

それでは。
コンピュータゲームの仕組み : オブジェクト指向について>

コンピュータゲームの仕組み

どうも、solaです。

今回はコンピュータゲームの仕組みについてのお話です。

■コンピュータゲームの定義

まずはさらっと、個人的コンピュータゲームの定義をしてみます。

1.コンピュータ上で動くこと

コンピュータゲームとは、パソコン・アーケード機・コンシューマ機といった各種コンピュータ上で実行するように設計・実装されたゲームソフト=プログラムを指します。

そして、ゲームソフトを設計・実装するのは人間であり、その作業をプログラミングと呼びます。(本来的にはプログラミングは実装(コーディング)を指します。ですが、ここでは個人制作をターゲットとしているので、設計もプログラミングに含めています)

例えば、RPGツクールや吉里吉里などを利用すれば、プログラミングをせずにゲームを作ることも可能だと思われますが、実はそれらも面倒な作業の大部分がカバーされているだけであって、プログラミング的な考え方=論理的思考はコンピュータゲームを作る上で必須です。

2.インタラクティブであること

インタラクティブとはユーザーの操作とソフト側の処理が対話形式で進んでいくもので、双方向性とか、対話性とも呼ばれます。もちろん、コンピュータゲームに限ったものではありません。

コンピュータゲームにおけるインタラクティブ性とは、ユーザの操作によってゲーム(ゲームの進行や結果)に変化が起こることを指します。

例えば、十字キーの右を押すとキャラクターが右に移動するとか、NPCの前でボタンを押したら会話がはじまるとか。それから、画面上を勝手に動き回る敵キャラクターも「ゲームをスタートした」というユーザの操作の結果起こった変化です。

ユーザが操作してもゲーム画面に変化が起こらない、または操作が一切介在ないものはゲームではなく、映像作品や音楽といった別の創作物だと言えます。※例外的に、スタート後は勝手にゲームが進んでいきユーザは何もせず画面を眺めているだけというモノもあることにはあります。

3.ゲーム性があること

十字キーの操作でキャラクターが上下左右に移動するだけではゲームとは呼べません。ゲームとは「遊び」でありエンターテインメントです。つまり、人の心を動かし、夢中にさせる仕組みが必要です。

キャラクターを操作して敵を避けるとか、戦闘を行って成長させより強い敵キャラクターを倒していくとか、謎をときながらストーリーを進めていくとか。そういったエンターテインメントを仕込んでいくことがゲーム作りであり、その作業をゲームデザインと呼びます(もっといろいろと含みますが)。そして、ゲームデザインによるゲームの分類が、アクション、RPG、シミュレーションといったジャンルを生み出します。

ゲーム制作において、このゲームデザインが最も重要な要素となります

■ゲームプログラムの仕組み-fpsとは何か-

特に格闘ゲームやシューティングゲームが好きな方であれば、60fpsとか30fpsという言葉を聴いたことがあるのではないでしょうか。

fps(frame per second)とは、「一秒間あたりのフレーム数」を指します。60fpsなら一秒間に60フレーム、30fpsなら30フレームというわけです。

じゃあフレームってなんだよって話です。

例として「2DRPG風に十字キーの操作でプレイヤーキャラクターを動かす」ことを考えてみます。処理の概要は「十字キーの入力情報を取得」→「入力情報の方向に座標を動かす」→「その座標にプレイヤーキャラクターを表示する」という3つに別れ、その3つの処理をひとまとめにしたものをフレームと呼びます。設計によって千差万別ですが、1フレームの詳細は、例えば↓のような感じになります。

1フレーム

・ユーザによる十字キーの入力情報を取得する(入力がない場合は「入力情報がない」という情報になる)
・入力情報の方向に単位移動量分だけプレイヤーキャラクターの座標を動かす
・プレイヤーキャラクターの座標にプレイヤーキャラクターの画像を表示する。

ちなみに、単位移動量というのは、一回の入力で動く距離だと考えてください。2Dのようなドット単位の場合、1ドットだと滑らかに動きますが1フレームで1ドットしか動かないのでもっさりとします。16ドットだとスッキリと動きますが、16ドットごとにワープすることになります(人間の目にはちゃんと動いているように見えます)。

上記のフレームを何度も繰り返すことで、キャラクターが移動(もちろん操作がなければ止まります)するように見せるわけです。そして、このフレームを一秒間に60回ループさせれば60fps、30回なら30fpsになります。

ところで、上記程度の処理であれば数万fps以上とかで処理することが可能です(あくまで比喩です。多分もっと多いですし、環境によって変わります)。

でもそれでは困ります。なぜなら、fpsが増えるということはそれだけゲーム速度が早くなってしまうからです。早すぎて人間の目に止まらないというのはもちろんですが、例えばレースゲームのようなタイムを競うゲームにおいてユーザの環境ごとに操作感や速度が変わればタイムに影響します。そんなわけで「◯秒ごとにフレームを処理する」という風に制限をかけるわけです。それを固定fpsと呼び、60fpsであれば約0.017秒内で1フレームを処理します。

ゲームの機能が増えればそれだけフレーム内の処理も増えていきます。例えば「一歩動くたびに敵が出現するかどうか判定する」「現在立っているマップチップの情報を取得し毒の沼地ならHPを減らす」などです。本当は60fpsで動かしたかったのに、処理が多すぎるために1フレームを0.017秒で処理できなくなる場合には30fpsにfpsを落としたりします。最近のゲームに30fpsが多いのは高度な3D機能の処理の重さが原因でしょう。ちなみにファミコンなどで敵キャラがたくさん出てきた時に画面がちらついたり重くなったりするのもこれが原因です。処理が増えることで、フレームを実行する時間が増えてしまうのです。

ゲームプログラミングの手法(パラダイム)や2D/3Dの差こそあれ、ゲームプログラミングの基本は上記のようなもので変わりません(※あくまで概念レベルでは)。

簡単にまとめると、コンピュータゲームとは「フレーム内の処理を繰り返し実行し続ける」ものであり、ゲームプログラミングとはそのループする各処理を実装していくことになります。この概念はかなり重要で、この辺りの理解不足でつまずく人をそれなりに見ています。

老婆心ながら補足ですが、操作を一切しない場合でもフレームの繰り返し(ループ)は常になされています。原則としてゲームプログラムを終了するまで止まることはありません。

 

あくまで概念的な話なので正確でない部分もありますが、とにかくわかりやすさ優先で書いてみました。ひとつのループ(メインループとかゲームループとか呼びます)に実直にすべての処理をコーディングしていく設計思想は現在では古いものだということにご注意ください。

実際のハード(CPUやメモリ、入出力装置など)やソフト(プログラミングの文法、オブジェクト指向など)的な面からのゲーム制作についてはまた別の機会ということで。

それでは。

< はじめに : ものぐさ文系脳のためのプログラミング勉強法>

はじめに:ゲーム制作Tips




どうも、solaです。スマートフォン向けゲームアプリの個人デベロッパーやってます。
現在はストーリー重視のアドベンチャーゲームをいくつかリリースしています。ぜひ『アプリ一覧』をご覧ください!

さて、私がゲーム制作に興味を持ったのは学生時代、自分専用のPCを買ってもらってからでした。
マリオ64、時のオカリナ、FFやICOといった3Dゲームが好きだったので、そういったものを作りたかったのですが、右も左も分かりません。とある掲示板で「3Dゲームの作り方を教えてください!」という無謀かつ具体性のない質問を繰り出して叩かれたのもいい思い出です。

そんなド素人な自分でも、書籍やインターネットの情報にあたりつつ、なんとか独学でゲームを制作、公開できるようになりました。

特にインターネット上の情報は鮮度も良く、かなり助けられました。
そんなわけで自分もいつか、ゲーム制作関連の情報提供を行いたいなあと常日頃から思ってはいました。
当サイトにも、『Unity Tips』というメニューだけは用意していたのですが、更新には至りませんでした。インターネット上にはUnity(やC#)についての有用で詳細なハウツー、チュートリアルがすでに数多く存在しているからです。中途半端な技術しか持たない自分が情報を発信したところで、ただの焼き直し・引用になってしまうと思ったのです。

というわけで、ちょっと毛色を変えて『ゲーム制作Tips』という形で、ゲーム制作に関連する創作全体について、コラムのようなものを発信しようと思います。

ゲーム制作は様々な創作物の集合体です。システム(ゲームアイデア)、プログラミング、シナリオ、絵素材、サウンド……ぼっちなので、個人でゲームを開発するためにいろいろなものに手を出してきました。
良い言い方をすれば「何でも屋」、悪い言い方をすれば「器用貧乏」。特化型ではなく汎用型みたいな感じです。

まあ、とにかくそういった創作関連の情報をカテゴリに分けて発信していきます。

また、コラムとは別に、それなりの規模のゲームをゼロから作っていく過程を連載することもおぼろげに考えています。

兎にも角にも、
・ゲームを創ってみたいけれど、どうしたら良いかわからない。
・ググってみたけれどなんだか難しいことばかり書いてある。
……みたいな、主に一人でゲームを作ってみたい初心者向けに記事を発信していきたいと思います。

まったりと更新していきますので、お楽しみいただければ幸いです。

それでは。

>コンピュータゲームの仕組み