アピリッツ コンテンツデザイン部の金井と申します。前回、前々回に引き続き、ソーシャルゲームにおけるミッション機能の話をしていきます。

関連：ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:問題編
関連：ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:思考編

前回までのあらすじ

　ソーシャルゲームにおけるミッション機能とは

• 構造的に改修し辛い
• 処理の時間が掛かり易い
• 問題が発生した場合それが大事になり易い

　加えて実装面でもミッション機能を構成する要素が複雑に絡み合う事が多々あり、クソコードになり易い。

　それらの問題を解消する為の自分の結論としては、API単位でミッションの処理を纏めるしかない。

実際にやってみた

　ええ、やりました。詳しくは言いませんが、出来る環境になった事があるので。
　そして目の前には、そこそこの期間付き合ってきた、さながら油でべたつく茶色にコーティングされた換気扇を思わせるようなコードがあったので。

　さて。綺麗に出来るタイミングにせよ、やるべき事は大量にありました。上記の仕組み以外にも、

• マスタ、ユーザーデータの構成が冗長である
• 過去のユーザー単位で1回しか通らないバッチ処理がそのまま残っている

　等々。
　それらも綺麗に出来るのならば、一気に綺麗にしてしまいます。どうせ、全体的にコードの差分が莫大になるのは明らかなのですから。
　ただ、しかし。マスタ、ユーザーデータの構成を変えてしまえば、もうそこから先に碌な休憩地点はありません。プロジェクトを健全に保つテストコードの文句を黙らせるまでは(え、テストコードが無い？　……ご愁傷様です)。

どの程度の時間的コストになったのか

　まあ、これの為には自分の経歴も多少書いておいた方が良いと思いますので。

• ソーシャルゲームサーバーエンジニア歴新卒4年目
• ソーシャルゲームの開発、リリース、運営を2度経験

　端的に書くとこんな感じです。まあ、入社して3年間でソーシャルゲームの全般を2度程経験した形ですね。
　そしてこの位の経験がある自分が、使い込まれたミッション機能を根本から作り直す事には、それだけに注力した状態で1~2ヶ月は掛かりました。

　また、実際のコードの差分は3500行、80ファイル以上でした。
　馬鹿でかいプルリクですが、基本的にここまででかいプルリクというのはマスタの構造の変更等で流し読み出来る部分が多かったりするものだと思います。
　しかし、このプルリクの中身は基本的にロジックの変更になります。要するに、大半が流し読み出来ないものです。
　更に言うならば、これだけ差分が大きくなる事が予見出来ようとも、自分の場合は途中でプルリクを出す事を出来ませんでした。自分が携わっていたそのコードを改善する為には、全体の挙動そのものの改善が必要だという事が途中で判明し、1APIだけを新挙動に書き換えて一旦プルリクを出す、というようなコンパクトな事もできなくなった為です。
　まあ、はい。コードレビュー等も必要に応じて行うべきかと思いますが、これだけのプルリクを見る事が出来る人が必要ですね！

精神的疲弊

　何日も何週間も同じ事柄へのリファクタリングを続けていると、流石に疲弊してきます。

　プランナーと掛け合い、無駄や冗長を削ぎ落としたミッションの仕様を新たに殆ど一から構築し直す。
　その為に既存のコード……仕様が追加、変更された事により、まるで後先考えずに違法増築を繰り返されて巨大地震でも来れば粉々に瓦解してしまいそうなそれを必死こいて読み直し、それらを綺麗に纏め上げる。
　纏め上げる最中に不必要になった変数や新たに必要となるユーザーデータなどが発生して来れば、それらの一つ一つが本当に不必要か、必要かを吟味した上で削除、追加をしていく。
　テストコードもそのままでは失敗を叫び続けるだけであり、その新たな規範に沿って作り直すところから始めなければいけない。

　……そんな作業の一つ一つを地道に、丹念に続けるにはかなりの労力が必要になります。更に続けていると、

　途中でどうしてこんな事に手を出してしまったのかという後悔が湧いてきたり。
　業務中に暫くぼーっとしたくなったり。
　業務終了後も帰りの電車の中でぼけーっとミッションの事を考えたり。
　夢の中でミッションのコードを弄っていたり。
　誰かのプルリクが飛んでくるとミッション以外のコードを見られる事に喜んですぐにレビューを飛ばし、そして同時にマージする時のコンフリクトの量がまた増えた事に辟易とし。

