■ 物の考え方

　先日、7つのLEDを

 

のように配置し、それを点灯させて0-9までのパターンを点灯

させる場合に、LED彩度での信号の受信に着目したほうが、条

件判定の記述を簡素にできると言うのを書きました。

 

　とりあえず、この桁数を増やした場合はどうしようか？と言

う内容などを考えると、処理がまた変わってくるわけですが、

そうした場合に、どういう着眼点でモノを考えていくとソー

スコードに無駄がなくなるかを考える事が出来ます。

 

　とりあえず、こうしたものが、BGEのコンピューターですら

ない8bitとか4bitのマイコンで処理するのと、IoTの製品で処

理するのでは全く異なるのですが、基本ｔ期に外部デバイスを

使った表示を考えた場合、こうしたものは潤沢なストレージ容

量やメモリー実装量は存在しませんから、効率的にコードを書

く必要があります。こうした内容は、処理能力の低いマシンを

使ってモノを行う場合に、処理を遅くしないための工夫でもあ

るのですが、先日書いた内容は、設計段階で何をしたらいいの

か？を考えるときに行い内容になります。

 

　先日も少し触れましたが、前回のは、7つの発行体の配列で

すが、これが、8x8の64となった場合どうだろうか？という事

になります。つまり、発光体は

【　点灯なし　】

 

【　全てが点灯　】

　

 

の二つ上納権威なります。ちなみに、ここまでドット数が多いと、

既に、1バイト文字が表示できる事になります。これは、マトリッ

クスディスプレイとかがソレになりますが、その解像度では電光

掲示板のように文字を表示できると言う訳です。

 

　本来はこうしたやり方をしないのですが、パターンと情報解析

によるそれで考えてみましょう。

 

　まず、誰でも思いつくパターンを無視した対応のさせ方だと、

 

　　■　50音

　　■　アルファベット

　　■　記号

 

に対して、そのドットで全て対応する方法です。この場合、実装

関数が存在して、帯出してフォントが使える条件だといいのです

が、そうでない場合には、これは使えません。つまり、従来だと

前回の配列ではなく、こうした場合にはキャラクターコードを使

って酔いだした配列を点灯させる（IoTでマトリックスディスプレ

イを購入して、電気工作をしてから光らせる場合にはそうした処理

になります。）わけですが、そうでない場合の方法を考えてみまし

ょう。

 

　まず、8x8の発行体ですから、前回同様にパターン化が出来な

いかを考えてみます。そうすると、

 

　0000 0000 ~ 1111 1111

 

で推移する事になりますから、これは、16進数の処理でシフトし

ている事が解ります。つまり、00～FFです。ちなみに、16新数で

すが、

 

　【　８　】【　４　】【　２　】【　１　】

　　　１　　　　１　　　　１　　　　１

 

となっているので、1001の9までが数字で、それ以降はA~Fで

表記されます。こうして見てみると、2進数の数値変換と言うの

は解りやすいと思います。当然、これも配置があるので、

 

　【　０　】　００００

　【　１　】　０００１

　【　２　】　００１０

　【　３　】　００１１

　【　４　】　０１００

　【　５　】　０１０１

　【　６　】　０１１０

　【　７　】　０１１１

　【　８　】　１０００

　【　９　】　１００１

　【　Ａ　】　１０１０

　【　Ｂ　】　１０１１

　【　Ｃ　】　１１００

　【　Ｄ　】　１１０１

　【　Ｅ　】　１１１０

　【　Ｆ　】　１１１１

 

こうして見てみると、それぞれに法則性があり、その発光の

条件を満たせば、その個別モジュールを利用できます。

 

　そうなると、この条件の発行体を

 

　　■　横ｘ２

　　■　縦ｘ８

 

で並べた構造物と考えると解りやすくなります。上記の条件の

物を条件抽出で出した場合、4つのLEDの条件は構築できます。

つまり、発光する条件の構築なので、今度はデータ側でそれを

