Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
いい感じのパッケージ構成を考える
Search
kyp
March 29, 2024
540
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
880
私とノベルゲームとEbitengine -SAEKO: Giantess Dating Simの紹介-
kypkyp
1
3.2k
Featured
See All Featured
The SEO Collaboration Effect
kristinabergwall1
1
590
The Curse of the Amulet
leimatthew05
3
15k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.5k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
390
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.2k
Side Projects
sachag
456
43k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
480
Optimising Largest Contentful Paint
csswizardry
37
4k
Typedesign – Prime Four
hannesfritz
42
3.2k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
550
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
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