■ レトゲーと今のゲームの違い

　現状においてローポリモデルを使っても、レトゲーとは

出来る事が全く違う訳ですが、この最大の理由は、シェー

ダーモデルの世代の違いだと言えます。

 

　マイクロソフトの3DのAPIというとDirect 3Dですが、

これは、1995年に1が登場し、2000年に登場した8まで、

毎年アップデートがされていたわけですが、仕様を見て

みると1998年に登場した6でバンプマッピングとマルチ

テクスチャーに対応しています。つまり、これ以前の仕

様だとそうした処理が出来ないので品質が低いわけです。

 

　ちなみに

 

【　テクスチャー付き　】

　　■　PlayStation　：　36万ポリゴン/秒（＊）　

　　■　セガサターン　：　10万ポリゴン/秒（＊）

 

　（＊）1フレームではない事に注意。つまり、フレーム

　　　　単位だともっと落とす必要がある

 

 

などになっています。とりあえず、最大演算数であるポリゴン

数とシェーダーを入れた場合及びテクスチャーが入った倍では

様子が異なるので、単なる平面の数値と、テクスチャーを包含

した何かでは内容が違うと言う事にも注意したいところですが

結果的に現状での表記が、秒数ではなくフレーム数である事に

も着目する必要があります。つまり、前述の場合、1/30の数値

ですから、ポリゴンリダクションの必要性は相当高かったと言

えます。

 

　バー茶ファイターシリーズでの様子が変わったのは3からで

すが、アーケード筐体のIはテクスチャーの概念すらないもの

で、IIも画像を張り付ける能力を有していない時代なので、

あそこまで酷くなるというのは、現在の状態では考えられな

い話で、BGEを使った場合でも当然のようにそれ以上の品質

は出ます。また、シェーダーとセットで、CutmulClarkを使

えない時代のそれと現在では全く内容が異なるので、

 

【　現在のローポリ　＞＞＞＞　レトゲー品質　】

 

と言う図式が成立します。つまり、処理が全く異なるので

内容が違うと言う訳です。

 

　ちなみに、初代鉄拳のSystem11がプレステ互換でテク

スチャーとカラーブレンディングが可能だったので、バーチ

ャファイターよりも品質が高くなっていたわけですが、結果

的にシェーディングの差は相当あります。

 

　ローポリの文化というのは、プレステ末期に登場したリア

ルなシェーディングを捨ててヌルヌル動くキャラづくりに特

化させた何かがあるのですが、アプローチで変わると言うの

はゲームハードの末期に時々登場する作品などに存在してい

ます。

 

　基本的に、見れるローポリのアーケードと言うとサイキッ

クフォース2以降になりますが、これが実は、PC/AT互換機

のMS-DOSのマシンで開発されており、Voodoo1とMMX P

entiumの環境で制作されていたようです。

 

　多分、大抵の環境、ジャスティス学園やサイキックフォー

ス２位のポリゴン数だと当たり前に動いてくれるはずなので、

BGEで作業しても大丈夫なはずなんですが、出来る事が違う

のは確かです。というのも、シェーディングが異なるのと、

仕様的にできる事が違うというのがあるからです。

 

　例えば、ムービーテクスチャーを入れてモノを作るとしま

しょう。この場合、プレステの時代は320x240のMotion JP

EGのエンコーダーでの再生ですが、現在において720x480

のOggやQuickTimeベースの某で書き出すと仮定した場合に

影響が出る要素はあまりありません。つまり、PS2の仕様程

度だと現状では影響が出る環境は少ないと言えます。

 

　とりあえず、ゲームのポリゴン数ですが、セガサターンと

かが1フレームで1万ポリゴン程度だったのが、PS2では桁数

が上がり、PS3ではもう一ケタ上がり、現状のそれだともう一

ケタ上がってるような状態になるのですが、PCでゲームを作

る場合に

 

【　現状のフツーに一般向けのPCとして販売されている

　　モノで品質を追いかけると1~2世代前くらいの前の

　　コンソールゲーム機のポリゴン数を想定して作ったほ

　　うがいい　】

 

と言えます。とりあえず、Core i7にQuadro K2200とか

の構成（メモリーが16GB以上でSSD+HDDの場合）だと、

PS3やXbox 360辺りでしょうか。

 

　そうするとゲーム時の重さがない状態で動くはずです。

 

　これを読み込み時間まで短縮しようと思うと、ポリゴン

数の削減とテクスチャーでの調整を考える必要が出てくる

のですが、ぽっリ権数の上限を下げるとレスポンスと読み

込み時間を削減できるので、UV展開後のテクスチャーを

どんな感じで当てるのか？が重要になってきます。

 

　とりあえず、はっきりと言えるのは、

 

【　現状のコンシューマのPC環＠単体を使った場合

　　においてPS4 ProやXbox One Sのハイポリゲー

　　ムを作れる要素は存在しない　】

 

ので、、旧世代機のポリゴン総数の仕様で作るとゲームを一人

で作ってみたい場合のマシンのリソースの上限が見えてる場合

には有効な手段になります。

 

　とりあえず、モバイルゲームのキャラクターモデルが1万ポ

リゴン以下でPS2位で収まっていてあの品質と言うのを考える

とアプローチで内容が変わってくると言えます。

　

　基本的に、

 

　■　ゲームの解像度を上げると、その分重くなる

　　　（現状でいうと720pと1080pと2160pの違い）

 

　■　フレームレートが高くなると重くなる

　　　（現状だと60pを綺麗に出そうと言う内容で

　　　　その時の解像度の話になる）

 

という、動画と全く同じ条件が存在するのですが、動画と異な

るのは

 

　■　総ポリゴン数が増えると重くなる

　　　（と言ってもLODを使うので、BGEでも実際の

　　　　　ポリゴン数をLODなしで表示するほど重た

　　　　　くはない）

 

　■　テクスチャーサイズが巨大になると重くなる

　　　（これと同時に、VRAM不足なども懸念され

　　　　　始めるため上限を知る必要がある）

 

　■　表示はシェーダーなどの演算処理なので、リア

　　　ルタイムレンダーでの処理が複雑になるほど重

　　　くなる。（これはプリレンダリングでの動画の

　　　書き出しの条件と全く同じ）

 

などの内容があります。

 

　個人が所有しているPCで作業するとなると、そうした

部分に気を付ける必要があるのですが、既存の環境で見た

場合（当然、ビジネスモデルは除外する）だと、１世代前

のポリゴン数でシェーダーモデルも似せてみると意外と軽

いです。

 

　こうした内容ですが、スペックが低くなるほどに出来る

事がなくなるのですが、AtomとかCeleronとかPentium

のスモールデスクトップやスレート製品だと、速度がない

ので、プリレンダリングを想定した場合、ポリゴン数の調

整で書き出しが可能な場合があったり、GLレンダリングで

出力できない事もない物も存在しますが、基本的にソレと

IGPの構成では、ゲームや動画の制作は無理と考えてくだ

さい。その為、人世代前のコンソールゲーム機（名称その

物が違う何か）のポリゴン総数を前提に作業する事になる

と言う訳です。

 

　ただし...。1キャラに1万ポリゴン位のものというのは、

結構ローポリですが、NaomiIIで作られたバーチャファイ

ター５がPS3のゲームのポリゴン仕様相当ですから、実質

的にその辺りだと狙えると言う事になります。

 

　あと、注意が必要な内容として、

 

　■　PS3のグラフィックレーベルは出る

 

