ID:82411さん

# スロットマシンゲーム「瘋狂大鱸魚骰子」 ## プロジェクト経験概要 東南アジア向けモバイル(iOS/Android)スロットゲームの新規開発。ベット→リール回転→シンボルがラインに揃うと配当の基本フローに加え、フリースピンモードや漁師シンボルが盤面上の魚シンボルの金額を収集する独自演出を持つ。 ## チーム情報 BE1・FE2・企画1の4名体制、約3ヶ月で開発完了。使用技術：Cocos2d-x 2.2.6 / Lua 5.1 / GitLab。 私はBEとゲームコマンド・イベントのAPI定義を策定した上で、ゲーム全体のアーキテクチャ設計・リールコンポーネント開発・演出フロー実装を担当。もう1名のFEは操作UIを担当。各担当を並行開発し、最終的にフロー・UI・Socket通信を結合した。 ## 開発・実装内容A：ゲーム主フロー 【概要】ゲームルーム入室からスピン開始・結果判定・配当までの一連のゲーム主フローを設計・実装した。通常モードとフリースピンモードの2つのゲームモードを持ち、各モードで速度切替・自動スピンの状態管理が必要。 【どのような機能の開発・実装か】プレイヤーの操作（ゲームルーム入室・スピン開始・スピン継続等）をSocket通信でサーバーに送信し、サーバーからのスピン結果を受信して演出を実行、配当を表示するまでの主フローを実装。 【課題・問題点】ゲーム状態管理と演出ロジックが混在しやすく、モード追加時に既存コードへの影響範囲が読めなくなるリスクがあった。 【打ち手・使用した技術】チーム合意のもとClean Architectureを採用し、私が具体的な設計を主導。操作を「コマンド」、応答を「イベント」としてアプリケーション層のユースケースに整理。ゲームモード・速度・自動状態はドメイン層、演出はフレームワーク層に分離した。新モード追加時にユースケース追加のみで対応できる拡張性を実現。 ## 開発・実装内容B：リールコンポーネント 【概要】スロットのリール（輪帯）の回転・停止アニメーションコンポーネントを設計・実装した。 【どのような機能の開発・実装か】5本のリールがそれぞれ回転し順番に停止する基本動作に加え、特殊シンボルが2つ出現した場合に最後の2軸で減速演出を行いプレイヤーの期待感を高める仕掛けを実装。 【課題・問題点】通常速度では各リールが順番に停止するが、高速モードでは全リールが同時に落下する。ただし特殊シンボルが2つ出現した場合は高速モードでも最後の2軸が減速演出に切り替わる。速度×特殊シンボル出現数の組み合わせで複数のタイミングパターンが生じる。 【打ち手・使用した技術】`getDelayTime(columnIndex, speed)`のような意味論的関数でタイミング条件を外部化し、各リールの落下完了をPromise.all相当の並行awaitで待つ設計にすることで可読性を確保した。 ## 開発・実装内容C：フリースピン漁師収集演出（個人で設計・開発） 【概要】フリースピンモード内の独自コレクション機能として、漁師シンボルが盤面上の魚シンボルの金額を収集する演出フローを設計・実装した。 【どのような機能の開発・実装か】漁師シンボル出現時に、登場アニメーション→盤面に魚シンボルがあるか判定→ある場合は収集アニメーション実行（ない場合はスキップ）→累積数の更新アニメーション、という分岐を含む多段階の演出フローを実装。 【課題・問題点】従来のcallbackベースの実装ではネストが深くなり、どのcallbackがどこに登録されているか追跡困難で、演出の順序変更や追加時に副作用を生むリスクが高かった。 【打ち手・使用した技術】Lua coroutineを活用しJavaScriptのasync/awaitに相当する非同期フロー制御ツールを設計・開発。演出フローを同期的に記述可能にし、追加・順序変更時にcallbackの登録関係を再整理する必要がない構造を実現した。 ## 成果 - async/awaitツールとClean Architectureの導入により、同規模の他プロジェクトと比較して演出関連のバグ報告が約25%減少 - 非同期ツールは後続の同シリーズプロジェクトでも採用された - 新モード追加がユースケース追加のみで完結する拡張性を実現

