ai21.net
言語

警察追跡アーケードゲームのプロトタイプ

警察追跡アーケードゲームのプロトタイプ — 1警察追跡アーケードゲームのプロトタイプ — 2

プロンプト

PRD — Police Chase Arcade Game

Working title: Heatwave
Platform: iOS + Android
Engine: Unity
Genre: Top-down 3D arcade chase / survival
Orientation: Portrait
Input: One-thumb touch controls
Business model: TBD — design MVP around gameplay first
Primary goal: Build a genuinely fun playable prototype before adding progression or monetization.
⸻
Product vision
A fast, chaotic mobile arcade game where the player is constantly being pursued by increasingly aggressive police.
The player cannot directly attack.
Instead, they survive by driving aggressively, drifting around obstacles, making sudden turns and tricking pursuing police into crashing into obstacles and each other.
The fantasy is:
You’re not stronger than the police. You’re harder to catch.

Runs should produce constant near-misses, chain collisions and moments where the player escapes a seemingly impossible situation.

Think:

easy controls + aggressive pursuit + physics chaos + escalating pressure.

⸻

Core gameplay loop

START RUN
↓
DRIVE / DRIFT
↓
POLICE PURSUE
↓
BAIT POLICE
↓
DODGE
↓
POLICE CRASH
↓
GAIN SCORE
↓
WANTED LEVEL INCREASES
↓
MORE / HARDER POLICE
↓
SURVIVE
↓
EVENTUALLY GET CAUGHT
↓
SCORE / RESTART

Target run duration:

2–5 minutes.

Restart should take less than 2 seconds.

⸻

Design principles

3.1 One-thumb playable

The player should be able to understand the controls within seconds.
No accelerator.
No brake pedal.
No virtual steering wheel.
The vehicle moves automatically.
The player controls only direction.

(I moved away from this after testing it the first time and added the onscreen joystick)

3.2 Arcade physics, not simulation
Vehicles should:
drift
slide
bounce
spin
collide dramatically
recover quickly
Fun takes priority over physical accuracy.

3.3 Pursuers are weapons
Police are effectively the player’s offensive mechanic.
The player should learn:
“If I turn here, that cop is going straight into that wall.”
3.4 Chaos should remain readable

Even with 10+ vehicles on screen, the player must immediately understand:
where they are
where they’re moving

where police are coming from

what can kill them

3.5 Failure should feel fair

Death should generally result from a mistake the player understands rather than unpredictable physics.

⸻

MVP scope

Do not build progression, upgrades, missions or monetization for the first milestone.

The first version contains:

1 player vehicle

1 arena

1 police vehicle

1 elite police variant

5 wanted levels

physics collisions

environmental obstacles
scoring
player health
police destruction
basic VFX
basic audio

game-over screen

instant restart

That’s enough to determine whether the game deserves further development.

⸻

Player vehicle

Movement

Player vehicle uses a Rigidbody-based arcade controller.

Do not rely heavily on realistic WheelColliders.
Core variables should be exposed in the Unity Inspector:
Acceleration
Maximum Speed
Turn Speed
Turn Curve
Lateral Grip
Drift Factor
Vehicle Mass
Collision Force
Drag
Angular Drag
Recovery Speed
These need to be extremely easy to tune.

⸻

Controls

Recommended first implementation:

Drag steering

Player touches anywhere on the lower portion of the screen.

Dragging horizontally controls steering.

← drag          turn left
→ drag          turn right
Vehicle accelerates automatically.
Steering should be relative rather than absolute.
The player should be able to lift their finger without immediately losing control.
Alternative to prototype
Test:
Hold left/right side of screen = steer left/right.
Don’t commit until both have been tested on a physical phone.
⸻
Drift system
Drifting should happen naturally when turning at speed.
No dedicated drift button.
At low speed:
high traction

At high speed:

reduced lateral traction

This produces controlled sliding.

Long drifts can optionally award score.

Example:

DRIFT
+120
LONG DRIFT
+340

But drift scoring is secondary to police destruction.