用意する事になります。

 

　例えば、2ドットを使った縦棒だと

 

　18,18,18,18,18,18,18,18

 

で、2ドットを使った横棒だと

 

　00,00,00,FF,FF,00,00,00

 

と言う感じです。縦一本のラインだと、

 

　80,40,20,10,08,04,02,01

 

で一行の中のいずれかのドットが選択できるので、

それが8つ並ぶだけとなります。横列の罫線は、FF

の位置がどこにあるのか？と言う話になります。

 

　楯列ですが、連続という事になると、forループ

で8貝繰り返せばいいのだはないだろうか？という

事になりますが、そうした呼び出しを連続の配列

の場合だと用意しておけば、固定されたものの場

合には使いやすくなります。

 

　こう考えると、ドットパターンがどういう状態

であるのか？をそれそぞれ指定しておき、それを

登録し、呼び出せば各列の処理が可能になると言

えます。

 

　とりあえず、外周を覆う枠を作る場合だと

 

FF

81

81

81

81

81

81

FF

 

で完成し、これをL文字のする場合には

 

80

80

80

80

80

80

80

FF

 

となり、逆にする場合だと

 

01

01

01

01

01

01

01

FF

 

となります。こうしたドットのデータを個別の検知し

て読み込ませれば、8x8のパターンだと問題がないと言

う事になります。

 

　こうして見てみると、前回の7つのLEDの配列の場合、

 

【　キャラクター数　】

　　０～９までの10種

 

【　LED　】　　

　　7つ

 

【　配列における組み合わせ　】

　　最大で7の階乗

 

 

ですが、この場合、

 

【　キャラクター数　】

　　64の階乗で表現できるすべての配列

　　

【　LED　】

　　8列ｘ8行の64

 

【　配列における組み合わせ　】

　　最大で64の階乗

 

ですから、処理が複雑にのあるのも自然な内容と

言えます。

 

　配列パターンを定義しｔえ、それを呼び出せるような

仕組みを最初に作っておいた場合、呼び出しにおける条

件は、こうした処理を考えずに行える訳ですが、基本的

に【　こうした64のLEDそれぞれに登録キャラクターご

との点灯パターンをひとつづつ指定するのは処理として

厳しい　】（つまり、□だと各LEDに点灯か否かの命令

をぶーリアン型でそれぞれ出すような処理だと厳しく、

文字数分だけそれをするのは無理がある）ので、配列

で処理できるものを用意して、16までの配列の中で効

率的な処理方法を考えるというほうが処理がしやすくな

ります。

 

　16新数位がの考え方だと、

 

【　１　】　奇数で点灯

【　２　】　2,4,6,7,A,B,E,Fで点灯

【　４　】　2~7,D~Fで点灯

【　８　】　8以降で点灯

 

となります。つまり、8の点灯条件は

 

　【　８　】　I>=8

 

になり、奇数店頭の場合、10進数変換で

 

　【　１　】I/2><0

 

範囲選択は、ORではなくANDで可能なので

 

　【　４　】　I=>2　AND　I<=7

　　　　　　　I=>D　AND　I<=F

 

となります。 

　

　そう考えると、それが構造物として配列している

問う考え方をすると、変わりやすくなります。

 

　これを一行にして、オンとオフにした状態のモノ

が自動織り機の二進数制御の機材なんですが、処理

の仕方にもいろいろあります。

+

■ 表示と内部処理

　実質的に人の認知すべき状態と内部処理で一致しな

ければならない処理は存在しますが、その状態の処理

は人の認知と同じかと言うとそうでもない場合があり

ます。

 

　基本的に、処理には

 

【　変数として存在し、人が見てそれと一致してなく

　　てはならない物　】

 

と【　そうではない処理　】が存在します。例えば、LED

が7つ揃った文字盤で数字を表示する場合、

 

　■　LEDの表示処理

　　　ブーリアン型（0と1）

 

　■　処理する対象物の数

