「ゴブリンでもわかるゲームプログラミング」第２６話 ～読むだけでゲームプログラミングがなんとなくわかるようになる謎のファンタジー小説～
本作は連載作品です。第１話は下記です。
気に入っていただけたら↓に「スキ」いただけると嬉しいです。
（……なんかなー、スプリンクラーみたいな感じに出せたらいいのになぁー）
ユキはふと、前世にあった散水機のことを思い出す。
装置を中心に３～４方向に対して、回転するように水を撒くものだ。
（スプリンクラーって、なんかついついぼーっと眺めちゃうんだよなー。でも……あれを真似するためには……今、知ってるパラメータだけじゃできない）
スプリンクラーの水の動きを真似するには、ユキが今、解読できている初期値設定だけでは、実現できない点があった。
それは〝複数同時発射〟である。
スプリンクラーは３～４方向に対して、同時に水を放出している。
だが、現在、ユキが解読できている範囲では、弾は等間隔で１つずつ出すような仕組みになっており、複数同時発射はできなかった。
（うーむ……ちょっと骨が折れるけど……少し、解析してみるか……）
ユキは意を決して、魔法論理の解析に着手した。
まずはユキがこれまで触ってきた処理を改めて確認する。
////////////////////////////////////////////
// 弾の初期化処理
time = 1200 // 射出時間
interval = 60 // 射出間隔
angle = 360 / 10 * count / 60 // 射出角度
position = device.position //射出位置
size = 0.5 // 大きさ
power = 0.1 // 威力
if(count % 120 == 0){
attribute = ICE // 属性＝氷
}
else{
attribute = WIND // 属性＝風
}
speed = 0.1 // 速度
acceleration = 0 // 加速度
・・・
////////////////////////////////////////////
これが今まで、散々、改造してきた初期化処理である。
これだけでも結構、魔法をアレンジすることはできた。
（今まではここまでしか解析できなかったけど、きっと今ならもっと詳細を解析できるんじゃないかな……）
ユキの解析能力も初期に比べると、成長していた。
実際、冷蔵庫の開発過程においては実行宣言なしでの自動走行を成功させるなど、それまではできなかった……いや、できないと思っていたことも成し遂げられたのだ。
（よし……！ 気合入れて頑張るぞ……！）
まず、ユキはこの初期化処理の大元となっている要素がないかを探してみることにした。
（恐らく……このパラメータも何かしらの〝クラス〟の中のパラメータなんじゃないかな……）
ユキはプログラミングにおいて、かなり重要な要素である〝クラス〟の存在が魔法論理にも実装されていることは、ほぼほぼ確信していた。
なぜなら、そのすでにその存在を暗示するコードに遭遇していたからだ。
例えば、下記が代表例だ。
////////////////////////////////////////////
position = device.position //射出位置
////////////////////////////////////////////
この射出位置を設定するコードの右の値
device.positionはデバイス（device）の位置（position）を表しているわけだが、
これはつまり位置（position）という要素を持つ、上位の存在であるデバイス（device）が定義されていることを暗示していた。
ユキが初めて魔法論理を読み取ることができた時、すでにコードの中にdevice.positionは使用されていた。
ゆえに、変数名から、きっとデバイス（device）の位置（position）を表しているのだろうと〝予想〟して、これまで使ってきており、実際にそうであったわけだが、実はこのデバイス（device）の中身が具体的にどういう構成になっているのかについては、今まで解析してこなかったのだ。
だが、ユキは前世のプログラミングの経験から、なんとなくきっとこのような魔法論理をしているのだろうという予想をしていた。
それが、下記のような魔法論理である。
////////////////////////////////////////////
class Device{
position // 位置
angle // 角度
// 以下、ひょっとすると、こんなのがあるんじゃないかと予想される要素
count // カウンター
temperature // 温度
など
}
////////////////////////////////////////////
このように、クラス(class)では、
デバイス（Device）の中に、必要な要素である
・位置（position）
・角度（angle）
などを集約している。
そうすることで、
それぞれの要素をバラバラに扱うよりも、分かりやすくなるのである。
これがクラス(class)の定義の初歩的な考え方だ。
更に、クラス(class)のもう一つの特徴は、処理（メソッド）を持つことができることだ。
例えば、このようなイメージだ。
////////////////////////////////////////////
class Device{
// 要素の定義
position // 位置
angle // 角度
count // カウンター
temperature // 温度
// 処理（メソッド）の定義
// カウンターの初期化処理（メソッド）
init_count(){
count = 0 // カウンターを0で初期化する
}
}
////////////////////////////////////////////
上記の例のinit_count()がクラス(class)における処理（メソッド）である。
つまり、
クラス(class)とは、特定のモノに対して、
そのモノが所持している〝要素〟と〝処理（メソッド）〟をひとまとめにできる便利な仕組みである。
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
【プログラミング豆知識】
以前、
device.positionのように、
左の値．右の値
というように、〝．〟でつなぐ場合、
左の値〝の〟右の値
user.execute_magic()のように右側に()が付くと、意味が変わり、
左の値が右の処理をする
という意味になると説明しましたが、その理由がまさにこれです。
クラスの内部にある〝要素〟や〝処理（メソッド）〟を使うために用いるのが．です。
クラスには〝要素〟と〝処理（メソッド）〟があり、処理には()が付くため、上記のように意味が変化します。
（なぜ処理（メソッド）には、()が付くのかについては、別の機会に説明しますが、まずはそういうものだと思っていただければと思います）
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
このクラス(class)という仕組みがあることを前提に考えると、
ユキは、ある一つの仮説を立てることができた。
それは、今まで、ユキが変更していた魔法論理が、特定のクラスの処理（メソッド）の一部なのではないか？ ということである。
確信はない……だが、きっとそうであると信じたならば、ユキにできることは集中して魔法論理を感じ取ることだけだ。
＝＝＝＝＝＝＝
【あとがき】
ついにclassの登場です。classは、昨今のプログラミングでは、けっこう重要な考え方なので、是非ご参考に。
でも〝要素〟と〝処理（メソッド）〟があるって、〝ステータス〟と〝技〟があるゲームのキャラになんとなく似てますよね。
この記事が気に入ったらサポートをしてみませんか？