「ソー シャルゲームの作り方」というテーマで、５回に分けてお話ししています。
※↑↑
いいね！ボタンを押していただければとってもうれしいです。
今回（第３回め）のテーマは
「PHP
実装のポイント」と、「データベース設計での留意点」
です。
PHP実装のポイント
☆注意した点
１：判定について
NULL,0,FALSEは
「==」では判定対象辺がいずれかの値であれば全て正となります。
※別々の判定を行うためには「===」を必ず使用します。
また、「empty()」
では上記の3つは全て正となります。
２：特殊なライブラリ（PECLな
ど）を使用する場合には
インストールが必要な旨を必ず記録、サーバ構築担当者に連絡します。（忘れずに）
３：かなり適当にプログラム書いても動いてしまうので
些細なエラーログでも多めに出力するようにします。
※
「NULL」とは？
プログ
ラミングで、変数に対して値がまったくない状態や、どのアドレスも指していない
ポインターの値を意味します。
※「FALSE」
とは？
UNIX系のオペレーティングシステムにおいて、常に終了コード「1」を返
すコマンドです。
※「empty()」とは？
ＰＨＰの関数で、引数で指定された変数の値を検査します。
変数に何もセットされていない場合には「false」を、値が空だった場合には「true」を
返します。
※「ライブラリ」
とは？
汎用性の高い複数のプログラムを、再利用可能な形でひとま
とまりにしたものです。
※
「PECL」
とは？
PECL（ピクル、PHP Extension Community
Library）は、PHPで利用できる拡張ライブラリ
（パッケージ）を提供しているサービスです。
☆工夫した点
１：Intvalで、速度向上
データベースから取得したデータは基本的に、文字列として扱われるので、
速度向上のため、数値計算などはなるべくintval()な
どを使い、数値化した上で
行うようにしました。
２：ＳimpleTestで効率化
SimpleTestが
インストールされていたのでそれを利用。
これにより、変更が容易になり、後に発生したゲームのマップ追加にともなう作業も
簡単に行うことができました。
※
「intval()」とは？
PHPの関数で、変数の整数としての値を取得します。
※ 「SimpleTest」 とは？
ユニットテストを行うためのライブラリです。ユニットテストを行うメソッドに対してテスト
ケースという、
テスト内容を記述したクラスを作成することで、テストを実行します。
☆PHPアクセラレータの利用（必須）
１：APC eAccelerator
などを利用し高速化を図りました。
２：運用上の問題（更新反映等）は
ソース配信管理に使用していたCapistranoの
ロジック上で限定Sudo権
限で
アパッチを自動でリスタートし、アクセラレートキャッシュ
（PHPにおけるコンパイル済みスクリプトキャッシュ）を消去していました。
※
「APC」とは？
PHP:_Hypertext_Preprocessor のモジュールの一つの Alternative
PHP Cacheの略。
PHPの実行コードをキャッシュ（高速化）します。
※
「eAccelelator」とは？
コンパイルされたPHPスクリプトを保存し、PHPスクリプトに変化がなければ保存された
ものから実行してやろうというもので、つまり毎回コンパイルする必要がなくなるので
PHPが高速に実行できるという仕組みです。
※「Capistrano」
とは？
複数の環境に同じ処理を同時に実行させるソフト
※
「Sudo」とは？
UNIXおよびUnix系オペレーティングシステムのプログラムの1つで、
ユーザーが別のユーザー（通常、スーパーユーザーすなわち
root）の特権レベルで
プログラムを実行するためのコマンドです。
※「アパッチ」とは？
人気の高いWebサーバソフトウェアの一つ。1995年にNCSA
httpd 1.3をベースに開発が始まり、
UNIX系OSを中心に幅広い人気を獲得した。Apacheはフリーソフトウェアとして無償で公開され、
世界中のボランティアのプログラマたちの手によって長年に渡って開発が続けられています。
※「コンパイル」とは？
プログラミング言語を用いて作成したソフトウェアの設計図(ソースコード)
を、
コンピュータ上で実行可能な形式(オブジェクトコード)に
変換することです。
データベース設計での留意点
１：
データの配置
ユーザデータについて個別に扱われるデータと他ユーザデータと連携して扱われる
データについて、配置を考慮して設計を行いました。
（データベース分け、テーブル分けを行うのか。行った場合に何らかの問題が出ないか等）
２：
膨大なデータはテーブル分けする
登録されるデータの種類とそれが運用されたときの最大数を見積もり、
膨大な量となる場合にはデータベースのテーブルを分ける、またはデータベース自体を
分けるようにしました。
また、レコード数ができるだけ多くならないように１アカウントで持てる数が固定である
データについて、リストデータとして１レコードにデータをまとめるようにしました。
（ただし、１データの大きさにもよりますが）
３：
巨大なテーブルは連携しない
巨大かつレコード数も多いテーブルは、連携を行わないようにしました。
（削除時などに膨大な負荷が掛かるので）
４：
巨大なテキストデータは別テーブルに分ける
巨大なテキストデータを持つテーブルはなるべく別テーブルに分けました。
５：
ノード分けしたデータベースは一括検索しない
ノード分
けしたデータベースについて、なるべく一括で検索するような処理を
避けました。必要な場合は検索したいデータはそれぞれのノードに重複して持たせるか、
共有データベースに持たせました。
※ 「ノード」とは？
ネットワークの接点のことです。
第３回は、これで終了 です。
次回（４回目）は、「FLASH開発」と「開発フェーズでの苦労点」
などについてお話する 予定です。
なお、ご意見、ご質問 などは、こちら（フォーム）から、お願いいたします。
※ご意見、ご質問の本文内に、「ソーシャルゲームの作り方（その３）」について
と、記入いただくとうれしいです。
ソーシャルゲーム虎の 巻Facebookページはこちらです。
ではでは