ではなく、【　もう少し上の品質になる　】ということです。

 

　これは、ゲーム内でのシェーディングとマルチテクスチャー

の利用が可能なので、リアルタイム処理でももう少し上の事が

出来ると言う事も含めてそうした事が言えます。

 

　現在は、PBRを使った質感の追い込みが可能なのと、テクス

チャーについてもマルチテクスチャーになっている（基本的に

単一テクスチャーと言うのは大昔のお話で、容量を削減したい

と言う用途や糸がない場合には使わない手法。シェーディング

によってはそのでフューズマップだけでいい場合もある物の、

フォトリアルだと除外されます。ちなみに、PS3辺りでも複数

のテクスチャーで質感を出すアプローチになっているので結構

昔からそうなっています。と言うよりもDX6からそれが可能な

ので、アーキテクチャで対応できる時期からはそのアプローチ

と言う事になります。）ので、その時代の最新鋭と現在の当た

り前では内容が違います。

 

　基本的に、ゲーム画面のスクショをフルHD（と言っても、P

S3やXbox 360は720pのが多いですが...。）で撮ってみて、

そのゲーム画面のシェーディングはそのエンジンで出るだろ

うか？と考えると大抵の場合は出ます。

 

　ただし、その場合において

 

　■　ゲームの読み込み時間はどの程度だろうか？

　■　ゲーム時のレスポンスはどうだろうか？

 

などの問題が出てきます。こうした内容を含めて、マシンス

ペックに合わせて、品質調整やアプローチを変える必要が出

てくるわけですが、そうポリゴン数でいうと、50万ポリゴン

辺りでもたつくような事は少ない気がします。

 

　ただし、これも環境で異なるので、PS2位に品質を抑えて

テクスチャーなどで品質を上げると言う手法になる場合もあ

りますが、マシンスペックが低くなると無理が来ます。

 

　あと、3Dゲームですが、これに関しては、ウディタで行う

と重たくなるので、3Dのエンジンで行たほう田峪、2.5D系の

ドットがそう見える系脳物だと問題はない物の解像度が上がる

とタイルのサイズの問題が出てくるので、これもマシンスペッ

クで出来る事が変わってくる部分があります。

 

　平面でいうと、ノベルゲームやドット絵のゲームについては

処理が全く違うので3Dゲームは政策不能な環境でも制作可能

な場合もあるのですが、やはりマシンスペックでできる事が異

なるのでその辺りは注意が必要です。

 

　3Dの場合ですが、

 

　■　キャラ1体のポリゴン数を決める

　■　背景のモデルをその20-30倍で考える。

 

とします。こうすると、

 

　【　無双系をする場合だと、キャラのモデルを抑えないと

　　　開発環境が脆弱だと無理　】

 

と言えますし、格ゲーの場合だと、ポリゴン数がどのくらいに

なるかで内容が変わってくると言えます。つまり、PS3レベル

で、2万ポリゴン位で対戦格闘ゲームのような状態のシーンを

組むと

 

　キャラｘ２　＝　4万ポリゴン

　セット　　　＝　40-120万ポリゴン

 

で44-124万ポリゴン/フレームとなります。

 

　ただ、これだと厳しい場合、ドリキャス版のDOA2のように

キャラで3000ポリゴンで、セットで9万ポリゴンにして、9.

6万ポリゴン＋IBL+HDR+PBRとかで作ると言う方法になり

ます。こうなると、処理速度と読み込みスピードが圧倒的に

違うので全く別のゲームになるのは確かですが、環境によっ

てはこの辺りまで下げないと重くて話にならない物もあるの

で、明らかにそれを制作するのに適していない環境だとそう

した状態に至ります。

 

　現状においてローポリでも質感が出せる時代になっている

ので、その辺りが平坦なモノしか出ない時代のソレと今のシ

ェーダーモデルの違いになるのですが、基本的に2009年あた

りの個人が使えるゲームエンジンの機能として

 

　■　VideoTexture

　■　Valletによるダイナミクス

　■　リッジドボディー・ソフトボディー

　

などがあり、テクスチャー性能についてもマシンスペックが

条件を満たせば追い込める状態にあったので、それ以前の時

代のシェーダーモデルのそれで同一ポリゴン数のモノを作る

としても内容が全く違うと言う訳です。

 

　その為、【　品質の追い込める上演を知る事　】という

プリレンダリングの時に必要になる内容とは別に、ゲームエ

ンジンを使う場合だと、

 

【　とりあえず、自分の手持ちの環境を実行環境として

　　想定した場合における処理の上限の確認　】

 

が必要になります。そのうえで

 

　■　ファイルの読み込み時間

　■　ゲームの処理におけるレスポンス

 

なども考えて、調整していき、条件を割り出すことになり

ます。

 

　とりあえず、個人がそうした事をしてみると、意外とポ

リゴン数が多くても動くことに驚くと思うのですが、LOD

の効果があってもムリが来る場合には無理が来るので、そ

の環境での処理の上限の確認が出来ます。それと同時に

 

　【　動いているのか堕ちてるのか解らないレベルで

　　　読み込みが長くなる現象　】　

 

というのにも遭遇するわけですが、その時間が流石に3分も

ある（しかも、シーンの切り替えごとだと終わっている）と、

問題があるので、その辺りのローディングの時間おかねあい

も考えてシーンやプロジェクトの状態を調整する事になり

ます。（実行環境の性能が低いとそれに合わせる感じになり

ます。）

 

　とりあえず、ポリゴン数を抑えないと厳しくなるのは、

個人がPCを購入して何かを作る場合には発生する条件です

が、テクスチャーやマテリアルで品質は変更できるので、

レトゲーと現在のそれでは全く異なる状態になっています。

 

 

■ ポリゴンと考察

　とりあえず、ゲームを動かす場合、自前の環境がスペッ

クの上限になるので、ゲームの挙動を考えると、ある程度

仕様が見えてくるわけですが、ゲームエンジンに限らず、

 

　【　仕様で読み込み時間が変わる　】

 

訳ですが、それと同時に

 

　【　処理可能なポリゴン数　】

 

も存在しています。

 

　その為、ゲームエンジンを動かす場合には、

 

　■　1フレームに何ポリゴンの処理が出来るか

　■　LODを用いた状態でのシーン内の最大ポ

 　　リゴン数

 

の割り出しが必要になります。これで、ゲームにおいて

のポリゴンお割り振りがある程度見えてきます。

　対戦格闘ゲームだと、

 

　【　キャラ：シーン　】＝【　１：３０　】

 

位で考えて、1万ポリゴンで作る場合には、シーンは30

万ポリゴン（か50万ポリゴン以内）で抑えるイメージで

す。

 

　つまり、その状態だと、キャラは2人居ますから上記

の状態だとシーン内で32万ポリゴンと言う事になります。

　

　キャラが多い場合、LODは効きますが、バーチャファ

イター5のようなポリゴン数のがPS3で複数人歩く状態と

言うのは考えにくいですから、この場合、PS4やXbox

Oneだと1万ポリゴンのキャラが複数歩いていてもおか

しくはないのですが、やはり、ハードウェアの上限で、

ポリゴンお割り振りが決まってきます。つまり、上記

の条件だと、

 

　　■　シーン　：　30万ポリゴン

　　■　キャラ　：　2万ポリゴン

 

位ですから、4000ポリゴン位で抑えると、5キャラは

登場させる事が可能とも言えます。

 

　ただし、引きの絵だとLODを利用出来るので、どの

