個人的にゲーム実況はされる側にもメリットがあるためやってもらう分には構わないのですが、作者によっては嫌がる人も居ます。よって規約などで非営利ならokだが、営利ならNGなどと言った制限を加える事が有ります。これら規約は作者の持つ著作権の範囲内で効果を発揮します。

　営利、非営利について触れる機会というのが少ないため、恐らく「動画作者当人にお金が発生していなければ非営利」「動画作者当人にお金が発生していたら営利」という分け方をしているのだと思いますが、実はこの線引きは著作権的には間違いでして。

　ニコ動の場合、プレミアム会員と言う形で、見る側が動画の受信に対価を支払う場合があります。また、ニコ動そのものは投稿された動画を配信して利益を出しているので、どれだけ取り繕った所で非営利目的とはなりません。

　例えばデパートで流れているBGMは、聞くだけなら無料だしそれを目的に聞くだけ聞いて帰るなら無料ではあります。が、利用法としては…無い環境を良くするための利用で商売に使っているため、著作権の例外とはなりません。デパートの屋上での無料公演も同じ理由で著作権侵害の対象となります。

　規約の内容については、どういった意図で書こうとしているのかはしっかりと意識しておかないと予想もつかない使われ方をすることが有りますし、どういう意味なのかも使う側は押さえておかないとトラブルの元となります。

　非営利目的と言う言葉が何を意味するのかを知らず、規約の内容について議論している人を多々見かけますが、その手の議論を見る度に「動画投稿者にお金が発生しないのであれば」といったストレートな書き方にした方が、「非営利」とするよりも伝わりやすいのではないかと思います。

# 余談ですが、ニコ動自身も間違った使い方をしているので、余計に混乱を招いているように思います。

公序良俗も同様

　営利非営利の話と同様に、公序良俗も誤解されて使われる事が多い文言です。具体的に言うと、「公序良俗に反するもの」と「アダルトコンテンツへの使用」は同じではありません。

　本来は契約を作る際に、一般的な常識から逸脱していたら無効と言った具合に使われるものです。何が公序良俗かは時代によって変化するし、下手すると人によっても違います。よって、規約に記載されたものを鵜呑みにすると、後々「アダルトに使わないでください。公序良俗に反する物は禁止しています」というお手紙を貰う事になる……かもしれません。（もちろんこの時に「公序良俗とは～」という反論をするのはNG）

　大雑把な物差しをつけると、公序は「公の秩序」なので、犯罪ではないものや、法律に違反しない物を指します。良俗は「善良の風俗」、要は常識の範囲内を指します。常識の範囲内は解釈が非常に難しいのですが、違法ではないにせよどうだろうかと疑われるような行為、例えば、「結婚して無ければ浮気はＯＫだから、何人と関係を持っても良い」と言う意見をどう見るか、という話になります。

　上記の例の回答は、まぁ、人によって異なるとは思います。よって、公序良俗に反する使い方として何かを具体的に禁止する、というのはやはり難しくは有ります。

　この公序良俗と言う言葉を「性的な物への使用を禁止」という意味でに使う人が居るが、それは大間違いです。モザイクをかける等、流通しているものと同様の処置を取れば、今機能している法律に沿う形なので公序には沿います。性的なコンテンツが良俗に反するのであれば、世の中に流通しているAV全てが商売として成り立たなくなってしまうし、AV女優と言う職業も無くなってしまいます。

　これも性的な物への使用を禁止したいのであればそう名言したほうが良いように思います。公序良俗に反するとした場合は、大雑把には違法な物といったニュアンスで記述した方がいいでしょう。

　色んな人の使い道に影響を与えるものなので、こと規約を書く側に回る際には、なるべく正しい日本語を使うように心がけていただけましたら有難いです。

ゲームに限らずプログラミングに触れるようになると必ず「オブジェクト指向」という単語を耳にします。どうやら便利な物らしいという事で調べると、良くわからない解説やたとえ話にぶつかって結局全く理解できないって言う経験、多分あるあるだと思います。

　wikipediaだとこう書かれています。

オブジェクト指向プログラミングとは、オブジェクトと呼ばれる機能の部品でソフトウェアを構成させるものであり、一般的に以下の機能や特徴を活用したプログラミング技法のことをいう。

• カプセル化（振る舞いの隠蔽とデータ隠蔽）
• インヘリタンス（継承） -- クラスベースの言語
• ポリモフィズム（多態性、多相性） -- 型付きの言語
• ダイナミックバインディング（動的束縛） -- 動的型付言語

　オブジェクト指向に限った話でもないのですが、プログラムの用語を調べると良く数式に遭遇することがあり、そんな物は求めていないと毎回感じてたりします。説明不足を指摘するプレイヤーが求めているのは説明ではない説と全く同じで、使い方を求めているんであって、説明は求めていない訳ですね。