⸻
Police AI
Police should feel:
aggressive, predictable and slightly stupid.
They should not simply follow the player’s current position.
Instead, calculate an interception target based on player velocity.
Conceptually:
target =
playerPosition
+
playerVelocity * predictionTime
Police therefore try to cut the player off.
⸻
Police intelligence

Police intentionally have limited obstacle avoidance.

This is important.

Perfect navigation would make the game less fun.

Police should:

pursue aggressively

attempt interception

avoid obvious static obstacles

poorly account for other police
overshoot turns

collide with each other

occasionally take dangerous routes

This creates opportunities for the player.

⸻

Police destruction

Police can be destroyed by:

high-speed obstacle collisions

hitting another police vehicle

chain collisions

environmental hazards

The player does not have weapons.

Example scoring:

COP SMASHED
+250
DOUBLE SMASH
+600
TRIPLE SMASH
+1,000
PILEUP!
+2,000

Chain collisions should be heavily rewarded.

⸻

Wanted system

Wanted level controls difficulty.

★☆☆☆☆
★★☆☆☆
★★★☆☆
★★★★☆
★★★★★

Wanted level increases based primarily on survival time and score.
Level 1
2 police.
Slow and forgiving.

Level 2

3–4 police.

Slightly faster.

Level 3

5–6 police.

More aggressive interception.

Level 4

7–9 police.

Elite police introduced.
Level 5
Maximum chaos.
10+ police depending on device performance.

Elite units appear frequently.

The game should eventually become effectively impossible.

That’s intentional.

⸻

Elite police

The MVP only needs one special police type.

Interceptor

Visually distinct vehicle.
Characteristics:
faster than standard police
lower mass
aggressive prediction
sharp steering
easier to destroy in collisions

This creates a glass-cannon pursuer.

⸻

Player health

Use a simple health bar.

Example:
HULL
██████░░░░
Minor impacts:
small damage.

Heavy impacts:

large damage.

Extremely high-speed impacts:
potential instant destruction.
Police contact alone shouldn’t immediately kill the player.
This allows chaotic scrambles.
⸻
Arena
First arena should be compact.
Something roughly equivalent to:

ROCK

┌─────────────┐
│             │
│   ROCK      │
│             │
│       ███   │
│             │
│ ROCK        │
│         ROCK│
└─────────────┘

Obstacles need enough space between them for high-speed movement.

Avoid procedural generation initially.

Hand-design one good arena.
⸻
Environment
For the first visual theme, I’d use something other than water so we’re not cloning the reference too closely.
My preference:

Desert outlaw chase

Player is an outlaw escaping through a stylized desert environment.

Environment contains:

rock formations

cacti

barriers

abandoned vehicles

ramps

fences

small buildings

dust

destructible props

It also fits the chunky visual language you’re already exploring with Bolt Pit.

⸻

Camera

Top-down perspective camera.

Not completely vertical.

Something approximately:

55–70° downward angle.

Camera follows player with smoothing.

Camera should look slightly ahead in the player’s travel direction.

At high speed:

camera pulls back slightly.

At low speed:

camera moves closer.

⸻
Camera juice
Small camera effects make a large difference.
Light collision
Tiny shake.

Heavy collision

Strong short shake.

Police destruction

Shake + tiny freeze frame.

Example:

50–100 ms hit stop.
Large pileup

Slight zoom impulse + shake + particles.

Don’t overdo continuous shaking.

⸻

Visual style

Chunky stylized 3D.

Characteristics:

simplified geometry

exaggerated proportions

bright readable vehicles

soft lighting

minimal textures

strong silhouettes

exaggerated particles
Avoid realistic vehicle proportions.
Cars should feel almost toy-like.
⸻
VFX
Minimum MVP effects:
Player
dust trail
tire/skid marks
drift smoke

impact sparks

Police

siren lights

smoke when damaged

destruction explosion

debris

Environment

dust

destructible objects

impact particles

⸻
Collision feedback
Every significant collision should combine:
physics + particles + audio + camera response.
Major police destruction:
IMPACT
→ physics impulse
→ vehicle fragments/debris
→ sparks
→ smoke
→ camera shake
→ hit stop
→ sound
→ score popup
This interaction is one of the game’s main sources of satisfaction.
⸻
Score system