辺りまでだと挙動に影響が出ないのか？を探る作業は

発生します。

 

　こうした内容はアーキテクチャが固定されているコ

ンソールゲーム機とは異なるPCでは遅い物はゲーム機

はおろか、スマホにすら届いていないし、ゲーミング

PCの最大拡張は【　どこかのアトラクション内の施設

や研究機関のシミュレーター　】なので、【　既にゲー

ムの枠を超えて、どこか遠い世界へと向かっている何

か　】まで選べます（そう、スパコンで世界一を狙い

にかかる事も含めて演算ですし、速度を求めると倍精

度浮動小数点演算の速度は必須なので、それも含めて

実装する事を考えると青天井です。）からアーキテク

チャで内容が異なります。

 

　ただ、スパコンで何か巨大な施設が動いているよう

なレベルのSFじみたのはさすがに個人のゲーム開発と

は全く関係ない世界の話なので、この辺りは除外する

としても、単純にCore MAやPhenome IIシリーズの

時代と、Core InsideやAMD FXの世代では速度が違

うので作れるものが異なります。また、扱えるポリゴ

ン数もそうですが、シェーダーモデルが全く違うので

出来る事が異なります。

 

　その為、表示がまたく違うので、同じポリゴン数で

も出力結果がまるで違う訳ですが

 

【　処理の上限はハードウェアのスペックによる　】

 

ので、そこは把握しておく必要があります。

 

　また、BGE以外でも体感する事になりますが、

 

　【　ゲーム自体は動くものおん読み込み時間が

　　　長くなる現象　】

 

があります。これは、確認できている事象としては

 

　■　AnimatedTextureが巨大すぎる事

　　（720pの16x16の256で16bit PNGとか）

 

　■　シーン全体のポリゴン数が多い

 

などです。動画って張ると重くなるのでは？と言う

懸念というのは圧縮コーディックでも数MBの巨大な

容量になる為ですが、前述の画像は100MBをゆうに

超える大容量なので、ポリゴン総数でいうと、100

万ポリゴン位のシーンと同じレベルの読み込み時間

を有します。その為テクスチャーで使う場合、寄り

で見た場合に何ポリゴン位になるだろうか？を考え

る事になります。

 

　シーン全体ですが、300万ポリゴン位のシーンで

も現在のゲーミングＰＣだと当たり前に処理が出来

るのですが、読み込み時間は数十秒かかります。

 

　この間、何かひょじしてバックグラウンドで読み込

めていればいいのですが、ゲームのプロジェクトその

ものが重たい場合にはそれはムリなようなので、この

あたりの兼ね合いを考える必要があります。

 

　その為、ポリゴン数をどの辺りにするのか？という

のはゲーム時の挙動もそうなのですが、それとは別に

 

【　読み込み時間の許容をどの辺りに設けて、その

　　条件でのポリゴン数をどの辺りにするのか？　】

 

も含まれるわけです。そうなると、ポリゴン数を多め

にすると、その分読み込みが長くなるので、その待ち

時間の調整が必要になるのですが、その調整をどう行

うかも考えてポリゴン数の上限を考える事になります。

 

---

リダクションは必須条件

---

 

　そうなると、無駄なポリゴンは極力削除したほうが

いいと言う結論に行き着くので、

 

【　CGで行う両面ポリゴンはどうしようか？　】

 

と言う内容も含めて扱いを考える必要性が出てきます。

 

　それとは別に、

 

　【　指定の範囲内でのモデル制作　】

 

になるので、極力ポリゴン数を抑えて作る工夫は必要

になります。

 

　制作としては二通り存在して、海外ゲームのように

 

　【　どうせムービーでハイポリ使うんだから、ゲー

　　　ムのほうはリダクションしたものを使ってハイ

　　　ポリはそのまま使う　】

 

と言う近年のゲーム機のソレと、

 

　【　レトゲーのようにリソースがなさすぎる暗黒

　　　時代に発生したローポリテクニックの系譜の

　　　現代版のそれを使う　】

 

方法があります。

 

　と言っても、前者については、メモリーをフルで搭載した

ようなハイスペックマシンでのお話になるので、メーカー

のそれと同等のメッシュは無理ですが、メッシュの多いモデ

ルをリダクションして使うと言う手法があります。

 

　この場合、Sculptを使う方法も出てくるので、Z-Brushや

BlenderのSculptやMetasequoiaの彫刻などで作る方法と、

シェープの分割巣を増やして作っていく方法があります。

 

　ただし、マインドクラフトやプレステやサターンレベルの

ローポリだとリダクションであれにすると破たんするので、

素直に、立方体から形状生成をするか、面を貼っていくほう

がほうがいいように思います。

 

　とりあえず、ポリゴン数が恐ろしく少なくなる状態だと、

基本的に面をはるかシェープを変形させて作る手法になる

ので、【　ハイポリ＝＞ミドルポリゴン　】と言うPS3や

Xbox 360の世代のゲームのつくり方とは少し異なるよう

な気がします。

 

---

個人的なローポリの考察

---

 

　まず、ローポリですが、極限までローポリにする場合、

考え方としては、【　Doga-Lシリーズ　】のような状態

で【　表情をテクスチャーの切り変えで行う　】という

アプローチまで下げてしまえば相当メッシュは減らせま

す。つまり、この場合だと、瞼の必要性がありません。

 

　ただし、【　何時の時代のCGなんだろうか？　】とい

う話になります。次に、

 

　【　表情はどの程度あるのか？　】

 

でメッシュの内容が変わります。例えば、キャラが無表

情で動くようなものだと

 

　■　口　：　テクスチャーで描く

　■　目　：　くぼみにテクスチャー

 

で対応できます。この時に、目のメッシュの前方を閉じる

世にシェープキーを入れるとかすれば、目は閉じれる（B

GEの場合、ドライバーで頭のボーンに連動させると動くっ

ぽい。もしくはフェイシャルリグ適応）のですが、この有

無で内容は変わってきます。つまり、そうした足しようだ

と、一体化成形のフィギュアのような目のモールドがある

モデルで、ソコにデカールを貼ったり、塗るようにテクス

チャーを利用する事になります。

 

　つまり、瞼のメッシュが違和感なく閉じてくれれば、問

題がなく、その形状にまつ毛のオブジェクトが連動してく

れれば問題がないと言う訳です。

 

　つまり、この状態で考えると、

 

　【　目パチはあるが、視点の変化はないモデル　】

 

になります。この対策として、テクスチャーの位置を動か

すと言うアプローチもありますが、モデルの使い方で変わ

ってくるような気がします。

 

　フェイシャルを入れる場合、ローポリだと

 

　■　目パチ

　■　口

　■　眉毛

 

辺りがモーションで動かせるほうが表情はつけやすいのです

が、この場合に、

 

　■　眼球を内包する形状と眼球

　■　口腔内と歯や舌

 

などをどうするのか？も出てきます。つまり、簡素な作りの

ものなのか、それとも、歯と歯茎と舌まで存在するつくりな

のかで内容が変わります。

 

　アニメのシェーディングだと、テイストにもよりますが、

ローポリのそれだと、48本の歯が存在している状態とは考

えにくいので、形状でいうと歯の形状を個別に制作して歯

茎に配置すると言う作業は発生しません。そうなると、こ

の場合は、もう少し簡素な形状になりますし、舌も同様で

す。

　

　また、見え方で変わるのですが、古いシェーダーモデル

のようにノーマルマップが使えない環境下だと濃淡だけで