# スロットマシンゲーム「火山女神」 ## プロジェクト経験概要 東南アジア向けモバイル(iOS/Android)スロットゲームの新規開発。ベット→リール回転→シンボルがラインに揃うと配当の基本フローを持つ。ベット方法は通常ベットと高倍率ベットの2種類があり、高倍率ベットでは次回スピンで確定的にフリーまたはスピン強化モードに突入する。これらに加え抽選モードもあり、4モードのうち2つは専用盤面の独立したミニゲームとして動作する。 ## チーム情報 BE1・FE3・企画1の5名体制、約3ヶ月で開発完了。使用技術：Cocos2d-x 2.2.6 / Lua 5.1 / GitLab。 私はBEとAPI定義を策定した上で、ゲーム全体のフロー設計・主プログラム実装を担当。他のFEメンバーは操作UIとリールコンポーネントを担当。 ## 開発・実装内容：ゲーム主フローのモード遷移管理 【概要】通常モードを起点に、フリー・スピン強化・抽選の各モードへ条件分岐で遷移し、最終的に通常モードへ戻る一連のゲーム主フローを設計・実装した。 【どのような機能の開発・実装か】通常モードのスピン結果に応じてフリーまたはスピン強化モードに分岐し、その後さらに抽選モードに入る可能性がある遷移フロー全体を管理する主プログラムを実装。4モードのうち2つは専用盤面と独自演出を持つ事実上のミニゲームであり、進入条件やスピンの概念もそれぞれ異なる。 【課題・問題点】これらのモードを一つのフローに直列で記述すると巨大化し、モード単位の修正やデバッグが困難になるリスクがあった。 【打ち手・使用した技術】各モードを独立オブジェクトとしてカプセル化し、主フローからLua coroutineでモード処理を委譲、モード終了時にcoroutine.resumeで主フローの呼び出し元に復帰する設計とした。これにより主フローはモード分岐判定のみに集中し、各モードの開発・修正・デバッグを互いに影響なく独立して進められる構造を実現。 ## 成果 - 各モードの開発・修正・デバッグが独立し並行開発可能になった - この非同期フロー管理の知見を後続プロジェクト「瘋狂大鱸魚骰子」でasync/awaitツールとして汎用化・発展させた

# スロットマシンゲーム「糖果狂熱」 ## プロジェクト経験概要 東南アジア向けモバイル(iOS/Android)スロットゲームの新規開発。従来のリール回転式ではなく、シンボルが上から落下するドロップ式の盤面を採用。一定数以上の同一シンボルが隣接して繋がると配当となり、消去後に新たなシンボルが落下して連鎖が発生する。消去された位置には倍率表示（1→2→4→...→1024）が蓄積され、通常モードでは毎スピンでリセットされるが、フリーモードでは連続スピン中（例：10回）蓄積が維持される。ベット方法は通常ベットと高倍率ベットの2種類があり、高倍率ベットではフリーまたはスーパーモードに確定突入する。 ## チーム情報 BE1・FE3・企画1の5名体制、約2ヶ月で開発完了。使用技術：Cocos2d-x 2.2.6 / Lua 5.1 / GitLab。 私はBEとAPI定義を策定した上で、盤面コンポーネント全体（シンボル落下・消去・連鎖・倍率蓄積・配当演出）の設計・実装を担当。他のFEメンバーは操作UIと主フローを担当。 ## 開発・実装内容：ドロップ式盤面コンポーネント 【概要】シンボルの落下→隣接判定→配当演出→消去→連鎖落下という一連の盤面動作と、消去位置に蓄積する倍率表示の管理を含む盤面コンポーネントを設計・実装した。 【どのような機能の開発・実装か】スピン開始後、盤面全体に新しいシンボルが上から落下する。配当成立時は該当シンボルのSpine消去アニメーションを再生し、非該当シンボルは透明度を下げて視覚的に区別する。消去後に空いた位置へ新シンボルが落下し、再度判定を行う連鎖処理を実装。各位置の消去回数に応じた倍率表示の蓄積と、通常モード・フリーモードでのリセットタイミング管理も含む。 【課題・問題点】主に2つの課題があった。第一に、シンボルは主動作レイヤー（落下・消去等のアニメーション）とSpineアニメーションレイヤーの2層に存在し、位置の同期と表示切替タイミングの管理が必要だった。第二に、配当演出時に非該当シンボルの透明度を下げる際、倍率表示が重なったシンボルは一つの単位として透明度を設定できず、個別に設定すると重なり部分に穿透効果が発生する問題があった。 【打ち手・使用した技術】レイヤー構成を3層に整理した。主動作レイヤーではシンボルの落下・移動をbatch描画でdraw callを削減。Spine演出レイヤーは主動作レイヤーより描画優先度を高く設定し、消去アニメーションが常に前面に表示されるようにした。透明度の問題に対しては、個々のシンボルに透明度を設定する方式を廃止し、盤面全体に半透明の背景レイヤーを重ねる方式に変更。Spine演出レイヤーをこの半透明レイヤーの上に配置することで、穿透効果を回避しつつ実装複雑度も低減した。 ## 成果 - レイヤー分離設計により、盤面の描画パフォーマンスと演出品質を両立 - 半透明背景レイヤー方式により、倍率表示付きシンボルの透明度問題を個別対応なしで解決し、実装複雑度を低減