　　　7つ

 

となります。とりあえず、その場合ですが、人の目から見た

場合に

 

【　10新数表記に見える事　】

 

と言う条件が付くと

 

　■　入力値

　　　０~9

 

　■　メモリーに格納する数値

　　　０~9

 

となります。つまり、この時

 

 

　■　入力とメモリーに格納する数値は同じ　

　■　入力と表示される数値は同じ

 

と言う条件が付きます。この条件から、命題によって

 

　■　メモリーに格納される数値と表示は同じ

 

とも言える訳ですが、この三者の関係性は担保される必

要があります。

 

　しかし、処理を考える場合にその店頭をどう考えたら

いいだろうか？というので複数の思考方法が出てきます。

 

とりあえず、

 

 

な感じのものがあったとして、

 

 

 

との表示が可能な訳ですが、この状態で考えると構造的には

 

　【　その値がメモリーに格納された場合、その対象の

　　　LEGを発光させる　】

 

と言う条件で片付くので、それぞれの数値に、パターンを記録

させておき、処理する方法をとれば大丈夫という事になります。

 

　配線がつながってる場合だと考え方が少し違うので、プログ

ラムとして考えた場合、

 

　■　入力用の数値を格納する変数

 

を用意して、0-9までの数値を入力できるようにします。

 

　ただ、これだけだと数値を入力した処理だけなので、これに

対して

 

【　各LEDに番号をつけ、それに対しての信号を制御する　】

 

と考えると、処理の方法が見えてきます。とりあえず、

 

　　　　【　２　】　

【　１　】　　　【　３　】

　　　　【　４　】

【　５　】　　　【　６　】

　　　　【　７　】

 

と言う風に考えた場合、

１：3,6

２：2,3,4,5,7

３：2,3,4,6,7

４：1,3,4,6

５：1,2,4,6,7

６：1,2,4,5,6,7

７：2,3,6

８：1,2,3,4,5,6,7

９：1,2,3,4,6,7

０：1,2,3,4,6,7

 

と言う条件になります。つまり。この条件に真のパルス

を送信し、送信しない場合には、反応なしにしておけば、

上記の条件が成立します。

 

　では、もう少し考え方を変えてみて、発行体側で判断

してみると

 

１：456890

　　（1,2,3以外）

２：23567890

　　（1,4以外）

３：12347890

　　（5以外）

４：23456890

　　（2,7以外）

５：268

　　（上記の条件）

６：134567890

　　（2以外）

７：2356890

　　（1,4以外）　

 

となります。つまり、メモリー格納の数値基準である

場合、

 

【　入力された変数に対して、8つのセンサーの

　　複数に対し処理を行うプログラム　】

 

になるので、処理系が複数発生します。

 

　つまり、変数をi、LEDをa1～a7と仮定すると、

 

　IF i=8 

 　a1=True

 　a2=True

 　a3=True

 　a4=True

 　a5=True

 　a6=True

 　a7=True

 

のような処理です。それを1~8まで書く感じです。これだと

フツーに誰でも思いつく方法ですよね。

 

　では、LED側を主体に考えてみると、

　

　if i<>5

　a3=True

　if i<>2

　a6=True

 

のような条件です。複数ある場合は、

 　

　if i<>1 or i<>4

　a2=True

 

のような感じです。上記の変数基準のもので考えると、

 

---

　■　処理の対比

---

 

【　変数を基準にした場合　】　

（８～０まで）

 

　IF i=8 

 　a1=True

 　a2=True

 　a3=True

 　a4=True

 　a5=True

 　a6=True

 　a7=True

 

 

　IF i=9

 　a1=True

 　a2=True

 　a3=True

 　a4=True

 　a5=Fauls

 　a6=True

 　a7=True

 

　IF i=0

 　a1=True

 　a2=True

 　a3=True

 　a4=Fauls

 　a5=True

 　a6=True

 　a7=True

 

　　

【　LEDを基準にした場合、　】

 