Score comes from:

ActionExample
Surviving+10/sec
Police destroyed+250
Driftvariable
Near miss+100
Double collision+600
Triple collision+1,000
Large pileup+2,000

Exact values should remain configurable.

⸻

Near misses

Optional for MVP but potentially valuable.

Detect when a police vehicle passes extremely close to the player at high relative velocity.

Display:

CLOSE CALL! +100

This rewards risky driving.

⸻

UI

During gameplay keep UI extremely minimal.

SCORE                          COINS
13,590                          14
★★★☆☆
WANTED
GAME
HULL
████████░░

No minimap initially.

Off-screen police can use subtle edge indicators.

⸻

Game over

When hull reaches zero:

brief slow motion.

Player crashes.

Then:

BUSTED
SCORE
24,850
BEST
31,220
[ AGAIN ]

Tapping anywhere could restart.

Avoid unnecessary menus between runs.

⸻

Audio

The soundscape should sell speed and collisions.

Required:

engine

tire squeal

police sirens
impact
metal crunch
debris
destruction
UI score sounds
wanted level increase

Sirens should become increasingly chaotic as wanted level increases.

⸻

Technical architecture

Suggested Unity structure:

GameManager
Player
├── PlayerController
├── VehiclePhysics
├── PlayerHealth
└── PlayerEffects
Police
├── PoliceController
├── PoliceAI
├── VehiclePhysics
├── PoliceHealth
└── PoliceEffects
Systems
├── SpawnManager
├── WantedManager
├── ScoreManager
├── AudioManager
├── CameraManager
└── PoolManager
UI
├── HUD
├── WantedUI
├── ScoreUI
├── HealthUI
└── GameOverUI

Avoid building an elaborate framework.

⸻
Object pooling
Police, particles and debris should use object pooling.
Avoid frequent:

Instantiate()
Destroy()

during gameplay.
Mobile performance should be considered from the beginning.
⸻
Performance target

Target:

60 FPS
on a mid-range modern iPhone/Android device.
Initial limits:

~12 active vehicles

~100 simple debris/particles

simple shadows

limited real-time lights

Performance should be tested on device early.

⸻
Development milestones
Milestone 1 — Greybox driving
Build:
empty arena
cube player
touch steering
acceleration
drifting

camera

Success criterion:

Driving around an empty arena feels satisfying.

Do not continue until it does.

⸻
Milestone 2 — The chase
Add:
one police vehicle
pursuit AI
interception
collisions
Success criterion:

Dodging one police car is entertaining.

⸻

Milestone 3 — Emergent chaos

Add:

multiple police

police-police collisions

obstacles

destruction

scoring

Success criterion:

Player can intentionally cause:

police → police
and
police → environment
collisions.
This is the critical milestone.
⸻
Milestone 4 — Escalation

Add:

wanted levels

spawning

difficulty scaling

interceptor

Now a run has an arc:

calm
↓
pressure
↓
chaos
↓
panic
↓
death

⸻

Milestone 5 — Juice
Add:
particles
camera shake
hit stop
skid marks

dust

sirens

collision sounds

score popups

⸻

Milestone 6 — Mobile build

Build for real devices.
Test:
controls
performance
readability
battery/thermal behaviour
different screen ratios
⸻
Milestone 7 — Decide whether to continue

At this point, stop development temporarily.

Don’t immediately build a garage and 37 unlockable cars.

Put the build in front of people.

The important questions are:

Do people immediately understand it?
Do they restart after dying?
Do they intentionally try to make cops crash?
Does “one more run” happen naturally?
If not, work on the core loop rather than adding content.
⸻
Phase 2 — only after validation
If the prototype works, then expand into:
Cars
↓
Coins
↓
Unlocks
↓
Challenges
↓
New arenas
↓
Special police
↓
Upgrades
↓
Daily challenges
↓
Leaderboards
Potential environments:
desert
city
docks
snow
industrial yard
airport
construction site
military base
And then there’s room for ridiculous police units: SUVs, armored vans, helicopters dropping roadblocks, etc.

