• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Interaction channel
 

Interaction channel

on

  • 20,142 views

2013/03/16 Room Metro #14 にて発表。 ...

2013/03/16 Room Metro #14 にて発表。

ファイル名の「Interaction Channel」が本当のタイトルで、
タイトルスライドの「P●PをC#で書きなおしたら100倍速くなった」は釣りです。

http://ufcpp.wordpress.com/2013/03/17/100%e5%80%8d%e9%80%9f%e3%81%8f%e3%81%aa%e3%82%8b%e9%96%8b%e7%99%ba/

Statistics

Views

Total Views
20,142
Views on SlideShare
2,900
Embed Views
17,242

Actions

Likes
16
Downloads
11
Comments
0

19 Embeds 17,242

http://ufcpp.wordpress.com 17147
https://twitter.com 19
http://www.newsblur.com 17
http://newsblur.com 15
https://ufcpp.wordpress.com 9
http://webcache.googleusercontent.com 6
http://www.feedspot.com 6
http://cloud.feedly.com 6
http://cache.yahoofs.jp 3
http://feedly.com 2
https://www.google.co.jp 2
http://digg.com 2
http://131.253.14.98 2
http://reader.aol.com 1
http://127.0.0.1 1
http://locatefind.net&_=1377618246406 HTTP 1
http://www.google.co.jp 1
http://news.google.com 1
http://locatefind.net&_=1377618373669 HTTP 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Interaction channel Interaction channel Presentation Transcript

    • P●PをC#で書き直したら100倍速くなった++C++;岩永 信之
    • 開幕ネタバレうそ、おおげさ、まぎらわしい PHPをC#で 書き直したら 100倍速くなった言語変えただけで100倍になったら苦労しない
    • 参考までに: 性能 静的な言語※と動的な言語(一般論として)  平均的には5倍程度の差(静的な言語が速い)  文字列処理なんかだと差が出ない  数値計算だと30倍くらい開くことも C#でも(時々実測する限り)  dynamic型を使うとスピードが5分の1くらいに言語を変えて1桁は変わるけど、2ケタはそうない 正直、「100倍速い…」って言われて自分もビビった ※ コンパイル(あるいはJIT)型の言語で、 コンパイル時に型情報を使った最適化をかけるもの
    • 正しくは自分がPHPをC#で書き直したら100倍速くなった 要は、きっちり設計しなおしたから 大まかに2ケタくらい速くなったのは本当
    • 元P●Pとあるモジュールにて 1つの巨大なファイル 参照局所性  1クラスで約4,000行 落とす 巨大switchもJump Table化されない?  publicフィールド数50  1つのswitch文で長さ688行、caseラベル約200個 ログ取りや結果の出力までべた書き  文字列連結で、固定フォーマットで HTMLソースコードを生成してる (その用途しか想定してない)
    • 実装しなおし後C# クラス化  1クラス数フィールド  switch分岐解消(多態化) 債務分割  ゲーム ロジックだけ切り出し  出力用のフォーマットは別途行う (今や元より高機能だけども) 同様の機能の実装 (四角1つ1つが1クラス)
    • ちなみに: 書き換えの理由 理由もなく書き替えない  100倍程度の速度差だと動機として弱い※ クライアント上でも同じロジック使うから ネットワーク切れ チートされると てもプレイしたい まずい クライアント上実装必須 サーバー上実装必須  サバクラ両方で使うからC#  ちなみに、クライアントはiOS  サーバーもMonoにする† ※ サーバー代金が問題になるような負荷でもなかった たぶん、データベース アクセスとかの方がよっぽどネック † 「サーバーOSはそのままLinuxにするかも」という意味 このモジュール以外はP●Pのまま&同一サーバー内実行
    • その他の効能 整理されたことで  開発ペースはかなり速い (前はバグが1か月取れない※とかあった) 債務分割(ビューの切り離し)で  コマンドライン デバッグ可能に  (サーバー、クライアントはもちろん) 企画者向けのバランス検証ツールともコード共有化  他のゲームでも使う予定 ※ かかる工数的に、直しても見合わないという判断あり バグを直すんじゃなくて、バグってるアイテムの出現確率を落として回避
    • 今日のテーマなんだっけ?
    • その他の効能(再) 整理されたことで  開発ペースはかなり速い (前はバグが1か月取れない※とかあった) 債務分割(ビューの切り離し)で  コンソール デバッグ可能に  (サーバー、クライアントはもちろん) 企画者向けのバランス検証ツールともコード共有化  他のゲームでも使う予定 これ
    • つまり こういう状態 主要機能 共有 Window デバッグ用 iOS Linux デスクトップ コマンドクライアント サーバー クライアント ライン Window ストア アプリ 今更1個増えたくらい どうってことない※ ※ ロジック担当の発言です。UI担当の方ごめんなさい。
    • ※ ロジック担当の発言です。UI担当の方ごめんなさい。
    • 実際にやったことの片鱗を 三択クイズ アプリ  実際に作ったものそのものではないものの、似た仕組み で実装 Windowsストア アプリでデモを
    • 三択クイズ  制御フロー的にはこんなの View Model ループ 出題 問題を表示 問題選択 問題集回答 回答 答え 答えを表示 正誤判定OK 次の問題へ 全問終了 No Yes 結果 結果を表示 合格判定
    • ポイント1: Modelはいろいろ使う 用途• ゲーム本体 Model• サーバー上でチート検証 ループ• プランナー向け調整ツール 出題• デバッグはコマンドラインで 問題選択 問題集 回答• iOS、Windows、Linux… 答え 正誤判定• GUI、CUI• 手動、自動 次の問題へ 全問終了 No Yes 結果 合格判定
    • ポイント2: 完全状況再現 乱数シード 値を記録 Model ループ• ユーザー回答を記録 出題• 与えた値が同じな 問題選択 問題集 ら、 回答 完全に同じ実行結果 答え 正誤判定 次の問題へ用途 全問終了 No• チート検証 Yes• オンライン対戦 結果• ゲーム途中での中断/再開 合格判定
    • ポイント3: View⇔Model往復 制御フローはModel側 が管理してる/すべき View Model 双方向 ループ 制御フローの 出題 問題を表示 問題選択 問題集 中断と再開が必要回答 回答 答え 答えを表示 正誤判定OK 次の問題へ 全問終了 No Yes 結果 結果を表示 合格判定
    • ポイント4: 非同期 I/O処理 タイマー処理 =非同期 View Model• ユーザー操作を待ったり ループ• アニメーション終了を待ったり 出題 問題を表示 問題選択 問題集回答 回答 答え 答えを表示 正誤判定 OK 次の問題へ 全問終了 No Yes 結果 結果を表示 合格判定
    • ポイント まとめ ポイント  ViewとModelの分離必須  制御フローはModel側で  完全状況再現  ViewとModelの双方向のやりとり  (Model側から見て)Viewは非同期 三択クイズごときですら、たやすくない うまく扱えれば、いろいろなゲームに応用可能
    • どういうものを作ったかModel 制御フローの中断と再開 = イテレーター  制御フローはModel側で Interaction Channel  完全状況再現 間を取り持つクラス  ViewとModelの双方向のやりとり  (Model側から見て)Viewは非同期 View 非同期 = Taskクラス
    • Model イテレーター化 Model ループ 出題 問題選択 問題集 回答 答え 正誤判定 次の問題へ 全問終了 No Yes 結果 合格判定
    • Model イテレーター化 int correctCount = 0; foreach (var q in _questions) { var qm = new Q(q); 問題選択 出題 yield return qm; var isCorrect = qm.Response == q.AnswerIndex; if (isCorrect) correctCount++; 正誤判定 答え yield return new A(isCorrect); } var correctRate = correctCount / num; 結果 yield return new Result( 合格判定 correctRate, _acceptableRate);
    • Interaction Channel  ViewとModelをつなぐ部分 View Model ループ 出題 問題を表示 問題選択 問題集回答 回答 答え 答えを表示 正誤判定OK 次の問題へ 全問終了 No Yes 結果 結果を表示 合格判定
    • Interaction Channel  ViewとModelをつなぐ部分 Modelの制御フロー Model (イテレーター)を登録 public class Channel<TMessage> { public Channel(IEnumerator<TMessage> coroutine) public Task RunAsync() 実行 public void AddAsyncHandler(Func<T, Task<TR>> handler) where T : Tmessage } ViewはTask非同期で応答View 同期版(Func<T, TR>)もある
    • View  Interaction Channelから来たメッセージを処理  Task非同期 View 出題 問題を表示回答 回答 答え 答えを表示OK 次の問題へ 結果 結果を表示
    • View Interaction Channelから来たメッセージを処理  Task非同期 例: 問題の表示と回答(コマンドライン版) channel.AddHandler<Q, int>(m => 問題文 { Console.WriteLine(m.Question.Statement); int i = 1; 選択肢 foreach (var op in m.Question.Options) Console.WriteLine("{0}. {1}", i++, op); Console.Write("何番?: "); int answer = int.Parse(Console.ReadLine(); return answer - 1; }); 回答番号
    • 結果 意外と汎用性高い  今日のデモ用の三択クイズ  実務で、2系統のロジックをこれで実装  結構な種類のゲームがこの仕組みに乗る 残念なところ  C#に型マッチング機能欲しい  型で分岐してる  アクター的機構も欲しい  他の言語のアクター機能も、使いやすいとは言い難いけど
    • デモ コンソール版までは作ってあるんで じゃあ、ストア アプリ作ろうか  今から