　ただ、それでも自分は精神的支柱があったからこそ出来たと思います。
　それは何かと言われると、まあ、はい。クソコードに対する憎悪、それに尽きます。

　以前はこのクソコードを根本的にどうにも出来る余裕がなかったから、余計にクソコードを追加して負荷や計算量を減らすしかなかった。
　このクソコードが分かりづらいから本番でエンバグを何度も引き起こした。
　このクソコードのせいで休日に出社する羽目になった。
　このクソコードを新しいプロジェクトでも残し続けていたらまた同じ目に遭う。
　クソコード……駆逐してやる！　このプロジェクトから……一行残らず！

　そんな意志が私の最大の精神的支柱でした。
　流石にソースの全体に及ぶ程に大きい改修するのは初めてでもあったりして、挑戦するような気持ちもあったのですが、そんなものは二の次で。
　お前は存在してはいけない生き物だ、と某生き恥ポップコーンさんに告げるような絶対なる意志を用いて滅しました。

改修は本当に価値があったか？

　はい。それは断言出来ます。
　少なくとも、

• 各所に散乱していた似たようなロジックや冗長な処理
• 殆ど実際に動く事は無いのに常に通ってクエリだけを投げていく処理

　は巻物を投げつけられたドラゴンの如くジェノサイドされ、

• 現状の仕様を満たす処理はそれぞれ端的に纏まった形で集約されている
• 仕様変更に対してもそれらのみを改修する事によって対応可能

　という状態にする事が出来ました。
　デイビークロケット並の予想だにしない仕様改修依頼が無い限りは、ミッションの処理はここに集約されたままに出来ると思える位には。
　勿論、まだ怪しい部分もあります。しっかりと負荷試験をして性能を数値として出してはいませんし、改修した中でも時間の掛かる冗長な処理がまだ残っているかもしれません。
　もしかしたらそんなデイビークロケットをパンジャンドラムに乗ったプランナーから渡される可能性もあります。
　しかし、まあ、そんな仕様は来ない事を信じたいなあ……。

最後に

　この巨大プルリクを半日掛けて見て下さった先輩に感謝します。

アピリッツ コンテンツデザイン部の金井と申します。前回に引き続き、ソーシャルゲームにおけるミッション機能に対する考察をしていきます。

関連：ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:問題編

前回のあらすじ

　ミッション機能というものは構造的に、

• 全てのAPIに影響が及ぶが故に改修へのQAコストが非常に高く
• 処理に時間が掛かりやすく
• ユーザーデータが膨大になるが故にそれらの問題が更に面倒な事になりやすい

　ものである。
　また、実際に実装/改修するとしても、仕様面の都合で

• ミッション受注処理
• ミッション進捗処理
• ミッション報酬受け取り処理

　の3つが複雑に絡み合う事が多く、所謂スパゲッティコードというものに、しかも見るからに不味いそれになりやすい。

どのように実装/改修すべきか

注:

　ここから記述する内容は、”これから実装する“もしくは”既存のソースを流用して新しいゲームを開発する“と言った、運用中ではない事を前提としたものとなります。
　既存のミッション機能が如何にクソコード汚いものでも改修する事によって得られるメリットは、精々、

• レスポンスが早くなる
• コードが見やすくなる
• 改修等に伴うバグの発生率を減らす事が出来る

等と言ったユーザーからは見えないものが多く、更に

• 影響が膨大な以上、QAを入念に介してもバグを除き切れずに本番障害を引き起こす可能性が高い
• バグを引き起こした場合の長時間メンテ、修正、補填などで大きな損害も被る
• マスタの改修なども必要となった場合、マスタデータを作るExcel…これまで使用していたマクロなども改修しなければいけない事となり、プランナー側、そしてクライアント側にも大きな負担が掛かる