　　if  i<>1 or i<>2 or i<>3

　　a1=Ture

 

　　if  i<>1 or i<>4

　　a2=Ture

 

　　if  i<>5

　　a3=Ture

 

　　if  i<>2 or i<>7

　　a4=Ture

　　if  i=2 or i=6 or i=8

　　a5=Ture

 

　　if  i<>2

　　a6=Ture

 

　　if  i<>1 or i<>4

　　a7=Ture

 

---

 

のように圧倒的に簡素になります。 仮に

　var i=0;

　var a1=Fauls;

　var a2=Fauls;

　　　：

 

 

と言う感じで、宣言して、同じように処理をするとしても、

ソースコードが入力した数値を主体としたものなのか、そ

れとも処理の対象側から見たもので考えるのかでソースコー

ドの状態が変わってきます。

 

　同じ処理をしてるのに、ソースコードが全く違う事があ

るというのは、視点の違いだったり考え方の違いなんです

が、変数を前提としてパターンを割り当てると、その状態

に合わせたパターンを用意してそれを随時処理する状態に

なる訳ですが、0-7までのモノがパターンで発光すると言う

条件で、その発行パターンが存在する場合、そこに法則性

があれば、発行の有無において、少なくなる条件が必ず

出てきます。つまり、その真逆の条件がそれが実行される

内容なので、少ないほうの戻り値を参照して、その逆の

条件で機能するようにすれば、短いソースコードで処理が

できるわけです。

 

　無駄に複雑にしようと思うと、これを３列で考え

 

 

右　00/01/10/11の配列

　　（16進数0-3）

中　000/001/010/011/100/101/110/111の配列

　　（16進数0-7）

左　00/01/10/11の配列

　　（16進数0-3）

 

 

で、000-373で制御するとかもありますが、これを縦で

00000-13131で管理する事もできます。（というか、

そこまでくると既に暗号ですが...。ｗ）

 

　ただ、処理系で考えると非効率なので、この場合、パ

ターンで非表示を基準にしたほうが条件式が簡素になり

処理も複雑にならないので処理をする上でもソースコー

ドを簡素にできるわけです。

 

 

　通常の考え方だと、人の意認知の場合、こうした配列

は経験則から、積み木・ブロック・パズルなどのように

 

【　形状をそれに合わせる　】

 

 と言う【　図画工作的な発想　】が先に来るので、最初

の答えに行き着く人は多いのですが、少し視点を変えると

 

【　パターンからもっと簡素な処理が可能場合がある　】

 

と言う事が見つかる事もあります。

 

　

　プログラミングをする場合、無駄な処理を省く作業は

発生しますが、手抜きでは物は動きませんから、モノの

見方考え方で、どうすればそれが効率的に動くだろうか？

や、【　無駄な処理をしていないだろうか？　】を考え

る事になるのですが、こうした考え方もプログラミング

をする場合、おのずと必要になってくるような気がしま

す。

 

とりあえず、ソースコード度が短くなっていますが、手

抜きではなく同じ処理をする場合における着眼点御違い

であり、パターン解析をすれば、そうした傾向がある為、

その条件から、処理を少なくしても条件が満たされる内

容を判断すれば上記のような条件式でLEDの発光を実現

出来る訳です。

 

　こうした処理がもう少し複雑な事をしてるので、この

辺りの処理が複合的に鳴っただけで無理が来る場合、効

率化というものが解らない場合があるわけですが、基本

的にどういう条件で何が動くのかを考えるのがプログラ

ミングで身につく能力なので、そうした思考も養われて

いくように思います。

 

　ちなみに、BGEだとこの処理はロジックエディタで処

理する事になるのですが、前者の変数の値を基準にした

場合、一つのセンサー（0-9までの９つのセンサーが存

在する）でANDにつないで、1-7のオブジェクトの色を

変える処理を入れる事になるのですが、後者の場合、

 

【　それぞれのオブジェクトで、変数参照を行い