I have opened a @[Unity CLI installation] project which we can work in. The art style of the game should be fun and cartoony and the action also over the top.
I have imported the Topdown engine into the project as well that we can use:
https://topdown-engine.moremountains.com/

I want the game to be optimized for mobile, but should work on desktop while testing.

日本語訳

PRD — 警察追跡アーケードゲーム

仮タイトル:Heatwave
プラットフォーム:iOS + Android
エンジン:Unity
ジャンル:トップダウン3Dアーケードチェイス/サバイバル
画面の向き:縦(ポートレート)
入力:親指1本のタッチ操作
ビジネスモデル:未定 — まずゲームプレイを中心にMVPを設計する
主要目標:進行要素やマネタイズを追加する前に、本当に楽しく遊べるプロトタイプを作る。
⸻
プロダクトビジョン
プレイヤーがますます攻撃的になる警察に常に追われ続ける、高速で混沌としたモバイルアーケードゲーム。
プレイヤーは直接攻撃できない。
その代わり、アグレッシブに走り、障害物の周りでドリフトし、急旋回し、追跡してくる警察を騙して障害物や互いに衝突させることで生き延びる。
このゲームのファンタジーは:
警察より強いわけではない。捕まりにくいのだ。

ランでは、絶え間ないニアミス、連鎖衝突、そしてプレイヤーが不可能に見える状況から逃げ切る瞬間が生まれるべきだ。

イメージ:

簡単な操作 + アグレッシブな追跡 + 物理の混沌 + 高まるプレッシャー。

⸻

コアゲームプレイ・ループ

ラン開始
↓
走行 / ドリフト
↓
警察が追跡
↓
警察を誘導
↓
回避
↓
警察が衝突
↓
スコア獲得
↓
手配レベル上昇
↓
警察が増加 / 強化
↓
生き延びる
↓
最終的に捕まる
↓
スコア / リスタート

目標ラン時間:

2–5分。

リスタートは2秒未満で完了すべき。

⸻

デザイン原則

3.1 親指1本で遊べる

プレイヤーは数秒以内に操作を理解できるべきだ。
アクセルなし。
ブレーキペダルなし。
バーチャルステアリングホイールなし。
車両は自動的に進む。
プレイヤーが操作するのは方向だけ。

(最初のテスト後にこの方式から離れ、画面上のジョイスティックを追加した)

3.2 シミュレーションではなくアーケード物理
車両は次のように:
ドリフトする
スライドする
跳ね返る
スピンする
ドラマチックに衝突する
素早く体勢を立て直す
物理的な正確さよりも楽しさを優先する。

3.3 追跡者は武器である
警察は事実上、プレイヤーの攻撃手段である。
プレイヤーは次のことを学ぶべきだ:
「ここで曲がれば、あの警官はまっすぐあの壁に突っ込む」
3.4 混沌は読み取れる状態を保つべき

画面に10台以上の車両があっても、プレイヤーは即座に理解できなければならない:
自分がどこにいるか
自分がどこへ向かっているか

警察がどこから来るか

何が自分を殺しうるか

3.5 失敗はフェアに感じられるべき

死は基本的に、予測不能な物理ではなく、プレイヤーが理解できるミスから生じるべきだ。

⸻

MVPスコープ

最初のマイルストーンでは、進行要素、アップグレード、ミッション、マネタイズを作らないこと。

最初のバージョンに含むもの:

プレイヤー車両1台

アリーナ1つ

警察車両1台

エリート警察バリアント1種

手配レベル5段階

物理衝突

環境障害物
スコアリング
プレイヤーの体力
警察の破壊
基本的なVFX
基本的なオーディオ

ゲームオーバー画面

即時リスタート

これだけで、このゲームがさらなる開発に値するかを判断できる。

⸻

プレイヤー車両

移動

プレイヤー車両はRigidbodyベースのアーケードコントローラーを使う。

リアルなWheelCollidersに大きく依存しないこと。
主要な変数はUnity Inspectorで公開する:
加速度
最高速度
旋回速度
旋回カーブ
横方向のグリップ
ドリフト係数
車両の質量
衝突力
抗力(ドラッグ)
角抗力(アンギュラードラッグ)
復帰速度
これらは極めて調整しやすくする必要がある。