　と言ったそれ以上のデメリットが膨大です。
　如何にエンジンが錆び付いてガションガションうるさい音を立てていようとも、熱効率が悪かろうとも、動いている状態のまま幾つかの部品を取り替える事なんて早々出来ないですからね。
　それでもやらなければいけないとなる場合は、レスポンスの重さでユーザー離脱が激しいとか、原因不明のバグが頻発して、更に手をつけようにも秘伝のソース過ぎて壊さないとどうしようも出来ないとかそんな、それを使い続ける事で極度の不利益が出る場合に限るでしょう。
　そうでない場合は、その汚いコードと付き合っていくのがベストです。
　ベストです。
　ベストなんですよ。悲しい事に。とても、とても悲しい事に。

普遍的に良く見られるであろう悪くなっていくコード

　まず前回でも書いたような、カードの強化で例えてみましょう。
　カードを強化させた回数のミッションと指定アイテムを手に入れた回数のミッションが存在するとします。
　そして、カードを最大レベルまで強化するとカードマスタに指定されたアイテムが貰えるとします。
　すると、さっくり疑似コードとして書いてみると以下のようになるでしょう。

class User < ActiveRecord::Base
  def カード強化(カードID, 使用素材群, 時刻)
    カードが存在するか確認
    カードが既に最大レベルでないか確認
    使用素材群それぞれに対し do
    　消費数分持っているか、またそれらがレベルアップ用アイテムか確認
  　　消費数分の減算、獲得経験値を計算
    end

    カードをレベルアップ(獲得経験値)
    カードを強化したミッションを進捗させる

    if カードが最大レベルならば
    　アイテム付与(カードマスタに定義されている報酬アイテムマスタコード, カードマスタに定義されている報酬アイテム量, 時刻)
    end
  end

  def アイテム付与(アイテムマスタコード, 付与量, 時刻)
    指定されたアイテムマスタが存在するか、また受け取れる時間であるか確認
    ユーザーにアイテムを付与
    アイテムを獲得したミッションを進捗させる
  end
end

　こんな感じですね。
　確かにミッションがシンプルな仕様ならば、そんなに時間も掛からないでしょう。
　しかし例えばカードの強化を促進させる施策の一環で、カードを指定レベルまで成長させた、カードのレベルを最大まで上げたというミッションが追加されたとすると、最大、合計で4つのミッションの進捗確認を1個1個する事になります。
　段々雲行きが怪しくなってきましたね！

　そして今度はミッションを進捗させる方を詳しく見ていきましょう。分かりやすさの為に、ミッション進捗は別のクラスに纏めましょうか。

class ミッション進捗
  def 進捗させる(ユーザー, 進捗させるミッション種, 進捗させるミッションカウント, ...)
    進捗させるミッション種に属する、現在有効なミッション群を確認する
    そのミッション群に対して do
      ユーザーの進捗を加算する
    end
  end
end

　簡単に書くとこうなりますね。
　さて。ここで例えば前回でも書いたような、ミッションの仕様に良くある、ミッションをクリアしたら次のミッションが解放されるという仕様が入ってくるとこうなりますね。

class ミッション進捗
  class << self
    def 進捗させる(ユーザー, 進捗させるミッション種, 進捗させるミッションカウント, ...)
      進捗させるミッション種に属する、現在有効なミッション群を確認する
      そのミッション群に対して do
        ユーザーの進捗を加算する
        if クリアしたならば
          それのクリアを前提条件とするミッション群を解放させる
        end
      end
    end
  end
end

　シンプルにこのような感じになるでしょうね。
　さて。ミッション進捗そのものも重くなりましたね。それがカードを強化するだけで最大4回走りますね。
　雨が降ってきたようです。
　そしてトドメに、ある特定のミッション種別だったらクリアまでではなく、報酬付与までするとの仕様が入ってきたとしましょうか。

class ミッション進捗
  class << self
    def 進捗させる(ユーザー, 進捗させるミッション種, 進捗させるミッションカウント, ...)
      進捗させるミッション種に属する、現在有効なミッション群を確認する
      そのミッション群に対して do
        ユーザーの進捗を加算する
        if クリアしたならば
          それのクリアを前提条件とするミッション群を解放させる
          そのミッションが特定の種別だった場合、報酬付与まで行う
        end
      end
    end
  end
end

　はい。報酬付与の中ではこのミッション進捗が呼ばれていますね。雷まで落ちてきたようです。

こうならない為にはどうするべきか

　自分なりの考えとなりますが、結論としては単純です。

　同じようなコードを何度も通さない仕組みにすれば良い。

