---

Pikumei(ぴくめい)

チーム4:KSD(京都産業大学)

背景・課題・解決されること

背景

このハッカソンのテーマは「本当に必要なものをカタチにする」。 そこでまず考えたのは、 人はなぜゲームを他人と遊ぶのかという点だった。

課題

多くのゲームでは、オンライン機能があっても 一人で完結する遊びが成立している。 そのため「誰かと遊ぶこと」は、 なくても困らない付加要素になりやすい。

一方で、身の回りのモノを使った遊びや空想は、 本来は他人と比べたり共有したりすることで価値が生まれる。 しかし、その体験をそのままゲームに落とし込んだプロダクトは存在しない。

解決

Pikumeiでは、他人と関わることを機能として追加するのではなく、 関わらないと遊びきれない構造を前提に設計した。

• 撮影したモノがそのままモンスターになるため、 個体ごとに正解や最適解が存在しない
• 強化（合体）には他人のメイティが必要で、 一人では最大性能に到達できない
• その結果、比較・交換・相談が自然に発生する

Pikumeiにおける「人との関わり」は目的ではなく、 この遊びを成立させるために必要な要素である。

プロダクト説明

機能	概要
メイティスキャン	カメラで撮影 → Vision API で被写体を自動切り抜き → CoreML（PikumeiClassifier2）で 7 タイプ（Fire / Water / Leaf / Ghost / Human / Fish / Bird）に分類 → 名前を付けて保存
リアルタイム対戦	Supabase Realtime Broadcast を使った P2P ターン制バトル。タイプ相性（1.5 倍 / 0.5 倍）・ステータス（HP / 攻撃 / 特攻 / 特防）による戦略的な戦闘
CPU 対戦	一人でも遊べるソロバトルモード（決定論的 AI）
モンスター交換	Supabase を介した P2P 交換。5 分以内のマッチング・RLS によるセキュアなトランザクション
モンスター合体	自分のモンスター × 交換で得たモンスターを合体。画像は左右合成、ステータスは平均値 +10% ブーストで新たなモンスターが誕生
コレクション管理	タイプ別グリッド表示・レーダーチャートによるステータス可視化・バトル履歴

操作説明・デモ動画

メイティ召喚

scan.MP4

バトル

battle.mp4

メイティ交換

exchange.mp4

メイティ合体

fusion.MP4

注力したポイント

アイデア面

• ユーザーの動線を徹底的に設計
  • スキャン → バトル → 強いメイティには勝てない → 合体すれば強くなれる
  • 合体には「誰かとメイティを交換」が必要、という自然な流れを構築
• Subject Liftingで身の回りのものをなんでもスキャン可能
  • 家、ポスト、人形、フィギュアなど、日常のあらゆるものがメイティになる
• 機械学習によるタイプ自動判定
  • スキャン対象から自動でタイプが決まり、タイプごとにステータス傾向が異なる
    （例：人間タイプは防御力が高い、とりタイプは攻撃特化）
• ゴーストタイプと合体のバランス設計
  • ゴーストタイプは他タイプより強いが、合体で「片方の高いステータス継承 +10%ボーナス」により対抗可能
  • 合体には他ユーザーとのメイティ交換が必須 → 交流を促進する仕組み
• CPU対戦・対人対戦の両方に対応

デザイン面

• Figmaで可愛さにこだわったデザイン
• アイコンやUI崩れが起きないよう徹底的に調整

使用技術

アーキテクチャ：MVVM

• View（SwiftUI）/ ViewModel（状態管理・処理）/ Model（struct/enum + SwiftData）の明確な責務分離
• ハッカソンの開発スピードと可読性を両立するため、過度な抽象化（Repository / UseCase）を排除したシンプルな設計

技術選定の妥当性：

技術	選定理由
CoreML + Vision	オンデバイスで高速な画像分類と被写体検出を実現。ネットワーク不要で即座に結果を返せる
Vision API（VNGenerateForegroundInstanceMaskRequest）	Apple 純正の被写体切り抜き機能。精度が高く、ゲーム用の透過 PNG をリアルタイムに生成できる
Supabase（PostgreSQL + Realtime + Anonymous Auth）	BaaS としてリアルタイム通信・認証・RLS を一括提供。ハッカソンの短期開発に最適
SwiftData	ローカルでのモンスター画像（外部ストレージ）やバトル履歴の永続化に Apple 純正の ORM を採用
Lottie	勝利・敗北演出などゲーム性を高めるアニメーションを少ない工数で実現

設計上の工夫：

• ML の分類信頼度が 0.5 以下の場合は Ghost タイプに変換する「不明 → ゴーストタイプ」のフォールバック設計
• 信頼度 [0.5, 1.0] をステータス値にマッピングし、ML の出力がゲーム性に直結する仕組み
• サムネイル（200×200 JPEG）生成による効率的なクラウド同期

使用素材・クレジット (Credits)

効果音

• OtoLogic(https://otologic.jp/)
• 効果音ラボ(https://soundeffect-lab.info/)

---

チーム内ルール（開発用）

アーキテクチャ

• 基本構成：Model / View / ViewModel / Logic
• UI とロジックは分離する

ファイル構成

Pikumei/
├── Model/            # アプリ内で扱うデータ構造（struct / enum）
│   └── ...

├── View/             # SwiftUI の画面
│   ├── Screens/      # 各画面（Scan / Result / Battle など）
│   └── Components/   # 再利用する UI コンポーネント

├── ViewModel/        # 状態管理・処理の呼び出し
│   ├── Logic/        # ゲームロジック（ステータス計算・バトル処理）
│   ├── ML/           # CoreML / Vision による分類処理
│   └── Camera/       # カメラ制御・画像取得

├── Utils/            # Extension 類
│   └── Extensions/
│       └── ...

├── Library/          # 非コードリソース
│   ├── Assets/       # 画像・色など
│   ├── MLModels/     # .mlmodel ファイル
│   └── Preview/      # SwiftUI Preview 用

ブランチルール

• main：発表・デモ用
• develop：開発用
• feature/〇〇：機能開発

コンフリクト時の対応

• コンフリクト状態を一度コミットする
• その後、修正した内容を別コミットとして追加する

コミットルール

• コミットメッセージは日本語
• 変更の粒度を意識する（1コミット1変更）