　だがしかし、使い方の実例と言う物はこれまた少なく、出てきたとしてもソースコードでして。違うそうじゃない。

　と言う訳でない物は作れ。カス子で培ったフロンティアスピリッツで、間違えていると言う指摘覚悟で自分なりの理解を、整理もかねて記述したいと思います。間違ってると思った方は、より間違ってないであろう説明をご自身の手で作ってもらえれば幸いです。

オブジェクト指向とそうでない物

　オブジェクト指向を理解するには、同じ挙動をするものでオブジェクト指向のものとそうでないものを見比べると良いと思います。と言う訳で例題。

例題1：面構成

ツクールでアクションゲームを作った。この時各面の遷移をどう管理するか。全8面。用意したMAPも8つ。検討した結果、以下のようなものにしようと考えた。

面	マップID
1	6
2	8
3	1
4	2
5	10
6	9
7	4
8	3

　ぱっと思いつくのは、適当な変数、便宜上「面構成配列」としますが、この面構成配列に[6,8,1,2,10,9,4,2]と配列を代入するものです。


式
　面構成配列 = [6,8,1,2,10,9,4,3]

　これはオブジェクト指向でしょうか、それともオブジェクト指向とは違うスパゲティコード予備軍でしょうか？


　自分の理解では、面構成配列に配列を代入したものはオブジェクト指向ではありません。オブジェクト指向の場合はどう記述するかというと以下のように設定します。

マップID	次の面ID@メモ欄
1	2
2	10
3	0
4	3
6	8
8	1
9	4
10	9

　次の面のIDを各マップのメモ欄辺りに記述して、クリア時にこいつを読み込むという手法を取ります。

　処理の違いを見てみましょう。例えばゲームクリアをした際、面構成配列を採用した場合は以下の物が必要となります。

　次の面ID = 面構成配列[クリア面数]
　
　要するに、クリア面数を代入している変数が新たに必要となります。対してオブジェクト指向だとこうなります。

　次の面ID = 次の面ID@メモ欄

　クリア面数を代入している一行が削れただけですが、意外にこの一行がエラーの元になっていたりします。

手直しが発生した場合

　さて、ここでステージの構成を入れ替える事になったとしましょう。4面と8面を入れ替える事になりました。どうするか。配列の数字を入れ替えるだけですね。


式
　面構成配列 = [6,8,1,3,10,9,4,2]

　こういう場合は、オブジェクト指向よりも面構成配列を採用したほうが数が少ないから、まだぱっと解ります。ですが、もっと増えたらどうでしょう？

　また、テストプレイ中に今触っている面のIDが何番かというのは判断しづらく、難易度が高いからこの面は入れ替えようとなった際にはまずマップ画面を探すはずです。オブジェクト指向を採用していた際、マップ画面はその画面を開いているのでメモ欄に次のステージを新たな物に書き換え、前のステージなどを変更すればよいのですが、配列を使ていた場合、IDを見直す手間が発生します。視覚的に解りにくいんですね。

　面構成配列を採用していた場合はもう一つ、どこにその変数を用意したか探すのが面倒になる場合が有ります。また修正中にカンマを間違えて消してしまったり、気が付いたらステージ数が7になっていたりという事も発生します。そういった凡ミスをオブジェクト指向は防ぐことが出来ます。

　もちろん、オブジェクト指向でも凡ミスは発生します。ステージのつながりがおかしかったりエラーで終了したりもします。が、問題は今、その時プレイしていたステージにあるため、エラーの出たMAPIDの把握という工数が一つ減ります。

　まだ面構成の話なので、オブジェクト指向の便利さと言う物はこの文章では伝わりにくいと思います。オブジェクト指向がどういう物なのかについては何となく伝わったら嬉しいです。

　要は、極力一括で管理しないで、出来るだけオブジェクト単位、アイコンだったり、キャラクターだったりに設定を持たせましょう、というのがオブジェクト指向という理解です。

メンテナンス性の高さ

　数が増えれば増えるほど、オブジェクト指向はその真価を発揮するようになります。例えば以下のような処理をさせたい場合はどうでしょうか。

例題2：装備に応じて立ちグラフィックを変更する

　装備品によって立ちグラフィックが変化するゲームです。まぁエロ同人ではド定番ですし、3Dグラフィックを使うゲームでも定番の機能です。これをどう処理して実装するか、何も考えずに作るとしたらこうなります。

　if アクター1が、頭部にヘルメットを装備しているとき、ピクチャ4に「ヘルメット装備画像」を表示
　if アクター1が、頭部に帽子を装備しているとき、ピクチャ4に「帽子装備画像」を表示
　if ・
　if ・
　if ・
　if アクター1が、武器に弓を装備しているとき、ピクチャ5に「弓装備画像」を表示