形状の状態を表現しないとダメ（だったのですが、初代プ

レステやセガサターンのテクスチャーが微妙だったのは、

あれは256色減色でインデックスカラーに近い状態で処

理していたからとも言えます。）なものだと色の使い方

でどうにかするしかないのですが、ある程度の凹凸だと、

ノーマルマップで適応できるので、馬のひづめのような

形状のオブジェクトを生成して、シームを付けて展開し

歯の状態をマッピングで再現すると言う方法もあります。

 

　ただ、白いのが見えたらしいと言う条件だと形状の生

成が少し変わるのですが、フェイシャルをする場合だと、

 

　【　単にアとオとイが出来たらいい何か　】

 

と

　

　【　表情が複数ある何か　】

 

で周囲のメッシュ構造が変わるので、作り方が変わってき

ます。

　

　目については、テクスチャーの入れ替えで振る舞いを変

える事が可能ですが、眼球運動の有無で作りが変わります。

 

　あまり動かない場合の制作方法として

 

　【　裏面のメッシュ数が無駄なのでそれは

　　　削除する　】

 

と言う方法もあるのですが、半球のメッシュのテクスチャ

ーを当てると言う方法もありますが、用途で使い分ける感

じかなと。

 

　眉毛、まつ毛は独立したメッシュにRGBAなテクスチャ

ーを適応するわけですが、まつ毛はペアレントで動くので

いいとして眉毛はメッシュ連動で動く（ので、その場所の

メッシュに対応したフェイシャルリグとかで動かすと調整

しやすい）のですが、これについては表示腕いろいろ動き

ます。その為、【　どういう動きをさせるのか？　】で

変わってくるものになります。

 

　ポリゴン数を抑える場合、それが登場するか否かで使い

方が割るのですが、板ポリゴンを分割させて、形状を作り、

RGBAなメッシュで適応する方法もあります。

 

　とりあえず、表情がない物の場合、

 

　■　顔のモデルは一体化成形

　■　大半はテクスチャー

 

で処理したほうがポリゴン数は削減できます。

 

　ポリゴンの使う場合、四角形のそれを使いますが、筒状

のモノの最小構成はハニカムなので、六つの頂点のそれで

形状を作る事になります。たとえば、

 

　■　目

　■　口

 

ですが、これは長方形や正方形ではなくハニカムを横方向

に長くしてから加工したほうが作りやすいですし腕や足や

指も六角形のほうが融通が利きます。

 

　その為、意外とメッシュが嵩んでくるわけですが、ロー

ポリの場合だと、作る物と作らない物があります。

 

　例えば、

 

【　特定のひな型を作っておいて、それを組み合わせ

　　てキャラを量産するモブモブ大作戦的な何か　】

 

という、モブキャラ制作でバリエーション増やしたい場合

の選択肢でモンタージュ的に物を組み合わせて何かする

ような状態だと、これは、グローブやガントレットを付け

てるキャラでも素手の選択肢があるので、これは衣装を

着れる最小限の構成にする必要があります。

 

　しかし、それがない場合は、

 

　■　モデル＋衣装

 

では、ポリゴン数が物凄いことになるのと、貫通するので

 

　■　一体化成形をする

 

と言うれとげー的な手法も出てきます。この場合、内部が中

空なモデルと同じになりますが、シームを付けてテクスチャ

ーを塗ると作業がしやすくなります。

 

　また、この手の状態も

 

　【　手の演技や握りの違いなのど表現の有無　】

 

で内容が変わるのですが、そうしたモノがない場合、関節を

間引く事が出来ますし、ボーンの構造も

 

　■　手の甲

　■　指4本

　■　親指

 

まで間引けます。この条件でいうと、ガントレットとかと同じ

になるわけですが、指の微細な表現が発生する場合だと、Rig

fyで用意されたようなリグを入れて作業するような流れになり

ます。

 

　そうなると、鎧＋ガントレットと言う衣装だと、指のパー

ツの必要はないのでガントレットのみのモデリングでいいと

言う事になりますし、足にしてｍお素足の表現がない場合

だと、靴の生成でいいと言う事になります。

 

　つまり、当たり前に作る場合には、手足も含めて全て作っ

て衣装を着けてそれに連動するように調整すると言う流れに

なるのですが、衣装を着せると貫通するリスクが出てくるの

で、貫通する部分を削除して一体化してリグを配置し、オー

トウェイト調整からのIKの追加などの作業になるのですが、

極度のローポリの場合だと、その形状を少ないメッシュで

作ったほうがいいように思います。

 

　つまり、衣装や層部や服装の入れ替えがある場合だと一

体化成形をしてしまうと指などがないモデルになるので、

厳しい状態になりますから、用途でモデリングの仕方が

変わってきます。

 

---

極度のローポリの場合

---

 

　テクスチャー機能でいくつか制約を受ける事になるの

ですが、その一つに、

 

【　ディスプレイメントマップが使えない　】

 

と言うな要があります。これは、ハイポリメッシュを、

Sculptのように変形させる機能なんですが、これが全く

使えません。

 

　あと、【　減らすほどにエッジが立って来る　】ので

初代のバーチャファイターみたいになってきます。

 

　基本的に【　エッジを丸める　】と言うのも可能です

が、これも極度な期待はしないほうがいいので、気持ち

丸くなっている程度の状態になります。

 

　また、ボーンについても関節部分は分割が必要になる

ので、塊のような構造物ではボーンが適正に動かないの

で、そうした部分での分割数は自然に増える傾向があり

ます。

 

 

 

 

 

 

 

 

■ ゲーム関連の本

　相当昔に出版されていた本ですが、

 

 

というのがあります。とりあえず、これは、ゲームボーイアドバン

スをIoTデバイスとして考えた場合におけるアセンブリプログラミ

ングの学習本なんですが、ゲームボーイアドバンスというのが、

ARM A7+Z80カスタムなのでそういう使い方を考えたものになっ

ています。

 

　基本的にgccコンパイルでCのソースコードからアセンブリの

ソースを作り、アセンブラから解析編集ツールを使って実行ファ

イルにすると言う流れを付属のKnoppixで行うと言う仕様のMO

OKになっています。

 

　そう、安定と信頼のレトロハード御用達のアセンブラの登場

です。

 

　基本的に、このゲームハードは

 

【　プロセッサ　】

　　■　ARM7 TDMIメインプロセッサ

　　■　カスタムZ80サブプロセッサ

　

　　■　内部RAM　　　：　32KB

　　■　外部メモリー　：　256KB

 

　　■　R　O　M　　　：　16KB

　　

 

【　ビデオ　】 

　　■　VRAM　 　　：　96KB

　　■　パレット　　：　1KB　

　　■　スプレイト　：　1KB

 

　（＊）LCDパネル（240x160）に接続　　

 

【　サウンド　】

　　（＊）ボリューム・スピーカー・ヘッドフォンジャック

　　　　　に接続

 

【　シリアルコントローラー　】

　　（＊）通信ポートに接続

 

【　キーコントローラー　】

　　（＊）各ボタンに対応

 

【　ゲームIO　】

　　（＊）ゲームパックと相互通信

 

と言う仕様になっています。とりあえず、C++のコードを打ち

込みそれをターミナルでgccでコンパイルするとa.outが出来る

流れがありますが、その処理をKnoppixで行う事になります。

 

　この本では、GBAの外部メモリー256KBにUSBでアクセスし

て、表示系を弄ってみましょうと言う内容の本なので、当然の

ように特許切れのレトロハードを特殊にもほどがある使い方を