　　数値の条件以外だと色を変える処理をする　】

 

と言うものになります。つまり、センサー入力が複数

でアクチュエイターは一つのみになります。

 

　つまり、先ほどのa1=Trueのような処理と言うの

は、アクチュエイターの処理ですから、条件式の数

値の種類が、センサーの数になります。そうなると、

 

【　複数のセンサーをorで繋いで、一つのアクチュ

　　エイターで処理する構造　】

 

になります。つまり、一つのセンサーで７つのアク

チュエイターを処理するのと比較すれば簡素な仕組み

にできます。

 

　処理をする場合に、【　何がどう動くのか？　】

というのを判断して物を考える事になるのですが、今

回の事例のように

 

【　確実に決まった法則性（今回のは、異なる条件に

　　なりようがないですが。）がある場合だと法則性

　　を利用して、処理方法を考える　】

 

と言う手法もあります。まぁ、打算的に法則性を口にす

る人間と言う尾は、複雑系辺りに法則性があると言う野

生に返る準備をしてるような固有種ですから相手にする

とロクなことにならないのですが、簡素なモノで見ると、

パターン解析と、そこから考えられる処理方法の最適化

は効果があるのが解ると思います。ｗ

 

　これが8x8のLEDのグリッドになると、表示できるも

のが増えてきますが、これも法則性がある場合、8x8の

64のドットのそれで処理をする方法も扱えますが、

 

【　16進数で1行ずつその01の数値を指定した

　　モノを用意してそれを、個別のLEDの値と

　　して読ませたほうが効率的　】

 

なので、処理が複雑になると前述の方法だと無理が来る

ので、異なるアプローチを用いる事になります。当然、

これがピクセル数の多い画像とかになると、全く異な

る処理をすることになります。

 

■ 見える処理と見えない処理

　ソフトウェアと言うのはユーザーが何かをすることで

機能するもの及び、目的が、そうしたユーザーが何かを

するための物である場合と、バッチ処理などのように自

動で動くものがあります。

 

　そして、見えている状態で判断するそれと、実際に動

かす場合の処理が異なる場合があります。

 

　とりあえず、人が操作する条件が存在する物における

操作と処理の際について少し触れておこうかなと思いま

す。

 

　まず。単純な、数値を入力してそれの演算子が出る

特定のの数式を自動処理で行う物を想定した場合、人の

作業は入力のみで、演算子を出す場合において、その

処理をボタンで出すと仮定すると、

 

【　人の作業　】

　　■　数値の入力

　　■　ボタンのクリック

 

になります。では、この時のプログラムは何をしている

のか？というと、

　

　■　入力待ち

　（　数値の入力がされる　）

　■　入力された数値をメモリーに格納

　■　ボタンのクリックによる処理待ち

　（ボタンのクリック）

　■　演算処理

　■　演算結果の表示

 

になります。簡素な処理でも人の操作と内部処理では

全く異なる物が必要だという事が理解できると思いま

す。

　

　こうした処理ですが、HTMLのマウスアクションでも

同じで、カーソルの状態でも変わってきます。

 

　マウスと言うと

 

　■　OnClick

　■　mouseover

　■　MouseOut

 

の処理がありますが、最初のが、クリックによる処理で

マウスが特定のオブジェクトに重なった場合とそれから

外れた場合の処理がそれになります。

 

　つまり、

 

【　マウスが重なると何かのアクションが発生し、ク

　　リックで別のイベントが起きるような構造物の場

　　合、操作をしてる人から見た場合、二つの処理し

　　か起きていない用のに見える物の実際には、Mou

　　seOverイベントとま別にMoseOffのイベントを

　　用意してそれ以外の通常時の処理も必要　】

 

になります。

 

　JavaScriptでWEBページをコントロールするような場

合で、リアクション御身を用意する場合、ここに変数は

存在しませんから、そのまま処理しますが、ゲームなど

の場合、数値の変動が発生します。

 