　ただ、それだけです。
　上のコードを書き換えるとこんな感じでしょうか。

class User < ActiveRecord::Base
  def カード強化(カードID, 使用素材群, 時刻)
    カードが存在するか確認
    カードが既に最大レベルでないか確認
    使用素材群それぞれに対し do
    　消費数分持っているか、またそれらがレベルアップ用アイテムか確認
  　　消費数分の減算、獲得経験値を計算
    end

    カードをレベルアップ(獲得経験値)
    ミッション用にカードを強化したというデータを保持

    if カードが最大レベルならば
    　アイテム付与(カードマスタに定義されている報酬アイテムマスタコード, カードマスタに定義されている報酬アイテム量, 時刻)
    end
  end

  def アイテム付与(アイテムマスタコード, 付与量, 時刻)
    指定されたアイテムマスタが存在するか、また受け取れる時間であるか確認
    ユーザーにアイテムを付与
    ミッション用にアイテム付与したというデータを保持
  end
end

　そしてカード強化の後、他に何もやらなくなったタイミングで保持したデータに対して一括でミッションを進捗させる。

class ミッション進捗
  class << self
    # 進捗させるミッションデータ群 = {ミッション種別: 進捗カウント}
    def 進捗させる(ユーザー, 進捗させるミッションデータ群, ...)
      進捗させるミッション種別群に属する、現在有効なミッション群を確認する
      そのミッション群に対して do
        ユーザーの進捗を加算する
      end
      クリアしたミッション群それぞれに対して do
        それのクリアを前提条件とするミッション群を解放させる
        そのミッションが特定の種別だった場合、報酬付与まで行う
      end

      if 報酬付与まで行なった場合
        ミッション進捗をまた呼ぶ
      end
    end
  end
end

　ざっくりこのような形ですね。
　工夫が足りず、このミッション進捗はこれでも複数回呼ばれる可能性はありますが、少なくとも元々の形よりは呼ばれる頻度は落ちるでしょう。
　カードを強化させた回数のミッション、指定アイテムを手に入れた回数のミッションに加えてカードを指定レベルまで成長させた、カードのレベルを最大まで上げたというミッションがあったとしても、このミッション進捗を通る回数は1回で変わらないのですから。

結論

　自分ではそれしか思いつきませんでした。
　ミッションという機能は性質上、1APIで様々なミッションの進捗が進むという事が絶対にあります。
　幾らそのミッションの進捗1回分を軽量化しようとしても、無理な軽量化はどこかに歪みを生みます。コードがより複雑になったり、新たな仕様によって軽量化の前提が上等な料理にハチミツをぶちまけるが如くに崩れる事があったり。
　1個1個に対して愚直に進捗を進ませるという事柄自体をやめなければ、ミッションという機能は健全に運営に組み込めないという結論です。
　しかし、それはやはり運営フェーズに入ってからは絶対に出来ない事です。
　全てのAPIに浸透し、隆盛しているようなそんな文化を一気にひっくり返すなど、濃口のラーメンが流行りの極みの時に薄口のラーメンのみを売り出して儲けを出そうとするようなものでしょう。

　次回は、そんなコードを実際に改修した時に起きた事などを書こうと思います。

第三回はこちら：ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:実践編

アピリッツ コンテンツデザイン部の金井と申します。幾つかに渡ってソーシャルゲームにおけるミッション機能に対して書いていこうと思います。

関連：第二回「思索編」はこちら！ → ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:思考編

前置き:ミッション機能の構造的問題

　ソーシャルゲームにおけるミッション機能というものは、サーバーサイドにおける実装を極めて慎重に行わなければいけないものである。
　理由としては、

• リリース後の改修が困難になり易い
• 負荷的な問題になりやすい
• マスタ、ユーザーデータが膨大になる

　という、サーバーサイドにしては一つ一つが重大な問題を抱えるからである。
　一つ一つに対して詳細を追っていく。

リリース後の改修が困難になりやすい

　まず一つ目として、ソーシャルゲームにおけるミッションというものはユーザーの様々な行動で更新が発生する。ユーザーの所持するユニット/カードなどを成長させる、ログイン日数が一定数に達成する、指定のダンジョン/楽曲を指定のスコアでクリアする等々。
　即ち、ゲーム全体で実装する全てのAPIにおいてトリガーとなる事象が発生する可能性があるという事だ。それが意味する事とは、ミッションにおける根幹の部分を変更しようと思った場合には、全てのAPIに影響が及ぶ事を想定しなければいけない。
　それへのQAコストを考えた場合、リリース後の改修が困難になりがちである。