する何かで、実機を使う物になっています。

 

　ここで面白いことが書かれているのですが、アセンブラレベ

ルで作業する場合には、メモリーアドレスやレジスタについて

は必須な知識として調べる必要があるのですが、ARMは実に面

白い構造で、【　メモリー空間問IO空間が共存しているので、

メモリーを読み画する感じで/Oを操作する事が出来る　】よう

です（Memory Mappd I/O）。

 

　また、ASIC（Application Specific Integrated Cirduit）が

実装さえているので、液晶・サウンド・キーなどの操作をレジス

タを通じで操作が可能になっています。

 

　現在のゲームエンジンで何かがつっくれる作ってみよう系の本

と比較すると、恐ろしく敷居が高いのですが、とりあえず、ネッ

トからアセンブラとリンカのダウンロードから始まり、セットア

ップをし、いきなり安定と信頼のＭＯＶ命令から始まります。

 

　とりあえず、【　扱い方の学習は出来るが、何も知らない人

間に解るような代物ではない　】という事をまざまざと教えて

くれる良書となっています。ｗ

 

　とりあえず、アセンブラなんド絵打ち込む文字数はものすごく

短い物で、それが数ページにわたって何か書かれているのですが、

流石に低級言語でハードウェア寄りのものである為、低級言語の

ように人類の言語に近いので字面から何か解るようなレベルの内

容になってはいません。ｗ

 

　まぁ、スペックを見れば、RasberryPI 3などのようにはいかな

いのは当然なですが、安定と信頼のアセンブリを使う事になる何か

だと言うのは理解できます。

 

　こうした開発ですが、ファミコンなども同様にアセンブリでない

と無理なのでレトロハードはそんな感じなんですが、とりあえず、

ファミコン辺りからステップアップしたほうが幸せなのではないだ

ろうか？と思うくらい結構ハードルが高い本になっています。

 

　まぁ、試して覚えて物を作っていく何かなので、アセンブラの関連

テキストは必要であるのは確かですが、ハードエアの構造などを知る

うえでは面白い一冊になっています。

　

■ 3Dのゲームエンジン

 

　基本的に、3DCADと3DCGは違うのですが、ゲー無制作

環境と3DCADも全く異なる構成のようで、ゲームエンジン

の仕様を見ると、3DCGをする構成とは少し異なる仕様に

なっています。

 

 

---

3Dゲームエンジン

---

　Blenderは結構動いてくれるけど、Unityはダメだったと言う内容が

あるので、これはあからさまに構成が違うのかなぁ？と言う気がしな

くもないのですが、基本的に

 

【　3Dのモデリング　】

　　〇　GL性能が高いコト

　　〇　倍精度浮動小数点演算お性能が高いコト

 

なので、CUDAでレンダリングを行うときに選ぶGeforce GTXとは

方向性が全く違う訳ですが、VRAMが多い物を選ぶのも含めてグラボ

の選択が決まってる気がします。あと、　

 

　【　Sculptはメモリーが多くないと無理　】

 

なので、16GB以上のメモリーは必須になります。これは、デジ絵

でも同じなんですが、最近はこうしたメモリー実装量が効く処理が

増えています。

 

　とりあえず、3DCGにおいては、そんな感じなので、

 

　UnityのようにGL表記が存在せず、Direct 3D系の事しか書か

れていない場合だと、構成がゲーミングデスクトップ寄りになる

ので、モデリングをするものとは少し構成が変わってくる可能性

があるような気がします。ゲーミング構成だとZ-Brush+Unity

とかでsRGBのカバー率の高いパネルを付けて、液タブか板タブ

で作業すると言う構成になりそうですがゲームエンジンと、制作

環境で求める仕様が異なる場合があるので注意が必要です。

 

　とりあえず、GLESやGLで使っているGLSLとDirect 3Dで使っ

ているHLSLは違うのですが、HLSLの関係か、コンシューマの

ボードの指定がUnityではしてあります。GLの表記がないので、

その優位性で考えるとゲーミングになると言う流れなので、Ble

nderが遅くなりそうな気がしますが、そうした仕様になってい

ます。

 

　ゲームエンジンの仕様ですが、

 

　■　Unreal Engine

　　https://docs.unrealengine.com/latest/JPN/

　　GettingStarted/RecommendedSpecification

　　s/index.html

 

　　　

 が現実味のあるスペックなので、これよりも速いマシンを用意す

る事になりますが、共通して、HLSLの関係からか、Direct 3D対

応のボードの指定がされています。

 

　Unityは謎まみれですが、とりあえず、他の仕様はこれに合わせ

て、それ以上にすると問題はないのでは？と思います。

 

　こうした内容から、ゲームングデスクトップ構成でグラボ強めで

メモリーを増やした何かと言う構成がスタンダートな仕様になりそ

うです。

 

　その為、通常の３D統合環境で求めるスペックとは異質なものに

なるので、作業で全く異なるスペックのモノを選ぶことになるよう

な気がします。

 

　以前、ゲームエンジンを動かす場合に、低いスペックでもゲー

ムは作れるが３Dは無理と書いたように、処理自体がスプライトと

ポリゴンでは全く違うので3Dで当たり前にバーテックスの変化が

発生するオブジェクトを動かす場合には、それに必要なマシンス

ペックを用意する事になります。

　

　なので、CryEngine 3の推奨スペックに合わせてPentiumとか

を導入すると結構絶望的な状態になるので注意が必要です。

 

　あと、こうした作業には、AtomやCore Mの選択は入りませ

ん。ｗ

 

 

■ コンテンツのつくりと仕様

　ゲームを作る場合、過去と今では出来る事が相当変わってい

る訳ですが、その中に存在する一つのものとして

 

　■　ネットワーク

　■　ストレージ

 

の存在は大きいのではないだろうか？と思います。まず、

ネットワークですが、これにより、プレイヤー数と、処理

におけるリソースがクライアント単独からそうでないクラ

ウドやサーバサイドスクリプトへとシフトするので、相当

内容が変わってきます。つまり、対戦格闘ゲームをすると

してもプレイヤーの絶対数が異なると言う内容が一つと、

ソシャゲやMMOGPGのようにプレイヤーの相対数が多く、

個人単体であとはPCと言う構造物とは異なる世界の構築

などもその一つです。こうした内容ですが、思考ルーチン

とボードゲームを遊ぶようなイメージで動くSLGとネット

ワーク型SLGの根本的な違いとも言えますが、そうした

プレイヤーという【　思考ルーチンが居の存在　】が動

く物が作れる利点がります。これは、ROMのみでモノが

動いている時代だと存在しない概念です。

 

　そして、もう一つはストレージです。これはアップデー

トファイルでゲームのコンテンツを増やせる選択肢ですが、

一度クリアしたら終わりにあならない仕組みとしてソシャ

ゲなどが導入しているスタイルとも言えます。

 

　ストレージの利点は、

 

【　システム改編で大型アップデートを入れても

　　対応できる　】

 

辺りなんですが、結果的に、こうした点は、レトゲーでは

全く行えないない仕様になります。

 

　こうした内容を考慮すると、インフラクチャーの変化で

出来る事が増えたとも言えます。

 

---

ローカル駆動のゲームの場合

---

 

　ネットと言うとネットワークの事ですから、これに

は二種類あり

 

【　LAN　】

　　ホームネットワークのような外部と遮断された

　　機材同士のネットワーク

 

【　WAN　】

　　インターネットのような広域ネットワーク

 