　例えば、RPGなどで、エンカウントをする場合、プレイ

ヤーにはいつエンカウントをするのかと言うタイミングは

全くわかりませんが、その処理は存在しています。

 

　つまり、キー判定でキャラが動いているわけですが、こ

の時にエンカウント判定と言うプレイヤーに解らない変数

が存在し、それの判定を行っています。

　

　つまり、見えている処理と挙動以外の変数の処理が行わ

れているので、プログラムの場合、見えているモノのみと

言う訳ではありません。

 

　これが、RPGの場合、

 

　■　シナリオ上で存在するフラグ

　■　特定の処理をした時の判定

 

においても変数による判定が存在するため、結果的に、キャ

ラの操作とは全く違う処理が当たり前に存在するわけです。

　

　その為、

 

　【　プレイヤーの操作系以外の処理を設計段階で

　　　　用意する必要がある　】

 

事になります。

 

　変数を使うような内容を少し考えてみると、ゲームにおけ

る戦闘シーンなどで考えてみると、キー操作と座標変動だけ

ではどうしようもない物があります。

 

　例えば、戦闘中のメニュー操作ですが、これは、

 

　■　シンプルな縦移動のメニュー

　■　アイコンが移動するスタイル

 

などがありますが、この場合の、アイコンと命令の処理と言う

のは、どういう相関関係であれば処理できるでしょうか？

 

　この場合、カーソル移動だけでは条件判定は出来ません。

 

　そうした場合、選択する対象を変数化し、その条件で条件

判定をする方法があります。

 

　例えば、

 

　■　物理

　■　魔法

　■　道具

　■　逃げる

 

の選択肢があったとします。この場合、1-4までの数値を選択す

る条件年、その操作に対して、数値変動をレ遠景させるようにす

れば、代入を行う条件は完成します。

 

　１　物理

　２　魔法

　３　道具

　４　逃げる

 

　変数への数値の代入の条件をボタンのアクション及びキー操作

と連動させた場合、カーソル移動中という数値選択時には、変数

は初期値のカーソルの位置に合わせた1になります。

 

　つまり、その条件で、仮にaと言う変数を用意して、1-4の数値

を代入するようにしたとします。それ以降の挙動の選択を、この

変数参照にするわけです。そうなると

 

 

【　ナビゲーションのコントロール用の処理　】

【　変数処理　】

 

の粗油法を用意し、それを動かすことになります。つまり、コマン

ドを選んで、実行すると別のアクションが起きると言うのは、完全

に条件式ですが、内容的にはSelectCaseのようなものになります。

 

　つまり、縦に並んだメニューの場合、カーソルのコントロールは

縦の座標移動のみになります。

 

　ゲームエンジンではコリジョン判定で接触をさせると言う条件や

マウス主体のナビゲーションの場合、処理が異なるのですが、そう

ではなく、キー操作やコントローラーの操作の場合、変数で制御し

なければ、その移動した条件とその見えている、プレイヤーの条件

と、処理におけるその状態の際の検知が出来ません。

 

　こうした場合、何かしらの変数参照をしてそれを対象にしていく必

要が出てきます。そうした変数を使わない場合、座標の数値を利用

するなどの方法もあるのですが、管理しにくいので、変数制御をした

ほうが効率的だと言えます。

 

　コーディングでモノを作る場合、当たり前ですが、コリジョンと言

う概念が使えない場合が多いので、接触判定ではなく、そうしたモ

ノは、変数で処理する事になります。つまり、上記の条件だと、この状態で

 

 

【　メニュー呼び出し　】

【　メニュー選択　】

　　　■　選択１　

　　　■　選択２

　　　■　選択３

　　　■　選択４

 

 

と言う条件分岐が発生します。つまり、処理の前の段階で

こうしたモノが出来上がります。つまり、これをテキスト

で動かすのか、もっしくは、円形のＵＩを表示させて、回

転させるか、表示を変更させるかなどのUIデザインの違い