# 小ゲーム管理ツールの改善 ## プロジェクト経験概要 小ゲーム管理ツールは、ゲームエンジニアがゲームプロトタイプを企画担当者に試遊してもらうための社内ツール。エンジニアがVue.jsの管理画面からゲームをローカルサーバー（Express.js）にアップロードし、企画担当者がモバイル端末のスーパーアプリ内ゲームロビー（Cocos2d-x/Lua）からダウンロード・試遊する仕組み。本プロジェクトではこのツールのUX改善と機能追加を行った。 ## チーム情報 エンジニア2名体制。使用技術：Cocos2d-x 2.2.6 / Lua 5.1 / Vue 3 / Express.js / TypeScript。 私はモバイル端末側（C++/Lua）のゲームロビー改修と、Vue.js/Expressへのバージョン管理機能の追加を担当。 ## 開発・実装内容A：ゲームロビーのUX改善 【概要】スーパーアプリ内のゲームロビーから小ゲームに入った後、ロビーに戻って別のゲームを試遊できるように改修した。 【どのような機能の開発・実装か】改修前は小ゲームに入るとアプリを再起動しないとロビーに戻れず、企画担当者が複数のゲームを試遊する際の効率が悪かった。改修後はゲーム終了時にロビーへ直接復帰し、連続して別のゲームを選択・試遊できるようにした。 【課題・問題点】既存のロビーはC++側で実装されており、カスタマイズの柔軟性が低かった。またゲームリスト取得・ダウンロード・削除といったファイル管理APIがLua側に公開されておらず、Lua側でロビーを再実装するための手段がなかった。 【打ち手・使用した技術】toluaのpkgファイルを作成し、ゲームリスト取得・ダウンロード・削除のAPIをC++からLuaへ公開。C++側でゲームリソースのダウンロード・管理コンポーネントを実装し、Lua側でロビーUIを新たに構築してこれらのAPIを呼び出す構成にした。これによりロビーの表示・遷移ロジックがLua側で柔軟に制御可能になった。 ## 開発・実装内容B：小ゲームバージョン管理機能 【概要】エンジニアがゲームプロトタイプを更新した際、モバイル端末のゲームリストに更新通知が表示される仕組みを構築した。 【どのような機能の開発・実装か】改修前はゲームを更新するたびにサーバー上のファイルを手動で削除して再アップロードする必要があり、バージョンの概念がなかった。改修後は同一ゲームのアップロード時にバージョン番号が自動で採番・記録され、モバイル端末側でローカルのバージョンと比較して更新通知を表示する仕組みを実装した。 【課題・問題点】既存のアップロード機能にはバージョン管理の仕組みがなく、エンジニアの更新作業に手間がかかるだけでなく、企画担当者側でも最新版かどうか判別できなかった。 【打ち手・使用した技術】Vue.js/Express.jsの既存コードにバージョン管理ロジックを追加。サーバー側で同一ゲームのアップロード時にバージョン番号を自動採番・記録し、ゲームリストAPIのレスポンスに最新バージョンを含める改修を行った。モバイル端末（Lua）側ではローカルに保持するバージョンとAPIから取得したバージョンを比較し、差分がある場合に更新通知を表示する処理を実装した。 ## 成果 - ロビー改修により、企画担当者がアプリ再起動なしで複数ゲームを連続試遊可能になり、試遊効率が向上 - バージョン管理の導入により、ゲーム更新時の手動削除・再アップロード作業が不要になった