があります。ゲーム機だと、

 

　【　wifiのアドホックモード　】

 

のように機材間通信がありますが（と言うか、最近はカメラ

とスマホをつないで、シャッターリモコンのように利用でき

る時代になりましたが。）これとインターネットは別物です。

 

　つまり、WANの場合だと、ISPと何かしらの契約が必要で

個人だとベストエフォート方式の特定の回線を使う事になる

訳ですが、その場合の選択が、SIMを使ったLTEや3Gだった

り、固定回線の光だったりするわけです。まぁ、この中には

端末を媒介して通信するテザリングもありますが、とりあえ

ず、WANを使う場合の選択肢はそうなります。

 

　個人が、サーバ彩度スクリプトの学習やサーバアプリケー

ション系をテストする場合にいきなりギャランティー契約を

して、安全性の担保が出来ていない状態でサーバを動かすと

言う【　野生に返すか、ボイジャー１号の専属修理人として

後でも追わせたほうが人類ンの為になりそうなふるまいをす

るわけがない　】ので、

 

【　通常は、LANを組みサーバマシンとクライアントを

　　用意してテストをする　】

 

訳ですが、NetBeansやEcripsのフルバージョンやNT系の

OSを入れるともれなくついてくるサーバソフト系のモノを

使わなくてもLANは組めます。

 

　つまり、サーバを使ったネトゲ系の仕様なのか、もしくは

複数のマシンがリソース共有して動く何かで内容が異なるの

ですが、屋内におけるLANであれば、自宅に、ルーターと、

ネットワークケーブルを用意すれば当たり前に利用可能に

なります。

 

　その為、ネットワークを組むだけだと、DOSカーネル時代

からできている事なので、大昔からできている事なんですが

LANとWANでは内容が全く異なります。

 

　とりあえず、ネットゲームと言うのは、WANを指すもので

あり、ネットワーク＝インターネットと言うバーバリアンの

ような間違い（時に、自称：コンピューターが解る系の無知

がこの手のウ間違いを無知な人間お舞で吹聴しているので注

意が必要です。）と現実では全く違います。

 

　とりあえず、ローカルで動くの場合だと、

 

【　通常はスタンドアローンな端末で、オフライン駆動　】

 

と言う条件になります。つまり、昔のゲーム機はオフライン

専用機材だったと言えます。

 

　ただし...。PS3やXbox 360辺りでもNICは実装していま

したが、

 

【　Xbox 360　】

　　WINDOWSメディアプレイヤーのサーバ機能で

 　　ストリーミングに対応

　　　（XPでも対応のコーディックは少ない物の

　　　　ストリーミングは可能）

 

【　PS3　】

　　■　DNLA（WMPのストリーミングもサポート）

　　■　DTCP-IP（ルームジャンプなどの機能に対応）

 

などがありましたが、これはLANなので、ローカルネッ

トワーク上での非インターネット環境で使える機能にな

ります。

 

　つまり、サーバクライアントシステムというのもロー

カルで組めば当たり甘えに機能すると言う至極当然な内

容がそれになります。（WINDOWS HomeSeverとか、

MediaTombとかでサーバを作れば、DNLAが使えるの

と同じです。）

 

　となると、現在ンおPCでゲームを作る場合、マシン

が二台あると仮定した場合サーバクライアントシステ

ムを用いたゲーム開発も可能という事になります。

 

　とりあえず、ローカル環境で動くものとはいいがた

いですが、【　選択肢にそれも包含される　】訳です。

 

---

スタンドアローンのマシンで動くゲーム

---

 

　通常のアプリケーションはこれなので、近年のスマ

ホアプリのようにネットに繋がってないと動かないと

言うほうが　【　特殊　】なんですが、個人がモノを

作る場合にコーディングにせよ、ゲームエンジンを使

うにせよ、最初に作るのは、

 

　■　オフライン

　■　プレイヤー数１

　■　何かが動くもの

 

になります。つまり、通常はこれになるのですが、その

仕様においても、れとげーのような要領の制約がないので

出来る事は相当多くなっています。

 

　とりあえず、30秒位待つような仕様だと容量の多いゲー

ム（単一プロジェクト）も機能するわけですが、仕様がど

んな感じかで内容が変わってきます。

 

　その為、大容量や多くのっポリゴン数は使えますが、

 

【　ハードウェアとしてどの辺りが上限だろうか？　】

 

に気をかける必要が出てきます。この辺りは、ドット絵

のゲームだとそういう問題が出にくい状態になってきて

いるのですが、3DゲームでPC環境となると、マシンス

ペックで出来る事が異なるので、

 

【　3万円位のローエンドマシンでゲームとなると

　　相当制約を受ける　】

 

事になります。その為、環境を添うてした作りになって

くる訳です。

 

　ちなみに、ネットブックやネットトップだと、処理能

力の上限が

 

【　QVGAでドット絵のゲームを想定するイメージ　】

 

なので相当ひどいのですが、ここまで酷くないにしても

プレステやセガサターンレベルのポリゴン数で解像度上

げるような状態になるような構成もあるんド絵、古いマ

シンだと3Dに全く向かない物があります。

 

　その為、どの辺りの事をどんな感じで処理させる物

なのかで出来る事が変わってくるので注意が必要です。

 

　ただ、ストレージ容量が多い場合には容量の制約は

出にくいですし、ポリゴン数をハードウェアに合わせ

た場合、リダクションの必要が出てきますから、それ

ほど巨大な容量にはならないはずなので、作る上での

成約は少ない物の、動くものの範囲と言うのは上限が

あり、読み込み時間との兼ね合いも考えて作っていく

必要性が出てきます。

 

　その為、

 

　【　ハードの仕様とお見込み時間のバランスで

　　　考えてゲームの仕様を策定する　】

 

と個人が手持ちのマシンでゲームを作る上で不快指

数の低い物を作る事が可能になる訳です。

 

　ゲームエンジンは重たいのでコーディングのよう

にはいかないですから、結果的に重たいもので作業

するとやはり制約が出てくるんド絵出来る事は少し

控え間になります。

 

---

基本的にスプライト方式のレトゲーは軽い

---

　これは、ゲームのつくり方の話になりますが、画

像と言うのはIDEを使った場合、NetBeansとかだと

ラベル（フル版を入れると、GUIの追加がプロジェ

クト内で当たり前に出来ます。）で、VisualStudio

だとピクチャーボックスをそのまま読み込めるのです

が、スプライト処理系のゲームと言うのは基本的にこ

れの座標変化になります。

 

　つまり、

 

【　浮動小数点演算をするとしても1キャラで

　　存在する座標変動は２軸　】

 

です。そう考えると、1つのキャラを想定した場合に浮動

小数点演算が

 

　■　キャラのアクション

　■　キャラの座標変動

 

で発生し、バーテックスの数だけ制御が入る何かと2D

ではやってる内容が全く違う訳です。

 

　例えば、正方形が平行四辺形になるとします。この場

合、メッシュは一つですが、座標変動は移動する二つの

バーテックスで存在していますから、個別の座標変動に

なります。

 

　これは平行四辺形ですから、X軸単独の移動ですが、

SVGのような平面画像ではないので、このバーテックス

には　（　X , Y , Z　）　の3つの座標軸が存在します。

 

　つまり、この移動が発生した場合、それぞれの処理が

生まれます。とりあえず、立方体と言うのは、8つのバー

テックスの構造物になりますが、これの座標変動条件は

前述の3軸で、処理でいうと

 