が発生する場合、処理をする上でラジアンを使う事になっ

たり、変数に該当する条件判定で、表示を変更するなどの

の表示のコントロールをすることも可能になります。しか

し、こうした処理方法は個別に設定されているとしてもプ

レイヤーからは見えません。

　　

　そして、先頭に関しての挙動も、どう要った振る舞いに

するのか？で変わってきますが、これがドラクエのような

ものだと、素手を前提にすると、

 

　■　敵へのダメージの計算

　■　攻撃時のアニメーション

　■　敵HP-ダメージ

　■　自分へのダメージ計算

　■　攻撃時のアニメーション

　■　自分のHP-ダメージ

 

と言う処理が発生します。しかし、これは1度ループしたの

ちにコマンド選択になります。

 

　つまり、【　ターンの概念を入れておく　】必要があるの

でこれも変数で処理させたほうが都合がよくなります。

 

　とちあえず、その条件で処理が変わるわけですが、文字の

表記と演算処理ン尾差異だと、魔法と物理の差は参照するパ

ラメーターと表記の違いになります。

 

　逃げる場合はパラメーター参照＋乱数で処理させるとして、

条件判定をするとして、その判定での文字の表記と、判定に

よって、先頭の終了処理を入れる事になります。

 

　アイテムの場合には、ウインドウを表示させる必要がある

為、それは異なる訳ですが、最初の三つと異なり、

 

【　アイテムの選択　】

 

が発生します。つまり、これもメニューの構成がどうなっ

ているかで変わるわけですが、多くの場合、画像表記にし

てもテキスト表記にしてもリスト型になっています。その

為、ここでも、戦闘メニューの選択のような処理が発生し

ます。

 

　当然、これは、変数の設定がアイテム単位になるので、

通常はデータべ－スで管理して処理する事になります。つ

まり、【　アイテム名：数量　】と言う型式のモノを複数

管理することになるので、この場合、データベースと同様

に

 

１：アイテム名：数量

２：アイテム名：数量

 

のように、番号管理をすることになります。これをどうレイ

アウトするのか？も含めて考える事になります。

 

　つまり、アイテム数で管理する事で、選択においての状況

変化を与える事が可能になります。

 

　以前書きましたが、このアイテムの変数をIとした場合、

 

　”名称”＋　i　＋"png"

 

などで画像を呼び出せますが、画像をアイテムとの関連付けを

する場合にはそうした手法を使う事もできます。

 

　とりあえず、戦闘シーンにおいて文字だけで処理するにして

も、アイテムの項目があれば、別途メニューのＵＩと処理を考

える必要があります。

 

　つまり、戦闘シーンにおいて、キャラクターモーションなど

を追加して処理をする場合には、別途、そのモーションの呼び

出しをする必要性が出てきます。つまり、物理にしても魔法に

しても、その発生処理の後の振る舞いを構築する必要性が出て

きます。

 

　この戦闘シーンと言うのが、メインのマップ上での処理とは

異なる処理ですから、エンカウント処理の後のものとなります。

 

　つまり、そうしたシステムを作る必要性があるのですが、こ

うした処理もバックグラウンドでの処理は、プレイヤー側では

見えて居ません。

 

　数値の増減ですが、変数の推移と同じなんですが、これは外

部のデータベースや変数の山を用意してそれを変更して調整す

る事になる訳ですが、これはメニュー処理よりも多くの数値の

処理が発生します。つまり、この場合、用意したアイテム数分

だけ選択が発生します。

 

　これと類似するのが、魔法の数を複数増やした場合や、魔道と

統僧侶系で異なる呪文形態を作った場合になります。

 

　つまり、属性で種類を増やした場合、アイテムの処理と同様に

データベースで管理する事になります。

 

　しかし、アイテムにしても前述の魔法にしても、LVと言う変数

で覚えている魔法に差があったり、所有していないアイテムは表

示されないなどの処理が入ります。そうなると、

 