⸻

操作

最初に推奨する実装:

ドラッグステアリング

プレイヤーは画面下部のどこにでも触れる。

水平方向にドラッグすると操舵できる。

← ドラッグ          左へ旋回
→ ドラッグ          右へ旋回
車両は自動的に加速する。
操舵は絶対値ではなく相対式にするべきだ。
プレイヤーは指を離しても即座に操作を失わないようにするべきだ。
プロトタイプ用の代替案
テスト:
画面の左右を押し続ける = 左/右へ操舵。
実機のスマートフォンで両方をテストするまで確定しないこと。
⸻
ドリフトシステム
ドリフトは速度を出した状態で曲がると自然に発生するべきだ。
専用のドリフトボタンはなし。
低速時:
高いトラクション

高速時:

横方向のトラクション低下

これにより制御されたスライドが生まれる。

長いドリフトには任意でスコアを与えてもよい。

例:

DRIFT
+120
LONG DRIFT
+340

ただしドリフトのスコアリングは警察の破壊に次ぐ副次的なものだ。

⸻
警察AI
警察は次のように感じられるべきだ:
攻撃的で、予測可能で、少し愚か。
単にプレイヤーの現在位置を追うだけにしてはいけない。
代わりに、プレイヤーの速度に基づいて迎撃目標を計算する。
概念的には:
target =
playerPosition
+
playerVelocity * predictionTime
したがって警察はプレイヤーの進路を先回りして塞ごうとする。
⸻
警察の知能

警察は意図的に障害物回避を限定されている。

これは重要だ。

完璧なナビゲーションはゲームをより面白くなくする。

警察は次のようにするべきだ:

攻撃的に追跡する

迎撃を試みる

明らかな静的障害物を避ける

他の警察を十分に考慮しない
旋回でオーバーシュートする

互いに衝突する

時々危険なルートを取る

これがプレイヤーに機会を生む。

⸻

警察の破壊

警察は次の方法で破壊できる:

高速での障害物衝突

別の警察車両への激突

連鎖衝突

環境の危険物

プレイヤーは武器を持たない。

スコアの例:

COP SMASHED
+250
DOUBLE SMASH
+600
TRIPLE SMASH
+1,000
PILEUP!
+2,000

連鎖衝突には大きく報酬を与えるべきだ。

⸻

手配システム

手配レベルが難易度を制御する。

★☆☆☆☆
★★☆☆☆
★★★☆☆
★★★★☆
★★★★★

手配レベルは主に生存時間とスコアに基づいて上昇する。
レベル1
警察2台。
遅く、寛容。

レベル2

警察3–4台。

やや速い。

レベル3

警察5–6台。

より攻撃的な迎撃。

レベル4

警察7–9台。

エリート警察を導入する。
レベル5
最大の混沌。
デバイス性能に応じて警察10台以上。

エリートユニットが頻繁に出現する。

ゲームは最終的に事実上不可能になるべきだ。

それは意図的だ。

⸻

エリート警察

MVPには特殊な警察タイプが1種類あればよい。

インターセプター

見た目がはっきり異なる車両。
特徴:
標準の警察より速い
質量が小さい
攻撃的な予測
鋭い操舵
衝突で破壊されやすい

これによりガラスキャノン型の追跡者が生まれる。

⸻

プレイヤーの体力

シンプルな体力バーを使う。

例:
HULL
██████░░░░
軽い衝突:
小さなダメージ。

強い衝突:

大きなダメージ。

極端な高速衝突:
即座に破壊される可能性。
警察との接触だけでプレイヤーが即死してはいけない。
これにより混沌とした立て直しが可能になる。
⸻
アリーナ
最初のアリーナはコンパクトにするべきだ。
おおよそ次のようなもの:

ROCK

┌─────────────┐
│             │
│   ROCK      │
│             │
│       ███   │
│             │
│ ROCK        │
│         ROCK│
└─────────────┘

障害物同士の間には、高速移動に十分なスペースが必要だ。

最初はプロシージャル生成を避ける。