【　4つの個別のバーテックスの処理になる　】

 

訳です。そうなると、仮にバーテックス一つをスプライ

トと同じだと仮定した場合、その座標移動における推移

の演算も軸一つ分ほど多いという事になります。

 

　そうなると、移動だけの考えで想定しても重さが違

います。また、

 

　【　ポリゴンはバーテックスの構造物　】

 

なので、X/OBJ/DXFのような三角形ポリゴンの場合だと

3点で、Colladaなどのように4点のものもありますが、

 

【　キャラクターモーション生成時のボーンの調整で

　　発生した形状変化と言うのは、バーテックスの座

　　標変動　】

 

ですから、その推移の分だけ演算が発生します。

 

　そうなると、スプライトだと何枚分の表示になるだ

ろうか？という事になります。ｗ

 

　これが、キャラクターモーション尾段階で発生する

バーテックスの変化で、BGEだとアクションで呼び出

す項目での状況変化です。

 

　しかし、ゲームエンジンだとキャラを入れなくても

座標変動は出来ますが、この時に

 

　【　オブジェクトの持つローカル座標　】

 

問う物が登場します。つまり、これがスプライトの座標

移動相当のモノになります。しかし、これは三軸での移

動なので、やはり処理はスプライトよりも多いです。

 

　これに、UV展開をしたテクスチャーマップを適応する

ので、テクスチャー情報分の重さと、

 

　■　GLSL（Open-GL/GLES）

　■　HLSL（Direct3Dなど）

 

によるシェーディングの効果などが入るので、テクスチ

ャー情報＋板ポリゴンでの二軸移動相当のそれと、3DC

Gのモデルを使ったゲーム制作では、リアルタイムで演

算している処理数が全く違うので比較するほうがどうか

しているレベルで異なる訳です。

 

　とりあえず、ストZEROは動くが、ストαは動かないと

か、FFVは動くがFFVIIは動かないというのは処理が全く

異なり、リアルタイムで行われている演算の絶対数が比

較にならないほど多いからです。

 

　その為、この辺りから崩壊していると問題があるので

すが、【　崩壊した状態で間違いを吹聴するのが時に居

るので注意が必要　】です。

 

　そうした内容から、平面のゲームは軽いと言う条件が存

在するため、アニメーション処理をしているものでも比較

的推奨スペックの低い物が存在していると言う訳です。

 

　うしろ、こうした場合、HLSLは使わないので、GPUの

仕様は相当低いはずです。

 

　つまり、物を作る上において、その処理が何を使うのか

で選択が変わってくるのですが、平面お処理だとGPUの負

荷はあまり考えなくてもいいので3Dゲームのような化け物

じみた物を用意しなくてはならないと言う状態には至りま

せん。

 

　ただし、ノベルゲームで動かす場合に、解像度が高くな

るとその分重あくなるので、マシンスペック的にどの辺り

が最適なのか？や処理的にどの辺りで処理させるのかを考

える必要が出てきます。

 

---

実行環境と素材制作環境はハイスペックになる

---

 

　この辺りは、注意したいところですが、

 

【　実行環境がどの辺りなのか？　】

 

でマシンスペックは大きく変わります。例えば、セガサター

ンレベルの事を今行おうと思ってその時代のポリゴンゲーム

を作ったとします。この場合、多くの環境で軽いと感じるは

ずです。なぜなら

 

　【　毎秒処理するポリゴン数が恐ろしく少ない　】

 

からです。つまり、Unityが重いと言っても、この辺りのキャ

ラクターモデルだとそうでもありませんし、BGEも同様です。

 

　これがXbox 360やPS3クラスになると作業時に求めるマシ

ンスペックが高くなっていきます。当然、これは、Core i7の

マシンかXEONのマシンでそれ相応の構成になります。

 

 　これと同様に、素材制作というのも、実行環境よりも高い物

 になるので注意が必要です。例えば、現在のノベルゲームのエ

ンジンで当たり前に使える【　720pのゲーム　】を想定したと

します。これで【　えもふり　】や【　Live2D　】を使った場

合、

 

【　1280x720の画像制作よりも圧倒的に重たい処理になる　】

 

ので内容が変わります。あと、画像制作その物が720pだから

その解像度で描くと言う選択肢は存在しない （この方法だと、

キャラや風景が画面上のサイズでスクロールするようなシーン

が作れないので、それ以上の作業が出来る環境でないとどうし

ようもない）ので、

 

【　そのゲームの実行環境よりもハイスペックになる　】

 

訳です。と言っても静止画でいうと、4K解像度位だと大抵の

環境で描ける時代になっているので、その枚数を描く作業が

大変と言う話になりますが、 

 

【　ゲームの動作環境と制作環境は全く違う　】

 

と言う条件があります。これはポリゴンになると更にハイ

スペックなモノが必要になるので、そうした構成になって

いきます。

 

　あと、音に関しても再生とミキシングは処理が違うので、

素材制作と再生環境は別物であることをあらかじめ知って

おく必要があります。 

 

　というのも、【　DCIの映像は16bitのソースとかで撮ら

れたのを4Kや2kにしてる状態があり、それをBDにして流通

させているが、その再生が出来る端末は多いけれど、再生が

可能な性能しかない端末で制作時のソースが扱えるわけがな

い　】 のと同じです。時に、野生に返る準備が出来ており、

年を取るほどに会話が通じなくなり、文明解脱の成果によっ

て、明々後日な事まで口にし始めるのが居ますが、あれは

作る気以前に文明を捨てており、大自然の摂理によって野生

に強制送還される系統ですから、既に、物を作る事を尋ねる

ような固有種でも生命体でもありません。ｗ

 

　とりあえず、そうした条件から、目的の仕様のゲームを作

る上での

 

　■　素材の仕様に合った物を作れるマシンスペック

　■　仕様に合った物を作る上でのゲームエンジンを

　　　動かすためのスペック 

 

のモノを用意して、　

 

　■　テスト環境

 

とセットでそろえる事になります。音に関しても収録がどんなの

で何を使うのかで変わってきますが、CDDA音質を使う場合でも

大抵の場合、ミックスダウンしてある（24bit/192KHzとかそれ

以上の音源で作ったのをCDDAの16bit/44.1KHzに落としてミキ

シングしている）ので、音質を求める場合にはやはりそれ相応の

ハードウェアが必要になってきます。

 

---

マシンスペック的に軽い物

---

　基本的に、上記の内容から、

 

　■　平面は軽い

 

訳ですが、個人が平たく動いてくれそうなゲームエンジンを

探すとすれば、

 

　■　AVG及びノベルゲームエンジン

　■　ドット絵の2Dエンジン

 

などになります。あとは、コーディング必須ですが、

 

　■　Cocos2DXのようなもの

　■　HTML5系のブラウザゲームようのもの

　■　DXラリブラリで平面処理で作る

 

などになるような気がします。3Dの場合だと、ポリゴン数を

多くしたい場合にはスペックが高くなるんド絵、その辺りは

考えて物を選ぶ必要があります。

 

---

関連機材

---

　とりあえず、コストをかけれる人は別の選択になりますが、

とりあえず、そうした作業で発生するものと、個人が作る事を

想定した状態でのその機材でも書いておこうかなと、

 

【　2Dの場合　】

 

　　ドット絵ゲームの場合だとドット絵を描くのでマウス

　　でもいいのですが、こうしたゲームの場合、

 

　　　■　カットイン

　　　■　キャラクターグラフィック

 

　　とかが入ります。この画像ですが、実は128x128以上

