MMDのセットアップに欠かせないPMXEには以下のような規約が有り、多くの人がこれに頭を悩ませています。

・ソフトウェアの商用利用(※4)
※4 ソフトウェアの利用により作成されたデータの売買なども広義においては商用利用と見なされます。ただし事業行為とは認められない程度の個人レベルでの取り扱いに関しては関知しません。当然ながらこの例外には事業者は含まれません。なお、個人を対象とした商用利用の許諾は一切行いません。

　特に「ソフトウェアの利用により生成されたデータの売買なども～」とある部分で、PMXエディタでセットアップされたMMDモデルの販売や、そのモデルの動作を撮影した動画の販売などは規約に抵触するのではないかと言う懸念を持つのは当然の事と思います。

　結論から言うと、PMXEでセットアップしたモデルの販売、動画の販売共に問題はありません。

　この問題を調べるにあたっていくつか調査してみた所、弁護士ドットコムにて以下のような質問が投稿されていました。

プログラムの規約に「商用利用禁止」と書かれていた際、自作の著作物の販売は制限されますか？

　もしワードの規約に商用利用禁止と書かれていた際、ワードで作成した小説の販売は規約に違反するのかどうかと言う質問でしたが、弁護士の回答は「なりません」と簡潔な物となっています。なぜならないのか少し整理してみます。

　そもそも、規約として制限できるものは、作者が有している権利の範囲内についてです。権利を有していない事柄について規制を加えることは出来ません。

　法的な話としては二次的著作物に該当するか否かが争点となります。原則としてツールの二次的著作物は、ツールのバージョンアップやツールの改造であって、ツールで作られたデータはツールの二次的著作物には該当しません。一方で、例えばツールの画面であったり、ツールにより描画されたもの等は著作権の及ぶ範囲となります。PMXEの場合、PMXEにより作成されたデータが画像や動画などの描画された物ではない以上、作成されるデータはPMXEの二次的著作物ではありません。

　つまり、「ソフトウェアの利用により作成されたデータの売買なども」と規約上は書かれているものの、PMXEの作者が「ソフトウェアの利用により作成されたデータ」の権利を持たないため、規約としては効果を発揮できません。


　上記理由からPMXEでセットアップしたモデルに関しては規約に背景となる法的根拠が存在しないため販売、動画の販売共に問題はない。という事になります。

　ではどういった場合にこの商用利用禁止の規約が効果を発揮するのかというと、読み書きやソフトウェアそのものを授業に使ったりする場合のみ、となります。

　ファイルフォーマットは原則としては著作権が無いものとされています。しかし、そのフォーマットを読み込むプログラムに関しては著作権の保護対象となりますので、商用のソフトウェアによるPMX形式の読み込み、もしくは書き出しなどに関しては制限を加える事が可能です。また、PMXEをパソコン教室などで用いて商売を行うと言うような場合も制限を加える事が可能です。

　余談になりますが、セットアップされたモデルが商用利用禁止となっていた場合は、当然動画などの販売はこれに抵触します。権利者がPMXEの作者ではない、という話ですね。ご注意ください。

三人寄れば文殊の知恵とは言いますが、三人いたらもめるのが人間と言う物です。正直、自分は二人でももめる時はもめます。怒られるときは怒られますし、怒る時は怒るります。経験上、意見の食い違いよりも解釈の食い違いで問題になることが多く、特に文章でやり取りした際に発生しやすいと感じます。

　GYMで実際にあったのですが、ある曲のラフが上がってきた際、頭のシンバルが大きすぎたためこのまま公開すると試聴の時点で最後まで聞いてもらえないだろうと感じました。そこで「これはちょっと聞いてもらえないかもしれない」と送った所、曲そのものの全否定と取られてしまい、そこから大いにもめた事があります。

　文章でのコミュニケーションでは抑揚などの感情面が一切カットされてしまうため、読み手の抑揚で読まれてしまいます。このため全く同じ内容のものでも180度違った取られ方をしてしまうことが有ります。

　例えば「おはよう」というありふれた単語でも、前日に特にトラブルの無い相手からであれば特になんでもない単語ですが、何かちょっともめた相手だとこの「おはよう」からして重苦しく感じてしまいます。送った側はちょっとでも仲を戻したくて軽い挨拶から入ったとしても、です。

　人は言葉のみでコミュニケーションを取る訳ではありません。同じ言葉でも姿勢、声の大きさ、抑揚と様々な情報を感じとって相手の感情を判断しています。「おはよう～」でも、明るく言っているときも有れば、疲れて伸ばしている場合もあります。どういった感情で再生するかは100%読み手に委ねられています。どれだけ文面を取り繕ったとしても、相手が不機嫌な音声で再生したらすべて失礼な文章になってしまいます。

　こういったトラブルを防ぐため、必ず音声通話ができる環境を整えておきましょう。電話でもいいし、電話番号を知らなければSkypeやLINEなどのVC（ボイスチャット）ができるものを準備し、ヘッドセットを購入しておきましょう。3000円ぐらいの安い物で構いません。人脈を保つのに3000円なら安いものです。

個人的にゲーム実況はされる側にもメリットがあるためやってもらう分には構わないのですが、作者によっては嫌がる人も居ます。よって規約などで非営利なら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での説明不足

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