Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
いい感じのパッケージ構成を考える
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
kyp
March 29, 2024
500
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
いい感じのパッケージ構成を考える
kyp
March 29, 2024
More Decks by kyp
See All by kyp
Ebitengine製ゲームをチーム開発するために
kypkyp
0
800
私とノベルゲームとEbitengine -SAEKO: Giantess Dating Simの紹介-
kypkyp
1
3.2k
Featured
See All Featured
Between Models and Reality
mayunak
4
330
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
280
Claude Code のすすめ
schroneko
67
230k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.3k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
200
Building an army of robots
kneath
306
46k
The Curious Case for Waylosing
cassininazir
1
380
Rails Girls Zürich Keynote
gr2m
96
14k
sira's awesome portfolio website redesign presentation
elsirapls
0
280
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
360
BBQ
matthewcrist
89
10k
Believing is Seeing
oripsolob
1
140
Transcript
いい感じのパッケージ構成を考える kyp
発表者について kyp (X: @_newkyp) SAFE HAVN STUDIOという3人のサークルで 「SAEKO: Giantess Dating
Sim」を作っています SAEKO: Giantess Dating Sim https://saekogame.com/ 少しダークで刺激的なノベルゲーム 大きい女の子がでてくる
Ebitengine製
TGSにも出展!しかし...
展示会のたびにバグり散らかしていた TGS: 試遊機上で バグ修正 台北ゲームショー: 終わりなきLQA
前回のぷちconfで...
前回のぷちconfで... eihighさんはじめ前回の参加者の皆様 ありがとうございました
今回のLTテーマ 「とりあえずで始められるパッケージ構成」
とりあえずで始められるパッケージ構成 SAEKOを組み始めたときの、パッケージ設計があまりよくなかった →今回のLTではリファクタ後のSAEKOのパッケージ構成を共有してみます 正解ではありません!あくまで事例です
前提: scene ゲームはいくつかの シーン scene に分かれている 「タイトルシーン」「ゲームシーン」「リザルトシーン」とか 例: https://github.com/hajimehoshi/ebiten/tree/main/examples/blocks
層を分ける: state, drawer sceneごとに、 state パッケージと drawer パッケージを用意。 ゲームのデータを具体的に変更する処理は state
パッケージに、 そのデータを描画する処理は drawer パッケージに分けて書く。 scene.Day state.Day drawer.Day ゲームのデータ を変更する ゲームのデータ を描画する
層を分ける: state, drawer sceneはすごく薄い。 毎フレーム state, drawerを呼び出し、 相互の連携をするだけ。 scene.Day state.Day
drawer.Day s.state.Update() s.drawer.Update(s.state) s.drawer.Draw() func (s *Basic) Update(game *Game) (err error) { // 例外処理とかは省略 s.state.Update() s.drawer.Update(s.state) return nil } func (s Basic) Draw(screen *ebiten.Image) { s.drawer.Draw(screen) }
層を分ける: state, drawer 利点: 状態管理 と 描画 を分けられること - 「描画を変えたらなぜか条件分岐までバグる」みたいな心配がない
- バグが起きたときも該当箇所が分かりやすい (注: 実際には2つはすっぱり分けられない ボタンの位置やアニメーションの秒数など、描画が状態に影響するものがある → state でも drawer でもないパッケージを作って管理するとスッキリする)
なぜわざわざこんなことを? • 「進行バグ」「描画バグ」など、バグの性質によって該当箇所が分かる • データに影響を及ぼすことなく、気軽に描画方法を変更できる ◦ 描画の処理は、だいたいややこしい scene.Day state.Day drawer.Day
なぜわざわざこんなことを? 例: ステータス更新 scene.Day state.Day drawer.Day
その先の世界へ... state, drawer 以外の層は無理に作らない 開発しながら、何回もバグり散らかす箇所を独立したパッケージへと分けていく
バグり散らかす箇所? SAEKOの場合は、スクリプト処理がとにかくバグる • スクリプトの分岐処理ミス ◦ 「条件遷移の遷移先が1行ミスる」とか • スクリプト自体の文法ミス ◦ 「新しいスクリプトで1文字だけコマンドtypoしてる」とか
• どれもデバッグが超たいへん • 他言語版で起きると地獄
テストするためにパッケージを切り離す バグる箇所が出てきたら、単体テストを書くためにパッケージを分ける 例: scripter -> スクリプトの解釈と分岐だけを専門に行うパッケージ
おわりに いまのコード行数は11,000行ぐらい (やばい) 開発してるとどうしてもバグは起きるけど、 問題の追跡がしやすいと気持ちが楽になります あとGoでのリファクタは楽しい!
ご清聴ありがとうございました! ウィッシュリスト登録お願いします (呪文) https://saekogame.com/steam 現在のビルドやコードもお見せできるので、 このあと気軽にお声掛けください! SAFE HAVN STUDIO /
kyp