Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ゲームを0.5から作ってわかったこと(@KMC春合宿2019)

ikubaku
March 15, 2019

 ゲームを0.5から作ってわかったこと(@KMC春合宿2019)

ゲームの構造をほぼ無から作って学んだ話など

ikubaku

March 15, 2019
Tweet

More Decks by ikubaku

Other Decks in Programming

Transcript

  1. 8 今日の流れ - 0.5 からゲームを作る - 作って知ったゲームの仕組み - - ゲームフレーム

    - - 当たり判定 - - 幾何と物理現象 - - 入力仮想化 - 去年のラピゲの反省点 - 技術的な視点から - 改良したキットについて
  2. 11 なぜこの話を?( 2 ) 主にやってたこと - MS Office VBA (だいいっぽ)

    - Windows Form Application (ブラウザをかいた) - ゲーム(開発支援ソフト使用から DirectX 使用までいろいろ) - 組み込み(ちょっとロボカップをやってた、 Arduino とか) - OS (ほんと???) - GPGPU (ほんと???) (アプリ開発、 Web アプリ、 AI についてはほぼ無なので、 やっていきたい)
  3. 14 0.5 からゲームを作る - ゲーム開発支援ツール ( Unity Editor, RPG ツクール)を

    使わないゲーム開発、ということにする - ゲームエンジン(の一部)を自分で定義することが多い
  4. 15 変わること - 様々な恩恵がない - 開発支援ツールの使い方は知らなくていける → 自分でエディタを書く文明もある → エディタだけ借りる文明もある(

    Tiled など) 実は学習も兼ねてやる場合は便利だったり( n=1 ) polaris も何度かゲームエンジンの実装を試みてきた
  5. 16 使ってみたもの - DirectX - DX ライブラリ - pygame -

    SDL - Processing → 画像の描画、音の再生、入力装置の状態取得だけ代行して くれる
  6. 21 よりよい方法 準備 : 1 フレームにちょうどかけたい時間を f とする 1. 現在時刻

    t を取得する 2. 処理と描画を行う 3. 現在時刻 s を取得する 4. 2 にかかった時間 d = s - t を計算する 5. d > f ならば 1 に戻る(処理落ち) 6. 時間 f – (s – t) だけ待つ 7. 1 に戻る
  7. 23 deltaTime の謎 - 時間がかかることはどうすることもできない - 1 フレームにかかっている時間を直前のフレームなどから得て、 状態をどれだけ変えればよいか決定する →

    目標フレーム時間で実行できるときと結果が同じように見える ( Unity にある deltaTime はこれ) // 加算される値が単位時間あたりのフレーム数に依存する Character.position += 3.0f * dirVector * frameTime; // 最後のフレーム時間に依存する Character.position += 3.0f * dirVector * deltaTime;
  8. 27 点 vs 円 - 距離を測る ex) 点の座標を p 、円の中心座標を

    c 、円の半径を r として、次の条件 を満たす dist(p, c) <= r
  9. 28 円 vs 円 - 距離を測る(いっしょやんけ!) ex) 円 i(i=0,1) の中心座標を

    c[i] 、円の半径を r[i] として、次の 条件を満たす dist(c[0], c[1]) <= r[0] + r[1] えっ、高校で習った?
  10. 29 矩形 vs 点 - 辺が属する直線で挟み込む ex) 矩形の左上の座標を r0 、右下の座標を

    r1 、点の座標を p とした とき次の条件を満たす( 2 次元、 x 軸方向は右、 y 軸方向は下) r0.x <= p.x <= r1.x かつ r0.y <= p.y <= r1.y
  11. 30 矩形 vs 矩形 - 円 vs 円に近いアプローチで考える ex) 矩形

    i(i=0,1) の中心座標(各辺の垂直二等分線の交点の座標) を c[i] 、幅、高さをそれぞれ w[i] 、 h[i] とするとき、次の条 件を満たす dist(c[0].x, c[1].x) <= w[i] // 側面のめり込み かつ dist(c[0].y, c[1].y) <= h[i] // 上面仮面のめり 込み
  12. 31 矩形 vs 円 - むずい ex) 矩形の中心座標を c 、幅、高さをそれぞれ

    w 、 h 、円の中心座標を d 、半径を r として (I) c-w <= d.x <= c+r なら C-h-r <= d.y <= c+h+r (II) c-h <= d.y <= c+h C-w-r <= d.x <= c+w+r (III) それ以外 矩形の 4 頂点について点 vs 円
  13. 34 向きのベクトルから角度を得る - 逆正接関数( Tan-1 )をつかう - x == 0

    のときに場合分けする - y の正負で絶対値が大きな角度について判定する (場合分けをまとめた手続きが実装されている場合もある。 atan2 など)
  14. 39 より簡単なモデル化 - 単振動 振幅を A 、周期を T として、 x

    軸に関して単振動するには p.x = Asin(2π * t/T) x 軸について時計回りに θ 傾けると p.x = Acos(θ)sin(2π * t/T) p.y = -Asin(θ)sin(2π * t/T)
  15. 43 Down か Pressed か (I) キーが押されている || 離されていることを調べる場合 キーの現在の状態を取得すれば良い

    (II) キーが押された瞬間 || 話された瞬間を得る場合 直前の状態と現在の状態を比較すれば良い
  16. 49 変わること(再掲) - 様々な恩恵がない - 開発支援ツールの使い方は知らなくていける → 自分でエディタを書く文明もある → エディタだけ借りる文明もある(

    Tiled など) 実は学習も兼ねてやる場合は便利だったり( n=1 ) polaris も何度かゲームエンジンの実装を試みて きた
  17. 51 わかったこと - 全く実用的なものにならなくても、実装することでわかっ てくることがある( OS 自作入門と同じような感じ) - ゲームエンジンを開発するのは極めて難しいミッションの 一つ

    - ここまでやれるんだったら既存のエンジンを改造していき ましょう(真理ではなく私の見解ですが) → 最近のゲーム開発環境は拡張が充実していることが多い (当社比) - 良い子は polaris の真似をしないように
  18. 52 ラピッドコーディング祭り - KMC の新歓期イベントの一つ - 見学者と部員でチームを組み、 6 時間でゲームを作る大炎 上ハッカソン

    とても楽しいイベント - 去年私が担当させていただきました(会場で死んだように 眠っていた人です(は?))
  19. 59 反省点 - ドキュメンテーションが貧弱だった → 公式リファレンスは英語、自作したコードの説明はコメントし かなかった - 引数がすごくたくさんある関数があってむずかった →

    カンマとピリオドを間違えて意味不明なエラーが出るなど → まあ、エディタも悪い - 作ったもののアップロードで少し混乱があった → どこをコピーしたら他の環境でも動くのか?
  20. 60 解決策とか - ドキュメント自動生成(ほんと?) - Prosessing 本もっと導入する - ライブラリ関数の引数をできるだけ短くする -

    やっぱりいい感じのエディタから使えるようにする - 提出や他の環境への移植を簡単にする(パッケージ化と か) - ブラウザで動かせると実はは偉い?
  21. 61 p5.js - Processing API の JavaScript での実装 - ブラウザで動かすことができる

    - 天才 (実は Processing のコードもブラウザで実行することがかつては できたのだが、必要なプログラムがもうメンテナンスされてないの で事実上不可能になってしまっている)