必殺技ロジックの実装を 半自動化する機構を作った話

Transcript

1. 必殺技ロジックの実装を 半自動化する機構を作った話 きょーま @Akatsuki
2. 自己紹介 • 2018年 新卒入社（2021年4月で4年目） • クライアントエンジニア ◦ 新機能作ったり、バグ直したり、たまに企画書いたり • 趣味はゲームとお絵描き 最近は毎日１冊以上ラノベ読んでる
3. 毎回エンジニア実装が必要な必殺技を どんなフローで運用しているのか という話をします
4. 必殺技とは • 特定のキャラが持ってる • 条件を満たすと発動できる • 個性を出すためキャラごとに条件・効果が違う • 例 ◦ このキャラのターンの時、攻撃力+3000、速度+1000 ◦ このキャラのターンで敵を倒した場合、ターン終了時に特定のスキルを付与 ◦ ※ 実際には存在しない架空の必殺技です
5. 必殺技ができるまで 1. 運用チームが大体の内容を議論 2. エンジニアと検証チームで実現方法を議論 3. エンジニアが実装、新機能がある場合は検証 4. バランス調整 5. リリース！ ίίͷ ࿩
6. なぜ毎回エンジニア実装が必要なのか • 必殺技は、ゲームロジックの中ならなんでもできるって思想で作られている • つまり、仕組みとしてあまり型が決まっていないので、 多少効果が変わろうが、毎回新しいことをしようが大体は実現できる • もし、実装無しでパラメータ入力だけでできるようすると、 ある程度型を固めないといけない = できることが減る、望むところではない • とはいえ、毎回似るようなところは考えなくていいようにしたい
7. 必殺技はどのように実装されているのか • 1つの必殺技につき1つのスクリプトファイルがあって、条件と効果を記述 ◦ 条件は既存のものの組み合わせだけである程度実現可能 ◦ 効果はベーシックな効果と今まで存在しなかった効果に分けられる • 本当に毎回考えないといけないのは、今まで存在していなかった効果の部分 ◦ スクリプトを生成して、条件とよく使う効果の部分は機械的に実装できる
8. どこを自動化するの？ • ベーシックな部分を自動化 ◦ 条件は汎用的なものが多いので、ほぼ全てパラメータで対応可能 ◦ 効果は値をいじる系全般はパラメータで対応可能 • 例 ◦ このキャラのターンで、このスキルを発動させた時 : ここはパラメータで可能 ◦ 攻撃力+3000、速度+1000 : ここもパラメータで可能 ◦ この必殺技で敵を倒した場合、 ランダムな相手のキャラの全能力-20% : ここは幅が広すぎて無理
9. どうやって自動化したの？ • Jenkinsでパラメータを入力したらリポジトリにPRが飛ぶように自動化 ◦ 元々Jenkinsを使った運用フローがあるのでメンバーが理解しやすい ◦ パラメータはどんな条件にするか、どの効果をどんな値にするかなど ύϥϝʔλ ʢखಈʣ 1VMM
   3FRVFTU Ϛʔδ͸खಈ
10. Jenkinsで何やってるの？ • シェルスクリプトでコードジェネレート ◦ 雛形を元に、sedコマンドでパラメータに対応するタグを置換 ▪ Attack = <PARAM_ATTACK> みたいなのを Attack = 3000 に置き換える • Github CLIでPR化 ◦ Githubをコマンドラインから操作できるようにする公式ツール ◦ 去年の9月にv1.0がリリースしたばかり！ ▪ https://github.com/cli/cli ◦ gh pr create -t “タイトル” -b “説明文” -B “対象ブランチ” でPRを作れる
11. 半自動化の恩恵 • エンジニアは新しく増える効果の実装に集中できる ◦ 他の作業と並行してやるので、コンテキストスイッチを切り替えるのが大変だった • ベーシックな必殺技の実装ならエンジニア不要 • コードジェネレートに使われるコードは全てテストされている ◦ 生成時点でユニットテスト完了扱い、効果としての組み合わせに完全に注目できる ◦ ついでに人為ミスの可能性も減る
12. まとめ • 継続的になんらかのコストが発生するようなものは、 ◦ 専属の人がいないとどうしようもない部分はできるだけ減らそう！ ◦ 減らせなくても負担が軽くなるようにしよう！ ◦ 仕組みはドキュメント化しよう！