負荷的な問題になりやすい

　一つのAPIに対して、複数のミッション種が更新される、となった場合の処理を考えてみる。
　例えば、ダンジョン/楽曲をクリアした時などで考えると、
　ゲームクリアに紐付いて起こる事柄は例えば、
・パーティの経験値が増加する
・報酬が貰える
　等と言った事がある。さて、ここでそれらに紐付く、カードのレベルが指定に達する、指定のアイテムを手に入れると言ったミッションがあったとする。
　サーバー側で行わなければいけない処理は簡単に書いても
・対象のミッションを探す
・対象のミッションの数値を達成数分加算する
・対象のミッションの達成条件を満たしたら達成状態に変化させる、もしくは報酬を付与する
　となる。しかも上記は、愚直に行うのならば、レベルアップしたカードの数と手に入れたアイテムの種類数、更にミッションを達成して手に入れたアイテムの種類数だけの回数を繰り返さなければいけない。
　下手な実装をしたら、あっという間にレスポンスが返って来るまで5秒、10秒と掛かってしまう事の想像は難くない。

マスタ、ユーザーデータが膨大になる

　負荷、改修コストの問題にも紐付くが、それに拍車を掛けるのがこの問題だ。
　リリース直後にはミッションデータは少なく、負荷的な問題にならなかったとしても、リリースして暫く時間が経って来ると色んな施策を実践していくに連れてミッションマスタ、それに紐付くユーザーデータというものは肥大化していく。
　新たな施策の為にユーザーデータにカラムを追加したい、と言った事をしたくとも、その膨れ上がったデータベースに対してカラムを追加しようとした時、それだけでも数時間掛かる……即ちそれだけの時間は少なくともメンテナンスに入れなければいけない、と言った事も容易に発生する。

ミッション機能の構造的問題の纏め

　簡単に纏めてしまえば、ミッション機能と言うのはサーバー側にとって、

• 全てのAPIに影響が及ぶが故に改修へのQAコストが非常に高く
• 処理に時間が掛かりやすく
• ユーザーデータが膨大になるが故にそれらの問題が更に面倒な事になりやすい

　と言う三拍子揃った非常に厄介なものとなりやすい。
　勿論、仕様次第ではもっと厄介な事になる事も十分にある、と言うか問題が上記だけで済むのならばとても喜ばしいとまで言える。

ミッション機能の実現の為に

　サーバーサイドで実装すべき機能は大まかに分けて以下の3つになる。

• ミッション受注処理
• ミッション進捗処理
• ミッション報酬受取処理

　同様に一つ一つ詳細に見ていこう。

ミッション受注処理

　問題になりやすい部分。
　ただ受注させるだけならマスタデータ参照してユーザーデータ作るだけでしょ？　と思っても、些細な問題が色々と発生し易い。
　例えば、15:00から受注出来るミッションに対して、14:58にゲームを開始して15:02にゲームをクリアした、と言った事柄を考えてみる。
　この場合、15:02にゲームクリアのAPIを叩かれた時にはユーザーはミッションを受注していない状態である訳だ。
　その場合に15:00から受注出来るミッションを進ませたい、とプランナーから要望を受けた場合、エンジニアとしてはミッションの受注処理をゲームクリアAPIの最初に仕込む必要が出て来る。
　さて。時が経つに連れて、似たような事柄がポンポン出て来てしまった。この処理の前にもミッション受注処理を入れる。この処理の前にもミッション受注処理を入れる。この処理の前にもミッション受注処理を入れる。この処理の前にも……。殆どの場合に何も発生しない処理が至る所に埋め込まれる。これだけでも香ばしいクソコードの出来上がりだ。
　後から考えれば、プランナーにゴメンナサイしてゲームクリアAPI以外では基本的にログインさせ直すように仕向けた方が良かったとか、期間前であろうとも受注させておいて進捗だけは進ませないようにしておくとか、そういうもっと良い対応も取れたけれど、もう後の祭りである。
　運用に乗っているクソコードはもうずっとそこにあるのだ。直そうとしてもQAコストを余計に掛ける余裕も無いのだ。

