游戏开发的世界太大了，每个类型都有它独特的坑和乐趣。这次挑几个不同的方向——Roguelike的随机性、节奏游戏的精确帧、物理搭建的稳定性、卡牌对战的逻辑网、弹球打砖块的变体。每一个都有它独特的挑战。英文提示词照旧，拿走就跑。
1. 小型Roguelike地牢（随机生成 + 永久死亡）
Create a turn-based roguelike dungeon crawler using Canvas or grid of divs. Dungeon size: 10x10 rooms connected by corridors (or use a single map of 20x20 cells with walls, floors, doors). Generate map randomly using binary space partitioning (BSP) or simple random walk. Place player ( @ ) at start, stairs down ( > ) at the farthest room, and 5-10 enemies (goblin, skeleton) randomly. Combat is turn-based: player moves into enemy cell to attack, enemy attacks back. Player stats: HP 20, attack 5-10. Enemy stats: goblin HP 10, attack 3; skeleton HP 15, attack 5. Player can pick up health potions (heal 10) and weapons (+2 attack) from chests (random spawn). When player dies, game over with message and restart button. When player reaches stairs, generate next floor (new random map, enemies harder – e.g., +2 HP and +1 attack each floor). No permadeath across floors? Actually permadeath means you lose all progress if you die. Implement permadeath: death resets to floor 1. Display current floor number, HP, attack, inventory (simple list). Use localStorage to save the game state (floor, stats, position) so player can reload, but on death clear save. Movement: arrow keys. Provide a "Restart" button. FOV (field of view) optional but not required – show whole map. The core is procedural generation, turn-based combat, and permadeath with progression.
为什么选这个：Roguelike的核心是随机性和风险决策。BSP生成地牢虽然代码量不小，但做完后你会对“程序化内容生成”有直观理解。永久死亡和楼层难度递增会让玩家认真对待每一次移动。
常见翻车：随机生成可能导致死路或无法到达楼梯。需要加一个连通性检查（BFS从玩家出发能走到楼梯才算有效）。
2. 节奏小游戏（音符下落 + 精确判定）
Build a rhythm game similar to "osu!" or "Guitar Hero" but simplified. Use Canvas. A track (vertical lane) with 4 columns (keys: A, S, D, F). Notes fall from top to bottom. A music file? For simplicity, hardcode a note sequence (array of objects: { time: 0.5, lane: 0 }, { time: 1.0, lane: 1 }, etc.) with a pre-defined song length (e.g., 30 seconds). Use the Web Audio API to play a simple beep or a background audio file (you can use an MP3 from a URL or generate a sine wave). The tricky part: timing. Use requestAnimationFrame and AudioContext.currentTime to synchronize. When a note reaches the hit line (bottom 100px), player presses the corresponding key. Scoring: Perfect (±0.05s) = 100 points, Good (±0.15s) = 50 points, Miss = 0 points. Display score, combo (consecutive hits), and accuracy percentage. After song ends, show final score and replay button. Provide a simple visualization of the hit line and the notes. No external libraries for audio timing. Must handle keyboard events without page scrolling (preventDefault). Notes that pass the hit line without hit are counted as miss. Show a floating text ("Perfect", "Good", "Miss") on hit. Add a simple metronome visual (pulse on beat). This is entirely front-end, no backend required.
说人话：节奏游戏最难的是帧同步和音频时钟的结合。requestAnimationFrame的帧率不稳定，必须用AudioContext.currentTime作为绝对时间参考。判定窗口的代码要小心边界条件。
适合练：精确计时、键盘事件、数组操作（移除超出屏幕的note）。做完你会对游戏循环的时间管理有全新的理解。
3. 物理搭建桥（结构稳定性模拟）
Implement a physics-based bridge builder game using Canvas and a simple Verlet integration or matter.js? But to avoid external engine, use a basic spring-mass system? Actually writing a stable physics engine from scratch for bridges is too heavy for a prompt. So allow using matter.js (a 2D physics library) but require the logic of construction and stress test. The prompt: Use Matter.js (or Planck.js) to simulate a bridge building game. Player clicks to create joints (nodes) and then connects them with beams (edges) that have strength limits. The bridge spans a gap (width 400px) between two fixed supports. Player can add beams (wood, steel) with different strength/cost. After building, click "Test" to apply a weight (a heavy box) moving across the bridge. The bridge collapses if any beam stress exceeds its limit. Display stress as color (green to red). Provide budget (wood costs 10, steel costs 30, start with 200). The player can delete beams (click to select then delete). The goal is to build a bridge that supports a 100kg weight crossing from left to right. Provide reset and rebuild options. Use Matter.js for constraints (distance constraints) and collision detection. You must predefine support bodies (static) and the ground. This is a construction puzzle, not a real-time action game.
为什么选这个：物理搭建类游戏考察的是对约束系统（关节、连杆）的理解。Matter.js虽然是个库，但你要配置点约束、设定断裂阈值、实时计算应力。预算系统和应力可视化增加了策略深度。
坑点：节点和边的数据结构要设计好，删除边时要同时移除物理约束。应力计算可以用当前负载下的长度变化率或者Matter.js提供的reaction force。
4. 轻量级卡牌对战（回合制 + 状态效果）
Build a turn-based card game (like a simplified Hearthstone or Gwent) using HTML/CSS/JS. No canvas – use DOM elements for cards. Each player has 20 HP. Deck of 10 cards (hardcoded). Card types:
- Minion: attack 3, health 3, cost 2 mana.
- Spell: deal 4 damage, cost 3 mana.
- Heal: restore 5 HP, cost 2 mana.
- Taunt minion: attack 2, health 5, cost 4 mana (forces enemies to attack it first if present).
Players take turns. Each turn, draw one card (max hand size 5), gain 1 mana (max 10). Play cards by clicking from hand, then target (if needed). Minions are placed on the board (max 5 minions per side). Combat phase: when a player ends turn, their minions attack the opponent's minions (if any) or the opponent hero. Implement simple attack logic: each minion deals its attack damage to a random enemy minion (or face if no minions). Taunt minions must be attacked first. Spells can target any minion or hero. Track status effects? Not necessary, but implement “Taunt” as a keyword. Show health bars. Game ends when hero HP <= 0. Provide restart and "End Turn" button. AI opponent: simple AI that plays random valid cards (spell damage to enemy hero if possible, otherwise minions) and ends turn. No animations except card click reactions. Use vanilla JS to manage game state. No backend, no multiplayer. The focus is on state management, turn flow, targeting rules, and AI logic.
核心价值：卡牌对战的状态机非常复杂——手牌、战场、法力值、回合切换、攻击目标选择、嘲讽优先级。写出来以后你会对“事件驱动”和“状态校验”有深刻认识。AI不需要聪明，但必须遵守规则。
常见bug：攻击时目标已经死亡、法术指向非法目标、手牌超过上限、法力值扣减错误。建议用不可变数据或者每次操作后重新验证整个状态。
5. 弹球打砖块变体（道具系统 + 多球）
Create an Arkanoid/Breakout variant with power-ups and multi-ball using Canvas. Paddle at bottom (width 100, controlled by mouse X). Ball (radius 8) bounces off walls, paddle, and bricks. Bricks arranged in 5 rows (different colors = different hit points). Red bricks take 3 hits, blue 2 hits, green 1 hit. When ball hits a brick, brick hit points reduce, score increases by 10 per hit. Random chance (30%) for a power-up to drop from destroyed brick. Power-ups (represented as colored capsules) fall straight down. If caught by paddle, activate:
- Expand paddle (width +50 for 10 seconds)
- Multi-ball (add one extra ball – max 3 balls)
- Laser (paddle can shoot lasers for 5 seconds – clicking or space bar)
- Slow ball (ball speed halved for 8 seconds)
Power-up effects have timers (display icons with countdown). Implement collision detection between ball and power-up capsule (capsule caught if touches paddle). Multi-ball requires managing an array of balls, each with position and velocity. When all balls fall off bottom (below paddle), lose one life (start with 3 lives). Display score, lives, active power-up timers. When bricks are cleared, show victory message and reset button. No external physics engine – implement your own bounce vector math (reflect angle based on where ball hits paddle: offset from center changes horizontal velocity). Provide a "Start Level" button to regenerate bricks (same layout). Use requestAnimationFrame. Ensure that when multi-ball is active and balls exceed 3, new balls added up to 3. Lasers: paddle fires projectiles upwards that destroy bricks on hit (simple line collision). All this in pure JS.
说人话：打砖块看起来基础，但加上道具系统、多球管理、激光射击后，逻辑复杂度直接翻倍。多球时需要遍历每个球进行移动和碰撞，还要处理球之间互不影响。道具的效果计时器要用requestAnimationFrame或setInterval更新剩余时间。
翻车重灾区：多球时一个球触发了道具掉落，掉落物被接住后产生新的球——递归或循环引用容易出问题。建议道具效果和球体管理解耦。
这五个方向每个都有自己独特的难点。Roguelike考验随机生成算法，节奏游戏挑战精确计时，物理搭建依赖约束系统，卡牌对战讲究状态管理，弹球变体需要处理多实体交互。选一个你最感兴趣的，周末把它肝出来。记住：先做个最小原型（比如地牢只生成一个房间，节奏游戏只有一首短曲，卡牌只有几张牌），跑通后再慢慢加功能。游戏开发没有捷径，但每一次debug都是经验值。