　と、条件式を作って、全てのパターンを用意すると言うものです。単純作業で量も多いが実装は不可能ではありません。もちろん、これはオブジェクト指向ではありません。

　オブジェクト指向ではどうするかというと、アクターに以下のように設定していきます。（うちで提供しているRPGツクール VX aceの汎用タグスクリプトを使用した前提です）

<立ち：ヘルメット "ヘルメット装備画像">
<立ち：帽子 "帽子装備画像">
・
・
・
<立ち：弓 "弓装備画像">

　そして、立ち画像を表示する際にはこのように実装します。

　アクター1の頭部の装備を確認
　⇒アクターのメモ欄から<立ち：装備品 "画像">を取得して対応するものを表示。

　ざっくり解説しますと、条件式を一切合切カットしています。ソースコードがすっきりするのはもちろんですが、単純に条件式のみで実装した場合、ピクチャ番号を間違える場合があります。また、数が増えれば増えるほどソースコードは長くなり、間違えた場所を探すのが難しくなります。

　対してオブジェクト指向であれば、少なくともピクチャ番号が装備部位では統一される。間違えたとしても、特定の装備だけ間違えるという事はありません。その場合、5か6行のなかから一つを修正してやれば修正が完了します。

　デバッグも1つの装備がきちんと表示されれば、ファイル名の間違いが無い限りはきちんと表示されるためいちいち全部を確認する必要がありません。（後々あらためて一通り確認はするべきですが）

　例えば弓を装備した際にエラーが発生したのであれば、 <立ち：弓 "弓装備画像">が間違っているか、保存しているファイル名が間違っているのかのどちらかで、原因の特定が楽です。

　例題ではアクターは一人でしたが、実際に作られるゲームでは2,3人、多ければもっと増えるでしょう。実際自分のように人員整理が上手く出来なければ20何人という事も有ります。（RAVAGE）

　全員分の着せ替えを条件式で作っていくとなると、装備品が各5種類、部位が5か所アクター3人としても、条件式は75行必要となります。一行に1分かかったとしても一時間以上かかる計算です。この単純作業に耐えられるかどうかという問題と同時に、どこか間違えたとき、75行から探さなければならず、この修正作業がまた時間がかかってしまいます。メンテナンスのしにくさ、という意味でも条件式のみで作るよりは、オブジェクト指向で作成したほうが楽です。

追加の処理がしやすい

　SAVAGEがちょうど過渡期でして、オブジェクト指向ではない物からオブジェクト指向へと処理を変更していっている所なので、実例としてこんなことをしてました。

例題3：特定のアイテムを所有している場合にイベントが有る、という通知を行う

　SAVAGEでは特定の拠点を解放した際、特定のカードを持っていると掛け合いのイベントが発生するようになっています。イベントが発生している場合、フキダシアイコンを表示させているのですが、この管理をコモンイベントで行っていました。

　まず、所持しているアイテムをチェックして該当するものが有れば「イベントがあるかもスイッチ」をonにしています。

　つづいて、有るかもスイッチがonの時、実際に該当するイベントを精査して、どの一度も発生していないイベントが一つでもあれば、通知をonにし、発生通知がonの時、特定の拠点にフキダシを表示させています。

　こういう処理の仕方をしていると、イベントの新規追加が難しくなります。なので、次はこういう風に変更してみました。



　見比べてみて欲しいのですが、コモンイベントを3つまたいでいたものがわずか3つの命令で済んでいます。ややこしい条件式も要らないし、なによりもイベントの追加がこれによって非常に容易になりました。

　追加のしやすさ、メンテナンスのしやすさがオブジェクト指向を採用する利点で、規模が大きくなればなるほどその恩恵は大きくなります。

まとめ

　自分から実例として表示されるのは以上ですが、少なくともオブジェクト指向ではない処理の仕方と言う物についてはご理解いただけたのではないかなと思います。簡単に言ってしまうと、条件式を多用してしまうのはオブジェクト指向では無い、という事ですね。

　もちろん、オブジェクト指向はいくつかのデータを効率よく扱うために検討と設計が必要なので、小規模なもの、例えば3つ4つの分岐程度であれば、オブジェクト指向で組んだ方が時間の無駄になる可能性も有ります。

　よって、無暗に最初からオブジェクト指向を視野に入れず、条件式だけでぱぱっと組んでしまっていいと思います。同じ処理を何度も繰り返したり、数が多くて面倒になりそうだ、という場合は今組んだ条件式から省けそうな物を省くにはどうしたらいいだろうか、と検討してみて実装していくと言う手順が学習の流れとしては良いと思います。

