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.22 first-letter メディア 特別 トーク 利用者 利用者・トーク Wikibooks Wikibooks・トーク ファイル ファイル・トーク MediaWiki MediaWiki・トーク テンプレート テンプレート・トーク ヘルプ ヘルプ・トーク カテゴリ カテゴリ・トーク Transwiki Transwiki‐ノート TimedText TimedText talk モジュール モジュール・トーク Gadget Gadget talk Gadget definition Gadget definition talk 0 572 205999 205900 2022-07-29T18:55:35Z Kwawe 68789 /* 2022年度以降 */ wikitext text/x-wiki {{Pathnav|メインページ|小学校・中学校・高等学校の学習|frame=1}} ここでは高校の教科書を中心に収録しています。現行課程・新課程（令和４年度以降）になってからの改訂作業が大幅に遅れているため、[[高等学校の学習/旧課程|旧課程]]の教科書を参照せざるをえない教科も多くあります。あしからずご了承ください。また、改訂作業をお手伝いいただける方はご協力ください。 __TOC__ {{進捗状況}} == 高等学校の教科書目録一覧 == [[検定教科書/高等学校|高等学校の検定教科書一覧]]{{進捗|100%|2022-07-27}} ※リンク先は、2022年以降入学された現高校1年生で使う教科書です。 == 普通教育に関する各教科・科目と標準単位数 == === [[高等学校国語|国語]] === ==== 2021年度以前 ==== * [[高等学校国語総合|国語総合]] 4単位{{進捗|25%|2014-12-23}} * [[高等学校国語表現|国語表現]] 3単位 * [[高等学校現代文A|現代文A]] 2単位{{進捗|00%|2012-12-21}} * [[高等学校現代文B|現代文B]] 4単位 {{進捗|00%|2014-11-24}} * [[高等学校古典A|古典A]] 2単位 {{進捗|25%|2012-12-21}} * [[高等学校古典B|古典B]] 4単位 {{進捗|25%|2014-12-22}} ==== 2022年度以降 ==== * [[高等学校現代の国語|現代の国語]] * [[高等学校言語文化|言語文化]] * [[高等学校国語表現|国語表現]] * [[高等学校論理国語|論理国語]] * [[高等学校文学国語|文学国語]] * [[高等学校古典探究|古典探究]] '''関連項目''' * [[高等学校古文]] === [[高等学校地理歴史|地理歴史]] === ==== 2021年度以前 ==== * [[高等学校世界史A|世界史A]] 2単位 {{進捗|50%|2012-12-21}} * [[高等学校世界史B|世界史B]] 4単位 {{進捗|75%|2018-05-04}} * [[高等学校日本史A|日本史A]] 2単位{{進捗|00%|2018-07-31}} * [[高等学校日本史B|日本史B]] 4単位 {{進捗|50%|2018-06-06}} * [[高等学校地理A|地理A]] 2単位 * [[高等学校地理B|地理B]] 4単位 {{進捗|25%|2018-06-11}} ==== 2022年度以降 ==== * [[高等学校歴史総合|歴史総合]] * [[高等学校地理総合|地理総合]] * [[高等学校世界史探究|世界史探究]] * [[高等学校日本史探究|日本史探究]] * [[高等学校地理探究|地理探究]] 4単位 {{進捗|25%|2022-07-17}} ===[[高等学校公民|公民]]=== （現在、新課程に対応する公民の教科書は執筆途中です。当面の間は[[/旧課程|/旧課程]]の教科書で代用してください） ==== 2021年度以前 ==== * [[高等学校現代社会|現代社会]] 2単位 {{進捗|25%|2013-09-30}} * [[高等学校倫理|倫理]] 2単位 {{進捗|00%|2013-09-30}} * [[高等学校政治経済|政治経済]] 2単位 {{進捗|00%|2013-09-30}} ==== 2022年度以降 ==== * [[高等学校公共|公共]] {{進捗|25%|2022-07-30}} * [[高等学校倫理|倫理]] * [[高等学校政治経済|政治経済]] === [[高等学校数学|数学]] === （２０２１年入学生までの旧課程に対応する数学の教科書は[[高等学校数学]]を参照してください） * [[新課程高等学校数学I|数学I]] 3単位 * [[新課程高等学校数学II|数学II]] 4単位 * [[新課程高等学校数学III|数学III]] 3単位 * [[新課程高等学校数学A|数学A]] 2単位 * [[新課程高等学校数学B|数学B]] 2単位 * [[新課程高等学校数学C|数学C]] 2単位 === [[高等学校理科|理科]] === （現在、現行・新課程に対応する理科の教科書は執筆途中です。当面の間は[[/旧課程|/旧課程]]の教科書で代用してください。） * [[高等学校理科 科学と人間生活|科学と人間生活]] 2単位 * [[高等学校理科 物理基礎|物理基礎]] 2単位 {{進捗|00%|2013-09-30}} * [[高等学校理科 化学基礎|化学基礎]] 2単位 * [[高等学校 生物基礎|生物基礎]] 2単位 * [[高等学校理科 地学基礎|地学基礎]] 2単位 * [[高等学校 物理|物理]] 4単位 {{進捗|25%|2022-06-27}} * [[高等学校 化学|化学]] 4単位 {{進捗|25%|2022-6-2}} * [[高等学校 地学|地学]] 4単位 *[[高等学校 生物|生物]] 4単位 {{進捗|50%|2022-07-09}} * [[高等学校理科 理科課題研究|理科課題研究]] 1単位 === [[高等学校外国語|外国語]] === （現在日本語版ウィキブックスには現行課程に対応する外国語科の教科書はありません。当面の間は[[/旧課程|/旧課程]]の教科書で代用してください） * コミュニケーション英語Ⅰ 3単位 * コミュニケーション英語Ⅱ 4単位 * コミュニケーション英語Ⅲ 4単位 * コミュニケーション英語基礎 2単位 * 英語表現Ⅰ 2単位 * 英語表現Ⅱ 4単位 * 英語会話 2単位 * 英語以外の外国語に関する科目 '''関連項目''' * [[高校英語の文法]] === [[高等学校保健体育|保健体育]] === * [[高等学校保健体育体育|体育]] 7～8単位 * [[高等学校保健体育保健|保健]] 2単位 {{進捗|25%|2013-09-30}} === [[高等学校芸術|芸術]] === * [[高等学校音楽I|音楽I]] 2単位 * [[高等学校美術I|美術I]] 2単位 * [[高等学校工芸I|工芸I]] 2単位 * [[高等学校書道I|書道I]] 2単位 === [[高等学校家庭|家庭]] === * [[高等学校家庭基礎|家庭基礎]] 2単位 {{進捗|00%|2013-09-30}} * [[高等学校家庭総合|家庭総合]] 4単位 * 生活デザイン 4単位 === [[高等学校情報|情報]] === ==== 2021年度以前 ==== * [[高等学校情報/社会と情報|社会と情報]] 2単位 {{進捗|25%|2016-06-10}} * [[高等学校情報/情報の科学|情報の科学]] 2単位 {{進捗|25%|2016-06-10}} ==== 2022年度以降 ==== * [[高等学校情報I|情報I]] 2単位 * [[高等学校情報II|情報II]] 2単位 === [[総合的な学習の時間]] === 3~6単位(2単位まで減可) == 専門教育に関する各教科 == * [[高等学校農業]] {{進捗|00%|2013-09-30}} * [[高等学校工業]] {{進捗|25%|2013-09-23}} * [[高等学校商業]] {{進捗|00%|2013-09-30}} * [[高等学校水産]] {{進捗|00%|2013-09-30}} * [[高等学校家庭]] {{進捗|00%|2013-09-30}} * [[高等学校看護]] {{進捗|00%|2013-09-30}} * [[高等学校情報]] {{進捗|00%|2013-09-30}} * [[高等学校福祉]] {{進捗|00%|2013-09-30}} * [[高等学校理数]] {{進捗|00%|2013-09-30}} * [[高等学校体育]] {{進捗|00%|2013-09-30}} * [[高等学校音楽]] {{進捗|00%|2013-09-30}} * [[高等学校美術]] {{進捗|00%|2013-09-30}} * [[高等学校英語]] {{進捗|00%|2013-09-30}} == 特別活動 == * [[高等学校ホームルーム活動]] * [[高等学校生徒会活動・委員会活動]] * [[高等学校学校行事]] == 課外活動 == * [[高等学校部活動]] {{進捗|25%|2013-09-30}} * [[高等学校ボランティア活動]] == 関連項目 == * [[高校生活ガイド]] * [[大学受験ガイド]] {{進捗|25%|2013-09-30}} * [[学習方法#高等学校|学習方法]] [[Category:高等学校教育|*]] s2os7co5nu84rwzn44pnfkq8qs9bwh2 0 4250 206002 205984 2022-07-29T22:24:20Z Honooo 14373 /*テレビとディスプレイの焼き付き*/ wikitext text/x-wiki <div class="pathnavbox"> * {{Pathnav|ゲーム}} * {{Pathnav|工学|情報技術|プログラミング}} </div> == 概観 == このWiki参考書では、コンピュータを用いた[[w:ゲーム]]のプログラミングを扱います。つまり、いわゆる「テレビゲーム」や、[[w:コンピュータゲーム|コンピュータゲーム]]に関する記述についてです。 ここでは家庭用のパーソナルコンピュータで扱える範囲の事柄、それらのゲームソフトをつくるためのプログラミングについて議論します。必要に応じて家庭用ゲーム機の話題にも触れますが、あくまで派生的なものです。本書はプログラミングの教材であるので、大多数の読者が最初にプログラミングで触れるであろうパーソナルコンピュータでのプログラミングを、特にことわらないかぎりは想定しています。 用語に関して、コンピューターゲームの世界独自なものもあるでしょうから、適宜『[[ゲームプログラミング/コンピュータゲームの種類]]』などを参照してください。 == 本書の目的 == この教科書『ゲームプログラミング』の目的は、題名にもあるとおり、プログラミングによってゲームを作るための技術の参考資料を目的としています。 ゲームクリエイターやゲームデザイナー（絵描きではなくゲームの設計者のこと）のためではなく、プログラマーのための教科書です。 したがって本書では、ゲームとは関係の少ない一般IT企業での仕事のしかたについての記述もあれば、製造業系の組込ソフトなどに関する概要的な記述もあります。 なぜなら本書はゲームクリエイターではなく、たまたま何らかの理由でゲームを作っているプログラマーのための教科書だからです。たとえゲーム会社を退職しても、他の一般IT企業に転職してもプログラマーとして応用できることなども目指して本書は書かれています。 従って、紹介する話題が、かなりIT系、テクノロジー系の話題に片寄っています。本書で紹介するクリエイター論やデザイン論は、派生的なものにすぎません。 ;本書を扱う上での注意点 特にことわりのないかぎり、本書ではC言語でのプログラミングによってゲームを作りたい読書を念頭に説明しています。 だから、ゲームの生産効率性を無視してでも、本来ならRPGツクールのような開発ツールを使ったほうが早いシンプルなゲームの場合ですら、本書ではC言語または他のプログラミング言語での開発にこだわった方法を説明している場合もあります。 ;その他、本書について このページとそのサブページだけを見ていると本書は「ゲームクリエイトの教科書かな?」と捉えられるかもしれませんが、 しかしこのページとは別に本wikibooksには「[[プログラミング]]」というページがあり、そこではC言語やJavaなど代表的なプログラム言語のwiki教科書にリンクしています。ゲーム限定の話題ではないですが、プログラミングのコードについても、そちら『[[C言語]]』や『[[Java]]』やなどの教科書のほうが（実際に動作するコードの量が）充実しています。また、Visual C++ での画面出力については『[[Windows API]]』に入門的な説明があります。 本書『ゲームプログラミング』はそういったプログラミング教科書一覧の一部でもあります。C言語やWindows API の教科書では、これをどうやってゲームのプログラミングに応用すればいいか説明できないので（本wiki『[[C言語]]』はけっしてゲーム目的のページではないので）、ゲームの実際としてプログラミングの話題を切り離すために本書『ゲームプログラミング』は存在しています。 なので本書にゲームデザイン論やクリエイター論などの内容の充実は期待できません。 本書『ゲームプログラミング』は現状、プログラマー目的以外には対応できないかもしれません。もしプログラマー目的以外の無料のwiki教科書が欲しい方は、現状では、自分で本wikiに加筆するか、あるいは本書『ゲームプログラミング』とは別に新規Wiki執筆を検討していただきたい。 == ゲームを作りたいな、よし、ゲームを作ろう。でも… == ===しかし自分の本当の目的ってゲーム作り？=== 「ゲームを作りたい」と思ったのなら、まずはあまり細かい難しいことは考えず、実際に作り始めてみるのが一番いいと思います。もちろんプログラミングについてほとんど何も知らないのなら、ある程度の勉強は必要ですが、ある程度の知識があるのなら、プログラミングの技量や知識の充実を気にするよりは、実際にゲームの完成を目指してプログラムを書いてみるのが一番いいようですよ。その過程でプログラミングの学習や経験は積んでいけますしね。JavaScriptやPython、無料でプログラミングに取り組める環境も、今現在では充実しています。 しかし、ゲームをプレイするのが好きだからと言って、ゲームを作る、までが本当に自分が好きかどうか、試しに少し作ってみたら、少し考えてみるといいですね。 例えば読者の中には、「私はRPGがすき」という人も多いでしょう。 RPG が好きという事はおそらく、よくRPGの題材になる西洋ファンタジーのストーリーや世界も好きという場合が多いでしょう。そして一方で現実のコンピューターRPGで魅力的に提供される、イラストや音楽が好きという場合もあります。 実際のゲーム業界の人々も、ゲームを彩るイラストレーションや音楽がいかに重要な要素かを語っています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P85</ref>。 さて、ここで問題なのですが、「ゲームを作りたい」と貴方が思っていたとして、あなたが本当に作りたいのはゲームなのか？あるいは本当はイラストが描きたかったり、音楽を作りたいのではないか？ …というのは、ゲームというのは総合的な分野ですから、イラストや音楽はその要素として確実にありますが、それ以外、プログラミングやシナリオなど、様々な創作や創造が必要で、全ての作業量はかなり多いものになるでしょう。 そしてゲーム、コンピューターゲームにはゲーム独自の世界観があって、現実や小説や映画とは違う、独特の法則に支配された世界を作る必要があります。ある意味リアリティを持たない、リアリティから外れた世界です。だから、小説のようなリアリティにこだわるなら、ゲームは不向きかもしれません。 ゲーム作り始めの時点では、これらの判断は明確でなくても勉強目的でも構いませんが、しかその内「自分は本当にゲームを作りたいのか? Yes or no?」という疑問への答えが必要になるときがくるかもしれません。 試しにゲームを作ってみて、もし自分の本当の目的がゲームでないと分かったなら、それ以外の活動に移るのも、取る道の選択肢でしょう。 ;給料は安い 職業として、商売としてゲームを作る場合、ゲームプログラマーの給料は洋の東西を問わず、安い事が知られており、書籍などでも言及されています。たとえば『CAREER SKILLS　ソフトウェア開発者の完全キャリアガイド』（ジョン・ソンメズ 著）という欧米人のプログラマーの書いた本には、アメリカのゲーム業界ですらハードワークの割に賃金が低い事が記載されており、もし給料の高い仕事につきたいならウォールストリート（※米国の金融ウォール街のこと）のための仕事をするべきだと書籍中で指摘しています。 日本でも同様にゲーム業界の報酬が低いことは知られており、多くのゲーム会社の伝記漫画でも、よく語られています。 アニメーション業界と比べたら、ゲーム業界のほうが報酬が高いことは事実かもしれませんが、これは実は恐ろしいことに、アニメーション業界の報酬が異常に低いだけで、アニメーション業界よりはましだけど、結局は…というのが現状でしょう。 === 同人ゲーム以外の発表の場 === 2001年ごろの日本はネットを活用した同人ゲーム黎明期、フリーゲーム黎明期で、実験的な時代でもあり、多くのイラスト愛好、創作者や音楽創作者がゲーム制作に手を染めていたようです。この頃、まだイラスト投稿サイトや小説投稿サイトといったものは無かったか、あったとしても小規模でマイナーなものでした。 しかし2010年のあたりから各種の投稿サイトが普及したことにより状況は変わり、むしろ現在では、小説やイラストを発表したい人はそのジャンルの投稿サイトに直接アクセスしたほうが早く、そのためゲームを通して発表するのは人によっては廻り道かもしれません。 それをわかったうえで、それでもゲーム制作に身を投じるかを考えた上で、「よし、自分はゲーム制作をしよう」と思えるなら、ゲーム制作をするのが良いでしょう。 実際、今現在の作曲家やイラストレーターは、ゲームに関わったとしても、専門家として楽曲やイラストを提供するという立場に過ぎない場合もあり、自分自身が主体になってゲーム制作をする人は、プロアマ問わず少数派のように見えます。 同人ゲームの世界でも現在は（2021年頃に記述）、プログラマー系の作者が圧倒的に多い様です。 しかし、専門外の人だからこそ、メディアミックス的な意外な視点で新しいものが作れる可能性もあるかもしれません。コピーライター、作家の糸井重里が、マザー2の企画にたずさわった例もあります。しかし、あくまで「可能性」であり、成功はけっして保証されてはいないので、読者の自己責任でお願いします。 今現在のゲーム専門学校のカリキュラムはプログラミングが主体です。CGの授業は、週に2時間程の様。一方でゲームCG、或いは、一般CGに特化した学科もある様です。 あるWikibooks編集者Aは、もしイラストを描きたいなら、イラストの世界で描くのが安全、と考えています。ゲームプログラミングについては、プログラムを書ける人は絵コンテも描けそうだし、基本的にある程度の作図的なイラストを描ける人は多いだろうから、別にプログラミングに専念しろとは思っていません。 さて、読者がゲーム制作を職業として目指すのかどうかはともかく、とりあえず、ゲーム業界の状況を知っておくのが有用でしょう。 結局商業界の状況が権威をもってその分野を支配しているのがこの社会の基本なので、趣味でも職業でも、業界周辺のことを知っておくのは得ることが多いはずです。 文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか忘れる必要があることを説いています<ref>大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81</ref>。著者は、最初はグラフィッカーでしたが、しかしプランナーに転職したので、グラフィック関係の技能は仕事では「忘れて」しまった、という内容を述べています。ただし、比喩的に「忘れる」とは言っていますが、実際には忘却し無くなってしまったわけではなく、仕事では時間の都合により両立できないので、グラフィック関係の技能は例え話で「忘れた」、のであり、現実にはグラフィッカー時代に培った観察眼をプランナー時代の現在でも活用している、と、書籍中では述べられています。 このことは職業、あるいは技能とは一般的にそういうもの、と考えることができるでしょう。 {{コラム|漫画家大塚志郎のアドバイス| 同人ゲーム界では、ゲーム制作と、イラストまたは作曲などを一人で兼ねている作者も、ある程度は居ます。一方ネットの世界には様々な簡単に利用できるフリー素材もあるので、イラスト作画や作曲をしなくてもゲーム制作は可能ですよね。 一人でイラスト作画や作曲をしながらゲーム制作をするのはある意味マルチタレントだとも言えますが、現実にその創作をしている人たちは、かなり年長のこの分野の熟練者が多いようです。若い19歳ぐらいの頃に、それらマルチジャンルを両立するのは、一般にかなり困難なことだと思われます。 漫画家の大塚志郎は、漫画家を漫画創作の手本にするならデビュー時代を手本にするのが良い、と、漫画家向けの技法の教育漫画で語っています。 大塚は、漫画家の人生のうちで、これからデビューを目指している新人に近い境遇にあるのは、ヒット後の漫画家の生活状況ではなく、まだ無名･マイナーな時代の態度・生活だ、と描いています。成功後の熟練した漫画家より、若いデビュー直後の作家をお手本にするのがいいだろう、という主張ですよね。 さて、それでもデビュー時代から複数ジャンルの同人活動を均等に兼業する意思が硬いなら、それはそれでひとつの考え方ですが、上述のリスクを知っておく必要があるでしょう。 }} ===ゲーム業界は産業のエンジン役?=== かつてはゲーム産業が、日本のIT産業やデジタル家電産業の中心的・牽引（けんいん）役であった時代がありました。しかし、2010年以降、この考えは当てはまらなくなっています。 PlayStation2あたりまでの時代は、経済評論誌の未来予想でも、「もしかしたら今後、家庭用の据え置きゲーム機がパソコンの代替品として、家庭のリビング家電の標準品になるかもしれない」という予想があった。ゲーム産業がそのような牽引役として、経済界から期待されていました。ソニーが国産CPUをプレステ2〜3に搭載したり、WindwosのマイクロソフトがXBOXでゲーム機に参入したり、そういう時代です。 しかし2020年代の今は違います。結局、2020年代のゲーム機に使われてる技術や部品は、パソコン用の部品や技術の流用、ゲーム機のCPUも、今やインテルなどのパソコン用CPUをゲーム機でも使っています。 もはや現代は、ゲーム業界は、産業のエンジンではないようです。 ですから今現在、新しい技術に興味ある人は、ゲームにこだわらず、直接的にその技術を勉強し改良したほうが近道です。 たとえば、インターネット技術を使って何か新しい事をしたいなら、ゲームを作るよりもwebアプリやサーバーwebサービスを作るべきだし、目的のネットワーク用ソフトウェアをそのまま制作したほうが早いし確実です。 古い経済知識の先入観にとらわれず、無理にゲーム制作にこだわらないほうが、自分自身の技能やキャリアも開けていくでしょう。 2010年に出版された商学書籍『メイド・イン・ジャパンは終わるのか』には、「しかしながら、ファミリーコンピュータで世界に攻勢をかけ、その後圧倒的な強さを誇っていた日本の家庭用ゲーム産業も、90年代末からはその競争力にかげりがみえはじめた。日本の国内市場は伸び悩み、成長率は鈍化傾向にある（図表7-3）。」とあります<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.263</ref>。 その「図表7-3」の統計値によると、 :ファミコン発売の1993年には2268億円、 :スーファミ発売の1990年には2430億円、 :プレステ1発売の1994年には3882億円、 :1995年には急成長して4769億円、 :1997年には4795億円で、ほぼこの頃がピークであり、 :2000年には3768億円にまで低下（プレステ2の発売年）、 :2005年には3151億円まで低下（XBOXの発売年）、 である。（青島らが『レジャー白書』、『情報メディア白書』、『月刊トイジャーナル』、『CESAゲーム白書』などをもとに作成した図表の統計値です。） <!-- ところで前編集者Sさん，これって正確には何の数字，金額なの?それを後で書き足しておいてほしいんだけど…。あれかな？一年のこの国のゲーム産業の売上高？ --> また、2010年の時点の商学研究では、1997年を境に、ゲームソフト市場で競争する企業数が増加傾向から減少傾向に転じた<ref name="m289">青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.289</ref>、とも言われています。 書籍『メイド・イン・ジャパンは終わるのか』にも、引用文「家庭用ゲームは日本がその本格的立ち上げを主導し」<ref name="m91">青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.91 </ref>と書かれているぐらいで、1990年代は日本のインパクトが強かったようです。 なお、携帯電話の分野で、日本は国際的な地位を喪失したのに対し、デジタルカメラとゲームは「現代」（参考文献の著作時2010年ごろ）でも日本が主要な地位にある<ref name="m91" />。 {{コラム|ゲームが産業の牽引役だと語った人物| 1998年頃、アニメ評論家の岡田斗司夫が、未来予想の一貫として、「これからゲーム機が、（パソコンではなく）家電の中枢になるだろう」というような内容の未来予想をしていました。たしか、岡田の著書『東大オタキングゼミ』（自由国民社、1998年）で、このような未来予想が読めます。岡田の東大での講義を加筆修正してまとめた書籍なので、実際の講義はその数年前に行われていたのだろうと思います。 岡田の東大での講義は東大生のその後の進路、官僚や大企業のビジネスマン達に大きな影響を与えただろうし、若手新進評論家として、この国の政治・経済人達も、その言論を参考にしただろう。 実際、2008年（リーマンショックあたり）くらいまでの日本の家電業界の投資は、ソニーがゲーム機のCPUを作ったりと、岡田の予想を参考にしているような面もありました。 ですが実際の2001年以降の家電業界の結果は予想とは少し外れました。まず :* そもそも、冷蔵庫もエアコンも全然デジタル化（IoT化）されず、家電のほとんどが外部からのコンピュータ制御を必要としない状況。 :* 個々人が持ち歩いているデジタル家電は、携帯ゲーム機ではなくスマホになった。 :* パソコンは多くの家庭にいまだにインターネット用端末などとして残り続けている。 一方岡田は東大オタキングゼミで、98年当時の時点で任天堂が莫大な現金資産（たしか数千億円ほど）を持っていることに注目しています。 一般の大企業は、現金ではなく株券や不動産などの形で資産を蓄えています。しかし任天堂は、銀行口座の現金だけで数千億円という、非常に資金力の高い企業でした。今や日本を代表する世界的なゲーム大企業になっています。 また、日本だけでなくマイクロソフトのXBOXなど、実際に欧米の企業も昔はコンピュータゲームが産業の牽引役だと思って、先をこぞってゲーム機に参入していたわけでもある。岡田の未来予想は、決して根拠の無いものではなかったのです。 }} {{コラム|読書について| ゲーム業界と関連のない文献も、この教科書では出典として書かれていますが、これはこの頁の主要執筆者Sが、多量の市販本を読む以外に知的活動の方法を知らないことと、自分自身の文章の権威と信頼性を、著名人の威を借りて確立したいからでしょう。 ゲーム業界を志望するなら、ゲーム業界人の書いた本は少なくとも何冊かは読んでおくといいでしょう。 ネット上では、業界人ではないのにもっともらしく書かれた文章も多いですし、おそらく本Wikiの執筆者にも本格的なゲーム業界関係者は一人もいないでしょう。 業界人達のSNS発言ではなく、現代では書籍があるので、実際に書籍を手に入れて読むのがいいですね。書店で販売される書籍というのは、けっして著者だけの意見でなく、編集者や校正者、周辺の職業人達が査読をして、内容の信憑性を確認しています。 <!-- ニュース解説者の池上彰（いけがみ あきら）が、たしか2011年くらいのテレビ番組で言っていたことだと、編集者Sは言っている。 --> 何十冊も本を読むよりはプログラミングを書く実践のほうが重要でしょう。 『ゲームデザイン プロフェッショナル』著者であるFGOクリエイターも、ゲーム開発の書籍は読んでおくべきだと忠告しています<ref>『ゲームデザイン プロフェッショナル』、P234</ref>。また、ゲームデザイン本で学んだ知識は、ゲーム業界以外でも仕事術として活用できます。たとえば上司への業務報告の報告・連絡・相談（ホウ・レン・ソウ）などの考え方は、ゲーム業界でなくても活用できます<ref>『ゲームデザイン プロフェッショナル』、P332</ref>。 いっぽう、もし最新IT技術を勉強したいなら、読むべきは、ゲーム制作の解説本ではなく、そのIT技術の解説本など、そのものの書籍を読むほうが近道でしょう。 }} ===ゲームプログラミングは面白い。しかし、そんな楽な事ではない。=== ここでいう「プログラミング」とは、C言語などのプログラム言語による開発のことです。RPGツクールなど開発ツールによるゲーム制作の話は原則していません（本書『ゲームプログラミング』はあくまでプログラミングのための教科書です）。 さて、よくネットや、あるいは日常でも（C言語などによる）「ゲームプログラミングは簡単だよ。イラストやシナリオのほうが難しい。」、などという人がいますが、この発言の心は、「俺はプログラミングもイラストもシナリオも出来る凄い男だぜ。しかもプログラミングなんて簡単だし、むしろクリエイティブなイラストやシナリオの方に精力を費やす偉い奴だぜ^^」という、世間に良くいる武勇伝、自慢を語りたがる、インチキ親父が吹かしているだけなので、あまり真面目に取り合わないのが正解だと思います。 まず第一に、不当にプログラミングの価値を貶めている言説ですよね。 Visual C++またはVC# 、あるいは Direct Xなどを使ってプログラミングすることは、そんなに簡単なことではないでしょう。 ゲームプログラミングの入門書などには、初心者でも理解できそうな比較的簡単ないくつかのサンプルコードがありますが、それは初心者でも簡単に書けそうな技術だけを抜粋してるという、あくまで例外です。 RPGならたとえば、ドラクエ3のような戦争画面の行動順を処理するソート機能をつくるだけでも一苦労ですし、ほかにも道具・アイテムなどの自動整理をはじめとする標準機能を作るだけでも一苦労です。 決して上手い人のサンプルコードをコピーアンドペーストをして終わりという訳にはいかず（そもそも現状そのようなサンプルコードがネット上に無いですが）、もし仮にサンプルコードがネットに公開されていても、自作品に組み込む際にさらにそれをデバッグ（決してテストプレイの意味ではなく、実際にコード修正が必要になります）しなければならず、プログラミング言語の理解が必要です。 ゲームのプログラミングは決して楽ではないし、仮にもし楽だとしたら、じゃあゲーム会社のプログラマー職の人の仕事は何なんだ・・・という疑問につながりますよね（デマを言ってる人は、この疑問を脳内に都合よく無視しますが）。 ツクールやエディタのような制作ツールを使えば、C言語的なプログラミングは不要ですが、それはそのツクールなどのツールを開発している人達にプログラミングを肩代わりしてもらっているだけなので、決して「ゲームプログラミングが楽」、ではないでしょう。楽だというなら、じゃあツクール開発元の角川書店およびその発注先ソフトメーカーのプログラミングが楽だとでも言うのか・・・（デマを言ってる人はこの疑問を無視します）。 そもそもコンピューターゲームというのはプログラミングがなければ成立しないのですから、そのプログラミングの価値を貶めて平気な人は、コンピューターゲームにかかわる資格はないでしょう。 == ゲーム制作に関する留意点 == === IT的な留意点 === ====プログラミングなしでも同人ゲームを作れる==== 自分でゲームを作る際、必ずしも、C言語などプログラム言語で記述する必要はありません。 プログラミングをせずに、ほぼマウス操作と会話メッセージなどの文章のキーボード入力だけでゲーム開発をできるようにするソフトウェアが、有料または無料で発表されています。 たとえば、RPGを作りたいなら、日本で発表されているソフトでは、『[[w:RPGツクール]]』や『[[w:WOLF RPGエディター]]』などのように、RPG製作に特化された開発ソフトがあり、大幅に開発の手間を減らせます。なお、『RPGツクール』は有料製品です。『WOLF RPGエディター』は無料ソフトです。 アクションゲームを作りたいなら、『[[w:アクションゲームツクール]]』があります。これらツクール製品は有料製品です。（なお、かつて『[[w: 2D格闘ツクール2nd.]]』というのがありましたが、しかし現在ではサポート切れのため、今現在の市販の十字キーコントローラーが初期設定では動かない、一部のボタンしか使えないなど問題点があります。） また、ノベルゲームを作りたいなら、フリーソフトの『[[w:吉里吉里Z]]』などがあります。吉里吉里Zはソースコードが公開されており、オープンソースになっています。 :なお、とりあえず「ゲーム開発ツール」と呼びましたが、じつは呼び方は特に決まってはいません。「ゲーム制作ツール」と呼ぶ場合もあります。ゲーム開発ツールのことを「ゲームエンジン」と言う場合もありますが、開発ツール以外のゲーム用ランタイムのことも「ゲームエンジン」という場合があります。 :本Wikibooksでは、とりあえず、ツクールや吉里吉里シリーズやウディタ（WOLF RPGエディター）などのソフトの呼び方は、まとめて「ゲーム開発ツール」または「ゲーム開発ソフト」と呼ぶことにします。 C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合の選択肢になるでしょう。 既存のゲーム開発ツールの仕様に不満を感じる場合に、「じゃあ自分でプログラムして作ろう」となり、プログラミングが必要になるわけです。 なお、上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動きません。MacやLinuxで動作するゲームを作りたい場合は、別のソフトウエアを使う必要があります。 既存のゲーム開発ソフトを使わずにプログラムを組んでゲームを自作する場合、必ずしも既存のツールのような、ゲーム作品と開発ツールが分離された仕組みを再現する必要はありません。 一般的に初心者が、ゲーム開発ツールを作ることはほぼ不可能です。初心者は開発ツールを作ることは考えずに、まず1本、とりあえずゲーム自体を完成させてみましょう。開発ツールを自作したいのなら、まず先にゲーム1本を完成させたあとに、あとから開発ツールとゲーム作品の分離などに取り掛かるのが推奨です。 ==== 商業ゲームの開発言語 ==== 基本的に、現代の商業ゲームは、C言語で開発をする。 ただし、ファミコンの古いゲームは、アセンブラで開発されていた。ファミリーコンピューターからスーパーファミコンに至るまで、OSは搭載されていない<ref name="m289" />。 ではいつからC言語がゲーム開発に使われるようになったかというと、商学の学説では、プレイステーション（※ おそらくプレステ1？）の頃からだろう、と考えられている<ref name="m289" />。ただしこの時代でも、処理速度の高速化のためにアセンブラにアクセスする開発チームも少なくなかった<ref name="m289" />。 また、プレイステーションのOSは独自仕様である<ref name="m289" />。 カプコンなど一部の企業は、OSによる開発ではなく、移植性を高めるために自社製の内製フレームワークを用いて開発する。カプコンの場合、2010年頃は「MTフレームワーク」という自社製フレームワークを用いて開発を行っていた<ref name="m289" />。 {{コラム|ゲーム用のメーカー独自プログラミング言語について| ゲーム開発ソフトには、ゲーム開発用の独自のプログラミング言語を持っている場合があります。このような機能の実現方法は、原理的には、ファイル入出力の関数を使い、テキストファイルの文字列を読み取って、文ごとにプログラム動作を設定・実行している、と、考えられます。インタプリタは、このような方法で作られています。 ゲーム製作ソフトでの独自のプログラミング言語はたいてい、コンパイル作業を必要としないので、おそらくインタプリタ方式でしょう。 基本的にWindowsの場合、実行ファイルに変換するには、Visual Studio というマイクロソフト社の配布している開発環境が必要です。 Visual Studio が開発環境を提供していない独自言語は、たいてい、インタプリタ方式となると思われます。 コンパイラ方式に比べて、インタプリタは処理速度が不利なので、適用できるジャンルや用途が限られます。たとえば3Dアクションゲームには、インタプリタ方式は不向きでしょう。 これらの独自言語を使うにしても、自分自身で独自言語を作りたいと思うとしても、この教本ではまず、既存のプログラミング言語を使ってゲーム制作を開始することを推奨します。 }} ====ゲームのプログラム言語の歴史==== ゲームを書くために利用される言語は多岐にわたっています。歴史的にはゲーム業界でも、[[C言語]]や、特に計算機のスピードが重要になる場面では[[w:アセンブリ言語|アセンブラ]]を利用してプログラミングを行うことが普通に行われていました。<!-- (文献)→-->そのため、ゲームプログラミングは通常のプログラミングと違った技能が必要であるように思われていました。 現在では計算機がある程度速くなったことや、ゲームプログラムの開発を複数人で行うことでテクニカルなプログラミングが避けられるようになったことにより、ゲームプログラミングは他の一般のプログラミングと同じような課題だと見なされています。 しかし、特にアクションゲームなどのリアルタイムでの画面書き換えが必要なゲームで、プログラムのスピードが重視されることは変わっていません。また、コンピュータの性能があがるにつれ、それらの性能を全て引き出すように表現手段が変化してきたため（[[w:3次元コンピュータグラフィックス|3D]]、[[w:ポリゴン|ポリゴン]]などを参照）、状況によっては複雑で特殊なプログラミングが必要になることもあります。 ===== 初心者が使えるプログラミング言語 ===== ゲーム開発において、一般にゲームショップなどで流通している商業ゲーム作品において、現在よく利用されているプログラミング言語として、[[C言語]]、[[CPlusPlus|C++]]、[[Java]]があげられます。 Windowsの3DエンジンのDirectXは、主にC++を想定しています。なので負荷の高いアクションゲームを作りたい場合、Visual C++での開発が安全でしょう。 しかし、ネット上のフリーゲームでは、C++以外の言語が使われることも、よくあります。 さいきんゲームエンジンとして有名なUnityは、言語としてはC#の文法を採用しています。 [[w:携帯電話|携帯電話]]向けのゲームでは[[Java]]が利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります（[[w:iアプリ|iアプリ]]、[[w:EZアプリ (Java)|EZアプリ]]、[[w:S!アプリ|S!アプリ]]などを参照）。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。 市販の書籍では、Pythonによるゲーム開発を紹介した出版物もあります。ただし Python は原理的にインタプリタ方式であるために処理速度がC++に劣り、アクションゲームなど負荷の高いゲームを作る事を目指している場合は、将来的にはPythonからC++への装備変更が必要になるかもしれません。 ===== ゲームに適さない（だろう）言語 ===== ;Flash関係 例えば、かつて Adobe の Flash が、ブラウザで動かせるゲームを作る際に、よく使われていました。このようなwebブラウザ上で動くゲームのことを一般に、「ブラウザゲーム」と言います。ただし、現在ではFlashは廃止の方向です、すでにほぼ廃止されているといっていいでしょう。また、現状では、ローカルPC環境でのゲームをJavaScriptで作るのは、アマチュア段階では困難です。JavaScriptのアマチュアゲームと言う事例を聞きません。 ;JavaScript なお、JavaScript はクロスプラットフォームですが、しかし、セキュリティ上の理由などから、いくつかの機能（たとえばファイル入出力）がwebブラウザ上では使えないようになっており、そのため、JavaScript だけでゲームを作るのは、初歩的なゲームを除くと、かなり困難です。（おそらく、オンラインゲームでは、サーバー側でPHPやサーバサイドJavaScriptなどの別プログラムが走っていると思われます。） セーブ機能の必要なゲームを作る場合は、JavaScriptでの開発は選択肢にない（セーブの実装には、JavaScript国際規格にはない非標準仕様を使いこなす必要があり、かなりの技術力を要するでしょう）。 =====ブラウザゲームの初歩的な原理===== 商品として流通するようなゲームや、高度な機能を持つブラウザゲームを作ることはとても難しく、このページでは手に負えません。そこで、このページでは、初心者が練習用につくるゲームを例に記述します。 webブラウザだけで動くのがブラウザゲームです。ブラウザゲームを作るのに使う言語の第一選択肢はJavaScriptです。サーバー側の処理が必要ならPHP,Python,Perl,Javaなどの言語の出番でしょう。 「ネットワークゲーム」は「ブラウザゲーム」とは意味が違います。 「ブラウザゲーム」は、パソコンにwebブラウザさえあれば、ネットワークに接続していなくてもゲームプレイできて、最後、クリアまでプレイできる作品もあります。 しかしネットゲームは、ネットワークに接続しないと、ゲームを開始することさえ不可能です。つまり、サーバの提供するゲームが「ネットワークゲーム」「ネトゲ」です。 もしPHPやPerlなどでゲームを作る場合、普通はネットゲームになる筈なので、作者がサーバを構築して提供する必要がありますし、プレイヤーにはゲーム中にサーバに接続する環境が必要になります。提供者は、サーバを用意したり、保守管理する必要がありますよね。サーバーがダウンしてしまうと、プレイヤーがゲームをできなくなります。 「PHP ゲーム」などの単語でネット検索したり、あるいは書店でプログラム言語の書籍や解説サイトを見ると、ときどきPHP・Perlなどの言語でゲーム開発しているものもありますが、一般的なダウンロード型のゲームとは違う筈なので、気をつけてください。 {{コラム|ソケット通信、ほか| コンピュータプログラムからインターネットに通信するには、いくつかの方法がある。 C言語の場合はOSの提供するソケット通信といわれる機能を使う方法、 JavaScriptにあるHTTP通信の機能を使う方法、 などがあるだろう。 ただし、JavaScriptでゲームを制作するのは、セキュリティ上の制約などからセーブロードが標準的方法では困難など、とても制作が難しい。 よって本セクションでは、C言語にソケット通信を組み込むことの概要を説明する。 ゲーム制作初心者がソケット通信までする必要はないが、将来的には知る必要があるかもしれない。 本wikiではWindowsの場合については 教科書『[[WinSock]]』、 macやLinux / Unix や BSD の場合は 教科書『[[Unixソケットプログラミング]]』 で説明している。 Windowsとそれ以外のOSとで、ソケット通信の仕様が微妙に異なる。 ソケット通信では文字コードの問題がある。手元のパソコンの文字コード設定は、通信相手方の端末には反映されない。 Windowsの日本語版では、伝統的に Shift-JIS といわれる文字コードが使われてきたが、海外のWindows端末は日本の文字コードにあわせてくれないし、macやLinuxやBSDも同様に日本には合わせてくれない。 簡単な対処法として、ゲーム中では日本語を送受信しない、つまり半角の英数字と記号だけを送受信する、という道はある。 会員登録などのためにどうしても氏名や住所などの日本語を使う必要がある場合、PHP・Pythonなどサーバ言語に対応した「フレームワーク」があり、そのフレームワークが最初から日本語に対応、もしくは設定を少しいじるだけで日本語対応するので、それを利用すれば効率的かもしれない。 ゲームとは別途、サーバー側にフレームワークをインストールして、会員登録時にサーバー側でそれを使うようにすればいいだろう。 しかしゲーム内では日本語の扱いは非常に難しい、限定されるという事になるだろう。 C言語のプログラムにサーバサイドの言語・システムを組み込むのは難しいから、ネットゲームではどこかでソケット通信に頼ることになるだろう。 市販の本を探しても、そもそもソケット通信の書籍自体がめったに見当たらないし（ほんの少しだけ出版されている）、もし見つけても全く文字コードの問題の解決方法は紹介されていない（2021年現在）。 }} ====プラットフォ－ム==== ;ライセンス料 一般に、プレイステーションや任天堂のゲームを開発するには、専用の機材が必要であり、そのため、ソニーや任天堂とライセンス契約しなければいけない<ref>『ゲームプランとデザインの教科書』、P.107 </ref>。 その契約に際して、ライセンス費用または料金と呼ばれるものを、ゲーム機開発会社の任天堂、ソニーに支払う必要があります。 現在でもソニーや任天堂のゲーム機用のソフト開発・販売には、ライセンス料が必要です。少なくともPS4やニンテンドースイッチのパッケージソフト開発には、「ライセンス費」が必要<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.120</ref>。 なお、書籍『ゲームプランナーの新しい教科書』によると任天堂やソニーのようにゲーム機を作っている会社のことをハードメーカーと言います。つまり、ゲーム機のハードメーカーにライセンス料を支払うという仕組みになっています<ref>『ゲームプランナーの新しい教科書』、P20</ref>。 また、スマートフォン向けアプリは、プラットフォーム使用料が掛かります。 書籍『ゲームプランとデザインの教科書』によると AppleStore, GooglePlayともに売上げの30%とのこと<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.121</ref>。その他のプラットフォームも、大体同じとのことです（参考文献の著作の時点では）。 Google やAppleのようにプラットフォームを提供している企業のことをプラットフォーマーと言います<ref name="gp244">吉冨賢介『ゲームプランナー入門』、P244</ref>。 昔からゲーム機のライセンス料は有料で高額であり、ソニーや任天堂の収益源のひとつになっている<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.267 </ref>。一方、パソコンゲームにはライセンス料が無いのが普通です<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.283 </ref>。 なお、ハードメーカーでなければプラットフォーマーでもないゲーム会社のうち、製造から販売までを手がける会社のことをパブリッシャーといい、たとえばカプコンやコナミやセガやスクウェア・エニックスやバンダイナムコなどがパブリッシャーです<ref name="gp244" />。 実は、必ずしもパブリッシャーが開発を手がけるとは限らず、スマホ向けアプリなどではディベロッパーといわれる開発専門の会社に委託している場合もあります<ref>吉冨賢介『ゲームプランナー入門』、P245</ref>。 ;ポリコレ規制 Apple社のAppStore向けのスマートフォンアプリでは、アップロード後に、公開前にAppleによる審査があり<ref name="g139">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.139</ref>。、審査は欧米基準です。 GooglePlayは、公開前の審査はないが公開開始後に海外基準で審査されるので、それに違反していると配信停止になります<ref name="g139" />。 海外プラットフォームで販売・配布したい場合、「ポリティカル・コレクトネス」（政治的な正しさ）といわれる、海外の公序良俗の基準に配慮する必要があります<ref>『ゲーム作りの発想法と企画書のつくりかた』、P.235</ref>。 欧米の判断基準が、アジア諸国やアフリカの生活習俗に合致しない場合も多いのですが、欧米のIT大企業はその欧米基準での規制が政治的に正しいと考えているでしょう。「日本では、少し考え方が違う」と言っても、通用せず規制される場合も多い。 ゲームだけでなくテレビアニメでも、漫画ワンピースの海外アニメ版では、主人公側の若者がタバコを吸っているシーンをアメ玉に作画を変えられたり、ドラゴンボールに出てくるミスターポポという肌の真っ黒なキャラクターの肌を青く書き換えたり、色々な例があります。 ポリコレとは関係ない事例ですが、TVアニメーションのポケットモンスターで主人公のサトシ達がお握りを食べているシーンで、アメリカ版ではドーナツになっていたことがあります。これは、国による食文化の違いを示していますよね。 ===プロトタイプ=== ゲームでは、曲や絵が良くても、ゲームとしては今ひとつ面白くない、という事は起こり得ますよね。 ですからむしろ、商業的なゲーム制作では、イラストは簡略なものを使ったうえで、プログラム中心の試作品（プロトタイプ）をいくつか作り、その中でゲームとしての面白さがあるものを、取捨選択したうえで商品化を考え、その後イラストや楽曲を詰めて完成度を高めていく、と、いう制作過程を取るようです。 書籍『ゲームプランナー入門』（吉冨賢介 著）によると、商業ゲーム界では、企画書に書かれたゲームが本当に面白いかどうか確認するために、「プロトタイプ」が作られます。プロトタイプの段階では、プログラマーと、企画の意図を考慮するためプランナーも関わります。<ref name="gp17">吉冨賢介『ゲームプランナー入門』、P17</ref> イラストレーターは、プロトタイプの前段階あたりでイメージイラストを提供し、スタッフ間の共有イメージを作ります<ref name="gp18">吉冨賢介『ゲームプランナー入門』、P18</ref>。そしてプロトタイプ進行中は、グラフィック案の提案をしていきます<ref name="gcw56">蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P56</ref>。サウンドも同様、プロトタイプでは、曲調を固めていく段階です<ref name="gcw56" />。 :※時々あるトラブルとして、マイナーな同人ゲームや零細メーカーのゲームで、背景イラストや脇役キャラクターなど目立たない部分で他社のイラストが使われていることがあるようです。おそらく試作用に流用したイラストが、そのまま製品に混入したのでしょう。こういうトラブルがあるので、他社イラストの使用は試作であっても避けるべきです。 ;実装検証 プログラマーは、そのゲームでコアになるプログラムやシステムやミドルウェアについて、プロトタイプ段階で実装検証を済ませておく必要があります。プロトタイプより前の原案の段階では、利用するミドルウェアの洗い出しをして、出来る範囲での基礎実験をしておきます<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P54</ref>。 ミドルウェアによっては使用料が発生するので、その点を事前に調べておく<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P55</ref>。 プロトタイプのうち、張りぼての例えば画面だけの物等を、「モックアップ」といいます。一方である程度遊べる状態まで作っているものを、「プレアブル」といいます<ref>STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日初版第2刷、P251の図</ref>。 ゲームデザイン本ではよく「プロトタイプ」という表現が用いられるので、本ページではこの言葉を使うことにします。 {{コラム|商標権等| 知的財産権には著作権・商標権・意匠権などがありますが、商標権は特に強い権利であり、気を配る必要があります。 意匠権とは、建物や工業製品の外観に関する権利なので、ゲーム制作ではあまり気にする必要はないようです<ref name="gpd135">川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.135</ref>。 「特許権・実用新案権」と「商標権」は、事業者によって国に登録されている権利で、かなり強力な権利なので、気をつける必要があります。 特許権や実用新案権とは、大まかに言えば、技術的な発明に関する権利です。商標が登録されているかどうかは、特許庁の『特許情報プラットフォーム』というwebサイト<ref name="gpd134">川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.134</ref>で確認できます。 商標をトリッキーな意図で登録する人も多く、自社でビジネス展開をする気がなかったり、他社の商品などでまだ登録されていない物を申請したり、そういうやや不正な登録申請でも認可されてしまう場合も多いです。 また、商標は業種のジャンルごとに分かれているので、たとえば携帯電話のジャンルが新たに追加された時代に、過去のゲームの商標を登録した人がいました。そのため携帯ゲームを出せなかったり、商標を買い戻したり、取り戻すための裁判をするのに時間とお金がかかってしまったり、様々な問題が発生します。<ref name="gpd134" /> 著作権は、登録の必要がなく、著作をした時点で発生する権利です。 『ゲームプランとデザインの教科書』によると、こういう事柄にまだ慣れていない人によくあることなのですが、他人の個人サイトやSNSで公開されていた絵や曲などを、許可なく勝手に使う事例があるようです<ref name="gpd135" />。 二次利用を許可されてない著作物は素材として使えません。 そして見落としがちなのが、フォントの著作権です<ref name="gpd135" />。フォントにも著作権があります。 フリー素材と書かれていても、商用販売が禁止されている配布形態のものもありますので、気をつけましょう。 }} {{コラム|アイデアの権利。アイデアとは盗まれるのか、盗むのか?| 商業ゲーム作家たちの、2022/1時点でのSNS発言によると、業界全体でみられることですが、会社外部の人がアイデアを一方的に投稿してきて、会社で作った作品にそのアイデアと類似点があったら、アイデア使用料を要求してくる、そのような問題に悩まされているようです。 そこでゲーム会社側では原則、 :送られてきたハガキやメールは、まずクリエイター以外の事務系の人間が読む。 :もしハガキなどにアイデアがあった場合、そのハガキを処分。 などの方策を取ると言われています。 また、偶然や何らかの理由でアイデアが一致してしまった場合に備えてのリスク回避として、事前に会社のウェブサイトなどで「弊社にアイデアが送られてきた場合、そのアイデアは弊社のものになります」のような宣言をしている会社も多くあると言われています。<!-- （以上、作家のSNS発言やそれを紹介したサイトの取材などのまとめ.）←出典を消すなってS氏はやたら云うんだけど，そんな重要な事かね?もちろん全くなくて，いい加減な事書いていいと言ってるわけではないけど… --> ここで前編集者は娯楽産業の世界には厄介な消費者がいると言及しているけど、この前編集者自身がこのWikibooks で異常なまでに厄介な参加者なんだが、そろそろ人のふり見て自分を返り見るべきだと思うな。 法学的には、著作権法はアイデアを保護しません（『アイデア・表現の二分論』と言います）。 そして前編集者はアイデアに関して権利をどうこう言う人間を無知だと書いているけど、自分は至上の賢人だと思ってるようだね。 そしてこの人物は他者を愚弄する時は必ず自分の意見ではなく、権威ある人がそう書いたから、出典だからと宣う。 出典は岡田斗司夫氏の著作『東大オタク学講座』や『マジメな話』だそうだ。 まあ岡田氏ならかなり過激なことを書くのは事実だろうが，この前編集者S はその悪徳をさらに10倍に高めてこのWikibooks に記述する地獄のように厄介で無知で馬鹿な人間だ。 }} 任天堂『ゼルダの伝説 ブレス オブ ザ ワイルド』は、プロトタイプの段階ではイラストや音楽を組み込まずに（イラストは、代わりに大きなドットの塊などで代用する）作られている事がゲーム業界見本市イベント CEDEC 2017 で公開されています<ref>https://game.watch.impress.co.jp/docs/news/1078888.html 2020年11月25日に閲覧して確認</ref>。 プロトタイプの段階では、画像や音楽は発注せず、骨組み的なプログラムだけで、そのゲームのアイデアが「はたして本当に面白いか？」を、実際に社内の関係者にプレイさせてみて確認します。 因みにプロトタイプに関しては『[[高等学校情報/その他の技術的な話題#プロトタイプ開発]]』の記述も参考になる。 ここでいう「プロトタイプ」（試作品）とは、コンピュータプログラムのゲームとして動作するのが前提です。映画製作でいう絵コンテ試写のように、ゲームの試作では、なるべく早期に第三者が試作ゲームを遊べるように作っていく必要があります。 プロトタイプという言葉を使用すること自体が妥当かどうか。まず、書籍『ゲームプランとデザインの教科書』で使われている<ref name="gpd350">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.350</ref>。 ニコニコ動画の経営者、川上量生が使っています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.38</ref>。川上は角川書店も買収したので、おそらくそこ（カドカワ・RPGツクール販売元）でも使っているでしょう。 ゲームのプロトタイプの基本姿勢は、「汚く作って、やりなおす」です<ref name="gpd350" />。もちろん最低限のプログラムの知識、勉強は必要ですが、あまり知識収集や理解充実を気にするより、実際に作ってみることを優先したほうがいいようです。チーム制作をしている場合はプロタイプは赤ん坊であり、そのチームで育てていこう、我々の子供だという意識で接しているようです<ref name="gpd350" />。 勉強に関しては、汚くてもいいからまず工夫して作ってみると、何を勉強すればいいかが見えてきます。 英語では「quick and dirty prototype」という言葉があります<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.349</ref>。 書籍『ゲーム作りの発想法と企画書のつくりかた』によると、シナリオライター志望者が企画書やシナリオ案をメーカーに送りつけても、あまり効果的ではないようです。 それよりゲーム形式でシナリオを書いてしまうのがいいようで、「CHR:ヒロインA(私服)、表示」のような文章を織り交ぜて構成していくのが推奨<ref>『ゲーム作りの発想法と企画書のつくりかた、P.140</ref>。 参考文献のその章では、シナリオライター志望者に向けて語られていますが、プログラマーを目指すならどうすればいいでしょうかね。 プログラマー志望なら、サンプルゲーム、サンプルプログラムを作ってしまうのがいいかもしれません。 1990年代、週刊少年マガジンに不定期掲載していた読みきり漫画『ゲームクリエイター列伝』では、カプコン社のゲーム『バイオハザード』を扱った『バイオハザードを創った男達』の際、制作過程でゲームデザイナーが大幅な作り直しを判断して進行させた、という描写があります。（ただしWikiboooks一編集者の記憶、詳細はあいまい）。 のちの、ゲーム評論家の阿部広樹の評によると、むしろそれは劇的な大きな決断ではなく、ゲームデザイナーの日常の普通の仕事ではないか、と語られています。 どんな肩書の人間だろうと、すでに決まって進行していた方針をひっくり返すのは、かなりのストレスのある判断で指摘になりますが、一般に漫画や映画、あるいはNHKの仕事に関するドキュメンタリーでもそうですが、職業や職業者の物語では、過剰に対象を美化し、劇的な演出によって関係者を称賛し、英雄視する傾向があるように思います。 {{コラム|アイデアはアイデアで価値がある。でも、せっかくなら、それを試作して、形にしてみよう。| ゲーム業界人広井王子は書籍のインタビューで、自分の社長としての人材評価は「0点」から始まる「加点法」だと語っていたようです。 『ゲームデザイン プロフェッショナル』著者も、文脈は違いますが「加点方式で物事を考える」と述べています<ref>『ゲームデザイン プロフェッショナル』、P224</ref>。 正直インチキなゲーム業界人の点数勘定などには全く興味ないが、そんな話とは全く別に、ゲーム制作の上で、実際に動く簡単なプロトタイプを作ってみることは間違いなく有意義な事でしょう。 アイデアはアイデアとして、思考や思想の展開としてありますが、それを具体的な形にしてみることは非常に楽しくエキサイティングで、意味ある活動ですよね。 }} 仕様書や設定資料を超えて、誰もが遊べる試作品は、意味のある企画行為でしょう。前編集者は、時間軸・動きの制作意図の明確化、という言葉を使っています。もちろん短くまとめること自体もなかなか難しいのですが、工夫を凝らして、ゲームプログラムを完成させることが重要な経験であり、思考の具体化でもあると思います。 ===アルファ版=== アルファ版はプロトタイプとは違うもので、その後段階で、ゲームの全体像が分かる一部分を、商品に準じた形で作ることです<ref name="gp17" />。 アルファ版でもそのゲームが本当に面白いかどうか検証がなされます。サウンドやビジュアルは商品に近いほぼ完成化された形で取り込みます。 アルファ版の使用の結果、プロジェクト中止の決定がなされる場合もあります<ref name="gp18" />。 ベータ版とは、会社によって意味が多少違いますが（たとえば『ゲームデザインプロフェッショナル』と『ゲームプランナ－入門』とでも微妙に違う）、おおむね、とりあえずのゲーム、最初からエンディングまでのほぼ完成状態をひととおり遊べる制作物です<ref>『ゲームデザインプロフェッショナル』、P170</ref>。 細かいバグ修正はこれらの段階では後回しにします。 基本的に :プロトタイプ→アルファ版→ベータ版→調整→デバッグ の流れですね。 ===プロトタイプ制作に必要な予備知識=== ====数学は後回し==== ゲーム制作の作り始めにおいて、必要な数学や物理の予備知識は、それほど多くありません。 文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、数学や物理の習熟に拘って、それに多くの時間と精力を費やして勉強するよりは、3Dの勉強などで必要を感じたら、そのつど、その分野の数学や物理を学ぶのが効率的だと述べており、また可能なら実際にプログラミングでその理論を試してみると具体的に理解をしやすいと述べています<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P88</ref>。 ====C言語の予備知識は入門書1冊+αで十分==== C言語を使ったゲームは、予備知識はそれほど多くないので、あまり難しいことは考えず、まず実際にプログラムを書いて作ってしまう事優先にするのが正解なようです。 市販のC言語入門書で、配列や関数などの一般的な機能を一通り習得したら、あとはVisual C++ で映像出力とキーボ－ド入力のみを、1～2週間ほど勉強、そしてVisual Studioを起動してゲームを作り始める。 うまくいけば数か月以内に、パソコン用の非ネット通信のゲームを作ることができるでしょう。 ただ、ゲームプログラミングを試みる人は、必ずしもゲーム制作のみが絶対的な唯一の目標ではない可能性もあるので、それぞれの立場に応じて、座学を取り入れてみるのもいいと思います。 == 作業リストを作る == ===作業リストの制作開始の方法=== さて、ゲームを作る時は、アイデアを頭の中だけに置いておくのではなく、文章に書きだしてみましょう。 そして、壮大な長大なアイデアではなく、1週間～1ヶ月ていどで成果の確認できそうなアイデアだけを書いてみましょう。 次にそのアイデアを、実際に動作するプログラム、ソフトウェア（つまりプロトタイプ）にするために、具体的などんな機能を持ったプログラム（簡単なものでよい）を制作しなければいけないか、自分のやるべきことのリストを、箇条書きで作ります。<ref>https://www.youtube.com/watch?v=J5FCZG7dfEY 2020年3月17日に閲覧</ref> IT界ではこういうリストを「ToDoリスト」（読み: トゥードゥーリスト）とか「タスクリスト」といいます。このページではむしろ日本語で、「作業リスト」と呼んでみましょう。 さて、このリストを作るときは、作業項目は具体的かつ単純な目標に分割します。ですから例えば RPG の戦闘システムを作るときは、 *「戦闘システムを作る。」 と、あいまいに総体的に書くのではなく、具体的に、 *戦闘画面のメッセージ表示欄および標準メッセージを作る。 *「戦う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは後回し。） *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 という風に、作業項目を細かく分割していきます。 こうすることで、作業がひとつずつ比較的に簡単な要素に分解されていくので、楽になります。また、バージョン管理ソフトを使って管理している場合も、上記のような作業リストの分解をしておけば、各バージョンの概要を書く際にも作業リストの項目が転用できるので、一石二鳥です。 予定日は書かないほうがいいように思われます。スケジュールを管理したい場合は、別にファイルを作るといいですね。 そして書き出した項目を優先順位で並べたら、最初の作業リストは完成です。 ===作業リストの更新=== プログラミングする前に作業リストを眺めて、そして上の項目から実際に作業を開始しましょう。 そして一つの項目を完成させましょう。 そして作業項目がひとつ終わったら、「【完了！】」等、そういう情報を、項目の前または後ろにつけます。備忘のための記録ですね。 たとえば、 *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 こうします。 以前の記述を残したまま、その作業が終了したことを示しておくわけですね。 また、もし追加の作業が必要になったら、たとえばダメージ計算システムを作るために、ランダム計算が必要になって、自分がそのプログラム言語でのランダム計算に詳しくないなら、たとえば *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 ::※3行目に追加されています。 と、必要に応じて項目を追加します。 さて、これから行う作業を検索しやすくするため、たとえば '''やることリスト''' *Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 '''完了した作業''' *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） の様に完了した項目を後回しにしたり、或いは *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *（現在→） Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 のように、（現在→）、を追加するのも良いでしょう。 つまり作業の記述をそのままに、どこまで進展しているかが分かる等に書き足していくわけですね。 ==プロトタイプ制作における創作面の検討事項== ===ゲーム性=== 「ゲーム性」という概念があって、これがあるからこそゲームは面白く、魅力的だと考えられています。 プレイステーション開発元のソニーもこれを重視していますし、一般的に多くのゲーム愛好者、関係者たちもその考えに同意するでしょう。 ではゲーム性とは何か? ゲームのジャンルにもよりますが、「駆け引き」や「戦術」、これが「ゲーム性」だとよく言われます。 『ゲームプランとデザインの教科書』によると、ゲーム性とは、シューティングやアクションでは「対戦の駆け引き」、RPGでは「戦闘と物語の介入」、シミュレーションゲームなら「戦略性」だそうです<ref>『ゲームプランとデザインの教科書』、P152</ref>。 ただし上述の書籍によると、1990年代は今よりもゲーム性とシステムが重視されていたとの説明があるので、裏を返せば2010年以降の現代では、ゲーム業界ではゲーム性の重視の比率は1990年代よりも減っているかもしれません<ref>『ゲームプランとデザインの教科書』、P302</ref>。 『ゲームプランナー入門』（吉冨賢介 著）では、ゲーム性とは「課題や挑戦の仕組み」であると結論づけています<ref>吉冨賢介『ゲームプランナー入門』、P36</ref>。そして、この達成感こそが「ゲームならではの面白さ」だと述べています。 ;アクションパズルゲーム「I.Q」 メディアクリエイターの佐藤 雅彦氏（「だんご3兄弟」や「ピタゴラスイッチ」等を手掛けている）が、初めてかかわるコンピュータゲームで、ソニー・コンピュータ・エンターテインメントとの共同企画で、のちに「I.Q」（1997年にシリーズ第一弾を発売）と呼ばれるシリーズに携わった時、プロトタイプが全くゲーム性のないものになってしまい、それをプレイしたソニーの幹部陣の顔色が非常に曇ってしまったようです<ref name="br67">川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.67</ref>。 ここでの悪い反応、薄い反応の理由がわからなかった佐藤氏が、階段の踊り場でソニーの新人に尋ねてみると、「それが、あの、ゲーム性がないっていうか・・・」と言われたと出典の対談集に書かれています<ref name="br67" />。 基本的に佐藤氏は、プロトタイプの企画を提案しただけですが、ソニーにはプロトタイプを作るための部署があるらしく、1～2ヶ月かけてそこでプロトタイプが作られたようです。 この問題の責任が誰にあるかは、大した重要な事ではありませんが、商業作品としてプロトタイプを作る以上は、どこかの段階でゲーム性を意識して、プログラムに盛り込む工夫が必要になるでしょう。 ===ゲームの見た目とは？=== ふつうゲームのプレイヤーは、まず最初にそのゲームの「見た目」を判断し感受するでしょう。ですからその見た目のインパクト、興味を呼び起こす構成が必要になります。 例えばスーパーファミコンRPG『新桃太郎伝説』では、開発当初はドラゴンクエスト5 のようなマップ画面のトップビューUIでしたが、開発中にクォータービューの他社製RPGが発売されて高い評価を得たので、マップUIを（トップビューではなく）クォータービューに作り直したようです。このことは攻略本『新桃太郎伝説 究極本』に開発裏話として書かれています。 一方現在でもこの方向の試みは重要なようで、書籍『ゲームデザイン プロフェッショナル』の著者は、他企業の製品の画面と、自社の製品を目で見比べる分析方法で、自分たちの製品のUI の問題を見出しています<ref name="gdp199">『ゲームデザイン プロフェッショナル』、P199</ref>。 割と素朴で単純で即物的な見た目、「かっこいい」とか、「ぱっと見派手」等の要素が非常に重要なようです<ref name="gdp199" />。 商業としてゲームを作る以上は、ペイしなければ企業も事業の継続も維持できませんから、考慮せざるを得ない問題ではあります。 == ゲーム開発ツールを使う場合 == ====開発ツールのライセンス条件==== ゲーム開発ツールのなかには、そのツールで開発したゲームソフトに義務として「この開発ツールで開発したソフトウェアは、ソースコードを必ず公開しなければならない」などの条件をつけている場合があり、このような条件を「開示義務」（かいじ ぎむ）または「ソース開示義務」などといいます。 ソース開示が嫌な場合は、開示義務のあるツールは使わないのが正解ですね。 ゲームに限らず、ソース開示を義務としている開発ツールは多くあるので、ライセンスには気を配る必要があります。 「有料ソフトの販売を禁止」とか「アダルト作品の開発は禁止」などの条件をつけている場合も、ありえます。 ですからゲーム開発において、ツールのライセンス条件の確認は、非常に重要です。 {{コラム|GPLライセンス違反| GPL（ジーピーエル）というライセンスがあって、Linuxなどのオープンソースで使われています。このGPLを組み込んだプログラムは、ソースを公開しなければいけません。 ですから、ソース公開したくないプログラムには、GPLソフトウェアは組み込めません。 ゲーム業界でも、GPLライセンスのソフトウェアを組み込んでしまったために、呼出し元ソフトウェアでのソースコードの一部を公開することになったゲームがあります。2005年頃、『ToHeart2』という美少女ゲームが、xvidというGPLソフトを取り込んだ疑惑によって、GPL違反の疑いでソース公開になりました。（[[w:ToHeart2#GPL違反とソース公開]]） GPLでも、たとえばLinuxサーバ上でソース非公開のアプリを動かすように、GPLのソフトウェアを非公開ソフトとは独立した状態で使う場合は、ソース公開の必要はない、と、考えられています。（これが必要有りとなると、オンラインのプログラムやネットゲームは全てソース公開しなければならなくなり、非合理な結果になる。） 特定のプログラム自体に、GPLソフトウェアのコードを取り込んだ時、ソースコード公開が必要になります。 }} {{コラム|BSDライセンス他| オープンソースの中には、どのような利用法であっても、利用者にソース公開を求めないライセンスもあります。BSDライセンスとMITライセンスはソース非公開で利用できます。 ゲーム制作ツールの吉里吉里Zは、修正BSDライセンスで公開されています。 もしライセンスのことがよくわからない、またはライセンスの学習に時間をかけたくないなら、オープンソースのツールを使うなら、BSDライセンスを使うのが安全です。 }} [[w:DXライブラリ]]は、GPLでもBSDライセンスでもありません（DXライブラリ説明書「DxLib.txt」には、どこにも「GPL」とも「BSD」とも書いていない）。DXライブラリは単にソースコードが公開されていて、著作権者の「山田 巧」氏が著作権を保持しているオープンソースなライブラリです。 このように、ネット上でソース公開されているソフトウェアには、ライセンスの複雑な解釈を嫌ってか、「BSD」や「MIT」などのライセンス条件を名乗らないオープンソースソフトウェアもあります。 {{コラム|自作ソフトでソース開示| 昨今ではオープンソースやフリーソフトウエアの発展などの背景もあり、「自作ゲームのソースコードやソースファイルも開示しよう」と思うゲーム作者もいるかもしれません。 然しソースコードを開示していることが原因で、トラブルに巻き込まれる場合もあるかもしれません。自分の作ったゲームのコードが悪用され、トリッキーないたずらや嫌がらせ、誹謗中傷などを受ける可能性も全くないわけではありません。 そこでライセンスに、利用による損害に対する保証が無いことを明示するのは、ある程度有効でしょう。大抵の著名なフリーソフトウェアライセンスには、この条項があります。他者の悪意を完全に防ぎ失くすることは難しいのですが、ある程度の対策は見出されていますし、自身でも見出していく必要があるでしょう。 }} ====開発ツールを使用しないという事==== 下記の理由（機能制限および移植性の悪さ）の問題から、あまり大規模な作品は開発ツールでは作らないでおくのが安全です。 大規模な作品の場合、Visual C++ などでコードを書いて開発することを推奨します。 =====機能制限===== ゲーム開発ツールを使う場合、そのツールにもよりますが、「○○ができない」、つまり特定の目的を果たすための機能を持っていない場合があります。 Visual Basic や Visual C++ には普通にある関数でも、開発ツールには無い場合も多い。 また、もし、いったんはゲーム開発ツールを使って目的の機能を持ったシステムを作ったとして、さらなる機能をそのシステムに追加しようとするときに、大幅な作り直しが必要になる場合があります（拡張性の悪さ）。 システムがモジュール化されていても、そのモジュール部分では大きく改変する必要がある場合もあるでしょう。 ですからゲーム開発ツールによるゲーム制作では、あまり大作を作ろうとしないほうが安全です。開発ツールで作る作品は、比較的に小規模な作品に、とどめておくことを推奨します。 Windowsの場合、本来なら Visual C++ などを使って、プログラム文法のいろいろな事に留意しながらプログラムを書きますよね。開発ツールを使う場合、 Visual C++ のコードを書かずに、ほぼマウス操作だけでプログラムを作ろうとしているわけですから、何かしらの制限があります。拡張性の悪さは、プログラム文法などの学習の負担を減らすためのトレード・オフのようなものですね。 =====移植性の悪さ===== また、もうひとつの問題点として、C言語への移植性の悪さがあります。 ソースコードが公開されていない開発ツールの場合、異なる開発環境にゲームのソースファイルを移植するのは、ほぼ不可能です（仮に、開発ツールのランタイムを模倣できたとしても、著作権などの法的な懸念が生じる可能性あり）。 ゲーム開発ツールで作ったソースを、Visual C++のソースに置き換えるのは、簡単にはできないし、ほぼ全面的に新たに書くことになるでしょう。 ==イラストレーター、デザイナー== ゲーム制作、業界において、イラストや音楽を作る部署、人物は、まとめて、"アーティスト"と呼んでいるようです。 ゲーム界の場合デザイナーというのは、プランナーやディレクターのことであり、管理職的な設計者のことで、美術的なクリエイターではない。design という英語には、機械建築の設計という意味もあります。 映像関係、画像系のアーティストはグラフィッカーと呼ばれることもあります。ムービー担当者、特にゲーム界では3D-CGの制作者をアニメーターと呼ぶことが多いようです。アニメーション業界では主に、手描きの原画、動画マンをアニメーターと呼びますが、最近は3D-CGアニメーション映画も多いので、すこし状況が変わっているかもしれません。 ゲーム業界とアニメーション業界、各会社企業、過去と現在で、「原画」「仕上げ」「絵コンテ」等、一般的な作業に関する言葉が、それぞれの状況で微妙に違った意味で使われることも多いですね。 …ところで前編集者はわざわざこの項目を作ったうえで、色々な場所での言葉の意味の違いを、クドクドと自分勝手な分かりづらい説明で長々述べた後、「混同しないように気をつけましょう。」なんて馬鹿馬鹿しい言葉で締めているんだけど、この人物の意図はどこにあるのだろう? 例えばデザイナーというのは一般的に、造形作品、図案、意匠を考案する人のことを言うのだから、ゲーム界の外の人間が多少その業界内での意味を取り違えても、それほど致命的なミスでもないし、罵倒、愚弄されるいわれもなければ、好き放題にその相手を罵倒、愚弄していいわけでもない。間違えて使っている人を見たら、その都度やんわりと教えてあげればいいだけじゃあない? だいたいその世界に現実に身を置いたら、そこでの言葉の意味、使い方なんて自然に覚えるものだし…。 それを得意げにこれが違うあれが間違いといちいち理屈書いて、いい気になって威張っているこの人物は何者なのだろう? 現編集者が思うには、この人物は、学問、知識、知恵、科学とは何かという事を、根源的に取り違えている、のだろう。 ==操作性== 操作性について、親指と人差し指<!-- ←ここ，中指って書いてあったけど，こっちだよね? -->だけでボタンプッシュなどの操作ができるように作成するのが基本です。中指、小指、薬指はコントローラのホールドに使うぐらいです。人間工学的に、小指や薬指は力が弱いので、微妙な操作には向かないことが知られています<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.48</ref>。 一般的にゲームプログラミングでは、 # プレイヤーからの入力を扱うことができる。 # ゲームが提示する内容を表示することができる。 入力と出力、この2点が機能として必要になります。 プログラミング言語とプレイヤーからの入力については歴史的にも、あまり変化がありません。言語では主に[[C言語]]、[[C++]]が用いられる。[[w:携帯電話|携帯電話]]向けのゲームでは[[Java]]が利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります（[[w:iアプリ|iアプリ]]、[[w:EZアプリ (Java)|EZアプリ]]、[[w:S!アプリ|S!アプリ]]などを参照）。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。 パソコンゲームでは、プレイヤーからの入力には通常、キーボードかマウスを利用します。他に[[w:ジョイスティック|ジョイスティック]]や[[w:ゲームパッド|ゲームパッド]]が利用される場合もあります。家庭用ゲーム機では[[w:コントローラ|コントローラ]]が利用されることが多いのですが、[[w:ニンテンドーDS|ニンテンドーDS]]や[[w:Wii U|Wii U]]では[[w:タッチパネル|タッチパネル]]、[[w:Wii|Wii]]では複数の入力機器が提供されることが発表されています。各種入力機器をプログラムから扱う手法自体は、普遍性があり、入力機器ごとに大きく変化しない、と、考えられています。[[w:デバイスドライバ|デバイスドライバ]]、[[高等学校情報B]]には、プログラムから周辺機器を扱う方法について多少の記述があります。 画面表示のうち、3Dの表現は割合難しく、ある程度の数学（高校、あるいは場合によってはそれ以上）の理解が必要でしょう。2Dに関してはプログラムの面では、さほど難しい部分はありません。 ==処理速度の問題== 基本的にプログラミングでは、関数を使って、処理をコンパクトにまとめ、定数ではなく変数で柔軟性のある操作をすることが求められますが、ゲームの場合は、この構造のせいで処理速度が低下することがあります。 現在のCPUの性能、速さはかなり高くなってはいますが、プログラム処理は無限に煩雑化できますから、やはり高度な処理を短時間でなすことが求められます。特にゲームは、リアルタイムの反応のタイミングが非常に重要ですからね。数学の指数計算についての雑学で、「新聞紙を42回おりたたむと、月に届く距離になる」というものがあります。(新聞紙の厚さ)*2^42、ですね。もっとも新聞紙の物性から言って、ほぼ不可能な操作ですけど^^;;。コードの内容、組み合わせによっては、このように計算量が指数関数的に膨大になってしまい、処理速度が非常に遅くなってしまう場合があります。 ですが、このセクションで後述するように、関数を用いる場合の解決策（※概要:あとでdefineやinlineに置き換え）があるので、プログラミングの初期のほうは、とりあえずバグを未然防止するために関数を活用するべきでしょう。 1980年代頃のファミコンなど古い時代のゲームでは、ストレージ容量（ハードディスク容量のこと）が、ボトルネックでした。「容量不足でイベントをいくつか削りました」と、当時のRPGなどのゲーム作家が述べるのは、ストレージ容量の不足のことですね。ただ当時のファミコンはROMカセットでハードディスクは無いので、まさにストレージ容量という言葉が適切でしょう。 しかし2010年以降の現代では、ボトルネックになっている要因は、ストレージ容量不足よりも処理速度です。 ゲームプログラミングに要求されるコード特性は、科学計算ソフトウェアや金融プログラミングなどの手法とは異なります。情報工学・情報科学で適切とされる「構造化プログラミング」などの歴史的に発展してきたプログラミング・パラダイムの理念とは反するようなコード開発方針になる場合もあります。しかしゲームプログラミングに限らず、限定されたハードウェアで特定の結果を速く得るためには、様々なトリッキーな手管が必要になるでしょう。 ;ツクール等制作ツール RPGツクールの制作元のカドカワ（アスキー社→エンターブレイン社→カドカワ（かつての「角川書店」） ）では、PRGツクールでのアクションゲーム開発は推奨していません。アクションゲームの場合は、同じカドカワの「アクションゲームツクール」で制作するよう、薦めています。 アクションゲームとターン制RPG では要求される特性が大きく異なり、なかには、ほぼ対立しているような性質もあります。 ツクールやウディタでも、万能にあらゆることがスタマイズできるわけではなく、その制作ツールの特性に依存しますし、主に処理速度の低下しない部分についてユーザが創作できるようになっているでしょう。 多くのRPG制作ツールはマップ操作や戦闘画面の基本システムのルーチンそのものは、あまりカスタマイズできません。画像や音楽は挿入できますが、例えば戦闘プログラムなら、「コマンド」の命令文など一部の派生的な部分だけが独自に作れる程度でしょう。 ですから、ツクールでどうしてもアクションRPGを作りたい場合、基本システムの改造はかなり困難だろうし、別途、アクションRPGのような動作をするマップイベントを作成する・・・ぐらいでしょうね。 ツクールやウディタでターン制RPG以外のジャンルを制作するのには、実質的には限界があり、さまざまな制約が生じます。 ;具体的な手法 初期段階では関数や変数を活用してプログラミングし、処理速度を高める必要がある箇所にだけdefineマクロ等を用い別の方法に置き換える。C++ならinline関数という前処理命令もあります。 通常の関数で記述していったソースコードを、あとから一括変換などでdefineマクロやinline関数などに置き換えることは比較的に容易です。 また、関数を経由しているので、マクロを使った場合でも比較的にバグが混入しづらくなっているかもしれません。（defineなどの前処理命令マクロは、用いるとバグを発見しづらいので、なるべくマクロの利用を避けるべきなのが、ゲームプログラミングに限らないプログラミングの定石です。） 一方、まったく関数を使ってないコードを、あとからdefineマクロなどに手作業で置き換えるのは、なかなか面倒です。 最終的には一括変換で置き換えることが出来ますから、途中の段階では、処理速度を気にせず関数を使うのがいいでしょう。 なお、defineマクロは、値の置換以外には用いないのが、プログラミングの定石です。このため、たとえば黒色RGB値の<code>10,10,10</code>といった配列にdefineマクロを使うべきかどうか悩みますが、とりあえずなるべく値周辺にだけdefineマクロを適用するようにするようにするのが良いでしょう。いっぽう、一般の命令文をdefineマクロで置き換えるのは、避けるべきでしょう。 たとえば、処理に0.5秒ほどの時間の掛かってもかまわないような場所は、どんどん、関数に置き換えていっても良いかもしれません。 アクション性のないゲームなら、関数をぞんぶんに活用できます。 ターン制RPGやシミュレーションゲーム、アドベンチャーゲームなど、関数を活用しやすいでしょう。 一方、アクションゲームなどでキャラクター操作中のコードのように頻繁に使って、しかもそのゲームの中心的なコードなら、そこは最終的には関数にしないほうが良いかもしれません。 このように、ゲームのジャンルによって処理速度に対する必要な水準が異なりますので、プログラミング時における関数などの利用の方針も異なります。 以上のように、何でも関数にすることは避けるべきです。関数は処理速度の問題がありますので、必要性のある部分だけ関数にするべき。関数を使わなくても、for文やif文などのブロックの構成を適切に組み合わせることで、コード中のmain関数以降の部分でコード共通化できることは色々とあります。 「共通性のあるコードだから」といって、大して長いわけでもないコードを関数に置き換える事は、速度維持には寄与せず、ゲーム制作のプログラミングとしては、悪手となるでしょう。 ===2Dの画面出力=== 画面出力の場合も入力機器の場合と同じで、これらを操作する方法はOSごとに異なっています。先ほどあげた GTK+, Qt, SDLなどのライブラリはクロスプラットフォームの画面出力を提供しているため、これらを利用することで全てのプラットフォームで動くプログラムを作ることができます。<!--画面出力を扱うためには近年の[[w:ビデオカード|ビデオカード]]の発展についても見る必要があります。しかし、ビデオカードの機能は2次元の描画に関してはあまりあらわには見えないので、この話題は3次元の描画を行うときに再び戻ってきます。--> *[[ゲームプログラミング/ブロック崩し]] *[[ゲームプログラミング/画面出力]] ==目次== === ジャンル別のプログラミング手法 === ==== 3Dグラフィック ==== * [[ゲームプログラミング/3Dグラフィック]] * [[XNAを使用したシンプルな3Dゲームの作成]] ==== RPG ==== * [[ゲームプログラミング/RPG]] ==== アクション ==== ※未作成 ==== パズル ==== ※未作成 ==== シミュレーション ==== ※未作成 === ゲームのデバッグ === * [[ゲームプログラミング/デバッグ]] === 入力 === OSの種類によって、キーボード入力やマウス入力の受け付けのさいのプログラムの書き方は違う。 Windows API での具体的な手順は『[[ゲームプログラミング/入力]]』で説明する。 === ゲームエンジン ※未完成 === * [[ゲームプログラミング/Unity]] ※リンク先ページの編集者が現状ではUnityの著作･調査を放棄中なので、調べ物としては役立ちません（2021年12月19日に本文を記述）。 === 非プログラミングのゲーム製作の関連作業 === ==== バランス調整 ==== *[[ゲームプログラミング/バランス調整]] 厳密にはプログラミングの話題ではないが、ゲーム製作では必要な知識なので、サブページで説明する。 :※ゲームデザインに関する記述をここに集積し分離したい、という編集者の意図もある。 ==== ゲーム用の書類の書き方 ==== 説明書や仕様書（しようしょ）の書き方については、『[[ゲームプログラミング/書類]]』で解説する。 == 未分類 == ===Visual C++プログラムによる文字画像の出力=== Visual Studio付属のフォームデザイナ（VSの用意するGUI自動作成ソフト）によるGUIオブジェクト作成では、RPG用には使いづらい。いや、ひょっとしたら上手に使う方法はあるのかもしれないが、様々な理由で難易度は高い。 そこでまず、Visual C++で、フォームデザイナをなるべく使わずに文字や映像を出力する方法を考える。 選択肢は、幾つかある。 1.フォームデザイナを1つも使わない方式 *Windows APIで入力していく方法。(Wikibooksに『[[Windows API]]』の入門書があります。) *DirectXで入力していく方法。DirectX自体はWindowsAPIを利用している。 2.1つだけフォームデザイナのパネルを使う方式 *フォームデザイナで「パネル」という画像表示機能のコンポーネントを一つ用意して、そのパネルで表示する画像をゲーム内のストーリーなどに応じて切り替えるだけで、すべての画像表示を行う。 フリーソフトでゲーム用ライブラリの『HSP』はWindows API を呼び出す仕組みになっています(HSP関連のサイトを見ると、Win APIプログラミングの解説をしている場合もある)。 フリーソフトでゲーム用ライブラリの『DXライブラリ』は Direct X を呼び出す仕組みになっています。そして、ゲーム開発ツールのひとつであるウディタのソースコードは、DXライブラリとVisual C++ を使って書かれていると、作者が公表しています（ただしソースコードは非公開）。しかし、ウディタを用いたRPGプログラミングでは DXライブラリによるコーディングはしない。ウディタにはコード入力の機能は無く、マウス操作や、キーボード操作、キャラ名称や会話文などのテキスト文字や数値の入力のみに対応している。 ===乱数=== そもそも乱数とは何かという問題があるが、それは高度な数学的な議論になるだろうから、我々はその問題には深入りできない。 ゲームにおける乱数的な処理では、事実上ランダムな値にならず、演出や調整のためにアルゴリズムが介入している場合も多い。例えばゲーム中のくじで「外れ」続くと、当たり確率が変動し、次からは当たりやすくなるアルゴリズムなども良く使われる。<ref>『ゲームプランナー集中講座』、P232</ref>。 ゲームは娯楽であり、実用目的のシミュレータではないし、アルゴリズム介入で、確率的にもいんちきが多いので、あまり厳密なランダム性が問題になることは少ないだろう<ref>『ゲームプランナー集中講座』、P231</ref>。 例えばさいころというのは典型的な乱数器だし、ゲームにもよく使う物だろう。 無印C言語には標準的乱数関数 rand()があるが、これを乱数発生に使うことに批判的な意見もあるし、機能もやや不足していると見れる。 Windows64bit では int rand(void) の出力は 32bit 整数だろう。まず stand関数で初期化してから rand()を呼ぶごとに疑似乱数が帰ってくる。これの複数回の連なりが乱数列だね。帰ってくる値は0 以上 定数RAND_MAX の値以下。 例えばさいころの数値が欲しいなら、rand の返り値を6で割った後、余りに1足せば、とりあえずそれらしいものはできる。 RAND_MAXは rand()の属性として定数が与えられているだけだから(Windowsで0x7FFF)、この値の変更はできない。 まあこれでもそこそこいい加減な乱数として機能するだろうが、最近ではもう少し改良された、質の高い乱数関数もある。 また、改良された乱数関数は、乱数の範囲も指定できるから何かと使い勝手が良いし、バグを防ぐ効果もあるのだろう。 <syntaxhighlight lang="cpp"> Random^ saikoro1=gcnew Random();// Random^ でRandomクラスの変数を作っている。gcnewはインスタンスをつくるための演算子。 int detame; detame=saikoro1->Next(1, 7);// Next メソッドで「〇〇以上△△未満」の乱数を指定できる。「->」はメンバーアクセス演算子。 MessageBox::Show("目"+detame.ToString()+"が出ました。"); </syntaxhighlight> ↑例えば上述のコードは前編集者が示したものだが、これは .NETプログラミングですね。.NET のSystem::Randomクラスを使っている。.NETのクラスは普通、C#かVisual Basic で利用するので、Visual C++で使えるようにするには結構面倒な手管がいるが、その辺は読者諸兄、ヘルプやネット情報を参照して、適宜辿り付いてほしい。 C++ の場合はむしろ、 #include <random> を宣言してそこで使える関数を使用するほうが簡単でしょうね。この場合でも、乱数としての精度も高いし、帰り値の範囲指定もできる。 ===画像のちらつき=== 画像がひんぱんに変化するアプリでは、画面が、ちらつく事がある。画面のちらつきは、ゲームのように、画像を凝視するアプリでは、かなり利便性を損なう。 キャラクターが1歩移動するだけで、画面全体がちらついたりする場合もあり、かなり、プレイヤーの不満になる。 これは、ダブルバッファ（「裏画面」と、良く言われる）という技術で、解決を図る。 Direct Xの用語では「スワップ チェーン」と呼んでいる。 .NET Framework開発環境の C++や C#でもダブルバッファの機能があると解説されている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。 しかし前編集者が実験したところ、この機能を有効に使って確認することはできなかったとの指摘がある。ひょっとしたら何らかのマイクロソフトの解説に間違いがあって、工夫次第では利用できるかもしれないが、少なくとも今現在のこのページでは、その問題に関するリファレンスは提供できない。 そこでやはり、以前の項目と同様、Win32 API または DirextX の利用をこのページでは考えたい。 前編集者は、.NET Framework のフォームデザイナでは、ちらつき自体は解決できそうだが、グローバル変数の共有が困難だったり、アプリ内から終了コマンドが使えない、などの難点があると指摘している。 ただ現編集者はこの2点に関しては、解決策はあると思うが、しかし特に調査はしない。 前編集者は、.NETプログラムでゲームを作る難点をいくつも上げているが、おそらくどれも、.NET の仕様や全貌に精通すれば解決できるように思えるが、そもそもその全貌がかなり広大なので、解決の道のりは長いだろう。 そこで少なくともこのページでのWindowsゲームプログラミングは、Win32 API を利用したものになるだろう。 ==セーブ、ロード、データベース== ===セーブ機能とロード機能の作り方=== ゲームでもシリアライズ機能が必要なことは多いだろう。数値（HPなどの各種パラメータ現在値）や文字列（例えば、プレイヤーの作成したキャラクターの名前）や現在地やフラグ状況などなど、セーブの機能は欲しい。一番簡単な方法は、C言語の fopen 関数のテキストファイル書き込み機能で、テキストファイルとしてセーブすることだろう。 Windows API には CreateFile関数 があるが、テキストファイルでの素朴なセーブは一番簡単で単純なセーブ法だろう。そしてテキストファイルを読み込んでプログラムに各種変数を配置して、ロードとする。 書き込みとしては、一番単純なC言語記法では、fprintf ですかね。C++としての書き込みをしてもいいし、読み込むのも、一番基本的な方法で。基本Cだとしたら fscanf で、この関数でテキストの数値も変数として読み込めるはずですよ。場合によっては atoi関数 で文字列→数値の変換をすることもありますかね。 基本的にデータファイルは、OS もアプリケーションも、テキストファイルとバイナリファイルの２分類で考えるでしょう。でもテキストファイルだってバイナリの集まりなんですが、テキストを扱うファイルだけ特別視していると考えていい。 そして多少それらしいデータを作りたいときは、バイナリファイルで作るという事になるでしょう。 バイナリファイルでもデータとしてのファイルと、OS が機械語または何らかの仮想的な機械語として扱う実行ファイルがある。それらのバイナリは種類に応じて多くは冒頭にファイル識別子の情報があるだろうし、OS や アプリケーション側で工夫を凝らして、特定の条件を満たす場合しか動作しないようにしているだろう。そしてバイナリファイルを扱うときは、セキュリティの安全性も考慮するだろう。 基本的にプログラム側は何でもありだが、識別子の判別その他、ある程度様々な考慮をしないと、困った事態が起こり、プログラマーが責任を問われることも起こるかもしれない。 まあその時はいつものように口先だけで謝り、それでも許してくれなかったら、腹をかっ割いて死んでお詫びすれば、世間の人たちは美事な武士道精神と言って、口々に褒め称えてくれるだろう^^。←もちろんこれは冗談^^;;;。 市販のパソコン用ゲームや同人ゲームでは、テキストファイルではなくバイナリでデータ保存するゲームの方が圧倒的に多いだろう。その方がそれらしいしかっこがつく。ゲーム開発ツール側自体も、そうなっている場合が多い。RPGツクールもウディタも、セーブデータの形式はバイナリ。 テキストデータは基本エディタで開けるが、バイナリデータも内容によっては結構ぐちゃぐちゃの状態で開ける。バイナリデータはバイナリエディタで開ける。バイナリエディタのリードオンリーモードやバイナリビューアみたいなものがあれば、データーを壊さないで結構安全にデータ調査できる。 データ内容を秘匿したければ、バイナリ化だけではなく、暗号化も必要になるかもしれない。 ===機能の整備=== セーブ&ロード機能の実装時には、まずセーブ機能から作るのがやりやすいという。 しかし最終的には関係関数の整備は、ロード機能が基盤となるだろう。 データや変数を、一定のスタイルでセーブして、一方で正しいスタイルでロードする、この機能が必要なわけですよね。 シリアライズされたデータを、型を決めたうえで配置しなければいけないから、ロードのプログラムの方が複雑に、面倒になる。 結局データのシリアライズは、ロード機能が基盤となり、その機能の作りやすさが、セーブ機能の作りやすさも支配するようだ。 == ゲーム中の特殊イベント == *[[ゲームプログラミング/特殊イベント]] RPGやシミュレーションゲームで、1回しか起きない特殊イベントを作りたい場合もありますね。例えば日本の中世の戦国シミュレーションゲームで、「桶狭間の戦い」が3回も起きたら困りますよね。まあ起きるなら起きてもいいけどね^^。信長君には敦盛を3回舞ってもらいましょう^^。 さて、リンク先ではその話題についての叩き台、「こうプログラミングしたら、いいんじゃない？」、という事を説明しています。 ==スケジュール管理== [[File:Tokai Hairo.jpg|thumb|500px|ガントチャートの例:東海発電所の廃止解体工程]] 個人でゲームを作る時にはあまり考慮しなくていいのですが、シビアな仕事の世界では、スケジュール管理表が良く使われます。 「作業責任分担表」（TRM:Task Responcibility Matrix）といわれるスケジュール表から、それをグラフ的に図示したガントチャートといわれる表を作って、その表を見て作業計画を判断する<ref name="gpd65">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.65</ref>。 {|class="wikitable" style="float:left" | 仕事 | 担当 | 状態 | 開始 | 終了予定 | 終了日 |- | 仕事1 | 田中 | 済 | 2021/10/03 | 2021/10/10 | 2021/10/10 |- | 仕事2 | 田中 | 仕掛 | 2021/10/11 | 2021/10/13 | |- | 仕事3 | 鈴木 | 済 | 2021/10/05 | 2021/10/08 | 2021/10/08 |- | 仕事4 | 山田 | 未着手 | 2021/10/13 | 2021/10/17 | |- |} {{-}} ガントチャートでは普通、横軸に日程をとります。 商業ゲーム界でもガントチャートの横軸は日程です<ref name="gpd65" />。 ガントチャートとして図示することで、ボトルネック、リスク要素、直感的にスケジュールの詳細や全体像が理解しやすくなります<ref name="gpd65" />。 スケジュール管理のための、現実的、習慣的な工夫ですね。 このTRMとガントチャートは、IT業界だけでなく建築工事でも使われ、これを利用したボトルネックの洗い出しも、建築学の教科書に記述があります。 住宅の新築やリフォームをする時、建築業者がこの表を提示して、見せてくれることもあるでしょう。 業界人ではなくとも、こういう慣習を知っておくと、得るものがありますよね。 ==ストーリー制作、そして順序== ゲーム界、特に商業ゲーム界では、ストーリーもゲームも全体から作っていくようです。アトラス社（ペルソナシリーズ、女神転生シリーズ、などを手掛ける）では、「ゲーム全体に血を回すのが先」、という言葉が良く言われていました<ref>[https://news.denfaminicogamer.jp/projectbook/191030a/2]2020年12月1日に閲覧して確認.</ref>。 プレーヤーが見たいのは、物語の細部ではなく、ゲーム全体のストーリーやテンポ、総合像である、とは限らないのだが、しかし物語を含む創作物では、全体を見て重視し、そこから作っていくのはある意味王道、常套手段ではあります。 ちなみにやや雑談的ですが、日本の週刊漫画は、その週その週での勢いや読者の興味の引き付けも大事なので、全体がないのに、その場その場で場当たり的に作られた事も多かったようです。 現編集者が聞いたことのある話では、週刊少年ジャンプで連載していた本宮ひろ志氏が、不良少年物の漫画で、敵の不良少年グループと1対1000の喧嘩になり、さあいよいよ対決場に着いて勝負だってところで以下次号にし、そして実は本宮氏はその続きを全く考えていなくて、考えてみたけどどう考えてもどう描いていいかわからない^^;;;、そこで仕方ないのでイライラして近所の酒場に飲みに行き、そしてイライラしたままそこの常連達とあり得ない大ゲンカして^^;;、そのままボロボロになって家に帰って、2時間で次の号の漫画を描き終えた、と、本宮氏自身がメディアで語っていたのを聞いたことがあります。 さて、コンピューターゲームである以上、ゲームのストーリーはシステムと連携、調和したものになるでしょう。 そこで、ゲーム作家として、システムを先に決めた後ストーリー、そういう方法論の作者も多いようです<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.306</ref>。 とにかく商業ゲーム界では常識的に、全体像から攻めていく。 例えばドラマ脚本では、「ハコ書き」という方法がある。全体像に当たる「大ハコ」を記述してから、「大ハコ」→「中ハコ」→「小ハコ」と記述していく<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.184</ref>。 しかし、本当にすべてのゲーム制作は全体から作る必要があるのか、という疑問はありますが、その方法論に従うとすると、 :*エンディングを大まかに先に作る :*機能の実験を簡易でいいので事前にしておく（※プロトタイプの項目を参照） :*使用頻度の高い部分から作る などの工夫を凝らして、常識的な方法を遂行していくことになるでしょう。 或いは、アルファ版（α版）を中盤から作り始めるとか…<ref>吉冨賢介『ゲームプランナー入門』、P17</ref>。α版の製作目的の一つとして、そのゲームが本当に面白いかの検証がある。面白くないと判断したら、制作中止もある。最初からではなく中盤から作ると、ゲームの全体像が見えるので、検証、判断がしやすい。 つまり全体から攻めて、細部やゲームが作られていくわけですから、必ずしも冒頭部から作り始める必要はないわけです。 ;エンディングやラスボス戦闘を早めに作る場合 ゲーム作者にもよりますが、商業ゲームシナリオでは、エンディングを早い時期に作る人も多い<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166</ref>。 システム面についても、先にゲーム全体のクリア条件を決めてから、あとから各ステージの条件を決めていくことが多いようです<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.253</ref>。 エンディングの仮の、おおざっぱなシナリオ、そしてキャラクターの性格付けを先に決めておくと、ゲームの方向性と主人公達が目指すもの、ゲームの全世界像が作者やスタッフに明快になっていきます<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166</ref>。 基本的に商業ゲーム界では、全体→部分と細部、の構成を進めていきます。 ゲームは必ず最後にラスボスと戦う訳では無いでしょうが、その戦いはゲーム中で最も高負荷になるでしょうし、全てのシステムが集積する場面でもあるので、エンディングを先に作ると、ゲームの最大負荷の検証ができます<ref name="yth">[https://www.youtube.com/watch?v=kAUkSNhH410] 2020年8月30日</ref>。 3Dゲームでは、RPGなら戦闘シーン、アクションゲームならアクションシーンが、一般的に最も高負荷<ref>ntny著『ローポリスーパーテクニック』、ソフトバンククリエイティブ、2010年2月16日初版第5刷、P28</ref>。 負荷が高くて処理が落ちないかどうかも、この方法で確認できます。 まあ全ての物語は最後の最後が一番の見せ場ですからね。 中盤は重要性が低い…訳では無いが、少し手を抜いておこうという事か^^;;;。 最後は見せ場を盛り込むから、物語を削る必要があるとすれば、それ以外の部分、という事になりますよね<ref name="yth" />。 つまりラスボス戦（必ずゲームってこれで終わるの? ^^;;;）は最重要なので削らない。後の部分は削る可能性あり。だから最後を先に作って作りこんでおけば、制作過程で不測の事態が起こっても、重要部分はできているので、早く、上手にリリースできる。 {{コラム|イラスト制作でも順番を考え直すと打開できる場合あり。| イラスト雑誌『コミッカーズ』（1995年季刊夏号）（唯 登詩樹 表紙）での藤島康介のインタビュー 藤島（談）:よく若い漫画家さんから相談で、「先生みたいに女性の長い髪を書くとき、毛先を書くのが難しいです。根元は書けるのに」との相談を受けるのですが、 僕（藤島）は髪を描くときは毛先から始めて根元に向かって描いてます。 つまりイラスト初心者は、根元から髪の毛を描きたくなるのですが、ここで長い髪の毛を描く場合はむしろ毛先を先に書いて位置決めして、長い毛を描くと割とうまく描ける。 きれいな女性の髪の毛は、毛先の奇麗さが大事ですからね。 ストーリーを作る時に全体を考えたうえで、必ずしも最初から書くことにこだわらない方がいいように、絵を描く時にも同じ発想が有効になる。例えば機械製図でも、正確に奇麗に書くためあるいは実際の製作のため?、位置決めの優先指示の記法がある。 }} *目標 世の中では目的や目標を明確化せよ、と主張する人は結構多い。現編集者は懐疑的。むしろ他人を自分の都合いいように動かしたいから、その方向を明示したいのだろう。それより、我々の本当の目的と目標は何か、歩みを止めてちょっと考えてみろよ、と、言いたい。 しかし結局世の人たちは目標をはっきり、言語化したがる。ゲームでもそれをすると、プレイヤーがゲームに引き込まれる、と言うが、実際にはそれはゲーム業界のカモになっている、インチキゲーマーだけだろう。 とにかくカモたちは目的を欲しがる。目標や課題がゲーム中で明確になっていないと、疑問だらけになり、ゲームをやめて、業界にお金を落としてくれない。そこで設計の際、各ステージやエリアなどの冒頭で、そのステージの課題や目標などを明示する必要があるという<ref>『ゲームプランナー入門』、P39</ref>。 ファミコンなどの古いアクションゲームではゲーム本編では目標は語られていませんが、しかし説明書などではきちんとそれが語られており、実際にスーパーマリオブラザーズの第1作目の説明書では、目的はクッパを倒してピーチ姫を救出することだと語られています<ref>『ゲームプランナー入門』、P54</ref>。 ===チュートリアル、製作順序=== RGBやシミュレーションゲームでは、初めの方は、操作説明のためのチュートリアルイベントになることも多いのですが、ここにも製作順序のポイントは指摘できますね。 基本的にはチュートリアルの細部は後回しにしたい。と、いうのはゲーム本体の仕様変更が、製作過程で頻繁に起こるので、チュートリアルもそれに合わせて後回しにせざるを得ない。 最初の段階でチュートリアルを作りこんでも、仕様変更になれば、その記述自体が不適になる。 当初のチュートリアルイベントがそもそも必要かどうか。説明書、マニュアルに任せてもいいですよね。 基本的にゲーム本体の仕様がかなり変更を含み場当たり的なので、チュートリアルは後回し、ゲーム本編の完成間近の時期になるか、もしくは本編完成後になるでしょう。 ==昔のコンピューターゲームと技術の発達、変遷== ゲーム制作の時は、自分が昔プレイして楽しかったゲームを思い浮かべるし、参考にもしますよね。 ただ、コンピューターゲームは明らかに、周辺技術が時間とともに、かなりの速度で発達、変遷していきますし、過去のゲームを参考にすると言っても、精神面、思想面での参考で、技術面ではやはり、最新の情報技術を取り入れたいと、誰もが思うでしょう。 前編集者は得意げに、古典技芸の世界では、『師を見るな、 師が見ているものを見よ』と、いう言葉があると宣っていますが、そもそもこの国のゲーム業界では、基本的に金と目先の安易な欲望と私欲しか顧みられないし、そこを支配する知性と教養は、善意や誠意や真理とはかけ離れた、歪んだ論理と無駄に衒学的な詳細しか持たないし、権力をもって威張っている連中は、善性や美などとはかけ離れた安易な偏向した物理主義的な議論に明け暮れている連中なので、師などと呼べる人物に出会うことさえ、至難な事でしょう。 === スプライト === ファミコン時代の昔のゲーム機には、一画面に表示できるキャラチップ数（敵チップも含める）に上限がありました。 一画面中に表示できる限界は、だいたい、マリオが一画面中に数十人ぶんです。 このように、ビデオゲームで小さなキャラクタを、高速表示する仕組みを、「スプライト」と呼んでいました。マリオのキャラクター表示は小単位のスプライトを複数合成していたようです。 このキャラクター数の制限が、当時はゲームの設計にも大きな影響を及ぼしていたわけですね。 例えばシューティングゲームで、100体の敵機を表示することはできない。 しかしそれなりの工夫はあった。表示のタイミングを変えることで、なんとなく、多量のスプライトがあるように見せることはできた。 つまり、 :1タイミング目では0～10体目までのAグループを表示、 :2タイミング目では11～20体目までのBグループを表示、 して、切り替える、うまく、素早くとか? 上手にプログラムを作ればそこそこ上手くいったようですね。それでも、キャラクターが多いと、一瞬、消えたりしている。 ファミコン上における実際の技術限界の正確な数値は、別の資料を参照していただくとして、あまりあてにならない数字として例えば、横1列上には 8体目までしか表示できなかったようです。マリオは一人で2*2=チップ使っていた。だから横一列では 4体までしか表示できませんね。 例えばシューティングでは、敵機の他に、弾丸などもスプライトでしょう。 マリオが４チップなように、巨大ボスなんかチップ数をかなり使っているでしょうね。 そしてチップ数が多いから、速度が遅くなるのでしょうか、何か我々の昔のゲームをプレイした記憶では、巨大ボスの動きは緩慢でしたよね。 しかしやや脱線しますが、巨大なキャラクターは何となく動きが遅いという我々の固定観念がある一方で、レスラーやヘビー級ボクサーはかなり動きが速い。相手の体が大きい上動きが早ければ、もう勝てないね。座して死を待つしかないか^^;;;。 <!-- すじ肉先輩さー、「ウドの大木」みたいな言葉を得意げに書いてる時点で、あんたは性格悪いし、このサイトでの不適切編集者である証拠なんだよね。--> ===画面描き換えと背景=== ファミコンのマリオの横スクロールでは、例えば地上ステージの空は、青一色で描き換えを行わない。低地の地面の障害物周辺だけを動かしていたようですね。動かす部分はプログラムでの描き換えが必要だし、動かない部分は背景として、描き換える必要がない。 書き換える必要のない背景表示は当然プログラムの負荷も少ないですよね。 ですから昔のレトロゲームの雰囲気や映像、仕様は、当時の技術の制限、影響を受けた上でその形態になっていたという事で、今は技術が発達したので、様々な斬新な映像表現や、演出を駆使できる。 一方で最新の技術を駆使したうえで、過去のレトロな雰囲気を再現、表現するという道もあるでしょうね。 ===アナログテレビのドットのにじみ=== 昔のブラウン管テレビのドットは、にじみが大きいとみていいようですね。これは画面の性質なので、ゲームでも映画でもバラエティでもドキュメンタリーでも、解像度画面としてのにじみは同じように大きい。 だから、ファミコンからプレイステーション1時代ぐらいまで、ゲームのグラフィッカーは、そういうにじみの大きい映像を意識して、ドット絵を描いていたでしょうね。 今の液晶画面が完全ににじみがないかどうかは怪しいですが、ブラウン管よりは少ない。 ただ滲みが大きいから、解像度が低くても何となく、自然に見えるという事はあったでしょう。 色に関してもにじみの重なりで、何となく豊かな色に見える。 前編集者は、同じドットの黄色の単色でも、そのドットの幅が1ドットか2ドットかで、テレビ上で表示される色が違う、実際にブラウン管のディスプレイ上で色が違うと書いていますが、どうでしょうね、要するに電子線が蛍光物質を刺激する量が割とあいまいですからね、そういう事を言いたいのか。 まあとにかく、昔のゲームはそういうあいまいでアナログな技術で、一種独特の画面を作り出していたわけですね。 ですからプログラムとしては当時の仕様をそのまま再現したとしても、今現在の機材では、昔のゲームの独特の雰囲気そのものまで再現するのは難しいですよね。 パソコン市場では、1999年ごろからノートパソコンが普及し、液晶ディスプレイも安価で出回ってきた。そこでにじみの少ないくっきりした映像が主流になってきますね。 基本的にディスプレイはブラウン管→液晶と変わり、解像度は大きくなる一方ですね。 プレイステーション2あたりからはもはやブラウン管でのプレイ自体考えなくなる。 この辺から家庭用ディプレイの切り替えが起こっていましたよね。 アナログ放送は2010年ぐらいまで続いたでしょうか。しかし家庭ではゲームをするにしても、普通に放送を見るにしても、DVDを見るにしても、ブラウン管から液晶や、プラズマというのもありましたよね、画面の解像度自体も高くなっていく。 そして画像のドットはにじみの少ないくっきりしたものへ、ゲームの映像の考え方自体変わっていきますよね。 最近はパソコン画面でも、TVでもドットの縦横は等しい正方形ですが、ブラウン管はそうではなかった。 だから、当時はドットで絵を描く時も、長方形ドットですね。 しかも、ゲーム機やパソコンの種類、さらにはアーケードゲームの基盤といったハードウェアの種類ごとに、コンピュータ側でのドットの縦横比の管理は違っている（らしい）。このため、移植のたびに、ドットは書き直しになったようだ。 昔は、というか実はいまでも、CGや画像の縦横比が正確ではない映像を見る事はありますよね。 現在のパソコン用のドットエディタ（という画像制作ツールがある）は1ドットが正方形だが、ファミコン時代は1ドットが（ドット用紙の時点で）少しだけ長方形。（なお、画像制作ツールの作り方については、『[[ゲームプログラミング/画像ファイルの作成プログラム]]』というコンテンツがこのサイトにある。） ファミコンの色数制限は52色から4色×4パレット（1パレットあたり4色）を使えると言われている<ref>[https://mynavi-creator.jp/blog/article/history-of-2dcg-designer] 2021年12月30日に確認.</ref>。しかし実際には、4色のうち1色は透明色として利用される色であり、全パレット共通の色になる（だから3×4=12色が使える）。 スプライトのパレットとは別に背景のパレットがあるので実際にはもっと多くの色数が一画面内で使えるが、しかしその他さまざまな制限があるので、合計で一画面内で25色が使えると言われる（12+13=25）。 論理的には25色だが、ブラウン管のドットの滲みやテレビのアナログな仕様から、結局はなかなか豊かな映像が当時も見れたと言っていいのではないだろうか。 しかしレトロなゲーム機では、さらにメモリ容量やストレージ容量などの制限もあり、けっして仕様上の最大色数を気軽に利用できたわけではないかもしれない。こういう制限もあったからか、ネットではファミコンの色数が「4色」や「8色」、スーパーファミコンの色数が「16色」や「256色」、とも言われることがある。 {{コラム|ドット絵| ファミコンのギザギザのキャラクターの絵は、良く、ドット絵と言われますよね。 ただ、プレーステーション以降、ゲーム機が進化しても、コンピュータの画像は、ドットのラスターグラフィックだから、ドット単位で絵を描くことは多い。 特に小さい絵、キャラクターやアイコンはドット単位でデザインします。 しかし言葉の使い方では、ドット絵と言えば昔の、ファミコンキャラクター風のギザギザの解像度の低い絵を指すことが多いでしょう。 現在のドットエディタで絵を描く場合でも、解像度の低い絵が多いですね。ラスターグラフィックも結局ドット単位で解像度が高いだけですが、解像度が高い、アンチエイリアスを駆使した絵は、もはや、ドットというよりはアナログの手描きの絵と言いたくなる。 前編集者はこのドット絵という言葉にこだわって、なんかグダグダ理屈書いていたけど、現編集者にとって何がしたいのか、何を言いたいのかただただ謎ですね。 とにかくドット絵にレトロな意味を持たせても全然問題ないと思うけど…。 子供時代の思い出は大事だぜ^^。 1990年代後半に、岡田斗司夫氏の対談でこういうものがあったそうです。出典はおそらく『マジメな話』。 「アニメの黄金期っていつだろう?」 「70年代かな～。」 「いや、80年代だろう。」 「そうかな～。」 「むしろ…」 「むしろ?」 「…12歳だね^^」 12歳万歳!(^^)/ }} ===テレビとディスプレイの焼き付き=== ゲームというのは色数も少ないし、静止画も多い。 ファミコン時代から、同じ色長時間の表示は、ディスプレイの焼き付きを起こすので、常にそれなりの工夫がされていたかもしれませんね。 静止画を避ける、時々背景を変える、背景色を光のエネルギーを持たない黒にするとか… パソコンでは昔からその工夫がありましたね。スクリーンセイバーという機能もある。 とにかく一つのドットに同じ色が長時間表示されると…ちょっと危ない。 焼き付きの問題は昔も今もありますよ。昔のブラウン管は焼き付かないという主張が時々あるようですが、事実ではないでしょう。 現代のテレビ受像機には、焼きつき防止のために「ピクセルシフト」という機能がある。これは画面上の映像の表示位置をタイミングごとに微妙にずらす機能です。こういう機能がすでに搭載されているので、ゲームソフト側で焼き付き防止を必要以上に考慮しなくてもいいらしい。液晶モニターは、焼きつきが起きにくいという。ただし有機ELはどうか。知りませんね。現編集者も前編集者も知らない^^;;;。 == 脚注 == <references /> == 関連項目 == * [[ゲームプログラミング/コンピュータゲームの種類]] * [[XNAを使用したシンプルな3Dゲームの作成]] * [[プログラミング]] * [[w:ゲームプログミング]] {{DEFAULTSORT:けえむふろくらみんく}} [[Category:ゲーム]] [[Category:情報技術]] {{NDC|007.64}} akisrk8fdyav8mxnau5vu2w49xlqfr4 206004 206002 2022-07-29T22:28:00Z Honooo 14373 /* 関連項目 */ 再編集一応の終了ですが、今後少し、出典の整理をするかもしれません。 wikitext text/x-wiki <div class="pathnavbox"> * {{Pathnav|ゲーム}} * {{Pathnav|工学|情報技術|プログラミング}} </div> == 概観 == このWiki参考書では、コンピュータを用いた[[w:ゲーム]]のプログラミングを扱います。つまり、いわゆる「テレビゲーム」や、[[w:コンピュータゲーム|コンピュータゲーム]]に関する記述についてです。 ここでは家庭用のパーソナルコンピュータで扱える範囲の事柄、それらのゲームソフトをつくるためのプログラミングについて議論します。必要に応じて家庭用ゲーム機の話題にも触れますが、あくまで派生的なものです。本書はプログラミングの教材であるので、大多数の読者が最初にプログラミングで触れるであろうパーソナルコンピュータでのプログラミングを、特にことわらないかぎりは想定しています。 用語に関して、コンピューターゲームの世界独自なものもあるでしょうから、適宜『[[ゲームプログラミング/コンピュータゲームの種類]]』などを参照してください。 == 本書の目的 == この教科書『ゲームプログラミング』の目的は、題名にもあるとおり、プログラミングによってゲームを作るための技術の参考資料を目的としています。 ゲームクリエイターやゲームデザイナー（絵描きではなくゲームの設計者のこと）のためではなく、プログラマーのための教科書です。 したがって本書では、ゲームとは関係の少ない一般IT企業での仕事のしかたについての記述もあれば、製造業系の組込ソフトなどに関する概要的な記述もあります。 なぜなら本書はゲームクリエイターではなく、たまたま何らかの理由でゲームを作っているプログラマーのための教科書だからです。たとえゲーム会社を退職しても、他の一般IT企業に転職してもプログラマーとして応用できることなども目指して本書は書かれています。 従って、紹介する話題が、かなりIT系、テクノロジー系の話題に片寄っています。本書で紹介するクリエイター論やデザイン論は、派生的なものにすぎません。 ;本書を扱う上での注意点 特にことわりのないかぎり、本書ではC言語でのプログラミングによってゲームを作りたい読書を念頭に説明しています。 だから、ゲームの生産効率性を無視してでも、本来ならRPGツクールのような開発ツールを使ったほうが早いシンプルなゲームの場合ですら、本書ではC言語または他のプログラミング言語での開発にこだわった方法を説明している場合もあります。 ;その他、本書について このページとそのサブページだけを見ていると本書は「ゲームクリエイトの教科書かな?」と捉えられるかもしれませんが、 しかしこのページとは別に本wikibooksには「[[プログラミング]]」というページがあり、そこではC言語やJavaなど代表的なプログラム言語のwiki教科書にリンクしています。ゲーム限定の話題ではないですが、プログラミングのコードについても、そちら『[[C言語]]』や『[[Java]]』やなどの教科書のほうが（実際に動作するコードの量が）充実しています。また、Visual C++ での画面出力については『[[Windows API]]』に入門的な説明があります。 本書『ゲームプログラミング』はそういったプログラミング教科書一覧の一部でもあります。C言語やWindows API の教科書では、これをどうやってゲームのプログラミングに応用すればいいか説明できないので（本wiki『[[C言語]]』はけっしてゲーム目的のページではないので）、ゲームの実際としてプログラミングの話題を切り離すために本書『ゲームプログラミング』は存在しています。 なので本書にゲームデザイン論やクリエイター論などの内容の充実は期待できません。 本書『ゲームプログラミング』は現状、プログラマー目的以外には対応できないかもしれません。もしプログラマー目的以外の無料のwiki教科書が欲しい方は、現状では、自分で本wikiに加筆するか、あるいは本書『ゲームプログラミング』とは別に新規Wiki執筆を検討していただきたい。 == ゲームを作りたいな、よし、ゲームを作ろう。でも… == ===しかし自分の本当の目的ってゲーム作り？=== 「ゲームを作りたい」と思ったのなら、まずはあまり細かい難しいことは考えず、実際に作り始めてみるのが一番いいと思います。もちろんプログラミングについてほとんど何も知らないのなら、ある程度の勉強は必要ですが、ある程度の知識があるのなら、プログラミングの技量や知識の充実を気にするよりは、実際にゲームの完成を目指してプログラムを書いてみるのが一番いいようですよ。その過程でプログラミングの学習や経験は積んでいけますしね。JavaScriptやPython、無料でプログラミングに取り組める環境も、今現在では充実しています。 しかし、ゲームをプレイするのが好きだからと言って、ゲームを作る、までが本当に自分が好きかどうか、試しに少し作ってみたら、少し考えてみるといいですね。 例えば読者の中には、「私はRPGがすき」という人も多いでしょう。 RPG が好きという事はおそらく、よくRPGの題材になる西洋ファンタジーのストーリーや世界も好きという場合が多いでしょう。そして一方で現実のコンピューターRPGで魅力的に提供される、イラストや音楽が好きという場合もあります。 実際のゲーム業界の人々も、ゲームを彩るイラストレーションや音楽がいかに重要な要素かを語っています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P85</ref>。 さて、ここで問題なのですが、「ゲームを作りたい」と貴方が思っていたとして、あなたが本当に作りたいのはゲームなのか？あるいは本当はイラストが描きたかったり、音楽を作りたいのではないか？ …というのは、ゲームというのは総合的な分野ですから、イラストや音楽はその要素として確実にありますが、それ以外、プログラミングやシナリオなど、様々な創作や創造が必要で、全ての作業量はかなり多いものになるでしょう。 そしてゲーム、コンピューターゲームにはゲーム独自の世界観があって、現実や小説や映画とは違う、独特の法則に支配された世界を作る必要があります。ある意味リアリティを持たない、リアリティから外れた世界です。だから、小説のようなリアリティにこだわるなら、ゲームは不向きかもしれません。 ゲーム作り始めの時点では、これらの判断は明確でなくても勉強目的でも構いませんが、しかその内「自分は本当にゲームを作りたいのか? Yes or no?」という疑問への答えが必要になるときがくるかもしれません。 試しにゲームを作ってみて、もし自分の本当の目的がゲームでないと分かったなら、それ以外の活動に移るのも、取る道の選択肢でしょう。 ;給料は安い 職業として、商売としてゲームを作る場合、ゲームプログラマーの給料は洋の東西を問わず、安い事が知られており、書籍などでも言及されています。たとえば『CAREER SKILLS　ソフトウェア開発者の完全キャリアガイド』（ジョン・ソンメズ 著）という欧米人のプログラマーの書いた本には、アメリカのゲーム業界ですらハードワークの割に賃金が低い事が記載されており、もし給料の高い仕事につきたいならウォールストリート（※米国の金融ウォール街のこと）のための仕事をするべきだと書籍中で指摘しています。 日本でも同様にゲーム業界の報酬が低いことは知られており、多くのゲーム会社の伝記漫画でも、よく語られています。 アニメーション業界と比べたら、ゲーム業界のほうが報酬が高いことは事実かもしれませんが、これは実は恐ろしいことに、アニメーション業界の報酬が異常に低いだけで、アニメーション業界よりはましだけど、結局は…というのが現状でしょう。 === 同人ゲーム以外の発表の場 === 2001年ごろの日本はネットを活用した同人ゲーム黎明期、フリーゲーム黎明期で、実験的な時代でもあり、多くのイラスト愛好、創作者や音楽創作者がゲーム制作に手を染めていたようです。この頃、まだイラスト投稿サイトや小説投稿サイトといったものは無かったか、あったとしても小規模でマイナーなものでした。 しかし2010年のあたりから各種の投稿サイトが普及したことにより状況は変わり、むしろ現在では、小説やイラストを発表したい人はそのジャンルの投稿サイトに直接アクセスしたほうが早く、そのためゲームを通して発表するのは人によっては廻り道かもしれません。 それをわかったうえで、それでもゲーム制作に身を投じるかを考えた上で、「よし、自分はゲーム制作をしよう」と思えるなら、ゲーム制作をするのが良いでしょう。 実際、今現在の作曲家やイラストレーターは、ゲームに関わったとしても、専門家として楽曲やイラストを提供するという立場に過ぎない場合もあり、自分自身が主体になってゲーム制作をする人は、プロアマ問わず少数派のように見えます。 同人ゲームの世界でも現在は（2021年頃に記述）、プログラマー系の作者が圧倒的に多い様です。 しかし、専門外の人だからこそ、メディアミックス的な意外な視点で新しいものが作れる可能性もあるかもしれません。コピーライター、作家の糸井重里が、マザー2の企画にたずさわった例もあります。しかし、あくまで「可能性」であり、成功はけっして保証されてはいないので、読者の自己責任でお願いします。 今現在のゲーム専門学校のカリキュラムはプログラミングが主体です。CGの授業は、週に2時間程の様。一方でゲームCG、或いは、一般CGに特化した学科もある様です。 あるWikibooks編集者Aは、もしイラストを描きたいなら、イラストの世界で描くのが安全、と考えています。ゲームプログラミングについては、プログラムを書ける人は絵コンテも描けそうだし、基本的にある程度の作図的なイラストを描ける人は多いだろうから、別にプログラミングに専念しろとは思っていません。 さて、読者がゲーム制作を職業として目指すのかどうかはともかく、とりあえず、ゲーム業界の状況を知っておくのが有用でしょう。 結局商業界の状況が権威をもってその分野を支配しているのがこの社会の基本なので、趣味でも職業でも、業界周辺のことを知っておくのは得ることが多いはずです。 文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか忘れる必要があることを説いています<ref>大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81</ref>。著者は、最初はグラフィッカーでしたが、しかしプランナーに転職したので、グラフィック関係の技能は仕事では「忘れて」しまった、という内容を述べています。ただし、比喩的に「忘れる」とは言っていますが、実際には忘却し無くなってしまったわけではなく、仕事では時間の都合により両立できないので、グラフィック関係の技能は例え話で「忘れた」、のであり、現実にはグラフィッカー時代に培った観察眼をプランナー時代の現在でも活用している、と、書籍中では述べられています。 このことは職業、あるいは技能とは一般的にそういうもの、と考えることができるでしょう。 {{コラム|漫画家大塚志郎のアドバイス| 同人ゲーム界では、ゲーム制作と、イラストまたは作曲などを一人で兼ねている作者も、ある程度は居ます。一方ネットの世界には様々な簡単に利用できるフリー素材もあるので、イラスト作画や作曲をしなくてもゲーム制作は可能ですよね。 一人でイラスト作画や作曲をしながらゲーム制作をするのはある意味マルチタレントだとも言えますが、現実にその創作をしている人たちは、かなり年長のこの分野の熟練者が多いようです。若い19歳ぐらいの頃に、それらマルチジャンルを両立するのは、一般にかなり困難なことだと思われます。 漫画家の大塚志郎は、漫画家を漫画創作の手本にするならデビュー時代を手本にするのが良い、と、漫画家向けの技法の教育漫画で語っています。 大塚は、漫画家の人生のうちで、これからデビューを目指している新人に近い境遇にあるのは、ヒット後の漫画家の生活状況ではなく、まだ無名･マイナーな時代の態度・生活だ、と描いています。成功後の熟練した漫画家より、若いデビュー直後の作家をお手本にするのがいいだろう、という主張ですよね。 さて、それでもデビュー時代から複数ジャンルの同人活動を均等に兼業する意思が硬いなら、それはそれでひとつの考え方ですが、上述のリスクを知っておく必要があるでしょう。 }} ===ゲーム業界は産業のエンジン役?=== かつてはゲーム産業が、日本のIT産業やデジタル家電産業の中心的・牽引（けんいん）役であった時代がありました。しかし、2010年以降、この考えは当てはまらなくなっています。 PlayStation2あたりまでの時代は、経済評論誌の未来予想でも、「もしかしたら今後、家庭用の据え置きゲーム機がパソコンの代替品として、家庭のリビング家電の標準品になるかもしれない」という予想があった。ゲーム産業がそのような牽引役として、経済界から期待されていました。ソニーが国産CPUをプレステ2〜3に搭載したり、WindwosのマイクロソフトがXBOXでゲーム機に参入したり、そういう時代です。 しかし2020年代の今は違います。結局、2020年代のゲーム機に使われてる技術や部品は、パソコン用の部品や技術の流用、ゲーム機のCPUも、今やインテルなどのパソコン用CPUをゲーム機でも使っています。 もはや現代は、ゲーム業界は、産業のエンジンではないようです。 ですから今現在、新しい技術に興味ある人は、ゲームにこだわらず、直接的にその技術を勉強し改良したほうが近道です。 たとえば、インターネット技術を使って何か新しい事をしたいなら、ゲームを作るよりもwebアプリやサーバーwebサービスを作るべきだし、目的のネットワーク用ソフトウェアをそのまま制作したほうが早いし確実です。 古い経済知識の先入観にとらわれず、無理にゲーム制作にこだわらないほうが、自分自身の技能やキャリアも開けていくでしょう。 2010年に出版された商学書籍『メイド・イン・ジャパンは終わるのか』には、「しかしながら、ファミリーコンピュータで世界に攻勢をかけ、その後圧倒的な強さを誇っていた日本の家庭用ゲーム産業も、90年代末からはその競争力にかげりがみえはじめた。日本の国内市場は伸び悩み、成長率は鈍化傾向にある（図表7-3）。」とあります<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.263</ref>。 その「図表7-3」の統計値によると、 :ファミコン発売の1993年には2268億円、 :スーファミ発売の1990年には2430億円、 :プレステ1発売の1994年には3882億円、 :1995年には急成長して4769億円、 :1997年には4795億円で、ほぼこの頃がピークであり、 :2000年には3768億円にまで低下（プレステ2の発売年）、 :2005年には3151億円まで低下（XBOXの発売年）、 である。（青島らが『レジャー白書』、『情報メディア白書』、『月刊トイジャーナル』、『CESAゲーム白書』などをもとに作成した図表の統計値です。） <!-- ところで前編集者Sさん，これって正確には何の数字，金額なの?それを後で書き足しておいてほしいんだけど…。あれかな？一年のこの国のゲーム産業の売上高？ --> また、2010年の時点の商学研究では、1997年を境に、ゲームソフト市場で競争する企業数が増加傾向から減少傾向に転じた<ref name="m289">青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.289</ref>、とも言われています。 書籍『メイド・イン・ジャパンは終わるのか』にも、引用文「家庭用ゲームは日本がその本格的立ち上げを主導し」<ref name="m91">青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.91 </ref>と書かれているぐらいで、1990年代は日本のインパクトが強かったようです。 なお、携帯電話の分野で、日本は国際的な地位を喪失したのに対し、デジタルカメラとゲームは「現代」（参考文献の著作時2010年ごろ）でも日本が主要な地位にある<ref name="m91" />。 {{コラム|ゲームが産業の牽引役だと語った人物| 1998年頃、アニメ評論家の岡田斗司夫が、未来予想の一貫として、「これからゲーム機が、（パソコンではなく）家電の中枢になるだろう」というような内容の未来予想をしていました。たしか、岡田の著書『東大オタキングゼミ』（自由国民社、1998年）で、このような未来予想が読めます。岡田の東大での講義を加筆修正してまとめた書籍なので、実際の講義はその数年前に行われていたのだろうと思います。 岡田の東大での講義は東大生のその後の進路、官僚や大企業のビジネスマン達に大きな影響を与えただろうし、若手新進評論家として、この国の政治・経済人達も、その言論を参考にしただろう。 実際、2008年（リーマンショックあたり）くらいまでの日本の家電業界の投資は、ソニーがゲーム機のCPUを作ったりと、岡田の予想を参考にしているような面もありました。 ですが実際の2001年以降の家電業界の結果は予想とは少し外れました。まず :* そもそも、冷蔵庫もエアコンも全然デジタル化（IoT化）されず、家電のほとんどが外部からのコンピュータ制御を必要としない状況。 :* 個々人が持ち歩いているデジタル家電は、携帯ゲーム機ではなくスマホになった。 :* パソコンは多くの家庭にいまだにインターネット用端末などとして残り続けている。 一方岡田は東大オタキングゼミで、98年当時の時点で任天堂が莫大な現金資産（たしか数千億円ほど）を持っていることに注目しています。 一般の大企業は、現金ではなく株券や不動産などの形で資産を蓄えています。しかし任天堂は、銀行口座の現金だけで数千億円という、非常に資金力の高い企業でした。今や日本を代表する世界的なゲーム大企業になっています。 また、日本だけでなくマイクロソフトのXBOXなど、実際に欧米の企業も昔はコンピュータゲームが産業の牽引役だと思って、先をこぞってゲーム機に参入していたわけでもある。岡田の未来予想は、決して根拠の無いものではなかったのです。 }} {{コラム|読書について| ゲーム業界と関連のない文献も、この教科書では出典として書かれていますが、これはこの頁の主要執筆者Sが、多量の市販本を読む以外に知的活動の方法を知らないことと、自分自身の文章の権威と信頼性を、著名人の威を借りて確立したいからでしょう。 ゲーム業界を志望するなら、ゲーム業界人の書いた本は少なくとも何冊かは読んでおくといいでしょう。 ネット上では、業界人ではないのにもっともらしく書かれた文章も多いですし、おそらく本Wikiの執筆者にも本格的なゲーム業界関係者は一人もいないでしょう。 業界人達のSNS発言ではなく、現代では書籍があるので、実際に書籍を手に入れて読むのがいいですね。書店で販売される書籍というのは、けっして著者だけの意見でなく、編集者や校正者、周辺の職業人達が査読をして、内容の信憑性を確認しています。 <!-- ニュース解説者の池上彰（いけがみ あきら）が、たしか2011年くらいのテレビ番組で言っていたことだと、編集者Sは言っている。 --> 何十冊も本を読むよりはプログラミングを書く実践のほうが重要でしょう。 『ゲームデザイン プロフェッショナル』著者であるFGOクリエイターも、ゲーム開発の書籍は読んでおくべきだと忠告しています<ref>『ゲームデザイン プロフェッショナル』、P234</ref>。また、ゲームデザイン本で学んだ知識は、ゲーム業界以外でも仕事術として活用できます。たとえば上司への業務報告の報告・連絡・相談（ホウ・レン・ソウ）などの考え方は、ゲーム業界でなくても活用できます<ref>『ゲームデザイン プロフェッショナル』、P332</ref>。 いっぽう、もし最新IT技術を勉強したいなら、読むべきは、ゲーム制作の解説本ではなく、そのIT技術の解説本など、そのものの書籍を読むほうが近道でしょう。 }} ===ゲームプログラミングは面白い。しかし、そんな楽な事ではない。=== ここでいう「プログラミング」とは、C言語などのプログラム言語による開発のことです。RPGツクールなど開発ツールによるゲーム制作の話は原則していません（本書『ゲームプログラミング』はあくまでプログラミングのための教科書です）。 さて、よくネットや、あるいは日常でも（C言語などによる）「ゲームプログラミングは簡単だよ。イラストやシナリオのほうが難しい。」、などという人がいますが、この発言の心は、「俺はプログラミングもイラストもシナリオも出来る凄い男だぜ。しかもプログラミングなんて簡単だし、むしろクリエイティブなイラストやシナリオの方に精力を費やす偉い奴だぜ^^」という、世間に良くいる武勇伝、自慢を語りたがる、インチキ親父が吹かしているだけなので、あまり真面目に取り合わないのが正解だと思います。 まず第一に、不当にプログラミングの価値を貶めている言説ですよね。 Visual C++またはVC# 、あるいは Direct Xなどを使ってプログラミングすることは、そんなに簡単なことではないでしょう。 ゲームプログラミングの入門書などには、初心者でも理解できそうな比較的簡単ないくつかのサンプルコードがありますが、それは初心者でも簡単に書けそうな技術だけを抜粋してるという、あくまで例外です。 RPGならたとえば、ドラクエ3のような戦争画面の行動順を処理するソート機能をつくるだけでも一苦労ですし、ほかにも道具・アイテムなどの自動整理をはじめとする標準機能を作るだけでも一苦労です。 決して上手い人のサンプルコードをコピーアンドペーストをして終わりという訳にはいかず（そもそも現状そのようなサンプルコードがネット上に無いですが）、もし仮にサンプルコードがネットに公開されていても、自作品に組み込む際にさらにそれをデバッグ（決してテストプレイの意味ではなく、実際にコード修正が必要になります）しなければならず、プログラミング言語の理解が必要です。 ゲームのプログラミングは決して楽ではないし、仮にもし楽だとしたら、じゃあゲーム会社のプログラマー職の人の仕事は何なんだ・・・という疑問につながりますよね（デマを言ってる人は、この疑問を脳内に都合よく無視しますが）。 ツクールやエディタのような制作ツールを使えば、C言語的なプログラミングは不要ですが、それはそのツクールなどのツールを開発している人達にプログラミングを肩代わりしてもらっているだけなので、決して「ゲームプログラミングが楽」、ではないでしょう。楽だというなら、じゃあツクール開発元の角川書店およびその発注先ソフトメーカーのプログラミングが楽だとでも言うのか・・・（デマを言ってる人はこの疑問を無視します）。 そもそもコンピューターゲームというのはプログラミングがなければ成立しないのですから、そのプログラミングの価値を貶めて平気な人は、コンピューターゲームにかかわる資格はないでしょう。 == ゲーム制作に関する留意点 == === IT的な留意点 === ====プログラミングなしでも同人ゲームを作れる==== 自分でゲームを作る際、必ずしも、C言語などプログラム言語で記述する必要はありません。 プログラミングをせずに、ほぼマウス操作と会話メッセージなどの文章のキーボード入力だけでゲーム開発をできるようにするソフトウェアが、有料または無料で発表されています。 たとえば、RPGを作りたいなら、日本で発表されているソフトでは、『[[w:RPGツクール]]』や『[[w:WOLF RPGエディター]]』などのように、RPG製作に特化された開発ソフトがあり、大幅に開発の手間を減らせます。なお、『RPGツクール』は有料製品です。『WOLF RPGエディター』は無料ソフトです。 アクションゲームを作りたいなら、『[[w:アクションゲームツクール]]』があります。これらツクール製品は有料製品です。（なお、かつて『[[w: 2D格闘ツクール2nd.]]』というのがありましたが、しかし現在ではサポート切れのため、今現在の市販の十字キーコントローラーが初期設定では動かない、一部のボタンしか使えないなど問題点があります。） また、ノベルゲームを作りたいなら、フリーソフトの『[[w:吉里吉里Z]]』などがあります。吉里吉里Zはソースコードが公開されており、オープンソースになっています。 :なお、とりあえず「ゲーム開発ツール」と呼びましたが、じつは呼び方は特に決まってはいません。「ゲーム制作ツール」と呼ぶ場合もあります。ゲーム開発ツールのことを「ゲームエンジン」と言う場合もありますが、開発ツール以外のゲーム用ランタイムのことも「ゲームエンジン」という場合があります。 :本Wikibooksでは、とりあえず、ツクールや吉里吉里シリーズやウディタ（WOLF RPGエディター）などのソフトの呼び方は、まとめて「ゲーム開発ツール」または「ゲーム開発ソフト」と呼ぶことにします。 C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合の選択肢になるでしょう。 既存のゲーム開発ツールの仕様に不満を感じる場合に、「じゃあ自分でプログラムして作ろう」となり、プログラミングが必要になるわけです。 なお、上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動きません。MacやLinuxで動作するゲームを作りたい場合は、別のソフトウエアを使う必要があります。 既存のゲーム開発ソフトを使わずにプログラムを組んでゲームを自作する場合、必ずしも既存のツールのような、ゲーム作品と開発ツールが分離された仕組みを再現する必要はありません。 一般的に初心者が、ゲーム開発ツールを作ることはほぼ不可能です。初心者は開発ツールを作ることは考えずに、まず1本、とりあえずゲーム自体を完成させてみましょう。開発ツールを自作したいのなら、まず先にゲーム1本を完成させたあとに、あとから開発ツールとゲーム作品の分離などに取り掛かるのが推奨です。 ==== 商業ゲームの開発言語 ==== 基本的に、現代の商業ゲームは、C言語で開発をする。 ただし、ファミコンの古いゲームは、アセンブラで開発されていた。ファミリーコンピューターからスーパーファミコンに至るまで、OSは搭載されていない<ref name="m289" />。 ではいつからC言語がゲーム開発に使われるようになったかというと、商学の学説では、プレイステーション（※ おそらくプレステ1？）の頃からだろう、と考えられている<ref name="m289" />。ただしこの時代でも、処理速度の高速化のためにアセンブラにアクセスする開発チームも少なくなかった<ref name="m289" />。 また、プレイステーションのOSは独自仕様である<ref name="m289" />。 カプコンなど一部の企業は、OSによる開発ではなく、移植性を高めるために自社製の内製フレームワークを用いて開発する。カプコンの場合、2010年頃は「MTフレームワーク」という自社製フレームワークを用いて開発を行っていた<ref name="m289" />。 {{コラム|ゲーム用のメーカー独自プログラミング言語について| ゲーム開発ソフトには、ゲーム開発用の独自のプログラミング言語を持っている場合があります。このような機能の実現方法は、原理的には、ファイル入出力の関数を使い、テキストファイルの文字列を読み取って、文ごとにプログラム動作を設定・実行している、と、考えられます。インタプリタは、このような方法で作られています。 ゲーム製作ソフトでの独自のプログラミング言語はたいてい、コンパイル作業を必要としないので、おそらくインタプリタ方式でしょう。 基本的にWindowsの場合、実行ファイルに変換するには、Visual Studio というマイクロソフト社の配布している開発環境が必要です。 Visual Studio が開発環境を提供していない独自言語は、たいてい、インタプリタ方式となると思われます。 コンパイラ方式に比べて、インタプリタは処理速度が不利なので、適用できるジャンルや用途が限られます。たとえば3Dアクションゲームには、インタプリタ方式は不向きでしょう。 これらの独自言語を使うにしても、自分自身で独自言語を作りたいと思うとしても、この教本ではまず、既存のプログラミング言語を使ってゲーム制作を開始することを推奨します。 }} ====ゲームのプログラム言語の歴史==== ゲームを書くために利用される言語は多岐にわたっています。歴史的にはゲーム業界でも、[[C言語]]や、特に計算機のスピードが重要になる場面では[[w:アセンブリ言語|アセンブラ]]を利用してプログラミングを行うことが普通に行われていました。<!-- (文献)→-->そのため、ゲームプログラミングは通常のプログラミングと違った技能が必要であるように思われていました。 現在では計算機がある程度速くなったことや、ゲームプログラムの開発を複数人で行うことでテクニカルなプログラミングが避けられるようになったことにより、ゲームプログラミングは他の一般のプログラミングと同じような課題だと見なされています。 しかし、特にアクションゲームなどのリアルタイムでの画面書き換えが必要なゲームで、プログラムのスピードが重視されることは変わっていません。また、コンピュータの性能があがるにつれ、それらの性能を全て引き出すように表現手段が変化してきたため（[[w:3次元コンピュータグラフィックス|3D]]、[[w:ポリゴン|ポリゴン]]などを参照）、状況によっては複雑で特殊なプログラミングが必要になることもあります。 ===== 初心者が使えるプログラミング言語 ===== ゲーム開発において、一般にゲームショップなどで流通している商業ゲーム作品において、現在よく利用されているプログラミング言語として、[[C言語]]、[[CPlusPlus|C++]]、[[Java]]があげられます。 Windowsの3DエンジンのDirectXは、主にC++を想定しています。なので負荷の高いアクションゲームを作りたい場合、Visual C++での開発が安全でしょう。 しかし、ネット上のフリーゲームでは、C++以外の言語が使われることも、よくあります。 さいきんゲームエンジンとして有名なUnityは、言語としてはC#の文法を採用しています。 [[w:携帯電話|携帯電話]]向けのゲームでは[[Java]]が利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります（[[w:iアプリ|iアプリ]]、[[w:EZアプリ (Java)|EZアプリ]]、[[w:S!アプリ|S!アプリ]]などを参照）。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。 市販の書籍では、Pythonによるゲーム開発を紹介した出版物もあります。ただし Python は原理的にインタプリタ方式であるために処理速度がC++に劣り、アクションゲームなど負荷の高いゲームを作る事を目指している場合は、将来的にはPythonからC++への装備変更が必要になるかもしれません。 ===== ゲームに適さない（だろう）言語 ===== ;Flash関係 例えば、かつて Adobe の Flash が、ブラウザで動かせるゲームを作る際に、よく使われていました。このようなwebブラウザ上で動くゲームのことを一般に、「ブラウザゲーム」と言います。ただし、現在ではFlashは廃止の方向です、すでにほぼ廃止されているといっていいでしょう。また、現状では、ローカルPC環境でのゲームをJavaScriptで作るのは、アマチュア段階では困難です。JavaScriptのアマチュアゲームと言う事例を聞きません。 ;JavaScript なお、JavaScript はクロスプラットフォームですが、しかし、セキュリティ上の理由などから、いくつかの機能（たとえばファイル入出力）がwebブラウザ上では使えないようになっており、そのため、JavaScript だけでゲームを作るのは、初歩的なゲームを除くと、かなり困難です。（おそらく、オンラインゲームでは、サーバー側でPHPやサーバサイドJavaScriptなどの別プログラムが走っていると思われます。） セーブ機能の必要なゲームを作る場合は、JavaScriptでの開発は選択肢にない（セーブの実装には、JavaScript国際規格にはない非標準仕様を使いこなす必要があり、かなりの技術力を要するでしょう）。 =====ブラウザゲームの初歩的な原理===== 商品として流通するようなゲームや、高度な機能を持つブラウザゲームを作ることはとても難しく、このページでは手に負えません。そこで、このページでは、初心者が練習用につくるゲームを例に記述します。 webブラウザだけで動くのがブラウザゲームです。ブラウザゲームを作るのに使う言語の第一選択肢はJavaScriptです。サーバー側の処理が必要ならPHP,Python,Perl,Javaなどの言語の出番でしょう。 「ネットワークゲーム」は「ブラウザゲーム」とは意味が違います。 「ブラウザゲーム」は、パソコンにwebブラウザさえあれば、ネットワークに接続していなくてもゲームプレイできて、最後、クリアまでプレイできる作品もあります。 しかしネットゲームは、ネットワークに接続しないと、ゲームを開始することさえ不可能です。つまり、サーバの提供するゲームが「ネットワークゲーム」「ネトゲ」です。 もしPHPやPerlなどでゲームを作る場合、普通はネットゲームになる筈なので、作者がサーバを構築して提供する必要がありますし、プレイヤーにはゲーム中にサーバに接続する環境が必要になります。提供者は、サーバを用意したり、保守管理する必要がありますよね。サーバーがダウンしてしまうと、プレイヤーがゲームをできなくなります。 「PHP ゲーム」などの単語でネット検索したり、あるいは書店でプログラム言語の書籍や解説サイトを見ると、ときどきPHP・Perlなどの言語でゲーム開発しているものもありますが、一般的なダウンロード型のゲームとは違う筈なので、気をつけてください。 {{コラム|ソケット通信、ほか| コンピュータプログラムからインターネットに通信するには、いくつかの方法がある。 C言語の場合はOSの提供するソケット通信といわれる機能を使う方法、 JavaScriptにあるHTTP通信の機能を使う方法、 などがあるだろう。 ただし、JavaScriptでゲームを制作するのは、セキュリティ上の制約などからセーブロードが標準的方法では困難など、とても制作が難しい。 よって本セクションでは、C言語にソケット通信を組み込むことの概要を説明する。 ゲーム制作初心者がソケット通信までする必要はないが、将来的には知る必要があるかもしれない。 本wikiではWindowsの場合については 教科書『[[WinSock]]』、 macやLinux / Unix や BSD の場合は 教科書『[[Unixソケットプログラミング]]』 で説明している。 Windowsとそれ以外のOSとで、ソケット通信の仕様が微妙に異なる。 ソケット通信では文字コードの問題がある。手元のパソコンの文字コード設定は、通信相手方の端末には反映されない。 Windowsの日本語版では、伝統的に Shift-JIS といわれる文字コードが使われてきたが、海外のWindows端末は日本の文字コードにあわせてくれないし、macやLinuxやBSDも同様に日本には合わせてくれない。 簡単な対処法として、ゲーム中では日本語を送受信しない、つまり半角の英数字と記号だけを送受信する、という道はある。 会員登録などのためにどうしても氏名や住所などの日本語を使う必要がある場合、PHP・Pythonなどサーバ言語に対応した「フレームワーク」があり、そのフレームワークが最初から日本語に対応、もしくは設定を少しいじるだけで日本語対応するので、それを利用すれば効率的かもしれない。 ゲームとは別途、サーバー側にフレームワークをインストールして、会員登録時にサーバー側でそれを使うようにすればいいだろう。 しかしゲーム内では日本語の扱いは非常に難しい、限定されるという事になるだろう。 C言語のプログラムにサーバサイドの言語・システムを組み込むのは難しいから、ネットゲームではどこかでソケット通信に頼ることになるだろう。 市販の本を探しても、そもそもソケット通信の書籍自体がめったに見当たらないし（ほんの少しだけ出版されている）、もし見つけても全く文字コードの問題の解決方法は紹介されていない（2021年現在）。 }} ====プラットフォ－ム==== ;ライセンス料 一般に、プレイステーションや任天堂のゲームを開発するには、専用の機材が必要であり、そのため、ソニーや任天堂とライセンス契約しなければいけない<ref>『ゲームプランとデザインの教科書』、P.107 </ref>。 その契約に際して、ライセンス費用または料金と呼ばれるものを、ゲーム機開発会社の任天堂、ソニーに支払う必要があります。 現在でもソニーや任天堂のゲーム機用のソフト開発・販売には、ライセンス料が必要です。少なくともPS4やニンテンドースイッチのパッケージソフト開発には、「ライセンス費」が必要<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.120</ref>。 なお、書籍『ゲームプランナーの新しい教科書』によると任天堂やソニーのようにゲーム機を作っている会社のことをハードメーカーと言います。つまり、ゲーム機のハードメーカーにライセンス料を支払うという仕組みになっています<ref>『ゲームプランナーの新しい教科書』、P20</ref>。 また、スマートフォン向けアプリは、プラットフォーム使用料が掛かります。 書籍『ゲームプランとデザインの教科書』によると AppleStore, GooglePlayともに売上げの30%とのこと<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.121</ref>。その他のプラットフォームも、大体同じとのことです（参考文献の著作の時点では）。 Google やAppleのようにプラットフォームを提供している企業のことをプラットフォーマーと言います<ref name="gp244">吉冨賢介『ゲームプランナー入門』、P244</ref>。 昔からゲーム機のライセンス料は有料で高額であり、ソニーや任天堂の収益源のひとつになっている<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.267 </ref>。一方、パソコンゲームにはライセンス料が無いのが普通です<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.283 </ref>。 なお、ハードメーカーでなければプラットフォーマーでもないゲーム会社のうち、製造から販売までを手がける会社のことをパブリッシャーといい、たとえばカプコンやコナミやセガやスクウェア・エニックスやバンダイナムコなどがパブリッシャーです<ref name="gp244" />。 実は、必ずしもパブリッシャーが開発を手がけるとは限らず、スマホ向けアプリなどではディベロッパーといわれる開発専門の会社に委託している場合もあります<ref>吉冨賢介『ゲームプランナー入門』、P245</ref>。 ;ポリコレ規制 Apple社のAppStore向けのスマートフォンアプリでは、アップロード後に、公開前にAppleによる審査があり<ref name="g139">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.139</ref>。、審査は欧米基準です。 GooglePlayは、公開前の審査はないが公開開始後に海外基準で審査されるので、それに違反していると配信停止になります<ref name="g139" />。 海外プラットフォームで販売・配布したい場合、「ポリティカル・コレクトネス」（政治的な正しさ）といわれる、海外の公序良俗の基準に配慮する必要があります<ref>『ゲーム作りの発想法と企画書のつくりかた』、P.235</ref>。 欧米の判断基準が、アジア諸国やアフリカの生活習俗に合致しない場合も多いのですが、欧米のIT大企業はその欧米基準での規制が政治的に正しいと考えているでしょう。「日本では、少し考え方が違う」と言っても、通用せず規制される場合も多い。 ゲームだけでなくテレビアニメでも、漫画ワンピースの海外アニメ版では、主人公側の若者がタバコを吸っているシーンをアメ玉に作画を変えられたり、ドラゴンボールに出てくるミスターポポという肌の真っ黒なキャラクターの肌を青く書き換えたり、色々な例があります。 ポリコレとは関係ない事例ですが、TVアニメーションのポケットモンスターで主人公のサトシ達がお握りを食べているシーンで、アメリカ版ではドーナツになっていたことがあります。これは、国による食文化の違いを示していますよね。 ===プロトタイプ=== ゲームでは、曲や絵が良くても、ゲームとしては今ひとつ面白くない、という事は起こり得ますよね。 ですからむしろ、商業的なゲーム制作では、イラストは簡略なものを使ったうえで、プログラム中心の試作品（プロトタイプ）をいくつか作り、その中でゲームとしての面白さがあるものを、取捨選択したうえで商品化を考え、その後イラストや楽曲を詰めて完成度を高めていく、と、いう制作過程を取るようです。 書籍『ゲームプランナー入門』（吉冨賢介 著）によると、商業ゲーム界では、企画書に書かれたゲームが本当に面白いかどうか確認するために、「プロトタイプ」が作られます。プロトタイプの段階では、プログラマーと、企画の意図を考慮するためプランナーも関わります。<ref name="gp17">吉冨賢介『ゲームプランナー入門』、P17</ref> イラストレーターは、プロトタイプの前段階あたりでイメージイラストを提供し、スタッフ間の共有イメージを作ります<ref name="gp18">吉冨賢介『ゲームプランナー入門』、P18</ref>。そしてプロトタイプ進行中は、グラフィック案の提案をしていきます<ref name="gcw56">蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P56</ref>。サウンドも同様、プロトタイプでは、曲調を固めていく段階です<ref name="gcw56" />。 :※時々あるトラブルとして、マイナーな同人ゲームや零細メーカーのゲームで、背景イラストや脇役キャラクターなど目立たない部分で他社のイラストが使われていることがあるようです。おそらく試作用に流用したイラストが、そのまま製品に混入したのでしょう。こういうトラブルがあるので、他社イラストの使用は試作であっても避けるべきです。 ;実装検証 プログラマーは、そのゲームでコアになるプログラムやシステムやミドルウェアについて、プロトタイプ段階で実装検証を済ませておく必要があります。プロトタイプより前の原案の段階では、利用するミドルウェアの洗い出しをして、出来る範囲での基礎実験をしておきます<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P54</ref>。 ミドルウェアによっては使用料が発生するので、その点を事前に調べておく<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P55</ref>。 プロトタイプのうち、張りぼての例えば画面だけの物等を、「モックアップ」といいます。一方である程度遊べる状態まで作っているものを、「プレアブル」といいます<ref>STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日初版第2刷、P251の図</ref>。 ゲームデザイン本ではよく「プロトタイプ」という表現が用いられるので、本ページではこの言葉を使うことにします。 {{コラム|商標権等| 知的財産権には著作権・商標権・意匠権などがありますが、商標権は特に強い権利であり、気を配る必要があります。 意匠権とは、建物や工業製品の外観に関する権利なので、ゲーム制作ではあまり気にする必要はないようです<ref name="gpd135">川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.135</ref>。 「特許権・実用新案権」と「商標権」は、事業者によって国に登録されている権利で、かなり強力な権利なので、気をつける必要があります。 特許権や実用新案権とは、大まかに言えば、技術的な発明に関する権利です。商標が登録されているかどうかは、特許庁の『特許情報プラットフォーム』というwebサイト<ref name="gpd134">川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.134</ref>で確認できます。 商標をトリッキーな意図で登録する人も多く、自社でビジネス展開をする気がなかったり、他社の商品などでまだ登録されていない物を申請したり、そういうやや不正な登録申請でも認可されてしまう場合も多いです。 また、商標は業種のジャンルごとに分かれているので、たとえば携帯電話のジャンルが新たに追加された時代に、過去のゲームの商標を登録した人がいました。そのため携帯ゲームを出せなかったり、商標を買い戻したり、取り戻すための裁判をするのに時間とお金がかかってしまったり、様々な問題が発生します。<ref name="gpd134" /> 著作権は、登録の必要がなく、著作をした時点で発生する権利です。 『ゲームプランとデザインの教科書』によると、こういう事柄にまだ慣れていない人によくあることなのですが、他人の個人サイトやSNSで公開されていた絵や曲などを、許可なく勝手に使う事例があるようです<ref name="gpd135" />。 二次利用を許可されてない著作物は素材として使えません。 そして見落としがちなのが、フォントの著作権です<ref name="gpd135" />。フォントにも著作権があります。 フリー素材と書かれていても、商用販売が禁止されている配布形態のものもありますので、気をつけましょう。 }} {{コラム|アイデアの権利。アイデアとは盗まれるのか、盗むのか?| 商業ゲーム作家たちの、2022/1時点でのSNS発言によると、業界全体でみられることですが、会社外部の人がアイデアを一方的に投稿してきて、会社で作った作品にそのアイデアと類似点があったら、アイデア使用料を要求してくる、そのような問題に悩まされているようです。 そこでゲーム会社側では原則、 :送られてきたハガキやメールは、まずクリエイター以外の事務系の人間が読む。 :もしハガキなどにアイデアがあった場合、そのハガキを処分。 などの方策を取ると言われています。 また、偶然や何らかの理由でアイデアが一致してしまった場合に備えてのリスク回避として、事前に会社のウェブサイトなどで「弊社にアイデアが送られてきた場合、そのアイデアは弊社のものになります」のような宣言をしている会社も多くあると言われています。<!-- （以上、作家のSNS発言やそれを紹介したサイトの取材などのまとめ.）←出典を消すなってS氏はやたら云うんだけど，そんな重要な事かね?もちろん全くなくて，いい加減な事書いていいと言ってるわけではないけど… --> ここで前編集者は娯楽産業の世界には厄介な消費者がいると言及しているけど、この前編集者自身がこのWikibooks で異常なまでに厄介な参加者なんだが、そろそろ人のふり見て自分を返り見るべきだと思うな。 法学的には、著作権法はアイデアを保護しません（『アイデア・表現の二分論』と言います）。 そして前編集者はアイデアに関して権利をどうこう言う人間を無知だと書いているけど、自分は至上の賢人だと思ってるようだね。 そしてこの人物は他者を愚弄する時は必ず自分の意見ではなく、権威ある人がそう書いたから、出典だからと宣う。 出典は岡田斗司夫氏の著作『東大オタク学講座』や『マジメな話』だそうだ。 まあ岡田氏ならかなり過激なことを書くのは事実だろうが，この前編集者S はその悪徳をさらに10倍に高めてこのWikibooks に記述する地獄のように厄介で無知で馬鹿な人間だ。 }} 任天堂『ゼルダの伝説 ブレス オブ ザ ワイルド』は、プロトタイプの段階ではイラストや音楽を組み込まずに（イラストは、代わりに大きなドットの塊などで代用する）作られている事がゲーム業界見本市イベント CEDEC 2017 で公開されています<ref>https://game.watch.impress.co.jp/docs/news/1078888.html 2020年11月25日に閲覧して確認</ref>。 プロトタイプの段階では、画像や音楽は発注せず、骨組み的なプログラムだけで、そのゲームのアイデアが「はたして本当に面白いか？」を、実際に社内の関係者にプレイさせてみて確認します。 因みにプロトタイプに関しては『[[高等学校情報/その他の技術的な話題#プロトタイプ開発]]』の記述も参考になる。 ここでいう「プロトタイプ」（試作品）とは、コンピュータプログラムのゲームとして動作するのが前提です。映画製作でいう絵コンテ試写のように、ゲームの試作では、なるべく早期に第三者が試作ゲームを遊べるように作っていく必要があります。 プロトタイプという言葉を使用すること自体が妥当かどうか。まず、書籍『ゲームプランとデザインの教科書』で使われている<ref name="gpd350">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.350</ref>。 ニコニコ動画の経営者、川上量生が使っています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.38</ref>。川上は角川書店も買収したので、おそらくそこ（カドカワ・RPGツクール販売元）でも使っているでしょう。 ゲームのプロトタイプの基本姿勢は、「汚く作って、やりなおす」です<ref name="gpd350" />。もちろん最低限のプログラムの知識、勉強は必要ですが、あまり知識収集や理解充実を気にするより、実際に作ってみることを優先したほうがいいようです。チーム制作をしている場合はプロタイプは赤ん坊であり、そのチームで育てていこう、我々の子供だという意識で接しているようです<ref name="gpd350" />。 勉強に関しては、汚くてもいいからまず工夫して作ってみると、何を勉強すればいいかが見えてきます。 英語では「quick and dirty prototype」という言葉があります<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.349</ref>。 書籍『ゲーム作りの発想法と企画書のつくりかた』によると、シナリオライター志望者が企画書やシナリオ案をメーカーに送りつけても、あまり効果的ではないようです。 それよりゲーム形式でシナリオを書いてしまうのがいいようで、「CHR:ヒロインA(私服)、表示」のような文章を織り交ぜて構成していくのが推奨<ref>『ゲーム作りの発想法と企画書のつくりかた、P.140</ref>。 参考文献のその章では、シナリオライター志望者に向けて語られていますが、プログラマーを目指すならどうすればいいでしょうかね。 プログラマー志望なら、サンプルゲーム、サンプルプログラムを作ってしまうのがいいかもしれません。 1990年代、週刊少年マガジンに不定期掲載していた読みきり漫画『ゲームクリエイター列伝』では、カプコン社のゲーム『バイオハザード』を扱った『バイオハザードを創った男達』の際、制作過程でゲームデザイナーが大幅な作り直しを判断して進行させた、という描写があります。（ただしWikiboooks一編集者の記憶、詳細はあいまい）。 のちの、ゲーム評論家の阿部広樹の評によると、むしろそれは劇的な大きな決断ではなく、ゲームデザイナーの日常の普通の仕事ではないか、と語られています。 どんな肩書の人間だろうと、すでに決まって進行していた方針をひっくり返すのは、かなりのストレスのある判断で指摘になりますが、一般に漫画や映画、あるいはNHKの仕事に関するドキュメンタリーでもそうですが、職業や職業者の物語では、過剰に対象を美化し、劇的な演出によって関係者を称賛し、英雄視する傾向があるように思います。 {{コラム|アイデアはアイデアで価値がある。でも、せっかくなら、それを試作して、形にしてみよう。| ゲーム業界人広井王子は書籍のインタビューで、自分の社長としての人材評価は「0点」から始まる「加点法」だと語っていたようです。 『ゲームデザイン プロフェッショナル』著者も、文脈は違いますが「加点方式で物事を考える」と述べています<ref>『ゲームデザイン プロフェッショナル』、P224</ref>。 正直インチキなゲーム業界人の点数勘定などには全く興味ないが、そんな話とは全く別に、ゲーム制作の上で、実際に動く簡単なプロトタイプを作ってみることは間違いなく有意義な事でしょう。 アイデアはアイデアとして、思考や思想の展開としてありますが、それを具体的な形にしてみることは非常に楽しくエキサイティングで、意味ある活動ですよね。 }} 仕様書や設定資料を超えて、誰もが遊べる試作品は、意味のある企画行為でしょう。前編集者は、時間軸・動きの制作意図の明確化、という言葉を使っています。もちろん短くまとめること自体もなかなか難しいのですが、工夫を凝らして、ゲームプログラムを完成させることが重要な経験であり、思考の具体化でもあると思います。 ===アルファ版=== アルファ版はプロトタイプとは違うもので、その後段階で、ゲームの全体像が分かる一部分を、商品に準じた形で作ることです<ref name="gp17" />。 アルファ版でもそのゲームが本当に面白いかどうか検証がなされます。サウンドやビジュアルは商品に近いほぼ完成化された形で取り込みます。 アルファ版の使用の結果、プロジェクト中止の決定がなされる場合もあります<ref name="gp18" />。 ベータ版とは、会社によって意味が多少違いますが（たとえば『ゲームデザインプロフェッショナル』と『ゲームプランナ－入門』とでも微妙に違う）、おおむね、とりあえずのゲーム、最初からエンディングまでのほぼ完成状態をひととおり遊べる制作物です<ref>『ゲームデザインプロフェッショナル』、P170</ref>。 細かいバグ修正はこれらの段階では後回しにします。 基本的に :プロトタイプ→アルファ版→ベータ版→調整→デバッグ の流れですね。 ===プロトタイプ制作に必要な予備知識=== ====数学は後回し==== ゲーム制作の作り始めにおいて、必要な数学や物理の予備知識は、それほど多くありません。 文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、数学や物理の習熟に拘って、それに多くの時間と精力を費やして勉強するよりは、3Dの勉強などで必要を感じたら、そのつど、その分野の数学や物理を学ぶのが効率的だと述べており、また可能なら実際にプログラミングでその理論を試してみると具体的に理解をしやすいと述べています<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P88</ref>。 ====C言語の予備知識は入門書1冊+αで十分==== C言語を使ったゲームは、予備知識はそれほど多くないので、あまり難しいことは考えず、まず実際にプログラムを書いて作ってしまう事優先にするのが正解なようです。 市販のC言語入門書で、配列や関数などの一般的な機能を一通り習得したら、あとはVisual C++ で映像出力とキーボ－ド入力のみを、1～2週間ほど勉強、そしてVisual Studioを起動してゲームを作り始める。 うまくいけば数か月以内に、パソコン用の非ネット通信のゲームを作ることができるでしょう。 ただ、ゲームプログラミングを試みる人は、必ずしもゲーム制作のみが絶対的な唯一の目標ではない可能性もあるので、それぞれの立場に応じて、座学を取り入れてみるのもいいと思います。 == 作業リストを作る == ===作業リストの制作開始の方法=== さて、ゲームを作る時は、アイデアを頭の中だけに置いておくのではなく、文章に書きだしてみましょう。 そして、壮大な長大なアイデアではなく、1週間～1ヶ月ていどで成果の確認できそうなアイデアだけを書いてみましょう。 次にそのアイデアを、実際に動作するプログラム、ソフトウェア（つまりプロトタイプ）にするために、具体的などんな機能を持ったプログラム（簡単なものでよい）を制作しなければいけないか、自分のやるべきことのリストを、箇条書きで作ります。<ref>https://www.youtube.com/watch?v=J5FCZG7dfEY 2020年3月17日に閲覧</ref> IT界ではこういうリストを「ToDoリスト」（読み: トゥードゥーリスト）とか「タスクリスト」といいます。このページではむしろ日本語で、「作業リスト」と呼んでみましょう。 さて、このリストを作るときは、作業項目は具体的かつ単純な目標に分割します。ですから例えば RPG の戦闘システムを作るときは、 *「戦闘システムを作る。」 と、あいまいに総体的に書くのではなく、具体的に、 *戦闘画面のメッセージ表示欄および標準メッセージを作る。 *「戦う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは後回し。） *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 という風に、作業項目を細かく分割していきます。 こうすることで、作業がひとつずつ比較的に簡単な要素に分解されていくので、楽になります。また、バージョン管理ソフトを使って管理している場合も、上記のような作業リストの分解をしておけば、各バージョンの概要を書く際にも作業リストの項目が転用できるので、一石二鳥です。 予定日は書かないほうがいいように思われます。スケジュールを管理したい場合は、別にファイルを作るといいですね。 そして書き出した項目を優先順位で並べたら、最初の作業リストは完成です。 ===作業リストの更新=== プログラミングする前に作業リストを眺めて、そして上の項目から実際に作業を開始しましょう。 そして一つの項目を完成させましょう。 そして作業項目がひとつ終わったら、「【完了！】」等、そういう情報を、項目の前または後ろにつけます。備忘のための記録ですね。 たとえば、 *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 こうします。 以前の記述を残したまま、その作業が終了したことを示しておくわけですね。 また、もし追加の作業が必要になったら、たとえばダメージ計算システムを作るために、ランダム計算が必要になって、自分がそのプログラム言語でのランダム計算に詳しくないなら、たとえば *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 ::※3行目に追加されています。 と、必要に応じて項目を追加します。 さて、これから行う作業を検索しやすくするため、たとえば '''やることリスト''' *Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 '''完了した作業''' *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） の様に完了した項目を後回しにしたり、或いは *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *（現在→） Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 のように、（現在→）、を追加するのも良いでしょう。 つまり作業の記述をそのままに、どこまで進展しているかが分かる等に書き足していくわけですね。 ==プロトタイプ制作における創作面の検討事項== ===ゲーム性=== 「ゲーム性」という概念があって、これがあるからこそゲームは面白く、魅力的だと考えられています。 プレイステーション開発元のソニーもこれを重視していますし、一般的に多くのゲーム愛好者、関係者たちもその考えに同意するでしょう。 ではゲーム性とは何か? ゲームのジャンルにもよりますが、「駆け引き」や「戦術」、これが「ゲーム性」だとよく言われます。 『ゲームプランとデザインの教科書』によると、ゲーム性とは、シューティングやアクションでは「対戦の駆け引き」、RPGでは「戦闘と物語の介入」、シミュレーションゲームなら「戦略性」だそうです<ref>『ゲームプランとデザインの教科書』、P152</ref>。 ただし上述の書籍によると、1990年代は今よりもゲーム性とシステムが重視されていたとの説明があるので、裏を返せば2010年以降の現代では、ゲーム業界ではゲーム性の重視の比率は1990年代よりも減っているかもしれません<ref>『ゲームプランとデザインの教科書』、P302</ref>。 『ゲームプランナー入門』（吉冨賢介 著）では、ゲーム性とは「課題や挑戦の仕組み」であると結論づけています<ref>吉冨賢介『ゲームプランナー入門』、P36</ref>。そして、この達成感こそが「ゲームならではの面白さ」だと述べています。 ;アクションパズルゲーム「I.Q」 メディアクリエイターの佐藤 雅彦氏（「だんご3兄弟」や「ピタゴラスイッチ」等を手掛けている）が、初めてかかわるコンピュータゲームで、ソニー・コンピュータ・エンターテインメントとの共同企画で、のちに「I.Q」（1997年にシリーズ第一弾を発売）と呼ばれるシリーズに携わった時、プロトタイプが全くゲーム性のないものになってしまい、それをプレイしたソニーの幹部陣の顔色が非常に曇ってしまったようです<ref name="br67">川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.67</ref>。 ここでの悪い反応、薄い反応の理由がわからなかった佐藤氏が、階段の踊り場でソニーの新人に尋ねてみると、「それが、あの、ゲーム性がないっていうか・・・」と言われたと出典の対談集に書かれています<ref name="br67" />。 基本的に佐藤氏は、プロトタイプの企画を提案しただけですが、ソニーにはプロトタイプを作るための部署があるらしく、1～2ヶ月かけてそこでプロトタイプが作られたようです。 この問題の責任が誰にあるかは、大した重要な事ではありませんが、商業作品としてプロトタイプを作る以上は、どこかの段階でゲーム性を意識して、プログラムに盛り込む工夫が必要になるでしょう。 ===ゲームの見た目とは？=== ふつうゲームのプレイヤーは、まず最初にそのゲームの「見た目」を判断し感受するでしょう。ですからその見た目のインパクト、興味を呼び起こす構成が必要になります。 例えばスーパーファミコンRPG『新桃太郎伝説』では、開発当初はドラゴンクエスト5 のようなマップ画面のトップビューUIでしたが、開発中にクォータービューの他社製RPGが発売されて高い評価を得たので、マップUIを（トップビューではなく）クォータービューに作り直したようです。このことは攻略本『新桃太郎伝説 究極本』に開発裏話として書かれています。 一方現在でもこの方向の試みは重要なようで、書籍『ゲームデザイン プロフェッショナル』の著者は、他企業の製品の画面と、自社の製品を目で見比べる分析方法で、自分たちの製品のUI の問題を見出しています<ref name="gdp199">『ゲームデザイン プロフェッショナル』、P199</ref>。 割と素朴で単純で即物的な見た目、「かっこいい」とか、「ぱっと見派手」等の要素が非常に重要なようです<ref name="gdp199" />。 商業としてゲームを作る以上は、ペイしなければ企業も事業の継続も維持できませんから、考慮せざるを得ない問題ではあります。 == ゲーム開発ツールを使う場合 == ====開発ツールのライセンス条件==== ゲーム開発ツールのなかには、そのツールで開発したゲームソフトに義務として「この開発ツールで開発したソフトウェアは、ソースコードを必ず公開しなければならない」などの条件をつけている場合があり、このような条件を「開示義務」（かいじ ぎむ）または「ソース開示義務」などといいます。 ソース開示が嫌な場合は、開示義務のあるツールは使わないのが正解ですね。 ゲームに限らず、ソース開示を義務としている開発ツールは多くあるので、ライセンスには気を配る必要があります。 「有料ソフトの販売を禁止」とか「アダルト作品の開発は禁止」などの条件をつけている場合も、ありえます。 ですからゲーム開発において、ツールのライセンス条件の確認は、非常に重要です。 {{コラム|GPLライセンス違反| GPL（ジーピーエル）というライセンスがあって、Linuxなどのオープンソースで使われています。このGPLを組み込んだプログラムは、ソースを公開しなければいけません。 ですから、ソース公開したくないプログラムには、GPLソフトウェアは組み込めません。 ゲーム業界でも、GPLライセンスのソフトウェアを組み込んでしまったために、呼出し元ソフトウェアでのソースコードの一部を公開することになったゲームがあります。2005年頃、『ToHeart2』という美少女ゲームが、xvidというGPLソフトを取り込んだ疑惑によって、GPL違反の疑いでソース公開になりました。（[[w:ToHeart2#GPL違反とソース公開]]） GPLでも、たとえばLinuxサーバ上でソース非公開のアプリを動かすように、GPLのソフトウェアを非公開ソフトとは独立した状態で使う場合は、ソース公開の必要はない、と、考えられています。（これが必要有りとなると、オンラインのプログラムやネットゲームは全てソース公開しなければならなくなり、非合理な結果になる。） 特定のプログラム自体に、GPLソフトウェアのコードを取り込んだ時、ソースコード公開が必要になります。 }} {{コラム|BSDライセンス他| オープンソースの中には、どのような利用法であっても、利用者にソース公開を求めないライセンスもあります。BSDライセンスとMITライセンスはソース非公開で利用できます。 ゲーム制作ツールの吉里吉里Zは、修正BSDライセンスで公開されています。 もしライセンスのことがよくわからない、またはライセンスの学習に時間をかけたくないなら、オープンソースのツールを使うなら、BSDライセンスを使うのが安全です。 }} [[w:DXライブラリ]]は、GPLでもBSDライセンスでもありません（DXライブラリ説明書「DxLib.txt」には、どこにも「GPL」とも「BSD」とも書いていない）。DXライブラリは単にソースコードが公開されていて、著作権者の「山田 巧」氏が著作権を保持しているオープンソースなライブラリです。 このように、ネット上でソース公開されているソフトウェアには、ライセンスの複雑な解釈を嫌ってか、「BSD」や「MIT」などのライセンス条件を名乗らないオープンソースソフトウェアもあります。 {{コラム|自作ソフトでソース開示| 昨今ではオープンソースやフリーソフトウエアの発展などの背景もあり、「自作ゲームのソースコードやソースファイルも開示しよう」と思うゲーム作者もいるかもしれません。 然しソースコードを開示していることが原因で、トラブルに巻き込まれる場合もあるかもしれません。自分の作ったゲームのコードが悪用され、トリッキーないたずらや嫌がらせ、誹謗中傷などを受ける可能性も全くないわけではありません。 そこでライセンスに、利用による損害に対する保証が無いことを明示するのは、ある程度有効でしょう。大抵の著名なフリーソフトウェアライセンスには、この条項があります。他者の悪意を完全に防ぎ失くすることは難しいのですが、ある程度の対策は見出されていますし、自身でも見出していく必要があるでしょう。 }} ====開発ツールを使用しないという事==== 下記の理由（機能制限および移植性の悪さ）の問題から、あまり大規模な作品は開発ツールでは作らないでおくのが安全です。 大規模な作品の場合、Visual C++ などでコードを書いて開発することを推奨します。 =====機能制限===== ゲーム開発ツールを使う場合、そのツールにもよりますが、「○○ができない」、つまり特定の目的を果たすための機能を持っていない場合があります。 Visual Basic や Visual C++ には普通にある関数でも、開発ツールには無い場合も多い。 また、もし、いったんはゲーム開発ツールを使って目的の機能を持ったシステムを作ったとして、さらなる機能をそのシステムに追加しようとするときに、大幅な作り直しが必要になる場合があります（拡張性の悪さ）。 システムがモジュール化されていても、そのモジュール部分では大きく改変する必要がある場合もあるでしょう。 ですからゲーム開発ツールによるゲーム制作では、あまり大作を作ろうとしないほうが安全です。開発ツールで作る作品は、比較的に小規模な作品に、とどめておくことを推奨します。 Windowsの場合、本来なら Visual C++ などを使って、プログラム文法のいろいろな事に留意しながらプログラムを書きますよね。開発ツールを使う場合、 Visual C++ のコードを書かずに、ほぼマウス操作だけでプログラムを作ろうとしているわけですから、何かしらの制限があります。拡張性の悪さは、プログラム文法などの学習の負担を減らすためのトレード・オフのようなものですね。 =====移植性の悪さ===== また、もうひとつの問題点として、C言語への移植性の悪さがあります。 ソースコードが公開されていない開発ツールの場合、異なる開発環境にゲームのソースファイルを移植するのは、ほぼ不可能です（仮に、開発ツールのランタイムを模倣できたとしても、著作権などの法的な懸念が生じる可能性あり）。 ゲーム開発ツールで作ったソースを、Visual C++のソースに置き換えるのは、簡単にはできないし、ほぼ全面的に新たに書くことになるでしょう。 ==イラストレーター、デザイナー== ゲーム制作、業界において、イラストや音楽を作る部署、人物は、まとめて、"アーティスト"と呼んでいるようです。 ゲーム界の場合デザイナーというのは、プランナーやディレクターのことであり、管理職的な設計者のことで、美術的なクリエイターではない。design という英語には、機械建築の設計という意味もあります。 映像関係、画像系のアーティストはグラフィッカーと呼ばれることもあります。ムービー担当者、特にゲーム界では3D-CGの制作者をアニメーターと呼ぶことが多いようです。アニメーション業界では主に、手描きの原画、動画マンをアニメーターと呼びますが、最近は3D-CGアニメーション映画も多いので、すこし状況が変わっているかもしれません。 ゲーム業界とアニメーション業界、各会社企業、過去と現在で、「原画」「仕上げ」「絵コンテ」等、一般的な作業に関する言葉が、それぞれの状況で微妙に違った意味で使われることも多いですね。 …ところで前編集者はわざわざこの項目を作ったうえで、色々な場所での言葉の意味の違いを、クドクドと自分勝手な分かりづらい説明で長々述べた後、「混同しないように気をつけましょう。」なんて馬鹿馬鹿しい言葉で締めているんだけど、この人物の意図はどこにあるのだろう? 例えばデザイナーというのは一般的に、造形作品、図案、意匠を考案する人のことを言うのだから、ゲーム界の外の人間が多少その業界内での意味を取り違えても、それほど致命的なミスでもないし、罵倒、愚弄されるいわれもなければ、好き放題にその相手を罵倒、愚弄していいわけでもない。間違えて使っている人を見たら、その都度やんわりと教えてあげればいいだけじゃあない? だいたいその世界に現実に身を置いたら、そこでの言葉の意味、使い方なんて自然に覚えるものだし…。 それを得意げにこれが違うあれが間違いといちいち理屈書いて、いい気になって威張っているこの人物は何者なのだろう? 現編集者が思うには、この人物は、学問、知識、知恵、科学とは何かという事を、根源的に取り違えている、のだろう。 ==操作性== 操作性について、親指と人差し指<!-- ←ここ，中指って書いてあったけど，こっちだよね? -->だけでボタンプッシュなどの操作ができるように作成するのが基本です。中指、小指、薬指はコントローラのホールドに使うぐらいです。人間工学的に、小指や薬指は力が弱いので、微妙な操作には向かないことが知られています<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.48</ref>。 一般的にゲームプログラミングでは、 # プレイヤーからの入力を扱うことができる。 # ゲームが提示する内容を表示することができる。 入力と出力、この2点が機能として必要になります。 プログラミング言語とプレイヤーからの入力については歴史的にも、あまり変化がありません。言語では主に[[C言語]]、[[C++]]が用いられる。[[w:携帯電話|携帯電話]]向けのゲームでは[[Java]]が利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります（[[w:iアプリ|iアプリ]]、[[w:EZアプリ (Java)|EZアプリ]]、[[w:S!アプリ|S!アプリ]]などを参照）。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。 パソコンゲームでは、プレイヤーからの入力には通常、キーボードかマウスを利用します。他に[[w:ジョイスティック|ジョイスティック]]や[[w:ゲームパッド|ゲームパッド]]が利用される場合もあります。家庭用ゲーム機では[[w:コントローラ|コントローラ]]が利用されることが多いのですが、[[w:ニンテンドーDS|ニンテンドーDS]]や[[w:Wii U|Wii U]]では[[w:タッチパネル|タッチパネル]]、[[w:Wii|Wii]]では複数の入力機器が提供されることが発表されています。各種入力機器をプログラムから扱う手法自体は、普遍性があり、入力機器ごとに大きく変化しない、と、考えられています。[[w:デバイスドライバ|デバイスドライバ]]、[[高等学校情報B]]には、プログラムから周辺機器を扱う方法について多少の記述があります。 画面表示のうち、3Dの表現は割合難しく、ある程度の数学（高校、あるいは場合によってはそれ以上）の理解が必要でしょう。2Dに関してはプログラムの面では、さほど難しい部分はありません。 ==処理速度の問題== 基本的にプログラミングでは、関数を使って、処理をコンパクトにまとめ、定数ではなく変数で柔軟性のある操作をすることが求められますが、ゲームの場合は、この構造のせいで処理速度が低下することがあります。 現在のCPUの性能、速さはかなり高くなってはいますが、プログラム処理は無限に煩雑化できますから、やはり高度な処理を短時間でなすことが求められます。特にゲームは、リアルタイムの反応のタイミングが非常に重要ですからね。数学の指数計算についての雑学で、「新聞紙を42回おりたたむと、月に届く距離になる」というものがあります。(新聞紙の厚さ)*2^42、ですね。もっとも新聞紙の物性から言って、ほぼ不可能な操作ですけど^^;;。コードの内容、組み合わせによっては、このように計算量が指数関数的に膨大になってしまい、処理速度が非常に遅くなってしまう場合があります。 ですが、このセクションで後述するように、関数を用いる場合の解決策（※概要:あとでdefineやinlineに置き換え）があるので、プログラミングの初期のほうは、とりあえずバグを未然防止するために関数を活用するべきでしょう。 1980年代頃のファミコンなど古い時代のゲームでは、ストレージ容量（ハードディスク容量のこと）が、ボトルネックでした。「容量不足でイベントをいくつか削りました」と、当時のRPGなどのゲーム作家が述べるのは、ストレージ容量の不足のことですね。ただ当時のファミコンはROMカセットでハードディスクは無いので、まさにストレージ容量という言葉が適切でしょう。 しかし2010年以降の現代では、ボトルネックになっている要因は、ストレージ容量不足よりも処理速度です。 ゲームプログラミングに要求されるコード特性は、科学計算ソフトウェアや金融プログラミングなどの手法とは異なります。情報工学・情報科学で適切とされる「構造化プログラミング」などの歴史的に発展してきたプログラミング・パラダイムの理念とは反するようなコード開発方針になる場合もあります。しかしゲームプログラミングに限らず、限定されたハードウェアで特定の結果を速く得るためには、様々なトリッキーな手管が必要になるでしょう。 ;ツクール等制作ツール RPGツクールの制作元のカドカワ（アスキー社→エンターブレイン社→カドカワ（かつての「角川書店」） ）では、PRGツクールでのアクションゲーム開発は推奨していません。アクションゲームの場合は、同じカドカワの「アクションゲームツクール」で制作するよう、薦めています。 アクションゲームとターン制RPG では要求される特性が大きく異なり、なかには、ほぼ対立しているような性質もあります。 ツクールやウディタでも、万能にあらゆることがスタマイズできるわけではなく、その制作ツールの特性に依存しますし、主に処理速度の低下しない部分についてユーザが創作できるようになっているでしょう。 多くのRPG制作ツールはマップ操作や戦闘画面の基本システムのルーチンそのものは、あまりカスタマイズできません。画像や音楽は挿入できますが、例えば戦闘プログラムなら、「コマンド」の命令文など一部の派生的な部分だけが独自に作れる程度でしょう。 ですから、ツクールでどうしてもアクションRPGを作りたい場合、基本システムの改造はかなり困難だろうし、別途、アクションRPGのような動作をするマップイベントを作成する・・・ぐらいでしょうね。 ツクールやウディタでターン制RPG以外のジャンルを制作するのには、実質的には限界があり、さまざまな制約が生じます。 ;具体的な手法 初期段階では関数や変数を活用してプログラミングし、処理速度を高める必要がある箇所にだけdefineマクロ等を用い別の方法に置き換える。C++ならinline関数という前処理命令もあります。 通常の関数で記述していったソースコードを、あとから一括変換などでdefineマクロやinline関数などに置き換えることは比較的に容易です。 また、関数を経由しているので、マクロを使った場合でも比較的にバグが混入しづらくなっているかもしれません。（defineなどの前処理命令マクロは、用いるとバグを発見しづらいので、なるべくマクロの利用を避けるべきなのが、ゲームプログラミングに限らないプログラミングの定石です。） 一方、まったく関数を使ってないコードを、あとからdefineマクロなどに手作業で置き換えるのは、なかなか面倒です。 最終的には一括変換で置き換えることが出来ますから、途中の段階では、処理速度を気にせず関数を使うのがいいでしょう。 なお、defineマクロは、値の置換以外には用いないのが、プログラミングの定石です。このため、たとえば黒色RGB値の<code>10,10,10</code>といった配列にdefineマクロを使うべきかどうか悩みますが、とりあえずなるべく値周辺にだけdefineマクロを適用するようにするようにするのが良いでしょう。いっぽう、一般の命令文をdefineマクロで置き換えるのは、避けるべきでしょう。 たとえば、処理に0.5秒ほどの時間の掛かってもかまわないような場所は、どんどん、関数に置き換えていっても良いかもしれません。 アクション性のないゲームなら、関数をぞんぶんに活用できます。 ターン制RPGやシミュレーションゲーム、アドベンチャーゲームなど、関数を活用しやすいでしょう。 一方、アクションゲームなどでキャラクター操作中のコードのように頻繁に使って、しかもそのゲームの中心的なコードなら、そこは最終的には関数にしないほうが良いかもしれません。 このように、ゲームのジャンルによって処理速度に対する必要な水準が異なりますので、プログラミング時における関数などの利用の方針も異なります。 以上のように、何でも関数にすることは避けるべきです。関数は処理速度の問題がありますので、必要性のある部分だけ関数にするべき。関数を使わなくても、for文やif文などのブロックの構成を適切に組み合わせることで、コード中のmain関数以降の部分でコード共通化できることは色々とあります。 「共通性のあるコードだから」といって、大して長いわけでもないコードを関数に置き換える事は、速度維持には寄与せず、ゲーム制作のプログラミングとしては、悪手となるでしょう。 ===2Dの画面出力=== 画面出力の場合も入力機器の場合と同じで、これらを操作する方法はOSごとに異なっています。先ほどあげた GTK+, Qt, SDLなどのライブラリはクロスプラットフォームの画面出力を提供しているため、これらを利用することで全てのプラットフォームで動くプログラムを作ることができます。<!--画面出力を扱うためには近年の[[w:ビデオカード|ビデオカード]]の発展についても見る必要があります。しかし、ビデオカードの機能は2次元の描画に関してはあまりあらわには見えないので、この話題は3次元の描画を行うときに再び戻ってきます。--> *[[ゲームプログラミング/ブロック崩し]] *[[ゲームプログラミング/画面出力]] ==目次== === ジャンル別のプログラミング手法 === ==== 3Dグラフィック ==== * [[ゲームプログラミング/3Dグラフィック]] * [[XNAを使用したシンプルな3Dゲームの作成]] ==== RPG ==== * [[ゲームプログラミング/RPG]] ==== アクション ==== ※未作成 ==== パズル ==== ※未作成 ==== シミュレーション ==== ※未作成 === ゲームのデバッグ === * [[ゲームプログラミング/デバッグ]] === 入力 === OSの種類によって、キーボード入力やマウス入力の受け付けのさいのプログラムの書き方は違う。 Windows API での具体的な手順は『[[ゲームプログラミング/入力]]』で説明する。 === ゲームエンジン ※未完成 === * [[ゲームプログラミング/Unity]] ※リンク先ページの編集者が現状ではUnityの著作･調査を放棄中なので、調べ物としては役立ちません（2021年12月19日に本文を記述）。 === 非プログラミングのゲーム製作の関連作業 === ==== バランス調整 ==== *[[ゲームプログラミング/バランス調整]] 厳密にはプログラミングの話題ではないが、ゲーム製作では必要な知識なので、サブページで説明する。 :※ゲームデザインに関する記述をここに集積し分離したい、という編集者の意図もある。 ==== ゲーム用の書類の書き方 ==== 説明書や仕様書（しようしょ）の書き方については、『[[ゲームプログラミング/書類]]』で解説する。 == 未分類 == ===Visual C++プログラムによる文字画像の出力=== Visual Studio付属のフォームデザイナ（VSの用意するGUI自動作成ソフト）によるGUIオブジェクト作成では、RPG用には使いづらい。いや、ひょっとしたら上手に使う方法はあるのかもしれないが、様々な理由で難易度は高い。 そこでまず、Visual C++で、フォームデザイナをなるべく使わずに文字や映像を出力する方法を考える。 選択肢は、幾つかある。 1.フォームデザイナを1つも使わない方式 *Windows APIで入力していく方法。(Wikibooksに『[[Windows API]]』の入門書があります。) *DirectXで入力していく方法。DirectX自体はWindowsAPIを利用している。 2.1つだけフォームデザイナのパネルを使う方式 *フォームデザイナで「パネル」という画像表示機能のコンポーネントを一つ用意して、そのパネルで表示する画像をゲーム内のストーリーなどに応じて切り替えるだけで、すべての画像表示を行う。 フリーソフトでゲーム用ライブラリの『HSP』はWindows API を呼び出す仕組みになっています(HSP関連のサイトを見ると、Win APIプログラミングの解説をしている場合もある)。 フリーソフトでゲーム用ライブラリの『DXライブラリ』は Direct X を呼び出す仕組みになっています。そして、ゲーム開発ツールのひとつであるウディタのソースコードは、DXライブラリとVisual C++ を使って書かれていると、作者が公表しています（ただしソースコードは非公開）。しかし、ウディタを用いたRPGプログラミングでは DXライブラリによるコーディングはしない。ウディタにはコード入力の機能は無く、マウス操作や、キーボード操作、キャラ名称や会話文などのテキスト文字や数値の入力のみに対応している。 ===乱数=== そもそも乱数とは何かという問題があるが、それは高度な数学的な議論になるだろうから、我々はその問題には深入りできない。 ゲームにおける乱数的な処理では、事実上ランダムな値にならず、演出や調整のためにアルゴリズムが介入している場合も多い。例えばゲーム中のくじで「外れ」続くと、当たり確率が変動し、次からは当たりやすくなるアルゴリズムなども良く使われる。<ref>『ゲームプランナー集中講座』、P232</ref>。 ゲームは娯楽であり、実用目的のシミュレータではないし、アルゴリズム介入で、確率的にもいんちきが多いので、あまり厳密なランダム性が問題になることは少ないだろう<ref>『ゲームプランナー集中講座』、P231</ref>。 例えばさいころというのは典型的な乱数器だし、ゲームにもよく使う物だろう。 無印C言語には標準的乱数関数 rand()があるが、これを乱数発生に使うことに批判的な意見もあるし、機能もやや不足していると見れる。 Windows64bit では int rand(void) の出力は 32bit 整数だろう。まず stand関数で初期化してから rand()を呼ぶごとに疑似乱数が帰ってくる。これの複数回の連なりが乱数列だね。帰ってくる値は0 以上 定数RAND_MAX の値以下。 例えばさいころの数値が欲しいなら、rand の返り値を6で割った後、余りに1足せば、とりあえずそれらしいものはできる。 RAND_MAXは rand()の属性として定数が与えられているだけだから(Windowsで0x7FFF)、この値の変更はできない。 まあこれでもそこそこいい加減な乱数として機能するだろうが、最近ではもう少し改良された、質の高い乱数関数もある。 また、改良された乱数関数は、乱数の範囲も指定できるから何かと使い勝手が良いし、バグを防ぐ効果もあるのだろう。 <syntaxhighlight lang="cpp"> Random^ saikoro1=gcnew Random();// Random^ でRandomクラスの変数を作っている。gcnewはインスタンスをつくるための演算子。 int detame; detame=saikoro1->Next(1, 7);// Next メソッドで「〇〇以上△△未満」の乱数を指定できる。「->」はメンバーアクセス演算子。 MessageBox::Show("目"+detame.ToString()+"が出ました。"); </syntaxhighlight> ↑例えば上述のコードは前編集者が示したものだが、これは .NETプログラミングですね。.NET のSystem::Randomクラスを使っている。.NETのクラスは普通、C#かVisual Basic で利用するので、Visual C++で使えるようにするには結構面倒な手管がいるが、その辺は読者諸兄、ヘルプやネット情報を参照して、適宜辿り付いてほしい。 C++ の場合はむしろ、 #include <random> を宣言してそこで使える関数を使用するほうが簡単でしょうね。この場合でも、乱数としての精度も高いし、帰り値の範囲指定もできる。 ===画像のちらつき=== 画像がひんぱんに変化するアプリでは、画面が、ちらつく事がある。画面のちらつきは、ゲームのように、画像を凝視するアプリでは、かなり利便性を損なう。 キャラクターが1歩移動するだけで、画面全体がちらついたりする場合もあり、かなり、プレイヤーの不満になる。 これは、ダブルバッファ（「裏画面」と、良く言われる）という技術で、解決を図る。 Direct Xの用語では「スワップ チェーン」と呼んでいる。 .NET Framework開発環境の C++や C#でもダブルバッファの機能があると解説されている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。 しかし前編集者が実験したところ、この機能を有効に使って確認することはできなかったとの指摘がある。ひょっとしたら何らかのマイクロソフトの解説に間違いがあって、工夫次第では利用できるかもしれないが、少なくとも今現在のこのページでは、その問題に関するリファレンスは提供できない。 そこでやはり、以前の項目と同様、Win32 API または DirextX の利用をこのページでは考えたい。 前編集者は、.NET Framework のフォームデザイナでは、ちらつき自体は解決できそうだが、グローバル変数の共有が困難だったり、アプリ内から終了コマンドが使えない、などの難点があると指摘している。 ただ現編集者はこの2点に関しては、解決策はあると思うが、しかし特に調査はしない。 前編集者は、.NETプログラムでゲームを作る難点をいくつも上げているが、おそらくどれも、.NET の仕様や全貌に精通すれば解決できるように思えるが、そもそもその全貌がかなり広大なので、解決の道のりは長いだろう。 そこで少なくともこのページでのWindowsゲームプログラミングは、Win32 API を利用したものになるだろう。 ==セーブ、ロード、データベース== ===セーブ機能とロード機能の作り方=== ゲームでもシリアライズ機能が必要なことは多いだろう。数値（HPなどの各種パラメータ現在値）や文字列（例えば、プレイヤーの作成したキャラクターの名前）や現在地やフラグ状況などなど、セーブの機能は欲しい。一番簡単な方法は、C言語の fopen 関数のテキストファイル書き込み機能で、テキストファイルとしてセーブすることだろう。 Windows API には CreateFile関数 があるが、テキストファイルでの素朴なセーブは一番簡単で単純なセーブ法だろう。そしてテキストファイルを読み込んでプログラムに各種変数を配置して、ロードとする。 書き込みとしては、一番単純なC言語記法では、fprintf ですかね。C++としての書き込みをしてもいいし、読み込むのも、一番基本的な方法で。基本Cだとしたら fscanf で、この関数でテキストの数値も変数として読み込めるはずですよ。場合によっては atoi関数 で文字列→数値の変換をすることもありますかね。 基本的にデータファイルは、OS もアプリケーションも、テキストファイルとバイナリファイルの２分類で考えるでしょう。でもテキストファイルだってバイナリの集まりなんですが、テキストを扱うファイルだけ特別視していると考えていい。 そして多少それらしいデータを作りたいときは、バイナリファイルで作るという事になるでしょう。 バイナリファイルでもデータとしてのファイルと、OS が機械語または何らかの仮想的な機械語として扱う実行ファイルがある。それらのバイナリは種類に応じて多くは冒頭にファイル識別子の情報があるだろうし、OS や アプリケーション側で工夫を凝らして、特定の条件を満たす場合しか動作しないようにしているだろう。そしてバイナリファイルを扱うときは、セキュリティの安全性も考慮するだろう。 基本的にプログラム側は何でもありだが、識別子の判別その他、ある程度様々な考慮をしないと、困った事態が起こり、プログラマーが責任を問われることも起こるかもしれない。 まあその時はいつものように口先だけで謝り、それでも許してくれなかったら、腹をかっ割いて死んでお詫びすれば、世間の人たちは美事な武士道精神と言って、口々に褒め称えてくれるだろう^^。←もちろんこれは冗談^^;;;。 市販のパソコン用ゲームや同人ゲームでは、テキストファイルではなくバイナリでデータ保存するゲームの方が圧倒的に多いだろう。その方がそれらしいしかっこがつく。ゲーム開発ツール側自体も、そうなっている場合が多い。RPGツクールもウディタも、セーブデータの形式はバイナリ。 テキストデータは基本エディタで開けるが、バイナリデータも内容によっては結構ぐちゃぐちゃの状態で開ける。バイナリデータはバイナリエディタで開ける。バイナリエディタのリードオンリーモードやバイナリビューアみたいなものがあれば、データーを壊さないで結構安全にデータ調査できる。 データ内容を秘匿したければ、バイナリ化だけではなく、暗号化も必要になるかもしれない。 ===機能の整備=== セーブ&ロード機能の実装時には、まずセーブ機能から作るのがやりやすいという。 しかし最終的には関係関数の整備は、ロード機能が基盤となるだろう。 データや変数を、一定のスタイルでセーブして、一方で正しいスタイルでロードする、この機能が必要なわけですよね。 シリアライズされたデータを、型を決めたうえで配置しなければいけないから、ロードのプログラムの方が複雑に、面倒になる。 結局データのシリアライズは、ロード機能が基盤となり、その機能の作りやすさが、セーブ機能の作りやすさも支配するようだ。 == ゲーム中の特殊イベント == *[[ゲームプログラミング/特殊イベント]] RPGやシミュレーションゲームで、1回しか起きない特殊イベントを作りたい場合もありますね。例えば日本の中世の戦国シミュレーションゲームで、「桶狭間の戦い」が3回も起きたら困りますよね。まあ起きるなら起きてもいいけどね^^。信長君には敦盛を3回舞ってもらいましょう^^。 さて、リンク先ではその話題についての叩き台、「こうプログラミングしたら、いいんじゃない？」、という事を説明しています。 ==スケジュール管理== [[File:Tokai Hairo.jpg|thumb|500px|ガントチャートの例:東海発電所の廃止解体工程]] 個人でゲームを作る時にはあまり考慮しなくていいのですが、シビアな仕事の世界では、スケジュール管理表が良く使われます。 「作業責任分担表」（TRM:Task Responcibility Matrix）といわれるスケジュール表から、それをグラフ的に図示したガントチャートといわれる表を作って、その表を見て作業計画を判断する<ref name="gpd65">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.65</ref>。 {|class="wikitable" style="float:left" | 仕事 | 担当 | 状態 | 開始 | 終了予定 | 終了日 |- | 仕事1 | 田中 | 済 | 2021/10/03 | 2021/10/10 | 2021/10/10 |- | 仕事2 | 田中 | 仕掛 | 2021/10/11 | 2021/10/13 | |- | 仕事3 | 鈴木 | 済 | 2021/10/05 | 2021/10/08 | 2021/10/08 |- | 仕事4 | 山田 | 未着手 | 2021/10/13 | 2021/10/17 | |- |} {{-}} ガントチャートでは普通、横軸に日程をとります。 商業ゲーム界でもガントチャートの横軸は日程です<ref name="gpd65" />。 ガントチャートとして図示することで、ボトルネック、リスク要素、直感的にスケジュールの詳細や全体像が理解しやすくなります<ref name="gpd65" />。 スケジュール管理のための、現実的、習慣的な工夫ですね。 このTRMとガントチャートは、IT業界だけでなく建築工事でも使われ、これを利用したボトルネックの洗い出しも、建築学の教科書に記述があります。 住宅の新築やリフォームをする時、建築業者がこの表を提示して、見せてくれることもあるでしょう。 業界人ではなくとも、こういう慣習を知っておくと、得るものがありますよね。 ==ストーリー制作、そして順序== ゲーム界、特に商業ゲーム界では、ストーリーもゲームも全体から作っていくようです。アトラス社（ペルソナシリーズ、女神転生シリーズ、などを手掛ける）では、「ゲーム全体に血を回すのが先」、という言葉が良く言われていました<ref>[https://news.denfaminicogamer.jp/projectbook/191030a/2]2020年12月1日に閲覧して確認.</ref>。 プレーヤーが見たいのは、物語の細部ではなく、ゲーム全体のストーリーやテンポ、総合像である、とは限らないのだが、しかし物語を含む創作物では、全体を見て重視し、そこから作っていくのはある意味王道、常套手段ではあります。 ちなみにやや雑談的ですが、日本の週刊漫画は、その週その週での勢いや読者の興味の引き付けも大事なので、全体がないのに、その場その場で場当たり的に作られた事も多かったようです。 現編集者が聞いたことのある話では、週刊少年ジャンプで連載していた本宮ひろ志氏が、不良少年物の漫画で、敵の不良少年グループと1対1000の喧嘩になり、さあいよいよ対決場に着いて勝負だってところで以下次号にし、そして実は本宮氏はその続きを全く考えていなくて、考えてみたけどどう考えてもどう描いていいかわからない^^;;;、そこで仕方ないのでイライラして近所の酒場に飲みに行き、そしてイライラしたままそこの常連達とあり得ない大ゲンカして^^;;、そのままボロボロになって家に帰って、2時間で次の号の漫画を描き終えた、と、本宮氏自身がメディアで語っていたのを聞いたことがあります。 さて、コンピューターゲームである以上、ゲームのストーリーはシステムと連携、調和したものになるでしょう。 そこで、ゲーム作家として、システムを先に決めた後ストーリー、そういう方法論の作者も多いようです<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.306</ref>。 とにかく商業ゲーム界では常識的に、全体像から攻めていく。 例えばドラマ脚本では、「ハコ書き」という方法がある。全体像に当たる「大ハコ」を記述してから、「大ハコ」→「中ハコ」→「小ハコ」と記述していく<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.184</ref>。 しかし、本当にすべてのゲーム制作は全体から作る必要があるのか、という疑問はありますが、その方法論に従うとすると、 :*エンディングを大まかに先に作る :*機能の実験を簡易でいいので事前にしておく（※プロトタイプの項目を参照） :*使用頻度の高い部分から作る などの工夫を凝らして、常識的な方法を遂行していくことになるでしょう。 或いは、アルファ版（α版）を中盤から作り始めるとか…<ref>吉冨賢介『ゲームプランナー入門』、P17</ref>。α版の製作目的の一つとして、そのゲームが本当に面白いかの検証がある。面白くないと判断したら、制作中止もある。最初からではなく中盤から作ると、ゲームの全体像が見えるので、検証、判断がしやすい。 つまり全体から攻めて、細部やゲームが作られていくわけですから、必ずしも冒頭部から作り始める必要はないわけです。 ;エンディングやラスボス戦闘を早めに作る場合 ゲーム作者にもよりますが、商業ゲームシナリオでは、エンディングを早い時期に作る人も多い<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166</ref>。 システム面についても、先にゲーム全体のクリア条件を決めてから、あとから各ステージの条件を決めていくことが多いようです<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.253</ref>。 エンディングの仮の、おおざっぱなシナリオ、そしてキャラクターの性格付けを先に決めておくと、ゲームの方向性と主人公達が目指すもの、ゲームの全世界像が作者やスタッフに明快になっていきます<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166</ref>。 基本的に商業ゲーム界では、全体→部分と細部、の構成を進めていきます。 ゲームは必ず最後にラスボスと戦う訳では無いでしょうが、その戦いはゲーム中で最も高負荷になるでしょうし、全てのシステムが集積する場面でもあるので、エンディングを先に作ると、ゲームの最大負荷の検証ができます<ref name="yth">[https://www.youtube.com/watch?v=kAUkSNhH410] 2020年8月30日</ref>。 3Dゲームでは、RPGなら戦闘シーン、アクションゲームならアクションシーンが、一般的に最も高負荷<ref>ntny著『ローポリスーパーテクニック』、ソフトバンククリエイティブ、2010年2月16日初版第5刷、P28</ref>。 負荷が高くて処理が落ちないかどうかも、この方法で確認できます。 まあ全ての物語は最後の最後が一番の見せ場ですからね。 中盤は重要性が低い…訳では無いが、少し手を抜いておこうという事か^^;;;。 最後は見せ場を盛り込むから、物語を削る必要があるとすれば、それ以外の部分、という事になりますよね<ref name="yth" />。 つまりラスボス戦（必ずゲームってこれで終わるの? ^^;;;）は最重要なので削らない。後の部分は削る可能性あり。だから最後を先に作って作りこんでおけば、制作過程で不測の事態が起こっても、重要部分はできているので、早く、上手にリリースできる。 {{コラム|イラスト制作でも順番を考え直すと打開できる場合あり。| イラスト雑誌『コミッカーズ』（1995年季刊夏号）（唯 登詩樹 表紙）での藤島康介のインタビュー 藤島（談）:よく若い漫画家さんから相談で、「先生みたいに女性の長い髪を書くとき、毛先を書くのが難しいです。根元は書けるのに」との相談を受けるのですが、 僕（藤島）は髪を描くときは毛先から始めて根元に向かって描いてます。 つまりイラスト初心者は、根元から髪の毛を描きたくなるのですが、ここで長い髪の毛を描く場合はむしろ毛先を先に書いて位置決めして、長い毛を描くと割とうまく描ける。 きれいな女性の髪の毛は、毛先の奇麗さが大事ですからね。 ストーリーを作る時に全体を考えたうえで、必ずしも最初から書くことにこだわらない方がいいように、絵を描く時にも同じ発想が有効になる。例えば機械製図でも、正確に奇麗に書くためあるいは実際の製作のため?、位置決めの優先指示の記法がある。 }} *目標 世の中では目的や目標を明確化せよ、と主張する人は結構多い。現編集者は懐疑的。むしろ他人を自分の都合いいように動かしたいから、その方向を明示したいのだろう。それより、我々の本当の目的と目標は何か、歩みを止めてちょっと考えてみろよ、と、言いたい。 しかし結局世の人たちは目標をはっきり、言語化したがる。ゲームでもそれをすると、プレイヤーがゲームに引き込まれる、と言うが、実際にはそれはゲーム業界のカモになっている、インチキゲーマーだけだろう。 とにかくカモたちは目的を欲しがる。目標や課題がゲーム中で明確になっていないと、疑問だらけになり、ゲームをやめて、業界にお金を落としてくれない。そこで設計の際、各ステージやエリアなどの冒頭で、そのステージの課題や目標などを明示する必要があるという<ref>『ゲームプランナー入門』、P39</ref>。 ファミコンなどの古いアクションゲームではゲーム本編では目標は語られていませんが、しかし説明書などではきちんとそれが語られており、実際にスーパーマリオブラザーズの第1作目の説明書では、目的はクッパを倒してピーチ姫を救出することだと語られています<ref>『ゲームプランナー入門』、P54</ref>。 ===チュートリアル、製作順序=== RGBやシミュレーションゲームでは、初めの方は、操作説明のためのチュートリアルイベントになることも多いのですが、ここにも製作順序のポイントは指摘できますね。 基本的にはチュートリアルの細部は後回しにしたい。と、いうのはゲーム本体の仕様変更が、製作過程で頻繁に起こるので、チュートリアルもそれに合わせて後回しにせざるを得ない。 最初の段階でチュートリアルを作りこんでも、仕様変更になれば、その記述自体が不適になる。 当初のチュートリアルイベントがそもそも必要かどうか。説明書、マニュアルに任せてもいいですよね。 基本的にゲーム本体の仕様がかなり変更を含み場当たり的なので、チュートリアルは後回し、ゲーム本編の完成間近の時期になるか、もしくは本編完成後になるでしょう。 ==昔のコンピューターゲームと技術の発達、変遷== ゲーム制作の時は、自分が昔プレイして楽しかったゲームを思い浮かべるし、参考にもしますよね。 ただ、コンピューターゲームは明らかに、周辺技術が時間とともに、かなりの速度で発達、変遷していきますし、過去のゲームを参考にすると言っても、精神面、思想面での参考で、技術面ではやはり、最新の情報技術を取り入れたいと、誰もが思うでしょう。 前編集者は得意げに、古典技芸の世界では、『師を見るな、 師が見ているものを見よ』と、いう言葉があると宣っていますが、そもそもこの国のゲーム業界では、基本的に金と目先の安易な欲望と私欲しか顧みられないし、そこを支配する知性と教養は、善意や誠意や真理とはかけ離れた、歪んだ論理と無駄に衒学的な詳細しか持たないし、権力をもって威張っている連中は、善性や美などとはかけ離れた安易な偏向した物理主義的な議論に明け暮れている連中なので、師などと呼べる人物に出会うことさえ、至難な事でしょう。 === スプライト === ファミコン時代の昔のゲーム機には、一画面に表示できるキャラチップ数（敵チップも含める）に上限がありました。 一画面中に表示できる限界は、だいたい、マリオが一画面中に数十人ぶんです。 このように、ビデオゲームで小さなキャラクタを、高速表示する仕組みを、「スプライト」と呼んでいました。マリオのキャラクター表示は小単位のスプライトを複数合成していたようです。 このキャラクター数の制限が、当時はゲームの設計にも大きな影響を及ぼしていたわけですね。 例えばシューティングゲームで、100体の敵機を表示することはできない。 しかしそれなりの工夫はあった。表示のタイミングを変えることで、なんとなく、多量のスプライトがあるように見せることはできた。 つまり、 :1タイミング目では0～10体目までのAグループを表示、 :2タイミング目では11～20体目までのBグループを表示、 して、切り替える、うまく、素早くとか? 上手にプログラムを作ればそこそこ上手くいったようですね。それでも、キャラクターが多いと、一瞬、消えたりしている。 ファミコン上における実際の技術限界の正確な数値は、別の資料を参照していただくとして、あまりあてにならない数字として例えば、横1列上には 8体目までしか表示できなかったようです。マリオは一人で2*2=チップ使っていた。だから横一列では 4体までしか表示できませんね。 例えばシューティングでは、敵機の他に、弾丸などもスプライトでしょう。 マリオが４チップなように、巨大ボスなんかチップ数をかなり使っているでしょうね。 そしてチップ数が多いから、速度が遅くなるのでしょうか、何か我々の昔のゲームをプレイした記憶では、巨大ボスの動きは緩慢でしたよね。 しかしやや脱線しますが、巨大なキャラクターは何となく動きが遅いという我々の固定観念がある一方で、レスラーやヘビー級ボクサーはかなり動きが速い。相手の体が大きい上動きが早ければ、もう勝てないね。座して死を待つしかないか^^;;;。 <!-- すじ肉先輩さー、「ウドの大木」みたいな言葉を得意げに書いてる時点で、あんたは性格悪いし、このサイトでの不適切編集者である証拠なんだよね。--> ===画面描き換えと背景=== ファミコンのマリオの横スクロールでは、例えば地上ステージの空は、青一色で描き換えを行わない。低地の地面の障害物周辺だけを動かしていたようですね。動かす部分はプログラムでの描き換えが必要だし、動かない部分は背景として、描き換える必要がない。 書き換える必要のない背景表示は当然プログラムの負荷も少ないですよね。 ですから昔のレトロゲームの雰囲気や映像、仕様は、当時の技術の制限、影響を受けた上でその形態になっていたという事で、今は技術が発達したので、様々な斬新な映像表現や、演出を駆使できる。 一方で最新の技術を駆使したうえで、過去のレトロな雰囲気を再現、表現するという道もあるでしょうね。 ===アナログテレビのドットのにじみ=== 昔のブラウン管テレビのドットは、にじみが大きいとみていいようですね。これは画面の性質なので、ゲームでも映画でもバラエティでもドキュメンタリーでも、解像度画面としてのにじみは同じように大きい。 だから、ファミコンからプレイステーション1時代ぐらいまで、ゲームのグラフィッカーは、そういうにじみの大きい映像を意識して、ドット絵を描いていたでしょうね。 今の液晶画面が完全ににじみがないかどうかは怪しいですが、ブラウン管よりは少ない。 ただ滲みが大きいから、解像度が低くても何となく、自然に見えるという事はあったでしょう。 色に関してもにじみの重なりで、何となく豊かな色に見える。 前編集者は、同じドットの黄色の単色でも、そのドットの幅が1ドットか2ドットかで、テレビ上で表示される色が違う、実際にブラウン管のディスプレイ上で色が違うと書いていますが、どうでしょうね、要するに電子線が蛍光物質を刺激する量が割とあいまいですからね、そういう事を言いたいのか。 まあとにかく、昔のゲームはそういうあいまいでアナログな技術で、一種独特の画面を作り出していたわけですね。 ですからプログラムとしては当時の仕様をそのまま再現したとしても、今現在の機材では、昔のゲームの独特の雰囲気そのものまで再現するのは難しいですよね。 パソコン市場では、1999年ごろからノートパソコンが普及し、液晶ディスプレイも安価で出回ってきた。そこでにじみの少ないくっきりした映像が主流になってきますね。 基本的にディスプレイはブラウン管→液晶と変わり、解像度は大きくなる一方ですね。 プレイステーション2あたりからはもはやブラウン管でのプレイ自体考えなくなる。 この辺から家庭用ディプレイの切り替えが起こっていましたよね。 アナログ放送は2010年ぐらいまで続いたでしょうか。しかし家庭ではゲームをするにしても、普通に放送を見るにしても、DVDを見るにしても、ブラウン管から液晶や、プラズマというのもありましたよね、画面の解像度自体も高くなっていく。 そして画像のドットはにじみの少ないくっきりしたものへ、ゲームの映像の考え方自体変わっていきますよね。 最近はパソコン画面でも、TVでもドットの縦横は等しい正方形ですが、ブラウン管はそうではなかった。 だから、当時はドットで絵を描く時も、長方形ドットですね。 しかも、ゲーム機やパソコンの種類、さらにはアーケードゲームの基盤といったハードウェアの種類ごとに、コンピュータ側でのドットの縦横比の管理は違っている（らしい）。このため、移植のたびに、ドットは書き直しになったようだ。 昔は、というか実はいまでも、CGや画像の縦横比が正確ではない映像を見る事はありますよね。 現在のパソコン用のドットエディタ（という画像制作ツールがある）は1ドットが正方形だが、ファミコン時代は1ドットが（ドット用紙の時点で）少しだけ長方形。（なお、画像制作ツールの作り方については、『[[ゲームプログラミング/画像ファイルの作成プログラム]]』というコンテンツがこのサイトにある。） ファミコンの色数制限は52色から4色×4パレット（1パレットあたり4色）を使えると言われている<ref>[https://mynavi-creator.jp/blog/article/history-of-2dcg-designer] 2021年12月30日に確認.</ref>。しかし実際には、4色のうち1色は透明色として利用される色であり、全パレット共通の色になる（だから3×4=12色が使える）。 スプライトのパレットとは別に背景のパレットがあるので実際にはもっと多くの色数が一画面内で使えるが、しかしその他さまざまな制限があるので、合計で一画面内で25色が使えると言われる（12+13=25）。 論理的には25色だが、ブラウン管のドットの滲みやテレビのアナログな仕様から、結局はなかなか豊かな映像が当時も見れたと言っていいのではないだろうか。 しかしレトロなゲーム機では、さらにメモリ容量やストレージ容量などの制限もあり、けっして仕様上の最大色数を気軽に利用できたわけではないかもしれない。こういう制限もあったからか、ネットではファミコンの色数が「4色」や「8色」、スーパーファミコンの色数が「16色」や「256色」、とも言われることがある。 {{コラム|ドット絵| ファミコンのギザギザのキャラクターの絵は、良く、ドット絵と言われますよね。 ただ、プレーステーション以降、ゲーム機が進化しても、コンピュータの画像は、ドットのラスターグラフィックだから、ドット単位で絵を描くことは多い。 特に小さい絵、キャラクターやアイコンはドット単位でデザインします。 しかし言葉の使い方では、ドット絵と言えば昔の、ファミコンキャラクター風のギザギザの解像度の低い絵を指すことが多いでしょう。 現在のドットエディタで絵を描く場合でも、解像度の低い絵が多いですね。ラスターグラフィックも結局ドット単位で解像度が高いだけですが、解像度が高い、アンチエイリアスを駆使した絵は、もはや、ドットというよりはアナログの手描きの絵と言いたくなる。 前編集者はこのドット絵という言葉にこだわって、なんかグダグダ理屈書いていたけど、現編集者にとって何がしたいのか、何を言いたいのかただただ謎ですね。 とにかくドット絵にレトロな意味を持たせても全然問題ないと思うけど…。 子供時代の思い出は大事だぜ^^。 1990年代後半に、岡田斗司夫氏の対談でこういうものがあったそうです。出典はおそらく『マジメな話』。 「アニメの黄金期っていつだろう?」 「70年代かな～。」 「いや、80年代だろう。」 「そうかな～。」 「むしろ…」 「むしろ?」 「…12歳だね^^」 12歳万歳!(^^)/ }} ===テレビとディスプレイの焼き付き=== ゲームというのは色数も少ないし、静止画も多い。 ファミコン時代から、同じ色長時間の表示は、ディスプレイの焼き付きを起こすので、常にそれなりの工夫がされていたかもしれませんね。 静止画を避ける、時々背景を変える、背景色を光のエネルギーを持たない黒にするとか… パソコンでは昔からその工夫がありましたね。スクリーンセイバーという機能もある。 とにかく一つのドットに同じ色が長時間表示されると…ちょっと危ない。 焼き付きの問題は昔も今もありますよ。昔のブラウン管は焼き付かないという主張が時々あるようですが、事実ではないでしょう。 現代のテレビ受像機には、焼きつき防止のために「ピクセルシフト」という機能がある。これは画面上の映像の表示位置をタイミングごとに微妙にずらす機能です。こういう機能がすでに搭載されているので、ゲームソフト側で焼き付き防止を必要以上に考慮しなくてもいいらしい。液晶モニターは、焼きつきが起きにくいという。ただし有機ELはどうか。知りませんね。現編集者も前編集者も知らない^^;;;。 == 脚注 == <references /> == 関連項目 == * [[ゲームプログラミング/コンピュータゲームの種類]] * [[XNAを使用したシンプルな3Dゲームの作成]] * [[プログラミング]] * [[w:ゲームプログラミング]] {{DEFAULTSORT:けえむふろくらみんく}} [[Category:ゲーム]] [[Category:情報技術]] {{NDC|007.64}} 1a45fmotese6aa0c9a1mgtk28s8horl 0 5310 205985 196430 2022-07-29T12:53:04Z Rhkmk 66092 /* 判例 */ wikitext text/x-wiki [[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第2編 物権 (コンメンタール民法)]] ==条文== （[[w:善意|善意]]の占有者による[[w:果実|果実]]の取得等） ;第189条 # 善意の占有者は、占有物から生ずる果実を取得する。 # 善意の占有者が[[w:本権|本権]]の訴えにおいて敗訴したときは、その訴えの提起の時から悪意の占有者とみなす。 ==解説== 善意の占有者は、占有物から生ずる果実を取得することができる。本来、本権を有しない限り果実の取得権は発生しないが、自身に本権が帰属すると誤信した（＝善意）の占有者はこの規定により保護されることになっている。盗人など、自身に本権が帰属しないと知っている（＝悪意）の占有者はこの規定の保護の対象外となり、原則通り果実の返還義務を（[[w:不当利得|不当利得]])負う。 第2項は、民法第186条の推定規定の例外を定めたものである。 もし[[民法第703条]]が適用されれば、訴訟によって占有者に占有の権原がないことが明らかになった後でも、すでに費消した果実については「取得」が認められて返還する義務を負わず、まだ費消していない果実については返還しなければならない。この189条も不当利得の条文だから、この条文の「果実」とはすでに費消した果実に限ると解釈されている（縮小解釈）。 ただ、189条は703条と異なり、訴訟によって占有者に占有の権原がないことが明らかになった場合、提訴時にさかのぼって[[民法第190条|190条]]が適用されるため、占有開始時から提訴時までにすでに費消した果実は「取得」が認められて返還義務がないが、提訴時以降に費消した果実は金銭評価して利息をつけて返還しなければならない。 つまり権利者は善意の占有者に対して物の返還を求めると同時に、費消していない果実の返還＋提訴時以降に費消した果実の金額と利息を請求することができる。 ==参考文献== *[[w:加藤雅信|加藤雅信]]『新民法体系物権2（第2版）』222頁、235頁 ==参照条文== *[[民法第89条]](果実の帰属) *[[民法第186条]](占有の態様等に関する推定) *[[民法第190条]]（悪意の占有者による果実の返還等） *[[民法第206条]](所有権の内容) *[[民法第704条]](悪意の受益者の返還義務等) ==判例== *[http://www.courts.go.jp/search/jhsp0030?hanreiid=53723&hanreiKbn=02 不当利得返還請求]（最高裁判例  昭和38年12月24日)[[民法第703条]] *[http://www.courts.go.jp/search/jhsp0030?hanreiid=57462&hanreiKbn=02  損害賠償請求] (最高裁判例  昭和32年01月31日)[[民法第709条]]，民訴法199条1項，民訴法709条 *[] (最高裁判例 ) ---- {{前後 |[[コンメンタール民法|民法]] |[[第2編 物権 (コンメンタール民法)|第2編 物権]]<br> [[第2編 物権 (コンメンタール民法)#2|第2章 占有権]]<br> [[第2編 物権 (コンメンタール民法)#2-2|第2節 占有権の効力]] |[[民法第188条]]<br>（占有物について行使する権利の適法の推定） |[[民法第190条]]<br>（悪意の占有者による果実の返還等） }} {{stub}} [[category:民法|189]] i2mppg3thk7qr8dmbg0zr89hvo8u1h6 0 5392 205986 79138 2022-07-29T13:02:28Z Rhkmk 66092 /* 判例 */ wikitext text/x-wiki [[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第2編 物権 (コンメンタール民法)]] ==条文== （[[w:所有権|所有権]]の内容） ;第206条 : 所有者は、法令の制限内において、自由にその所有物の使用、収益及び処分をする権利を有する。 ==解説== 所有権の制限と、その権利内容について規定している。 ==参照条文== *[[w:日本国憲法第29条|日本国憲法第29条]](財産権) ==判例== *土地建物所有権移転登記手続請求 (最高裁判例 昭和35年02月25日) *[http://www.courts.go.jp/search/jhsp0030?hanreiid=70438&hanreiKbn=02 建物収去土地明渡](最高裁判例 昭和57年06月17日)[[民法第249条]],[[民法第252条]],[[民法第555条]] *[http://www.courts.go.jp/search/jhsp0030?hanreiid=52181&hanreiKbn=02  書籍所有権侵害禁止] (最高裁判例 昭和59年01月20日)[[著作権法第2条]]1項1号，[[著作権法第45条]]1項 *[http://www.courts.go.jp/search/jhsp0030?hanreiid=52503&hanreiKbn=02 建物収去土地明渡](最高裁判例 平成6年02月08日)[[民法第177条]]、[[民法第200条]] *[http://www.courts.go.jp/search/jhsp0030?hanreiid=52332&hanreiKbn=02 製作販売差止等請求事件](最高裁判例 平成16年02月13日)[[民法第198条]],[[民法第199条]],[[民法第709条]],[[知的財産基本法第2条]]2項 ---- {{前後 |[[コンメンタール民法|民法]] |[[第2編 物権 (コンメンタール民法)|第2編 物権]]<br> [[第2編 物権 (コンメンタール民法)#3|第3章 所有権]]<br> [[第2編 物権 (コンメンタール民法)#3-1|第1節 所有権の限界]] |[[民法第205条]]<br>（準占有） |[[民法第207条]]<br>（土地所有権の範囲） }} {{stub}} [[category:民法|206]] dkums9aynux0lszunyo9md3i0adi3li 0 9672 206010 191730 2022-07-30T08:51:57Z はいかぐら 45848 wikitext text/x-wiki ==漢文とは何か== 漢文とは、漢人つまり中国人が書いた文章をいう。中国人は漢字を用いるため、漢字のみで書かれる。ただ、ここでいう中国人は、一般に清代以前の中国人をさす。清代とは日本史にでてくる日清戦争の清である。このように、漢文は古い中国語にあたる。但し、清代においても、漢文は日常会話と異なるいわゆる文語の位置にあった。また、広大な中国においては方言の差が大きく（言語学的には、別の言語といってよいほどの差異がある）、ここで共通のコミュニケーションの方法として、漢文は機能した。さらに、清朝は領土内に満州族、蒙古族、ウィグル族、チベット族など、中国語を日常語としない民族が多数おり、それらを統治するための文書語として用いられた。加えて、朝鮮やヴェトナムといった周辺諸国においても、朝廷の公式文書は漢文で書かれた。 これは、[[w:前漢|前漢]]期（紀元前206年 - 8年）に完成された漢文の、文法の簡潔性と漢字の強い抽象化機能の賜物といえ、東アジア文化圏において、西欧諸国における[[w:ラテン語|ラテン語]]と同じ機能を果たしたといえる。 日本では、朝鮮半島を通じ、漢字とともにその表現方法として、遅くとも4世紀には伝わったものとされる。日本においても、相当に長い期間、公式の文書は漢文で記されるものとされていた。また、教養のひとつとして、漢文を読むことが、盛んになされたが、そのような環境において、漢文の語彙・文法を頭に入れ、それによって書いた文章も漢文の一種になる。ただ和語も混ざるので和様漢文とよばれる。『日本書記』などがそうである<ref>和様漢文は山川『日本史用語集』にあり</ref>。ただし、日本では、比較的早い時代に、日本語自体の音声の特徴にあった表記方法である'''かな'''（仮名、即ち、「仮の表現」。これに対して、漢字を『真名』という）が発明され、表現方法としても、漢字の抽象化機能を生かしたまま表現できる「[[w:和漢混淆文|和漢混淆文]]（和漢混交文）」が工夫されたため、自由に日本語を表現することができた。 近代に至って、日本が明治維新を迎え、近代化の一環として、話し言葉（口語）と書き言葉（文語）を近づけることにより、社会の変化に柔軟に対応できることを可能にするための[[w:言文一致運動|言文一致運動]]を起こしたのと同様に、清朝が滅んでからの中国は、近代化を進めるために、書き言葉を話し言葉に近づける運動がなされた。これを、[[w:白話運動|白話運動]]（「白」は「告白」等に見られる「いう」の意）という。これは、清以降、中華民国を経由し、現代の中国である中華人民共和国における表現方法となっており<ref>そのため、現代の中国語では、北京周辺の標準語（これを普通話という）と、各地の方言（広東語など）は、文字表現も異なることとなっている</ref>、漢文は中国語を表す表現方法となっていない。しかし、現代の中国人も、古典となった中国語を読み、暗記し、そこにおける語彙や文の作りを覚え、古典の文体で書くことがあり、それも「漢文」といえる。 ===高校漢文=== 高校の古典において学ぶのは、上の漢文の入門編であり、かなりその幅を限定できる。 漢文の古いものは、[[w:春秋時代|春秋時代]]の人である[[w:孔子|孔子]]が、すでに古典であったものを取りまとめた「[[書経]]」や「[[詩経]]」といったものがあるが、これらは、あまりに古く、続く[[w:戦国時代 (中国)|戦国時代]]には注釈書が必要となるほどであるので、初学者には難しく、高校の漢文においては参考程度に紹介されるに止まる。 次の時代である戦国時代に、孔子の弟子筋により、孔子の言行録である「[[論語]]」が編纂される。この頃漢文の表記法が一応の完成を見せ、また、その後の中国において国教ともいえる位置を占める[[w:儒教|儒教]]の創始者である孔子の「論語」は、長期にわたって東アジア全体に大きな影響を与えた。高校漢文においても、最も重要なテキストのひとつである。 この時代、中国は社会体制の大きな転換期であり、儒教のみならず、いろいろな思想が各地で興った、これを[[w:諸子百家|諸子百家]]という。彼らは、自らの思想を分かりやすく伝えるため、多くのたとえ話をした。これらの多くが現代にも「故事成語」として残るものである。これらの、出典としては、儒家の「[[孟子]]」、道家の「[[荘子]]」、兵家の「[[孫子]]」等が有名である。検定教科書や参考書には、孫子を除く、孟子や荘子などがよく取り上げられる。 この転換期の混乱を[[w:秦|秦]]の[[w:始皇帝|始皇帝]]が収め、その業績を漢が継ぎ、実に数百年ぶりに、国土の安定を得る。中国には歴史を重んずるという伝統があるが（[[高等学校古文/歴史書]]参照）、この国家の安定において、過去の各地の歴史書を大成した作品が生まれる。[[w:司馬遷|司馬遷]]による「[[高等学校古文/歴史書/史記|史記]]」である。これは、それ以前の歴史を大成するのと同時に、その後の中国の[[w:正史|正史]]の形を決め、論語同様、東アジア全体に大きな影響を与えた。勿論、高校漢文においても、最も重要なテキストである。極論を言うなら、「論語」と「史記」が、ある程度読みこなせれば、その水準の3/4程度は達したものと考えても良いくらいである（あと、1/4は後述する漢詩である）。 漢文による散文は、漢代を以って完成する。これを狭義の「漢文（漢代の文章）」という。これ以降の漢文は、当時の中国語特有の音律を意識した文章であったり、語彙が難解になったりして、初学者には難しいので、高校漢文で体系的に取り上げられることは少ない。「[[世説新語]]」等のように教科書でよく取り上げられる古典もあるが、「史記」を読めれば、多くは苦労することなく読むことができる部分が取り上げられている。入門編と割り切るなら、教科書と入試の過去問に取り上げられているものを読むのに終始すればよい。例外的に体系的に取り上げられるものに、史記以降の歴史のダイジェストとして[[w:元|元]]代に編纂された「[[十八史略]]」がある。このため、「[[w:漢書|漢書]]」「[[w:三国志|三国志]]（有名な[[w:諸葛孔明|諸葛孔明]]の[[w:出師表|出師表]]や[[w:魏志倭人伝|魏志倭人伝]]が含まれる）」「[[w:貞観政要|貞観政要]]」といった、本当の意味での古典はあまり取り上げられない傾向にある。 一方で、時代は漢から[[w:三国時代 (中国)|三国時代]]、[[w:晋|晋]]、[[w:南北朝時代 (中国)|南北朝時代]]、[[w:隋|隋]]をへて、[[w:唐|唐]]にいたる。この時代に発展した表現形式が、我々が「[[高等学校古文/漢詩|漢詩]]」と呼ぶ'''詩'''である。これらについては、日本が体系的に初めて出会ったカルチャーショックからか、日本文化に深い影響を与える（それ以降に中国で流行した宋詞や元曲がほとんど影響を与えなかったのとは対照的である）。その影響であるかは断言できないが、漢詩は高校漢文において重要な位置を占めており、「[[杜甫]]」「[[李白]]」の有名な作品や、「[[唐詩選]]」からも多く教科書に取り上げられている。ただし、その中心は'''[[盛唐]]'''期であり、それ以降は、入門の域を超えるため参考の位置づけに近くなる。 これ以降も、漢文による重要な古典は、数多く輩出する。例えば、「[[源氏物語]]」をはじめとする日本の古典文学に大きな影響を与えた「[[長恨歌]]」の作者である[[w:白居易|白居易]]や[[w:唐宋八大家|唐宋八大家]]といわれる大文学者は唐末期から[[w:宋|宋]]代になって現れるし、近世儒学は[[w:南宋|南宋]]において[[w:朱熹|朱熹]]が完成させる。また、フィクションの分野においては、[[w:明|明]]代から清の初期にわたって「[[w:三国志演義|三国志演義]]」「[[w:水滸伝|水滸伝]]」「[[w:西遊記|西遊記]]」「[[w:紅楼夢|紅楼夢]]」といった現代において古典とされるものが、ようやく見られるようになるが、このあたりになると、語彙が特殊であったり、口語が含まれていたりするので、高校の漢文で取り上げられることは、非常にまれとなる。 結論として、高校の漢文では、時代としては「論語」成立の諸子百家の時代から、「史記」成立の前漢までの文書が中心であり、それに、盛唐期の漢詩が加わえれば、その90％以上はフォローできているものと考える。 ==漢文をなぜ学ぶのか== 古典の学習の理由として以下のことが学習指導要領で説明されている。ただし古典が科目になった歴史上の経緯<ref>江戸期において、高等教育の中心は漢学であり、教育者と言えば漢学者が多数であって、明治に入って近代教育制度整備の過程においても、これら漢学者の多くが参加をしていた。</ref>とは異なる。 #　古文・漢文の語句の意味、用法、文の構造を理解する。 #　内容を構成や展開にそくしてとらえる。 #　人間、社会、自然などにたいする思想や感情を読み取る。そうしてものの見方、感じ方、考え方を豊かにする。 #　表現の特色を理解し、優れた表現に親しむ。 #　古典を読んで、日本文化と中国文化の関係について考える<ref>『高等学校学習指導要領』ｐ２１</ref>。 ただし、高等学校などでの漢文履修者の大半は、上記の学習指導要領上の理由というよりも、「必修科目の国語教科内の一部であるため」や「大学受験のため」、といったことが学習の理由であることが実情である。（これは他の教科・科目にも同様に言えることであり、漢文に限ったことではない）。 ==漢文を学ぶ方法== 要領では上のようにあった。ここではおのおのについてまとめる。 ===古文・漢文の語句の理解=== 語句の意味、用法、文の構造を理解する。その方法は、辞書を引くことなどになる。漢文の場合は、おのおのの漢字と熟語については、漢和辞典を引く。句形や置字については、教科書の中で説明を探すか、漢和辞典の句形や置字の解説をよむ。また、熟語の中で、専門用語の場合は、広辞苑など詳しい国語辞典を引く。 漢字を引くことについては、教科書・受験問題に関わらず、自分が目にする文章を、冒頭からながめ、少しでもひっかかり、意味がすぐに思い浮かばないものは、どれも辞典を引く。辞典を引くのは時間がかかるようだが、自分で意味を考え出そうとして時間をかけるより引いた方が早く、ひとつひとつ地道にやっていくと意外と進みは早い。 ===内容を構成や展開にそくしてとらえる=== 内容を構成や展開に即してとらえる。その方法は、語句の意味や句形につうじて、それにより目にしている文章の全体を見渡たせるようになることである。漢文を、日本語の文章と同じような感覚ですらすらよめる、そういう状態を想像し勉強をする。 また構成や展開に即してとらえる、というのは、目にしている文章のあるフレーズについて、そのようにする、ということである。それは、一面としてつぎのことである。目にしているフレーズ内の語句が、同じ文章内のべつの箇所にも出ていないかを探し、べつの箇所での、その語の用法をみる。つまりその語がどういうほかの事物とイメージ的に結び付けられているかをみる。そしてその〈用法〉を、もとの目にしていたフレーズにあるその語句に代入して読む。 このような、他の箇所での用法を見てそれを代入して読む、というやりかたが客観的な漢文の読解法になる。 ===思想や感情を読み取る=== 人間、社会、自然などに対する思想や感情を読み取る。その方法も、他の箇所での用法をみてそれを代入して読む、ということになる。これが著者にそくして客観的に読み取る方法である。 ===優れた表現の理解=== 表現の特色を理解し、優れた表現に親しむ。自分が好きであると感じる文章を読むのが、ひとつのいい方法である。漢文の文章を手に入れるには、岩波文庫が手頃である。漢詩、論語、荘子、歴史書、仏典などさまざまなものが手に入る。ウェブ上でも、中国の古典なら[http://wagang.econ.hc.keio.ac.jp/txthuangye/home.html 電脳瓦崗寨　電子文献黄頁]や[http://www.let.osaka-u.ac.jp/chutetsu/lunwen/etxt_lst/index.html 電子テキスト類目]、仏典なら[http://21dzk.l.u-tokyo.ac.jp/SAT 大蔵経テキストデータベース]で漢文を入手できる。 ===日本文化と中国文化の関係=== 古典を読んで、日本文化と中国文化の関係について考える。『源氏物語』などの古文には、仏教に関する話があるが、仏教はインドでつくられたものであるものの、日本に入ってきたのは中国でインドの言葉から翻訳された漢訳仏典で、日本人は漢文で仏教にふれてきた。漢文を通じて仏教文化を共有している面がある。 ただ、各時代の「日本」の範囲や、各時代の日本の読書が可能な人の割合、については、日本史を勉強することが必要である。「中国」の範囲についても、王朝の変遷による地理的範囲の変化がある。このように、日本文化と中国文化の関係について、過去の歴史上の事実として把握するには、漢文だけでなく、歴史についても学ぶ必要がある。 ===学ぶ上での注意・訓読文=== 漢文は、もともと中国語（繰り返すが話し言葉ではなかった）であり、日本語とは、その文法構造を大きく異にしている。そもそも、歴史的には、日本人は漢文を外国語として捉え、大和言葉とは一線を画して読み書きを行っていたが、時代が下り、漢字の知識が深まるようになると、漢文に助詞や送り仮名を付し、さらに順序が日本語らしくなるよう記号（返り点）を付けて日本語として読めるような工夫（[[w:漢文訓読|漢文訓読]]）がなされるようになった。 書き下し文、読み下し文、訓読文などというのがこれであり、漢文独特の言い回しとしてなじみがあり、漢文の特徴のひとつといってよい。 しかしながら、これはあくまでも原文理解のための「'''便法'''」であって、その言い回しや仮名遣いの正誤にこだわるのは、漢文理解の為のエネルギーの無駄遣いでしかない。そもそも、一意に訓読ができるものではなく、ある種の仮置きに過ぎないということを理解しておくべきである。 訓点の機能を理解する初学の時期を除いて、「書き下し文を書け」等という問題が試験に出たならば、それは悪問であり、出題者の見識を疑って然るべきである<ref>本章の主張の多くは、中国文学者[[w:高島俊男|高島俊男]]著『漱石の夏休み』中「『漢文』について-訓読の歴史」に負っている。</ref>。 ==漢文を学ぶための本== 漢文に関わる背景的歴史的知識については、日本史の教科書や、世界史の中国史の部分が、参考にできる。各漢和辞典は、本文や巻末に句形・置字（助字）の解説や、中国の昔の時代の地図などもあるので、漢字を引くだけでなく、参考書としてもつかえる。学習参考書としては、駿台の『漢文　学習資料集』が、句形の索引があり便利である。漢字については、大島正二『漢字伝来』岩波新書などが内容豊富に書いている。漢文の概説書としては、手頃なのとして、岩波全書の『漢文入門』や、『漢文法要説』朋友書店などがある。また、句形・置字のより詳しい参考書としては、『漢文を読むための　助字小字典』内山書店が、値段も定価４７３円で薄くコンパクトである。書店の店頭にはあまり置いていないものだが、注文すれば、どの書店でも購入できる。 ==脚注== <references/> [[Category:高等学校教育|かんふん]] [[Category:高等学校教育 国語 漢文|*]] obdjbc14iihp84i35e8g5yup8xbzxq1 0 10189 205992 205737 2022-07-29T16:24:23Z 椎楽 32225 /* 貴族政治と国風文化 */ wikitext text/x-wiki * [[日本史]] ＞ [[高等学校日本史]] ＞ [[高等学校日本史B]] * [[高等学校の学習]] > [[高等学校地理歴史|地理歴史]] > [[高等学校日本史B|日本史B]] ---- 日本の高等学校課程における「日本史B」の教科書。 == 原始・古代の日本 == === 古代国家の形成 === * [[高等学校日本史B/日本文化のあけぼの]]（人類の発生、旧石器時代、縄文時代） * [[高等学校日本史B/弥生時代]]（弥生時代） * [[高等学校日本史B/古墳とヤマト王権]] === 律令国家の形成 === * [[高等学校日本史B/飛鳥の朝廷]] * [[高等学校日本史B/律令国家への道]]（大化の改新 〜 大宝律令、租庸調など） * [[高等学校日本史B/奈良時代]] * [[高等学校日本史B/天平文化]] === 貴族政治と国風文化 === * [[高等学校日本史B/平安遷都と政治改革]] * [[高等学校日本史B/藤原氏の台頭]] * [[高等学校日本史B/平安時代の地方政治]] * [[高等学校日本史B/国風文化]] == 中世の日本 == === 院政期 === * [[高等学校日本史B/院政とその展開]] * [[高等学校日本史B/保元・平治の乱]] * [[高等学校日本史B/院政期の文化]] === 武家政権の成立 === * [[高等学校日本史B/鎌倉幕府の成立]] * [[高等学校日本史B/北条氏の台頭]] * [[高等学校日本史B/武家社会]] * [[高等学校日本史B/鎌倉時代の経済]] * [[高等学校日本史B/元寇と鎌倉幕府の動揺]] * [[高等学校日本史B/後醍醐天皇と建武の新政]] === 室町〜戦国時代 === * [[高等学校日本史B/室町幕府の成立と南北朝時代]] {{進捗|00%|2018-06-21}} * [[高等学校日本史B/室町幕府の展開]] * [[高等学校日本史B/室町幕府の衰退と下剋上の時代]] * [[高等学校日本史B/戦国大名の台頭]] * [[高等学校日本史B/室町文化と戦国時代の文化]] == 近世の日本 == === 戦国時代末～織豊政権 === * [[高等学校日本史B/ヨーロッパ人との交流]] * [[高等学校日本史B/織田信長・豊臣秀吉]] * [[高等学校日本史B/桃山文化]] === 幕藩体制の成立 === * [[高等学校日本史B/徳川幕府の成立]] {{進捗|00%|2018-06-06}} * [[高等学校日本史B/寛永文化]] === 幕藩体制の展開 === * [[高等学校日本史B/幕藩体制の展開]] * [[高等学校日本史B/江戸時代の経済の発展]] * [[高等学校日本史B/元禄文化と学問の発展]] === 幕藩体制の動揺 === * [[高等学校日本史B/幕藩体制の動揺]] * [[高等学校日本史B/幕藩体制の停滞と諸藩の改革]] * [[高等学校日本史B/江戸中・後期の文化]] {{進捗|00%|2018-06-06}} == 近代の日本 == === 近代への転換 === * [[高等学校日本史B/開国]] * [[高等学校日本史B/明治維新]] * [[高等学校日本史B/明治の近代化の改革]] * [[高等学校日本史B/明治初期の文化]] * [[高等学校日本史B/明治初期の外交]] === 日本の軍事的覇権 === * [[高等学校日本史B/立憲体制の確立]] * [[高等学校日本史B/日清・日露戦争]] * [[高等学校日本史B/第一次世界大戦と日本]] === ブロック経済の成立と崩壊 === * [[高等学校日本史B/経済恐慌と中国侵略]] * [[高等学校歴史総合/世界恐慌とブロック経済]] * [[高等学校歴史総合/満州事変]] * [[高等学校日本史B/第二次世界大戦と日本]] == 現代の日本 == === 占領期と独立 === * [[高等学校日本史B/占領と改革]] * [[高等学校日本史B/冷戦の開始と講和]] === 平和と繁栄をめざして === * [[高等学校日本史B/安保闘争の時代]] :* 参考: [[高等学校政治経済/政治/右翼と左翼、保守と革新]] (※ 用語解説。分かっていれば、読み飛ばしても良い。) {{進捗|50%|2016-04-05}} * [[高等学校日本史B/高度経済成長の日本]] === 理想の挫折 === * [[高等学校日本史B/高度経済成長の終焉]] * [[高等学校日本史B/冷戦後の日本]] == テーマ史 == * [[高等学校日本史B/テーマ史別]] == 資料集 == * [[高等学校日本史B/史料集|史料集]] == 学習方法 == * [[学習方法/高校日本史]] {{DEFAULTSORT:にほんしB}} [[カテゴリ:高等学校教育]] [[カテゴリ:社会科教育]] [[カテゴリ:高等学校日本史|*]] qpbpvm5d343kz8bb6ps8ow7zj4260yd 0 24156 205990 205735 2022-07-29T16:23:53Z 椎楽 32225 椎楽 がページ「[[高等学校日本史B/平安初期]]」を「[[高等学校日本史B/平安遷都と政治改革]]」に移動しました: 「平安初期」では本章のテーマがぼやけており、わかりにくいため。 wikitext text/x-wiki {{Nav}} == 平安時代 == [[ファイル:Miniature Model of Rajomon.jpg|thumb|平安京の羅城門（らじょうもん）の復元模型（京都文化博物館）]] かつての天平文化の仏教保護の政策などにより、仏教の僧や寺院の影響力が強くなる。 のちの天皇や朝廷は、これらの仏教勢力を嫌がり、そのため、光仁天皇のあとをついだ桓武天皇（かんむ てんのう）により、寺院の多い現在でいう奈良県から京都府へと都をうつす。まず784年に都を山背国（やましろこく）の長岡京に移した。 しかし、新都造営（しんとぞうえい）の中心人物であった藤原種継（ふじわらのたねつぐ）が暗殺されたり、政情不安が続いたので、794年に都を平安京に移した。 == 政治 == 桓武天皇は、国司に対する監督をきびしくするため、'''勘解由使'''（かげゆし）という役人を置きました。 :※ 『[[高等学校国語総合/土佐日記#門出（かどで）]]』に出てくる「解由」（げゆ）とは、このカゲユシ関連の書類である。著者の紀貫之（きの つらゆき）は、国司として、取り締まりされる側の立場。くわしくはリンク先で。 勘解由使に、国司の交代の際には、前任の国司に不正がなかったことを証明するための解由状（げゆじょう）を審査させた。 :※ 中学校で習った『[[中学校社会 歴史/平安時代]]』も参照せよ。 桓武天皇の政策として、辺境の他では徴兵をやめ、辺境の他では従来の軍団を廃止して、あらたに郡司の子弟で弓馬にたくみな者からなる健児（こんでい）を設けた。 また、このころ、都の造営と、蝦夷との戦いからなる二大事業が、国家財政や民衆の負担だった。 貴族間で、この事業の存続をめぐる論争が起き、桓武天皇はこの二大事業を中止した。 桓武天皇は、二大事業の存続の件で、管野真道（すがのまみち）と藤原緒嗣（ふじわらおつぐ）という2人の参議に論争させた（徳政論争）。（菅野が存続派。藤原が打ち切り派。） 桓武天皇の死後、平城天皇（へいぜいてんのう）、つづいて809年に'''嵯峨天皇'''（さがてんのう）になった。 :※ 社会の変化により、従来の家柄や血筋による人事制度がうまく機能しなくなったため、嵯峨天皇らは、従来の官職を残しつつも、新たに、家柄にとらわれない新設の官職も設置して活用した。<br><br> {| style="width:100%" |valign=top style="width:60%;text-indent:1em"| 嵯峨天皇（さがてんのう）のとき、'''薬子の変'''（くすこのへん）が起きた。しかし、薬子の変は失敗に終わった。 |valign=top style="width:5%;text-indent:1em"| |valign=top style="width:35%;text-indent:1em"| ---- '''薬子の変'''とは、810年に藤原薬子（ふじわらの くすこ）とその兄 藤原仲成（ふじわらの なかなり）が、平城太上天皇（平城上皇）をふたたび天皇の地位につけようとして失敗した事件。「'''平城太上天皇の変'''」ともいう。 （※ 範囲外: ） 薬子（くすこ）とは、平城太上天皇の愛人の名前。かつての学説では、薬子が事件の首謀者に近いと思われていたが、歴史研究では、単に上皇の罪を薬子が なすりつけられただけとかの別の可能性が否定できず、現代の学校教科書では この事件の呼び名で「平城太上天皇の変」という呼び名も西暦2003年ごろから増えてきた。とはいえ、では平城上皇が首謀者かというと、その証拠もとぼしく、真相は不明である。歴史的な事実としては、最終的に薬子は自殺したとされている。 |} {| style="width:100%" |valign=top style="width:60%;text-indent:1em"| 嵯峨天皇は、あらかじめ'''蔵人所'''（くらうどのところ）を設置し、機密をあつかった。 蔵人所の長官を'''蔵人頭'''（くらうどのとう）という。蔵人頭（くらうどのかみ）には、藤原冬嗣（ふじわら ふゆつぐ）らが任命された。 また、京都の治安維持・警察をつかさどるために'''検非違使'''（けびいし）を置いた。 |valign=top style="width:5%;text-indent:1em"| |valign=top style="width:35%;text-indent:1em"| （※ 参考: ）検非違使が創設される前は、京都の治安維持・警察などの仕事は、複数の官庁（衛府（えふ）、刑部省、弾正台、京職など）に分散されて処理がされていた<ref>相澤理『歴史が面白くなる　東大のディープな日本史【古代・中世編】』、株式会社KADOKAWA (中経文庫)、2016年7月15日 第1刷発行、P173</ref>。つまり、検非違使長の創設により、それらの処理がひとつの官庁に一元化された事になる。一説には、いわゆる「縦割り行政」の弊害を解消するという目的もあって京都という地域限定だが検非違使が設けられたのだろう、という説もある。<ref>相澤理『歴史が面白くなる　東大のディープな日本史【古代・中世編】』、株式会社KADOKAWA (中経文庫)、2016年7月15日 第1刷発行、P173</ref> |} {| style="width:100%" |valign=top style="width:60%;text-indent:1em"| これら新設の官職は令（りょう）には規定がないので、'''令外官'''（りょうのげかん）と呼ばれた。 検非違使も、令の規定によらずに犯罪人の取り締まりができた。（※ 東京書籍の見解） また、これら令外官では、家柄にとらわれずに有能な人材を登用できた。（※ 東京書籍の見解） |valign=top style="width:5%;text-indent:1em"| |valign=top style="width:35%;text-indent:1em"| ---- :※ （東京書籍や明成社が言うには、）令外官はべつに嵯峨天皇が始めたのでなくって、702年の「参議」や、705年の「中納言」も、令外官である。ただ、令外官が重要な要職になったのが、嵯峨天皇の頃からである。 |} {| style="width:100%" |valign=top style="width:60%;text-indent:1em"| また、嵯峨天皇は、律令を補足した'''格'''（きゃく）と、官庁で施行する際の細則である'''式'''（しき）とを整備した。 嵯峨天皇のもとで、820年ごろ、'''光仁格式'''（こうにん〜）が出来た。 |valign=top style="width:5%;text-indent:1em"| |valign=top style="width:35%;text-indent:1em"| ---- のちの天皇のもとで、「貞観格式」（じょうがん〜）・「延喜格式」（えんぎ〜）が出きた。これら3つ（光仁格式、貞観格式、延喜格式）をあわせて三代格式という。 |} {| style="width:100%" |valign=top style="width:60%;text-indent:1em"| （823年に嵯峨天皇は、つぎの天皇に皇位をゆずって退位する。） （833年には、）令（りょう）の条文の解釈を統一するための注釈書として『'''令義解'''』（りょうのぎげ）がつくられた。 （842年、嵯峨 元天皇が死没。） |valign=top style="width:5%;text-indent:1em"| |valign=top style="width:35%;text-indent:1em"| |} == 平安初期の密教文化 == {| style="width:100%" |valign=top style="width:60%;text-indent:1em"| 唐で仏教を学んだ'''最澄'''（さいちょう）と'''空海'''（くうかい）が日本に帰国して、仏教の知識も日本に持ち帰る。 空海は、唐では、インドから中国に伝えられたばかりの真言密教（しんごん みっきょう）を学んでいた。 空海が日本で'''密教'''（みっきょう）を広めた。（いっぽう、最澄が広めたのは法華経（ほけきょう）。） 空海は、高野山（こうやさん）に金剛峰寺（こんごう ぶじ）を建て、密教にもとづく'''真言宗'''（しんごんしゅう）をつくった。 また、最澄は比叡山（ひえいざい）に'''延暦寺'''（えんりゃくじ）をひらき、天台宗（てんだいしゅう）をつくった。 天台宗・真言宗の寺院の多くは、山中に建てられた。 :（空海の宗派の寺だけが山中にあるのではなく、最澄の宗派の寺も山中に建てられたことに、注意。） 天台宗も、しだいに密教の影響を受け、最澄の弟子の円仁（えんにん）・円珍（えんちん）が唐に留学して密教の知識を日本に持ち帰り、天台宗は密教化した。 真言宗の密教を'''東密'''（とうみつ）という。いっぽう天台宗の密教を'''台密'''（たいみつ）という。 また、従来の宗派でも山岳修行をしていたが、これらが天台・真言宗とむすびつき、'''修験道'''（しゅげんどう）が流行した。 |valign=top style="width:5%;text-indent:1em"| |valign=top style="width:35%;text-indent:1em"| ---- 密教の特徴として、加持（かじ）祈祷（きとう）など、呪法（じゅほう）的なお祈りで悟りが開けるとされる。 これらの特徴が、現世利益（げんぜりやく）を求める貴族に好まれた。また、密教は、経典よりも山岳修行などの修業を重んじる傾向がある。 なお、既存の仏教など、経典を重んずる宗派のことを、密教の用語で「顕教」（けんきょう）という。 |} いっぽう、奈良時代の後半から既に、日本古来の神々と仏教とをむすびつける'''神仏習合'''（しんぶつ しゅうごう）の考えがあった。 このため、神社の境内（けいだい）に神宮寺（じんぐうじ）を建てたり、神前（しんぜん）で読経（どきょう）する風習などがあったが、密教の普及とともに、これらの風習も普及した。 [[File:Murou-ji 4.jpg|thumb|室生寺（むろうじ）]] 大和の室生寺（むろうじ）では、伽藍（がらん）も地形に応じて自由に配置された。 :※ 伽藍とは、寺院の建物全体や、その構成のこと。 文芸では、漢詩・漢文が流行した。 勅撰漢詩文集の『凌雲集』（りょううんしゅう）、『文華秀麗集』（ぶんかしゅうれいしゅう）、『経国集』（けいこくしゅう）などが編纂（へんさん）された。 また、空海の漢詩文をあつめた『性霊集』（しょうりょうしゅう）もつくられた。 書道では、唐風の書が好まれ、嵯峨天皇・空海・橘逸勢（たちばなの はやなり）は'''三筆'''（さんぴつ）と呼ばれた。 {| style="width:100%" |valign=top style="width:60%;text-indent:1em"| 有力な氏族たちは、一族から優れた官吏（かんり）を出すために、氏ごとの塾・予備校的な寮（りょう）の'''大学別曹'''（だいがくべっそう）を建てた。 また、空海は、大学や国学に入学できない庶民が仏教・儒教などを学べる'''綜芸種智院'''（しゅげいしゅちいん）を開いた。 |valign=top style="width:5%;text-indent:1em"| |valign=top style="width:35%;text-indent:1em"| '''大学別曹'''　和気（わけ）氏の弘文院（こうぶんいん）、藤原氏の勧学院（かんがくいん）、橘（たちばな）氏の学館院（がくかんいん）、在原（ありわら）氏の奨学院（しょうがくいん）、などがある。 |} {{-}} * 美術など [[Image:NYOIRIN KANSHINJI.JPG|thumb|歓心寺 如意輪（にょいりん）観音像 （大阪・観心寺）]] 絵画では、密教の世界観をあらわす'''曼荼羅'''（まんだら）が描かれた。 彫刻では、一本の大木を彫って作る'''一本造'''（いっぽんづくり）が流行した。 また、不動明王（ふどう みょうおう）の絵画や彫刻がつくられた。 {{-}} == 参考文献 == <references/> [[category:高等学校日本史|へいあんしよき]] 6aw3phugj0mu2aybj2dhpij2evbmr92 205993 205990 2022-07-29T16:36:10Z 椎楽 32225 中途半端に紙に寄せてかえって分かりにくいレイアウト修正。(脚注や章立てを活用しようぜ……) wikitext text/x-wiki {{Nav}} == 平安京遷都 == [[ファイル:Miniature Model of Rajomon.jpg|thumb|平安京の羅城門（らじょうもん）の復元模型（京都文化博物館）]] かつての天平文化の仏教保護の政策などにより、仏教の僧や寺院の影響力が強くなる。 のちの天皇や朝廷は、これらの仏教勢力を嫌がり、そのため、光仁天皇のあとをついだ桓武天皇（かんむ てんのう）により、寺院の多い現在でいう奈良県から京都府へと都をうつす。まず784年に都を山背国（やましろこく）の長岡京に移した。 しかし、新都造営（しんとぞうえい）の中心人物であった藤原種継（ふじわらのたねつぐ）が暗殺されたり、政情不安が続いたので、794年に都を平安京に移した。 == 政治 == === 律令制度の立て直し === 桓武天皇は、国司に対する監督をきびしくするため、'''勘解由使'''（かげゆし）という役人を置きました。 :※ 『[[高等学校国語総合/土佐日記#門出（かどで）]]』に出てくる「解由」（げゆ）とは、このカゲユシ関連の書類である。著者の紀貫之（きの つらゆき）は、国司として、取り締まりされる側の立場。くわしくはリンク先で。 勘解由使に、国司の交代の際には、前任の国司に不正がなかったことを証明するための解由状（げゆじょう）を審査させた。 :※ 中学校で習った『[[中学校社会 歴史/平安時代]]』も参照せよ。 桓武天皇の政策として、辺境の他では徴兵をやめ、辺境の他では従来の軍団を廃止して、あらたに郡司の子弟で弓馬にたくみな者からなる健児（こんでい）を設けた。 また、このころ、都の造営と、蝦夷との戦いからなる二大事業が、国家財政や民衆の負担だった。 貴族間で、この事業の存続をめぐる論争が起き、桓武天皇はこの二大事業を中止した。 桓武天皇は、二大事業の存続の件で、管野真道（すがのまみち）と藤原緒嗣（ふじわらおつぐ）という2人の参議に論争させた（徳政論争）。（菅野が存続派。藤原が打ち切り派。） === 薬子の変 === 桓武天皇の死後、平城天皇（へいぜいてんのう）、つづいて809年に'''嵯峨天皇'''（さがてんのう）になった。 :※ 社会の変化により、従来の家柄や血筋による人事制度がうまく機能しなくなったため、嵯峨天皇らは、従来の官職を残しつつも、新たに、家柄にとらわれない新設の官職も設置して活用した。 嵯峨天皇（さがてんのう）のとき、'''薬子の変'''（くすこのへん）が起きた。しかし、薬子の変は失敗に終わった。 '''薬子の変'''<ref>薬子（くすこ）とは、平城太上天皇の愛人の名前。かつての学説では、薬子が事件の首謀者に近いと思われていたが、歴史研究では、単に上皇の罪を薬子が なすりつけられただけとかの別の可能性が否定できず、現代の学校教科書では この事件の呼び名で「平城太上天皇の変」という呼び名も西暦2003年ごろから増えてきた。とはいえ、では平城上皇が首謀者かというと、その証拠もとぼしく、真相は不明である。歴史的な事実としては、最終的に薬子は自殺したとされている。</ref>とは、810年に藤原薬子（ふじわらの くすこ）とその兄 藤原仲成（ふじわらの なかなり）が、平城太上天皇（平城上皇）をふたたび天皇の地位につけようとして失敗した事件。「'''平城太上天皇の変'''」ともいう。 嵯峨天皇は、あらかじめ'''蔵人所'''（くらうどのところ）を設置し、機密をあつかった。 蔵人所の長官を'''蔵人頭'''（くらうどのとう）という。蔵人頭（くらうどのかみ）には、藤原冬嗣（ふじわら ふゆつぐ）らが任命された。 また、京都の治安維持・警察をつかさどるために'''検非違使'''（けびいし）を置いた。 （※ 参考: ）検非違使が創設される前は、京都の治安維持・警察などの仕事は、複数の官庁（衛府（えふ）、刑部省、弾正台、京職など）に分散されて処理がされていた<ref>相澤理『歴史が面白くなる　東大のディープな日本史【古代・中世編】』、株式会社KADOKAWA (中経文庫)、2016年7月15日 、p.173</ref>。つまり、検非違使長の創設により、それらの処理がひとつの官庁に一元化された事になる。一説には、いわゆる「縦割り行政」の弊害を解消するという目的もあって京都という地域限定だが検非違使が設けられたのだろう、という説もある。<ref>相澤理『歴史が面白くなる　東大のディープな日本史【古代・中世編】』、株式会社KADOKAWA (中経文庫)、2016年7月15日 p.173</ref> これら新設の官職は令（りょう）には規定がないので、'''令外官'''（りょうのげかん）と呼ばれた。 検非違使も、令の規定によらずに犯罪人の取り締まりができた。（※ 東京書籍の見解） また、これら令外官では、家柄にとらわれずに有能な人材を登用できた。（※ 東京書籍の見解） :※ 令外官は嵯峨天皇によってはじめられたのではなく、702年の「参議」や、705年の「中納言」も、令外官である。ただ、令外官が重要な要職になったのが、嵯峨天皇の頃からである。 また、嵯峨天皇は、律令を補足した'''格'''（きゃく）と、官庁で施行する際の細則である'''式'''（しき）とを整備した。 嵯峨天皇のもとで、820年ごろ、'''光仁格式'''（こうにん〜）が出来た。 のちの天皇のもとで、「貞観格式」（じょうがん〜）・「延喜格式」（えんぎ〜）が出きた。これら3つ（光仁格式、貞観格式、延喜格式）をあわせて三代格式という。 （823年に嵯峨天皇は、つぎの天皇に皇位をゆずって退位する。） （833年には、）令（りょう）の条文の解釈を統一するための注釈書として『'''令義解'''』（りょうのぎげ）がつくられた。 （842年、嵯峨 元天皇が死没。） == 平安初期の密教文化 == 唐で仏教を学んだ'''最澄'''（さいちょう）と'''空海'''（くうかい）が日本に帰国して、仏教の知識も日本に持ち帰る。 空海は、唐では、インドから中国に伝えられたばかりの真言密教（しんごん みっきょう）を学んでいた。 空海が日本で'''密教'''（みっきょう）<ref>なお、既存の仏教など、経典を重んずる宗派のことを、密教の用語で「顕教」（けんきょう）という。 </ref>を広めた。（いっぽう、最澄が広めたのは法華経（ほけきょう）。） 空海は、高野山（こうやさん）に金剛峰寺（こんごう ぶじ）を建て、密教にもとづく'''真言宗'''（しんごんしゅう）をつくった。 また、最澄は比叡山（ひえいざい）に'''延暦寺'''（えんりゃくじ）をひらき、天台宗（てんだいしゅう）をつくった。 天台宗・真言宗の寺院の多くは、山中に建てられた。 :（空海の宗派の寺だけが山中にあるのではなく、最澄の宗派の寺も山中に建てられたことに、注意。） 天台宗も、しだいに密教の影響を受け、最澄の弟子の円仁（えんにん）・円珍（えんちん）が唐に留学して密教の知識を日本に持ち帰り、天台宗は密教化した。 真言宗の密教を'''東密'''（とうみつ）という。いっぽう天台宗の密教を'''台密'''（たいみつ）という。 また、従来の宗派でも山岳修行をしていたが、これらが天台・真言宗とむすびつき、'''修験道'''（しゅげんどう）が流行した。 密教の特徴として、加持（かじ）祈祷（きとう）など、呪法（じゅほう）的なお祈りで悟りが開けるとされる。 これらの特徴が、現世利益（げんぜりやく）を求める貴族に好まれた。また、密教は、経典よりも山岳修行などの修業を重んじる傾向がある。 いっぽう、奈良時代の後半から既に、日本古来の神々と仏教とをむすびつける'''神仏習合'''（しんぶつ しゅうごう）の考えがあった。 このため、神社の境内（けいだい）に神宮寺（じんぐうじ）を建てたり、神前（しんぜん）で読経（どきょう）する風習などがあったが、密教の普及とともに、これらの風習も普及した。 [[File:Murou-ji 4.jpg|thumb|室生寺（むろうじ）]] 大和の室生寺（むろうじ）では、伽藍（がらん）も地形に応じて自由に配置された。 :※ 伽藍とは、寺院の建物全体や、その構成のこと。 == 平安初期の文化 == 文芸では、漢詩・漢文が流行した。 勅撰漢詩文集の『凌雲集』（りょううんしゅう）、『文華秀麗集』（ぶんかしゅうれいしゅう）、『経国集』（けいこくしゅう）などが編纂（へんさん）された。 また、空海の漢詩文をあつめた『性霊集』（しょうりょうしゅう）もつくられた。 書道では、唐風の書が好まれ、嵯峨天皇・空海・橘逸勢（たちばなの はやなり）は'''三筆'''（さんぴつ）と呼ばれた。 有力な氏族たちは、一族から優れた官吏（かんり）を出すために、氏ごとの塾・予備校的な寮（りょう）の'''大学別曹'''（だいがくべっそう）を建てた。 また、空海は、大学や国学に入学できない庶民が仏教・儒教などを学べる'''綜芸種智院'''（しゅげいしゅちいん）を開いた。 '''大学別曹'''　和気（わけ）氏の弘文院（こうぶんいん）、藤原氏の勧学院（かんがくいん）、橘（たちばな）氏の学館院（がくかんいん）、在原（ありわら）氏の奨学院（しょうがくいん）、などがある。 {{-}} * 美術など [[Image:NYOIRIN KANSHINJI.JPG|thumb|歓心寺 如意輪（にょいりん）観音像 （大阪・観心寺）]] 絵画では、密教の世界観をあらわす'''曼荼羅'''（まんだら）が描かれた。 彫刻では、一本の大木を彫って作る'''一本造'''（いっぽんづくり）が流行した。 また、不動明王（ふどう みょうおう）の絵画や彫刻がつくられた。 {{-}} == 注・参考文献 == <references/> [[category:高等学校日本史|へいあんしよき]] bkop3sc6sd13w32p3i16q86af2i49bs 0 24158 205989 205736 2022-07-29T16:19:33Z 椎楽 32225 レイアウト変更。中途半端に紙の教科書寄りで読みにくかったため。 wikitext text/x-wiki {{Nav}} == 藤原北家の伸張 == [[ファイル:Ban dainagon ekotoba.jpg|thumb|550px|応天門（おうてんもん）の炎上（『伴大納言絵詞』より）]] 藤原北家の藤原冬嗣（ふゆつぐ）は、嵯峨天皇の信任を得て、冬嗣は蔵人頭に任命された。また、冬嗣の娘は、皇太子の妃になった。 冬嗣の子の'''藤原良房'''（よしふさ）が、842年の承和の変で、大伴・橘氏の勢力をそいだ。 858年に、幼少（9歳）の清和天皇が即位すると、藤原良房が外祖父として実権をにぎり、良房は'''摂政'''（せっしょう）になった。 さらに'''応天門の変'''<ref>大納言 伴善男（ばん よしお）が、左大臣 源信（みなもとの まこと）に罪をきせるために応天門に放火したとされる事件。この事件の処罰として、伴は流罪に処せられた。この事件は、良房の陰謀という説もある（※ 実教出版が紹介している。）</ref>で、伴氏などが失脚し、ますます藤原氏が権力をにぎった。 応天門の変（おうてんもん の へん）ののち、良房は正式に摂政に就任した。 ついで、良房の甥（おい）から養子になった'''藤原基経'''（もとつね）が、幼い陽成天皇（ようぜい〜）の摂政になり、884年には光孝天皇（こうこう〜）を即位させ、また、基経は'''関白'''（かんぱく）の地位についた。 （897年に基経は死亡。） 基経の死後、宇多天皇は、摂政・関白を置かずに、'''菅原道真'''（すがわらの みちざね）を重用した。 しかし、つづく醍醐天皇のときに、藤原時平（〜ときひら）の策謀により菅原道真は太宰府に左遷（させん）された。 醍醐・村上の両天皇は、摂政・関白を置かず、天皇みずからの親政を行った。 == 時事 == :966年に藤原道長（ふじわらの みちなが）が生まれるよりも前に、935年に関東で平将門の乱（たいらのまさかど の らん）が起きた。 :※ 小中学校では、のちの源平合戦とのつながりから、藤原道長よりも後に将門を紹介する。しかし、実際の歴史的順序は、けっして藤原氏が衰えてから将門の反乱が起きたのではない。 :939年の西国での藤原純友の乱（ふじわらのすみとも の らん）も、道長の生まれる前の出来事である。 == 注 == <references/> [[category:高等学校日本史|ふしわらしのたいとう]] jbn0sqk47ts0uac0aqcwdslmt3w4v1f 0 28508 206000 204713 2022-07-29T21:43:09Z Ef3 694 Bumpup go1.18.3 to go1.18.4 wikitext text/x-wiki {{Nav}} == 環境構築 == Goのプログラミングを学ぶには、なんらかのコンパイル・実行環境が必要です。 === オンラインコンパイル実行環境 === Goのコンパイルと実行をウェブブラウザからオンラインで行えるサイトがあります。 * [https://go.dev/play/ go.dev/play/] {{---}} 公式のオンラインコンパイル実行環境です。ネットワークサービスは禁止され、時計はいつも同じ時刻を返し、乱数も同じ系列を返します。このため実行結果は基本的に同じになります。 ** [https://gotipplay.golang.org/ gotipplay.golang.org] {{---}} リリース前の開発版のオンラインコンパイル実行環境です。 * [https://paiza.io/ja/projects/new?language=go paiza.io] {{---}} 多くのプログラミング言語のオンラインコンパイル実行環境です。 オンラインコンパイル実行環境を使えば、Goのコンパイル環境を構築しにくいスマートフォン・タブレット・ChromebookなどからもGoのプログラミングを学ぶことができます。 ;[https://go.dev/play/p/X0_wfzwyj-E 例] ← クリックまたはタップしてみてください。:<syntaxhighlight lang=go> package main import "fmt" func main() { fmt.Println("Hello, World") } </syntaxhighlight> === Windowsの場合 === [https://golang.org/ Goの公式サイト]のダウンロードページからMSIインストーラーをダウンロードし、起動するとインストールを開始できます。 Goは言語仕様で、「ソースコードは UTF-8 でエンコードされた Unicode テキスト」(''Source code is Unicode text encoded in UTF-8.'')と決められています<ref name="Source_code_representation">{{cite book | url = https://golang.org/ref/spec#Source_code_representation | title = The Go Programming Language Specification | chapter = Source code representation ¶ | date = Jul 26, 2021 | publisher = The Go website }} </ref>。 このため [[W:Microsoftコードページ932|Microsoftコードページ932]] に構成設定されている日本語Windowsの環境ではエンコーディングの違いによるトラブルに見舞われるケースがある点に注意が必要です。 === FreeBSDの場合 === FreeBSD Ports/Packages Collection の、<code>ports/lang/go</code> にあるので、 :<syntaxhighlight lang="csh"> % sudo make -C /usr/ports/lang/go all install clean </syntaxhighlight> でビルドしインストールできます。 また :<syntaxhighlight lang="shell"> % sudo pkg install go118-1.18.4_1 </syntaxhighlight> でビルド済みパッケージをインストールできますが、Goのバージョンアップやportsのパッチレベルの更新で <code>go118-1.18.4_1</code>の部分は変わるので、 :<syntaxhighlight lang="shell"> % pkg search '^go[1-9]' go117-1.17.12 Go programming language go118-1.18.4_1 Go programming language </syntaxhighlight> の様に、最初に最新のパッケージ名を確認してください。 === GNU/Linuxの場合 === GNU/Linuxではディストリビューションによってパッケージマネジャーとリポジトリーの構成によりコマンドは違いますが、ディストリビューションの配布しているGoをそのままインストールできます。 ディストリビューションごとにパッケージマネジャーの仕様や操作方法が異なるので、パッケージマネージャーの検索機能で go- あるいは golang- をキーワードに検索してパッケージの名前を調べてインストールしましょう。 また、これはGoのパッケージに限りませんが、パッケージマネジャーを操作してパッケージアーカイブが更新されていないか定期的に確認し、脆弱性の修正などが施される前のパッケージを使い続けないよう注意しましょう。 ディストリビューションによっては、それでもバージョンが古いこともあるので、最新版が必要な場合は[https://golang.org/dl/ 公式ウェブサイトのダウンロードページ]からバイナリーオプションの配布物をダウンロードするか、ソースコードを入手して、環境に合わせてビルドとインストールを行うと良いでしょう（Goは、セルフホスティング<ref>Goコンパイラーを始めとする、Goの言語処理系と支援環境は、Go自身で書かれています。</ref>なので、最初にバイナリーを入手してブートストラップするか、クロスコンパイルでターゲットでセルフコンパイル出来る状態を作る方法があります）。 == 動作確認 == インストール作業が完了したらバージョンの確認を行いましょう。 ;コマンド:<syntaxhighlight lang="shell"> go version </syntaxhighlight> でバージョンを確認できます。 ;Windowsでの表示結果の例:(Windows PowerShell)<syntaxhighlight lang="powershell"> PS C:\Users\myname> go version go version go1.18.4 windows/amd64 </syntaxhighlight> ;FreeBSDでの表示結果の例 :<syntaxhighlight lang="shell"> % go version go version go1.18.4 freebsd/amd64 </syntaxhighlight> ;GNU/Linuxのあるディストリビューションでの表示結果の例:<syntaxhighlight lang="shell"> $ go version go version go1.14.3 linux/amd64 </syntaxhighlight> ;Android で開発バージョンをセルフビルドした例:<syntaxhighlight lang="shell"> $ go version go version devel go1.18-e5f6d8d Mon Oct 4 23:29:20 2021 +0000 android/arm64 </syntaxhighlight> == Go言語の特徴 == ; 動的ではなく静的 : どのような型が使われているかをコンピュータに推測させるのではなく、使用する型を定義する必要があります。 ; インタプリタ型ではなくコンパイル型 : プログラムが実行される前にコンパイルされ、最初から直接機械語に変換されるのです。これは、コードを実行するための余分なステップがないため、いくつかの効率化につながる可能性があります。しかし、コードを動的に変更することができないということになります。 ; 厳密なシーケンシャルではなくコンカレント : Goでは、より簡単に同時処理を書いたり考えたりすることができます。これにより、ウェブやサーバーの開発などでよく見られる問題を、よりシンプルな設計で構築することができます。つまり、より複雑なタスクを、互いに通信することで調整される小さなタスクに分割するのです。さらに、この設計の利点は、これらの小さなタスクを並行して実行することができることです。 ; メモリーセーフ : Goがメモリの使用を処理して、境界を越えてプログラムがクラッシュするのを防ぐことを意味します。 ; ガベージコレクション : 使われなくなったメモリデータを再利用するために解放し、まだ使われているデータをより効率的に保存できることを意味しています。 {{Nav}} == 脚註 == <references /> j1qme3joxqp9j6he8zk7c99hxt8f2v9 0 28640 206001 202929 2022-07-29T22:13:19Z Ef3 694 /* BSD系Unixの場合 */ インストールが終わったら、インストールされたKotlinのバージョンを確認します。 ;バージョン確認:<syntaxhighlight lang="console"> % kotlinc -version info: kotlinc-jvm 1.7.10 (JRE 1.8.0_332-b09) </syntaxhighlight> もし :<syntaxhighlight lang="console"> % kotlinc -version kotlinc: Command not found. </syntaxhighlight> の様に、失敗するようでしたらインストール失敗も考えられますが、/usr/local/bin にPATHが通っているか確認してください。 wikitext text/x-wiki == 注釈 == Kotlinは、コンパイルのターゲットごとに大別すると * [[JavaScript]]向けであるKotlin/JS * [[w:Java仮想マシン]]向けのKotlin/JVM * [[w:LLVM]] 向けのKotlin/Native がある。 それぞれ、開発に必要になるものが微妙に異なる。 == Kotlin/JVM 環境のインストール方法 == === Windowsの場合 === ==== Javaのインストール ==== まず、2020年現在のJava開発元のオラクルのwebサイトに行って、Javaのインストーラーをダウンロードして、これをダブルクリック起動などしてインストールする。 単に、起動後に出てくるインストーラーに、「OK」ボタンなどで答えていけば、Javaがインストールされるのが通常。 ==== kotlinの入手 ==== GitHubにkotlinの公式リポジトリがある。 https://github.com/JetBrains/kotlin/ このリポジトリから、[https://github.com/JetBrains/kotlin/releases リリース情報]を開き、'''Assets''' をページ内検索しその章にある kotlin-compiler-1.7.0 をダウンロードする。 1.7.0 の部分は、リリースの度に更新されていくので、適宜、読み替えて欲しい。 ==== kotlin のインストール ==== GitHubからダウンロードしたkotlinコンパイラのZIPを展開すると、「kotlinc」というホルダー以下に展開されます（語尾に「c」がついている）。 目標として、このkotlincの場所に環境変数パスをこれから通せばいい。 なので、kotlincの保管場所は、単にインストールするだけなら どこでもいいのだが、Cドライブ直下またはCドライブの「Program Files」などにkotlincを移動したほうが、他のプログラマーとノウハウ共有しやすく管理しやすいだろう。 なので、たとえば今回は、Cドライブ直下にkotlincを移動したとしよう。 Windowsの環境変数には、システム環境変数とユーザ環境変数があるのだが、kotlinのインストールではシステム環境変数を設定する。システム環境変数は他のユーザと共有される。 システム環境変数を設定するには、デスクトップで「システムのプロパティ」を検索し、システムのプロパティを開き、［詳細設定］タブの右下にある［環境変数］ボタンをクリックして、［環境変数］画面を開き、システム環境変数の設定をする。 環境変数PATHの末尾に「;C:\kotlinc\bin」を追加する。なお、セミコロン;とコロン:の使い分けには中注意。 Cの直前にある「;」はセミコロンであり、意味はほかのアプリのパスとの区切り記号である。 Cの直後にある「:」はコロンである。 ともかく、環境変数パスの設定が正しく出来たら、インストールに成功しているはずなので、下記のように、バージョン確認コマンドなどで確認する。 コマンド入力は、Windowsアクセサリの『コマンド プロンプト』『Windows Terminal』あるいは『Power shell』から行える。 バージョン確認コマンドは、 kotlin -version であるので、単にこのコマンドを入力すればいい。 成功すれば Kotlin version 1.7.0-release-281 (JRE 1.8.0_332-b09) のように kotlin 自身と JRE のバージョンが表示される。 === Linuxの場合 === 2020年の現状では、Linux で kotlinのインストールのために、まず先にSDKMANというのをインストールしないといけない。（sdkmanを使わなくてもできるが、sdkmanを使うほうがラクである。） なお、sdkmanはkotlinに限らず、Java関連のいろいろなものをLinuxにインストールするのにも使われるので、ネット検索の際には混同しないように。 ==== sdkmanのインストール ==== Linuxの場合、コマンド :<nowiki> curl -s "https://get.sdkman.io" | bash</nowiki> でsdkmanが入る。（※ Fedora32で2020年6月18日に確認） なんか、アスキーアートみたいなのが出たあとに <!-- Now attempting の前の長い空白は、実機の仕様です。 --> <pre> Now attempting installation... Looking for a previous installation of SDKMAN... Looking for unzip... Looking for zip... </pre> （※ 後略） みたいなのが出て来て、 後半のほうに All done! とか Enjoy!!! とか書いてあれば、おそらくsdkmanのインストール自体は成功（まだパス設定などが、されていない）。 そのあと、sdkman のパス設定などのために、コマンド source "$HOME/.sdkman/bin/sdkman-init.sh" を入力。 このあと、インストールが成功したかどうかの確認のため sdk version もし sdkman のインストールに成功してれば、 <pre> ==== BROADCAST ================================================================= * 2020-06-17: Asciidoctorj 2.3.1 released on SDKMAN! #asciidoctorj * 2020-06-16: Micronaut 2.0.0.RC1 released on SDKMAN! #micronautfw * 2020-06-14: Jbang 0.31.0 released on SDKMAN! See https://github.com/jbangdev/jbang/releases/tag/v0.31.0 #jbang ================================================================================ SDKMAN 5.8.3+506 </pre> とか、こういう表示内容が出る。 しかし、まだsdkmanがインストールされただけである。 ==== sdkmanのインストール後 ==== sdkmanのインストールに成功したら、これから kotlin をインストールするため、さらにコマンド sdk install kotlin でkotlinをインストールする。 成功すれば、下記のような表示が出る <pre> Downloading: kotlin 1.3.72 In progress... ######################################################################### 100.0%######################################################################### 100.0% Installing: kotlin 1.3.72 Done installing! Setting kotlin 1.3.72 as default. </pre> これで kotlin のインストールが成功しているハズ。 最終確認として、バージョン確認をしてみよう。 コマンド kotlinc -version を実行すれば、 info: kotlinc-jvm 1.5.31 (JRE 17.0.1+12) のように表示されるだろう。 === BSD系Unixの場合 === NetBSDやFreeBSDなどのBSD系Unixの場合、Ports Collectionに、lang/kotlin としてエントリーがあるので ;ソースからビルド:<syntaxhighlight lang="console"> % sudo make -C /usr/ports/lang/kotlin all install clean </syntaxhighlight> あるいは ;パッケージからインストール:<syntaxhighlight lang="console"> % sudo pkg install lang/kotlin </syntaxhighlight> の2通りのインストール方法があります。 ソースからビルドと言っも、lang/kotlin の場合は2022年6月現在、GitHubからリリースバージョンのコンパイラーのZIPを fetch して展開するだけなので、ビルドオプションを変えてホスト環境に最適化などはしなしので、パッケージ版との差異はありません。 なお、どちらの方法も、jdk などのパッケージに不足があれば、依存関係により、ビルドあるいは fetch & install されます。 インストールが終わったら、インストールされたKotlinのバージョンを確認します。 ;バージョン確認:<syntaxhighlight lang="console"> % kotlinc -version info: kotlinc-jvm 1.7.10 (JRE 1.8.0_332-b09) </syntaxhighlight> もし :<syntaxhighlight lang="console"> % kotlinc -version kotlinc: Command not found. </syntaxhighlight> の様に、失敗するようでしたらインストール失敗も考えられますが、/usr/local/bin にPATHが通っているか確認してください。 aoh1mf7xrypav445e1m7a0utwtskn4o 0 28654 206005 201866 2022-07-29T23:42:29Z Ef3 694 /* ldc と dlang-tools */ ldcは、LLVMをベースに開発されたD言語処理系です。 dlang-toolsは、DMDとともに再配布されるツールや、様々なビルドタスクで内部的に使用される様々なツールで、単体でもリリースされています。 wikitext text/x-wiki == インストール方法 == Winowsでは、D言語の開発元のDigitalMarsが配布しているコンパイラであるDMDをインストールするのがラクです。 Linuxでは、もしGnome系のデスクトップ環境を使っているなら、GCC(GNU Compiler Collection)を D言語用に拡張したコンパイラである gcc-gdc をインストールするのがラクです。 gcc-gdc は略して「gdc」とも呼びます。GNUとは、主にオープンソース関連のアプリケーションを開発しているコミュニティのひとつです。 gcc および gdc は、DMDとは別のコンパイラですので、混同しないように。gcc の開発元である GNU は、D言語以外の他の多くのプログラム言語のコンパイラも開発しています。 === DMDのダウンロード/インストール === D言語の[https://dlang.org/download.html 公式ホームページ]から環境に合わせてインストーラ、あるいはzipファイル等をダウンロードしてください。 Windows版もLinux版も存在します。 ですが、Windows版の場合、日本語対応が不十分で、文字化けが起こります。 なので、英語だけでWindows版D言語を使うか、あるいは日本語を表示したいならLinux版を使うと良いでしょう。 Windows版の場合、コマンドプロンプトからD言語を使えるようにするため、D言語インストーラーに出てくる「DMC」にもチェックを入れて、DMCを追加インストールしてください。 インストールの設定時、DMD動作環境として MinGWを使うか、Visual Studio を使うかを聞かれます。初心者には MinGW のほうが設定がラクでしょう。（Visual Stuido は設定が複雑だったり、アカウント登録が必要だったりと、なにかとメンドウです。） さて、DMDがインストールが出来たら rdmd -v でバージョン確認します。 <pre> rdmd build 20200611 Usage: rdmd [RDMD AND DMD OPTIONS]... program [PROGRAM OPTIONS]... Builds (with dependents) and runs a D program. Example: rdmd -release myprog --myprogparm 5 </pre> :（後略） のように、表示されます。 === gdcをインストールする場合 === OS が Fedora Linux の場合なら、コマンド sudo dnf install gcc-gdc または sudo dnf install gdc でインストールできます。 ;バージョン確認 インストールに成功したと思ったら、動作確認を兼ねてバージョン表示をしてみましょう。コマンド gdc --version を実行すれば <pre> gdc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. </pre> のように表示されます。 === ldc と dlang-tools === ldcは、LLVMをベースに開発されたD言語処理系です<ref>[https://github.com/ldc-developers/ldc The LLVM-based D Compiler.]</ref>。 dlang-toolsは、DMDとともに再配布されるツールや、様々なビルドタスクで内部的に使用される様々なツールで、単体でもリリースされています<ref>[https://github.com/dlang/tools Ancillary tools for the D programming language compiler]</ref>。 両方ともFreeBSDのPort Collectionに lang/ldc と lang/dlang-tools の名前でエントリーがあるので ;pkg:<syntaxhighlight lang=console> # pkg install lang/ldc lang/dlang-tools </syntaxhighlight> ;ports:<syntaxhighlight lang=console> # make -C /usr/ports/lang/ldc all install clean # make -C /usr/ports/lang/dlang-tools all install clean </syntaxhighlight> でインストールできます。 ldc のコマンド名は ldc2 です。バージョンを確認確認してみます（サポートターゲットの数が多すぎるので head で割愛しました）。 ;バージョン確認:<syntaxhighlight lang=console> % ldc2 --version | head LDC - the LLVM D compiler (1.23.0): based on DMD v2.093.1 and LLVM 10.0.1 built with LDC - the LLVM D compiler (0.17.6) Default target: x86_64-portbld-freebsd13.0 Host CPU: cascadelake http://dlang.org - http://wiki.dlang.org/LDC Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) </syntaxhighlight> <!--9日前にLDC 1.30.0がリリースされたので対応必要か？2022-07-30--> dlang-toolsには、rdmdなどが含まれているので ;バージョン確認:<syntaxhighlight lang=console> % rdmd -v | head rdmd build 20220408 Usage: rdmd [RDMD AND DMD OPTIONS]... program [PROGRAM OPTIONS]... Builds (with dependents) and runs a D program. Example: rdmd -release myprog --myprogparm 5 Any option to be passed to the compiler must occur before the program name. In addition to compiler options, rdmd recognizes the following options: --build-only just build the executable, don't run it --chatty write compiler commands to stdout before executing them --compiler=comp use the specified compiler (e.g. gdmd) instead of ldmd2 % cat hello.d import std.stdio; void main(){ writeln("Hello world!"); } $ rdmd hello Hello world! </syntaxhighlight> この様に、DMDを使っているのと変わらないコンパイル環境が用意できます。 == 実行の仕方 == DMDで実行する場合と、gdcでインストールする場合とで、実行の方法が違います。 === DMDの場合 === コマンドプロンプトでカレントディレクトリを合わせた後 dmd ''対象ファイル名.d'' ''対象ファイル名.exe'' でコンパイルと実行。もしくは rdmd ''対象ファイル名'' の一行でコンパイルと同時に実行できます。 DMDとは、D言語の公式コンパイラです。 === gdcの場合 === コマンド gdc ファイル名.d です。 ファイル名を保存する際、ファイルの末尾に拡張子 d がついてないとエラーになりますので、コンパイルできません。なので、ファイル名はたとえば「test.d」や「hello.d」のような名称になります。 Linux の場合、特に出力ファイル名などを命名しなければ、「a.out」というファイル名になるので ./a.out で実行できます。 == ※ 参考: Hello World == <syntaxhighlight lang="D"> import std.stdio; void main() { writeln("Hello World!"); } </syntaxhighlight> :※ 文法の解説については省略します（別ページで解説しています）。ファイル実行のチェックの際、実行するコードとして活用してください。 [[カテゴリ:D言語]] 4rbsgk6qmvmzioi8oralymrxgj4i2ev 206009 206005 2022-07-30T05:39:06Z Ef3 694 /* 脚註 */ <references /> wikitext text/x-wiki == インストール方法 == Winowsでは、D言語の開発元のDigitalMarsが配布しているコンパイラであるDMDをインストールするのがラクです。 Linuxでは、もしGnome系のデスクトップ環境を使っているなら、GCC(GNU Compiler Collection)を D言語用に拡張したコンパイラである gcc-gdc をインストールするのがラクです。 gcc-gdc は略して「gdc」とも呼びます。GNUとは、主にオープンソース関連のアプリケーションを開発しているコミュニティのひとつです。 gcc および gdc は、DMDとは別のコンパイラですので、混同しないように。gcc の開発元である GNU は、D言語以外の他の多くのプログラム言語のコンパイラも開発しています。 === DMDのダウンロード/インストール === D言語の[https://dlang.org/download.html 公式ホームページ]から環境に合わせてインストーラ、あるいはzipファイル等をダウンロードしてください。 Windows版もLinux版も存在します。 ですが、Windows版の場合、日本語対応が不十分で、文字化けが起こります。 なので、英語だけでWindows版D言語を使うか、あるいは日本語を表示したいならLinux版を使うと良いでしょう。 Windows版の場合、コマンドプロンプトからD言語を使えるようにするため、D言語インストーラーに出てくる「DMC」にもチェックを入れて、DMCを追加インストールしてください。 インストールの設定時、DMD動作環境として MinGWを使うか、Visual Studio を使うかを聞かれます。初心者には MinGW のほうが設定がラクでしょう。（Visual Stuido は設定が複雑だったり、アカウント登録が必要だったりと、なにかとメンドウです。） さて、DMDがインストールが出来たら rdmd -v でバージョン確認します。 <pre> rdmd build 20200611 Usage: rdmd [RDMD AND DMD OPTIONS]... program [PROGRAM OPTIONS]... Builds (with dependents) and runs a D program. Example: rdmd -release myprog --myprogparm 5 </pre> :（後略） のように、表示されます。 === gdcをインストールする場合 === OS が Fedora Linux の場合なら、コマンド sudo dnf install gcc-gdc または sudo dnf install gdc でインストールできます。 ;バージョン確認 インストールに成功したと思ったら、動作確認を兼ねてバージョン表示をしてみましょう。コマンド gdc --version を実行すれば <pre> gdc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. </pre> のように表示されます。 === ldc と dlang-tools === ldcは、LLVMをベースに開発されたD言語処理系です<ref>[https://github.com/ldc-developers/ldc The LLVM-based D Compiler.]</ref>。 dlang-toolsは、DMDとともに再配布されるツールや、様々なビルドタスクで内部的に使用される様々なツールで、単体でもリリースされています<ref>[https://github.com/dlang/tools Ancillary tools for the D programming language compiler]</ref>。 両方ともFreeBSDのPort Collectionに lang/ldc と lang/dlang-tools の名前でエントリーがあるので ;pkg:<syntaxhighlight lang=console> # pkg install lang/ldc lang/dlang-tools </syntaxhighlight> ;ports:<syntaxhighlight lang=console> # make -C /usr/ports/lang/ldc all install clean # make -C /usr/ports/lang/dlang-tools all install clean </syntaxhighlight> でインストールできます。 ldc のコマンド名は ldc2 です。バージョンを確認確認してみます（サポートターゲットの数が多すぎるので head で割愛しました）。 ;バージョン確認:<syntaxhighlight lang=console> % ldc2 --version | head LDC - the LLVM D compiler (1.23.0): based on DMD v2.093.1 and LLVM 10.0.1 built with LDC - the LLVM D compiler (0.17.6) Default target: x86_64-portbld-freebsd13.0 Host CPU: cascadelake http://dlang.org - http://wiki.dlang.org/LDC Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) </syntaxhighlight> <!--9日前にLDC 1.30.0がリリースされたので対応必要か？2022-07-30--> dlang-toolsには、rdmdなどが含まれているので ;バージョン確認:<syntaxhighlight lang=console> % rdmd -v | head rdmd build 20220408 Usage: rdmd [RDMD AND DMD OPTIONS]... program [PROGRAM OPTIONS]... Builds (with dependents) and runs a D program. Example: rdmd -release myprog --myprogparm 5 Any option to be passed to the compiler must occur before the program name. In addition to compiler options, rdmd recognizes the following options: --build-only just build the executable, don't run it --chatty write compiler commands to stdout before executing them --compiler=comp use the specified compiler (e.g. gdmd) instead of ldmd2 % cat hello.d import std.stdio; void main(){ writeln("Hello world!"); } $ rdmd hello Hello world! </syntaxhighlight> この様に、DMDを使っているのと変わらないコンパイル環境が用意できます。 == 実行の仕方 == DMDで実行する場合と、gdcでインストールする場合とで、実行の方法が違います。 === DMDの場合 === コマンドプロンプトでカレントディレクトリを合わせた後 dmd ''対象ファイル名.d'' ''対象ファイル名.exe'' でコンパイルと実行。もしくは rdmd ''対象ファイル名'' の一行でコンパイルと同時に実行できます。 DMDとは、D言語の公式コンパイラです。 === gdcの場合 === コマンド gdc ファイル名.d です。 ファイル名を保存する際、ファイルの末尾に拡張子 d がついてないとエラーになりますので、コンパイルできません。なので、ファイル名はたとえば「test.d」や「hello.d」のような名称になります。 Linux の場合、特に出力ファイル名などを命名しなければ、「a.out」というファイル名になるので ./a.out で実行できます。 == ※ 参考: Hello World == ;hello.d:<syntaxhighlight lang="D"> import std.stdio; void main() { writeln("Hello World!"); } </syntaxhighlight> :※ 文法の解説については省略します（別ページで解説しています）。ファイル実行のチェックの際、実行するコードとして活用してください。 == 脚註 == <references /> [[カテゴリ:D言語]] i0r14d6balebq9vfk92sl7r7w1nn7h4 0 33920 206003 205980 2022-07-29T22:25:33Z Mtodo 450 wikitext text/x-wiki {{Nav}} {{Pathnav|メインページ|小学校・中学校・高等学校の学習|小学校の学習|小学校社会|6学年|歴史編|frame=1}} {| class="wikitable" style="width:100%" |+ この章の概要 |<!--1889年前後から「国際的地位が向上」（1920年国際連盟成立 常任理事国入り）まで--><!--（コ） 大日本帝国憲法の発布，日清・日露の戦争，条約改正，科学の発展などを手掛かりに，我が国の国力が充実し国際的地位が向上したことを理解すること。--> ★時代区分:明治時代後期、大正時代</br> ★取り扱う年代:1889年（大日本帝国憲法の発布）から1925年（昭和改元）まで ; 大日本帝国憲法の制定 : 明治維新の改革は、五箇条の御誓文の方針によりなされましたが、改革が進み近代文明国としての形がひととおり整ってきたところ、さらに政治の形を確かなものとし、人々の権利を明らかにするため、'''憲法'''の制定と選挙によって選ばれた議員による議会を開くことが求められました。'''板垣退助'''や'''大隈重信'''は国会の開設を求めて、政党をつくりました。'''伊藤博文'''を中心とした明治政府は欧米諸国の憲法を研究し、1885年に'''内閣制度'''が創設され、1889年に'''大日本帝国憲法'''が発布されました。翌年憲法の精神に基づいて、初めて総選挙が行われ'''帝国議会'''（国会）が召集されました。 ; 日清戦争と日露戦争 : 急激な近代化に成功した日本は、国内で拡大した産業の新たな市場を求め大陸に進出しようとします。朝鮮は中国の帝国'''{{ruby|清|しん}}'''の属国でしたが、その影響で近代化が進んでおらず、朝鮮国内の近代化を求める人々は日本と協力して清の影響から逃れようとしました。朝鮮国内の清に従う保守派と改革派の争いに日本と清はそれぞれ兵を出すなどして緊張が高まり、1894年朝鮮半島西岸における両国海軍の接触をきっかけに'''日清戦争'''が始まりました。日本は清の北洋海軍を壊滅させ、遼東半島を占領するなど戦いを有利に進め、翌年、'''陸奥宗光'''外務大臣と清の提督である李鴻章が交渉し、清の日本への賠償や台湾・遼東半島の割譲などを定めた下関条約が締結され講和が結ばれました（日本の勝利）。 : 遼東半島はロシア、ドイツ、フランスが反対したので割譲は取りやめとなりましたが（三国干渉）、そこにロシアが進出し、それを警戒する日本と対立しました。1904年日本とロシアは開戦し（'''日露戦争'''）、日本とロシアは、ロシアが植民地としていた遼東半島や中国東北部（満州）で戦いました。日本は多くの犠牲者を出しましたが、'''東郷平八郎'''がロシアのバルチク艦隊をやぶるなどして有利な位置となり、翌年、'''小村寿太郎'''外務大臣とロシアのウィッテが交渉し、ロシアの中国からの撤退、南満州鉄道の譲渡、南樺太の割譲などを定めたポーツマス条約が締結され講和が結ばれました（日本の勝利）。 ; 条約改正と国際社会での地位の向上 : 幕末に欧米各国と結ばれた通商条約（不平等条約）の改正は日本政府の悲願でした。まず、政府は、国内の法整備を進め、公正な裁判が行われることを示し、日清戦争終結後の1899年治外法権を撤廃しました。そして、日露戦争の勝利は、世界に驚きをもってむかえられ、国際的地位も上がったことをうけて、1911年関税自主権も回復しました。 : 1912年大正天皇が即位し、元号が「'''大正'''」となりました。 : 1914年にヨーロッパの国々を二分した'''第一次世界大戦'''が始まりました。日本は、イギリスやフランスの属する連合国に参加し、敵対する同盟国の一つであるドイツが租借する中国の{{ruby|青島|チンタオ}}や南太平洋の島々を占領しました。1919年戦争は連合国の勝利に終わり、翌年、平和を維持するための'''国際連盟'''が設立、日本は英仏などとともに常任理事国の一つとなりました。 : このころになると、日本の科学技術の水準も世界的なものになり、'''野口英世'''のように国際的な研究者がでてくるようになりました。 |} === 世界の変化2 - 市民革命 === :日本が鎖国をしている間、ヨーロッパやそれを受けたアメリカ大陸では、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#世界の変化1 - 産業革命|産業革命]]ともうひとつの大きな社会変革が起こっていました。 ;市民革命以前のヨーロッパ :ヨーロッパの国々も長い間、生まれながら身分によって職業などが決められ、多くの人々は農民や職人として土地（荘園）の領主（「{{ruby|封建|ほうけん}}領主」といいます）や都市の貴族などに服従する社会でした。また、この時代は、ローマ教皇を頂点とする'''カトリック教会'''が、強い影響力や荘園を持っていたというのは、[[小学校社会/6学年/歴史編/戦乱の世の中と日本の統一-戦国時代・安土桃山時代#キリスト教|前にお話ししたとおり]]です。この時代を{{ruby|封建|ほうけん}}制<ref>土地（領地）を間に介して、主従関係を結ぶ制度を言います。日本でも、[[小学校社会/6学年/歴史編/武家社会の始まり-鎌倉時代#封建制|鎌倉時代の「'''ご恩と奉公'''」の関係]]はこれにあたりますし、安土桃山時代から江戸時代にかけての[[小学校社会/6学年/歴史編/戦乱の世の中と日本の統一-戦国時代・安土桃山時代#石高制|石高制]]も封建制の一種です。</ref>の時代と言います。 :14世紀くらいになると、都市を中心に商業が発展してきて、豊かな財産を持って、荘園領主よりも強い影響力を持つようになる者もでてきました。15世紀「[[小学校社会/6学年/歴史編/戦乱の世の中と日本の統一-戦国時代・安土桃山時代#大航海時代|大航海時代]]」になると、さらに、貿易や植民地からの収益で都市の商人などは勢力を強くしました。また、繊維工業などを中心に、人を集めて工場などを経営する人たちもあらわれました。これらの、封建領主や貴族ではない階層の人たちを、「{{ruby|市民|しみん}}階級」といいます。これらの、市民階級の経済力を背景に、ヨーロッパの各地で強い力を持った国王が誕生し、伝統的な荘園領主などを圧倒しました。これを、{{ruby|絶対王政|ぜったいおうせい}}の時代といいます。絶対王政の王国は、政治を行う政府は専門の役人をおき、戦争に備えて軍隊を平時から常設するようになりました<ref>封建制の時代は、国王でも自分の荘園をおさめられる程度の役人がいればよく、戦争などでは、その都度、封建領主に命令して軍隊（騎士）を集めていました。</ref>。 ;市民革命と近代国家 :市民階級が台頭してくると、封建制度以来の身分制度に対して、生まれながらの身分にかかわらず人間は'''平等'''であり、'''自由'''に発言や経済活動をする'''権利'''（'''人権'''）を持っているという考え方が広がってきました。また、封建制の時代はおさめている荘園の収穫から政治を行っていましたが、絶対王政の政府は、市民階級からの税金で成り立っていたのですが、税金を取られる市民たちは国王の都合だけで徴税されることに不満を持ち始めました。こうして、17世紀以降、市民階級は絶対王政と対立するようになります。市民階級は代表を出して、政治に参加するようになります。'''議会'''（'''国会'''）の始まりです。さらには、国王の圧政に対しては、市民階級が集まって武力をもって王政を倒したりしました。これを「'''{{ruby|市民革命|しみんかくめい}}'''」と言います。 :市民革命は、17世紀のイギリスに始まりました （'''清教徒革命'''など）。ひきつづいて、北アメリカ大陸のイギリス植民地が、独立を求めて戦争を起こしアメリカ合衆国が成立しました （'''アメリカ独立戦争'''）。そして、1789年代表的市民革命である'''フランス革命'''が起こります。市民革命は、フランスの'''ナポレオン'''が、フランスの革命政府を打ち倒そうとする周辺の国々を逆にせめた戦争によってヨーロッパ各地に広がります。 :市民革命自体は、各国の状況によって様々な結果を生みました。革命後に王政が復活した国もあります。しかし、市民革命で国の政治に身分によらない一般の市民が参加できるようになって、広く国全体から資金を集める仕組みができたこと、また、兵隊に国民が動員されるようになったこと（'''[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#徴兵制|徴兵制]]'''）から、数が多く強力な軍隊を持つようになり、それまでの、封建的な国や絶対王政の国を圧倒するようになりました。これらの古い体制の国々も、市民階級を国の政治に参加させるように、国の仕組みを変えるようになりました。まず、国民の権利を保障し、国民の代表が参加する'''議会'''を設置して国の政治に参加できるようにしました。そして、そのことを'''憲法'''という、強い力を持った法律に定めるようになりました。 :国が、国王などの所有物ではなく、そこに住む国民によって成立するという近代国家（'''国民国家'''）の誕生です。 === 大日本帝国憲法の制定 === [[File:Taisuke ITAGAKI.jpg|thumb|125px|板垣退助]] [[File:OKUMA_Shigenobu.jpg|thumb|125px|大隈重信]] [[file:Itō Hirobumi.jpg|thumb|125px|伊藤博文]] :明治になって、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#四民平等|身分制度がなくなり]]<ref name="華族">実際は、公家や大名、明治政府に大きな貢献のあった人たちについては、{{ruby|公爵|こうしゃく}}・{{ruby|侯|こう}}爵・{{ruby|伯|はく}}爵・{{ruby|子|し}}爵・{{ruby|男|だん}}爵といった貴族の爵位が与えられ、その一族は「{{ruby|華族|かぞく}}」と呼ばれました。華族には、いくつかの特権が認められましたが、華族の数は比較的少ないうえ、江戸時代ほど極端に大きな差ではありませんでしたし、社会的な貢献をすることで、誰でも華族となる機会はありました。また、「士族」と「平民」の間で異なる取り扱いは一切ありませんでした。</ref>、人々は才覚や努力によって、どのような職業に就くこともできるようになりました。人々は、学業をはじめとしたさまざまな努力をして、いろいろな分野で活躍するようになりました。 :明治政府は、さまざまな改革を強引に進めたため民衆と対立することも少なくありませんでした。このような民衆の不満は、[[#士族の反乱|士族の反乱]]の後は、こうした近代思想を取り入れて政治参加を求める{{ruby|自由民権|じゆうみんけん}}運動につながります。自由民権運動は、憲法の制定と、民衆が政治に参加できる選挙を通じた国会の開設をもとめるようになります。自由民権運動は、征韓論で下野した'''[[小学校社会/6学年/歴史編/人物事典#板垣退助|{{ruby|板垣退助|いたがきたいすけ}}]]'''と1881年（明治14年）に'''[[小学校社会/6学年/歴史編/人物事典#伊藤博文|{{ruby|伊藤博文|いとうひろぶみ}}]]'''らと対立して政府を離れた'''[[小学校社会/6学年/歴史編/人物事典#大隈重信|{{ruby|大隈重信|おおくましげのぶ}}]]'''らに主導されました。 :大隈や板垣が主導する自由民権運動の主張は、国民の自由と権利を保障する憲法の制定とそれに基づく国民の選挙による議会（民選議会）の開設及び議会による政府の統制でした。伊藤博文ら明治政府を主導する人たちは、自由民権運動の考えをそのまま受け入れると、政策を政府が思うとおりに進めることができず、富国強兵などの改革政策に差しさわりがあると考え、この運動を弾圧しました。一方で各地の有力者や、新たな産業の成功者が登場してきており、明治政府はこれらの人々の支持を受けたいと思っていました。また、欧米諸国から見ると、民選議会が政治を進めない国は遅れているとの意識があり、不平等条約改正にあたっても説得させることができない理由の一つとなっていました。 :1881年（明治14年）明治政府は、明治天皇名で「国会開設の勅諭」を下し、1889年（明治22年）に国会を開設することを国民に約束しました。これを受けて、自由民権運動の活動家は政党を結成し、同年には自由党が板垣退助を中心として、翌1882年（明治15年）立憲改進党が大隈重信らによって結成されました。 :一方、伊藤は、1882年（明治15年）、憲法制定・国会開設の模範を研究するためためにヨーロッパを視察しました。そこで、伊藤は議会が発達したイギリスや、人権思想が進んでいたフランスではなく、ドイツ帝国の憲法を模範にすることとしました<ref>この頃のドイツは、日本が藩に分かれていたのと同様に、多くの王国・貴族領に分かれていたものを、各地で統一の要望が上がり、その中で有力となったプロイセン国王を皇帝とするドイツ帝国が成立していました。ドイツ帝国は、イギリスやフランスよりも、皇帝（それを受けた行政機関）の権限が強く、議会の力はおさえられていました。ドイツは、英仏に比べ工業化などが遅れていたために、それを推進するために、強い行政の力が必要であったためです。また、各個人の人権についても制限がありました。伊藤が、英仏ではなく、ドイツを国の形の模範としたのは、このように、日本と状況が似ていたためです。</ref>。帰国した伊藤は憲法制定の準備をはじめ、1885年（明治18年）に内閣総理大臣を長とする'''内閣制度'''が創設され、1889年（明治22年）に'''大日本帝国憲法'''（明治憲法<span id="明治憲法"/>）が発布されました。翌1890年（明治23年）7月1日憲法の精神に基づいて<ref>明治憲法が、実際に有効となる（施行される）のは、1890年（明治23年）11月29日なので、まだ、憲法の下の選挙・国会の招集ではありませんでした。</ref>、初めて総選挙が行われ、11月25日'''帝国議会'''（国会）が召集されました。 :明治憲法は以下のことを定めています。 :#天皇は、日本の統治者とされます。 :#国会は、天皇に「協賛」して法律や予算を定める機関とされます。 :#*法律や予算を決めるのは天皇であって、国会は、その補助をしているに過ぎないという考えを表しています。 :#*緊急と認められる時には、天皇<ref>実際は、行政府である政府の仕事です。</ref>は国会の議決によらず、法律に代わる勅令を出すことができました。 :#国会は、貴族院と衆議院により成り立ち、衆議院は選挙によって選ばれた議員により構成され、貴族院は皇族・華族<ref name="華族"/>及び勅命<ref>天皇の命令。実際は、その時の行政府による指名。</ref>で任名された議員により構成されます<ref>ただし、このような議会の成り立ちは、世界的に見ても珍しいものではありませんでした。明治憲法の元になったドイツ帝国の議会が貴族院と衆議院で成り立っていましたし、そもそも、議会政治の模範とされるイギリスも世襲貴族による「貴族院」と選挙で選ばれた議員による「庶民院」で構成されていて、現在もその伝統が残ります。このことで、身分で選ばれた議員による議会を「上院」、選挙で選ばれた議員による議会を「下院」という習慣ができました。アメリカ合衆国には独立当時から貴族制度はありませんでしたが、上院は各州の代表（元々は州議会が選出していましたが、現在は州民の選挙によります）、下院は州にかかわらず選挙で選ばれた議員による議会と、上院と下院で性質を変えていたりします。時代が下るにつれ、選挙で選ばれた議員の決めることが優先されるという政治習慣（下院優先の原則）が有力になります。</ref>。 :#*衆議院の優位などの定めはなく、各議院で議決されなければ法律などは成立しませんでした。 :#*<span id="制限選挙"/>衆議院議員の選挙権は、憲法を定めた当時は、一定以上の税金を納めた者にのみ認められていました。 :#国務大臣は天皇を{{ruby|輔弼|ほひつ}}（助言し助ける）すると定められます。また、内閣総理大臣についての定めはありません。 :#*<span id="内閣総理大臣"/>内閣総理大臣は、天皇が指名する建前でしたが、実際には、元老といわれる人達<ref>元老には、最初は伊藤博文など維新の功臣が、後代には長期に首相を務めた者がなりました。</ref>が協議したり、後には首相経験者などで構成する重臣会議で決議して天皇に{{ruby|推薦|すいせん}}して決まるものでした。 :#軍隊（陸海軍）は天皇が直接まとめひきいるとされました。また、国民には徴兵に応じる義務がありました。 :#*軍隊は、国会や内閣の命令を聞く必要がないと解釈されるようになります。 :#様々な国民の人権が認められましたが、それは、法律の範囲内で認められるものとされました。 :#*例えば、女性には選挙権は認められることはありませんでした。また、民法で家族や相続は家制度によったため、女性は不利な取り扱いを受けました。 :#*後に制定される治安維持法は、政治思想（特に[[小学校社会/6学年/歴史編/戦争への道と現代の民主国家日本の誕生-昭和から現在まで#社会主義と共産主義|社会主義思想・共産主義思想]]）を取り締まる法律でした。 === 日清戦争と日露戦争 === ==== 日清戦争 ==== [[File:《马关条约》签字时的情景.jpg|thumb|right|200px|none|下関条約の調印の様子。　向かって左に着席するのが日本の伊藤全権、右が清国の李全権]] : 急激な近代化に成功した日本は、国内で拡大した産業の新たな市場を求め大陸に進出しようとします<ref>「急激な近代化に成功した日本」と書きましたが、これは、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#世界の変化1 - 産業革命|前の章の『産業革命』の節]]に書いた「欧米各国は、産業革命で経済力が大きくなりましたが、さらにそれを大きくするため、国内で生産する工業製品の{{ruby|市場|しじょう}}と原材料となる農産物や鉱物資源を欧米諸国の外に求めるようになりました。」の部分を日本に当てはめたものです。しかし、この頃の日本の工業力はまだ近代化が始まったばかりで、外国に市場を求めるまで成長していません。</ref>。朝鮮は中国の帝国'''{{ruby|清|しん}}'''の属国でしたが、その影響で近代化が進んでおらず、朝鮮国内の近代化を求める人々は日本と協力して清の影響から逃れようとしました。朝鮮国内の清に従う保守派と改革派の争いに日本と清はそれぞれ兵を出すなどして緊張が高まり、1894年（明治27年）朝鮮半島西岸における両国海軍の接触をきっかけに'''日清戦争'''が始まりました。日本は清の北洋海軍を壊滅させ、黄海沿岸の軍事拠点を攻撃し、遼東半島を占領するなど戦いを有利に進め、翌1895年（明治28年）、'''[[小学校社会/6学年/歴史編/人物事典#陸奥宗光|{{ruby|陸奥宗光|むつむねみつ}}]]<span id="陸奥宗光"/>'''外務大臣と清の提督である{{ruby|李鴻章|りこうしょう}}が交渉し、以下の事項などを定めた'''下関条約'''が締結され講和が結ばれました（日本の勝利）。 :#清は、朝鮮の独立を認める。 :#清は、日本へ台湾と{{ruby|遼東|<small>りょうとう/リャオトン</small>}}半島<ref name="中国地名">中国の地名については、日本語の音読みで読む方法と現代の中国語に近い音で読む方法があります。後者は、「音読みだと日本人にしか通じない」と言う配慮から現代の中国語に近い音を当てると言う意図なのかもしれませんが、実際の発音とは異なっているので中国人にも伝わらないでしょう。ですから、ここでは、原則として音読みで音をふりますが、{{ruby|北京|ペキン}}、{{ruby|上海|シャンハイ}}のように現代中国語音に似せた言い方が一般的になったものもありますので、それらは、よく使う言い方をカタカナで表記します。</ref>を割譲する。 :#清は、日本へ賠償金2億両<ref>1両は銀37.3gで、当時の日本円に換算して約3億円。これは、政府の年間予算の約3倍にあたります。</ref>を支払う。 :#*日本は、この賠償金を資金として大規模な製鉄所を福岡県に作りました（'''{{ruby|八幡|やはた}}製鉄所'''）。 :清はそれまでも、イギリスやフランスと争って負けてはいましたが、欧米諸国は、それでも清国は世界最大の人口をかかえる巨大な国<ref>当時、3億人を超える程度の人口があったものとされています。</ref>であって、実力を発揮すれば欧米諸国であっても勝てるものではないと思われていた<ref>これを、「清国は『眠れる獅子』だ」という言い方をします。</ref>ので中国本土への進出はおさえられていましたが、近代化後間もない日本に敗れたため、欧米諸国は清国への進出を強め、中国大陸の多くの地域で欧米諸国の半植民地と言ってよい状態になりました。 <div style="margin:0 2em 0 4em"> {| class="wikitable" style="width:100%" |'''【脱線 - 覚えなくてもいい話&考えてみましょう】日本は、どうして清国に勝てたのでしょう<small> :戦争の勝敗の原因は、様々な要素があって、簡単に決めることができるものではありませんが、その時代の当事国の違いを比較することで、国の体制などの特徴を理解することができます。ここでは、なぜ、清国はやぶれ、日本は勝つことができたのかを考えてみましょう。 :戦争の勝敗を決める要素の第一は双方の国の規模です。大きな国の方が当然有利です。このころ、日本の人口はようやく4千万人程度のところ、清国の人口は3億人を超えていました。農業に適した広大な国土を有しており、近代化が遅れていたとは言え、税収などは日本よりもはるかに大きかったと考えられます。日清戦争の前も、世界最大級の軍艦をドイツから購入していたりします。相手の政権を倒すまでの全面戦争と言われる戦争であれば、日本は、勝つことは難しかったでしょう。 :一方で、清国は皇帝の軍隊は{{ruby|八旗|はっき}}・{{ruby|緑営|りょくえい}}と言われる17世紀の軍隊のままで、これは、日本の武士同様将兵が生まれながらの家柄で決まっている軍隊でしたが、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#アヘン戦争|アヘン戦争]]以後の近代的戦争や民衆の反乱<ref>銃器などを欧米の商人から買っていました。</ref>では対応できなくなっていました。そこで、地方に派遣された高官は地元の有力者に呼びかけ、その地方の税を流用するなどして、地元の若者を集め、私的に軍隊を組織していました。一種の義勇兵ですが、実際は金を払って集めた{{ruby|傭兵|ようへい}}も少なくなかった言われています。 :また、清国は皇帝が独裁する事が建前であったため、外交と軍事がばらばらの動きをし、軍事も統一的な動きはできていませんでした。 :日本の場合、中央政府が全国民から国の制度として兵を集め、政府の予算で設備をそろえ、組織だった訓練を実施した軍隊を有していました。また、「天皇の軍隊」「日本国の軍隊」としての『国民』意識も高く、これが、士気につながりました。 :このような違いから、黄海およびその沿岸での戦闘という局地的な戦争では、国の規模の違いにかかわらず勝つことができたということです。 </small> |}</div> ==== 日露戦争 ==== [[画像:Location-of-Liaodong-Peninsula.png|thumb|150px|left|遼東半島]] [[ファイル:Kisaburō Ohara, Europe and Asia Octopus Map, 1904 Cornell CUL PJM 1145 01.jpg|thumb|300px|right|1904年当時、日本人がロシアにもったイメージを伝える風刺地図。]] :下関条約で、日本は、台湾などとともに中国本土の遼東半島の割譲を受けましたが、ロシア、ドイツ、フランスが反対し（'''{{ruby|三国干渉|さんごくかんしょう}}'''<ref>「干渉」とは、「他のものの動きに影響を与える」という元々の意味から、このような場合、「他国の政治に口を出す」という意味で使われています。</ref>）、遼東半島の割譲は取りやめとなりました。ところが、その遼東半島にはロシアが進出し、{{ruby|大連|だいれん}}、{{ruby|旅順|りょじゅん}}<ref name="中国地名"/>といった都市を建設し始めました。 :ロシアは、ユーラシア大陸を横断する鉄道（'''シベリア鉄道'''）を建築し、ヨーロッパとアジアの間の物流をおさえようとしていました<ref>日本からイギリスやフランスまで、船ならば45日〜50日かかったところを、シベリア鉄道を使えば15日程度で移動できました。</ref>。シベリア鉄道は、もともと、ロシア領内をウラジオストックまでのものですが、ロシアは遼東半島支配に伴って、大連まで{{ruby|東清|とうしん}}鉄道を建設し、その途中である{{ruby|満州|まんしゅう}}地域<ref>現在は、中国東北部と呼ばれる地域です。もともと、「満州（満洲）」とは清王朝をおこした民族（女真族）の名前で地名ではありませんが、「満洲族が起こった土地」と言うことで通称として用いられるようになりました。このころから、1945年頃まで、満州は日本にとって歴史上重要な土地となります。</ref>を実質的に植民地とするなど支配を強めます。そして、満州に接する朝鮮（日清戦争後、{{ruby|大韓帝国|だいかんていこく}}）の政治にも介入するなどしはじめました<ref>ロシア進出の背景には、大韓帝国の王室のメンバーや{{ruby|両班|ヤンバン}}と呼ばれる高級官僚らが、朝鮮の政治・経済に段々影響を強めてくる日本を警戒して、それに対抗するため、ロシアと通じていたということもあります。</ref>。 :日本は、ロシアの動きに対して警戒しました。ロシアが満州地域でやっていることは、他のヨーロッパ諸国がアジアやアフリカでやっていて、日清戦争後に中国本土で進められている植民地化であって、そのままでは、満州地域だけでなく、朝鮮半島も、さらには日本までもが、植民地となってしまうのではないかと考えました<ref>これは、大げさな話ではなく、アフリカの植民地化はこの時期に進み、19世紀末には独立国は、エジプト周辺、エチオピア、リベリアだけになっていましたし、アジアも1887年にフランスがベトナムを植民地にするなどして、独立を保っていたのはシャム王国（現在のタイ王国）くらいになっていました。</ref>。 :日本政府では、伊藤博文に代表される日露の衝突を外交努力などで避けるべきとするグループがあった一方で、陸軍に対して大きな影響を持った'''[[小学校社会/6学年/歴史編/人物事典#山県有朋|{{ruby|山県|やまがた}}(山縣){{ruby|有朋|ありとも}}]]'''や首相の{{ruby|桂太郎|かつらたろう}}、外交官出身の外務大臣'''[[小学校社会/6学年/歴史編/人物事典#小村寿太郎|{{ruby|小村寿太郎|こむらじゅたろう}}]]<span id="小村寿太郎"/>'''らは、戦争は避けられないので、それに向けての準備をするという態度に出ました。日本国内では、戦争に向け軍艦を整備したり新たな兵器の開発を行う一方で、ロシアの中央アジアからインドへの南下などを警戒するイギリスと同盟を結び、ロシアとの戦争に備えました。 [[file:Nichirojp.png|thumb|300px|日露戦争の経過]] :1904年（明治37年）日本とロシアは開戦し（'''日露戦争'''）、日本とロシアは、ロシアが植民地としていた遼東半島や満州で戦いました。ロシアは、モスクワなどから遠い極東に兵や兵器・軍馬・食料などを送るには、シベリア鉄道に頼るしかないので、すぐに戦場で攻撃の体制を作ることはできません。一方で、日本も、兵などを送るには日本海を渡らなければならないので、この地域の{{ruby|制海|せいかい}}権<ref>ある地域を自由に航行できるということ。</ref>を握る必要がありました。海軍はロシアの太平洋側の主力艦隊である旅順艦隊をせめ有利な立場になりますが、旅順艦隊は、援軍である世界最大級の艦隊バルチック艦隊<ref>「バルト海」で行動する艦隊なのでバルチック艦隊といいます。</ref>が到着するまで、旅順港に待機することになりました。日本陸軍は遼東半島南端から東進鉄道沿いに北上、朝鮮国境からの軍とあわせ、ロシア軍を満州地域北部までおしもどしました。また、旅順に引き込んだ艦隊がバルチック艦隊と合流すると制海権が危うくなるので、'''{{ruby|乃木希典|のぎまれすけ}}'''<ref>死後、乃木神社にまつられます。乃木坂などの地名にも残っています。</ref>が率いる陸軍の軍団が、要塞となった旅順を攻撃します。この旅順を囲む戦いは、日露戦争の中でも多くの日本兵の犠牲を出しましたが1905年（明治38年）1月に降伏し、バルチック艦隊のみを迎えうつことになりました。そうして、5月に'''[[小学校社会/6学年/歴史編/人物事典#東郷平八郎|{{ruby|東郷平八郎|とうごうへいはちろう}}]]'''がひきいる日本海軍は日本海海戦でバルチック艦隊をやぶり、日本海の制海権を安定したものにしました。 :日本は、戦争を有利に進めたとことで、アメリカ合衆国大統領'''セオドア・ルーズベルト'''に講和の仲介を依頼し、日本からは'''[[#小村寿太郎|小村寿太郎]]'''が、ロシアからは'''ウィッテ'''（前蔵相、のちに初代首相）が、米国のポーツマスに出向き、講和会議が開かれました。1905年9月5日、以下の事項を決めた条約（'''ポーツマス条約'''）が結ばれ、ロシアは中国から撤退し、日露戦争は日本の勝利で終わりました。 :# ロシアは日本の朝鮮半島における優越権を認める。 :# 日露両国の軍隊は、鉄道警備隊を除いて満州から撤退する。 :# ロシアは樺太の北緯50度以南の領土を永久に日本へ譲渡する。 :# ロシアは東清鉄道の内、旅順－長春間の南満洲支線と、付属地の炭鉱の{{ruby|租借|そしゃく}}<ref>土地などを、借り受けるという意味ですが、実質的な支配が行われ、「租借地」というのは、「植民地」とほぼ同義語になります。</ref>権を日本へ譲渡する。 :#*この路線は、「南満州鉄道」と改称され、日本の満洲進出の基礎となります。 :# ロシアは関東州（旅順・大連を含む遼東半島南端部）の租借権を日本へ譲渡する。 :# ロシアは沿海州沿岸の漁業権を日本人に与える。 :ポーツマス条約では下関条約と異なり賠償金の支払いはありませんでした。一部の日本国民はこれを不満に思って、暴動をおこすものもありました。しかし、国民には知らされていませんでしたが、戦争を有利に進めていたとはいえ、これ以上は財政上ほとんど無理な状態になっていて、すぐにでも戦争をやめなければならない状態になっていました。ロシアはそれを見越して、敗戦国でありながら、比較的有利な条件で講和条約を結んだといえます。 :しかし、この結果、満州や朝鮮半島に対するロシアの脅威は去りましたので、日本は、この地域への進出を高めます。特に、満州は石炭や鉄鉱石の地下資源が豊かな地域であったため鉱山開発を盛んに行いました。 :韓国については、政治的な不安定を理由に日本の属国化が進められ、1905年12月には統監府が設置され、伊藤博文が初代統監に就任しました。 :1909年 (明治42年)、伊藤博文はロシアとの外交交渉のため満州のハルビンに出向きましたが、そこで、朝鮮民族主義者に暗殺されます。それまで、韓国に対しては朝鮮民族に対し強硬的に望む人たちと、穏健に進めるべきという人たち（伊藤博文もその意見でした）が対立していたのですが、伊藤博文が暗殺されたことで、強硬派の勢いを増し、1910年（明治43年）8月に、日本は大韓帝国を併合しました('''{{ruby|韓国併合|かんこくへいごう}}''')。 :<span id="辛亥革命"/>日露戦争は、日本とロシアの戦争でしたが、その戦いは清国の領土でなされました。清国は、もはやそれを止める力を失っていました。中国の人々は、外国に国土を侵される不安が高まり、中国の人々が政治参加をする国をつくるため、1911年{{ruby|孫文|そんぶん}}が主導者となって革命を起こしました('''{{ruby|辛亥革命|しんがいかくめい}}''')。翌1912年清王朝は滅ぼされ、アジアにおいて史上初の独立した共和制国家である{{ruby|中華民国|ちゅうかみんこく}}が誕生しました。 <div style="margin:0 2em 0 4em"> {| class="wikitable" style="width:100%" |'''【脱線 - 覚えなくてもいい話】<span id="南下政策"/>ロシアの南下政策<small> :ロシアは、ヨーロッパの国の中では最も東にあって、17世紀にシベリアを征服し太平洋に達する領土を持つ大きな国ではあったのですが、ヨーロッパ中心部から離れていたので産業革命などはおくれてつたわりました。また、国土の多くが北にあったため、冬にほとんどの港が凍結するなどして、通商などにも支障が出るため、南へ勢力を伸ばす政策をとっていました。これを、「『{{ruby|不凍港|ふとうこう}}』を求めての南下」と言ったりします。19世紀、{{ruby|黒海|こっかい}}を勢力におさめようと、1853年トルコ（オスマン帝国）の領土であったバルカン半島などで戦争（クリミヤ戦争<ref>ロシアは、バルカン半島を南下しようとしたのですが、イギリス・フランスの参戦により押し戻され、クリミア半島が主要な戦場となりました。クリミヤ半島は、現在（2022年4月）、ロシアの侵攻で話題になっているウクライナの黒海地域です。</ref>）を起こしましたが、トルコをイギリスやフランスが支援し、この戦争ではロシアは敗北します<ref>クリミア戦争で、戦傷者の救護を組織的に行い、看護師による近代看護を確立したのが、フローレンス・'''ナイチンゲール'''です。</ref>。その後のバルカン半島の各民族の独立運動に合わせ、1877年オスマン帝国と戦争（露土戦争）をし、これに勝利しバルカン半島を経由したロシアの南下路が開けます。しかし、軍事的な勝利を収めたロシアの勢力拡大に対して欧州各国が警戒感が広がったため、ドイツ帝国の首相ビスマルクが主導し、1878年ベルリン会議を開き、ロシアの南下政策を止め、ロシアはバルカン半島方面の南下を一旦断念します。 :そこで、ロシアは、ヨーロッパ方面から世界へ出ることをあきらめ、東側のシベリアを経由して中央アジアや太平洋への進出をもくろみます。その結果のひとつが、三国干渉及びそれに続く遼東半島への進出です。 :しかし、日露戦争に敗れたため、ロシアは、ふたたび西へ目を向けます。そこで、バルカン半島から東に勢力を伸ばそうとしていたドイツとぶつかります。これが、第一次世界大戦の原因の一つとなります。 </small> |}</div> <div style="margin:0 2em 0 4em"> {| class="wikitable" style="width:100%" |'''【脱線 - 覚えなくてもいい話&考えてみましょう】日本は、どうしてロシアに勝てたのでしょう<small> :ここでは、なぜ、ロシアはやぶれ、日本は勝つことができたのかを考えてみましょう。 :双方の国の規模ですが、日本とロシアでは、人口で3倍、国家予算で10倍、常備軍で5倍という、大きな差がありました。また、清国と違い、ロシアの軍隊はロシア皇帝の下に組織された近代的な軍隊でした。実際、戦没者はロシアが81千人程度のところ、日本は88千人と日本の方が被害が大きかったりしています<ref>当時は、戦場の衛生環境などが悪く、病気になって亡くなる兵士も少なくありませんでした。日露とも、戦没者の1/4が病没者で。特に日本の病没の原因としては、ビタミンB欠乏症の「{{ruby|脚気|かっけ}}」が目立っていて、これは、日本陸軍の医療関係者が、当時新興の栄養学を軽視したためとも言われています。この医療関係者には、小説家の森鴎外もいました。</ref>。 :このように、日本に大きな被害が出た戦争であっても、ロシアが強気に出られなかったのは、サンクトペテルブルクやモスクワなどがある本拠地であるヨーロッパから、鉄道で10日以上かかる遠隔の地で兵隊を送ろうとしても、1日に数千人程度が限界だったからでしょう<ref>戦争において装備に大きな差がなければ、数の違いは大きく影響します。</ref>。ロシアにとっては、バルチック艦隊が日本海の制海権をにぎって、日本が大陸に兵隊や物資を送れなくすることで逆転をもくろんだのですが、日本海海戦でその希望もなくなり、ロシアは戦争の継続をあきらめたのだと思われます。 :バルチック艦隊は強力な艦隊でしたが、日英同盟により、インドなどイギリス植民地への寄港<ref>当時の軍艦の動力は蒸気機関であっったため、石炭と真水を大量に積み込む必要がありました。</ref>が拒否されたため、大西洋から、アフリカの南を回ってインド洋経由で7ヶ月もの航海ののちの到着でした。また、ロシアは身分制が残っており、士官は貴族階級など上流階級の出身者が多く、それに対して、水兵などは農民出身の者や都市の労働者などが多く、航海での待遇の差もあり、航海中から対立も生じていました。 :この上流階級と庶民階級の対立は、海軍だけでなく、陸軍でも見られました。なにより、ロシア国内の一般的な生活でも見られたのです。いくら国の規模が大きいとはいえ、戦争は国民生活に商品不足・インフレーションの影響を与えます。もともと、民衆からの不満がみられ、革命運動もあったところ、日露戦争によるインフレーションと数々の戦いで敗戦したとの知らせで民衆の間に暴動が頻発し、1905年には革命と言っていい状態になっていました。このような国内の不安定さから、ロシア政府は講和を急ぐようになり、日本の勝利につながったといえます。 </small> |}</div> === 条約改正と国際社会での地位の向上 === [[File:Chikamatsu Kiken buto no ryakuke.jpg|thumb|300px|鹿鳴館における舞踏会を描いた浮世絵]] ;不平等条約改正の歩み :幕末に欧米各国と結ばれた通商条約（不平等条約）の改正は日本政府の悲願でした。 :明治政府は、文明開化が進んで欧米並みの文明国になったことを示すため、さまざまなアピールをします。たとえば、1883年(明治16年)に外務卿{{ruby|井上馨|いのうえかおる}}は、'''{{ruby|鹿鳴館|ろくめいかん}}'''という、外国からの重要な来訪者や外交官を接待するための社交場を建設し、舞踏会を開いたりしていました。鹿鳴館での舞踏会などには、政府高官の夫人や娘なども参加しましたが、当時はドレスなどの洋装、欧米風の応対のマナーやエチケット、また、ダンスなどは全く一般的ではなく、必死の訓練などがあったと言われています。しかし、このような取り組みは、欧米人には「{{ruby|滑稽|こっけい}}」と感じられたと言う記録も残っており、あまりうまくいきませんでした。 :一方で、政府は、まず[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#治外法権|治外法権]]（領事裁判権）の撤廃のため、国内の法整備を進め、公正な裁判が行われることを諸外国に示そうとしました。領事裁判権の裁判は犯罪に関するものなので、法律に関するフランス人の[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#お雇い外国人|お雇い外国人]]ボアソナードが指導してフランスの法律をもとにして、1880年（明治13年）に犯罪とその刑罰に関する刑法<span id="刑法"/>と刑事手続と裁判を定めた治罪法<ref>後に、刑事訴訟法に改正されます。</ref>が制定され、1882年（明治15年）施行されました。1889年（明治22年）には、[[#明治憲法|明治憲法]]が発布され法制度が欧米並みに整理されたことが、国際的に示されました。外務大臣'''[[#陸奥宗光|陸奥宗光]]'''は、各国と粘り強く交渉し、まず、1897年（明治30年）イギリスとの間で治外法権を撤廃する条約を結び、日清戦争終結後の1899年（明治32年）すべての国との間で治外法権を撤廃しました。 :そして、日露戦争の勝利は、世界に驚きをもってむかえられ、国際的地位も上がったことをうけて、外務大臣'''[[#小村寿太郎|小村寿太郎]]'''が主導し、1911年（明治44年）関税自主権も回復しました。 <div style="margin:0 2em 0 4em"> {| class="wikitable" style="width:100%" |'''【脱線 - 覚えなくてもいい話】大津事件<small> :1891年（明治24年）、日本を訪問中のロシア帝国皇太子ニコライ（後の皇帝ニコライ2世）が、滋賀県大津市で警備中の警察官に突然サーベルで切りつけられケガを負うと言う事件がありました。 :驚いた日本政府は、すぐに明治天皇自身が見舞いに駆けつけるよう手配し、日本を離れる際も自身で見送りました。大国ロシアの皇太子に対して小国日本の国民しかも警察官が暗殺{{ruby|未遂|みすい}}<ref>殺そうとした相手が死ななかったことを言います。</ref>をおかしたということで、ロシアが攻めてくるかもしれない、そして、当時の日本ではロシアに勝てるはずがないということで、日本国内は、大騒ぎになりました。 :明治政府は、犯人を死刑に処してロシア政府に対して謝罪の意も示そうとしました。 :ところが、当時の[[#刑法|刑法]]では、殺人未遂の最高刑は無期{{ruby|徒刑|とけい}}<ref>現在の言い方では「無期{{ruby|懲役|ちょうえき}}」、一生、刑務所に入れられる刑です。</ref>で、死刑とすることはできません。そこで、政府は、天皇や皇室に暴行などを加え死傷させた場合に適用される{{ruby|大逆|たいぎゃく}}罪を適用するよう裁判所に要請しました。しかし、これは「法律に定められていること以外を罪としてはならない」という近代法の原則「{{ruby|罪刑|ざいけい}}{{ruby|法定|ほうてい}}主義」に反します。大審院院長<ref>現在の最高裁判所長官に相当します。</ref>{{ruby|児島惟謙|こじまいけん}}は、事件の裁判所に、法律に従って判決を下すよう指示し、その結果、死刑ではなく無期徒刑の判決となりました。 :このことは、ロシアとの外交関係を難しくさせるおそれがありましたが、欧米諸国に対しては、「日本は、法律を厳格に守る国である」ということが印象付けられ、条約改正に向けても信用を得ることができました。 </small> |}</div> ;<span id="国際社会"/>国際社会での地位の向上 : 1912年（明治45年・大正元年）大正天皇が即位し、元号が「'''大正'''」となりました。 : 1914年（大正3年）にヨーロッパの国々を二分した'''[[#全世界を巻き込む戦争 - 第一次世界大戦|第一次世界大戦]]'''が始まりました。日本は、イギリスやフランスの属する[[#協商国|協商国]]に参加し、敵対する[[#同盟国|同盟国]]の一つであるドイツが租借する中国の{{ruby|青島|チンタオ}}<ref name="中国地名"/>や南太平洋の島々を占領しました。1919年戦争は協商国の勝利に終わり、翌年、平和を維持するための'''[[#国際連盟|国際連盟]]'''が設立、日本は英仏などとともに常任理事国の一つとなりました。 : 第一次世界大戦は、今までに見られなかったほどの大規模な戦争で、戦場が全国土に広がり多くの工場設備なども失われ、工業生産が止まってしまったりしました。しかし、主な戦場はヨーロッパで、日本への被害はほとんどなかったため、日本は、ヨーロッパの工業生産に代わって、綿糸や綿布といった繊維製品や化学肥料など、さまざまな工業製品を輸出しました。また、日本へのヨーロッパからの輸入が止まったため、それにかわる重工業などが起こるきっかけにもなり、国際取引においても機械など高度な工業製品を輸出できる国となりました。第一次世界大戦の影響で日本の経済は急速に成長しました。 ;明治後期から大正にかけての人々の生活や文化と学問 :明治維新後、さまざまな[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#殖産興業|殖産興業]]の取り組みによって、経済的余裕ができ、国民生活は向上し、さまざまな近代文化の進展が見られました。また、欧米から伝わった工業的な製紙法と活版印刷は安価で大量の印刷を可能として、新聞や雑誌が広く普及します。これら新聞や出版業の発達したことと、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#学校|学校制度]]が定着し教育水準が上がったことで、国民の政治参加の意識も高まりました。 :さらに、日清戦争・日露戦争といった戦争で、納税額が多いかどうか、つまり財産が多いかどうかにかかわらず、国民として平等に生命を犠牲にするということが意識され、納税額による選挙権の制限（[[#制限選挙|制限選挙]]）をやめて、成人であれば誰にでも選挙権が与えられる「普通選挙」を求めた社会運動（'''普選運動'''）がおこり、1925年（大正14年）すべての男性が選挙権を有する普通選挙法が成立しました。このような、民主化の動きを「'''大正デモクラシー'''」と言います。しかし、まだ女性には選挙権は認められていませんでした。 :<span id="政党政治"/>このように、国民の政治への関心が高まると、選挙で選ばれた国会議員による衆議院の発言力が強まり、[[#内閣総理大臣|内閣総理大臣なども衆議院の意向を受けて選び出されることもありました]]。しかし、一方で議会での議論においては、政党同士の争いもあって、無駄な議論がなされるように見えることもありました。また、政策に関しての、議員の{{ruby|汚職|おしょく}}なども発生するようになりました。 :[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#文明開化|文明開化]]を受けて、日本には西洋風の文化が広く普及し、明治20年（1887年）代以降になると、それを受けた独自の文化が育ってきました。 :新聞や出版業の発達は上で述べたとおり人々の政治への意識を高めたところですが、そこには、政治的な考えなどだけではなく、人々の娯楽としての小説なども掲載されるようになりました。明治も初めのうちは、歌舞伎の演目などを題材としたものが多かったのですが、1885年（明治18年）、{{ruby|坪内逍遥|つぼうちしょうよう}}は、『{{ruby|小説神髄|しょうせつしんずい}}』をあらわし、人々の普段の生活に近い題材をとりあげる、いわゆる近代文学を提唱しました。またその中で、話し言葉と書き言葉の間の大きな違いから、もっと平易で話し言葉に近い言葉を使うよう進められました。これを{{ruby|言文一致|げんぶんいっち}}運動といいます<ref>ただし、今でも話し言葉と書き言葉は同じものではありません。</ref>。このような動きのなかで、多くの近代文学というものが生まれました。その中には、1895年（明治28年）に『たけくらべ』を書いた{{ruby|樋口一葉|ひぐちいちよう}}のような女性もいました。その後、{{ruby|森鴎外|もりおうがい}}や{{ruby|夏目漱石|なつめそうせき}}があらわれ、近代文学が確立します。特に、夏目漱石が1905年（明治38年）に初めて書いた小説『{{ruby|吾輩|わがはい}}は猫である』はユーモアに富んだ内容と落語にヒントを得たとされる平易な語り口調で広く普及し、日本語の書き言葉の元になったとも言われています。 :美術の分野では、写実的な西洋絵画や彫刻が日本でも制作されるようになりました。政府は1887年（明治20年）、「東京美術学校<ref name="芸大">「東京美術学校」と「東京音楽学校」は、のちに合併し「東京{{ruby|藝術|げいじゅつ}}大学」となります。</ref>」を設立し、西洋絵画の製作者や指導者を育てました。 :また、音楽の分野でも西洋音楽の受け入れが進み、1890年（明治23年）、演奏家・作曲家や指導者を育てる「東京音楽学校<ref name="芸大"/>」が開校しました。 :学問の分野では、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#学校|大学教育]]が定着し、日本の科学技術の水準も世界的なものになってきました。物理学では原子のモデルを提唱した{{ruby|長岡半太郎|ながおかはんたろう}}、数学の分野では{{ruby|高木貞治|たかぎていじ}}といった世界的に評価される研究者も登場するようになりました。 :特に、人々の生活に密着した医学の分野では、世界的に進みつつあった細菌学の分野で多くの成果が見られ、破傷風の治療法の研究やペスト菌の発見をおこなった'''[[小学校社会/6学年/歴史編/人物事典#北里柴三郎|{{ruby|北里柴三郎|きたざとしばさぶろう}}]]'''、{{ruby|赤痢|せきり}}菌を発見した{{ruby|志賀潔|しがきよし}}、黄熱病や梅毒の研究で知られ、ノーベル生理学・医学賞の授賞候補ともなった'''[[小学校社会/6学年/歴史編/人物事典#野口英世|{{ruby|野口英世|のぐちひでよ}}]]'''のように国際的な研究者がでてくるようになりました。 <div style="margin:0 2em 0 4em"> {| class="wikitable" style="width:100%" |[[ファイル:Noguchi Hideyo.jpg|thumb|120px|right]] '''【脱線 - 覚えなくてもいい話】<span id="野口英世"/>野口英世<small> :本文に書いたとおり、野口英世は、国際的に活躍した細菌学者で、現在、その肖像が1000円札に使われている人です。子供の頃から大変苦労して勉強して、多くの業績を残した人で、皆さんの中で、野口英世の伝記を読んだことのある人も少なくないでしょう。ここでは、野口英世の生涯について簡単に紹介して、なぜ彼が偉人とされているかをお話ししたいと思います。 :1876年（明治9年）、英世<ref>元の名は「清作」で「英世」は22歳になって改名したものですが、ここでは、「英世」で統一します。</ref>は福島県耶麻郡三ッ和村（現：耶麻郡猪苗代町）に生まれます。貧しいというほどではありませんが、決して余裕のある家の生まれではありませんでした。英世は1歳の時に{{ruby|囲炉裏|いろり}}に落ち、左手に大{{ruby|火傷|やけど}}を負います。ただれた皮膚で指がくっついて開かなくなるというひどいものでした。英世は、学校に上がるようになると、このことでいじめられました。しかし、英世の学校の成績はとても素晴らしいものでした。英世の家計では、上級の学校に出すのは難しく、普通は小学校を出て働きに出るとことだったのですが、これを惜しんだ教師や地域の人がお金を出し合って、上の学校へ進ませました。また、火傷あとが不便であろうと、やはりお金を出し合って、まだ珍しかった西洋医術による手術を受けさせ、左手を使えるようにしました。英世はこの手術の成功に感激したことがきっかけで医師を目指すこととなりました。 :1896年（明治29年）英世は上京し、医学を学びます。1900年（明治33年）米国に渡り、研究を始めます。そして、アメリカを拠点として基礎医学の分野で数々の業績をあげ世界的な名声を得て、何回かノーベル生理学・医学賞の候補者ともなりました。 :1918年（大正7年）以降は{{ruby|黄熱|おうねつ}}病の研究に打ち込み、黄熱病の流行地域である南アメリカ各国やアフリカに渡って研究を続けます。しかし、黄熱病の研究中に自身もその病にかかり、1928年（昭和3年）アフリカのイギリス植民地ゴールド・コースト(現:ガーナ共和国) アクラで亡くなります。 :野口英世が偉人とされるのは、 :*庶民の出身であるにもかかわらず、高い能力で医者・研究者の地位についた<ref>大学以上の高等教育を受けさせることは当時の庶民にはめったにないことでした。また、英世の出身地会津は、戊辰戦争で官軍に抵抗し、政府などに関係者も少なく、薩長などの出身者より不利なところもありました。</ref>。 :*体に受けたハンディキャップにも負けず、努力して勉強した<ref>当時、家が貧しくても、軍隊に入って勉強するという方法もありましたが、英世の場合、このやり方は難しかったと考えられます。</ref>。 :*能力を世に出そうと、周囲の人が協力した。 :*日本ではなく、国外の研究所を拠点として国際的な活躍をした。 :というところにあると思います。野口英世の業績自体は、その後の医学の発展によって否定されたものも少なくはありませんが、目標に向けて努力する姿には見習うものがあると思います。 </small> |}</div> :日本の経済力が大きくなることにともなって、人々の暮らしもだんだん豊かなものになっていきましたが、この時期に、大きな災害に見舞われてもいます。 :まず、<span id="スペインかぜ"/>1918年（大正7年）から1920年（大正9年）にかけて世界中で流行した'''スペインかぜ'''といわれるインフルエンザの大流行です。当時は第一次世界大戦の交戦中であったため、軍人を中心に広く行き来し世界中で流行しました。全世界で30％にあたる5億人が感染し、少なくとも1700万人の死者がでたものと推定されています。日本においてもこの3年間で約40万人程度の死者が出ました<ref>最近のコロナ禍で、2020年から2022年7月現在の死者の累計数が約3万人であることと比較してみてください。</ref>。 :もう一つは、<span id="関東大震災"/>1923年（大正12年）9月1日、南関東一円を襲った'''関東大震災'''です。マグニチュード7.9〜8.3と推定される大地震<ref>1000年に1度と言われる2011年東日本大震災のマグニチュードは9.0で特別ですが、1995年阪神淡路大地震のマグニチュードは7.3くらいです。</ref>で、約1万人が倒れた建物の下敷きになって亡くなり、約9万人が、地震ののちに発生した火災で亡くなりました。 == 世界の変化3 == :'''この節は、小学校で学習する範囲を超えていますが、昭和以後の日本の歴史に大きく関わる第二次世界大戦がなぜ起きたのか、その後、「世界」はどうなったのかということを理解できていないと、昭和以降の日本の歴史を深く理解することはできません。''' :'''この節では、「ナショナリズム」「社会主義・共産主義」「資本主義」とはなにかということについては理解しておいてください。ここでは細かいところを覚えるのではなく、大きな流れを頭のかたすみに置けるようにし、次の章を読み進めてください。''' === ナショナリズムと社会主義・共産主義 === ==== 20世紀初めの世界 ==== :[[File:World 1898 empires colonies territory.png|thumb|650px|1898年の世界<br>国旗は上から、イギリス、フランス、スペイン、ポルトガル、オランダ、ドイツ、トルコ、ベルギー、ロシア、日本、清、オーストリア、デンマーク、スウェーデン、アメリカ、イタリアの順です。]] :18世紀から19世紀にかけて、ヨーロッパや北アメリカを中心に[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#世界の変化1_-_産業革命|'''産業革命'''が起こって経済を工業が大きく動かす社会になりました]]。また、[[#世界の変化2_-_市民革命|欧米の'''市民革命'''をきっかけに経済力を持った市民が国の政治に参加するようになり、国民全員が国の活動に参加する'''国民国家'''が誕生しました]]。日本も、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#明治維新と武士の社会の終わり|明治維新で一つの国民国家になり、富国強兵・殖産興業をスローガンとして、国内経済の近代工業化を進めました]]。 :一方、国民国家をつくりあげ、産業革命で大きな経済力を得た欧米の各国（ここでは、『{{ruby|先進国|せんしんこく}}』と呼んでおきましょう。）は、[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#帝国主義|各国の工業製品の材料と{{ruby|市場|しじょう}}を求め、アフリカやアジアの、まだ、国民国家としてまとまっていない国や地域に進出し、ほとんどの地域を植民地にしていました]]。 ==== ナショナリズム（民族運動） ==== :近代的な工業は、先進国を中心に進みましたが、やがて、製品を各地に売るため、また、原材料を輸送するため鉄道が各地に伸びて、近代社会は世界各地に広がり人々の生活を変えていきました。植民地となった地域でも近代的な教育が行われ、自由や平等といった人権の考え方が普及します。また、新聞などの出版物により人々のさまざまな考えが、広く伝わるようになります。 :植民地となっている地域で、このような知識の高まりが広がると、人々の中に、「どうして、私たちは、言葉や生活習慣の違う人たちに支配されなければならないのか」「私たちの作ったものは、安く買われて、先進国のものを高く買わないといけないのか」という考えが起こってきて、「独立して、自分たちの国を作ろう」という主張が芽生えます。この考えやこの考えに基づく運動を「'''ナショナリズム'''(民族主義・民族運動<ref>「ナショナリズム(Nationalism)」は、「ナショナル(National; ネイション(Nation;　国民・民族)の)」+「イズム(ism;　主義)」という意味です。国民主義とも訳されます。</ref>)」といいます。 :ナショナリズムは、最初、西ヨーロッパに隣接するオーストリア=ハンガリー帝国（「オーストリア帝国」と略します）やオスマン帝国の領土<ref>オーストリア帝国は、もともとヨーロッパの中でも最も強力な国の一つで、プロシアを中心としたドイツ帝国の成立まではドイツ民族の中心でした。この時代においても、中部ヨーロッパに広い領土を持つ国です。また、オスマン帝国は、15世紀に起こったトルコ民族が中心の国で、中東から北アフリカにかけてのイスラム世界を広くおさめ、ヨーロッパもバルカン半島まで領土としていた大国です。両国とも、19世紀にあっても広い領域を支配していましたが、近代化が遅れていました。</ref>であった中部ヨーロッパや東ヨーロッパ（'''バルカン半島'''と呼ばれる地域を含みます）で盛んとなり、これが、第一次世界大戦の大きな原因となります。 :第一次世界大戦終結後は、アジア・アフリカの各地に広がり、世界各地で独立運動が展開されます。 <div style="margin:0 2em 0 4em"> {| class="wikitable" style="width:100%" |'''【脱線 - 覚えなくてもいい話】<span id="バルカン半島"/>バルカン半島<small> [[File:Karte Suedosteuropa 03 01.png|thumb|200px|太線でかこまれた地域がバルカン半島です。色の濃い地域が民族や宗教が入り混じっている地域になります。]] :バルカン半島は、ヨーロッパ中部、ドナウ川より南のアドリア海と黒海にはさまれた地域で、南は狭い海峡を隔ててアナトリア半島に面しています。歴史的には、古代ギリシア文明が栄えた地域であり、それに引き続いて古代ローマの文化が栄え、アナトリア半島との海峡のそばには、中世まで栄えた東ローマ帝国の首都コンスタンティノープル（ビザンティウム）が建設され、後にオスマン帝国の首都イスタンブールとなります。 :バルカン半島は、このように西にドイツやイタリアなどの西ヨーロッパ社会、東にロシアなどのスラブ社会、南にトルコなどのイスラム社会にかこまれ、東西ヨーロッパと西アジアを結ぶ交通の重要な地域であったため、それらの大きな勢力が波のように寄せたり引いたりする地域でした。また、この地域は山がちで、盆地が多く、各盆地ごとに生活する社会ができあがり、大変複雑な状態になっていました。スラブ系民族が多かったのですが、それに、ラテン系民族や、ギリシア系民族が混ざり、一部にはアジア系の民族もいました。また宗教もカトリックとギリシア正教にイスラム教の三大勢力が入り組んでいました。 :19世紀以降、人々がナショナリズムをとなえはじめ、各地で独立運動が起こります。この独立運動も運動の中での対立もあって、まとまることがなく、過激な行動も見られるようになりました。こうして、バルカン半島は『ヨーロッパの火薬庫』と呼ばれるようになりました。 </small> |}</div> ==== 社会主義と共産主義 ==== :[[File:Marx7.jpg|thumb|150px|カール・マルクス]] :<span id="労働運動"/>先進国国内にあっては、工業が発展するにつれて多くの{{ruby|労働者|ろうどうしゃ}}が生まれました。工場では工場労働者、石炭の炭鉱や鉄鉱石の鉱山では鉱山労働者、港で貨物の積み下ろしをする港湾労働者などです。産業革命前は、たとえば職人などは技術を長年にわたって習得する必要がある反面、技術を習得した職人は、代わりになる人を探すのが難しいという特徴がありましたが、産業革命以降の労働者の多くは単純な作業が多く、それができる人は数多いので経営者の都合で雇うこともクビにすることも簡単にできるようになりました。そのため、経営者など（労働者に対して{{ruby|資本家|しほんか}}という言い方をします）に比べて、多くの労働者は非常に貧しい生活となることが一般的でした。労働者は、自分たちの待遇（安定して雇われること、十分な賃金をもらえることや安全な労働環境など）を改善するために'''{{ruby|労働組合|ろうどうくみあい}}'''を結成し、集団で経営者と交渉したり、場合によっては'''ストライキ'''を起こすなどして資本家に対抗したりしました（'''{{ruby|労働運動|ろうどううんどう}}'''）。そのように、社会が変わっていくのを受けて、自由な経済活動を制限してでも、人々の平等な生活が送れる社会をめざすべきであるという'''{{ruby|社会主義|しゃかいしゅぎ}}'''の考えが生まれます。[[#世界の変化2 - 市民革命|市民革命]]は、国王や世襲の貴族といった身分社会から「自由」に活動できる権利を求める社会の変化でしたが、この自由には、工場を作ったり、物を取引する経済的な自由を含みます。自由な経済活動の結果、貧富の差が生じることについて、これをしかたがないことと認める考え方を、社会主義者は批判して、'''{{ruby|資本主義|しほんしゅぎ}}'''と名づけました。さらに、社会主義の中から、19世紀の半ばドイツ生まれの経済学者'''カール・マルクス'''は『{{ruby|資本論|しほんろん}}』を書いて、一層過激な'''{{ruby|共産主義|きょうさんしゅぎ}}'''をとなえました。 :<span id="共産主義"/>共産主義とは、簡単にいうと、農地や工場といった経済的な価値を生み出すものは、人々の共有にしてしまって、全ての人たちが働くことからのみ収入を得る<ref>この考えは、「働かざる者食うべからず」というスローガンに現れています。これは、働かないで怠けているものは食べるべきでない（＝生きるべきでない）ととらえられがちですが、第一には、たとえば、地主が土地を小作人に貸したり、財産の利子や配当収入だけで生活できるような資本家を攻撃した言葉です。</ref>平等な社会を目指すという考え方です。それを実現するためには、資本家が持っている財産をうばって、分けあたえるということが必要になります。これは、革命であって、共産主義は、目指す社会を実現させるためには、革命が必要だと主張しました。この考え方は、世界中の多くの労働者の支持を得た一方で、ほとんどの資本家や、資本家が強く関わっている当時の各国の政府を強く警戒させました。また、社会主義や共産主義は、全ての人民が平等という考えが根本にありますから、君主制や民族主義とはあいいれないもので、<span id="反社会主義"/>王国や天皇制に親しみのある人たちや同じ民族だけで助け合おうとする人たちと敵対しましたし、また、平等な社会を作るためには、各個人の自由は多少制限されても仕方がないという考えであるため、人としての自由な行動を大事に思う人たちとも対立しました。 <div style="margin:0 2em 0 4em"> {| class="wikitable" style="width:100%" |'''【脱線 - 覚えなくてもいい話】<span id="イノベーション"/>新たな科学・技術の発展<small> :[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#世界の変化1_-_産業革命|人々のくらしが「産業革命」で大きく変わったことは、前にお話ししたとおりですが]]、1860年頃から1910年くらいまでの間に、「産業革命」と同じくらい、またはそれ以上の科学技術上の大きな発展が見られ、さらに人々の生活を大きく変えます<ref>歴史学者の一部では、これを「'''第二次産業革命'''」と呼びます</ref>。 #'''新たな動力の発明''' - 「産業革命」において、中心となった動力は、主に石炭を使用した蒸気機関でしたが、19世紀半ば以降、これに、新たな動力源が加わります。 #;{{ruby|内燃機関|ないねんきかん}} #:内燃機関とは、ガスまたは霧状にした燃料を爆発させ、それによって急激にふくらむ力を動力にする装置です。皆さんがよく知っているところでは、自動車のガソリンエンジンやディーゼルエンジンが代表的なものです。 #:蒸気機関の発明は主にイギリスでなされましたが、内燃機関はドイツで発展しました。1880年代、ゴットリープ・ダイムラーとカール・ベンツは各々で実用的なガソリンエンジンを発明し、それに少し遅れて、ルドルフ・ディーゼルがディーゼルエンジンを発明します。内燃機関は、蒸気機関に比べて小型化が容易なので、これを動力とした自動車が誕生しました<ref>ゴットリープ・ダイムラーとカール・ベンツは、各々で自動車の会社を作ります。1926年それらの会社が合併しダイムラー・ベンツができます。現在のメルセデス・ベンツ・グループ（「メルセデス」はダイムラー社製の車の愛称です）です。</ref>。蒸気機関は石炭に加え水が必要でしたが、内燃機関は燃料だけで足りるため、船舶などの動力は早期に内燃機関に切り替わりました。 #:<span id="飛行機"/>また、小型で高出力という特徴を活かして、1903年アメリカで'''ライト兄弟'''がガソリンエンジンを動力とした'''飛行機'''を飛ばすことに成功しました。 #:このように、内燃機関は小型にでき利用できる範囲も広いということで蒸気機関に取って代わっていきました。そのため、石油が資源としての重要性を大きく増すことになりました。 #;{{ruby|電動機|でんどうき}}（モーター）・発電機 #:[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代#電気|電気が長い間研究されていたことは、前章に書いたとおりです]]。 #:電気を研究しているうちに、電気を通すことで磁石の力（磁力）が生じることが発見されました。すなわち、「電流」を通すと、「磁力」が発生し、鉄などが電磁石にくっつく（＝「運動」する）ということです。1831年ファラデーは、これをまとめた、電気と磁気と運動の関係を発見します。この発見をもとに工夫して、電流を流して連続した回転運動を得る電動機（モーター）が発明されました。 #:逆に磁力のあるところで電線を運動させると、電線に電流が生じます。これを、応用して発電機が発明されました<ref>モーターに力を加えて回すことで電流を得ることができます。</ref>。電力は、それまで、化学反応を使った電池によって得ていましたが、大量に得ることは困難でした。発電機の発明によって、大量の電力を連続で安定的に得ることができるようになり、次に述べる「電気の実用化」が可能になります。 #'''電気の実用化''' #:こうして、大量の電気が供給されるようになると、産業や生活に大きな変化がもたらされます。 #:産業の面では、電気を使うことでメッキや化学産業などが起こりました。また、精錬するのに電気を必要とするアルミニウムが実用化になりました。 #:生活の面では、1880年頃に'''トーマス・エジソン'''が電球を発明するなど、身近な家庭電化製品が発明されていきました。また、同じ時期に'''アレクサンダー・グラハム・ベル'''が実用的な電話を発明しています。 #:1900年頃、音声を電波<ref>何もない空間を電気の変化を伝える性質である電波は、1887年に発見されました。</ref>を使って無線で飛ばす技術が開発され、それを応用して、1920年、'''ラジオ放送'''が開始しました。 #'''化学工業''' #:植物が育つには{{ruby|窒素|ちっそ}}が必要ですが、空気中の窒素は、豆類の根につく細菌類が化学合成し物質として固定するのを待つしかありませんでした。1909年にドイツで完成されたハーバー・ボッシュ法によって、空気中の窒素から直接、化学肥料の材料となるアンモニアを合成できるようになりました。効果的な化学肥料を製造できるようになり、農作物の収穫が格段と大きくなりました。これは、「水と石炭と空気からパンを作る方法」と言われました。 #:また、従来は火薬（黒色火薬）の原料として{{ruby|硝石|しょうせき}}が使われていて、地下資源として採掘するなど、容易に入手できるものではありませんでしたが、アンモニアが大量に手に入るようになったことと、黒色火薬より強力な窒素系の火薬が開発されたことで<ref>代表的なものは、ニトログリセリンです。これを安全に取り扱えるようダイナマイトを発明したアルフレッド・ノーベルは、莫大な遺産でノーベル賞を創設しました。</ref>、火薬製造は原料の輸入に頼らず、強力な火薬が大量に製造できるようになりました。 </small> |}</div> === 全世界を巻き込む戦争 - 第一次世界大戦 === ==== 先進国の間の対立 ==== :[[File:3goku kyosho & 3goku domei.png|thumb|250px|三国同盟と三国協商]] :先進国のうちでも、イギリスやフランスは、いち早く近代的な国家の仕組みを整え、産業革命も世界に先がけて成しとげていました。そのため、国内では余る生産力を海外に向けるためアフリカやアジアの多くの地域を植民地として、綿花など原材料の生産地として、そして製品の市場としていました。19世紀半ば頃から他のヨーロッパの他の国も近代工業化がすすんできました。特に、1871年に北部のドイツを統一してできたドイツ帝国では、[[#イノベーション|科学技術のめざましい発展]]が見られ、国の経済力は、すでにフランスを圧倒し、イギリスと肩を並べるものになっていました。しかし、イギリスやフランスは国外にも多くの植民地をはじめとした国際的な市場を持っていたのですが、近代化の遅れたドイツは植民地をあまり持っておらず、国外への展開に困難がありました。 :ドイツ帝国は、同じドイツ系のオーストリア帝国、隣国のイタリア王国と同盟し（'''三国同盟'''<ref name="イタリア">'''イタリア王国'''もドイツと同じように市民革命ののちに封建諸国でばらばらであったイタリア民族を統一した王国で、イギリス、フランスを追いかけていた国の一つです。このような共通点から、ドイツと同盟を結びますが、オーストリアとの間に領土問題が存在したため、最初は参戦せず、後に、協商国側で参戦します。</ref>）、オスマン帝国とはかって、バルカン半島からトルコを経由して中東までの鉄道を敷設し、この地域の経済を有利に進めようともくろみました。ドイツから中東までを独占し、さらに、そこからアジア・アフリカに進もうとする考えです。 :この考えに、アジアやアフリカを大きな市場としていたイギリスやフランスは警戒します。 :また、東にあるロシアは、バルカン半島での[[#南下政策|南下政策]]がクリミア戦争で{{ruby|挫折|ざせつ}}した後、極東に目を向けていたのですが、[[#日露戦争|日露戦争]]に敗れたため、再び、クリミヤ半島からの南下に政策を変えます。今度は直接攻め入るのではなくバルカン半島のスラブ国家や独立運動家を支援しオーストリア帝国やオスマン帝国に対抗させる形での介入です。イギリスとフランスは、ドイツを{{ruby|牽制|けんせい}}<ref>相手に自分の行動を見せつけ、勝手な行動をとれなくすること。</ref>するため、ロシアとの間に{{ruby|協商|きょうしょう}}条約<ref>「協商」は「相談をする」と言う意味で、「協商条約」は外交にあたって相談をするということを約束した条約です。「商業」と直接の関係はありません。</ref>を結びます('''三国協商'''<ref>英仏・仏露・英露、各々の協商条約などを合わせたものです。イギリスとロシアは日露戦争までは敵対していましたが、ロシアが敗戦したことをきっかけに、同盟関係を結びます。</ref>)。 :こうして、バルカン半島を中心に、ドイツ・オーストリア・オスマン帝国とその東西の国との緊張が高まってきました。 ==== 初めての『世界大戦』 ==== :バルカン半島中西部のボスニア・ヘルツェゴビナは、長い間、オスマン帝国の領土で、住民もイスラム教に改宗した人々（ボスニア人）が多い地域でしたが、19世紀後半以降オーストリア帝国が支配する領域となっていました。 :1914年6月28日、オーストリア皇太子がボスニア・ヘルツェゴビナのサラエボを訪問した際、隣国セルビア王国のボスニア系の独立運動家に暗殺されました（'''サラエボ事件'''）。これが、きっかけとなって、7月28日オーストリア帝国はセルビア王国に宣戦布告し、セルビアを支援するロシアも参戦、これを受けてオーストリアと同盟を組むドイツが参戦、そして、ドイツと敵対するフランスとイギリスが参戦し全ヨーロッパにおける戦争『'''第一次世界大戦'''<ref>これから、25年後、次の世界中を巻き込んだ大きな戦争が起こり、それを『'''第二次'''世界大戦』と呼ぶため、この戦争を『'''第一次'''世界大戦』とよびます。この当時は、『世界戦争』・『大戦争』と呼んでいました。</ref>』が始まりました。なお、以下、ドイツ・オーストリア側を「<span id="同盟国"/>'''同盟国'''<ref name="イタリア"/>」、イギリス・フランス・ロシア側を「<span id="協商国"/>'''協商国'''」と言うこととします。 :第一次世界大戦はそれまでの戦争とことなって『'''国家総力戦'''（または、'''総力戦'''）』と言われます。それまでの戦争は、あくまでも軍隊と軍隊の戦いで、軍事拠点をめぐっての争いや、双方の主力部隊がある戦場で戦う（会戦）もので成り立っていて、そのような場所以外が戦火の被害を受けることは少なく、また、軍人以外で戦争で死傷する人は限られていました。しかし、第一次世界大戦になると、戦争は軍人以外の国民も巻き込んだものとなります。兵士は国民の中から徴兵されたものですし、銃砲や砲弾・銃弾、それに用いる火薬といった兵器の製造力も国内の工業力に支えられます。兵器だけではなく、軍服や戦場に持ち込む食糧もそうです。また、兵器やその他の物資を輸入に頼るにしても、その資金は国内の工場の生産物を輸出することで得られるものです。そのため、敵対する国は、相手の軍隊を攻撃するだけではなく、相手の国の生産力を下げるため、戦闘の機会に工場や輸送に用いる鉄道・港湾・船舶を破壊するようになります。さらに、相手が戦争を継続する力を落とすために、軍隊どうしの戦場ではないところの住宅等も破壊するようになりました。総力戦になって、軍人以外の民間人の死傷者や家屋などの財産の破壊が、それ以前と比べられないほどに増大しました。 :戦争は、ヨーロッパだけでなく世界中を巻き込みました。1914年11月ロシアと対抗し、イギリスに脅威を感じていたオスマン帝国は同盟国として参戦しました。こうして戦争は北アフリカなどにも広がりました。 :日本は、日英同盟から、イギリスに要請され協商国側に参戦し、ドイツの租借地である中国の{{ruby|青島|チンタオ}}や南太平洋の島々を占領しました。 :[[File:Cheshire Regiment trench Somme 1916.jpg|thumb|250px|第一次世界大戦の塹壕(ざんごう)]] :第一次世界大戦では、{{ruby|塹壕|ざんごう}}という攻めてくる敵に対して地面に人が隠れられる溝を掘って<ref>フランスとドイツの間には、大西洋からスイスまでの全長700kmにわたる塹壕が両陣営でできました。</ref>、守りを固める戦法をとったため、お互い戦闘が進まず、戦争は長期化し、同盟国・協商国ともども国内経済は衰退し、国民生活はだんだん貧しいものとなっていました。一方で、当時の最先端の科学技術は次々と投入されます。化学工業の発展は火薬の力を強くしていましたし、毒ガスの開発にも応用されました。また、内燃機関を使ったトラックなどが、馬車などに代わって兵士を移動する手段となり、また、道の状態にかかわらず進むことができる、戦車なども開発されました。そして、[[#飛行機|発明されたばかりの航空機]]も戦場に投入されました。こうした、最新の科学技術の投入は、戦場をますます{{ruby|悲惨|ひさん}}なものにしていきました。 :1917年になって、状況が大きく変わります。 :アメリカ合衆国（以下、しばしば、「米国」と略します)は、もともと、「<span id="モンロー主義"/>南北アメリカ大陸のことに、ヨーロッパの国に口を出させない。その代わり、米国もヨーロッパの政治に口を出さない」という外交の方針があって、また、移民の国であるため、ドイツ系の国民も多く、中立の立場にいました。しかし、ドイツがイギリス周辺を航行する船を、軍事に関する物品を輸送する船であると潜水艦で攻撃し沈めるという作戦をとったところ、米国人を多数乗せた船を沈めると言う事件などがあって、この年に、協商国側として参戦します。米国の参戦は軍隊が増えたことに加えて、米国の工場など生産設備が無傷であったため、イギリスやフランスといった協商国には物資がどんどん補給され、協商国側に有利となりました。 :一方で、東側のロシアとの戦争も一進一退の状態でしたが、バルト海と黒海を同盟国側が封鎖したため、ロシアは輸出入がとだえ、国内の物資不足とインフレが社会問題となっており、各地でストライキや暴動が起こり、1917年2月に皇帝ニコライ2世は退位します（'''ロシア革命'''）。このような中、[[#共産主義|共産主義]]の運動家である'''ウラジーミル・レーニン'''らが政府を握り、同年12月にはドイツとの戦争を停止します。 :こうして、ドイツは、東側での戦争は終結したのですが、イギリス・フランスと戦う西側では、1918年になると米国の支援により優勢になり、また、[[#スペインかぜ|スペインかぜ（インフルエンザ）が大流行]]するなどして、戦闘の継続は困難なものとなり、11月ドイツ皇帝ヴィルヘルム2世はオランダへ{{ruby|亡命|ぼうめい}}<ref>国外に逃げ出すことを言います。</ref>、オーストリア皇帝カール1世も退位し、第一次世界大戦は事実上終了しました(正式な終了は講和条約が締結された翌年1919年となります)。 :同盟国であったドイツ帝国、オーストリア帝国、オスマン帝国は崩壊し、それぞれ共和国となりました<ref>オスマン帝国は、1918年に降伏し、1922年にトルコ革命により共和制となります。</ref>。 :第一次世界大戦は、協商国側の戦死者 553万人、戦傷者 1283万人、行方不明者 412万人、同盟国側の 戦死者 439万人、戦傷者 839万人、行方不明 363万人。民間人の死亡者、協商国側 360万人、同盟国側　314万人と人類が経験したことがない規模の犠牲者を出すことになりました。 ==== 第一次世界大戦後の世界 ==== :1919年フランスのパリで第一次世界大戦の講和会議が開かれました。その結果、 :#敗戦国は戦勝国に賠償金を支払う。 :#領土の一部を戦勝国に割譲する。 :#オーストリア帝国、オスマン帝国が支配していた中央ヨーロッパ・バルカン半島、中東から北アフリカにかけての地域について、独立またはイギリスやフランスの保護領とする。 :#敗戦国の軍備は数年間制限する。 :などが決められました。 :また、このような戦争が2度と起こらないようにと米国大統領ウッドロウ・ウィルソンが提唱し、常設の国際的な協議機関「<span id="国際連盟"/>'''{{ruby|国際連盟|こくさいれんめい}}'''」が誕生します。国際連盟の運用は理事会が行いますが、日本は理事会の常任理事国にイギリス、フランス、イタリアと共に選ばれました。しかし、これを提唱した米国は、[[#モンロー主義|従来の国の方針]]から国内の反対があって国際連盟に加盟しませんでした。 ;第一次世界大戦がもたらしたもの :第一次世界大戦は、人類の歴史が始まって以来の大量の戦死者や戦傷者を出し、当時最も発展していたヨーロッパの国土が荒廃するなど、世界に大きな影響を与えました。その結果として以下のような変化が生じました。 :#ヨーロッパの衰退とアメリカ合衆国・日本の台頭 :#:同盟国であるドイツはもちろん協商国側のフランスは戦場として荒廃し、イギリスも大量の兵力を送り出すなどして疲弊するなど、ヨーロッパの生産力が弱まりました。代わって戦場とならなかった米国は、協商国に兵器他大量の物資を輸出した他、ヨーロッパ諸国が輸出していた地域に代わって輸出することになり、大きな経済的発展を見せることとなりました。その国力を背景に、国際政治で主導的な地位に立ちました。しかし、[[#モンロー主義|もともとの国の方針]]から、国際政治に十分に参加できませんでした。 :#:日本も、国民国家を成立させ産業革命をなしとげた世界でも数少ない国のひとつでしたが、ヨーロッパから遠く離れ、第一次世界大戦の影響を受けることはなく、米国ほどではありませんがヨーロッパの国々が輸出できない分をうめあわせるなどして経済が発展し、[[#国際社会|国際社会でも有力な国となりました]]。 :#<span id="軍縮"/>国際機関の誕生と軍縮の傾向 :#:それまでの国際外交は、国対国の関係でしたが、国際関係が複雑になると、関係する国がまとまって討議するようになりました。第一次世界大戦以前から、電気通信に関して万国電信連合（現.国際電気通信連合）がありましたが、戦後、世界平和を目標とする国際連盟が結成され、平和以外にも人権などについて各国が参加して討議されるようになりました。 :#:第一次世界大戦の{{ruby|惨状|さんじょう}}から、各国共に{{ruby|厭戦|えんせん}}<ref>戦争を嫌うこと。</ref>ムードになっていたため、軍縮に関する国際会議が何回も開かれました。 :#ナショナリズムの実現 :#:ナショナリズムの高まりは、国際的に認められるようになり、オーストリア帝国やオスマン帝国が支配した領域から、同じ民族で集まった国が数多く独立することになりました。しかし、アジアやアフリカの諸国は、まだ独立が認められず、第一次世界大戦後はアジア各地での独立運動が見られるようになります。 :#:また、先進国自身においても一種の民族主義が盛んになります。これは、国外資本が進出してくることや社会主義の民族主義を否定する動きに反発するものです。これが、のちに[[戦争への道と現代の民主国家日本の誕生-昭和から現在まで#ファシズム|ファシズム]]と呼ばれるものになります。 :#社会主義国家の誕生 :#:ロシア革命後、ロシア国内では内戦が起こり、1922年レーニンが率いる共産党が国内をまとめ、世界で初めての[[#共産主義|社会主義・共産主義]]を国の仕組みに持った'''ソビエト社会主義共和国連邦'''<ref>「ソビエト（ソヴェート）」はロシア語で「評議会」の意味で、ロシア革命前後に人々が集まって政治の方針を決めた団体が母体になっていることを意味します。「社会主義共和国」は社会主義を政治の方針とする共和国ということです。最後の「連邦」は、そのような社会主義共和国がいくつか集まって1国となっているということを言っており、ロシア・ソビエト連邦社会主義共和国、ウクライナ社会主義ソビエト共和国、白ロシア・ソビエト社会主義共和国など、いくつかのの国で構成されていました。</ref>（'''ソビエト連邦'''、'''ソ連'''）が誕生しました。 == 脚注 == 以下は学習の参考ですので覚える必要はありません。<small> <references/></small> ---- {{前後 |type=章 |[[小学校社会/6学年/歴史編]] |[[小学校社会/6学年/歴史編/歴史の流れをつかもう|日本の歴史の流れ]] |[[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代|明治維新と近代国家日本の成立-幕末・明治時代]] |[[小学校社会/6学年/歴史編/戦争への道と現代の民主国家日本の誕生-昭和から現在まで|戦争への道と現代の民主国家日本の誕生-昭和から現在まで]] }} [[Category:社会|しようかつこうしやかい6]] [[Category:小学校社会|6ねん]] [[Category:小学校社会 歴史|#12]] 64pyul9pac7abquyhrkqbx4s2wekxty 0 34701 205987 203807 2022-07-29T15:51:59Z Kwawe 68789 /* 第２部　よりよい社会の形成と参画 */ wikitext text/x-wiki <small> [[小学校・中学校・高等学校の学習]] > [[高等学校の学習]] > 高等学校公共 </small> [[w:高等学校|高等学校]]「[[w:公民|公民]]」の科目の一つです。当科目は[[w:必修科目|必修科目]]です。 　以下の見出しは清水書院<ref>『私たちの公共』～資料から考える現代社会の課題～： https://www.shimizushoin.co.jp/info_kyo/koukyouAB/index.html</ref>の新課程教科書配列に従っています。 {{進捗状況}} ==第１部 公共の扉 == ===第１章　社会で生きるということ=== #[[高等学校公共/青年期|青年期]]{{進捗|25%|2022-06-24}} #[[高等学校公共/社会|社会]] #[[高等学校公共/社会と文化|社会と文化]] ===第２章　みんなが幸せな社会とは？=== ===第３章　公共的な空間における基本原理=== ==第２部　よりよい社会の形成と参画== ===第１章　私たちの生活と法=== #[[高等学校公共/個人と法|個人と法]] #[[高等学校公共/平等権|平等権]] #[[高等学校公共/自由権|自由権]] ===第２章　私たちの生活と政治=== #[[高等学校公共/統治総論|統治総論]]{{進捗|00%|2022-06-25}} #[[高等学校公共/国会|国会]]{{進捗|75%|2022-07-01}} #[[高等学校公共/内閣|内閣]]{{進捗|25%|2022-07-06}} #[[高等学校公共/裁判所|裁判所]] #[[高等学校公共/選挙|選挙]] ===第３章　平和主義と日本=== ===第４章　私たちの生活と経済=== #[[高等学校公共/企業の経済的役割|企業の経済的役割]]{{進捗|00%|2022-07-30}} ===第５章　私たちの生活と国際社会=== ==第３部　持続可能な社会を創る== 6yoqnsqxkbxq9kjnmqs20eglc6y9o38 205998 205987 2022-07-29T18:52:13Z Kwawe 68789 /* 第４章　私たちの生活と経済 */ wikitext text/x-wiki <small> [[小学校・中学校・高等学校の学習]] > [[高等学校の学習]] > 高等学校公共 </small> [[w:高等学校|高等学校]]「[[w:公民|公民]]」の科目の一つです。当科目は[[w:必修科目|必修科目]]です。 　以下の見出しは清水書院<ref>『私たちの公共』～資料から考える現代社会の課題～： https://www.shimizushoin.co.jp/info_kyo/koukyouAB/index.html</ref>の新課程教科書配列に従っています。 {{進捗状況}} ==第１部 公共の扉 == ===第１章　社会で生きるということ=== #[[高等学校公共/青年期|青年期]]{{進捗|25%|2022-06-24}} #[[高等学校公共/社会|社会]] #[[高等学校公共/社会と文化|社会と文化]] ===第２章　みんなが幸せな社会とは？=== ===第３章　公共的な空間における基本原理=== ==第２部　よりよい社会の形成と参画== ===第１章　私たちの生活と法=== #[[高等学校公共/個人と法|個人と法]] #[[高等学校公共/平等権|平等権]] #[[高等学校公共/自由権|自由権]] ===第２章　私たちの生活と政治=== #[[高等学校公共/統治総論|統治総論]]{{進捗|00%|2022-06-25}} #[[高等学校公共/国会|国会]]{{進捗|75%|2022-07-01}} #[[高等学校公共/内閣|内閣]]{{進捗|25%|2022-07-06}} #[[高等学校公共/裁判所|裁判所]] #[[高等学校公共/選挙|選挙]] ===第３章　平和主義と日本=== ===第４章　私たちの生活と経済=== #[[高等学校公共/企業の経済的役割|企業の経済的役割]]{{進捗|25%|2022-07-30}} ===第５章　私たちの生活と国際社会=== ==第３部　持続可能な社会を創る== i39d88lgkhi9l3esb8z4zdjk8snmvs5 0 35197 206006 205795 2022-07-30T00:51:39Z Ef3 694 /* ソースコードからのビルド */ Zigは、セルフホスティング<ref>Zigコンパイラーを始めとする、Zigの言語処理系とツールチェインやユーティリティーなどは、Ziｇ自身で書かれています。</ref>なので、最初にバイナリーを入手してブートストラップするか、クロスビルドしたバイナリーを持込むか、パッケージシステムからインストールし、ターゲットでセルフコンパイル出来る状態を作る方法があります（FreeBSDのPortsが行っているのは、まさにこれです）。 wikitext text/x-wiki {{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}} {{Wikipedia|Zig (プログラミング言語)}} 本書は、[[w:Zig|Zig]]のチュートリアルです。 Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです<ref>{{Cite web |url=https://ziglang.org/ |title=Home ⚡ Zig Programming Language |website=ziglang.org |accessdate=2022-07-17 |cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software. }}</ref>。 Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。 == 概要 == Zigは、2016年2月に発表された比較的若いプログラミング言語で<ref>{{Cite web |last1=Kelley |first1=Andrew |title=Introduction to the Zig Programming Language |url=https://andrewkelley.me/post/intro-to-zig.html |website=andrewkelley.me |accessdate=2022-07-17 }}</ref>、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています<ref>{{Cite web |url=https://github.com/ziglang/zig/releases |title=Releases · ziglang/zig |website=github.com |accessdate=2022-07-17 }}</ref>。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。 === Hello world の変遷 === [https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。 ;master@2022-07-17<ref>{{Cite web |url=https://ziglang.org/documentation/master/#Hello-World |title=Zig Documentation(master@2022-07-17) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:0.8.1に同じ ;0.9.1<ref>{{Cite web |url=https://ziglang.org/documentation/0.9.1/#Hello-World |title=Zig Documentation(0.9.1) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:0.8.1に同じ ;0.8.1<ref>{{Cite web |url=https://ziglang.org/documentation/0.8.1/#Hello-World |title=Zig Documentation(0.8.1) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:<syntaxhighlight lang=zig highlight=4> const std = @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().writer(); try stdout.print("Hello, {s}!\n", .{"world"}); } </syntaxhighlight> : <code>{}</code> ⇒ <code>{s}</code><ref>{{Cite web |url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing |title=0.8.0 Release Notes |website=ziglang.org |accessdate=2022-07-17 |quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string. }}</ref> ;0.7.1<ref>{{Cite web |url=https://ziglang.org/documentation/0.7.1/#Hello-World |title=Zig Documentation(0.7.1) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:<syntaxhighlight lang=zig highlight=3> const std = @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().writer(); try stdout.print("Hello, {}!\n", .{"world"}); } </syntaxhighlight> : s/outStream/writer/ ;0.6.0<ref>{{Cite web |url=https://ziglang.org/documentation/0.6.0/#Hello-World |title=Zig Documentation(0.6.0) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:<syntaxhighlight lang=zig highlight=3> const std = @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().outStream(); try stdout.print("Hello, {}!\n", .{"world"}); } </syntaxhighlight> : 初期化の初期値から <code>try</code> がなくなった。 ;0.4.0<ref>{{Cite web |url=https://ziglang.org/documentation/0.4.0/#Hello-World |title=Zig Documentation(0.4.0) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:0.2.0に同じ ;0.5.0<ref>{{Cite web |url=https://ziglang.org/documentation/0.5.0/#Hello-World |title=Zig Documentation(0.5.0) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:<syntaxhighlight lang=zig highlight=4> const std = @import("std"); pub fn main() !void { // If this program is run without stdout attached, exit with an error. const stdout_file = try std.io.getStdOut(); // If this program encounters pipe failure when printing to stdout, exit // with an error. try stdout_file.write("Hello, world!\n"); } </syntaxhighlight> : <var>stdout_file</var> が <code>var</code> から <code>const</code> に変更された。 ;0.3.0<ref>{{Cite web |url=https://ziglang.org/documentation/0.3.0/#Hello-World |title=Zig Documentation(0.3.0) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:0.2.0に同じ ;0.2.0<ref>{{Cite web |url=https://ziglang.org/documentation/0.2.0/#Hello-World |title=Zig Documentation(0.2.0) |website=ziglang.org |accessdate=2022-07-17 }}</ref>:<syntaxhighlight lang=zig> const std = @import("std"); pub fn main() !void { // If this program is run without stdout attached, exit with an error. var stdout_file = try std.io.getStdOut(); // If this program encounters pipe failure when printing to stdout, exit // with an error. try stdout_file.write("Hello, world!\n"); } </syntaxhighlight> ;0.1.1<ref>{{Cite web |url=https://ziglang.org/documentation/0.1.1/#hello-world |title=Zig Documentation |website=ziglang.org |accessdate=2022-07-17 }}</ref>:<syntaxhighlight lang=zig> const io = @import("std").io; pub fn main() -> %void { %%io.stdout.printf("Hello, world!\n"); } </syntaxhighlight> === 環境準備 === Zigは、2022年7月の時点で '''pre-release''' の段階にあり、インストール手順も何度か変わっているので、まずは https://ziglang.org/learn/getting-started/ を参照し、最新のインストール手順を確認してください。また、ローカルのパッケージデータベースをパッケージシステムのリポジトリと同期を取り、鮮度の高い状態を維持するよう心がけてください。これは、インストール後も同じですし、zigに限ったことでもありません。 ==== パッケージ マネージャー によるインストール ==== nightly の Zigを使いたい場合でない限り、お使いのOSやディストリビューションでサポートされているパッケージ マネージャを使ってインストールする事をお勧めします。 ===== Windows ===== Zig は、[[Chocolatey]]パッケージシステムが対応しています。 :<syntaxhighlight lang=console> > choco install zig </syntaxhighlight> {{See also|w:Chocolatey}} ===== macOS ===== macOS では、[[Homebrew]]と[[MacPorts]]が対応しています。 ;最新とタグ付けされたリリース:<syntaxhighlight lang=console> # brew install zig </syntaxhighlight> ;Git の master ブランチの最新ビルド:<syntaxhighlight lang=console> # brew install zig --HEAD </syntaxhighlight> ;MacPorts:<syntaxhighlight lang=console> # port install zig </syntaxhighlight> {{See also|w:Homebrew|w:MacPorts}} ===== FreeBSD ===== ;pkg:<syntaxhighlight lang=console> # pkg install zig </syntaxhighlight> ;ports:<syntaxhighlight lang=console> # make -C /usr/ports/lang/zig all install clean </syntaxhighlight> {{See also|w:Ports}} ===== GNU/Linuxのディストリビューション ===== いわゆるLinuxは、Linux（ここではOSカーネル）と、FSFがHurdカーネルのために設計・開発したGNUユーザーランド（OSの基本機能を提供するソフトウェアの集合）を組合わせたものです。 このように、LinuxカーネルとGNUユーザーランドを組合わせたソフトウェアプラットフォームをGNU/Linuxと呼びます<ref>GNU/Linuxの中核として、商用・非商用を問わず、再配布可能なユーティリティを収集・配布するディストリビューターが登場しました。これらのディストリビューターは、それぞれの配布物（互換性を失いがち）を、ディストリビューションとして区別する必要が生じました（特に、共有ライブラリの非互換性は目立ち、Linux支持者自身が嫌悪するWindowsのDLL-Hellに酷似しています)。 このようにして、ディストリビューション間の区別がなされたのです(また、ほかにもマーケティング上の理由などもあります)。<hr/>Unixでディストリビューションという言葉は、ソースコードで配布されるBSDのD (''distribution'') と関連付けられ、一方、非ソースコード指向のGNU/Linuxディストリビューションが、Unix訴訟の間隙を利する形で386 BSDのニッチをに受入れているのは皮肉なことです。</ref> ====== Fedora 36 ====== :<syntaxhighlight lang=console> # dnf install zig </syntaxhighlight> {{See also|w:Dandified Yum}} ==== ソースコードからのビルド ==== Zig は、ソースコードが Github の https://github.com/ziglang/zig.git で公開されているので、必要に応じてソースコードからビルドすることができます。 Zigは、セルフホスティング<ref>Zigコンパイラーを始めとする、Zigの言語処理系とツールチェインやユーティリティーなどは、Zig自身で書かれています。</ref>なので、最初にバイナリーを入手してブートストラップするか、クロスビルドしたバイナリーを持込むか、パッケージシステムからインストールし、ターゲットでセルフコンパイル出来る状態を作る方法があります（FreeBSDのPortsが行っているのは、まさにこれです）。 ビルド方法こそ頻繁に内容が変わるので、個別具体的な手順は述べませんが、zig はコンパイラーであるとともにツールチェインでもあり、ビルドシステムも内包しているので、 :<syntaxhighlight lang=console>zig build</syntaxhighlight>とすると <code>build.zig</code> ファイルに書かれているレシピにしたがって自動的にビルドが進行します（ストレージとメモリーと時間に余裕を見る必要があります）。 ===== build & exec ===== zig コマンドは、コンパイラーにとどまらずビルドツールの機能を持ち、<code>run</code>サブコマンドは、当該ソースファイルの（ソースコードの変更やキャッシュ クリアーなど必要性があれば）コンパイルとコンパイルの成果物の実行を行います。これを「インタープリター風」と称することがありますが、二回目からはソースファイルを変更したりキャッシュをクリアーしない限りコンパイルのオーバーヘッドが不要で、キャッシュ内の実行形式が実行されるなど、ビルドツール/ビルドシステムとしての特徴が際立ち、逐次解釈的な要素は希薄（皆無）です<ref>crystal の <code>i/interactive</code> サブコマンドのように、真に対話的に実行する処理系も既にあるので、ビルドシステムの簡易呼出しとインタープリターを混同すべきではありません）</ref>。 ;適用例:<syntaxhighlight lang=console> % zig run hello.zig Hello world! </syntaxhighlight> ===== プロジェクトの作成 ===== プログラミングの上で必須ではありませんが、プロジェクト単位でファイルやビルド手順を他からアイソレーションすることができ、zigコマンドにもそれを支援する機能があります。 プログラムの記述言語で、ビルドツールのレシピを書くことができるのは魅力的ですが、当の記述言語の習得中には有難みも半減なので、複数のソースに分割する規模になるまでは単に、zig ソースファイル で不都合はありません。 ここで作るプロジェクトの名前は myproj としましょう。 予め、作業用に適したファイルシステムに、ディレクトリー myproj を用意し、zig init-exe を実行します。 ;myproj の雛型生成とスケルトンのままビルド（と実行）:<syntaxhighlight lang=console> % mkdir myproj/ % cd myproj/ % zig init-exe % find -s * -type f build.zig src/main.zig % cat build.zig const std = @import("std"); pub fn build(b: *std.build.Builder) void { // Standard target options allows the person running `zig build` to choose // what target to build for. Here we do not override the defaults, which // means any target is allowed, and the default is native. Other options // for restricting supported target set are available. const target = b.standardTargetOptions(.{}); // Standard release options allow the person running `zig build` to select // between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. const mode = b.standardReleaseOptions(); const exe = b.addExecutable("myproj", "src/main.zig"); exe.setTarget(target); exe.setBuildMode(mode); exe.install(); const run_cmd = exe.run(); run_cmd.step.dependOn(b.getInstallStep()); if (b.args) |args| { run_cmd.addArgs(args); } const run_step = b.step("run", "Run the app"); run_step.dependOn(&run_cmd.step); const exe_tests = b.addTest("src/main.zig"); exe_tests.setTarget(target); exe_tests.setBuildMode(mode); const test_step = b.step("test", "Run unit tests"); test_step.dependOn(&exe_tests.step); } % cat src/main.zig const std = @import("std"); pub fn main() anyerror!void { std.log.info("All your codebase are belong to us.", .{}); } test "basic test" { try std.testing.expectEqual(10, 3 + 7); } % zig build % zig-out/bin/myproj info: All your codebase are belong to us. </syntaxhighlight> == 基礎篇 == <!-- TODO:書くべき項目を並べてみましたが、例えば「値と型」だけでも網羅的に書いていくとコンテンツの分量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。--> === コメント === Zigでは、<code>//</code> から行末までがコメントです。 C言語の <code>/* … */</code> のスタイルの複数行に渡るコメントは'''ありません'''。 これは、コードの各行を文脈に関係なくトークン化できるようにするためです。 ;hello.zig:<syntaxhighlight lang=zig> // hello.zig: const std = @import("std"); // 先頭に @ が付く関数は組込み関数です pub fn main() !void { try std.io.getStdOut().writeAll("Hello, World!\n"); } </syntaxhighlight> ==== Docコメント ==== Zigでは、<code>///</code> から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。 Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。 [TODO:サンプルコードと整形結果] ==== トップレベルDocコメント ==== Zigでは、<code>//!</code> から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。 コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。 [TODO:サンプルコードと整形結果] DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。 === 値と型 === [TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型, 関連する組込み関数] ;formatを伴うprintと値と型:<syntaxhighlight lang="zig"> pub fn main() !void { const print = @import("std").io.getStdOut().writer().print; try print(" (1) = {}\n", .{42}); try print(" (2) = {}\n", .{0x17}); try print(" (3) = {}\n", .{0o17}); try print(" (4) = {}\n", .{0b0100101}); try print(" (5) = {}\n", .{1e222}); try print(" (6) = {}\n", .{3.1415926536}); try print(" (7) = {}\n", .{'c'}); try print(" (8) = {c}\n", .{'c'}); try print(" (9) = {s}\n", .{"abcdef"}); try print("(10) = {}, {}\n", .{ 111, 999 }); try print("(11) = {1}, {0}\n", .{ 111, 999 }); try print("(12) = {1s}, {0}\n", .{ 111, "abc" }); try print("(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n", .{ 123 }); } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> (1) = 42 (2) = 23 (3) = 15 (4) = 37 (5) = 1.0e+222 (6) = 3.1415926536e+00 (7) = 99 (8) = c (9) = abcdef (10) = 111, 999 (11) = 999, 111 (12) = abc, 111 (13) = 123, 1111011, 173, 7b, 7B </syntaxhighlight> : <code>print()</code>の前の、<code>try</code>は単項演算子です。<code>try</code> は、右の式が例外を投げると式の値にします。 :: エラーユニオン型を返す関数は、<code>try</code>単項演算子か<code>catch</code>二項演算子で、値とエラーを弁別する必要があります（<code>try</code>あるいは<code>catch</code>がないと、コンパイル時にエラーになります）。 : <code>print()</code>の様に、標準ライブラリの <code>format()</code>を使う関数は、'''書式化文字列'''と'''可変長配列''' <code>.{ … }</code> を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので<ref>printf() に代表される可変引数関数は利便性は高いですが、書式化文字列と引数の型不一致が生じると、スタックフレームを非可逆的に破壊します。これを未然に防ぐことは、コンパイル時の書式化文字列の解析と引数の型情報の照合で可能ですが、コンパイル時のメモリーと計算量（≒時間）の増大に直結します。</ref>、プレースホルダーがない場合でも、空の配列 <code>.{}</code> は必須です。 :;書式化文字列:通常の文字列ですが <code>{</code> と <code>}</code> で囲まれたプレスホルダーが、配列の当該順位の値（を書式化した文字列）に置換わります。 :;可変長配列 ::書式化文字列のプレースホルダーのよって、参照と文字列化される値の配列です。 ::2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りの配列にします（ {} の前の . （点）を忘れがち）。 ::基本的に、左から順にプレスホルダーに配列の値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。 ::書式指定と併用する時は、 <code> print("? = {1s}, {0}\n", .{ 111, "abc" })</code> の様に順位が先、書式指定文字が後になります。 : :数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数はいくつかの異なる基数表現が、浮動小数点数は指数表現と小数表現があります。 :文字と文字列は明確に異なり、リレラルでは ’A’ が文字、 ”ABC” が文字列です。 ::嫌な予感がした人の直感は正解です。Zig では、文字列は第一級オブジェクト'''ではなく'''文字（u8）の配列で、関数から返すときはアロケータとdeferの連携などで記憶域の寿命と値の妥当性を「プログラマ」が担保する必要があります。また、[[Go]]のGCはありません。[[Crystal]]のASTを操作できるマクロもありませんし、[[Rust]]の所有権も、[[C++]]のスマートポインターもありません。 :::このことは、C言語なみのプログラマー任せのメモリー管理を文字列以外でも強いられることを意味していますが、zig（コマンド）のソースコードを読むと、複数の型でアロケータを使い分け、スタック上のインスタンス（のハードウェア起因のスコープ）を超絶技巧的に使い分けられることを実践で証明しているので、'''pre-'''releaseから、initial-releasまでの間に、安定化・定式化が図られることを期待します。 <!-- [TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し] [TODO:表組み] --> ==== comptime ==== Zigでは、コンパイル時に'''式が既知かどうか'''という概念を重要視しています。 下記コードはコンパイルエラーになります。 :<syntaxhighlight lang="zig" line highlight=7> fn mul(x: usize, y: usize) usize { return x * y; } pub fn main() void { const len : usize = mul(3, 4); const ary: [len]i32 = undefined; _ = ary; } </syntaxhighlight> ;コンパイル結果:<syntaxhighlight lang=text> An error occurred: /tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression const ary: [len]i32 = undefined; </syntaxhighlight> : 「定数式が評価できない 」と宣っています。 : [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。 :<syntaxhighlight lang="zig" line highlight=6> fn mul(x: usize, y: usize) usize { return x * y; } pub fn main() void { const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 const ary: [len]i32 = undefined; _ = ary; } </syntaxhighlight> :変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。 : _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。 <!-- const std = @import("std"); pub fn main() !void { const i = 0; const string = [_]i32{ 1, 2, 3, 4 }; for (string) |character, index| { std.debug.print("character: {}, index: {}, :{s} \n", .{ character, index, @typeName(@TypeOf(character)) }); } _ = i; } --> === テスト === === 変数 === === 制御構造 === [TODO:Zig の制御構造は文ではなく式] ==== 分岐 ==== [TODO:ifとswitch] ==== 反復 ==== [TODO:whileとfor] === 関数 === === エラー === === 演算子 === ==== 優先順位 ==== 高 <syntaxhighlight lang=text line> x() x[] x.y x.* x.? a!b x{} !x -x -%x ~x &x ?x * / % ** *% *| || + - ++ +% -% +| -| << >> <<| & ^ | orelse catch == != < > <= >= and or = *= *%= *|= /= %= += +%= +|= -= -%= -|= <<= <<|= >>= &= ^= |= </syntaxhighlight> 低 === optional type === === opaque === 訳語未定 === ブロック === [TODO:スコープとシャドーイング；deferはここ？] === キャスト === [TODO:Zig は強い型付け()； 型強制 (Type coercion) について] === アセンブリ言語との連携 === [TODO:所謂インラインアセンラ] === atomic === === 非同期関数 === === 組込み関数 === [TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数] === メモリ管理 === === キーワード一覧 === <code>align</code> <code>allowzero</code> <code>and</code> <code>anyframe</code> <code>anytype</code> <code>asm</code> <code>async</code> <code>await</code> <code>break</code> <code>catch</code> <code>comptime</code> <code>const</code> <code>continue</code> <code>defer</code> <code>else</code> <code>enum</code> <code>errdefer</code> <code>error</code> <code>export</code> <code>extern</code> <code>fn</code> <code>for</code> <code>if</code> <code>inline</code> <code>noalias</code> <code>nosuspend</code> <code>or</code> <code>orelse</code> <code>packed</code> <code>pub</code> <code>resume</code> <code>return</code> <code>linksection</code> <code>struct</code> <code>suspend</code> <code>switch</code> <code>test</code> <code>threadlocal</code> <code>try</code> <code>union</code> <code>unreachable</code> <code>usingnamespace</code> <code>var</code> <code>volatile</code> <code>while</code> == チートシート == [TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ] == リファレンス篇 == == 脚註 == <references /> == 外部リンク == * [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト ** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル * [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ * [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境 ** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ [[Category:zig|*]] [[Category:プログラミング言語]] csp37n2n2s6vn6t37qhzv4qm1lcu2mn 0 35227 206007 205956 2022-07-30T01:03:14Z Ef3 694 /* ソースコードからのビルド */ 多くの場合、インストールされた crystal はスタティック リンクされているので、ダイナミック リンク版の crystal を入手するには、ソースコードからビルドします。 また、interactive Crystalを有効にするためにも、ソースコードからのビルドが必要です。 crystal は、ソースコードが Github の https://github.com/crystal-lang/crystal.git で公開されているので、必要に応じてソースコードからビルドすることができます。 crystalは、[[W:セルフホスティング|セルフホスティング]]<ref>crystalコンパイラーを始めとする、crystalの言語処理系（標準ライブラリーを含む）とツールチェインやユーティリティーなどは、crystal自身で書かれています。</ref>なので、最初にバイナリーを入手してブートストラップするか、クロスビルドしたバイナリーを持込むか、パッケージシステムからインストールし、ターゲットでセルフコンパイル出来る状態を作る方法があります。 wikitext text/x-wiki {{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}} {{Wikipedia|Crystal (プログラミング言語)}} 本書は、[[w:Crystal (プログラミング言語)|Crystal]]のチュートリアルです。 '''Crystal'''は、Ary Borenszweig、Juan Wajnerman、Brian Cardiffと300人以上の貢献者によって設計・開発された汎用オブジェクト指向プログラミング言語です<ref>{{Cite web |url=https://github.com/crystal-lang/crystal/graphs/contributors |title=Contributors |accessdate=2022-07-18 |website=github.com }}</ref>。[[Ruby]] にヒントを得た構文を持ち、[[W:静的型付け|静的型付け]]な[[w:コンパイル型言語|コンパイル型言語]]ですが、変数やメソッドの引数の型は一般には不要です。型は高度なグローバル[[型推論]]アルゴリズムによって解決されます。<ref>{{Cite web |url=http://crystal-lang.org/2013/09/23/type-inference-part-1.html |title=Type inference part 1 |last=Brian J. |first=Cardiff |date=2013-09-09 |accessdate=2022-07-18 |website=crystal-lang.org }}</ref>Crystalは[[W:Apache License|Apache License]]バージョン2.0のもと、[[W:FOSS|FOSS]]としてリリースされています。 __TOC__ == Hello, World! == お約束の[[W:Hello world|Hello_world]]ですが、ここではRubyとの比較も兼ねて、[[Ruby#Hello, World!]]をそのまま実行してみます。 ''hello.cr''を用意します<ref>Crystalのソースファイルの拡張子は''.cr'' です</ref>。 ;hello.cr:<syntaxhighlight lang=Crystal> puts 'Hello, World!' </syntaxhighlight> ;コマンドラインでの操作:<syntaxhighlight lang="console"> % cat hello.cr puts 'Hello, World!' % crystal hello.cr In hello.cr:1:6 1 | puts 'Hello, World!' ^ Error: unterminated char literal, use double quotes for strings % sed -i -e "s@'@Q@g" -e 's@Q@"@g' hello.cr % cat hello.cr puts "Hello, World!" % crystal hello.cr Hello, World! </syntaxhighlight> : Crystalでは、文字列の場合は二重引用符(")を使用するので、' を " に sed で置換えました。 :: 修正後の hello.cr も問題なく ruby で実行できます。 == プログラミング環境 == Crystalのプログラムを作り、コンパイル・実装するには、「オンライン実行環境を使う」・「エディト・コンパイル・実行環境を用意してそれを使う」の２通りの方法があります。 === オンライン実行環境 === 公式のオンライン実行環境、 https://play.crystal-lang.org/ があります。 まずは、これを使って本書に例示されているコードを実行してみることをお勧めします。 === エディト・コンパイル・実行環境 === エディタについては本書では触れませんが、プログラミング時間の大半はエディタの操作に費やされるため、良いエディタを選択することが重要です。 Crystal の言語処理系は、 https://crystal-lang.org/install/ から入手します。 自分の、OSやGNU/Linuxであればディストリビューションに合わせてインストールしてください。 また、FreeBSDのように crystal と shards が別パッケージとなっていることもあるので、その場合は shards も追加インストールします。 === ソースコードからのビルド === 多くの場合、インストールされた crystal はスタティック リンクされているので、ダイナミック リンク版の crystal を入手するには、ソースコードからビルドします。 また、interactive Crystalを有効にするためにも、ソースコードからのビルドが必要です。 crystal は、ソースコードが Github の https://github.com/crystal-lang/crystal.git で公開されているので、必要に応じてソースコードからビルドすることができます。 crystalは、[[W:セルフホスティング|セルフホスティング]]<ref>crystalコンパイラーを始めとする、crystalの言語処理系（標準ライブラリーを含む）とツールチェインやユーティリティーなどは、crystal自身で書かれています。</ref>なので、最初にバイナリーを入手してブートストラップするか、クロスビルドしたバイナリーを持込むか、パッケージシステムからインストールし、ターゲットでセルフコンパイル出来る状態を作る方法があります。 ビルドには、Chromebook(メモリー4GB, Celeron N4020, OS Version: octopus-release/R103-14816.131.0, Chromebrew version: `1.24.0`, llvm-14.0.6)で約30分かかりました。 === crystal コマンド === crystal コマンドは Crystal のコンパイラであると同時に、ビルドツールなどを含んだツールチェインです（プログラミング言語のCrystalは、先頭を大文字、コマンドのcrystalは、先頭を小文字にして区別します）。 [TODO: コマンドラインツール crystal の解説。 crystal ファイル名 は crystal run ファイル名 の短縮形で、インタープリタ的な実行…ではなく、内部ビルドツールでコンパイル・実行を行う] == Ruby との違い == Crystalは、Rubyに触発された構文を持つものの、Rubyとの互換性をゴールに定めては'''いません'''。 このため、細部を見ると仕様に差異があり、Rubyのソースコードをcrystalに掛けても前節の 'Hello World' の様にコンパイルに失敗することがあります。 また、コンパイルできても実行結果に違いが出ることがあります。 ここでは、Ruby との違いについて実際のコードと双方の結果を比較することで、差異についての理解を深めていきます。 === 整数型の特性 === ;大きな整数:<syntaxhighlight lang=Crystal> p 2 ** 999 p (2 ** 999).class </syntaxhighlight> ;rubyの実行結果:<syntaxhighlight lang="console"> 5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688 Integer </syntaxhighlight> ;crystalの実行結果:<syntaxhighlight lang="console"> Unhandled exception: Arithmetic overflow (OverflowError) from /usr/local/share/crystal/share/crystal/src/int.cr:295:9 in '**' from pow.cr:1:1 in '__crystal_main' from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:115:5 in 'main_user_code' from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:101:7 in 'main' from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:127:3 in 'main' from /usr/local/lib64/libc.so.6 in '__libc_start_main' from /usr/local/.cache/crystal/crystal-run-pow.tmp in '_start' from ??? </syntaxhighlight> : Ruby の整数は、桁あふれが起こると自動的に多倍長整数に型変換されるので、継ぎ目なしに大きな数を扱うアルゴルズムが使えます。 : Crystal の整数は、固定長です（大きさについては[[#リテラルと型|後述]]）。なので大きな答えになる式を評価すると桁あふれが生じます。桁あふれが生じますが、C言語のように寡黙に処理を続けるのではなく、実行時に例外（OverflowError）が上がるので、例外を捕捉し然るべき処置を施すことが可能です。 ==== BigInt ==== <code>big</code> を <code>require</code> すると <code>BigInt</code> が使えるようになります。 ;BigInt:<syntaxhighlight lang=Crystal> require "big" p BigInt.new(2) ** 999 p (BigInt.new(2) ** 999).class </syntaxhighlight> ;実行結果:<syntaxhighlight lang="console"> 5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688 BigInt </syntaxhighlight> : BigIntはプリミティブではなので、リテラル表現はありません。また、 ::<syntaxhighlight lang=Crystal> n : BigInt = 2 </syntaxhighlight> ::<syntaxhighlight lang=console> Error: type must be BigInt, not Int32 </syntaxhighlight> :: のように型アノテーションすることも出来ません。 === リテラルと型 === ;様々なリテラルと型:<syntaxhighlight lang=Crystal> [nil, false, true, 42, 2.73, 'Q', "string", [1,2,3], {a:1, b:2}].each{|x| p [x, x.class] } </syntaxhighlight> ;rubyの実行結果:<syntaxhighlight lang="console"> [nil, NilClass] [false, FalseClass] [true, TrueClass] [42, Integer] [2.73, Float] ["Q", String] ["string", String] [[1, 2, 3], Array] [{:a=>1, :b=>2}, Hash] </syntaxhighlight> ;crystalの実行結果:<syntaxhighlight lang="console"> [nil, Nil] [false, Bool] [true, Bool] [42, Int32] [2.73, Float64] ['Q', Char] ["string", String] [[1, 2, 3], Array(Int32)] [{a: 1, b: 2}, NamedTuple(a: Int32, b: Int32)] </syntaxhighlight> : Crystal の整数は Int32、浮動小数点数は Float64 です。 ;サイズを指定した数リテラル:<syntaxhighlight lang=Crystal> [1_i64, 2_u32, 3_u64, 4_i32, 5_i16, 6_u8, 7_i128, 8_u128, 3.14_f32, 1.44_f64].each{|x| p [x, x.class] } </syntaxhighlight> ;ruby:Rubyでは、サーフィックスの付いた数値リテラルは無効 ;crystalの実行結果:<syntaxhighlight lang="console"> [1, Int64] [2, UInt32] [3, UInt64] [4, Int32] [5, Int16] [6, UInt8] [7, Int128] [8, UInt128] [3.14, Float32] [1.44, Float64] </syntaxhighlight> : Crystal では、数値リテラルに _ で始まるサーフィックスを付け { i:符号付き整数, u:符号なし整数, f:浮動小数点数 } と { 8,16,32,64,128 } のビット幅の組合せです<ref>[https://crystal-lang.org/reference/1.5/syntax_and_semantics/literals/ Literals]</ref>。 === for式がない === Crystal には、Ruby にはある for式がありません。 ;Rubyのfor式の構文:<syntaxhighlight lang="ruby"> for 変数 in コレクション 文 end </syntaxhighlight> :コレクションは Range, Array, Hash など内部構造を持つオブジェクトです。 :for式は、最後に評価した値を返すので、for'''式'''です。 ;for式のeachメソッドによる置換え:<syntaxhighlight lang="ruby"> for x in [ 2, 3, 5, 7, 11 ] do p x end # ↓ [ 2, 3, 5, 7, 11 ].each do | x | p x end </syntaxhighlight> : の様にコレクションの each メソッドで置換え可能なので、Rubyからの移植でも小規模な書換えで済みます<ref>[https://github.com/crystal-lang/crystal/issues/830 "For" Loop support #830]</ref>（後述のマクロで実装できないかと思いましたが、いまのところ無理のようです）。 また loop 式もありませんが while true; … end で間に合います。Ruby では while 式の条件の次に do が置けますが、Crystal では置けません。 ==== 自作のforメソッド ==== Rubyのforに似せるという縛りがなければ、（マクロを使うまでもなく）簡単に実装できます。 偶然ですが、[[Scala]]のforメソッドに似てしまいました（あれも、イテレーション メソッドに展開されるのである程度は必然）。Scalaと同じ様にジェネレターと組合わせて多次元に拡張することもできそうです。 ;自作のforメソッド:<syntaxhighlight lang=crystal> def for(collection) collection.each do |elm| yield(elm) end end for [1,2,3,4] do |x| p! x * x end for ({3,4,5,6}) do |x| p! x + x end for (1...999) do |x| p! x - 1 break if x > 5 end for (9999.times) do |x| p! x ** 3 break if x > 7 end </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> x * x # => 1 x * x # => 4 x * x # => 9 x * x # => 16 x + x # => 6 x + x # => 8 x + x # => 10 x + x # => 12 x - 1 # => 0 x - 1 # => 1 x - 1 # => 2 x - 1 # => 3 x - 1 # => 4 x - 1 # => 5 x ** 3 # => 0 x ** 3 # => 1 x ** 3 # => 8 x ** 3 # => 27 x ** 3 # => 64 x ** 3 # => 125 x ** 3 # => 216 x ** 3 # => 343 x ** 3 # => 512 </syntaxhighlight> === eval()がない === Crystal には eval() はありません。 Crystalはコンパイル型言語ですので、無理もないことです。 もし、Crystal で eval() を実装しようとすると、Common Lisp の様にインタープリターを丸ごとランタイムに含む必要があります。 これはリーズナブルな選択ではありません。 Crystal では、eval() が必要なケースに（限定的ですが）マクロを使うことで実現出来る可能性があります。 === マクロ === Crystalには、Rubyにはないマクロがあります<ref>[https://crystal-lang.org/reference/1.5/syntax_and_semantics/macros/ Macros - Crystal]</ref>。Rubyは実行時にすべてのオブジェクトにアクセス出来て、メソッド生やし放題なのでマクロは必要ありませんが、Crystalはコンパイル時に型やメソッドを確定する必要があり、特にメソッドジェネレターとしてのマクロにニーズがあります。また、テンプレート言語的なマクロなので、環境変数による条件分岐や、コンテナを渡し繰返し処理する構文もあります（面白いことにマクロには for 文があり、反対にマクロの中では、eachメソッドは使えません）。マクロには <code><nowiki>{{</nowiki>attr.id}}</code> の様にASTへのアクセス手順が用意されており、半ば言語を拡張するようなアプローチを取ることも出来ます。 [TODO:ASTについての解説；コラム向き？] ;マクロを使ったattr_accessorのイミュレーション:<syntaxhighlight lang=crystal> class Point def initialize(@x : Int32, @y : Int32) end # macro定義 macro attr_accessor(*attrs) {% for attr in attrs %} def {{attr.id}}() @{{attr.id}} end def {{attr.id}}=(var) @{{attr.id}} = var end {% end %} end # macro呼出し attr_accessor :x, :y end pt = Point.new(20, 30) p [pt.x, pt.y] t = pt.x pt.x = pt.y pt.y = t p [pt.x, pt.y] </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> [20, 30] [30, 20] </syntaxhighlight> : Ruby には、attr_accessor と言う「クラスのメンバーのアクセサーを自動生成するメソッド」がありますが、Crystalにはないようなので、マクロで実装しました。 :: attr_accessor :name からは ::<syntaxhighlight lang=ruby> def name() @name end def name=(val) @name = val end </syntaxhighlight>相当のコードが生成されます。 [TODO:マクロの機能と構文の説明 *の付いた引数、 <nowiki>{{</nowiki>引数}}、{% … %} 構文] ==== マクロ p! ==== メソッド p は、与えられた「式」の inspaect() の返す値を puts しますが、マクロ p! は、それに先んじて（評価前の）「式」を表示します<ref>[https://crystal-lang.org/api/1.5.0/Crystal/Macros.html#p%21%28%2Aexpressions%29%3ANop-instance-method def p!(*expressions) : Nop]</ref>。 ;p!の例:<syntaxhighlight lang=crystal> x, y = true, false p! x,y,x && y, x || y, x ^ y, !x, x != y, x == y ary = [ 1, 2, 3 ] p! ary p! ary.map(&. << 1) p! ary.map(&.to_f) </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> x # => true y # => false x && y # => false x || y # => true x ^ y # => true !x # => false x != y # => true x == y # => false ary # => [1, 2, 3] ary.map(&.<<(1)) # => [2, 4, 6] ary.map(&.to_f) # => [1.0, 2.0, 3.0] </syntaxhighlight> ===== 入れ子のp! ===== マクロ p! は入れ子に出来ます。また、一旦ASTに変換してから再度ソースコードに変換するので、等価な別の構文に変換されることがあります。 ;入れ子のp!:<syntaxhighlight lang=crystal> p! ( 100.times{|i| p! i break i if i > 12 } ) </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> (100.times do |i| p!(i) if i > 12 break i end end) # => i # => 0 i # => 1 i # => 2 i # => 3 i # => 4 i # => 5 i # => 6 i # => 7 i # => 8 i # => 9 i # => 10 i # => 11 i # => 12 i # => 13 13 </syntaxhighlight> === クラス === ==== シンプルなクラス ==== ;シンプルなクラス:<syntaxhighlight lang=crystal highlight="2" line> class Hello def initialize(@name : String = "World") end def greeting puts "Hello #{@name}!" end end hello = Hello.new() hello.greeting universe = Hello.new("Universe") universe.greeting </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Hello World! Hello Universe! </syntaxhighlight> :;初期化メソッド :: <syntaxhighlight lang=crystal line start=4> def initialize(@name : String = "World") end </syntaxhighlight> ::Rubyであれば :: <syntaxhighlight lang=ruby line start=4> def initialize(name = "World") @name = name end </syntaxhighlight> ::とするところですが、Crystalでは、型アノテーション <code> : String</code> を使い、引数の型を限定しました。 ::また、（@ 付きの）アトリビュート名を仮引数にすると、そのままアトリビュート（a.k.a. インスタンス変数）に仮引数が代入されます。 ::これは、C++のコンストラクターのメンバー初期化リストと同じアイディアですが、Crystalではインスタンス変数に @ が前置されるので、仮引数に @ が出現すればインスタンス変数の初期値だと自明で、聡明な選択です。 ==== 都市間の大圏距離 ==== [[Ruby#ユーザー定義クラス]]の都市間の大圏距離を求めるメソッドを追加した例を、Crystalに移植しました。 ;都市間の大圏距離:<syntaxhighlight lang=crystal highlight=”2,7,12” line> class GeoCoord getter :longitude, :latitude def initialize(@longitude : Float64, @latitude : Float64) end def to_s(io) ew, ns = "東経", "北緯" long, lat = @longitude, @latitude ew, long = "西経", -long if long < 0.0 ns, lat = "南緯", -lat if lat < 0.0 io << "(#{ew}: #{long}, #{ns}: #{lat})" end # https://github.com/crystal-lang/crystal/issues/259 def distance(other) i, r = Math::PI / 180, 6371.008 Math.acos(Math.sin(@latitude*i) * Math.sin(other.latitude * i) + Math.cos(@latitude*i) * Math.cos(other.latitude * i) * Math.cos(@longitude * i - other.longitude * i)) * r end end # メソッドの先頭を大文字に出来ないのでクラス名のメソッドは作ることが出来ない # def GeoCoord(lng : Float64, lat : Float64) # GeoCoord.new(lng, lat) # end Sites = { "東京駅": GeoCoord.new(139.7673068, 35.6809591), "シドニー・オペラハウス": GeoCoord.new(151.215278, -33.856778), "グリニッジ天文台": GeoCoord.new(-0.0014, 51.4778), } Sites.each { |name, gc| puts "#{name}: #{gc}" } puts "" keys, len = Sites.keys, Sites.size keys.each_with_index { |x, i| y = keys[(i + 1) % len] puts "#{x} ⇔ #{y}: #{Sites[x].distance(Sites[y])} [km]" } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 東京駅: (東経: 139.7673068, 北緯: 35.6809591) シドニー・オペラハウス: (東経: 151.215278, 南緯: 33.856778) グリニッジ天文台: (西経: 0.0014, 北緯: 51.4778) 東京駅 ⇔ シドニー・オペラハウス: 7823.269299386704 [km] シドニー・オペラハウス ⇔ グリニッジ天文台: 16987.2708377249 [km] グリニッジ天文台 ⇔ 東京駅: 9560.546566490015 [km] </syntaxhighlight> :Crystal には、<syntaxhighlight lang=ruby inline> attr_accessor </syntaxhighlight> はありませんが、標準ライブラリーのマクロに <syntaxhighlight lang=crystal inline> getter </syntaxhighlight>があるので :: <syntaxhighlight lang=crystal line start=2> getter :longitude, :latitude </syntaxhighlight> ::としました。 ::将来、<syntaxhighlight lang=ruby inline> attr_accessor </syntaxhighlight> が実装される可能性はありますが、姉妹品の<syntaxhighlight lang=crystal inline> setter </syntaxhighlight>　との併用が下位互換性を考えると確実です。 : to_s は、Ruby ならば :: <syntaxhighlight lang=ruby line start=7> def to_s() </syntaxhighlight> :: <syntaxhighlight lang=ruby line start=12> "(#{ew}: #{long}, #{ns}: #{lat})" </syntaxhighlight> :: ですが、Crystalでは追加の引数 <var>io</var> が必要で :: <syntaxhighlight lang=ruby line start=7> def to_s(io) </syntaxhighlight> :: <syntaxhighlight lang=ruby line start=12> io << "(#{ew}: #{long}, #{ns}: #{lat})" </syntaxhighlight> : Ruby にはクラス名と同じ名前のメソッドで .new を呼出す文化があるのですが、Crystalはメソッドの先頭を大文字に出来ないので、これは見送りました。 ==== 包含と継承 ==== [[JavaScript/クラス#包含と継承]]を、Rubyに移植した[[Ruby#包含と継承]]を、Crystalに移植しました。 ;包含と継承の例:<syntaxhighlight lang=crystal line> class Point def initialize(@x = 0, @y = 0) end def inspect(io) io << "x:#{@x}, y:#{@y}" end def move(dx = 0, dy = 0) @x, @y = @x + dx, @y + dy self end end class Shape def initialize(x = 0, y = 0) @location = Point.new(x, y) end def inspect(io) @location.inspect(io) end def move(x, y) @location.move(x, y) self end end class Rectangle < Shape def initialize(x = 0, y = 0, @width = 0, @height = 0) super(x, y) end def inspect(io) super(io) io << ", width:#{@width}, height:#{@height}" end end rct = Rectangle.new(12, 32, 100, 50) p! rct, rct.is_a?(Rectangle), rct.is_a?(Shape), rct.is_a?(Point), rct.move(11, 21) (END)</syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> rct # => x:12, y:32, width:100, height:50 rct.is_a?(Rectangle) # => true rct.is_a?(Shape) # => true rct.is_a?(Point) # => false rct.move(11, 21) # => x:23, y:53, width:100, height:50 </syntaxhighlight> ;crystal tool hierarchy:<syntaxhighlight lang=console> % crystal tool hierarchy inclusion-and-inheritance.cr -e Shape - class Object (4 bytes) | +- class Reference (4 bytes) | +- class Shape (16 bytes) . @location : Point (8 bytes) | +- class Rectangle (24 bytes) @width : Int32 (4 bytes) @height : Int32 (4 bytes) </syntaxhighlight> : crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。 ===== superclass と subclasses ===== Crystal には、RubyのClassにあるメソッド superclass と subclasses がないので、マクロで実装しました。 ;superclass と subclasses:<syntaxhighlight lang=crystal line> class Class def self.superclass {{ @type.superclass }} end def self.subclasses : Array(self.class) {{ @type.subclasses }}.map(&.as(self.class)) end def self.all_subclasses : Array(self.class) {% begin %} [{{ @type.all_subclasses.join(",").id }}] of self.class {% end %} end end class A end class AA < A end class AAA < AA end class AAB < AA end class AB < A end p! A, A.subclasses, A.all_subclasses, AAA.superclass, A.superclass c = AAA while !c.is_a? Nil p! c.superclass c = c.superclass end</syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> A # => A A.subclasses # => [AA, AB] A.all_subclasses # => [AA, AAA, AAB, AB] AAA.superclass # => AA A.superclass # => Reference c.superclass # => AA c.superclass # => A c.superclass # => Reference c.superclass # => Object c.superclass # => nil </syntaxhighlight> ==== 抽象クラス ==== [[Java/抽象クラス]]を、Crystalに移植しました。 ;抽象クラスの宣言:<syntaxhighlight lang=Java> abstract class クラス名 # end </syntaxhighlight> : このクラス名は、 .new でインスタンス化出来ません。 :: Error: can't instantiate abstract class クラス名 : となります。 :インスタンス化することは出来ませんが、抽象クラスを別のクラスが継承する事は出来ます。 :また、抽象クラスを <code>super()</code> を使うことでメソッドを呼び出せるので、抽象メソッドではないメソッド（具象メソッド）を持つことも、インスタンス変数も持つことも出来ます。 :'''抽象クラスの例'''では、Shapeのinitializeメソッドが抽象クラスの具象メソッドとなっています。 ;抽象メソッドの宣言:<syntaxhighlight lang=Java> abstract def メソッド名 </syntaxhighlight> : 派生先のクラスで、「メソッド名」を定義(def)し忘れると :: Error: abstract `def クラス名#メソッド名()` must be implemented by クラス名 : となります ;抽象クラスの例:<syntaxhighlight lang=crystal line> abstract class Shape def initialize(@x = 0.0, @y = 0.0) end abstract def to_s(io) abstract def area end class Square < Shape def initialize(x, y, @wh = 0.0) super(x, y) end def to_s(io) io << "Square(#{@x}, #{@y}, #{@wh})" end def area @wh * @wh end end abstract class Shape def initialize(@x = 0.0, @y = 0.0) end abstract def to_s(io) abstract def area end class Square < Shape def initialize(x, y, @wh = 0.0) super(x, y) end def to_s(io) io << "Square(#{@x}, #{@y}, #{@wh})" end def area @wh * @wh end end class Recrangle < Shape def initialize(x, y, @w = 0.0, @h = 0.0) super(x, y) end def to_s(io) io << "Rectanle(#{@x}, #{@y}, #{@w}, #{@h})" end def area @w * @h end end class Circle < Shape def initialize(x, y, @r = 0.0) super(x, y) end def to_s(io) io << "Circle(#{@x}, #{@y}, #{@r})" end def area 3.1425926536 * @r * @r end end shapes = [ Square.new(5.0, 10.0, 15.0), Recrangle.new(13.0, 23.0, 20.0, 10.0), Circle.new(3.0, 2.0, 20.0), ] of Shape shapes.each do |shape| puts("#{shape}: #{shape.area}") end </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Square(5.0, 10.0, 15.0): 225.0 Rectanle(13.0, 23.0, 20.0, 10.0): 200.0 Circle(3.0, 2.0, 20.0): 1257.03706144 </syntaxhighlight> ;crystal tool hierarchy:<syntaxhighlight lang=console> % crystal tool hierarchy abstract.cr -e Shape - class Object (4 bytes) | +- class Reference (4 bytes) | +- class Shape (24 bytes) . @x : Float64 (8 bytes) . @y : Float64 (8 bytes) | +- class Circle (32 bytes) | @r : Float64 (8 bytes) | +- class Recrangle (40 bytes) | @w : Float64 (8 bytes) | @h : Float64 (8 bytes) | +- class Square (32 bytes) @wh : Float64 (8 bytes) </syntaxhighlight> : crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。 : 「包含と継承の例」と比べると、ShapeとRectangleが同じ階層にあることがわかると思います。 [TODO:virtual class::いい例がない] == キーワード == Crystalのキーワード( ''keywords'' ) は、以下の通り。 <code>abstract</code> <code>alias</code> <code>as</code> <code>asm</code> <code>begin</code> <code>break</code> <code>case</code> <code>class</code> <code>def</code> <code>do</code> <code>else</code> <code>elsif</code> <code>end</code> <code>ensure</code> <code>enum</code> <code>extend</code> <code>for</code> <code>fun</code> <code>if</code> <code>include</code> <code>instance_sizeof</code> <code>lib</code> <code>macro</code> <code>module</code> <code>next</code> <code>of</code> <code>out</code> <code>pointerof</code> <code>private</code> <code>protected</code> <code>rescue</code> <code>return</code> <code>require</code> <code>select</code> <code>sizeof</code> <code>struct</code> <code>super</code> <code>then</code> <code>type</code> <code>typeof</code> <code>uninitialized</code> <code>union</code> <code>unless</code> <code>until</code> <code>when</code> <code>while</code> <code>with</code> <code>yield</code> <!-- <code>__DIR__</code> <code>__END_LINE__</code> <code>__FILE__</code> <code>__LINE__</code> --> == 演算子 == Crystalは、1つ、2つ、または3つのオペランドを持つ数多くの演算子をサポートしています<ref>[https://crystal-lang.org/reference/1.5/syntax_and_semantics/operators.html Operators]access-date:2022-07-22</ref>。 演算子式は、実際にはメソッド呼び出しとしてパースされます。例えば、<code>a + b</code> は <code>a.+(b)</code> と意味的に同じで、引数 b を持つ a のメソッド + を呼び出すことになります。 {| class="wikitable" |+ 演算子の優先度 !種類 !演算子 |- |インデックス アクセサー |<code>[]</code>, <code>[]?</code> |- |単項 |<code>+</code>, <code>&+</code>, <code>-</code>, <code>&-</code>, <code>!</code>, <code>~</code> |- |指数 |<code>**</code>, <code>&**</code> |- |乗除 |<code>*</code>, <code>&*</code>, <code>/</code>, <code>//</code>, <code>%</code> |- |加減 |<code>+</code>, <code>&+</code>, <code>-</code>, <code>&-</code> |- |シフト |<code><<</code>, <code>>></code> |- |ビット間 AND |<code>&</code> |- |ビット間 OR/XOR |<code><nowiki>|</nowiki></code>,<code>^</code> |- |等値 |<code>==</code>, <code>!=</code>, <code>=~</code>, <code>!~</code>, <code>===</code> |- |比較 |<code><</code>, <code><=</code>, <code>></code>, <code>>=</code>, <code><=></code> |- |論理 AND |<code>&&</code> |- |論理 OR |<code><nowiki>||</nowiki></code> |- |Range |<code>..</code>, <code>...</code> |- |条件 |<code>?:</code> |- |代入 |<code>=</code>, <code>[]=</code>, <code>+=</code>, <code>&+=</code>, <code>-=</code>, <code>&-=</code>, <code>*=</code>, <code>&*=</code>, <code>/=</code>, <code>//=</code>, <code>%=</code>, <code><nowiki>|=</nowiki></code>, <code>&=</code>,<code>^=</code>,<code>**=</code>,<code><<=</code>,<code>>>=</code>, <code><nowiki>||=</nowiki></code>, <code>&&=</code> |- |スプラット |<code>*</code>, <code>**</code> |} == 制御構造 == '''[[w:制御構造|制御構造]]'''（せいぎょこうぞう、''control flow''）とは、「順次」「分岐」「反復」という基本的な処理のことを言います。 {{コラム|Crystalの真理値|2= 制御構造は「条件式」が真であるか偽であるかによって分岐や反復の振る舞いが変わります。 では「条件式」が真・偽はどの様に決まるのでしょう？ Crystalでは <code>false</code> あるいは <code>nil</code> であると偽、それ以外が真です。 なので <code>0</code> も <code>[]</code>（空のArray） も <code>{}</code>（空のNamedTuple）も真です。 }} === 条件分岐 === Crystalの条件分岐には、[[#if|if]], [[#until|until]] と [[#case|case]]の3つの構文があります。 ==== if ==== '''[[w:if|if]]'''は条件式によって実行・否を切り替える構造構文で、評価した式の値を返すので条件演算子でもあります。 ;ifの例:<syntaxhighlight lang=crystal line> a = 0.0 / 0.0 if a < 0 puts "minus" elsif a > 0 puts "plus" elsif a == 0 puts "zero" else puts a end p! ( if a < 0 "minus" elsif a > 0 "plus" elsif a == 0 "zero" else a end ) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> NaN (if a < 0 "minus" else if a > 0 "plus" else if a == 0 "zero" else a end end end) # => NaN </syntaxhighlight> :; elsif節:ifは、オプショナルな elsif 節を設け、条件式が偽であった時に別の条件に合致した処理を実行させることが出来ます。 :; else節:ifは、オプショナルな else 節を設け、条件式が偽であった時に処理を実行させることが出来ます。 : ifは値を返すので、メソッドの実引数に使うことが出来ますし、代入演算の右辺にも使えます。 ==== 後置のif ==== Crystalには、RubyやPerlのような後置のifがあります。 ;後置のifの例:<syntaxhighlight lang=crystal> n = 0 puts "nは0" if n == 0 puts "nは1" if n == 1 </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> nは0 </syntaxhighlight> ==== unless==== '''unless'''（アンレス）は条件式によって実行・否を切り替える構造構文ですが、ifとは条件式に対する挙動が逆です。 ;unless文の例:<syntaxhighlight lang=crystal line> a = 0.0 / 0.0 unless a == 0 puts "Non-zero" else puts a end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> Non-zero </syntaxhighlight> :; else節 : unless文は、オプショナルな else 節を設け、条件式が真であった時に処理を実行させることが出来ます。 ::また、unless文は elsif 節は持てません。 ==== 後置のunless ==== Crystalには、RubyやPerlのような後置のunlessがあります。 ;後置のunlessの例:<syntaxhighlight lang=crystal> n = 0 puts "nは0" unless n == 0 puts "nは1" unless n == 1 </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> nは1ではない </syntaxhighlight> ==== case ==== caseは、複数の条件式によって処理を降る分ける用途の為に用意されています。 ;caseの例:<syntaxhighlight lang=crystal line> n = 2 case n when 1 puts "one" when 2 puts "two" when 3 puts "three" else puts "other" end p! ( case n when 1 "one" when 2 "two" when 3 "three" else "other" end ) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> two (case n when 1 "one" when 2 "two" when 3 "three" else "other" end) # => "two"</syntaxhighlight> :C言語系のswitch文に慣れた人はbreakがないことに気がつくと思います。Crystalのcaseはfall throughしませんし、fall throughさせる方法もありません。 ===== when節が定数でなく式を受付けます ===== [[#if|if]]を使ったコードをcaseに書き換えてみましょう。 ;case の式の省略:<syntaxhighlight lang=crystal line> a = 0.0 / 0.0 case when a < 0 puts "minus" when a > 0 puts "plus" when a == 0 puts "zero" else puts a end p! ( case true when a < 0 "minus" when a > 0 "plus" when a == 0 "zero" else a end ) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> NaN (case true when a < 0 "minus" when a > 0 "plus" when a == 0 "zero" else a end) # => NaN </syntaxhighlight> このコードは when 節の式の値とcaseの式を <code>===</code> で比較し、最初に一致した when に対応する式が実行される事を利用しています。 ===== 型による分岐 ===== when 節が式ではなく型であった場合、caseの式を <code>is_a?</code> で評価し、最初に一致した when に対応する式が実行されます。 ;型による分岐:<syntaxhighlight lang=crystal line> p! 0.class, 0.is_a?(Object), 0.is_a?(Int32), 0.is_a?(Number), 0.is_a?(String) case 0 when String puts "String" when Number puts "Number" when Int32 puts "Int32" when Object puts "Object" else puts "Unknown" end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> 0.class # => Int32 0.is_a?(Object) # => true 0.is_a?(Int32) # => true 0.is_a?(Number) # => true 0.is_a?(String) # => false Number </syntaxhighlight> 暗黙のオブジェクト構文を使うと :<syntaxhighlight lang=crystal line> case 0 when .is_a?(String) puts "String" when .is_a?(Number) puts "Number" when .is_a(Int32) puts "Int32" when .is_a(Object) puts "Object" else puts "Unknown" end </syntaxhighlight> :と書くことが出来ます。 :: メソッドは、.is_a? に限定しないので、 .odd? .even? .include? など Bool を返すメソッドなら何でも使えます。 when に対応する式は、1つのことが珍しくないので、その場合は省略可能な then を補うと、１行で書けます。 :<syntaxhighlight lang=crystal line> case 0 when String then puts "String" when Number then puts "Number" when Int32 then puts "Int32" when Object then puts "Object" else puts "Unknown" end </syntaxhighlight> [TODO:タプルとダミー識別子 _ ] ===== 網羅性の検査 ===== when の代わりに in を使用すると、exhaustive case 式が作成されます。exhaustive case では、必要な in 条件を省略するとコンパイル時にエラーとなります。exhaustive case 式では、when 節と else 節を含むことはできません。 ;Enumの網羅性チェック（網羅不完全）:<syntaxhighlight lang=crystal line highlight=11> enum Colours Red Green Blue end colour : Colours = Colours::Red q = case colour in Colours::Red then "赤" in .green? then "緑" # in .blue? then "青" end p q </syntaxhighlight> ;コンパイルエラー:<syntaxhighlight lang="text"> Showing last frame. Use --error-trace for full trace. In enumcase.cr:8:5 8 | q = case colour ^ Error: case is not exhaustive for enum Colours. Missing members: - Blue </syntaxhighlight> : case - in 式の in が列挙型の要素を網羅していないと、コンパイル時にこの様にエラーになります。 :: Colours::Red と .red? は同義です（enum では、要素名を小文字にし最後に ? が付いたメソッドが生えてきます）。 ;Enumの網羅性チェック（網羅完全）:<syntaxhighlight lang=crystal line highlight=11> enum Colours Red Green Blue end colour : Colours = Colours::Red q = case colour in Colours::Red then "赤" in .green? then "緑" in .blue? then "青" end p q </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> "赤" </syntaxhighlight> [TODO:短絡評価 && || ] === 繰返し === Crystalには、他のプログラミング言語のような[[#繰返し構文|繰返し構文]]と、[[#イテレーターメソッド|イテレーターメソッド]]があります。 ==== 繰返し構文 ==== Crystalの繰返し構文には、while と untilの2つがあります<ref>for も do-while も loop もありません。</ref>。 ===== while ===== while（ホワイル）は条件が'''真'''である間、式を実行しつづけます。 ;構文:<syntaxhighlight lang=crystal> while 条件式 式１ 式２ ： 式ｎ end </syntaxhighlight> : Rubyと違い、条件式の後ろに <code>do</code> をつけることは出来ません。 ;while文のコード例:<syntaxhighlight lang=crystal line> i = 0 p! ( while i < 10 p! i i += 1 break i if i > 5 end ) </syntaxhighlight> : ２行目の <code>i < 5</code>が真の間、次の２行を繰返します。 : ４行目の <code>i += 1</code> は <code>i = i + 1</code> の構文糖 ;実行結果:<syntaxhighlight lang="text"> (while i < 10 p!(i) i = i + 1 if i > 5 break i end end)# => i # => 0 i # => 1 i # => 2 i # => 3 i # => 4 i # => 5 6 </syntaxhighlight> ===== until ===== until（アンティル）は条件が'''偽'''である間、式を実行しつづけます。whileとは条件に対する挙動が逆です。 ;構文:<syntaxhighlight lang=crystal> until 条件式 [ do ] 文１ 文２ ： 文ｎ end </syntaxhighlight> : <code>do</code> は省略できます。 ;untilのコード例:<syntaxhighlight lang=crystal line> i = 0 until i == 3 puts i i += 1 end </syntaxhighlight> : ２行目の <code>i == 3</code>が偽の間、次の２行を繰返します。 ;実行結果:<syntaxhighlight lang="text"> 0 1 2 </syntaxhighlight> ===== for ===== Crystalにはforがありませんが、コレクションのイテレーションメソッドを使うことで繰返しを簡素に実現出来ます。 ==== Rangeオブジェクト ==== Rangeオブジェクトは、整数の区間を表し範囲演算子 <code>開始 .. 終了</code> や <code>開始 ... 終了</code> で生成します。 範囲演算子の終了は省略でき、その場合は数学の半開区間（半閉区間）となり、例えば、<code>1 ..</code>は自然数となります（ただし、日本的な０を自然数に含まない場合）。 ;コード:<syntaxhighlight lang=crystal> rng = 1..3 puts rng.class rng.each do | n | puts "#{n}番"; end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> Range(Int32, Int32) 1番 2番 3番 </syntaxhighlight> ==== Arrayオブジェクト ==== Arrayオブジェクトは、任意の Crystal オブジェクトを要素として持つことができます。 配列式<code>[ 要素1, 要素2, … 要素n ]</code> で生成します。 ;コード:<syntaxhighlight lang=crystal> animals = [ "ネコ", "金魚", "ハムスター" ] puts animals.class animals.each do | animal | puts "動物 #{animal}" end p! ([ "イヌ", *animals , "イグアナ" ]) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> Array(String) 動物 ネコ 動物 金魚 動物 ハムスター (["イヌ", *animals, "イグアナ"]) # => ["イヌ", "ネコ", "金魚", "ハムスター", "イグアナ"] </syntaxhighlight> ==== Tupleオブジェクト ==== Tupleオブジェクトは、任意の Crystal オブジェクトを要素として持つことができます。 配列式<code>{ 要素1, 要素2, … 要素n }</code> で生成します。 ;コード:<syntaxhighlight lang=crystal> animals = { "ネコ", "金魚", "ハムスター" } puts animals.class animals.each do | animal | puts "動物 #{animal}" end p! ({ "イヌ", *animals , "イグアナ" }) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> Tuple(String, String, String) 動物 ネコ 動物 金魚 動物 ハムスター ({"イヌ", *animals, "イグアナ"}) # => {"イヌ", "ネコ", "金魚", "ハムスター", "イグアナ"} </syntaxhighlight> ==== Setオブジェクト ==== Setオブジェクトは集合です。任意の Crystal オブジェクトを要素として持つことができますが、1つの値は重複して持てません。 Set.newに配列式<code>{ 要素1, 要素2, … 要素n }</code> などを渡し初期化します。 ;コード:<syntaxhighlight lang=crystal> animals = Set.new({ "ネコ", "金魚", "ハムスター" }) puts animals.class animals.each do | animal | puts "動物 #{animal}" end p! animals, animals.includes?("ネコ"), animals.includes?("イヌ") animals.delete "ネコ" animals.add "イヌ" p! animals, animals.includes?("ネコ"), animals.includes?("イヌ") animals = Set.new({ "ネコ", "イヌ", "金魚", "ハムスター", "カナリヤ", "クサガメ" }) mammals = Set.new({ "ネコ", "イヌ", "ハムスター" }) p! animals , mammals, animals & mammals, animals | mammals, animals + mammals, animals ^ mammals, animals - mammals, mammals - animals </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> Set(String) 動物 ネコ 動物 金魚 動物 ハムスター animals # => Set{"ネコ", "金魚", "ハムスター"} animals.includes?("ネコ") # => true animals.includes?("イヌ") # => false animals # => Set{"金魚", "ハムスター", "イヌ"} animals.includes?("ネコ") # => false animals.includes?("イヌ") # => true animals # => Set{"ネコ", "イヌ", "金魚", "ハムスター", "カナリヤ", "クサガメ"} mammals # => Set{"ネコ", "イヌ", "ハムスター"} animals & mammals # => Set{"ネコ", "イヌ", "ハムスター"} animals | mammals # => Set{"ネコ", "イヌ", "金魚", "ハムスター", "カナリヤ", "クサガメ"} animals + mammals # => Set{"ネコ", "イヌ", "金魚", "ハムスター", "カナリヤ", "クサガメ"} animals ^ mammals # => Set{"金魚", "カナリヤ", "クサガメ"} animals - mammals # => Set{"金魚", "カナリヤ", "クサガメ"} mammals - animals # => Set{} </syntaxhighlight> ==== NamedTupleオブジェクト ==== NamedTupleオブジェクトは、任意の Crystal オブジェクトをキーに、任意の Crystal オブジェクトを値に持つことができる連想配列です。 NamedTuple式<code>{キー1 => 値1, キー2 => 値2, キーn => 値n}</code> で生成します。 また、キーが Symbol の場合 NamedTuple式<code>{キー1: 値1, キー2: 値2, キーn: 値n}</code> で生成することが出来ます。 ;コード:<syntaxhighlight lang=crystal> animals = {cat: "ネコ", gold_fish: "金魚", hamster: "ハムスター"} puts animals.class animals.each do | en, animal | puts "動物 #{en}: #{animal}" end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> NamedTuple(cat: String, gold_fish: String, hamster: String) 動物 cat: ネコ 動物 gold_fish: 金魚 動物 hamster: ハムスター </syntaxhighlight> このように、Crystalではforがなくてもコレクションのメソッドで同様の処理を実現できます。 ==== loop ==== loop ありません。 while true で代用します。 ;loopの代用コード例:<syntaxhighlight lang=crystal line> i = 1 while true puts "0b%b" % i i <<= 1 break if i > 2**8 end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> 0b1 0b10 0b100 0b1000 0b10000 0b100000 0b1000000 0b10000000 0b100000000 </syntaxhighlight> :５行目の、<code>break if i > 2**8</code>でループを脱出するようにしています。この様に break や return あるいは例外が上がらないとループは永久に終わりません。 :このコードは、Crystalにはない do-while文を模倣する例にもなっています。 ==== イテレーターメソッド ==== ===== Integer#times ===== Integer#timesは与えられたブロックをオブジェクトの示す整数値回くりかえします。 :コード<syntaxhighlight lang=crystal> 3.times{ puts "Hello, world!" } </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> Hello, world! Hello, world! Hello, world! </syntaxhighlight> ;ループ変数を使た例:<syntaxhighlight lang=crystal> 3.times do |i| puts "#{i}の倍は#{2 * i}" end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> 0の倍は0 1の倍は2 2の倍は4 </syntaxhighlight> ;ブロックを伴わないtimesメソッド:<syntaxhighlight lang=crystal> iter = 3.times puts iter.class p! iter.next p! iter.next p! iter.next p! iter.next p! iter.next p! iter.next # puts iter.next # `next': StopIteration: iteration reached an end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> Int::TimesIterator(Int32) iter.next # => 0 iter.next # => 1 iter.next # => 2 iter.next # => #<Iterator::Stop:0x7fb5bedd7fe0> iter.next # => #<Iterator::Stop:0x7fb5bedd7fe0> iter.next # => #<Iterator::Stop:0x7fb5bedd7fe0> </syntaxhighlight> : Integer#times にブロックを渡さないと、Int::TimesIterator([T])オブジェクトが返ります。 : Int::TimesIterator([T])オブジェクトは外部イテレーターと呼ばれnextメソッドで反復を行えます。 == オブジェクト == Crystal では、全てがオブジェクトです。 === オブジェクトのリテラルとクラス === ;オブジェクトのリテラルとクラス:<syntaxhighlight lang=crystal> [nil, false, true, 1, 3.14, "abc", :abc, 1..10, 1...10, 1.., [1, 2_u8, 3_i128], [1, 2, 3], [1, "abc"], {1, 2, 3}, {1, "abc"}, {"a" => 1, "b" => 2}, {a: 1, b: 2}, Set.new([:a, :bc, :def]), ->(x : Int32) { 2 * x }, 100.times, (1..).each, [1, 2, 3].each, {1, 2, 3}.each, {"a" => 1, "b" => 2}.each, # {a:1, b:2}.each, # Error: 'NamedTuple(a: Int32, b: Int32)#each' is expected to be invoked with a block, but no block was given ].each do |obj| p [obj, obj.class] end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text" style="overflow: scroll;height:12em"> [nil, Nil] [false, Bool] [true, Bool] [1, Int32] [3.14, Float64] ["abc", String] [:abc, Symbol] [1..10, Range(Int32, Int32)] [1...10, Range(Int32, Int32)] [1.., Range(Int32, Nil)] [[1, 2, 3], Array(Int128 | Int32 | UInt8)] [[1, 2, 3], Array(Int32)] [[1, "abc"], Array(Int32 | String)] [{1, 2, 3}, Tuple(Int32, Int32, Int32)] [{1, "abc"}, Tuple(Int32, String)] [{"a" => 1, "b" => 2}, Hash(String, Int32)] [{a: 1, b: 2}, NamedTuple(a: Int32, b: Int32)] [Set{:a, :bc, :def}, Set(Symbol)] [#<Proc(Int32, Int32):0x5a6c0ffabcf0>, Proc(Int32, Int32)] [#<Int::TimesIterator(Int32):0x7e2b4be59e80 @n=100, @index=0>, Int::TimesIterator(Int32)] [#<Range::ItemIterator(Int32, Nil):0x7e2b4be5dfc0 @range=1.., @current=1, @reached_end=false>, Range::ItemIterator(Int32, Nil)] [#<Indexable::ItemIterator(Array(Int32), Int32):0x7e2b4be58da0 @array=[1, 2, 3], @index=0>, Indexable::ItemIterator(Array(Int32), Int32)] [#<Indexable::ItemIterator(Tuple(Int32, Int32, Int32), Int32):0x7e2b4be5dfa0 @array={1, 2, 3}, @index=0>, Indexable::ItemIterator(Tuple(Int32, Int32, Int32), Int32)] [#<Hash::EntryIterator(String, Int32):0x7e2b4be58d80 @hash={"a" => 1, "b" => 2}, @index=0>, Hash::EntryIterator(String, Int32)] </syntaxhighlight> === Rubyのオブジェクトのリテラルとクラス === ;Rubyのオブジェクトのリテラルとクラス:<syntaxhighlight lang=ruby> require 'set' [nil, false, true, 1, 3.14, "abc", :abc, 1..10, 1...10, 1.., # [1, 2_u8, 3_i128], [1, 2, 3], [1, "abc"], # {1, 2, 3}, {1, "abc"}, {"a" => 1, "b" => 2}, {a: 1, b: 2}, Set.new([:a, :bc, :def]), ->(x) { 2 * x }, 100.times, (1..).each, [1, 2, 3].each, # {1, 2, 3}.each, {"a" => 1, "b" => 2}.each, # {a:1, b:2}.each, # Error: 'NamedTuple(a: Int32, b: Int32)#each' is expected to be invoked with a block, but no block was given ].each do |obj| p [obj, obj.class] end </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text" style="overflow: scroll;height:12em"> [nil, NilClass] [false, FalseClass] [true, TrueClass] [1, Integer] [3.14, Float] ["abc", String] [:abc, Symbol] [1..10, Range] [1...10, Range] [1.., Range] [[1, 2, 3], Array] [[1, "abc"], Array] [{"a"=>1, "b"=>2}, Hash] [{:a=>1, :b=>2}, Hash] [#<Set: {:a, :bc, :def}>, Set] [#<Proc:0x000014af26147eb0 Main.rb:10 (lambda)>, Proc] [#<Enumerator: 100:times>, Enumerator] [#<Enumerator: 1..:each>, Enumerator] [#<Enumerator: [1, 2, 3]:each>, Enumerator] [#<Enumerator: {"a"=>1, "b"=>2}:each>, Enumerator] </syntaxhighlight> == メソッド == オブジェクトの値や機能を呼び出すためには、メソッドを使います（多くの演算子もメソッドです）。 === クラスのメソッド一覧 === Crystal には、Objectクラスにmethodsメソッドがないので、マクロで実装しました。 ;RubyのObject#methods:<syntaxhighlight lang=crystal> p Object.methods.sort, Integer.methods.sort, Float.methods.sort, Array.methods.sort, Range.methods.sort </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text" style="overflow: scroll;height:12em"> [:!, :!=, :!~, :<, :<=, :<=>, :==, :===, :=~, :>, :>=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] [:!, :!=, :!~, :<, :<=, :<=>, :==, :===, :=~, :>, :>=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :sqrt, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] [:!, :!=, :!~, :<, :<=, :<=>, :==, :===, :=~, :>, :>=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] [:!, :!=, :!~, :<, :<=, :<=>, :==, :===, :=~, :>, :>=, :[], :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] [:!, :!=, :!~, :<, :<=, :<=>, :==, :===, :=~, :>, :>=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] </syntaxhighlight> ;Crystalに実装したmethodsマクロ:<syntaxhighlight lang=crystal> class Object macro methods {{ @type.methods.map(&.name.stringify).sort.uniq }} end end p! Object.methods, Reference.methods, Array.methods, Box.methods, Channel.methods, Deque.methods, Dir.methods, Exception.methods, ArgumentError.methods, DivisionByZeroError.methods, IndexError.methods, InvalidByteSequenceError.methods, Fiber.methods, Hash.methods, IO.methods, File.methods, Mutex.methods, PrettyPrint.methods, Process.methods, Regex.methods, String.methods, Thread.methods, Bool.methods, Int32.methods, Float64.methods, Proc.methods </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text" style="overflow: scroll;height:12em"> Object.methods # => ["!=", "!~", "==", "===", "=~", "class", "crystal_type_id", "dup", "hash", "in?", "inspect", "itself", "not_nil!", "pretty_inspect", "pretty_print", "tap", "to_s", "try", "unsafe_as"] Reference.methods # => ["==", "dup", "exec_recursive", "exec_recursive_clone", "hash", "inspect", "object_id", "pretty_print", "same?", "to_s"] Array.methods # => ["&", "*", "+", "-", "<<", "<=>", "==", "[]", "[]=", "[]?", "calculate_new_capacity", "check_needs_resize", "check_needs_resize_for_unshift", "clear", "clone", "compact", "compact!", "concat", "delete", "delete_at", "dup", "each_repeated_permutation", "fill", "first", "flatten", "increase_capacity", "increase_capacity_for_unshift", "index", "initialize", "insert", "inspect", "internal_delete", "last", "map", "map_with_index", "needs_resize?", "pop", "pop?", "pretty_print", "product", "push", "reject!", "remaining_capacity", "repeated_permutations", "replace", "reset_buffer_to_root_buffer", "resize_if_cant_insert", "resize_to_capacity", "resize_to_capacity_for_unshift", "reverse", "root_buffer", "rotate", "rotate!", "select!", "shift", "shift?", "shift_buffer_by", "shift_when_not_empty", "shuffle", "size", "size=", "skip", "sort", "sort!", "sort_by", "sort_by!", "to_a", "to_lookup_hash", "to_s", "to_unsafe", "to_unsafe_slice", "transpose", "truncate", "uniq", "uniq!", "unsafe_fetch", "unsafe_put", "unshift", "unstable_sort", "unstable_sort!", "unstable_sort_by", "unstable_sort_by!", "|"] Box.methods # => ["initialize", "object"] Channel.methods # => ["close", "closed?", "dequeue_receiver", "dequeue_sender", "initialize", "inspect", "pretty_print", "receive", "receive?", "receive_impl", "receive_internal", "receive_select_action", "receive_select_action?", "send", "send_internal", "send_select_action"] Deque.methods # => ["+", "<<", "==", "buffer", "clear", "clone", "concat", "delete", "delete_at", "dup", "each", "halfs", "increase_capacity", "initialize", "insert", "inspect", "internal_delete", "pop", "pop?", "pretty_print", "push", "reject!", "rotate!", "select!", "shift", "shift?", "size", "size=", "to_s", "unsafe_fetch", "unsafe_put", "unshift"] Dir.methods # => ["children", "close", "each", "each_child", "entries", "initialize", "inspect", "path", "pretty_print", "read", "rewind", "to_s"] Exception.methods # => ["backtrace", "backtrace?", "callstack", "callstack=", "cause", "initialize", "inspect", "inspect_with_backtrace", "message", "to_s"] ArgumentError.methods # => ["initialize"] DivisionByZeroError.methods # => ["initialize"] IndexError.methods # => ["initialize"] InvalidByteSequenceError.methods # => ["initialize"] Fiber.methods # => ["cancel_timeout", "dead?", "enqueue", "initialize", "inspect", "makecontext", "name", "name=", "next", "next=", "previous", "previous=", "push_gc_roots", "resumable?", "resume", "resume_event", "run", "running?", "stack_bottom", "stack_bottom=", "timeout", "timeout_event", "timeout_select_action", "timeout_select_action=", "to_s"] Hash.methods # => ["==", "[]", "[]=", "[]?", "add_entry_and_increment_size", "clear", "clear_entries", "clear_impl", "clear_indices", "clone", "compact", "compact!", "compare_by_identity", "compare_by_identity?", "compute_indices_bytesize", "delete", "delete_entry", "delete_entry_and_update_counts", "delete_impl", "delete_linear_scan", "dig", "dig?", "do_compaction", "double_indices_size", "dup", "each", "each_entry_with_index", "each_key", "each_value", "empty?", "entries", "entries_capacity", "entries_full?", "entries_size", "entry_matches?", "fetch", "find_entry", "find_entry_with_index", "find_entry_with_index_linear_scan", "first_entry?", "first_key", "first_key?", "first_value", "first_value?", "fit_in_indices", "get_entry", "get_index", "has_key?", "has_value?", "hash", "indices_malloc_size", "indices_size", "initialize", "initialize_clone", "initialize_clone_entries", "initialize_compare_by_identity", "initialize_copy_non_entries_vars", "initialize_default_block", "initialize_dup", "initialize_dup_entries", "inspect", "invert", "key_for", "key_for?", "key_hash", "keys", "last_entry?", "last_key", "last_key?", "last_value", "last_value?", "malloc_entries", "malloc_indices", "merge", "merge!", "merge_into!", "next_index", "pretty_print", "proper_subset_of?", "proper_superset_of?", "put", "realloc_entries", "realloc_indices", "rehash", "reject", "reject!", "resize", "select", "select!", "set_entry", "set_index", "shift", "shift?", "size", "subset_of?", "superset_of?", "to_a", "to_a_impl", "to_h", "to_s", "transform_keys", "transform_values", "transform_values!", "update", "update_linear_scan", "upsert", "values", "values_at"] IO.methods # => ["<<", "check_open", "close", "closed?", "decoder", "each_byte", "each_char", "each_line", "encoder", "encoding", "flush", "getb_to_end", "gets", "gets_peek", "gets_slow", "gets_to_end", "has_non_utf8_encoding?", "peek", "peek_or_read_utf8", "peek_or_read_utf8_masked", "pos", "pos=", "print", "printf", "puts", "read", "read_at", "read_byte", "read_bytes", "read_char", "read_char_with_bytesize", "read_fully", "read_fully?", "read_line", "read_string", "read_utf8", "read_utf8_byte", "rewind", "seek", "set_encoding", "skip", "skip_to_end", "tell", "tty?", "utf8_encoding?", "write", "write_byte", "write_bytes", "write_string", "write_utf8"] File.methods # => ["delete", "initialize", "inspect", "path", "read_at", "size", "truncate"] Mutex.methods # => ["initialize", "lock", "lock_slow", "synchronize", "try_lock", "unlock"] PrettyPrint.methods # => ["break_outmost_groups", "breakable", "comma", "current_group", "fill_breakable", "flush", "group", "group_queue", "group_sub", "indent", "initialize", "list", "nest", "newline", "surround", "text"] Process.methods # => ["channel", "close", "close_io", "copy_io", "ensure_channel", "error", "error?", "exists?", "finalize", "initialize", "input", "input?", "output", "output?", "pid", "signal", "stdio_to_fd", "terminate", "terminated?", "wait"] Regex.methods # => ["+", "==", "===", "=~", "capture_count", "clone", "dup", "finalize", "hash", "initialize", "inspect", "internal_matches?", "match", "match_at_byte_index", "matches?", "matches_at_byte_index?", "name_table", "options", "source", "to_s"] String.methods # => ["%", "*", "+", "<=>", "==", "=~", "[]", "[]?", "ascii_only?", "blank?", "byte_at", "byte_at?", "byte_delete_at", "byte_index", "byte_index_to_char_index", "byte_slice", "byte_slice?", "bytes", "bytesize", "calc_excess_left", "calc_excess_right", "camelcase", "capitalize", "center", "char_at", "char_bytesize_at", "char_index_to_byte_index", "chars", "check_no_null_byte", "chomp", "clone", "codepoint_at", "codepoints", "compare", "count", "delete", "delete_at", "downcase", "dump", "dump_char", "dump_hex", "dump_or_inspect", "dump_or_inspect_char", "dump_or_inspect_unquoted", "dump_unquoted", "dup", "each_byte", "each_byte_index_and_char_index", "each_char", "each_char_with_index", "each_codepoint", "each_grapheme", "each_grapheme_boundary", "each_line", "empty?", "encode", "ends_with?", "find_start_and_end", "grapheme_size", "graphemes", "gsub", "gsub_append", "gsub_ascii_char", "has_back_references?", "hash", "hexbytes", "hexbytes?", "includes?", "index", "insert", "insert_impl", "inspect", "inspect_char", "inspect_unquoted", "just", "lchop", "lchop?", "lines", "ljust", "lstrip", "match", "matches?", "partition", "presence", "pretty_print", "rchop", "rchop?", "remove_excess", "remove_excess_left", "remove_excess_right", "reverse", "rindex", "rjust", "rpartition", "rstrip", "scan", "scan_backreferences", "scrub", "single_byte_optimizable?", "size", "size_known?", "split", "split_by_empty_separator", "split_single_byte", "squeeze", "starts_with?", "strip", "sub", "sub_append", "sub_index", "sub_range", "succ", "titleize", "to_f", "to_f32", "to_f32?", "to_f64", "to_f64?", "to_f?", "to_f_impl", "to_i", "to_i128", "to_i128?", "to_i16", "to_i16?", "to_i32", "to_i32?", "to_i64", "to_i64?", "to_i8", "to_i8?", "to_i?", "to_s", "to_slice", "to_u128", "to_u128?", "to_u16", "to_u16?", "to_u32", "to_u32?", "to_u64", "to_u64?", "to_u8", "to_u8?", "to_unsafe", "to_unsigned_info", "to_utf16", "tr", "underscore", "unicode_delete_at", "unsafe_byte_at", "unsafe_byte_slice", "unsafe_byte_slice_string", "upcase", "valid_encoding?"] Thread.methods # => ["detach", "event_base", "gc_thread_handler", "gc_thread_handler=", "initialize", "join", "main_fiber", "next", "next=", "previous", "previous=", "scheduler", "stack_address", "start", "to_unsafe"] Bool.methods # => ["!=", "&", "==", "^", "clone", "hash", "to_s", "to_unsafe", "|"] Int32.methods # => ["!=", "&", "&*", "&+", "&-", "*", "+", "-", "/", "<", "<=", "==", ">", ">=", "^", "clone", "leading_zeros_count", "popcount", "to_f", "to_f!", "to_f32", "to_f32!", "to_f64", "to_f64!", "to_i", "to_i!", "to_i128", "to_i128!", "to_i16", "to_i16!", "to_i32", "to_i32!", "to_i64", "to_i64!", "to_i8", "to_i8!", "to_u", "to_u!", "to_u128", "to_u128!", "to_u16", "to_u16!", "to_u32", "to_u32!", "to_u64", "to_u64!", "to_u8", "to_u8!", "trailing_zeros_count", "unsafe_chr", "unsafe_div", "unsafe_mod", "unsafe_shl", "unsafe_shr", "|"] Float64.methods # => ["!=", "*", "**", "+", "-", "/", "<", "<=", "==", ">", ">=", "ceil", "clone", "fdiv", "floor", "next_float", "prev_float", "round_away", "round_even", "to_f", "to_f!", "to_f32", "to_f32!", "to_f64", "to_f64!", "to_i", "to_i!", "to_i128", "to_i128!", "to_i16", "to_i16!", "to_i32", "to_i32!", "to_i64", "to_i64!", "to_i8", "to_i8!", "to_s", "to_u", "to_u!", "to_u128", "to_u128!", "to_u16", "to_u16!", "to_u32", "to_u32!", "to_u64", "to_u64!", "to_u8", "to_u8!", "trunc"] Proc.methods # => ["==", "===", "arity", "call", "clone", "closure?", "closure_data", "hash", "internal_representation", "partial", "pointer", "to_s"]</syntaxhighlight> == 脚註 == <references /> == 外部リンク == * [https://crystal-lang.org/ The Crystal Programming Language] {{---}} 公式サイト ** [https://crystal-lang.org/reference/1.5/ ドキュメント] *** [https://crystal-lang.org/api/1.5.0/ APIマニュアル] ** [https://play.crystal-lang.org/#/cr Compile & run code in Crystal] {{---}} playground [[Category:Crystal|*]] [[Category:プログラミング言語]] {{NDC|007.64}} cwnbsyjn6uijz2qcgu9esv8cy2u1rj7 0 35259 205988 2022-07-29T16:02:31Z Kwawe 68789 ページの作成:「{| class="wikitable" style="float:right" |+ <big>企業の種類</big> |- ! rowspan="6" |　私　<br />　企　<br />　業　 |　個人企業　 | colspan="2" |個人商店、農家など |- |rowspan="5" |　共同企業　<br />（法人企業） |rowspan="4" |　会社企業　 || <span style="color:maroon">株式会社</span> |- || 合名会社 |- || 合資会社 |- || 合同会社 |- |　組合企業　|| 農業協同組合 など |- ! rowspan="3" |公<br /…」 wikitext text/x-wiki {| class="wikitable" style="float:right" |+ <big>企業の種類</big> |- ! rowspan="6" |　私　<br />　企　<br />　業　 |　個人企業　 | colspan="2" |個人商店、農家など |- |rowspan="5" |　共同企業　<br />（法人企業） |rowspan="4" |　会社企業　 || <span style="color:maroon">株式会社</span> |- || 合名会社 |- || 合資会社 |- || 合同会社 |- |　組合企業　|| 農業協同組合 など |- ! rowspan="3" |公<br />企<br />業 |colspan="2"|　国営企業 |国有林野　など |- |colspan="2"|　地方公営企業　 | 市営バス、水道　など |- |colspan="2"|　特殊法人　など |- |} {| class="wikitable sortable" |+中小企業の定義（中小企業法） !業種 !従業員 !資本金 |- |製造業・その他 |３００人以下 |３億円以下 |- |卸売業 |１００人以下 |１億円以下 |- |小売業 |５０人以下 |５０００万円以下 |- |サービス業 |１００人以下 |５０００万円以下 |} jyy0izlprg4vchq1zgdi2yxqwejc07l 205994 205988 2022-07-29T18:34:57Z Kwawe 68789 wikitext text/x-wiki === 会社の分類 === 私企業は、組織化された法人企業と自営業である個人企業とに分けられます。さらに法人企業は会社企業と組合企業とに分けられます。ここでは、株式会社を中心とする会社企業について見ていきます。会社企業の社員（出資者）には、無限責任社員と有限責任社員がいます。無限責任社員とは、会社が倒産した際に、債権者に対して私有財産を全てなげうってでも責任を負わなければならない社員（出資者）で、有限責任社員とは、会社が倒産しても、出資した金額の範囲で責任を負えばよい社員（出資者）です。会社企業は、この社員の責任の違いによって種類が分かれます。 {| class="wikitable" | colspan="7" |会社企業の種類 |- | colspan="3" rowspan="3" | | colspan="4" |会社企業 |- | colspan="3" |持分会社 | rowspan="2" |株式会社 |- |合名会社 |合資会社 |合同会社 |- | rowspan="2" |社員 | colspan="2" |無限責任社員 |○ |○ |× |× |- | colspan="2" |有限責任社員 |× |○ |○ |○ |- | colspan="3" |出資の種類 |財産・労務・信用 |財産・労務・信用（ただし、有限責任社員は財産） |財産 |財産 |- | colspan="3" |持分の譲渡 |社員の承認 |無限責任社員の承認 |社員の承認 |自由 |- | colspan="7" |企業の種類 |- | colspan="2" |合名会社 | colspan="5" |・無限責任社員のみで構成される会社です。 |- | colspan="2" |合資会社 | colspan="5" |・無限責任社員と有限責任社員で構成される会社です。 |- | colspan="2" |合同会社 | colspan="5" |・２００６年の会社法施行により導入された会社形態 ・出資の範囲内に責任が限定される物的会社の安全性と、内部規律の高い自由度という人的会社の有利性を併せ持つ組織です。 ・２００６年の会社法施行で設立が認められなくなった有限会社に代わって誕生した会社 |- | colspan="2" |株式会社 | colspan="5" |・有限責任社員のみで構成される会社 ・社員（出資者）である株主は、出資額の範囲でのみ責任を負い、出資額に応じて株式を取得して配当を受けます。 ・大企業に相応しい会社形態です。 |- | colspan="2" |特例有限会社 | colspan="5" |・有限会社は２００６年の会社法施行で設立が認められなくなりましたが、特例有限会社として存続は出来ます。 ・有限会社法の廃止により有限会社制度は廃止され、それまでの有限会社は株式会社へ組織変更するか、有限会社として存続するかの選択を迫られることとなり、後者を選んだ場合の会社形態です。 ・法律上は、株式会社と同じように扱われます。 |} dpty1o15duxc3ojqwgdpc9fw5fm3ohf 205995 205994 2022-07-29T18:48:12Z Kwawe 68789 /* 会社の分類 */ wikitext text/x-wiki === 会社の分類 === モノの生産やサービスを提供・販売を継続的に行うことで売り上げを得るために設置される組織を'''企業'''といいます。 ※余談ですが、民間企業では売り上げがないと社員や従業員の給料を支払うことが出来ません。新型コロナウイルスでは、行動制限が政府や都道府県によって課され、企業が人件費削減のために氷河期世代や女性従業員が解雇され問題となりました。 '''私企業'''（いわゆる'''民間企業'''）は、組織化された'''法人企業'''と自営業である'''個人企業'''とに分けられます。さらに法人企業は'''会社企業'''と'''組合企業'''とに分けられます。ここでは、株式会社を中心とする会社企業について見ていきます。会社企業の'''社員'''（出資者）には、'''無限責任社員'''と'''有限責任社員'''がいます。'''無限責任社員'''とは、会社が倒産した際に、債権者に対して私有財産を全てなげうってでも責任を負わなければならない社員（出資者）で、'''有限責任社員'''とは、会社が倒産しても、出資した金額の範囲で責任を負えばよい社員（出資者）です。会社企業は、この社員の責任の違いによって種類が分かれます。 {| class="wikitable" | colspan="7" |会社企業の種類 |- | colspan="3" rowspan="3" | | colspan="4" |会社企業 |- | colspan="3" |持分会社 | rowspan="2" |株式会社 |- |合名会社 |合資会社 |合同会社 |- | rowspan="2" |社員 | colspan="2" |無限責任社員 |○ |○ |× |× |- | colspan="2" |有限責任社員 |× |○ |○ |○ |- | colspan="3" |出資の種類 |財産・労務・信用 |財産・労務・信用（ただし、有限責任社員は財産） |財産 |財産 |- | colspan="3" |持分の譲渡 |社員の承認 |無限責任社員の承認 |社員の承認 |自由 |- | colspan="7" |企業の種類 |- | colspan="2" |合名会社 | colspan="5" |・無限責任社員のみで構成される会社です。 |- | colspan="2" |合資会社 | colspan="5" |・無限責任社員と有限責任社員で構成される会社です。 |- | colspan="2" |合同会社 | colspan="5" |・２００６年の会社法施行により導入された会社形態 ・出資の範囲内に責任が限定される物的会社の安全性と、内部規律の高い自由度という人的会社の有利性を併せ持つ組織です。 ・２００６年の会社法施行で設立が認められなくなった有限会社に代わって誕生した会社 |- | colspan="2" |株式会社 | colspan="5" |・有限責任社員のみで構成される会社 ・社員（出資者）である株主は、出資額の範囲でのみ責任を負い、出資額に応じて株式を取得して配当を受けます。 ・大企業に相応しい会社形態です。 |- | colspan="2" |特例有限会社 | colspan="5" |・有限会社は２００６年の会社法施行で設立が認められなくなりましたが、特例有限会社として存続は出来ます。 ・有限会社法の廃止により有限会社制度は廃止され、それまでの有限会社は株式会社へ組織変更するか、有限会社として存続するかの選択を迫られることとなり、後者を選んだ場合の会社形態です。 ・法律上は、株式会社と同じように扱われます。 |} px7cn52dnd1wux0yo8kjkh7azm7or89 205996 205995 2022-07-29T18:51:13Z Kwawe 68789 /* 会社の分類 */ wikitext text/x-wiki === 会社の分類 === モノの生産やサービスを提供・販売を継続的に行うことで売り上げを得るために設置される組織を'''企業'''といいます。 ※余談ですが、民間企業では売り上げがないと社員や従業員の給料を支払うことが出来ません。新型コロナウイルスでは、行動制限が政府や都道府県によって課され、企業が人件費削減のために氷河期世代や女性従業員が解雇され問題となりました。 企業は私企業、公企業、公私合同企業に分けられます。 '''私企業'''（いわゆる'''民間企業'''）は、組織化された'''法人企業'''と自営業である'''個人企業'''とに分けられます。さらに法人企業は'''会社企業'''と'''組合企業'''とに分けられます。ここでは、株式会社を中心とする会社企業について見ていきます。会社企業の'''社員'''（出資者）には、'''無限責任社員'''と'''有限責任社員'''がいます。'''無限責任社員'''とは、会社が倒産した際に、債権者に対して私有財産を全てなげうってでも責任を負わなければならない社員（出資者）で、'''有限責任社員'''とは、会社が倒産しても、出資した金額の範囲で責任を負えばよい社員（出資者）です。会社企業は、この社員の責任の違いによって種類が分かれます。 {| class="wikitable" | colspan="7" |会社企業の種類 |- | colspan="3" rowspan="3" | | colspan="4" |会社企業 |- | colspan="3" |持分会社 | rowspan="2" |株式会社 |- |合名会社 |合資会社 |合同会社 |- | rowspan="2" |社員 | colspan="2" |無限責任社員 |○ |○ |× |× |- | colspan="2" |有限責任社員 |× |○ |○ |○ |- | colspan="3" |出資の種類 |財産・労務・信用 |財産・労務・信用（ただし、有限責任社員は財産） |財産 |財産 |- | colspan="3" |持分の譲渡 |社員の承認 |無限責任社員の承認 |社員の承認 |自由 |- | colspan="7" |企業の種類 |- | colspan="2" |合名会社 | colspan="5" |・無限責任社員のみで構成される会社です。 |- | colspan="2" |合資会社 | colspan="5" |・無限責任社員と有限責任社員で構成される会社です。 |- | colspan="2" |合同会社 | colspan="5" |・２００６年の会社法施行により導入された会社形態 ・出資の範囲内に責任が限定される物的会社の安全性と、内部規律の高い自由度という人的会社の有利性を併せ持つ組織です。 ・２００６年の会社法施行で設立が認められなくなった有限会社に代わって誕生した会社 |- | colspan="2" |株式会社 | colspan="5" |・有限責任社員のみで構成される会社 ・社員（出資者）である株主は、出資額の範囲でのみ責任を負い、出資額に応じて株式を取得して配当を受けます。 ・大企業に相応しい会社形態です。 |- | colspan="2" |特例有限会社 | colspan="5" |・有限会社は２００６年の会社法施行で設立が認められなくなりましたが、特例有限会社として存続は出来ます。 ・有限会社法の廃止により有限会社制度は廃止され、それまでの有限会社は株式会社へ組織変更するか、有限会社として存続するかの選択を迫られることとなり、後者を選んだ場合の会社形態です。 ・法律上は、株式会社と同じように扱われます。 |} 3nolaobcyput6gf9okgfokxcdcm4y94 205997 205996 2022-07-29T18:51:31Z Kwawe 68789 /* 会社の分類 */ wikitext text/x-wiki === 会社の分類 === モノの生産やサービスを提供・販売を継続的に行うことで売り上げを得るために設置される組織を'''企業'''といいます。企業は私企業、公企業、公私合同企業に分けられます。 ※余談ですが、民間企業では売り上げがないと社員や従業員の給料を支払うことが出来ません。新型コロナウイルスでは、行動制限が政府や都道府県によって課され、企業が人件費削減のために氷河期世代や女性従業員が解雇され問題となりました。 '''私企業'''（いわゆる'''民間企業'''）は、組織化された'''法人企業'''と自営業である'''個人企業'''とに分けられます。さらに法人企業は'''会社企業'''と'''組合企業'''とに分けられます。ここでは、株式会社を中心とする会社企業について見ていきます。会社企業の'''社員'''（出資者）には、'''無限責任社員'''と'''有限責任社員'''がいます。'''無限責任社員'''とは、会社が倒産した際に、債権者に対して私有財産を全てなげうってでも責任を負わなければならない社員（出資者）で、'''有限責任社員'''とは、会社が倒産しても、出資した金額の範囲で責任を負えばよい社員（出資者）です。会社企業は、この社員の責任の違いによって種類が分かれます。 {| class="wikitable" | colspan="7" |会社企業の種類 |- | colspan="3" rowspan="3" | | colspan="4" |会社企業 |- | colspan="3" |持分会社 | rowspan="2" |株式会社 |- |合名会社 |合資会社 |合同会社 |- | rowspan="2" |社員 | colspan="2" |無限責任社員 |○ |○ |× |× |- | colspan="2" |有限責任社員 |× |○ |○ |○ |- | colspan="3" |出資の種類 |財産・労務・信用 |財産・労務・信用（ただし、有限責任社員は財産） |財産 |財産 |- | colspan="3" |持分の譲渡 |社員の承認 |無限責任社員の承認 |社員の承認 |自由 |- | colspan="7" |企業の種類 |- | colspan="2" |合名会社 | colspan="5" |・無限責任社員のみで構成される会社です。 |- | colspan="2" |合資会社 | colspan="5" |・無限責任社員と有限責任社員で構成される会社です。 |- | colspan="2" |合同会社 | colspan="5" |・２００６年の会社法施行により導入された会社形態 ・出資の範囲内に責任が限定される物的会社の安全性と、内部規律の高い自由度という人的会社の有利性を併せ持つ組織です。 ・２００６年の会社法施行で設立が認められなくなった有限会社に代わって誕生した会社 |- | colspan="2" |株式会社 | colspan="5" |・有限責任社員のみで構成される会社 ・社員（出資者）である株主は、出資額の範囲でのみ責任を負い、出資額に応じて株式を取得して配当を受けます。 ・大企業に相応しい会社形態です。 |- | colspan="2" |特例有限会社 | colspan="5" |・有限会社は２００６年の会社法施行で設立が認められなくなりましたが、特例有限会社として存続は出来ます。 ・有限会社法の廃止により有限会社制度は廃止され、それまでの有限会社は株式会社へ組織変更するか、有限会社として存続するかの選択を迫られることとなり、後者を選んだ場合の会社形態です。 ・法律上は、株式会社と同じように扱われます。 |} fckk4yh70e2uc0e8nuqeuuny9hn9mvt 0 35260 205991 2022-07-29T16:23:53Z 椎楽 32225 椎楽 がページ「[[高等学校日本史B/平安初期]]」を「[[高等学校日本史B/平安遷都と政治改革]]」に移動しました: 「平安初期」では本章のテーマがぼやけており、わかりにくいため。 wikitext text/x-wiki #転送 [[高等学校日本史B/平安遷都と政治改革]] jrl08dw0mxtwme6ctdzeo0qpzc1jk8r 2 35262 206011 2022-07-30T11:50:59Z 長寿垢 69212 ページの作成:「どうも、長寿アカウント、略して長寿垢です。」 wikitext text/x-wiki どうも、長寿アカウント、略して長寿垢です。 fmdzc5yyxmfvkmw5x2ffau5cykiqx1l