ミッション進捗処理

　問題になる部分。
　端的にやるべき事は、トリガーとなる処理にミッション進捗処理を引っ掛けて、対象のミッションを探し出し、進捗を進める。
　ただそれだけである。しかし、色んな仕様がここにくっついたりすると一気に複雑になってくる。
　良く見る機能としては、ミッションA1をクリアした場合、ミッションA2が解放されるというもの。
　そうなるとミッション進捗機能にミッション受注処理がくっついてくるのだ。さて、これだけでも頭が痛くなって来る。ミッション受注処理自体は、その上記で書いたように時間制限とかを鑑みずにA2だけを解放すれば良いのだろうが、問題はそこではない。ミッション受注処理が複数種類生まれて来るという事がよりコードを複雑にさせる。
　他にもA1の進捗が4/5で、その場合に進捗を2進めた場合にA2の進捗は1進んだ状態であって欲しいとか言われたらさあ大変。受注の後に更に進捗処理が発生する。ぐるぐるぐるぐる処理が回るよどこまでも。こういうループ処理はとても危険で、もしかしたらQAも気付かずに極めて限定的な条件で無限ループに入ったりする時もある。
　更に、この処理は根幹のトリガーとなる処理にミッション進捗処理を引っ掛けて、対象のミッションを探し出し、進捗を進めるという部分で時間が掛かり易いという部分もある。
　簡単に考えても、対象の種別のミッションマスタ群の中で進捗可能な時間内にあるものを引っ張って来る、ユーザーがまだクリアしていないもの、という両方ともクエリを掛けないと引っ張ってこれないものが必要になってくる。
　そして、更に問題なのは、そんな時間が掛かる処理が何度も回る可能性がある、という事だ。カードのレベルアップ処理にミッション処理を紐づけて、上記でも書いた、ゲームクリア時にカードがレベルアップした、とするとどうなるか考えてみよう。
・使用したデッキのカード群それぞれに対して
　・カードのレベルが上がる
　・レベルが上がったのでミッション進捗処理が走る
　・ミッションが達成状態になったらそれに紐付くミッションの解放処理が走る
　これだけで最悪数秒掛かりそうな予感がする。
　更にここに、上記で言うアイテムを手に入れた場合にミッション進捗処理が走ると考えると、
・使用したデッキのカード群それぞれに対して
　・カードのレベルが上がる
　・レベルが上がったのでミッション進捗処理が走る
　・ミッションが達成状態になったらそれに紐付くミッションの解放処理が走る
　　・達成したミッションからアイテムが手に入ったらそれに紐付くミッションの進捗処理が走る
　　・そのミッションがクリアしたらそれに紐付くミッション解放処理が走る
　　　・達成したミッションからアイテムが手に入ったらそれに紐付くミッションの進捗処理が走る
　　　・そのミッションがクリアしたらそれに紐付くミッション解放処理が走る
　うわあああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛あ゛!!!!!!!!!???????????!!!???!!?!?!?!?!?!?!?!

※ここまでなるのは達成状態になったら、このミッション区分に関してはユーザーが能動的に受け取るAPIを叩かずとも報酬が自動的に付与されるとか、そんな仕様がある場合に限る

ミッション受け取り処理

　そんなに問題になる可能性は低い部分。
　けれどミッションを受け取り完了状態にしてアイテムを付与すると同時に、別のミッションが解放されるとか、別のミッションの進捗が進むとかそんな事があると更に頭が痛くなってきますね！！

実装面での障害の纏め

　主に3つと書いたが、問題なのは、書いたようにその3つは仕様次第で複雑に絡み合っていく事である。
　ただでさえ色んな問題が起き易いのに、コードがイタリア人がターボ機能を仕込んだ靴で助走をつけてパイルバンカーを顔面に叩き込み、そして馬乗りになり原型がなくなっても憤怒の表情を浮かべながら打ち込み続ける程の作り方で仕上げられた、見るからに、そして実際吐いてしまう程のスパゲッティのようになり易いのである。

　次回はどう実装すれば、よりマシになるかを考察していく。

関連：第二回「思索編」はこちら！ → ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:思考編