　以上、自分なりのオブジェクト指向の解釈をでした。株式会社とかの例を出されるよりかは解りやすいんじゃないかと個人的には思います。もし違和感を感じたら各自で解説を作ってみてもらいたいです。色んな例えが有った方が解りやすいと思いますので。理解の一助になれば幸いです。

予備知識

導入

BFのwiki

属性などについて

とっつきやすさと難易度

L4Dでの説明不足

BFでの説明不足

提示されているノウハウ不足

DLsiteやDMMで登録した際、一番左上に登録された他サークルの物をみていいなぁと思った事が多分あるのではないかと思います。良い作品を作ったらあのポールポジションを取れるんじゃないだろうかとそんな風に思うかもしれません。

　一位の広告効果は決して大きくは無いかもしれません。しかし、下の方に埋もれるよりは圧倒的に人の目には付きやすい位置です。他の利点としては111さんなど同人ゲームの感想ブログを運営している人の目に止まりやすく、何かしらの反応を得ることができるでしょうし、そこから広がる可能性に期待が持てます。よって、なるべく高い順位、スクロールなしでも表示される4位以内を取るに越したことはないと思います。

　実はあの掲載位置は作品の内容云々で決定されているものではなく、単純に登録された速さの順でしかありません。と言っても、いかに前日の午前0時ジャストに登録するか、というラットレースが行われている訳ではありません。

　ポールポジションを取りたければ、単純に販売開始日を指定してやれば良いだけです。

　DLsiteでは通信欄に、DMMでは指定用のカレンダーがあるので、そこで指定してやれば特に問題が無い限りは適用してくれます。

　登録の傾向には以下のような物があると思います。

• 月曜日は基本的に一番少ない。
• 日曜日が近づくにつれ登録数は増える。
• 祝日はどの曜日でも多い
• 祝日の前日も多い
• 給料日である25日はどの曜日でも多い
• 給料日の前日である24日も多い
• 25日から月末までは基本的に増加傾向にある

　当然他のサークルも同様に日付を指定してきます。特に土日などは一ヶ月前でもなかなか1位をとれません。激戦区を避け、平日を狙うか、それともあえて激戦区に埋もれる覚悟で勝負するかは各自の判断になるかと思います。上記の傾向はご参考までに。

【関連リンク】

• 111さんTwitter（感想アカウント）
• 111さんTwitter（日常アカウント）

タイトルについてなのですが、おかしな意見に聞こえると思います。「作成中のゲームなのだから勉強しても構わないだろう」「なぜ学んではいけないんだ」……ごもっともな意見だと思います。でも、学ばないほうがいいんです。

　あのゲームはどうやっているんだろうか？　このゲームはどうやっているんだろうか？　他の人がこのジャンルの醍醐味って感じているものはなんだろう？

　調べれば調べるほど、知れば知るほど自分の今作っているゲームとのギャップが気になり、あれも入れよう、これも入れようとなってしまうんですね。結果として完成が遠のいてしまいます。一番大事なのは未完成の究極のゲームではありません。完成した一本の駄作です。失敗を経験とすること。これだけが、良ゲーを作る道です。

　もちろん、ゲームジャンルの醍醐味と言う物は分析し、学び、自分なりの答えを持っておかなければなりません。だから勉強はしなければならないのですが、それは作成中にやる事ではないんです。何故なら、今作っているゲームの醍醐味を引き出すために、そのジャンルを選んだはずだからです。ジャンルを決定してからそのジャンルの良さを探すのは順序が逆です。コンセプトワークとしては手順が逆になってしまいます。だから学んではいけないんです。制作前に学び、制作中に学んだとしても次回作に生かすようしっかりと切り分けなければ完成しなくなります。

　よく格闘技の議論などでどの流派が一番強いのか、どの武器が一番強いのかといった議論がなされることが有ります。ボクシング最強説だったり、ムエタイ最強説だったり、空手最強説だったり。あるいは、トンファー最強説や、マグナム最強説などなど……色々ありますがこれらはすべて嘘です。どの流派、どの武器が一番強いかではなく、「誰」が一番強いかでしかありません。強い武器というのは、その人にあった武器で、身長や体力、状況に合わせて選ぶもので、ゲームジャンルにしても同じことです。人がコンセプトで、ジャンルは流派や武器に過ぎません。自分に合わない醍醐味を引っ張り出しても扱えるものではありません。

　今作っているゲームの醍醐味を引き出すためにそのジャンルを選んだのですから、下手に学ぶよりもまずはテストプレイです。自身が出したかった醍醐味が出ているかどうか。チェックするポイントはそこだけで十分です。他の作品を気にするのは、次の作品を作る時にしましょう。