Wikibooks jawikibooks https://ja.wikibooks.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 MediaWiki 1.39.0-wmf.25 first-letter メディア 特別 トーク 利用者 利用者・トーク Wikibooks Wikibooks・トーク ファイル ファイル・トーク MediaWiki MediaWiki・トーク テンプレート テンプレート・トーク ヘルプ ヘルプ・トーク カテゴリ カテゴリ・トーク Transwiki Transwiki‐ノート TimedText TimedText talk モジュール モジュール・トーク Gadget Gadget talk Gadget definition Gadget definition talk 0 3121 206842 206117 2022-08-20T08:53:35Z 49.96.244.108 wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 名古屋大学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難～超難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名大法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名大物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名大に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名大物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] qk7b410qtcrpjjhp952laxs5rxzsi3u 206843 206842 2022-08-20T08:54:28Z 49.96.244.108 wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 名古屋大学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名古屋大学対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難～超難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名大法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名大物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名大に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名大物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] e5uklhzweb7cbgebmdb4ewlq1zk4s3k 206844 206843 2022-08-20T08:56:31Z 49.96.244.108 wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 名古屋大学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名古屋大学対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大学受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難～超難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名大法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名大物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名大に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名大物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] q4heywp0rdaszlwsr1ac5nmts72ha08 206845 206844 2022-08-20T08:59:04Z 49.96.244.108 wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 名古屋大学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名古屋大学対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大学受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難～超難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名古屋大学法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名大物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名大に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名大物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] e8uxp0a4mm7f33rv8uqdoqat6eubvz5 206846 206845 2022-08-20T09:01:54Z 49.96.244.108 wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 名古屋大学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名古屋大学対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大学受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難～超難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名古屋大学法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名古屋大学物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名古屋大学に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名古屋大学物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] 0ea9jdbt66ua8d99xyzxiyatxvgoiwa 206847 206846 2022-08-20T09:02:44Z 49.96.244.108 wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 名古屋大学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名古屋大学対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大学受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難～超難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名古屋大学法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名古屋大学物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名古屋大学に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名古屋大学物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名古屋大学化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] 9n4s478ty8tu5c3sjeam24kxi4g9ecd 0 4591 206820 174131 2022-08-19T22:28:36Z Rhkmk 66092 /* 判 例 */ wikitext text/x-wiki [[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第3編 債権 (コンメンタール民法)]] ==条文== （権利移転の対抗要件に係る売主の義務） ;第560条 :売主は、買主に対し、登記、登録その他の売買の目的である権利の移転についての対抗要件を備えさせる義務を負う。 ===改正経緯=== 2017年改正により、売買契約に基づいて売主が負う基本的な義務のひとつを明記。 他人物売買に関する以下の一連の条項について、基本的な規律を維持しつつ[[民法第561条|第561条]]（他人の権利の売買における売主の義務）に集約し、個別の事項については、広範に認められるようになった「解除権」の行使などによることとした。 [[民法第561条/他人物売買|他人物売買]] *本条（他人の権利の売買における売主の義務） *:''他人の権利を売買の目的としたときは、売主は、その権利を取得して買主に移転する義務を負う。'' *[[民法第561条#改正経緯|第561条]]（他人の権利の売買における売主の担保責任） *[[民法第562条#改正経緯|第562条]]（他人の権利の売買における善意の売主の解除権） *[[民法第563条#改正経緯|第563条]]（権利の一部が他人に属する場合における売主の担保責任） *[[民法第564条#改正経緯|第564条]]（権利の一部が他人に属する場合における売主の担保責任） ==解説== ==参照条文== ==判例== ---- {{前後 |[[コンメンタール民法|民法]] |[[第3編 債権 (コンメンタール民法)|第3編 債権]]<br> [[第3編 債権 (コンメンタール民法)#2|第2章 契約]]<br> [[第3編 債権 (コンメンタール民法)#2-3|第3節 売買]] |[[民法第559条]]<br>（有償契約への準用） |[[民法第561条]]<br>（他人の権利の売買における売主の義務） }} {{stub}} [[category:民法|560]] [[category:民法 2017年改正|560]] lckka0ljr6azog6f107wrde1sxv2gfx 0 5668 206821 197586 2022-08-19T22:32:52Z Rhkmk 66092 wikitext text/x-wiki [[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第3編 債権 (コンメンタール民法)]] ==条文== （買主の代金減額請求権） ;第563条 # [[民法第562条|前条]]第1項本文に規定する場合において、買主が相当の期間を定めて履行の追完の催告をし、その期間内に履行の追完がないときは、買主は、その不適合の程度に応じて代金の減額を請求することができる。 # 前項の規定にかかわらず、次に掲げる場合には、買主は、同項の催告をすることなく、直ちに代金の減額を請求することができる。 #:一　履行の追完が不能であるとき。 #:二　売主が履行の追完を拒絶する意思を明確に表示したとき。 #:三　契約の性質又は当事者の意思表示により、特定の日時又は一定の期間内に履行をしなければ契約をした目的を達することができない場合において、売主が履行の追完をしないでその時期を経過したとき。 #:四　前三号に掲げる場合のほか、買主が前項の催告をしても履行の追完を受ける見込みがないことが明らかであるとき。 # 第1項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、前二項の規定による代金の減額の請求をすることができない。 ===改正経緯=== 2017年改正により、目的物が契約の趣旨に適合しない場合における買主の代金減額請求権について新設。 改正前は、「権利の一部が他人に属する場合における売主の担保責任権」について定めていたが、他人物売買に関する以下の一連の条項について、基本的な規律を維持しつつ[[民法第561条|第561条]]（他人の権利の売買における売主の義務）に集約し、個別の事項については、広範に認められるようになった「解除権」の行使などによることとした。 [[民法第561条/他人物売買|他人物売買]] *[[民法第560条#改正経緯|第560条]]（他人の権利の売買における売主の義務） *[[民法第561条#改正経緯|第561条]]（他人の権利の売買における売主の担保責任） *[[民法第562条#改正経緯|第562条]]（他人の権利の売買における善意の売主の解除権） *本条（権利の一部が他人に属する場合における売主の担保責任） *#''売買の目的である権利の一部が他人に属することにより、売主がこれを買主に移転することができないときは、買主は、その不足する部分の割合に応じて代金の減額を請求することができる。'' *#''前項の場合において、残存する部分のみであれば買主がこれを買い受けなかったときは、善意の買主は、契約の解除をすることができる。'' *#''代金減額の請求又は契約の解除は、善意の買主が損害賠償の請求をすることを妨げない。'' *[[民法第564条#改正経緯|第564条]]（権利の一部が他人に属する場合における売主の担保責任） ==解説== ==参照条文== ---- {{前後 |[[コンメンタール民法|民法]] |[[第3編 債権 (コンメンタール民法)|第3編 債権]]<br> [[第3編 債権 (コンメンタール民法)#2|第2章 契約]]<br> [[第3編 債権 (コンメンタール民法)#2-3|第3節 売買]] |[[民法第562条]]<br>（買主の追完請求権） |[[民法第564条]]<br>（買主の損害賠償請求及び解除権の行使） }} {{stub}} [[category:民法|563]] [[category:民法 2017年改正|563]] 6mhle09sh40dzc6it5cvp0ldei8yprk 0 7462 206840 146216 2022-08-20T06:37:04Z 126.194.218.123 wikitext text/x-wiki [[File:The 19th Yokozuna Hitachiyama Taniemon 02.jpg|The 19th Yokozuna Hitachiyama Taniemon 02.jpg|300px]] 料理にはたくさんの　思い出がある あの子にはいくつもの　思い出がある アズキマロン　茶太郎に　テレビを見ながら サクラさん　その母も　たまには♪いいよ こわがれ！こわがれ！こわがりヒーロー かぞくだんらん　しょくじちゅう とつぜん　じしんが　やってきた グラグラ　ガタガタ　してるのに だいじょうぶ　そのうち　おさまると み～んな　ちっとも　うごかない こわいよ　こわいよ　ぼくこわい！ これが　おおきな　さいがいの はじまり　なのかもしれないよ だったら　こうかいしたくない ぼくが　みんなを　まもるんだ！！ 「あたまを　まもって！」 「あぶないものから　はなれて！」 「にげるときは　ブレーカーをおとす！」 「みんな　ひなんのじゅんびを　しようー！」 ぼくが　こわがることで みんなの　きもちが　うごく かぞくの　いのちを　すくうんだ！ こわがれ！こわがれ！こわがりヒーロー テレビニュースで　けいほうちゅう たいふう　おおあめ　ふりそうだ ゴーゴー　ジャブジャブ　なるってさ なのに　ここまで　こないよと み～んな　ちっとも　うごかない こわいよ　こわいよ　わたしこわい！ これが　おおきな　さいがいの はじまり　なのかもしれないよ だったら　こうかいしたくない わたしが　みんなを　まもるんだ！ 「あるけるか　そとを　かくにん！」 「あんぜんな　ばしょにいこう！」 「となりの　おばあちゃんに　こえをかけよう！」 「いますぐ　みんなで　にげようー！」 わたしが　こわがることで みんなの　きもちが　うごく おおくの　いのちを　すくうんだ こわがれ！こわがれ！こわがりヒーロー おおげさだって　わらわれたって なんどでも　なんどでも　こわがるよ とめられない　きょうだいな　しぜんのいりょくを ぼくらが　こわがることで おとなの　きもちを　うごかす みんなで　いっしょに　たすかろう！ こわがれ！こわがれ！こわがりヒーロー あの頃を振りかえる　博物館で ワルモノに向かった　3人で アユコムギ　フキノスケ　テレビを見ながら 彼彼女　強いかな　強いか3人よ == メインモジュール == {{進捗状況}} {{ウィキジュニアの蔵書一覧}} [[Image:Da Vinci Vitruve Luc Viatour.jpg|200px]] # [[/タイトルページ|タイトルページ]] # [[/著作権について|著作権について]]（ちょさくけんについて） {{進捗|100%|2013-10-07}} # [[/はじめに|はじめに]] {{進捗|100%|2013-10-07}} # [[/胃|胃]]（い） # [[/筋肉|筋肉]]（きんにく） # [[/口|口]]（くち） # [[/血液|血液]]（けつえき） # [[/十二指腸|十二指腸]]（じゅうにしちょう） # [[/神経|神経]]（しんけい） # [[/心臓|心臓]]（しんぞう） # [[/大腸|大腸]]（だいちょう） # [[/手|手]]（て） # [[/脳|脳]]（のう） # [[/肺|肺]] （はい）{{進捗|25%|2013-10-07}} # [[/鼻|鼻]] （はな）{{進捗|25%|2007-12-13}} # [[/皮膚|皮膚]]（ひふ） # [[/骨|骨]]（ほね） # [[/耳|耳]] （みみ）{{進捗|25%|2007-12-13}} # [[/目|目]] （め）{{進捗|50%|2013-10-07}} # [[/生殖器官|生殖器官]] (せいしょくきかん) # [[/用語集|用語集]]（ようごしゅう） == 主な質問 == == 役に立つリンク集 == * * [[Category:人間の体 (ウィキジュニア)|*]] [[Category:ウィキジュニア|にんけんのからた]] [[Category:生物学 (ウィキジュニア・ジャンル)|にんけんのからた]] [[en:Wikijunior:Human Body]] [[nl:Wikijunior:Het lichaam]] 1ye2ppfczdefyh1j1x3vtozws86k40j 206841 206840 2022-08-20T06:39:15Z 20041027 tatsu 43944 [[Special:Contributions/126.194.218.123|126.194.218.123]] ([[User talk:126.194.218.123|会話]]) による編集を取り消し、令和少年 による直前の版へ差し戻す wikitext text/x-wiki {{ウィキジュニアのスタブ}} {{wikipedia|人体|人間の体}} {{pathnav|Wikijunior:メインページ}} == メインモジュール == {{進捗状況}} {{ウィキジュニアの蔵書一覧}} [[Image:Da Vinci Vitruve Luc Viatour.jpg|200px]] # [[/タイトルページ|タイトルページ]] # [[/著作権について|著作権について]]（ちょさくけんについて） {{進捗|100%|2013-10-07}} # [[/はじめに|はじめに]] {{進捗|100%|2013-10-07}} # [[/胃|胃]]（い） # [[/筋肉|筋肉]]（きんにく） # [[/口|口]]（くち） # [[/血液|血液]]（けつえき） # [[/十二指腸|十二指腸]]（じゅうにしちょう） # [[/神経|神経]]（しんけい） # [[/心臓|心臓]]（しんぞう） # [[/大腸|大腸]]（だいちょう） # [[/手|手]]（て） # [[/脳|脳]]（のう） # [[/肺|肺]] （はい）{{進捗|25%|2013-10-07}} # [[/鼻|鼻]] （はな）{{進捗|25%|2007-12-13}} # [[/皮膚|皮膚]]（ひふ） # [[/骨|骨]]（ほね） # [[/耳|耳]] （みみ）{{進捗|25%|2007-12-13}} # [[/目|目]] （め）{{進捗|50%|2013-10-07}} # [[/生殖器官|生殖器官]] (せいしょくきかん) # [[/用語集|用語集]]（ようごしゅう） == 主な質問 == == 役に立つリンク集 == * * [[Category:人間の体 (ウィキジュニア)|*]] [[Category:ウィキジュニア|にんけんのからた]] [[Category:生物学 (ウィキジュニア・ジャンル)|にんけんのからた]] [[en:Wikijunior:Human Body]] [[nl:Wikijunior:Het lichaam]] i2ag89uqmzivlagwm89nxy0vtnfyn11 0 11664 206824 203017 2022-08-19T23:17:59Z Rhkmk 66092 /* 参照条文 */ wikitext text/x-wiki [[法学]]＞[[コンメンタール行政手続法]] ==条文== （[[w:聴聞]]の主宰） ;第19条 # 聴聞は、行政庁が指名する職員その他政令で定める者が主宰する。 # 次の各号のいずれかに該当する者は、聴聞を主宰することができない。 #:一　当該聴聞の当事者又は参加人 #:二　前号に規定する者の配偶者、四親等内の親族又は同居の親族 #:三　第一号に規定する者の代理人又は[[行政手続法第20条|次条]]第3項に規定する補佐人 #:四　前三号に規定する者であったことのある者 #:五　第一号に規定する者の後見人、後見監督人、保佐人、保佐監督人、補助人又は補助監督人 #:六　参加人以外の関係人 ==解説== ==参照条文== :[[行政手続法第17条|第17条]](参加人) 関係人　当事者以外の者であって当該不利益処分の根拠となる法令に照らし当該不利益処分につき利害関係を有するものと認められる者 ==判例== ---- {{前後 |[[コンメンタール行政手続法|行政手続法]] |[[コンメンタール行政手続法#3|第3章 不利益処分]]<br> [[コンメンタール行政手続法#3-2|第2節 聴聞]] |[[行政手続法第18条|第18条]]<br>（文書等の閲覧） |[[行政手続法第20条|第20条]]<br>（聴聞の期日における審理の方式） }} {{stub}} [[category:行政手続法|19]] ozeow9z7kgcf92ik8n4ydyskpfw5alv 206826 206824 2022-08-19T23:20:29Z Rhkmk 66092 /* 参照条文 */ wikitext text/x-wiki [[法学]]＞[[コンメンタール行政手続法]] ==条文== （[[w:聴聞]]の主宰） ;第19条 # 聴聞は、行政庁が指名する職員その他政令で定める者が主宰する。 # 次の各号のいずれかに該当する者は、聴聞を主宰することができない。 #:一　当該聴聞の当事者又は参加人 #:二　前号に規定する者の配偶者、四親等内の親族又は同居の親族 #:三　第一号に規定する者の代理人又は[[行政手続法第20条|次条]]第3項に規定する補佐人 #:四　前三号に規定する者であったことのある者 #:五　第一号に規定する者の後見人、後見監督人、保佐人、保佐監督人、補助人又は補助監督人 #:六　参加人以外の関係人 ==解説== ==参照条文== ;[[行政手続法第17条|第17条]](参加人) 関係人　当事者以外の者であって当該不利益処分の根拠となる法令に照らし当該不利益処分につき利害関係を有するものと認められる者 ==判例== ---- {{前後 |[[コンメンタール行政手続法|行政手続法]] |[[コンメンタール行政手続法#3|第3章 不利益処分]]<br> [[コンメンタール行政手続法#3-2|第2節 聴聞]] |[[行政手続法第18条|第18条]]<br>（文書等の閲覧） |[[行政手続法第20条|第20条]]<br>（聴聞の期日における審理の方式） }} {{stub}} [[category:行政手続法|19]] 89vzv3dcbhzjtvlnw0wb0pjmrrekie4 0 11705 206825 203016 2022-08-19T23:19:52Z Rhkmk 66092 wikitext text/x-wiki [[法学]]＞[[コンメンタール行政手続法]] ==条文== （聴聞調書及び報告書） ;第24条 # 主宰者は、聴聞の審理の経過を記載した調書を作成し、当該調書において、不利益処分の原因となる事実に対する当事者及び参加人の陳述の要旨を明らかにしておかなければならない。 # 前項の調書は、聴聞の期日における審理が行われた場合には各期日ごとに、当該審理が行われなかった場合には聴聞の終結後速やかに作成しなければならない。 # 主宰者は、聴聞の終結後速やかに、不利益処分の原因となる事実に対する当事者等の主張に理由があるかどうかについての意見を記載した報告書を作成し、第1項の調書とともに行政庁に提出しなければならない。 # 当事者又は参加人は、第1項の調書及び前項の報告書の閲覧を求めることができる。 ==解説== ==参照条文== :[[行政手続法第18条|第18条]](文書等の閲覧) 当事者等　当事者及び当該不利益処分がされた場合に自己の利益を害されることとなる参加人 ==判例== ---- {{前後 |[[コンメンタール行政手続法|行政手続法]] |[[コンメンタール行政手続法#3|第3章 不利益処分]]<br> [[コンメンタール行政手続法#3-2|第2節 聴聞]] |[[行政手続法第23条|第23条]]<br>（当事者の不出頭等の場合における聴聞の終結） |[[行政手続法第25条|第25条]]<br>（聴聞の再開） }} {{stub}} [[category:行政手続法|24]] f9zahf9s6e9cl1iq3t3zhunx0iofxf4 0 11726 206827 193446 2022-08-19T23:23:27Z Rhkmk 66092 /* 参照条文 */ wikitext text/x-wiki [[法学]]＞[[コンメンタール行政手続法]] ==条文== （適用除外） ;第3条 # 次に掲げる処分及び行政指導については、[[コンメンタール行政手続法#2|次章]]から[[コンメンタール行政手続法#4の2|第4章の2]]までの規定は、適用しない。 #:一　国会の両院若しくは一院又は議会の議決によってされる処分 #:二　裁判所若しくは裁判官の裁判により、又は裁判の執行としてされる処分 #:三　国会の両院若しくは一院若しくは議会の議決を経て、又はこれらの同意若しくは承認を得た上でされるべきものとされている処分 #:四　検査官会議で決すべきものとされている処分及び会計検査の際にされる行政指導 #:五　刑事事件に関する法令に基づいて検察官、検察事務官又は司法警察職員がする処分及び行政指導 #:六　国税又は地方税の犯則事件に関する法令（他の法令において準用する場合を含む。）に基づいて国税庁長官、国税局長、税務署長、国税庁、国税局若しくは税務署の当該職員、税関長、税関職員又は徴税吏員（他の法令の規定に基づいてこれらの職員の職務を行う者を含む。）がする処分及び行政指導並びに金融商品取引の犯則事件に関する法令（他の法令において準用する場合を含む。）に基づいて証券取引等監視委員会、その職員（当該法令においてその職員とみなされる者を含む。）、財務局長又は財務支局長がする処分及び行政指導 #:七　学校、講習所、訓練所又は研修所において、教育、講習、訓練又は研修の目的を達成するために、学生、生徒、児童若しくは幼児若しくはこれらの保護者、講習生、訓練生又は研修生に対してされる処分及び行政指導 #:八　刑務所、少年刑務所、拘置所、留置施設、海上保安留置施設、少年院、少年鑑別所又は婦人補導院において、収容の目的を達成するためにされる処分及び行政指導 #:九　公務員（国家公務員法 （昭和22年法律第120号）第2条第1項 に規定する国家公務員及び地方公務員法 （昭和25年法律第261号）第3条第1項 に規定する地方公務員をいう。以下同じ。）又は公務員であった者に対してその職務又は身分に関してされる処分及び行政指導 #:十　外国人の出入国、難民の認定又は帰化に関する処分及び行政指導 #:十一　専ら人の学識技能に関する試験又は検定の結果についての処分 #:十二　相反する利害を有する者の間の利害の調整を目的として法令の規定に基づいてされる裁定その他の処分（その双方を名あて人とするものに限る。）及び行政指導 #:十三　公衆衛生、環境保全、防疫、保安その他の公益にかかわる事象が発生し又は発生する可能性のある現場において警察官若しくは海上保安官又はこれらの公益を確保するために行使すべき権限を法律上直接に与えられたその他の職員によってされる処分及び行政指導 #:十四　報告又は物件の提出を命ずる処分その他その職務の遂行上必要な情報の収集を直接の目的としてされる処分及び行政指導 #:十五　審査請求、再調査の請求その他の不服申立てに対する行政庁の裁決、決定その他の処分 #:十六　前号に規定する処分の手続又は[[コンメンタール行政手続法#3|第3章]]に規定する聴聞若しくは弁明の機会の付与の手続その他の意見陳述のための手続において法令に基づいてされる処分及び行政指導 # 次に掲げる命令等を定める行為については、[[コンメンタール行政手続法#6|第6章]]の規定は、適用しない。 #:一　法律の施行期日について定める政令 #:二　恩赦に関する命令 #:三　命令又は規則を定める行為が処分に該当する場合における当該命令又は規則 #:四　法律の規定に基づき施設、区間、地域その他これらに類するものを指定する命令又は規則 #:五　公務員の給与、勤務時間その他の勤務条件について定める命令等 #:六　審査基準、処分基準又は行政指導指針であって、法令の規定により若しくは慣行として、又は命令等を定める機関の判断により公にされるもの以外のもの # 第1項各号及び前項各号に掲げるもののほか、地方公共団体の機関がする処分（その根拠となる規定が条例又は規則に置かれているものに限る。）及び行政指導、地方公共団体の機関に対する届出（[[行政手続法第2条|前条]]第七号の通知の根拠となる規定が条例又は規則に置かれているものに限る。）並びに地方公共団体の機関が命令等を定める行為については、次章から第6章までの規定は、適用しない。 ==解説== 平成29年法律第4号による改正により、「収税官吏」を「国税庁、国税局若しくは税務署の当該職員」に改めた。 *第二章 申請に対する処分 *第三章 不利益処分 *第四章 行政指導 *第五章 届出 *第六章 意見公募手続等 ==参照条文== ;[[行政手続法第2条|第2条]](定義) 「命令」　法律に基づく命令（処分の要件を定める告示を含む。） ==判例== ---- {{前後 |[[コンメンタール行政手続法|行政手続法]] |[[コンメンタール行政手続法#1|第1章 総則]]<br> |[[行政手続法第2条|第2条]]<br>（定義） |[[行政手続法第4条|第4条]]<br>（国の機関等に対する処分等の適用除外） }} {{stub}} [[category:行政手続法|3]] t2ptvvtdmgtgf2yztf0pdakiilmbe8b 0 12192 206823 53689 2022-08-19T22:58:09Z Rhkmk 66092 wikitext text/x-wiki [[法学]]＞[[コンメンタール行政手続法]] ==条文== （地方公共団体の措置） ;第46条 : 地方公共団体は、[[行政手続法第3条|第3条]]第3項において第2章から前章までの規定を適用しないこととされた処分、行政指導及び届出並びに命令等を定める行為に関する手続について、この法律の規定の趣旨にのっとり、行政運営における公正の確保と透明性の向上を図るため必要な措置を講ずるよう努めなければならない。 ==解説== ==参照条文== ;[[行政手続法第1条|第1条]] 透明性　行政上の意思決定について、その内容及び過程が国民にとって明らかであること ==判例== ---- {{前後 |[[コンメンタール行政手続法|行政手続法]] |[[コンメンタール行政手続法#7|第7章 補則]]<br> |[[行政手続法第45条|第45条]]<br>（公示の方法） | }} {{stub}} [[category:行政手続法|46]] 2514ypquiuq41440ud9si093kx7mxpq 0 21950 206839 203418 2022-08-20T04:04:31Z すじにくシチュー 12058 /* 数字 */ 「40」のfortyは つづり に注意。「14」fourteen に引きづられてか、つづりを間違える例がある。 wikitext text/x-wiki {{Pathnav|Main Page|小学校・中学校・高等学校の学習|中学校の学習|中学校英語|中学校英語/1年}} [[{{PAGENAME}}]]では、学年の英語について教授します。[[中学校英語/1年]]及び[[中学校英語/1年/文法]]も必要に合わせて一緒にお読みください。本ページでは熟語・連語も含みます。 {{発音}} == 基本的な単語 == === 基本的な単語 === {{Wordヘッダ}} {{Word|apple|名詞|リンゴ|'''ア'''ポゥ}} {{Word|boy|名詞|少年|'''ボ'''ーイ}} {{Word|girl|名詞|少女|'''ガ'''ール}} {{Word|cat|名詞|猫|'''キャ'''ッ<u>ト</u>}} {{Word|dog|名詞|犬|'''ド'''ッ<u>グ</u>}} {{Word|egg|名詞|卵|'''エ'''ッグ}} {{Word|fish|名詞|魚|'''フィ'''ッシ<u>ュ</u>}} {{Word|1=father|3=父親|2=名詞|4=fáːðər}} {{Word|1=mother|3=母親|2=名詞|4=mʌ́ðər}} {{Word|family|名詞|家族|'''ファ'''ミリ<small>ィ</small>}} {{Word|house|名詞|家|'''ハ'''ウス}} {{Word|3=名前|2=名詞|1=name|4='''ネ'''ィ<u>ム</u>}} {{Word|milk|名詞|牛乳(単独では)・soy milk などになると「乳」だけの意味になる|mɪɫk}} {{Word|3=窓|1=window|2=名詞|4=wɪn.dəʊ}} {{Word|3=腕時計|1=watch|2=名詞|4=watʄ}} {{Word|3=動物園|1=zoo|2=名詞|4=zuː}} |} === 食事 === {{Wordヘッダ}} {{Word|3=昼食|1=lunch|2=名詞|4=ɭʌntʃ}} {{Word|3=食事に使う机・居間に置いてあるもの|1=table|2=名詞|4='''テ'''イブォ|5={{Ruby|学習机|がくしゅうづくえ}}や仕事用の{{Ruby|机|つくえ}}などの食べ物を食べる場所ではない机は{{Ruby|desk|デスク}}という単語であってtableではない。}} {{Word|cup|名詞|飲み物を入れる容器・コップ|kʌp}} {{Word|food|名詞|食べ物・食物|fuːd}} {{Word|3=魚|1=fish|2=名詞|4=fiʃ}} {{Word|3=米、炊飯|1=rice|2=名詞|4=rais}} {{Word|3=パン|1=bread|2=名詞|4=bréd}} {{Word|curry and rice|名詞|カレーライス|名詞|'''カ'''ゥリィアン<u>ド</u>ライス}} {{Word|3=牛乳|1=milk|2=名詞|4=milk}} {{Word|3=水|1=water|2=名詞|4=wɔ́ːtər}} {{Word|3=茶|1=tea|2=名詞|4=ティー|5=英語で「tea」と言ったら、ふつうは、紅茶（こうちゃ）のことになる。もし、緑茶（りょくちゃ）のことを言いたい場合、「 Japanese tea 」などと言う。}} {{Word|coffee|名詞|コーヒー|kɔ́ːfi}} {{Word|3=ジュース|1=juice|2=名詞|4=dʒuːs}} {{Word|1=orange juice|2=名詞|3=オレンジジュース}} |} === 一日 === :朝 morning（モーニング） :ベッド bed （ベッド） :今朝（けさ、※ 今日の朝） this morning （ディス モーニング） :起きる get up （ゲットアップ） :起きる wake up （ウェイク アップ） :朝食 breakfast （ブレックファースト） :朝食を食べる have a breakfast :晩 evening （イブニング） === 筆記用具 === :えんぴつ pencil （ペンシル） :ボールペンとか油性ペンなど pen （ペン） :ノート notebook （ノートブック） :消しゴム eraser （イレイサー） :定規（じょうぎ） ruler （ルーラー） === 教室にあるもの === :机（つくえ） desk （デスク） :いす chair （チェア） :黒板 board （ボード） 黒板は、または、 :黒板 blackboard （ブラックボード） ともいう。 ※ ちなみに黒板用のチョークは、英語でも chalk （チョーク）である。 :教室 classroom （クラスルーム） アメリカからの転校生が、学校の校門に、やってきたとしましょう。 クラスの前までつれてきたとして、クラスを紹介する例文は :This is our classroom. （ディス イズ アワー クラスルーム） こちらが私たちのクラスです === 学校の施設 === :図書室 library （ライブラリー） :職員室 teacher's room （ティーチャーズ ルーム） 学外の市営や県営などの図書館も、英語で library という。つまり、英語では、図書室と図書館を区別しないのが普通。 :保健室 nurse's office （ナースズ オフィス） :コンピューター室 computer room （コンピューター ルーム） === 国名 === :USA （ユーエスエー） アメリカ合衆国 :Australia （オーストラリア）オーストラリア :China （チャイナ） 中国（中華人民共和国のこと。けっして、日本の広島県とかの中国地方ではない。） :Japan （ジャパン） 日本 :America （アメリカ）アメリカ :american （アメリカン） アメリカ人、アメリカの ※ 「アメリカ」とはカナダやメキシコなどもふくむ、あのあたりの地域名だが、「America」でもアメリカ合衆国だと通じる場合も多い。 例文 :Bob is an american. （ボブ イズ アン アメリカン） ボブはアメリカ人です。 :Japanese （ジャパニーズ） 日本人、日本の、日本語 例文 :Taro Yamada is an Japanese. （タロー・ヤマダ イズ ジャパニーズ）ヤマダ・タロウは日本人です。 :Taro speaks Japanese. （タロウ スピークス ジャパニース） タロウは日本語を話します。 === いろんな単語 === :趣味 hobby （ホビー） :お友だち、友人 friend （フレンド） :書籍、本 book （ブック） :read a book （リード ア ブック）本を読む ちなみにマンガ本は、 :漫画本 comic book （漫画本） :辞書（じしょ） dictionary （ディくショナリー） dictionary を覚えるのは、1年生にはやや難しいだろうが、中学の範囲内なので、とりあえず練習しよう。 例文 :My hobby is a tennis. （マイ ホビー イズ ア テニス）私の趣味はテニスです。 :My hobby is playing tennis. （マイ ホビー イズ プレイング テニス）私の趣味はテニスをプレイすることです。 :My hobby is listening to music. （マイ ホビー イズ リスニング ミュージック） わたしの趣味は、音楽を聞くことです。 :My hobby is reading a book. （マイ ホビー イズ リーディング ア ブック） わたしの趣味は、本を読むことです。 {{コラム|（※ 範囲外 :）hobby の本当の意味| hobby の意味は、実は単なる「趣味」ではない。hobby は、本業以外のもので、しかも技術を要する趣味に限定される（※出展: 桐原3000<ref>桐原書店編集部『基本英単語熟語3000 基本英単語・熟語 5th Edition』、桐原書店、2017年9月30日 第5版第3刷発行、P76</ref>）。 そのため、実は「音楽鑑賞」や「読書」は、普通は hobby には含めない。 スポーツや園芸、切手収集、楽器演奏、絵画（を書くこと）、などが、hobby とされる（ジーニアス英和辞典<ref>『ジーニアス英和辞典 第4版』、大修館書店、第3刷発行 2008年4月1日、P943</ref>、桐原3000）。 もちろん、日本の学校教育では、中立的な立場という都合により、なにが技術を要する趣味かどうかなんかて言えないので、「読書」や「音楽鑑賞」などでも hobby としも、日本国内では、かまわないだろう。 ただし、米英では、読書や音楽鑑賞のようなものは、受け身の趣味とみなされ、pastime （パスタイム）と言われ、pastime とは「気晴らし」の意味である（ジーニアス英和の項目hobby、桐原3000の項目hobby）。 ずいぶんとヒドい言われ様だが、しかし米英人がそう見なしているので、日本人としては変えさせることもできない。 これはつまり、英語では、楽器を演奏することから、音楽を聞くことも一緒に趣味とする表現に当たる単語が、英語には存在しない、という事になる。スポーツの場合も同様で、スポーツ観戦からスポーツの競技者としての参加もふくめて一緒に趣味として表現する単語が、英語には存在しない。 高校英語や大学受験では、そこまでの深入りは要求されておらず、たとえば大学受験用の高校1年レベルの単語集「英単語ターゲット1200」でも、hobbyは単に「趣味」という意味だとされている。 }} === 私とあなた === :わたし、わたくし、ぼく I （アイ） :あなた、あなたたち you == うごき == :持つ have （ハブ） 例文 ::I have a pen. （アイ ハブ ア ペン）私はペンを持ってます。 :書く write （ライト） :聞く listen （リッスン） 例文 :I am listening to music now. （アイ アム リッスン トゥー ミュージック ナウ） 私はいま、音楽を聞いている最中です。 listen to （リッスン トゥー） で「〜を聞く」という意味の熟語です。よく使う表現なので、覚えよう。 :食べる eat （イート） 例文 :I eat dinner. （アイ イート ディナー） 私は夕食を食べます。 :飲む drink （ドリンク） 例文 :I drink a tea.（アイ ドリンク ア ティー）私は茶をのみます。 :open （オープン） ひらく :close （クローズ） とじる 例文 :Please open a window. （プリーズ オープン ア ウィンドウ） まどを開けてください :Open your book. （オープン ユア ブック） 本をひらきなさい。 :Open your book page eight. （オープン ユア ブック ページ エイト） 本の8ページ目をあけなさい。 ※ 「your」 で「あなたの」という意味。文脈から明らかだろうから、自然な訳になるように、例文の訳では「あなたの」を省略した。よく、授業中で先生が生徒に教科書を開かせるときに、「open your book page ○○」とかいって、教科書の○○ページ目を開けさせる。 :Close your book. （クローズユアブック） 本を閉じなさい。 :読む read （リード） :本（ほん）を読む read a book （リード ア ブック） 例文 :I read a book. （アイ リード ア ブック） わたしは本を読んでいます。 :He reads a book. （ヒー リーズ ア ブック） かれは本を読んでいます。 :行く go（ゴウ） :go to school 学校へ行く 例文 :Let's go to school. （レッツ ゴー ツー スクール） 学校へ行きましょう。 :来る come （カム） :live （リブ） 住む 例文 ::I live in Tokyo.（アイ リブ イン トーキョー） 私は東京に住んでいます。 :like （ライク） 好き 例文 ::Bob: Do you like sports？ （ドゥー ユー ライク スポーツ？） スポーツは好きですか。 さきほどの例文に対する答え ::Taro: Yes,I do. Ι like tennis. はい、私はテニスが好きです。 ::Taro: No,I don't. いいえ、私はスポーツが好きではありません。 :（動物を）飼う have （ハブ） ※ 持つの have と同じ単語。 例文 :Do you have a dog？ （ドゥー ユー ハブ ア ドッグ？） イヌを飼ってますか？ 例文にたいする答え ::Yes, I do. I have three dogs. はい、私は3匹のイヌを飼ってます。 ::No, I don't. I have two cats. いいえ、私はネコを2匹、飼ってるのです。 :掃除する clean （クリーン） 例文 ::I clean my room. （アイ クリーン マイ ルーム） 私は自分の部屋を掃除します。 :勉強する study （スタディ） 例文 ::I study English. （アイ スタディ イングリッシュ） 私は英語を勉強します。 :〜する do （ドゥー） :do the shopping （ドゥー ザ ショッピング）買い物をする === 学校にかんする動作 === :学校に行く go to school （ゴー・トゥー・スクール） :手を上げる raise a hand （レイズ・ア・ハンド） :宿題をする do my homework （ドゥー・マイ・ホームワーク） :家にかえる go home === 代名詞 === :this （ジス、ディス） これ :it （イット） それ :that （ザット） あれ === からだの一部 === [[File:Face engish education japanese.svg|thumb|500px|]] :手 hand （ハンド） :頭 head （ヘッド） :かみ hair（ヘアー） :足 foot （フット） :目 eye （アイ） :顔 face （フェイス） :鼻 nose （ノーズ） :耳 ear （イアー） :ひじ elbow （エルボー） :ひざ knee（ニー） ※ 「knee」は発音に注意。「ニー」である。「くにー」などと発音しないように。 :口 mouth （マウス） :ゆび finger （フィンガー） :せなか back （バック） :うで（腕） arm （アーム） からだ全体 :からだ body （ボディ） === スポーツ === :ボール、球 ball （ボール） :サッカー soccer （サッカー、サカー） :テニス tennis （テニス、タニス） :野球 baseball （ベイスボール） :（スポーツを）プレイする play :体育館 gym （ジム） :体育 P.E. （ピーイー） 例文 :I play a tennis. (アイ プレイ ア テニス.)私はテニスをプレイします。 :My hobby is a tennis. （マイ ホビー イズ ア テニス）.私の趣味はテニスです。 :ファン fun （ファン） 例文 Tom is a baseball fun. トムは野球ファンです。 「プレイすることがすきです」 :I like playing a tennis. （アイ ライク プレイング ア テニス）.テニスをすることが、好きです。 ::※ 動詞のうしろに「ing」をつけると、名詞になる。つまり、 play ＋ ing → playing で、「プレイすること」という意味になる。こういう動詞〜ingで名詞化する用法を動名詞（どうめいし）という。動名詞は、中学1年の範囲を超えるので、覚えるのは後回しでよい。 :練習 practice （プラクティス） スポーツ以外のことでも、練習には practice を使える。 :スポーツ sports（スポーツ） ※ なお、ラケットは racket （ラケット）。覚えなくて良い。 === 音楽 === :音楽 music （ミュージック） :演奏する play （プレイ） :I play the piano. （アイ プレイ ザ ピアノウ） 私はピアノを演奏します。 :I play the guitar. （アイ プレイ ザ ギター）私はギターを演奏します。 :歌う sing （シング） :歌 song （ソング） 例文 :I sing a song. （アイ シング ア ソング） 私は歌を歌います。 :ピアノ（楽器名） piano （ピアノウ） :歌手 singer （シンガー） 例文 :He is a singer. （ヒー イズ ア シンガー） 彼は歌手です。 === コンピューター用語 === :インターネット internet （インタネット） :コンピューター computer （コンピューター） === 学校 === :学校 school （スクール） :学級 classroom （クラスルーム） :学生 student （スチューデント） :教師、先生 teacher （ティーチャー） 「teach」（ティーチ）で「教える」という意味。語尾に「er」（○○アーと読む）で「○○をする人」という意味の英語になる。「teach ＋ er」で 「教える人」→「先生」というわけ。 例文 :Bob: Is she a teacher? （イズ シー ア ティーチャー？） 彼女は先生ですか？ ::Yamada: Yes,she is. （イエス ,シーイズ） はい、そうです。彼女は先生です。 ::Tamada: she is an English teacer. （シーイズ アン イングリッシュ ティーチャー）彼女は英語の先生です。 ※ English（イングリッシュ） の場合、前につくのは a でなく an （アン）になるので注意。単語のさいしょの発音が「ア・イ・ウ・エ・オ」のどれかの前では、a ではなく an になる。 ほかの教科の教師を{{ruby|紹介|しょうかい}}する場合は、 たとえば、数学の田中先生(男性)を紹介する場合、 ::Yamada: This is Mr.Tanaka. ::Yamada: He is a math teacher. のようになる。 単語について、ちなみに「制服」を英語でいうと uniform （ユニフォーム） である。 その他の例文 :I go to school. （アイ ゴー ツー スクール） わたしは学校に行きます。 単語 :放課後 after school （アフター スクール） :中学校 junior high school （ジュニア ハイ スクール） :高校 high school （ハイ スクール） ちなみに大学は :大学 university （ユニバーシティ） === 交通手段 === :車、自動車 car （カー） :自転車 bike （バイク） :電車 train （トレイン） :バス bus（バス） ちなみに、お風呂は :お風呂 bath （バス） であり、bus とは、ちがう単語。 === 家の中 === :部屋（へや） room （ルーム） :台所 kitchen （キッチン） :お風呂 bath バス :風呂に入る take a bath （テイク ア バス） 例文 :I take a bath. （アイ テイク ア バス） わたしは風呂に入る === 数字 === :0 zero （ゼロ） :1 one （ワン） :2 two （ツー） :3 three スリー :4 four フォー :5 five ファイブ :6 six シックス :7 seven セブン :8 eight エイト :9 nine ナイン :10 ten テン :11 eleven イレブン :12 twelve トウェルブ :13 thirteen サーティーン :14 fourteen フォーティーン :15 fifteen フィフティーン :16 sixteen シクスティーン :17 seventeen セブンティーン :18 wghteen エイティーン :19 nineteen ナインティーン :20 twenty トウェンティー :21 twenty one トウェンティーワン :30 thirty サーティー :40 forty フォーティー :50 fifty フィフティー :60 sixty シクスティー :70 seventy セブンティー :80 eighty エイティー :90 ninty ナインティー :100 one hundred ワン・ハンドレッド :101 one hundred and one ワンハンドレッド アンド ワン :200 two hundred ツー・ハンドレッド :1000 one thousand ワン・サウザンド ※ 注意事項など 「40」のfortyは つづり に注意。「14」fourteen に引きづられてか、つづりを間違える例がある。 === 算数 === 3＋4＝7 :three plus four is seven. :（スリープラス フォー イズ セブン.） 8-3＝5 :eight minus three is five. :（エイト マイナス スリー イズ ファイブ） === 年{{ruby|齢|れい}} === :私は13{{ruby|歳|さい}}です。 I'm thirteen years old. （アイム サーティーン イアズ オールド） 「 ○○（数字） ＋ yaers old 」で、「○○歳」の意味になる。 === 色 === :赤 red （レッド） :青 blue （ブルー） :緑 green （グリーン） :黄色 yellow （イェロー） :黒 black （ブラック） :白 white （ホワイト） == よくある人名 == ※ 人名の最初の文字は、かならず大文字で書く。 :Mike マイク（男性の名前のひとつ。）※ 「ミケ」ではない。 :Mary メアリー（女性の名前のひとつ。）※「マリー」ではない(※ヨーロッパ系では「マリー」と発音するが、アメリカ系では「メアリー」となる)。 :Tom トム :John ジョン :Jack ジャック :Brown ブラウン （姓のひとつ（苗字、名字のこと）。よって、男性でも女性でも使う。） 呼びかけるときは、 Mr.Brown とか Ms.Brown のように、敬称をつけて使おう。 :Green グリーン （姓のひとつ） Mr.Green とか Ms.Green のように、敬称をつけて使おう。 最近、教科書で見かける人名 :Ellen エレン （女性の名前のひとつ） :Kate ケイト （女性の名前のひとつ） :Judy ジュディ （女性の名前のひとつ） :Daniel ダニエル （男性の名前のひとつ） :Tina ティナ （女性の名前のひとつ） :Sherry シェリー （女性の名前のひとつ） :Allison アリスン（女性の名前のひとつ） :Carol キャロル （女性の名前のひとつ） ※ 「キャロル」は女性の名前のひとつだが、しかし小説『不思議の国のアリス』の原作者の男性がペンネームで「ルイス・キャロル」というのを名乗っていたりと、ややこしい。しかも、このアリスの文中の一節も、英語教科書で紹介されることがあるので、これまた、ややこしい。 :Bill ビル （男性の名前のひとつ） :Robert ロバート （男性の名前のひとつ） ::Robert のニックネーム（あだ名）が Bob だったりすることもある。 Bob とは、なにも、ボブソンの略とは限らない。 :Laura ローラ （女性の名前のひとつ） :Paul ポール （男性の名前のひとつ） :Hall ホール (姓のひとつ。つまり、男性と女性両方で使われる。) Mr.Hall とか Ms.Hall とか、Mrs.Hall などのように使う。 なお、「穴」（あな）を表す英単語は hole である。 == 日本について == :日本 Japan （ジャパン） :※ 「Japan」の「J」は、かならず大文字になる。 :日本語 Japanese （ジャパニーズ） :日本人 Japanese 日本語と日本人は、同じ Japanese という単語である。 :東京 Tokyo :大阪 Osaka :名古屋 Nagoya == 健康 == :お医者さん doctor ドクター :病院 hospital （ホスピタル） ※ 「doctor」の、さいごの2文字は「or」である。「er」ではないので、間違えないように。 学校の中の保健室については、 :保健室 nurse's office （ナースズ オフィス） === 衣服 === :Tシャツ T-shirt （ティーシャト） :ドレス dress :帽子（ぼうし） cap （キャップ） :コート coat （コート） ::レインコート raincoat （レインコート） :ズボン pants（パンツ）,trousers ※ イギリスではpantsは下着を指す。 :スカート skirt （スカート） :制服 uniform （ユニフォーム） :くつ shoes （シューズ） shoesは「shoe」（シュー）の複数形。単数形shoeだと、片足ぶんになってしまう。なので、ふつうに両足ぶんの場合、複数形 shoes のまま使う。 :めがね glasses （グラシィズ） 単数形 glass だと、片方の目のぶんだけになってしまう。なので、ふつうは、 glasses で使う。 :衣服 clothes （クロウジィズ） === 身につける道具 === :うで時計 watch （ウォッチ） :めがね glasses （グラシィズ） == ちょっと難しい単語 == :難しい difficult （ディフィカルト） 例文 :Math is difficult.（マス イズ ディフィカルト） 数学は、むずかしい。 :「簡単な」「簡単である」 easy （イージー） ここでの「簡単な」は、「難しい」の対義語としての「簡単な」のこと。easy は形容詞なので、「簡単」とだけ訳してはいけない。「簡単な」あるいは「簡単である」と訳すように。 だから辞書には「容易な」「（・・・するのが）やさしい」とも書いてある（ジーニアス英和<ref>『ジーニアス英和辞典 第4版』、大修館書店、第3刷発行 2008年4月1日, P622</ref> ）。なお、訳語のひとつの「やさしい」の表記についてジーニアス英和辞典にもセンチュリー英和辞典にも平仮名で「やさしい」と書いてある<ref>『ジーニアス英和辞典 第4版』、大修館書店、第3刷発行 2008年4月1日, P622</ref><ref>『グランドセンチュリー英和辞典 第4版』、三省堂、第3刷発行 2017年1月10日 第1刷発行, P480 </ref>。 語尾が -eの ease （イース）だと、「容易さ」と訳せると、英和辞典にある（ジーニアス英和やセンチュリー英和など）。英和辞典では、「簡単さ」という言い回しは、現状ではあまり採用されていない。だが、国語辞典を見ると、「簡単さ」という単語もあるのが日本語では実情である（三省堂『新明解国語辞典 第八版』<ref>山田忠雄 ほか編集『新明解国語辞典 第八版』、三省堂、2020年10月20日 第1版発行,P330</ref>）。 ※ 難易のことではなく、構造や仕組みが「単純な」「簡単な」と言いたい場合は、別の単語（たとえば simple など）なので、誤解しないように。 だが実際には、simpleでも、難易における「簡単な」意味もある（ジーニアス英和辞典やセンチュリー英和で確認できる）。 === 曜日 === :日曜日 Sunday （サンデー） :月曜日 Monday （マンデー） :火曜日 Tuesday （チュースデー） :水曜日 Wednesday （ウェンズデー） :木曜日 Thursday （サースデー） :金曜日 Friday （フライデー） :土曜日 Saturday （サタデー） :週 week （ウィーク） :今週 this week （ディス ウィーク） :先週 last week ::※ 火曜日 Tuesday とか水曜日 Wednesday など、火曜から、つづり が急に難しくなるが、これは実はゲルマン神話などの神々の名前が由来なので（けっして惑星・天体の名前ではない）。なお、つづりは簡単だが Friday も同様、神の名前が由来。 ::なお、土曜日は、神の名前だが（なおキリスト教の悪魔サタンとは別）、土星の英語名もその神の名前なので、気にしなくていい。 === きのう、今日、あす === :今日 today （トゥデイ） :昨日 yesterday （イエスタデイ） :明日 tomorrow （トゥモロウ） ※ 動詞の未来形は1年の範囲外なので、tomorrow は1年では習わないかもしれないが、せっかくだから、いっしょに覚えよう。どうせ、2年生で、未来形をあつかう授業で tomorrow も習うだろうし。 === 教科 === :数学 mathematics （マテマティクス） math（マス）と略される。 小学校の「算数」も英語では mathematics である。 :理科 science （サイエンス） :社会科 social science（ソーシャルサイエンス）もしくは Social studies （ソーシャルスタディー） :英語 English :音楽 music （ミュージック） :体育 P.E. （ピーイー） :美術 fine arts （ファイン・アーツ） :技術・家庭科 industrial and home economics （インダストリアル・アンド・ホーム・エコノミクス） ※ 家庭科の英語は、直訳すると、工業 (industrial) と家庭 (home) の経済学 (economics) 、となる。 :教科 subject （サブジェクト） == 参考 == === 洋食 === :オムレツ omlet （オムレット） :プリン custard pudding （カスタード・プディング）<!-- 単に pudding とするとオカズの範疇のものまで含まれる。 --> === 楽器 === :ギター guitar :フルート flute === 季節と月 === :冬 winter （ウィンター） ::1月 January （ジャーニュアリー） ::2月 February （フェーブラリー） :春 spring （スプリング） ::3月 March （マーチ） ::4月 April （エイプリル） ::5月 May （メイ） :夏 summer （サマー） ::6月 June （ジューン） ::7月 July （ジュライ） ※ 7月「July」は、古代ローマの偉人のジュリアス・シーザーが名前の由来。なお、シーザーは英語風の発音。現地風の発音ではユリウス・カエサルになる。 ::8月 August （オーガスト） ※ 「August」は、古代ローマの偉人のアウグスツスが名前の由来。 シーザー（カエサル）とアウグススツは、高校の世界史などで習う。 :※ 1月と5月と6月の名前は、ギリシャ・ローマなどの宗教の神々の名前が由来である。 ※ 3月のMarch は、冒頭の大文字・小文字の違いをのぞけば、「行進」march （マーチ）と同じスペル。 :秋 fall（フォール） または autumn （オウタム） ::9月 September （セプテンバー） ::10月 October （オクトーバー） ::11月 November （ノーベンバー） :冬 ::12月 December （ディッセンバー） 会話例 :When is your birthday? （フェーンイズユアバースディ？） あなたの誕生日はいつですか？ :September 2nd. （セプテンバー セカンド） 9月2日です。 === 家族 === :おじいさん grand father （グランドファザー） :おばあさん grand mother （グランドマザー） :男性の兄や弟 brother （ブラザー） :女性の妹や姉 sister （シスター） :おば aunt （アント） :おじ uncle （アンクル） :むすこ son （サン） :むすめ daughter （ドーター） === 番号 === :1番目の、第1の first （ファースト） ※ 「第一の」は、one （ワン）ではない :2番目、第2の second （セカンド） :第3の third （サード） :第4の fourth （フォース） :第5の fifth （フィフス） :第6の sixth （シックスス） :第7の seventh （セブンス） :第8の eighth （エイス） :第9の ninth :第10の tenth （テンス） :第11の eleventh :第12の twelfth :第13の thiteenth === 私たちと彼ら === {| class="wikitable" style="float:right" |+ 人称（複数） ! !!　 !! 主格 !! 所有格<br />（〜の） |- ! 1人称 || わたしたち | we || our |- ! 2人称 || あなたたち | you || your 　 |- ! 3人称 || 彼（かれ）ら、<br />彼女ら、<br />それら | they || their 　 |} {| class="wikitable" style="float:right" |+ 人称（単数） ! !!　 !! 主格 !! 所有格<br />（〜の） |- ! 1人称 || わたし | I || my |- ! 2人称 || あなた | you || your 　 |- ! rowspan="3" | 3人称 || 彼（かれ） | he || his 　 |- ! 彼女 | she || her 　 |- ! それ | it || its 　 |} :私たち we （ウィー） :私 I （アイ） :あなたたち you （ユー） :あなた you （ユー） :かれ（その人が男性の場合のみ） he （ヒー） :彼女（その人が女性の場合のみ） she （シー） :it（それ、性別不明） it （イット） :彼ら、彼女ら、それら、 they （ゼイ） 「私の○○」は「my ○○」（マイ ○○）というように、Iではなく、my （マイ）を使う。 たとえば、「私のペン」は「my pen」。 「彼の○○」は、「his（ヒズ）○○」。たとえば「彼のペン」は「his pen」。「彼女のペン」は「her pen」。 ちなみに、「あなたの○○」は「your(ユア) ○○」 このような my, your, his, her などの言葉の形を所有格（しょゆうかく）という。 :they の所有格は their （ゼア）。We の所有格は our （アワー）。 いっぽう、I, you, he, she, they などを主格（しゅかく）という。 === スポーツ === :バスケットボール basket ball （バスケットボウル） :バレーボール volleyball （バリィボウル） :卓球 table tennis （テーブルテニス） :アメフト（アメリカンフットボール） football（フットボウル） :柔道 judo （ジュードー） :ゴルフ golf （ゴルフ） :水泳 swimming （スイミング） === 音楽 === :ドラム drum （ドラム） :ギター guitar （ギター） :ピアノ piano （ピアノ） :フルート flute （フルート） === だれ、なに === :誰（だれ） who （フー） 例文 :Yamada: Who is Tom？ トムとは、だれですか？ ::Bob: Tom is my brother. トムは、私の兄弟です。 :なに What 例文 ::What your favorite sports？（ホワッツ ユア フェイバリット スポーツ？） 好きなスポーツは何ですか？ 回答例 :I like tennis. :My favorite sports is tennis. === 方向をともなう動き === :立て。立ちなさい。 Stand up. （スタンド アップ） :すわれ。すわりなさい。 Sit down. （シット ダウン） ※ 「up」（アップ） は「上へ」「上に」のような意味。「down」（ダウン）は「下へ」「下に」のような意味。 === 動詞 === :洗う（あらう） wash （ウォッシュ） :皿（さら）を洗う wash a dishes （ウォッシュ ア ディッシィズ） ※ wash a dishes は、教科書でよくある表現なので、そのまま覚えてしまおう。 === 食事 === :トマト tomato （トメイトウ） :いも、ポテト potato （ポテイトウ） :ピザ pizza :ハンバーガー hamburger :ソーセージ sausages :ホットドッグ hot dog おやつ :ドーナツ donut :あめ candy :ポップコーン popcorn :ポテトチップス potate chips :クッキー cookie :チョコ chocolate （チョコレート） :プリン pudding （プディング） :ヨーグルト yogurt :アイスクリーム ice cream おなかがすいたら、 :おなかがすいてる hungry （ハングリー） 例文 :I'm hungry. （アイム ハングリー） のように使う。 === 動物 === :ぞう elephant （エレファント） : : : : == 形容詞 == :強い strong （ストロング） 例文 Bob is strong. （ボブ イズ ストロング） ボブは強い。 :奇妙な strange （ストレンジ） :つかれている tired （タイアード） 語尾が ed で、動詞の過去形と同じだが、 tired は形容詞である。 例文 I'm tired. （アイム タイアード） わたしは、疲れています。 :伝統的な traditional トラディショナル 例文 :Kimono is a Japanese traditional cloth. （キモノ イズ ジャパニーズ トラディショナル クローズ） 着物は、日本の伝統的な衣服です。 :Kendama is a Japanese traditional toy. （ケンダマ イズ ジャパニーズ トラディショナル トーイ） けん玉は、日本の伝統的なオモチャです。 == 買い物 == :ドル（アメリカのおかねの単位） dollars （ダラー） :日本円 yen （エン） :買う buy （バイ） :おいくら？ How much？（ハウマッチ？） == その他 == :箱（はこ） box（ボックス） :複数の箱 boxes （ボクシーズ） ※ boxは、複数形が、boxs（×）ではなく、boxes なので、まちがえないように。 :カメラ camera （カメラ） :写真 picture （ピクチャー）または photograph （フォトグラフ） :CD（コンパクトディスク） CD （シーディー） ::CDは英語も日本語も同じで「CD」。 :CDプレイヤー CD player （シーディー プレイヤー） == 形容詞 == 形容詞の暗記は、反対の意味どうしを組み合わせで覚えると、覚えやすい。 :大きい big （ビッグ） :小さい small （スモール） :新しい new （ニュー） :古い old （オウルド） :熱い hot （ホット） :冷たい、寒い cold （コウルド） :背が高い tall （トール） :（山や建物などが）高い high （ハイ） :若い young （ヤング） :年をとった old （オウルド） == 町の中にあるもの == :公園 park （パーク） They are playing soccer in the park. （ゼイ アー プレイング サッカー イン ザ パーク） 彼らは公園でサッカーをしています。 :駅 station （ステイション） なお、鉄道について ::電車 train （トレイン） :町、街 city （シティ） == ABCD・・・ == :エプロン apron :バス bus :city シティ :イヌ dog :ワシ（鳥類）eagle イーグル :さかな fish :巨人 giant ジャイアント :帽子 hat ハット :インク ink :ジュース juice :台所 kitchen :ライオン lion :口 mouth （マウス） :n :海洋 ocean オーシャン :p :質問 question （クエスチョン） :お米 rice （ライス） :s :ティッシュ（鼻をかむためのアレ） tissue :かさ umbrella :バイオリン violin :窓 window :x :ヨーヨー yoｰyo :ゼロ zero == 食べ物 == === 肉 === :牛肉 beef :豚肉 pork :鶏肉 chicken === 料理 === :ステーキ steak :シリアル（牛乳とかをかけて食べるアレ） cereal :トースト toast :ベーコン bacon :グラタン gratin :ヌードル（ラーメン、うどん、など） noodle :オムレツ omlet （オムレット） === 野菜 === :キュウリ cucumber （キューカンバー） :キャベツ cabbage （キャベッジ） :レタス lettuce （レタス） :ピーマン green ppper （グリーンペッパー） :玉ねぎ onion （オニオン） :カボチャ pumpkin （パンプキン） :ニンジン carrot （キャロット） : === おやつ === :パイ（アップルパイなど） pie :クッキー cookie :ポップコーン popcorn :ポテトチップ potato chip :ヨーグルト yogurt :プリン pudding :ドーナツ donuts :キャンディー candy :チョコレート chocolate :ケーキ cake == 街の中 == :ガソリンスタンド gas station :交番 police box :映画館 theater （シアター） :スーパー supermarket （スーパーマーケット） :レストラン restaurant （レストウラント） :コンビニ convenience store :ホテル hotel （ホウテル） ※ 発音注意 :銀行 bank （バンク） == 野菜 == :ピーマン green pepper （グリーンペッパー） : : : == ニッポンの伝統など == :金魚 goldfish : : : : == 動物 == * おぼえるべき :生きている牛（うし） cow （カウ） :ネズミ mouse （マウス） :キツネ fox （フォックス） :生きているブタ pig （ピッグ） * オーストラリアの動物 :カンガルー kangaroo :コアラ koala :ウォンバット wombat :カモノハシ platypus （単数形） カモノハシの複数形は platypuses なお、カモノハシは、ほ乳類。 :ほ乳類 mammals （複数形） * その他の動物 :カバ hippo ヒッポ :ハムスター hamster :亀 turtle タートル :たこ octopus オクトパス :キリン giraffe （ジラフ） :トラ tiger （タイガー） :チーター cheetah :イルカ dolphin :カエル frog （フロッグ） :クモ（虫のクモ） spider （スパイダー） == 未分類 == :MP3 player :網（あみ） net ネット テニスとかのコートのネットも、net と書く。 : == 外国の都市 == :ロンドン（イギリスの首都） London :トロント（カナダの都市市のひとつ） Toronto :オタワ（カナダの首都） Ottawa :キャンベラ（オーストラリアの首都） Canberra :シドニー（オーストラリアの都市のひとつ） Sydney :ペキン（中国の首都） Beijing （ベイジン） :ソウル（韓国の首都） Seoul :ニューデリー （インドの都市市のひとつ） New Delhi :カイロ（エジプトの都市市のひとつ） Cairo :サンフランシスコ（アメリカ合衆国の都市のひとつ） San Francisco == 人名 == :デイビッド（男性の名前） David :デイブ Dave （※デイビッドなどの略称） :ジャック Jack :エリザベス Elizabeth :ベス Beth （※ エリザベスなどの略称） :ベッキー Becky :ナンシー Nancy :ケビン Kevin == 日本語の外来語の語源になってる英語 == :ボランティア volunteer （ボランティーア） :ボトル（ペットボトルとか、洗剤の容器など） bottle :シャンプー shampoo :アイスティー iced teaka :スペシャル（「特別な」の意味の形容詞） special == 検定教科書の名前に使われている単語 == :crown （クラウン） 王冠 :horizon（ホライズン） 地平線 :world （ワールド） 世界 :sunshine （サンシャイン） 太陽のかがやき、日差し : == 英語以外の国のあいさつ == 書けなくてもいいが、ドイツ語、スペイン語、中国語の「ありがとう」「こんにちは」に相当する言葉については、発音を知っておくとよい。 いちおう、検定教科書にも、書いてある(東京書籍の「ニューホライズン」という教科書にある)。 英語以外の外国語は、日本の高校入試には、ふつうは、出ない。 * ドイツ語 :こんにちは: Guten Tag. グーテン ターク :ありがとう: Danke. ダンケ 英語とドイツ語は、ドイツ語の Guten と 英語の good が対応しており,ドイツ語の tag とは 英語のday（デイ） が対応しており,ドイツ語の Danke には英語の Thank が対応してるなど、多くの単語が対応しあっている。 つまり、Guten Tag を日本語に直訳すると、「良い日」になる。 だが、ドイツ語の文法は、英語の文法とは大きく違うので、上記の対応は、おぼえなくてよい。 ※ なお、社会科の地理分野で、世界地理で、英語とドイツ語はともに'''ゲルマン系'''の言語であることを習う。社会科のほうで、言語について、ゲルマン語系の設問が出題される可能性がある。 * スペイン語 :こんにちは: Buenas tardes. ブエナス タルデス :ありがとう: Gracias. グラシアス 世界で、スペイン語を日常的に話す人口は、すごく多い。ある言語を話す人口の順位で、スペイン語は上位である。 なぜなら、南アメリカ大陸の多くの国で、スペイン語が公用語になっている。メキシコなど、アメリカ大陸中部の諸国でも、スペイン語が公用語として使われている。 スペイン本国よりも、南アメリカ大陸など本国以外のスペイン語人口の総人口のほうが多いほどである。 ※ 中学社会科の地理分野で、世界地理で、スペイン語とフランス語はともに'''ラテン系'''の言語であることを習う。 * 中国語 :こんにちは: 你好。 ニーハオ :ありがとう: 谢谢。 シェシェ * フランス語 :こんにちは: ボンジュール :ありがとう: メルシー ※ つづりは省略。フランス語のつづりは、むずかしいので。 ※ 中学社会科の地理分野で、世界地理で、スペイン語とフランス語やイタリア語はともに'''ラテン系'''の言語であることを習う。 :スペイン語のあいさつ「ブエノスディアス」と、フランスのあいさつ「ボンジュール」では、両国のあいさつとも最初の音はバ行であるという点が共通している。 * ロシア語 :こんにちは: ズトラーストビチェ :ありがとう: スパシーバ ※ つづりは省略。ロシア語の文字はキリル文字をつかう。ローマ文字ではない。 ※ ロシア語やポーランド語は'''スラブ系'''の言語である。 * 韓国語 :こんにちは: アンニョンハセヨ :ありがとう: カムサハニダ ※ つづりは省略。韓国語の文字はハングル文字をつかう。漢字は、韓国では、あまり使わない。 * アラビア語 :こんにちは: アッサラーム アライクム :ありがとう: シュクラン アラビア文字は、むずかしいの [[カテゴリ:中学校英語|いちねんたんこ]] [[カテゴリ:英語教育|ちゆういちたんこ]] cuantpbmfnpwngeub00xusmmtspnek2 0 21996 206822 206589 2022-08-19T22:47:07Z すじにくシチュー 12058 /* 代名詞 */ Heaven helps those who help themselves. 「天はみずから助くる者を助く。」（ことわざ） wikitext text/x-wiki <!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --> == 目次 == * [[高校英語の文法/文の種類]] * [[高校英語の文法/動詞と文型]] * [[高校英語の文法/時制]] ※ 参考書によって微妙に単元名が異なるので暫定 * [[高校英語の文法/完了形]] * [[高校英語の文法/助動詞]] * [[高校英語の文法/不定詞]] * [[高校英語の文法/動名詞]] * * [[高校英語の文法/比較]] * [[高校英語の文法/関係詞]] * [[高校英語の文法/仮定法]] * [[高校英語の文法/名詞]] * [[高校英語の文法/冠詞]] * * [[高校英語の文法/否定]] * [[高校英語の文法/接続詞]] * [[高校英語の文法/前置詞]] == 文の構造 == === 文の要素 === 文の構造を知るためには、文がどのような要素で成り立っているのかを知らなければならない。 ==== 主語と述語動詞 ==== # '''The old man''' ''is'' a famous singer. # '''My sister''' ''studied'' math. ## 訳例:その老人'''は'''有名な歌手'''だ'''。 ## 訳例:私の姉'''は'''数学を研究'''していた'''。 1の文は「AはBだ」という文であり、2の文は「AはCする」という文である。どちらも # 「…は」「…が」という主題の部分 # 「～である」「～する」という主題が何であるかについて述べる部分 の二つが共通している。 この場合、1を'''主部'''といい、2を'''述部'''という。 そして、主部の中心となる語を'''主語'''(Subject)といい、述部の中心となる部分を'''述語動詞'''(Predicate Verb略して'''動詞'''('''Verb'''))という。以下では、述語動詞は原則として単に動詞と呼ぶ。 {| class="wikitable" style="text-align:center" |- ! || - || 主語 || 述語動詞 || - |- | - | colspan="2" | 主部 | colspan="2" | 述部 |- | 1. | The old | man | is | a famous singer. |- | 2. | My | sister | studied | math. |} 主語は単に'''S'''で表し、動詞は'''V'''で表す。 ==== 目的語 ==== # He ''has'' '''a personal computer'''. # We ''played'' '''soccer'''. # Everone ''likes'' '''Sushi'''. ## 訳例:彼はパソコン'''を'''持っている。 ## 訳例:私たちはサッカー'''を'''した。 ## 訳例:みんなが寿司'''を'''好む。 いずれの文の動詞も「～を」という、動作の対象が必要である。このような動作の対象を表す語を'''目的語'''(Object)といい、'''O'''で表す。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 目的語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | He | has | a personal computer. |- | 2. | We | played | soccer. |- | 3. | Everone | likes | Sushi. |} このような、'''S+V+O'''という形の文は英文の基本形の一つである。 ==== 補語 ==== # Mary ''is'' '''happy'''. # John ''became'' '''a doctor'''. ## 訳例:メアリーは幸せだ。 ## 訳例:ジョンは医者になった。 これらはいずれも主語の状態を説明した文であるが、isやbecomeで文を切ると意味をとれない。happyやa doctorという、主語の様子をおぎなう語があって初めて意味のある文となる。このように、主語の様子について説明する語を'''補語'''(Complement)という。補語は'''C'''で表される。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 補語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | Mary | is | happy. |- | 2. | John | became | a doctor. |} このような'''S+V+C'''の文も基本的な文の一つである。なお、後で学ぶように、補語は主語の様子だけでなく目的語の様子を説明する場合もある(例文:I call him Sensei.(私は彼を先生と呼ぶ))。 == 動詞の用法 == === 助動詞 === === 態 === ==== 助動詞と組み合わさった受動態 ==== He could be seen by her. 受動態の文を作るときには、その文の述語は必ずbe動詞の節になるが、be動詞に対して助動詞を用いたり、時制の変化をさせることも普通に行なわれる。 この時には、例えば He is seen by her. という文が He could be seen by her. の様にbe動詞は、助動詞+beの形で書き換えられる。これは、be動詞の原形が beで与えられることによる。同じ様に例えば、 might be may be must be will be なども用いることが出来る。また、過去形や現在完了と組み合わせるときにも通常の規則に従えばよい。例えば、上の文では He was seen by her. He has been seen by her. などとなる。been は be の過去分詞である。ここで、be が過去分詞 been になったのは、現在完了を作るためであり、see が過去分詞 seen になったのは、受動態を作るためであることに注意。 === 分詞 === == さまざまな構文 == === 分詞構文 === 分詞構文は現在分詞や過去分詞を用いて、従属の接続詞節のような意味を持つ文の成分を作る用法である。例文として、 Crying out something, he quickly runs away. がある。この文は「何かを叫びながら、彼は素早く逃げていった。」という 意味だが、この様な文は例えば接続詞whileを用いて、 While he cries out something, he quickly runs away 接続詞を取る。 He cries out something, he quickly runs away. 主語を取る。 Cries out some thing, he guickly runs away. 動詞を現在分詞形にする。 Crying out some thing, he quickly runs away.→'''これで完成！''' などとすることが出来る。分詞構文は文の前後関係から、省略される接続詞が予測できると考えられるとき、接続詞と主語を省略することによって 得られる。ただし、接続詞無しで節を作ることは出来ないことから、接続詞節の述語は対応する現在分詞になるのである。上の例文は while を用いた文から接続詞 while を省き、述語 cries を現在分詞 crying にすることに よって得たものと解釈出来る。ただし、元の従属接続詞節に対応する主文の主語と接続詞節の主語が等しいときには、現在分詞の主語は 省略出来る。上の文で while 節の主語に対応する語が無いのはこのことからである。 主節の主語と従属節の主語が異なっているときには、分詞構文の主語として対応する従属節の主語を所有格として与える。例えば、上の例で主語を省略せず書くと、 His crying out something, ... のようになる。 一般に現在分詞の主語を指定するときは通常所有格を用いる。 分詞構文で省略される接続詞には主なものとして、 because, since, as: 〜だから(理由) when, as, while: 〜のとき(ある時点) などがあげられる。 分詞構文になる従属節では述語がbe動詞であることがある。 このときにも上の規則に従って、Being -,によって分詞構文が作られることも多い。 ==== 分詞構文の受動態 ==== 特にbe動詞に対応する補語が受動態であったり、形容詞であるときには、beingを省いて過去分詞、もしくは形容詞から分詞構文が 始まることも多い。 (Being) seen from airport, everything looked small.（飛行機から見ると、全てのものが小さく見えた） The assignment (being) finished, we went on a hike to the nearby mountain.（その課題が終わってから、私たちは近くの山へハイキングへ行った。） このときには、be動詞と接続詞、必要なら対応する主語も補って考える必要がある。ただし、この様な省略がなされるのは、あくまで省略されたものが文脈からすぐに分かる時のみである。 === 話法 === === 会話表現 === == 品詞 == === 代名詞 === ==== 未分類 ==== 中学校では「代名詞」として、 he や she や we など、基本的な代名詞を習う。 もちろんそれも代名詞であるが、しかしそれ以外にも多くの代名詞がある。 たとえば the same （「同じもの」の意味）も代名詞である（青チャート、ジーニアス）。なぜなら、the same は、なにか具体的な名詞を言う代わりとして使われるのだから、the same も立派な代名詞である。 このように、代名詞は別に一語でなくても構わない。 なお、形容詞的に the same の直後につづけて名詞が来る場合もあり、「the same ～ as ・・・（名詞または代名詞）」で、「・・・と同じ ～」の意味。 こちらの構文では the same は代名詞というよりも形容詞としての用法だが、市販の参考書では都合上、代名詞の章でいっしょにthe same ～ as の構文も教えているのが通例である。 ともかく例文は、たとえば the same ～ as yours で「あなたのと同じ～」の意味（ジーニアス、エバーグリーン）。 the same shoes as yours なら「あなたのと同じ靴」だし（エバー）、 the same computer as yours なら「あなたのと同じコンピュータ」である（ジーニアス）。 一方、慣用的に、節が続く場合は as ではなく that の場合が多く the same man that I saw yesterday で「昨日見かけたのと同じ男の人」の意味だし（エバーの和訳を少し改造）、 the same song that I heard yesterday で「昨日聞いたのと同じ曲」の意味（ジーニアス）。 のように、 「the same ～ that ・・・（節）」 というのもある。 ただし、節が続く場合でも、べつに as を使ってもかまわず、つまり「 the same ～ as ・・・（節）」としてもマチガイではない（ブレイクスルー）。 those who ～ で「～な人々」の意味の代名詞である。 たとえばエバーグリーンいわく、 those who wish to smoke で「たばこを吸いたい人々」である。 such は代名詞として「そのようなもの」「そのような人」として扱われる場合もある。 たとえば He is an adult now, and should be treated as such. 「彼はもう大人なのだから、そのように扱うべきだ。」　※ジーニアス He is mere child, and should be treated as such. 「彼はまだほんの子供だから、子供として扱ってやるべきだ。」　※青チャート のように such はよく as such などとして使われる。 ==== some と any ==== {| class="wikitable" style="left" |+ 複合不定代名詞 ! 　 !! some- !! any- !! no- !! every- |- ! 人<br> -one<br> -body | 　someone <br>　somebody<br>（だれか） || 　anyone <br>　anybody<br>（だれか、だれでも） || no one （※ 離して書く）<br>　nobody<br>（だれも～ない） || 　everyone<br>　everybody<br>（だれでも） |- ! 物<br>-thing | 　something || 　anything 　|| nothing || everything |- |} some にも any にも「いくつかの」という意味がある。 よく参考書では、「 some は肯定文で使う。anyは疑問文・否定文で使う」などと習う（青チャート、ジーニアスなど）。 しかし桐原ファクトいわく、anyの基本的な意味は「どれでも」の意味である。any の「いくつかの」の意味は、「どれでも」の派生だと思うほうが良いだろう。 some と any の区別で悩んだ場合は、この「どれでも」の意味を基準に考えると良い。 だから肯定文であっても、「どれでも」の意味の形容詞には any を使う。 桐原ファクトいわく、疑問文で any を使う場合でも、ニュアンス的には「どれでも」の意味があるのが実際とのこと。否定文の any も同様。 この any の基本的な意味が「どれでも」の説に立てば、たとえば熟語 not ～ any が形容詞 no と同じ意味だということも、 not ～ any は「どれでもいいので存在してほしい（any）という事についてすら、それが成り立たない（not）。　→　つまり無い」というふうに理解できます。 なお、any の後ろに否定語を置くのは禁止されている（ジーニアス、青チャート）。 ほか、慣用的な表現として、よくお茶などやコーヒーの飲み物をすすめる際に、 Would you like some coffee? 「コーヒーはいかがですか」（桐原ファクト） Would you like some more tea? 「お茶のお代わりはいかがですか」（青チャート） のようにsome を使う。 青チャートいわく、some は、答えが Yes であることを期待しているニュアンスのある表現とのこと。そういう用法もある。なので、人にものを勧めるからには、some で質問しないと失礼になるので、someを使うのが当然とのこと。 実際にはsome も any もけっして意味中立的な表現ではなく、それぞれニュアンスがあるので、some と any を完全に使い分けるのは難しいだろう。 参考書にあるような代表的な事例についてだけ、some とanyを使い分ければ、とりあえずは平気だろう。 somebody と anybody などの使い分けも、上記の some と any に準じる（桐原ファクト）。 たとえば「誰かに出会いました」といいたい場合は、somebody を使うべきだと桐原は言っている。これがもしanybodyだと 「誰でもいいのですが、その人に会いました」（原文ママ（桐原））という内容の意味不明の文章になってしまうことからも分かるとして、桐原ファクトは誰かに会った事を言いたい場合には somebody を使うべきだと言っている。 ==== every とall の違い ==== 「すべての」という意味での every は形容詞であるが（インスパイア）、市販の参考書では便宜的に代名詞の章で紹介される。形容詞なので、every 単独ではあつかわれず、必ず直後に名詞または代名詞をともなう（インスパイア）。 every には「すべての」の意味もある（桐原ファクト、インスパイア）。しかし every と all には、ニュアンスの違いが明確に存在する。 また、every の後ろは単数形でなければならない。 every は、その全部を構成する一つ一つに関心がある文脈の場合に用いられる（桐原ファクト）。だから every で形容される名詞は必ず単数形でなければならないのも当然である（桐原ファクト）。また、everyは例外がないことを強調している（ジーニアス）。 each は2つ以上、every は3つ以上のものについて使用する。 なお、each は比較的に小さい個数のものに使い、everyは比較的に大きい数のものに使う（ジーニアス）。 each の使用対象はべつに2個限定でなくても構わない。 every と all には、こういったニュアンスの違いがあるので、参考書によってはevery の標準的な和訳を「すべての」以外で紹介する参考書も多い。 たとえば「あらゆる」「どの～も」という訳で every を紹介する参考書がよくある（青チャート、ブレイクスル－）。 なお、every には別の用法で「～（数詞のつく名詞）ごとに」の意味もあり、この場合は複数形になる。 たとえば every six hours で「6時間ごとに」である（ブレイクスルー）。 every four years で「四年ごとに」である（エバーグリーン）、なおオリンピックが四年ごとに開かれる　という文章。 なお、「一日おきに」は every other day である（インスパイア）。 {{コラム|every child を受ける代名詞は he か she か？| 桐原ファクトに書いてあるのですが、男女のどちらの場合もある単数の名詞について、それを代名詞で受ける際、 he か she かが、時代とともに変わっていきました。 もともとは、男女不明などの場合は、とりあえず he で代名詞を受けていました（桐原ファクト）。 だから every child も he で受けていました。 しかし、それが男女平等の観点に反するという意見が多くなり、近年になって、「 he/ she 」などと受ける代名詞が変わってきました。 「he / she 」はhe or she と読みます。 しかし、長くなるので会話などで不便でした（桐原ファクト）。 その不便さを解消するためか、さらに最近では、単数形であることを無視して every child のような名詞でも they で受けています（桐原ファクトの 2022年 第2版で確認）。 each も同様、最近では they で受けます（桐原ファクト）。 :※ 上記のような説が有名であるが、それに対する若干の異論もある。それは 「もともと he は男の代名詞ではなく性別不明の代名詞であり、もし、男である何らかの名詞についてそれを代名詞で受ける場合については、とりあえず性別不明の代名詞である he を当てるというルールだった」というような説です。 細かな出典は忘れましたが、たしか、日本どこかの有名大学に勤務している米英人の高齢の学者が、「自分はそう習った（heは性別不明の代名詞だと子供時代に習った）」とツイッターで主張していました。 この場合でも男女は不平等であります。しかし、女性差別とは言いがたい実態になります。 つまり、「女性を無視して男性を意味する he を使っていたのではなく、そもそも he は男女不明の代名詞であったが、女性専用の she という代名詞が存在していたため、あとからhe に男性の意味がついてきた。なのに『性別不明の名詞に he を使う事を女性差別だ』というフェミニズム言説は間違っている」という説です。 もしこの説「he は性別不明の代名詞だった」論のとおりなら（この説が間違っている可能性もありますので、どちらかに決め付けないように）、現代の各国の英語教育が、フェミニズミム運動などに配慮して代名詞 he の歴史の説明について、若干のウソをついている事になる可能性があります。 どちらの場合にせよ（数学の確率問題の場合わけのように、マジメに検証する人は両方の可能性を検討する）、参考書の桐原ファクトをよく読めば、性別不明の代名詞 he → he/she → they の変遷について「男女平等」という表現は説明に用いていますが、しかし「女性差別」という表現は用いていません。桐原ファクトの著者たちは、なかなか優秀です。こういう何気ない言葉の端々に、参考書の著者の優秀さが現れます。 まあ、私たちは背景事情にまでは深入りする必要はありません。上記のような異論もあることも承知した上で、異論もふくめた両者の合意である he → he/she → they という性別不明の単数代名詞の客観的事実を覚えれば済みます。 }} ==== その他 ==== 「those who ～」で「～する人々」 Heaven helps those who help themselves. 「天はみずから助くる者を助く。」（ことわざ）　※ 青チャート === 形容詞・副詞 === ;副詞の位置 副詞の位置がどこに来るかについて、単語や文章によって様々である。 通常、英語では副詞の位置は、修飾対象に前置きである。 しかし very much や from time to time など複数語から構成される副詞表現になると、通常は文末または修飾対象の後ろに置かれるのが通常である（桐原ファクト）。 == 名詞構文・無生物主語 == === 名詞構文 === === 無生物主語 === The road takes you to the station. 「その道を歩いていくと駅につきます。」 The bus takes you to the station. 「そのバスに乗れば駅に行きます。」 take は「連れて行く」の意味だが、交通機関などを主語にして使うことも出来る。その場合は、たとえば道なら「その道を行けば、～につきます」のような意味になる。 takes の代わりに will take としても良い（ロイヤル英文法）。 「remind 人 of」 で「人に～を思い出させる」の意味である。 This picture reminds me of vacation in Greece. 「その写真を見ると、ギリシャでの休日を思い出す。」 This picture reminds me of holidays in London. 「その写真を見ると、ロンドンでの休日を思い出す。」 なお、大修館ジーニアスだとロンドン、桐原フォレストだとギリシャの例文。 「deprived 人 of ～」 「（機会などが）うばわれる」 The knee injury deprived him of the chance to play in the final game. 「ひざのけがのため、彼は決勝戦に出場する機会を失った。」 または The knee injury deprived the player of the chance to play in the game. 「ひざにけがをしたため、その選手は試合に出場する機会を失った。」 のように例文が参考書によくある。 enable ～ は、「～をできるようにする」「～を可能にする」の意味。「～のおかげで、・・・できるようになった」と訳すことができる。 The scholarship enabled him to go on to university. 「その奨学金のおかげで彼は大学へ進学できた。」 ジーニアス、ロイヤルに scholarship の似た例文。 == 疑問詞 == === 前置詞と疑問詞 === Where are you from? 出身はどちらですか？ 文法上、ここでの Where は副詞であり、「疑問副詞」というのに分類される（ロイヤル）。 さて、前置詞 from に注目しよう。 もしかしたら中学高校などで「前置詞は名詞や代名詞の前に移動するのが原則」とか習うかもしれないが、しかし前置詞をけっしてfromの前に移動しない。 なので、Where は副詞であると考えたほうが理解しやすいだろう。（これとは別の解釈で、そもそも「副詞には前置詞がいらない」という考えから副詞ではなく代名詞としての機能だと考える立場もあり、ジーニアスやロイヤルやフォレストがそういう立場。だが、机上の空論だろう。） なお、法学など幾つかの学問では、『原則』というのは例外のありうる規則、という意味である。おそらくジーニアスが「原則」という言葉を使っているのは、Where ～?などの疑問詞を文頭にもちいた疑問文の場合は例外的な事例という含みがあるのだろう。 Where に限らず、たとえば When などで疑問文を作るときも原則、それらの疑問詞の前には前置詞（When の場合は since や till や until など）を置かない。そのため、それら When の文でも前置詞は文末にくる場合が多くなる。 つまり、「いつから～？」なら When do you ～ since ? のような文章になる事が多い。 ただし、Whoの場合はやや例外的である。 たとえば前置詞 With を使う場合、Who が目的格 Whom に変化する場合もあり、 With whom do you ～? 「誰と一緒に～しますか？」 のようにWith が文頭にくる場合もある（桐原）。with以外の前置詞の場合でも文頭に持ってくる場合には同様にwhoではなく whom に変化する（ジーニアス）。なお、前置詞を文頭に持ってくる場合、whomを使わずにwho のままで文頭の前置詞の次に置くのは禁止である。 なお、Whomを使わずとも who のままで下記のように言うこともできる Who do you ～ with？ Where are you from? の場合、もし前置詞 from がないと、「あなたはどこ？」となり、それが出身をたずねているのか、それとも現在地をたずねているのか、意味が分からなくなることもあってか、ともかく 「Where are you from?」の文章は from を省略できない。 ジーニアスは、話し言葉ではWhereでは from を省略しないという言い方をしているが、しかし書き言葉であっても from を省略しないのが一般的であろう（省略したら上述のように意味が通らなり読み手に誤解を与えるので。）。 しかし、用いる動詞などによっては前置詞を省略できる場合があり、たとえば Where do you go to? 「どこに行きますか？」 なら、もし前置詞 to を省略しても、動詞 go から意味を推測できるので、この場合は to を省略されるのが許され、つまり Where do you go? でも許される（ジーニアス）。 このように文法の理論というのは、あまり論理的ではない。最終的には、英文法の学習では典型的な構文を覚えて、それを真似して使っていく必要がある。 === 慣用的な疑問文 === How about a cup of tea? 「お茶を一杯いかがですか？」 How about ～？ は勧誘を表す。 What do you say to ～ing 名詞/動名詞　？　「～はいかがですか？」「～しませんか」 What do you say to ～ing　でも勧誘を表せる。 ここでのsayの直後にある to は前置詞であると考えられている（桐原フォレスト）。どういうわけか、ジーニアスもロイヤルも、to が前置詞かどうかは言及していない。 ほか、Why don't you 動詞 ～　？ は、「～してはどうしょうか」のような相手に行為を促す（うながす）言い方であり、やや押し付けがましい言い方である（ジーニアス）。 Why don't we の形で、一緒になにかをする時に「～しましょうよ」の意味で使う場合もある（フォレスト）。 また、これを省略的に Why not ～？ の形で「～はどうですか」「～してはいかがでしょうか」「～しましょうよ」の意味にもある。 How come S + V ～？ How come ～？　は「どうして～」の意味でありwhy に近いが、How come のほうが感情的な表現であるので、目上の人に使うのは避けるのが良い（ジーニアス）。なお、How come は語順がSVと肯定形の語順になる。 How come you didn't call me ? 「どうして電話をくれなかったの？」 ※ 「電話してほしかったのに」のような含みがあり、相手を責めているようにも受け取られかねない。だから返事も、Sorry, 「ごめん」とかになる（ジーニアス）。 許可を求める表現である Do you mind if～? で、「～してもいいですか」という許可を求める表現ができる。なお Would you mind if ～? については仮定法になり、つまり「～」中の動詞が過去形になる。Would you mind if ～? については 『[[高校英語の文法/仮定法]]』で説明済み。 Do you mind if のほうは、if ～ の動詞は現在形で構わない。 == 参考文献についての注意 == サブページ中の参考文献で、現代2022年では廃止になったシリーズの桐原『フォレスト』などを掲げているが、現代でも他社の　いいずな出版『エバーグリーン』シリーズにフォレストの権利が引き継がれているようなので、わざわざ古本のフォレストを探す必要は無い。 [[カテゴリ:高等学校教育|ふむほふ]] 3g9lfj3fis2xpvuywyi69pm6c7qoxvs 206828 206822 2022-08-19T23:37:02Z すじにくシチュー 12058 /* その他 */ wikitext text/x-wiki <!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --> == 目次 == * [[高校英語の文法/文の種類]] * [[高校英語の文法/動詞と文型]] * [[高校英語の文法/時制]] ※ 参考書によって微妙に単元名が異なるので暫定 * [[高校英語の文法/完了形]] * [[高校英語の文法/助動詞]] * [[高校英語の文法/不定詞]] * [[高校英語の文法/動名詞]] * * [[高校英語の文法/比較]] * [[高校英語の文法/関係詞]] * [[高校英語の文法/仮定法]] * [[高校英語の文法/名詞]] * [[高校英語の文法/冠詞]] * * [[高校英語の文法/否定]] * [[高校英語の文法/接続詞]] * [[高校英語の文法/前置詞]] == 文の構造 == === 文の要素 === 文の構造を知るためには、文がどのような要素で成り立っているのかを知らなければならない。 ==== 主語と述語動詞 ==== # '''The old man''' ''is'' a famous singer. # '''My sister''' ''studied'' math. ## 訳例:その老人'''は'''有名な歌手'''だ'''。 ## 訳例:私の姉'''は'''数学を研究'''していた'''。 1の文は「AはBだ」という文であり、2の文は「AはCする」という文である。どちらも # 「…は」「…が」という主題の部分 # 「～である」「～する」という主題が何であるかについて述べる部分 の二つが共通している。 この場合、1を'''主部'''といい、2を'''述部'''という。 そして、主部の中心となる語を'''主語'''(Subject)といい、述部の中心となる部分を'''述語動詞'''(Predicate Verb略して'''動詞'''('''Verb'''))という。以下では、述語動詞は原則として単に動詞と呼ぶ。 {| class="wikitable" style="text-align:center" |- ! || - || 主語 || 述語動詞 || - |- | - | colspan="2" | 主部 | colspan="2" | 述部 |- | 1. | The old | man | is | a famous singer. |- | 2. | My | sister | studied | math. |} 主語は単に'''S'''で表し、動詞は'''V'''で表す。 ==== 目的語 ==== # He ''has'' '''a personal computer'''. # We ''played'' '''soccer'''. # Everone ''likes'' '''Sushi'''. ## 訳例:彼はパソコン'''を'''持っている。 ## 訳例:私たちはサッカー'''を'''した。 ## 訳例:みんなが寿司'''を'''好む。 いずれの文の動詞も「～を」という、動作の対象が必要である。このような動作の対象を表す語を'''目的語'''(Object)といい、'''O'''で表す。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 目的語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | He | has | a personal computer. |- | 2. | We | played | soccer. |- | 3. | Everone | likes | Sushi. |} このような、'''S+V+O'''という形の文は英文の基本形の一つである。 ==== 補語 ==== # Mary ''is'' '''happy'''. # John ''became'' '''a doctor'''. ## 訳例:メアリーは幸せだ。 ## 訳例:ジョンは医者になった。 これらはいずれも主語の状態を説明した文であるが、isやbecomeで文を切ると意味をとれない。happyやa doctorという、主語の様子をおぎなう語があって初めて意味のある文となる。このように、主語の様子について説明する語を'''補語'''(Complement)という。補語は'''C'''で表される。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 補語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | Mary | is | happy. |- | 2. | John | became | a doctor. |} このような'''S+V+C'''の文も基本的な文の一つである。なお、後で学ぶように、補語は主語の様子だけでなく目的語の様子を説明する場合もある(例文:I call him Sensei.(私は彼を先生と呼ぶ))。 == 動詞の用法 == === 助動詞 === === 態 === ==== 助動詞と組み合わさった受動態 ==== He could be seen by her. 受動態の文を作るときには、その文の述語は必ずbe動詞の節になるが、be動詞に対して助動詞を用いたり、時制の変化をさせることも普通に行なわれる。 この時には、例えば He is seen by her. という文が He could be seen by her. の様にbe動詞は、助動詞+beの形で書き換えられる。これは、be動詞の原形が beで与えられることによる。同じ様に例えば、 might be may be must be will be なども用いることが出来る。また、過去形や現在完了と組み合わせるときにも通常の規則に従えばよい。例えば、上の文では He was seen by her. He has been seen by her. などとなる。been は be の過去分詞である。ここで、be が過去分詞 been になったのは、現在完了を作るためであり、see が過去分詞 seen になったのは、受動態を作るためであることに注意。 === 分詞 === == さまざまな構文 == === 分詞構文 === 分詞構文は現在分詞や過去分詞を用いて、従属の接続詞節のような意味を持つ文の成分を作る用法である。例文として、 Crying out something, he quickly runs away. がある。この文は「何かを叫びながら、彼は素早く逃げていった。」という 意味だが、この様な文は例えば接続詞whileを用いて、 While he cries out something, he quickly runs away 接続詞を取る。 He cries out something, he quickly runs away. 主語を取る。 Cries out some thing, he guickly runs away. 動詞を現在分詞形にする。 Crying out some thing, he quickly runs away.→'''これで完成！''' などとすることが出来る。分詞構文は文の前後関係から、省略される接続詞が予測できると考えられるとき、接続詞と主語を省略することによって 得られる。ただし、接続詞無しで節を作ることは出来ないことから、接続詞節の述語は対応する現在分詞になるのである。上の例文は while を用いた文から接続詞 while を省き、述語 cries を現在分詞 crying にすることに よって得たものと解釈出来る。ただし、元の従属接続詞節に対応する主文の主語と接続詞節の主語が等しいときには、現在分詞の主語は 省略出来る。上の文で while 節の主語に対応する語が無いのはこのことからである。 主節の主語と従属節の主語が異なっているときには、分詞構文の主語として対応する従属節の主語を所有格として与える。例えば、上の例で主語を省略せず書くと、 His crying out something, ... のようになる。 一般に現在分詞の主語を指定するときは通常所有格を用いる。 分詞構文で省略される接続詞には主なものとして、 because, since, as: 〜だから(理由) when, as, while: 〜のとき(ある時点) などがあげられる。 分詞構文になる従属節では述語がbe動詞であることがある。 このときにも上の規則に従って、Being -,によって分詞構文が作られることも多い。 ==== 分詞構文の受動態 ==== 特にbe動詞に対応する補語が受動態であったり、形容詞であるときには、beingを省いて過去分詞、もしくは形容詞から分詞構文が 始まることも多い。 (Being) seen from airport, everything looked small.（飛行機から見ると、全てのものが小さく見えた） The assignment (being) finished, we went on a hike to the nearby mountain.（その課題が終わってから、私たちは近くの山へハイキングへ行った。） このときには、be動詞と接続詞、必要なら対応する主語も補って考える必要がある。ただし、この様な省略がなされるのは、あくまで省略されたものが文脈からすぐに分かる時のみである。 === 話法 === === 会話表現 === == 品詞 == === 代名詞 === ==== 未分類 ==== 中学校では「代名詞」として、 he や she や we など、基本的な代名詞を習う。 もちろんそれも代名詞であるが、しかしそれ以外にも多くの代名詞がある。 たとえば the same （「同じもの」の意味）も代名詞である（青チャート、ジーニアス）。なぜなら、the same は、なにか具体的な名詞を言う代わりとして使われるのだから、the same も立派な代名詞である。 このように、代名詞は別に一語でなくても構わない。 なお、形容詞的に the same の直後につづけて名詞が来る場合もあり、「the same ～ as ・・・（名詞または代名詞）」で、「・・・と同じ ～」の意味。 こちらの構文では the same は代名詞というよりも形容詞としての用法だが、市販の参考書では都合上、代名詞の章でいっしょにthe same ～ as の構文も教えているのが通例である。 ともかく例文は、たとえば the same ～ as yours で「あなたのと同じ～」の意味（ジーニアス、エバーグリーン）。 the same shoes as yours なら「あなたのと同じ靴」だし（エバー）、 the same computer as yours なら「あなたのと同じコンピュータ」である（ジーニアス）。 一方、慣用的に、節が続く場合は as ではなく that の場合が多く the same man that I saw yesterday で「昨日見かけたのと同じ男の人」の意味だし（エバーの和訳を少し改造）、 the same song that I heard yesterday で「昨日聞いたのと同じ曲」の意味（ジーニアス）。 のように、 「the same ～ that ・・・（節）」 というのもある。 ただし、節が続く場合でも、べつに as を使ってもかまわず、つまり「 the same ～ as ・・・（節）」としてもマチガイではない（ブレイクスルー）。 those who ～ で「～な人々」の意味の代名詞である。 たとえばエバーグリーンいわく、 those who wish to smoke で「たばこを吸いたい人々」である。 such は代名詞として「そのようなもの」「そのような人」として扱われる場合もある。 たとえば He is an adult now, and should be treated as such. 「彼はもう大人なのだから、そのように扱うべきだ。」　※ジーニアス He is mere child, and should be treated as such. 「彼はまだほんの子供だから、子供として扱ってやるべきだ。」　※青チャート のように such はよく as such などとして使われる。 ==== some と any ==== {| class="wikitable" style="left" |+ 複合不定代名詞 ! 　 !! some- !! any- !! no- !! every- |- ! 人<br> -one<br> -body | 　someone <br>　somebody<br>（だれか） || 　anyone <br>　anybody<br>（だれか、だれでも） || no one （※ 離して書く）<br>　nobody<br>（だれも～ない） || 　everyone<br>　everybody<br>（だれでも） |- ! 物<br>-thing | 　something || 　anything 　|| nothing || everything |- |} some にも any にも「いくつかの」という意味がある。 よく参考書では、「 some は肯定文で使う。anyは疑問文・否定文で使う」などと習う（青チャート、ジーニアスなど）。 しかし桐原ファクトいわく、anyの基本的な意味は「どれでも」の意味である。any の「いくつかの」の意味は、「どれでも」の派生だと思うほうが良いだろう。 some と any の区別で悩んだ場合は、この「どれでも」の意味を基準に考えると良い。 だから肯定文であっても、「どれでも」の意味の形容詞には any を使う。 桐原ファクトいわく、疑問文で any を使う場合でも、ニュアンス的には「どれでも」の意味があるのが実際とのこと。否定文の any も同様。 この any の基本的な意味が「どれでも」の説に立てば、たとえば熟語 not ～ any が形容詞 no と同じ意味だということも、 not ～ any は「どれでもいいので存在してほしい（any）という事についてすら、それが成り立たない（not）。　→　つまり無い」というふうに理解できます。 なお、any の後ろに否定語を置くのは禁止されている（ジーニアス、青チャート）。 ほか、慣用的な表現として、よくお茶などやコーヒーの飲み物をすすめる際に、 Would you like some coffee? 「コーヒーはいかがですか」（桐原ファクト） Would you like some more tea? 「お茶のお代わりはいかがですか」（青チャート） のようにsome を使う。 青チャートいわく、some は、答えが Yes であることを期待しているニュアンスのある表現とのこと。そういう用法もある。なので、人にものを勧めるからには、some で質問しないと失礼になるので、someを使うのが当然とのこと。 実際にはsome も any もけっして意味中立的な表現ではなく、それぞれニュアンスがあるので、some と any を完全に使い分けるのは難しいだろう。 参考書にあるような代表的な事例についてだけ、some とanyを使い分ければ、とりあえずは平気だろう。 somebody と anybody などの使い分けも、上記の some と any に準じる（桐原ファクト）。 たとえば「誰かに出会いました」といいたい場合は、somebody を使うべきだと桐原は言っている。これがもしanybodyだと 「誰でもいいのですが、その人に会いました」（原文ママ（桐原））という内容の意味不明の文章になってしまうことからも分かるとして、桐原ファクトは誰かに会った事を言いたい場合には somebody を使うべきだと言っている。 ==== every とall の違い ==== 「すべての」という意味での every は形容詞であるが（インスパイア）、市販の参考書では便宜的に代名詞の章で紹介される。形容詞なので、every 単独ではあつかわれず、必ず直後に名詞または代名詞をともなう（インスパイア）。 every には「すべての」の意味もある（桐原ファクト、インスパイア）。しかし every と all には、ニュアンスの違いが明確に存在する。 また、every の後ろは単数形でなければならない。 every は、その全部を構成する一つ一つに関心がある文脈の場合に用いられる（桐原ファクト）。だから every で形容される名詞は必ず単数形でなければならないのも当然である（桐原ファクト）。また、everyは例外がないことを強調している（ジーニアス）。 each は2つ以上、every は3つ以上のものについて使用する。 なお、each は比較的に小さい個数のものに使い、everyは比較的に大きい数のものに使う（ジーニアス）。 each の使用対象はべつに2個限定でなくても構わない。 every と all には、こういったニュアンスの違いがあるので、参考書によってはevery の標準的な和訳を「すべての」以外で紹介する参考書も多い。 たとえば「あらゆる」「どの～も」という訳で every を紹介する参考書がよくある（青チャート、ブレイクスル－）。 なお、every には別の用法で「～（数詞のつく名詞）ごとに」の意味もあり、この場合は複数形になる。 たとえば every six hours で「6時間ごとに」である（ブレイクスルー）。 every four years で「四年ごとに」である（エバーグリーン）、なおオリンピックが四年ごとに開かれる　という文章。 なお、「一日おきに」は every other day である（インスパイア）。 {{コラム|every child を受ける代名詞は he か she か？| 桐原ファクトに書いてあるのですが、男女のどちらの場合もある単数の名詞について、それを代名詞で受ける際、 he か she かが、時代とともに変わっていきました。 もともとは、男女不明などの場合は、とりあえず he で代名詞を受けていました（桐原ファクト）。 だから every child も he で受けていました。 しかし、それが男女平等の観点に反するという意見が多くなり、近年になって、「 he/ she 」などと受ける代名詞が変わってきました。 「he / she 」はhe or she と読みます。 しかし、長くなるので会話などで不便でした（桐原ファクト）。 その不便さを解消するためか、さらに最近では、単数形であることを無視して every child のような名詞でも they で受けています（桐原ファクトの 2022年 第2版で確認）。 each も同様、最近では they で受けます（桐原ファクト）。 :※ 上記のような説が有名であるが、それに対する若干の異論もある。それは 「もともと he は男の代名詞ではなく性別不明の代名詞であり、もし、男である何らかの名詞についてそれを代名詞で受ける場合については、とりあえず性別不明の代名詞である he を当てるというルールだった」というような説です。 細かな出典は忘れましたが、たしか、日本どこかの有名大学に勤務している米英人の高齢の学者が、「自分はそう習った（heは性別不明の代名詞だと子供時代に習った）」とツイッターで主張していました。 この場合でも男女は不平等であります。しかし、女性差別とは言いがたい実態になります。 つまり、「女性を無視して男性を意味する he を使っていたのではなく、そもそも he は男女不明の代名詞であったが、女性専用の she という代名詞が存在していたため、あとからhe に男性の意味がついてきた。なのに『性別不明の名詞に he を使う事を女性差別だ』というフェミニズム言説は間違っている」という説です。 もしこの説「he は性別不明の代名詞だった」論のとおりなら（この説が間違っている可能性もありますので、どちらかに決め付けないように）、現代の各国の英語教育が、フェミニズミム運動などに配慮して代名詞 he の歴史の説明について、若干のウソをついている事になる可能性があります。 どちらの場合にせよ（数学の確率問題の場合わけのように、マジメに検証する人は両方の可能性を検討する）、参考書の桐原ファクトをよく読めば、性別不明の代名詞 he → he/she → they の変遷について「男女平等」という表現は説明に用いていますが、しかし「女性差別」という表現は用いていません。桐原ファクトの著者たちは、なかなか優秀です。こういう何気ない言葉の端々に、参考書の著者の優秀さが現れます。 まあ、私たちは背景事情にまでは深入りする必要はありません。上記のような異論もあることも承知した上で、異論もふくめた両者の合意である he → he/she → they という性別不明の単数代名詞の客観的事実を覚えれば済みます。 }} ==== その他 ==== 「those who ～」で「～する人々」 Heaven helps those who help themselves. 「天はみずから助くる者を助く。」（ことわざ）　※ 青チャート So do I. 「私もです。」 「So 動詞＋主語」 か「So 主語＋動詞」かで意味が違う。 「So 動詞＋主語」は、「主語もです」の意味。 「So 主語＋動詞 」 は「主語は確かにそうだ」の意味（インスパ代名詞、ジーニアス副詞）。 例文を出せば、たとえば So he is. 「確かに彼はそうだ」 Tom is kind. 「トムは親切だ。」 - So he is. 「確かに彼はそうだ（＝彼・トムは親切だ）。」 - So is John. 「ジョンもそうです。（＝トムだけでなくジョンも親切ですよ）」 のような違いがある。 === 形容詞・副詞 === ;副詞の位置 副詞の位置がどこに来るかについて、単語や文章によって様々である。 通常、英語では副詞の位置は、修飾対象に前置きである。 しかし very much や from time to time など複数語から構成される副詞表現になると、通常は文末または修飾対象の後ろに置かれるのが通常である（桐原ファクト）。 == 名詞構文・無生物主語 == === 名詞構文 === === 無生物主語 === The road takes you to the station. 「その道を歩いていくと駅につきます。」 The bus takes you to the station. 「そのバスに乗れば駅に行きます。」 take は「連れて行く」の意味だが、交通機関などを主語にして使うことも出来る。その場合は、たとえば道なら「その道を行けば、～につきます」のような意味になる。 takes の代わりに will take としても良い（ロイヤル英文法）。 「remind 人 of」 で「人に～を思い出させる」の意味である。 This picture reminds me of vacation in Greece. 「その写真を見ると、ギリシャでの休日を思い出す。」 This picture reminds me of holidays in London. 「その写真を見ると、ロンドンでの休日を思い出す。」 なお、大修館ジーニアスだとロンドン、桐原フォレストだとギリシャの例文。 「deprived 人 of ～」 「（機会などが）うばわれる」 The knee injury deprived him of the chance to play in the final game. 「ひざのけがのため、彼は決勝戦に出場する機会を失った。」 または The knee injury deprived the player of the chance to play in the game. 「ひざにけがをしたため、その選手は試合に出場する機会を失った。」 のように例文が参考書によくある。 enable ～ は、「～をできるようにする」「～を可能にする」の意味。「～のおかげで、・・・できるようになった」と訳すことができる。 The scholarship enabled him to go on to university. 「その奨学金のおかげで彼は大学へ進学できた。」 ジーニアス、ロイヤルに scholarship の似た例文。 == 疑問詞 == === 前置詞と疑問詞 === Where are you from? 出身はどちらですか？ 文法上、ここでの Where は副詞であり、「疑問副詞」というのに分類される（ロイヤル）。 さて、前置詞 from に注目しよう。 もしかしたら中学高校などで「前置詞は名詞や代名詞の前に移動するのが原則」とか習うかもしれないが、しかし前置詞をけっしてfromの前に移動しない。 なので、Where は副詞であると考えたほうが理解しやすいだろう。（これとは別の解釈で、そもそも「副詞には前置詞がいらない」という考えから副詞ではなく代名詞としての機能だと考える立場もあり、ジーニアスやロイヤルやフォレストがそういう立場。だが、机上の空論だろう。） なお、法学など幾つかの学問では、『原則』というのは例外のありうる規則、という意味である。おそらくジーニアスが「原則」という言葉を使っているのは、Where ～?などの疑問詞を文頭にもちいた疑問文の場合は例外的な事例という含みがあるのだろう。 Where に限らず、たとえば When などで疑問文を作るときも原則、それらの疑問詞の前には前置詞（When の場合は since や till や until など）を置かない。そのため、それら When の文でも前置詞は文末にくる場合が多くなる。 つまり、「いつから～？」なら When do you ～ since ? のような文章になる事が多い。 ただし、Whoの場合はやや例外的である。 たとえば前置詞 With を使う場合、Who が目的格 Whom に変化する場合もあり、 With whom do you ～? 「誰と一緒に～しますか？」 のようにWith が文頭にくる場合もある（桐原）。with以外の前置詞の場合でも文頭に持ってくる場合には同様にwhoではなく whom に変化する（ジーニアス）。なお、前置詞を文頭に持ってくる場合、whomを使わずにwho のままで文頭の前置詞の次に置くのは禁止である。 なお、Whomを使わずとも who のままで下記のように言うこともできる Who do you ～ with？ Where are you from? の場合、もし前置詞 from がないと、「あなたはどこ？」となり、それが出身をたずねているのか、それとも現在地をたずねているのか、意味が分からなくなることもあってか、ともかく 「Where are you from?」の文章は from を省略できない。 ジーニアスは、話し言葉ではWhereでは from を省略しないという言い方をしているが、しかし書き言葉であっても from を省略しないのが一般的であろう（省略したら上述のように意味が通らなり読み手に誤解を与えるので。）。 しかし、用いる動詞などによっては前置詞を省略できる場合があり、たとえば Where do you go to? 「どこに行きますか？」 なら、もし前置詞 to を省略しても、動詞 go から意味を推測できるので、この場合は to を省略されるのが許され、つまり Where do you go? でも許される（ジーニアス）。 このように文法の理論というのは、あまり論理的ではない。最終的には、英文法の学習では典型的な構文を覚えて、それを真似して使っていく必要がある。 === 慣用的な疑問文 === How about a cup of tea? 「お茶を一杯いかがですか？」 How about ～？ は勧誘を表す。 What do you say to ～ing 名詞/動名詞　？　「～はいかがですか？」「～しませんか」 What do you say to ～ing　でも勧誘を表せる。 ここでのsayの直後にある to は前置詞であると考えられている（桐原フォレスト）。どういうわけか、ジーニアスもロイヤルも、to が前置詞かどうかは言及していない。 ほか、Why don't you 動詞 ～　？ は、「～してはどうしょうか」のような相手に行為を促す（うながす）言い方であり、やや押し付けがましい言い方である（ジーニアス）。 Why don't we の形で、一緒になにかをする時に「～しましょうよ」の意味で使う場合もある（フォレスト）。 また、これを省略的に Why not ～？ の形で「～はどうですか」「～してはいかがでしょうか」「～しましょうよ」の意味にもある。 How come S + V ～？ How come ～？　は「どうして～」の意味でありwhy に近いが、How come のほうが感情的な表現であるので、目上の人に使うのは避けるのが良い（ジーニアス）。なお、How come は語順がSVと肯定形の語順になる。 How come you didn't call me ? 「どうして電話をくれなかったの？」 ※ 「電話してほしかったのに」のような含みがあり、相手を責めているようにも受け取られかねない。だから返事も、Sorry, 「ごめん」とかになる（ジーニアス）。 許可を求める表現である Do you mind if～? で、「～してもいいですか」という許可を求める表現ができる。なお Would you mind if ～? については仮定法になり、つまり「～」中の動詞が過去形になる。Would you mind if ～? については 『[[高校英語の文法/仮定法]]』で説明済み。 Do you mind if のほうは、if ～ の動詞は現在形で構わない。 == 参考文献についての注意 == サブページ中の参考文献で、現代2022年では廃止になったシリーズの桐原『フォレスト』などを掲げているが、現代でも他社の　いいずな出版『エバーグリーン』シリーズにフォレストの権利が引き継がれているようなので、わざわざ古本のフォレストを探す必要は無い。 [[カテゴリ:高等学校教育|ふむほふ]] aolfh1anqvzvh71mbkc3n2gc6ujwmul 206829 206828 2022-08-19T23:50:54Z すじにくシチュー 12058 /* その他 */ wikitext text/x-wiki <!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --> == 目次 == * [[高校英語の文法/文の種類]] * [[高校英語の文法/動詞と文型]] * [[高校英語の文法/時制]] ※ 参考書によって微妙に単元名が異なるので暫定 * [[高校英語の文法/完了形]] * [[高校英語の文法/助動詞]] * [[高校英語の文法/不定詞]] * [[高校英語の文法/動名詞]] * * [[高校英語の文法/比較]] * [[高校英語の文法/関係詞]] * [[高校英語の文法/仮定法]] * [[高校英語の文法/名詞]] * [[高校英語の文法/冠詞]] * * [[高校英語の文法/否定]] * [[高校英語の文法/接続詞]] * [[高校英語の文法/前置詞]] == 文の構造 == === 文の要素 === 文の構造を知るためには、文がどのような要素で成り立っているのかを知らなければならない。 ==== 主語と述語動詞 ==== # '''The old man''' ''is'' a famous singer. # '''My sister''' ''studied'' math. ## 訳例:その老人'''は'''有名な歌手'''だ'''。 ## 訳例:私の姉'''は'''数学を研究'''していた'''。 1の文は「AはBだ」という文であり、2の文は「AはCする」という文である。どちらも # 「…は」「…が」という主題の部分 # 「～である」「～する」という主題が何であるかについて述べる部分 の二つが共通している。 この場合、1を'''主部'''といい、2を'''述部'''という。 そして、主部の中心となる語を'''主語'''(Subject)といい、述部の中心となる部分を'''述語動詞'''(Predicate Verb略して'''動詞'''('''Verb'''))という。以下では、述語動詞は原則として単に動詞と呼ぶ。 {| class="wikitable" style="text-align:center" |- ! || - || 主語 || 述語動詞 || - |- | - | colspan="2" | 主部 | colspan="2" | 述部 |- | 1. | The old | man | is | a famous singer. |- | 2. | My | sister | studied | math. |} 主語は単に'''S'''で表し、動詞は'''V'''で表す。 ==== 目的語 ==== # He ''has'' '''a personal computer'''. # We ''played'' '''soccer'''. # Everone ''likes'' '''Sushi'''. ## 訳例:彼はパソコン'''を'''持っている。 ## 訳例:私たちはサッカー'''を'''した。 ## 訳例:みんなが寿司'''を'''好む。 いずれの文の動詞も「～を」という、動作の対象が必要である。このような動作の対象を表す語を'''目的語'''(Object)といい、'''O'''で表す。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 目的語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | He | has | a personal computer. |- | 2. | We | played | soccer. |- | 3. | Everone | likes | Sushi. |} このような、'''S+V+O'''という形の文は英文の基本形の一つである。 ==== 補語 ==== # Mary ''is'' '''happy'''. # John ''became'' '''a doctor'''. ## 訳例:メアリーは幸せだ。 ## 訳例:ジョンは医者になった。 これらはいずれも主語の状態を説明した文であるが、isやbecomeで文を切ると意味をとれない。happyやa doctorという、主語の様子をおぎなう語があって初めて意味のある文となる。このように、主語の様子について説明する語を'''補語'''(Complement)という。補語は'''C'''で表される。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 補語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | Mary | is | happy. |- | 2. | John | became | a doctor. |} このような'''S+V+C'''の文も基本的な文の一つである。なお、後で学ぶように、補語は主語の様子だけでなく目的語の様子を説明する場合もある(例文:I call him Sensei.(私は彼を先生と呼ぶ))。 == 動詞の用法 == === 助動詞 === === 態 === ==== 助動詞と組み合わさった受動態 ==== He could be seen by her. 受動態の文を作るときには、その文の述語は必ずbe動詞の節になるが、be動詞に対して助動詞を用いたり、時制の変化をさせることも普通に行なわれる。 この時には、例えば He is seen by her. という文が He could be seen by her. の様にbe動詞は、助動詞+beの形で書き換えられる。これは、be動詞の原形が beで与えられることによる。同じ様に例えば、 might be may be must be will be なども用いることが出来る。また、過去形や現在完了と組み合わせるときにも通常の規則に従えばよい。例えば、上の文では He was seen by her. He has been seen by her. などとなる。been は be の過去分詞である。ここで、be が過去分詞 been になったのは、現在完了を作るためであり、see が過去分詞 seen になったのは、受動態を作るためであることに注意。 === 分詞 === == さまざまな構文 == === 分詞構文 === 分詞構文は現在分詞や過去分詞を用いて、従属の接続詞節のような意味を持つ文の成分を作る用法である。例文として、 Crying out something, he quickly runs away. がある。この文は「何かを叫びながら、彼は素早く逃げていった。」という 意味だが、この様な文は例えば接続詞whileを用いて、 While he cries out something, he quickly runs away 接続詞を取る。 He cries out something, he quickly runs away. 主語を取る。 Cries out some thing, he guickly runs away. 動詞を現在分詞形にする。 Crying out some thing, he quickly runs away.→'''これで完成！''' などとすることが出来る。分詞構文は文の前後関係から、省略される接続詞が予測できると考えられるとき、接続詞と主語を省略することによって 得られる。ただし、接続詞無しで節を作ることは出来ないことから、接続詞節の述語は対応する現在分詞になるのである。上の例文は while を用いた文から接続詞 while を省き、述語 cries を現在分詞 crying にすることに よって得たものと解釈出来る。ただし、元の従属接続詞節に対応する主文の主語と接続詞節の主語が等しいときには、現在分詞の主語は 省略出来る。上の文で while 節の主語に対応する語が無いのはこのことからである。 主節の主語と従属節の主語が異なっているときには、分詞構文の主語として対応する従属節の主語を所有格として与える。例えば、上の例で主語を省略せず書くと、 His crying out something, ... のようになる。 一般に現在分詞の主語を指定するときは通常所有格を用いる。 分詞構文で省略される接続詞には主なものとして、 because, since, as: 〜だから(理由) when, as, while: 〜のとき(ある時点) などがあげられる。 分詞構文になる従属節では述語がbe動詞であることがある。 このときにも上の規則に従って、Being -,によって分詞構文が作られることも多い。 ==== 分詞構文の受動態 ==== 特にbe動詞に対応する補語が受動態であったり、形容詞であるときには、beingを省いて過去分詞、もしくは形容詞から分詞構文が 始まることも多い。 (Being) seen from airport, everything looked small.（飛行機から見ると、全てのものが小さく見えた） The assignment (being) finished, we went on a hike to the nearby mountain.（その課題が終わってから、私たちは近くの山へハイキングへ行った。） このときには、be動詞と接続詞、必要なら対応する主語も補って考える必要がある。ただし、この様な省略がなされるのは、あくまで省略されたものが文脈からすぐに分かる時のみである。 === 話法 === === 会話表現 === == 品詞 == === 代名詞 === ==== 未分類 ==== 中学校では「代名詞」として、 he や she や we など、基本的な代名詞を習う。 もちろんそれも代名詞であるが、しかしそれ以外にも多くの代名詞がある。 たとえば the same （「同じもの」の意味）も代名詞である（青チャート、ジーニアス）。なぜなら、the same は、なにか具体的な名詞を言う代わりとして使われるのだから、the same も立派な代名詞である。 このように、代名詞は別に一語でなくても構わない。 なお、形容詞的に the same の直後につづけて名詞が来る場合もあり、「the same ～ as ・・・（名詞または代名詞）」で、「・・・と同じ ～」の意味。 こちらの構文では the same は代名詞というよりも形容詞としての用法だが、市販の参考書では都合上、代名詞の章でいっしょにthe same ～ as の構文も教えているのが通例である。 ともかく例文は、たとえば the same ～ as yours で「あなたのと同じ～」の意味（ジーニアス、エバーグリーン）。 the same shoes as yours なら「あなたのと同じ靴」だし（エバー）、 the same computer as yours なら「あなたのと同じコンピュータ」である（ジーニアス）。 一方、慣用的に、節が続く場合は as ではなく that の場合が多く the same man that I saw yesterday で「昨日見かけたのと同じ男の人」の意味だし（エバーの和訳を少し改造）、 the same song that I heard yesterday で「昨日聞いたのと同じ曲」の意味（ジーニアス）。 のように、 「the same ～ that ・・・（節）」 というのもある。 ただし、節が続く場合でも、べつに as を使ってもかまわず、つまり「 the same ～ as ・・・（節）」としてもマチガイではない（ブレイクスルー）。 those who ～ で「～な人々」の意味の代名詞である。 たとえばエバーグリーンいわく、 those who wish to smoke で「たばこを吸いたい人々」である。 such は代名詞として「そのようなもの」「そのような人」として扱われる場合もある。 たとえば He is an adult now, and should be treated as such. 「彼はもう大人なのだから、そのように扱うべきだ。」　※ジーニアス He is mere child, and should be treated as such. 「彼はまだほんの子供だから、子供として扱ってやるべきだ。」　※青チャート のように such はよく as such などとして使われる。 ==== some と any ==== {| class="wikitable" style="left" |+ 複合不定代名詞 ! 　 !! some- !! any- !! no- !! every- |- ! 人<br> -one<br> -body | 　someone <br>　somebody<br>（だれか） || 　anyone <br>　anybody<br>（だれか、だれでも） || no one （※ 離して書く）<br>　nobody<br>（だれも～ない） || 　everyone<br>　everybody<br>（だれでも） |- ! 物<br>-thing | 　something || 　anything 　|| nothing || everything |- |} some にも any にも「いくつかの」という意味がある。 よく参考書では、「 some は肯定文で使う。anyは疑問文・否定文で使う」などと習う（青チャート、ジーニアスなど）。 しかし桐原ファクトいわく、anyの基本的な意味は「どれでも」の意味である。any の「いくつかの」の意味は、「どれでも」の派生だと思うほうが良いだろう。 some と any の区別で悩んだ場合は、この「どれでも」の意味を基準に考えると良い。 だから肯定文であっても、「どれでも」の意味の形容詞には any を使う。 桐原ファクトいわく、疑問文で any を使う場合でも、ニュアンス的には「どれでも」の意味があるのが実際とのこと。否定文の any も同様。 この any の基本的な意味が「どれでも」の説に立てば、たとえば熟語 not ～ any が形容詞 no と同じ意味だということも、 not ～ any は「どれでもいいので存在してほしい（any）という事についてすら、それが成り立たない（not）。　→　つまり無い」というふうに理解できます。 なお、any の後ろに否定語を置くのは禁止されている（ジーニアス、青チャート）。 ほか、慣用的な表現として、よくお茶などやコーヒーの飲み物をすすめる際に、 Would you like some coffee? 「コーヒーはいかがですか」（桐原ファクト） Would you like some more tea? 「お茶のお代わりはいかがですか」（青チャート） のようにsome を使う。 青チャートいわく、some は、答えが Yes であることを期待しているニュアンスのある表現とのこと。そういう用法もある。なので、人にものを勧めるからには、some で質問しないと失礼になるので、someを使うのが当然とのこと。 実際にはsome も any もけっして意味中立的な表現ではなく、それぞれニュアンスがあるので、some と any を完全に使い分けるのは難しいだろう。 参考書にあるような代表的な事例についてだけ、some とanyを使い分ければ、とりあえずは平気だろう。 somebody と anybody などの使い分けも、上記の some と any に準じる（桐原ファクト）。 たとえば「誰かに出会いました」といいたい場合は、somebody を使うべきだと桐原は言っている。これがもしanybodyだと 「誰でもいいのですが、その人に会いました」（原文ママ（桐原））という内容の意味不明の文章になってしまうことからも分かるとして、桐原ファクトは誰かに会った事を言いたい場合には somebody を使うべきだと言っている。 ==== every とall の違い ==== 「すべての」という意味での every は形容詞であるが（インスパイア）、市販の参考書では便宜的に代名詞の章で紹介される。形容詞なので、every 単独ではあつかわれず、必ず直後に名詞または代名詞をともなう（インスパイア）。 every には「すべての」の意味もある（桐原ファクト、インスパイア）。しかし every と all には、ニュアンスの違いが明確に存在する。 また、every の後ろは単数形でなければならない。 every は、その全部を構成する一つ一つに関心がある文脈の場合に用いられる（桐原ファクト）。だから every で形容される名詞は必ず単数形でなければならないのも当然である（桐原ファクト）。また、everyは例外がないことを強調している（ジーニアス）。 each は2つ以上、every は3つ以上のものについて使用する。 なお、each は比較的に小さい個数のものに使い、everyは比較的に大きい数のものに使う（ジーニアス）。 each の使用対象はべつに2個限定でなくても構わない。 every と all には、こういったニュアンスの違いがあるので、参考書によってはevery の標準的な和訳を「すべての」以外で紹介する参考書も多い。 たとえば「あらゆる」「どの～も」という訳で every を紹介する参考書がよくある（青チャート、ブレイクスル－）。 なお、every には別の用法で「～（数詞のつく名詞）ごとに」の意味もあり、この場合は複数形になる。 たとえば every six hours で「6時間ごとに」である（ブレイクスルー）。 every four years で「四年ごとに」である（エバーグリーン）、なおオリンピックが四年ごとに開かれる　という文章。 なお、「一日おきに」は every other day である（インスパイア）。 {{コラム|every child を受ける代名詞は he か she か？| 桐原ファクトに書いてあるのですが、男女のどちらの場合もある単数の名詞について、それを代名詞で受ける際、 he か she かが、時代とともに変わっていきました。 もともとは、男女不明などの場合は、とりあえず he で代名詞を受けていました（桐原ファクト）。 だから every child も he で受けていました。 しかし、それが男女平等の観点に反するという意見が多くなり、近年になって、「 he/ she 」などと受ける代名詞が変わってきました。 「he / she 」はhe or she と読みます。 しかし、長くなるので会話などで不便でした（桐原ファクト）。 その不便さを解消するためか、さらに最近では、単数形であることを無視して every child のような名詞でも they で受けています（桐原ファクトの 2022年 第2版で確認）。 each も同様、最近では they で受けます（桐原ファクト）。 :※ 上記のような説が有名であるが、それに対する若干の異論もある。それは 「もともと he は男の代名詞ではなく性別不明の代名詞であり、もし、男である何らかの名詞についてそれを代名詞で受ける場合については、とりあえず性別不明の代名詞である he を当てるというルールだった」というような説です。 細かな出典は忘れましたが、たしか、日本どこかの有名大学に勤務している米英人の高齢の学者が、「自分はそう習った（heは性別不明の代名詞だと子供時代に習った）」とツイッターで主張していました。 この場合でも男女は不平等であります。しかし、女性差別とは言いがたい実態になります。 つまり、「女性を無視して男性を意味する he を使っていたのではなく、そもそも he は男女不明の代名詞であったが、女性専用の she という代名詞が存在していたため、あとからhe に男性の意味がついてきた。なのに『性別不明の名詞に he を使う事を女性差別だ』というフェミニズム言説は間違っている」という説です。 もしこの説「he は性別不明の代名詞だった」論のとおりなら（この説が間違っている可能性もありますので、どちらかに決め付けないように）、現代の各国の英語教育が、フェミニズミム運動などに配慮して代名詞 he の歴史の説明について、若干のウソをついている事になる可能性があります。 どちらの場合にせよ（数学の確率問題の場合わけのように、マジメに検証する人は両方の可能性を検討する）、参考書の桐原ファクトをよく読めば、性別不明の代名詞 he → he/she → they の変遷について「男女平等」という表現は説明に用いていますが、しかし「女性差別」という表現は用いていません。桐原ファクトの著者たちは、なかなか優秀です。こういう何気ない言葉の端々に、参考書の著者の優秀さが現れます。 まあ、私たちは背景事情にまでは深入りする必要はありません。上記のような異論もあることも承知した上で、異論もふくめた両者の合意である he → he/she → they という性別不明の単数代名詞の客観的事実を覚えれば済みます。 }} ==== その他 ==== 「those who ～」で「～する人々」 Heaven helps those who help themselves. 「天はみずから助くる者を助く。」（ことわざ）　※ 青チャート So do I. 「私もです。」 「So 動詞＋主語」 か「So 主語＋動詞」かで意味が違う。 「So 動詞＋主語」は、「主語もです」の意味。 「So 主語＋動詞 」 は「主語は確かにそうだ」の意味（インスパ代名詞、ジーニアス副詞）。 例文を出せば、たとえば So he is. 「確かに彼はそうだ」 Tom is kind. 「トムは親切だ。」 - So he is. 「確かに彼はそうだ（＝彼・トムは親切だ）。」 - So is John. 「ジョンもそうです。（＝トムだけでなくジョンも親切ですよ）」 のような違いがある。 Tom can French well. 「トムはフランス語を上手に話せます」 - So he can. 「確かに彼はそうだ」 - So can John. 「ジョンもフランス語が上手ですよ」 ※ 青チャにcanで似た例文 === 形容詞・副詞 === ;副詞の位置 副詞の位置がどこに来るかについて、単語や文章によって様々である。 通常、英語では副詞の位置は、修飾対象に前置きである。 しかし very much や from time to time など複数語から構成される副詞表現になると、通常は文末または修飾対象の後ろに置かれるのが通常である（桐原ファクト）。 == 名詞構文・無生物主語 == === 名詞構文 === === 無生物主語 === The road takes you to the station. 「その道を歩いていくと駅につきます。」 The bus takes you to the station. 「そのバスに乗れば駅に行きます。」 take は「連れて行く」の意味だが、交通機関などを主語にして使うことも出来る。その場合は、たとえば道なら「その道を行けば、～につきます」のような意味になる。 takes の代わりに will take としても良い（ロイヤル英文法）。 「remind 人 of」 で「人に～を思い出させる」の意味である。 This picture reminds me of vacation in Greece. 「その写真を見ると、ギリシャでの休日を思い出す。」 This picture reminds me of holidays in London. 「その写真を見ると、ロンドンでの休日を思い出す。」 なお、大修館ジーニアスだとロンドン、桐原フォレストだとギリシャの例文。 「deprived 人 of ～」 「（機会などが）うばわれる」 The knee injury deprived him of the chance to play in the final game. 「ひざのけがのため、彼は決勝戦に出場する機会を失った。」 または The knee injury deprived the player of the chance to play in the game. 「ひざにけがをしたため、その選手は試合に出場する機会を失った。」 のように例文が参考書によくある。 enable ～ は、「～をできるようにする」「～を可能にする」の意味。「～のおかげで、・・・できるようになった」と訳すことができる。 The scholarship enabled him to go on to university. 「その奨学金のおかげで彼は大学へ進学できた。」 ジーニアス、ロイヤルに scholarship の似た例文。 == 疑問詞 == === 前置詞と疑問詞 === Where are you from? 出身はどちらですか？ 文法上、ここでの Where は副詞であり、「疑問副詞」というのに分類される（ロイヤル）。 さて、前置詞 from に注目しよう。 もしかしたら中学高校などで「前置詞は名詞や代名詞の前に移動するのが原則」とか習うかもしれないが、しかし前置詞をけっしてfromの前に移動しない。 なので、Where は副詞であると考えたほうが理解しやすいだろう。（これとは別の解釈で、そもそも「副詞には前置詞がいらない」という考えから副詞ではなく代名詞としての機能だと考える立場もあり、ジーニアスやロイヤルやフォレストがそういう立場。だが、机上の空論だろう。） なお、法学など幾つかの学問では、『原則』というのは例外のありうる規則、という意味である。おそらくジーニアスが「原則」という言葉を使っているのは、Where ～?などの疑問詞を文頭にもちいた疑問文の場合は例外的な事例という含みがあるのだろう。 Where に限らず、たとえば When などで疑問文を作るときも原則、それらの疑問詞の前には前置詞（When の場合は since や till や until など）を置かない。そのため、それら When の文でも前置詞は文末にくる場合が多くなる。 つまり、「いつから～？」なら When do you ～ since ? のような文章になる事が多い。 ただし、Whoの場合はやや例外的である。 たとえば前置詞 With を使う場合、Who が目的格 Whom に変化する場合もあり、 With whom do you ～? 「誰と一緒に～しますか？」 のようにWith が文頭にくる場合もある（桐原）。with以外の前置詞の場合でも文頭に持ってくる場合には同様にwhoではなく whom に変化する（ジーニアス）。なお、前置詞を文頭に持ってくる場合、whomを使わずにwho のままで文頭の前置詞の次に置くのは禁止である。 なお、Whomを使わずとも who のままで下記のように言うこともできる Who do you ～ with？ Where are you from? の場合、もし前置詞 from がないと、「あなたはどこ？」となり、それが出身をたずねているのか、それとも現在地をたずねているのか、意味が分からなくなることもあってか、ともかく 「Where are you from?」の文章は from を省略できない。 ジーニアスは、話し言葉ではWhereでは from を省略しないという言い方をしているが、しかし書き言葉であっても from を省略しないのが一般的であろう（省略したら上述のように意味が通らなり読み手に誤解を与えるので。）。 しかし、用いる動詞などによっては前置詞を省略できる場合があり、たとえば Where do you go to? 「どこに行きますか？」 なら、もし前置詞 to を省略しても、動詞 go から意味を推測できるので、この場合は to を省略されるのが許され、つまり Where do you go? でも許される（ジーニアス）。 このように文法の理論というのは、あまり論理的ではない。最終的には、英文法の学習では典型的な構文を覚えて、それを真似して使っていく必要がある。 === 慣用的な疑問文 === How about a cup of tea? 「お茶を一杯いかがですか？」 How about ～？ は勧誘を表す。 What do you say to ～ing 名詞/動名詞　？　「～はいかがですか？」「～しませんか」 What do you say to ～ing　でも勧誘を表せる。 ここでのsayの直後にある to は前置詞であると考えられている（桐原フォレスト）。どういうわけか、ジーニアスもロイヤルも、to が前置詞かどうかは言及していない。 ほか、Why don't you 動詞 ～　？ は、「～してはどうしょうか」のような相手に行為を促す（うながす）言い方であり、やや押し付けがましい言い方である（ジーニアス）。 Why don't we の形で、一緒になにかをする時に「～しましょうよ」の意味で使う場合もある（フォレスト）。 また、これを省略的に Why not ～？ の形で「～はどうですか」「～してはいかがでしょうか」「～しましょうよ」の意味にもある。 How come S + V ～？ How come ～？　は「どうして～」の意味でありwhy に近いが、How come のほうが感情的な表現であるので、目上の人に使うのは避けるのが良い（ジーニアス）。なお、How come は語順がSVと肯定形の語順になる。 How come you didn't call me ? 「どうして電話をくれなかったの？」 ※ 「電話してほしかったのに」のような含みがあり、相手を責めているようにも受け取られかねない。だから返事も、Sorry, 「ごめん」とかになる（ジーニアス）。 許可を求める表現である Do you mind if～? で、「～してもいいですか」という許可を求める表現ができる。なお Would you mind if ～? については仮定法になり、つまり「～」中の動詞が過去形になる。Would you mind if ～? については 『[[高校英語の文法/仮定法]]』で説明済み。 Do you mind if のほうは、if ～ の動詞は現在形で構わない。 == 参考文献についての注意 == サブページ中の参考文献で、現代2022年では廃止になったシリーズの桐原『フォレスト』などを掲げているが、現代でも他社の　いいずな出版『エバーグリーン』シリーズにフォレストの権利が引き継がれているようなので、わざわざ古本のフォレストを探す必要は無い。 [[カテゴリ:高等学校教育|ふむほふ]] 83kc9vli9vwudfa3wv2udtglghhoj5r 206830 206829 2022-08-20T00:57:34Z すじにくシチュー 12058 /* some と any */ Everybody's business is nobody's business. 「みなの仕事は誰の仕事でもない」（直訳）→「共同責任は無責任」（ことわざ） wikitext text/x-wiki <!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --> == 目次 == * [[高校英語の文法/文の種類]] * [[高校英語の文法/動詞と文型]] * [[高校英語の文法/時制]] ※ 参考書によって微妙に単元名が異なるので暫定 * [[高校英語の文法/完了形]] * [[高校英語の文法/助動詞]] * [[高校英語の文法/不定詞]] * [[高校英語の文法/動名詞]] * * [[高校英語の文法/比較]] * [[高校英語の文法/関係詞]] * [[高校英語の文法/仮定法]] * [[高校英語の文法/名詞]] * [[高校英語の文法/冠詞]] * * [[高校英語の文法/否定]] * [[高校英語の文法/接続詞]] * [[高校英語の文法/前置詞]] == 文の構造 == === 文の要素 === 文の構造を知るためには、文がどのような要素で成り立っているのかを知らなければならない。 ==== 主語と述語動詞 ==== # '''The old man''' ''is'' a famous singer. # '''My sister''' ''studied'' math. ## 訳例:その老人'''は'''有名な歌手'''だ'''。 ## 訳例:私の姉'''は'''数学を研究'''していた'''。 1の文は「AはBだ」という文であり、2の文は「AはCする」という文である。どちらも # 「…は」「…が」という主題の部分 # 「～である」「～する」という主題が何であるかについて述べる部分 の二つが共通している。 この場合、1を'''主部'''といい、2を'''述部'''という。 そして、主部の中心となる語を'''主語'''(Subject)といい、述部の中心となる部分を'''述語動詞'''(Predicate Verb略して'''動詞'''('''Verb'''))という。以下では、述語動詞は原則として単に動詞と呼ぶ。 {| class="wikitable" style="text-align:center" |- ! || - || 主語 || 述語動詞 || - |- | - | colspan="2" | 主部 | colspan="2" | 述部 |- | 1. | The old | man | is | a famous singer. |- | 2. | My | sister | studied | math. |} 主語は単に'''S'''で表し、動詞は'''V'''で表す。 ==== 目的語 ==== # He ''has'' '''a personal computer'''. # We ''played'' '''soccer'''. # Everone ''likes'' '''Sushi'''. ## 訳例:彼はパソコン'''を'''持っている。 ## 訳例:私たちはサッカー'''を'''した。 ## 訳例:みんなが寿司'''を'''好む。 いずれの文の動詞も「～を」という、動作の対象が必要である。このような動作の対象を表す語を'''目的語'''(Object)といい、'''O'''で表す。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 目的語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | He | has | a personal computer. |- | 2. | We | played | soccer. |- | 3. | Everone | likes | Sushi. |} このような、'''S+V+O'''という形の文は英文の基本形の一つである。 ==== 補語 ==== # Mary ''is'' '''happy'''. # John ''became'' '''a doctor'''. ## 訳例:メアリーは幸せだ。 ## 訳例:ジョンは医者になった。 これらはいずれも主語の状態を説明した文であるが、isやbecomeで文を切ると意味をとれない。happyやa doctorという、主語の様子をおぎなう語があって初めて意味のある文となる。このように、主語の様子について説明する語を'''補語'''(Complement)という。補語は'''C'''で表される。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 補語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | Mary | is | happy. |- | 2. | John | became | a doctor. |} このような'''S+V+C'''の文も基本的な文の一つである。なお、後で学ぶように、補語は主語の様子だけでなく目的語の様子を説明する場合もある(例文:I call him Sensei.(私は彼を先生と呼ぶ))。 == 動詞の用法 == === 助動詞 === === 態 === ==== 助動詞と組み合わさった受動態 ==== He could be seen by her. 受動態の文を作るときには、その文の述語は必ずbe動詞の節になるが、be動詞に対して助動詞を用いたり、時制の変化をさせることも普通に行なわれる。 この時には、例えば He is seen by her. という文が He could be seen by her. の様にbe動詞は、助動詞+beの形で書き換えられる。これは、be動詞の原形が beで与えられることによる。同じ様に例えば、 might be may be must be will be なども用いることが出来る。また、過去形や現在完了と組み合わせるときにも通常の規則に従えばよい。例えば、上の文では He was seen by her. He has been seen by her. などとなる。been は be の過去分詞である。ここで、be が過去分詞 been になったのは、現在完了を作るためであり、see が過去分詞 seen になったのは、受動態を作るためであることに注意。 === 分詞 === == さまざまな構文 == === 分詞構文 === 分詞構文は現在分詞や過去分詞を用いて、従属の接続詞節のような意味を持つ文の成分を作る用法である。例文として、 Crying out something, he quickly runs away. がある。この文は「何かを叫びながら、彼は素早く逃げていった。」という 意味だが、この様な文は例えば接続詞whileを用いて、 While he cries out something, he quickly runs away 接続詞を取る。 He cries out something, he quickly runs away. 主語を取る。 Cries out some thing, he guickly runs away. 動詞を現在分詞形にする。 Crying out some thing, he quickly runs away.→'''これで完成！''' などとすることが出来る。分詞構文は文の前後関係から、省略される接続詞が予測できると考えられるとき、接続詞と主語を省略することによって 得られる。ただし、接続詞無しで節を作ることは出来ないことから、接続詞節の述語は対応する現在分詞になるのである。上の例文は while を用いた文から接続詞 while を省き、述語 cries を現在分詞 crying にすることに よって得たものと解釈出来る。ただし、元の従属接続詞節に対応する主文の主語と接続詞節の主語が等しいときには、現在分詞の主語は 省略出来る。上の文で while 節の主語に対応する語が無いのはこのことからである。 主節の主語と従属節の主語が異なっているときには、分詞構文の主語として対応する従属節の主語を所有格として与える。例えば、上の例で主語を省略せず書くと、 His crying out something, ... のようになる。 一般に現在分詞の主語を指定するときは通常所有格を用いる。 分詞構文で省略される接続詞には主なものとして、 because, since, as: 〜だから(理由) when, as, while: 〜のとき(ある時点) などがあげられる。 分詞構文になる従属節では述語がbe動詞であることがある。 このときにも上の規則に従って、Being -,によって分詞構文が作られることも多い。 ==== 分詞構文の受動態 ==== 特にbe動詞に対応する補語が受動態であったり、形容詞であるときには、beingを省いて過去分詞、もしくは形容詞から分詞構文が 始まることも多い。 (Being) seen from airport, everything looked small.（飛行機から見ると、全てのものが小さく見えた） The assignment (being) finished, we went on a hike to the nearby mountain.（その課題が終わってから、私たちは近くの山へハイキングへ行った。） このときには、be動詞と接続詞、必要なら対応する主語も補って考える必要がある。ただし、この様な省略がなされるのは、あくまで省略されたものが文脈からすぐに分かる時のみである。 === 話法 === === 会話表現 === == 品詞 == === 代名詞 === ==== 未分類 ==== 中学校では「代名詞」として、 he や she や we など、基本的な代名詞を習う。 もちろんそれも代名詞であるが、しかしそれ以外にも多くの代名詞がある。 たとえば the same （「同じもの」の意味）も代名詞である（青チャート、ジーニアス）。なぜなら、the same は、なにか具体的な名詞を言う代わりとして使われるのだから、the same も立派な代名詞である。 このように、代名詞は別に一語でなくても構わない。 なお、形容詞的に the same の直後につづけて名詞が来る場合もあり、「the same ～ as ・・・（名詞または代名詞）」で、「・・・と同じ ～」の意味。 こちらの構文では the same は代名詞というよりも形容詞としての用法だが、市販の参考書では都合上、代名詞の章でいっしょにthe same ～ as の構文も教えているのが通例である。 ともかく例文は、たとえば the same ～ as yours で「あなたのと同じ～」の意味（ジーニアス、エバーグリーン）。 the same shoes as yours なら「あなたのと同じ靴」だし（エバー）、 the same computer as yours なら「あなたのと同じコンピュータ」である（ジーニアス）。 一方、慣用的に、節が続く場合は as ではなく that の場合が多く the same man that I saw yesterday で「昨日見かけたのと同じ男の人」の意味だし（エバーの和訳を少し改造）、 the same song that I heard yesterday で「昨日聞いたのと同じ曲」の意味（ジーニアス）。 のように、 「the same ～ that ・・・（節）」 というのもある。 ただし、節が続く場合でも、べつに as を使ってもかまわず、つまり「 the same ～ as ・・・（節）」としてもマチガイではない（ブレイクスルー）。 those who ～ で「～な人々」の意味の代名詞である。 たとえばエバーグリーンいわく、 those who wish to smoke で「たばこを吸いたい人々」である。 such は代名詞として「そのようなもの」「そのような人」として扱われる場合もある。 たとえば He is an adult now, and should be treated as such. 「彼はもう大人なのだから、そのように扱うべきだ。」　※ジーニアス He is mere child, and should be treated as such. 「彼はまだほんの子供だから、子供として扱ってやるべきだ。」　※青チャート のように such はよく as such などとして使われる。 ==== some と any ==== {| class="wikitable" style="left" |+ 複合不定代名詞 ! 　 !! some- !! any- !! no- !! every- |- ! 人<br> -one<br> -body | 　someone <br>　somebody<br>（だれか） || 　anyone <br>　anybody<br>（だれか、だれでも） || no one （※ 離して書く）<br>　nobody<br>（だれも～ない） || 　everyone<br>　everybody<br>（だれでも） |- ! 物<br>-thing | 　something || 　anything 　|| nothing || everything |- |} some にも any にも「いくつかの」という意味がある。 よく参考書では、「 some は肯定文で使う。anyは疑問文・否定文で使う」などと習う（青チャート、ジーニアスなど）。 しかし桐原ファクトいわく、anyの基本的な意味は「どれでも」の意味である。any の「いくつかの」の意味は、「どれでも」の派生だと思うほうが良いだろう。 some と any の区別で悩んだ場合は、この「どれでも」の意味を基準に考えると良い。 だから肯定文であっても、「どれでも」の意味の形容詞には any を使う。 桐原ファクトいわく、疑問文で any を使う場合でも、ニュアンス的には「どれでも」の意味があるのが実際とのこと。否定文の any も同様。 この any の基本的な意味が「どれでも」の説に立てば、たとえば熟語 not ～ any が形容詞 no と同じ意味だということも、 not ～ any は「どれでもいいので存在してほしい（any）という事についてすら、それが成り立たない（not）。　→　つまり無い」というふうに理解できます。 なお、any の後ろに否定語を置くのは禁止されている（ジーニアス、青チャート）。 ほか、慣用的な表現として、よくお茶などやコーヒーの飲み物をすすめる際に、 Would you like some coffee? 「コーヒーはいかがですか」（桐原ファクト） Would you like some more tea? 「お茶のお代わりはいかがですか」（青チャート） のようにsome を使う。 青チャートいわく、some は、答えが Yes であることを期待しているニュアンスのある表現とのこと。そういう用法もある。なので、人にものを勧めるからには、some で質問しないと失礼になるので、someを使うのが当然とのこと。 実際にはsome も any もけっして意味中立的な表現ではなく、それぞれニュアンスがあるので、some と any を完全に使い分けるのは難しいだろう。 参考書にあるような代表的な事例についてだけ、some とanyを使い分ければ、とりあえずは平気だろう。 somebody と anybody などの使い分けも、上記の some と any に準じる（桐原ファクト）。 たとえば「誰かに出会いました」といいたい場合は、somebody を使うべきだと桐原は言っている。これがもしanybodyだと 「誰でもいいのですが、その人に会いました」（原文ママ（桐原））という内容の意味不明の文章になってしまうことからも分かるとして、桐原ファクトは誰かに会った事を言いたい場合には somebody を使うべきだと言っている。 Everybody's business is nobody's business. 「みなの仕事は誰の仕事でもない」（直訳）→「共同責任は無責任」（ことわざ） ※ 「共同責任は無責任」の部分がことわざ。青チャートがこの　ことわざ　を紹介。 ==== every とall の違い ==== 「すべての」という意味での every は形容詞であるが（インスパイア）、市販の参考書では便宜的に代名詞の章で紹介される。形容詞なので、every 単独ではあつかわれず、必ず直後に名詞または代名詞をともなう（インスパイア）。 every には「すべての」の意味もある（桐原ファクト、インスパイア）。しかし every と all には、ニュアンスの違いが明確に存在する。 また、every の後ろは単数形でなければならない。 every は、その全部を構成する一つ一つに関心がある文脈の場合に用いられる（桐原ファクト）。だから every で形容される名詞は必ず単数形でなければならないのも当然である（桐原ファクト）。また、everyは例外がないことを強調している（ジーニアス）。 each は2つ以上、every は3つ以上のものについて使用する。 なお、each は比較的に小さい個数のものに使い、everyは比較的に大きい数のものに使う（ジーニアス）。 each の使用対象はべつに2個限定でなくても構わない。 every と all には、こういったニュアンスの違いがあるので、参考書によってはevery の標準的な和訳を「すべての」以外で紹介する参考書も多い。 たとえば「あらゆる」「どの～も」という訳で every を紹介する参考書がよくある（青チャート、ブレイクスル－）。 なお、every には別の用法で「～（数詞のつく名詞）ごとに」の意味もあり、この場合は複数形になる。 たとえば every six hours で「6時間ごとに」である（ブレイクスルー）。 every four years で「四年ごとに」である（エバーグリーン）、なおオリンピックが四年ごとに開かれる　という文章。 なお、「一日おきに」は every other day である（インスパイア）。 {{コラム|every child を受ける代名詞は he か she か？| 桐原ファクトに書いてあるのですが、男女のどちらの場合もある単数の名詞について、それを代名詞で受ける際、 he か she かが、時代とともに変わっていきました。 もともとは、男女不明などの場合は、とりあえず he で代名詞を受けていました（桐原ファクト）。 だから every child も he で受けていました。 しかし、それが男女平等の観点に反するという意見が多くなり、近年になって、「 he/ she 」などと受ける代名詞が変わってきました。 「he / she 」はhe or she と読みます。 しかし、長くなるので会話などで不便でした（桐原ファクト）。 その不便さを解消するためか、さらに最近では、単数形であることを無視して every child のような名詞でも they で受けています（桐原ファクトの 2022年 第2版で確認）。 each も同様、最近では they で受けます（桐原ファクト）。 :※ 上記のような説が有名であるが、それに対する若干の異論もある。それは 「もともと he は男の代名詞ではなく性別不明の代名詞であり、もし、男である何らかの名詞についてそれを代名詞で受ける場合については、とりあえず性別不明の代名詞である he を当てるというルールだった」というような説です。 細かな出典は忘れましたが、たしか、日本どこかの有名大学に勤務している米英人の高齢の学者が、「自分はそう習った（heは性別不明の代名詞だと子供時代に習った）」とツイッターで主張していました。 この場合でも男女は不平等であります。しかし、女性差別とは言いがたい実態になります。 つまり、「女性を無視して男性を意味する he を使っていたのではなく、そもそも he は男女不明の代名詞であったが、女性専用の she という代名詞が存在していたため、あとからhe に男性の意味がついてきた。なのに『性別不明の名詞に he を使う事を女性差別だ』というフェミニズム言説は間違っている」という説です。 もしこの説「he は性別不明の代名詞だった」論のとおりなら（この説が間違っている可能性もありますので、どちらかに決め付けないように）、現代の各国の英語教育が、フェミニズミム運動などに配慮して代名詞 he の歴史の説明について、若干のウソをついている事になる可能性があります。 どちらの場合にせよ（数学の確率問題の場合わけのように、マジメに検証する人は両方の可能性を検討する）、参考書の桐原ファクトをよく読めば、性別不明の代名詞 he → he/she → they の変遷について「男女平等」という表現は説明に用いていますが、しかし「女性差別」という表現は用いていません。桐原ファクトの著者たちは、なかなか優秀です。こういう何気ない言葉の端々に、参考書の著者の優秀さが現れます。 まあ、私たちは背景事情にまでは深入りする必要はありません。上記のような異論もあることも承知した上で、異論もふくめた両者の合意である he → he/she → they という性別不明の単数代名詞の客観的事実を覚えれば済みます。 }} ==== その他 ==== 「those who ～」で「～する人々」 Heaven helps those who help themselves. 「天はみずから助くる者を助く。」（ことわざ）　※ 青チャート So do I. 「私もです。」 「So 動詞＋主語」 か「So 主語＋動詞」かで意味が違う。 「So 動詞＋主語」は、「主語もです」の意味。 「So 主語＋動詞 」 は「主語は確かにそうだ」の意味（インスパ代名詞、ジーニアス副詞）。 例文を出せば、たとえば So he is. 「確かに彼はそうだ」 Tom is kind. 「トムは親切だ。」 - So he is. 「確かに彼はそうだ（＝彼・トムは親切だ）。」 - So is John. 「ジョンもそうです。（＝トムだけでなくジョンも親切ですよ）」 のような違いがある。 Tom can French well. 「トムはフランス語を上手に話せます」 - So he can. 「確かに彼はそうだ」 - So can John. 「ジョンもフランス語が上手ですよ」 ※ 青チャにcanで似た例文 === 形容詞・副詞 === ;副詞の位置 副詞の位置がどこに来るかについて、単語や文章によって様々である。 通常、英語では副詞の位置は、修飾対象に前置きである。 しかし very much や from time to time など複数語から構成される副詞表現になると、通常は文末または修飾対象の後ろに置かれるのが通常である（桐原ファクト）。 == 名詞構文・無生物主語 == === 名詞構文 === === 無生物主語 === The road takes you to the station. 「その道を歩いていくと駅につきます。」 The bus takes you to the station. 「そのバスに乗れば駅に行きます。」 take は「連れて行く」の意味だが、交通機関などを主語にして使うことも出来る。その場合は、たとえば道なら「その道を行けば、～につきます」のような意味になる。 takes の代わりに will take としても良い（ロイヤル英文法）。 「remind 人 of」 で「人に～を思い出させる」の意味である。 This picture reminds me of vacation in Greece. 「その写真を見ると、ギリシャでの休日を思い出す。」 This picture reminds me of holidays in London. 「その写真を見ると、ロンドンでの休日を思い出す。」 なお、大修館ジーニアスだとロンドン、桐原フォレストだとギリシャの例文。 「deprived 人 of ～」 「（機会などが）うばわれる」 The knee injury deprived him of the chance to play in the final game. 「ひざのけがのため、彼は決勝戦に出場する機会を失った。」 または The knee injury deprived the player of the chance to play in the game. 「ひざにけがをしたため、その選手は試合に出場する機会を失った。」 のように例文が参考書によくある。 enable ～ は、「～をできるようにする」「～を可能にする」の意味。「～のおかげで、・・・できるようになった」と訳すことができる。 The scholarship enabled him to go on to university. 「その奨学金のおかげで彼は大学へ進学できた。」 ジーニアス、ロイヤルに scholarship の似た例文。 == 疑問詞 == === 前置詞と疑問詞 === Where are you from? 出身はどちらですか？ 文法上、ここでの Where は副詞であり、「疑問副詞」というのに分類される（ロイヤル）。 さて、前置詞 from に注目しよう。 もしかしたら中学高校などで「前置詞は名詞や代名詞の前に移動するのが原則」とか習うかもしれないが、しかし前置詞をけっしてfromの前に移動しない。 なので、Where は副詞であると考えたほうが理解しやすいだろう。（これとは別の解釈で、そもそも「副詞には前置詞がいらない」という考えから副詞ではなく代名詞としての機能だと考える立場もあり、ジーニアスやロイヤルやフォレストがそういう立場。だが、机上の空論だろう。） なお、法学など幾つかの学問では、『原則』というのは例外のありうる規則、という意味である。おそらくジーニアスが「原則」という言葉を使っているのは、Where ～?などの疑問詞を文頭にもちいた疑問文の場合は例外的な事例という含みがあるのだろう。 Where に限らず、たとえば When などで疑問文を作るときも原則、それらの疑問詞の前には前置詞（When の場合は since や till や until など）を置かない。そのため、それら When の文でも前置詞は文末にくる場合が多くなる。 つまり、「いつから～？」なら When do you ～ since ? のような文章になる事が多い。 ただし、Whoの場合はやや例外的である。 たとえば前置詞 With を使う場合、Who が目的格 Whom に変化する場合もあり、 With whom do you ～? 「誰と一緒に～しますか？」 のようにWith が文頭にくる場合もある（桐原）。with以外の前置詞の場合でも文頭に持ってくる場合には同様にwhoではなく whom に変化する（ジーニアス）。なお、前置詞を文頭に持ってくる場合、whomを使わずにwho のままで文頭の前置詞の次に置くのは禁止である。 なお、Whomを使わずとも who のままで下記のように言うこともできる Who do you ～ with？ Where are you from? の場合、もし前置詞 from がないと、「あなたはどこ？」となり、それが出身をたずねているのか、それとも現在地をたずねているのか、意味が分からなくなることもあってか、ともかく 「Where are you from?」の文章は from を省略できない。 ジーニアスは、話し言葉ではWhereでは from を省略しないという言い方をしているが、しかし書き言葉であっても from を省略しないのが一般的であろう（省略したら上述のように意味が通らなり読み手に誤解を与えるので。）。 しかし、用いる動詞などによっては前置詞を省略できる場合があり、たとえば Where do you go to? 「どこに行きますか？」 なら、もし前置詞 to を省略しても、動詞 go から意味を推測できるので、この場合は to を省略されるのが許され、つまり Where do you go? でも許される（ジーニアス）。 このように文法の理論というのは、あまり論理的ではない。最終的には、英文法の学習では典型的な構文を覚えて、それを真似して使っていく必要がある。 === 慣用的な疑問文 === How about a cup of tea? 「お茶を一杯いかがですか？」 How about ～？ は勧誘を表す。 What do you say to ～ing 名詞/動名詞　？　「～はいかがですか？」「～しませんか」 What do you say to ～ing　でも勧誘を表せる。 ここでのsayの直後にある to は前置詞であると考えられている（桐原フォレスト）。どういうわけか、ジーニアスもロイヤルも、to が前置詞かどうかは言及していない。 ほか、Why don't you 動詞 ～　？ は、「～してはどうしょうか」のような相手に行為を促す（うながす）言い方であり、やや押し付けがましい言い方である（ジーニアス）。 Why don't we の形で、一緒になにかをする時に「～しましょうよ」の意味で使う場合もある（フォレスト）。 また、これを省略的に Why not ～？ の形で「～はどうですか」「～してはいかがでしょうか」「～しましょうよ」の意味にもある。 How come S + V ～？ How come ～？　は「どうして～」の意味でありwhy に近いが、How come のほうが感情的な表現であるので、目上の人に使うのは避けるのが良い（ジーニアス）。なお、How come は語順がSVと肯定形の語順になる。 How come you didn't call me ? 「どうして電話をくれなかったの？」 ※ 「電話してほしかったのに」のような含みがあり、相手を責めているようにも受け取られかねない。だから返事も、Sorry, 「ごめん」とかになる（ジーニアス）。 許可を求める表現である Do you mind if～? で、「～してもいいですか」という許可を求める表現ができる。なお Would you mind if ～? については仮定法になり、つまり「～」中の動詞が過去形になる。Would you mind if ～? については 『[[高校英語の文法/仮定法]]』で説明済み。 Do you mind if のほうは、if ～ の動詞は現在形で構わない。 == 参考文献についての注意 == サブページ中の参考文献で、現代2022年では廃止になったシリーズの桐原『フォレスト』などを掲げているが、現代でも他社の　いいずな出版『エバーグリーン』シリーズにフォレストの権利が引き継がれているようなので、わざわざ古本のフォレストを探す必要は無い。 [[カテゴリ:高等学校教育|ふむほふ]] sirluluz7i9wcuh4g5rvykwemhm9d2l 206831 206830 2022-08-20T01:17:10Z すじにくシチュー 12058 /* some と any */ ;慣用句など wikitext text/x-wiki <!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --> == 目次 == * [[高校英語の文法/文の種類]] * [[高校英語の文法/動詞と文型]] * [[高校英語の文法/時制]] ※ 参考書によって微妙に単元名が異なるので暫定 * [[高校英語の文法/完了形]] * [[高校英語の文法/助動詞]] * [[高校英語の文法/不定詞]] * [[高校英語の文法/動名詞]] * * [[高校英語の文法/比較]] * [[高校英語の文法/関係詞]] * [[高校英語の文法/仮定法]] * [[高校英語の文法/名詞]] * [[高校英語の文法/冠詞]] * * [[高校英語の文法/否定]] * [[高校英語の文法/接続詞]] * [[高校英語の文法/前置詞]] == 文の構造 == === 文の要素 === 文の構造を知るためには、文がどのような要素で成り立っているのかを知らなければならない。 ==== 主語と述語動詞 ==== # '''The old man''' ''is'' a famous singer. # '''My sister''' ''studied'' math. ## 訳例:その老人'''は'''有名な歌手'''だ'''。 ## 訳例:私の姉'''は'''数学を研究'''していた'''。 1の文は「AはBだ」という文であり、2の文は「AはCする」という文である。どちらも # 「…は」「…が」という主題の部分 # 「～である」「～する」という主題が何であるかについて述べる部分 の二つが共通している。 この場合、1を'''主部'''といい、2を'''述部'''という。 そして、主部の中心となる語を'''主語'''(Subject)といい、述部の中心となる部分を'''述語動詞'''(Predicate Verb略して'''動詞'''('''Verb'''))という。以下では、述語動詞は原則として単に動詞と呼ぶ。 {| class="wikitable" style="text-align:center" |- ! || - || 主語 || 述語動詞 || - |- | - | colspan="2" | 主部 | colspan="2" | 述部 |- | 1. | The old | man | is | a famous singer. |- | 2. | My | sister | studied | math. |} 主語は単に'''S'''で表し、動詞は'''V'''で表す。 ==== 目的語 ==== # He ''has'' '''a personal computer'''. # We ''played'' '''soccer'''. # Everone ''likes'' '''Sushi'''. ## 訳例:彼はパソコン'''を'''持っている。 ## 訳例:私たちはサッカー'''を'''した。 ## 訳例:みんなが寿司'''を'''好む。 いずれの文の動詞も「～を」という、動作の対象が必要である。このような動作の対象を表す語を'''目的語'''(Object)といい、'''O'''で表す。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 目的語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | He | has | a personal computer. |- | 2. | We | played | soccer. |- | 3. | Everone | likes | Sushi. |} このような、'''S+V+O'''という形の文は英文の基本形の一つである。 ==== 補語 ==== # Mary ''is'' '''happy'''. # John ''became'' '''a doctor'''. ## 訳例:メアリーは幸せだ。 ## 訳例:ジョンは医者になった。 これらはいずれも主語の状態を説明した文であるが、isやbecomeで文を切ると意味をとれない。happyやa doctorという、主語の様子をおぎなう語があって初めて意味のある文となる。このように、主語の様子について説明する語を'''補語'''(Complement)という。補語は'''C'''で表される。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 補語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | Mary | is | happy. |- | 2. | John | became | a doctor. |} このような'''S+V+C'''の文も基本的な文の一つである。なお、後で学ぶように、補語は主語の様子だけでなく目的語の様子を説明する場合もある(例文:I call him Sensei.(私は彼を先生と呼ぶ))。 == 動詞の用法 == === 助動詞 === === 態 === ==== 助動詞と組み合わさった受動態 ==== He could be seen by her. 受動態の文を作るときには、その文の述語は必ずbe動詞の節になるが、be動詞に対して助動詞を用いたり、時制の変化をさせることも普通に行なわれる。 この時には、例えば He is seen by her. という文が He could be seen by her. の様にbe動詞は、助動詞+beの形で書き換えられる。これは、be動詞の原形が beで与えられることによる。同じ様に例えば、 might be may be must be will be なども用いることが出来る。また、過去形や現在完了と組み合わせるときにも通常の規則に従えばよい。例えば、上の文では He was seen by her. He has been seen by her. などとなる。been は be の過去分詞である。ここで、be が過去分詞 been になったのは、現在完了を作るためであり、see が過去分詞 seen になったのは、受動態を作るためであることに注意。 === 分詞 === == さまざまな構文 == === 分詞構文 === 分詞構文は現在分詞や過去分詞を用いて、従属の接続詞節のような意味を持つ文の成分を作る用法である。例文として、 Crying out something, he quickly runs away. がある。この文は「何かを叫びながら、彼は素早く逃げていった。」という 意味だが、この様な文は例えば接続詞whileを用いて、 While he cries out something, he quickly runs away 接続詞を取る。 He cries out something, he quickly runs away. 主語を取る。 Cries out some thing, he guickly runs away. 動詞を現在分詞形にする。 Crying out some thing, he quickly runs away.→'''これで完成！''' などとすることが出来る。分詞構文は文の前後関係から、省略される接続詞が予測できると考えられるとき、接続詞と主語を省略することによって 得られる。ただし、接続詞無しで節を作ることは出来ないことから、接続詞節の述語は対応する現在分詞になるのである。上の例文は while を用いた文から接続詞 while を省き、述語 cries を現在分詞 crying にすることに よって得たものと解釈出来る。ただし、元の従属接続詞節に対応する主文の主語と接続詞節の主語が等しいときには、現在分詞の主語は 省略出来る。上の文で while 節の主語に対応する語が無いのはこのことからである。 主節の主語と従属節の主語が異なっているときには、分詞構文の主語として対応する従属節の主語を所有格として与える。例えば、上の例で主語を省略せず書くと、 His crying out something, ... のようになる。 一般に現在分詞の主語を指定するときは通常所有格を用いる。 分詞構文で省略される接続詞には主なものとして、 because, since, as: 〜だから(理由) when, as, while: 〜のとき(ある時点) などがあげられる。 分詞構文になる従属節では述語がbe動詞であることがある。 このときにも上の規則に従って、Being -,によって分詞構文が作られることも多い。 ==== 分詞構文の受動態 ==== 特にbe動詞に対応する補語が受動態であったり、形容詞であるときには、beingを省いて過去分詞、もしくは形容詞から分詞構文が 始まることも多い。 (Being) seen from airport, everything looked small.（飛行機から見ると、全てのものが小さく見えた） The assignment (being) finished, we went on a hike to the nearby mountain.（その課題が終わってから、私たちは近くの山へハイキングへ行った。） このときには、be動詞と接続詞、必要なら対応する主語も補って考える必要がある。ただし、この様な省略がなされるのは、あくまで省略されたものが文脈からすぐに分かる時のみである。 === 話法 === === 会話表現 === == 品詞 == === 代名詞 === ==== 未分類 ==== 中学校では「代名詞」として、 he や she や we など、基本的な代名詞を習う。 もちろんそれも代名詞であるが、しかしそれ以外にも多くの代名詞がある。 たとえば the same （「同じもの」の意味）も代名詞である（青チャート、ジーニアス）。なぜなら、the same は、なにか具体的な名詞を言う代わりとして使われるのだから、the same も立派な代名詞である。 このように、代名詞は別に一語でなくても構わない。 なお、形容詞的に the same の直後につづけて名詞が来る場合もあり、「the same ～ as ・・・（名詞または代名詞）」で、「・・・と同じ ～」の意味。 こちらの構文では the same は代名詞というよりも形容詞としての用法だが、市販の参考書では都合上、代名詞の章でいっしょにthe same ～ as の構文も教えているのが通例である。 ともかく例文は、たとえば the same ～ as yours で「あなたのと同じ～」の意味（ジーニアス、エバーグリーン）。 the same shoes as yours なら「あなたのと同じ靴」だし（エバー）、 the same computer as yours なら「あなたのと同じコンピュータ」である（ジーニアス）。 一方、慣用的に、節が続く場合は as ではなく that の場合が多く the same man that I saw yesterday で「昨日見かけたのと同じ男の人」の意味だし（エバーの和訳を少し改造）、 the same song that I heard yesterday で「昨日聞いたのと同じ曲」の意味（ジーニアス）。 のように、 「the same ～ that ・・・（節）」 というのもある。 ただし、節が続く場合でも、べつに as を使ってもかまわず、つまり「 the same ～ as ・・・（節）」としてもマチガイではない（ブレイクスルー）。 those who ～ で「～な人々」の意味の代名詞である。 たとえばエバーグリーンいわく、 those who wish to smoke で「たばこを吸いたい人々」である。 such は代名詞として「そのようなもの」「そのような人」として扱われる場合もある。 たとえば He is an adult now, and should be treated as such. 「彼はもう大人なのだから、そのように扱うべきだ。」　※ジーニアス He is mere child, and should be treated as such. 「彼はまだほんの子供だから、子供として扱ってやるべきだ。」　※青チャート のように such はよく as such などとして使われる。 ==== some と any ==== {| class="wikitable" style="left" |+ 複合不定代名詞 ! 　 !! some- !! any- !! no- !! every- |- ! 人<br> -one<br> -body | 　someone <br>　somebody<br>（だれか） || 　anyone <br>　anybody<br>（だれか、だれでも） || no one （※ 離して書く）<br>　nobody<br>（だれも～ない） || 　everyone<br>　everybody<br>（だれでも） |- ! 物<br>-thing | 　something || 　anything 　|| nothing || everything |- |} some にも any にも「いくつかの」という意味がある。 よく参考書では、「 some は肯定文で使う。anyは疑問文・否定文で使う」などと習う（青チャート、ジーニアスなど）。 しかし桐原ファクトいわく、anyの基本的な意味は「どれでも」の意味である。any の「いくつかの」の意味は、「どれでも」の派生だと思うほうが良いだろう。 some と any の区別で悩んだ場合は、この「どれでも」の意味を基準に考えると良い。 だから肯定文であっても、「どれでも」の意味の形容詞には any を使う。 桐原ファクトいわく、疑問文で any を使う場合でも、ニュアンス的には「どれでも」の意味があるのが実際とのこと。否定文の any も同様。 この any の基本的な意味が「どれでも」の説に立てば、たとえば熟語 not ～ any が形容詞 no と同じ意味だということも、 not ～ any は「どれでもいいので存在してほしい（any）という事についてすら、それが成り立たない（not）。　→　つまり無い」というふうに理解できます。 なお、any の後ろに否定語を置くのは禁止されている（ジーニアス、青チャート）。 ほか、慣用的な表現として、よくお茶などやコーヒーの飲み物をすすめる際に、 Would you like some coffee? 「コーヒーはいかがですか」（桐原ファクト） Would you like some more tea? 「お茶のお代わりはいかがですか」（青チャート） のようにsome を使う。 青チャートいわく、some は、答えが Yes であることを期待しているニュアンスのある表現とのこと。そういう用法もある。なので、人にものを勧めるからには、some で質問しないと失礼になるので、someを使うのが当然とのこと。 実際にはsome も any もけっして意味中立的な表現ではなく、それぞれニュアンスがあるので、some と any を完全に使い分けるのは難しいだろう。 参考書にあるような代表的な事例についてだけ、some とanyを使い分ければ、とりあえずは平気だろう。 somebody と anybody などの使い分けも、上記の some と any に準じる（桐原ファクト）。 たとえば「誰かに出会いました」といいたい場合は、somebody を使うべきだと桐原は言っている。これがもしanybodyだと 「誰でもいいのですが、その人に会いました」（原文ママ（桐原））という内容の意味不明の文章になってしまうことからも分かるとして、桐原ファクトは誰かに会った事を言いたい場合には somebody を使うべきだと言っている。 所有格については、-body や -thing の末尾に 's をつければいい（インスパ）。 Everybody's business is nobody's business. 「みなの仕事は誰の仕事でもない」（直訳）→「共同責任は無責任」（ことわざ） ※ 「共同責任は無責任」の部分がことわざ。青チャートおよびインスパイアがこの　ことわざ　を紹介。 ;慣用句など He is something of musician. 「彼はちょっとした音楽家だ」　※青チャ、インスパ、ロイヤル something of a 「少しは～である」※青チャ、「ちょっとした～」※インスパ、 He thinks he is something. 「彼は自分を立派な人だと思っている」 「He thinks himself somebody. 」などでも同じ意味。 somebody または something で「立派な人」の意味（青チャート）。 逆に、nobody または nothing には「とるにたらない人」の意味がある（青チャート、ロイヤル）。 be something like または look something like で「少し似ている」の意味（青チャ、ロイヤル）。 ==== every とall の違い ==== 「すべての」という意味での every は形容詞であるが（インスパイア）、市販の参考書では便宜的に代名詞の章で紹介される。形容詞なので、every 単独ではあつかわれず、必ず直後に名詞または代名詞をともなう（インスパイア）。 every には「すべての」の意味もある（桐原ファクト、インスパイア）。しかし every と all には、ニュアンスの違いが明確に存在する。 また、every の後ろは単数形でなければならない。 every は、その全部を構成する一つ一つに関心がある文脈の場合に用いられる（桐原ファクト）。だから every で形容される名詞は必ず単数形でなければならないのも当然である（桐原ファクト）。また、everyは例外がないことを強調している（ジーニアス）。 each は2つ以上、every は3つ以上のものについて使用する。 なお、each は比較的に小さい個数のものに使い、everyは比較的に大きい数のものに使う（ジーニアス）。 each の使用対象はべつに2個限定でなくても構わない。 every と all には、こういったニュアンスの違いがあるので、参考書によってはevery の標準的な和訳を「すべての」以外で紹介する参考書も多い。 たとえば「あらゆる」「どの～も」という訳で every を紹介する参考書がよくある（青チャート、ブレイクスル－）。 なお、every には別の用法で「～（数詞のつく名詞）ごとに」の意味もあり、この場合は複数形になる。 たとえば every six hours で「6時間ごとに」である（ブレイクスルー）。 every four years で「四年ごとに」である（エバーグリーン）、なおオリンピックが四年ごとに開かれる　という文章。 なお、「一日おきに」は every other day である（インスパイア）。 {{コラム|every child を受ける代名詞は he か she か？| 桐原ファクトに書いてあるのですが、男女のどちらの場合もある単数の名詞について、それを代名詞で受ける際、 he か she かが、時代とともに変わっていきました。 もともとは、男女不明などの場合は、とりあえず he で代名詞を受けていました（桐原ファクト）。 だから every child も he で受けていました。 しかし、それが男女平等の観点に反するという意見が多くなり、近年になって、「 he/ she 」などと受ける代名詞が変わってきました。 「he / she 」はhe or she と読みます。 しかし、長くなるので会話などで不便でした（桐原ファクト）。 その不便さを解消するためか、さらに最近では、単数形であることを無視して every child のような名詞でも they で受けています（桐原ファクトの 2022年 第2版で確認）。 each も同様、最近では they で受けます（桐原ファクト）。 :※ 上記のような説が有名であるが、それに対する若干の異論もある。それは 「もともと he は男の代名詞ではなく性別不明の代名詞であり、もし、男である何らかの名詞についてそれを代名詞で受ける場合については、とりあえず性別不明の代名詞である he を当てるというルールだった」というような説です。 細かな出典は忘れましたが、たしか、日本どこかの有名大学に勤務している米英人の高齢の学者が、「自分はそう習った（heは性別不明の代名詞だと子供時代に習った）」とツイッターで主張していました。 この場合でも男女は不平等であります。しかし、女性差別とは言いがたい実態になります。 つまり、「女性を無視して男性を意味する he を使っていたのではなく、そもそも he は男女不明の代名詞であったが、女性専用の she という代名詞が存在していたため、あとからhe に男性の意味がついてきた。なのに『性別不明の名詞に he を使う事を女性差別だ』というフェミニズム言説は間違っている」という説です。 もしこの説「he は性別不明の代名詞だった」論のとおりなら（この説が間違っている可能性もありますので、どちらかに決め付けないように）、現代の各国の英語教育が、フェミニズミム運動などに配慮して代名詞 he の歴史の説明について、若干のウソをついている事になる可能性があります。 どちらの場合にせよ（数学の確率問題の場合わけのように、マジメに検証する人は両方の可能性を検討する）、参考書の桐原ファクトをよく読めば、性別不明の代名詞 he → he/she → they の変遷について「男女平等」という表現は説明に用いていますが、しかし「女性差別」という表現は用いていません。桐原ファクトの著者たちは、なかなか優秀です。こういう何気ない言葉の端々に、参考書の著者の優秀さが現れます。 まあ、私たちは背景事情にまでは深入りする必要はありません。上記のような異論もあることも承知した上で、異論もふくめた両者の合意である he → he/she → they という性別不明の単数代名詞の客観的事実を覚えれば済みます。 }} ==== その他 ==== 「those who ～」で「～する人々」 Heaven helps those who help themselves. 「天はみずから助くる者を助く。」（ことわざ）　※ 青チャート So do I. 「私もです。」 「So 動詞＋主語」 か「So 主語＋動詞」かで意味が違う。 「So 動詞＋主語」は、「主語もです」の意味。 「So 主語＋動詞 」 は「主語は確かにそうだ」の意味（インスパ代名詞、ジーニアス副詞）。 例文を出せば、たとえば So he is. 「確かに彼はそうだ」 Tom is kind. 「トムは親切だ。」 - So he is. 「確かに彼はそうだ（＝彼・トムは親切だ）。」 - So is John. 「ジョンもそうです。（＝トムだけでなくジョンも親切ですよ）」 のような違いがある。 Tom can French well. 「トムはフランス語を上手に話せます」 - So he can. 「確かに彼はそうだ」 - So can John. 「ジョンもフランス語が上手ですよ」 ※ 青チャにcanで似た例文 === 形容詞・副詞 === ;副詞の位置 副詞の位置がどこに来るかについて、単語や文章によって様々である。 通常、英語では副詞の位置は、修飾対象に前置きである。 しかし very much や from time to time など複数語から構成される副詞表現になると、通常は文末または修飾対象の後ろに置かれるのが通常である（桐原ファクト）。 == 名詞構文・無生物主語 == === 名詞構文 === === 無生物主語 === The road takes you to the station. 「その道を歩いていくと駅につきます。」 The bus takes you to the station. 「そのバスに乗れば駅に行きます。」 take は「連れて行く」の意味だが、交通機関などを主語にして使うことも出来る。その場合は、たとえば道なら「その道を行けば、～につきます」のような意味になる。 takes の代わりに will take としても良い（ロイヤル英文法）。 「remind 人 of」 で「人に～を思い出させる」の意味である。 This picture reminds me of vacation in Greece. 「その写真を見ると、ギリシャでの休日を思い出す。」 This picture reminds me of holidays in London. 「その写真を見ると、ロンドンでの休日を思い出す。」 なお、大修館ジーニアスだとロンドン、桐原フォレストだとギリシャの例文。 「deprived 人 of ～」 「（機会などが）うばわれる」 The knee injury deprived him of the chance to play in the final game. 「ひざのけがのため、彼は決勝戦に出場する機会を失った。」 または The knee injury deprived the player of the chance to play in the game. 「ひざにけがをしたため、その選手は試合に出場する機会を失った。」 のように例文が参考書によくある。 enable ～ は、「～をできるようにする」「～を可能にする」の意味。「～のおかげで、・・・できるようになった」と訳すことができる。 The scholarship enabled him to go on to university. 「その奨学金のおかげで彼は大学へ進学できた。」 ジーニアス、ロイヤルに scholarship の似た例文。 == 疑問詞 == === 前置詞と疑問詞 === Where are you from? 出身はどちらですか？ 文法上、ここでの Where は副詞であり、「疑問副詞」というのに分類される（ロイヤル）。 さて、前置詞 from に注目しよう。 もしかしたら中学高校などで「前置詞は名詞や代名詞の前に移動するのが原則」とか習うかもしれないが、しかし前置詞をけっしてfromの前に移動しない。 なので、Where は副詞であると考えたほうが理解しやすいだろう。（これとは別の解釈で、そもそも「副詞には前置詞がいらない」という考えから副詞ではなく代名詞としての機能だと考える立場もあり、ジーニアスやロイヤルやフォレストがそういう立場。だが、机上の空論だろう。） なお、法学など幾つかの学問では、『原則』というのは例外のありうる規則、という意味である。おそらくジーニアスが「原則」という言葉を使っているのは、Where ～?などの疑問詞を文頭にもちいた疑問文の場合は例外的な事例という含みがあるのだろう。 Where に限らず、たとえば When などで疑問文を作るときも原則、それらの疑問詞の前には前置詞（When の場合は since や till や until など）を置かない。そのため、それら When の文でも前置詞は文末にくる場合が多くなる。 つまり、「いつから～？」なら When do you ～ since ? のような文章になる事が多い。 ただし、Whoの場合はやや例外的である。 たとえば前置詞 With を使う場合、Who が目的格 Whom に変化する場合もあり、 With whom do you ～? 「誰と一緒に～しますか？」 のようにWith が文頭にくる場合もある（桐原）。with以外の前置詞の場合でも文頭に持ってくる場合には同様にwhoではなく whom に変化する（ジーニアス）。なお、前置詞を文頭に持ってくる場合、whomを使わずにwho のままで文頭の前置詞の次に置くのは禁止である。 なお、Whomを使わずとも who のままで下記のように言うこともできる Who do you ～ with？ Where are you from? の場合、もし前置詞 from がないと、「あなたはどこ？」となり、それが出身をたずねているのか、それとも現在地をたずねているのか、意味が分からなくなることもあってか、ともかく 「Where are you from?」の文章は from を省略できない。 ジーニアスは、話し言葉ではWhereでは from を省略しないという言い方をしているが、しかし書き言葉であっても from を省略しないのが一般的であろう（省略したら上述のように意味が通らなり読み手に誤解を与えるので。）。 しかし、用いる動詞などによっては前置詞を省略できる場合があり、たとえば Where do you go to? 「どこに行きますか？」 なら、もし前置詞 to を省略しても、動詞 go から意味を推測できるので、この場合は to を省略されるのが許され、つまり Where do you go? でも許される（ジーニアス）。 このように文法の理論というのは、あまり論理的ではない。最終的には、英文法の学習では典型的な構文を覚えて、それを真似して使っていく必要がある。 === 慣用的な疑問文 === How about a cup of tea? 「お茶を一杯いかがですか？」 How about ～？ は勧誘を表す。 What do you say to ～ing 名詞/動名詞　？　「～はいかがですか？」「～しませんか」 What do you say to ～ing　でも勧誘を表せる。 ここでのsayの直後にある to は前置詞であると考えられている（桐原フォレスト）。どういうわけか、ジーニアスもロイヤルも、to が前置詞かどうかは言及していない。 ほか、Why don't you 動詞 ～　？ は、「～してはどうしょうか」のような相手に行為を促す（うながす）言い方であり、やや押し付けがましい言い方である（ジーニアス）。 Why don't we の形で、一緒になにかをする時に「～しましょうよ」の意味で使う場合もある（フォレスト）。 また、これを省略的に Why not ～？ の形で「～はどうですか」「～してはいかがでしょうか」「～しましょうよ」の意味にもある。 How come S + V ～？ How come ～？　は「どうして～」の意味でありwhy に近いが、How come のほうが感情的な表現であるので、目上の人に使うのは避けるのが良い（ジーニアス）。なお、How come は語順がSVと肯定形の語順になる。 How come you didn't call me ? 「どうして電話をくれなかったの？」 ※ 「電話してほしかったのに」のような含みがあり、相手を責めているようにも受け取られかねない。だから返事も、Sorry, 「ごめん」とかになる（ジーニアス）。 許可を求める表現である Do you mind if～? で、「～してもいいですか」という許可を求める表現ができる。なお Would you mind if ～? については仮定法になり、つまり「～」中の動詞が過去形になる。Would you mind if ～? については 『[[高校英語の文法/仮定法]]』で説明済み。 Do you mind if のほうは、if ～ の動詞は現在形で構わない。 == 参考文献についての注意 == サブページ中の参考文献で、現代2022年では廃止になったシリーズの桐原『フォレスト』などを掲げているが、現代でも他社の　いいずな出版『エバーグリーン』シリーズにフォレストの権利が引き継がれているようなので、わざわざ古本のフォレストを探す必要は無い。 [[カテゴリ:高等学校教育|ふむほふ]] qifgmqtls542xsci6th2gwne9ppd0i2 206832 206831 2022-08-20T01:30:15Z すじにくシチュー 12058 /* every とall の違い */ 出典の追加。ジャンダー関連のコラムの出典。東大の地震学のロバート・ゲラー教授がツイッターで 午前8:26 · 2018年11月14日 に発言。 wikitext text/x-wiki <!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --> == 目次 == * [[高校英語の文法/文の種類]] * [[高校英語の文法/動詞と文型]] * [[高校英語の文法/時制]] ※ 参考書によって微妙に単元名が異なるので暫定 * [[高校英語の文法/完了形]] * [[高校英語の文法/助動詞]] * [[高校英語の文法/不定詞]] * [[高校英語の文法/動名詞]] * * [[高校英語の文法/比較]] * [[高校英語の文法/関係詞]] * [[高校英語の文法/仮定法]] * [[高校英語の文法/名詞]] * [[高校英語の文法/冠詞]] * * [[高校英語の文法/否定]] * [[高校英語の文法/接続詞]] * [[高校英語の文法/前置詞]] == 文の構造 == === 文の要素 === 文の構造を知るためには、文がどのような要素で成り立っているのかを知らなければならない。 ==== 主語と述語動詞 ==== # '''The old man''' ''is'' a famous singer. # '''My sister''' ''studied'' math. ## 訳例:その老人'''は'''有名な歌手'''だ'''。 ## 訳例:私の姉'''は'''数学を研究'''していた'''。 1の文は「AはBだ」という文であり、2の文は「AはCする」という文である。どちらも # 「…は」「…が」という主題の部分 # 「～である」「～する」という主題が何であるかについて述べる部分 の二つが共通している。 この場合、1を'''主部'''といい、2を'''述部'''という。 そして、主部の中心となる語を'''主語'''(Subject)といい、述部の中心となる部分を'''述語動詞'''(Predicate Verb略して'''動詞'''('''Verb'''))という。以下では、述語動詞は原則として単に動詞と呼ぶ。 {| class="wikitable" style="text-align:center" |- ! || - || 主語 || 述語動詞 || - |- | - | colspan="2" | 主部 | colspan="2" | 述部 |- | 1. | The old | man | is | a famous singer. |- | 2. | My | sister | studied | math. |} 主語は単に'''S'''で表し、動詞は'''V'''で表す。 ==== 目的語 ==== # He ''has'' '''a personal computer'''. # We ''played'' '''soccer'''. # Everone ''likes'' '''Sushi'''. ## 訳例:彼はパソコン'''を'''持っている。 ## 訳例:私たちはサッカー'''を'''した。 ## 訳例:みんなが寿司'''を'''好む。 いずれの文の動詞も「～を」という、動作の対象が必要である。このような動作の対象を表す語を'''目的語'''(Object)といい、'''O'''で表す。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 目的語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | He | has | a personal computer. |- | 2. | We | played | soccer. |- | 3. | Everone | likes | Sushi. |} このような、'''S+V+O'''という形の文は英文の基本形の一つである。 ==== 補語 ==== # Mary ''is'' '''happy'''. # John ''became'' '''a doctor'''. ## 訳例:メアリーは幸せだ。 ## 訳例:ジョンは医者になった。 これらはいずれも主語の状態を説明した文であるが、isやbecomeで文を切ると意味をとれない。happyやa doctorという、主語の様子をおぎなう語があって初めて意味のある文となる。このように、主語の様子について説明する語を'''補語'''(Complement)という。補語は'''C'''で表される。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 補語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | Mary | is | happy. |- | 2. | John | became | a doctor. |} このような'''S+V+C'''の文も基本的な文の一つである。なお、後で学ぶように、補語は主語の様子だけでなく目的語の様子を説明する場合もある(例文:I call him Sensei.(私は彼を先生と呼ぶ))。 == 動詞の用法 == === 助動詞 === === 態 === ==== 助動詞と組み合わさった受動態 ==== He could be seen by her. 受動態の文を作るときには、その文の述語は必ずbe動詞の節になるが、be動詞に対して助動詞を用いたり、時制の変化をさせることも普通に行なわれる。 この時には、例えば He is seen by her. という文が He could be seen by her. の様にbe動詞は、助動詞+beの形で書き換えられる。これは、be動詞の原形が beで与えられることによる。同じ様に例えば、 might be may be must be will be なども用いることが出来る。また、過去形や現在完了と組み合わせるときにも通常の規則に従えばよい。例えば、上の文では He was seen by her. He has been seen by her. などとなる。been は be の過去分詞である。ここで、be が過去分詞 been になったのは、現在完了を作るためであり、see が過去分詞 seen になったのは、受動態を作るためであることに注意。 === 分詞 === == さまざまな構文 == === 分詞構文 === 分詞構文は現在分詞や過去分詞を用いて、従属の接続詞節のような意味を持つ文の成分を作る用法である。例文として、 Crying out something, he quickly runs away. がある。この文は「何かを叫びながら、彼は素早く逃げていった。」という 意味だが、この様な文は例えば接続詞whileを用いて、 While he cries out something, he quickly runs away 接続詞を取る。 He cries out something, he quickly runs away. 主語を取る。 Cries out some thing, he guickly runs away. 動詞を現在分詞形にする。 Crying out some thing, he quickly runs away.→'''これで完成！''' などとすることが出来る。分詞構文は文の前後関係から、省略される接続詞が予測できると考えられるとき、接続詞と主語を省略することによって 得られる。ただし、接続詞無しで節を作ることは出来ないことから、接続詞節の述語は対応する現在分詞になるのである。上の例文は while を用いた文から接続詞 while を省き、述語 cries を現在分詞 crying にすることに よって得たものと解釈出来る。ただし、元の従属接続詞節に対応する主文の主語と接続詞節の主語が等しいときには、現在分詞の主語は 省略出来る。上の文で while 節の主語に対応する語が無いのはこのことからである。 主節の主語と従属節の主語が異なっているときには、分詞構文の主語として対応する従属節の主語を所有格として与える。例えば、上の例で主語を省略せず書くと、 His crying out something, ... のようになる。 一般に現在分詞の主語を指定するときは通常所有格を用いる。 分詞構文で省略される接続詞には主なものとして、 because, since, as: 〜だから(理由) when, as, while: 〜のとき(ある時点) などがあげられる。 分詞構文になる従属節では述語がbe動詞であることがある。 このときにも上の規則に従って、Being -,によって分詞構文が作られることも多い。 ==== 分詞構文の受動態 ==== 特にbe動詞に対応する補語が受動態であったり、形容詞であるときには、beingを省いて過去分詞、もしくは形容詞から分詞構文が 始まることも多い。 (Being) seen from airport, everything looked small.（飛行機から見ると、全てのものが小さく見えた） The assignment (being) finished, we went on a hike to the nearby mountain.（その課題が終わってから、私たちは近くの山へハイキングへ行った。） このときには、be動詞と接続詞、必要なら対応する主語も補って考える必要がある。ただし、この様な省略がなされるのは、あくまで省略されたものが文脈からすぐに分かる時のみである。 === 話法 === === 会話表現 === == 品詞 == === 代名詞 === ==== 未分類 ==== 中学校では「代名詞」として、 he や she や we など、基本的な代名詞を習う。 もちろんそれも代名詞であるが、しかしそれ以外にも多くの代名詞がある。 たとえば the same （「同じもの」の意味）も代名詞である（青チャート、ジーニアス）。なぜなら、the same は、なにか具体的な名詞を言う代わりとして使われるのだから、the same も立派な代名詞である。 このように、代名詞は別に一語でなくても構わない。 なお、形容詞的に the same の直後につづけて名詞が来る場合もあり、「the same ～ as ・・・（名詞または代名詞）」で、「・・・と同じ ～」の意味。 こちらの構文では the same は代名詞というよりも形容詞としての用法だが、市販の参考書では都合上、代名詞の章でいっしょにthe same ～ as の構文も教えているのが通例である。 ともかく例文は、たとえば the same ～ as yours で「あなたのと同じ～」の意味（ジーニアス、エバーグリーン）。 the same shoes as yours なら「あなたのと同じ靴」だし（エバー）、 the same computer as yours なら「あなたのと同じコンピュータ」である（ジーニアス）。 一方、慣用的に、節が続く場合は as ではなく that の場合が多く the same man that I saw yesterday で「昨日見かけたのと同じ男の人」の意味だし（エバーの和訳を少し改造）、 the same song that I heard yesterday で「昨日聞いたのと同じ曲」の意味（ジーニアス）。 のように、 「the same ～ that ・・・（節）」 というのもある。 ただし、節が続く場合でも、べつに as を使ってもかまわず、つまり「 the same ～ as ・・・（節）」としてもマチガイではない（ブレイクスルー）。 those who ～ で「～な人々」の意味の代名詞である。 たとえばエバーグリーンいわく、 those who wish to smoke で「たばこを吸いたい人々」である。 such は代名詞として「そのようなもの」「そのような人」として扱われる場合もある。 たとえば He is an adult now, and should be treated as such. 「彼はもう大人なのだから、そのように扱うべきだ。」　※ジーニアス He is mere child, and should be treated as such. 「彼はまだほんの子供だから、子供として扱ってやるべきだ。」　※青チャート のように such はよく as such などとして使われる。 ==== some と any ==== {| class="wikitable" style="left" |+ 複合不定代名詞 ! 　 !! some- !! any- !! no- !! every- |- ! 人<br> -one<br> -body | 　someone <br>　somebody<br>（だれか） || 　anyone <br>　anybody<br>（だれか、だれでも） || no one （※ 離して書く）<br>　nobody<br>（だれも～ない） || 　everyone<br>　everybody<br>（だれでも） |- ! 物<br>-thing | 　something || 　anything 　|| nothing || everything |- |} some にも any にも「いくつかの」という意味がある。 よく参考書では、「 some は肯定文で使う。anyは疑問文・否定文で使う」などと習う（青チャート、ジーニアスなど）。 しかし桐原ファクトいわく、anyの基本的な意味は「どれでも」の意味である。any の「いくつかの」の意味は、「どれでも」の派生だと思うほうが良いだろう。 some と any の区別で悩んだ場合は、この「どれでも」の意味を基準に考えると良い。 だから肯定文であっても、「どれでも」の意味の形容詞には any を使う。 桐原ファクトいわく、疑問文で any を使う場合でも、ニュアンス的には「どれでも」の意味があるのが実際とのこと。否定文の any も同様。 この any の基本的な意味が「どれでも」の説に立てば、たとえば熟語 not ～ any が形容詞 no と同じ意味だということも、 not ～ any は「どれでもいいので存在してほしい（any）という事についてすら、それが成り立たない（not）。　→　つまり無い」というふうに理解できます。 なお、any の後ろに否定語を置くのは禁止されている（ジーニアス、青チャート）。 ほか、慣用的な表現として、よくお茶などやコーヒーの飲み物をすすめる際に、 Would you like some coffee? 「コーヒーはいかがですか」（桐原ファクト） Would you like some more tea? 「お茶のお代わりはいかがですか」（青チャート） のようにsome を使う。 青チャートいわく、some は、答えが Yes であることを期待しているニュアンスのある表現とのこと。そういう用法もある。なので、人にものを勧めるからには、some で質問しないと失礼になるので、someを使うのが当然とのこと。 実際にはsome も any もけっして意味中立的な表現ではなく、それぞれニュアンスがあるので、some と any を完全に使い分けるのは難しいだろう。 参考書にあるような代表的な事例についてだけ、some とanyを使い分ければ、とりあえずは平気だろう。 somebody と anybody などの使い分けも、上記の some と any に準じる（桐原ファクト）。 たとえば「誰かに出会いました」といいたい場合は、somebody を使うべきだと桐原は言っている。これがもしanybodyだと 「誰でもいいのですが、その人に会いました」（原文ママ（桐原））という内容の意味不明の文章になってしまうことからも分かるとして、桐原ファクトは誰かに会った事を言いたい場合には somebody を使うべきだと言っている。 所有格については、-body や -thing の末尾に 's をつければいい（インスパ）。 Everybody's business is nobody's business. 「みなの仕事は誰の仕事でもない」（直訳）→「共同責任は無責任」（ことわざ） ※ 「共同責任は無責任」の部分がことわざ。青チャートおよびインスパイアがこの　ことわざ　を紹介。 ;慣用句など He is something of musician. 「彼はちょっとした音楽家だ」　※青チャ、インスパ、ロイヤル something of a 「少しは～である」※青チャ、「ちょっとした～」※インスパ、 He thinks he is something. 「彼は自分を立派な人だと思っている」 「He thinks himself somebody. 」などでも同じ意味。 somebody または something で「立派な人」の意味（青チャート）。 逆に、nobody または nothing には「とるにたらない人」の意味がある（青チャート、ロイヤル）。 be something like または look something like で「少し似ている」の意味（青チャ、ロイヤル）。 ==== every とall の違い ==== 「すべての」という意味での every は形容詞であるが（インスパイア）、市販の参考書では便宜的に代名詞の章で紹介される。形容詞なので、every 単独ではあつかわれず、必ず直後に名詞または代名詞をともなう（インスパイア）。 every には「すべての」の意味もある（桐原ファクト、インスパイア）。しかし every と all には、ニュアンスの違いが明確に存在する。 また、every の後ろは単数形でなければならない。 every は、その全部を構成する一つ一つに関心がある文脈の場合に用いられる（桐原ファクト）。だから every で形容される名詞は必ず単数形でなければならないのも当然である（桐原ファクト）。また、everyは例外がないことを強調している（ジーニアス）。 each は2つ以上、every は3つ以上のものについて使用する。 なお、each は比較的に小さい個数のものに使い、everyは比較的に大きい数のものに使う（ジーニアス）。 each の使用対象はべつに2個限定でなくても構わない。 every と all には、こういったニュアンスの違いがあるので、参考書によってはevery の標準的な和訳を「すべての」以外で紹介する参考書も多い。 たとえば「あらゆる」「どの～も」という訳で every を紹介する参考書がよくある（青チャート、ブレイクスル－）。 なお、every には別の用法で「～（数詞のつく名詞）ごとに」の意味もあり、この場合は複数形になる。 たとえば every six hours で「6時間ごとに」である（ブレイクスルー）。 every four years で「四年ごとに」である（エバーグリーン）、なおオリンピックが四年ごとに開かれる　という文章。 なお、「一日おきに」は every other day である（インスパイア）。 {{コラム|every child を受ける代名詞は he か she か？| 桐原ファクトに書いてあるのですが、男女のどちらの場合もある単数の名詞について、それを代名詞で受ける際、 he か she かが、時代とともに変わっていきました。 もともとは、男女不明などの場合は、とりあえず he で代名詞を受けていました（桐原ファクト）。 だから every child も he で受けていました。 しかし、それが男女平等の観点に反するという意見が多くなり、近年になって、「 he/ she 」などと受ける代名詞が変わってきました。 「he / she 」はhe or she と読みます。 しかし、長くなるので会話などで不便でした（桐原ファクト）。 その不便さを解消するためか、さらに最近では、単数形であることを無視して every child のような名詞でも they で受けています（桐原ファクトの 2022年 第2版で確認）。 each も同様、最近では they で受けます（桐原ファクト）。 :※ 上記のような説が有名であるが、それに対する若干の異論もある。それは 「もともと he は男の代名詞ではなく性別不明の代名詞であり、もし、男である何らかの名詞についてそれを代名詞で受ける場合については、とりあえず性別不明の代名詞である he を当てるというルールだった」というような説です。 ツイッターで東大の地震学の教授・[[w:ロバート・ゲラー]]がそのような主張をしています。 [https://twitter.com/rjgeller/status/1062486963242979328 Robert Geller@rjgeller 午前8:26 · 2018年11月14日] おおむね、その教授はおおむね「自分は５０年前の高校生のときにそう習った（heは性別不明の代名詞だと習った）」（※ 日本語として読みやすくなるようにwiki側で文章を修正。正確な文章については参照元を読むこと）とツイッターで主張していました。 この場合でも男女は不平等であります。しかし、女性差別とは言いがたい実態になります。 つまり、「女性を無視して男性を意味する he を使っていたのではなく、そもそも he は男女不明の代名詞であったが、女性専用の she という代名詞が存在していたため、あとからhe に男性の意味がついてきた。なのに『性別不明の名詞に he を使う事を女性差別だ』というフェミニズム言説は間違っている」という説です。 もしこの説「he は性別不明の代名詞だった」論のとおりなら（この説が間違っている可能性もありますので、どちらかに決め付けないように）、現代の各国の英語教育が、フェミニズミム運動などに配慮して代名詞 he の歴史の説明について、若干のウソをついている事になる可能性があります。 どちらの場合にせよ（数学の確率問題の場合わけのように、マジメに検証する人は両方の可能性を検討する）、参考書の桐原ファクトをよく読めば、性別不明の代名詞 he → he/she → they の変遷について「男女平等」という表現は説明に用いていますが、しかし「女性差別」という表現は用いていません。桐原ファクトの著者たちは、なかなか優秀です。こういう何気ない言葉の端々に、参考書の著者の優秀さが現れます。 まあ、私たちは背景事情にまでは深入りする必要はありません。上記のような異論もあることも承知した上で、異論もふくめた両者の合意である he → he/she → they という性別不明の単数代名詞の客観的事実を覚えれば済みます。 }} ==== その他 ==== 「those who ～」で「～する人々」 Heaven helps those who help themselves. 「天はみずから助くる者を助く。」（ことわざ）　※ 青チャート So do I. 「私もです。」 「So 動詞＋主語」 か「So 主語＋動詞」かで意味が違う。 「So 動詞＋主語」は、「主語もです」の意味。 「So 主語＋動詞 」 は「主語は確かにそうだ」の意味（インスパ代名詞、ジーニアス副詞）。 例文を出せば、たとえば So he is. 「確かに彼はそうだ」 Tom is kind. 「トムは親切だ。」 - So he is. 「確かに彼はそうだ（＝彼・トムは親切だ）。」 - So is John. 「ジョンもそうです。（＝トムだけでなくジョンも親切ですよ）」 のような違いがある。 Tom can French well. 「トムはフランス語を上手に話せます」 - So he can. 「確かに彼はそうだ」 - So can John. 「ジョンもフランス語が上手ですよ」 ※ 青チャにcanで似た例文 === 形容詞・副詞 === ;副詞の位置 副詞の位置がどこに来るかについて、単語や文章によって様々である。 通常、英語では副詞の位置は、修飾対象に前置きである。 しかし very much や from time to time など複数語から構成される副詞表現になると、通常は文末または修飾対象の後ろに置かれるのが通常である（桐原ファクト）。 == 名詞構文・無生物主語 == === 名詞構文 === === 無生物主語 === The road takes you to the station. 「その道を歩いていくと駅につきます。」 The bus takes you to the station. 「そのバスに乗れば駅に行きます。」 take は「連れて行く」の意味だが、交通機関などを主語にして使うことも出来る。その場合は、たとえば道なら「その道を行けば、～につきます」のような意味になる。 takes の代わりに will take としても良い（ロイヤル英文法）。 「remind 人 of」 で「人に～を思い出させる」の意味である。 This picture reminds me of vacation in Greece. 「その写真を見ると、ギリシャでの休日を思い出す。」 This picture reminds me of holidays in London. 「その写真を見ると、ロンドンでの休日を思い出す。」 なお、大修館ジーニアスだとロンドン、桐原フォレストだとギリシャの例文。 「deprived 人 of ～」 「（機会などが）うばわれる」 The knee injury deprived him of the chance to play in the final game. 「ひざのけがのため、彼は決勝戦に出場する機会を失った。」 または The knee injury deprived the player of the chance to play in the game. 「ひざにけがをしたため、その選手は試合に出場する機会を失った。」 のように例文が参考書によくある。 enable ～ は、「～をできるようにする」「～を可能にする」の意味。「～のおかげで、・・・できるようになった」と訳すことができる。 The scholarship enabled him to go on to university. 「その奨学金のおかげで彼は大学へ進学できた。」 ジーニアス、ロイヤルに scholarship の似た例文。 == 疑問詞 == === 前置詞と疑問詞 === Where are you from? 出身はどちらですか？ 文法上、ここでの Where は副詞であり、「疑問副詞」というのに分類される（ロイヤル）。 さて、前置詞 from に注目しよう。 もしかしたら中学高校などで「前置詞は名詞や代名詞の前に移動するのが原則」とか習うかもしれないが、しかし前置詞をけっしてfromの前に移動しない。 なので、Where は副詞であると考えたほうが理解しやすいだろう。（これとは別の解釈で、そもそも「副詞には前置詞がいらない」という考えから副詞ではなく代名詞としての機能だと考える立場もあり、ジーニアスやロイヤルやフォレストがそういう立場。だが、机上の空論だろう。） なお、法学など幾つかの学問では、『原則』というのは例外のありうる規則、という意味である。おそらくジーニアスが「原則」という言葉を使っているのは、Where ～?などの疑問詞を文頭にもちいた疑問文の場合は例外的な事例という含みがあるのだろう。 Where に限らず、たとえば When などで疑問文を作るときも原則、それらの疑問詞の前には前置詞（When の場合は since や till や until など）を置かない。そのため、それら When の文でも前置詞は文末にくる場合が多くなる。 つまり、「いつから～？」なら When do you ～ since ? のような文章になる事が多い。 ただし、Whoの場合はやや例外的である。 たとえば前置詞 With を使う場合、Who が目的格 Whom に変化する場合もあり、 With whom do you ～? 「誰と一緒に～しますか？」 のようにWith が文頭にくる場合もある（桐原）。with以外の前置詞の場合でも文頭に持ってくる場合には同様にwhoではなく whom に変化する（ジーニアス）。なお、前置詞を文頭に持ってくる場合、whomを使わずにwho のままで文頭の前置詞の次に置くのは禁止である。 なお、Whomを使わずとも who のままで下記のように言うこともできる Who do you ～ with？ Where are you from? の場合、もし前置詞 from がないと、「あなたはどこ？」となり、それが出身をたずねているのか、それとも現在地をたずねているのか、意味が分からなくなることもあってか、ともかく 「Where are you from?」の文章は from を省略できない。 ジーニアスは、話し言葉ではWhereでは from を省略しないという言い方をしているが、しかし書き言葉であっても from を省略しないのが一般的であろう（省略したら上述のように意味が通らなり読み手に誤解を与えるので。）。 しかし、用いる動詞などによっては前置詞を省略できる場合があり、たとえば Where do you go to? 「どこに行きますか？」 なら、もし前置詞 to を省略しても、動詞 go から意味を推測できるので、この場合は to を省略されるのが許され、つまり Where do you go? でも許される（ジーニアス）。 このように文法の理論というのは、あまり論理的ではない。最終的には、英文法の学習では典型的な構文を覚えて、それを真似して使っていく必要がある。 === 慣用的な疑問文 === How about a cup of tea? 「お茶を一杯いかがですか？」 How about ～？ は勧誘を表す。 What do you say to ～ing 名詞/動名詞　？　「～はいかがですか？」「～しませんか」 What do you say to ～ing　でも勧誘を表せる。 ここでのsayの直後にある to は前置詞であると考えられている（桐原フォレスト）。どういうわけか、ジーニアスもロイヤルも、to が前置詞かどうかは言及していない。 ほか、Why don't you 動詞 ～　？ は、「～してはどうしょうか」のような相手に行為を促す（うながす）言い方であり、やや押し付けがましい言い方である（ジーニアス）。 Why don't we の形で、一緒になにかをする時に「～しましょうよ」の意味で使う場合もある（フォレスト）。 また、これを省略的に Why not ～？ の形で「～はどうですか」「～してはいかがでしょうか」「～しましょうよ」の意味にもある。 How come S + V ～？ How come ～？　は「どうして～」の意味でありwhy に近いが、How come のほうが感情的な表現であるので、目上の人に使うのは避けるのが良い（ジーニアス）。なお、How come は語順がSVと肯定形の語順になる。 How come you didn't call me ? 「どうして電話をくれなかったの？」 ※ 「電話してほしかったのに」のような含みがあり、相手を責めているようにも受け取られかねない。だから返事も、Sorry, 「ごめん」とかになる（ジーニアス）。 許可を求める表現である Do you mind if～? で、「～してもいいですか」という許可を求める表現ができる。なお Would you mind if ～? については仮定法になり、つまり「～」中の動詞が過去形になる。Would you mind if ～? については 『[[高校英語の文法/仮定法]]』で説明済み。 Do you mind if のほうは、if ～ の動詞は現在形で構わない。 == 参考文献についての注意 == サブページ中の参考文献で、現代2022年では廃止になったシリーズの桐原『フォレスト』などを掲げているが、現代でも他社の　いいずな出版『エバーグリーン』シリーズにフォレストの権利が引き継がれているようなので、わざわざ古本のフォレストを探す必要は無い。 [[カテゴリ:高等学校教育|ふむほふ]] 3t26nwu8an7t34xmhsd5fy33s1m40z3 828 23726 206813 184341 2022-08-19T13:32:08Z JackPotte 4751 Add printable version header, footer and no evaluation param if overflow Scribunto text/plain -- Search and display the book pages from the TOC page, in order to create a printable version and a previous / next navigation. debug = false include_book_subpages_only = true do_not_evaluate_each_chapter = false local p = {} ModuleTnt = require('Module:TNT') Error = ModuleTnt.format('I18n/Module:Printable version', 'error_invalid_toc') Beginning1 = ModuleTnt.format('I18n/Module:Printable version', 'header_notice') Beginning2 = ModuleTnt.format('I18n/Module:Printable version', 'header_cover') Break = ModuleTnt.format('I18n/Module:Printable version', 'page_break') Ending1 = ModuleTnt.format('I18n/Module:Printable version', 'footer_license') Ending2 = ModuleTnt.format('I18n/Module:Printable version', 'footer2') templateLeft = ModuleTnt.format('I18n/Module:Printable version', 'template_left') templateRight = ModuleTnt.format('I18n/Module:Printable version', 'template_right') TOC = ModuleTnt.format('I18n/Module:Printable version', 'TOC') sep = ModuleTnt.format('I18n/Module:Printable version', 'subpage_separator') page_before = ModuleTnt.format('I18n/Module:Printable version', 'page_before') page_after = ModuleTnt.format('I18n/Module:Printable version', 'page_after') function p._escapePattern(pattern) return mw.ustring.gsub(pattern, "([%(%)%.%%%+%-%*%?%[%^%$%]])", "%%%1"); end function p.displays_book(frame) if not debug then Error = '' end if frame == nil then return '' end if frame.args == nil then return '' end if frame.args[1] == nil then return '' end local BookName = frame.args[1] if (BookName ~= nil and mw.text.trim(BookName) ~= '') then title = mw.title.new(BookName) if frame.args[2] ~= nil and frame.args[2] ~= '' then BookName = frame.args[2] else if mw.ustring.find(BookName, sep .. TOC, 1, true) ~= nil then BookName = mw.ustring.gsub(BookName, "^(.*)" .. sep .. TOC .. "$", "%1") end end if frame.args[3] ~= nil then include_book_subpages_only = false end else return Error end if frame.args[4] ~= nil and frame.args[4] ~= '' then do_not_evaluate_each_chapter = true end if (title == nil or title == '') then return Error end text = title.getContent(title) if (text == nil or text == '') then return Error end -- Book subpages titles normalization to absolute names local lines_ = mw.text.split(text, "\n") local fullPageName local PrintVersion = {} if (page_before ~= '') then -- Add book header fullPageName = BookName .. sep .. page_before ChapterTitle = mw.title.new(fullPageName) if (ChapterTitle ~= nil and ChapterTitle.exists) then -- Title should be defined in the page itself table.insert(PrintVersion, frame:expandTemplate{ title = ':' .. fullPageName } .. '\n\n') end end -- Add book chapters for i,v in ipairs(lines_) do if mw.text.trim(v) ~= '' then fullPageName = p.getFullPageName(BookName, v) if fullPageName ~= nil then ChapterTitle = mw.title.new(fullPageName) if (ChapterTitle ~= nil and (do_not_evaluate_each_chapter or ChapterTitle.exists)) then PageName = p.getSubpageName(BookName, fullPageName) if (PageName ~= nil and PageName ~= '') then if Break ~= "" then table.insert(PrintVersion, frame:expandTemplate{title = Break}) end table.insert(PrintVersion, '\n<div style="clear:both;page-break-before:always;"></div>\n=' .. PageName .. '=\n') end table.insert(PrintVersion, frame:expandTemplate{ title = ':' .. fullPageName } .. '\n\n') else if debug then table.insert(PrintVersion, '<span class="error">Missing subpage "' .. fullPageName .. '" on line "' .. v .. '" for the book:</span> ' .. BookName .. '\n\n') end end end end end if (page_after ~= '') then -- Add book footer fullPageName = BookName .. sep .. page_after ChapterTitle = mw.title.new(fullPageName) if (ChapterTitle ~= nil and ChapterTitle.exists) then -- Title should be defined in the page itself table.insert(PrintVersion, frame:expandTemplate{ title = ':' .. fullPageName } .. '\n\n') end end Templates1 = "" if Beginning1 ~= "" then Templates1 = Templates1 .. frame:expandTemplate{title = Beginning1} .. '\n' end if Beginning2 ~= "" then Templates1 = Templates1 .. frame:expandTemplate{title = Beginning2} .. '\n' end Templates2 = "" if Ending1 ~= "" then Templates2 = Templates2 .. frame:expandTemplate{title = Ending1} .. '\n' end if Ending2 ~= "" then Templates2 = Templates2 .. frame:expandTemplate{title = Ending2} .. '\n' end return Templates1 .. table.concat(PrintVersion, "\r\n") .. Templates2 end function p.extract_fullPageName(frame) if frame == nil then return '' end if frame.args == nil then return '' end if frame.args[1] == nil then return '' end if frame.args[2] == nil then return '' end return p.getFullPageName(frame.args[1], frame.args[2]) end function p.getFullPageName(BookName, chapter) if (BookName ~= nil and mw.text.trim(BookName) ~= '') or (chapter ~= nil and mw.text.trim(chapter) ~= '') then BookName = mw.text.trim(BookName) chapter = mw.text.trim(chapter) BookName = mw.ustring.gsub(BookName, "_", " ") chapter = mw.ustring.gsub(chapter, "_", " ") else if debug then chapter = '<span class="error">Incorrect book or chapter name</span>' else chapter = '' end end chapter = mw.ustring.gsub(chapter, "{{BOOKNAME}}", BookName) chapter = mw.ustring.gsub(chapter, "{{[Mm]odulo%|([^}]+)}}", "[[%1]]") chapter = mw.ustring.gsub(chapter, " *%| *[0-9]*.*{{[Cc]%|([^}]+)%|[0-9]}}", "[[" .. BookName .. sep .. "%1]]") chapter = mw.ustring.gsub(chapter, " *%| *[0-9]*.*{{[Cc]%|([^}]+)}}", "[[" .. BookName .. sep .. "%1]]") chapter = mw.ustring.gsub(chapter, " *%[%[Image:[^%]]+%]%]", "") chapter = mw.ustring.gsub(chapter, "{{[^}]*}}", "") chapter = mw.ustring.gsub(chapter, "^[%#%*:; ]*", "") chapter = mw.ustring.gsub(chapter, "%[%[%.%.?/", "[[" .. BookName .. sep) chapter = mw.ustring.gsub(chapter, "%[%[/", "[[" .. BookName .. sep) chapter = mw.ustring.gsub(chapter, "%/%]%]", "]]") chapter = mw.ustring.gsub(chapter, "%/$", "") if mw.ustring.find(chapter, "%[%[") ~= nil then -- Pages titles extraction from the TOC if mw.ustring.find(chapter, "%|") == nil or (mw.ustring.find(chapter, "%]") ~= nil and mw.ustring.find(chapter, "%|") > mw.ustring.find(chapter, "%]")) then Ending = "%]" else if mw.ustring.find(chapter, "%/%|") == nil or mw.ustring.find(chapter, "%/%|") > mw.ustring.find(chapter, "%|") then Ending = "%|" else Ending = "%/%|" end end chapter = mw.text.split(chapter, Ending)[1] -- extraction of the line beginning --chapter = mw.text.split(chapter, "%[%[")[2] chapter = mw.ustring.gsub(chapter, "[^%[]*%[%[(.*)", "%1") -- brackets and pipes removal if chapter == BookName or chapter == BookName .. sep or mw.ustring.find(chapter, "%#") ~= nil then if debug then chapter = '<span class="error">Chapter = ' .. chapter .. ' => book name or another subpage name</span> with Ending = ' .. Ending else chapter = '' end else if include_book_subpages_only then -- Book subpages only (and ignoring the other links like "see also") if mw.ustring.find(chapter, BookName .. sep, 1, true) == nil then if debug then chapter = "<span class=\"error\">No book subpage into the internal link:</span> '" .. chapter .. "' doesn't include '" .. BookName .. sep .. "'" else chapter = '' end end end end else if debug then chapter = "<span class=\"error\">No internal link</span> for: " .. chapter .. "\n" else chapter = '' end end return chapter end function p.getSubpageName(bookName, fullPageName) k, v = mw.ustring.gsub(fullPageName, '^' .. p._escapePattern(bookName .. sep), '') return k end function p.extract_subpageName(frame) if frame == nil then return '' end if frame.args == nil then return '' end if frame.args[1] == nil then return '' end if frame.args[2] == nil then return '' end return p.getSubpageName(frame.args[1], frame.args[2]) end function p.displays_footer(frame) if not debug then Error = '' end if frame == nil then return "" end if frame.args == nil then return "" end if frame.args[1] == nil then return "" end local footer = {} local BookName = frame.args[1] if (BookName ~= nil and mw.text.trim(BookName) ~= "") then title = mw.title.new(BookName) if mw.ustring.find(BookName, sep .. TOC, 1, true) ~= nil then BookName = mw.ustring.gsub(BookName, "^(.*)" .. sep .. TOC .. "$", "%1") end else return Error end local currentPageName if frame.args[2] ~= nil and frame.args[2] ~= '' then currentPageName = frame.args[2] else currentPageName = p.getSubpageName(BookName, mw.title.getCurrentTitle().fullText) end if (currentPageName ~= nil and mw.text.trim(currentPageName) ~= "") then currentPageName = mw.text.trim(currentPageName) else return Error end if debug then table.insert(footer, " currentPageName = " .. currentPageName .. "\n") end if (title == nil or title == "") then return Error end text = title.getContent(title) if (text == nil or text == "") then return Error end if frame.args[3] ~= nil and frame.args[3] ~= '' then if frame.args[3] == 'programming' then if debug then table.insert(footer, " skin=programming\n\n") end templateLeft = '{| style="width:100%; border:solid 1px #71c837; background:#c6e9af; color:#2d5016;" class="navlinks noprint"\n| style="text-align:left; width:33%; font-size:90%;" class="navprevious" |[[Image:Navigation_Left_Arrow.svg|18px|link=printf|alt=]] [[printf]]\n' templateRight = '| style="text-align:center; width:34%;" class="navtitle" | [['..mw.title.getCurrentTitle().rootText..']]<br><b>'..mw.title.getCurrentTitle().subpageText..'</b>\n| style="text-align:right; width:33%; font-size:90%;" class="navnext" | [[printf]] [[Image:Navigation_Right_Arrow.svg|18px|link=printf|alt=]]\n|}' end end -- Book subpages titles normalization to absolute names local lines_ = mw.text.split(text, "\n") local previousChapter = "" local found = false local fullPageName local homepage = false local subpageName local rawFullPageName if (currentPageName == BookName) then if debug then table.insert(footer, " homepage\n") end homepage = true end for i, v in ipairs(lines_) do rawFullPageName = mw.text.trim(v) if rawFullPageName ~= '' then fullPageName = p.getFullPageName(BookName, rawFullPageName) if debug then if mw.ustring.find(fullPageName, "<span class=\"error\">No internal link</span>") ~= nil then fullPageName = nil else table.insert(footer, " research into: " .. rawFullPageName .. "\n") table.insert(footer, " extraction of: " .. fullPageName .. "\n") end end if fullPageName ~= nil then if mw.ustring.find(fullPageName, BookName .. sep, 1, true) == nil then if debug then table.insert(footer, " replacement of " .. fullPageName .. " by " .. BookName .. sep .. fullPageName .. "\n") end fullPageName = BookName .. sep .. fullPageName end ChapterTitle = mw.title.new(fullPageName) if (ChapterTitle ~= nil and ChapterTitle.exists) then subpageName = p.getSubpageName(BookName, fullPageName) if debug then table.insert(footer, " cut subpage: " .. subpageName .. "\n") end if (subpageName ~= nil and subpageName ~= "") then if found == true or homepage == true then if debug then table.insert(footer, "<span class=\"error\">Previous & next chapter insertion</span>\n") end if homepage == false then if previousChapter == "" then theTemplateLeft, nb = mw.ustring.gsub(templateLeft, "printf", BookName .. "|" .. TOC) else theTemplateLeft, nb = mw.ustring.gsub(templateLeft, "printf", BookName .. sep .. previousChapter .. "|" .. previousChapter) end table.insert(footer, theTemplateLeft) end theTemplateRight, nb = mw.ustring.gsub(templateRight, "printf", BookName .. sep .. subpageName .. "|" .. subpageName) table.insert(footer, theTemplateRight) break elseif subpageName == currentPageName then if debug then table.insert(footer, "<span class=\"error\">Page</span> '" .. currentPageName .. "' found\n\n") end found = true elseif fullPageName ~= "" then if debug then table.insert(footer, " " .. subpageName .. " is different from " .. currentPageName .. "\n") end previousChapter = subpageName else if debug then table.insert(footer, "<span class=\"error\">The current page</span> '" .. subpageName .. "' is not '" .. currentPageName .. "'") end end end else if debug then table.insert(footer, "<span class=\"error\">The page</span> '" .. fullPageName .. "' doesn't exist, for '" .. currentPageName .. "'\n\n") end end end end end if found == true and table.getn(footer) == 0 then if debug then table.insert(footer, "<span class=\"error\">No next chapter</span>\n") end theTemplateLeft, nb = mw.ustring.gsub(templateLeft, "printf", BookName .. sep .. previousChapter .. "|" .. previousChapter) table.insert(footer, theTemplateLeft) theTemplateRight, nb = mw.ustring.gsub(templateRight, "printf", BookName .. "|" .. TOC) table.insert(footer, theTemplateRight) end return table.concat(footer, "") end return p 35av02bakr987k40bv756fw0o856sxj 0 24170 206783 206697 2022-08-19T13:01:02Z 椎楽 32225 記述修正。 wikitext text/x-wiki {{Nav}} == 源平の争乱 == === 治承・寿永の内乱 === 1179年に平清盛は後白河法皇を幽閉し、平氏の専制体制を作り上げた。このことは他の有力貴族や寺社の不満を高めることとなった。1180年に清盛が、娘の{{ruby|徳子|とくこ}}の産んだ安徳天皇を即位させると、後白河法皇の第2皇子の{{ruby|以仁王|もちひとおう}}が{{ruby|源頼政|みなもとのよりまさ}}とともに挙兵した。これに清盛は速やかに対応し、以仁王らを攻撃した。頼政は宇治で戦死し、以仁王も奈良に逃亡する最中に討ち取られた。 こうした中、同年6月に清盛は都を摂津の'''福原'''に移した。この遷都は瀬戸内海の支配を確保し、平家の指導力を高めるための拠点移動であった。だが、貴族の反対に加え、南都北嶺の僧兵や畿内の源氏の活動が活発になったために半年で京に都を戻した。 以仁王は敗死したが、挙兵と同時に諸国の武士に平氏討伐の令旨を出しており、各地でこれに呼応した各地の武士(在地領主)が立ち上がった。その中でも有力だったのが、平治の乱で敗れて{{ruby|伊豆|いず}}に流されていた'''源頼朝'''、および信濃国木曽の'''源義仲'''であった。 源頼朝は、叔父の源行家によって伝えられた以仁王の令旨に応じ、1180年8月に妻・'''政子'''の父である'''北条時政'''らと挙兵して伊豆国目代の館を奇襲した。目代への襲撃は成功するものの、頼朝挙兵の報を受けた平家方の大庭景親が3000騎の大軍を率いて頼朝討伐を開始した。兵力の乏しい頼朝軍は石橋山(神奈川県)で迎撃するも大敗する('''石橋山の戦い''')。頼朝は安房国(千葉県南部)へと逃れ、再起をはかった。安房で北条氏とともに挙兵した三浦氏とも合流し、源氏に仕えていた武士たちも頼朝の下に集まりはじめた。そして、千葉常胤や上総広常などの有力な豪族が頼朝に従うと形勢は頼朝の方へ一気に傾いた。そして、同年10月には平家方の大庭らの平家方豪族を倒して源氏ゆかりの地である鎌倉に入った。 1181年の清盛の死や、畿内・西国を中心とした飢饉（養和の飢饉）の発生は平氏に不利に働いた。 1183年、平氏は京都をめぐって義仲の軍勢と戦い、平氏が負け、平氏は安徳天皇を連れて西国に逃げる（都落ち（みやこおち） ）。 後白河法皇は、京都にとどまった。 そして、源義仲と後白河が対立した。 そして、頼朝は、弟の源範頼（のりより）および源義経（よしつね）および彼らの軍勢を京に派遣し、源義仲を討った<ref>これについては、実教出版の教科書では源氏どうしで戦わせて勢力を削ぎ、後白河法皇を中心とした政権を築こうとする策謀という解釈を述べている。他方、後白河法皇には長期的な戦略がなく、場当たり的な判断に終始しているという見解も根強い。(『陰謀の日本中世史』呉座勇一著、角川書店、p.84参照)</ref>。 （※ ） また1183年に頼朝は後白河法皇との交渉の末に東海•東山両道の支配権を承認された（'''寿永二年十月宣旨'''）。 === 平家滅亡 === そして、摂津の一の谷（いちのたに）、讃岐の八島（やしま）の合戦で源氏が勝って平氏をやぶり、ついに1185年に長門（ながと）の壇ノ浦（だんのうら）での海戦が源平最後の決戦となり、壇ノ浦で平氏を滅亡させた。壇ノ浦の戦いで安徳天皇は死去した。 === コラム:源平合戦の実態 === 治承・寿永の内乱は源平合戦とも言われ、源氏と平氏の勢力争いのように描かれることが多い。軍記物では「源平の宿命的な対立」も強調されがちである。しかし、実のところ全ての源氏が頼朝に、全ての平氏が平家<ref><!--どこぞのポンコツ煮込みを含む-->多くの人が誤解しがちだが、平氏=平家ではない。一般的に平家は平清盛の一族・縁者とその郎党を指す。</ref>の下についたわけではない。例えば、頼朝とともに挙兵した北条氏・三浦氏は平氏であった。一方、古くからの源氏の家人は当初、頼朝の挙兵には否定的な者も少なくなかった。また、同じ清和源氏である常陸(茨城県)の佐竹氏は平家に近かったため、頼朝から討伐された。 治承・寿永の内乱の背景には、平家による権力の独占に対する反発に加えて、所領の拡大を目指す在地領主と国司・荘園領主との対立があった。自らの知行国を増加させて荘園の集積も行った平家一門がその矛盾を一手に引き受けてしまうことになったのである。そして、在地領主はあくまで自らの要求に最も応える可能性のあるものに従ったのであり、「源氏の棟梁」という理由で頼朝に従ったわけではない。 そのため、頼朝以外にも武家の棟梁となりうる者もいた。平家一門を都落ちさせた源義仲、以仁王の令旨を届けた源行家、甲斐源氏の棟梁であり富士川の戦いで頼朝の勝利に貢献した武田(源)信義、さらには清盛の後継者である平宗盛にも棟梁となるチャンスはあった。しかし、在地領主や荘園の荘官、諸国の在庁官人たちの要求に最もよく応えられた頼朝だけが彼らを御家人としてまとめ上げ、武家の棟梁となることに成功したのだった。 == 鎌倉幕府 == === 統治機構の確立 === 鎌倉は東海道の要衝であり、三方を山で囲まれ、南は海に面した天然の要害であった。さらに、頼朝の五代前の先祖である頼義が鶴岡八幡宮を建立したこともあり、鎌倉は源氏ゆかりの地でもある。こうしたことから、頼朝は鎌倉を拠点として関東統治のための機構をつくりあげる。頼朝は鎌倉を動かず、合戦はもっぱら弟の源範頼と源義経に任せていた。 1180年、富士川の戦いの後、頼朝は有力武士たちとの主従関係を明確なものとし、頼朝に直属する武士たちは'''御家人'''と呼ばれるようになり、頼朝は後に'''鎌倉殿'''と呼ばれるようになった。そして、御家人たちを統括する部署として{{Ruby|'''侍所'''|さむらいどころ}}が設けられた。その別当(長官)に任じられたのが関東の有力豪族であった三浦一族の{{Ruby|和田義盛|わだよしもり}}であった。 1184年には政務や財務を取りしきる{{Ruby|'''公文所'''|くもんじょ}}と裁判事務を担当する'''{{Ruby|問注所|もんちゅうじょ}}'''が開かれた。公文所は後に整備が進み{{ruby|'''政所'''|まんどころ}}となる。公文所（政所）別当には元々朝廷の下級官吏であった{{Ruby|大江広元|おおえのひろもと}}が、問注所執事(長官)には下級官吏出身の{{Ruby|三善康信|みよしのやすのぶ}}が招かれた。 === 全国支配の公認 === 1185年、後白河法皇は、頼朝の勢力をそごうとして、義経に頼朝追討を命じるが失敗する。そして、逆に頼朝は軍勢を京に送って後白河にせまり、頼朝は諸国を管理する権限（御家人を「'''守護'''」（しゅご）として各国に置く権利）を獲得する。また、荘園や国衙領にも地頭を置いて兵糧米を徴収する権利も、獲得した(文治勅許)。 :当初は「守護」でなく「'''国地頭'''」（くにじとう）などと呼ばれたが、やがて「守護」と呼ばれるようになった。 :すでに東国は頼朝の支配下にあったので、実質的には、頼朝は西国の支配権を手に入れたことになる。 こうして、1185年に、頼朝が実質的に全国支配をする体制が出来上がった。 そして1189年、頼朝は、奥州藤原氏が義経（よしつね）をかくまったとして、頼朝は奥州藤原氏をほろぼした。（奥州藤原氏の藤原泰衡（やすひら）は頼朝の要求に従って義経を殺したが、それにもかかわらず、頼朝は藤原泰衡を滅ぼした。） 1190年に頼朝は右近衛大将（うこのえたいしょう）となった。 1192年の後白河法皇の死後、源頼朝は征夷大将軍に任命された。 === コラム:鎌倉幕府の成立は何年か === 今(2022年)の40歳代以上の年代に鎌倉幕府の成立年を聞けば、たいていの場合「{{ruby|いい国|1192}}つくろう鎌倉幕府」の言葉とともに1192年という答えが返ってくるだろう。 しかし、現在では1192年を鎌倉幕府成立とする教科書・テキストはない。現行の中高の日本史教科書では1185年を鎌倉幕府成立としていることが多いが、これは頼朝が「日本国惣追捕使(守護)」「日本国惣地頭」の地位を獲得し、守護・地頭の任命権を持ったことを根拠とする。しかし、中世史研究者の間では以下の6説が提示されている。 #1180年末:頼朝が鎌倉を拠点とし、侍所を設け、南関東と東海道東部の支配権を確立した段階。 #1183年10月:頼朝の東国支配権が事実上承認された、いわゆる「寿永二年十月宣旨」を受けた段階。 #1184年10月:公文所と問注所の設立。 #1185年11月:全国の荘園と公領に守護・地頭を置く権限を獲得した「文治勅許」を得た段階。(中高の歴史教科書で採用されている見解でもある) #1190年11月:頼朝が右近衛大将に任命されたとき。 #1192年7月:頼朝が征夷大将軍に任命されたとき。 古くからの説は5と6であるが、これは「幕府」という言葉が近衛大将や将軍の館の意味に由来したことに基づく説である。すなわち、「頼朝が近衛大将・将軍となったこと」に注目したものと言える。現在、この2説に人気がないのは、既に頼朝が統治のための機構を作り上げつつあったことよりも「将軍」という形式にのみ注目しているからといえる。 一方、1～4は「鎌倉幕府」が軍事政権としての実体を持つようになった時期、つまり「どの段階で頼朝が政権を握った」と言えるか注目したものである。現在有力視されている4は頼朝の権力を全国に広げる契機に着目した説である。だが、鎌倉幕府の「頼朝による東国の支配権の確立」という性格に着目すれば2ないし3の説が、さらにその実効支配までさかのぼるならば1の説も主張される。 こうした見解の相違は、結局のところ「武家政権=幕府なのか」「将軍がいなくとも幕府と言えるか」「そもそも武家政権の権限はどこまで有効だったのか」などといった「幕府とは何か」という根本的な問いに由来する。 == 封建制度の成立 == ---- <references/> ckxtp135w57r7n8ee45m10rc3r7nkw8 0 24486 206833 194522 2022-08-20T02:34:36Z すじにくシチュー 12058 /* 似た機能を複製する場合 */ IT業界だけなく法律業界でも、むやみに高階層的な法令を設計するとその法令の構造が複雑になる現象は知られています wikitext text/x-wiki == 本書の注意点 == === 本書の目的 === 本ページ『ゲームプログラミング/RPG』では原則、あまり（あるいは「まったく」）、いわゆるドラクエ的な意味での「RPG」の難易度デザインやそのためのパラメータ調整などのゲームデザインに関する話題は'''扱いません'''。 なぜなら、本書『ゲームプログラミング』は、題名にもあるとおりプログラミングの教科書だからです。つまり本書は、RPGのゲームデザイン論の教科書'''ではない'''です。 難易度デザインについては、RPG限定ではないですが本wikiでは別途、『[[ゲームプログラミング/バランス調整]]』という難易度デザインに特化した目的のページが切り離されて存在しているので、そちらをご利用ください。 同様に、ゲームシナリオやイラスト素材や音楽素材などの制作など自前のRPG制作に必要なその他の知識も説明しません。もしかしたら必要に応じて「ドットエディタ」などのキャラチップ制作ツールの存在や最低限のIT的な説明はするかもしれませんが、しかしデッサン的な話題は一切しません。 === 出典などの有無について === 市販のゲームクリエイター教育書には、一切、RPGのプログラミング解説書はありません。 一応、アクションゲームについては書籍『[https://www.amazon.co.jp/%E3%82%B2%E3%83%BC%E3%83%A0%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AB%E3%81%AA%E3%82%8B%E5%89%8D%E3%81%AB%E8%A6%9A%E3%81%88%E3%81%A6%E3%81%8A%E3%81%8D%E3%81%9F%E3%81%84%E6%8A%80%E8%A1%93-%E5%B9%B3%E5%B1%B1-%E5%B0%9A/dp/4798021180 ゲームプログラマになる前に覚えておきたい技術]』や『[https://www.amazon.co.jp/%E3%82%B2%E3%83%BC%E3%83%A0%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0C-Sanjay-Madhav/dp/4798157619/ref=pd_lpo_2?pd_rd_i=4798157619&psc=1 ゲームプログラミングC++] 』などがありますが、その書籍は別にRPGには限定しておらず、どちらかというとアクションゲーム寄りの内容かもしれません（たとえば『ゲームプログラミングC++』では「衝突検知」などの話題がある）。 そういった出版事情もあり、本ページでは、出典のないRPGゲームプログラミング技法を多く紹介しています。 出典がなくても、プログラミングについては実際に Visual Studio などのコンパイラでその技法を確認してみれば真偽の確認ができますので、読者ご自身で真偽をご確認ください。 本ページに限らず『[[C言語]]』や『[[JavaScript]]』などの本wikiのプログラミング言語の教科書も同様に、プログラミング技法については特に出典はないスタイルです（出典があるのは、主に用語や歴史などの説明に関する出典だったりする）。 想定読者として、そういう御自身でコンパイラでコードをビルドして確認できるレベルの人を本ページでは想定していますので、もし読者がそれに到達していないなら、このページからは決して学ばないでください。 === コード全部は紹介しきれない === 実際のゲームプログラミングでは、たとえ無音声の2Dゲームですら、計算処理の他にグラフィックやキーボード入力など多くの機能が連動するので、コードはかなり長くなります。無音2Dのシンプルな超短編ゲームですら、初心者でもコードが何千行やあるいは1万行以上にもなります。 そのため、本wikiでは動作ソースコードの全部は到底、紹介できないです。だから本wikiで紹介されているコードをコピーペーストしても、それだけでは動かないのが普通です。 本ページにあるC言語のコードは、プログラミングでRPGを作る際に、「たぶん多くの人はこういった点が気になって悩むと思うから、こういうふうにコード記述すれば解決できると思います」といった方針だけを提供するものに過ぎません。 あるいは、もし本書で紹介したコードで動作したとしても、そのコードの結果はコマンドプロンプト（DOSプロンプト）のような真っ黒い画面で、RPG的な計算内容による計算結果だけを表示するプログラムだったりするので、そのままでは他人に遊んでもらえるような実際のゲームではないので、したがって実際のゲームプログラミング時には映像の表示などのためのコード追加がかなり多く必要になります。 == はじめに == 本ページの'''RPG'''は、ターン制の戦闘システムを採用した<ref group="注">いわゆるドラクエ シリーズや昔のFF（ファイナルファンタジー）1～3あたり</ref>RPG（Turn-based RPG）を中心にとり扱う。アクションRPGやシミュレーションRPG、アクティブバトルなどを語る場合には、注記する。 以下のものは取り扱わない。 * テーブルトークRPG。TRPGや、テーブルトップRPGとも呼ばれる。 なお、本ページでは説明のために[[C言語]]を用いている。C言語の理解を前提としている箇所が存在するため、もし読者が知識をお持ちでない場合は、適切な媒体で調べながら読み進めていただきたい。 本ページではC言語を説明のために用いているが、開発環境がそれ以外の言語である場合は、適宜読み替えていただきたい。 {{コラム|使えない理論は捨てよう| これからこの単元では、ゲームプログラミングとそれに関連する理論を解説していきます。 ですが、ゲームやマンガやアニメなどの娯楽は、理論にもとづく分野ではなく、観客を楽しませてナンボの業界です。 また、そもそも伝えられている理論自体が間違っている場合もあります。 たとえば漫画家の江川達也（えがわ たつや）の体験談なのですが、彼は漫画家デビュー当初、マンガ中での男性キャラの履いているズボンをかっこよく書くのに時間が掛かっていて困っていました。 そうなった理由は、彼・江川の崇拝するマンガの巨匠、手塚治虫が、「人体に直線の部分は無いので、人の絵を書く際に定規などを使うべきではない」という理論を、江川も信用していたからです。 しかし、その手塚理論のせいで江川はズボンを書く際に定規を使わなかったので、ズボンのラインがうまく真っ直ぐに書けず、困っていました。 ある時、江川が試しに定規を使ってズボンを書いて見たら、短時間でズボンをかっこよく描けたので「手塚先生、ウソを教えやがった」と愚痴を何かの書籍で述べていました。 マンガなど創作の分野の理論とはこういものです。偉い人が言ったから正しい、というものでもないし、当然、偉くない人が言ったから正しいというわけでもありません。 そうでなくて、実際に理論を手段として使ってみた結果、観客から見ても「かっこいい」「かわいい」「楽しい」という感情を呼び起こさせる作品をつくるのに役立つかどうかです。「かっこいい作品」「かわいい作品」こそが良い作品なのです。「理論どおりの作品」はけっして良い作品ではありません。だからマンガ、アニメ、ゲームなどの創作の理論とは、観客を楽しませる良い作品をつくるための手段の知識をまとめただけにすぎない道具が「理論」です。 だから、ある理論がもし創作の役に立たないなら、その理論はさっさと捨て去るべきです。少なくとも、その理論のために手間を掛けたのに作品を作っている自分すらも「かっこいい」「かわいい」「楽しい」などの感情を呼び起こせないなら、捨て去るべきです。 ;言語の必要性 では、理論は全く不要なのでしょうか。いいえ、そうではありません。知識や技法を言葉にすることで、覚える内容が明確化されるので、同じ手法を今後も何度でも繰り返しできるようになるという再現性（さいげんせい）が生まれます。 一方、勘に頼っていると、その日の体調や気分によって作品が左右され、再現性が不安定になるので、生産性もまた低下します。 この再現性のための言語化の必要性は、「アニメ私塾」のペンネームで有名なアニメーター・イラストレーターの室井康雄がたびたび彼のYouTube動画などで言っていることです。 しかしその室井もまた、「理論どおりに描いてみて、（かわいいキャラ、かっこいいキャラなどを）うまく描けないなら、その理論は捨てろ」という旨の発言を彼のYouTube動画などで言っています（少なくとも2021年の前半に言っている）。 さて、上記の手塚治虫の理論を信じた江川の例は、まだ手塚が漫画家の先輩でもあるので、信じてしまったのも分かります。 ですがインターネット上には、誰が提唱したかも分からない理論もあふれています。このwikiもまた例外ではありません。ゲームやアニメなどは新しい分野であるので、出典をつけるのが困難な分野もあるので、出典も不明な俗説・仮説に頼らざるを得なかったりします。また出典のある情報だけに頼ると、文章構成が著しく断片的になってしまい、読むに耐えないか、読者が理解できなくて教科書としての役に立ちませんので、そういった仮説どうしを文脈的に結合するためにwikiでは更なる仮説によって補充説明などを加えていることすらもあります。 なので、このwikiも含めて、ネットに書いてあることは信用せず、読者は実際に自分で手を動かして確認をとったことをもとに、技術や感性などを磨いていってください。 このwikiは参考のひとつ程度に留めておいて、提唱している仮説を試してダメそうだった場合は、さっさとこのwikiの理論を捨ててください。 ;ゲーム業界でも再現性あるマニュアル化が必要 ゲーム業界においても、『FGO』クリエイターの塩川洋介は、『ゲームデザインは「マニュアル化」できる』と、ある程度のマニュアル化ができることを認めています<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.23</ref>。 けっして、そのマニュアルは「普遍的」ではないですが、しかしだからといって、マニュアルも持たずに「センスや才能（※wiki追記: だけ）でやってはいけない」と忠告していますす<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.24</ref>。 なぜかというと、塩川氏も、「再現性」という言葉を使って、マニュアルの必要性を説明しています<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.26</ref>。 しかし、実際のゲーム製作は理論だけではうまくいかず、たとえるならスポーツのように実技的な側面もあります<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.40</ref>。 あと、盲点ですが、スポンサー企業などが、再現性がないと投資してくれないと、塩川氏は著書で述べています。 ただし、理論だけでなく、実技的な能力も必要であり、上記のゲーム業界の塩川氏もアニメ業界出身の室井氏も、よく創作をスポーツに例えています。結局、ゲーム産業だけでなくアニメ業界やマンガ業界の実務分野の教育者たちも、似たようなことをいっており、よくスポーツにたとえます。 創作の世界は、どこも似たような傾向があります。 なので、けっして頭でっかちにならず、実際に手を動かすなどして、スキルを習得していきたいものです。結局、ゲームも漫画もアニメも、マニュアル的なものを準備しつつ、それを検証しながら修正していく運用法が必要になりそうです。 そういう言語の限界を分かった上で、理論は使いましょう。 ;異業種の例 アニメ業界だけでなく、テレビCM業界など異業種でも、言語の必要性と似たようなことを言う人はいます。 97年にソニ－から発売されたゲーム『I.Q』の企画に携わった有名な広告プランナーの佐藤雅彦（お菓子のポリンキーなどのＣＭの人）は、 映画監督の川村元気の対談集『理系に学ぶ』で、 佐藤いわく「感性とか信念みたいなことを軽々しく言いたくないですよね。最後は感性で探り当てるしかないんですが、 そういった言葉ですぐ片付けるのは、傲慢な気がします。」と述べています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.62</ref>。 同じ川村元気との対談集では、別の対談相手ですが医学者の養老孟司は『戦後のものづくりなんかも大勢の理系の人が一生懸命トンネル掘ったり、計算機を作ったりしたけど、あれも嘘をつかない。要は言葉を信用してないんです。』と述べてます<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.15</ref>。第二次世界大戦の終わった昭和20年8月15日、それまでの日本の新聞やラジオなどのメディアが喧伝する常識が崩れたのです。 養老はそういう過去を振り返って、「言葉を信用しない」と対談集で述べています。養老の場合、嘘をつかない医学解剖に興味をもち、解剖学を専攻したと述べています。 さて、ガンダムなどで有名な富野監督は、2012年ぐらいの書籍か雑誌での対談インタビューで、 その本では異業種の人たちと対談していたのですが、おおむね 「アニメ業界は教育を見直して整備しないといけない。会社が実務的なこともっと教育をしないと、頭のいい若手は、自分で教育を始めてしまう。」といった感じのことを言っていました。もちろん、富野監督は、大いに教育をすべし、という立場であり、その若者を応援する立場です。 自発的に若者が教育を始めるのなら、それだけ聞けばよいことのように思えますが、しかし富野監督がわざわざこういう苦言のような言い回しでいうことには、なにがしか、周囲からの反対意見などもあったんだろうとか、読者は推測してください。大人には、企業の事情などで言えないことがあるのです。 たとえばガンダムを作っている会社は「サンライズ」というアニメ会社なので、他社（たとえばエヴァンゲリオンの会社なら「ガイナックス」とか「カラー」という別アニメ会社です）に所属する若手アニメーターの主催するアニメ作画勉強会に出席するのは、いろいろと大人の事情があり、周囲からは疑義も出てくるのです。 富野監督はさらに、その対談書で、「自分だって絵を描くときにフォトショップを使っている」ということも言っています。もしかしたら、フォトショップに対する反対意見とか、いろいろあったんでしょう。 どこの業界でも、実務教育はいろいろと難しいものです。 }} {{コラム|それでも読書が必要なわけ| 創作は、読書だけでなく、スポーツ的に実際に手を動かして作品を作る経験も多く必要です。 それでも やはり読書は必要になり、ゲーム業界人の書いたゲーム専門書やゲーム制作教本などを読む必要が出てくるでしょう。 あまり何十冊も読む必要は無いですが、本屋で2冊くらいは教本を買って読んでおくと良いでしょう。 ではなぜ読書による勉強も必要なのかの話をします。 それは、業界の中にいる、ダメな先輩をダマらせるため、ダメ先輩に足を引っ張らせないためです。どこの業界でも、不勉強・経験不足な割に年功序列などで出世してきている先輩がいます。あるいは、勤勉ではあっても、自社でしか通用しないヤリ方を、業界全体の標準ケースだと勘違いしている先輩もいます。 そういう、ちょっと困った先輩を、それとなく間違いに気づかせるために、同じ業界でもっと経験のある専門家の書いた文献を読むのです。 たとえば、入社1年目の新人には、入社5～10年目くらいの上司がついたりするわけですが、所詮は入社10年目程度の中年サラリーマンなので、間違ったことを教える場合もあります。そこで、同じ業界の20年選手や30年選手のベテランの書いた本を読むのです。 だから、本屋で2冊くらいは、業界のベテランの書いた教本を買って読んでおけばいいのです。 このwiki『ゲームプログラミング』でいろんな分野を何十冊も出典紹介していたりするのは、単に著作権上の都合にすぎないので（もし1冊の本だけを書き写したら著作権侵害になる）、ゲーム制作にはそこまでの多くの文献は不要ですが教科書著作のため仕方なく多くの文献を確認しているだけにすぎません。読者はwiki編集者の読書法・勉強法を真似る必要は無いですし、真似るべきではないです。 ネットの情報をあさるのではなく、実際に本で買って読むのが必要です。なぜなら、ネット情報だと、本気度が分かりません。webサイトのスポンサーの都合などもあり、言いたいことが言えないケースもあります。だから、実際に書籍として出版されている本を買いましょう。 }} == 予備知識と学習法 == === 予備知識 === 一応、ターン制RPGは関数や配列を知らなくても、作り始めることはできます。 最低限必要な知識として、変数と、キーボード入出力の関数と、if文、タイマー関連、画面出力、あとはせいぜい乱数などがあれば、ゲームを作り始めることができます。 これはRPGにかぎらず、よくプログラミング入門書にあるジャンケンゲームなども同様でしょう。ジャンケンゲームならタイマーすら不要でしょう。 しかし、「関数を知らないプログラミング」とは、たとえば、zボタン（決定ボタンとする）を押したときのプログラム記述で、DXライブラリでの開発なら、マップ画面モードでも戦闘コマンド画面モードでもタイマーをカウント開始すると思いますが、そのタイマーの開始命令と関連する処置を各画面ごとに1行ずつ書いていく方式です。 だからもし、バグなどがあってコード修正する際、すべての画面モードのzボタンを命令を一個ずつ直さなければなりません。RPGはモードが多いので、そのような修正は、なかなか面倒です。 だから、別に作り始めの時点で関数を知らなくてもいいのですが、しかし作っている途中に「バグの訂正で似た部分の繰り返しが多くて面倒だなあ・・・」という気分になったら関数も勉強していくのが望ましいでしょう。 そして、いつごろが関数を学ぶタイミングなのかを知るには、事前に自分がある程度は「関数というものがあって、コードの使いまわしに便利なものらしい」という知識が必要です。 配列も同様です。配列を知らなくても、パーテイ1人目のHPを変数名「p1HP」、パーティ2人目のHPを変数名「p2HP」のような方式でRPGを作れます。 しかし、これを敵15体も登録されているRPGで「m1HP」から「m15HP」とやるのは、少し面倒です。 なにより一番の問題は、配列を知らないと、ドラクエ1的なマップ画面すら作るのが、かなり困難になることです。 よくプログラミング教本などにある例では、マップを二次元配列で実装しています。 たとえば、書籍『12歳から始めるゼロからのC言語 ゲームプログラミング教室』がそうです<ref>大槻有一郎『12歳から始めるゼロからのC言語 ゲームプログラミング教室 Visual Studio 2015対応』、2016年3月1日 第1刷発行、2017年4月10日 第2刷発行、P165</ref>。 たとえば、 <pre> { {0,0,0,0,0,0,0,2,2,2}, {0,0,0,0,0,0,0,2,2,2}, {0,0,1,1,0,0,0,2,2,2}, {0,0,1,1,1,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0}, } </pre> みたいな感じで、0番が草原、1番が森、2番が岩山、のような感じです。 横10×縦5のマップはそれほど広くないですが、 たったこれだけのマップでも、もし配列を知らなければ変数が50個必要です。 「配列を知らなくてもRPGを作れる」というのは、たしかにノンフィールドRPGなどは作れますし、 あるいはフィールドがあっても「マップはすべて草原、あるいはマップの99%くらいが草原（草原でないところだけ変数指定する方式）」のようなゲームなら作れますが、 しかしそれは、多くのRPGプログラミング入門者が考えているような、ファミコン～スーファミ水準のドラクエ・ファイファン的なイメージのRPGとは異なります。 初心者に「配列を知らなくてもいい」というのは無責任です。 配列を知らなくてもゲームプログラミングは開始できますが、もしも配列が必要になった時点で（変数を一個ずつ宣言するのが面倒なモジュールを作るとき）、 配列を学び始めるのが良いでしょう。 === 作ってから学ぶ === 別に市販のC言語の入門書の基礎文法すべてに精通してからゲームプログラミングを開始する必要はありません。 おおよその機能だけを市販のC言語入門書に目を通して知っておいて、プログラミングでは変数などの初歩的な知識だけを用いて作り始め、足りない知識は必要になったらそのたびに、市販の入門書などで学べばいいのです、 また、その市販のC言語入門書を読む時間も、通学中・通勤中で電車のイスに座ってる時に読むとか、あるいはトイレでウンコしている時に読むとか、そういう時に読めば、プログラミングの時間を減らさずに時間を有効活用できます（ただし睡眠時間や食事の時間などは減らさないようにしましょう）。 さて、セーブやロードなどの機能は、当分は不要です。そもそも、セーブが必要なほどの長さのシナリオなんて作るのは当分は後です。もしお作りのゲームが1分でクリアできるようなゲームなら、セーブなんて不要でしょう。 だから、C言語のファイル入出力の機能などは、当分は不要です。 つまり「学んでから作る」ではなく「作っているうちに気になった点を調べる」のがコツでしょう。 おそらく「関数を知らなくてもRPG作れる」といっているプログラマーはたぶんそういう事を言いたかった口ベタな人なのでしょう。 なお、配列や関数などは、自分が直接は使わなくても、他人が使います。 たとえば、マップの実装で、もしかしたら二次元配列を使わなくても、原理的には一次元配列を何十個も並べて実装する方法もあるかもしれませんが、しかし他人がそういう一次元配列を何十個も並べてマップ実装したコードなんて読みたくないし、教育者も面倒なのでそういうコードを教えてくれません。 なお、構造体は別に知らなくてもRPGは作れます。列挙体 enum なども同様です。単に構造体の配列を知っていると、（装備品やモンスターなどの）データベースを第三者がより読みやすい形で作りやすくなるだけです。列挙体を知っていると、モードの切り替え（マップ画面モードからメニュー画面モードへの切り替え等）をしやすくなります。 正直、市販の「ゲームプログラマー向け」をうたったプログラミング教本の中には、少なくともゲームプログラマー初心者の時点では不要な高度な知識も多く紹介されています。しかしそういう本でも、出版社などの宣伝の都合からか、「プログラマーになる前に読んでおきたい」みたいな宣伝文句が付けられたりしているかもしれません。そういう高度な知識もあとで仕事で必要になる場合がありうるので、ゲームプログラマー向けとして出版する事自体は正しいのですが、しかし初心者や入門書に進めるような宣伝文句をつけるべきかというと・・・となる内容の市販本もあります。 === ポインタ不要論 === よく、「ポインタによる処理で速度の向上!」みたいな事が、ゲーム好きのプログラマーに言われます。 しかしポインタによるコーディングは、プログラムのメンテナンス性を悪くします。なぜならもしポインタ使用個所の周辺でバグが発生した場合に、ポインタがあると原因が特定しづらくなるからです。 一般のグローバル変数やローカル変数と比べてポインタ変数は仕組みが単純ではないことや、配列や構造体にポインタなどを用いる場合はもしその配列・構造体にバグがあると同じ配列内・構造体の別の部分にまでバグが波及するなどするので（コードによっては、もしかしたら、下手したら周辺の別の配列や構造体に波及する場合もありうるかも）、ポインタで実装されたモジュールがあるとバグ発生時に原因の絞込みが難しくなるのです。 もし仮にポインタ処理化を実装した直後では正常に動いていても、しかしあとで、今まで未実装だった部分が実装された場合に、なんらかの不整合によるバグが発生するようなことも良くあり、ポインタ処理はその際、バグ原因の特定を難しくします。 だから仮にどうしてもポインタを使わないといけない場合でも、RPG製作なら、なるべくポインタを実装するのは後回しにして、当分は一般の変数で実装したままにしておくほうが良いかもしれません。 あるいは、もし機能の実験や勉強を兼ねてポインタ処理の実験と実装をしたのなら、現状ではポインタ変数で実装してある箇所でも、あとでデバッグなどの際に一般の変数に戻す可能性も考慮することになります。 RPGの場合、デバッグに時間を多くとられますし、変数がとても多いので、メンテナンス性も考慮せざるを得ません。 ;そもそも本当にポインタの必要な処理か? ポインタによって高速化のメリットが得られる場合とは、C言語教科書などの理論では、大量の要素の構造体を（関数の引数などとして利用する際に）コピーする場合ぐらいです。 だからもし構造体を使う場合であっても、そもそも自作で用いる構造体変数がグローバル変数であればコピーの必要自体がないので、ポインタの必要もありません。 ゲーム内の武器データベースやモンスターデータベースなどが構造体で実装されると思いますが、初心者なら普通はそれらの構造体変数はグローバル変数として実装することになるでしょうし、グローバル変数として実装しても何も困りませんし、実際それでもRPGを作れますし、正常な速度で動きます。 例外的な事例を考えるなら、たとえばマップイベントのデータベースなど、特定のモードでしか使う機会のないデータベースなら、理論的にはグローバル変数でなくポインタによる取り扱いによって処理速度の向上の可能性はありえますが、しかし正直メンテナンス性が悪いし、難しい割にはポインタ化してもしなくても初心者ゲームのレベルでは速度は変わりません。せいぜい勉強になるだけです。 こういう風に、市販のC言語教科書にある知識の一つ覚えは、通用しません。 == 設計の方針 == === 身体障害者プレイヤーの配慮 === ターン制RPGは、身体障害などでアクションゲームなど反射神経を要するゲームの苦手な人もプレイします。なので、それを意識した設計にしましょう。シミュレーションゲームも同様です。もっとも、さすがに腕のないプレイヤーにまでは配慮できないので、程度問題ですが。 ともかく、だから、もしどうしても制作中のターン制RPGにアクション要素のあるイベントを入れる場合、たとえば工夫として、 事前にそういうアクションイベントのあることをプレイヤーに作品紹介文などで紹介しておくとか、 あるいはそのアクションイベントをもしクリアできなくてもプレイヤーがゲームクリアできるように設計するなどの配慮が望ましいでしょう。 もしくは、充分にアクション要素の難易度を下げておく必要があるかもしれません。 === ユーザーインターフェース === もしもC言語でゼロからゲームを作るなら、UI（ユーザーインターフェース）をゼロからDirectXなどで作ることになります。 シナリオどうこうより、まずUIを作るのが真っ先になります。 結論から言うと、需要のあるUIの種類はそんなに多くなく、よって最終的には既存の有名ゲームのUIを真似することになります。（練習として新規のUIを色々と制作してみるのは構いませんが、しかし実用的なものを新規に発明するのは困難かと。） ==== 「はい」/「いいえ」の選択肢 ==== RPGなどで選択肢で『はい』か『いいえ』がよく出ることがあります。 この場合、必ずしも順番どおりに はい いいえ とするのが良いとは限りません。 なぜなら、プレイヤーがセリフ送りなどでボタンを連打している場合に、あやまって選択肢も連打してしまうことがあるからです。 文献『ゲームプランとデザインの教科書』によると、選択肢の順序についての設計テクニックとして、現状を維持するほうの選択項目を先に表示したりとか、あるいはマウス操作式のゲームなら現状維持や安全なほうの選択肢にカーソルを事前に合わせておくなどの工夫が、定石とされています<ref>『ゲームプランとデザインの教科書』、P399</ref>。 ==== 健康上の留意事項 ==== ===== カーソル点滅と「光過敏性てんかん」 ===== 例えば、コマンド選択などのカーソルの方式には、 :ファミコン時代のＦＦ（ファイナルファンタジー）のようにカーソル画像を選択内容の左隣に置く方式、 :あるいは、ツクールのゲームの標準設定のように選択項目の背景が点滅する方式、 など幾つかあります。 カーソル点滅させる場合、実はこれはほとんど、カーソル点滅色は白系の色にせざるを得ません。 なぜなら健康上の理由があり、もし青色ウィンドウなのに、たとえばカーソル色を赤（または緑にして）、赤カーソルを点滅させると、「光過敏性てんかん」のような症状を引き起こします。このため、点滅カーソルの背景色は、事実上は、ほぼ白色に決まります。 一応、白でなくても、たとえば青ウィンドウなら水色などの背景色でも可能ですが、手間が増えますし、ほかのウィンドウ色（たとえばウィンドウを赤に変更した場合）では応用が利きません。 ゲームによっては設定カスタマイズなどでウィンドウ色を変えられたりしますが、プログラマー的に分析するコツとしては、カスタマイズできない部分（たとえばカーソル色はカスタマイズできない等）にも注目すると良いでしょう。 ===== 色弱の対応 ===== なお、色弱（しきじゃく）/色盲（しきもう）という病気があり、緑色と赤色の区別がつきづらい人が、世間には居ます（赤緑色盲）。例外の人もいて、青など他の色が見えない人もいますが、しかし色弱患者で統計的に割合がもっとも多いのは赤緑色盲です。 赤緑色盲の人には、赤も緑も、ともに茶色に見えます。なので赤緑色盲の人にあ、赤と緑を区別できないのです。 よって事実上、ウィンドウ色は原則的に青色になります。ファイナルファンタジーや昔のツクールなどが、ウィンドウ色に青色を標準的に採用しているのは、決して偶然ではなく、いろいろな事情があるのです。 どうしても同一画面に赤と緑を表示しなければならない場合、色の濃さを変えるなどして、たとえば濃い緑と、うすい赤、などのように濃度差をつけるなどする必要があります。（この濃度差の手法は、役所などの出す、色覚障碍者向けのガイドラインなどにも書いてある、典型的なアドバイスです。 ） そもそも、色盲でなく健常者でも、濃度の同じくらいの赤色と緑色の組み合わせは、やや見えづらいです。 学校の「黒板」という緑色の板に、赤チョークで書かれた文字が、見づらかった記憶をもつ人も多いでしょう。 なお、赤緑色盲の人でも、黄色は、茶色とは区別して見えます。 なのでウィンドウに、黄色っぽい色と黒を組み合わせて使うのも手です。 あるいは、うすい茶色に、黒い文字という組み合わせもあります。 たとえばロマサガ1は、うすい茶色のウィンドウに、黒い文字です。うすい茶色と黒との組み合わせは、明度も大きく異なっているので、良い組み合わせでしょう。 スーファミ版の三国志4のウィンドウ色と文字色も、似たような組み合わせです。ただし三国志4の場合、文字に白い文字を使う場合もあります。数値などは白い文字です。このため、ウィンドウの茶色部分にはザラザラした模様をつけて白い文字を際立たせる工夫をしたりなど、工夫をしています。 ゲームに限らず、たとえば子供むけの歴史教材や小中学校の歴史教科書などでも、よくコラム欄などで、黄色い背景に黒い文字の組み合わせは使われます。古文書のような古い紙は黄ばんでいるので、歴史教材のコラムではそういう雰囲気に近づける目的で、コラムの枠を古文書の一ページのように描いているものもあります。 ゲームでもロマサガ1のメニューウィンドウは、古文書のように紙の下側の一部が書けていたり、まるで巻物の読み方のように左右が曲げられていたりして、ウィンドウに紙っぽさを出すデザインをしています。 例外的に、商業ゲームでもプレステ作品『俺の屍を越えてゆけ』のようにウィンドウがエンジ色（赤色っぽい色）の作品もあります。このようなUIの差異、当然ですが緑色の文字は使用不可能です。 {{コラム|回復量のフォントのうすい緑色について| よくツクールやウディタの同人ゲームで、 回復スキルをつかったときの回復量の数値のフォント色を、うすい緑色または水色っぽい色で表す場合があります。 しかし、攻撃ダメージのダメージ量の数値のフォント色は、ほとんどのゲームで絶対に白色ばかりです。 どこまで同人作家が色盲を意識しているかは知りませんが、 もしダメージのフォント色が赤色だと、色盲（赤緑色盲）の人には、これは回復スキルの緑色と区別できないのです。 ついつい出血の赤色を意識して、赤いフォントを使ってみようと思うかもしれませんが、しかしその場合は色盲の人にはプレイできなくなるゲームになることを覚悟する必要があります。 これはつまり演出面で考えれば、色盲の人には、血の色（赤）と、草の色（緑）とが、同じ色に見えていることを意味します。 }} {{コラム|色パズルのミニゲーム| ウィンドウを決める場合だけでなく、ゲーム中のミニゲームの暗号パズルなどで色を使う場合も、色盲に配慮しなくてはなりません。 ぶっちゃけ、商業RPGゲーム中にもしミニゲームとして色パズルの暗号イベントがあるなら、 暗号の正解に使える色は、もしそのパズルがクリア必須イベントなら、答えの色は必ず、赤・緑の以外の色になります。 だから答えに使えるのは、商業ゲームなら必ず、黒か黄色か青か灰色か白、のどれかです。 なぜなら、まず赤と緑は当然ながら使用不可能です。さらに、赤と青の混色である紫も使用不可ですし、 青と緑の絵の具の混色（減法混色）である青緑色も使用不可ですし、 青と緑の光の混色（加法混色）である水色も使用不可です。 橙色も、赤と黄色の混色ですので不可能です。 学校教育ではどうやら、こういう色盲のことはゲーム産業やIT産業の志望のための学校ではあまり教育されていないようですが、しかし電気工学の学校ではよく教育される知識です。 電気工業の分野で、抵抗の「カラーコード」というものがあって、下記の色がそれぞれ下記の数に対応しています。 :黒 0 :茶色 1 :赤 2 :橙 3 :黄色 4 :緑 5 :青 6 :紫 7 :灰 8 :白 9 国家資格の電気工事師は、抵抗素子についているカラーコード部分の色を見て、抵抗値を判断するスキルが必要です。 なので、昭和の規制の厳しかったころは、色盲の人はそもそも工業高校の電気科には入学できませんでした。どんなに中学の成績がよくても、色盲の子は工業高校電気科への受験自体を断られる時代があったのです。 電気工学の教科書には書かれていませんが、工業高校や大学工学部の電気系の学科に入学すると、もしまともな学校ならば、こういう事を教わるものです。 }} ===== 車酔いの防止 ===== 光の点滅以外にも、調整を誤るとプレイヤーに体調不良を及ぼす現象はあります。 、 たとえばキャラの移動速度の加速・減速は、なるべく滑らかに変化しなければなりません。 「車酔い」を思い出してください。もし急加速と急ブレーキを繰り返す車に乗車していれば、多くの乗客は酔います。 なので、たとえばRPGなどで、「マップの1マス移動後にいったん停止」というのは、避けたほうが安全です。 実際、ドラクエは決してそうなってはいません。行き止まりに当たらない限り、カーソルの左ボタンを押していれば、同じ速度で左に進み続けます。（右キーの場合も同様。） ドラクエの移動速度が等速度であることには、合理的な理由があるのです。 ;動きが時々カタつく場合 自作ゲームでテストした際、マップ移動中に右キーを押し続けたときに普段は等速で移動するのに時々カタつく場合があるかもしれません。その場合の対処法を後述で説明します。（2Dゲームのマップ機能の原理については、セクション『[[ゲームプログラミング/RPG#2Dマップ]]』で後述してある。） なお、普段から等速ですら移動しない場合は、単にバグですので、直してください。 このセクションでは、とりあえず普段は右キーを押し続けたら等速で移動するのに時々カタつく場合にだけ、よくある原因そのと対処法を説明します。 時々テストプレイ中に動作がカタつくことがあり、「バグか？」と不安になることがありますが、しかし必ずしもバグが原因でのカタつきとは限りません。 もしかしたら、Visual Studio コンパイラがメモリ圧迫またはCPU占有などをしていて、単に実行アプリの処理速度が低下しているだけかもしれません。プログラミングに熱中していると盲点ですが、Visual Studio はメモリやCPUの多くを占有することを思い出しましょう。 原因がそれか否かを確かめる簡単な方法は、まったくほかのアプリを起動していないときに、実行ファイルを起動してテストプレイしてみることです。 ただし、状況によってはその「実行ファイル」をビルドするためにVisual Studio を立ち上げないといけない場合もあり、なかなか面倒な作業でもあります（VSは終了や起動に時間が掛かるので面倒）。 1度に確認しようとすると面倒ですので、複数日に分けて確認しましょう。たとえば、このカタツキ問題が気になったときの睡眠前の晩にでも、事前に実行ファイルをビルドしておいてから Visual Studio を終了してから寝ましょう。そして翌日にでもwindows起動したときに、Visual Studio を起動せずに前日にビルドしておいた実行ファイルだけを起動してテストしてみましょう。 そのほか、この問題の検証方法として、どうしても Visual Studio 起動中に、メモリやCPUの圧迫によってカタついているか否かを判定したいなら、簡易的な方法ですが、 最近のRPGツクール製のゲームまたはウディタのサンプルゲームを起動してみて、カタつくかどうかを確かめてみる方法もあります。 もしVisual Studio によるメモリ圧迫やCPU占有がカタつきの原因なら、ツクール製ゲームやウディタサンプルゲームでもカタつくことがあります。いわゆる対照実験です（中学高校の理科（おもに生物分野）で習うアレです）。 上述の方法すべてを試してもカタつきの問題を判明できない場合、残念ですが当ページには原因がもはや分からないのが現状です。（もしお作りのRPGでのカタツキの原因が分かられて、他のプログラマーも遭遇しそうな原因でありましたら、情報提供のため編集に協力していただければ当wikiとしては幸い（さいわい）かもしれません。） ;高度な検討事項 前セクションの工夫でカタつきが解決すれば、下記の方法は不要です。また、ヘタにいじってバグの原因になると危険ですので、前セクションで解決したなら、そのままにするのをお勧めします。このセクションでは、参考のため、下記のような方法の検討を照会します。 動作をより滑らかにする工夫の一例として、たとえば、キーボードの十字キーの入力判定は、必ず1マス歩行のアニメーションの移動終了の少し前までに、判定を終わらせる工夫などが、考えられます。たとえば、1マス歩行のアニメーションが1.0秒かかるなら、入力判定は0.9秒目に行う、というような感じになります。 しかし、これはけっこう、シビアな条件であり、0.1秒単位でのタイミング調整を行わなければなりません。 歩行で1.0秒間というのは、割とゆっくりです。 一方、もしダッシュ機能とかあってダッシュ速度が1マスあたり0.5秒間だと、すこしタイミング調整が難しくなるでしょう。 もっと早いダッシュの場合は、Windowsだと少し難しいかもしれません。なぜなら、WindowsAPIのタイマー機能がそもそも、そんなに正確ではありません。0.05～0.10秒くらいの間隔になると、タイマーに誤差が出てきます。 DirectXのタイマーも、それに準じた性能だろうと思われます。なので、あまりに早すぎるダッシュでは、歩行のように「直前に入力判定」というのが、難しいかもしれません。 あるいは、もしかしたら、現代のコンピュータは処理速度が速いので、1.0秒のアニメーション終了後に入力判定を行っても、プレイヤーには気づかれないのかもしれません。 しかし、ハードウェアのメモリ容量などの事情によっては、もしかしたらアニメーション終了後の方式だと、動きにカクツキが出てくるかもしれません。ともかく、このように、速度ひとつとっても色々と考えなければならないことがあります。 こういうふうに、歩行アニメーション処理は、こりだすと、検討事項や調整事項が意外とあるので、初心者にはやや難しいです。 だから初心者には、歩行アニメーション抜きの方式がラクであり、いきなりキャラチップが移動先の隣マスに移動する方式（ファミコン時代の『信長の野望 武将風雲録』の戦闘の武将キャラチップみたいなの）のほうが、簡単でしょう。 同じ理由で、カメラの位置や向きなども、むやみに移動しないか、等速で移動しつづけるように注意する必要があります。 もし、「リアリティを出そう」としてカメラをキャラ歩行のたびに左右に振ると。プレイヤーが酔って気分が悪くなりかねません。よほど上手く調整しないかぎり、プレイヤーの体調的な気分を悪くしかねません。 だからカメラアングルで目指すべきは、2Dゲームなら結局、スーファミあたりのドラクエ的あるいはスーパーマリオ的な古典的なカメラ視点であるべきす。あるいは、もしポリゴンゲームなら、結局、カメラアングルで目指すべきは、プレステ1やサターンの時代のころのゲームのカメラアングルなどになるでしょうか。 あるいは、ファミコン時代にどうしても歩行アニメーションを停止しなければならなかった例として、ファミコン時代のウィザードリィや女神転生の3Dダンジョンのように、ポリゴン描写が無理などの理由で、どうしても停止しなければならない場合もあるでしょう。このような場合は、おそらくですが、停止中の1枚絵の表示時間の長さと、進行中の中割り（なかわり）の1枚絵の表示時間の長さが、同じぐらいの長さになるようにしないと、マズイでしょう（未確認）。 ==== 実装しようとしているものを明確にする ==== UIにおいて、アナログをデジタルで完全に実装するのは、大概困難ですが、アナログの「エミュレート」の実装は、それほど困難ではありません。 これはゲーム制作でも同様です。 たとえば、RPGの作中の武器屋や道具屋などでの買い物のシステムは、現実のスーパーマーケットやコンビニでの買い物とは異なり、まとめ買いはサポートされていないことが有ります。 ゲーム以外の話だと、たとえば通販サイトでの買い物の際、ユーザーレベルの目線では、サーバー側で異なるアイテムを連続して買う行動が一連のトランザクションとして処理されていたとしても、同様のことがありえます。 さて、ゲームでは、プレイヤーにとっては操作がやや面倒でも、デバッグの都合やメンテナンス等の都合で、あえてデジタル的な操作をしているゲームもあります。 たとえば昔のドラクエ3では、酒場で仲間をパーティに加入させる際、1人ずつ逐次的にコマンド入力をして加入させる必要がありました。（「3人まとめて加入」とかしたくでも、できない仕様。）ウィザードリィなどでも同様で、仲間のパーティ加入の編成などは、一人ずつ逐次的に操作する必要がありました。 このような、「まとめて〇〇を編集・編成」みたいな処理は、その分状態（取り得るケース）が増えるため、それに比例してデバッグにかかるコストが増える場合が有ります。 {{コラム|ゲームはゲーム以外の操作性を取り入れられるか？| ;家電とはゲームは操作性が異なる 上記のケーススタディの教訓としては、つまりデジタル家電（地デジ対応テレビやMP3プレイヤーなど）のような操作仕様ですら、ゲームには不適切な場合があります。（家電のハナシ）現実世界で機能に直接対応したボタンのある家電と、一方でゲーム中の選択肢だけしか（十字キーなどを介して選択してからでしか）押せないゲームとでは、操作の前提条件が異なるのです。 アナログ家電（アナログ放送テレビや銀塩カメラやラジカセなど）と、（デジタルコンテンツである）ゲームとでは操作性が異なるのはもちろんですが、デジタル家電ともゲームは操作性が異なることに、気をつける必要があります。 }} {{コラム|CGアルバム機能| アナログとはやや違いますが、例として、たとえばゲーム中に、CG閲覧機能として、プレイヤーがゲーム中でクリアしたイベントに関するCG閲覧機能などがある場合で、「アルバム機能」などの名前が付いている場合を考えましょう（2000年以降のノベルゲームなどで、よくある機能です）。 「アルバム」等の名前から、ついつい仕様の設計時には、実際の写真アルバム（物理）の操作性を真似したくなるかもしれません（つまり、「本の手触り」的な）。具体的には、電子書籍のようなUIを実装しようとか、思うかもしれません。 ですが、ゲームにおけるアルバム機能では、そういうことは無視して、単にCGの閲覧と検索のしやすさだけを考えたほうが、操作性とメンテナンス性もよくなるでしょう。 }} === 画面更新と速度との関係 === * 60 FPSは意外と遅い DXライブラリは、標準的な映像モニタでは、1秒間に60回のループ更新をします。 これは、一般的な映像モニターの画像の更新回数が60Hz、つまり映像モニタでは1秒間あたり60回の更新があるので、 プログラム側の更新回数もそれにあわせたものです。（これらのことを「60 FPS」などという。） このような、映像の更新の早さの度合いのことを'''フレームレート'''といいます。 さて、人間の計算速度と比べたら「1秒間に60回」は速いですが、しかしゲームとしては、必ずしも速くありませんので、そのギャップに気づかないとプログラマーは不安に「パソコンが処理落ちしてるのか？」と悩んでしまいます。 たとえば、アニメーションの表現などとして、キャタクター立ち絵が1ピクセル（1px）ずつ1回の画像更新で移動したとしましょう。 すると、1秒たっても60pxしか移動しません。RPGツクールの標準の画面サイズは横816px、縦624pxなので、つまり60pxの移動では、画面の10%にすら到達していません。なので、もっと早い速度で立ち絵を移動させたい場合、1回の更新で3pxや5pxあるいはそれ以上のピッチ間隔で画像を移動させる必要があります。 このことに気づかないと、立ち絵の高速移動のつもりで1pxずつ動かしても、画面の横幅の10%すら動いてないので、「まるで処理落ちでもしているのか」と錯覚しがちで不安になりますが、しかし1pxずつ動かした際に意外と遅く見えるのは正常な動作です。そういう速度計算での命令文だからです。 具体的にはどう悩むかと言うと、RPG制作の場合ならばマップチップの枚数が多いので「もしかしてマップチップの読み込み方が間違っていて処理落ちしているのか？」とか、あるいは「キャラ画像の周囲の透明処理による負担が重いのか？」とか色々と不安を思ってしまいますが、まったくの無関係です。 1更新あたりに1pxのピッチ速度とは、それだけ遅いのです。なので、1秒後に画面内でチョコっとしか動かなくても、1秒後に動き終わっていれば正常です。 さて、ついでの話題ですが、もしアクションゲームやシューティングゲームなどで、1更新あたり5pxや10pxといったピッチで攻撃対象の敵などが動いている場合を考えて見ましょう。 たとえば、もし移動中画面で、現在の瞬間の描画位置　から　次の瞬間の描画位置とのあいだの中間位置、つまりピッチの中間の場所に自キャラの放った攻撃などが当たったときの例を考えてみると、なかなか悩ましい問題でもあります。つまり、画面上ではピッチの中間の場所には映像が書かれていないのに、なのに、その場所に攻撃を食らう「当たり判定」が存在するからです。 実際、アクションゲームなどで、高速で動く敵の軌道上に攻撃を放ってみると、画面上にいない位置なのに、攻撃があたる場合もあります。 だからファミコン時代あるいはそれ以前のゲームセンター時代といった黎明期のシューティングゲームですら、高速で動く弾丸チップや機体チップなどの表現には、とても工夫しているのでしょう。 このように、キャラチップなどの画像を高速で動かすのは、思いのほか、調整事項が多くて大変です。なのでRPG制作の初心者は、あまり高速な描画表現には手を出さないほうが無難です（まずプログラミングの全体像を作る必要あるので）。 {{コラム|実写でもフレームレート問題はある| 実写の動画ですら、フレームレートの遅さに由来する違和感は生じます。実際、実写映画のDVDなどをコマ送りで見てみると、意外と動きが飛び飛びです。 人間は1秒間のあいだに、意外と多くの動きをしています。たとえば仮に、おやつのドーナツを食べる実写動画を例に考えてみると、1秒間のあいだに、まずドーナツに手を伸ばしたあとに、つまみあげて口元に持っていくぐらいの動作を、人間は1秒のあいだで平気でしています。もしアニメキャラだったら、ひょっとしたらドーナツ一噛みを始めているぐらいです。 このように1秒のあいだに多くの動作をするのに、たった60コマのフレームレートしか用意されていないのです。だからコマ送りで実写の動画を見ると、けっこう動きが飛び飛びで、まるでアニメを見ているかのような感覚です。たとえるならアメリカ製のアニメ映画は、日本アニメよりも1秒のコマ数が多く、日本アニメが1秒で8コマなのにアメリカ制アニメが1秒で24コマの違いはありますが、しかしアニメはしょせんアニメのような飛び飛びの動きです。実写の60フレームレートですら、アメリカ製アニメのたったの約2倍しかないフレームレートです。 また、半導体の性能向上は2010年以降は止まっていることなどを考えれば（「ムーアの法則」の破綻）、今後に市販の液晶モニターのフレームレートが飛躍的に上がる可能性は乏しいでしょう（説明の便宜上、液晶も「半導体」として扱った）。 さらにもし仮に製造業で技術革新が起きたとして、液晶モニターのフレームレートを飛躍的に十倍や百倍に向上させる新技術が出来たとしても、今度はハードディスク容量の問題があり、つまりフレームレートがもし10倍になったら、録画映像の容量バイト数も10倍になります。つまり、アニメや映画のブルーレイディスクなら、ディスク枚数が10倍になることを意味するし、これはつまりアニメなら作画枚数が10倍になるし、消費者にすればディスク購入費用も10倍ですし、生産者側からすれば予算も10倍なので投資リスクも10倍です。 このような技術的制約および経済的制約から、今後のフレームレートの向上の可能性はなかなか乏しいと考えざるを得ませんし、仮にフレームレート向上しても恩恵を受けられるのは実写やCGなどのようなアニメーターが手で作画しなくて済む分野の映像だけです。 }} === 万全のゲームシステムは無い === 少なくとも2D-RPGのゲームシステムやその実装に関する限り、処理が早くて操作性も良くてメンテナンスもしやすくて・・・のような究極万全なシステムやアルゴリズムは一切ありません。 たとえば操作性の分かりやすいアルゴリズムなら、おそらくはプレイヤーのさまざまな発想に対応するためにif文の分岐増えたり、あるいはグラフィカルに説明するために画像の制御が追加で多く必要になったりするなどして、そのぶん他の特性が悪化しますし、説明用グラフィックが増えれば処理速度の負担にもなります。 しかし現在のパソコンではファミコン時代よりも桁違いに多くのメモリ容量を扱えるようになり、CPU性能も桁違いに向上しました。よってゲームプログラミングでは基本、処理落ちをしない程度にまで処理速度に負担を掛けて犠牲にして、そのぶん操作性やグラフィック性やゲーム性やメンテナンス性などを向上させることになるでしょう。 だから実はファミコン風のドラクエ1のような簡素なプログラムでも、あれはあれで処理速度とメンテナンス性をもし最優先に目指すなら現在でも合理的な一形態なのです。 また、ドラクエ1的なアルゴリズムはメンテナンス性がよいので開発もしやすいし、開発時のデバッグもしやすいです。なので、私たちがRPGを手元でプログラミングして作る場合も、まず2D-RPGならドラクエ1～3のようなUIをまねたゲームを作ることになるでしょう。 ただし、真似るのはあくまでUIのみです。パスワードシステムのような、セーブ機能の発達した現在では不要なシステムを真似る必要はありません。「話す」コマンドとか「とびら」コマンドみたいに、現代では不要になったコマンドも不要でしょう。また、ドラクエのウィンドウ色は黒色ですが、しかし私たちにはデバッグの都合のためファイナルファンタジーや昔のツクールのような青色を基調としたウィンドウのほうがデバッグしやすいかもしれません。 だから初心者は、昔のRPGツクールっぽくアレンジしたドラクエ風UIを作ることになるでしょう。（ドラクエの難易度デザインやストーリー性などはプログラミングではないので、本ページでは言及しません。） == 製作の順序 == 本ページでは説明の都合上、RPGをモジュールごとに分割して説明しています。 たとえば、マップ関連のモジュール、戦闘関連のモジュール、装備関連のモジュール、のようにです、 しかし、実際のゲーム製作での開発順序は、少なくともRPGをVisual C++でゼロから作る場合においては、けっして、「マップモジュ－ルを完成させてから戦闘モジュール」のような順序には'''なりません'''。 そうではなく、まず自分が興味をもったモジュール（仮にマップモジュールとする）の初歩を作り始めたあと、とりあえず操作できて満足できるところまで作ったら、 次に関連する別モジュール（たとえば戦闘モジュール）を作る、というような順序です。 たとえば、すでにマップモジュールがあるなら、戦闘モジュールを作り始める際に、まずマップ画面上に固定敵を配置することで、 戦闘モジュールのテストをしやすくなります。 このように、すでに作ったモジュールの初歩を土台にして、別のモジュールの初歩を同様に作り始めます。 そして、まずRPGの基本システムを満足するところまで作ります。（シナリオ作成などは後回しになるでしょう。） マップシステム、戦闘システム、装備システム、道具システム、買い物システム、酒場システム、会話システム、・・・ など色々あるので、まず一通り、好きなシステムから順に、キリのいいところまで作りこんで、どんどんと次に作りたいシステムの開発に移行していき、 とりあえずゲーム全体の基本システムを構築していくことになるでしょう。 ;2周目 そして、一通り、満足するまで基本システムを作るのを1周したら、 次に2周目として、また、たとえばマップのシステムを作り始めます。 1周目のマップシステム製作では放置してた部分、たとえばキャラチップの歩行グラフィックなど絵が必要で放置してた部分の製作に取り掛かるとか（たとえば1周目では矢印の画像でゴマかしていたとする）、 そのように2周目では、1週目で放置していた部分の製作にとりかかるのです。たとえば、歩行グラフィックで前足を上げているポーズと、前足を着地させるポーズの切り替えプログラムとか、そういう1周目では面倒で放置していた部分に、2周目では取り掛かったりします。 このように、RPGの製作は、まるでラセン階段を昇るかのように、周回的に開発していくことになるでしょう。 企業などで作る場合はどうか知りませんが、少なくともVisual C++でゼロからRPGを作る場合はラセン階段でしょう。 RPGはモジュールがとても多いし、また相互に関連するモジュールも幾多もあるので、一度に各モジュールを作りきるのは不可能です。 だから、ラセン階段のように、開発を昇っていくことになります。 {{コラム|1=化学の学習に似ているかも|2= 余談ですが、理系の学問でも、1999年ごろは、化学（ケミストリー）の理系教養の学習法がラセン階段のような順序であると言われています。 たとえば理工書 [https://www.amazon.co.jp/%E5%8C%96%E5%AD%A6%E3%81%AE%E5%9F%BA%E7%A4%8E-%E5%8C%96%E5%AD%A6%E5%85%A5%E9%96%80%E3%82%B3%E3%83%BC%E3%82%B9-1-%E7%AB%B9%E5%86%85-%E6%95%AC%E4%BA%BA/dp/4000079816/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=2DKECS8MWBNZR&keywords=%E5%8C%96%E5%AD%A6+%E5%B2%A9%E6%B3%A2&qid=1641806771&s=books&sprefix=%E5%8C%96%E5%AD%A6%E5%85%A5+%E5%B2%A9%E6%B3%A2%2Cstripbooks%2C188&sr=1-1 『化学の基礎』 (化学入門コース 1) , 1996/4/17 ] などのシリーズ (化学入門コース) の巻頭の学習法ページにもラセン階段の絵が書いてあり、ラセン階段のイラストの絵の各所に対応する科目が描いてあったような気がします。 ただし、プログラミングは暗記科目ではないので、そこは手を動かしてプログラムを実際に構築していく必要があります。そういう点は、数学というか物理学というか。 }} == 共通カウントアップ機能 == RPGではシステム中にマップ画面モード、メニュー画面モード、戦闘画面モード、・・・など様々なモードがありますが、 DXライブラリを使っている場合にどのモードでも必ず使うことになる機能があり、それは自作タイマーのカウントアップです。 まず、DXライブラリでは1秒間に60ループするので、それを利用して1秒間に60回カウントアップする機能を作ります。 そして、そのカウンターを活用することで、たとえば、「zボタンを押してから40フレーム間（環境によっては約0.8秒くらい）は次のzボタンの入力を受けつけなくする」等のボタンをしばらく入力させなくする機能を作ります。 そうしないと、プレイヤーは1回だけzボタンを押したつもりでも、システム的には何十回もzボタンを連打したことになり、プレイヤーがうまくコマンド操作などを行えません。 また、コマンド操作などの他にも、マップ画面中でキャラクターがマップ1マスぶん動くスライドのアニメーションでも、カウンターが必要になります。 マップ画面の歩行グラフィックで「歩行カウンター」みたいな変数が必要になるでしょう。もしくは、歩行のキー入力に使った矢印キー用のカウンターを流用するなどの処置になるでしょう。 ともかく、このようなカウンター機能が必要なので、whileループ中での個別モードに分かれる前の共通部分のところに、カウントアップのコードを書くことになります。 「共通部分のところ」とはどこか具体的に言うと <syntaxhighlight lang="C"> while (1) { if (ProcessMessage() != 0) { // メッセージ処理 break;//ウィンドウの×ボタンが押されたらループを抜ける } if (CheckHitKey(KEY_INPUT_ESCAPE) == 1) { break; } ClearDrawScreen(); // ここにカウントアップ機能 </syntaxhighlight> のように、whileの開始のテンプレ文の直後に書き始めることになるでしょう。 なお、DXライブラリでよく書くことになる開始時のテンプレ文については 『[[ゲームプログラミング/画面出力#DXライブラリのコード初期設定]]』 で説明してある。 カウントアップではなくカウントダウンでも構いません。 イメージ的には、下記コードのような感じになります。ただし、下記のモジュールだけでは動きません。 あらかじめ、各モード側でzボタンを押した時などにカウンター値の設定などを行う必要があります。たとえばzボタンを押したときに nyuuryokuMatiZ =60; // デバッグしやすいように少し遅めにした などをセットしておきます。また、zキー入力可能かどうかを判定するフラグ変数、下記コードでは変数 keyEnableZ となっていますが、そのようなフラグ変数をあらかじめ用意しておき、もし値が1なら入力可能、0なら入力不可能として、 zボタンに対応する処理を1回実行してから<code>z=0;</code>に設定して、zが0のときにカウンタが動くようにする必要があります。（ツクールなどではマップ画面からメニュー画面を開くのはx（エックス）ボタンだが、読者のバツボタンとの混同を防ぐため、上記の文ではzボタンを例に説明した。） <syntaxhighlight lang="C"> while (1) { if (ProcessMessage() != 0) { // メッセージ処理 break;//ウィンドウの×ボタンが押されたらループを抜ける } if (CheckHitKey(KEY_INPUT_ESCAPE) == 1) { break; } ClearDrawScreen(); // ここからカウントダウン機能 // zボタン用のカウントダウン if (keyEnableZ == 0 && nyuuryokuMatiZ > 0) { nyuuryokuMatiZ = nyuuryokuMatiZ - 1; } // zカウンタが0以下に到達したらzキーが再入力可能 if (nyuuryokuMatiZ <= 0) { nyuuryokuMatiZ = 0; keyEnableZ = 1; } // 下記はエックスボタンのこと。 バツボタンではない。 // xボタン用のカウントダウン if (nyuuryokuMatiX > 0) { nyuuryokuMatiX = nyuuryokuMatiX - 1; } if (nyuuryokuMatiX <= 0) { nyuuryokuMatiX = 0; keyEnableX = 1; } // 長いので、あとは省略 </syntaxhighlight> このコード例のように、共通カウンタ部では単にカウントするだけでなく、さらにカウンタが目標値（カウントダウン方式なら0が目標値）に到達したときの処理（フラグの設定など）も行います。 いきなり上記のような機能を作るのは、かなり難しいです。なぜなら、カウンタだけでなく、マップ画面やメニュー画面側のzボタン押し時やxボタン押し時の命令も記述しないといけないからです。 だからまずは、マップ画面とメニュー画面の入り口画面（まだメニュー画面の各コマンドは作らなくていい）だけでいいので、でキーのカウント処理をうまく行えるようにしましょう。 なお、メニュー画面に移ったらキャンセルボタンで戻せるように、あらかじめメニュー画面にキャンセル機能を実装しておきましょう。 新しい画面を作るときに最初に必要なボタン機能は、実はキャンセル機能です。キャンセル機能が無いと操作不能になって、いちいちアプリ再起動の手間が生じます。 ;アクションゲームで肩慣らし いきなりマップ画面やメニュー画面を作るのは難しいので、ひとつの手として、RPGを作る前に、簡易的なアクションゲームのような操作性のプログラム、または簡易シューーティングゲームの操作性のようなプログラムを作るのも手です。 たとえば、スーパーマリオやスト2のようなアクションゲームなら、ジャンプボタンは1回入力したら着地までは再入力の受付が禁止なので、上記のようなカウンタ処理による再入力可否の制御が実験できます。 べつに、本格的にアクションゲームやシューティングゲームを作る必要はないです。後述のように、異なるジャンルのゲームをひとつのアプリに同梱するのは、管理の手間が増えますので（不可能ではないですが）、面倒が生じます。 これには準備として、マリオ（キャラ名）やスト2リュウに相当する自キャラ表示のため、あらかじめキャラチップの絵が必要です。別にアクションゲームを作るわけではないので、マウスでいいので何かキャラの全身絵を3分くらいで雑に書いてください。そして、キャラの周囲の空白部を、ドットエディタなどを使って透過させてください。（あるいはinkscapeを使ってキャラ絵を書いて、PNGエクスポートする、などの手法もあります。） ジャンプさえ出来る絵であればいいので、すでに手元にゲーム用キャラチップっぽい大きさの生き物の絵があるなら、別に人物の絵である必要もなく、動物の絵でもモンスター画でも何でも構いません。 さて、なんとかジャンプの実験に成功したら、ついつい次の目標で「右歩行中にジャンプして右斜め上に飛ぶ」機能とかを実装したくなりますが、本ページはRPGの教科書なので、アクション機能については説明を省略します。 ;ミニゲーム同梱時のカウンタ管理 ミニゲームとしてターン制RPG以外のジャンルのゲームを同梱するなら（たとえばシューティングなど。ファミコン『さんまの名探偵』では推理ゲーム中、シューティングゲームのミニゲームがあった）、別途、そのミニゲーム用の各モード前の共通部分に、ミニゲーム用のカウンタが必要になるかもしれません。 ターン制RPGとアクショゲーム・シューティングゲームは、カウンターに要求される待機時間が違ってくることと（ターン制RPGの操作はゆっくりめでいいので待機時間を多目にとれるが、しかしアクションは機敏な動作に対応するため待機時間が短い）、カウンタが目標値に到達したときの処理がRPGとアクションとで違うので（たとえばRPGなら決定ボタンを押したままの状態なら目標値の直後に受け付けしてもいいが、アクションゲームでは決定ボタンがジャンプやパンチに対応していることから、プレイヤーにパンチ連打などのためにボタン連打させたい場合は目標値直後の処理を変える必要があることなどから）、RPGとアクションを混在させるのは（可能ではあるが）難しいことが予想できます。 だから、もしあるゲーム中に別ジャンルのミニゲームを同梱するなら、メインとなるホスト側のジャンルを決めて、そのメインジャンルのカウンタだけをwhileループの冒頭でカウントアップすると安全かと思います。たとえば本ページはRPGなので、メインのジャンルはRPGなのでwhileループの序盤ではRPG用のカウンタだけをカウントアップ、という事になるでしょう。シューティングについては、while冒頭ではカウントアップしないか、あるいはRPG用のカウンタの流用で済ますかどのちらかです。 もしwhileループの冒頭でシューティング用のカウンタまで記述してしまうと、コードの管理が複雑になってしまうので、避けたほうが安全でしょう。 普段は使わないミニゲームのカウンタのせいで、普段から使うメインジャンル（本ページではRPG）のカウンタの可読性が下がるのは避けたいです。 RPG用のカウンタをシューティングに流用するのは、シューティング用にコードが最適化されてないので軽量性が若干は下がりアプリが重くなりますが、しかしゲーム制作ツールのRPGツクールやウディタなどで製作されたアクションゲームやシューティングゲームなどは、こういった流用の一種でしょう。 == アイテム関係 == === アイテムの定義 === * [[ゲームプログラミング/RPG/アイテム定義]] === アイテム表示 === * [[ゲームプログラミング/RPG/アイテム表示]] アイテム表示における、上詰めの自動化などを解説しています。 == 設計方針 == ==== ゲーム全体を先に作る ==== ともかく、ゲーム全体を先に作るのが先決です。ニュアンスは違いますがアトラス社いわく（ゲーム開発では）「ゲーム全体に全体に値を回すのが先」という格言があります<ref>[https://news.denfaminicogamer.jp/projectbook/191030a/2 『【ゲームの企画書】『ペルソナ3』を築き上げたのは反骨心とリスペクトだった。赤い企画書のもとに集った“愚連隊”がシリーズを生まれ変わらせるまで【橋野桂インタビュー】』2019年10月30日 11:30] 2020年12月1日に閲覧して確認.</ref>。 プレイヤーが見たいのは、ゲーム全体のストーリーやテンポといったゲームの全体像です。カーソルの動きとかウィンドウの動きとかは、あくまで補助的であり、そういったUIに対するプレイヤーの興味も、あくまでオマケの範囲でしかないのです。 ==== 似た機能を複製する場合 ==== ===== 複製前の確認事項 ===== ;短さよりも可読性を重視せよ 世の中には、残念ながら時々、他人の理解しやすさを無視して、やたらと短いコードを書く、独りよがりな人がいます。 しかし、たとえ仕事としての集団作業であっても、要求されるのは、同僚や後輩などが読んだときの分かりやすさです（「可読性」と言います）。 なので、少しぐらいコードが長くなってもいいので、分かり易いコードを書きましょう。 具体的には、できるだけ、どこの入門書にもあるような基本的な機能を使ってコードするのが安全です。具体的には、できるだけ、せいぜい構造体（およびC++ならクラスの構造体的な使い方）や配列や関数あたりまで、の機能どまりです。 また、「どうしても」と言った必要性のない限り、その分野の一般の入門書に書かれてない機能（たとえばメモリ管理の組込み関数など）や、解説の極端に乏しい機能は（入門書なっても巻末の機能一覧にだけしか記載のないような機能）、利用を控えましょう。 そもそも、一般入門書に書かれてない機能は、取扱いが難しかったりして、設定などの確認不足で使うとむしろバグの原因になりやすかったりとか、学習コストの高さなどの難しさがあるから、入門書から除外されているのです。なのに、そういう難解な機能を多用するのは、あまりよくプログラミングの仕事が分かってない自称プロかと思われても仕方ありません。 ;ゲームとして実態のある関数や配列を作れ 関数や配列をつくるときは、なるべく、ゲーム用語で説明できる関数および配列だけを作りましょう。たとえば「戦闘コマンド選択関数」や「モンスターデータベース配列」のような感じです。 けっして、そういうゲーム用語とは無関係に、単に抽象的に関数を呼び出す関数を呼び出すような関数を呼び出す関数、とか、配列を読む込む配列を読む込むような配列、のような高階層的な機能は、たとえそれでコードが短くなっても、同僚や後輩などが管理をしづらくなるので、避けましょう。 :というか、そういう無意味な抽象化を避けないと、あなたが会社から避けられるでしょう。（これはゲームに限らず、数学以外の物理学や化学で扱う数式も同様で、たとえば理系大学の論文指導やゼミなどで、なるべく物理的な実態や化学的な実態に対応のある立式をするように、よく大学の卒業研究では要求されています。具体的には、「質量（mass）を表す文字式には m を使え」（高校レベルですが）みたいに既存の慣習に合わせるように指導されます。たとえ数学的には矛盾のない立式でも、物理学の研究室なのに「質量に記号 a 、速度に記号 b 」みたいな書き方をする学生は、教授から学生がダメ出しをされます。） IT業界だけなく法律業界でも、むやみに高階層的な法令を設計するとその法令の構造が複雑になる現象は知られています[https://www.nature.com/articles/s41598-020-73623-x Daniel Martin Katz, Corinna Coupette, Janis Beckedorf & Dirk Hartung "Complex societies and the growth of the law" Published: 30 October 2020 ]。近年、世界各国でIT的な考え方を使って法律の設計論を研究しようという学問分野があり、その学問でそう指摘されています。これらのIT的な法学では、法律中の単語数、階層数、法律間の相互引用数が多ければ多いほど、その法律の構造は複雑になると考えられています。ご参考に。 もちろん、関数から関数を呼び出してもいい場合もあり、たとえば「RPGで戦闘モードの関数から、攻撃コマンド関数を呼び出す関数から、さらに攻撃対象の選択をする関数を記述する」といったようなゲーム仕様に直接的に結びついた関数ならば、普通のゲーマーなら理解できるので、書いても平気でしょう。ですが、それはゲームとしての実態に対応する共通化です。けっして、ゲームの実態に無関係の共通化ではありません。 ;仕様そのものの類似性に気を配れ また、ゲーム中で、仕様ではあまり類似性のない処理は、たとえ偶然的にコードの実装が似ていても、むやみに共通化して同じ関数にしたり配列にしたりするのは避けましょう。なぜなら他人（後輩など）が管理しづらいからです。 もちろん、共通化してもいい場合もあり、たとえば「回復アイテムによる回復対象を選ぶ関数」などは、 :たとえば戦闘モードでの「RPGで戦闘モードの関数から、（攻撃コマンドではなく）道具コマンド関数を呼び出す関数から、回復アイテムを選んだ時に、回復対象の味方キャラを選択をする関数を記述する」と、 :マップメニューモードでの「マップメニュー画面モードの関数から呼び出す、道具コマンドの関数で、回復アイテムを選んだ際に、道具の使用対象を選ぶ関数」 が、ともに仕様が「回復アイテムを選んだ時の使用対象の味方を選ぶ」と似ているので、場合によっては共通化するのも良いかもしれません（職場によるだろう。共通化しないほうが良い場合もある。たとえば戦闘モードでは敵にも回復アイテムを使えるゲームも存在する一方、マップメニュー画面では味方にしか回復アイテムを使えないので細部が異なるから）。 しかし、仕様自体すらも似ていない部分を共通化するのは、ダメでしょう。 たとえば、もしたまたま、「戦闘モードでのコマンド選択時の関数」（まだ道具コマンドを入力する前なので、どのアイテムを使うからすら選んでいない段階）と、「マップメニュー画面モードで道具コマンドのあとに使用対象キャラを選ぶときの関数」が、もし偶然にコードが似ていたとしても、そういう仕様的にあまり関連性の無いコードは共通化されても管理しづらくなるので、共通化するのをやめましょう。 ===== 具体的手順 ===== まず、それらの機能の共通点を探します。次に、その共通点を抽象化します。抽象化のコストと、それを再テストするコストの合計が、そのままにしておくコストよりも高く付くと考えられるならば、抽象化は後回しにしても構いません。 {{コラム|テキスト比較ツール| テキスト比較ツールを使うと、効率的に違う部分を強調して表示することができます。 GNUのdiffutils、[[Git]]などのバージョン管理システム、あるいは「ベクター」や「窓の杜」からインストールすることができます。 }} == リファクタリング == * [[ゲームプログラミング/RPG/リファクタリング]] == モードの管理手法について == * [[ゲームプログラミング/モード管理]] 戦闘モードとか、マップ画面モードとか、メニューモードとか、そういうののハナシです。とりあえず「モード」と言いましたが、ゲーム業界で何と言うのか知りません。もしかしたら、モードではなく「戦闘シーン」とか「戦闘パート」とか言うのかもしれません。ただし、書籍『ゲームプランとデザインの教科書』が、架空のスマホゲーム企画書で「モード」という言葉を使っています。「移動先指定モード」とか<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.255</ref>。 == 2Dマップ == === マップのアルゴリズム === 方針だけ述べる。具体的なコードは、上手い人のコードを参考にしよう（コードがけっこう長くなり、紹介がメンドウくさい）。 2Dマップがあると、俄然、RPGっぽく見えるようになって、ヤル気が出るので、さあ作ろう。 マップのデータは、ふつう、2次元配列で書く。 まず、グローバル領域で、たとえば <syntaxhighlight lang="c"> static int maptable[10][10] = { { 0,0,0,0,0,0,0,0,0,0 }, //0 y { 0,0,0,0,0,0,0,0,0,0 }, //1 { 0,0,0,0,0,0,0,0,0,0 }, //2 { 0,0,0,0,0,0,0,0,0,0 }, //3 { 0,0,0,0,0,0,0,0,0,0 }, //4 { 0,0,0,0,0,0,0,0,0,0 }, //5 { 0,0,0,0,0,0,0,0,0,0 } //6 }; </syntaxhighlight> のように、とりあえず配列を確保しよう。 ここで重要なのは、 確保した配列のタテとヨコは、ヨコの並びをx方向として、タテの並びをy方向としたとき、 <code> maptable[y][x] </code> のように確保されていることに注意する。 さて、各配列に「0」を入れても、はたして0番が何を意味するか、まだ何も決めていない。 ゲームにもよるが、とりあえず、何もマップチップを上書きしない領域だと定義しよう。 背景色と同じ色のベタ塗りのマップチップを作っておけば、それで上書きすれば、あたかも何も上書きしてないように見える。 いちいちif文などで、何も上書きしないように場合わけをするのもメンドウであるので、どっちの方式にするか、決めておこう。 さて、マップ用の配列は、作成したいマップで最低限必要なマス目よりも、やや大きめの領域を確保しておく必要がある。 たとえば、5×5のマップを作りたいなら、配列ではもっと大目に、たとえば 8×7 とか確保しておく必要がある。 もし、なんらかのバグで確保されていない領域を呼び出してしまうと、プログラムがエラーで異常停止してしまう。 たとえば、一番左端をもしx＝0とした場合、もしこの場所に主人公がいると、さらにプレイヤーが「左端に行こう」と考えて、左ボタンを押したときに、エラーで異常停止してしまう。 こういう停止はメンドウくさいので、だったら念のため、最初から、マップを移動可能な場所よりも何マスか大目に確保しておくと安全である。 さて、まだ配列を確保しただけなので、「0」が何かとか、「1」が何かとか、まったく定義していない。 とりあえず、 :0番は、進入不可能の暗闇。 :1番は、床とか、草原とか平地とか、とにかく歩ける場所 としよう。 だと思ってればイイ。 たとえば、もし配列 maptable の宣言が、 <syntaxhighlight lang="c"> static int maptable[10][10] = { { 0,0,0,0,0,0,0,0,0,0 }, //0 y { 0,0,1,1,1,1,1,1,0,0 }, //1 { 0,0,1,1,1,1,1,1,0,0 }, //2 { 0,0,1,1,1,1,1,1,0,0 }, //3 { 0,0,1,1,1,1,1,1,0,0 }, //4 { 0,0,0,0,0,0,0,0,0,0 }, //5 { 0,0,0,0,0,0,0,0,0,0 } //6 }; </syntaxhighlight> のような宣言だったら、このマップでは真ん中のほうに4マス×5マスの移動可能な地帯がある。 その周囲は移動不可能になっている。 ともかく、このように、プログラマーは、まず、何番のマップチップが何を現すかということを、脳内で設計しておく必要がある。 配列の範囲外の読み込みエラー防止のためも兼ねて、0番は、すべてのゲームキャラが進入禁止としておくのは安全だろう。 あとはもう、win32 API などの機能を使って、マップチップの画像を配列にもとづいて各マスごとに表示すればいい。 前提として、まずマップチップ画像の読み込みを行う必要がある。あるいは、画像をあらかじめ実行ファイルに組み込んでおく必要がある。 画像の実行ファイルへの組み込みは、Visual C++ にそういう機能があるので、それを使えばいい。 画像を読み込みたいなら、ゲーム起動時にでも読み込んでおけばいい。 イメージ的にコードの雰囲気（ふんいき）を書くと、たとえば <code>case WM_PAINT:</code> の節に、下記のように for文などを使って画像ハンドらに画像を代入するコードを裏画面に書いていき、最後にまとめて本画面に描画することになる。（「裏画面」とか「ダブルバッファリング」と言われるテクニックを使います。詳しくはネット検索して調べてください。） ;（イメージ） ::(※ あくまでイメージです。このままでは、動きません。) <syntaxhighlight lang="c"> int iTemp; for (x_map = 0; x_map <= 9; ++x_map) { for (y_map = 0; y_map <= 6; ++y_map) { iTemp = maptable[y_map][x_map]; // 配列の文字が長いので、いったんiに置き換え hbmp = hbmp_mapchip_list[iTemp].hbmp_mapchip; SelectObject(hMdc, hbmp); BitBlt(hbackDC, 225 + x_map * 32, 140 + y_map * 32, 32, 32, hMdc, 0, 0, SRCCOPY); // DeleteDC(hMdc); // これを入れると、マップが表示されない。 } } // 裏画面から本画面に転送 BitBlt(hdc, 0, 0, 700, 500, hbackDC, 0, 0, SRCCOPY); hbmp = NULL; // 初期化。 // 中間ハンドルからhbmpを解除 SelectObject(hMdc, NULL); SelectObject(hbackDC, NULL); // 不要になった中間物を削除 DeleteDC(hbackDC); DeleteDC(hMdc); DeleteObject(hbmp); } </syntaxhighlight> SelectObject や BitBlt は、Win32 API の専用の関数なので、分からなければ読者で調べてください。 なお、マップチップ画像そのものの作成は、単にWindowsアクセサリ『ペイント』などの画像作成アプリでビットマップ画像を用意すればいい。 ツクールやウディタなどだと、いくつかのマップチップをまとめた「タイルセット」などを取り扱うが、実はプログラミング的には、わざわざタイルセットを作らなくても、マップチップ1個ずつを読みとりすることも可能である（単にwin32APIのビットマップ画像の読みとりの機能を使えばいい）。 （win32 API の初期設定のままではビットマップしか表示できないハズ。PNGなどを使いたいなら、GDI+の設定を行うこと。GDI+については説明を省略。）。 なお、マップチップのサイズの規格は、よくある規格は16ピクセルの倍数で、「px」をピクセル単位の意味として16px×16pxまたは32px×32pxまたは64px×64pxのマップチップ規格がよくある（ツクールやウディタのマップチップのサイズ規格も、この系統）。 とりあえず、私たちにとって作るのがラクなのは、小さいほうが作成がラクなので、とりあえず16×16のマップチップを作ろう。 プログラム技術としてはマップ表示は単なる二次元配列なので難しいことは無い。しかし、その他の準備が忙しく、たとえばマップチップ用のビットマップを用意したりとか、あるいはキーボード操作のプログラムを作ったりとか、そういう準備が難しい。 これだけだと、まだマップを表示しただけなので、さらに主人公キャラのキャラチップとか、主人公がx＝何マス目、y＝何マス目にいるかの変数とかも宣言する必要がある。 主人公チップを移動させる際、ドラクエ1みたいに1ピクセルずつ動かしたいと思うだろうが（実際は何ピクセルかしらないが）、しかしそれは難しい。まずは、十字ボタンを押したら、その方向にいきなり隣のマスに動く仕組みをつくろう。 しかし、これすら、また難しい。 win32APIなら、ボタンを押して話す動作で1回の入力と判断してくれる。 なので、win32APIで隣マス移動の仕組みを作るのは、比較的にラクである。 しかしDXライブラリの場合、1瞬だけボタンを押しただけでも、何十回も入力があると判断され、 いっきに壁際のマスまで動いてしまう。 なのでDXライブラリのマップ移動の作成の場合、まずはタイマー系の関数を利用し、一定時間のボタンの押し続けがあって初めて「入力された」と判定すうプログラムが追加になる。 なお、win32APIでも別のシーン（たとえば戦闘モードでのコマンド決定後の自動処理など）でタイマー自作が必要になるので、どちらにせよラクではない。 最終的には、21世紀的な一般的なゲームを作りたいなら、（win32APIではなく）DXライブラリで作るのがラクである。 （ただし本セクションでは説明のしやすさの都合から、win32APIで説明した。） もし、ドラクエ風に1ピクセル（ないし数ピクセル）ずつアニメーション的に動かしたいなら、DXライブラリがほぼ必須であり（原理的にはwindowsAPIでも出来るが、しかしwindowAPIでのアニメーション表現はとても手間が多く難しく、強く薦めない。）、DXライブラリで開発しているRPGコードに、タイマー計算するコードと組み合わせて、下記イメージのようになる。 ;（イメージ） ::(※ あくまでイメージです。このままでは、動きません。) <syntaxhighlight lang="c"> if (moving == 1 && nyuuryokuMatiLR > 0) { // nyuuryokumati は「入力待ち」時間の意味 nyuuryokuMatiLR = nyuuryokuMatiLR - 1; // タイマーとして流用 } // 移動の終了処理 if (hero1_direction == rightward && moving == 1 && nyuuryokuMatiLR <= 0) { keyEnableRight = 1; // moving 回復までに時間が掛かるので、ここは1に。 nyuuryokuMatiLR = waitTime1; nyuuryokuMatiLeft = waitTime1; nyuuryokuMatiRight = waitTime1; xPosi++; // 右へ1マスだけ移動 moving = 0; townFlag = 0; } } // 右移動 </syntaxhighlight> // nyuuryokumati は「入力待ち」時間の意味 上記コードの仕組みは割とひどく、マップ移動中の特定の左右方向用のタイマーを、今後の戦闘モードなど他のすべてのタイマーと流用するという、ひどいコードである。 ナナメ移動にも対応したりを考える場合、左右（LR）方向と上下（UpDown）方向のキーボード入力を別々の変数として処理する必要があったりと、割と面倒くさい。 移動先が移動可能でないカベや川なのに移動できたらおかしいので（ドラクエだと川は移動不能。『信長の野望』での渡河とか野暮にツッコまないこと。）、 事前にそういう移動可能判定を色々とクリアしたら、移動中モードとしてmovingが1になるようにしているコードである（長くなるので上記コードでは省略した）。 キーボード入力の判定は、事前のmoving側の判定計算ですでに行っているので、上記コードでは省かれている。実際にはさらに、下記コードのようなキーボード入力判定プログラムが、上記コードの直前あたりに付け足される必要がある。 <syntaxhighlight lang="c"> // 移動先予定地の入場可否の判定 if (CheckHitKey(KEY_INPUT_RIGHT) == 1 && keyEnableRight == 1 && moving == 0) { if (map1table[yPosi][xPosi + 1] == 1) { destMovable = 0; } if (map1table[yPosi][xPosi + 1] == 0) { destMovable = 1; } // 入場可能ならフラグ設定 if (destMovable == 1) { // destとは目的地点 destination の略。 moving = 1; hero1_direction = rightward; keyEnableRight = 0; nyuuryokuMatiLR = waitTime1; } } </syntaxhighlight> いったん移動し終わったら、もはや移動中ではないので、再度movingをゼロに戻し、また移動可能判定を調べなおす、という手間になる。 マップ移動だけでも、こんな手間になる。 だから、市販の『中学生でも分かるゲームプログラミング』的な題名の本でこういう手間が無いのは、 それはその市販本の著者が、初心者が苦手感を抱かないように独自のライブラリなどで上記のような手間をライブラリ側に隠蔽する工夫などをしてるだけにすぎない。 ネットに出回るデマの、「RPG風のUIをつくるのは簡単」というのは、つくづくウソである。ドラクエ1風のUIですら、なかなか面倒である。 （『中学生でも分かるゲームプログラミング』的な本の手間だけでドラクエ1風UIが作れると思ってる、本を読んだだけの知ったかぶりが、ゲームプログラミング経験者ヅラしているということであろう。） === マップレイヤー画像について === * [[ゲームプログラミング/画面出力#RPGのマップレイヤー]] === 歩行グラフィック === ゲームにおけるキャラチップの歩行アニメーションの作画の定石は、テレビアニメの歩行の作画の定石とは、まったく違います。 説明の単純化のため、右向きの歩行を例に説明します。 ==== 3枚歩き ==== まず、ツクール水準の2D-RPGの歩行グラフィックではなんと、歩き始めの作画の立ちポーズのドット絵と、横向き時にプレイヤーから見てキャラ歩行中における右足と左足とが重なっているドット絵（便宜上「中ポーズ」と呼ぶとする）が、なんと同じドット絵です（テレビアニメ作画の常識とは大きく異なる）。 つまり2Dゲームのドット絵では、歩き始めと歩き中の中ポースとに、区別がないのです。 これは、実際にキャラチップのタイルと、キャラのゲーム中での歩行動画を録画して見比べると分かります。 テレビアニメ産業では、歩きお よび 走りの作画は、基本的になるべく滑らかに見せるために、6枚の絵を使います。 だからアニメ業界では「6枚歩き」とか「6枚走り」とか言います。 しかしゲームは違います。上記の言い方に習うなら、ゲームは「3枚歩き」です。「3枚歩き」というのは別にゲーム業界の用語ではなく、テレビアニメ業界での数え方をそのままゲーム業界に置き換えただけの本wikiでの独自的な呼び方です。 しかもゲームのドット絵では、走りと歩きの区別がありません。つまり、歩きのドット絵を、走りのドット絵でも使いまわします。 つまりゲームではドット絵だけなら 「3枚歩き」=「3枚走り」 でもあります。 ドット絵のゲームにおける走りと歩きの区別は単に、キャラチップのスライドさせる早さを切り替えることで区別しているだけです。 なお、テレビアニメ産業などでは、正面向きかつ走りシーン（ゲームにおける下キー入力時に相当）なら例外的に（6枚ではなく）4枚作画でも走りを描けることが知られています。なぜこれが通用するかというと、よく分析で言われるのは、6枚でなく4枚だと滑らかさはなくなりますが、しかし歩きではなく走りであるので動きに少々のギャップがあっても勢いがむしろ強調されるという点と、また6枚時の中ポーズのシルエットと4枚時の中ポーズノシルエットがあまり変わらないという点があるため、テレビアニメ業界では正面走りだけ「4枚走り」でも可能なのです。 しかしゲーム産業では正面向きでないのに、右向き左向き前向き後ろ向きすべてで、なんと「3枚歩き走り」なのです。ドット絵のゲームではキャラチップが小さいので、なんと3枚で歩きも走りも表現できてしまうのです。 このように、ゲームとアニメとでアニメーションの常識が大幅に異なります。 しかし、両業界でも一致している作画の風習もあり、それは歩行中グラでの頭の高さの上下運動です。 アニメ作画の頭の上下運動を文字だけで説明するのは難しいので、興味ある読者は外部サイトでアニメーターの作画教育サイトを見るなり、あるいは同人フリーゲーム用の公開キャラチップ素材などを実際に目で見るなどして、読者ご自身で研究してください。 ともかく、3枚で右向きの歩行を表現できます。RPGでは上下左右の4方向が必要なので、最低でも3×4 = 12枚 の絵画必要です。 なお、斜め歩行が加わると、2倍になるので必要枚数は合計24枚になります。 ;思考回路の切り替え もし、外部のゲーム用フリードット素材を使わずに「ゲームエンジンを一人で作る」というなら、上述のようなアニメ産業とゲーム産業での作画のギャップも知って絵を描く必要が生じるでしょう。頭の切り替えが必要になります。 今までプログラマー脳だったのを、ドット絵を描くのに絵描き脳に切り替える必要があって、しかも既存のテレビアニメ作画理論はそのままでは使えないので、ゲーム用に人気作のドット絵のグラフィックを研究しなおす必要が生じるのです。 ==== チップ作画の留意点 ==== ===== 3枚歩き ===== また、絵1枚ごとのRPGのキャラチップの作画も、テレビアニメとは違います。 まず、2D-RPGでは、前後向きのキャラチップの横幅のサイズ規格と、左右向きの横幅のサイズ規格が、RPGでは同じです。 しかし、テレビアニメでは、このような横幅はありえないのです。 なぜなら、人間が歩いていて左右の腕をふっていて前に突き出た状態の手先から胴体までの距離は、胴体の厚さに比べると、（手～胴体 の距離は）かなり長いです。 しかし、こういったリアルな腕の寸法に忠実に書くと、サイズ規格の横幅をオーバーしてしまい、少なくとも腕の片方の先がチップ外にハミ出てしまいます。 だから、進行方向側の腕だけは、2D-RPGキャラチップではあまり伸びていないです。 なお、進行中の胴体はやや進行方向に寄っています。これはリアルな人体がそうだからでしょう。 なので、もはや進行方向側の腕には、伸ばすだけの余裕がありません。 だから、進行方向側の腕を折り曲げる場合すらも存在します。または、進行方向側の腕だけ短くゴマかすなどしている場合もあります。 これは別に2010年以降の流行でなく、既に1980年代の商業ゲームでもファミコンのドラクエ3の勇者の母親のキャラチップも、実は進行方側に腕を伸ばしたときは、腕を折り曲げています。 なお、ドラクエ3の主人公である勇者は、剣を持っているので、利き腕の右手がもとから折り曲がっており、よく分かりません。 また利き腕の表現のためドラクエ3では、右向きと左向きのキャラチップを、けっして反転処理でゴマかさずに、きちんとポーズを書き分けています。 ともかく、一般にRPGの歩行キャラチップでは、進行方向の腕があまり伸びてないので、バランスを取るためにRPGでは、進行方向の反対側の手足を、目いっぱい、伸ばしています。 これはリアルで考えるとありえないし、テレビアニメでもありえない作画です。 ですが、ゲーム産業の2D-RPGでは、昔からこういう作画がよく行われています。 ;歩きの滑り 2D-RPGの歩行ではキャラは地面を滑ります。横向きグラフィックだと、比較的に確認しやすいでしょう。 テレビアニメだと、キャラが滑っているように見えなくさせるためもあってか6枚も使って作画する一方、 2Dゲームでは正反対であり、2D-RPGゲームでは「滑り上等!」な態度の作画です。 走りシーンだったら、「まるで滑っている」かのように高速で走っている身軽なキャラのようにも見えるのですが（実は、実際に足の作画が滑っているだけ）、 2D-RPGでは歩きですら滑りある作画です。 「3枚歩き」で描く以上、こういうリアリティを無視した作画ですので、あまり他のリアリティにこだわっても仕方ありません。 {{コラム|デッサン的なこと| ;後頭部は意外と大きい なお、横向きの顔で、後頭部の髪のある部分の大きさが、顔前面の髪のない部分の大きさと同じくらい囲う東部のほうが大きいのは、 これは現実のデッサンと同じです。後頭部は意外と大きいのです。 例としてアニメ『新世紀エヴァンゲリオン』の主人公・碇シンジの後頭部の大きさが、顔と同じくらいなのは、別にけっして「親父の碇ゲンドウが天才科学者だから息子シンジも遺伝で脳が大きくて後頭部も大きい」とかではなく、もともと人間の後頭部というのはあのくらいの大きさなのです。 ;上マツゲは頭の中間位置ぐらい また、目より上の頭の頂上までの大きさが、アゴから上マツゲまでの長さと同じくらいなのも、これは現実と同じです。 つまり、上マツゲは、頭の中間くらいの位置です。 ついつい、髪の毛の生え際の位置につられて、目より上の頭部の大きさを小さく認識してしまいますが、それは錯覚です。実は、目より上の部分の長さは、意外と長いのです。 また、ゲームの場合、45°上の角度から見下ろしているので、すると後頭部が少し見えることも意識すると、もうすこし長く書いても構わないのかもしれませんが、しかしチップのサイズ規格に上限があるので、あまり頭部を伸ばすこともできません。 }} ===== 初心者の抱きそうな疑問 ===== ;キャラチップの横幅を大きくしたら? 標準的なキャラチップの前側の腕は折りたたまれています。原理的には、キャラチップの横幅を長くすれば、横向き歩きのゲーム作画において、リアルの作画や、テレビアニメの作画に近づけることはできます。 ですがそれをすると、キャラチップがそのぶん大きくなってしまい、そのせいでチップタイルの横幅が大きくなってしまいます。 正確には計算していませんが、少なくとも2.5倍くらいは横幅が長くなると思います。斜め移動も含みで考えると、通常のツクールなどのチップタイルはやや横長なのに、さらにそれを2.5倍に長くするのは、やや編集時に見づらいかもしれません。 ドット絵のキャラチップという小さくて見づらい絵の、さらに「腕」という2ドット（枠線まで含めると4ドット）くらいしかない部分に対して、そこまでする必要あるのか、意義が不明です。 このように、ゲーム演出の特有の事情もあります。 :プログラム側の事情 また、もしキャラチップの横幅の規格だけ長くすると、マップチップの横幅の規格と、食い違いが出てきます。このため、プログラムがやや難しくなります。 なるべくキャラチップ横幅とマップチップ横幅の規格の長さが近いほうが、プログラムは楽になります。 このように、プログラミング側の事情もあります。 ===== どうしてもリアルにアニメしたい場合 ===== ;どうしても腕振りをリアルに近づけたいなら それでも、どうしても腕の振りをリアルやテレビアニメに近づけたいなら、 キャラチップのサイズ規格を変えるのではなく、キャラチップのサイズ規格はマップチップ規格と同じくらいの長さにしたままにして、 歩行時にキャラチップを3枚横につなげるなどの方法もあるかもしれません。3枚の真ん中のチップが胴体と腕の付け根側で、隣の左右チップがそれぞれの腕の先端側に対応、という手法です。おそらくですが、ファミコン時代の古いアクションゲームでも、巨大ボスなどを、複数のチップをつなげて作画していたでしょうから、そういうのを現代的に応用する手法というわけです。 ただし、これだとキャラの処理速度の負担も、単純計算で3倍になります。（実際は、左右のキャラチップは無描画の場合もあるし、描画量が少ないので、もっと少ないが。） 主人公とかボス敵だけのキャラチップなら、グラフィック重視のゲームなら、その意義もあるかもしれません。しかし、果たしてモブキャラのキャラチップにまで、そこまでのチップ3倍にする手間を掛ける価値があるかどうか。 また、製作ツールなどの事情により、読み込みできる画像の枚数に制限のある場合があるので、あまり目立たない部分のために画像を1枚増やすのは非効率です。 ですが、べつに全キャラに6枚歩きを実装する必要もありません。お好きなように。 ;ミニゲームで分離など どうしてもドット絵で手足の動きをリアリティある書き方で細かく表現したいなら、いっそ、ゲーム本編ではなく別途ゲーム中にミニゲームでリアルな腕の振り方のあるミニゲームを組み込むなどの方法のほうが、良いかもしれません。 この方法なら、たとえばもし2D対戦アクションゲーム（スト2みたいなの）のミニゲームを組み込んだら、歩きや走りだけでなく、ジャンプだろうが座りだろうが、もはやパンチやキックや剣撃なども思う存分に大きく作画できますし、作画によってゲーム性も向上します。（アクションゲーム特有の非リアル描写もあるだろうが、本ページはRPGの教科書なので、アクションゲームの非リアル描写には深入りしない。） 背景を手書き背景イラストにすれば、マップチップのサイズ規格に縛られる必要もなくなるので、思う存分にキャラの好きな大きさで作画できますので、腕などの細かい部分も目立つ大きさで作画できるでしょう。 ただし、この方法の背景だと、スーパーマリオのような、背景の空中ブロックの上に、キャラがジャンプして飛び移ったりとかの処理は、スト2的ゲームのままでは不可能です。別途、マリオ的システムのプログラムを組む必要があります。つまり「スト2のようなスーパーマリオ」というゲーム企画を実装する必要が生じてしまいます。 また、ツクール的システムのRPGでなければ「3枚歩き」に縛られず、歩きと走りの作画を分離するのも自由ですし、「6枚走り」と「6枚歩き」のシステムにすることで「滑り」も無くせてリアリティ向上します。そこまで作画する意欲があればの話ですが。 ===== 2D-RPG歩行のドット絵の描き方 ===== 歩行グラフィックの切り替えパターンはゲームごとに違うのですが、下記コラムでは実装のラクなパターンを紹介します。 なお、ツクールやウディタの歩行パターンとは異なります（ツクールなどは、もっと複雑なパターン。後述する）。 {{コラム|プログラマー用のドット絵制作のコツ| ドット絵の書き方ですが、プログラマーの場合、絵の表示のテストをしないといけないので、絶対に最初は下書きまでに止めます。細部は書き込まないのがベストです。（下書きの手法については、別コラムでまとめてあります。） なぜなら、もし自作プログラムでRPGをゼロから作る場合、表示プログラムのコーディングをしながら絵を描くので、プログラマー脳と絵描き脳を、まるで反復横とびのように何度も行ったり来たりします。だから絶対に、この段階では（作り始めの段階では）絵は下書きまでに止めます。下書きで描くドット絵はすごく大雑把なラフ画でいいです。 さて、いきなり4枚描く前に、まず2枚だけでいいので、方向による表示の切り替えプログラムをテストします。 たとえば最初の1枚は下向き静止画像でしょうから、残り1枚は、右向きか左向きか上向きの静止画像になると思います。 たぶん、多くの人は右向きか左向きを書くと思います。後ろ向きをまっ先に書きたがる人なんて、いるとしても一部の重度のアニメ作画マニアぐらいです（アニメーターは360度いろんな向きでポーズを描くので）。 とりあえず説明の簡単のため、私たちプログラマーは右向き静止画像のドット絵を書いたとしましょう。 さて、とりあえず下と右の2方向の表示の切り替えプログラムさえ出来れば、同様のアルゴリズムでどうせ左向きと後ろ向きの静止画像も表示できるだろうから、さっさと歩行中の足を上げてるポーズの作画に入ります。そっちのほうがプログラマ－的には楽しいと思います。 で、すでに右向きの静止ポーズは描きあがっているとして、さらに前足を上げているポーズを1枚書いたとします。つまりこの時点では右向き絵は、静止右向き絵 と 足上げ絵 の合計2枚あります 1マスの歩行に60フレームを使っている場合、とりあえず表示フレームのタイミングは二等分により、 :前半の30フレーム中に前足あげポーズを表示、 :後半の残り30フレーム中に静止ポーズを表示すれば、 とりあえず何とか歩いているっぽく見えます（実機で確認ずみ）。 次に後ろ足を上げているポースも書き終えたら、今度はフレーム間隔を調整して変更し、3枚の右向き絵がありますが、三等分すれば 60÷3 <nowiki>=</nowiki> 20 なので、 :前半の20フレーム中に前足あげポーズを表示、 :中盤の20フレーム中に後ろ足あげポーズを表示、 :後半の残り20フレーム中に静止ポーズを表示すれば、 とりあえず歩いているっぽく見えるでしょう（確認ずみ）。 静止ポーズ中の20フレーム中に、直立ポーズのままスライドするのはリアリティ的には奇妙ですが、 しかしこの静止ポーズがないと表示テストでは隣マス（1マス目）の到着直後にさらに隣マス（2マス目）に直進するときにキャラクターがまるで膝蹴りを発動しているかのようなアニメになってしまうので（実機で確認ずみ）、 決断によって静止ポーズのまま20フレームぶんをスライドさせるべきなのです。 }} 実はツクールやウディタなどの歩行アルゴリズムは、本ページの上記コラムのプログラムのようにはなっていません。 なお、ツクーツとウディタで、キャラの標準的な歩き方のアルゴリズムは両方とも、 :前足を上げる状態で進む → 直立 → 後ろ足をあげる状態で進む → 直立 → 前足を上げる状態で進む →　直立（同様に繰り返し） のように、直立ポーズを挟んで、前足あげと後ろ足あげを交互に繰り返す方式です。（最初に始まるのが前足か後ろ足かの若干の違いはあるかもしれませんが、本質的ではないので深入りしない。） けっして、 :前足を上げる状態で進む → 後ろ足を上げる状態で進む のようにはなりません。 これはおそらく、直立のように見えるグラフィックが、実は歩行中の前足と後ろ足とが重なった状態を兼ねている表現だろうと思われます。 そのほか、ツクールやウディタで1マスだけ進むのを繰り返すと分かりますが、 1マスしか動かないで停止したとき、キャラチップをよく見ると、その場で足踏みして最終的に直立して止まることがあります。 ツクールもウディタもソース非公開なので不明ですが、これはプログラム的には仕組みはおそらく、 移動中の間だけ「移動中カウンタ」的な変数が進み、それが一定値になると0に戻るという仕組みを繰り返していると思います。 そして隣マスに到着時の進行判定の際、もし右ボタンが押されていなくてマスに停止しており、 移動中カウンタがまだ0に戻る前の値だったら、その値を保存したまま、 表示プログラム用にカウンタ値だけカウントアップしていって0に戻るまで表示が進むような仕組みで、実装できるかと思われます。 もし読者がツクールやウディタっぽい歩行アルゴリスムを実装したいなら、ご自身で研究してください。どのみち、ツクールとウディタで、歩行のポーズ切り替えタイミングなど微妙に違いますので、統一されていません。 どのみち、たとえばファミコン版ドラクエ3のアルゴリズムは、ツクールやウディタとも違います。ドラクエ3ではマップ上でマスに立ち止まっても、キャラチップは静止せずに足踏みを続けます。 このように歩行パターンはゲームそれぞれです。 {{コラム|ドット絵の下書き手法| テレビアニメの下書きとは、ドット絵は、作画の順序や手法が大きく違います。 テレビアニメの下書きでは、まずエンピツで線画を描き（「原画」（げんが）という）、あとから色を塗る（バケツ塗り）という手法です（「彩色」（さいしき）という）。（このあと「撮影」とか「編集」とか色々な工程があるが、ゲームに関係ないので省略。） ですが、ドット絵はこれとは作画の順序や手法が大きく違います。 ドット絵グラフィッカーによって手法は個人差があるでしょうが、とりあえず一例として、下記のようなドット絵の書き方を紹介します。もちろん、コンピュータ上でのドットエディター上での作業です。 :前後左右4方向の中ポーズ（立ちポーズ）のラフ色塗り : ↓ :ゲームに組み込み目視で画面を見てテスト : ↓ :テストで異常あれば下書きを修正。異常なければ次に進む : ↓ :前後左右の腕足振りポーズを2枚ずつ色塗りで大まかに下書き。（3枚作画なので、あと2枚が追加で必要） : ↓ :ゲームに組み込み目視で画面を見てテスト : ↓ :テストで異常あれば下書きを修正。異常なければ次に進む : ↓ :これから細部の書き込みに進む。細部に興味なければここで終わる。 : ↓ :（細部の書き込みと、そのテストなど） : ↓ :（たぶん）終わり 上記フローのような書き方は、あくまでRPGのマップ画面でのキャラチップのアニメの書き方だけに限定の手法です。だから、それ以外には、そのままでは応用できず、たとえば戦闘画面のモンスター画像などには応用できません。 あくまでマップ画面モードのキャラチップのみの話題です。 さて、ではなぜ上記のような手順で描くと合理的なのかを説明します。 もし40px × 40px 程度のドット絵なのに、テレビアニメのように色の違う箇所すべてに枠線を書こうとすると、ゲームのチップは小さいので服の模様などによってドットが黒一色（rgb値が 20,20,20 とか）で潰れてしまうので、色がなにも見えなくなってしまうから、テレビアニメ的な作画の手法は使えないのです。 だから基本、ドットの下書きでは、まず、色を大まかに塗ります。この際、ポーズも大まかに仮に決めて、下書きのときに一緒にポーズを書きことになるでししょう。 なぜ、静止ポーズの前後左右4枚を先に描くかというと、歩行中の残り8枚の絵よりも静止4枚のほうがプレイヤーの目に入る時間が長いからです。 ポーズボタンのないRPGの場合、もしプレイヤーが歩行中8枚の絵のいずれかをじっくり見ようと思ったら、プレイ動画を録画してから一時停止などの手間が必要です。 しかし静止ポーズ4枚は、何もしなくてもプレイヤーが画面の前でボーッとしてるだけでも目に入ります。 だからこの4枚を優先的に作画していく必要があります。今後の工程で細部の書き込みをする際にも、静止ポーズ4枚を優先して細部を仕上げると良いでしょう。 そして、大雑把に色が塗れたら（すごく雑（ザツ）な塗りでいいです）。最低限、向きは前後左右の4ポーズの立ちポーズを描かないといけないので、とりあえず、さっさと4枚を大雑把に早く書いて、実際のゲーム画面で表示テストしてみます。 ゲームドットの下書きなので、けっして細かく書く必要はないです。一方、テレビ番組アニメ用のアニメーター教育などだと、「練習でも細かく描け。すると本番ではそれを早く書けるようになっている」と教育する場合もありますが、しかしゲームのドット絵の下書きの場合は目的が違います。 実際にテストで確認してみて、問題があれば書き直しです。 だから、もし最初から細かく描いてしまうと、書き直しになったときにそれを消さないといけないので、無駄になってしまうのです。だから、色を大まかに塗るだけなのです。 そして下書きのドット絵の中ポーズの4方向の向き転換などをテストしてみて違和感がないことを確認できたら、次に手足を振っているポーズの作画にとりかかります。ここでも、色を大まかに塗るのと、ポーズを決めるだけです。 そして、とりあえずテストで実際のゲーム画面中で動きのアニメーションを確認してみて、「キャラがおかしなポーズになってないか?」とか、遠めで見たときに歩いているように見えるかとか、そういうことを確認していきます。 どのみち2D-RPGゲ－ムでは（テレビアニメではありえない）3枚作画で歩きを買いているので、少々の滑りや、実際とのポーズの少々の違いは無視です。 }} おおむね、こういった作画の流れになるでしょう。もちろん個人差はあるでしょう。ですが、けっして「いきなり細部から描く」ことはしないのは、ほぼ確定でしょうし、線画はドットが潰れるので輪郭以外の線は描かないことも、ほぼ確定でしょう。 あくまで、2D-RPGのキャラチップの 40px × 40px 程度のドット絵だけに限定した話です。なので、反論などで顔グラフィックなどキャラチップ以外の話題を出されても、ピント外れです（相手が言ってもいないことで反論することを「[[w:ストローマン|w:藁人形論法]]」（わらにんぎょう ろんぽう）と言います）。ましてやRPG以外のアクションゲームなどのドット絵の手法で反論しないでください。 ===== デッサン的なこと ===== {{コラム|髪の揺れ と腰のねじれ など| 女性キャラのチップだと、前後の歩行中チップでは髪やスカートが左右にゆれたりします。男性キャラでも、マントを羽織った騎士などなら、マントが揺れたりします。 テストでは、そういう点をチェックをしていくことになるでしょう。 こういった感じで実際にゲーム画面中でテストしてみて、もし問題がなければ、あとで細部を書きこんでいくことになるでしょう。 また、キャラクターデザインの細部に興味がなければ、下書きの塗りを修正し終わった段階で、このままで完成としても構わないかもしれません。 なお、髪の毛が右に揺れる場合、足で伸びているのは反対側である左足です。 髪の毛が左に揺れる場合も、足で伸びるのは反対側である右足です。 これはなぜそうなるかというと、歩行時の腰の ねじれ を表現するためです。 普通の歩き方では、右手が前方に伸びているときは左手が後方に伸びており、このため上半身が左回転します。 このままだと体が左回転して進路が左にそれてしまうので、足側では左足が前方に伸びて右足が後ろに伸びることで下半身は右回転します。 こうして上半身が右回転する一方、下半身が左回転するので、全身では回転が打ち消されることで前方に歩行できます。 また、上半身と下半身とが逆方向に回転しているので、腰はわずかに ねじれます。 だから、髪の毛が右に揺れるなら、これは上半身が右回転した直後の表現なので、つまりこのとき下半身側では左回転した直後の表現になっていなければなりません。これはゲームに限らず、アニメでもそうでしょうし、現実の人体がそうでしょう。 なお、無理やり、腕の振りのタイミングと、足の降りのタイミングを一致させる歩き方を、ナンバ歩きといいます。つまり、右手が前に出ているときに右足も前に出る歩きがナンバ歩きです。 格闘技や古武術などだと、色々な理由によりナンバ歩きをする場合もあります。 だから、もしかしたら対戦格闘アクションゲーム（スト2みたいなの）ならナンバ歩きで描く場合もあるかもしれません。しかし、2D-RPGの歩行チップでは不要でしょう。 }} ===== ドット絵作画的なこと ===== さて、いくつかフリー素材を調べたところ、横向き時の中ポーズの足は、1本しか見えません。 ついつい歩行中の中ポーズも意識して足を微妙にズラして2本書きたくなりますが、しかし静止ポーズにも使うことと、ドット絵なので微妙な足の段差を表現しづらいことなどから、 決断して横向き時の足は1本しか見えないほうにするのが効率的でしょう。 どうしても中ポーズでも足2本を見えるようにしたい場合の裏ワザとして、2本の足が合体した太い1本足を描くというワザがあります。やや太めの1本足です。 一部のフリーゲーム素材がこういうワザを使ってドット絵を描いています。 ドット絵なんてこんなもんのゴマカシの連発ですから、あまり下調べの段階なのに細部を調べても仕方ありません。さっさと書き始めてから、書いてる途中に気になった点から手本を見直して調べていけばいいのです。いろいろと調べるの必要になりますが、さっさと書き始めるのも重要です。こういうのは、調べていたらキリがありません。 デッサンのコツなんて、細部を書き始める時点までに、把握できていればいいのいです。 仕事でなければ、イラストなんて最終的には描いた自分で満足できればいいのです。プログラマー視点で見るにしても、歩行プログラムの検証をできる最低限のイラストさえ書ければいいのです。 当ページはプログラミングの教科書ですので、まず先にプログラム検証のための最低限イラストを描くことになります。 == 戦闘 == * [[ゲームプログラミング/RPG/戦闘]] とりあえずバブルソートの話題など。ほか幾つか。 == デーテベース的なこと == * [[ゲームプログラミング/RPG/データベースとは]] == (※: 未確認)戦闘中のモンスター隊列 == さて、戦闘中のモンスター隊列の構成を定義するための配列（または同等の内容の数列）も、必要です。 まず、画面に敵を、表示したい順に表示するためも必要です。 また、上述の「素早さ順」での行動処理のためにも、前提として、敵パーティの構成を表すための配列が必要になります。 説明の単純化のため、敵は横一列に、左から右に、並んでいるとしましょう（ドラクエ2～3みたいな方式だとしましょう）。 たとえば敵が左から順に :ホブゴブリンが1匹、毒々スライムが1匹、ゾンビ兵士が1匹 出現したとしましょう。（説明の単純化のため、モンスターは各種類ごとに1体だけとする。） そして、ホブゴブリンのモンスター用データベース中でのIDが13番だとして、　毒々スライムのIDが8番、　ゾンビ兵士のIDが25番、　だとしましょう。 すると、この敵パーティを表すための配列として、 :{13,8,25,-99} のような配列が必要です。（もしくは、配列に格納できるような数値の列「13,8,25,-99」） 末尾の－99は、これはその配列の読み終わりとして使用するための数字です。この数字は、別に「-10」でも「-99」でもいいですが、モンスターのidとけっして重ならないようにする必要があります。 通常、なんらかのデータベースのidの値は0以上の正の整数ですので、マイナスの整数を「終了」の意味で使用しておけば、安全でしょう。 このように、敵側にも、配列が必要になります。 しかも、この敵側の配列は、そのゲーム中で出現する敵パーティの全パターンを用意する必要があります。 たとい1体だけしか出現しない敵でも（たとえばボス敵や強敵）、その1体分の敵パーティの配列が必要です。 たとえば、その1体だけで出現する、あるボス敵「暗黒大王」のモンスター用データベース中でのIDが205番だとしたら、 :{205,-99} のような、敵1体だけの配列を用意する必要があります。 === 余談: マイナスを含む並べ替え === なお、もしマイナスの数を含む数をふくめて並べ替えをしたいのでしたら、 上記の「-99」など終了処理を負数で区別する方法は、そのままでは使えないです。 たとえば、方向でもし東向きをプラス、西向きをマイナスとした場合、終了コードのつもりの「-99」は、誤解で「西に99マス」などと誤解される恐れがあります。 たとえば、 :-3 , 5 ,2, -6, -2 , 0 , 1 の並べ替えをしたい場合を考えましょう。 解決策としては、いろいろあります。 ==== 解決策1 ==== 一番ラクな方法は、要素数を新たな変数として追加し、それと組み合わせて配列を使うことでしょう。 たとえば、 :-3 , 5 ,2, -6, -2 , 0 , 1 は7個の数が並んでいるので、 youso = 7; みたいに新たに変数を用意します。 そして、たとえば最初の「-3」から順番意読み取りの際に、数えおわった個数を+1していき、+7になったら読み取りを終了することです。 この方法は、拡張性が高いのでオススメですが、ただし、要素を書く前に個数を宣言する必要があります。 実際の配列データは :-3 , 5 ,2, -6, -2 , 0 , 1, 0 ,0 ,0 , 0 ,0 ,0 , （以下略） のようになっているので、けっして数え終わって欲しいところでキリよく要素が終わるわけではないので、なので、要素数をあらかじめ宣言する必要があるのです。 さもないと、8番目の「0」が、読み取りたい数値としてゼロなのか、それとも、単にデータなしのためゼロなのか、不明になります。 終了コードなどとして負数を使用するのは、マイナスを含む並べ替えでは、あきらめましょう。それが安全でしょう。 ==== 解決策2 ==== 最初の解決策1（要素数を新たな変数として追加）がもっとも安全かつ簡単ですが、比較のため、別の解決策も紹介しておきます。 次の解決策2は、数学的にはエレガントですが、しかしプログラミング的には、煩雑になり、また、バグ時などのエラーの波及をしやすい欠点があります。 さて、並べ替えのもうひとつの解決策として、 一例は、符号と絶対値を分離して、その組み合わせとして処理することです。 たとえば、 :-3 , 5 ,2, -6, -2 , 0 , 1 の並べ替えをしたい場合、 プレイヤーからは表面的には「-6」は1つの数に見えまずが、これをあえて、「フラグhugouが状態2（マイナスに相当）である」「絶対値 zetai が6である」というように、2つの変数hugou と zetaiに分けます 符号がプラスなら、hugou = 1　にでもしておきましょう。また、ゼロは便宜上、hugou = 1 にしておきましょう。 すると、上記の数の並びは、(hugou, zetai)のベクトルで考えると、 :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1) という組み合わせに変換するので、マイナスが使われない形になります。 なので、終了処理に、「-99」などの負数を割り当てても、並べ替え対象の数値と重なる心配がなくなります。: (2, 6,) , (2, 3) , (2, 2) , (1,0) , (1,1) ,(1,2), (1,5) :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1),(-99,0) などのように、終了コード「(-99,0)」を末尾に追加しても、なんの混同の心配もなくなります。 さて、いったん上記のように、数を、符号と絶対値の組み合わせに分解して、同じ符号どうしで並びかえたなら、 あとは、符号が同じものどうしで、並べ替えをするだけですみます。 たとえば、 :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1) の並べ替えをしたい場合、ベクトルの第一引数に注目し、※ （第一引数、第二引数） まず、 :(2,3) , (2,6), (2,2) のグループ : (1,5) ,(1,2), (1,0) , (1,1)のグループ に分けます。 そして、絶対値(例では第二引数)だけに注目すれば、 :マイナス数の絶対値は 3,6,2 → 2,3,6 と並べ替え → 逆順にして6,3,2 → マイナス符号をつけて -6,-3,-2 :プラス数の絶対値は 5,2,0,1, → 0,1,2,5 と並べ替え となるので、簡単に並べ替えできます。 あとは、これを合成し、 :-6, -3 , -2 , 0 , 1 ,2, 5 と、並べ替えできます。 なお、説明の都合上でベクトルを蒸気の解説で使ったが、しかしC言語にベクトルの機能は無いので、もし上記の機能を実装するなら配列や構造体配列を使って、ベクトルと似たような処理を実装することになる。 たとえば配列で実装するなら、符号用の配列 hugou[id] と、絶対値用の配列 zetai[id] のようなものを用意したりすることになるだろう。 もし1番目の最初の数が「-3」なら、符号フラグは2、絶対値は3だからベクトル表現では :(2,3) であるが、これは配列で表現するなら、たとえば :hugou[0]=2; zetai[0]=3; のように記述できる（C言語では配列の番号は0から数える）。 ;欠点 この方法は、一見すると数学的にエレガントに見えるかもしれませんが、しかし、もしバグやタイプミスなどによって数え間違えると、数え落としや重複があると、以降の符号が1個ずつズレてしまうなどの大きな影響があります。 たとえば、説明のため上記では :-3 , 5 ,2, -6, -2 , 0 , 1 の分解を :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1) とマトメて書きましたが、 実際には :hugou 2,1,1,2,2,1,1 :zatai 3,5,2,6,2,0,1 のように別々の変数に分かれて保管されるのです。 もし、たとえば hugou の最初に、バグなどで「1」が加わると、 :hugou 1,2,1,1,2,2,1,1 :zatai 3,5,2,6,2,0,1,0 のようになってしまい、すべての符号が1個分、ズレてしまい、 :3, -5, 2, 6 ,-2 , 0, 1 ,0 となってしまいます。 正しい元々の数字の並びの :-3 , 5 ,2, -6, -2 , 0 , 1 と比べると、符号がいくつも間違っており（1個目と2個目と4個目が違う）、解決策2ではエラーの波及が大きいことが分かります。 == 脚注 == {{reflist|group=注}} == 参考文献など == {{Reflist}} 5gx1osvqp1u5axvkd9nsqeuzjpko82v 206834 206833 2022-08-20T02:38:02Z すじにくシチュー 12058 /* 似た機能を複製する場合 */ wikitext text/x-wiki == 本書の注意点 == === 本書の目的 === 本ページ『ゲームプログラミング/RPG』では原則、あまり（あるいは「まったく」）、いわゆるドラクエ的な意味での「RPG」の難易度デザインやそのためのパラメータ調整などのゲームデザインに関する話題は'''扱いません'''。 なぜなら、本書『ゲームプログラミング』は、題名にもあるとおりプログラミングの教科書だからです。つまり本書は、RPGのゲームデザイン論の教科書'''ではない'''です。 難易度デザインについては、RPG限定ではないですが本wikiでは別途、『[[ゲームプログラミング/バランス調整]]』という難易度デザインに特化した目的のページが切り離されて存在しているので、そちらをご利用ください。 同様に、ゲームシナリオやイラスト素材や音楽素材などの制作など自前のRPG制作に必要なその他の知識も説明しません。もしかしたら必要に応じて「ドットエディタ」などのキャラチップ制作ツールの存在や最低限のIT的な説明はするかもしれませんが、しかしデッサン的な話題は一切しません。 === 出典などの有無について === 市販のゲームクリエイター教育書には、一切、RPGのプログラミング解説書はありません。 一応、アクションゲームについては書籍『[https://www.amazon.co.jp/%E3%82%B2%E3%83%BC%E3%83%A0%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AB%E3%81%AA%E3%82%8B%E5%89%8D%E3%81%AB%E8%A6%9A%E3%81%88%E3%81%A6%E3%81%8A%E3%81%8D%E3%81%9F%E3%81%84%E6%8A%80%E8%A1%93-%E5%B9%B3%E5%B1%B1-%E5%B0%9A/dp/4798021180 ゲームプログラマになる前に覚えておきたい技術]』や『[https://www.amazon.co.jp/%E3%82%B2%E3%83%BC%E3%83%A0%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0C-Sanjay-Madhav/dp/4798157619/ref=pd_lpo_2?pd_rd_i=4798157619&psc=1 ゲームプログラミングC++] 』などがありますが、その書籍は別にRPGには限定しておらず、どちらかというとアクションゲーム寄りの内容かもしれません（たとえば『ゲームプログラミングC++』では「衝突検知」などの話題がある）。 そういった出版事情もあり、本ページでは、出典のないRPGゲームプログラミング技法を多く紹介しています。 出典がなくても、プログラミングについては実際に Visual Studio などのコンパイラでその技法を確認してみれば真偽の確認ができますので、読者ご自身で真偽をご確認ください。 本ページに限らず『[[C言語]]』や『[[JavaScript]]』などの本wikiのプログラミング言語の教科書も同様に、プログラミング技法については特に出典はないスタイルです（出典があるのは、主に用語や歴史などの説明に関する出典だったりする）。 想定読者として、そういう御自身でコンパイラでコードをビルドして確認できるレベルの人を本ページでは想定していますので、もし読者がそれに到達していないなら、このページからは決して学ばないでください。 === コード全部は紹介しきれない === 実際のゲームプログラミングでは、たとえ無音声の2Dゲームですら、計算処理の他にグラフィックやキーボード入力など多くの機能が連動するので、コードはかなり長くなります。無音2Dのシンプルな超短編ゲームですら、初心者でもコードが何千行やあるいは1万行以上にもなります。 そのため、本wikiでは動作ソースコードの全部は到底、紹介できないです。だから本wikiで紹介されているコードをコピーペーストしても、それだけでは動かないのが普通です。 本ページにあるC言語のコードは、プログラミングでRPGを作る際に、「たぶん多くの人はこういった点が気になって悩むと思うから、こういうふうにコード記述すれば解決できると思います」といった方針だけを提供するものに過ぎません。 あるいは、もし本書で紹介したコードで動作したとしても、そのコードの結果はコマンドプロンプト（DOSプロンプト）のような真っ黒い画面で、RPG的な計算内容による計算結果だけを表示するプログラムだったりするので、そのままでは他人に遊んでもらえるような実際のゲームではないので、したがって実際のゲームプログラミング時には映像の表示などのためのコード追加がかなり多く必要になります。 == はじめに == 本ページの'''RPG'''は、ターン制の戦闘システムを採用した<ref group="注">いわゆるドラクエ シリーズや昔のFF（ファイナルファンタジー）1～3あたり</ref>RPG（Turn-based RPG）を中心にとり扱う。アクションRPGやシミュレーションRPG、アクティブバトルなどを語る場合には、注記する。 以下のものは取り扱わない。 * テーブルトークRPG。TRPGや、テーブルトップRPGとも呼ばれる。 なお、本ページでは説明のために[[C言語]]を用いている。C言語の理解を前提としている箇所が存在するため、もし読者が知識をお持ちでない場合は、適切な媒体で調べながら読み進めていただきたい。 本ページではC言語を説明のために用いているが、開発環境がそれ以外の言語である場合は、適宜読み替えていただきたい。 {{コラム|使えない理論は捨てよう| これからこの単元では、ゲームプログラミングとそれに関連する理論を解説していきます。 ですが、ゲームやマンガやアニメなどの娯楽は、理論にもとづく分野ではなく、観客を楽しませてナンボの業界です。 また、そもそも伝えられている理論自体が間違っている場合もあります。 たとえば漫画家の江川達也（えがわ たつや）の体験談なのですが、彼は漫画家デビュー当初、マンガ中での男性キャラの履いているズボンをかっこよく書くのに時間が掛かっていて困っていました。 そうなった理由は、彼・江川の崇拝するマンガの巨匠、手塚治虫が、「人体に直線の部分は無いので、人の絵を書く際に定規などを使うべきではない」という理論を、江川も信用していたからです。 しかし、その手塚理論のせいで江川はズボンを書く際に定規を使わなかったので、ズボンのラインがうまく真っ直ぐに書けず、困っていました。 ある時、江川が試しに定規を使ってズボンを書いて見たら、短時間でズボンをかっこよく描けたので「手塚先生、ウソを教えやがった」と愚痴を何かの書籍で述べていました。 マンガなど創作の分野の理論とはこういものです。偉い人が言ったから正しい、というものでもないし、当然、偉くない人が言ったから正しいというわけでもありません。 そうでなくて、実際に理論を手段として使ってみた結果、観客から見ても「かっこいい」「かわいい」「楽しい」という感情を呼び起こさせる作品をつくるのに役立つかどうかです。「かっこいい作品」「かわいい作品」こそが良い作品なのです。「理論どおりの作品」はけっして良い作品ではありません。だからマンガ、アニメ、ゲームなどの創作の理論とは、観客を楽しませる良い作品をつくるための手段の知識をまとめただけにすぎない道具が「理論」です。 だから、ある理論がもし創作の役に立たないなら、その理論はさっさと捨て去るべきです。少なくとも、その理論のために手間を掛けたのに作品を作っている自分すらも「かっこいい」「かわいい」「楽しい」などの感情を呼び起こせないなら、捨て去るべきです。 ;言語の必要性 では、理論は全く不要なのでしょうか。いいえ、そうではありません。知識や技法を言葉にすることで、覚える内容が明確化されるので、同じ手法を今後も何度でも繰り返しできるようになるという再現性（さいげんせい）が生まれます。 一方、勘に頼っていると、その日の体調や気分によって作品が左右され、再現性が不安定になるので、生産性もまた低下します。 この再現性のための言語化の必要性は、「アニメ私塾」のペンネームで有名なアニメーター・イラストレーターの室井康雄がたびたび彼のYouTube動画などで言っていることです。 しかしその室井もまた、「理論どおりに描いてみて、（かわいいキャラ、かっこいいキャラなどを）うまく描けないなら、その理論は捨てろ」という旨の発言を彼のYouTube動画などで言っています（少なくとも2021年の前半に言っている）。 さて、上記の手塚治虫の理論を信じた江川の例は、まだ手塚が漫画家の先輩でもあるので、信じてしまったのも分かります。 ですがインターネット上には、誰が提唱したかも分からない理論もあふれています。このwikiもまた例外ではありません。ゲームやアニメなどは新しい分野であるので、出典をつけるのが困難な分野もあるので、出典も不明な俗説・仮説に頼らざるを得なかったりします。また出典のある情報だけに頼ると、文章構成が著しく断片的になってしまい、読むに耐えないか、読者が理解できなくて教科書としての役に立ちませんので、そういった仮説どうしを文脈的に結合するためにwikiでは更なる仮説によって補充説明などを加えていることすらもあります。 なので、このwikiも含めて、ネットに書いてあることは信用せず、読者は実際に自分で手を動かして確認をとったことをもとに、技術や感性などを磨いていってください。 このwikiは参考のひとつ程度に留めておいて、提唱している仮説を試してダメそうだった場合は、さっさとこのwikiの理論を捨ててください。 ;ゲーム業界でも再現性あるマニュアル化が必要 ゲーム業界においても、『FGO』クリエイターの塩川洋介は、『ゲームデザインは「マニュアル化」できる』と、ある程度のマニュアル化ができることを認めています<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.23</ref>。 けっして、そのマニュアルは「普遍的」ではないですが、しかしだからといって、マニュアルも持たずに「センスや才能（※wiki追記: だけ）でやってはいけない」と忠告していますす<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.24</ref>。 なぜかというと、塩川氏も、「再現性」という言葉を使って、マニュアルの必要性を説明しています<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.26</ref>。 しかし、実際のゲーム製作は理論だけではうまくいかず、たとえるならスポーツのように実技的な側面もあります<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.40</ref>。 あと、盲点ですが、スポンサー企業などが、再現性がないと投資してくれないと、塩川氏は著書で述べています。 ただし、理論だけでなく、実技的な能力も必要であり、上記のゲーム業界の塩川氏もアニメ業界出身の室井氏も、よく創作をスポーツに例えています。結局、ゲーム産業だけでなくアニメ業界やマンガ業界の実務分野の教育者たちも、似たようなことをいっており、よくスポーツにたとえます。 創作の世界は、どこも似たような傾向があります。 なので、けっして頭でっかちにならず、実際に手を動かすなどして、スキルを習得していきたいものです。結局、ゲームも漫画もアニメも、マニュアル的なものを準備しつつ、それを検証しながら修正していく運用法が必要になりそうです。 そういう言語の限界を分かった上で、理論は使いましょう。 ;異業種の例 アニメ業界だけでなく、テレビCM業界など異業種でも、言語の必要性と似たようなことを言う人はいます。 97年にソニ－から発売されたゲーム『I.Q』の企画に携わった有名な広告プランナーの佐藤雅彦（お菓子のポリンキーなどのＣＭの人）は、 映画監督の川村元気の対談集『理系に学ぶ』で、 佐藤いわく「感性とか信念みたいなことを軽々しく言いたくないですよね。最後は感性で探り当てるしかないんですが、 そういった言葉ですぐ片付けるのは、傲慢な気がします。」と述べています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.62</ref>。 同じ川村元気との対談集では、別の対談相手ですが医学者の養老孟司は『戦後のものづくりなんかも大勢の理系の人が一生懸命トンネル掘ったり、計算機を作ったりしたけど、あれも嘘をつかない。要は言葉を信用してないんです。』と述べてます<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.15</ref>。第二次世界大戦の終わった昭和20年8月15日、それまでの日本の新聞やラジオなどのメディアが喧伝する常識が崩れたのです。 養老はそういう過去を振り返って、「言葉を信用しない」と対談集で述べています。養老の場合、嘘をつかない医学解剖に興味をもち、解剖学を専攻したと述べています。 さて、ガンダムなどで有名な富野監督は、2012年ぐらいの書籍か雑誌での対談インタビューで、 その本では異業種の人たちと対談していたのですが、おおむね 「アニメ業界は教育を見直して整備しないといけない。会社が実務的なこともっと教育をしないと、頭のいい若手は、自分で教育を始めてしまう。」といった感じのことを言っていました。もちろん、富野監督は、大いに教育をすべし、という立場であり、その若者を応援する立場です。 自発的に若者が教育を始めるのなら、それだけ聞けばよいことのように思えますが、しかし富野監督がわざわざこういう苦言のような言い回しでいうことには、なにがしか、周囲からの反対意見などもあったんだろうとか、読者は推測してください。大人には、企業の事情などで言えないことがあるのです。 たとえばガンダムを作っている会社は「サンライズ」というアニメ会社なので、他社（たとえばエヴァンゲリオンの会社なら「ガイナックス」とか「カラー」という別アニメ会社です）に所属する若手アニメーターの主催するアニメ作画勉強会に出席するのは、いろいろと大人の事情があり、周囲からは疑義も出てくるのです。 富野監督はさらに、その対談書で、「自分だって絵を描くときにフォトショップを使っている」ということも言っています。もしかしたら、フォトショップに対する反対意見とか、いろいろあったんでしょう。 どこの業界でも、実務教育はいろいろと難しいものです。 }} {{コラム|それでも読書が必要なわけ| 創作は、読書だけでなく、スポーツ的に実際に手を動かして作品を作る経験も多く必要です。 それでも やはり読書は必要になり、ゲーム業界人の書いたゲーム専門書やゲーム制作教本などを読む必要が出てくるでしょう。 あまり何十冊も読む必要は無いですが、本屋で2冊くらいは教本を買って読んでおくと良いでしょう。 ではなぜ読書による勉強も必要なのかの話をします。 それは、業界の中にいる、ダメな先輩をダマらせるため、ダメ先輩に足を引っ張らせないためです。どこの業界でも、不勉強・経験不足な割に年功序列などで出世してきている先輩がいます。あるいは、勤勉ではあっても、自社でしか通用しないヤリ方を、業界全体の標準ケースだと勘違いしている先輩もいます。 そういう、ちょっと困った先輩を、それとなく間違いに気づかせるために、同じ業界でもっと経験のある専門家の書いた文献を読むのです。 たとえば、入社1年目の新人には、入社5～10年目くらいの上司がついたりするわけですが、所詮は入社10年目程度の中年サラリーマンなので、間違ったことを教える場合もあります。そこで、同じ業界の20年選手や30年選手のベテランの書いた本を読むのです。 だから、本屋で2冊くらいは、業界のベテランの書いた教本を買って読んでおけばいいのです。 このwiki『ゲームプログラミング』でいろんな分野を何十冊も出典紹介していたりするのは、単に著作権上の都合にすぎないので（もし1冊の本だけを書き写したら著作権侵害になる）、ゲーム制作にはそこまでの多くの文献は不要ですが教科書著作のため仕方なく多くの文献を確認しているだけにすぎません。読者はwiki編集者の読書法・勉強法を真似る必要は無いですし、真似るべきではないです。 ネットの情報をあさるのではなく、実際に本で買って読むのが必要です。なぜなら、ネット情報だと、本気度が分かりません。webサイトのスポンサーの都合などもあり、言いたいことが言えないケースもあります。だから、実際に書籍として出版されている本を買いましょう。 }} == 予備知識と学習法 == === 予備知識 === 一応、ターン制RPGは関数や配列を知らなくても、作り始めることはできます。 最低限必要な知識として、変数と、キーボード入出力の関数と、if文、タイマー関連、画面出力、あとはせいぜい乱数などがあれば、ゲームを作り始めることができます。 これはRPGにかぎらず、よくプログラミング入門書にあるジャンケンゲームなども同様でしょう。ジャンケンゲームならタイマーすら不要でしょう。 しかし、「関数を知らないプログラミング」とは、たとえば、zボタン（決定ボタンとする）を押したときのプログラム記述で、DXライブラリでの開発なら、マップ画面モードでも戦闘コマンド画面モードでもタイマーをカウント開始すると思いますが、そのタイマーの開始命令と関連する処置を各画面ごとに1行ずつ書いていく方式です。 だからもし、バグなどがあってコード修正する際、すべての画面モードのzボタンを命令を一個ずつ直さなければなりません。RPGはモードが多いので、そのような修正は、なかなか面倒です。 だから、別に作り始めの時点で関数を知らなくてもいいのですが、しかし作っている途中に「バグの訂正で似た部分の繰り返しが多くて面倒だなあ・・・」という気分になったら関数も勉強していくのが望ましいでしょう。 そして、いつごろが関数を学ぶタイミングなのかを知るには、事前に自分がある程度は「関数というものがあって、コードの使いまわしに便利なものらしい」という知識が必要です。 配列も同様です。配列を知らなくても、パーテイ1人目のHPを変数名「p1HP」、パーティ2人目のHPを変数名「p2HP」のような方式でRPGを作れます。 しかし、これを敵15体も登録されているRPGで「m1HP」から「m15HP」とやるのは、少し面倒です。 なにより一番の問題は、配列を知らないと、ドラクエ1的なマップ画面すら作るのが、かなり困難になることです。 よくプログラミング教本などにある例では、マップを二次元配列で実装しています。 たとえば、書籍『12歳から始めるゼロからのC言語 ゲームプログラミング教室』がそうです<ref>大槻有一郎『12歳から始めるゼロからのC言語 ゲームプログラミング教室 Visual Studio 2015対応』、2016年3月1日 第1刷発行、2017年4月10日 第2刷発行、P165</ref>。 たとえば、 <pre> { {0,0,0,0,0,0,0,2,2,2}, {0,0,0,0,0,0,0,2,2,2}, {0,0,1,1,0,0,0,2,2,2}, {0,0,1,1,1,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0}, } </pre> みたいな感じで、0番が草原、1番が森、2番が岩山、のような感じです。 横10×縦5のマップはそれほど広くないですが、 たったこれだけのマップでも、もし配列を知らなければ変数が50個必要です。 「配列を知らなくてもRPGを作れる」というのは、たしかにノンフィールドRPGなどは作れますし、 あるいはフィールドがあっても「マップはすべて草原、あるいはマップの99%くらいが草原（草原でないところだけ変数指定する方式）」のようなゲームなら作れますが、 しかしそれは、多くのRPGプログラミング入門者が考えているような、ファミコン～スーファミ水準のドラクエ・ファイファン的なイメージのRPGとは異なります。 初心者に「配列を知らなくてもいい」というのは無責任です。 配列を知らなくてもゲームプログラミングは開始できますが、もしも配列が必要になった時点で（変数を一個ずつ宣言するのが面倒なモジュールを作るとき）、 配列を学び始めるのが良いでしょう。 === 作ってから学ぶ === 別に市販のC言語の入門書の基礎文法すべてに精通してからゲームプログラミングを開始する必要はありません。 おおよその機能だけを市販のC言語入門書に目を通して知っておいて、プログラミングでは変数などの初歩的な知識だけを用いて作り始め、足りない知識は必要になったらそのたびに、市販の入門書などで学べばいいのです、 また、その市販のC言語入門書を読む時間も、通学中・通勤中で電車のイスに座ってる時に読むとか、あるいはトイレでウンコしている時に読むとか、そういう時に読めば、プログラミングの時間を減らさずに時間を有効活用できます（ただし睡眠時間や食事の時間などは減らさないようにしましょう）。 さて、セーブやロードなどの機能は、当分は不要です。そもそも、セーブが必要なほどの長さのシナリオなんて作るのは当分は後です。もしお作りのゲームが1分でクリアできるようなゲームなら、セーブなんて不要でしょう。 だから、C言語のファイル入出力の機能などは、当分は不要です。 つまり「学んでから作る」ではなく「作っているうちに気になった点を調べる」のがコツでしょう。 おそらく「関数を知らなくてもRPG作れる」といっているプログラマーはたぶんそういう事を言いたかった口ベタな人なのでしょう。 なお、配列や関数などは、自分が直接は使わなくても、他人が使います。 たとえば、マップの実装で、もしかしたら二次元配列を使わなくても、原理的には一次元配列を何十個も並べて実装する方法もあるかもしれませんが、しかし他人がそういう一次元配列を何十個も並べてマップ実装したコードなんて読みたくないし、教育者も面倒なのでそういうコードを教えてくれません。 なお、構造体は別に知らなくてもRPGは作れます。列挙体 enum なども同様です。単に構造体の配列を知っていると、（装備品やモンスターなどの）データベースを第三者がより読みやすい形で作りやすくなるだけです。列挙体を知っていると、モードの切り替え（マップ画面モードからメニュー画面モードへの切り替え等）をしやすくなります。 正直、市販の「ゲームプログラマー向け」をうたったプログラミング教本の中には、少なくともゲームプログラマー初心者の時点では不要な高度な知識も多く紹介されています。しかしそういう本でも、出版社などの宣伝の都合からか、「プログラマーになる前に読んでおきたい」みたいな宣伝文句が付けられたりしているかもしれません。そういう高度な知識もあとで仕事で必要になる場合がありうるので、ゲームプログラマー向けとして出版する事自体は正しいのですが、しかし初心者や入門書に進めるような宣伝文句をつけるべきかというと・・・となる内容の市販本もあります。 === ポインタ不要論 === よく、「ポインタによる処理で速度の向上!」みたいな事が、ゲーム好きのプログラマーに言われます。 しかしポインタによるコーディングは、プログラムのメンテナンス性を悪くします。なぜならもしポインタ使用個所の周辺でバグが発生した場合に、ポインタがあると原因が特定しづらくなるからです。 一般のグローバル変数やローカル変数と比べてポインタ変数は仕組みが単純ではないことや、配列や構造体にポインタなどを用いる場合はもしその配列・構造体にバグがあると同じ配列内・構造体の別の部分にまでバグが波及するなどするので（コードによっては、もしかしたら、下手したら周辺の別の配列や構造体に波及する場合もありうるかも）、ポインタで実装されたモジュールがあるとバグ発生時に原因の絞込みが難しくなるのです。 もし仮にポインタ処理化を実装した直後では正常に動いていても、しかしあとで、今まで未実装だった部分が実装された場合に、なんらかの不整合によるバグが発生するようなことも良くあり、ポインタ処理はその際、バグ原因の特定を難しくします。 だから仮にどうしてもポインタを使わないといけない場合でも、RPG製作なら、なるべくポインタを実装するのは後回しにして、当分は一般の変数で実装したままにしておくほうが良いかもしれません。 あるいは、もし機能の実験や勉強を兼ねてポインタ処理の実験と実装をしたのなら、現状ではポインタ変数で実装してある箇所でも、あとでデバッグなどの際に一般の変数に戻す可能性も考慮することになります。 RPGの場合、デバッグに時間を多くとられますし、変数がとても多いので、メンテナンス性も考慮せざるを得ません。 ;そもそも本当にポインタの必要な処理か? ポインタによって高速化のメリットが得られる場合とは、C言語教科書などの理論では、大量の要素の構造体を（関数の引数などとして利用する際に）コピーする場合ぐらいです。 だからもし構造体を使う場合であっても、そもそも自作で用いる構造体変数がグローバル変数であればコピーの必要自体がないので、ポインタの必要もありません。 ゲーム内の武器データベースやモンスターデータベースなどが構造体で実装されると思いますが、初心者なら普通はそれらの構造体変数はグローバル変数として実装することになるでしょうし、グローバル変数として実装しても何も困りませんし、実際それでもRPGを作れますし、正常な速度で動きます。 例外的な事例を考えるなら、たとえばマップイベントのデータベースなど、特定のモードでしか使う機会のないデータベースなら、理論的にはグローバル変数でなくポインタによる取り扱いによって処理速度の向上の可能性はありえますが、しかし正直メンテナンス性が悪いし、難しい割にはポインタ化してもしなくても初心者ゲームのレベルでは速度は変わりません。せいぜい勉強になるだけです。 こういう風に、市販のC言語教科書にある知識の一つ覚えは、通用しません。 == 設計の方針 == === 身体障害者プレイヤーの配慮 === ターン制RPGは、身体障害などでアクションゲームなど反射神経を要するゲームの苦手な人もプレイします。なので、それを意識した設計にしましょう。シミュレーションゲームも同様です。もっとも、さすがに腕のないプレイヤーにまでは配慮できないので、程度問題ですが。 ともかく、だから、もしどうしても制作中のターン制RPGにアクション要素のあるイベントを入れる場合、たとえば工夫として、 事前にそういうアクションイベントのあることをプレイヤーに作品紹介文などで紹介しておくとか、 あるいはそのアクションイベントをもしクリアできなくてもプレイヤーがゲームクリアできるように設計するなどの配慮が望ましいでしょう。 もしくは、充分にアクション要素の難易度を下げておく必要があるかもしれません。 === ユーザーインターフェース === もしもC言語でゼロからゲームを作るなら、UI（ユーザーインターフェース）をゼロからDirectXなどで作ることになります。 シナリオどうこうより、まずUIを作るのが真っ先になります。 結論から言うと、需要のあるUIの種類はそんなに多くなく、よって最終的には既存の有名ゲームのUIを真似することになります。（練習として新規のUIを色々と制作してみるのは構いませんが、しかし実用的なものを新規に発明するのは困難かと。） ==== 「はい」/「いいえ」の選択肢 ==== RPGなどで選択肢で『はい』か『いいえ』がよく出ることがあります。 この場合、必ずしも順番どおりに はい いいえ とするのが良いとは限りません。 なぜなら、プレイヤーがセリフ送りなどでボタンを連打している場合に、あやまって選択肢も連打してしまうことがあるからです。 文献『ゲームプランとデザインの教科書』によると、選択肢の順序についての設計テクニックとして、現状を維持するほうの選択項目を先に表示したりとか、あるいはマウス操作式のゲームなら現状維持や安全なほうの選択肢にカーソルを事前に合わせておくなどの工夫が、定石とされています<ref>『ゲームプランとデザインの教科書』、P399</ref>。 ==== 健康上の留意事項 ==== ===== カーソル点滅と「光過敏性てんかん」 ===== 例えば、コマンド選択などのカーソルの方式には、 :ファミコン時代のＦＦ（ファイナルファンタジー）のようにカーソル画像を選択内容の左隣に置く方式、 :あるいは、ツクールのゲームの標準設定のように選択項目の背景が点滅する方式、 など幾つかあります。 カーソル点滅させる場合、実はこれはほとんど、カーソル点滅色は白系の色にせざるを得ません。 なぜなら健康上の理由があり、もし青色ウィンドウなのに、たとえばカーソル色を赤（または緑にして）、赤カーソルを点滅させると、「光過敏性てんかん」のような症状を引き起こします。このため、点滅カーソルの背景色は、事実上は、ほぼ白色に決まります。 一応、白でなくても、たとえば青ウィンドウなら水色などの背景色でも可能ですが、手間が増えますし、ほかのウィンドウ色（たとえばウィンドウを赤に変更した場合）では応用が利きません。 ゲームによっては設定カスタマイズなどでウィンドウ色を変えられたりしますが、プログラマー的に分析するコツとしては、カスタマイズできない部分（たとえばカーソル色はカスタマイズできない等）にも注目すると良いでしょう。 ===== 色弱の対応 ===== なお、色弱（しきじゃく）/色盲（しきもう）という病気があり、緑色と赤色の区別がつきづらい人が、世間には居ます（赤緑色盲）。例外の人もいて、青など他の色が見えない人もいますが、しかし色弱患者で統計的に割合がもっとも多いのは赤緑色盲です。 赤緑色盲の人には、赤も緑も、ともに茶色に見えます。なので赤緑色盲の人にあ、赤と緑を区別できないのです。 よって事実上、ウィンドウ色は原則的に青色になります。ファイナルファンタジーや昔のツクールなどが、ウィンドウ色に青色を標準的に採用しているのは、決して偶然ではなく、いろいろな事情があるのです。 どうしても同一画面に赤と緑を表示しなければならない場合、色の濃さを変えるなどして、たとえば濃い緑と、うすい赤、などのように濃度差をつけるなどする必要があります。（この濃度差の手法は、役所などの出す、色覚障碍者向けのガイドラインなどにも書いてある、典型的なアドバイスです。 ） そもそも、色盲でなく健常者でも、濃度の同じくらいの赤色と緑色の組み合わせは、やや見えづらいです。 学校の「黒板」という緑色の板に、赤チョークで書かれた文字が、見づらかった記憶をもつ人も多いでしょう。 なお、赤緑色盲の人でも、黄色は、茶色とは区別して見えます。 なのでウィンドウに、黄色っぽい色と黒を組み合わせて使うのも手です。 あるいは、うすい茶色に、黒い文字という組み合わせもあります。 たとえばロマサガ1は、うすい茶色のウィンドウに、黒い文字です。うすい茶色と黒との組み合わせは、明度も大きく異なっているので、良い組み合わせでしょう。 スーファミ版の三国志4のウィンドウ色と文字色も、似たような組み合わせです。ただし三国志4の場合、文字に白い文字を使う場合もあります。数値などは白い文字です。このため、ウィンドウの茶色部分にはザラザラした模様をつけて白い文字を際立たせる工夫をしたりなど、工夫をしています。 ゲームに限らず、たとえば子供むけの歴史教材や小中学校の歴史教科書などでも、よくコラム欄などで、黄色い背景に黒い文字の組み合わせは使われます。古文書のような古い紙は黄ばんでいるので、歴史教材のコラムではそういう雰囲気に近づける目的で、コラムの枠を古文書の一ページのように描いているものもあります。 ゲームでもロマサガ1のメニューウィンドウは、古文書のように紙の下側の一部が書けていたり、まるで巻物の読み方のように左右が曲げられていたりして、ウィンドウに紙っぽさを出すデザインをしています。 例外的に、商業ゲームでもプレステ作品『俺の屍を越えてゆけ』のようにウィンドウがエンジ色（赤色っぽい色）の作品もあります。このようなUIの差異、当然ですが緑色の文字は使用不可能です。 {{コラム|回復量のフォントのうすい緑色について| よくツクールやウディタの同人ゲームで、 回復スキルをつかったときの回復量の数値のフォント色を、うすい緑色または水色っぽい色で表す場合があります。 しかし、攻撃ダメージのダメージ量の数値のフォント色は、ほとんどのゲームで絶対に白色ばかりです。 どこまで同人作家が色盲を意識しているかは知りませんが、 もしダメージのフォント色が赤色だと、色盲（赤緑色盲）の人には、これは回復スキルの緑色と区別できないのです。 ついつい出血の赤色を意識して、赤いフォントを使ってみようと思うかもしれませんが、しかしその場合は色盲の人にはプレイできなくなるゲームになることを覚悟する必要があります。 これはつまり演出面で考えれば、色盲の人には、血の色（赤）と、草の色（緑）とが、同じ色に見えていることを意味します。 }} {{コラム|色パズルのミニゲーム| ウィンドウを決める場合だけでなく、ゲーム中のミニゲームの暗号パズルなどで色を使う場合も、色盲に配慮しなくてはなりません。 ぶっちゃけ、商業RPGゲーム中にもしミニゲームとして色パズルの暗号イベントがあるなら、 暗号の正解に使える色は、もしそのパズルがクリア必須イベントなら、答えの色は必ず、赤・緑の以外の色になります。 だから答えに使えるのは、商業ゲームなら必ず、黒か黄色か青か灰色か白、のどれかです。 なぜなら、まず赤と緑は当然ながら使用不可能です。さらに、赤と青の混色である紫も使用不可ですし、 青と緑の絵の具の混色（減法混色）である青緑色も使用不可ですし、 青と緑の光の混色（加法混色）である水色も使用不可です。 橙色も、赤と黄色の混色ですので不可能です。 学校教育ではどうやら、こういう色盲のことはゲーム産業やIT産業の志望のための学校ではあまり教育されていないようですが、しかし電気工学の学校ではよく教育される知識です。 電気工業の分野で、抵抗の「カラーコード」というものがあって、下記の色がそれぞれ下記の数に対応しています。 :黒 0 :茶色 1 :赤 2 :橙 3 :黄色 4 :緑 5 :青 6 :紫 7 :灰 8 :白 9 国家資格の電気工事師は、抵抗素子についているカラーコード部分の色を見て、抵抗値を判断するスキルが必要です。 なので、昭和の規制の厳しかったころは、色盲の人はそもそも工業高校の電気科には入学できませんでした。どんなに中学の成績がよくても、色盲の子は工業高校電気科への受験自体を断られる時代があったのです。 電気工学の教科書には書かれていませんが、工業高校や大学工学部の電気系の学科に入学すると、もしまともな学校ならば、こういう事を教わるものです。 }} ===== 車酔いの防止 ===== 光の点滅以外にも、調整を誤るとプレイヤーに体調不良を及ぼす現象はあります。 、 たとえばキャラの移動速度の加速・減速は、なるべく滑らかに変化しなければなりません。 「車酔い」を思い出してください。もし急加速と急ブレーキを繰り返す車に乗車していれば、多くの乗客は酔います。 なので、たとえばRPGなどで、「マップの1マス移動後にいったん停止」というのは、避けたほうが安全です。 実際、ドラクエは決してそうなってはいません。行き止まりに当たらない限り、カーソルの左ボタンを押していれば、同じ速度で左に進み続けます。（右キーの場合も同様。） ドラクエの移動速度が等速度であることには、合理的な理由があるのです。 ;動きが時々カタつく場合 自作ゲームでテストした際、マップ移動中に右キーを押し続けたときに普段は等速で移動するのに時々カタつく場合があるかもしれません。その場合の対処法を後述で説明します。（2Dゲームのマップ機能の原理については、セクション『[[ゲームプログラミング/RPG#2Dマップ]]』で後述してある。） なお、普段から等速ですら移動しない場合は、単にバグですので、直してください。 このセクションでは、とりあえず普段は右キーを押し続けたら等速で移動するのに時々カタつく場合にだけ、よくある原因そのと対処法を説明します。 時々テストプレイ中に動作がカタつくことがあり、「バグか？」と不安になることがありますが、しかし必ずしもバグが原因でのカタつきとは限りません。 もしかしたら、Visual Studio コンパイラがメモリ圧迫またはCPU占有などをしていて、単に実行アプリの処理速度が低下しているだけかもしれません。プログラミングに熱中していると盲点ですが、Visual Studio はメモリやCPUの多くを占有することを思い出しましょう。 原因がそれか否かを確かめる簡単な方法は、まったくほかのアプリを起動していないときに、実行ファイルを起動してテストプレイしてみることです。 ただし、状況によってはその「実行ファイル」をビルドするためにVisual Studio を立ち上げないといけない場合もあり、なかなか面倒な作業でもあります（VSは終了や起動に時間が掛かるので面倒）。 1度に確認しようとすると面倒ですので、複数日に分けて確認しましょう。たとえば、このカタツキ問題が気になったときの睡眠前の晩にでも、事前に実行ファイルをビルドしておいてから Visual Studio を終了してから寝ましょう。そして翌日にでもwindows起動したときに、Visual Studio を起動せずに前日にビルドしておいた実行ファイルだけを起動してテストしてみましょう。 そのほか、この問題の検証方法として、どうしても Visual Studio 起動中に、メモリやCPUの圧迫によってカタついているか否かを判定したいなら、簡易的な方法ですが、 最近のRPGツクール製のゲームまたはウディタのサンプルゲームを起動してみて、カタつくかどうかを確かめてみる方法もあります。 もしVisual Studio によるメモリ圧迫やCPU占有がカタつきの原因なら、ツクール製ゲームやウディタサンプルゲームでもカタつくことがあります。いわゆる対照実験です（中学高校の理科（おもに生物分野）で習うアレです）。 上述の方法すべてを試してもカタつきの問題を判明できない場合、残念ですが当ページには原因がもはや分からないのが現状です。（もしお作りのRPGでのカタツキの原因が分かられて、他のプログラマーも遭遇しそうな原因でありましたら、情報提供のため編集に協力していただければ当wikiとしては幸い（さいわい）かもしれません。） ;高度な検討事項 前セクションの工夫でカタつきが解決すれば、下記の方法は不要です。また、ヘタにいじってバグの原因になると危険ですので、前セクションで解決したなら、そのままにするのをお勧めします。このセクションでは、参考のため、下記のような方法の検討を照会します。 動作をより滑らかにする工夫の一例として、たとえば、キーボードの十字キーの入力判定は、必ず1マス歩行のアニメーションの移動終了の少し前までに、判定を終わらせる工夫などが、考えられます。たとえば、1マス歩行のアニメーションが1.0秒かかるなら、入力判定は0.9秒目に行う、というような感じになります。 しかし、これはけっこう、シビアな条件であり、0.1秒単位でのタイミング調整を行わなければなりません。 歩行で1.0秒間というのは、割とゆっくりです。 一方、もしダッシュ機能とかあってダッシュ速度が1マスあたり0.5秒間だと、すこしタイミング調整が難しくなるでしょう。 もっと早いダッシュの場合は、Windowsだと少し難しいかもしれません。なぜなら、WindowsAPIのタイマー機能がそもそも、そんなに正確ではありません。0.05～0.10秒くらいの間隔になると、タイマーに誤差が出てきます。 DirectXのタイマーも、それに準じた性能だろうと思われます。なので、あまりに早すぎるダッシュでは、歩行のように「直前に入力判定」というのが、難しいかもしれません。 あるいは、もしかしたら、現代のコンピュータは処理速度が速いので、1.0秒のアニメーション終了後に入力判定を行っても、プレイヤーには気づかれないのかもしれません。 しかし、ハードウェアのメモリ容量などの事情によっては、もしかしたらアニメーション終了後の方式だと、動きにカクツキが出てくるかもしれません。ともかく、このように、速度ひとつとっても色々と考えなければならないことがあります。 こういうふうに、歩行アニメーション処理は、こりだすと、検討事項や調整事項が意外とあるので、初心者にはやや難しいです。 だから初心者には、歩行アニメーション抜きの方式がラクであり、いきなりキャラチップが移動先の隣マスに移動する方式（ファミコン時代の『信長の野望 武将風雲録』の戦闘の武将キャラチップみたいなの）のほうが、簡単でしょう。 同じ理由で、カメラの位置や向きなども、むやみに移動しないか、等速で移動しつづけるように注意する必要があります。 もし、「リアリティを出そう」としてカメラをキャラ歩行のたびに左右に振ると。プレイヤーが酔って気分が悪くなりかねません。よほど上手く調整しないかぎり、プレイヤーの体調的な気分を悪くしかねません。 だからカメラアングルで目指すべきは、2Dゲームなら結局、スーファミあたりのドラクエ的あるいはスーパーマリオ的な古典的なカメラ視点であるべきす。あるいは、もしポリゴンゲームなら、結局、カメラアングルで目指すべきは、プレステ1やサターンの時代のころのゲームのカメラアングルなどになるでしょうか。 あるいは、ファミコン時代にどうしても歩行アニメーションを停止しなければならなかった例として、ファミコン時代のウィザードリィや女神転生の3Dダンジョンのように、ポリゴン描写が無理などの理由で、どうしても停止しなければならない場合もあるでしょう。このような場合は、おそらくですが、停止中の1枚絵の表示時間の長さと、進行中の中割り（なかわり）の1枚絵の表示時間の長さが、同じぐらいの長さになるようにしないと、マズイでしょう（未確認）。 ==== 実装しようとしているものを明確にする ==== UIにおいて、アナログをデジタルで完全に実装するのは、大概困難ですが、アナログの「エミュレート」の実装は、それほど困難ではありません。 これはゲーム制作でも同様です。 たとえば、RPGの作中の武器屋や道具屋などでの買い物のシステムは、現実のスーパーマーケットやコンビニでの買い物とは異なり、まとめ買いはサポートされていないことが有ります。 ゲーム以外の話だと、たとえば通販サイトでの買い物の際、ユーザーレベルの目線では、サーバー側で異なるアイテムを連続して買う行動が一連のトランザクションとして処理されていたとしても、同様のことがありえます。 さて、ゲームでは、プレイヤーにとっては操作がやや面倒でも、デバッグの都合やメンテナンス等の都合で、あえてデジタル的な操作をしているゲームもあります。 たとえば昔のドラクエ3では、酒場で仲間をパーティに加入させる際、1人ずつ逐次的にコマンド入力をして加入させる必要がありました。（「3人まとめて加入」とかしたくでも、できない仕様。）ウィザードリィなどでも同様で、仲間のパーティ加入の編成などは、一人ずつ逐次的に操作する必要がありました。 このような、「まとめて〇〇を編集・編成」みたいな処理は、その分状態（取り得るケース）が増えるため、それに比例してデバッグにかかるコストが増える場合が有ります。 {{コラム|ゲームはゲーム以外の操作性を取り入れられるか？| ;家電とはゲームは操作性が異なる 上記のケーススタディの教訓としては、つまりデジタル家電（地デジ対応テレビやMP3プレイヤーなど）のような操作仕様ですら、ゲームには不適切な場合があります。（家電のハナシ）現実世界で機能に直接対応したボタンのある家電と、一方でゲーム中の選択肢だけしか（十字キーなどを介して選択してからでしか）押せないゲームとでは、操作の前提条件が異なるのです。 アナログ家電（アナログ放送テレビや銀塩カメラやラジカセなど）と、（デジタルコンテンツである）ゲームとでは操作性が異なるのはもちろんですが、デジタル家電ともゲームは操作性が異なることに、気をつける必要があります。 }} {{コラム|CGアルバム機能| アナログとはやや違いますが、例として、たとえばゲーム中に、CG閲覧機能として、プレイヤーがゲーム中でクリアしたイベントに関するCG閲覧機能などがある場合で、「アルバム機能」などの名前が付いている場合を考えましょう（2000年以降のノベルゲームなどで、よくある機能です）。 「アルバム」等の名前から、ついつい仕様の設計時には、実際の写真アルバム（物理）の操作性を真似したくなるかもしれません（つまり、「本の手触り」的な）。具体的には、電子書籍のようなUIを実装しようとか、思うかもしれません。 ですが、ゲームにおけるアルバム機能では、そういうことは無視して、単にCGの閲覧と検索のしやすさだけを考えたほうが、操作性とメンテナンス性もよくなるでしょう。 }} === 画面更新と速度との関係 === * 60 FPSは意外と遅い DXライブラリは、標準的な映像モニタでは、1秒間に60回のループ更新をします。 これは、一般的な映像モニターの画像の更新回数が60Hz、つまり映像モニタでは1秒間あたり60回の更新があるので、 プログラム側の更新回数もそれにあわせたものです。（これらのことを「60 FPS」などという。） このような、映像の更新の早さの度合いのことを'''フレームレート'''といいます。 さて、人間の計算速度と比べたら「1秒間に60回」は速いですが、しかしゲームとしては、必ずしも速くありませんので、そのギャップに気づかないとプログラマーは不安に「パソコンが処理落ちしてるのか？」と悩んでしまいます。 たとえば、アニメーションの表現などとして、キャタクター立ち絵が1ピクセル（1px）ずつ1回の画像更新で移動したとしましょう。 すると、1秒たっても60pxしか移動しません。RPGツクールの標準の画面サイズは横816px、縦624pxなので、つまり60pxの移動では、画面の10%にすら到達していません。なので、もっと早い速度で立ち絵を移動させたい場合、1回の更新で3pxや5pxあるいはそれ以上のピッチ間隔で画像を移動させる必要があります。 このことに気づかないと、立ち絵の高速移動のつもりで1pxずつ動かしても、画面の横幅の10%すら動いてないので、「まるで処理落ちでもしているのか」と錯覚しがちで不安になりますが、しかし1pxずつ動かした際に意外と遅く見えるのは正常な動作です。そういう速度計算での命令文だからです。 具体的にはどう悩むかと言うと、RPG制作の場合ならばマップチップの枚数が多いので「もしかしてマップチップの読み込み方が間違っていて処理落ちしているのか？」とか、あるいは「キャラ画像の周囲の透明処理による負担が重いのか？」とか色々と不安を思ってしまいますが、まったくの無関係です。 1更新あたりに1pxのピッチ速度とは、それだけ遅いのです。なので、1秒後に画面内でチョコっとしか動かなくても、1秒後に動き終わっていれば正常です。 さて、ついでの話題ですが、もしアクションゲームやシューティングゲームなどで、1更新あたり5pxや10pxといったピッチで攻撃対象の敵などが動いている場合を考えて見ましょう。 たとえば、もし移動中画面で、現在の瞬間の描画位置　から　次の瞬間の描画位置とのあいだの中間位置、つまりピッチの中間の場所に自キャラの放った攻撃などが当たったときの例を考えてみると、なかなか悩ましい問題でもあります。つまり、画面上ではピッチの中間の場所には映像が書かれていないのに、なのに、その場所に攻撃を食らう「当たり判定」が存在するからです。 実際、アクションゲームなどで、高速で動く敵の軌道上に攻撃を放ってみると、画面上にいない位置なのに、攻撃があたる場合もあります。 だからファミコン時代あるいはそれ以前のゲームセンター時代といった黎明期のシューティングゲームですら、高速で動く弾丸チップや機体チップなどの表現には、とても工夫しているのでしょう。 このように、キャラチップなどの画像を高速で動かすのは、思いのほか、調整事項が多くて大変です。なのでRPG制作の初心者は、あまり高速な描画表現には手を出さないほうが無難です（まずプログラミングの全体像を作る必要あるので）。 {{コラム|実写でもフレームレート問題はある| 実写の動画ですら、フレームレートの遅さに由来する違和感は生じます。実際、実写映画のDVDなどをコマ送りで見てみると、意外と動きが飛び飛びです。 人間は1秒間のあいだに、意外と多くの動きをしています。たとえば仮に、おやつのドーナツを食べる実写動画を例に考えてみると、1秒間のあいだに、まずドーナツに手を伸ばしたあとに、つまみあげて口元に持っていくぐらいの動作を、人間は1秒のあいだで平気でしています。もしアニメキャラだったら、ひょっとしたらドーナツ一噛みを始めているぐらいです。 このように1秒のあいだに多くの動作をするのに、たった60コマのフレームレートしか用意されていないのです。だからコマ送りで実写の動画を見ると、けっこう動きが飛び飛びで、まるでアニメを見ているかのような感覚です。たとえるならアメリカ製のアニメ映画は、日本アニメよりも1秒のコマ数が多く、日本アニメが1秒で8コマなのにアメリカ制アニメが1秒で24コマの違いはありますが、しかしアニメはしょせんアニメのような飛び飛びの動きです。実写の60フレームレートですら、アメリカ製アニメのたったの約2倍しかないフレームレートです。 また、半導体の性能向上は2010年以降は止まっていることなどを考えれば（「ムーアの法則」の破綻）、今後に市販の液晶モニターのフレームレートが飛躍的に上がる可能性は乏しいでしょう（説明の便宜上、液晶も「半導体」として扱った）。 さらにもし仮に製造業で技術革新が起きたとして、液晶モニターのフレームレートを飛躍的に十倍や百倍に向上させる新技術が出来たとしても、今度はハードディスク容量の問題があり、つまりフレームレートがもし10倍になったら、録画映像の容量バイト数も10倍になります。つまり、アニメや映画のブルーレイディスクなら、ディスク枚数が10倍になることを意味するし、これはつまりアニメなら作画枚数が10倍になるし、消費者にすればディスク購入費用も10倍ですし、生産者側からすれば予算も10倍なので投資リスクも10倍です。 このような技術的制約および経済的制約から、今後のフレームレートの向上の可能性はなかなか乏しいと考えざるを得ませんし、仮にフレームレート向上しても恩恵を受けられるのは実写やCGなどのようなアニメーターが手で作画しなくて済む分野の映像だけです。 }} === 万全のゲームシステムは無い === 少なくとも2D-RPGのゲームシステムやその実装に関する限り、処理が早くて操作性も良くてメンテナンスもしやすくて・・・のような究極万全なシステムやアルゴリズムは一切ありません。 たとえば操作性の分かりやすいアルゴリズムなら、おそらくはプレイヤーのさまざまな発想に対応するためにif文の分岐増えたり、あるいはグラフィカルに説明するために画像の制御が追加で多く必要になったりするなどして、そのぶん他の特性が悪化しますし、説明用グラフィックが増えれば処理速度の負担にもなります。 しかし現在のパソコンではファミコン時代よりも桁違いに多くのメモリ容量を扱えるようになり、CPU性能も桁違いに向上しました。よってゲームプログラミングでは基本、処理落ちをしない程度にまで処理速度に負担を掛けて犠牲にして、そのぶん操作性やグラフィック性やゲーム性やメンテナンス性などを向上させることになるでしょう。 だから実はファミコン風のドラクエ1のような簡素なプログラムでも、あれはあれで処理速度とメンテナンス性をもし最優先に目指すなら現在でも合理的な一形態なのです。 また、ドラクエ1的なアルゴリズムはメンテナンス性がよいので開発もしやすいし、開発時のデバッグもしやすいです。なので、私たちがRPGを手元でプログラミングして作る場合も、まず2D-RPGならドラクエ1～3のようなUIをまねたゲームを作ることになるでしょう。 ただし、真似るのはあくまでUIのみです。パスワードシステムのような、セーブ機能の発達した現在では不要なシステムを真似る必要はありません。「話す」コマンドとか「とびら」コマンドみたいに、現代では不要になったコマンドも不要でしょう。また、ドラクエのウィンドウ色は黒色ですが、しかし私たちにはデバッグの都合のためファイナルファンタジーや昔のツクールのような青色を基調としたウィンドウのほうがデバッグしやすいかもしれません。 だから初心者は、昔のRPGツクールっぽくアレンジしたドラクエ風UIを作ることになるでしょう。（ドラクエの難易度デザインやストーリー性などはプログラミングではないので、本ページでは言及しません。） == 製作の順序 == 本ページでは説明の都合上、RPGをモジュールごとに分割して説明しています。 たとえば、マップ関連のモジュール、戦闘関連のモジュール、装備関連のモジュール、のようにです、 しかし、実際のゲーム製作での開発順序は、少なくともRPGをVisual C++でゼロから作る場合においては、けっして、「マップモジュ－ルを完成させてから戦闘モジュール」のような順序には'''なりません'''。 そうではなく、まず自分が興味をもったモジュール（仮にマップモジュールとする）の初歩を作り始めたあと、とりあえず操作できて満足できるところまで作ったら、 次に関連する別モジュール（たとえば戦闘モジュール）を作る、というような順序です。 たとえば、すでにマップモジュールがあるなら、戦闘モジュールを作り始める際に、まずマップ画面上に固定敵を配置することで、 戦闘モジュールのテストをしやすくなります。 このように、すでに作ったモジュールの初歩を土台にして、別のモジュールの初歩を同様に作り始めます。 そして、まずRPGの基本システムを満足するところまで作ります。（シナリオ作成などは後回しになるでしょう。） マップシステム、戦闘システム、装備システム、道具システム、買い物システム、酒場システム、会話システム、・・・ など色々あるので、まず一通り、好きなシステムから順に、キリのいいところまで作りこんで、どんどんと次に作りたいシステムの開発に移行していき、 とりあえずゲーム全体の基本システムを構築していくことになるでしょう。 ;2周目 そして、一通り、満足するまで基本システムを作るのを1周したら、 次に2周目として、また、たとえばマップのシステムを作り始めます。 1周目のマップシステム製作では放置してた部分、たとえばキャラチップの歩行グラフィックなど絵が必要で放置してた部分の製作に取り掛かるとか（たとえば1周目では矢印の画像でゴマかしていたとする）、 そのように2周目では、1週目で放置していた部分の製作にとりかかるのです。たとえば、歩行グラフィックで前足を上げているポーズと、前足を着地させるポーズの切り替えプログラムとか、そういう1周目では面倒で放置していた部分に、2周目では取り掛かったりします。 このように、RPGの製作は、まるでラセン階段を昇るかのように、周回的に開発していくことになるでしょう。 企業などで作る場合はどうか知りませんが、少なくともVisual C++でゼロからRPGを作る場合はラセン階段でしょう。 RPGはモジュールがとても多いし、また相互に関連するモジュールも幾多もあるので、一度に各モジュールを作りきるのは不可能です。 だから、ラセン階段のように、開発を昇っていくことになります。 {{コラム|1=化学の学習に似ているかも|2= 余談ですが、理系の学問でも、1999年ごろは、化学（ケミストリー）の理系教養の学習法がラセン階段のような順序であると言われています。 たとえば理工書 [https://www.amazon.co.jp/%E5%8C%96%E5%AD%A6%E3%81%AE%E5%9F%BA%E7%A4%8E-%E5%8C%96%E5%AD%A6%E5%85%A5%E9%96%80%E3%82%B3%E3%83%BC%E3%82%B9-1-%E7%AB%B9%E5%86%85-%E6%95%AC%E4%BA%BA/dp/4000079816/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=2DKECS8MWBNZR&keywords=%E5%8C%96%E5%AD%A6+%E5%B2%A9%E6%B3%A2&qid=1641806771&s=books&sprefix=%E5%8C%96%E5%AD%A6%E5%85%A5+%E5%B2%A9%E6%B3%A2%2Cstripbooks%2C188&sr=1-1 『化学の基礎』 (化学入門コース 1) , 1996/4/17 ] などのシリーズ (化学入門コース) の巻頭の学習法ページにもラセン階段の絵が書いてあり、ラセン階段のイラストの絵の各所に対応する科目が描いてあったような気がします。 ただし、プログラミングは暗記科目ではないので、そこは手を動かしてプログラムを実際に構築していく必要があります。そういう点は、数学というか物理学というか。 }} == 共通カウントアップ機能 == RPGではシステム中にマップ画面モード、メニュー画面モード、戦闘画面モード、・・・など様々なモードがありますが、 DXライブラリを使っている場合にどのモードでも必ず使うことになる機能があり、それは自作タイマーのカウントアップです。 まず、DXライブラリでは1秒間に60ループするので、それを利用して1秒間に60回カウントアップする機能を作ります。 そして、そのカウンターを活用することで、たとえば、「zボタンを押してから40フレーム間（環境によっては約0.8秒くらい）は次のzボタンの入力を受けつけなくする」等のボタンをしばらく入力させなくする機能を作ります。 そうしないと、プレイヤーは1回だけzボタンを押したつもりでも、システム的には何十回もzボタンを連打したことになり、プレイヤーがうまくコマンド操作などを行えません。 また、コマンド操作などの他にも、マップ画面中でキャラクターがマップ1マスぶん動くスライドのアニメーションでも、カウンターが必要になります。 マップ画面の歩行グラフィックで「歩行カウンター」みたいな変数が必要になるでしょう。もしくは、歩行のキー入力に使った矢印キー用のカウンターを流用するなどの処置になるでしょう。 ともかく、このようなカウンター機能が必要なので、whileループ中での個別モードに分かれる前の共通部分のところに、カウントアップのコードを書くことになります。 「共通部分のところ」とはどこか具体的に言うと <syntaxhighlight lang="C"> while (1) { if (ProcessMessage() != 0) { // メッセージ処理 break;//ウィンドウの×ボタンが押されたらループを抜ける } if (CheckHitKey(KEY_INPUT_ESCAPE) == 1) { break; } ClearDrawScreen(); // ここにカウントアップ機能 </syntaxhighlight> のように、whileの開始のテンプレ文の直後に書き始めることになるでしょう。 なお、DXライブラリでよく書くことになる開始時のテンプレ文については 『[[ゲームプログラミング/画面出力#DXライブラリのコード初期設定]]』 で説明してある。 カウントアップではなくカウントダウンでも構いません。 イメージ的には、下記コードのような感じになります。ただし、下記のモジュールだけでは動きません。 あらかじめ、各モード側でzボタンを押した時などにカウンター値の設定などを行う必要があります。たとえばzボタンを押したときに nyuuryokuMatiZ =60; // デバッグしやすいように少し遅めにした などをセットしておきます。また、zキー入力可能かどうかを判定するフラグ変数、下記コードでは変数 keyEnableZ となっていますが、そのようなフラグ変数をあらかじめ用意しておき、もし値が1なら入力可能、0なら入力不可能として、 zボタンに対応する処理を1回実行してから<code>z=0;</code>に設定して、zが0のときにカウンタが動くようにする必要があります。（ツクールなどではマップ画面からメニュー画面を開くのはx（エックス）ボタンだが、読者のバツボタンとの混同を防ぐため、上記の文ではzボタンを例に説明した。） <syntaxhighlight lang="C"> while (1) { if (ProcessMessage() != 0) { // メッセージ処理 break;//ウィンドウの×ボタンが押されたらループを抜ける } if (CheckHitKey(KEY_INPUT_ESCAPE) == 1) { break; } ClearDrawScreen(); // ここからカウントダウン機能 // zボタン用のカウントダウン if (keyEnableZ == 0 && nyuuryokuMatiZ > 0) { nyuuryokuMatiZ = nyuuryokuMatiZ - 1; } // zカウンタが0以下に到達したらzキーが再入力可能 if (nyuuryokuMatiZ <= 0) { nyuuryokuMatiZ = 0; keyEnableZ = 1; } // 下記はエックスボタンのこと。 バツボタンではない。 // xボタン用のカウントダウン if (nyuuryokuMatiX > 0) { nyuuryokuMatiX = nyuuryokuMatiX - 1; } if (nyuuryokuMatiX <= 0) { nyuuryokuMatiX = 0; keyEnableX = 1; } // 長いので、あとは省略 </syntaxhighlight> このコード例のように、共通カウンタ部では単にカウントするだけでなく、さらにカウンタが目標値（カウントダウン方式なら0が目標値）に到達したときの処理（フラグの設定など）も行います。 いきなり上記のような機能を作るのは、かなり難しいです。なぜなら、カウンタだけでなく、マップ画面やメニュー画面側のzボタン押し時やxボタン押し時の命令も記述しないといけないからです。 だからまずは、マップ画面とメニュー画面の入り口画面（まだメニュー画面の各コマンドは作らなくていい）だけでいいので、でキーのカウント処理をうまく行えるようにしましょう。 なお、メニュー画面に移ったらキャンセルボタンで戻せるように、あらかじめメニュー画面にキャンセル機能を実装しておきましょう。 新しい画面を作るときに最初に必要なボタン機能は、実はキャンセル機能です。キャンセル機能が無いと操作不能になって、いちいちアプリ再起動の手間が生じます。 ;アクションゲームで肩慣らし いきなりマップ画面やメニュー画面を作るのは難しいので、ひとつの手として、RPGを作る前に、簡易的なアクションゲームのような操作性のプログラム、または簡易シューーティングゲームの操作性のようなプログラムを作るのも手です。 たとえば、スーパーマリオやスト2のようなアクションゲームなら、ジャンプボタンは1回入力したら着地までは再入力の受付が禁止なので、上記のようなカウンタ処理による再入力可否の制御が実験できます。 べつに、本格的にアクションゲームやシューティングゲームを作る必要はないです。後述のように、異なるジャンルのゲームをひとつのアプリに同梱するのは、管理の手間が増えますので（不可能ではないですが）、面倒が生じます。 これには準備として、マリオ（キャラ名）やスト2リュウに相当する自キャラ表示のため、あらかじめキャラチップの絵が必要です。別にアクションゲームを作るわけではないので、マウスでいいので何かキャラの全身絵を3分くらいで雑に書いてください。そして、キャラの周囲の空白部を、ドットエディタなどを使って透過させてください。（あるいはinkscapeを使ってキャラ絵を書いて、PNGエクスポートする、などの手法もあります。） ジャンプさえ出来る絵であればいいので、すでに手元にゲーム用キャラチップっぽい大きさの生き物の絵があるなら、別に人物の絵である必要もなく、動物の絵でもモンスター画でも何でも構いません。 さて、なんとかジャンプの実験に成功したら、ついつい次の目標で「右歩行中にジャンプして右斜め上に飛ぶ」機能とかを実装したくなりますが、本ページはRPGの教科書なので、アクション機能については説明を省略します。 ;ミニゲーム同梱時のカウンタ管理 ミニゲームとしてターン制RPG以外のジャンルのゲームを同梱するなら（たとえばシューティングなど。ファミコン『さんまの名探偵』では推理ゲーム中、シューティングゲームのミニゲームがあった）、別途、そのミニゲーム用の各モード前の共通部分に、ミニゲーム用のカウンタが必要になるかもしれません。 ターン制RPGとアクショゲーム・シューティングゲームは、カウンターに要求される待機時間が違ってくることと（ターン制RPGの操作はゆっくりめでいいので待機時間を多目にとれるが、しかしアクションは機敏な動作に対応するため待機時間が短い）、カウンタが目標値に到達したときの処理がRPGとアクションとで違うので（たとえばRPGなら決定ボタンを押したままの状態なら目標値の直後に受け付けしてもいいが、アクションゲームでは決定ボタンがジャンプやパンチに対応していることから、プレイヤーにパンチ連打などのためにボタン連打させたい場合は目標値直後の処理を変える必要があることなどから）、RPGとアクションを混在させるのは（可能ではあるが）難しいことが予想できます。 だから、もしあるゲーム中に別ジャンルのミニゲームを同梱するなら、メインとなるホスト側のジャンルを決めて、そのメインジャンルのカウンタだけをwhileループの冒頭でカウントアップすると安全かと思います。たとえば本ページはRPGなので、メインのジャンルはRPGなのでwhileループの序盤ではRPG用のカウンタだけをカウントアップ、という事になるでしょう。シューティングについては、while冒頭ではカウントアップしないか、あるいはRPG用のカウンタの流用で済ますかどのちらかです。 もしwhileループの冒頭でシューティング用のカウンタまで記述してしまうと、コードの管理が複雑になってしまうので、避けたほうが安全でしょう。 普段は使わないミニゲームのカウンタのせいで、普段から使うメインジャンル（本ページではRPG）のカウンタの可読性が下がるのは避けたいです。 RPG用のカウンタをシューティングに流用するのは、シューティング用にコードが最適化されてないので軽量性が若干は下がりアプリが重くなりますが、しかしゲーム制作ツールのRPGツクールやウディタなどで製作されたアクションゲームやシューティングゲームなどは、こういった流用の一種でしょう。 == アイテム関係 == === アイテムの定義 === * [[ゲームプログラミング/RPG/アイテム定義]] === アイテム表示 === * [[ゲームプログラミング/RPG/アイテム表示]] アイテム表示における、上詰めの自動化などを解説しています。 == 設計方針 == ==== ゲーム全体を先に作る ==== ともかく、ゲーム全体を先に作るのが先決です。ニュアンスは違いますがアトラス社いわく（ゲーム開発では）「ゲーム全体に全体に値を回すのが先」という格言があります<ref>[https://news.denfaminicogamer.jp/projectbook/191030a/2 『【ゲームの企画書】『ペルソナ3』を築き上げたのは反骨心とリスペクトだった。赤い企画書のもとに集った“愚連隊”がシリーズを生まれ変わらせるまで【橋野桂インタビュー】』2019年10月30日 11:30] 2020年12月1日に閲覧して確認.</ref>。 プレイヤーが見たいのは、ゲーム全体のストーリーやテンポといったゲームの全体像です。カーソルの動きとかウィンドウの動きとかは、あくまで補助的であり、そういったUIに対するプレイヤーの興味も、あくまでオマケの範囲でしかないのです。 ==== 似た機能を複製する場合 ==== ===== 複製前の確認事項 ===== ;短さよりも可読性を重視せよ 世の中には、残念ながら時々、他人の理解しやすさを無視して、やたらと短いコードを書く、独りよがりな人がいます。 しかし、たとえ仕事としての集団作業であっても、要求されるのは、同僚や後輩などが読んだときの分かりやすさです（「可読性」と言います）。 なので、少しぐらいコードが長くなってもいいので、分かり易いコードを書きましょう。 具体的には、できるだけ、どこの入門書にもあるような基本的な機能を使ってコードするのが安全です。具体的には、できるだけ、せいぜい構造体（およびC++ならクラスの構造体的な使い方）や配列や関数あたりまで、の機能どまりです。 また、「どうしても」と言った必要性のない限り、その分野の一般の入門書に書かれてない機能（たとえばメモリ管理の組込み関数など）や、解説の極端に乏しい機能は（入門書なっても巻末の機能一覧にだけしか記載のないような機能）、利用を控えましょう。 そもそも、一般入門書に書かれてない機能は、取扱いが難しかったりして、設定などの確認不足で使うとむしろバグの原因になりやすかったりとか、学習コストの高さなどの難しさがあるから、入門書から除外されているのです。なのに、そういう難解な機能を多用するのは、あまりよくプログラミングの仕事が分かってない自称プロかと思われても仕方ありません。 ;ゲームとして実態のある関数や配列を作れ 関数や配列をつくるときは、なるべく、ゲーム用語で説明できる関数および配列だけを作りましょう。たとえば「戦闘コマンド選択関数」や「モンスターデータベース配列」のような感じです。 けっして、そういうゲーム用語とは無関係に、単に抽象的に関数を呼び出す関数を呼び出すような関数を呼び出す関数、とか、配列を読む込む配列を読む込むような配列、のような高階層的な機能は、たとえそれでコードが短くなっても、同僚や後輩などが管理をしづらくなるので、避けましょう。 :というか、そういう無意味な抽象化を避けないと、あなたが会社から避けられるでしょう。（これはゲームに限らず、数学以外の物理学や化学で扱う数式も同様で、たとえば理系大学の論文指導やゼミなどで、なるべく物理的な実態や化学的な実態に対応のある立式をするように、よく大学の卒業研究では要求されています。具体的には、「質量（mass）を表す文字式には m を使え」（高校レベルですが）みたいに既存の慣習に合わせるように指導されます。たとえ数学的には矛盾のない立式でも、物理学の研究室なのに「質量に記号 a 、速度に記号 b 」みたいな書き方をする学生は、教授から学生がダメ出しをされます。） IT業界だけなく法律業界でも、むやみに高階層的な法令を設計するとその法令の構造が複雑になる現象は知られています[https://www.nature.com/articles/s41598-020-73623-x Daniel Martin Katz, Corinna Coupette, Janis Beckedorf & Dirk Hartung "Complex societies and the growth of the law" , nature.com, Published: 30 October 2020 ]。近年、世界各国でIT的な考え方を使って法律の設計論を研究しようという学問分野があり、その学問でそう指摘されています。これらのIT的な法学では、法律中の単語数、階層数、法律間の相互引用数が多ければ多いほど、その法律の構造は複雑になると考えられています。ご参考に。 もちろん、関数から関数を呼び出してもいい場合もあり、たとえば「RPGで戦闘モードの関数から、攻撃コマンド関数を呼び出す関数から、さらに攻撃対象の選択をする関数を記述する」といったようなゲーム仕様に直接的に結びついた関数ならば、普通のゲーマーなら理解できるので、書いても平気でしょう。ですが、それはゲームとしての実態に対応する共通化です。けっして、ゲームの実態に無関係の共通化ではありません。 ;仕様そのものの類似性に気を配れ また、ゲーム中で、仕様ではあまり類似性のない処理は、たとえ偶然的にコードの実装が似ていても、むやみに共通化して同じ関数にしたり配列にしたりするのは避けましょう。なぜなら他人（後輩など）が管理しづらいからです。 もちろん、共通化してもいい場合もあり、たとえば「回復アイテムによる回復対象を選ぶ関数」などは、 :たとえば戦闘モードでの「RPGで戦闘モードの関数から、（攻撃コマンドではなく）道具コマンド関数を呼び出す関数から、回復アイテムを選んだ時に、回復対象の味方キャラを選択をする関数を記述する」と、 :マップメニューモードでの「マップメニュー画面モードの関数から呼び出す、道具コマンドの関数で、回復アイテムを選んだ際に、道具の使用対象を選ぶ関数」 が、ともに仕様が「回復アイテムを選んだ時の使用対象の味方を選ぶ」と似ているので、場合によっては共通化するのも良いかもしれません（職場によるだろう。共通化しないほうが良い場合もある。たとえば戦闘モードでは敵にも回復アイテムを使えるゲームも存在する一方、マップメニュー画面では味方にしか回復アイテムを使えないので細部が異なるから）。 しかし、仕様自体すらも似ていない部分を共通化するのは、ダメでしょう。 たとえば、もしたまたま、「戦闘モードでのコマンド選択時の関数」（まだ道具コマンドを入力する前なので、どのアイテムを使うからすら選んでいない段階）と、「マップメニュー画面モードで道具コマンドのあとに使用対象キャラを選ぶときの関数」が、もし偶然にコードが似ていたとしても、そういう仕様的にあまり関連性の無いコードは共通化されても管理しづらくなるので、共通化するのをやめましょう。 ===== 具体的手順 ===== まず、それらの機能の共通点を探します。次に、その共通点を抽象化します。抽象化のコストと、それを再テストするコストの合計が、そのままにしておくコストよりも高く付くと考えられるならば、抽象化は後回しにしても構いません。 {{コラム|テキスト比較ツール| テキスト比較ツールを使うと、効率的に違う部分を強調して表示することができます。 GNUのdiffutils、[[Git]]などのバージョン管理システム、あるいは「ベクター」や「窓の杜」からインストールすることができます。 }} == リファクタリング == * [[ゲームプログラミング/RPG/リファクタリング]] == モードの管理手法について == * [[ゲームプログラミング/モード管理]] 戦闘モードとか、マップ画面モードとか、メニューモードとか、そういうののハナシです。とりあえず「モード」と言いましたが、ゲーム業界で何と言うのか知りません。もしかしたら、モードではなく「戦闘シーン」とか「戦闘パート」とか言うのかもしれません。ただし、書籍『ゲームプランとデザインの教科書』が、架空のスマホゲーム企画書で「モード」という言葉を使っています。「移動先指定モード」とか<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.255</ref>。 == 2Dマップ == === マップのアルゴリズム === 方針だけ述べる。具体的なコードは、上手い人のコードを参考にしよう（コードがけっこう長くなり、紹介がメンドウくさい）。 2Dマップがあると、俄然、RPGっぽく見えるようになって、ヤル気が出るので、さあ作ろう。 マップのデータは、ふつう、2次元配列で書く。 まず、グローバル領域で、たとえば <syntaxhighlight lang="c"> static int maptable[10][10] = { { 0,0,0,0,0,0,0,0,0,0 }, //0 y { 0,0,0,0,0,0,0,0,0,0 }, //1 { 0,0,0,0,0,0,0,0,0,0 }, //2 { 0,0,0,0,0,0,0,0,0,0 }, //3 { 0,0,0,0,0,0,0,0,0,0 }, //4 { 0,0,0,0,0,0,0,0,0,0 }, //5 { 0,0,0,0,0,0,0,0,0,0 } //6 }; </syntaxhighlight> のように、とりあえず配列を確保しよう。 ここで重要なのは、 確保した配列のタテとヨコは、ヨコの並びをx方向として、タテの並びをy方向としたとき、 <code> maptable[y][x] </code> のように確保されていることに注意する。 さて、各配列に「0」を入れても、はたして0番が何を意味するか、まだ何も決めていない。 ゲームにもよるが、とりあえず、何もマップチップを上書きしない領域だと定義しよう。 背景色と同じ色のベタ塗りのマップチップを作っておけば、それで上書きすれば、あたかも何も上書きしてないように見える。 いちいちif文などで、何も上書きしないように場合わけをするのもメンドウであるので、どっちの方式にするか、決めておこう。 さて、マップ用の配列は、作成したいマップで最低限必要なマス目よりも、やや大きめの領域を確保しておく必要がある。 たとえば、5×5のマップを作りたいなら、配列ではもっと大目に、たとえば 8×7 とか確保しておく必要がある。 もし、なんらかのバグで確保されていない領域を呼び出してしまうと、プログラムがエラーで異常停止してしまう。 たとえば、一番左端をもしx＝0とした場合、もしこの場所に主人公がいると、さらにプレイヤーが「左端に行こう」と考えて、左ボタンを押したときに、エラーで異常停止してしまう。 こういう停止はメンドウくさいので、だったら念のため、最初から、マップを移動可能な場所よりも何マスか大目に確保しておくと安全である。 さて、まだ配列を確保しただけなので、「0」が何かとか、「1」が何かとか、まったく定義していない。 とりあえず、 :0番は、進入不可能の暗闇。 :1番は、床とか、草原とか平地とか、とにかく歩ける場所 としよう。 だと思ってればイイ。 たとえば、もし配列 maptable の宣言が、 <syntaxhighlight lang="c"> static int maptable[10][10] = { { 0,0,0,0,0,0,0,0,0,0 }, //0 y { 0,0,1,1,1,1,1,1,0,0 }, //1 { 0,0,1,1,1,1,1,1,0,0 }, //2 { 0,0,1,1,1,1,1,1,0,0 }, //3 { 0,0,1,1,1,1,1,1,0,0 }, //4 { 0,0,0,0,0,0,0,0,0,0 }, //5 { 0,0,0,0,0,0,0,0,0,0 } //6 }; </syntaxhighlight> のような宣言だったら、このマップでは真ん中のほうに4マス×5マスの移動可能な地帯がある。 その周囲は移動不可能になっている。 ともかく、このように、プログラマーは、まず、何番のマップチップが何を現すかということを、脳内で設計しておく必要がある。 配列の範囲外の読み込みエラー防止のためも兼ねて、0番は、すべてのゲームキャラが進入禁止としておくのは安全だろう。 あとはもう、win32 API などの機能を使って、マップチップの画像を配列にもとづいて各マスごとに表示すればいい。 前提として、まずマップチップ画像の読み込みを行う必要がある。あるいは、画像をあらかじめ実行ファイルに組み込んでおく必要がある。 画像の実行ファイルへの組み込みは、Visual C++ にそういう機能があるので、それを使えばいい。 画像を読み込みたいなら、ゲーム起動時にでも読み込んでおけばいい。 イメージ的にコードの雰囲気（ふんいき）を書くと、たとえば <code>case WM_PAINT:</code> の節に、下記のように for文などを使って画像ハンドらに画像を代入するコードを裏画面に書いていき、最後にまとめて本画面に描画することになる。（「裏画面」とか「ダブルバッファリング」と言われるテクニックを使います。詳しくはネット検索して調べてください。） ;（イメージ） ::(※ あくまでイメージです。このままでは、動きません。) <syntaxhighlight lang="c"> int iTemp; for (x_map = 0; x_map <= 9; ++x_map) { for (y_map = 0; y_map <= 6; ++y_map) { iTemp = maptable[y_map][x_map]; // 配列の文字が長いので、いったんiに置き換え hbmp = hbmp_mapchip_list[iTemp].hbmp_mapchip; SelectObject(hMdc, hbmp); BitBlt(hbackDC, 225 + x_map * 32, 140 + y_map * 32, 32, 32, hMdc, 0, 0, SRCCOPY); // DeleteDC(hMdc); // これを入れると、マップが表示されない。 } } // 裏画面から本画面に転送 BitBlt(hdc, 0, 0, 700, 500, hbackDC, 0, 0, SRCCOPY); hbmp = NULL; // 初期化。 // 中間ハンドルからhbmpを解除 SelectObject(hMdc, NULL); SelectObject(hbackDC, NULL); // 不要になった中間物を削除 DeleteDC(hbackDC); DeleteDC(hMdc); DeleteObject(hbmp); } </syntaxhighlight> SelectObject や BitBlt は、Win32 API の専用の関数なので、分からなければ読者で調べてください。 なお、マップチップ画像そのものの作成は、単にWindowsアクセサリ『ペイント』などの画像作成アプリでビットマップ画像を用意すればいい。 ツクールやウディタなどだと、いくつかのマップチップをまとめた「タイルセット」などを取り扱うが、実はプログラミング的には、わざわざタイルセットを作らなくても、マップチップ1個ずつを読みとりすることも可能である（単にwin32APIのビットマップ画像の読みとりの機能を使えばいい）。 （win32 API の初期設定のままではビットマップしか表示できないハズ。PNGなどを使いたいなら、GDI+の設定を行うこと。GDI+については説明を省略。）。 なお、マップチップのサイズの規格は、よくある規格は16ピクセルの倍数で、「px」をピクセル単位の意味として16px×16pxまたは32px×32pxまたは64px×64pxのマップチップ規格がよくある（ツクールやウディタのマップチップのサイズ規格も、この系統）。 とりあえず、私たちにとって作るのがラクなのは、小さいほうが作成がラクなので、とりあえず16×16のマップチップを作ろう。 プログラム技術としてはマップ表示は単なる二次元配列なので難しいことは無い。しかし、その他の準備が忙しく、たとえばマップチップ用のビットマップを用意したりとか、あるいはキーボード操作のプログラムを作ったりとか、そういう準備が難しい。 これだけだと、まだマップを表示しただけなので、さらに主人公キャラのキャラチップとか、主人公がx＝何マス目、y＝何マス目にいるかの変数とかも宣言する必要がある。 主人公チップを移動させる際、ドラクエ1みたいに1ピクセルずつ動かしたいと思うだろうが（実際は何ピクセルかしらないが）、しかしそれは難しい。まずは、十字ボタンを押したら、その方向にいきなり隣のマスに動く仕組みをつくろう。 しかし、これすら、また難しい。 win32APIなら、ボタンを押して話す動作で1回の入力と判断してくれる。 なので、win32APIで隣マス移動の仕組みを作るのは、比較的にラクである。 しかしDXライブラリの場合、1瞬だけボタンを押しただけでも、何十回も入力があると判断され、 いっきに壁際のマスまで動いてしまう。 なのでDXライブラリのマップ移動の作成の場合、まずはタイマー系の関数を利用し、一定時間のボタンの押し続けがあって初めて「入力された」と判定すうプログラムが追加になる。 なお、win32APIでも別のシーン（たとえば戦闘モードでのコマンド決定後の自動処理など）でタイマー自作が必要になるので、どちらにせよラクではない。 最終的には、21世紀的な一般的なゲームを作りたいなら、（win32APIではなく）DXライブラリで作るのがラクである。 （ただし本セクションでは説明のしやすさの都合から、win32APIで説明した。） もし、ドラクエ風に1ピクセル（ないし数ピクセル）ずつアニメーション的に動かしたいなら、DXライブラリがほぼ必須であり（原理的にはwindowsAPIでも出来るが、しかしwindowAPIでのアニメーション表現はとても手間が多く難しく、強く薦めない。）、DXライブラリで開発しているRPGコードに、タイマー計算するコードと組み合わせて、下記イメージのようになる。 ;（イメージ） ::(※ あくまでイメージです。このままでは、動きません。) <syntaxhighlight lang="c"> if (moving == 1 && nyuuryokuMatiLR > 0) { // nyuuryokumati は「入力待ち」時間の意味 nyuuryokuMatiLR = nyuuryokuMatiLR - 1; // タイマーとして流用 } // 移動の終了処理 if (hero1_direction == rightward && moving == 1 && nyuuryokuMatiLR <= 0) { keyEnableRight = 1; // moving 回復までに時間が掛かるので、ここは1に。 nyuuryokuMatiLR = waitTime1; nyuuryokuMatiLeft = waitTime1; nyuuryokuMatiRight = waitTime1; xPosi++; // 右へ1マスだけ移動 moving = 0; townFlag = 0; } } // 右移動 </syntaxhighlight> // nyuuryokumati は「入力待ち」時間の意味 上記コードの仕組みは割とひどく、マップ移動中の特定の左右方向用のタイマーを、今後の戦闘モードなど他のすべてのタイマーと流用するという、ひどいコードである。 ナナメ移動にも対応したりを考える場合、左右（LR）方向と上下（UpDown）方向のキーボード入力を別々の変数として処理する必要があったりと、割と面倒くさい。 移動先が移動可能でないカベや川なのに移動できたらおかしいので（ドラクエだと川は移動不能。『信長の野望』での渡河とか野暮にツッコまないこと。）、 事前にそういう移動可能判定を色々とクリアしたら、移動中モードとしてmovingが1になるようにしているコードである（長くなるので上記コードでは省略した）。 キーボード入力の判定は、事前のmoving側の判定計算ですでに行っているので、上記コードでは省かれている。実際にはさらに、下記コードのようなキーボード入力判定プログラムが、上記コードの直前あたりに付け足される必要がある。 <syntaxhighlight lang="c"> // 移動先予定地の入場可否の判定 if (CheckHitKey(KEY_INPUT_RIGHT) == 1 && keyEnableRight == 1 && moving == 0) { if (map1table[yPosi][xPosi + 1] == 1) { destMovable = 0; } if (map1table[yPosi][xPosi + 1] == 0) { destMovable = 1; } // 入場可能ならフラグ設定 if (destMovable == 1) { // destとは目的地点 destination の略。 moving = 1; hero1_direction = rightward; keyEnableRight = 0; nyuuryokuMatiLR = waitTime1; } } </syntaxhighlight> いったん移動し終わったら、もはや移動中ではないので、再度movingをゼロに戻し、また移動可能判定を調べなおす、という手間になる。 マップ移動だけでも、こんな手間になる。 だから、市販の『中学生でも分かるゲームプログラミング』的な題名の本でこういう手間が無いのは、 それはその市販本の著者が、初心者が苦手感を抱かないように独自のライブラリなどで上記のような手間をライブラリ側に隠蔽する工夫などをしてるだけにすぎない。 ネットに出回るデマの、「RPG風のUIをつくるのは簡単」というのは、つくづくウソである。ドラクエ1風のUIですら、なかなか面倒である。 （『中学生でも分かるゲームプログラミング』的な本の手間だけでドラクエ1風UIが作れると思ってる、本を読んだだけの知ったかぶりが、ゲームプログラミング経験者ヅラしているということであろう。） === マップレイヤー画像について === * [[ゲームプログラミング/画面出力#RPGのマップレイヤー]] === 歩行グラフィック === ゲームにおけるキャラチップの歩行アニメーションの作画の定石は、テレビアニメの歩行の作画の定石とは、まったく違います。 説明の単純化のため、右向きの歩行を例に説明します。 ==== 3枚歩き ==== まず、ツクール水準の2D-RPGの歩行グラフィックではなんと、歩き始めの作画の立ちポーズのドット絵と、横向き時にプレイヤーから見てキャラ歩行中における右足と左足とが重なっているドット絵（便宜上「中ポーズ」と呼ぶとする）が、なんと同じドット絵です（テレビアニメ作画の常識とは大きく異なる）。 つまり2Dゲームのドット絵では、歩き始めと歩き中の中ポースとに、区別がないのです。 これは、実際にキャラチップのタイルと、キャラのゲーム中での歩行動画を録画して見比べると分かります。 テレビアニメ産業では、歩きお よび 走りの作画は、基本的になるべく滑らかに見せるために、6枚の絵を使います。 だからアニメ業界では「6枚歩き」とか「6枚走り」とか言います。 しかしゲームは違います。上記の言い方に習うなら、ゲームは「3枚歩き」です。「3枚歩き」というのは別にゲーム業界の用語ではなく、テレビアニメ業界での数え方をそのままゲーム業界に置き換えただけの本wikiでの独自的な呼び方です。 しかもゲームのドット絵では、走りと歩きの区別がありません。つまり、歩きのドット絵を、走りのドット絵でも使いまわします。 つまりゲームではドット絵だけなら 「3枚歩き」=「3枚走り」 でもあります。 ドット絵のゲームにおける走りと歩きの区別は単に、キャラチップのスライドさせる早さを切り替えることで区別しているだけです。 なお、テレビアニメ産業などでは、正面向きかつ走りシーン（ゲームにおける下キー入力時に相当）なら例外的に（6枚ではなく）4枚作画でも走りを描けることが知られています。なぜこれが通用するかというと、よく分析で言われるのは、6枚でなく4枚だと滑らかさはなくなりますが、しかし歩きではなく走りであるので動きに少々のギャップがあっても勢いがむしろ強調されるという点と、また6枚時の中ポーズのシルエットと4枚時の中ポーズノシルエットがあまり変わらないという点があるため、テレビアニメ業界では正面走りだけ「4枚走り」でも可能なのです。 しかしゲーム産業では正面向きでないのに、右向き左向き前向き後ろ向きすべてで、なんと「3枚歩き走り」なのです。ドット絵のゲームではキャラチップが小さいので、なんと3枚で歩きも走りも表現できてしまうのです。 このように、ゲームとアニメとでアニメーションの常識が大幅に異なります。 しかし、両業界でも一致している作画の風習もあり、それは歩行中グラでの頭の高さの上下運動です。 アニメ作画の頭の上下運動を文字だけで説明するのは難しいので、興味ある読者は外部サイトでアニメーターの作画教育サイトを見るなり、あるいは同人フリーゲーム用の公開キャラチップ素材などを実際に目で見るなどして、読者ご自身で研究してください。 ともかく、3枚で右向きの歩行を表現できます。RPGでは上下左右の4方向が必要なので、最低でも3×4 = 12枚 の絵画必要です。 なお、斜め歩行が加わると、2倍になるので必要枚数は合計24枚になります。 ;思考回路の切り替え もし、外部のゲーム用フリードット素材を使わずに「ゲームエンジンを一人で作る」というなら、上述のようなアニメ産業とゲーム産業での作画のギャップも知って絵を描く必要が生じるでしょう。頭の切り替えが必要になります。 今までプログラマー脳だったのを、ドット絵を描くのに絵描き脳に切り替える必要があって、しかも既存のテレビアニメ作画理論はそのままでは使えないので、ゲーム用に人気作のドット絵のグラフィックを研究しなおす必要が生じるのです。 ==== チップ作画の留意点 ==== ===== 3枚歩き ===== また、絵1枚ごとのRPGのキャラチップの作画も、テレビアニメとは違います。 まず、2D-RPGでは、前後向きのキャラチップの横幅のサイズ規格と、左右向きの横幅のサイズ規格が、RPGでは同じです。 しかし、テレビアニメでは、このような横幅はありえないのです。 なぜなら、人間が歩いていて左右の腕をふっていて前に突き出た状態の手先から胴体までの距離は、胴体の厚さに比べると、（手～胴体 の距離は）かなり長いです。 しかし、こういったリアルな腕の寸法に忠実に書くと、サイズ規格の横幅をオーバーしてしまい、少なくとも腕の片方の先がチップ外にハミ出てしまいます。 だから、進行方向側の腕だけは、2D-RPGキャラチップではあまり伸びていないです。 なお、進行中の胴体はやや進行方向に寄っています。これはリアルな人体がそうだからでしょう。 なので、もはや進行方向側の腕には、伸ばすだけの余裕がありません。 だから、進行方向側の腕を折り曲げる場合すらも存在します。または、進行方向側の腕だけ短くゴマかすなどしている場合もあります。 これは別に2010年以降の流行でなく、既に1980年代の商業ゲームでもファミコンのドラクエ3の勇者の母親のキャラチップも、実は進行方側に腕を伸ばしたときは、腕を折り曲げています。 なお、ドラクエ3の主人公である勇者は、剣を持っているので、利き腕の右手がもとから折り曲がっており、よく分かりません。 また利き腕の表現のためドラクエ3では、右向きと左向きのキャラチップを、けっして反転処理でゴマかさずに、きちんとポーズを書き分けています。 ともかく、一般にRPGの歩行キャラチップでは、進行方向の腕があまり伸びてないので、バランスを取るためにRPGでは、進行方向の反対側の手足を、目いっぱい、伸ばしています。 これはリアルで考えるとありえないし、テレビアニメでもありえない作画です。 ですが、ゲーム産業の2D-RPGでは、昔からこういう作画がよく行われています。 ;歩きの滑り 2D-RPGの歩行ではキャラは地面を滑ります。横向きグラフィックだと、比較的に確認しやすいでしょう。 テレビアニメだと、キャラが滑っているように見えなくさせるためもあってか6枚も使って作画する一方、 2Dゲームでは正反対であり、2D-RPGゲームでは「滑り上等!」な態度の作画です。 走りシーンだったら、「まるで滑っている」かのように高速で走っている身軽なキャラのようにも見えるのですが（実は、実際に足の作画が滑っているだけ）、 2D-RPGでは歩きですら滑りある作画です。 「3枚歩き」で描く以上、こういうリアリティを無視した作画ですので、あまり他のリアリティにこだわっても仕方ありません。 {{コラム|デッサン的なこと| ;後頭部は意外と大きい なお、横向きの顔で、後頭部の髪のある部分の大きさが、顔前面の髪のない部分の大きさと同じくらい囲う東部のほうが大きいのは、 これは現実のデッサンと同じです。後頭部は意外と大きいのです。 例としてアニメ『新世紀エヴァンゲリオン』の主人公・碇シンジの後頭部の大きさが、顔と同じくらいなのは、別にけっして「親父の碇ゲンドウが天才科学者だから息子シンジも遺伝で脳が大きくて後頭部も大きい」とかではなく、もともと人間の後頭部というのはあのくらいの大きさなのです。 ;上マツゲは頭の中間位置ぐらい また、目より上の頭の頂上までの大きさが、アゴから上マツゲまでの長さと同じくらいなのも、これは現実と同じです。 つまり、上マツゲは、頭の中間くらいの位置です。 ついつい、髪の毛の生え際の位置につられて、目より上の頭部の大きさを小さく認識してしまいますが、それは錯覚です。実は、目より上の部分の長さは、意外と長いのです。 また、ゲームの場合、45°上の角度から見下ろしているので、すると後頭部が少し見えることも意識すると、もうすこし長く書いても構わないのかもしれませんが、しかしチップのサイズ規格に上限があるので、あまり頭部を伸ばすこともできません。 }} ===== 初心者の抱きそうな疑問 ===== ;キャラチップの横幅を大きくしたら? 標準的なキャラチップの前側の腕は折りたたまれています。原理的には、キャラチップの横幅を長くすれば、横向き歩きのゲーム作画において、リアルの作画や、テレビアニメの作画に近づけることはできます。 ですがそれをすると、キャラチップがそのぶん大きくなってしまい、そのせいでチップタイルの横幅が大きくなってしまいます。 正確には計算していませんが、少なくとも2.5倍くらいは横幅が長くなると思います。斜め移動も含みで考えると、通常のツクールなどのチップタイルはやや横長なのに、さらにそれを2.5倍に長くするのは、やや編集時に見づらいかもしれません。 ドット絵のキャラチップという小さくて見づらい絵の、さらに「腕」という2ドット（枠線まで含めると4ドット）くらいしかない部分に対して、そこまでする必要あるのか、意義が不明です。 このように、ゲーム演出の特有の事情もあります。 :プログラム側の事情 また、もしキャラチップの横幅の規格だけ長くすると、マップチップの横幅の規格と、食い違いが出てきます。このため、プログラムがやや難しくなります。 なるべくキャラチップ横幅とマップチップ横幅の規格の長さが近いほうが、プログラムは楽になります。 このように、プログラミング側の事情もあります。 ===== どうしてもリアルにアニメしたい場合 ===== ;どうしても腕振りをリアルに近づけたいなら それでも、どうしても腕の振りをリアルやテレビアニメに近づけたいなら、 キャラチップのサイズ規格を変えるのではなく、キャラチップのサイズ規格はマップチップ規格と同じくらいの長さにしたままにして、 歩行時にキャラチップを3枚横につなげるなどの方法もあるかもしれません。3枚の真ん中のチップが胴体と腕の付け根側で、隣の左右チップがそれぞれの腕の先端側に対応、という手法です。おそらくですが、ファミコン時代の古いアクションゲームでも、巨大ボスなどを、複数のチップをつなげて作画していたでしょうから、そういうのを現代的に応用する手法というわけです。 ただし、これだとキャラの処理速度の負担も、単純計算で3倍になります。（実際は、左右のキャラチップは無描画の場合もあるし、描画量が少ないので、もっと少ないが。） 主人公とかボス敵だけのキャラチップなら、グラフィック重視のゲームなら、その意義もあるかもしれません。しかし、果たしてモブキャラのキャラチップにまで、そこまでのチップ3倍にする手間を掛ける価値があるかどうか。 また、製作ツールなどの事情により、読み込みできる画像の枚数に制限のある場合があるので、あまり目立たない部分のために画像を1枚増やすのは非効率です。 ですが、べつに全キャラに6枚歩きを実装する必要もありません。お好きなように。 ;ミニゲームで分離など どうしてもドット絵で手足の動きをリアリティある書き方で細かく表現したいなら、いっそ、ゲーム本編ではなく別途ゲーム中にミニゲームでリアルな腕の振り方のあるミニゲームを組み込むなどの方法のほうが、良いかもしれません。 この方法なら、たとえばもし2D対戦アクションゲーム（スト2みたいなの）のミニゲームを組み込んだら、歩きや走りだけでなく、ジャンプだろうが座りだろうが、もはやパンチやキックや剣撃なども思う存分に大きく作画できますし、作画によってゲーム性も向上します。（アクションゲーム特有の非リアル描写もあるだろうが、本ページはRPGの教科書なので、アクションゲームの非リアル描写には深入りしない。） 背景を手書き背景イラストにすれば、マップチップのサイズ規格に縛られる必要もなくなるので、思う存分にキャラの好きな大きさで作画できますので、腕などの細かい部分も目立つ大きさで作画できるでしょう。 ただし、この方法の背景だと、スーパーマリオのような、背景の空中ブロックの上に、キャラがジャンプして飛び移ったりとかの処理は、スト2的ゲームのままでは不可能です。別途、マリオ的システムのプログラムを組む必要があります。つまり「スト2のようなスーパーマリオ」というゲーム企画を実装する必要が生じてしまいます。 また、ツクール的システムのRPGでなければ「3枚歩き」に縛られず、歩きと走りの作画を分離するのも自由ですし、「6枚走り」と「6枚歩き」のシステムにすることで「滑り」も無くせてリアリティ向上します。そこまで作画する意欲があればの話ですが。 ===== 2D-RPG歩行のドット絵の描き方 ===== 歩行グラフィックの切り替えパターンはゲームごとに違うのですが、下記コラムでは実装のラクなパターンを紹介します。 なお、ツクールやウディタの歩行パターンとは異なります（ツクールなどは、もっと複雑なパターン。後述する）。 {{コラム|プログラマー用のドット絵制作のコツ| ドット絵の書き方ですが、プログラマーの場合、絵の表示のテストをしないといけないので、絶対に最初は下書きまでに止めます。細部は書き込まないのがベストです。（下書きの手法については、別コラムでまとめてあります。） なぜなら、もし自作プログラムでRPGをゼロから作る場合、表示プログラムのコーディングをしながら絵を描くので、プログラマー脳と絵描き脳を、まるで反復横とびのように何度も行ったり来たりします。だから絶対に、この段階では（作り始めの段階では）絵は下書きまでに止めます。下書きで描くドット絵はすごく大雑把なラフ画でいいです。 さて、いきなり4枚描く前に、まず2枚だけでいいので、方向による表示の切り替えプログラムをテストします。 たとえば最初の1枚は下向き静止画像でしょうから、残り1枚は、右向きか左向きか上向きの静止画像になると思います。 たぶん、多くの人は右向きか左向きを書くと思います。後ろ向きをまっ先に書きたがる人なんて、いるとしても一部の重度のアニメ作画マニアぐらいです（アニメーターは360度いろんな向きでポーズを描くので）。 とりあえず説明の簡単のため、私たちプログラマーは右向き静止画像のドット絵を書いたとしましょう。 さて、とりあえず下と右の2方向の表示の切り替えプログラムさえ出来れば、同様のアルゴリズムでどうせ左向きと後ろ向きの静止画像も表示できるだろうから、さっさと歩行中の足を上げてるポーズの作画に入ります。そっちのほうがプログラマ－的には楽しいと思います。 で、すでに右向きの静止ポーズは描きあがっているとして、さらに前足を上げているポーズを1枚書いたとします。つまりこの時点では右向き絵は、静止右向き絵 と 足上げ絵 の合計2枚あります 1マスの歩行に60フレームを使っている場合、とりあえず表示フレームのタイミングは二等分により、 :前半の30フレーム中に前足あげポーズを表示、 :後半の残り30フレーム中に静止ポーズを表示すれば、 とりあえず何とか歩いているっぽく見えます（実機で確認ずみ）。 次に後ろ足を上げているポースも書き終えたら、今度はフレーム間隔を調整して変更し、3枚の右向き絵がありますが、三等分すれば 60÷3 <nowiki>=</nowiki> 20 なので、 :前半の20フレーム中に前足あげポーズを表示、 :中盤の20フレーム中に後ろ足あげポーズを表示、 :後半の残り20フレーム中に静止ポーズを表示すれば、 とりあえず歩いているっぽく見えるでしょう（確認ずみ）。 静止ポーズ中の20フレーム中に、直立ポーズのままスライドするのはリアリティ的には奇妙ですが、 しかしこの静止ポーズがないと表示テストでは隣マス（1マス目）の到着直後にさらに隣マス（2マス目）に直進するときにキャラクターがまるで膝蹴りを発動しているかのようなアニメになってしまうので（実機で確認ずみ）、 決断によって静止ポーズのまま20フレームぶんをスライドさせるべきなのです。 }} 実はツクールやウディタなどの歩行アルゴリズムは、本ページの上記コラムのプログラムのようにはなっていません。 なお、ツクーツとウディタで、キャラの標準的な歩き方のアルゴリズムは両方とも、 :前足を上げる状態で進む → 直立 → 後ろ足をあげる状態で進む → 直立 → 前足を上げる状態で進む →　直立（同様に繰り返し） のように、直立ポーズを挟んで、前足あげと後ろ足あげを交互に繰り返す方式です。（最初に始まるのが前足か後ろ足かの若干の違いはあるかもしれませんが、本質的ではないので深入りしない。） けっして、 :前足を上げる状態で進む → 後ろ足を上げる状態で進む のようにはなりません。 これはおそらく、直立のように見えるグラフィックが、実は歩行中の前足と後ろ足とが重なった状態を兼ねている表現だろうと思われます。 そのほか、ツクールやウディタで1マスだけ進むのを繰り返すと分かりますが、 1マスしか動かないで停止したとき、キャラチップをよく見ると、その場で足踏みして最終的に直立して止まることがあります。 ツクールもウディタもソース非公開なので不明ですが、これはプログラム的には仕組みはおそらく、 移動中の間だけ「移動中カウンタ」的な変数が進み、それが一定値になると0に戻るという仕組みを繰り返していると思います。 そして隣マスに到着時の進行判定の際、もし右ボタンが押されていなくてマスに停止しており、 移動中カウンタがまだ0に戻る前の値だったら、その値を保存したまま、 表示プログラム用にカウンタ値だけカウントアップしていって0に戻るまで表示が進むような仕組みで、実装できるかと思われます。 もし読者がツクールやウディタっぽい歩行アルゴリスムを実装したいなら、ご自身で研究してください。どのみち、ツクールとウディタで、歩行のポーズ切り替えタイミングなど微妙に違いますので、統一されていません。 どのみち、たとえばファミコン版ドラクエ3のアルゴリズムは、ツクールやウディタとも違います。ドラクエ3ではマップ上でマスに立ち止まっても、キャラチップは静止せずに足踏みを続けます。 このように歩行パターンはゲームそれぞれです。 {{コラム|ドット絵の下書き手法| テレビアニメの下書きとは、ドット絵は、作画の順序や手法が大きく違います。 テレビアニメの下書きでは、まずエンピツで線画を描き（「原画」（げんが）という）、あとから色を塗る（バケツ塗り）という手法です（「彩色」（さいしき）という）。（このあと「撮影」とか「編集」とか色々な工程があるが、ゲームに関係ないので省略。） ですが、ドット絵はこれとは作画の順序や手法が大きく違います。 ドット絵グラフィッカーによって手法は個人差があるでしょうが、とりあえず一例として、下記のようなドット絵の書き方を紹介します。もちろん、コンピュータ上でのドットエディター上での作業です。 :前後左右4方向の中ポーズ（立ちポーズ）のラフ色塗り : ↓ :ゲームに組み込み目視で画面を見てテスト : ↓ :テストで異常あれば下書きを修正。異常なければ次に進む : ↓ :前後左右の腕足振りポーズを2枚ずつ色塗りで大まかに下書き。（3枚作画なので、あと2枚が追加で必要） : ↓ :ゲームに組み込み目視で画面を見てテスト : ↓ :テストで異常あれば下書きを修正。異常なければ次に進む : ↓ :これから細部の書き込みに進む。細部に興味なければここで終わる。 : ↓ :（細部の書き込みと、そのテストなど） : ↓ :（たぶん）終わり 上記フローのような書き方は、あくまでRPGのマップ画面でのキャラチップのアニメの書き方だけに限定の手法です。だから、それ以外には、そのままでは応用できず、たとえば戦闘画面のモンスター画像などには応用できません。 あくまでマップ画面モードのキャラチップのみの話題です。 さて、ではなぜ上記のような手順で描くと合理的なのかを説明します。 もし40px × 40px 程度のドット絵なのに、テレビアニメのように色の違う箇所すべてに枠線を書こうとすると、ゲームのチップは小さいので服の模様などによってドットが黒一色（rgb値が 20,20,20 とか）で潰れてしまうので、色がなにも見えなくなってしまうから、テレビアニメ的な作画の手法は使えないのです。 だから基本、ドットの下書きでは、まず、色を大まかに塗ります。この際、ポーズも大まかに仮に決めて、下書きのときに一緒にポーズを書きことになるでししょう。 なぜ、静止ポーズの前後左右4枚を先に描くかというと、歩行中の残り8枚の絵よりも静止4枚のほうがプレイヤーの目に入る時間が長いからです。 ポーズボタンのないRPGの場合、もしプレイヤーが歩行中8枚の絵のいずれかをじっくり見ようと思ったら、プレイ動画を録画してから一時停止などの手間が必要です。 しかし静止ポーズ4枚は、何もしなくてもプレイヤーが画面の前でボーッとしてるだけでも目に入ります。 だからこの4枚を優先的に作画していく必要があります。今後の工程で細部の書き込みをする際にも、静止ポーズ4枚を優先して細部を仕上げると良いでしょう。 そして、大雑把に色が塗れたら（すごく雑（ザツ）な塗りでいいです）。最低限、向きは前後左右の4ポーズの立ちポーズを描かないといけないので、とりあえず、さっさと4枚を大雑把に早く書いて、実際のゲーム画面で表示テストしてみます。 ゲームドットの下書きなので、けっして細かく書く必要はないです。一方、テレビ番組アニメ用のアニメーター教育などだと、「練習でも細かく描け。すると本番ではそれを早く書けるようになっている」と教育する場合もありますが、しかしゲームのドット絵の下書きの場合は目的が違います。 実際にテストで確認してみて、問題があれば書き直しです。 だから、もし最初から細かく描いてしまうと、書き直しになったときにそれを消さないといけないので、無駄になってしまうのです。だから、色を大まかに塗るだけなのです。 そして下書きのドット絵の中ポーズの4方向の向き転換などをテストしてみて違和感がないことを確認できたら、次に手足を振っているポーズの作画にとりかかります。ここでも、色を大まかに塗るのと、ポーズを決めるだけです。 そして、とりあえずテストで実際のゲーム画面中で動きのアニメーションを確認してみて、「キャラがおかしなポーズになってないか?」とか、遠めで見たときに歩いているように見えるかとか、そういうことを確認していきます。 どのみち2D-RPGゲ－ムでは（テレビアニメではありえない）3枚作画で歩きを買いているので、少々の滑りや、実際とのポーズの少々の違いは無視です。 }} おおむね、こういった作画の流れになるでしょう。もちろん個人差はあるでしょう。ですが、けっして「いきなり細部から描く」ことはしないのは、ほぼ確定でしょうし、線画はドットが潰れるので輪郭以外の線は描かないことも、ほぼ確定でしょう。 あくまで、2D-RPGのキャラチップの 40px × 40px 程度のドット絵だけに限定した話です。なので、反論などで顔グラフィックなどキャラチップ以外の話題を出されても、ピント外れです（相手が言ってもいないことで反論することを「[[w:ストローマン|w:藁人形論法]]」（わらにんぎょう ろんぽう）と言います）。ましてやRPG以外のアクションゲームなどのドット絵の手法で反論しないでください。 ===== デッサン的なこと ===== {{コラム|髪の揺れ と腰のねじれ など| 女性キャラのチップだと、前後の歩行中チップでは髪やスカートが左右にゆれたりします。男性キャラでも、マントを羽織った騎士などなら、マントが揺れたりします。 テストでは、そういう点をチェックをしていくことになるでしょう。 こういった感じで実際にゲーム画面中でテストしてみて、もし問題がなければ、あとで細部を書きこんでいくことになるでしょう。 また、キャラクターデザインの細部に興味がなければ、下書きの塗りを修正し終わった段階で、このままで完成としても構わないかもしれません。 なお、髪の毛が右に揺れる場合、足で伸びているのは反対側である左足です。 髪の毛が左に揺れる場合も、足で伸びるのは反対側である右足です。 これはなぜそうなるかというと、歩行時の腰の ねじれ を表現するためです。 普通の歩き方では、右手が前方に伸びているときは左手が後方に伸びており、このため上半身が左回転します。 このままだと体が左回転して進路が左にそれてしまうので、足側では左足が前方に伸びて右足が後ろに伸びることで下半身は右回転します。 こうして上半身が右回転する一方、下半身が左回転するので、全身では回転が打ち消されることで前方に歩行できます。 また、上半身と下半身とが逆方向に回転しているので、腰はわずかに ねじれます。 だから、髪の毛が右に揺れるなら、これは上半身が右回転した直後の表現なので、つまりこのとき下半身側では左回転した直後の表現になっていなければなりません。これはゲームに限らず、アニメでもそうでしょうし、現実の人体がそうでしょう。 なお、無理やり、腕の振りのタイミングと、足の降りのタイミングを一致させる歩き方を、ナンバ歩きといいます。つまり、右手が前に出ているときに右足も前に出る歩きがナンバ歩きです。 格闘技や古武術などだと、色々な理由によりナンバ歩きをする場合もあります。 だから、もしかしたら対戦格闘アクションゲーム（スト2みたいなの）ならナンバ歩きで描く場合もあるかもしれません。しかし、2D-RPGの歩行チップでは不要でしょう。 }} ===== ドット絵作画的なこと ===== さて、いくつかフリー素材を調べたところ、横向き時の中ポーズの足は、1本しか見えません。 ついつい歩行中の中ポーズも意識して足を微妙にズラして2本書きたくなりますが、しかし静止ポーズにも使うことと、ドット絵なので微妙な足の段差を表現しづらいことなどから、 決断して横向き時の足は1本しか見えないほうにするのが効率的でしょう。 どうしても中ポーズでも足2本を見えるようにしたい場合の裏ワザとして、2本の足が合体した太い1本足を描くというワザがあります。やや太めの1本足です。 一部のフリーゲーム素材がこういうワザを使ってドット絵を描いています。 ドット絵なんてこんなもんのゴマカシの連発ですから、あまり下調べの段階なのに細部を調べても仕方ありません。さっさと書き始めてから、書いてる途中に気になった点から手本を見直して調べていけばいいのです。いろいろと調べるの必要になりますが、さっさと書き始めるのも重要です。こういうのは、調べていたらキリがありません。 デッサンのコツなんて、細部を書き始める時点までに、把握できていればいいのいです。 仕事でなければ、イラストなんて最終的には描いた自分で満足できればいいのです。プログラマー視点で見るにしても、歩行プログラムの検証をできる最低限のイラストさえ書ければいいのです。 当ページはプログラミングの教科書ですので、まず先にプログラム検証のための最低限イラストを描くことになります。 == 戦闘 == * [[ゲームプログラミング/RPG/戦闘]] とりあえずバブルソートの話題など。ほか幾つか。 == デーテベース的なこと == * [[ゲームプログラミング/RPG/データベースとは]] == (※: 未確認)戦闘中のモンスター隊列 == さて、戦闘中のモンスター隊列の構成を定義するための配列（または同等の内容の数列）も、必要です。 まず、画面に敵を、表示したい順に表示するためも必要です。 また、上述の「素早さ順」での行動処理のためにも、前提として、敵パーティの構成を表すための配列が必要になります。 説明の単純化のため、敵は横一列に、左から右に、並んでいるとしましょう（ドラクエ2～3みたいな方式だとしましょう）。 たとえば敵が左から順に :ホブゴブリンが1匹、毒々スライムが1匹、ゾンビ兵士が1匹 出現したとしましょう。（説明の単純化のため、モンスターは各種類ごとに1体だけとする。） そして、ホブゴブリンのモンスター用データベース中でのIDが13番だとして、　毒々スライムのIDが8番、　ゾンビ兵士のIDが25番、　だとしましょう。 すると、この敵パーティを表すための配列として、 :{13,8,25,-99} のような配列が必要です。（もしくは、配列に格納できるような数値の列「13,8,25,-99」） 末尾の－99は、これはその配列の読み終わりとして使用するための数字です。この数字は、別に「-10」でも「-99」でもいいですが、モンスターのidとけっして重ならないようにする必要があります。 通常、なんらかのデータベースのidの値は0以上の正の整数ですので、マイナスの整数を「終了」の意味で使用しておけば、安全でしょう。 このように、敵側にも、配列が必要になります。 しかも、この敵側の配列は、そのゲーム中で出現する敵パーティの全パターンを用意する必要があります。 たとい1体だけしか出現しない敵でも（たとえばボス敵や強敵）、その1体分の敵パーティの配列が必要です。 たとえば、その1体だけで出現する、あるボス敵「暗黒大王」のモンスター用データベース中でのIDが205番だとしたら、 :{205,-99} のような、敵1体だけの配列を用意する必要があります。 === 余談: マイナスを含む並べ替え === なお、もしマイナスの数を含む数をふくめて並べ替えをしたいのでしたら、 上記の「-99」など終了処理を負数で区別する方法は、そのままでは使えないです。 たとえば、方向でもし東向きをプラス、西向きをマイナスとした場合、終了コードのつもりの「-99」は、誤解で「西に99マス」などと誤解される恐れがあります。 たとえば、 :-3 , 5 ,2, -6, -2 , 0 , 1 の並べ替えをしたい場合を考えましょう。 解決策としては、いろいろあります。 ==== 解決策1 ==== 一番ラクな方法は、要素数を新たな変数として追加し、それと組み合わせて配列を使うことでしょう。 たとえば、 :-3 , 5 ,2, -6, -2 , 0 , 1 は7個の数が並んでいるので、 youso = 7; みたいに新たに変数を用意します。 そして、たとえば最初の「-3」から順番意読み取りの際に、数えおわった個数を+1していき、+7になったら読み取りを終了することです。 この方法は、拡張性が高いのでオススメですが、ただし、要素を書く前に個数を宣言する必要があります。 実際の配列データは :-3 , 5 ,2, -6, -2 , 0 , 1, 0 ,0 ,0 , 0 ,0 ,0 , （以下略） のようになっているので、けっして数え終わって欲しいところでキリよく要素が終わるわけではないので、なので、要素数をあらかじめ宣言する必要があるのです。 さもないと、8番目の「0」が、読み取りたい数値としてゼロなのか、それとも、単にデータなしのためゼロなのか、不明になります。 終了コードなどとして負数を使用するのは、マイナスを含む並べ替えでは、あきらめましょう。それが安全でしょう。 ==== 解決策2 ==== 最初の解決策1（要素数を新たな変数として追加）がもっとも安全かつ簡単ですが、比較のため、別の解決策も紹介しておきます。 次の解決策2は、数学的にはエレガントですが、しかしプログラミング的には、煩雑になり、また、バグ時などのエラーの波及をしやすい欠点があります。 さて、並べ替えのもうひとつの解決策として、 一例は、符号と絶対値を分離して、その組み合わせとして処理することです。 たとえば、 :-3 , 5 ,2, -6, -2 , 0 , 1 の並べ替えをしたい場合、 プレイヤーからは表面的には「-6」は1つの数に見えまずが、これをあえて、「フラグhugouが状態2（マイナスに相当）である」「絶対値 zetai が6である」というように、2つの変数hugou と zetaiに分けます 符号がプラスなら、hugou = 1　にでもしておきましょう。また、ゼロは便宜上、hugou = 1 にしておきましょう。 すると、上記の数の並びは、(hugou, zetai)のベクトルで考えると、 :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1) という組み合わせに変換するので、マイナスが使われない形になります。 なので、終了処理に、「-99」などの負数を割り当てても、並べ替え対象の数値と重なる心配がなくなります。: (2, 6,) , (2, 3) , (2, 2) , (1,0) , (1,1) ,(1,2), (1,5) :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1),(-99,0) などのように、終了コード「(-99,0)」を末尾に追加しても、なんの混同の心配もなくなります。 さて、いったん上記のように、数を、符号と絶対値の組み合わせに分解して、同じ符号どうしで並びかえたなら、 あとは、符号が同じものどうしで、並べ替えをするだけですみます。 たとえば、 :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1) の並べ替えをしたい場合、ベクトルの第一引数に注目し、※ （第一引数、第二引数） まず、 :(2,3) , (2,6), (2,2) のグループ : (1,5) ,(1,2), (1,0) , (1,1)のグループ に分けます。 そして、絶対値(例では第二引数)だけに注目すれば、 :マイナス数の絶対値は 3,6,2 → 2,3,6 と並べ替え → 逆順にして6,3,2 → マイナス符号をつけて -6,-3,-2 :プラス数の絶対値は 5,2,0,1, → 0,1,2,5 と並べ替え となるので、簡単に並べ替えできます。 あとは、これを合成し、 :-6, -3 , -2 , 0 , 1 ,2, 5 と、並べ替えできます。 なお、説明の都合上でベクトルを蒸気の解説で使ったが、しかしC言語にベクトルの機能は無いので、もし上記の機能を実装するなら配列や構造体配列を使って、ベクトルと似たような処理を実装することになる。 たとえば配列で実装するなら、符号用の配列 hugou[id] と、絶対値用の配列 zetai[id] のようなものを用意したりすることになるだろう。 もし1番目の最初の数が「-3」なら、符号フラグは2、絶対値は3だからベクトル表現では :(2,3) であるが、これは配列で表現するなら、たとえば :hugou[0]=2; zetai[0]=3; のように記述できる（C言語では配列の番号は0から数える）。 ;欠点 この方法は、一見すると数学的にエレガントに見えるかもしれませんが、しかし、もしバグやタイプミスなどによって数え間違えると、数え落としや重複があると、以降の符号が1個ずつズレてしまうなどの大きな影響があります。 たとえば、説明のため上記では :-3 , 5 ,2, -6, -2 , 0 , 1 の分解を :(2,3) , (1,5) ,(1,2), (2,6), (2,2) , (1,0) , (1,1) とマトメて書きましたが、 実際には :hugou 2,1,1,2,2,1,1 :zatai 3,5,2,6,2,0,1 のように別々の変数に分かれて保管されるのです。 もし、たとえば hugou の最初に、バグなどで「1」が加わると、 :hugou 1,2,1,1,2,2,1,1 :zatai 3,5,2,6,2,0,1,0 のようになってしまい、すべての符号が1個分、ズレてしまい、 :3, -5, 2, 6 ,-2 , 0, 1 ,0 となってしまいます。 正しい元々の数字の並びの :-3 , 5 ,2, -6, -2 , 0 , 1 と比べると、符号がいくつも間違っており（1個目と2個目と4個目が違う）、解決策2ではエラーの波及が大きいことが分かります。 == 脚注 == {{reflist|group=注}} == 参考文献など == {{Reflist}} bhxc3d9qu37ca4hyzskjenj1vvcqvif 0 27227 206835 206610 2022-08-20T02:46:51Z すじにくシチュー 12058 /* ※例 */ nature の法律設計の複雑さの定量化の科学研究の記事を、こちらにも記載。 wikitext text/x-wiki {{substub}}このページの主要執筆者は、ゲーム業界経験者ではないので（2022/1時点）、ここの記述は調べ物としては役立ちません。 2022/1時点でゲームプログラミングと直接の関係ない話題が長い、という問題があるので、より簡潔、かつ分かり易い記事への編集にご協力いただけたら幸いです。もっとも現編集者Hは、解ってるならそれを書いた奴が書き直せ、そもそも余計なことは最初から書くな、…とは思いますが…。 このページは、教科書としてゲームプログラミングの方針を説明する際に、どうしても書類についての説明が必要だから記述されています。現状では、一般IT業界や製造業などの設計図を参考に説明がなされています。 == 本書の目的 == 本書は、ゲームデザイナーのための教科書ではありません。 メインページ、「[[ゲームプログラミング]]」の題名どおり、プログラマーのための教科書です。プログラマーがゲーム制作に興味をもって実際に作り始める際に、調べ物の手間を減らすために書かれた参考書籍です。 ゲームデザインに関する解説を望む方は、別途、他の参考資料に当たってみてください。 ==「仕様書」== ここでいう「仕様書」とは、ゲームの設計図のことです<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.126</ref>。しかも職業的に集団でゲームを作るときの書類です。 ではまず、「設計図」とは何か、について、考えていきましょう。これは普通科高校では学習しない事項です。 ゲーム業界では、「仕様書」を含む書類群の「発注書」には、決められたルールや書式はありません。だから作るゲーム内容や製作チームごとに、適切な発注書のありかたを毎回考える事になります<ref>『ゲームデザイン プロフェッショナル』、P.145</ref>。 職業的なゲーム開発では、一般に :発注 → 実装 → 調整 というプロセスを経て<ref>『ゲームデザイン プロフェッショナル』、P.61</ref>、最終的にとりあえずの完成になります。 ゲーム産業での「仕様書」は、発注の段階での書類です。 ==集団ゲーム制作での解説文== 発売禁止になってしまった書籍（おそらく。しかし何故？）『国際おたく大学―1998年 最前線からの研究報告』（岡田斗司夫ほか、光文社）に書いてあった事例なのですが、G.O.D.と言うイマジニア社のRPGゲームに対する大学生（岡田は当時、大学講師だった）の取材があって、そのGODの開発に参加した劇作家の鴻上尚史（こうかみ しょうじ）氏と、エニックスの堀井雄二（ほりい ゆうじ）氏とが、対談した経緯が、紹介されていました。 劇作家の鴻上は、ゲームに演劇のリアリティを入れようとして、スタッフに「間（ま）を意識したシナリオを書いてほしい」と要求したが、うまく行かずに難航したと体験談を述べています。 対談相手の堀井は、鴻上のその体験談に対し「『（※ここで3秒休止）』とか書くと良いですよ」と、指示書で具体的に書くと良い、とアドバイスした、と、岡田の書籍にある大学生のレポートにあります。 おそらくドラゴンクエストのゲーム開発でも、このように具体的な指定を必要に応じて出していた・いるものと思われます。 21世紀現代の、商業ゲームの現場でも同様であり、書籍『ゲームデザイン プロフェッショナル』にもありますが（※かぎカッコ内が引用）、「もっとかっこよく調整してほしい」という問題であれば、たとえば「もっと目立たせたいので、アニメーションのシルエットを全体的に今より少しだけ大きくしてほしい」<ref name="gp296">『ゲームデザイン プロフェッショナル』、P296</ref>という具体的な指定が妥当でしょう。 == 集団作業に必要な書類 == ===設計図=== IT業界やゲーム業界では、集団作業で制作開始をしようとする際、まず、いきなり設計図を作るのではなく、まず先に試作品（しさくひん、英語で「プロトタイプ」proto-type）のプログラムを作り、企画で考えた各種システムなどのアイデアが有効かどうかを検証します。 そのプロトタイプで、企画のアイデアが本当に有効であるかを確認してから、もし有効だったら、本格的な制作を開始します。 もしかしたら会社によっては、企画会議（もしくは企画の打ち合わせ）よりも先にプロトタイプを作るかもしれません。 さて、会社へのプロトタイプ提出で、制作続行・制作本格化の賛同が会社から得られたとしましょう。 IT業界でも製造業でも、どこの業界でも集団作業で、制作の合意を作るさい、必要な書類は、おおむね、 :作業者用の具体的な「完成予想図」 です。 しかしゲーム業界の場合、いきなり完成予想図に相当する「仕様書」は書けないので、書籍『ゲームデザインプロフェッショナル』によるとまずゲーム中の大まかな実装予定事項を記述した『企画概要書』という書類を作成することもあると言われています<ref>『ゲームデザインプロフェッショナル』、P139</ref>。ただしこの「企画概要書」は、名前に「企画」とはついているものの、どちらかというと仕様書の方針を大まかに打ち合わせするための書類に近いので、いわゆる「企画書」とは異なります。 なお、一般のIT企業でよく書かれる「要求事項書」は、ゲーム書籍では紹介されていないので、おそらくゲーム業界では書かないのが普通だと思われます。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ===ゲーム業界での技術職=== 言葉というのは同じ国の国語でも、その業種や職場、社会集団で、微妙に違った使われ方をすることも多く、技術職、という言葉もゲーム業界での特別な使い方があるようですね。 この業界では、グラフィックデザイナ－やサウンドクリエイターやプログラマーが「技術職」<ref>『ゲームプランとデザインの教科書』、P125</ref>。技術職 = ￢(not)企画職、という事で、プロデュ－サーやプランナーやディレクターなどの「技術職」でない製作スタッフが企画職です。 ただ現編集者はプロデューサーとディレクターは対立する職種だというイメージはありますね。プロデューサーは企画職だろうけど、ディレクターは、"実"制作職ではないかな？ ===企画書=== *PREP法 基本的にビジネス上の書類は、結論を一番先に書く構成法が望ましいですね。もちろん商業ゲーム制作の現場でもそうでしょう。文献『ゲームプランナー入門』では、具体例として、PREP法を紹介しています。 PREP法とは、 :Point（結論）→Reason（理由）→Example（具体例）→Point（結論）。 ほかにもホールパート法やSDS法などがありますが、どれも冒頭で結論を示した後詳細を伝える方法で、ビジネス文書はやはり、その形式が常道でしょう<ref>『ゲームプランナー入門』、P141</ref>。 しかしこの社会、ビジネスが重要なのは事実だが結局、他者の行為や仕事をただ自分の欲望と利益に使い、他者の存在や詳細に興味のない人間は、とにかく結論だけを先に聞きたがるし、それ以外の事には事実上何の興味も持っていないでしょう。 *ゲームのルール 常識的な判断としては、ゲームにはルールがあるものですよね。ルールのないゲームというのは、ふつうあまり考えつかないし、イメージできない。 ですからゲーム企画書としては、ルールの説明が必要になる。キャラクター設定や世界観の解説があったとして、ルール説明がない企画書はふつう受け入れられない<ref>『ゲームプランとデザインの教科書』、P83</ref>。 ただ今ではゲームジャンルの固定化が進んでいるので、ルールはくどくど説明する必要はない、という場合はある。 企画書を誰が書くかという問題もある。業界の内部の重要人物か、全く外部の業界経験の無い人物か。 どちらににろ常識判断としては、ある程度のゲームルールの解説は必要だろう。 *プレイ人数 企画書には、ゲームのプレイ人数の記述も必要<ref>『ゲームプランナー入門』、P159</ref>。 ほんとの昔は、一人か二人でプレイするのがコンピューターゲームだったのですが、もはや時代は変わりましたね。インターネットを駆使して多人数プレイ、ソーシャルゲームなんてものも出てきました。 <!--(:※ ここから先、セクション末尾まで文章の編集者が異なります。編集者Hによる文章です。なお出典のある部分は編集者Hではなく別の編集者Sによるものです。)←すじ肉先輩さー、この記述は無いわ^^;;。だってこれって、みなさーん、以下の馬鹿文はHが書いたんだからね、俺、Sujの文じゃあないよ、馬鹿なのはHであって、俺じゃあないから。Sujはちゃんと出典は全部書いてんだよ^^、って言ってるのと同じだよね^^;;;;;--> さて、企画書に関しては、よくない企画の典型例というのはあるようですね。特に特定人物のネームバリューに依存した企画は良くないし、批判の対象になることも多いようです。ゲームとしては、イラストレーターや声優に超大物を起用することを強調した企画書ですね。 出典として『テリー伊藤のお笑い大蔵省極秘情報』あたり、確実に特定はできませんが、木村拓也のタレント性に頼った企画は、著者のテリー伊藤によってよくない企画の例として指摘されていたようです。 もっともテリー伊藤という人物自身が、ビートたけしの面白さ、彼を起用したことの良さによって世に出て知られるようになった人物なので、そんな事言っていいのかね、などと現編集者は少し思いますが…。 また今回の本題、ゲーム業界でもそういう良くない企画書が提出されることは多いようです。元ゲーム業界人でゲーム評論家の あべひろき が、90年代の著書で、過去にゲーム関連会社に勤務してたときの体験談を書いています。企画書の精査をしているときに、「人気声優の○○さん起用！」と書かれていたものがあったが、あべ氏がその声優の所属する声優事務所に確認の電話をとると、なんの商談も声優とも事務所ともされていなかったという事です。 もっとも企画書とは企画に過ぎないのではないだろうか？これらの他人のネームバリューに頼った企画が良くないのは事実だが、企画が通って実現する見込みが決定する以前は、むしろ声優本人や事務所にアクセスすることはないのが普通だろう。 もちろん企画者がその事務者や声優と懇意にしてる場合は、あらかじめ話をする可能性はあるが、しかし企画段階ではそもそも現実のビジネスになる可能性はそれほど高くない。声優や事務所にとってもその段階でもっともらしく話をされても、むしろ困惑するだけではないだろうか？ ただこういう他人任せの企画は、「プロデューサー的企画」と呼ばれるようです<ref>吉冨賢介『ゲームプランナー入門』、P71</ref>。クリエイティブな企画とは言えないわけですが、しかし商業的な娯楽作品には、クリエイターだけではなく、プロデューサーも絶対必要でしょう。 一般に企画でも他の仕事でも、他者の力や権威、その後の作業などに頼り切った態度は、どんな場所でも嫌われて批判されますし、それは職業の場だけではないでしょう。 また、ゲームの企画に関してもう一つの話題として、アメリカでも売ることに成功したドンキーコングの、ディレクターの宮本茂（任天堂）は、「人間の生理的なところを体感できるゲームを作れば、それがユニバーサル」、だと、語っていたようです<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P89</ref>。 ===「仕様書」、「企画書」=== 商業的なゲーム制作では、一般に、 発注 → 実装 → 調整 の過程を辿ります。 そして発注段階で重要な書類は、「企画書」と「仕様書」の二つです。まず『企画書』で作るゲームのコンセプトを固めてから、あとで『仕様書』で、より詳細に内容をを決める、という順序をとります<ref>『ゲームプランとデザインの教科書』、P43およびP45</ref>。 企画書<ref name="gcs72">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、72ページ</ref>は社内だけでなく協力会社にも見せる資料であり、開発者・協力者に対して手短かに、そのゲームの全体的なコンセプトを伝えるためのものです。 仕様書は、ゲーム制作では「設計図」であり、「完成予想図」であるといっていいでしょう。企画書よりより詳細にゲームの内容を決め、指定しています。 さて、話を進める前に、商業的に集団でゲームを作る場合の他の書類や必要事項の名称について、ここで簡単に書いておきます。 まず「発注書」とは，発注時に作られる、必要な書類群のことでしょう。「企画書」と「仕様書」も含みます。 「指示書」はむしろ、実装や調整段階でなされる、具体的なゲーム演出上の指定でしょうね。 試作品（しさくひん、英語で「プロトタイプ」proto-type）や企画会議（もしくは企画の打ち合わせ）なんて言葉も出てきますが、こういうのはあえてクドクド説明しなくても、直感的にイメージわきますよね。 『企画概要書』とは企画書とは異なるもので、仕様書に準ずる書類で、仕様書の方針を大まかに打ち合わせするためゲーム中の大まかな実装予定事項を記述している書類です。 『原案書』<ref name="gcs72" />は社内だけで企画がペイするかどうかの検討を決算書などを参考に分析・会議するための書類です。 こういう書類や用語に関する言葉の使い方は、商業的集団的なゲーム制作の場として妥当と思われるものをまとめてみましたが、もちろん職場によって、会社によって使い方や意味が微妙に変わってくる場合はあるでしょう。 さらにゲーム以外の一般IT業界や製造業でもそれぞれの慣習があり、今回の説明が成り立たない、そしてそこはより一般的な職場ですから、それぞれより一般的な言葉の使い方があると思います。 さて、コンセプトの具体例として、書籍『ゲームプランとデザインの教科書』によると、たとえば『ポケットモンスター』のメインのコンセプトは、「通信ケーブルを伝わって、ポケモンが入ったカプセルが移動して交換する」、が始まりだそうです<ref>『ゲームプランとデザインの教科書』、P109</ref>。 また、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、『メタルギア』シリーズのコンセプトは、「敵に見つからないように進む」、とのことですね<ref>吉冨賢介『ゲームプランナー入門』、P108</ref>。 イラストや音楽の発注は、一般的には企画が決まった後でしょう。 そもそもイラストレーションや音楽を対価を払って提供してもらったとして、それを実作品に使用しないのは、作者にとっては不本意なことだと思います。 アニメーターの故大塚康生氏は、アニメーション演出家が安易にアニメーターに大量の絵を描かせ、そこからいいもの、利用できるものだけ取捨選択する方法を批判していましたし、一般的に手仕事には作者の思い入れがありますから、安易な大量生産品と同じ取り扱いはできないと思います。 もっとも一方で、あるアメリカの日本人アニメーターが、同僚の日本人アニメーターが、自分の描いたものを日本の家族や友人たちが見ることができないことを不満に思っていた、という事を批判的に語っていたのを、現編集者は聞いたことがあります。 しかしゲームの場合、例外的にイラストや音楽が先行する場合はありますね。 RPG『クロノトリガー』は、企画の当初からイラストレーターをつとめた漫画家・鳥山明のイラストがあって、それをもとに作品を作ったと、鳥山のマンガの編集者であった元・少年ジャンプ編集の鳥嶋和彦は述べています。<ref name="tskdq">[https://news.denfaminicogamer.jp/projectbook/torishima/2]</ref>決めシーンなどのキービジュアルを先に決め、それに合うように設定を練りこんでいくという方式で、クロノは作られたようです。 企画書の制作ツールとしては、清書としては、オフィスソフトの「PowerPoint」と、アドビの「Illustrator」、または、アドビのソフトウェアは高価なので代わりにフリーソフトの「Inkscape」および「GIMP」がよく使われます<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日第1版第1刷、P.281</ref>。なお、Illustrator および Inkscape は、ベクトル画像を描画するソフトウェアです。 ただし、下書きなどでは、タッチペンと何らかの画像ソフト、またはタッチペン用メモソフトで下書きすることもあります。 業界で、ゲームプランナーと呼ばれる職種は、仕様書作成や進捗管理、テスト&デバッグ、スタッフとのコミュニケーション、などが仕事ですね<ref name="gpd9">『ゲームプランとデザインの教科書』、P.9</ref>。 また、ゲーム制作に関して、だれもが様々なアイディアを持っていると思いますが、メモを取って、もし忘れてもメモで思い出せるようにするといいですね<ref>『ゲームプランとデザインの教科書』、P.20</ref>。 アマチュアの企画なら、実際にプロトタイプ（プレイできる試作品のこと）を作って実作品で企画、仕様を説明してしまったほうが早いかもしれません。 参考文献『ゲームプランとデザインの教科書』でも、（試作品を）「ゲームプランナーを志す中で企画書や仕様書を書きながら、ぜひ自分でも作ってみましょう。プログラムや3Dモデルを簡単なものでいいので作ってゲームに仕上げてみましょう。」と述べています<ref>『ゲームプランとデザインの教科書』、P.3</ref>。 上記の本の図表によると、企画書では、「競合情報」、「世界観」、「ストーリー」なども記述して欲しいようです<ref>『ゲームプランとデザインの教科書』、P.43 </ref>。世界観とストーリーが分けられているのです。 物語とその舞台ですね。我々自身もこの世界で自分という役を演じている役者ですよね^^ {{コラム|ゲームの企画書とアニメーションの企画書| 商業アニメーションの世界では、企画の段階でストーリーの概要が決まっているようです。ただこれは、アニメーション作品の企画として、当然に必要とされる要素であるから記述されているわけで、実制作の過程で、実際のスタッフの意向により大幅に変更されることもあります。また、これらの企画では、キャラクター設定やキャラクターイラストのデザインも当然必要であり、かなり明確な形で提出されています。 たとえば、アニメ業界の企画書ですが、1990年代のアニメ『新世紀エヴァンゲリオン』の企画書の掲載されている『新世紀エヴァンゲリオン (ニュータイプ100%コレクション) 』（1997年2月28日初版発行、85～88ページ）を読むと、『企書画』の段階でもう、キャラクターイラストが主役だけでなくその友人や周囲の大人なども含めて、ほとんどのキャラクターでイラスト紹介されており、さらに全部の話数ぶんの粗筋と見せ場・意図を2～3行ていどで説明しています（ただし第1話と最終3話（24～26話）のみ説明が5行以上くらいと長い）。 因みに現編集者は実際にアニメーション業界で企画書を書いたことがありますが、その時に上司、制作会社の重役に指摘されたのは、1クール（3か月）か2クール分の実際のストーリーの具体内容を書いてほしい、との事でした。 一方ゲーム業界では、そういうキャラクター設定やストーリーは、企画段階では決まっていなくて、もし書かれていても邪魔だと感じられるようです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、149ページ</ref>。 業界の企画書で、強調してほしい内容とは、ゲームシステムと、そうシステムを設計した根拠のようです。なぜなら、ゲームの企画書でいう「コンセプトが重要」、と言う際の「コンセプト」の意味とは、ゲームシステムやゲームルールを設計した根拠のことだからです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、108ページあたり</ref>。 とはいえ、ゲーム業界の企画書でも、ゲームの世界観が「中世西洋ファンタジー風」なのか、「現代日本」か、「近未来SF風」なのか、などの設定はある様です。ネット上で公開されている商業ゲ－ム企画書からその様子が分かりますが、しかし、最初の企画書の段階で決まってる世界観はその程度まで、です。 背景としては、ビジネスモデルが根本的にアニメーション業界とゲーム業界とでは違う、という事情があるのでしょう。 }} {{コラム|キャラクター重視の物語論| アニメ―ション業界のビジネスモデルは、キャラクタービジネスだと言われています。1990年代の徳間書店のアニメーションに関する書籍（アニメージュ10周年記念）で、徳間の編集者が1980年代のアニメ業界を振り返ると、これはキャラクタービジネスだろうと、たとえば銀河鉄道999のアニメ―ションの人気も、メーテルなどのキャラクターの人気なのだという分析があり、アニメージュ創刊当時の『銀河鉄道999』特集では、ストーリー解説ではなく、キャラクターに焦点を当てた記事を組んだと、述懐（じゅっかい）しています。 また、漫画産業もキャラクター重視のようです。主人公に共感させるための様々な演出が凝らされている。そして主人公が身近に感じられることが重要だと指摘されています<ref name="tskdq" />。 これは日本人が物語軽視というよりは、海外でも同様であり、むしろ物語とはキャラクターを描くという要素が非常に大きいという事でしょう。多くのミステリの中でも「シャーロック・ホームズ」や「007」の人気が非常に高いのも、キャラクター性と結びついた作品だからでしょうね<ref name="tskdq" />。 1982年頃『鳥山明のヘタッピマンガ研究所』では、おおむね「マンガとは人間を描くことだ」という主張がなされています。 現編集者の記憶では、漫画がキャラクターだという主張を強くしたのは、漫画原作者であり、劇画村塾の開設者である、故[[w:小池一夫|小池一夫]]氏でしょう。上述の書籍の共著者、さくまあきら氏も、劇画村塾出身ですから、さもありなんということですね。 アニメ評論家の岡田斗司夫氏は、対談集『マジメな話』で、「古代ギリシア人や古代ローマ人はとても論理的で学問も発達していたが、一方でギリシア神話やギリシア悲劇が普及していた、人間には物語が必要なのだろう、自分達の社会の仕組みを、物語になぞらえて理解する、物語が学問や科学に匹敵する」といったことを述べていました。 ギリシア神話では実に人間的な神々の物語が語られていきます。 また、政治学者小室直樹氏は、別の書籍、おそらく、『日本人のための宗教原論』あたりで、「幼少期の子供にとっての、父親の力強さと畏怖のイメージ」こそが神のイメージだろうと述べています。ギリシア神話の最高神ゼウスは、明らかに父性を示していますよね。 これはユダヤ教やキリスト教の神のイメージだと考えてもいいと思います。この辺[[w:父なる神]]あたりに面白い記述がありますし、一方でイスラム教は神に父性を見出さない、などの興味深い分析も書かれています。 また、RPGゲーム『真・女神転生』では、裏設定ですが、作中の「悪魔」とは、力の象徴であり、それは父親を暗喩しているというコンセプトがあります（たしか公式ファンブック『CLUB邪教の館』あたりに記載がある）。だからこのゲームの主人公は、父親がいない母子家庭の子供だという事になっています。 }} {{コラム|ゲームにおけるキャラクター| ゲームの世界は、ソーシャルゲームや美少女ゲーム等はありますが、一般的にはキャラクター重視のメディアではないようです。シューティングゲーム『ゼビウス』のキャラクター性とか、『平安京エイリアン』のキャラクター性など、想像力を最大限に駆使すれば見出せないことはないですが、常識的にはキャラクターの魅力は提供されてはいないでしょう。 ゲーム学という概念を推進している人達は、ナラティブ（「叙述」という意味）といって、スーパーマリオなどのように作中にストーリー説明文が無いゲームのことを説明しているようです。 今現在では、可愛いキャラクターや恰好いいキャラクターを作品に取り込めるのなら、それを除外する必要はないでしょう。しかし現実の人気ゲームでは、キャラクター性があいまい、あるいはほとんど見出せないゲームも多いですよね。 ゲームのキャラクターは、開発途上で変更される可能性もある。海外展開しているゲームは、相手国の風習、社会状況に合わせて、キャラクター設定を変える場合もある。 今現在は、ソーシャルゲームでもキャラクターゲームは人気ですが、昔はそうではありませんでした。1990年代は、多くのゲームファンの間では、「キャラクターゲームはつまらない」と言われていました。 2002年にシリーズ発売開始されたRPG『ドットハック』シリーズの企画コンセプトは、面白いキャラクターゲームを実現することであり、2003年当時の社長（松山洋）がラジオ番組『ドットハックレイディオ』に出演した時に、「キャラクターゲームがつまらない」という一般的に言われている常識を打破したい、それがコンセプトだ、と述べていました。 しかし実際には1990年時点で魅力的なキャラクターゲームもありましたし、大ヒットすることは無くても、一部の大きな人気は得られていたようです。 }} {{コラム|企画が実制作に移ること| 1990年代後半に書籍を出し始めた、元ゲーム業界人・阿部広樹氏は、ゲーム会社から請け負って、そこで頓挫した、或いは難航した企画を練り直しする仕事をしていたようです。彼の著作ではその経験、経緯が語られています。 扱った一つの企画が、ガンダム風の巨大ロボット操作ゲームで、企画として完成度の高いものでした。 主要機体の巨大ロボットのグラフィック設定画は線画が完成していて、機体パイロットである主人公の顔グラフィック線画もある、ロボットの設定サイズ（「全長○○メートル」、「主要武器：○○」など）なども含む、仕様書がすでに用意されていました。 機体の名前には「メタトロン」や（たしか）「サンダルフォン」と、ネットの普及していなかった当時では調べるのにも手間のかかるユダヤ教の大天使の名前がつけられていました。 阿部氏も、このゲームは実現するだろうと、期待を込めて企画を進めていたようです。 しかし現実にはこのロボットゲーム企画は対象のゲーム会社では採用されず、実際に制作されることはありませんでした。このようにゲームの企画は、企画だけで終了してしまうものが沢山あります。 一般的に商業ゲームの製作は、本当にペイするかどうか、経営者や出資者の審査、判断の上、実制作に取り掛かるでしょう。 企画を作る方も仕事として取り組んでいるのですから、「没になるかもしれない」といって手抜きするはずもなく、内容的にも、前設定の完成度としても、どれも相当の力と手間暇をかけて企画を練りこんでゆくでしょう。 しかし結果は結果としてありますよね。採用される保証はないしされないほうが実際多い。その判断が正しかったかどうかはまた別の話ですがね。 }} {{コラム|他業種、一般的な意味での『企画書』| 企画書にもいろいろな段階があります。 #本当に企画の初期段階の、内部関係者しか見ない、思いつきを書きなぐったような企画提案の書類（厚さはせいぜい2～3ページくらいまで？） #企画が熟成してスポンサーや外部に見せられるようになった段階、もしくはその直前くらいの企画書（10ページを超える程度） #パワーポイントなどを使ってプロジェクタ－で見せるプレゼン資料の「企画書」 多くの業界の企画書で学生や外部の人間が見るのは 2.か 3.でしょう。 1990年代後半のゲーム評論家の阿部広樹の他者との共著による書籍によると、彼はゲーム業界で企画に関するトラブルを解決する仕事をしていたようですが、ある案件で、「当時の人気アニメ声優を起用！」など書かれた企画書をトラブル解決のために扱いましたが、彼らが調査した時には相手先のアニメ声優および声優事務所には全く話が行っておらず、対応にも難航したようです。ただ、本Wikiの別の場所でも指摘しましたが、企画時点では、その手の手続きを踏む必要はないでしょう。企画は企画にすぎませんし、実現の見通しが大きくはないその時点で話を持ってこられても、声優も事務所も、対応しようがないと思う。ただ、前編集者の記述では、許可をとれそうな見込みもないと書いてあるから、よほどのビッグネーム声優、要するにその声優の知名度だけをあてにしている企画ですから、悪い企画の例として非難されても仕方ないのかもしれません。しかし現編集者がさらに邪推、想像するに、彼らに企画トラブルの解決を依頼したゲーム会社は、自分たちは零細で知名度もパワーもないので、とてもその有名声優にはアクセスできない、ですからトラブル解決を稼業にしている業者なら、上手にその声優にアクセスしてくれるのでは？という期待があったのではないでしょうか？だとしたら、この事案に対する阿部氏らの態度、そして後になってわざわざ自らの著書でその出来事、関係者を愚弄して、それで自分たちが正しいかのように言うこの人物の姿勢は、職業人、仕事人として問題があるのではないでしょうか？ さて、ある程度企画が本格化してくると、スポンサーに提示するプレゼン用の資料とは別に、詳細な設定や企画意図を説明する、「詳述企画書（ここでの仮の名称）」も作られていきます。この書類は今後の作業のためのひな型の意味もあり、具体的にどんなキャラクターが出てくるか、イラストなども描かれます。 因みに、「ゲーム　企画書」でグーグル検索してみると、企画書としては 1.~3. そして今書いた「詳述企画書」が混然と表示され、書類として種類や趣旨は明確化されていないようです。企業が求職者を採用するために、企画書を求める場合は、プレゼン資料が最適のようですね。採用担当者にとって一番読みやすい資料だからでしょう。 企画書として、説得力のある内容なら、採用され実制作に移る可能性も高くなるのでしょうね。そのために指摘される事として、冒頭部分で、この企画と既存の作品の違い、今までの状況からの改善点、そして実際の改良の実現の見通しと方針を示すといい様です。これは「企画意図」や「コンセプト」と呼ばれますね。 「改善点→（競合他社の）現状説明→改善案の詳細」を、詳細企画書で段階的に説明するといいですね。新聞記事の書き方で、起承転結ならぬ「結・起・承」（けつきしょう）というのがあるので、それを参考にするのもいいでしょう。 また、売り込み先の消費者として想定しているターゲット層の指定も必要です。年齢はいくつくらいなのか、性別は男性か女性か、などですね。 企画の詳細を作りこんである場合や、すでにゲームソフトを実装してある場合のシステムの説明では、単にフローチャートを図示するだけでなく、そのシステムでプレイヤーは何ができるのか、簡単な遊び方の概要説明、等を加えるといいですね。 }} {{コラム|日産自動車の社内講習でのアニメーション業界人の講演| どこの企業でも社員向けの講習会はそれなりにあるでしょうが、日産自動車では過去、アニメーション制作会社の幹部を招いて、営業マンや企画職の社員のために講演してもらったことがあるようです。 テレビアニメーション『輪廻のラグランジェ』が2012年に放映されていた前後、日産が取材協力として制作に参加していたので、CG雑誌で、日産の講演会の様子が紹介されていました。 アニメーション業界では、実在しない物体や機械のイメージを、メカニック設定などで詳細にイメージを作り、絵コンテマンや、原画・動画のスタッフ間でその具体設計を共有するので、自動車製造業界でも参考になる要素があると考えられたようです。 日産の担当者は、制作会社の幹部の講演会に手ごたえを感じたので、もっと話を聞かせてほしいと要望すると、『輪廻のラグランジェ』の製作会社を紹介してくれたので、その会社にも講演をお願いし、さらに制作会社側の取材協力にも積極的に応じて、異業種同士のコラボレーションが形成されていったようです。 }} さて、ゲームの『仕様書』はそのゲームの設計図なので、起こりうる全てのパターンを網羅して設計を指定する必要があります…と言いたいところですが、そもそも本当にすべての操作に対する反応をもれなく記述できるのか? しかしできる出来ないにかかわらず、創作物が世に出れば、それはコンピューターアプリケーションとして、ユーザーに自由に操作される。その時仕様と創作物が、合理的に網羅的に作られていれば、プレーヤーはストレスなく、ゲームを楽しむ事が出来るでしょう。 ;検品、検収 さて、一般に技術系の業界では、図面などの設計図は、検品のさいのチェックリストを兼ねています。（ただし、ゲーム業界での「仕様書」が検品チェックリストを兼ねているかどうかは、2022/01時点、著者側の調査不足で不明。） しかし検品自体はゲーム業界でも行っている。協力会社から納品されたプログラムも、仕様を満たしているかチェックするだろう。 そしてチェックを通ったら、合格した製品として正式に受け取る。 納品物を合格として認めて受け取ることを「検収」（けんしゅう）という。（ゲーム業界でも）<ref name="creator_work:77">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、77ページ</ref>。ゲームの仕様書は、この検収を考慮に入れて書くのがいいだろう。 つまり逆に納品物が合格していないと判断されると、受け入れない、検収しない、納品者に作り直しを要求することになるだろう<ref>蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、76ページ</ref>。 商業ゲーム界では、営業マンが見積もりをするときの根拠は、仕様書、という事になる<ref name="creator_work:77" />。 外注テストに関しては、仕様書では不十分で、テスト用の別資料を用意する<ref name="gpd9" />。 バグチェックを外注しない場合は、「仕様書」を根拠にする場合が多いという<ref>吉冨賢介『ゲームプランナー入門』、P20およびP199</ref>。 つまりやはり、製品の仕様の基盤は仕様書、正しい仕様は、仕様書に書かれている事だという事になる。 開発後半のデバッグ段階などのバグチェックの段階に入る前に、仕様書を最新のゲームの状態とそろえる<ref>吉冨賢介『ゲームプランナー入門』、P238</ref>。つまりこれは、ゲームの仕様が制作過程で変わっていったら、逆に仕様書を書き換えて、実際の仕様に合わせるという事だ。 ==作成工程== ===完成予想図=== 仕様書はゲームの設計図。この書類を基盤にプログラマー、グラフィッカー、製作スタッフたちは作業を進める。しかし、ゲームの場合は、いきなり完成図を明確に決定するのは困難な場合が多い。そうなると方便的に大まかな設計、決定を作っていくという事になるだろう。事実、現実の業界では、大まかな「企画概要書」から詳細な「仕様書」へと、段階的に仕様が決まっていく<ref>『ゲームデザイン プロフェッショナル』、P.141</ref>。 一般的な製造業でもゲーム業界でも、あいまいな指定は事故のもとだと考えている。「とにかく、かっこいい感じでお願いします」なんて言いたくなることもあるけど、危険らしい<ref>『ゲームデザイン プロフェッショナル』、P.60</ref>。相手の「かっこいい」のイメージが、有り得ないものだったりする場合、あるよね^^;;;。 しかし場合によっては例外もあるようだ。裁量とか、阿吽の呼吸といったものも、人間関係ではある。しかし技術を語る場合、設計とは極力あいまいさは排除するものだろう。 ゲームでは、他者に発注するときは、ある程度相手の裁量にゆだねた方が良い場合もある<ref>『ゲームデザイン プロフェッショナル』、P.134</ref>。しかしその場合も、具体的にどういう実装予定のもので、どこに裁量を与えるのか明確にする必要があるという。裁量の発注については、『ゲームデザイン プロフェッショナル』本書を読めと、前編集者は書く。 とにかくこの編集者によると、Wikibooks をはじめ、Web上のWiki には何の価値もないと言う。世の中唯一価値のある文献は市販されている書籍で、Wikiの利用意味はその価値のある素晴らしい書籍を、出典としての記述を参考に、知ることだと言う。 それなら、Wiki書くのなんて辞めて、本屋でも始めたら? ===各機能の予想図の決定=== ソフトウェアの完成予想図は、画面を基準にすると伝わりやすい。 結局パソコン、情報機器を使っている時は画面を見ますからね。 <pre> △△モードの××画面 Aボタン: ダッシュ（走る）。押すとキャラが十字キーの選択方向にダッシュするようにプログラムする Bボタン: ジャンプ。押すとキャラが上方向にジャンプするようにプログラムする </pre> とか、こんな風に書くといいのではないでしょうか。それぞれのモード、画面での機能の満たすべき情報の一覧、を伝えておきたいですね。 ユーザ視点での仕様の事は、「外部仕様」、というようです。 ですからソフトウェア設計者は、各モードについて、画面表示、操作などの外部仕様の一覧を用意したいですね。 これは完成予想図でもある。 一方ソースコードの詳細は、内部仕様ですね。 商業ゲーム界では、原則的に内部仕様に関する書類は、あまり書かないようです。とはいえ設計項目の、ファイルや変数の具体的な記述は、ある程度は仕様書に書かれる。 そして外部仕様は「画面仕様」だけではない。例えばアクションゲームのモンスターの動き方のパターン、RPGのダメージ計算式、プレイヤーが具体的に実感できる仕様は、仕様書において指摘しておきたい。 ゲーム完成予想図とは、各種外部仕様を具体的にわかりやすく記述することになるだろう。 ==※例== 一冊の完成予想図の中で、説明が重複し、同じ記述が複数あるのは好ましくない。 ある記述内容が変更になる時、重複した先も変更しなければいけなくなる<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。 一般的製造業の製図でもこのルールは守られている。一つの末端部分の図面はそれだけで完結し、他の部分を参照しないようにしている。 ではここからは、ウディタのサンプルゲームを具体例に説明しよう。 本来サンプルがあれば仕様書は不要という事になるが、今回は説明用として、サンプルから仕様書を書き起こす。 まずサンプルゲームのメニュー画面、 :相談 :アイテム :特殊技能 :装備 :システム :セーブ と、６つのコマンドがある。 上から4つめの「装備」にカーソルを合わせた状態で決定ボタンを押すとキャラクター選択に移り、十字キーで目的のキャラクターを選択して決定ボタンを押すと、装備画面に移る。 さて、これを仕様書に書くと… 【'''装備キャラクター選択画面'''】 '''遷移直後の変化''' メニュー欄に「装備」コマンド位置に決定後カーソル画像「○○○.bmp」を表示。 キャラクター選択欄のカーソルの点滅が開始。キャラクター選択用の点滅用カーソルの画像は「△△△.bmp」。 '''ボタン押の反応''' キャラ選択欄で十字キーの方向にいる隣または次のキャラクターを選択でき、そのキャラの選択欄にて点滅カーソルが点滅表示される。 決定キーを押すと、選択中キャラクターの『装備部位の選択画面』に移る。 キャンセルキーを押すと『メニュー画面』に移る。 '''画像リソース''' ○○○.bmp :メニュー欄用の決定中カーソル画像 △△△.bmp :キャラクター選択欄用の点滅用カーソル画像 という感じ? その画面とやりとりする相手先の画面の名前と、あとはその画面の読み込むファイル、無駄なことは書かない、他の画面や他ファイルについては書かないほうが良い。 上述の仕様書の書式の参考は、吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、221ページ、の例『各画面の仕様書の例』の書式。 『装備部位の選択画面』に移ったあとの説明は続けて書かず、別途、たとえば『装備フロー仕様書』のような仕様書を作成せよ。 仕様変更で、『装備』コマンドの位置が（サンプルゲームでは上から4番目だが）上から6個目に変わったら、「メニューの装備コマンドは上から4番目にある」と書いた書類は全部作り直しになってしまう、そういう事態を避けたい。 そのため、あえて書類をモジュール化する。全体像は把握しづらくなるが、しかし全体像の把握については、そのための専用フローチャートを書類に設け、修正の手間が波及しないようにする。 例えば… '''装備フロー仕様''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 とかね。 フローチャートの作図をしたい場合は、オフィスソフトのパワーポイントの図形描画の機能で作図が可能。フローチャートの描き方はJISで決まっているので、それを参考に。中学校の技術家庭科でも習うのでその教科書を引っ張り出してきても良い。 例えば装備部分の選択画面は、 :右手 :左手 :身体 :装飾1 :装飾2 これがこう変更されると… :武器 :盾 :頭 :身体 :腕 :装飾 書類上の「装備部位の選択画面の「右手」選択にカーソルの合わさった状態で移る」というような記述はすべて書き直さざるを得ない。 そこでまず、『メニュー画面』や『キャラクター選択画面』では、他画面、例えば『装備部位選択画面』の具体的項目名称とその遷移法は書かないようにする。 『キャラクター選択画面』の仕様は、例えば、「選択キャラクターの『装備部位選択画面』に移る。」と書く。 「画面の変更時は原則、その画面のいちばん上のメニュー項目にカーソルの合わさった状態で画面が移る」と書く。 例えば装備関係のフローを描くときは、 :マップ画面 → 決定ボタン → メニュー画面 → 「装備」を選択で決定ボタン → キャラクター選択 → 決定ボタン → 装備品選択画面 と、続けて書くのはよくない。フローを分解する。 '''メニュー選択フロー''' 【 マップ画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 メニュー画面 】 '''装備関係フロー''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 こういう２分割でしょうか。 意味的にまとまりのある単位ごとに階層をフロー分割したい。 かといって、5分割や10分割と、階層が大きくなりすぎるのは、多重下請けのいんちき業界みたいなので、多くてもせいぜい３分割でしょうね。 そしてフロー同士を結ぶ記述が必要。 【メニュー画面仕様】 '''表示項目リスト''' 決定ボタンで下記の項目を選択できる。 ・相談　　　　　　:決定すればメニュー相談フローに移行 ・アイテム　　　　:決定すればメニューアイテムフローに移行 ・特殊技能　　　　:決定すればメニュー特殊技能フローに移行 ・装備　　　 　:決定すればメニュー装備フローに移行 ・システム　　　　:決定すればメニューシステムフローに移行 ・セーブ　　　 　:決定すればメニューセーブフローに移行 '''非表示項目''' ・キャンセルボタンでマップ画面に戻る とか? なお、各画面での遷移先の画面の説明と、フロー図での遷移先の画面との説明が重複しているけど、まあ気にしない、気にしない^^;;;。 参考文献の『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』の209ページ「状態遷移フローの例」と211ページ「各画面の仕様書の例」とでも、遷移先の画面の説明はそれぞれ重複しています。まあ場合によってはいつものようにこの後の記述でそこそこ言い訳するかもしれないけど…^^;;; ;一枚の図面の中での重複は、すじ肉大先生が許してくださる^^ というのは、例えば機能の似たものを二つ作る時、2個目の説明では、「○○については△△と同じ」と、書けるからね<ref name="aps229">吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ</ref>。 同じ一枚の図面なら、これで良い。 「○○については△△と同じ」「～～～と同じ」のように書いて具体的には書かない。<ref name="aps229" />。 ;その他 画面名やファイル名の名前は、具体的にしたい<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。 たとえば、上述のウディタのサンプルゲームの画面は :「マップ画面」、「メニュー画面」、「装備キャラクター選択画面」、「装備部位選択画面」と、したいね。 例えば 「画面1」、「画面2」、「画面3」、… とか、 「メイン画面」、「メニュー画面」、「サブメニュー画面1」、「サブメニュー画面2」、… にしたいときはあるし、事実上これは、命名の手間は省けるんだけど、他人に伝わりにくいので、ここは少し手間をかけて、具体的に内容ある命名にしたい。 {{コラム|| 法律の設計でも、相互参照が増えると、その法律の構造自体の複雑さが増加する現象が知られています。近年、世界各国でIT的な考え方を使って法律の設計論を研究しようという学問分野があり、その学問でそう指摘されています[https://www.nature.com/articles/s41598-020-73623-x Daniel Martin Katz, Corinna Coupette, Janis Beckedorf & Dirk Hartung "Complex societies and the growth of the law" , nature.com, Published: 30 October 2020 ]。これらのIT的な法学では、法律中の単語数、階層数、法律間の相互引用数が多ければ多いほど、その法律の構造は複雑になると考えられています。ご参考に。 }} ====要求事項書==== IT界の一般的な慣習として、「要求事項」とは、完成品の満たすべき要件を示しています。 商業ゲーム界ではどうでしょうかね。E.Suj.の調査では、商業ゲーム界で要求事項書が作られている証拠は見つけられなかったようです。 個人でのゲーム制作ではまず不要な書類でしょう。 基本的には、要求事項書とは、発注者と受注者の両方の打ち合わせによって作られていきます。 ただゲーム界では、発注書で、成果物が作中でどういう目的で使われるのか、意図・用途を伝えるのがいいようです<ref name="gp296" />。 ==== データ暫定値 ==== ゲーム中のデータの数値、例えばRPG武器の攻撃力、等、はすべての項目の想定値を設計図に記述します<ref>https://www.youtube.com/watch?v=KVdtNiB_lIQ 2020年3月14日に閲覧</ref>。 CSVファイルを作りましょうか、ソフトはエクセル? 【剣データ暫定値】 銅の剣: 攻撃力 7 鉄の剣: 攻撃力 18 ハガネの剣: 攻撃力 37 ミスリルの剣: 攻撃力 70 ほのおの剣: 攻撃力 57 （※ 剣ではランク5は欠番とする） デスブリンガー: 攻撃力 150 備前長船: 攻撃力 250 聖剣エクスカリバー: 攻撃力 450 魔剣レーヴァテイン: 攻撃力 450 具体的な指定も一緒に書いて、もちろん今後の調整で変更する可能性はあります。 ====データ仕様書==== データ仕様書とは、たとえばRPGなら :攻撃力: 敵の守備力との計算によってダメージを算出する のようなパラメータ計算式の定義を行った仕様書のことです<ref name="gpnt92">STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日初版第2刷発行、92ページ</ref>。 そして、この「データ仕様書」は、デバッグのための資料になります。デバッガーが、この資料と実際の動作を照合することで、仕様どおりにプログラムが動いているかを確認します<ref name="gpnt92" />。 書籍『ゲームプランナーの新しい教科書』では、アイテム（「やくそう」や「毒消し」などの）価格の「100」（100ゴールド）や「200」（200ゴールド）の具体値のあるデータ表のことを「仕様書」と言っている。この本では、本当は「100」になるべき数値が「200」になっている場合 「仕様書」で簡単に確認できる、記述されている。 一般にRPGの仕様書は非常に厚く、大冊になるという。オタキング岡田斗司夫氏が聞いたところによると、（出典は『オタク学講座』など）、ある有名RPGの仕様書は、書類の量をページ数ではなくKg で数えていたという。（しかし、1kg=何枚かな?^^）。有名作の仕様書は、分厚い電話帳のようなものが何冊もあるらしいです。データ台帳、 各種パラメータ、設計の背景の要求事項、まあいろいろ書かれているのでしょうね。 ;攻略本と仕様書 ゲーム攻略本にある、アイテムの効果値や、敵の能力値といった数値の一覧は、おそらくそのゲームのデータ台帳から転記されているのでしょう。 プログラム部分の設計図である仕様書も参考になるでしょうが、データ台帳には、直接的な数値が書かれています。 しかし実際の市販の攻略本には正しくない記述もある。制作側から正しいデータ、情報を手に入れられなかった場合もあるでしょう。 ==プランナーが事務方の現場で動いているスタッフとみて良いでしょう== ゲーム業界では、プランナーと言われる人が、連絡網の中心になって、いろいろな部署のあいだの情報伝達をします。 <div style="font-size:120%;"> <pre> ディレクター　━━━　プランナー　━━━━┳━　プログラマ 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　グラフィッカー 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　デバッガー </pre> </div> ディレクターが現実の制作のトップ、そしてその後ろにプロデューサー、管理職など、商業コンテンツとしての責任者がいることになりますね。 このプランナーは、ゲーム業界の場合、中間管理職? のような権限があり、各部署（プログラマ部署やグラフィッカー部署など）やディレクター（監督）の間で、様々な調整や連絡をしていきます。 アニメーション業界で言えば、制作進行とか、制作デスク、のような立場でしょうか。 「プランナー」というと、プラン「計画」を練るという意味になりますが、テレビ業界でいう「AD」アシスタントディレクターのようなイメージのほうが近いかもしれません<ref>吉冨賢介『ゲームプランナー入門』、P236</ref>。勿論現場を現実に回すための様々なプランは必要ですね。 ==ゲームに取り込むイラスト、音楽== 商業ゲームで、イラストや音楽、そしてそれ以外でも、他者に何らかの作業を発注する場合、特に常識的、慣習的な発注フォーマットというのは無いようです。割と場当たり的に、作品、状況にあった発注形態がとられているのでしょう<ref>『ゲームデザイン プロフェッショナル』、P.146</ref>。 音楽やイラストの提供を他者に求める場合は、もちろんその作品に関するその絵描きや音楽家の関わり方にもよりますが、そのゲーム内でどのように絵や音楽を使うか、明確に説明できることが望ましいですね。 様々な事象項目チェックリストも用意したい<ref>『ゲームデザイン プロフェッショナル』、P.159</ref>。 ===他者に委ねる場合=== 商業としても、あるいは同人としても、割と外部の他者に描いてもらったイラストや音楽をゲームに取り込むことは多いでしょう。商業ならそれこそ、対価を明示したうえで外注、ということになる。 例えば他者にイラストをお願いするときは… :構図、 :希望のポーズ、 :塗り方、 :テイスト、 この辺を相手に伝えておきたいですね<ref name="gpd128">『ゲームプランとデザインの教科書』、P.128</ref>。 さて、ゲームには美術的な素材として、イラストレーション、アニメーション、コミック（漫画）などがありますが、これらはもちろん絵画としての共通点はありますが、一般的にはそれぞれ別分野と見なした方がいいようです<ref name="gpd128" />。 特に商業の世界では、美術作品という共通点はあっても、他分野の創作は手間や方法論の整備や熟練などの問題で、それぞれの専門家に依頼するのが妥当でしょう<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P168</ref>。 そして、商業ゲーム界では、あるいはそれ以外でもあるかもしれませんが、キャラクターイラストを描いてもらうときは、実在のアイドルやモデルの名前をイメージとして、提示する場合もある<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 あるいは仮に自分は絵が上手に描けなかったとしても、ラフな簡単な絵をかいて、どんなキャラクターのどんな構図を描いてほしいか、大体の要望を伝える、ということもありますし、また、その構図が作中でどういう目的で使われるか、意図用途を伝える<ref name="gp296" />、というのも意義がありますね。 ただ他人に何かを伝えるということは、一般的な意味でも難しいことですよね。ここでイラスト描きに希望を伝えるにしても、長文の書類だと読んでもらえないこともあるし、口頭でもその相手にとって分かりにくい説明というのがある。 ですから、出来るだけ、ですね、わかり易く受け入れやすい言及が必要です<ref>『ゲームデザイン プロフェッショナル』、P295</ref>。 ;アダルトゲーム アダルトゲームでは、シナリオも外注の場合があるらしい<ref>畑大典著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P129</ref>。しかしむしろこれは企画販売の会社と、制作主体が別だという話ではないだろうか？ ところで皆さんは、アダルトゲームって、プレイします?^^;;; ;そもそもイラストの発注者は、絵描きの頬を札びらで叩いて描かせているわけ? 基本的には有償のイラストの場合は、発注者の指定にイラストレーターは従うでしょう。それでも媒体にもよりますけどね。ゲームの場合は、発注者の指定に従う縛りは大きいと見ていいですね。 そもそも要求事項がどうのとか、書類に関する理屈をグダグダ述べれば、さらにこの縛りは強くなりますね。事実上はその辺の判断はあいまいなのですが、発注者は一般的にリテイク（書き直し）を出す権利があるとみて良い。 例えばイラストの仕事を有償で得たとして、実際にはそのイラストの使われ方も問題になりますが、「セーラー服の少女を描いてください」と頼まれてそのイラストを引き受けたら、ブレザー服の少女を描いて提出するのは不適切でしょう。リテイクを出される<ref>『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.208</ref>。それどころか、仮にセーラー服の少女を描いたとしても、発注元がそのイラストの質が良くないと判断したら、一般的にはリテイクを出してよいと見られています。しかしもう一つ問題があって、そのイラストレーターはそもそもなぜブレザー少女を描いたのか？そしてもう一つ、現編集者の推奨としては、イラストレーターはリテイクの扱いについて、具体的にどう扱うか、発注者とよく話し合ってある程度ルールを明確にしておいた方が良いと思います。 前編集者はこの問題について、社会のルールがどうのとか、自称イラストレーターがどうのとか、教育がどうのとか、2005以前がどうのとか、いつものように狂った理屈を長々書いていますが、全て愚か者の自己本位なたわごとでしょう。 {{コラム|絵の仕事とはどんな仕事?| さて、前編集者 Suj. は、このコラムで、2005~2008 にかけて、絵の仕事を、「自由に絵が描ける」「漫画や絵の仕事は、競争を気にしなくていい」と、思い込んでいる人がいたと書いているけど、これ本当の事かね? どうせいつもの[[w:かかし論法]]じゃあないの? そもそもなんでこの話では、大好きな出典出さないわけ? しかもこの人物は、教育に携わる資格なんてまるでない性格異常者なのに、なぜか偉そうに大上段に教育論を語りたがる。 そもそもそんな人がいるかどうかも怪しいが、それは小中高の美術教育、自由に絵を描かせる授業方針のせいなんだって。 この人物の妄想世界では、「小学校の図工のような自由な仕事 <nowiki>=</nowiki> プロ絵描き」と思い込んでいる人がいるんだって。ほんとかね? 何かこの人物が大好きな江川達也もそんなこと書いていたようだよ。 2001~2005の雑誌コラム、スパ? 漫画業界について「漫画家は、競争が無くて自由に漫画を描ける仕事」、という言説に怒っているんだって。しかしほんとにそんな主張があったの？江川もストローマン叩いてるだけじゃあない？そしてわざわざゆとり教育に言及? インチキ臭いね。 しかも江川が書くには、「漫画家はとても競争の厳しい世界だ。」ってことだけど、まあそんな部分はあるけど、結局はそこで生き残って飯食ってる俺は偉いって話でしょ? 江川ってほんとにいい漫画描いてる? 単にインチキな業界人に気に入られているだけでしょ? あと小林よしのりは、ゴーマニズム（そろそろマジメニズムになったら?）宣言で、プロデビュー前、「マンガ出版社は、漫画家が死ぬまで面倒を見てくれる、まるで公務員のような終身雇用の業界が漫画業界」と思い込んでいた、と、描いていたって言うけど、そうね、私もこんな記述昔読んだような気はするけど… しかし、E.Suj.はこの小林の当時の考えはよくて、今同じ様な考えを持つと阿保馬鹿書くわけ? しかもほんとにこんな考えの人が今いるのかね? 出典くれない? まあ確かに実際に今現在、そんな考えの人はひょっとしたらいるかもしれないけど…。しかしここでわざわざその話題をコラムとやらにして、彼らを愚弄する意味なんてある? }} ===特定の絵に関して、誰でも質やクオリテイを語ることはできる。しかしそれは主観的な判断に過ぎない上、自分自身が神のように凄い絵を描けるわけではない。だからあまり威張って断定的にそれを語るなよな。=== 事実上今現在の商業ゲーム界の主流の絵は、まずCGであり、手描きの場合は細密かつCG特有のグラデーション、その他最新のテクニックを駆使した多色の華やかな絵柄 でしょう。 その絵が上手に描かれたいいものであれば、ゲーム業界の馬鹿馬鹿しい連中は、この絵はクオリティが高い、などと宣うわけです。 で、その条件から外れた絵を見ると、彼らは下手だ下手だと騒ぎだすのでしょう。 ;アニメーション、漫画、CGイラストレーション 上記の3つの絵画は、多少質が異なるものになるでしょう。前者二つは一枚絵で完結していないので、ある程度簡略化した手間をかけない描き方がなされる。一枚絵のイラストはそれだけで完結なので、事実かなり手間と時間はかける事が出来る。 しかしどちらにしろ、時間と手間は様々な諸事情のバランスで、それが選ばれ決定されますね。 特定の絵が上手いとか下手なことにこだわり、朝から晩までその議論ばかりしている愚か者は多いですが、事実上、時間と手間の大小にかかわらず、特定の人の心を打つ絵というのはある。 しかしやはりその心の動き自体が、主観的なものであるでしょう。 ;後日修正 手間と時間をかけた絵が欲しいなら、後日修正という道はありますね。商業漫画でもアニメーションでも、後から修正を加えて絵の質を高めることはあるでしょう。 基本的にはあらゆる物事が、時間と手間をかけたことによって評価は高まりますが、しかし我々の時間も労力も無限ではない。いいバランスで、いい完成度で、多くの物は創作終了されています。 ===芸術、自由、文化。そして娯楽、商業作品=== さて、前編集者Suj. は常に自分にとって都合のいい主張をしている市販本を探し、そしてそれが見つかったら購入し（しかしそのお金はどこから出ているのだろう?）、そしてそれを斜め読みした後、このサイトでクオリティ最悪の駄文を書き散らしているのだが、彼の愛読書には、ゲーム作りに必要な資質は、作家性と「人を楽しませたいと思う気持ち」<ref name="gpl246">『ゲームプランナー集中講座』、P246</ref>、だと、書かれている、らしい。 まあこのサイトを見てわかるとおり、彼自身はその二つとも全く持ち合わせていないのだが… そしてその馬鹿馬鹿しい本には、ゲーム会社の採用担当も、ゲーム会社自体も、クリエーターに自己表現は求めていない、と書いている<ref name="gpl246" />。つまり、ゲーム会社の幹部たちに都合のいい作業を安い賃金でしてくれる、奴隷が欲しいということだろう。 そして、E.Suj,はとにかく他人の褌をはいて威張ること以外何もしないのだが、彼のイラスト分野の愛読書には、依頼内容を無視して自由に絵を描こうとする人は、「プロ」ではなく「芸術家」、と書かれている<ref> 『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.198</ref>（らしい）。 ====芸術と商業漫画==== 漫画『サルでも描けるまんが教室』には、芸術と商業漫画に関する面白い記述がありました。 {{コラム|竹熊と相原のサル漫| 一応この漫画を知らない人のために少し説明すると、竹熊健太郎氏が原作、相原コージ氏が作画、まあ必ずきっかり分業がなされているかはわかりませんが、この二人が漫画内で主人公にもなって、商業漫画ハウツーギャクが展開します。 相原「む～…。俺たちはこんなくだらない漫画を描いてていいのだろうか…」 竹熊「どうした相原？」 相原「俺たちはもっと本質的な作品を作るべきではないか？例えば…資本主義などという下らない次元にとらわれてはいけないのではないだろうか…俺たちは国や大企業におどらされているのではないか？やはり漫画にも芸術は必要だろう…」 竹熊「バッキャローー!!!（ガッと、相原を殴る）」 相原「な、何をする…」 竹熊「お前は芸術をぜんぜん分かっちゃあいない！」 相原「そんなことない…」 竹熊「じゃあ、お前のいう芸術とは何か、言ってみろ？」 相原「それはー…、人間の内面の…真実ってゆうか…」 竹熊「にんげんのぉー、ないめんの～しんじつぅ～??? あのなー、お前は権威にとらわれてはいけないとはいうが、じゃあお前のその意見は、どこかの芸術大学の教授の権威にすがっているだけではないのか！？」 相原「そんなことない…お前こそ、政府や商業メデイアによる宣伝のつくった権威にとらわれているじゃないか。」 竹熊「ああそうかね。だけどお前だって、芸術教授の権威にあやかって自分も地位と名誉が欲しいだけだし、結局、お前もカネが欲しいだけなのだ。」 ……と、いうような、もちろんこの漫画は第一にギャグマンガですが、商業漫画界やアニメーション界での、芸術という言葉の捉え方をよく示していると思います。 例えば、『ねじ式』という漫画に芸術性があると評価された、つげ義春さんも自身の漫画が芸術でくくられることを嫌っていました。漫画家は芸術家ではなくて職人だ、と語っていたインタビュー記事を読んだことがあります。 しかし実はこのサル漫、最新最終作『サルまん2.0』ではさらに面白い展開を迎えています。 少し書きますが、「とんち番長」という漫画で一世を風靡した竹熊と相原（もちろんこの漫画内の、ですよ）だったが、やがて落ちぶれ、それでも再起を図って、漫画出版社に持ち込みする。 そこでの編集者が採用を断る時の言葉。 「いやいや先生。我々の雑誌では、先生たちの高尚な漫画は掲載できませんよ…。読者はみんなほんの愚かな子供たちで、先生たちの高尚な漫画はとてもとても理解できません…」 つまり過去大騒ぎして否定していた芸術側に、いつの間にか落ちぶれて、竹熊と相原は所属していたわけです… }} ====私小説==== {{コラム|基本的に娯楽産業の連中は、芸術という言葉も概念も嫌う| 前コラムでも書きましたが、結局商業アニメーションや漫画界では、娯楽、楽しい或いは扇情的、売れる、ということが重要で、あまり芸術的なことを語ると徹底的に嫌われます。 このコラムの前編集を見てもらえるとわかりますが、前編集の筆者もその感覚に追従して、好きかってなことを書いています。 特に自己探求にこだわった創作は、「私小説」などと呼ばれて揶揄されます。 1998年、オタキング岡田斗司夫の対談集『マジメな話』でも、当時のエヴァンゲリオンの映画版を「私小説」だと、対談相手の小説家・今野敏が批判していました。事実上この作品は衒学的な、疑似芸術作品でした。 やはり何らかの娯楽性、収益性、芸術性の問題が、常に創作作品には付きまとうようです。 さて、例えば、大正文学の売上のベストセラーは、 :倉田百三『出家とその弟子』、 :島田清次郎『地上』、 :賀川豊彦『死線を越えて』、 三大ベストセラーですが、しかし今や彼らは文学史の教科書には、滅多にのりません。せいぜい高校日本史の教科書で、倉田が少し紹介されているくらいです。 現代の教科書でよく大正時代の小説家として紹介される芥川龍之介は、じつは当時は倉田・島田らほどには売れていない作家です。また、「私小説」といわれるジャンルも当初から収益性はない。もっとも、芥川が私小説を書き出したのは晩年のことですが…。 しかし前編集者はこの問題に、毎日新聞の戦略とか、左翼がどうのとか、研究不足がどうのとか、なんかいい加減なこと書いているようですが、まあどうでもいいか。 現編集者は上記の3ベストセラーの、倉田の作品だけ読んだことがある。親鸞の話だったけど、私にとっては底の浅いいい加減な話に見えた。はっきり言って芥川の小説の方が、はるかに意味と深い内容を持っているだろう。 島田清次郎に関しては、「栄光なき天才たち」という漫画で、この人物の詳細と人生が描かれていたのを読んでいる。この漫画の中では彼は、「地上」の最終巻の採用を、編集者に断られている。 }} === ローポリ関連の作画 === 単元『[[ゲームプログラミング/3Dグラフィック#ローポリ制作手法的なこと]]』で説明した。 ==レポートは結論だけを読んでも分かるように書く== レポートなどは、ゲーム業界なら、途中を読み飛ばしても、内容がおおまかに分かるように書きたい。 別に冒頭で結論を述べる必要はありませんが（会社による）、しかし、仮に書類のページの順序どおりに他者が読まなくても、 レポート全体の内容を把握できるように書くのが推奨です。 ==書類は誰でも簡単に理解できるように書きたい== 書類の言葉選択は、「中学生の知識でも理解できる言葉を使う」、のが望ましいですね。言いやすいフレーズ、理解しやすいフレーズ、こういう言語選択も重要です。<ref>『ゲームデザイン プロフェッショナル』、P101</ref> 基本的にゲーム界に限らず、あらゆる場所で、わかり易い言葉を使うことが重要ですし、相手の理解に配慮することは必要でしょう。E.Suj.のように自分が理解できなければ全て相手のせいにし、相手が理解できないのもすべて相手のせいにするのは、一番有り得ない最低の態度でしょう。 == 脚注・参考文献 == 3eh82h619d84o2gzbdchaywdexaje17 206836 206835 2022-08-20T02:59:40Z すじにくシチュー 12058 /* 要求事項書 */ タイトル変更「要求事項」に。ゲーム業界に「要求事項書」は無い。 wikitext text/x-wiki {{substub}}このページの主要執筆者は、ゲーム業界経験者ではないので（2022/1時点）、ここの記述は調べ物としては役立ちません。 2022/1時点でゲームプログラミングと直接の関係ない話題が長い、という問題があるので、より簡潔、かつ分かり易い記事への編集にご協力いただけたら幸いです。もっとも現編集者Hは、解ってるならそれを書いた奴が書き直せ、そもそも余計なことは最初から書くな、…とは思いますが…。 このページは、教科書としてゲームプログラミングの方針を説明する際に、どうしても書類についての説明が必要だから記述されています。現状では、一般IT業界や製造業などの設計図を参考に説明がなされています。 == 本書の目的 == 本書は、ゲームデザイナーのための教科書ではありません。 メインページ、「[[ゲームプログラミング]]」の題名どおり、プログラマーのための教科書です。プログラマーがゲーム制作に興味をもって実際に作り始める際に、調べ物の手間を減らすために書かれた参考書籍です。 ゲームデザインに関する解説を望む方は、別途、他の参考資料に当たってみてください。 ==「仕様書」== ここでいう「仕様書」とは、ゲームの設計図のことです<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.126</ref>。しかも職業的に集団でゲームを作るときの書類です。 ではまず、「設計図」とは何か、について、考えていきましょう。これは普通科高校では学習しない事項です。 ゲーム業界では、「仕様書」を含む書類群の「発注書」には、決められたルールや書式はありません。だから作るゲーム内容や製作チームごとに、適切な発注書のありかたを毎回考える事になります<ref>『ゲームデザイン プロフェッショナル』、P.145</ref>。 職業的なゲーム開発では、一般に :発注 → 実装 → 調整 というプロセスを経て<ref>『ゲームデザイン プロフェッショナル』、P.61</ref>、最終的にとりあえずの完成になります。 ゲーム産業での「仕様書」は、発注の段階での書類です。 ==集団ゲーム制作での解説文== 発売禁止になってしまった書籍（おそらく。しかし何故？）『国際おたく大学―1998年 最前線からの研究報告』（岡田斗司夫ほか、光文社）に書いてあった事例なのですが、G.O.D.と言うイマジニア社のRPGゲームに対する大学生（岡田は当時、大学講師だった）の取材があって、そのGODの開発に参加した劇作家の鴻上尚史（こうかみ しょうじ）氏と、エニックスの堀井雄二（ほりい ゆうじ）氏とが、対談した経緯が、紹介されていました。 劇作家の鴻上は、ゲームに演劇のリアリティを入れようとして、スタッフに「間（ま）を意識したシナリオを書いてほしい」と要求したが、うまく行かずに難航したと体験談を述べています。 対談相手の堀井は、鴻上のその体験談に対し「『（※ここで3秒休止）』とか書くと良いですよ」と、指示書で具体的に書くと良い、とアドバイスした、と、岡田の書籍にある大学生のレポートにあります。 おそらくドラゴンクエストのゲーム開発でも、このように具体的な指定を必要に応じて出していた・いるものと思われます。 21世紀現代の、商業ゲームの現場でも同様であり、書籍『ゲームデザイン プロフェッショナル』にもありますが（※かぎカッコ内が引用）、「もっとかっこよく調整してほしい」という問題であれば、たとえば「もっと目立たせたいので、アニメーションのシルエットを全体的に今より少しだけ大きくしてほしい」<ref name="gp296">『ゲームデザイン プロフェッショナル』、P296</ref>という具体的な指定が妥当でしょう。 == 集団作業に必要な書類 == ===設計図=== IT業界やゲーム業界では、集団作業で制作開始をしようとする際、まず、いきなり設計図を作るのではなく、まず先に試作品（しさくひん、英語で「プロトタイプ」proto-type）のプログラムを作り、企画で考えた各種システムなどのアイデアが有効かどうかを検証します。 そのプロトタイプで、企画のアイデアが本当に有効であるかを確認してから、もし有効だったら、本格的な制作を開始します。 もしかしたら会社によっては、企画会議（もしくは企画の打ち合わせ）よりも先にプロトタイプを作るかもしれません。 さて、会社へのプロトタイプ提出で、制作続行・制作本格化の賛同が会社から得られたとしましょう。 IT業界でも製造業でも、どこの業界でも集団作業で、制作の合意を作るさい、必要な書類は、おおむね、 :作業者用の具体的な「完成予想図」 です。 しかしゲーム業界の場合、いきなり完成予想図に相当する「仕様書」は書けないので、書籍『ゲームデザインプロフェッショナル』によるとまずゲーム中の大まかな実装予定事項を記述した『企画概要書』という書類を作成することもあると言われています<ref>『ゲームデザインプロフェッショナル』、P139</ref>。ただしこの「企画概要書」は、名前に「企画」とはついているものの、どちらかというと仕様書の方針を大まかに打ち合わせするための書類に近いので、いわゆる「企画書」とは異なります。 なお、一般のIT企業でよく書かれる「要求事項書」は、ゲーム書籍では紹介されていないので、おそらくゲーム業界では書かないのが普通だと思われます。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ===ゲーム業界での技術職=== 言葉というのは同じ国の国語でも、その業種や職場、社会集団で、微妙に違った使われ方をすることも多く、技術職、という言葉もゲーム業界での特別な使い方があるようですね。 この業界では、グラフィックデザイナ－やサウンドクリエイターやプログラマーが「技術職」<ref>『ゲームプランとデザインの教科書』、P125</ref>。技術職 = ￢(not)企画職、という事で、プロデュ－サーやプランナーやディレクターなどの「技術職」でない製作スタッフが企画職です。 ただ現編集者はプロデューサーとディレクターは対立する職種だというイメージはありますね。プロデューサーは企画職だろうけど、ディレクターは、"実"制作職ではないかな？ ===企画書=== *PREP法 基本的にビジネス上の書類は、結論を一番先に書く構成法が望ましいですね。もちろん商業ゲーム制作の現場でもそうでしょう。文献『ゲームプランナー入門』では、具体例として、PREP法を紹介しています。 PREP法とは、 :Point（結論）→Reason（理由）→Example（具体例）→Point（結論）。 ほかにもホールパート法やSDS法などがありますが、どれも冒頭で結論を示した後詳細を伝える方法で、ビジネス文書はやはり、その形式が常道でしょう<ref>『ゲームプランナー入門』、P141</ref>。 しかしこの社会、ビジネスが重要なのは事実だが結局、他者の行為や仕事をただ自分の欲望と利益に使い、他者の存在や詳細に興味のない人間は、とにかく結論だけを先に聞きたがるし、それ以外の事には事実上何の興味も持っていないでしょう。 *ゲームのルール 常識的な判断としては、ゲームにはルールがあるものですよね。ルールのないゲームというのは、ふつうあまり考えつかないし、イメージできない。 ですからゲーム企画書としては、ルールの説明が必要になる。キャラクター設定や世界観の解説があったとして、ルール説明がない企画書はふつう受け入れられない<ref>『ゲームプランとデザインの教科書』、P83</ref>。 ただ今ではゲームジャンルの固定化が進んでいるので、ルールはくどくど説明する必要はない、という場合はある。 企画書を誰が書くかという問題もある。業界の内部の重要人物か、全く外部の業界経験の無い人物か。 どちらににろ常識判断としては、ある程度のゲームルールの解説は必要だろう。 *プレイ人数 企画書には、ゲームのプレイ人数の記述も必要<ref>『ゲームプランナー入門』、P159</ref>。 ほんとの昔は、一人か二人でプレイするのがコンピューターゲームだったのですが、もはや時代は変わりましたね。インターネットを駆使して多人数プレイ、ソーシャルゲームなんてものも出てきました。 <!--(:※ ここから先、セクション末尾まで文章の編集者が異なります。編集者Hによる文章です。なお出典のある部分は編集者Hではなく別の編集者Sによるものです。)←すじ肉先輩さー、この記述は無いわ^^;;。だってこれって、みなさーん、以下の馬鹿文はHが書いたんだからね、俺、Sujの文じゃあないよ、馬鹿なのはHであって、俺じゃあないから。Sujはちゃんと出典は全部書いてんだよ^^、って言ってるのと同じだよね^^;;;;;--> さて、企画書に関しては、よくない企画の典型例というのはあるようですね。特に特定人物のネームバリューに依存した企画は良くないし、批判の対象になることも多いようです。ゲームとしては、イラストレーターや声優に超大物を起用することを強調した企画書ですね。 出典として『テリー伊藤のお笑い大蔵省極秘情報』あたり、確実に特定はできませんが、木村拓也のタレント性に頼った企画は、著者のテリー伊藤によってよくない企画の例として指摘されていたようです。 もっともテリー伊藤という人物自身が、ビートたけしの面白さ、彼を起用したことの良さによって世に出て知られるようになった人物なので、そんな事言っていいのかね、などと現編集者は少し思いますが…。 また今回の本題、ゲーム業界でもそういう良くない企画書が提出されることは多いようです。元ゲーム業界人でゲーム評論家の あべひろき が、90年代の著書で、過去にゲーム関連会社に勤務してたときの体験談を書いています。企画書の精査をしているときに、「人気声優の○○さん起用！」と書かれていたものがあったが、あべ氏がその声優の所属する声優事務所に確認の電話をとると、なんの商談も声優とも事務所ともされていなかったという事です。 もっとも企画書とは企画に過ぎないのではないだろうか？これらの他人のネームバリューに頼った企画が良くないのは事実だが、企画が通って実現する見込みが決定する以前は、むしろ声優本人や事務所にアクセスすることはないのが普通だろう。 もちろん企画者がその事務者や声優と懇意にしてる場合は、あらかじめ話をする可能性はあるが、しかし企画段階ではそもそも現実のビジネスになる可能性はそれほど高くない。声優や事務所にとってもその段階でもっともらしく話をされても、むしろ困惑するだけではないだろうか？ ただこういう他人任せの企画は、「プロデューサー的企画」と呼ばれるようです<ref>吉冨賢介『ゲームプランナー入門』、P71</ref>。クリエイティブな企画とは言えないわけですが、しかし商業的な娯楽作品には、クリエイターだけではなく、プロデューサーも絶対必要でしょう。 一般に企画でも他の仕事でも、他者の力や権威、その後の作業などに頼り切った態度は、どんな場所でも嫌われて批判されますし、それは職業の場だけではないでしょう。 また、ゲームの企画に関してもう一つの話題として、アメリカでも売ることに成功したドンキーコングの、ディレクターの宮本茂（任天堂）は、「人間の生理的なところを体感できるゲームを作れば、それがユニバーサル」、だと、語っていたようです<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P89</ref>。 ===「仕様書」、「企画書」=== 商業的なゲーム制作では、一般に、 発注 → 実装 → 調整 の過程を辿ります。 そして発注段階で重要な書類は、「企画書」と「仕様書」の二つです。まず『企画書』で作るゲームのコンセプトを固めてから、あとで『仕様書』で、より詳細に内容をを決める、という順序をとります<ref>『ゲームプランとデザインの教科書』、P43およびP45</ref>。 企画書<ref name="gcs72">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、72ページ</ref>は社内だけでなく協力会社にも見せる資料であり、開発者・協力者に対して手短かに、そのゲームの全体的なコンセプトを伝えるためのものです。 仕様書は、ゲーム制作では「設計図」であり、「完成予想図」であるといっていいでしょう。企画書よりより詳細にゲームの内容を決め、指定しています。 さて、話を進める前に、商業的に集団でゲームを作る場合の他の書類や必要事項の名称について、ここで簡単に書いておきます。 まず「発注書」とは，発注時に作られる、必要な書類群のことでしょう。「企画書」と「仕様書」も含みます。 「指示書」はむしろ、実装や調整段階でなされる、具体的なゲーム演出上の指定でしょうね。 試作品（しさくひん、英語で「プロトタイプ」proto-type）や企画会議（もしくは企画の打ち合わせ）なんて言葉も出てきますが、こういうのはあえてクドクド説明しなくても、直感的にイメージわきますよね。 『企画概要書』とは企画書とは異なるもので、仕様書に準ずる書類で、仕様書の方針を大まかに打ち合わせするためゲーム中の大まかな実装予定事項を記述している書類です。 『原案書』<ref name="gcs72" />は社内だけで企画がペイするかどうかの検討を決算書などを参考に分析・会議するための書類です。 こういう書類や用語に関する言葉の使い方は、商業的集団的なゲーム制作の場として妥当と思われるものをまとめてみましたが、もちろん職場によって、会社によって使い方や意味が微妙に変わってくる場合はあるでしょう。 さらにゲーム以外の一般IT業界や製造業でもそれぞれの慣習があり、今回の説明が成り立たない、そしてそこはより一般的な職場ですから、それぞれより一般的な言葉の使い方があると思います。 さて、コンセプトの具体例として、書籍『ゲームプランとデザインの教科書』によると、たとえば『ポケットモンスター』のメインのコンセプトは、「通信ケーブルを伝わって、ポケモンが入ったカプセルが移動して交換する」、が始まりだそうです<ref>『ゲームプランとデザインの教科書』、P109</ref>。 また、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、『メタルギア』シリーズのコンセプトは、「敵に見つからないように進む」、とのことですね<ref>吉冨賢介『ゲームプランナー入門』、P108</ref>。 イラストや音楽の発注は、一般的には企画が決まった後でしょう。 そもそもイラストレーションや音楽を対価を払って提供してもらったとして、それを実作品に使用しないのは、作者にとっては不本意なことだと思います。 アニメーターの故大塚康生氏は、アニメーション演出家が安易にアニメーターに大量の絵を描かせ、そこからいいもの、利用できるものだけ取捨選択する方法を批判していましたし、一般的に手仕事には作者の思い入れがありますから、安易な大量生産品と同じ取り扱いはできないと思います。 もっとも一方で、あるアメリカの日本人アニメーターが、同僚の日本人アニメーターが、自分の描いたものを日本の家族や友人たちが見ることができないことを不満に思っていた、という事を批判的に語っていたのを、現編集者は聞いたことがあります。 しかしゲームの場合、例外的にイラストや音楽が先行する場合はありますね。 RPG『クロノトリガー』は、企画の当初からイラストレーターをつとめた漫画家・鳥山明のイラストがあって、それをもとに作品を作ったと、鳥山のマンガの編集者であった元・少年ジャンプ編集の鳥嶋和彦は述べています。<ref name="tskdq">[https://news.denfaminicogamer.jp/projectbook/torishima/2]</ref>決めシーンなどのキービジュアルを先に決め、それに合うように設定を練りこんでいくという方式で、クロノは作られたようです。 企画書の制作ツールとしては、清書としては、オフィスソフトの「PowerPoint」と、アドビの「Illustrator」、または、アドビのソフトウェアは高価なので代わりにフリーソフトの「Inkscape」および「GIMP」がよく使われます<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日第1版第1刷、P.281</ref>。なお、Illustrator および Inkscape は、ベクトル画像を描画するソフトウェアです。 ただし、下書きなどでは、タッチペンと何らかの画像ソフト、またはタッチペン用メモソフトで下書きすることもあります。 業界で、ゲームプランナーと呼ばれる職種は、仕様書作成や進捗管理、テスト&デバッグ、スタッフとのコミュニケーション、などが仕事ですね<ref name="gpd9">『ゲームプランとデザインの教科書』、P.9</ref>。 また、ゲーム制作に関して、だれもが様々なアイディアを持っていると思いますが、メモを取って、もし忘れてもメモで思い出せるようにするといいですね<ref>『ゲームプランとデザインの教科書』、P.20</ref>。 アマチュアの企画なら、実際にプロトタイプ（プレイできる試作品のこと）を作って実作品で企画、仕様を説明してしまったほうが早いかもしれません。 参考文献『ゲームプランとデザインの教科書』でも、（試作品を）「ゲームプランナーを志す中で企画書や仕様書を書きながら、ぜひ自分でも作ってみましょう。プログラムや3Dモデルを簡単なものでいいので作ってゲームに仕上げてみましょう。」と述べています<ref>『ゲームプランとデザインの教科書』、P.3</ref>。 上記の本の図表によると、企画書では、「競合情報」、「世界観」、「ストーリー」なども記述して欲しいようです<ref>『ゲームプランとデザインの教科書』、P.43 </ref>。世界観とストーリーが分けられているのです。 物語とその舞台ですね。我々自身もこの世界で自分という役を演じている役者ですよね^^ {{コラム|ゲームの企画書とアニメーションの企画書| 商業アニメーションの世界では、企画の段階でストーリーの概要が決まっているようです。ただこれは、アニメーション作品の企画として、当然に必要とされる要素であるから記述されているわけで、実制作の過程で、実際のスタッフの意向により大幅に変更されることもあります。また、これらの企画では、キャラクター設定やキャラクターイラストのデザインも当然必要であり、かなり明確な形で提出されています。 たとえば、アニメ業界の企画書ですが、1990年代のアニメ『新世紀エヴァンゲリオン』の企画書の掲載されている『新世紀エヴァンゲリオン (ニュータイプ100%コレクション) 』（1997年2月28日初版発行、85～88ページ）を読むと、『企書画』の段階でもう、キャラクターイラストが主役だけでなくその友人や周囲の大人なども含めて、ほとんどのキャラクターでイラスト紹介されており、さらに全部の話数ぶんの粗筋と見せ場・意図を2～3行ていどで説明しています（ただし第1話と最終3話（24～26話）のみ説明が5行以上くらいと長い）。 因みに現編集者は実際にアニメーション業界で企画書を書いたことがありますが、その時に上司、制作会社の重役に指摘されたのは、1クール（3か月）か2クール分の実際のストーリーの具体内容を書いてほしい、との事でした。 一方ゲーム業界では、そういうキャラクター設定やストーリーは、企画段階では決まっていなくて、もし書かれていても邪魔だと感じられるようです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、149ページ</ref>。 業界の企画書で、強調してほしい内容とは、ゲームシステムと、そうシステムを設計した根拠のようです。なぜなら、ゲームの企画書でいう「コンセプトが重要」、と言う際の「コンセプト」の意味とは、ゲームシステムやゲームルールを設計した根拠のことだからです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、108ページあたり</ref>。 とはいえ、ゲーム業界の企画書でも、ゲームの世界観が「中世西洋ファンタジー風」なのか、「現代日本」か、「近未来SF風」なのか、などの設定はある様です。ネット上で公開されている商業ゲ－ム企画書からその様子が分かりますが、しかし、最初の企画書の段階で決まってる世界観はその程度まで、です。 背景としては、ビジネスモデルが根本的にアニメーション業界とゲーム業界とでは違う、という事情があるのでしょう。 }} {{コラム|キャラクター重視の物語論| アニメ―ション業界のビジネスモデルは、キャラクタービジネスだと言われています。1990年代の徳間書店のアニメーションに関する書籍（アニメージュ10周年記念）で、徳間の編集者が1980年代のアニメ業界を振り返ると、これはキャラクタービジネスだろうと、たとえば銀河鉄道999のアニメ―ションの人気も、メーテルなどのキャラクターの人気なのだという分析があり、アニメージュ創刊当時の『銀河鉄道999』特集では、ストーリー解説ではなく、キャラクターに焦点を当てた記事を組んだと、述懐（じゅっかい）しています。 また、漫画産業もキャラクター重視のようです。主人公に共感させるための様々な演出が凝らされている。そして主人公が身近に感じられることが重要だと指摘されています<ref name="tskdq" />。 これは日本人が物語軽視というよりは、海外でも同様であり、むしろ物語とはキャラクターを描くという要素が非常に大きいという事でしょう。多くのミステリの中でも「シャーロック・ホームズ」や「007」の人気が非常に高いのも、キャラクター性と結びついた作品だからでしょうね<ref name="tskdq" />。 1982年頃『鳥山明のヘタッピマンガ研究所』では、おおむね「マンガとは人間を描くことだ」という主張がなされています。 現編集者の記憶では、漫画がキャラクターだという主張を強くしたのは、漫画原作者であり、劇画村塾の開設者である、故[[w:小池一夫|小池一夫]]氏でしょう。上述の書籍の共著者、さくまあきら氏も、劇画村塾出身ですから、さもありなんということですね。 アニメ評論家の岡田斗司夫氏は、対談集『マジメな話』で、「古代ギリシア人や古代ローマ人はとても論理的で学問も発達していたが、一方でギリシア神話やギリシア悲劇が普及していた、人間には物語が必要なのだろう、自分達の社会の仕組みを、物語になぞらえて理解する、物語が学問や科学に匹敵する」といったことを述べていました。 ギリシア神話では実に人間的な神々の物語が語られていきます。 また、政治学者小室直樹氏は、別の書籍、おそらく、『日本人のための宗教原論』あたりで、「幼少期の子供にとっての、父親の力強さと畏怖のイメージ」こそが神のイメージだろうと述べています。ギリシア神話の最高神ゼウスは、明らかに父性を示していますよね。 これはユダヤ教やキリスト教の神のイメージだと考えてもいいと思います。この辺[[w:父なる神]]あたりに面白い記述がありますし、一方でイスラム教は神に父性を見出さない、などの興味深い分析も書かれています。 また、RPGゲーム『真・女神転生』では、裏設定ですが、作中の「悪魔」とは、力の象徴であり、それは父親を暗喩しているというコンセプトがあります（たしか公式ファンブック『CLUB邪教の館』あたりに記載がある）。だからこのゲームの主人公は、父親がいない母子家庭の子供だという事になっています。 }} {{コラム|ゲームにおけるキャラクター| ゲームの世界は、ソーシャルゲームや美少女ゲーム等はありますが、一般的にはキャラクター重視のメディアではないようです。シューティングゲーム『ゼビウス』のキャラクター性とか、『平安京エイリアン』のキャラクター性など、想像力を最大限に駆使すれば見出せないことはないですが、常識的にはキャラクターの魅力は提供されてはいないでしょう。 ゲーム学という概念を推進している人達は、ナラティブ（「叙述」という意味）といって、スーパーマリオなどのように作中にストーリー説明文が無いゲームのことを説明しているようです。 今現在では、可愛いキャラクターや恰好いいキャラクターを作品に取り込めるのなら、それを除外する必要はないでしょう。しかし現実の人気ゲームでは、キャラクター性があいまい、あるいはほとんど見出せないゲームも多いですよね。 ゲームのキャラクターは、開発途上で変更される可能性もある。海外展開しているゲームは、相手国の風習、社会状況に合わせて、キャラクター設定を変える場合もある。 今現在は、ソーシャルゲームでもキャラクターゲームは人気ですが、昔はそうではありませんでした。1990年代は、多くのゲームファンの間では、「キャラクターゲームはつまらない」と言われていました。 2002年にシリーズ発売開始されたRPG『ドットハック』シリーズの企画コンセプトは、面白いキャラクターゲームを実現することであり、2003年当時の社長（松山洋）がラジオ番組『ドットハックレイディオ』に出演した時に、「キャラクターゲームがつまらない」という一般的に言われている常識を打破したい、それがコンセプトだ、と述べていました。 しかし実際には1990年時点で魅力的なキャラクターゲームもありましたし、大ヒットすることは無くても、一部の大きな人気は得られていたようです。 }} {{コラム|企画が実制作に移ること| 1990年代後半に書籍を出し始めた、元ゲーム業界人・阿部広樹氏は、ゲーム会社から請け負って、そこで頓挫した、或いは難航した企画を練り直しする仕事をしていたようです。彼の著作ではその経験、経緯が語られています。 扱った一つの企画が、ガンダム風の巨大ロボット操作ゲームで、企画として完成度の高いものでした。 主要機体の巨大ロボットのグラフィック設定画は線画が完成していて、機体パイロットである主人公の顔グラフィック線画もある、ロボットの設定サイズ（「全長○○メートル」、「主要武器：○○」など）なども含む、仕様書がすでに用意されていました。 機体の名前には「メタトロン」や（たしか）「サンダルフォン」と、ネットの普及していなかった当時では調べるのにも手間のかかるユダヤ教の大天使の名前がつけられていました。 阿部氏も、このゲームは実現するだろうと、期待を込めて企画を進めていたようです。 しかし現実にはこのロボットゲーム企画は対象のゲーム会社では採用されず、実際に制作されることはありませんでした。このようにゲームの企画は、企画だけで終了してしまうものが沢山あります。 一般的に商業ゲームの製作は、本当にペイするかどうか、経営者や出資者の審査、判断の上、実制作に取り掛かるでしょう。 企画を作る方も仕事として取り組んでいるのですから、「没になるかもしれない」といって手抜きするはずもなく、内容的にも、前設定の完成度としても、どれも相当の力と手間暇をかけて企画を練りこんでゆくでしょう。 しかし結果は結果としてありますよね。採用される保証はないしされないほうが実際多い。その判断が正しかったかどうかはまた別の話ですがね。 }} {{コラム|他業種、一般的な意味での『企画書』| 企画書にもいろいろな段階があります。 #本当に企画の初期段階の、内部関係者しか見ない、思いつきを書きなぐったような企画提案の書類（厚さはせいぜい2～3ページくらいまで？） #企画が熟成してスポンサーや外部に見せられるようになった段階、もしくはその直前くらいの企画書（10ページを超える程度） #パワーポイントなどを使ってプロジェクタ－で見せるプレゼン資料の「企画書」 多くの業界の企画書で学生や外部の人間が見るのは 2.か 3.でしょう。 1990年代後半のゲーム評論家の阿部広樹の他者との共著による書籍によると、彼はゲーム業界で企画に関するトラブルを解決する仕事をしていたようですが、ある案件で、「当時の人気アニメ声優を起用！」など書かれた企画書をトラブル解決のために扱いましたが、彼らが調査した時には相手先のアニメ声優および声優事務所には全く話が行っておらず、対応にも難航したようです。ただ、本Wikiの別の場所でも指摘しましたが、企画時点では、その手の手続きを踏む必要はないでしょう。企画は企画にすぎませんし、実現の見通しが大きくはないその時点で話を持ってこられても、声優も事務所も、対応しようがないと思う。ただ、前編集者の記述では、許可をとれそうな見込みもないと書いてあるから、よほどのビッグネーム声優、要するにその声優の知名度だけをあてにしている企画ですから、悪い企画の例として非難されても仕方ないのかもしれません。しかし現編集者がさらに邪推、想像するに、彼らに企画トラブルの解決を依頼したゲーム会社は、自分たちは零細で知名度もパワーもないので、とてもその有名声優にはアクセスできない、ですからトラブル解決を稼業にしている業者なら、上手にその声優にアクセスしてくれるのでは？という期待があったのではないでしょうか？だとしたら、この事案に対する阿部氏らの態度、そして後になってわざわざ自らの著書でその出来事、関係者を愚弄して、それで自分たちが正しいかのように言うこの人物の姿勢は、職業人、仕事人として問題があるのではないでしょうか？ さて、ある程度企画が本格化してくると、スポンサーに提示するプレゼン用の資料とは別に、詳細な設定や企画意図を説明する、「詳述企画書（ここでの仮の名称）」も作られていきます。この書類は今後の作業のためのひな型の意味もあり、具体的にどんなキャラクターが出てくるか、イラストなども描かれます。 因みに、「ゲーム　企画書」でグーグル検索してみると、企画書としては 1.~3. そして今書いた「詳述企画書」が混然と表示され、書類として種類や趣旨は明確化されていないようです。企業が求職者を採用するために、企画書を求める場合は、プレゼン資料が最適のようですね。採用担当者にとって一番読みやすい資料だからでしょう。 企画書として、説得力のある内容なら、採用され実制作に移る可能性も高くなるのでしょうね。そのために指摘される事として、冒頭部分で、この企画と既存の作品の違い、今までの状況からの改善点、そして実際の改良の実現の見通しと方針を示すといい様です。これは「企画意図」や「コンセプト」と呼ばれますね。 「改善点→（競合他社の）現状説明→改善案の詳細」を、詳細企画書で段階的に説明するといいですね。新聞記事の書き方で、起承転結ならぬ「結・起・承」（けつきしょう）というのがあるので、それを参考にするのもいいでしょう。 また、売り込み先の消費者として想定しているターゲット層の指定も必要です。年齢はいくつくらいなのか、性別は男性か女性か、などですね。 企画の詳細を作りこんである場合や、すでにゲームソフトを実装してある場合のシステムの説明では、単にフローチャートを図示するだけでなく、そのシステムでプレイヤーは何ができるのか、簡単な遊び方の概要説明、等を加えるといいですね。 }} {{コラム|日産自動車の社内講習でのアニメーション業界人の講演| どこの企業でも社員向けの講習会はそれなりにあるでしょうが、日産自動車では過去、アニメーション制作会社の幹部を招いて、営業マンや企画職の社員のために講演してもらったことがあるようです。 テレビアニメーション『輪廻のラグランジェ』が2012年に放映されていた前後、日産が取材協力として制作に参加していたので、CG雑誌で、日産の講演会の様子が紹介されていました。 アニメーション業界では、実在しない物体や機械のイメージを、メカニック設定などで詳細にイメージを作り、絵コンテマンや、原画・動画のスタッフ間でその具体設計を共有するので、自動車製造業界でも参考になる要素があると考えられたようです。 日産の担当者は、制作会社の幹部の講演会に手ごたえを感じたので、もっと話を聞かせてほしいと要望すると、『輪廻のラグランジェ』の製作会社を紹介してくれたので、その会社にも講演をお願いし、さらに制作会社側の取材協力にも積極的に応じて、異業種同士のコラボレーションが形成されていったようです。 }} さて、ゲームの『仕様書』はそのゲームの設計図なので、起こりうる全てのパターンを網羅して設計を指定する必要があります…と言いたいところですが、そもそも本当にすべての操作に対する反応をもれなく記述できるのか? しかしできる出来ないにかかわらず、創作物が世に出れば、それはコンピューターアプリケーションとして、ユーザーに自由に操作される。その時仕様と創作物が、合理的に網羅的に作られていれば、プレーヤーはストレスなく、ゲームを楽しむ事が出来るでしょう。 ;検品、検収 さて、一般に技術系の業界では、図面などの設計図は、検品のさいのチェックリストを兼ねています。（ただし、ゲーム業界での「仕様書」が検品チェックリストを兼ねているかどうかは、2022/01時点、著者側の調査不足で不明。） しかし検品自体はゲーム業界でも行っている。協力会社から納品されたプログラムも、仕様を満たしているかチェックするだろう。 そしてチェックを通ったら、合格した製品として正式に受け取る。 納品物を合格として認めて受け取ることを「検収」（けんしゅう）という。（ゲーム業界でも）<ref name="creator_work:77">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、77ページ</ref>。ゲームの仕様書は、この検収を考慮に入れて書くのがいいだろう。 つまり逆に納品物が合格していないと判断されると、受け入れない、検収しない、納品者に作り直しを要求することになるだろう<ref>蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、76ページ</ref>。 商業ゲーム界では、営業マンが見積もりをするときの根拠は、仕様書、という事になる<ref name="creator_work:77" />。 外注テストに関しては、仕様書では不十分で、テスト用の別資料を用意する<ref name="gpd9" />。 バグチェックを外注しない場合は、「仕様書」を根拠にする場合が多いという<ref>吉冨賢介『ゲームプランナー入門』、P20およびP199</ref>。 つまりやはり、製品の仕様の基盤は仕様書、正しい仕様は、仕様書に書かれている事だという事になる。 開発後半のデバッグ段階などのバグチェックの段階に入る前に、仕様書を最新のゲームの状態とそろえる<ref>吉冨賢介『ゲームプランナー入門』、P238</ref>。つまりこれは、ゲームの仕様が制作過程で変わっていったら、逆に仕様書を書き換えて、実際の仕様に合わせるという事だ。 ==作成工程== ===完成予想図=== 仕様書はゲームの設計図。この書類を基盤にプログラマー、グラフィッカー、製作スタッフたちは作業を進める。しかし、ゲームの場合は、いきなり完成図を明確に決定するのは困難な場合が多い。そうなると方便的に大まかな設計、決定を作っていくという事になるだろう。事実、現実の業界では、大まかな「企画概要書」から詳細な「仕様書」へと、段階的に仕様が決まっていく<ref>『ゲームデザイン プロフェッショナル』、P.141</ref>。 一般的な製造業でもゲーム業界でも、あいまいな指定は事故のもとだと考えている。「とにかく、かっこいい感じでお願いします」なんて言いたくなることもあるけど、危険らしい<ref>『ゲームデザイン プロフェッショナル』、P.60</ref>。相手の「かっこいい」のイメージが、有り得ないものだったりする場合、あるよね^^;;;。 しかし場合によっては例外もあるようだ。裁量とか、阿吽の呼吸といったものも、人間関係ではある。しかし技術を語る場合、設計とは極力あいまいさは排除するものだろう。 ゲームでは、他者に発注するときは、ある程度相手の裁量にゆだねた方が良い場合もある<ref>『ゲームデザイン プロフェッショナル』、P.134</ref>。しかしその場合も、具体的にどういう実装予定のもので、どこに裁量を与えるのか明確にする必要があるという。裁量の発注については、『ゲームデザイン プロフェッショナル』本書を読めと、前編集者は書く。 とにかくこの編集者によると、Wikibooks をはじめ、Web上のWiki には何の価値もないと言う。世の中唯一価値のある文献は市販されている書籍で、Wikiの利用意味はその価値のある素晴らしい書籍を、出典としての記述を参考に、知ることだと言う。 それなら、Wiki書くのなんて辞めて、本屋でも始めたら? ===各機能の予想図の決定=== ソフトウェアの完成予想図は、画面を基準にすると伝わりやすい。 結局パソコン、情報機器を使っている時は画面を見ますからね。 <pre> △△モードの××画面 Aボタン: ダッシュ（走る）。押すとキャラが十字キーの選択方向にダッシュするようにプログラムする Bボタン: ジャンプ。押すとキャラが上方向にジャンプするようにプログラムする </pre> とか、こんな風に書くといいのではないでしょうか。それぞれのモード、画面での機能の満たすべき情報の一覧、を伝えておきたいですね。 ユーザ視点での仕様の事は、「外部仕様」、というようです。 ですからソフトウェア設計者は、各モードについて、画面表示、操作などの外部仕様の一覧を用意したいですね。 これは完成予想図でもある。 一方ソースコードの詳細は、内部仕様ですね。 商業ゲーム界では、原則的に内部仕様に関する書類は、あまり書かないようです。とはいえ設計項目の、ファイルや変数の具体的な記述は、ある程度は仕様書に書かれる。 そして外部仕様は「画面仕様」だけではない。例えばアクションゲームのモンスターの動き方のパターン、RPGのダメージ計算式、プレイヤーが具体的に実感できる仕様は、仕様書において指摘しておきたい。 ゲーム完成予想図とは、各種外部仕様を具体的にわかりやすく記述することになるだろう。 ==※例== 一冊の完成予想図の中で、説明が重複し、同じ記述が複数あるのは好ましくない。 ある記述内容が変更になる時、重複した先も変更しなければいけなくなる<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。 一般的製造業の製図でもこのルールは守られている。一つの末端部分の図面はそれだけで完結し、他の部分を参照しないようにしている。 ではここからは、ウディタのサンプルゲームを具体例に説明しよう。 本来サンプルがあれば仕様書は不要という事になるが、今回は説明用として、サンプルから仕様書を書き起こす。 まずサンプルゲームのメニュー画面、 :相談 :アイテム :特殊技能 :装備 :システム :セーブ と、６つのコマンドがある。 上から4つめの「装備」にカーソルを合わせた状態で決定ボタンを押すとキャラクター選択に移り、十字キーで目的のキャラクターを選択して決定ボタンを押すと、装備画面に移る。 さて、これを仕様書に書くと… 【'''装備キャラクター選択画面'''】 '''遷移直後の変化''' メニュー欄に「装備」コマンド位置に決定後カーソル画像「○○○.bmp」を表示。 キャラクター選択欄のカーソルの点滅が開始。キャラクター選択用の点滅用カーソルの画像は「△△△.bmp」。 '''ボタン押の反応''' キャラ選択欄で十字キーの方向にいる隣または次のキャラクターを選択でき、そのキャラの選択欄にて点滅カーソルが点滅表示される。 決定キーを押すと、選択中キャラクターの『装備部位の選択画面』に移る。 キャンセルキーを押すと『メニュー画面』に移る。 '''画像リソース''' ○○○.bmp :メニュー欄用の決定中カーソル画像 △△△.bmp :キャラクター選択欄用の点滅用カーソル画像 という感じ? その画面とやりとりする相手先の画面の名前と、あとはその画面の読み込むファイル、無駄なことは書かない、他の画面や他ファイルについては書かないほうが良い。 上述の仕様書の書式の参考は、吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、221ページ、の例『各画面の仕様書の例』の書式。 『装備部位の選択画面』に移ったあとの説明は続けて書かず、別途、たとえば『装備フロー仕様書』のような仕様書を作成せよ。 仕様変更で、『装備』コマンドの位置が（サンプルゲームでは上から4番目だが）上から6個目に変わったら、「メニューの装備コマンドは上から4番目にある」と書いた書類は全部作り直しになってしまう、そういう事態を避けたい。 そのため、あえて書類をモジュール化する。全体像は把握しづらくなるが、しかし全体像の把握については、そのための専用フローチャートを書類に設け、修正の手間が波及しないようにする。 例えば… '''装備フロー仕様''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 とかね。 フローチャートの作図をしたい場合は、オフィスソフトのパワーポイントの図形描画の機能で作図が可能。フローチャートの描き方はJISで決まっているので、それを参考に。中学校の技術家庭科でも習うのでその教科書を引っ張り出してきても良い。 例えば装備部分の選択画面は、 :右手 :左手 :身体 :装飾1 :装飾2 これがこう変更されると… :武器 :盾 :頭 :身体 :腕 :装飾 書類上の「装備部位の選択画面の「右手」選択にカーソルの合わさった状態で移る」というような記述はすべて書き直さざるを得ない。 そこでまず、『メニュー画面』や『キャラクター選択画面』では、他画面、例えば『装備部位選択画面』の具体的項目名称とその遷移法は書かないようにする。 『キャラクター選択画面』の仕様は、例えば、「選択キャラクターの『装備部位選択画面』に移る。」と書く。 「画面の変更時は原則、その画面のいちばん上のメニュー項目にカーソルの合わさった状態で画面が移る」と書く。 例えば装備関係のフローを描くときは、 :マップ画面 → 決定ボタン → メニュー画面 → 「装備」を選択で決定ボタン → キャラクター選択 → 決定ボタン → 装備品選択画面 と、続けて書くのはよくない。フローを分解する。 '''メニュー選択フロー''' 【 マップ画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 メニュー画面 】 '''装備関係フロー''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 こういう２分割でしょうか。 意味的にまとまりのある単位ごとに階層をフロー分割したい。 かといって、5分割や10分割と、階層が大きくなりすぎるのは、多重下請けのいんちき業界みたいなので、多くてもせいぜい３分割でしょうね。 そしてフロー同士を結ぶ記述が必要。 【メニュー画面仕様】 '''表示項目リスト''' 決定ボタンで下記の項目を選択できる。 ・相談　　　　　　:決定すればメニュー相談フローに移行 ・アイテム　　　　:決定すればメニューアイテムフローに移行 ・特殊技能　　　　:決定すればメニュー特殊技能フローに移行 ・装備　　　 　:決定すればメニュー装備フローに移行 ・システム　　　　:決定すればメニューシステムフローに移行 ・セーブ　　　 　:決定すればメニューセーブフローに移行 '''非表示項目''' ・キャンセルボタンでマップ画面に戻る とか? なお、各画面での遷移先の画面の説明と、フロー図での遷移先の画面との説明が重複しているけど、まあ気にしない、気にしない^^;;;。 参考文献の『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』の209ページ「状態遷移フローの例」と211ページ「各画面の仕様書の例」とでも、遷移先の画面の説明はそれぞれ重複しています。まあ場合によってはいつものようにこの後の記述でそこそこ言い訳するかもしれないけど…^^;;; ;一枚の図面の中での重複は、すじ肉大先生が許してくださる^^ というのは、例えば機能の似たものを二つ作る時、2個目の説明では、「○○については△△と同じ」と、書けるからね<ref name="aps229">吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ</ref>。 同じ一枚の図面なら、これで良い。 「○○については△△と同じ」「～～～と同じ」のように書いて具体的には書かない。<ref name="aps229" />。 ;その他 画面名やファイル名の名前は、具体的にしたい<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。 たとえば、上述のウディタのサンプルゲームの画面は :「マップ画面」、「メニュー画面」、「装備キャラクター選択画面」、「装備部位選択画面」と、したいね。 例えば 「画面1」、「画面2」、「画面3」、… とか、 「メイン画面」、「メニュー画面」、「サブメニュー画面1」、「サブメニュー画面2」、… にしたいときはあるし、事実上これは、命名の手間は省けるんだけど、他人に伝わりにくいので、ここは少し手間をかけて、具体的に内容ある命名にしたい。 {{コラム|| 法律の設計でも、相互参照が増えると、その法律の構造自体の複雑さが増加する現象が知られています。近年、世界各国でIT的な考え方を使って法律の設計論を研究しようという学問分野があり、その学問でそう指摘されています[https://www.nature.com/articles/s41598-020-73623-x Daniel Martin Katz, Corinna Coupette, Janis Beckedorf & Dirk Hartung "Complex societies and the growth of the law" , nature.com, Published: 30 October 2020 ]。これらのIT的な法学では、法律中の単語数、階層数、法律間の相互引用数が多ければ多いほど、その法律の構造は複雑になると考えられています。ご参考に。 }} ==== 要求事項 ==== IT界の一般的な慣習として、「要求事項」とは、完成品の満たすべき要件を示しています。 一般のIT業界では「要求事項書」というものを作る場合もありますが、ゲーム業界では通例は、そのような追加の書類は作られません。ゲーム設計論の専門書を読んでも「要求事項書」などというものは紹介されていません。 ゲームデザイナーからの要求については「仕様書」または発注書などの手続きの際に、相手方に要求を伝えてしまいます。 E.Suj.の調査では、商業ゲーム界で『要求事項書」が作られている証拠は見つけられなかったようです。 なお、基本的に「要求事項書」とは、発注者と受注者の両方の打ち合わせによって作られていきます。 ただゲーム界では、発注書で、成果物が作中でどういう目的で使われるのか、意図・用途を伝えるのがいいようです<ref name="gp296" />。 ==== データ暫定値 ==== ゲーム中のデータの数値、例えばRPG武器の攻撃力、等、はすべての項目の想定値を設計図に記述します<ref>https://www.youtube.com/watch?v=KVdtNiB_lIQ 2020年3月14日に閲覧</ref>。 CSVファイルを作りましょうか、ソフトはエクセル? 【剣データ暫定値】 銅の剣: 攻撃力 7 鉄の剣: 攻撃力 18 ハガネの剣: 攻撃力 37 ミスリルの剣: 攻撃力 70 ほのおの剣: 攻撃力 57 （※ 剣ではランク5は欠番とする） デスブリンガー: 攻撃力 150 備前長船: 攻撃力 250 聖剣エクスカリバー: 攻撃力 450 魔剣レーヴァテイン: 攻撃力 450 具体的な指定も一緒に書いて、もちろん今後の調整で変更する可能性はあります。 ====データ仕様書==== データ仕様書とは、たとえばRPGなら :攻撃力: 敵の守備力との計算によってダメージを算出する のようなパラメータ計算式の定義を行った仕様書のことです<ref name="gpnt92">STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日初版第2刷発行、92ページ</ref>。 そして、この「データ仕様書」は、デバッグのための資料になります。デバッガーが、この資料と実際の動作を照合することで、仕様どおりにプログラムが動いているかを確認します<ref name="gpnt92" />。 書籍『ゲームプランナーの新しい教科書』では、アイテム（「やくそう」や「毒消し」などの）価格の「100」（100ゴールド）や「200」（200ゴールド）の具体値のあるデータ表のことを「仕様書」と言っている。この本では、本当は「100」になるべき数値が「200」になっている場合 「仕様書」で簡単に確認できる、記述されている。 一般にRPGの仕様書は非常に厚く、大冊になるという。オタキング岡田斗司夫氏が聞いたところによると、（出典は『オタク学講座』など）、ある有名RPGの仕様書は、書類の量をページ数ではなくKg で数えていたという。（しかし、1kg=何枚かな?^^）。有名作の仕様書は、分厚い電話帳のようなものが何冊もあるらしいです。データ台帳、 各種パラメータ、設計の背景の要求事項、まあいろいろ書かれているのでしょうね。 ;攻略本と仕様書 ゲーム攻略本にある、アイテムの効果値や、敵の能力値といった数値の一覧は、おそらくそのゲームのデータ台帳から転記されているのでしょう。 プログラム部分の設計図である仕様書も参考になるでしょうが、データ台帳には、直接的な数値が書かれています。 しかし実際の市販の攻略本には正しくない記述もある。制作側から正しいデータ、情報を手に入れられなかった場合もあるでしょう。 ==プランナーが事務方の現場で動いているスタッフとみて良いでしょう== ゲーム業界では、プランナーと言われる人が、連絡網の中心になって、いろいろな部署のあいだの情報伝達をします。 <div style="font-size:120%;"> <pre> ディレクター　━━━　プランナー　━━━━┳━　プログラマ 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　グラフィッカー 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　デバッガー </pre> </div> ディレクターが現実の制作のトップ、そしてその後ろにプロデューサー、管理職など、商業コンテンツとしての責任者がいることになりますね。 このプランナーは、ゲーム業界の場合、中間管理職? のような権限があり、各部署（プログラマ部署やグラフィッカー部署など）やディレクター（監督）の間で、様々な調整や連絡をしていきます。 アニメーション業界で言えば、制作進行とか、制作デスク、のような立場でしょうか。 「プランナー」というと、プラン「計画」を練るという意味になりますが、テレビ業界でいう「AD」アシスタントディレクターのようなイメージのほうが近いかもしれません<ref>吉冨賢介『ゲームプランナー入門』、P236</ref>。勿論現場を現実に回すための様々なプランは必要ですね。 ==ゲームに取り込むイラスト、音楽== 商業ゲームで、イラストや音楽、そしてそれ以外でも、他者に何らかの作業を発注する場合、特に常識的、慣習的な発注フォーマットというのは無いようです。割と場当たり的に、作品、状況にあった発注形態がとられているのでしょう<ref>『ゲームデザイン プロフェッショナル』、P.146</ref>。 音楽やイラストの提供を他者に求める場合は、もちろんその作品に関するその絵描きや音楽家の関わり方にもよりますが、そのゲーム内でどのように絵や音楽を使うか、明確に説明できることが望ましいですね。 様々な事象項目チェックリストも用意したい<ref>『ゲームデザイン プロフェッショナル』、P.159</ref>。 ===他者に委ねる場合=== 商業としても、あるいは同人としても、割と外部の他者に描いてもらったイラストや音楽をゲームに取り込むことは多いでしょう。商業ならそれこそ、対価を明示したうえで外注、ということになる。 例えば他者にイラストをお願いするときは… :構図、 :希望のポーズ、 :塗り方、 :テイスト、 この辺を相手に伝えておきたいですね<ref name="gpd128">『ゲームプランとデザインの教科書』、P.128</ref>。 さて、ゲームには美術的な素材として、イラストレーション、アニメーション、コミック（漫画）などがありますが、これらはもちろん絵画としての共通点はありますが、一般的にはそれぞれ別分野と見なした方がいいようです<ref name="gpd128" />。 特に商業の世界では、美術作品という共通点はあっても、他分野の創作は手間や方法論の整備や熟練などの問題で、それぞれの専門家に依頼するのが妥当でしょう<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P168</ref>。 そして、商業ゲーム界では、あるいはそれ以外でもあるかもしれませんが、キャラクターイラストを描いてもらうときは、実在のアイドルやモデルの名前をイメージとして、提示する場合もある<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 あるいは仮に自分は絵が上手に描けなかったとしても、ラフな簡単な絵をかいて、どんなキャラクターのどんな構図を描いてほしいか、大体の要望を伝える、ということもありますし、また、その構図が作中でどういう目的で使われるか、意図用途を伝える<ref name="gp296" />、というのも意義がありますね。 ただ他人に何かを伝えるということは、一般的な意味でも難しいことですよね。ここでイラスト描きに希望を伝えるにしても、長文の書類だと読んでもらえないこともあるし、口頭でもその相手にとって分かりにくい説明というのがある。 ですから、出来るだけ、ですね、わかり易く受け入れやすい言及が必要です<ref>『ゲームデザイン プロフェッショナル』、P295</ref>。 ;アダルトゲーム アダルトゲームでは、シナリオも外注の場合があるらしい<ref>畑大典著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P129</ref>。しかしむしろこれは企画販売の会社と、制作主体が別だという話ではないだろうか？ ところで皆さんは、アダルトゲームって、プレイします?^^;;; ;そもそもイラストの発注者は、絵描きの頬を札びらで叩いて描かせているわけ? 基本的には有償のイラストの場合は、発注者の指定にイラストレーターは従うでしょう。それでも媒体にもよりますけどね。ゲームの場合は、発注者の指定に従う縛りは大きいと見ていいですね。 そもそも要求事項がどうのとか、書類に関する理屈をグダグダ述べれば、さらにこの縛りは強くなりますね。事実上はその辺の判断はあいまいなのですが、発注者は一般的にリテイク（書き直し）を出す権利があるとみて良い。 例えばイラストの仕事を有償で得たとして、実際にはそのイラストの使われ方も問題になりますが、「セーラー服の少女を描いてください」と頼まれてそのイラストを引き受けたら、ブレザー服の少女を描いて提出するのは不適切でしょう。リテイクを出される<ref>『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.208</ref>。それどころか、仮にセーラー服の少女を描いたとしても、発注元がそのイラストの質が良くないと判断したら、一般的にはリテイクを出してよいと見られています。しかしもう一つ問題があって、そのイラストレーターはそもそもなぜブレザー少女を描いたのか？そしてもう一つ、現編集者の推奨としては、イラストレーターはリテイクの扱いについて、具体的にどう扱うか、発注者とよく話し合ってある程度ルールを明確にしておいた方が良いと思います。 前編集者はこの問題について、社会のルールがどうのとか、自称イラストレーターがどうのとか、教育がどうのとか、2005以前がどうのとか、いつものように狂った理屈を長々書いていますが、全て愚か者の自己本位なたわごとでしょう。 {{コラム|絵の仕事とはどんな仕事?| さて、前編集者 Suj. は、このコラムで、2005~2008 にかけて、絵の仕事を、「自由に絵が描ける」「漫画や絵の仕事は、競争を気にしなくていい」と、思い込んでいる人がいたと書いているけど、これ本当の事かね? どうせいつもの[[w:かかし論法]]じゃあないの? そもそもなんでこの話では、大好きな出典出さないわけ? しかもこの人物は、教育に携わる資格なんてまるでない性格異常者なのに、なぜか偉そうに大上段に教育論を語りたがる。 そもそもそんな人がいるかどうかも怪しいが、それは小中高の美術教育、自由に絵を描かせる授業方針のせいなんだって。 この人物の妄想世界では、「小学校の図工のような自由な仕事 <nowiki>=</nowiki> プロ絵描き」と思い込んでいる人がいるんだって。ほんとかね? 何かこの人物が大好きな江川達也もそんなこと書いていたようだよ。 2001~2005の雑誌コラム、スパ? 漫画業界について「漫画家は、競争が無くて自由に漫画を描ける仕事」、という言説に怒っているんだって。しかしほんとにそんな主張があったの？江川もストローマン叩いてるだけじゃあない？そしてわざわざゆとり教育に言及? インチキ臭いね。 しかも江川が書くには、「漫画家はとても競争の厳しい世界だ。」ってことだけど、まあそんな部分はあるけど、結局はそこで生き残って飯食ってる俺は偉いって話でしょ? 江川ってほんとにいい漫画描いてる? 単にインチキな業界人に気に入られているだけでしょ? あと小林よしのりは、ゴーマニズム（そろそろマジメニズムになったら?）宣言で、プロデビュー前、「マンガ出版社は、漫画家が死ぬまで面倒を見てくれる、まるで公務員のような終身雇用の業界が漫画業界」と思い込んでいた、と、描いていたって言うけど、そうね、私もこんな記述昔読んだような気はするけど… しかし、E.Suj.はこの小林の当時の考えはよくて、今同じ様な考えを持つと阿保馬鹿書くわけ? しかもほんとにこんな考えの人が今いるのかね? 出典くれない? まあ確かに実際に今現在、そんな考えの人はひょっとしたらいるかもしれないけど…。しかしここでわざわざその話題をコラムとやらにして、彼らを愚弄する意味なんてある? }} ===特定の絵に関して、誰でも質やクオリテイを語ることはできる。しかしそれは主観的な判断に過ぎない上、自分自身が神のように凄い絵を描けるわけではない。だからあまり威張って断定的にそれを語るなよな。=== 事実上今現在の商業ゲーム界の主流の絵は、まずCGであり、手描きの場合は細密かつCG特有のグラデーション、その他最新のテクニックを駆使した多色の華やかな絵柄 でしょう。 その絵が上手に描かれたいいものであれば、ゲーム業界の馬鹿馬鹿しい連中は、この絵はクオリティが高い、などと宣うわけです。 で、その条件から外れた絵を見ると、彼らは下手だ下手だと騒ぎだすのでしょう。 ;アニメーション、漫画、CGイラストレーション 上記の3つの絵画は、多少質が異なるものになるでしょう。前者二つは一枚絵で完結していないので、ある程度簡略化した手間をかけない描き方がなされる。一枚絵のイラストはそれだけで完結なので、事実かなり手間と時間はかける事が出来る。 しかしどちらにしろ、時間と手間は様々な諸事情のバランスで、それが選ばれ決定されますね。 特定の絵が上手いとか下手なことにこだわり、朝から晩までその議論ばかりしている愚か者は多いですが、事実上、時間と手間の大小にかかわらず、特定の人の心を打つ絵というのはある。 しかしやはりその心の動き自体が、主観的なものであるでしょう。 ;後日修正 手間と時間をかけた絵が欲しいなら、後日修正という道はありますね。商業漫画でもアニメーションでも、後から修正を加えて絵の質を高めることはあるでしょう。 基本的にはあらゆる物事が、時間と手間をかけたことによって評価は高まりますが、しかし我々の時間も労力も無限ではない。いいバランスで、いい完成度で、多くの物は創作終了されています。 ===芸術、自由、文化。そして娯楽、商業作品=== さて、前編集者Suj. は常に自分にとって都合のいい主張をしている市販本を探し、そしてそれが見つかったら購入し（しかしそのお金はどこから出ているのだろう?）、そしてそれを斜め読みした後、このサイトでクオリティ最悪の駄文を書き散らしているのだが、彼の愛読書には、ゲーム作りに必要な資質は、作家性と「人を楽しませたいと思う気持ち」<ref name="gpl246">『ゲームプランナー集中講座』、P246</ref>、だと、書かれている、らしい。 まあこのサイトを見てわかるとおり、彼自身はその二つとも全く持ち合わせていないのだが… そしてその馬鹿馬鹿しい本には、ゲーム会社の採用担当も、ゲーム会社自体も、クリエーターに自己表現は求めていない、と書いている<ref name="gpl246" />。つまり、ゲーム会社の幹部たちに都合のいい作業を安い賃金でしてくれる、奴隷が欲しいということだろう。 そして、E.Suj,はとにかく他人の褌をはいて威張ること以外何もしないのだが、彼のイラスト分野の愛読書には、依頼内容を無視して自由に絵を描こうとする人は、「プロ」ではなく「芸術家」、と書かれている<ref> 『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.198</ref>（らしい）。 ====芸術と商業漫画==== 漫画『サルでも描けるまんが教室』には、芸術と商業漫画に関する面白い記述がありました。 {{コラム|竹熊と相原のサル漫| 一応この漫画を知らない人のために少し説明すると、竹熊健太郎氏が原作、相原コージ氏が作画、まあ必ずきっかり分業がなされているかはわかりませんが、この二人が漫画内で主人公にもなって、商業漫画ハウツーギャクが展開します。 相原「む～…。俺たちはこんなくだらない漫画を描いてていいのだろうか…」 竹熊「どうした相原？」 相原「俺たちはもっと本質的な作品を作るべきではないか？例えば…資本主義などという下らない次元にとらわれてはいけないのではないだろうか…俺たちは国や大企業におどらされているのではないか？やはり漫画にも芸術は必要だろう…」 竹熊「バッキャローー!!!（ガッと、相原を殴る）」 相原「な、何をする…」 竹熊「お前は芸術をぜんぜん分かっちゃあいない！」 相原「そんなことない…」 竹熊「じゃあ、お前のいう芸術とは何か、言ってみろ？」 相原「それはー…、人間の内面の…真実ってゆうか…」 竹熊「にんげんのぉー、ないめんの～しんじつぅ～??? あのなー、お前は権威にとらわれてはいけないとはいうが、じゃあお前のその意見は、どこかの芸術大学の教授の権威にすがっているだけではないのか！？」 相原「そんなことない…お前こそ、政府や商業メデイアによる宣伝のつくった権威にとらわれているじゃないか。」 竹熊「ああそうかね。だけどお前だって、芸術教授の権威にあやかって自分も地位と名誉が欲しいだけだし、結局、お前もカネが欲しいだけなのだ。」 ……と、いうような、もちろんこの漫画は第一にギャグマンガですが、商業漫画界やアニメーション界での、芸術という言葉の捉え方をよく示していると思います。 例えば、『ねじ式』という漫画に芸術性があると評価された、つげ義春さんも自身の漫画が芸術でくくられることを嫌っていました。漫画家は芸術家ではなくて職人だ、と語っていたインタビュー記事を読んだことがあります。 しかし実はこのサル漫、最新最終作『サルまん2.0』ではさらに面白い展開を迎えています。 少し書きますが、「とんち番長」という漫画で一世を風靡した竹熊と相原（もちろんこの漫画内の、ですよ）だったが、やがて落ちぶれ、それでも再起を図って、漫画出版社に持ち込みする。 そこでの編集者が採用を断る時の言葉。 「いやいや先生。我々の雑誌では、先生たちの高尚な漫画は掲載できませんよ…。読者はみんなほんの愚かな子供たちで、先生たちの高尚な漫画はとてもとても理解できません…」 つまり過去大騒ぎして否定していた芸術側に、いつの間にか落ちぶれて、竹熊と相原は所属していたわけです… }} ====私小説==== {{コラム|基本的に娯楽産業の連中は、芸術という言葉も概念も嫌う| 前コラムでも書きましたが、結局商業アニメーションや漫画界では、娯楽、楽しい或いは扇情的、売れる、ということが重要で、あまり芸術的なことを語ると徹底的に嫌われます。 このコラムの前編集を見てもらえるとわかりますが、前編集の筆者もその感覚に追従して、好きかってなことを書いています。 特に自己探求にこだわった創作は、「私小説」などと呼ばれて揶揄されます。 1998年、オタキング岡田斗司夫の対談集『マジメな話』でも、当時のエヴァンゲリオンの映画版を「私小説」だと、対談相手の小説家・今野敏が批判していました。事実上この作品は衒学的な、疑似芸術作品でした。 やはり何らかの娯楽性、収益性、芸術性の問題が、常に創作作品には付きまとうようです。 さて、例えば、大正文学の売上のベストセラーは、 :倉田百三『出家とその弟子』、 :島田清次郎『地上』、 :賀川豊彦『死線を越えて』、 三大ベストセラーですが、しかし今や彼らは文学史の教科書には、滅多にのりません。せいぜい高校日本史の教科書で、倉田が少し紹介されているくらいです。 現代の教科書でよく大正時代の小説家として紹介される芥川龍之介は、じつは当時は倉田・島田らほどには売れていない作家です。また、「私小説」といわれるジャンルも当初から収益性はない。もっとも、芥川が私小説を書き出したのは晩年のことですが…。 しかし前編集者はこの問題に、毎日新聞の戦略とか、左翼がどうのとか、研究不足がどうのとか、なんかいい加減なこと書いているようですが、まあどうでもいいか。 現編集者は上記の3ベストセラーの、倉田の作品だけ読んだことがある。親鸞の話だったけど、私にとっては底の浅いいい加減な話に見えた。はっきり言って芥川の小説の方が、はるかに意味と深い内容を持っているだろう。 島田清次郎に関しては、「栄光なき天才たち」という漫画で、この人物の詳細と人生が描かれていたのを読んでいる。この漫画の中では彼は、「地上」の最終巻の採用を、編集者に断られている。 }} === ローポリ関連の作画 === 単元『[[ゲームプログラミング/3Dグラフィック#ローポリ制作手法的なこと]]』で説明した。 ==レポートは結論だけを読んでも分かるように書く== レポートなどは、ゲーム業界なら、途中を読み飛ばしても、内容がおおまかに分かるように書きたい。 別に冒頭で結論を述べる必要はありませんが（会社による）、しかし、仮に書類のページの順序どおりに他者が読まなくても、 レポート全体の内容を把握できるように書くのが推奨です。 ==書類は誰でも簡単に理解できるように書きたい== 書類の言葉選択は、「中学生の知識でも理解できる言葉を使う」、のが望ましいですね。言いやすいフレーズ、理解しやすいフレーズ、こういう言語選択も重要です。<ref>『ゲームデザイン プロフェッショナル』、P101</ref> 基本的にゲーム界に限らず、あらゆる場所で、わかり易い言葉を使うことが重要ですし、相手の理解に配慮することは必要でしょう。E.Suj.のように自分が理解できなければ全て相手のせいにし、相手が理解できないのもすべて相手のせいにするのは、一番有り得ない最低の態度でしょう。 == 脚注・参考文献 == rnvjnaxw106c2vcd6yz85mobfunc70y 206837 206836 2022-08-20T03:00:11Z すじにくシチュー 12058 /* 要求事項 */ wikitext text/x-wiki {{substub}}このページの主要執筆者は、ゲーム業界経験者ではないので（2022/1時点）、ここの記述は調べ物としては役立ちません。 2022/1時点でゲームプログラミングと直接の関係ない話題が長い、という問題があるので、より簡潔、かつ分かり易い記事への編集にご協力いただけたら幸いです。もっとも現編集者Hは、解ってるならそれを書いた奴が書き直せ、そもそも余計なことは最初から書くな、…とは思いますが…。 このページは、教科書としてゲームプログラミングの方針を説明する際に、どうしても書類についての説明が必要だから記述されています。現状では、一般IT業界や製造業などの設計図を参考に説明がなされています。 == 本書の目的 == 本書は、ゲームデザイナーのための教科書ではありません。 メインページ、「[[ゲームプログラミング]]」の題名どおり、プログラマーのための教科書です。プログラマーがゲーム制作に興味をもって実際に作り始める際に、調べ物の手間を減らすために書かれた参考書籍です。 ゲームデザインに関する解説を望む方は、別途、他の参考資料に当たってみてください。 ==「仕様書」== ここでいう「仕様書」とは、ゲームの設計図のことです<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.126</ref>。しかも職業的に集団でゲームを作るときの書類です。 ではまず、「設計図」とは何か、について、考えていきましょう。これは普通科高校では学習しない事項です。 ゲーム業界では、「仕様書」を含む書類群の「発注書」には、決められたルールや書式はありません。だから作るゲーム内容や製作チームごとに、適切な発注書のありかたを毎回考える事になります<ref>『ゲームデザイン プロフェッショナル』、P.145</ref>。 職業的なゲーム開発では、一般に :発注 → 実装 → 調整 というプロセスを経て<ref>『ゲームデザイン プロフェッショナル』、P.61</ref>、最終的にとりあえずの完成になります。 ゲーム産業での「仕様書」は、発注の段階での書類です。 ==集団ゲーム制作での解説文== 発売禁止になってしまった書籍（おそらく。しかし何故？）『国際おたく大学―1998年 最前線からの研究報告』（岡田斗司夫ほか、光文社）に書いてあった事例なのですが、G.O.D.と言うイマジニア社のRPGゲームに対する大学生（岡田は当時、大学講師だった）の取材があって、そのGODの開発に参加した劇作家の鴻上尚史（こうかみ しょうじ）氏と、エニックスの堀井雄二（ほりい ゆうじ）氏とが、対談した経緯が、紹介されていました。 劇作家の鴻上は、ゲームに演劇のリアリティを入れようとして、スタッフに「間（ま）を意識したシナリオを書いてほしい」と要求したが、うまく行かずに難航したと体験談を述べています。 対談相手の堀井は、鴻上のその体験談に対し「『（※ここで3秒休止）』とか書くと良いですよ」と、指示書で具体的に書くと良い、とアドバイスした、と、岡田の書籍にある大学生のレポートにあります。 おそらくドラゴンクエストのゲーム開発でも、このように具体的な指定を必要に応じて出していた・いるものと思われます。 21世紀現代の、商業ゲームの現場でも同様であり、書籍『ゲームデザイン プロフェッショナル』にもありますが（※かぎカッコ内が引用）、「もっとかっこよく調整してほしい」という問題であれば、たとえば「もっと目立たせたいので、アニメーションのシルエットを全体的に今より少しだけ大きくしてほしい」<ref name="gp296">『ゲームデザイン プロフェッショナル』、P296</ref>という具体的な指定が妥当でしょう。 == 集団作業に必要な書類 == ===設計図=== IT業界やゲーム業界では、集団作業で制作開始をしようとする際、まず、いきなり設計図を作るのではなく、まず先に試作品（しさくひん、英語で「プロトタイプ」proto-type）のプログラムを作り、企画で考えた各種システムなどのアイデアが有効かどうかを検証します。 そのプロトタイプで、企画のアイデアが本当に有効であるかを確認してから、もし有効だったら、本格的な制作を開始します。 もしかしたら会社によっては、企画会議（もしくは企画の打ち合わせ）よりも先にプロトタイプを作るかもしれません。 さて、会社へのプロトタイプ提出で、制作続行・制作本格化の賛同が会社から得られたとしましょう。 IT業界でも製造業でも、どこの業界でも集団作業で、制作の合意を作るさい、必要な書類は、おおむね、 :作業者用の具体的な「完成予想図」 です。 しかしゲーム業界の場合、いきなり完成予想図に相当する「仕様書」は書けないので、書籍『ゲームデザインプロフェッショナル』によるとまずゲーム中の大まかな実装予定事項を記述した『企画概要書』という書類を作成することもあると言われています<ref>『ゲームデザインプロフェッショナル』、P139</ref>。ただしこの「企画概要書」は、名前に「企画」とはついているものの、どちらかというと仕様書の方針を大まかに打ち合わせするための書類に近いので、いわゆる「企画書」とは異なります。 なお、一般のIT企業でよく書かれる「要求事項書」は、ゲーム書籍では紹介されていないので、おそらくゲーム業界では書かないのが普通だと思われます。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ===ゲーム業界での技術職=== 言葉というのは同じ国の国語でも、その業種や職場、社会集団で、微妙に違った使われ方をすることも多く、技術職、という言葉もゲーム業界での特別な使い方があるようですね。 この業界では、グラフィックデザイナ－やサウンドクリエイターやプログラマーが「技術職」<ref>『ゲームプランとデザインの教科書』、P125</ref>。技術職 = ￢(not)企画職、という事で、プロデュ－サーやプランナーやディレクターなどの「技術職」でない製作スタッフが企画職です。 ただ現編集者はプロデューサーとディレクターは対立する職種だというイメージはありますね。プロデューサーは企画職だろうけど、ディレクターは、"実"制作職ではないかな？ ===企画書=== *PREP法 基本的にビジネス上の書類は、結論を一番先に書く構成法が望ましいですね。もちろん商業ゲーム制作の現場でもそうでしょう。文献『ゲームプランナー入門』では、具体例として、PREP法を紹介しています。 PREP法とは、 :Point（結論）→Reason（理由）→Example（具体例）→Point（結論）。 ほかにもホールパート法やSDS法などがありますが、どれも冒頭で結論を示した後詳細を伝える方法で、ビジネス文書はやはり、その形式が常道でしょう<ref>『ゲームプランナー入門』、P141</ref>。 しかしこの社会、ビジネスが重要なのは事実だが結局、他者の行為や仕事をただ自分の欲望と利益に使い、他者の存在や詳細に興味のない人間は、とにかく結論だけを先に聞きたがるし、それ以外の事には事実上何の興味も持っていないでしょう。 *ゲームのルール 常識的な判断としては、ゲームにはルールがあるものですよね。ルールのないゲームというのは、ふつうあまり考えつかないし、イメージできない。 ですからゲーム企画書としては、ルールの説明が必要になる。キャラクター設定や世界観の解説があったとして、ルール説明がない企画書はふつう受け入れられない<ref>『ゲームプランとデザインの教科書』、P83</ref>。 ただ今ではゲームジャンルの固定化が進んでいるので、ルールはくどくど説明する必要はない、という場合はある。 企画書を誰が書くかという問題もある。業界の内部の重要人物か、全く外部の業界経験の無い人物か。 どちらににろ常識判断としては、ある程度のゲームルールの解説は必要だろう。 *プレイ人数 企画書には、ゲームのプレイ人数の記述も必要<ref>『ゲームプランナー入門』、P159</ref>。 ほんとの昔は、一人か二人でプレイするのがコンピューターゲームだったのですが、もはや時代は変わりましたね。インターネットを駆使して多人数プレイ、ソーシャルゲームなんてものも出てきました。 <!--(:※ ここから先、セクション末尾まで文章の編集者が異なります。編集者Hによる文章です。なお出典のある部分は編集者Hではなく別の編集者Sによるものです。)←すじ肉先輩さー、この記述は無いわ^^;;。だってこれって、みなさーん、以下の馬鹿文はHが書いたんだからね、俺、Sujの文じゃあないよ、馬鹿なのはHであって、俺じゃあないから。Sujはちゃんと出典は全部書いてんだよ^^、って言ってるのと同じだよね^^;;;;;--> さて、企画書に関しては、よくない企画の典型例というのはあるようですね。特に特定人物のネームバリューに依存した企画は良くないし、批判の対象になることも多いようです。ゲームとしては、イラストレーターや声優に超大物を起用することを強調した企画書ですね。 出典として『テリー伊藤のお笑い大蔵省極秘情報』あたり、確実に特定はできませんが、木村拓也のタレント性に頼った企画は、著者のテリー伊藤によってよくない企画の例として指摘されていたようです。 もっともテリー伊藤という人物自身が、ビートたけしの面白さ、彼を起用したことの良さによって世に出て知られるようになった人物なので、そんな事言っていいのかね、などと現編集者は少し思いますが…。 また今回の本題、ゲーム業界でもそういう良くない企画書が提出されることは多いようです。元ゲーム業界人でゲーム評論家の あべひろき が、90年代の著書で、過去にゲーム関連会社に勤務してたときの体験談を書いています。企画書の精査をしているときに、「人気声優の○○さん起用！」と書かれていたものがあったが、あべ氏がその声優の所属する声優事務所に確認の電話をとると、なんの商談も声優とも事務所ともされていなかったという事です。 もっとも企画書とは企画に過ぎないのではないだろうか？これらの他人のネームバリューに頼った企画が良くないのは事実だが、企画が通って実現する見込みが決定する以前は、むしろ声優本人や事務所にアクセスすることはないのが普通だろう。 もちろん企画者がその事務者や声優と懇意にしてる場合は、あらかじめ話をする可能性はあるが、しかし企画段階ではそもそも現実のビジネスになる可能性はそれほど高くない。声優や事務所にとってもその段階でもっともらしく話をされても、むしろ困惑するだけではないだろうか？ ただこういう他人任せの企画は、「プロデューサー的企画」と呼ばれるようです<ref>吉冨賢介『ゲームプランナー入門』、P71</ref>。クリエイティブな企画とは言えないわけですが、しかし商業的な娯楽作品には、クリエイターだけではなく、プロデューサーも絶対必要でしょう。 一般に企画でも他の仕事でも、他者の力や権威、その後の作業などに頼り切った態度は、どんな場所でも嫌われて批判されますし、それは職業の場だけではないでしょう。 また、ゲームの企画に関してもう一つの話題として、アメリカでも売ることに成功したドンキーコングの、ディレクターの宮本茂（任天堂）は、「人間の生理的なところを体感できるゲームを作れば、それがユニバーサル」、だと、語っていたようです<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P89</ref>。 ===「仕様書」、「企画書」=== 商業的なゲーム制作では、一般に、 発注 → 実装 → 調整 の過程を辿ります。 そして発注段階で重要な書類は、「企画書」と「仕様書」の二つです。まず『企画書』で作るゲームのコンセプトを固めてから、あとで『仕様書』で、より詳細に内容をを決める、という順序をとります<ref>『ゲームプランとデザインの教科書』、P43およびP45</ref>。 企画書<ref name="gcs72">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、72ページ</ref>は社内だけでなく協力会社にも見せる資料であり、開発者・協力者に対して手短かに、そのゲームの全体的なコンセプトを伝えるためのものです。 仕様書は、ゲーム制作では「設計図」であり、「完成予想図」であるといっていいでしょう。企画書よりより詳細にゲームの内容を決め、指定しています。 さて、話を進める前に、商業的に集団でゲームを作る場合の他の書類や必要事項の名称について、ここで簡単に書いておきます。 まず「発注書」とは，発注時に作られる、必要な書類群のことでしょう。「企画書」と「仕様書」も含みます。 「指示書」はむしろ、実装や調整段階でなされる、具体的なゲーム演出上の指定でしょうね。 試作品（しさくひん、英語で「プロトタイプ」proto-type）や企画会議（もしくは企画の打ち合わせ）なんて言葉も出てきますが、こういうのはあえてクドクド説明しなくても、直感的にイメージわきますよね。 『企画概要書』とは企画書とは異なるもので、仕様書に準ずる書類で、仕様書の方針を大まかに打ち合わせするためゲーム中の大まかな実装予定事項を記述している書類です。 『原案書』<ref name="gcs72" />は社内だけで企画がペイするかどうかの検討を決算書などを参考に分析・会議するための書類です。 こういう書類や用語に関する言葉の使い方は、商業的集団的なゲーム制作の場として妥当と思われるものをまとめてみましたが、もちろん職場によって、会社によって使い方や意味が微妙に変わってくる場合はあるでしょう。 さらにゲーム以外の一般IT業界や製造業でもそれぞれの慣習があり、今回の説明が成り立たない、そしてそこはより一般的な職場ですから、それぞれより一般的な言葉の使い方があると思います。 さて、コンセプトの具体例として、書籍『ゲームプランとデザインの教科書』によると、たとえば『ポケットモンスター』のメインのコンセプトは、「通信ケーブルを伝わって、ポケモンが入ったカプセルが移動して交換する」、が始まりだそうです<ref>『ゲームプランとデザインの教科書』、P109</ref>。 また、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、『メタルギア』シリーズのコンセプトは、「敵に見つからないように進む」、とのことですね<ref>吉冨賢介『ゲームプランナー入門』、P108</ref>。 イラストや音楽の発注は、一般的には企画が決まった後でしょう。 そもそもイラストレーションや音楽を対価を払って提供してもらったとして、それを実作品に使用しないのは、作者にとっては不本意なことだと思います。 アニメーターの故大塚康生氏は、アニメーション演出家が安易にアニメーターに大量の絵を描かせ、そこからいいもの、利用できるものだけ取捨選択する方法を批判していましたし、一般的に手仕事には作者の思い入れがありますから、安易な大量生産品と同じ取り扱いはできないと思います。 もっとも一方で、あるアメリカの日本人アニメーターが、同僚の日本人アニメーターが、自分の描いたものを日本の家族や友人たちが見ることができないことを不満に思っていた、という事を批判的に語っていたのを、現編集者は聞いたことがあります。 しかしゲームの場合、例外的にイラストや音楽が先行する場合はありますね。 RPG『クロノトリガー』は、企画の当初からイラストレーターをつとめた漫画家・鳥山明のイラストがあって、それをもとに作品を作ったと、鳥山のマンガの編集者であった元・少年ジャンプ編集の鳥嶋和彦は述べています。<ref name="tskdq">[https://news.denfaminicogamer.jp/projectbook/torishima/2]</ref>決めシーンなどのキービジュアルを先に決め、それに合うように設定を練りこんでいくという方式で、クロノは作られたようです。 企画書の制作ツールとしては、清書としては、オフィスソフトの「PowerPoint」と、アドビの「Illustrator」、または、アドビのソフトウェアは高価なので代わりにフリーソフトの「Inkscape」および「GIMP」がよく使われます<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日第1版第1刷、P.281</ref>。なお、Illustrator および Inkscape は、ベクトル画像を描画するソフトウェアです。 ただし、下書きなどでは、タッチペンと何らかの画像ソフト、またはタッチペン用メモソフトで下書きすることもあります。 業界で、ゲームプランナーと呼ばれる職種は、仕様書作成や進捗管理、テスト&デバッグ、スタッフとのコミュニケーション、などが仕事ですね<ref name="gpd9">『ゲームプランとデザインの教科書』、P.9</ref>。 また、ゲーム制作に関して、だれもが様々なアイディアを持っていると思いますが、メモを取って、もし忘れてもメモで思い出せるようにするといいですね<ref>『ゲームプランとデザインの教科書』、P.20</ref>。 アマチュアの企画なら、実際にプロトタイプ（プレイできる試作品のこと）を作って実作品で企画、仕様を説明してしまったほうが早いかもしれません。 参考文献『ゲームプランとデザインの教科書』でも、（試作品を）「ゲームプランナーを志す中で企画書や仕様書を書きながら、ぜひ自分でも作ってみましょう。プログラムや3Dモデルを簡単なものでいいので作ってゲームに仕上げてみましょう。」と述べています<ref>『ゲームプランとデザインの教科書』、P.3</ref>。 上記の本の図表によると、企画書では、「競合情報」、「世界観」、「ストーリー」なども記述して欲しいようです<ref>『ゲームプランとデザインの教科書』、P.43 </ref>。世界観とストーリーが分けられているのです。 物語とその舞台ですね。我々自身もこの世界で自分という役を演じている役者ですよね^^ {{コラム|ゲームの企画書とアニメーションの企画書| 商業アニメーションの世界では、企画の段階でストーリーの概要が決まっているようです。ただこれは、アニメーション作品の企画として、当然に必要とされる要素であるから記述されているわけで、実制作の過程で、実際のスタッフの意向により大幅に変更されることもあります。また、これらの企画では、キャラクター設定やキャラクターイラストのデザインも当然必要であり、かなり明確な形で提出されています。 たとえば、アニメ業界の企画書ですが、1990年代のアニメ『新世紀エヴァンゲリオン』の企画書の掲載されている『新世紀エヴァンゲリオン (ニュータイプ100%コレクション) 』（1997年2月28日初版発行、85～88ページ）を読むと、『企書画』の段階でもう、キャラクターイラストが主役だけでなくその友人や周囲の大人なども含めて、ほとんどのキャラクターでイラスト紹介されており、さらに全部の話数ぶんの粗筋と見せ場・意図を2～3行ていどで説明しています（ただし第1話と最終3話（24～26話）のみ説明が5行以上くらいと長い）。 因みに現編集者は実際にアニメーション業界で企画書を書いたことがありますが、その時に上司、制作会社の重役に指摘されたのは、1クール（3か月）か2クール分の実際のストーリーの具体内容を書いてほしい、との事でした。 一方ゲーム業界では、そういうキャラクター設定やストーリーは、企画段階では決まっていなくて、もし書かれていても邪魔だと感じられるようです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、149ページ</ref>。 業界の企画書で、強調してほしい内容とは、ゲームシステムと、そうシステムを設計した根拠のようです。なぜなら、ゲームの企画書でいう「コンセプトが重要」、と言う際の「コンセプト」の意味とは、ゲームシステムやゲームルールを設計した根拠のことだからです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、108ページあたり</ref>。 とはいえ、ゲーム業界の企画書でも、ゲームの世界観が「中世西洋ファンタジー風」なのか、「現代日本」か、「近未来SF風」なのか、などの設定はある様です。ネット上で公開されている商業ゲ－ム企画書からその様子が分かりますが、しかし、最初の企画書の段階で決まってる世界観はその程度まで、です。 背景としては、ビジネスモデルが根本的にアニメーション業界とゲーム業界とでは違う、という事情があるのでしょう。 }} {{コラム|キャラクター重視の物語論| アニメ―ション業界のビジネスモデルは、キャラクタービジネスだと言われています。1990年代の徳間書店のアニメーションに関する書籍（アニメージュ10周年記念）で、徳間の編集者が1980年代のアニメ業界を振り返ると、これはキャラクタービジネスだろうと、たとえば銀河鉄道999のアニメ―ションの人気も、メーテルなどのキャラクターの人気なのだという分析があり、アニメージュ創刊当時の『銀河鉄道999』特集では、ストーリー解説ではなく、キャラクターに焦点を当てた記事を組んだと、述懐（じゅっかい）しています。 また、漫画産業もキャラクター重視のようです。主人公に共感させるための様々な演出が凝らされている。そして主人公が身近に感じられることが重要だと指摘されています<ref name="tskdq" />。 これは日本人が物語軽視というよりは、海外でも同様であり、むしろ物語とはキャラクターを描くという要素が非常に大きいという事でしょう。多くのミステリの中でも「シャーロック・ホームズ」や「007」の人気が非常に高いのも、キャラクター性と結びついた作品だからでしょうね<ref name="tskdq" />。 1982年頃『鳥山明のヘタッピマンガ研究所』では、おおむね「マンガとは人間を描くことだ」という主張がなされています。 現編集者の記憶では、漫画がキャラクターだという主張を強くしたのは、漫画原作者であり、劇画村塾の開設者である、故[[w:小池一夫|小池一夫]]氏でしょう。上述の書籍の共著者、さくまあきら氏も、劇画村塾出身ですから、さもありなんということですね。 アニメ評論家の岡田斗司夫氏は、対談集『マジメな話』で、「古代ギリシア人や古代ローマ人はとても論理的で学問も発達していたが、一方でギリシア神話やギリシア悲劇が普及していた、人間には物語が必要なのだろう、自分達の社会の仕組みを、物語になぞらえて理解する、物語が学問や科学に匹敵する」といったことを述べていました。 ギリシア神話では実に人間的な神々の物語が語られていきます。 また、政治学者小室直樹氏は、別の書籍、おそらく、『日本人のための宗教原論』あたりで、「幼少期の子供にとっての、父親の力強さと畏怖のイメージ」こそが神のイメージだろうと述べています。ギリシア神話の最高神ゼウスは、明らかに父性を示していますよね。 これはユダヤ教やキリスト教の神のイメージだと考えてもいいと思います。この辺[[w:父なる神]]あたりに面白い記述がありますし、一方でイスラム教は神に父性を見出さない、などの興味深い分析も書かれています。 また、RPGゲーム『真・女神転生』では、裏設定ですが、作中の「悪魔」とは、力の象徴であり、それは父親を暗喩しているというコンセプトがあります（たしか公式ファンブック『CLUB邪教の館』あたりに記載がある）。だからこのゲームの主人公は、父親がいない母子家庭の子供だという事になっています。 }} {{コラム|ゲームにおけるキャラクター| ゲームの世界は、ソーシャルゲームや美少女ゲーム等はありますが、一般的にはキャラクター重視のメディアではないようです。シューティングゲーム『ゼビウス』のキャラクター性とか、『平安京エイリアン』のキャラクター性など、想像力を最大限に駆使すれば見出せないことはないですが、常識的にはキャラクターの魅力は提供されてはいないでしょう。 ゲーム学という概念を推進している人達は、ナラティブ（「叙述」という意味）といって、スーパーマリオなどのように作中にストーリー説明文が無いゲームのことを説明しているようです。 今現在では、可愛いキャラクターや恰好いいキャラクターを作品に取り込めるのなら、それを除外する必要はないでしょう。しかし現実の人気ゲームでは、キャラクター性があいまい、あるいはほとんど見出せないゲームも多いですよね。 ゲームのキャラクターは、開発途上で変更される可能性もある。海外展開しているゲームは、相手国の風習、社会状況に合わせて、キャラクター設定を変える場合もある。 今現在は、ソーシャルゲームでもキャラクターゲームは人気ですが、昔はそうではありませんでした。1990年代は、多くのゲームファンの間では、「キャラクターゲームはつまらない」と言われていました。 2002年にシリーズ発売開始されたRPG『ドットハック』シリーズの企画コンセプトは、面白いキャラクターゲームを実現することであり、2003年当時の社長（松山洋）がラジオ番組『ドットハックレイディオ』に出演した時に、「キャラクターゲームがつまらない」という一般的に言われている常識を打破したい、それがコンセプトだ、と述べていました。 しかし実際には1990年時点で魅力的なキャラクターゲームもありましたし、大ヒットすることは無くても、一部の大きな人気は得られていたようです。 }} {{コラム|企画が実制作に移ること| 1990年代後半に書籍を出し始めた、元ゲーム業界人・阿部広樹氏は、ゲーム会社から請け負って、そこで頓挫した、或いは難航した企画を練り直しする仕事をしていたようです。彼の著作ではその経験、経緯が語られています。 扱った一つの企画が、ガンダム風の巨大ロボット操作ゲームで、企画として完成度の高いものでした。 主要機体の巨大ロボットのグラフィック設定画は線画が完成していて、機体パイロットである主人公の顔グラフィック線画もある、ロボットの設定サイズ（「全長○○メートル」、「主要武器：○○」など）なども含む、仕様書がすでに用意されていました。 機体の名前には「メタトロン」や（たしか）「サンダルフォン」と、ネットの普及していなかった当時では調べるのにも手間のかかるユダヤ教の大天使の名前がつけられていました。 阿部氏も、このゲームは実現するだろうと、期待を込めて企画を進めていたようです。 しかし現実にはこのロボットゲーム企画は対象のゲーム会社では採用されず、実際に制作されることはありませんでした。このようにゲームの企画は、企画だけで終了してしまうものが沢山あります。 一般的に商業ゲームの製作は、本当にペイするかどうか、経営者や出資者の審査、判断の上、実制作に取り掛かるでしょう。 企画を作る方も仕事として取り組んでいるのですから、「没になるかもしれない」といって手抜きするはずもなく、内容的にも、前設定の完成度としても、どれも相当の力と手間暇をかけて企画を練りこんでゆくでしょう。 しかし結果は結果としてありますよね。採用される保証はないしされないほうが実際多い。その判断が正しかったかどうかはまた別の話ですがね。 }} {{コラム|他業種、一般的な意味での『企画書』| 企画書にもいろいろな段階があります。 #本当に企画の初期段階の、内部関係者しか見ない、思いつきを書きなぐったような企画提案の書類（厚さはせいぜい2～3ページくらいまで？） #企画が熟成してスポンサーや外部に見せられるようになった段階、もしくはその直前くらいの企画書（10ページを超える程度） #パワーポイントなどを使ってプロジェクタ－で見せるプレゼン資料の「企画書」 多くの業界の企画書で学生や外部の人間が見るのは 2.か 3.でしょう。 1990年代後半のゲーム評論家の阿部広樹の他者との共著による書籍によると、彼はゲーム業界で企画に関するトラブルを解決する仕事をしていたようですが、ある案件で、「当時の人気アニメ声優を起用！」など書かれた企画書をトラブル解決のために扱いましたが、彼らが調査した時には相手先のアニメ声優および声優事務所には全く話が行っておらず、対応にも難航したようです。ただ、本Wikiの別の場所でも指摘しましたが、企画時点では、その手の手続きを踏む必要はないでしょう。企画は企画にすぎませんし、実現の見通しが大きくはないその時点で話を持ってこられても、声優も事務所も、対応しようがないと思う。ただ、前編集者の記述では、許可をとれそうな見込みもないと書いてあるから、よほどのビッグネーム声優、要するにその声優の知名度だけをあてにしている企画ですから、悪い企画の例として非難されても仕方ないのかもしれません。しかし現編集者がさらに邪推、想像するに、彼らに企画トラブルの解決を依頼したゲーム会社は、自分たちは零細で知名度もパワーもないので、とてもその有名声優にはアクセスできない、ですからトラブル解決を稼業にしている業者なら、上手にその声優にアクセスしてくれるのでは？という期待があったのではないでしょうか？だとしたら、この事案に対する阿部氏らの態度、そして後になってわざわざ自らの著書でその出来事、関係者を愚弄して、それで自分たちが正しいかのように言うこの人物の姿勢は、職業人、仕事人として問題があるのではないでしょうか？ さて、ある程度企画が本格化してくると、スポンサーに提示するプレゼン用の資料とは別に、詳細な設定や企画意図を説明する、「詳述企画書（ここでの仮の名称）」も作られていきます。この書類は今後の作業のためのひな型の意味もあり、具体的にどんなキャラクターが出てくるか、イラストなども描かれます。 因みに、「ゲーム　企画書」でグーグル検索してみると、企画書としては 1.~3. そして今書いた「詳述企画書」が混然と表示され、書類として種類や趣旨は明確化されていないようです。企業が求職者を採用するために、企画書を求める場合は、プレゼン資料が最適のようですね。採用担当者にとって一番読みやすい資料だからでしょう。 企画書として、説得力のある内容なら、採用され実制作に移る可能性も高くなるのでしょうね。そのために指摘される事として、冒頭部分で、この企画と既存の作品の違い、今までの状況からの改善点、そして実際の改良の実現の見通しと方針を示すといい様です。これは「企画意図」や「コンセプト」と呼ばれますね。 「改善点→（競合他社の）現状説明→改善案の詳細」を、詳細企画書で段階的に説明するといいですね。新聞記事の書き方で、起承転結ならぬ「結・起・承」（けつきしょう）というのがあるので、それを参考にするのもいいでしょう。 また、売り込み先の消費者として想定しているターゲット層の指定も必要です。年齢はいくつくらいなのか、性別は男性か女性か、などですね。 企画の詳細を作りこんである場合や、すでにゲームソフトを実装してある場合のシステムの説明では、単にフローチャートを図示するだけでなく、そのシステムでプレイヤーは何ができるのか、簡単な遊び方の概要説明、等を加えるといいですね。 }} {{コラム|日産自動車の社内講習でのアニメーション業界人の講演| どこの企業でも社員向けの講習会はそれなりにあるでしょうが、日産自動車では過去、アニメーション制作会社の幹部を招いて、営業マンや企画職の社員のために講演してもらったことがあるようです。 テレビアニメーション『輪廻のラグランジェ』が2012年に放映されていた前後、日産が取材協力として制作に参加していたので、CG雑誌で、日産の講演会の様子が紹介されていました。 アニメーション業界では、実在しない物体や機械のイメージを、メカニック設定などで詳細にイメージを作り、絵コンテマンや、原画・動画のスタッフ間でその具体設計を共有するので、自動車製造業界でも参考になる要素があると考えられたようです。 日産の担当者は、制作会社の幹部の講演会に手ごたえを感じたので、もっと話を聞かせてほしいと要望すると、『輪廻のラグランジェ』の製作会社を紹介してくれたので、その会社にも講演をお願いし、さらに制作会社側の取材協力にも積極的に応じて、異業種同士のコラボレーションが形成されていったようです。 }} さて、ゲームの『仕様書』はそのゲームの設計図なので、起こりうる全てのパターンを網羅して設計を指定する必要があります…と言いたいところですが、そもそも本当にすべての操作に対する反応をもれなく記述できるのか? しかしできる出来ないにかかわらず、創作物が世に出れば、それはコンピューターアプリケーションとして、ユーザーに自由に操作される。その時仕様と創作物が、合理的に網羅的に作られていれば、プレーヤーはストレスなく、ゲームを楽しむ事が出来るでしょう。 ;検品、検収 さて、一般に技術系の業界では、図面などの設計図は、検品のさいのチェックリストを兼ねています。（ただし、ゲーム業界での「仕様書」が検品チェックリストを兼ねているかどうかは、2022/01時点、著者側の調査不足で不明。） しかし検品自体はゲーム業界でも行っている。協力会社から納品されたプログラムも、仕様を満たしているかチェックするだろう。 そしてチェックを通ったら、合格した製品として正式に受け取る。 納品物を合格として認めて受け取ることを「検収」（けんしゅう）という。（ゲーム業界でも）<ref name="creator_work:77">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、77ページ</ref>。ゲームの仕様書は、この検収を考慮に入れて書くのがいいだろう。 つまり逆に納品物が合格していないと判断されると、受け入れない、検収しない、納品者に作り直しを要求することになるだろう<ref>蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、76ページ</ref>。 商業ゲーム界では、営業マンが見積もりをするときの根拠は、仕様書、という事になる<ref name="creator_work:77" />。 外注テストに関しては、仕様書では不十分で、テスト用の別資料を用意する<ref name="gpd9" />。 バグチェックを外注しない場合は、「仕様書」を根拠にする場合が多いという<ref>吉冨賢介『ゲームプランナー入門』、P20およびP199</ref>。 つまりやはり、製品の仕様の基盤は仕様書、正しい仕様は、仕様書に書かれている事だという事になる。 開発後半のデバッグ段階などのバグチェックの段階に入る前に、仕様書を最新のゲームの状態とそろえる<ref>吉冨賢介『ゲームプランナー入門』、P238</ref>。つまりこれは、ゲームの仕様が制作過程で変わっていったら、逆に仕様書を書き換えて、実際の仕様に合わせるという事だ。 ==作成工程== ===完成予想図=== 仕様書はゲームの設計図。この書類を基盤にプログラマー、グラフィッカー、製作スタッフたちは作業を進める。しかし、ゲームの場合は、いきなり完成図を明確に決定するのは困難な場合が多い。そうなると方便的に大まかな設計、決定を作っていくという事になるだろう。事実、現実の業界では、大まかな「企画概要書」から詳細な「仕様書」へと、段階的に仕様が決まっていく<ref>『ゲームデザイン プロフェッショナル』、P.141</ref>。 一般的な製造業でもゲーム業界でも、あいまいな指定は事故のもとだと考えている。「とにかく、かっこいい感じでお願いします」なんて言いたくなることもあるけど、危険らしい<ref>『ゲームデザイン プロフェッショナル』、P.60</ref>。相手の「かっこいい」のイメージが、有り得ないものだったりする場合、あるよね^^;;;。 しかし場合によっては例外もあるようだ。裁量とか、阿吽の呼吸といったものも、人間関係ではある。しかし技術を語る場合、設計とは極力あいまいさは排除するものだろう。 ゲームでは、他者に発注するときは、ある程度相手の裁量にゆだねた方が良い場合もある<ref>『ゲームデザイン プロフェッショナル』、P.134</ref>。しかしその場合も、具体的にどういう実装予定のもので、どこに裁量を与えるのか明確にする必要があるという。裁量の発注については、『ゲームデザイン プロフェッショナル』本書を読めと、前編集者は書く。 とにかくこの編集者によると、Wikibooks をはじめ、Web上のWiki には何の価値もないと言う。世の中唯一価値のある文献は市販されている書籍で、Wikiの利用意味はその価値のある素晴らしい書籍を、出典としての記述を参考に、知ることだと言う。 それなら、Wiki書くのなんて辞めて、本屋でも始めたら? ===各機能の予想図の決定=== ソフトウェアの完成予想図は、画面を基準にすると伝わりやすい。 結局パソコン、情報機器を使っている時は画面を見ますからね。 <pre> △△モードの××画面 Aボタン: ダッシュ（走る）。押すとキャラが十字キーの選択方向にダッシュするようにプログラムする Bボタン: ジャンプ。押すとキャラが上方向にジャンプするようにプログラムする </pre> とか、こんな風に書くといいのではないでしょうか。それぞれのモード、画面での機能の満たすべき情報の一覧、を伝えておきたいですね。 ユーザ視点での仕様の事は、「外部仕様」、というようです。 ですからソフトウェア設計者は、各モードについて、画面表示、操作などの外部仕様の一覧を用意したいですね。 これは完成予想図でもある。 一方ソースコードの詳細は、内部仕様ですね。 商業ゲーム界では、原則的に内部仕様に関する書類は、あまり書かないようです。とはいえ設計項目の、ファイルや変数の具体的な記述は、ある程度は仕様書に書かれる。 そして外部仕様は「画面仕様」だけではない。例えばアクションゲームのモンスターの動き方のパターン、RPGのダメージ計算式、プレイヤーが具体的に実感できる仕様は、仕様書において指摘しておきたい。 ゲーム完成予想図とは、各種外部仕様を具体的にわかりやすく記述することになるだろう。 ==※例== 一冊の完成予想図の中で、説明が重複し、同じ記述が複数あるのは好ましくない。 ある記述内容が変更になる時、重複した先も変更しなければいけなくなる<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。 一般的製造業の製図でもこのルールは守られている。一つの末端部分の図面はそれだけで完結し、他の部分を参照しないようにしている。 ではここからは、ウディタのサンプルゲームを具体例に説明しよう。 本来サンプルがあれば仕様書は不要という事になるが、今回は説明用として、サンプルから仕様書を書き起こす。 まずサンプルゲームのメニュー画面、 :相談 :アイテム :特殊技能 :装備 :システム :セーブ と、６つのコマンドがある。 上から4つめの「装備」にカーソルを合わせた状態で決定ボタンを押すとキャラクター選択に移り、十字キーで目的のキャラクターを選択して決定ボタンを押すと、装備画面に移る。 さて、これを仕様書に書くと… 【'''装備キャラクター選択画面'''】 '''遷移直後の変化''' メニュー欄に「装備」コマンド位置に決定後カーソル画像「○○○.bmp」を表示。 キャラクター選択欄のカーソルの点滅が開始。キャラクター選択用の点滅用カーソルの画像は「△△△.bmp」。 '''ボタン押の反応''' キャラ選択欄で十字キーの方向にいる隣または次のキャラクターを選択でき、そのキャラの選択欄にて点滅カーソルが点滅表示される。 決定キーを押すと、選択中キャラクターの『装備部位の選択画面』に移る。 キャンセルキーを押すと『メニュー画面』に移る。 '''画像リソース''' ○○○.bmp :メニュー欄用の決定中カーソル画像 △△△.bmp :キャラクター選択欄用の点滅用カーソル画像 という感じ? その画面とやりとりする相手先の画面の名前と、あとはその画面の読み込むファイル、無駄なことは書かない、他の画面や他ファイルについては書かないほうが良い。 上述の仕様書の書式の参考は、吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、221ページ、の例『各画面の仕様書の例』の書式。 『装備部位の選択画面』に移ったあとの説明は続けて書かず、別途、たとえば『装備フロー仕様書』のような仕様書を作成せよ。 仕様変更で、『装備』コマンドの位置が（サンプルゲームでは上から4番目だが）上から6個目に変わったら、「メニューの装備コマンドは上から4番目にある」と書いた書類は全部作り直しになってしまう、そういう事態を避けたい。 そのため、あえて書類をモジュール化する。全体像は把握しづらくなるが、しかし全体像の把握については、そのための専用フローチャートを書類に設け、修正の手間が波及しないようにする。 例えば… '''装備フロー仕様''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 とかね。 フローチャートの作図をしたい場合は、オフィスソフトのパワーポイントの図形描画の機能で作図が可能。フローチャートの描き方はJISで決まっているので、それを参考に。中学校の技術家庭科でも習うのでその教科書を引っ張り出してきても良い。 例えば装備部分の選択画面は、 :右手 :左手 :身体 :装飾1 :装飾2 これがこう変更されると… :武器 :盾 :頭 :身体 :腕 :装飾 書類上の「装備部位の選択画面の「右手」選択にカーソルの合わさった状態で移る」というような記述はすべて書き直さざるを得ない。 そこでまず、『メニュー画面』や『キャラクター選択画面』では、他画面、例えば『装備部位選択画面』の具体的項目名称とその遷移法は書かないようにする。 『キャラクター選択画面』の仕様は、例えば、「選択キャラクターの『装備部位選択画面』に移る。」と書く。 「画面の変更時は原則、その画面のいちばん上のメニュー項目にカーソルの合わさった状態で画面が移る」と書く。 例えば装備関係のフローを描くときは、 :マップ画面 → 決定ボタン → メニュー画面 → 「装備」を選択で決定ボタン → キャラクター選択 → 決定ボタン → 装備品選択画面 と、続けて書くのはよくない。フローを分解する。 '''メニュー選択フロー''' 【 マップ画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 メニュー画面 】 '''装備関係フロー''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 こういう２分割でしょうか。 意味的にまとまりのある単位ごとに階層をフロー分割したい。 かといって、5分割や10分割と、階層が大きくなりすぎるのは、多重下請けのいんちき業界みたいなので、多くてもせいぜい３分割でしょうね。 そしてフロー同士を結ぶ記述が必要。 【メニュー画面仕様】 '''表示項目リスト''' 決定ボタンで下記の項目を選択できる。 ・相談　　　　　　:決定すればメニュー相談フローに移行 ・アイテム　　　　:決定すればメニューアイテムフローに移行 ・特殊技能　　　　:決定すればメニュー特殊技能フローに移行 ・装備　　　 　:決定すればメニュー装備フローに移行 ・システム　　　　:決定すればメニューシステムフローに移行 ・セーブ　　　 　:決定すればメニューセーブフローに移行 '''非表示項目''' ・キャンセルボタンでマップ画面に戻る とか? なお、各画面での遷移先の画面の説明と、フロー図での遷移先の画面との説明が重複しているけど、まあ気にしない、気にしない^^;;;。 参考文献の『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』の209ページ「状態遷移フローの例」と211ページ「各画面の仕様書の例」とでも、遷移先の画面の説明はそれぞれ重複しています。まあ場合によってはいつものようにこの後の記述でそこそこ言い訳するかもしれないけど…^^;;; ;一枚の図面の中での重複は、すじ肉大先生が許してくださる^^ というのは、例えば機能の似たものを二つ作る時、2個目の説明では、「○○については△△と同じ」と、書けるからね<ref name="aps229">吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ</ref>。 同じ一枚の図面なら、これで良い。 「○○については△△と同じ」「～～～と同じ」のように書いて具体的には書かない。<ref name="aps229" />。 ;その他 画面名やファイル名の名前は、具体的にしたい<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。 たとえば、上述のウディタのサンプルゲームの画面は :「マップ画面」、「メニュー画面」、「装備キャラクター選択画面」、「装備部位選択画面」と、したいね。 例えば 「画面1」、「画面2」、「画面3」、… とか、 「メイン画面」、「メニュー画面」、「サブメニュー画面1」、「サブメニュー画面2」、… にしたいときはあるし、事実上これは、命名の手間は省けるんだけど、他人に伝わりにくいので、ここは少し手間をかけて、具体的に内容ある命名にしたい。 {{コラム|| 法律の設計でも、相互参照が増えると、その法律の構造自体の複雑さが増加する現象が知られています。近年、世界各国でIT的な考え方を使って法律の設計論を研究しようという学問分野があり、その学問でそう指摘されています[https://www.nature.com/articles/s41598-020-73623-x Daniel Martin Katz, Corinna Coupette, Janis Beckedorf & Dirk Hartung "Complex societies and the growth of the law" , nature.com, Published: 30 October 2020 ]。これらのIT的な法学では、法律中の単語数、階層数、法律間の相互引用数が多ければ多いほど、その法律の構造は複雑になると考えられています。ご参考に。 }} ==== 要求事項 ==== IT界の一般的な慣習として、「要求事項」とは、完成品の満たすべき要件を示しています。 一般のIT業界では「要求事項書」という書類を作る場合もありますが、しかしゲーム業界では通例は、そのような追加の書類は作られません。ゲーム設計論の専門書を読んでも「要求事項書」などというものは紹介されていません。 ゲームデザイナーからの要求については「仕様書」または発注書などの手続きの際に、相手方に要求を伝えてしまいます。 E.Suj.の調査では、商業ゲーム界で『要求事項書」が作られている証拠は見つけられなかったようです。 なお、基本的に「要求事項書」とは、発注者と受注者の両方の打ち合わせによって作られていきます。 ただゲーム界では、発注書で、成果物が作中でどういう目的で使われるのか、意図・用途を伝えるのがいいようです<ref name="gp296" />。 ==== データ暫定値 ==== ゲーム中のデータの数値、例えばRPG武器の攻撃力、等、はすべての項目の想定値を設計図に記述します<ref>https://www.youtube.com/watch?v=KVdtNiB_lIQ 2020年3月14日に閲覧</ref>。 CSVファイルを作りましょうか、ソフトはエクセル? 【剣データ暫定値】 銅の剣: 攻撃力 7 鉄の剣: 攻撃力 18 ハガネの剣: 攻撃力 37 ミスリルの剣: 攻撃力 70 ほのおの剣: 攻撃力 57 （※ 剣ではランク5は欠番とする） デスブリンガー: 攻撃力 150 備前長船: 攻撃力 250 聖剣エクスカリバー: 攻撃力 450 魔剣レーヴァテイン: 攻撃力 450 具体的な指定も一緒に書いて、もちろん今後の調整で変更する可能性はあります。 ====データ仕様書==== データ仕様書とは、たとえばRPGなら :攻撃力: 敵の守備力との計算によってダメージを算出する のようなパラメータ計算式の定義を行った仕様書のことです<ref name="gpnt92">STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日初版第2刷発行、92ページ</ref>。 そして、この「データ仕様書」は、デバッグのための資料になります。デバッガーが、この資料と実際の動作を照合することで、仕様どおりにプログラムが動いているかを確認します<ref name="gpnt92" />。 書籍『ゲームプランナーの新しい教科書』では、アイテム（「やくそう」や「毒消し」などの）価格の「100」（100ゴールド）や「200」（200ゴールド）の具体値のあるデータ表のことを「仕様書」と言っている。この本では、本当は「100」になるべき数値が「200」になっている場合 「仕様書」で簡単に確認できる、記述されている。 一般にRPGの仕様書は非常に厚く、大冊になるという。オタキング岡田斗司夫氏が聞いたところによると、（出典は『オタク学講座』など）、ある有名RPGの仕様書は、書類の量をページ数ではなくKg で数えていたという。（しかし、1kg=何枚かな?^^）。有名作の仕様書は、分厚い電話帳のようなものが何冊もあるらしいです。データ台帳、 各種パラメータ、設計の背景の要求事項、まあいろいろ書かれているのでしょうね。 ;攻略本と仕様書 ゲーム攻略本にある、アイテムの効果値や、敵の能力値といった数値の一覧は、おそらくそのゲームのデータ台帳から転記されているのでしょう。 プログラム部分の設計図である仕様書も参考になるでしょうが、データ台帳には、直接的な数値が書かれています。 しかし実際の市販の攻略本には正しくない記述もある。制作側から正しいデータ、情報を手に入れられなかった場合もあるでしょう。 ==プランナーが事務方の現場で動いているスタッフとみて良いでしょう== ゲーム業界では、プランナーと言われる人が、連絡網の中心になって、いろいろな部署のあいだの情報伝達をします。 <div style="font-size:120%;"> <pre> ディレクター　━━━　プランナー　━━━━┳━　プログラマ 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　グラフィッカー 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　デバッガー </pre> </div> ディレクターが現実の制作のトップ、そしてその後ろにプロデューサー、管理職など、商業コンテンツとしての責任者がいることになりますね。 このプランナーは、ゲーム業界の場合、中間管理職? のような権限があり、各部署（プログラマ部署やグラフィッカー部署など）やディレクター（監督）の間で、様々な調整や連絡をしていきます。 アニメーション業界で言えば、制作進行とか、制作デスク、のような立場でしょうか。 「プランナー」というと、プラン「計画」を練るという意味になりますが、テレビ業界でいう「AD」アシスタントディレクターのようなイメージのほうが近いかもしれません<ref>吉冨賢介『ゲームプランナー入門』、P236</ref>。勿論現場を現実に回すための様々なプランは必要ですね。 ==ゲームに取り込むイラスト、音楽== 商業ゲームで、イラストや音楽、そしてそれ以外でも、他者に何らかの作業を発注する場合、特に常識的、慣習的な発注フォーマットというのは無いようです。割と場当たり的に、作品、状況にあった発注形態がとられているのでしょう<ref>『ゲームデザイン プロフェッショナル』、P.146</ref>。 音楽やイラストの提供を他者に求める場合は、もちろんその作品に関するその絵描きや音楽家の関わり方にもよりますが、そのゲーム内でどのように絵や音楽を使うか、明確に説明できることが望ましいですね。 様々な事象項目チェックリストも用意したい<ref>『ゲームデザイン プロフェッショナル』、P.159</ref>。 ===他者に委ねる場合=== 商業としても、あるいは同人としても、割と外部の他者に描いてもらったイラストや音楽をゲームに取り込むことは多いでしょう。商業ならそれこそ、対価を明示したうえで外注、ということになる。 例えば他者にイラストをお願いするときは… :構図、 :希望のポーズ、 :塗り方、 :テイスト、 この辺を相手に伝えておきたいですね<ref name="gpd128">『ゲームプランとデザインの教科書』、P.128</ref>。 さて、ゲームには美術的な素材として、イラストレーション、アニメーション、コミック（漫画）などがありますが、これらはもちろん絵画としての共通点はありますが、一般的にはそれぞれ別分野と見なした方がいいようです<ref name="gpd128" />。 特に商業の世界では、美術作品という共通点はあっても、他分野の創作は手間や方法論の整備や熟練などの問題で、それぞれの専門家に依頼するのが妥当でしょう<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P168</ref>。 そして、商業ゲーム界では、あるいはそれ以外でもあるかもしれませんが、キャラクターイラストを描いてもらうときは、実在のアイドルやモデルの名前をイメージとして、提示する場合もある<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 あるいは仮に自分は絵が上手に描けなかったとしても、ラフな簡単な絵をかいて、どんなキャラクターのどんな構図を描いてほしいか、大体の要望を伝える、ということもありますし、また、その構図が作中でどういう目的で使われるか、意図用途を伝える<ref name="gp296" />、というのも意義がありますね。 ただ他人に何かを伝えるということは、一般的な意味でも難しいことですよね。ここでイラスト描きに希望を伝えるにしても、長文の書類だと読んでもらえないこともあるし、口頭でもその相手にとって分かりにくい説明というのがある。 ですから、出来るだけ、ですね、わかり易く受け入れやすい言及が必要です<ref>『ゲームデザイン プロフェッショナル』、P295</ref>。 ;アダルトゲーム アダルトゲームでは、シナリオも外注の場合があるらしい<ref>畑大典著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P129</ref>。しかしむしろこれは企画販売の会社と、制作主体が別だという話ではないだろうか？ ところで皆さんは、アダルトゲームって、プレイします?^^;;; ;そもそもイラストの発注者は、絵描きの頬を札びらで叩いて描かせているわけ? 基本的には有償のイラストの場合は、発注者の指定にイラストレーターは従うでしょう。それでも媒体にもよりますけどね。ゲームの場合は、発注者の指定に従う縛りは大きいと見ていいですね。 そもそも要求事項がどうのとか、書類に関する理屈をグダグダ述べれば、さらにこの縛りは強くなりますね。事実上はその辺の判断はあいまいなのですが、発注者は一般的にリテイク（書き直し）を出す権利があるとみて良い。 例えばイラストの仕事を有償で得たとして、実際にはそのイラストの使われ方も問題になりますが、「セーラー服の少女を描いてください」と頼まれてそのイラストを引き受けたら、ブレザー服の少女を描いて提出するのは不適切でしょう。リテイクを出される<ref>『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.208</ref>。それどころか、仮にセーラー服の少女を描いたとしても、発注元がそのイラストの質が良くないと判断したら、一般的にはリテイクを出してよいと見られています。しかしもう一つ問題があって、そのイラストレーターはそもそもなぜブレザー少女を描いたのか？そしてもう一つ、現編集者の推奨としては、イラストレーターはリテイクの扱いについて、具体的にどう扱うか、発注者とよく話し合ってある程度ルールを明確にしておいた方が良いと思います。 前編集者はこの問題について、社会のルールがどうのとか、自称イラストレーターがどうのとか、教育がどうのとか、2005以前がどうのとか、いつものように狂った理屈を長々書いていますが、全て愚か者の自己本位なたわごとでしょう。 {{コラム|絵の仕事とはどんな仕事?| さて、前編集者 Suj. は、このコラムで、2005~2008 にかけて、絵の仕事を、「自由に絵が描ける」「漫画や絵の仕事は、競争を気にしなくていい」と、思い込んでいる人がいたと書いているけど、これ本当の事かね? どうせいつもの[[w:かかし論法]]じゃあないの? そもそもなんでこの話では、大好きな出典出さないわけ? しかもこの人物は、教育に携わる資格なんてまるでない性格異常者なのに、なぜか偉そうに大上段に教育論を語りたがる。 そもそもそんな人がいるかどうかも怪しいが、それは小中高の美術教育、自由に絵を描かせる授業方針のせいなんだって。 この人物の妄想世界では、「小学校の図工のような自由な仕事 <nowiki>=</nowiki> プロ絵描き」と思い込んでいる人がいるんだって。ほんとかね? 何かこの人物が大好きな江川達也もそんなこと書いていたようだよ。 2001~2005の雑誌コラム、スパ? 漫画業界について「漫画家は、競争が無くて自由に漫画を描ける仕事」、という言説に怒っているんだって。しかしほんとにそんな主張があったの？江川もストローマン叩いてるだけじゃあない？そしてわざわざゆとり教育に言及? インチキ臭いね。 しかも江川が書くには、「漫画家はとても競争の厳しい世界だ。」ってことだけど、まあそんな部分はあるけど、結局はそこで生き残って飯食ってる俺は偉いって話でしょ? 江川ってほんとにいい漫画描いてる? 単にインチキな業界人に気に入られているだけでしょ? あと小林よしのりは、ゴーマニズム（そろそろマジメニズムになったら?）宣言で、プロデビュー前、「マンガ出版社は、漫画家が死ぬまで面倒を見てくれる、まるで公務員のような終身雇用の業界が漫画業界」と思い込んでいた、と、描いていたって言うけど、そうね、私もこんな記述昔読んだような気はするけど… しかし、E.Suj.はこの小林の当時の考えはよくて、今同じ様な考えを持つと阿保馬鹿書くわけ? しかもほんとにこんな考えの人が今いるのかね? 出典くれない? まあ確かに実際に今現在、そんな考えの人はひょっとしたらいるかもしれないけど…。しかしここでわざわざその話題をコラムとやらにして、彼らを愚弄する意味なんてある? }} ===特定の絵に関して、誰でも質やクオリテイを語ることはできる。しかしそれは主観的な判断に過ぎない上、自分自身が神のように凄い絵を描けるわけではない。だからあまり威張って断定的にそれを語るなよな。=== 事実上今現在の商業ゲーム界の主流の絵は、まずCGであり、手描きの場合は細密かつCG特有のグラデーション、その他最新のテクニックを駆使した多色の華やかな絵柄 でしょう。 その絵が上手に描かれたいいものであれば、ゲーム業界の馬鹿馬鹿しい連中は、この絵はクオリティが高い、などと宣うわけです。 で、その条件から外れた絵を見ると、彼らは下手だ下手だと騒ぎだすのでしょう。 ;アニメーション、漫画、CGイラストレーション 上記の3つの絵画は、多少質が異なるものになるでしょう。前者二つは一枚絵で完結していないので、ある程度簡略化した手間をかけない描き方がなされる。一枚絵のイラストはそれだけで完結なので、事実かなり手間と時間はかける事が出来る。 しかしどちらにしろ、時間と手間は様々な諸事情のバランスで、それが選ばれ決定されますね。 特定の絵が上手いとか下手なことにこだわり、朝から晩までその議論ばかりしている愚か者は多いですが、事実上、時間と手間の大小にかかわらず、特定の人の心を打つ絵というのはある。 しかしやはりその心の動き自体が、主観的なものであるでしょう。 ;後日修正 手間と時間をかけた絵が欲しいなら、後日修正という道はありますね。商業漫画でもアニメーションでも、後から修正を加えて絵の質を高めることはあるでしょう。 基本的にはあらゆる物事が、時間と手間をかけたことによって評価は高まりますが、しかし我々の時間も労力も無限ではない。いいバランスで、いい完成度で、多くの物は創作終了されています。 ===芸術、自由、文化。そして娯楽、商業作品=== さて、前編集者Suj. は常に自分にとって都合のいい主張をしている市販本を探し、そしてそれが見つかったら購入し（しかしそのお金はどこから出ているのだろう?）、そしてそれを斜め読みした後、このサイトでクオリティ最悪の駄文を書き散らしているのだが、彼の愛読書には、ゲーム作りに必要な資質は、作家性と「人を楽しませたいと思う気持ち」<ref name="gpl246">『ゲームプランナー集中講座』、P246</ref>、だと、書かれている、らしい。 まあこのサイトを見てわかるとおり、彼自身はその二つとも全く持ち合わせていないのだが… そしてその馬鹿馬鹿しい本には、ゲーム会社の採用担当も、ゲーム会社自体も、クリエーターに自己表現は求めていない、と書いている<ref name="gpl246" />。つまり、ゲーム会社の幹部たちに都合のいい作業を安い賃金でしてくれる、奴隷が欲しいということだろう。 そして、E.Suj,はとにかく他人の褌をはいて威張ること以外何もしないのだが、彼のイラスト分野の愛読書には、依頼内容を無視して自由に絵を描こうとする人は、「プロ」ではなく「芸術家」、と書かれている<ref> 『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.198</ref>（らしい）。 ====芸術と商業漫画==== 漫画『サルでも描けるまんが教室』には、芸術と商業漫画に関する面白い記述がありました。 {{コラム|竹熊と相原のサル漫| 一応この漫画を知らない人のために少し説明すると、竹熊健太郎氏が原作、相原コージ氏が作画、まあ必ずきっかり分業がなされているかはわかりませんが、この二人が漫画内で主人公にもなって、商業漫画ハウツーギャクが展開します。 相原「む～…。俺たちはこんなくだらない漫画を描いてていいのだろうか…」 竹熊「どうした相原？」 相原「俺たちはもっと本質的な作品を作るべきではないか？例えば…資本主義などという下らない次元にとらわれてはいけないのではないだろうか…俺たちは国や大企業におどらされているのではないか？やはり漫画にも芸術は必要だろう…」 竹熊「バッキャローー!!!（ガッと、相原を殴る）」 相原「な、何をする…」 竹熊「お前は芸術をぜんぜん分かっちゃあいない！」 相原「そんなことない…」 竹熊「じゃあ、お前のいう芸術とは何か、言ってみろ？」 相原「それはー…、人間の内面の…真実ってゆうか…」 竹熊「にんげんのぉー、ないめんの～しんじつぅ～??? あのなー、お前は権威にとらわれてはいけないとはいうが、じゃあお前のその意見は、どこかの芸術大学の教授の権威にすがっているだけではないのか！？」 相原「そんなことない…お前こそ、政府や商業メデイアによる宣伝のつくった権威にとらわれているじゃないか。」 竹熊「ああそうかね。だけどお前だって、芸術教授の権威にあやかって自分も地位と名誉が欲しいだけだし、結局、お前もカネが欲しいだけなのだ。」 ……と、いうような、もちろんこの漫画は第一にギャグマンガですが、商業漫画界やアニメーション界での、芸術という言葉の捉え方をよく示していると思います。 例えば、『ねじ式』という漫画に芸術性があると評価された、つげ義春さんも自身の漫画が芸術でくくられることを嫌っていました。漫画家は芸術家ではなくて職人だ、と語っていたインタビュー記事を読んだことがあります。 しかし実はこのサル漫、最新最終作『サルまん2.0』ではさらに面白い展開を迎えています。 少し書きますが、「とんち番長」という漫画で一世を風靡した竹熊と相原（もちろんこの漫画内の、ですよ）だったが、やがて落ちぶれ、それでも再起を図って、漫画出版社に持ち込みする。 そこでの編集者が採用を断る時の言葉。 「いやいや先生。我々の雑誌では、先生たちの高尚な漫画は掲載できませんよ…。読者はみんなほんの愚かな子供たちで、先生たちの高尚な漫画はとてもとても理解できません…」 つまり過去大騒ぎして否定していた芸術側に、いつの間にか落ちぶれて、竹熊と相原は所属していたわけです… }} ====私小説==== {{コラム|基本的に娯楽産業の連中は、芸術という言葉も概念も嫌う| 前コラムでも書きましたが、結局商業アニメーションや漫画界では、娯楽、楽しい或いは扇情的、売れる、ということが重要で、あまり芸術的なことを語ると徹底的に嫌われます。 このコラムの前編集を見てもらえるとわかりますが、前編集の筆者もその感覚に追従して、好きかってなことを書いています。 特に自己探求にこだわった創作は、「私小説」などと呼ばれて揶揄されます。 1998年、オタキング岡田斗司夫の対談集『マジメな話』でも、当時のエヴァンゲリオンの映画版を「私小説」だと、対談相手の小説家・今野敏が批判していました。事実上この作品は衒学的な、疑似芸術作品でした。 やはり何らかの娯楽性、収益性、芸術性の問題が、常に創作作品には付きまとうようです。 さて、例えば、大正文学の売上のベストセラーは、 :倉田百三『出家とその弟子』、 :島田清次郎『地上』、 :賀川豊彦『死線を越えて』、 三大ベストセラーですが、しかし今や彼らは文学史の教科書には、滅多にのりません。せいぜい高校日本史の教科書で、倉田が少し紹介されているくらいです。 現代の教科書でよく大正時代の小説家として紹介される芥川龍之介は、じつは当時は倉田・島田らほどには売れていない作家です。また、「私小説」といわれるジャンルも当初から収益性はない。もっとも、芥川が私小説を書き出したのは晩年のことですが…。 しかし前編集者はこの問題に、毎日新聞の戦略とか、左翼がどうのとか、研究不足がどうのとか、なんかいい加減なこと書いているようですが、まあどうでもいいか。 現編集者は上記の3ベストセラーの、倉田の作品だけ読んだことがある。親鸞の話だったけど、私にとっては底の浅いいい加減な話に見えた。はっきり言って芥川の小説の方が、はるかに意味と深い内容を持っているだろう。 島田清次郎に関しては、「栄光なき天才たち」という漫画で、この人物の詳細と人生が描かれていたのを読んでいる。この漫画の中では彼は、「地上」の最終巻の採用を、編集者に断られている。 }} === ローポリ関連の作画 === 単元『[[ゲームプログラミング/3Dグラフィック#ローポリ制作手法的なこと]]』で説明した。 ==レポートは結論だけを読んでも分かるように書く== レポートなどは、ゲーム業界なら、途中を読み飛ばしても、内容がおおまかに分かるように書きたい。 別に冒頭で結論を述べる必要はありませんが（会社による）、しかし、仮に書類のページの順序どおりに他者が読まなくても、 レポート全体の内容を把握できるように書くのが推奨です。 ==書類は誰でも簡単に理解できるように書きたい== 書類の言葉選択は、「中学生の知識でも理解できる言葉を使う」、のが望ましいですね。言いやすいフレーズ、理解しやすいフレーズ、こういう言語選択も重要です。<ref>『ゲームデザイン プロフェッショナル』、P101</ref> 基本的にゲーム界に限らず、あらゆる場所で、わかり易い言葉を使うことが重要ですし、相手の理解に配慮することは必要でしょう。E.Suj.のように自分が理解できなければ全て相手のせいにし、相手が理解できないのもすべて相手のせいにするのは、一番有り得ない最低の態度でしょう。 == 脚注・参考文献 == dpobx7ab05sdlsac705ewjwnsc8ckam 206838 206837 2022-08-20T03:04:36Z すじにくシチュー 12058 /* 要求事項 */ 要求事項書というのが無いということの出典。 wikitext text/x-wiki {{substub}}このページの主要執筆者は、ゲーム業界経験者ではないので（2022/1時点）、ここの記述は調べ物としては役立ちません。 2022/1時点でゲームプログラミングと直接の関係ない話題が長い、という問題があるので、より簡潔、かつ分かり易い記事への編集にご協力いただけたら幸いです。もっとも現編集者Hは、解ってるならそれを書いた奴が書き直せ、そもそも余計なことは最初から書くな、…とは思いますが…。 このページは、教科書としてゲームプログラミングの方針を説明する際に、どうしても書類についての説明が必要だから記述されています。現状では、一般IT業界や製造業などの設計図を参考に説明がなされています。 == 本書の目的 == 本書は、ゲームデザイナーのための教科書ではありません。 メインページ、「[[ゲームプログラミング]]」の題名どおり、プログラマーのための教科書です。プログラマーがゲーム制作に興味をもって実際に作り始める際に、調べ物の手間を減らすために書かれた参考書籍です。 ゲームデザインに関する解説を望む方は、別途、他の参考資料に当たってみてください。 ==「仕様書」== ここでいう「仕様書」とは、ゲームの設計図のことです<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.126</ref>。しかも職業的に集団でゲームを作るときの書類です。 ではまず、「設計図」とは何か、について、考えていきましょう。これは普通科高校では学習しない事項です。 ゲーム業界では、「仕様書」を含む書類群の「発注書」には、決められたルールや書式はありません。だから作るゲーム内容や製作チームごとに、適切な発注書のありかたを毎回考える事になります<ref>『ゲームデザイン プロフェッショナル』、P.145</ref>。 職業的なゲーム開発では、一般に :発注 → 実装 → 調整 というプロセスを経て<ref>『ゲームデザイン プロフェッショナル』、P.61</ref>、最終的にとりあえずの完成になります。 ゲーム産業での「仕様書」は、発注の段階での書類です。 ==集団ゲーム制作での解説文== 発売禁止になってしまった書籍（おそらく。しかし何故？）『国際おたく大学―1998年 最前線からの研究報告』（岡田斗司夫ほか、光文社）に書いてあった事例なのですが、G.O.D.と言うイマジニア社のRPGゲームに対する大学生（岡田は当時、大学講師だった）の取材があって、そのGODの開発に参加した劇作家の鴻上尚史（こうかみ しょうじ）氏と、エニックスの堀井雄二（ほりい ゆうじ）氏とが、対談した経緯が、紹介されていました。 劇作家の鴻上は、ゲームに演劇のリアリティを入れようとして、スタッフに「間（ま）を意識したシナリオを書いてほしい」と要求したが、うまく行かずに難航したと体験談を述べています。 対談相手の堀井は、鴻上のその体験談に対し「『（※ここで3秒休止）』とか書くと良いですよ」と、指示書で具体的に書くと良い、とアドバイスした、と、岡田の書籍にある大学生のレポートにあります。 おそらくドラゴンクエストのゲーム開発でも、このように具体的な指定を必要に応じて出していた・いるものと思われます。 21世紀現代の、商業ゲームの現場でも同様であり、書籍『ゲームデザイン プロフェッショナル』にもありますが（※かぎカッコ内が引用）、「もっとかっこよく調整してほしい」という問題であれば、たとえば「もっと目立たせたいので、アニメーションのシルエットを全体的に今より少しだけ大きくしてほしい」<ref name="gp296">『ゲームデザイン プロフェッショナル』、P296</ref>という具体的な指定が妥当でしょう。 == 集団作業に必要な書類 == ===設計図=== IT業界やゲーム業界では、集団作業で制作開始をしようとする際、まず、いきなり設計図を作るのではなく、まず先に試作品（しさくひん、英語で「プロトタイプ」proto-type）のプログラムを作り、企画で考えた各種システムなどのアイデアが有効かどうかを検証します。 そのプロトタイプで、企画のアイデアが本当に有効であるかを確認してから、もし有効だったら、本格的な制作を開始します。 もしかしたら会社によっては、企画会議（もしくは企画の打ち合わせ）よりも先にプロトタイプを作るかもしれません。 さて、会社へのプロトタイプ提出で、制作続行・制作本格化の賛同が会社から得られたとしましょう。 IT業界でも製造業でも、どこの業界でも集団作業で、制作の合意を作るさい、必要な書類は、おおむね、 :作業者用の具体的な「完成予想図」 です。 しかしゲーム業界の場合、いきなり完成予想図に相当する「仕様書」は書けないので、書籍『ゲームデザインプロフェッショナル』によるとまずゲーム中の大まかな実装予定事項を記述した『企画概要書』という書類を作成することもあると言われています<ref>『ゲームデザインプロフェッショナル』、P139</ref>。ただしこの「企画概要書」は、名前に「企画」とはついているものの、どちらかというと仕様書の方針を大まかに打ち合わせするための書類に近いので、いわゆる「企画書」とは異なります。 なお、一般のIT企業でよく書かれる「要求事項書」は、ゲーム書籍では紹介されていないので、おそらくゲーム業界では書かないのが普通だと思われます。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ===ゲーム業界での技術職=== 言葉というのは同じ国の国語でも、その業種や職場、社会集団で、微妙に違った使われ方をすることも多く、技術職、という言葉もゲーム業界での特別な使い方があるようですね。 この業界では、グラフィックデザイナ－やサウンドクリエイターやプログラマーが「技術職」<ref>『ゲームプランとデザインの教科書』、P125</ref>。技術職 = ￢(not)企画職、という事で、プロデュ－サーやプランナーやディレクターなどの「技術職」でない製作スタッフが企画職です。 ただ現編集者はプロデューサーとディレクターは対立する職種だというイメージはありますね。プロデューサーは企画職だろうけど、ディレクターは、"実"制作職ではないかな？ ===企画書=== *PREP法 基本的にビジネス上の書類は、結論を一番先に書く構成法が望ましいですね。もちろん商業ゲーム制作の現場でもそうでしょう。文献『ゲームプランナー入門』では、具体例として、PREP法を紹介しています。 PREP法とは、 :Point（結論）→Reason（理由）→Example（具体例）→Point（結論）。 ほかにもホールパート法やSDS法などがありますが、どれも冒頭で結論を示した後詳細を伝える方法で、ビジネス文書はやはり、その形式が常道でしょう<ref>『ゲームプランナー入門』、P141</ref>。 しかしこの社会、ビジネスが重要なのは事実だが結局、他者の行為や仕事をただ自分の欲望と利益に使い、他者の存在や詳細に興味のない人間は、とにかく結論だけを先に聞きたがるし、それ以外の事には事実上何の興味も持っていないでしょう。 *ゲームのルール 常識的な判断としては、ゲームにはルールがあるものですよね。ルールのないゲームというのは、ふつうあまり考えつかないし、イメージできない。 ですからゲーム企画書としては、ルールの説明が必要になる。キャラクター設定や世界観の解説があったとして、ルール説明がない企画書はふつう受け入れられない<ref>『ゲームプランとデザインの教科書』、P83</ref>。 ただ今ではゲームジャンルの固定化が進んでいるので、ルールはくどくど説明する必要はない、という場合はある。 企画書を誰が書くかという問題もある。業界の内部の重要人物か、全く外部の業界経験の無い人物か。 どちらににろ常識判断としては、ある程度のゲームルールの解説は必要だろう。 *プレイ人数 企画書には、ゲームのプレイ人数の記述も必要<ref>『ゲームプランナー入門』、P159</ref>。 ほんとの昔は、一人か二人でプレイするのがコンピューターゲームだったのですが、もはや時代は変わりましたね。インターネットを駆使して多人数プレイ、ソーシャルゲームなんてものも出てきました。 <!--(:※ ここから先、セクション末尾まで文章の編集者が異なります。編集者Hによる文章です。なお出典のある部分は編集者Hではなく別の編集者Sによるものです。)←すじ肉先輩さー、この記述は無いわ^^;;。だってこれって、みなさーん、以下の馬鹿文はHが書いたんだからね、俺、Sujの文じゃあないよ、馬鹿なのはHであって、俺じゃあないから。Sujはちゃんと出典は全部書いてんだよ^^、って言ってるのと同じだよね^^;;;;;--> さて、企画書に関しては、よくない企画の典型例というのはあるようですね。特に特定人物のネームバリューに依存した企画は良くないし、批判の対象になることも多いようです。ゲームとしては、イラストレーターや声優に超大物を起用することを強調した企画書ですね。 出典として『テリー伊藤のお笑い大蔵省極秘情報』あたり、確実に特定はできませんが、木村拓也のタレント性に頼った企画は、著者のテリー伊藤によってよくない企画の例として指摘されていたようです。 もっともテリー伊藤という人物自身が、ビートたけしの面白さ、彼を起用したことの良さによって世に出て知られるようになった人物なので、そんな事言っていいのかね、などと現編集者は少し思いますが…。 また今回の本題、ゲーム業界でもそういう良くない企画書が提出されることは多いようです。元ゲーム業界人でゲーム評論家の あべひろき が、90年代の著書で、過去にゲーム関連会社に勤務してたときの体験談を書いています。企画書の精査をしているときに、「人気声優の○○さん起用！」と書かれていたものがあったが、あべ氏がその声優の所属する声優事務所に確認の電話をとると、なんの商談も声優とも事務所ともされていなかったという事です。 もっとも企画書とは企画に過ぎないのではないだろうか？これらの他人のネームバリューに頼った企画が良くないのは事実だが、企画が通って実現する見込みが決定する以前は、むしろ声優本人や事務所にアクセスすることはないのが普通だろう。 もちろん企画者がその事務者や声優と懇意にしてる場合は、あらかじめ話をする可能性はあるが、しかし企画段階ではそもそも現実のビジネスになる可能性はそれほど高くない。声優や事務所にとってもその段階でもっともらしく話をされても、むしろ困惑するだけではないだろうか？ ただこういう他人任せの企画は、「プロデューサー的企画」と呼ばれるようです<ref>吉冨賢介『ゲームプランナー入門』、P71</ref>。クリエイティブな企画とは言えないわけですが、しかし商業的な娯楽作品には、クリエイターだけではなく、プロデューサーも絶対必要でしょう。 一般に企画でも他の仕事でも、他者の力や権威、その後の作業などに頼り切った態度は、どんな場所でも嫌われて批判されますし、それは職業の場だけではないでしょう。 また、ゲームの企画に関してもう一つの話題として、アメリカでも売ることに成功したドンキーコングの、ディレクターの宮本茂（任天堂）は、「人間の生理的なところを体感できるゲームを作れば、それがユニバーサル」、だと、語っていたようです<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P89</ref>。 ===「仕様書」、「企画書」=== 商業的なゲーム制作では、一般に、 発注 → 実装 → 調整 の過程を辿ります。 そして発注段階で重要な書類は、「企画書」と「仕様書」の二つです。まず『企画書』で作るゲームのコンセプトを固めてから、あとで『仕様書』で、より詳細に内容をを決める、という順序をとります<ref>『ゲームプランとデザインの教科書』、P43およびP45</ref>。 企画書<ref name="gcs72">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、72ページ</ref>は社内だけでなく協力会社にも見せる資料であり、開発者・協力者に対して手短かに、そのゲームの全体的なコンセプトを伝えるためのものです。 仕様書は、ゲーム制作では「設計図」であり、「完成予想図」であるといっていいでしょう。企画書よりより詳細にゲームの内容を決め、指定しています。 さて、話を進める前に、商業的に集団でゲームを作る場合の他の書類や必要事項の名称について、ここで簡単に書いておきます。 まず「発注書」とは，発注時に作られる、必要な書類群のことでしょう。「企画書」と「仕様書」も含みます。 「指示書」はむしろ、実装や調整段階でなされる、具体的なゲーム演出上の指定でしょうね。 試作品（しさくひん、英語で「プロトタイプ」proto-type）や企画会議（もしくは企画の打ち合わせ）なんて言葉も出てきますが、こういうのはあえてクドクド説明しなくても、直感的にイメージわきますよね。 『企画概要書』とは企画書とは異なるもので、仕様書に準ずる書類で、仕様書の方針を大まかに打ち合わせするためゲーム中の大まかな実装予定事項を記述している書類です。 『原案書』<ref name="gcs72" />は社内だけで企画がペイするかどうかの検討を決算書などを参考に分析・会議するための書類です。 こういう書類や用語に関する言葉の使い方は、商業的集団的なゲーム制作の場として妥当と思われるものをまとめてみましたが、もちろん職場によって、会社によって使い方や意味が微妙に変わってくる場合はあるでしょう。 さらにゲーム以外の一般IT業界や製造業でもそれぞれの慣習があり、今回の説明が成り立たない、そしてそこはより一般的な職場ですから、それぞれより一般的な言葉の使い方があると思います。 さて、コンセプトの具体例として、書籍『ゲームプランとデザインの教科書』によると、たとえば『ポケットモンスター』のメインのコンセプトは、「通信ケーブルを伝わって、ポケモンが入ったカプセルが移動して交換する」、が始まりだそうです<ref>『ゲームプランとデザインの教科書』、P109</ref>。 また、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、『メタルギア』シリーズのコンセプトは、「敵に見つからないように進む」、とのことですね<ref>吉冨賢介『ゲームプランナー入門』、P108</ref>。 イラストや音楽の発注は、一般的には企画が決まった後でしょう。 そもそもイラストレーションや音楽を対価を払って提供してもらったとして、それを実作品に使用しないのは、作者にとっては不本意なことだと思います。 アニメーターの故大塚康生氏は、アニメーション演出家が安易にアニメーターに大量の絵を描かせ、そこからいいもの、利用できるものだけ取捨選択する方法を批判していましたし、一般的に手仕事には作者の思い入れがありますから、安易な大量生産品と同じ取り扱いはできないと思います。 もっとも一方で、あるアメリカの日本人アニメーターが、同僚の日本人アニメーターが、自分の描いたものを日本の家族や友人たちが見ることができないことを不満に思っていた、という事を批判的に語っていたのを、現編集者は聞いたことがあります。 しかしゲームの場合、例外的にイラストや音楽が先行する場合はありますね。 RPG『クロノトリガー』は、企画の当初からイラストレーターをつとめた漫画家・鳥山明のイラストがあって、それをもとに作品を作ったと、鳥山のマンガの編集者であった元・少年ジャンプ編集の鳥嶋和彦は述べています。<ref name="tskdq">[https://news.denfaminicogamer.jp/projectbook/torishima/2]</ref>決めシーンなどのキービジュアルを先に決め、それに合うように設定を練りこんでいくという方式で、クロノは作られたようです。 企画書の制作ツールとしては、清書としては、オフィスソフトの「PowerPoint」と、アドビの「Illustrator」、または、アドビのソフトウェアは高価なので代わりにフリーソフトの「Inkscape」および「GIMP」がよく使われます<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日第1版第1刷、P.281</ref>。なお、Illustrator および Inkscape は、ベクトル画像を描画するソフトウェアです。 ただし、下書きなどでは、タッチペンと何らかの画像ソフト、またはタッチペン用メモソフトで下書きすることもあります。 業界で、ゲームプランナーと呼ばれる職種は、仕様書作成や進捗管理、テスト&デバッグ、スタッフとのコミュニケーション、などが仕事ですね<ref name="gpd9">『ゲームプランとデザインの教科書』、P.9</ref>。 また、ゲーム制作に関して、だれもが様々なアイディアを持っていると思いますが、メモを取って、もし忘れてもメモで思い出せるようにするといいですね<ref>『ゲームプランとデザインの教科書』、P.20</ref>。 アマチュアの企画なら、実際にプロトタイプ（プレイできる試作品のこと）を作って実作品で企画、仕様を説明してしまったほうが早いかもしれません。 参考文献『ゲームプランとデザインの教科書』でも、（試作品を）「ゲームプランナーを志す中で企画書や仕様書を書きながら、ぜひ自分でも作ってみましょう。プログラムや3Dモデルを簡単なものでいいので作ってゲームに仕上げてみましょう。」と述べています<ref>『ゲームプランとデザインの教科書』、P.3</ref>。 上記の本の図表によると、企画書では、「競合情報」、「世界観」、「ストーリー」なども記述して欲しいようです<ref>『ゲームプランとデザインの教科書』、P.43 </ref>。世界観とストーリーが分けられているのです。 物語とその舞台ですね。我々自身もこの世界で自分という役を演じている役者ですよね^^ {{コラム|ゲームの企画書とアニメーションの企画書| 商業アニメーションの世界では、企画の段階でストーリーの概要が決まっているようです。ただこれは、アニメーション作品の企画として、当然に必要とされる要素であるから記述されているわけで、実制作の過程で、実際のスタッフの意向により大幅に変更されることもあります。また、これらの企画では、キャラクター設定やキャラクターイラストのデザインも当然必要であり、かなり明確な形で提出されています。 たとえば、アニメ業界の企画書ですが、1990年代のアニメ『新世紀エヴァンゲリオン』の企画書の掲載されている『新世紀エヴァンゲリオン (ニュータイプ100%コレクション) 』（1997年2月28日初版発行、85～88ページ）を読むと、『企書画』の段階でもう、キャラクターイラストが主役だけでなくその友人や周囲の大人なども含めて、ほとんどのキャラクターでイラスト紹介されており、さらに全部の話数ぶんの粗筋と見せ場・意図を2～3行ていどで説明しています（ただし第1話と最終3話（24～26話）のみ説明が5行以上くらいと長い）。 因みに現編集者は実際にアニメーション業界で企画書を書いたことがありますが、その時に上司、制作会社の重役に指摘されたのは、1クール（3か月）か2クール分の実際のストーリーの具体内容を書いてほしい、との事でした。 一方ゲーム業界では、そういうキャラクター設定やストーリーは、企画段階では決まっていなくて、もし書かれていても邪魔だと感じられるようです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、149ページ</ref>。 業界の企画書で、強調してほしい内容とは、ゲームシステムと、そうシステムを設計した根拠のようです。なぜなら、ゲームの企画書でいう「コンセプトが重要」、と言う際の「コンセプト」の意味とは、ゲームシステムやゲームルールを設計した根拠のことだからです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、108ページあたり</ref>。 とはいえ、ゲーム業界の企画書でも、ゲームの世界観が「中世西洋ファンタジー風」なのか、「現代日本」か、「近未来SF風」なのか、などの設定はある様です。ネット上で公開されている商業ゲ－ム企画書からその様子が分かりますが、しかし、最初の企画書の段階で決まってる世界観はその程度まで、です。 背景としては、ビジネスモデルが根本的にアニメーション業界とゲーム業界とでは違う、という事情があるのでしょう。 }} {{コラム|キャラクター重視の物語論| アニメ―ション業界のビジネスモデルは、キャラクタービジネスだと言われています。1990年代の徳間書店のアニメーションに関する書籍（アニメージュ10周年記念）で、徳間の編集者が1980年代のアニメ業界を振り返ると、これはキャラクタービジネスだろうと、たとえば銀河鉄道999のアニメ―ションの人気も、メーテルなどのキャラクターの人気なのだという分析があり、アニメージュ創刊当時の『銀河鉄道999』特集では、ストーリー解説ではなく、キャラクターに焦点を当てた記事を組んだと、述懐（じゅっかい）しています。 また、漫画産業もキャラクター重視のようです。主人公に共感させるための様々な演出が凝らされている。そして主人公が身近に感じられることが重要だと指摘されています<ref name="tskdq" />。 これは日本人が物語軽視というよりは、海外でも同様であり、むしろ物語とはキャラクターを描くという要素が非常に大きいという事でしょう。多くのミステリの中でも「シャーロック・ホームズ」や「007」の人気が非常に高いのも、キャラクター性と結びついた作品だからでしょうね<ref name="tskdq" />。 1982年頃『鳥山明のヘタッピマンガ研究所』では、おおむね「マンガとは人間を描くことだ」という主張がなされています。 現編集者の記憶では、漫画がキャラクターだという主張を強くしたのは、漫画原作者であり、劇画村塾の開設者である、故[[w:小池一夫|小池一夫]]氏でしょう。上述の書籍の共著者、さくまあきら氏も、劇画村塾出身ですから、さもありなんということですね。 アニメ評論家の岡田斗司夫氏は、対談集『マジメな話』で、「古代ギリシア人や古代ローマ人はとても論理的で学問も発達していたが、一方でギリシア神話やギリシア悲劇が普及していた、人間には物語が必要なのだろう、自分達の社会の仕組みを、物語になぞらえて理解する、物語が学問や科学に匹敵する」といったことを述べていました。 ギリシア神話では実に人間的な神々の物語が語られていきます。 また、政治学者小室直樹氏は、別の書籍、おそらく、『日本人のための宗教原論』あたりで、「幼少期の子供にとっての、父親の力強さと畏怖のイメージ」こそが神のイメージだろうと述べています。ギリシア神話の最高神ゼウスは、明らかに父性を示していますよね。 これはユダヤ教やキリスト教の神のイメージだと考えてもいいと思います。この辺[[w:父なる神]]あたりに面白い記述がありますし、一方でイスラム教は神に父性を見出さない、などの興味深い分析も書かれています。 また、RPGゲーム『真・女神転生』では、裏設定ですが、作中の「悪魔」とは、力の象徴であり、それは父親を暗喩しているというコンセプトがあります（たしか公式ファンブック『CLUB邪教の館』あたりに記載がある）。だからこのゲームの主人公は、父親がいない母子家庭の子供だという事になっています。 }} {{コラム|ゲームにおけるキャラクター| ゲームの世界は、ソーシャルゲームや美少女ゲーム等はありますが、一般的にはキャラクター重視のメディアではないようです。シューティングゲーム『ゼビウス』のキャラクター性とか、『平安京エイリアン』のキャラクター性など、想像力を最大限に駆使すれば見出せないことはないですが、常識的にはキャラクターの魅力は提供されてはいないでしょう。 ゲーム学という概念を推進している人達は、ナラティブ（「叙述」という意味）といって、スーパーマリオなどのように作中にストーリー説明文が無いゲームのことを説明しているようです。 今現在では、可愛いキャラクターや恰好いいキャラクターを作品に取り込めるのなら、それを除外する必要はないでしょう。しかし現実の人気ゲームでは、キャラクター性があいまい、あるいはほとんど見出せないゲームも多いですよね。 ゲームのキャラクターは、開発途上で変更される可能性もある。海外展開しているゲームは、相手国の風習、社会状況に合わせて、キャラクター設定を変える場合もある。 今現在は、ソーシャルゲームでもキャラクターゲームは人気ですが、昔はそうではありませんでした。1990年代は、多くのゲームファンの間では、「キャラクターゲームはつまらない」と言われていました。 2002年にシリーズ発売開始されたRPG『ドットハック』シリーズの企画コンセプトは、面白いキャラクターゲームを実現することであり、2003年当時の社長（松山洋）がラジオ番組『ドットハックレイディオ』に出演した時に、「キャラクターゲームがつまらない」という一般的に言われている常識を打破したい、それがコンセプトだ、と述べていました。 しかし実際には1990年時点で魅力的なキャラクターゲームもありましたし、大ヒットすることは無くても、一部の大きな人気は得られていたようです。 }} {{コラム|企画が実制作に移ること| 1990年代後半に書籍を出し始めた、元ゲーム業界人・阿部広樹氏は、ゲーム会社から請け負って、そこで頓挫した、或いは難航した企画を練り直しする仕事をしていたようです。彼の著作ではその経験、経緯が語られています。 扱った一つの企画が、ガンダム風の巨大ロボット操作ゲームで、企画として完成度の高いものでした。 主要機体の巨大ロボットのグラフィック設定画は線画が完成していて、機体パイロットである主人公の顔グラフィック線画もある、ロボットの設定サイズ（「全長○○メートル」、「主要武器：○○」など）なども含む、仕様書がすでに用意されていました。 機体の名前には「メタトロン」や（たしか）「サンダルフォン」と、ネットの普及していなかった当時では調べるのにも手間のかかるユダヤ教の大天使の名前がつけられていました。 阿部氏も、このゲームは実現するだろうと、期待を込めて企画を進めていたようです。 しかし現実にはこのロボットゲーム企画は対象のゲーム会社では採用されず、実際に制作されることはありませんでした。このようにゲームの企画は、企画だけで終了してしまうものが沢山あります。 一般的に商業ゲームの製作は、本当にペイするかどうか、経営者や出資者の審査、判断の上、実制作に取り掛かるでしょう。 企画を作る方も仕事として取り組んでいるのですから、「没になるかもしれない」といって手抜きするはずもなく、内容的にも、前設定の完成度としても、どれも相当の力と手間暇をかけて企画を練りこんでゆくでしょう。 しかし結果は結果としてありますよね。採用される保証はないしされないほうが実際多い。その判断が正しかったかどうかはまた別の話ですがね。 }} {{コラム|他業種、一般的な意味での『企画書』| 企画書にもいろいろな段階があります。 #本当に企画の初期段階の、内部関係者しか見ない、思いつきを書きなぐったような企画提案の書類（厚さはせいぜい2～3ページくらいまで？） #企画が熟成してスポンサーや外部に見せられるようになった段階、もしくはその直前くらいの企画書（10ページを超える程度） #パワーポイントなどを使ってプロジェクタ－で見せるプレゼン資料の「企画書」 多くの業界の企画書で学生や外部の人間が見るのは 2.か 3.でしょう。 1990年代後半のゲーム評論家の阿部広樹の他者との共著による書籍によると、彼はゲーム業界で企画に関するトラブルを解決する仕事をしていたようですが、ある案件で、「当時の人気アニメ声優を起用！」など書かれた企画書をトラブル解決のために扱いましたが、彼らが調査した時には相手先のアニメ声優および声優事務所には全く話が行っておらず、対応にも難航したようです。ただ、本Wikiの別の場所でも指摘しましたが、企画時点では、その手の手続きを踏む必要はないでしょう。企画は企画にすぎませんし、実現の見通しが大きくはないその時点で話を持ってこられても、声優も事務所も、対応しようがないと思う。ただ、前編集者の記述では、許可をとれそうな見込みもないと書いてあるから、よほどのビッグネーム声優、要するにその声優の知名度だけをあてにしている企画ですから、悪い企画の例として非難されても仕方ないのかもしれません。しかし現編集者がさらに邪推、想像するに、彼らに企画トラブルの解決を依頼したゲーム会社は、自分たちは零細で知名度もパワーもないので、とてもその有名声優にはアクセスできない、ですからトラブル解決を稼業にしている業者なら、上手にその声優にアクセスしてくれるのでは？という期待があったのではないでしょうか？だとしたら、この事案に対する阿部氏らの態度、そして後になってわざわざ自らの著書でその出来事、関係者を愚弄して、それで自分たちが正しいかのように言うこの人物の姿勢は、職業人、仕事人として問題があるのではないでしょうか？ さて、ある程度企画が本格化してくると、スポンサーに提示するプレゼン用の資料とは別に、詳細な設定や企画意図を説明する、「詳述企画書（ここでの仮の名称）」も作られていきます。この書類は今後の作業のためのひな型の意味もあり、具体的にどんなキャラクターが出てくるか、イラストなども描かれます。 因みに、「ゲーム　企画書」でグーグル検索してみると、企画書としては 1.~3. そして今書いた「詳述企画書」が混然と表示され、書類として種類や趣旨は明確化されていないようです。企業が求職者を採用するために、企画書を求める場合は、プレゼン資料が最適のようですね。採用担当者にとって一番読みやすい資料だからでしょう。 企画書として、説得力のある内容なら、採用され実制作に移る可能性も高くなるのでしょうね。そのために指摘される事として、冒頭部分で、この企画と既存の作品の違い、今までの状況からの改善点、そして実際の改良の実現の見通しと方針を示すといい様です。これは「企画意図」や「コンセプト」と呼ばれますね。 「改善点→（競合他社の）現状説明→改善案の詳細」を、詳細企画書で段階的に説明するといいですね。新聞記事の書き方で、起承転結ならぬ「結・起・承」（けつきしょう）というのがあるので、それを参考にするのもいいでしょう。 また、売り込み先の消費者として想定しているターゲット層の指定も必要です。年齢はいくつくらいなのか、性別は男性か女性か、などですね。 企画の詳細を作りこんである場合や、すでにゲームソフトを実装してある場合のシステムの説明では、単にフローチャートを図示するだけでなく、そのシステムでプレイヤーは何ができるのか、簡単な遊び方の概要説明、等を加えるといいですね。 }} {{コラム|日産自動車の社内講習でのアニメーション業界人の講演| どこの企業でも社員向けの講習会はそれなりにあるでしょうが、日産自動車では過去、アニメーション制作会社の幹部を招いて、営業マンや企画職の社員のために講演してもらったことがあるようです。 テレビアニメーション『輪廻のラグランジェ』が2012年に放映されていた前後、日産が取材協力として制作に参加していたので、CG雑誌で、日産の講演会の様子が紹介されていました。 アニメーション業界では、実在しない物体や機械のイメージを、メカニック設定などで詳細にイメージを作り、絵コンテマンや、原画・動画のスタッフ間でその具体設計を共有するので、自動車製造業界でも参考になる要素があると考えられたようです。 日産の担当者は、制作会社の幹部の講演会に手ごたえを感じたので、もっと話を聞かせてほしいと要望すると、『輪廻のラグランジェ』の製作会社を紹介してくれたので、その会社にも講演をお願いし、さらに制作会社側の取材協力にも積極的に応じて、異業種同士のコラボレーションが形成されていったようです。 }} さて、ゲームの『仕様書』はそのゲームの設計図なので、起こりうる全てのパターンを網羅して設計を指定する必要があります…と言いたいところですが、そもそも本当にすべての操作に対する反応をもれなく記述できるのか? しかしできる出来ないにかかわらず、創作物が世に出れば、それはコンピューターアプリケーションとして、ユーザーに自由に操作される。その時仕様と創作物が、合理的に網羅的に作られていれば、プレーヤーはストレスなく、ゲームを楽しむ事が出来るでしょう。 ;検品、検収 さて、一般に技術系の業界では、図面などの設計図は、検品のさいのチェックリストを兼ねています。（ただし、ゲーム業界での「仕様書」が検品チェックリストを兼ねているかどうかは、2022/01時点、著者側の調査不足で不明。） しかし検品自体はゲーム業界でも行っている。協力会社から納品されたプログラムも、仕様を満たしているかチェックするだろう。 そしてチェックを通ったら、合格した製品として正式に受け取る。 納品物を合格として認めて受け取ることを「検収」（けんしゅう）という。（ゲーム業界でも）<ref name="creator_work:77">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、77ページ</ref>。ゲームの仕様書は、この検収を考慮に入れて書くのがいいだろう。 つまり逆に納品物が合格していないと判断されると、受け入れない、検収しない、納品者に作り直しを要求することになるだろう<ref>蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、76ページ</ref>。 商業ゲーム界では、営業マンが見積もりをするときの根拠は、仕様書、という事になる<ref name="creator_work:77" />。 外注テストに関しては、仕様書では不十分で、テスト用の別資料を用意する<ref name="gpd9" />。 バグチェックを外注しない場合は、「仕様書」を根拠にする場合が多いという<ref>吉冨賢介『ゲームプランナー入門』、P20およびP199</ref>。 つまりやはり、製品の仕様の基盤は仕様書、正しい仕様は、仕様書に書かれている事だという事になる。 開発後半のデバッグ段階などのバグチェックの段階に入る前に、仕様書を最新のゲームの状態とそろえる<ref>吉冨賢介『ゲームプランナー入門』、P238</ref>。つまりこれは、ゲームの仕様が制作過程で変わっていったら、逆に仕様書を書き換えて、実際の仕様に合わせるという事だ。 ==作成工程== ===完成予想図=== 仕様書はゲームの設計図。この書類を基盤にプログラマー、グラフィッカー、製作スタッフたちは作業を進める。しかし、ゲームの場合は、いきなり完成図を明確に決定するのは困難な場合が多い。そうなると方便的に大まかな設計、決定を作っていくという事になるだろう。事実、現実の業界では、大まかな「企画概要書」から詳細な「仕様書」へと、段階的に仕様が決まっていく<ref>『ゲームデザイン プロフェッショナル』、P.141</ref>。 一般的な製造業でもゲーム業界でも、あいまいな指定は事故のもとだと考えている。「とにかく、かっこいい感じでお願いします」なんて言いたくなることもあるけど、危険らしい<ref>『ゲームデザイン プロフェッショナル』、P.60</ref>。相手の「かっこいい」のイメージが、有り得ないものだったりする場合、あるよね^^;;;。 しかし場合によっては例外もあるようだ。裁量とか、阿吽の呼吸といったものも、人間関係ではある。しかし技術を語る場合、設計とは極力あいまいさは排除するものだろう。 ゲームでは、他者に発注するときは、ある程度相手の裁量にゆだねた方が良い場合もある<ref>『ゲームデザイン プロフェッショナル』、P.134</ref>。しかしその場合も、具体的にどういう実装予定のもので、どこに裁量を与えるのか明確にする必要があるという。裁量の発注については、『ゲームデザイン プロフェッショナル』本書を読めと、前編集者は書く。 とにかくこの編集者によると、Wikibooks をはじめ、Web上のWiki には何の価値もないと言う。世の中唯一価値のある文献は市販されている書籍で、Wikiの利用意味はその価値のある素晴らしい書籍を、出典としての記述を参考に、知ることだと言う。 それなら、Wiki書くのなんて辞めて、本屋でも始めたら? ===各機能の予想図の決定=== ソフトウェアの完成予想図は、画面を基準にすると伝わりやすい。 結局パソコン、情報機器を使っている時は画面を見ますからね。 <pre> △△モードの××画面 Aボタン: ダッシュ（走る）。押すとキャラが十字キーの選択方向にダッシュするようにプログラムする Bボタン: ジャンプ。押すとキャラが上方向にジャンプするようにプログラムする </pre> とか、こんな風に書くといいのではないでしょうか。それぞれのモード、画面での機能の満たすべき情報の一覧、を伝えておきたいですね。 ユーザ視点での仕様の事は、「外部仕様」、というようです。 ですからソフトウェア設計者は、各モードについて、画面表示、操作などの外部仕様の一覧を用意したいですね。 これは完成予想図でもある。 一方ソースコードの詳細は、内部仕様ですね。 商業ゲーム界では、原則的に内部仕様に関する書類は、あまり書かないようです。とはいえ設計項目の、ファイルや変数の具体的な記述は、ある程度は仕様書に書かれる。 そして外部仕様は「画面仕様」だけではない。例えばアクションゲームのモンスターの動き方のパターン、RPGのダメージ計算式、プレイヤーが具体的に実感できる仕様は、仕様書において指摘しておきたい。 ゲーム完成予想図とは、各種外部仕様を具体的にわかりやすく記述することになるだろう。 ==※例== 一冊の完成予想図の中で、説明が重複し、同じ記述が複数あるのは好ましくない。 ある記述内容が変更になる時、重複した先も変更しなければいけなくなる<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。 一般的製造業の製図でもこのルールは守られている。一つの末端部分の図面はそれだけで完結し、他の部分を参照しないようにしている。 ではここからは、ウディタのサンプルゲームを具体例に説明しよう。 本来サンプルがあれば仕様書は不要という事になるが、今回は説明用として、サンプルから仕様書を書き起こす。 まずサンプルゲームのメニュー画面、 :相談 :アイテム :特殊技能 :装備 :システム :セーブ と、６つのコマンドがある。 上から4つめの「装備」にカーソルを合わせた状態で決定ボタンを押すとキャラクター選択に移り、十字キーで目的のキャラクターを選択して決定ボタンを押すと、装備画面に移る。 さて、これを仕様書に書くと… 【'''装備キャラクター選択画面'''】 '''遷移直後の変化''' メニュー欄に「装備」コマンド位置に決定後カーソル画像「○○○.bmp」を表示。 キャラクター選択欄のカーソルの点滅が開始。キャラクター選択用の点滅用カーソルの画像は「△△△.bmp」。 '''ボタン押の反応''' キャラ選択欄で十字キーの方向にいる隣または次のキャラクターを選択でき、そのキャラの選択欄にて点滅カーソルが点滅表示される。 決定キーを押すと、選択中キャラクターの『装備部位の選択画面』に移る。 キャンセルキーを押すと『メニュー画面』に移る。 '''画像リソース''' ○○○.bmp :メニュー欄用の決定中カーソル画像 △△△.bmp :キャラクター選択欄用の点滅用カーソル画像 という感じ? その画面とやりとりする相手先の画面の名前と、あとはその画面の読み込むファイル、無駄なことは書かない、他の画面や他ファイルについては書かないほうが良い。 上述の仕様書の書式の参考は、吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、221ページ、の例『各画面の仕様書の例』の書式。 『装備部位の選択画面』に移ったあとの説明は続けて書かず、別途、たとえば『装備フロー仕様書』のような仕様書を作成せよ。 仕様変更で、『装備』コマンドの位置が（サンプルゲームでは上から4番目だが）上から6個目に変わったら、「メニューの装備コマンドは上から4番目にある」と書いた書類は全部作り直しになってしまう、そういう事態を避けたい。 そのため、あえて書類をモジュール化する。全体像は把握しづらくなるが、しかし全体像の把握については、そのための専用フローチャートを書類に設け、修正の手間が波及しないようにする。 例えば… '''装備フロー仕様''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 とかね。 フローチャートの作図をしたい場合は、オフィスソフトのパワーポイントの図形描画の機能で作図が可能。フローチャートの描き方はJISで決まっているので、それを参考に。中学校の技術家庭科でも習うのでその教科書を引っ張り出してきても良い。 例えば装備部分の選択画面は、 :右手 :左手 :身体 :装飾1 :装飾2 これがこう変更されると… :武器 :盾 :頭 :身体 :腕 :装飾 書類上の「装備部位の選択画面の「右手」選択にカーソルの合わさった状態で移る」というような記述はすべて書き直さざるを得ない。 そこでまず、『メニュー画面』や『キャラクター選択画面』では、他画面、例えば『装備部位選択画面』の具体的項目名称とその遷移法は書かないようにする。 『キャラクター選択画面』の仕様は、例えば、「選択キャラクターの『装備部位選択画面』に移る。」と書く。 「画面の変更時は原則、その画面のいちばん上のメニュー項目にカーソルの合わさった状態で画面が移る」と書く。 例えば装備関係のフローを描くときは、 :マップ画面 → 決定ボタン → メニュー画面 → 「装備」を選択で決定ボタン → キャラクター選択 → 決定ボタン → 装備品選択画面 と、続けて書くのはよくない。フローを分解する。 '''メニュー選択フロー''' 【 マップ画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 メニュー画面 】 '''装備関係フロー''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 こういう２分割でしょうか。 意味的にまとまりのある単位ごとに階層をフロー分割したい。 かといって、5分割や10分割と、階層が大きくなりすぎるのは、多重下請けのいんちき業界みたいなので、多くてもせいぜい３分割でしょうね。 そしてフロー同士を結ぶ記述が必要。 【メニュー画面仕様】 '''表示項目リスト''' 決定ボタンで下記の項目を選択できる。 ・相談　　　　　　:決定すればメニュー相談フローに移行 ・アイテム　　　　:決定すればメニューアイテムフローに移行 ・特殊技能　　　　:決定すればメニュー特殊技能フローに移行 ・装備　　　 　:決定すればメニュー装備フローに移行 ・システム　　　　:決定すればメニューシステムフローに移行 ・セーブ　　　 　:決定すればメニューセーブフローに移行 '''非表示項目''' ・キャンセルボタンでマップ画面に戻る とか? なお、各画面での遷移先の画面の説明と、フロー図での遷移先の画面との説明が重複しているけど、まあ気にしない、気にしない^^;;;。 参考文献の『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』の209ページ「状態遷移フローの例」と211ページ「各画面の仕様書の例」とでも、遷移先の画面の説明はそれぞれ重複しています。まあ場合によってはいつものようにこの後の記述でそこそこ言い訳するかもしれないけど…^^;;; ;一枚の図面の中での重複は、すじ肉大先生が許してくださる^^ というのは、例えば機能の似たものを二つ作る時、2個目の説明では、「○○については△△と同じ」と、書けるからね<ref name="aps229">吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ</ref>。 同じ一枚の図面なら、これで良い。 「○○については△△と同じ」「～～～と同じ」のように書いて具体的には書かない。<ref name="aps229" />。 ;その他 画面名やファイル名の名前は、具体的にしたい<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。 たとえば、上述のウディタのサンプルゲームの画面は :「マップ画面」、「メニュー画面」、「装備キャラクター選択画面」、「装備部位選択画面」と、したいね。 例えば 「画面1」、「画面2」、「画面3」、… とか、 「メイン画面」、「メニュー画面」、「サブメニュー画面1」、「サブメニュー画面2」、… にしたいときはあるし、事実上これは、命名の手間は省けるんだけど、他人に伝わりにくいので、ここは少し手間をかけて、具体的に内容ある命名にしたい。 {{コラム|| 法律の設計でも、相互参照が増えると、その法律の構造自体の複雑さが増加する現象が知られています。近年、世界各国でIT的な考え方を使って法律の設計論を研究しようという学問分野があり、その学問でそう指摘されています[https://www.nature.com/articles/s41598-020-73623-x Daniel Martin Katz, Corinna Coupette, Janis Beckedorf & Dirk Hartung "Complex societies and the growth of the law" , nature.com, Published: 30 October 2020 ]。これらのIT的な法学では、法律中の単語数、階層数、法律間の相互引用数が多ければ多いほど、その法律の構造は複雑になると考えられています。ご参考に。 }} ==== 要求事項 ==== IT界の一般的な慣習として、「要求事項」とは、完成品の満たすべき要件を示しています。しかしゲーム業界では通例は、そのような追加の書類は作られないと考えられます。ゲーム設計論の専門書を読んでも「要求事項書」などというものは紹介されていません。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ゲームデザイナーからの要求については「仕様書」または発注書などの手続きの際に、相手方に要求を伝えてしまうのでしょう。 E.Suj.の調査では、商業ゲーム界で『要求事項書」が作られている証拠は見つけられなかったようです。 なお、基本的に「要求事項書」とは、発注者と受注者の両方の打ち合わせによって作られていきます。 ただゲーム界では、発注書で、成果物が作中でどういう目的で使われるのか、意図・用途を伝えるのがいいようです<ref name="gp296" />。 ==== データ暫定値 ==== ゲーム中のデータの数値、例えばRPG武器の攻撃力、等、はすべての項目の想定値を設計図に記述します<ref>https://www.youtube.com/watch?v=KVdtNiB_lIQ 2020年3月14日に閲覧</ref>。 CSVファイルを作りましょうか、ソフトはエクセル? 【剣データ暫定値】 銅の剣: 攻撃力 7 鉄の剣: 攻撃力 18 ハガネの剣: 攻撃力 37 ミスリルの剣: 攻撃力 70 ほのおの剣: 攻撃力 57 （※ 剣ではランク5は欠番とする） デスブリンガー: 攻撃力 150 備前長船: 攻撃力 250 聖剣エクスカリバー: 攻撃力 450 魔剣レーヴァテイン: 攻撃力 450 具体的な指定も一緒に書いて、もちろん今後の調整で変更する可能性はあります。 ====データ仕様書==== データ仕様書とは、たとえばRPGなら :攻撃力: 敵の守備力との計算によってダメージを算出する のようなパラメータ計算式の定義を行った仕様書のことです<ref name="gpnt92">STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日初版第2刷発行、92ページ</ref>。 そして、この「データ仕様書」は、デバッグのための資料になります。デバッガーが、この資料と実際の動作を照合することで、仕様どおりにプログラムが動いているかを確認します<ref name="gpnt92" />。 書籍『ゲームプランナーの新しい教科書』では、アイテム（「やくそう」や「毒消し」などの）価格の「100」（100ゴールド）や「200」（200ゴールド）の具体値のあるデータ表のことを「仕様書」と言っている。この本では、本当は「100」になるべき数値が「200」になっている場合 「仕様書」で簡単に確認できる、記述されている。 一般にRPGの仕様書は非常に厚く、大冊になるという。オタキング岡田斗司夫氏が聞いたところによると、（出典は『オタク学講座』など）、ある有名RPGの仕様書は、書類の量をページ数ではなくKg で数えていたという。（しかし、1kg=何枚かな?^^）。有名作の仕様書は、分厚い電話帳のようなものが何冊もあるらしいです。データ台帳、 各種パラメータ、設計の背景の要求事項、まあいろいろ書かれているのでしょうね。 ;攻略本と仕様書 ゲーム攻略本にある、アイテムの効果値や、敵の能力値といった数値の一覧は、おそらくそのゲームのデータ台帳から転記されているのでしょう。 プログラム部分の設計図である仕様書も参考になるでしょうが、データ台帳には、直接的な数値が書かれています。 しかし実際の市販の攻略本には正しくない記述もある。制作側から正しいデータ、情報を手に入れられなかった場合もあるでしょう。 ==プランナーが事務方の現場で動いているスタッフとみて良いでしょう== ゲーム業界では、プランナーと言われる人が、連絡網の中心になって、いろいろな部署のあいだの情報伝達をします。 <div style="font-size:120%;"> <pre> ディレクター　━━━　プランナー　━━━━┳━　プログラマ 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　グラフィッカー 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　デバッガー </pre> </div> ディレクターが現実の制作のトップ、そしてその後ろにプロデューサー、管理職など、商業コンテンツとしての責任者がいることになりますね。 このプランナーは、ゲーム業界の場合、中間管理職? のような権限があり、各部署（プログラマ部署やグラフィッカー部署など）やディレクター（監督）の間で、様々な調整や連絡をしていきます。 アニメーション業界で言えば、制作進行とか、制作デスク、のような立場でしょうか。 「プランナー」というと、プラン「計画」を練るという意味になりますが、テレビ業界でいう「AD」アシスタントディレクターのようなイメージのほうが近いかもしれません<ref>吉冨賢介『ゲームプランナー入門』、P236</ref>。勿論現場を現実に回すための様々なプランは必要ですね。 ==ゲームに取り込むイラスト、音楽== 商業ゲームで、イラストや音楽、そしてそれ以外でも、他者に何らかの作業を発注する場合、特に常識的、慣習的な発注フォーマットというのは無いようです。割と場当たり的に、作品、状況にあった発注形態がとられているのでしょう<ref>『ゲームデザイン プロフェッショナル』、P.146</ref>。 音楽やイラストの提供を他者に求める場合は、もちろんその作品に関するその絵描きや音楽家の関わり方にもよりますが、そのゲーム内でどのように絵や音楽を使うか、明確に説明できることが望ましいですね。 様々な事象項目チェックリストも用意したい<ref>『ゲームデザイン プロフェッショナル』、P.159</ref>。 ===他者に委ねる場合=== 商業としても、あるいは同人としても、割と外部の他者に描いてもらったイラストや音楽をゲームに取り込むことは多いでしょう。商業ならそれこそ、対価を明示したうえで外注、ということになる。 例えば他者にイラストをお願いするときは… :構図、 :希望のポーズ、 :塗り方、 :テイスト、 この辺を相手に伝えておきたいですね<ref name="gpd128">『ゲームプランとデザインの教科書』、P.128</ref>。 さて、ゲームには美術的な素材として、イラストレーション、アニメーション、コミック（漫画）などがありますが、これらはもちろん絵画としての共通点はありますが、一般的にはそれぞれ別分野と見なした方がいいようです<ref name="gpd128" />。 特に商業の世界では、美術作品という共通点はあっても、他分野の創作は手間や方法論の整備や熟練などの問題で、それぞれの専門家に依頼するのが妥当でしょう<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P168</ref>。 そして、商業ゲーム界では、あるいはそれ以外でもあるかもしれませんが、キャラクターイラストを描いてもらうときは、実在のアイドルやモデルの名前をイメージとして、提示する場合もある<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 あるいは仮に自分は絵が上手に描けなかったとしても、ラフな簡単な絵をかいて、どんなキャラクターのどんな構図を描いてほしいか、大体の要望を伝える、ということもありますし、また、その構図が作中でどういう目的で使われるか、意図用途を伝える<ref name="gp296" />、というのも意義がありますね。 ただ他人に何かを伝えるということは、一般的な意味でも難しいことですよね。ここでイラスト描きに希望を伝えるにしても、長文の書類だと読んでもらえないこともあるし、口頭でもその相手にとって分かりにくい説明というのがある。 ですから、出来るだけ、ですね、わかり易く受け入れやすい言及が必要です<ref>『ゲームデザイン プロフェッショナル』、P295</ref>。 ;アダルトゲーム アダルトゲームでは、シナリオも外注の場合があるらしい<ref>畑大典著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P129</ref>。しかしむしろこれは企画販売の会社と、制作主体が別だという話ではないだろうか？ ところで皆さんは、アダルトゲームって、プレイします?^^;;; ;そもそもイラストの発注者は、絵描きの頬を札びらで叩いて描かせているわけ? 基本的には有償のイラストの場合は、発注者の指定にイラストレーターは従うでしょう。それでも媒体にもよりますけどね。ゲームの場合は、発注者の指定に従う縛りは大きいと見ていいですね。 そもそも要求事項がどうのとか、書類に関する理屈をグダグダ述べれば、さらにこの縛りは強くなりますね。事実上はその辺の判断はあいまいなのですが、発注者は一般的にリテイク（書き直し）を出す権利があるとみて良い。 例えばイラストの仕事を有償で得たとして、実際にはそのイラストの使われ方も問題になりますが、「セーラー服の少女を描いてください」と頼まれてそのイラストを引き受けたら、ブレザー服の少女を描いて提出するのは不適切でしょう。リテイクを出される<ref>『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.208</ref>。それどころか、仮にセーラー服の少女を描いたとしても、発注元がそのイラストの質が良くないと判断したら、一般的にはリテイクを出してよいと見られています。しかしもう一つ問題があって、そのイラストレーターはそもそもなぜブレザー少女を描いたのか？そしてもう一つ、現編集者の推奨としては、イラストレーターはリテイクの扱いについて、具体的にどう扱うか、発注者とよく話し合ってある程度ルールを明確にしておいた方が良いと思います。 前編集者はこの問題について、社会のルールがどうのとか、自称イラストレーターがどうのとか、教育がどうのとか、2005以前がどうのとか、いつものように狂った理屈を長々書いていますが、全て愚か者の自己本位なたわごとでしょう。 {{コラム|絵の仕事とはどんな仕事?| さて、前編集者 Suj. は、このコラムで、2005~2008 にかけて、絵の仕事を、「自由に絵が描ける」「漫画や絵の仕事は、競争を気にしなくていい」と、思い込んでいる人がいたと書いているけど、これ本当の事かね? どうせいつもの[[w:かかし論法]]じゃあないの? そもそもなんでこの話では、大好きな出典出さないわけ? しかもこの人物は、教育に携わる資格なんてまるでない性格異常者なのに、なぜか偉そうに大上段に教育論を語りたがる。 そもそもそんな人がいるかどうかも怪しいが、それは小中高の美術教育、自由に絵を描かせる授業方針のせいなんだって。 この人物の妄想世界では、「小学校の図工のような自由な仕事 <nowiki>=</nowiki> プロ絵描き」と思い込んでいる人がいるんだって。ほんとかね? 何かこの人物が大好きな江川達也もそんなこと書いていたようだよ。 2001~2005の雑誌コラム、スパ? 漫画業界について「漫画家は、競争が無くて自由に漫画を描ける仕事」、という言説に怒っているんだって。しかしほんとにそんな主張があったの？江川もストローマン叩いてるだけじゃあない？そしてわざわざゆとり教育に言及? インチキ臭いね。 しかも江川が書くには、「漫画家はとても競争の厳しい世界だ。」ってことだけど、まあそんな部分はあるけど、結局はそこで生き残って飯食ってる俺は偉いって話でしょ? 江川ってほんとにいい漫画描いてる? 単にインチキな業界人に気に入られているだけでしょ? あと小林よしのりは、ゴーマニズム（そろそろマジメニズムになったら?）宣言で、プロデビュー前、「マンガ出版社は、漫画家が死ぬまで面倒を見てくれる、まるで公務員のような終身雇用の業界が漫画業界」と思い込んでいた、と、描いていたって言うけど、そうね、私もこんな記述昔読んだような気はするけど… しかし、E.Suj.はこの小林の当時の考えはよくて、今同じ様な考えを持つと阿保馬鹿書くわけ? しかもほんとにこんな考えの人が今いるのかね? 出典くれない? まあ確かに実際に今現在、そんな考えの人はひょっとしたらいるかもしれないけど…。しかしここでわざわざその話題をコラムとやらにして、彼らを愚弄する意味なんてある? }} ===特定の絵に関して、誰でも質やクオリテイを語ることはできる。しかしそれは主観的な判断に過ぎない上、自分自身が神のように凄い絵を描けるわけではない。だからあまり威張って断定的にそれを語るなよな。=== 事実上今現在の商業ゲーム界の主流の絵は、まずCGであり、手描きの場合は細密かつCG特有のグラデーション、その他最新のテクニックを駆使した多色の華やかな絵柄 でしょう。 その絵が上手に描かれたいいものであれば、ゲーム業界の馬鹿馬鹿しい連中は、この絵はクオリティが高い、などと宣うわけです。 で、その条件から外れた絵を見ると、彼らは下手だ下手だと騒ぎだすのでしょう。 ;アニメーション、漫画、CGイラストレーション 上記の3つの絵画は、多少質が異なるものになるでしょう。前者二つは一枚絵で完結していないので、ある程度簡略化した手間をかけない描き方がなされる。一枚絵のイラストはそれだけで完結なので、事実かなり手間と時間はかける事が出来る。 しかしどちらにしろ、時間と手間は様々な諸事情のバランスで、それが選ばれ決定されますね。 特定の絵が上手いとか下手なことにこだわり、朝から晩までその議論ばかりしている愚か者は多いですが、事実上、時間と手間の大小にかかわらず、特定の人の心を打つ絵というのはある。 しかしやはりその心の動き自体が、主観的なものであるでしょう。 ;後日修正 手間と時間をかけた絵が欲しいなら、後日修正という道はありますね。商業漫画でもアニメーションでも、後から修正を加えて絵の質を高めることはあるでしょう。 基本的にはあらゆる物事が、時間と手間をかけたことによって評価は高まりますが、しかし我々の時間も労力も無限ではない。いいバランスで、いい完成度で、多くの物は創作終了されています。 ===芸術、自由、文化。そして娯楽、商業作品=== さて、前編集者Suj. は常に自分にとって都合のいい主張をしている市販本を探し、そしてそれが見つかったら購入し（しかしそのお金はどこから出ているのだろう?）、そしてそれを斜め読みした後、このサイトでクオリティ最悪の駄文を書き散らしているのだが、彼の愛読書には、ゲーム作りに必要な資質は、作家性と「人を楽しませたいと思う気持ち」<ref name="gpl246">『ゲームプランナー集中講座』、P246</ref>、だと、書かれている、らしい。 まあこのサイトを見てわかるとおり、彼自身はその二つとも全く持ち合わせていないのだが… そしてその馬鹿馬鹿しい本には、ゲーム会社の採用担当も、ゲーム会社自体も、クリエーターに自己表現は求めていない、と書いている<ref name="gpl246" />。つまり、ゲーム会社の幹部たちに都合のいい作業を安い賃金でしてくれる、奴隷が欲しいということだろう。 そして、E.Suj,はとにかく他人の褌をはいて威張ること以外何もしないのだが、彼のイラスト分野の愛読書には、依頼内容を無視して自由に絵を描こうとする人は、「プロ」ではなく「芸術家」、と書かれている<ref> 『クリエイターのためのおんなのこデータベース2008-ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日初版発行、P.198</ref>（らしい）。 ====芸術と商業漫画==== 漫画『サルでも描けるまんが教室』には、芸術と商業漫画に関する面白い記述がありました。 {{コラム|竹熊と相原のサル漫| 一応この漫画を知らない人のために少し説明すると、竹熊健太郎氏が原作、相原コージ氏が作画、まあ必ずきっかり分業がなされているかはわかりませんが、この二人が漫画内で主人公にもなって、商業漫画ハウツーギャクが展開します。 相原「む～…。俺たちはこんなくだらない漫画を描いてていいのだろうか…」 竹熊「どうした相原？」 相原「俺たちはもっと本質的な作品を作るべきではないか？例えば…資本主義などという下らない次元にとらわれてはいけないのではないだろうか…俺たちは国や大企業におどらされているのではないか？やはり漫画にも芸術は必要だろう…」 竹熊「バッキャローー!!!（ガッと、相原を殴る）」 相原「な、何をする…」 竹熊「お前は芸術をぜんぜん分かっちゃあいない！」 相原「そんなことない…」 竹熊「じゃあ、お前のいう芸術とは何か、言ってみろ？」 相原「それはー…、人間の内面の…真実ってゆうか…」 竹熊「にんげんのぉー、ないめんの～しんじつぅ～??? あのなー、お前は権威にとらわれてはいけないとはいうが、じゃあお前のその意見は、どこかの芸術大学の教授の権威にすがっているだけではないのか！？」 相原「そんなことない…お前こそ、政府や商業メデイアによる宣伝のつくった権威にとらわれているじゃないか。」 竹熊「ああそうかね。だけどお前だって、芸術教授の権威にあやかって自分も地位と名誉が欲しいだけだし、結局、お前もカネが欲しいだけなのだ。」 ……と、いうような、もちろんこの漫画は第一にギャグマンガですが、商業漫画界やアニメーション界での、芸術という言葉の捉え方をよく示していると思います。 例えば、『ねじ式』という漫画に芸術性があると評価された、つげ義春さんも自身の漫画が芸術でくくられることを嫌っていました。漫画家は芸術家ではなくて職人だ、と語っていたインタビュー記事を読んだことがあります。 しかし実はこのサル漫、最新最終作『サルまん2.0』ではさらに面白い展開を迎えています。 少し書きますが、「とんち番長」という漫画で一世を風靡した竹熊と相原（もちろんこの漫画内の、ですよ）だったが、やがて落ちぶれ、それでも再起を図って、漫画出版社に持ち込みする。 そこでの編集者が採用を断る時の言葉。 「いやいや先生。我々の雑誌では、先生たちの高尚な漫画は掲載できませんよ…。読者はみんなほんの愚かな子供たちで、先生たちの高尚な漫画はとてもとても理解できません…」 つまり過去大騒ぎして否定していた芸術側に、いつの間にか落ちぶれて、竹熊と相原は所属していたわけです… }} ====私小説==== {{コラム|基本的に娯楽産業の連中は、芸術という言葉も概念も嫌う| 前コラムでも書きましたが、結局商業アニメーションや漫画界では、娯楽、楽しい或いは扇情的、売れる、ということが重要で、あまり芸術的なことを語ると徹底的に嫌われます。 このコラムの前編集を見てもらえるとわかりますが、前編集の筆者もその感覚に追従して、好きかってなことを書いています。 特に自己探求にこだわった創作は、「私小説」などと呼ばれて揶揄されます。 1998年、オタキング岡田斗司夫の対談集『マジメな話』でも、当時のエヴァンゲリオンの映画版を「私小説」だと、対談相手の小説家・今野敏が批判していました。事実上この作品は衒学的な、疑似芸術作品でした。 やはり何らかの娯楽性、収益性、芸術性の問題が、常に創作作品には付きまとうようです。 さて、例えば、大正文学の売上のベストセラーは、 :倉田百三『出家とその弟子』、 :島田清次郎『地上』、 :賀川豊彦『死線を越えて』、 三大ベストセラーですが、しかし今や彼らは文学史の教科書には、滅多にのりません。せいぜい高校日本史の教科書で、倉田が少し紹介されているくらいです。 現代の教科書でよく大正時代の小説家として紹介される芥川龍之介は、じつは当時は倉田・島田らほどには売れていない作家です。また、「私小説」といわれるジャンルも当初から収益性はない。もっとも、芥川が私小説を書き出したのは晩年のことですが…。 しかし前編集者はこの問題に、毎日新聞の戦略とか、左翼がどうのとか、研究不足がどうのとか、なんかいい加減なこと書いているようですが、まあどうでもいいか。 現編集者は上記の3ベストセラーの、倉田の作品だけ読んだことがある。親鸞の話だったけど、私にとっては底の浅いいい加減な話に見えた。はっきり言って芥川の小説の方が、はるかに意味と深い内容を持っているだろう。 島田清次郎に関しては、「栄光なき天才たち」という漫画で、この人物の詳細と人生が描かれていたのを読んでいる。この漫画の中では彼は、「地上」の最終巻の採用を、編集者に断られている。 }} === ローポリ関連の作画 === 単元『[[ゲームプログラミング/3Dグラフィック#ローポリ制作手法的なこと]]』で説明した。 ==レポートは結論だけを読んでも分かるように書く== レポートなどは、ゲーム業界なら、途中を読み飛ばしても、内容がおおまかに分かるように書きたい。 別に冒頭で結論を述べる必要はありませんが（会社による）、しかし、仮に書類のページの順序どおりに他者が読まなくても、 レポート全体の内容を把握できるように書くのが推奨です。 ==書類は誰でも簡単に理解できるように書きたい== 書類の言葉選択は、「中学生の知識でも理解できる言葉を使う」、のが望ましいですね。言いやすいフレーズ、理解しやすいフレーズ、こういう言語選択も重要です。<ref>『ゲームデザイン プロフェッショナル』、P101</ref> 基本的にゲーム界に限らず、あらゆる場所で、わかり易い言葉を使うことが重要ですし、相手の理解に配慮することは必要でしょう。E.Suj.のように自分が理解できなければ全て相手のせいにし、相手が理解できないのもすべて相手のせいにするのは、一番有り得ない最低の態度でしょう。 == 脚注・参考文献 == 82t8nbxb46btbdryyrz1o7kmi2sr4yn 0 33824 206819 205949 2022-08-19T14:47:54Z Linguae 449 /* 各節注解 */ wikitext text/x-wiki <div style="font-family:Arial Black;font-style:normal;font-size:15pt;color:#990033;text-align:center;background-color:#fff0ff;">C・IVLII・CAESARIS・COMMENTARIORVM・BELLI・GALLICI</div> <div style="font-family:Arial Black;font-style:normal;font-size:30pt;color:#990033;text-align:center;background-color:#fff0ff;">LIBER・TERTIVS</div> <span style="font-size:13pt;">『<span style="background-color:#ffc;">[[ガリア戦記 第3巻]]</span>』の単語や構文を詳しく読み解く <span style="background-color:#fc8;font-size:15pt;">'''[[ガリア戦記/注解編|注解編]]'''</span> の目次。</span> {| id="toc" style="border:0px #ddf; align:left;clear:all;" align="center" cellpadding="5" |- ! style="background:#ccf; text-align:center;" colspan="10"| ガリア戦記 第3巻 注解 |- style="background:#f8f8ff; text-align:right; font-size: 0.85em;" |[[/1節|1節]] |[[/2節|2節]] |[[/3節|3節]] |[[/4節|4節]] |[[/5節|5節]] |[[/6節|6節]] |[[/7節|7節]] |[[/8節|8節]] |[[/9節|9節]] |[[/10節|10節]] <!-- |- style="background:#f8f8ff; text-align:right; font-size: 0.85em;" |[[/11節|11節]] |[[/12節|12節]] |[[/13節|13節]] |[[/14節|14節]] |[[/15節|15節]] |[[/16節|16節]] |[[/17節|17節]] |[[/18節|18節]] |[[/19節|19節]] |[[/20節|20節]] |- style="background:#f8f8ff; text-align:right; font-size: 0.85em;" |[[/21節|21節]] |[[/22節|22節]] |[[/23節|23節]] |[[/24節|24節]] |[[/25節|25節]] |[[/26節|26節]] |[[/27節|27節]] |[[/28節|28節]] |[[/29節|29節]] |[[/30節|30節]] | colspan="6" | |- style="background:#f8f8ff; text-align:right; font-size: 0.85em;" |[[/1節|1節]] |[[/2節|2節]] |[[/3節|3節]] |[[/4節|4節]] |[[/5節|5節]] |[[/6節|6節]] |[[/7節|7節]] |[[/8節|8節]] |[[/9節|9節]] |[[/0節|0節]] --> |- | style="background:#f5fefe; text-align:left; font-size: 0.8em;" colspan="10"| [[ガリア戦記 第1巻/注解|'''注解'''&nbsp; 第1巻]] | [[ガリア戦記 第2巻/注解|第2巻]] | [[ガリア戦記 第3巻/注解|第3巻]] <!--| [[ガリア戦記 第4巻/注解|第4巻]] | [[ガリア戦記 第5巻/注解|第5巻]] | [[ガリア戦記 第6巻/注解|第6巻]] | [[ガリア戦記 第7巻/注解|第7巻]] | [[ガリア戦記 第8巻/注解|第8巻]]--> |} <br style="clear:both;" /> __notoc__ == 各節注解 == [[画像:Gaule -56.png|thumb|right|150px|ガリア戦記 第3巻の情勢図（BC56年）。<br>黄色の領域がローマ領。桃色が同盟部族領。]] ===アルプス・オクトードゥールスの戦い=== *<span style="background-color:#fff;">[[/1節]]　{{進捗|00%|2022-04-24}}</span>　（144語） *<span style="background-color:#fff;">[[/2節]]　{{進捗|00%|2022-05-05}}</span>　（127語） *<span style="background-color:#fff;">[[/3節]]　{{進捗|00%|2022-05-05}}</span>　（104語） *<span style="background-color:#fff;">[[/4節]]　{{進捗|00%|2022-05-30}}</span>　（97語）　　　短い節 *<span style="background-color:#fff;">[[/5節]]　{{進捗|00%|2022-05-29}}</span>　（108語） *<span style="background-color:#fff;">[[/6節]]　{{進捗|00%|2022-06-06}}</span>　（130語） ===大西洋岸ウェネティー族の造反=== {{Wikipedia|モルビアン湾の海戦|モルビアン湾の海戦}} [[画像:Map of Aremorican tribes (Latin).svg|thumb|right|400px|[[w:アルモリカ|アルモリカ]]（<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Armorica|Armorica]]''</span> ）の部族分布図。]] *<span style="background-color:#fff;">[[/7節]]　{{進捗|00%|2022-06-12}}</span>　（98語）　　　短い節 *<span style="background-color:#fff;">[[/8節]]　{{進捗|00%|2022-06-20}}</span>　（147語） *<span style="background-color:#fff;">[[/9節]]　{{進捗|00%|2022-06-19}}</span>　（220語） *<span style="background-color:#fff;">[[/10節]]　{{進捗|00%|2022-07-02}}</span>　（79語）　　　短い節 *<span style="background-color:#fff;">[[/11節]]　{{進捗|00%|2022-07-03}}</span>　（112語） *<span style="background-color:#fff;">[[/12節]]　{{進捗|00%|2022-07-09}}</span>　（116語） *<span style="background-color:#fff;">[[/13節]]　{{進捗|00%|2022-07-18}}</span>　（193<!--?-->語） *<span style="background-color:#fff;">[[/14節]]　{{進捗|00%|2022-07-17}}</span>　（205語） *<span style="background-color:#fff;">[[/15節]]　{{進捗|00%|2022-07-28}}</span>　（94語）　　　短い節 *<span style="background-color:#fff;">[[/16節]]　{{進捗|00%|2022-08-20}}</span>　（80語）　　　短い節 *<span style="background-color:#fff;">[[/17節]]　{{進捗|00%|2022-08-20}}</span> <!--【ポン】 *<span style="background-color:#fff;">[[/34節]]　{{進捗|00%|2022-04-06}}</span>　（37語）　　　短い節 *<span style="background-color:#fff;">[[/54節]]　{{進捗|00%|2021-08-26}}</span>　（59語）　　　短い節 *<span style="background-color:#fff;">[[/22節]]　{{進捗|00%|2022-01-19}}</span>　（65語）　　　短い節 *<span style="background-color:#fff;">[[/16節]]　{{進捗|00%|2021-12-15}}</span>　（76節）　　　短い節 *<span style="background-color:#fff;">[[/30節]]　{{進捗|00%|2022-03-05}}</span>　（80語）　　　短い節 *<span style="background-color:#fff;">[[/7節]]　{{進捗|00%|2021-09-23}}</span>　（84節）　　短い節 *<span style="background-color:#fff;">[[/45節]]　{{進捗|00%|2021-06-23}}</span>　（86語）　　　短い節 *<span style="background-color:#fff;">[[/13節]]　{{進捗|00%|2021-11-13}}</span>　（92節）　　短い節 *<span style="background-color:#fff;">[[/51節]]　{{進捗|00%|2021-08-11}}</span>　（95語）　　　短い節 *<span style="background-color:#fff;">[[/4節]]　 {{進捗|00%|2022-05-16}}</span>　（97語）　　　短い節 *<span style="background-color:#fff;">[[/46節]]　{{進捗|00%|2021-07-03}}</span>　（104語） *<span style="background-color:#fff;">[[/42節]]　{{進捗|00%|2021-05-27}}</span>　（182語） *<span style="background-color:#fff;">[[/43節]]　{{進捗|00%|2021-06-02}}</span>　（217語） *<span style="background-color:#fff;">[[/44節]]　{{進捗|00%|2021-06-03}}</span>　（362語）　　長い節 --> == 固有名詞 == <!-- *<span style="background-color:#ffd;">[[/地名]]　　{{進捗|00%|2020-06-11}}</span> *<span style="background-color:#ffd;">[[/部族名]]　{{進捗|00%|2020-06-11}}</span> *<span style="background-color:#ffd;">[[/人名]]　　 {{進捗|00%|2020-07-12}}</span> --> == 関連項目 == *<span style="background-color:#ffd;">[[ガリア戦記]]</span><!--【2006年4月23日起稿】--> **<span style="background-color:#ffd;">[[ガリア戦記/注解編]]</span><!--(2020-03-27)--> ***<span style="background-color:#ffd;">[[ガリア戦記/注解編/写本と校訂版]]　{{進捗|00%|2020-04-17}}</span><!--(2020-04-17)--> **<span style="background-color:#ffd;">[[ガリア戦記/用例集]]　　　　　　　　　　{{進捗|00%|2020-03-29}}</span><!--(2020-03-29)--> **[[ガリア戦記/内容目次]]：巻・章・節の内容を記した目次　{{進捗|75%|2011-04-02}} **[[ガリア戦記/参照画像一覧]]：本文で参照した画像一覧　 {{進捗|75%|2011-04-16}} <br><div style="font-size:20pt;"> Ā Ē Ī Ō Ū ā ē ī ō ū &nbsp; Ă Ĕ Ĭ Ŏ Ŭ ă ĕ ĭ ŏ ŭ </div> <div style="font-size:13pt;"> <math>\overline{\mbox{VIIII}} </math> </div><!-- [[w:Help:数式の表示]] --> <span style="font-family:Times New Roman;font-size:15pt;background-color:#fff;"></span> <span style="font-family:Times New Roman;font-size:15pt;"></span> <span style="font-family:Times New Roman;"></span> <!-- *<span style="font-family:Times New Roman;font-style:normal;font-size:15pt;">† : </span>校訂者が、テクストが壊れていると判断した部分をこの記号で囲んでいる。 --> <!-- <ruby><rb>●漢字●</rb><rp>（</rp><rt>●ルビ●</rt><rp>）</rp></ruby> --> <!-- *<span style="background-color:#ffd;">[[/注解/3節]]　{{進捗|00%|2022-07-02}}</span> --> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> == 関連記事 == {{Wikisource|la:Commentarii de bello Gallico/Liber III|ガリア戦記 第3巻(ラテン語)}} *ウィキソース **<span style="font-family:Times New Roman;">[[s:la:Commentarii de bello Gallico/Liber III]] (第3巻 ラテン語)</span> **<span style="font-family:Times New Roman;">[[s:en:Commentaries on the Gallic War/Book 3]] (第3巻 英訳)</span> **<span style="font-family:Times New Roman;">[[s:fr:La Guerre des Gaules/Livre III]] (第3巻 仏訳)</span> ---- {{Commons|Category:Battles of Caesar's Gallic Wars|Battles of Caesar's Gallic Warsのカテゴリ}} *<span style="font-family:Times New Roman;font-size:13pt;">[[wikt:fr:Catégorie:Mots en latin issus d’un mot en gaulois]]</span> ---- *第3巻の登場人物 **Galba (副官) ***[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)]] ***[[w:en:Servius Sulpicius Galba (praetor 54 BC)]] ***[[w:fr:Servius Sulpicius Galba (préteur en -54)]] **Baculus ***[[w:la:Publius Sextius Baculus]] **Volusenus ***[[w:en:Gaius Volusenus]] ***[[w:fr:Caius Volusenus]] **Crassus ***[[w:プブリウス・リキニウス・クラッスス]] ***[[w:la:Publius Licinius Crassus]] ***[[w:en:Publius Licinius Crassus (son of triumvir)]] ***[[w:fr:Publius Crassus]] **Labienus (副官) ***[[w:ティトゥス・ラビエヌス]] ***[[w:la:Titus Labienus]] ***[[w:en:Titus Labienus]] ***[[w:fr:Titus Labienus]] **Sabinus (副官) ***[[w:クィントゥス・ティトゥリウス・サビヌス]] ***[[w:en:Quintus Titurius Sabinus]] ***[[w:fr:Quintus Titurius Sabinus]] **Brutus ***[[w:デキムス・ユニウス・ブルトゥス・アルビヌス]] ***[[w:la:Decimus Iunius Brutus Albinus]] ***[[w:en:Decimus Junius Brutus Albinus]] ***[[w:fr:Decimus Junius Brutus Albinus]] <br> <hr><!--【第3巻の関連記事】--> {{Commons|Category:Armorica|Armorica}} <span style="font-family:Times New Roman;font-size:13pt;"> *[[c:Category:Armorica]] **[[c:Category:Maps of the Antiquity of Bretagne]] *[[c:Category:Ancient Roman ships]] *[[c:Category:Steering oars]] *[[w:la:Vicipaedia:Glossarium nauticum]] <br> *[[w:en:Battle of Octodurus]] </span> <span style="font-family:Times New Roman;font-size:13pt;"></span> == 外部リンク == *[[ガリア戦記/注解編#外部リンク]]　を参照。 <span style="font-family:Times New Roman;font-style:normal;font-size:13pt;"> ; Eastman, Frederick Carlos., D'Ooge, Benjamin L. 1860-1940.(1917) *[https://catalog.hathitrust.org/Record/001058370 Catalog Record: Caesar in Gaul and selections from the third... | HathiTrust Digital Library] (catalog.hathitrust.org) :[https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=7&skin=2021 #7 - Caesar in Gaul and selections from the third book of the Civil ... - Full View | HathiTrust Digital Library] (babel.hathitrust.org) :II.35./BOOK III [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=383&skin=2021 #383 ] :III.2,3,4　[https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=384&skin=2021 #384 ] :III.5,-8　　[https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=385&skin=2021 #385 ] :III.9　　　[https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=386&skin=2021 #386 ] :III.10,11,12 [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=387&skin=2021 #387 ] :III.13, 14　 [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=388&skin=2021 #388 ] :III.15,-17　 [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=389&skin=2021 #389 ] :III.18,-21　 [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=390&skin=2021 #390 ] :III.22,-24　 [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=391&skin=2021 #391 ] :III.25,-29　 [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=392&skin=2021 #392 ] :BOOK IV. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=393&skin=2021 #393 ] <!-- :II.1. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=367&skin=2021 #367 ] :II.10. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=372&skin=2021 #372 ] :II.20. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=377&skin=2021 #377 ] :II.21. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=378&skin=2021 #378 ] :II.23. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=379&skin=2021 #379 ] :II.25. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=380&skin=2021 #380 ] :II.28. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=381&skin=2021 #381 ] :II.30. [https://babel.hathitrust.org/cgi/pt?id=hvd.hn5cnb&view=1up&seq=382&skin=2021 #382 ] --> </span> <span style="font-family:Times New Roman;font-style:normal;font-size:13pt;"></span> [[Category:ガリア戦記 第3巻|*#]] h12ph02inedl3wi56ynrrust7bk648y 0 35258 206773 205947 2022-08-19T12:48:19Z Linguae 449 /* 原文テキスト */ wikitext text/x-wiki <div style="font-family:Arial Black;font-style:normal;font-size:15pt;color:#990033;text-align:center;">C・IVLII・CAESARIS・COMMENTARIORVM・BELLI・GALLICI</div> <div style="font-family:Arial Black;font-style:normal;font-size:30pt;color:#990033;text-align:center;">LIBER・TERTIVS</div> <br> {| id="toc" style="align:center;clear:all;" align="center" cellpadding="5" |- ! style="background:#bbf; text-align:center;" |&nbsp; [[ガリア戦記/注解編|ガリア戦記 注解編]] &nbsp; | style="background:#ccf; text-align:center;" |&nbsp; [[ガリア戦記 第3巻/注解|第3巻]] &nbsp; | style="background:#eef; text-align:center;"| &nbsp;[[ガリア戦記 第3巻/注解/15節|15節]] | [[ガリア戦記 第3巻/注解/16節|16節]] | [[ガリア戦記 第3巻/注解/17節|17節]] &nbsp; |} __notoc__ == 原文テキスト == <div style="font-family:Times New Roman;font-style:normal;font-size:15pt;color:#333;text-align:left;"><ref>原文テキストについては[[ガリア戦記/注解編#原文テキスト]]を参照。</ref> 16. &nbsp;&nbsp; <!--❶-->¹Quo proelio bellum Venetorum totiusque orae maritimae confectum est. &nbsp;&nbsp; <!--❷-->²Nam cum omnis iuventus, omnes etiam gravioris aetatis in quibus aliquid consili<!--consilii--> aut dignitatis fuit eo convenerant, tum navium quod ubique fuerat in unum locum coegerant; &nbsp;&nbsp; <!--❸-->³quibus amissis reliqui neque quo se reciperent neque quem ad modum oppida defenderent habebant. &nbsp;&nbsp; Itaque se suaque omnia Caesari dediderunt. &nbsp;&nbsp; <!--❹-->⁴In quos eo gravius Caesar vindicandum statuit quo diligentius in reliquum tempus a barbaris ius legatorum conservaretur. &nbsp;&nbsp; Itaque omni senatu necato reliquos sub corona vendidit. </div> <span style="background-color:#ffc;"></span> ---- ;テキスト引用についての注記 <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-style:oblique;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-style:bold;font-size:15pt;"></span> == 整形テキスト == <div style="font-family:Times New Roman;font-style:normal;font-size:15pt;color:#333;text-align:left;"><ref>整形テキストについては[[ガリア戦記/注解編#凡例]]を参照。</ref> </div> <span style="color:#800;"></span> ---- ;注記 <!-- *原文の <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;">[[wikt:en:accommodatae|accommodātae]], [[wikt:en:Aduatuci|Aduatucī]], [[wikt:en:Aduatucos|Aduatucōs]], [[wikt:en:Aedui#Latin|Aeduī]], [[wikt:en:Alpis#Latin|Alpīs]], [[wikt:en:appropinquabat|appropinquābat]], [[wikt:en:appropinquare#Latin|appropinquāre]], [[wikt:en:appulso#Latin|appulsō]], [[wikt:en:auxili#Latin|auxilī]], [[wikt:en:cedentis|cēdentīs]], [[wikt:en:cohortis|cohortīs]], [[wikt:en:coicere|coicere]], [[wikt:en:coiecerunt|coiēcērunt]], [[wikt:en:coiecisse|coiēcisse]], [[wikt:en:collatis|collātīs]], [[wikt:en:collocabant|collocābant]], [[wikt:en:collocandis|collocandīs]], [[wikt:en:collocarat|collocārat]], [[wikt:en:collocare#Latin|collocāre]], [[wikt:en:collocaret|collocāret]], [[wikt:en:collocari|collocārī]], [[wikt:en:colloquium#Latin|colloquium]], complūrīs, [[wikt:en:conantis|cōnantīs]], [[wikt:en:consili|cōnsilī]], [[wikt:en:eis#Latin|eīs]], [[wikt:en:finis#Latin|fīnīs]], [[wikt:en:hostis#Latin|hostīs]], [[wikt:en:imperi#Latin|imperī]], [[wikt:en:irridere#Latin|irrīdēre]], [[wikt:en:montis|montīs]], [[wikt:en:navis#Latin|nāvīs]], [[wikt:en:negoti|negōtī]], nōn nūllōs, [[wikt:en:omnis#Latin|omnīs]], [[wikt:en:partis#Latin|partīs]], [[wikt:en:proeli|proelī]], proficīscentīs, [[wikt:en:resistentis|resistentīs]], [[wikt:en:subeuntis|subeuntīs]], trīs, [[wikt:en:vectigalis#Latin|vectīgālīs]] </span> などは、<br>それぞれ <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;">[[wikt:en:adcommodatae|adcommodātae]], [[wikt:de:Atuatuci|Atuatucī]], Atuatucōs, Haeduī, [[wikt:en:Alpes#Latin|Alpēs]], [[wikt:en:adpropinquabat|adpropinquābat]], [[wikt:en:adpropinquare|adpropinquāre]], [[wikt:en:adpulso|adpulsō]], [[wikt:en:auxilii|auxiliī]], [[wikt:en:cedentes#Latin|cēdentēs]], [[wikt:en:cohortes#Latin|cohortēs]], [[wikt:en:conicere|conicere]], [[wikt:en:coniecerunt|coniēcērunt]], [[wikt:en:coniecisse|coniēcisse]], [[wikt:en:conlatis|conlātīs]], [[wikt:en:conlocabant|conlocābant]], [[wikt:en:conlocandis|conlocandīs]], [[wikt:en:conlocarat|conlocārat]], [[wikt:en:conlocare|conlocāre]], [[wikt:en:conlocaret|conlocāret]], [[wikt:en:conlocari|conlocārī]], [[wikt:en:conloquium#Latin|conloquium]], [[wikt:en:complures#Latin|complūrēs]], [[wikt:en:conantes|cōnantēs]], [[wikt:en:consilii|cōnsiliī]], [[wikt:en:iis#Latin|iīs]], [[wikt:en:fines#Latin|fīnēs]], [[wikt:en:hostes#Latin|hostēs]], [[wikt:en:imperii#Latin|imperiī]], [[wikt:en:inridere|inrīdēre]], [[wikt:en:montes#Latin|montēs]], [[wikt:en:naves#Latin|nāvēs]], [[wikt:en:negotii|negōtiī]], [[wikt:en:nonnullos|nōnnūllōs]], [[wikt:en:omnes#Latin|omnēs]], [[wikt:en:partes#Latin|partēs]], [[wikt:en:proelii|proeliī]], [[wikt:en:proficiscentes|proficīscentēs]], [[wikt:en:resistentes#Latin|resistentēs]], [[wikt:en:subeuntes|subeuntēs]], [[wikt:en:tres#Latin|trēs]], [[wikt:en:vectigales|vectīgālēs]] </span> などとした。 --> <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-style:oblique;font-size:15pt;"></span> <span style="color:#b00;"></span> <span style="color:#800;"></span> <span style="font-size:10pt;"></span> <span style="background-color:#ff0;"></span> == 注解 == === 1項 === <span style="font-family:Times New Roman;font-size:20pt;"></span> ;語釈 <span style="font-family:Times New Roman;font-size:15pt;background-color:#fff;"></span> <span style="font-family:Times New Roman;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-size:15pt;"></span> <span style="background-color:#ccffcc;"></span> <!-- ;対訳 《　》　内は、訳者が説明のために補った語。<span style="font-family:Times New Roman;font-size:30pt;">{</span>　<span style="font-family:Times New Roman;font-size:30pt;">}</span>　内は関係文。 <span style="font-family:Times New Roman;font-size:15pt;"></span> --> == 訳文 == *<span style="background-color:#dff;">訳文は、[[ガリア戦記_第3巻#16節]]</span> == 脚注 == {{Reflist}} == 解説 == <!-- {| class="wikitable" style="text-align:center" |- style="height:23em;" | | |} --> == 関連項目 == *[[ガリア戦記]] **[[ガリア戦記/注解編]] ***[[ガリア戦記 第3巻/注解]] **[[ガリア戦記/用例集]] == 関連記事 == == 外部リンク == [[Category:ガリア戦記 第3巻|16節]] lst4skp5obbdunhkvnoezit8al9baeg 0 35347 206815 206708 2022-08-19T14:06:17Z Linguae 449 wikitext text/x-wiki <div style="font-size:35pt;text-align:center;">羅馬史畧　　　　　</div> <div style="background-color:#fffffee; width:800px;">　'''羅馬史略'''（羅馬史畧、ろーましりゃく）は、明治初期の[[w:1874年|1874年]]（明治7年）に日本の[[w:文部省|文部省]]が発行した[[w:古代ローマ|古代ローマ史]]の教科書。全10巻で、アメリカなどの複数の著述家などが著した英語の著作などをもとに、英語学などを修めて当時の文部省職員であった国語学者の '''[[w:大槻文彦|大槻文彦]]'''（1847-1928）が翻案したものである。<br>　</div> <div style="background-color:#ffffef; width:800px;">　『羅馬史略』という書名は「ローマ史の概略」あるいは「概説ローマ史」という意味である。内容は、伝承上の初代王である[[w:ロームルス|ロームルス]]による建国（紀元前8世紀）から、[[w:東ローマ帝国|東ローマ帝国]]の滅亡（[[w:1453年|1453年]]）まで約2200年にも及ぶ。<br>古代ローマ史だけでこのような大部の教科書が発行された理由は、当時の明治政府が国民への西洋事情の啓蒙を急いでいたという時勢があったためであろう。<br>　</div> <div style="background-color:#ffffff; width:800px;">　明治初期の著作全般にいえることであるが、現代日本語の[[w:日本語#文語文と口語文|口語文]]が確立する前の文語文で書かれ、漢字・仮名ともに現代では用いられない特殊な字体も見られるため、大戦後の現代日本人には甚だ読みづらい代物である。 <br>　ここでは、ローマ史のハイライトというべき題材を選び、読みづらい日本語文語文を判読しつつ、明治維新期の日本政府が教育しようとしていたローマ史を読み解く。 </div> __notoc__ == 各巻の内容 == == 羅馬史略の読解 == *巻之五 **<span style="background-color:#ffc;">[[/巻之五/塞撒ガ髙慮ヲ征伐スル事|/塞撒ガ髙慮ヲ征伐スル事]]（カエサルがガリアを征伐する事） {{進捗|00%|2022-08-18}}　</span><!-- 2022-08-18より --> == 関連項目 == *[[ガリア戦記]] *[[内乱記]] == 外部リンク == [[Category:羅馬史略|*]] [[Category:ローマ史|ろうましりやく]] px2ockvq1b2zvof2iqqwjlkbmunl80l 206817 206815 2022-08-19T14:27:28Z Linguae 449 wikitext text/x-wiki <div style="font-family:游明朝;font-size:60pt;text-align:center;">羅馬史畧　　　　</div> <div style="background-color:#fffffee; width:800px;">　'''羅馬史略'''（羅馬史畧、ろーましりゃく）は、明治初期の[[w:1874年|1874年]]（明治7年）に日本の[[w:文部省|文部省]]が発行した[[w:古代ローマ|古代ローマ史]]の教科書。全10巻で、アメリカなどの複数の著述家などが著した英語の著作などをもとに、英語学などを修めて当時の文部省職員であった国語学者の '''[[w:大槻文彦|大槻文彦]]'''（1847-1928）が翻案したものである。<br>　</div> <div style="background-color:#ffffef; width:800px;">　『羅馬史略』という書名は「ローマ史の概略」あるいは「概説ローマ史」という意味である。内容は、伝承上の初代王である[[w:ロームルス|ロームルス]]による建国（紀元前8世紀）から、[[w:東ローマ帝国|東ローマ帝国]]の滅亡（[[w:1453年|1453年]]）まで約2200年にも及ぶ。<br>古代ローマ史だけでこのような大部の教科書が発行された理由は、当時の明治政府が国民への西洋事情の啓蒙を急いでいたという時勢があったためであろう。<br>　</div> <div style="background-color:#ffffff; width:800px;">　明治初期の著作全般にいえることであるが、現代日本語の[[w:日本語#文語文と口語文|口語文]]が確立する前の文語文で書かれ、漢字・仮名ともに現代では用いられない特殊な字体も見られるため、大戦後の現代日本人には甚だ読みづらい代物である。 <br>　ここでは、ローマ史のハイライトというべき題材を選び、読みづらい日本語文語文を判読しつつ、明治維新期の日本政府が教育しようとしていたローマ史を読み解く。 </div> __notoc__ == 各巻の内容 == == 羅馬史略の読解 == *巻之五 **<span style="background-color:#ffc;">[[/巻之五/塞撒ガ髙慮ヲ征伐スル事|/塞撒ガ髙慮ヲ征伐スル事]]（カエサルがガリアを征伐する事） {{進捗|00%|2022-08-18}}　</span><!-- 2022-08-18より --> == 関連項目 == *[[ガリア戦記]] *[[内乱記]] == 外部リンク == [[Category:羅馬史略|*]] [[Category:ローマ史|ろうましりやく]] mfj3j9cj6sc6bg8uliauxtpg3ggkodr 0 35348 206814 206741 2022-08-19T14:00:05Z Linguae 449 /* 原文と修整テキスト */ wikitext text/x-wiki <div style="font-size:35pt;text-align:center;">羅馬史畧&nbsp;巻之五</div> <div style="font-size:20pt;text-align:center;">塞撒ガ髙慮ヲ征伐スル事</div> == はじめに == ここに示すのは、[[w:紀元前58年|紀元前58年]]にローマの政治家・武将[[w:ガイウス・ユリウス・カエサル|ユリウス・カエサル]]が[[w:ガリア|ガリア]]（現在のフランス・ベルギーなど）の征服戦争（[[w:ガリア戦争|ガリア戦争]]）を起こした記事である。この記事の後半は、カエサルの盟友[[w:マルクス・リキニウス・クラッスス|クラッスス]]の出来事を記すものだが、別稿に譲る。 == 原文と修整テキスト == 下表の左欄に原文を、右欄に修整テキストを示す。<br>修整テキストは、原文をもとにして漢字・仮名づかいなどの表記をより読みやすいように修整したものである。<br><span style="color:#800;">赤い文字</span>は、端末の環境（OSやブラウザー）によっては正しく表示されない場合がある。 {| class="wikitable" style="vertical-align:top;" |- style="font-family:Times New Roman;font-size:18pt;" | style="width:5em; text-align:center; background-color:#ddd;" |塞撒ガ<ruby><rb>髙慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>ヲ征伐スル事<br>紀元前五十八年ニ起ル | style="width:15em; text-align:center; background-color:#ddd;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>髙慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>を征伐する事<br>紀元前五十八年に起る |- style="vertical-align:top; font-family:Times New Roman;" | style="width:52%; font-size:15pt;" |塞撒ガ髙<!--&#39641;-->慮ニ於ケル政治戰畧ノ記事ハ、其自記スル<span style="color:#800;">&#x2B742;</span>ノ一正史アリテ、沿革事歴、能ク今世ニ傳ハレリ、 | style="width:48%; font-size:15pt;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>髙<!--&#39641;-->慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>に<ruby><rb>於</rb><rp>（</rp><rt>お</rt><rp>）</rp></ruby>ける政治戦略<ref>戰畧 → 戦略：旧字体→新字体の書き換え。</ref>の記事は、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>自記する所<ref name="ところ"><span style="font-size:30pt;"><span style="color:#800;">[[wikt:𫝂|&#x2B742;]]</span>([[画像:Gw u2b742.svg|border|40px]])</span> は「所」の俗字なので、書き換えた。</ref>の一正史ありて、沿革事歴、<ruby><rb>能</rb><rp>（</rp><rt>よ</rt><rp>）</rp></ruby>く<ruby><rb>今世</rb><rp>（</rp><rt>こんせ</rt><rp>）</rp></ruby>に伝<ref>傳 → 伝：旧字体→新字体の書き換え。</ref>われり、 |- style="vertical-align:top; font-family:Times New Roman;" | style="width:52%; font-size:15pt;" |塞撒、初メ此國ヲ征シテ、頗ル困難ナリシガ、終ニ其智勇ヲ以テ、盡ク之ヲ征服シ、羅馬ニ於テハ、其名聲嘖々トシテ、人皆塞撒ヲ驚歎畏敬セリ、 | style="width:48%; font-size:15pt;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>、初め<ruby><rb>此</rb><rp>（</rp><rt>この</rt><rp>）</rp></ruby>国<ref name="国">國 → 国：旧字体→新字体の書き換え。</ref>を征して、<ruby><rb>頗</rb><rp>（</rp><rt>すこぶ</rt><rp>）</rp></ruby>る困難なりしが、<ruby><rb>終</rb><rp>（</rp><rt>つい</rt><rp>）</rp></ruby>に<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>智勇を<ruby><rb>以</rb><rp>（</rp><rt>もっ</rt><rp>）</rp></ruby>て、<ruby><rb>盡</rb><rp>（</rp><rt>ことごと</rt><rp>）</rp></ruby>く<ruby><rb>之</rb><rp>（</rp><rt>これ</rt><rp>）</rp></ruby>を征服し、<ruby><rb>羅馬</rb><rp>（</rp><rt>ローマ</rt><rp>）</rp></ruby>に<ruby><rb>於</rb><rp>（</rp><rt>おい</rt><rp>）</rp></ruby>ては、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>名声<ruby><rb>嘖々</rb><rp>（</rp><rt>さくさく</rt><rp>）</rp></ruby>として、人皆<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>を驚嘆<ref>「[[wikt:歎|歎]]」を「[[wikt:嘆|嘆]]」に書き換えた。</ref><ruby><rb>畏敬</rb><rp>（</rp><rt>いけい</rt><rp>）</rp></ruby>せり、 |- style="vertical-align:top; font-family:Times New Roman;" | style="width:52%; font-size:15pt;" |獨リ會議官ニ<ruby><rb>加𡈽<!--&#135741;--></rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby>ナル者アリ、决<!--&#20915;-->シテ塞撒ヲ信セズ、其人、性剛毅ニシテ、功名ノ心ヨリハ、國ノ自由ヲ念<!--(おも)-->フノ心、更ニ大ニシテ、塞撒ガ非望ヲ懐<!--(なつ)-->クノ志アリテ、今其敵ヲ征服スルノ間ニ當<!--(あたっ)-->テ、既ニ、他年、自國ヲ脚下ニ壓スルノ機ヲ<!--〓-->含<!--〓-->メルヿ<!--&#x30FF;-->ヲ先見セリ、」 | style="width:48%; font-size:15pt;" |<ruby><rb>独</rb><rp>（</rp><rt>ひと</rt><rp>）</rp></ruby><ref>獨 → 独：旧字体→新字体の書き換え。</ref>り会<ref>會 → 会：旧字体→新字体の書き換え。</ref>議官<ref>「会議官」は、[[w:元老院 (ローマ)|元老院]]の議員のこと。</ref>に<ruby><rb>加土</rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby><ref>「[[wikt:𡈽|𡈽]]」は「[[wikt:土|土]]」の異体字なので、書き換えた。</ref><ref>「<ruby><rb>加土</rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby>」は、元老院議員でカエサルの政敵であった「小カトー」こと[[w:マルクス・ポルキウス・カト・ウティケンシス|マールクス・ポルキウス・カトー（・ウティケーンシス）]]のこと。</ref>なる者あり、<ruby><rb>決</rb><rp>（</rp><rt>けっ</rt><rp>）</rp></ruby><ref>「[[wikt:决|决]]」は「[[wikt:決|決]]」の異体字なので、書き換えた。</ref>して<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>を信ぜず、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>人、性剛毅にして、功名の心よりは、国<ref name="国"/>の自由を<ruby><rb>念</rb><rp>（</rp><rt>おも</rt><rp>）</rp></ruby>うの心、<ruby><rb>更</rb><rp>（</rp><rt>さら</rt><rp>）</rp></ruby>に大にして、<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>非望</rb><rp>（</rp><rt>ひぼう</rt><rp>）</rp></ruby><ref>「非望」とは、身分不相応の大それたことを望むこと、また、その望み。[https://kotobank.jp/word/%E9%9D%9E%E6%9C%9B-612357 コトバンク]等を参照せよ。</ref>を<ruby><rb>懐</rb><rp>（</rp><rt>なつ</rt><rp>）</rp></ruby>くの志ありて、今<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>敵を征服するの間に<ruby><rb>当</rb><rp>（</rp><rt>あたっ</rt><rp>）</rp></ruby>て、<ruby><rb>既</rb><rp>（</rp><rt>すで</rt><rp>）</rp></ruby>に、他年、自国<ref name="国"/>を脚下に圧<ref>壓 → 圧：旧字体→新字体の書き換え。</ref>するの機を<!--〓-->含<!--〓-->める事<ref name="事">「[[w:ヿ|ヿ]]<!--&#x30FF;-->」は「事(こと)」を表わす特殊な仮名文字なので「事」と書き換えた。</ref>を先見せり、」 |- style="vertical-align:top; font-family:Times New Roman;" | style="width:52%; font-size:15pt;" | | style="width:48%; font-size:15pt;" | |} （編集中） <!-- <span style="color:#800;"></span> <span style="font-size:50pt;"></span> <ruby><rb>●漢字●</rb><rp>（</rp><rt>●ルビ●</rt><rp>）</rp></ruby> --> == 訳注 == <div class="references-small"><references group="訳注"/></div> [[Category:羅馬史略|せさる]] njs9n6mzkls2hr0l0vebf496z43a84b 206816 206814 2022-08-19T14:24:42Z Linguae 449 /* 原文と修整テキスト */ wikitext text/x-wiki <div style="font-size:35pt;text-align:center;">羅馬史畧&nbsp;巻之五</div> <div style="font-size:20pt;text-align:center;">塞撒ガ髙慮ヲ征伐スル事</div> == はじめに == ここに示すのは、[[w:紀元前58年|紀元前58年]]にローマの政治家・武将[[w:ガイウス・ユリウス・カエサル|ユリウス・カエサル]]が[[w:ガリア|ガリア]]（現在のフランス・ベルギーなど）の征服戦争（[[w:ガリア戦争|ガリア戦争]]）を起こした記事である。この記事の後半は、カエサルの盟友[[w:マルクス・リキニウス・クラッスス|クラッスス]]の出来事を記すものだが、別稿に譲る。 == 原文と修整テキスト == 下表の左欄に原文を、右欄に修整テキストを示す。<br>修整テキストは、原文をもとにして漢字・仮名づかいなどの表記をより読みやすいように修整したものである。<br><span style="color:#800;">赤い文字</span>は、端末の環境（OSやブラウザー）によっては正しく表示されない場合がある。 {| class="wikitable" style="vertical-align:top;" |- style="font-family:游明朝;font-size:18pt;" | style="width:15em;text-align:center; background-color:#ddd;" |塞撒ガ<ruby><rb>髙慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>ヲ征伐スル事<br>紀元前五十八年ニ起ル | style="width:19em;text-align:center; background-color:#ddd;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>髙慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>を征伐する事<br>紀元前五十八年に起る |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" |塞撒ガ髙<!--&#39641;-->慮ニ於ケル政治戰畧ノ記事ハ、其自記スル<span style="color:#800;">&#x2B742;</span>ノ一正史アリテ、沿革事歴、能ク今世ニ傳ハレリ、 | style="font-size:16pt;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>髙<!--&#39641;-->慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>に<ruby><rb>於</rb><rp>（</rp><rt>お</rt><rp>）</rp></ruby>ける政治戦略<ref>戰畧 → 戦略：旧字体→新字体の書き換え。</ref>の記事は、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>自記する所<ref name="ところ"><span style="font-size:30pt;"><span style="color:#800;">[[wikt:𫝂|&#x2B742;]]</span>([[画像:Gw u2b742.svg|border|40px]])</span> は「所」の俗字なので、書き換えた。</ref>の一正史ありて、沿革事歴、<ruby><rb>能</rb><rp>（</rp><rt>よ</rt><rp>）</rp></ruby>く<ruby><rb>今世</rb><rp>（</rp><rt>こんせ</rt><rp>）</rp></ruby>に伝<ref>傳 → 伝：旧字体→新字体の書き換え。</ref>われり、 |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" |塞撒、初メ此國ヲ征シテ、頗ル困難ナリシガ、終ニ其智勇ヲ以テ、盡ク之ヲ征服シ、羅馬ニ於テハ、其名聲嘖々トシテ、人皆塞撒ヲ驚歎畏敬セリ、 | style="font-size:16pt;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>、初め<ruby><rb>此</rb><rp>（</rp><rt>この</rt><rp>）</rp></ruby>国<ref name="国">國 → 国：旧字体→新字体の書き換え。</ref>を征して、<ruby><rb>頗</rb><rp>（</rp><rt>すこぶ</rt><rp>）</rp></ruby>る困難なりしが、<ruby><rb>終</rb><rp>（</rp><rt>つい</rt><rp>）</rp></ruby>に<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>智勇を<ruby><rb>以</rb><rp>（</rp><rt>もっ</rt><rp>）</rp></ruby>て、<ruby><rb>盡</rb><rp>（</rp><rt>ことごと</rt><rp>）</rp></ruby>く<ruby><rb>之</rb><rp>（</rp><rt>これ</rt><rp>）</rp></ruby>を征服し、<ruby><rb>羅馬</rb><rp>（</rp><rt>ローマ</rt><rp>）</rp></ruby>に<ruby><rb>於</rb><rp>（</rp><rt>おい</rt><rp>）</rp></ruby>ては、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>名声<ruby><rb>嘖々</rb><rp>（</rp><rt>さくさく</rt><rp>）</rp></ruby>として、人皆<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>を驚嘆<ref>「[[wikt:歎|歎]]」を「[[wikt:嘆|嘆]]」に書き換えた。</ref><ruby><rb>畏敬</rb><rp>（</rp><rt>いけい</rt><rp>）</rp></ruby>せり、 |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" |獨リ會議官ニ<ruby><rb>加𡈽<!--&#135741;--></rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby>ナル者アリ、决<!--&#20915;-->シテ塞撒ヲ信セズ、其人、性剛毅ニシテ、功名ノ心ヨリハ、國ノ自由ヲ念<!--(おも)-->フノ心、更ニ大ニシテ、塞撒ガ非望ヲ懐<!--(なつ)-->クノ志アリテ、今其敵ヲ征服スルノ間ニ當<!--(あたっ)-->テ、既ニ、他年、自國ヲ脚下ニ壓スルノ機ヲ<!--〓-->含<!--〓-->メルヿ<!--&#x30FF;-->ヲ先見セリ、」 | style="font-size:16pt;" |<ruby><rb>独</rb><rp>（</rp><rt>ひと</rt><rp>）</rp></ruby><ref>獨 → 独：旧字体→新字体の書き換え。</ref>り会<ref>會 → 会：旧字体→新字体の書き換え。</ref>議官<ref>「会議官」は、[[w:元老院 (ローマ)|元老院]]の議員のこと。</ref>に<ruby><rb>加土</rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby><ref>「[[wikt:𡈽|𡈽]]」は「[[wikt:土|土]]」の異体字なので、書き換えた。</ref><ref>「<ruby><rb>加土</rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby>」は、元老院議員でカエサルの政敵であった「小カトー」こと[[w:マルクス・ポルキウス・カト・ウティケンシス|マールクス・ポルキウス・カトー（・ウティケーンシス）]]のこと。</ref>なる者あり、<ruby><rb>決</rb><rp>（</rp><rt>けっ</rt><rp>）</rp></ruby><ref>「[[wikt:决|决]]」は「[[wikt:決|決]]」の異体字なので、書き換えた。</ref>して<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>を信ぜず、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>人、性剛毅にして、功名の心よりは、国<ref name="国"/>の自由を<ruby><rb>念</rb><rp>（</rp><rt>おも</rt><rp>）</rp></ruby>うの心、<ruby><rb>更</rb><rp>（</rp><rt>さら</rt><rp>）</rp></ruby>に大にして、<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>非望</rb><rp>（</rp><rt>ひぼう</rt><rp>）</rp></ruby><ref>「非望」とは、身分不相応の大それたことを望むこと、また、その望み。[https://kotobank.jp/word/%E9%9D%9E%E6%9C%9B-612357 コトバンク]等を参照せよ。</ref>を<ruby><rb>懐</rb><rp>（</rp><rt>なつ</rt><rp>）</rp></ruby>くの志ありて、今<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>敵を征服するの間に<ruby><rb>当</rb><rp>（</rp><rt>あたっ</rt><rp>）</rp></ruby>て、<ruby><rb>既</rb><rp>（</rp><rt>すで</rt><rp>）</rp></ruby>に、他年、自国<ref name="国"/>を脚下に圧<ref><span style="font-size:20pt;">[[wikt:壓|壓]]</span> → 圧：旧字体→新字体の書き換え。</ref>するの機を<!--〓-->含<!--〓-->める事<ref name="事">「[[w:ヿ|ヿ]]<!--&#x30FF;-->」は「事(こと)」を表わす特殊な仮名文字なので「事」と書き換えた。</ref>を先見せり、」 |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" | | style="font-size:16pt;" | |- ! style="width:15em;" | ! style="width:19em;" | |} （編集中） <!-- <span style="color:#800;"></span> <span style="font-size:20pt;"></span> <ruby><rb>●漢字●</rb><rp>（</rp><rt>●ルビ●</rt><rp>）</rp></ruby> --> == 訳注 == <div class="references-small"><references group="訳注"/></div> [[Category:羅馬史略|せさる]] ce6dsqd5in24ujmozddgpd94ph208g5 206818 206816 2022-08-19T14:37:46Z Linguae 449 固有名詞の表記例 wikitext text/x-wiki <div style="font-family:游明朝;font-size:35pt;text-align:center;">羅馬史畧&nbsp;巻之五</div> <div style="font-family:游明朝;font-size:20pt;text-align:center;">塞撒ガ髙慮ヲ征伐スル事</div> == はじめに == ここに示すのは、[[w:紀元前58年|紀元前58年]]にローマの政治家・武将[[w:ガイウス・ユリウス・カエサル|ユリウス・カエサル]]が[[w:ガリア|ガリア]]（現在のフランス・ベルギーなど）の征服戦争（[[w:ガリア戦争|ガリア戦争]]）を起こした記事である。この記事の後半は、カエサルの盟友[[w:マルクス・リキニウス・クラッスス|クラッスス]]の出来事を記すものだが、こちらは別稿に譲る。 ;　固有名詞の表記例 <div style="font-family:游明朝;font-size:15pt;">　　<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby> → [[w:ガイウス・ユリウス・カエサル|カエサル]]、<ruby><rb>髙<!--&#39641;-->慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>→[[w:ガリア|ガリア]]、<ruby><rb>加𡈽<!--&#135741;--></rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby>→[[w:マルクス・ポルキウス・カト・ウティケンシス|カトー]] </div> == 原文と修整テキスト == 下表の左欄に原文を、右欄に修整テキストを示す。<br>修整テキストは、原文をもとにして漢字・仮名づかいなどの表記をより読みやすいように修整したものである。<br><span style="color:#800;">赤い文字</span>は、端末の環境（OSやブラウザー）によっては正しく表示されない場合がある。 {| class="wikitable" style="vertical-align:top;" |- style="font-family:游明朝;font-size:18pt;" | style="width:15em;text-align:center; background-color:#ddd;" |塞撒ガ<ruby><rb>髙慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>ヲ征伐スル事<br>紀元前五十八年ニ起ル | style="width:19em;text-align:center; background-color:#ddd;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>髙慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>を征伐する事<br>紀元前五十八年に起る |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" |塞撒ガ髙<!--&#39641;-->慮ニ於ケル政治戰畧ノ記事ハ、其自記スル<span style="color:#800;">&#x2B742;</span>ノ一正史アリテ、沿革事歴、能ク今世ニ傳ハレリ、 | style="font-size:16pt;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>髙<!--&#39641;-->慮</rb><rp>（</rp><rt>ゴウル</rt><rp>）</rp></ruby>に<ruby><rb>於</rb><rp>（</rp><rt>お</rt><rp>）</rp></ruby>ける政治戦略<ref>戰畧 → 戦略：旧字体→新字体の書き換え。</ref>の記事は、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>自記する所<ref name="ところ"><span style="font-size:30pt;"><span style="color:#800;">[[wikt:𫝂|&#x2B742;]]</span>([[画像:Gw u2b742.svg|border|40px]])</span> は「所」の俗字なので、書き換えた。</ref>の一正史ありて、沿革事歴、<ruby><rb>能</rb><rp>（</rp><rt>よ</rt><rp>）</rp></ruby>く<ruby><rb>今世</rb><rp>（</rp><rt>こんせ</rt><rp>）</rp></ruby>に伝<ref>傳 → 伝：旧字体→新字体の書き換え。</ref>われり、 |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" |塞撒、初メ此國ヲ征シテ、頗ル困難ナリシガ、終ニ其智勇ヲ以テ、盡ク之ヲ征服シ、羅馬ニ於テハ、其名聲嘖々トシテ、人皆塞撒ヲ驚歎畏敬セリ、 | style="font-size:16pt;" |<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>、初め<ruby><rb>此</rb><rp>（</rp><rt>この</rt><rp>）</rp></ruby>国<ref name="国">國 → 国：旧字体→新字体の書き換え。</ref>を征して、<ruby><rb>頗</rb><rp>（</rp><rt>すこぶ</rt><rp>）</rp></ruby>る困難なりしが、<ruby><rb>終</rb><rp>（</rp><rt>つい</rt><rp>）</rp></ruby>に<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>智勇を<ruby><rb>以</rb><rp>（</rp><rt>もっ</rt><rp>）</rp></ruby>て、<ruby><rb>盡</rb><rp>（</rp><rt>ことごと</rt><rp>）</rp></ruby>く<ruby><rb>之</rb><rp>（</rp><rt>これ</rt><rp>）</rp></ruby>を征服し、<ruby><rb>羅馬</rb><rp>（</rp><rt>ローマ</rt><rp>）</rp></ruby>に<ruby><rb>於</rb><rp>（</rp><rt>おい</rt><rp>）</rp></ruby>ては、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>名声<ruby><rb>嘖々</rb><rp>（</rp><rt>さくさく</rt><rp>）</rp></ruby>として、人皆<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>を驚嘆<ref>「[[wikt:歎|歎]]」を「[[wikt:嘆|嘆]]」に書き換えた。</ref><ruby><rb>畏敬</rb><rp>（</rp><rt>いけい</rt><rp>）</rp></ruby>せり、 |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" |獨リ會議官ニ<ruby><rb>加𡈽<!--&#135741;--></rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby>ナル者アリ、决<!--&#20915;-->シテ塞撒ヲ信セズ、其人、性剛毅ニシテ、功名ノ心ヨリハ、國ノ自由ヲ念<!--(おも)-->フノ心、更ニ大ニシテ、塞撒ガ非望ヲ懐<!--(なつ)-->クノ志アリテ、今其敵ヲ征服スルノ間ニ當<!--(あたっ)-->テ、既ニ、他年、自國ヲ脚下ニ壓スルノ機ヲ<!--〓-->含<!--〓-->メルヿ<!--&#x30FF;-->ヲ先見セリ、」 | style="font-size:16pt;" |<ruby><rb>独</rb><rp>（</rp><rt>ひと</rt><rp>）</rp></ruby><ref>獨 → 独：旧字体→新字体の書き換え。</ref>り会<ref>會 → 会：旧字体→新字体の書き換え。</ref>議官<ref>「会議官」は、[[w:元老院 (ローマ)|元老院]]の議員のこと。</ref>に<ruby><rb>加土</rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby><ref>「[[wikt:𡈽|𡈽]]」は「[[wikt:土|土]]」の異体字なので、書き換えた。</ref><ref>「<ruby><rb>加土</rb><rp>（</rp><rt>カト</rt><rp>）</rp></ruby>」は、元老院議員でカエサルの政敵であった「小カトー」こと[[w:マルクス・ポルキウス・カト・ウティケンシス|マールクス・ポルキウス・カトー（・ウティケーンシス）]]のこと。</ref>なる者あり、<ruby><rb>決</rb><rp>（</rp><rt>けっ</rt><rp>）</rp></ruby><ref>「[[wikt:决|决]]」は「[[wikt:決|決]]」の異体字なので、書き換えた。</ref>して<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>を信ぜず、<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>人、性剛毅にして、功名の心よりは、国<ref name="国"/>の自由を<ruby><rb>念</rb><rp>（</rp><rt>おも</rt><rp>）</rp></ruby>うの心、<ruby><rb>更</rb><rp>（</rp><rt>さら</rt><rp>）</rp></ruby>に大にして、<ruby><rb>塞撒</rb><rp>（</rp><rt>セサル</rt><rp>）</rp></ruby>が<ruby><rb>非望</rb><rp>（</rp><rt>ひぼう</rt><rp>）</rp></ruby><ref>「非望」とは、身分不相応の大それたことを望むこと、また、その望み。[https://kotobank.jp/word/%E9%9D%9E%E6%9C%9B-612357 コトバンク]等を参照せよ。</ref>を<ruby><rb>懐</rb><rp>（</rp><rt>なつ</rt><rp>）</rp></ruby>くの志ありて、今<ruby><rb>其</rb><rp>（</rp><rt>その</rt><rp>）</rp></ruby>敵を征服するの間に<ruby><rb>当</rb><rp>（</rp><rt>あたっ</rt><rp>）</rp></ruby>て、<ruby><rb>既</rb><rp>（</rp><rt>すで</rt><rp>）</rp></ruby>に、他年、自国<ref name="国"/>を脚下に圧<ref><span style="font-size:20pt;">[[wikt:壓|壓]]</span> → 圧：旧字体→新字体の書き換え。</ref>するの機を<!--〓-->含<!--〓-->める事<ref name="事">「[[w:ヿ|ヿ]]<!--&#x30FF;-->」は「事(こと)」を表わす特殊な仮名文字なので「事」と書き換えた。</ref>を先見せり、」 |- style="vertical-align:top; font-family:游明朝;" | style="font-size:16pt;" | | style="font-size:16pt;" | |- ! style="width:15em;" | ! style="width:19em;" | |} （編集中） <!-- <span style="color:#800;"></span> <span style="font-size:20pt;"></span> <ruby><rb>●漢字●</rb><rp>（</rp><rt>●ルビ●</rt><rp>）</rp></ruby> --> == 訳注 == <div class="references-small"><references group="訳注"/></div> [[Category:羅馬史略|せさる]] e4pjznc4zwvl4yw8k1zqhalio43ncbf 0 35360 206747 2022-08-19T12:14:25Z Linguae 449 17節 wikitext text/x-wiki <div style="font-family:Arial Black;font-style:normal;font-size:15pt;color:#990033;text-align:center;">C・IVLII・CAESARIS・COMMENTARIORVM・BELLI・GALLICI</div> <div style="font-family:Arial Black;font-style:normal;font-size:30pt;color:#990033;text-align:center;">LIBER・TERTIVS</div> <br> {| id="toc" style="align:center;clear:all;" align="center" cellpadding="5" |- ! style="background:#bbf; text-align:center;" |&nbsp; [[ガリア戦記/注解編|ガリア戦記 注解編]] &nbsp; | style="background:#ccf; text-align:center;" |&nbsp; [[ガリア戦記 第3巻/注解|第3巻]] &nbsp; | style="background:#eef; text-align:center;"| &nbsp;[[ガリア戦記 第3巻/注解/16節|16節]] | [[ガリア戦記 第3巻/注解/17節|17節]] | [[ガリア戦記 第3巻/注解/18節|18節]] &nbsp; |} __notoc__ == 原文テキスト == <div style="font-family:Times New Roman;font-style:normal;font-size:15pt;color:#333;text-align:left;"><ref>原文テキストについては[[ガリア戦記/注解編#原文テキスト]]を参照。</ref> </div> <span style="background-color:#ffc;"></span> ---- ;テキスト引用についての注記 <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-style:oblique;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-style:bold;font-size:15pt;"></span> == 整形テキスト == <div style="font-family:Times New Roman;font-style:normal;font-size:15pt;color:#333;text-align:left;"><ref>整形テキストについては[[ガリア戦記/注解編#凡例]]を参照。</ref> </div> <span style="color:#800;"></span> ---- ;注記 <!-- *原文の <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;">[[wikt:en:accommodatae|accommodātae]], [[wikt:en:Aduatuci|Aduatucī]], [[wikt:en:Aduatucos|Aduatucōs]], [[wikt:en:Aedui#Latin|Aeduī]], [[wikt:en:Alpis#Latin|Alpīs]], [[wikt:en:appropinquabat|appropinquābat]], [[wikt:en:appropinquare#Latin|appropinquāre]], [[wikt:en:appulso#Latin|appulsō]], [[wikt:en:auxili#Latin|auxilī]], [[wikt:en:cedentis|cēdentīs]], [[wikt:en:cohortis|cohortīs]], [[wikt:en:coicere|coicere]], [[wikt:en:coiecerunt|coiēcērunt]], [[wikt:en:coiecisse|coiēcisse]], [[wikt:en:collatis|collātīs]], [[wikt:en:collocabant|collocābant]], [[wikt:en:collocandis|collocandīs]], [[wikt:en:collocarat|collocārat]], [[wikt:en:collocare#Latin|collocāre]], [[wikt:en:collocaret|collocāret]], [[wikt:en:collocari|collocārī]], [[wikt:en:colloquium#Latin|colloquium]], complūrīs, [[wikt:en:conantis|cōnantīs]], [[wikt:en:consili|cōnsilī]], [[wikt:en:eis#Latin|eīs]], [[wikt:en:finis#Latin|fīnīs]], [[wikt:en:hostis#Latin|hostīs]], [[wikt:en:imperi#Latin|imperī]], [[wikt:en:irridere#Latin|irrīdēre]], [[wikt:en:montis|montīs]], [[wikt:en:navis#Latin|nāvīs]], [[wikt:en:negoti|negōtī]], nōn nūllōs, [[wikt:en:omnis#Latin|omnīs]], [[wikt:en:partis#Latin|partīs]], [[wikt:en:proeli|proelī]], proficīscentīs, [[wikt:en:resistentis|resistentīs]], [[wikt:en:subeuntis|subeuntīs]], trīs, [[wikt:en:vectigalis#Latin|vectīgālīs]] </span> などは、<br>それぞれ <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;">[[wikt:en:adcommodatae|adcommodātae]], [[wikt:de:Atuatuci|Atuatucī]], Atuatucōs, Haeduī, [[wikt:en:Alpes#Latin|Alpēs]], [[wikt:en:adpropinquabat|adpropinquābat]], [[wikt:en:adpropinquare|adpropinquāre]], [[wikt:en:adpulso|adpulsō]], [[wikt:en:auxilii|auxiliī]], [[wikt:en:cedentes#Latin|cēdentēs]], [[wikt:en:cohortes#Latin|cohortēs]], [[wikt:en:conicere|conicere]], [[wikt:en:coniecerunt|coniēcērunt]], [[wikt:en:coniecisse|coniēcisse]], [[wikt:en:conlatis|conlātīs]], [[wikt:en:conlocabant|conlocābant]], [[wikt:en:conlocandis|conlocandīs]], [[wikt:en:conlocarat|conlocārat]], [[wikt:en:conlocare|conlocāre]], [[wikt:en:conlocaret|conlocāret]], [[wikt:en:conlocari|conlocārī]], [[wikt:en:conloquium#Latin|conloquium]], [[wikt:en:complures#Latin|complūrēs]], [[wikt:en:conantes|cōnantēs]], [[wikt:en:consilii|cōnsiliī]], [[wikt:en:iis#Latin|iīs]], [[wikt:en:fines#Latin|fīnēs]], [[wikt:en:hostes#Latin|hostēs]], [[wikt:en:imperii#Latin|imperiī]], [[wikt:en:inridere|inrīdēre]], [[wikt:en:montes#Latin|montēs]], [[wikt:en:naves#Latin|nāvēs]], [[wikt:en:negotii|negōtiī]], [[wikt:en:nonnullos|nōnnūllōs]], [[wikt:en:omnes#Latin|omnēs]], [[wikt:en:partes#Latin|partēs]], [[wikt:en:proelii|proeliī]], [[wikt:en:proficiscentes|proficīscentēs]], [[wikt:en:resistentes#Latin|resistentēs]], [[wikt:en:subeuntes|subeuntēs]], [[wikt:en:tres#Latin|trēs]], [[wikt:en:vectigales|vectīgālēs]] </span> などとした。 --> <span style="font-family:Times New Roman;font-style:normal;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-style:oblique;font-size:15pt;"></span> <span style="color:#b00;"></span> <span style="color:#800;"></span> <span style="font-size:10pt;"></span> <span style="background-color:#ff0;"></span> == 注解 == === 1項 === <span style="font-family:Times New Roman;font-size:20pt;"></span> ;語釈 <span style="font-family:Times New Roman;font-size:15pt;background-color:#fff;"></span> <span style="font-family:Times New Roman;font-size:15pt;"></span> <span style="font-family:Times New Roman;font-size:15pt;"></span> <span style="background-color:#ccffcc;"></span> <!-- ;対訳 《　》　内は、訳者が説明のために補った語。<span style="font-family:Times New Roman;font-size:30pt;">{</span>　<span style="font-family:Times New Roman;font-size:30pt;">}</span>　内は関係文。 <span style="font-family:Times New Roman;font-size:15pt;"></span> --> == 訳文 == *<span style="background-color:#dff;">訳文は、[[ガリア戦記_第3巻#17節]]</span> == 脚注 == {{Reflist}} == 解説 == <!-- {| class="wikitable" style="text-align:center" |- style="height:23em;" | | |} --> == 関連項目 == *[[ガリア戦記]] **[[ガリア戦記/注解編]] ***[[ガリア戦記 第3巻/注解]] **[[ガリア戦記/用例集]] == 関連記事 == == 外部リンク == [[Category:ガリア戦記 第3巻|17節]] dnuyotvrsqn35629ps44afn92r22g8h