　■　数値による表示の変更

　■　選択する変数の上限の変更

 

などが発生します。テキスト表記の場合でもこうした処理が発生

しますが、アイテム管理システムや魔法管理システムと言うのは

ゲームで異なりますが、ディアブロのようなアイテムグリッドが

存在しており、アイテムのサイズがあり、配置の方法がそのサイ

ズに見合わない場合のは配置不能などの仕様だとこの場合、何も

ない場所とアイテムの配置された場所の検知の必要が出てきます。

そのうえで0の条件でその形状が埋まると言う内容が成立した場

合のみ配置可能になるので、SLGなどの移動範囲のような解析が

必要になります。

 

　しあｋし、その条件判定処理については、ゲーム中にプレイヤー

では何をしてるのか全く分かりませんが、それを用意しないと機能

はしません。

 

　こうしたリスト処理と、データの管理については、RPGやSLG

では恐ろしい量になるので、単独の変数で用意すするのではな

くデータベースを制作して、データ参照で処理する事になります。

 

　内容ですが、武器の装備とパラメーター変化や、表示の変更な

ども変数参照をすれば、管理しやすくなります。

 

　その為、マップ移動遺体の処理のキャラクターのパラメーター

と戦闘とアイテム管理などに関してもプレイヤーが見えてない部

分での処理が存在しています。

 

　そうした呼び出しも内部のグローバル変数やローカル変数の呼

び出しとは異なる処理で大丈夫な変数の絶対数が少ない物だと異

なるのですが、データベース参照だと処理が少し変わってきます。

 

　基本的にゲームの部分的な部分だけを見ても見える処理とそう

でない部分がっ存在しています。

 

 

 

 

 

 

 

 

 

■ ARM

　ゲームボーイアドバンスはARM7とカスタムＺ８０の構成

なんですが、ARM関連のアセンブラの情報は公式に存在して

います。

 

　■　ARM：Realview Compilation Tools

　　　アセンブラガイド　ver.4.0

　　　http://infocenter.arm.com/help/index.jsp?topic=

　　　/com.arm.doc.dui0204ij/Cegbgefe.html

 

 

■ インテルのPDF

　昨日、アセンブラ関連の本を紹介したのですが、技術仕様

については、IA32のものがIntelから開発ガイドがPDFで得ら

れるのでそれを参照するとプロセッサの事が解ります。

 

 ■　IA-32 インテル® アーキテクチャ •ソフトウェア

　　• デベロッパーズ •マニュアル(日本語)

　　上巻：基本アーキテクチャ インテル

　　http://www.intel.co.jp/content/dam/www/public/ijkk

　　/jp/ja/documents/developer/IA32_Arh_Dev_Man_Vol

　　1_Online_i.pdf

  

　

　■　IA-32 インテル® アーキテクチャ •ソフトウェア

　　　• デベロッパーズ •マニュアル(日本語)

　　　中巻：命令セット・リファレンス(A-M) インテル

　　　http://www.intel.co.jp/content/dam/www/public/ijkk

　　　/jp/ja/documents/developer/IA32_Arh_Dev_Man_Vol

　　　2A_i.pdf

 

 

 

　■　IA-32 インテル® アーキテクチャ •ソフトウェア

　　　• デベロッパーズ •マニュアル(日本語)

　　　中巻：命令セット・リファレンス(N-Z) インテル

　　　http://www.intel.co.jp/content/dam/www/public/ijkk

　　　/jp/ja/documents/developer/IA32_Arh_Dev_Man_Vol

　　　B_i.pdf

 

 

　■　IA-32 インテル® アーキテクチャ •ソフトウェア

　　　• デベロッパーズ •マニュアル(日本語)

　　　下巻：システム・プログラミング・ガイド インテル

 　　　http://www.intel.co.jp/content/dam/www/public/ijkk

 　　　/jp/ja/documents/developer/IA32_Arh_Dev_Man_Vo

 　　　l3_i.pdf