株式会社ヘキサドライブ | HEXADRIVE

こんにちは

 

先日、アップル社からApple Watchの開発キットである「WatchKit」が 公開されました。

iPhoneを持っている方が必ず持っている訳では無い という特性は考慮しないと

いけませんが、iPhoneとの連携を使って、 ゲームにするならどんな事が出来るか、

考えるとワクワクします

 

シュンスケです。

 

近頃はおかげ様でプログラマ以外のスタッフが充実してきて、この日記 の内容も様々な

ものになってきましたので、たまにはプログラマらしく、 プログラムに関する事でも書いて

みようと思います。

というわけで、今回は設計の話です

 

ゲーム開発を進める上で、重要視することは開発のフェーズで変わっては きますが、

長い目で見てバグを出しにくい、仕様変更に耐えやすいという 事を重視する方向で、

いつも念頭に置いている事を紹介します。 (※あくまで個人の見解です。)

 

・コピペしたら疑え！(師匠からの教え)

　　同じロジックを2度書かない、車輪を再開発しない為の注意喚起です。

　　同じことをしているのに様々なところでそれぞれ似たロジックを

　　書いていると、そのロジックに対する修正が必要なときに対応が

　　漏れてしまったりします。そんな事が無いように、切り分けて使い

　　回せるようにします。ただし、同じように見えても、たまたまその

　　時は同じになっているだけで、意味として別な事があるので、その

　　見極めは必要です。それによって、部分的な修正の影響が広範囲に

　　及ぶ事を防ぐことが出来ます。

 

・レイヤーを意識する

　　主にオブジェクト指向言語においてですが、ある処理があった時、

　　その処理を行うべきなのは誰なのかを常に意識します。

　　それによって、小さな単位の機能をなるべく独立した状態で作りつつ、

　　その組み合わせによって大きな流れを作る事に繋がります。

　　処理が独立している分、修正が楽になったり、チェック範囲も明確に

　　なります。

 

・数の変化への依存度

　　何か種別の数が増えるたびに、その増えたものに対する処理を記述しな

　　ければならない形だと、数が変わるたびに作業が必要になってしまいます。

　　可変長もしくは、環境次第では固定長でも長さを定数にして、最小の

　　修正で数の変化に耐えられるようにします。

　　ただし、個々の処理がユニークで、何かが増えた場合にそれに対する処理

　　さえ書けば良いという状態にすることで、拡張しやすくする事もあります

　　ので、実装内容に応じた判断が必要です。

 

・スコープのバランス

　　レイヤーとも似ていますが、始まりと終わりを明確にし、処理の

　　担当範囲の中で各々の動きを担保することで、独立した処理に分離

　　しやすくなります。

　　また、プロパティやメソッドのアクセス範囲は基本必要なもののみを

　　公開し、他との結びつきを最小にします。ただし、機能のレイヤー次第では、

　　拡張しやすいことや、使いやすいことを重視するために、多めに公開する

　　事が有効な場合もありますので、バランスが大切です。

 

・リソースとロジックの分離

　　デザイナさんとの連携が必要な部分では、多少冗長でも、各々で

　　作業が進められる事が大切になってきます。

 

・ありえないとは言えない

　　ある変数を元に処理を行う際に、これでもかというほど細やかな

　　エラーチェックを行うくらいで調度良いです。

　　それによって、デバッグ期間等、開発終盤での不具合原因究明速度に

　　効いてきます。

 

いかがでしたでしょうか。

プログラムの良い作りの果てには、修正や拡張が楽になり、それによって

クオリティアップに多くの時間が使えるようになるという効果があるわけです。

私もまだまだ勉強中の身ですが、将来ゲームのプログラマを目指している方など、

少しでも何かの足しになれば幸いです