良いアリーナを1つ手作業で設計する。
⸻
環境
最初のビジュアルテーマには、リファレンスをあまり忠実にコピーしないよう、水以外のものを使いたい。
自分の好み:

砂漠のアウトロー追跡

プレイヤーはアウトローとして様式化された砂漠環境を逃走する。

環境に含むもの:

岩の形成物

サボテン

バリア

放置された車両

ランプ(ジャンプ台)

フェンス

小さな建物

砂埃

破壊可能なプロップ

また、すでにBolt Pitで探求しているチャンキーなビジュアル言語にも合う。

⸻

カメラ

トップダウン視点のカメラ。

完全に真上ではない。

おおよそ次のような:

下向き55–70°の角度。

カメラはスムージングしながらプレイヤーを追従する。

カメラはプレイヤーの進行方向の少し先を見るべきだ。

高速時:

カメラは少し引く。

低速時:

カメラは近づく。

⸻
カメラのジュース
小さなカメラエフェクトが大きな違いを生む。
軽い衝突
小さな揺れ。

強い衝突

強く短い揺れ。

警察の破壊

揺れ + 小さなフリーズフレーム。

例:

50–100 ms のヒットストップ。
大規模な玉突き

わずかなズームインパルス + 揺れ + パーティクル。

継続的な揺れをやり過ぎないこと。

⸻

ビジュアルスタイル

チャンキーで様式化された3D。

特徴:

簡略化されたジオメトリ

誇張されたプロポーション

明るく読み取りやすい車両

柔らかなライティング

最小限のテクスチャ

強いシルエット

誇張されたパーティクル
リアルな車両のプロポーションは避ける。
車はほとんどおもちゃのように感じられるべきだ。
⸻
VFX
MVPの最小エフェクト:
プレイヤー
砂埃の軌跡
タイヤ/スキッドマーク
ドリフトスモーク

衝突の火花

警察

サイレンライト

損傷時の煙

破壊の爆発

デブリ

環境

砂埃

破壊可能なオブジェクト

衝突パーティクル

⸻
衝突フィードバック
重要な衝突はすべて次の要素を組み合わせるべきだ:
物理 + パーティクル + オーディオ + カメラの反応。
大きな警察の破壊:
衝突
→ 物理インパルス
→ 車両の破片/デブリ
→ 火花
→ 煙
→ カメラの揺れ
→ ヒットストップ
→ サウンド
→ スコアポップアップ
この相互作用が、このゲームの満足感の主要な源泉の一つだ。
⸻
スコアシステム

スコアは次から得られる:

行動例
生存+10/秒
警察を破壊+250
ドリフト可変
ニアミス+100
ダブル衝突+600
トリプル衝突+1,000
大規模な玉突き+2,000

正確な値は設定可能なままにするべきだ。

⸻

ニアミス

MVPでは任意だが、価値がある可能性がある。

警察車両が高い相対速度でプレイヤーの極めて近くを通過したときに検出する。

表示:

CLOSE CALL! +100

これにより危険な運転に報酬を与える。

⸻

UI

ゲームプレイ中はUIを極限まで最小限に保つ。

SCORE                          COINS
13,590                          14
★★★☆☆
WANTED
GAME
HULL
████████░░

最初はミニマップなし。

画面外の警察には控えめな端のインジケーターを使える。

⸻

ゲームオーバー

船体(HULL)がゼロになったら:

短いスローモーション。

プレイヤーがクラッシュする。

その後:

BUSTED
SCORE
24,850
BEST
31,220
[ AGAIN ]

どこをタップしてもリスタートできるようにする。

ラン間の不要なメニューは避ける。

⸻

オーディオ

サウンドスケープでスピードと衝突を感じさせるべきだ。

必須:

エンジン

タイヤの軋み

警察のサイレン
衝撃
金属の軋み
デブリ
破壊
UIのスコア音
手配レベルの上昇

手配レベルが上がるにつれて、サイレンはますます混沌としていくべきだ。

⸻

技術アーキテクチャ

推奨するUnityの構成:

GameManager
Player
├── PlayerController
├── VehiclePhysics
├── PlayerHealth
└── PlayerEffects
Police
├── PoliceController
├── PoliceAI
├── VehiclePhysics
├── PoliceHealth
└── PoliceEffects
Systems
├── SpawnManager
├── WantedManager
├── ScoreManager
├── AudioManager
├── CameraManager
└── PoolManager
UI
├── HUD
├── WantedUI
├── ScoreUI
├── HealthUI
└── GameOverUI

凝ったフレームワークの構築は避ける。

⸻
オブジェクトプーリング
警察、パーティクル、デブリはオブジェクトプーリングを使うべきだ。
以下を頻繁に行うことを避ける:

Instantiate()
Destroy()

ゲームプレイ中に。
モバイル性能は最初から考慮するべきだ。
⸻
パフォーマンス目標

目標:

60 FPS
中価格帯の最新iPhone/Android端末で。
初期の上限:

アクティブ車両 約12台

簡易デブリ/パーティクル 約100個

シンプルな影

限定的なリアルタイムライト

パフォーマンスは早い段階で実機テストするべきだ。

⸻
開発マイルストーン
マイルストーン1 — グレーボックス走行
作るもの:
空のアリーナ
キューブのプレイヤー
タッチ操舵
加速
ドリフト

カメラ

成功基準:

空のアリーナを走り回ることが気持ちよく感じられる。

そうなるまで先に進まないこと。

⸻
マイルストーン2 — 追跡
追加:
警察車両1台
追跡AI
迎撃
衝突
成功基準:

警察車1台をかわすのが楽しい。

⸻

マイルストーン3 — 創発的な混沌

追加:

複数の警察

警察同士の衝突

障害物

破壊

スコアリング

成功基準:

プレイヤーが意図的に起こせる:

警察 → 警察
および
警察 → 環境
衝突。
これが重要なマイルストーンだ。
⸻
マイルストーン4 — エスカレーション

追加:

手配レベル

スポーン

難易度スケーリング

インターセプター

これで1回のランに弧ができる:

平穏
↓
プレッシャー
↓
混沌
↓
パニック
↓
死

⸻

マイルストーン5 — ジュース
追加:
パーティクル
カメラの揺れ
ヒットストップ
スキッドマーク

砂埃

サイレン

衝突音

スコアポップアップ

⸻

マイルストーン6 — モバイルビルド

実機向けにビルドする。
テスト:
操作
パフォーマンス
読み取りやすさ
バッテリー/熱の挙動
異なる画面比率
⸻
マイルストーン7 — 続けるかどうかを決める

この時点で開発を一時停止する。

すぐにガレージと37台のアンロック可能な車を作らないこと。

ビルドを人々の前に出す。

重要な問いは:

人々はすぐに理解するか?
死んだ後にリスタートするか?
意図的に警官を衝突させようとするか?
「もう1回」は自然に起こるか?
そうでなければ、コンテンツを追加するのではなくコアループに取り組む。
⸻
フェーズ2 — 検証後にのみ
プロトタイプが機能するなら、次へ拡張する:
車
↓
コイン
↓
アンロック
↓
チャレンジ
↓
新しいアリーナ
↓
特殊警察
↓
アップグレード
↓
デイリーチャレンジ
↓
リーダーボード
候補となる環境:
砂漠
都市
埠頭
雪原
工業ヤード
空港
建設現場
軍事基地
さらに、SUV、装甲車、道路封鎖を投下するヘリコプターなど、荒唐無稽な警察ユニットの余地もある。

@[Unity CLI installation] プロジェクトを開いたので、そこで作業できる。ゲームのアートスタイルは楽しくカートゥーン調にし、アクションもオーバーザトップにするべきだ。
使用できるよう、Topdownエンジンもプロジェクトにインポート済みだ:
https://topdown-engine.moremountains.com/

ゲームはモバイル向けに最適化したいが、テスト中はデスクトップでも動作するべきだ。

出典

原作者
froessell
公開日
2026-09-26(由推文 ID 反解)
原典
元の投稿を見る ↗
収録元
yihui-dev/awesome-opus5-5-videos · froessell-562325 · MIT
zhuyansen/awesome-opus-5.5-video · 2103789415323562325 · ライセンス未表明
この項目は 2 件の出典を統合・重複排除して作られました