　　になるとデジ絵を描く感じで大き目のモノに描いて、

　　リサイズしたほうが綺麗に出る（ので256x256の場合

　　個人だとそうしてみてください。ドットよりもいい感

　　じになるかもしれません。ちなみに、MAC OSXのア

　 　イコンの1024x1024は間違いなく、4Kx4Kでガッツ

　　リと描い手リサイズしたほうがいいです。）ので、

 

　　【　PCの場合　】

 

　　　　■　板タブ（練習が必要ですが。）

　　　　■　液タブ（これも慣れが必要です。）

 

　　などが必要になります。とりあえず、タブレット端末

　　がある場合

 

　　　【　メディアバンペイントをインストールして、

　　　　　解像度の高いキャンバスで描いてリサイズ

　　　　　して持っていく　】

 

　　と言う選択肢があります。あと、立ち絵とかで大き目な

　　モノだと、アナログで描いてデジタルにする場合ですが、

 

　　　■　原稿をコピー紙に描く

　　　■　ボールペンで線画仕上げる

　　　■　スキャナーで取り込む

　　　■　コントラスト上げてゴミ取り

 

　　で後は着色と言う方法もあります。これですが、

 

　　【　乗算すると黒は黒なので色が変わらない　】

 

　　ので

　

　　【　モノクロ原稿＠線画の着色って、最上位

　　　　に原稿をもって行って、その下に透過レ

　　　　イヤーを配置して、セルが塗るみたいに

　　　　色別のレイヤーを置いていくとフツーに

　　　　仕上がる　】

 

　　と言う傾向があります。こうした部分ですが現在の

　　ペイント系ソフトは

 

 　　【　開いていてもその範囲で塗る　】

 

　　とか、メディアバンペイントみたいに

 

　　　【　下絵の指定船を境界と認識して塗る　】

 

　　とか出来るので、MSペイントとか昔のツールみたいな

　　酷さがありません。

 

　　とりあえず、

 

　　　■　板タブ＋ＰＣ　

　　　■　駅タブ＋ＰＣ

　　　■　お絵かき可能タブレットPC

　　　■　タブレット端末＋筆圧感知スタイラス

　　　■　アナログ→カラー複合機＠フィーダー

 

　　などの選択肢があります。あと、スキャナーアプリで

　　取り込んで補正して仕上げると言う方法もあります。

 

　　とりあえず、ノベルゲーム系の場合レイヤーを多く使え

　　るツールとそれが動くスペックおマシンは用意しておい

　　たほうがいいです。

 

【　2D/3D共通　】

 

　　これは、音のモニタリングです。この場合、

 

　　　■　オーディオインターフェース

　　　■　モニターヘッドフォン

 

　　を用意すれば大丈夫と言えます。SEや音楽を音源で作

　　る場合だと録音工程がないので、こうした組み合わせで

　　対応出来る気がします。この場合、CuadCapture辺り

　　がよさそうな気がしますが、予算に応じて物を選ぶ感じ

　　で、ヘッドフォンだと2万弱の当たり前のがあるといい

　　かなと思います。音素材ですが、こうしたモノを作る場

　　合録音が入りますが、

 

　　　ノイズは入らあない場合だと、DTM用のオーディオ

　　インターフェースと当たり前のコンデンサマイクとかで

　　録音したほうがきれいなんですが、川のせせらぎや自然

　　の音が欲しいので撮ってくるでそれを持ち出すのも気が

　　引けるのでそうした場合には、ポータブル製品で音質が

　　高めなものを選ぶと言う選択肢もあります。

　

　　そして、周囲の雑音を入れたくない場合には単一指向性

　　で収録すると、マイクの先の音に集中した素材が収録で

　　きるので周囲の音が混ざるとかいう、酷い機材で盗聴や

　　ってる怪しげなホモとゴリラの交錯した謎のストーカー

　　辺りの妙な知識と現実では全く違います。

 

　　素材の場合、フリー素材で対応できるのか、用意するか

　　で変わってきますが、モニター環境は定位能登沖の音の

　　違いがリスニング用ではわからない部分まで解るので、

　　ここは抑えておきたいところです。

 

【　モニター　】

　　基本的に設定できるのと表示できると言うのでは全く違

　　うので注意が必要ですが、ゲーミングＰＣのような構成

 　　とワークステーションでは全く違うんド絵その違いを書

　　いておきます。

 

　　　■　コンシューマの構成　Geforce/Radeon/IGP

　　　　　〇　8bit RGB

　　　　　　　（YCbCrは全く違うので注意）

 

　　　　　〇　sRGBのみに対応

 

　　　　　〇　Direct 3Dに特化

 

　　　　　〇　倍精度浮動小数点演算の性能が低い

　　　　　　　（なので、3DCADなどの制作に向かない）

 

　　　■　ワークステーション用の構成　Quadro/Fire Pro

　　　　　〇　10bit RGB

　　　　　　　（YCbCrは全く違うので注意）

 

　　　　　〇　Adobe RGBに対応

　　　　　　　（REC.709/CNYK/sRGBをカバー） 

 

　　　　　〇　Open-GLに特化

 

　　　　　〇　倍精度浮動小数点演算の性能が高い

　　　　　　　（ので制作に向いている）

 

　　　と言う違いがあります。とりあえず、印刷物とかだと後者

　　　とAdobe RGBのモニターでCMYKに合わせて使う感じにな

　　　りますが、これはカバーしているモノが広いので、Lutを合

　　　わせてキャリブレーションすれば、ソレになるとも言えます。

 

　　　　基本的に、sRGBの色空間しか出ないボードではsRGBカ

　　　バー率の高いモニターを入れたほうがよく、QuadroやFire

　　　Proを入れたほうがよくなります。

 

　　　　sRGBしか出ない物でAdobe RGBのカバー率の高い物を

　　　　繋いでも無理がある（そもそも色域が狭い物が出る訳がな

　　　　く、出ていない色があるだけならいざ知らず、色そのもの

　　　　がずれているので使い物にならない。）ので、その間違い

　　　　を【　現世背を捨ててコンゴ川北部の密林い変える予定で

　　　　もあるかのように推奨してる末期な無能が居るが、その内

　　　　容はその固有種の生物的な在り方と同じレベルで間違い　】

　　　　なので、当たり前の選択をしましょう。

 

　　　　つまり、WEB用の某だと、表示はsRGB準拠なので、

 

　　　　　　■　ゲーミングＰＣ

　　　　　　■　sRGBカバー率の高いプロ用モニター

 

　　　　になるのですが、これが印刷とかRAW現像になると3Dを

　　　　使わないとしても

 

　　　　　　■　ワークステーションか、そうした用のボード

　 　　　　　　実装ＰＣ

　　　　　　■　Adobe RGBカバー率の高いモニター

 

　　　　になります。（つまり、印刷をするだけでもIGP＋ビジネス

　　　　モニターと言う選択肢はありません。ｗ）　

 

　　　その為、理想を言えばそうですが、基本的にモニターとその組

　　　み合わせがあるという事を理解しておくといいかなと。あと、

　　　WEBやゲームの場合sRGB準拠の場合が多いのでsRGB用の構

 　　　成でも御大丈夫なんですが、ソレに印刷が入るとなると、大

　　　は小を兼ねるの出、後者のワークステーション用のボードで

　　　色空間を使い分ける事になるような気がします。

 

とりあえず、ビジュアルとかの素材や資料として何か撮る場合にカメラ

があるといいような気もします。