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
kyp
March 29, 2024
510
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
820
私とノベルゲームとEbitengine -SAEKO: Giantess Dating Simの紹介-
kypkyp
1
3.2k
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.1k
Amusing Abliteration
ianozsvald
1
220
Context Engineering - Making Every Token Count
addyosmani
9
1k
AI: The stuff that nobody shows you
jnunemaker
PRO
8
820
Making Projects Easy
brettharned
120
6.7k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.9k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
910
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.5k
The Limits of Empathy - UXLibs8
cassininazir
1
410
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