[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-76590":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":12,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":13,"stars7d":14,"stars30d":15,"stars90d":13,"forks30d":13,"starsTrendScore":13,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":18,"hasPages":18,"topics":20,"createdAt":9,"pushedAt":9,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":13,"starSnapshotCount":13,"syncStatus":24,"lastSyncTime":25,"discoverSource":26},76590,"Cobweb","shixiangxi0\u002FCobweb","shixiangxi0","Cobweb: An AI-native game development framework based on Dual-World Theory. View = f(State) for complex game logic.",null,"JavaScript",132,8,0,1,80,51.36,"MIT License",false,"main",[],"2026-06-12 04:01:21","\u003Cp align=\"center\">\n  \u003Cimg src=\"asset\u002FCobweb.png\" alt=\"Cobweb\" width=\"640\">\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"README_CN.md\">中文\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Ch2 align=\"center\">An Event-Driven Game Engine Paradigm\u003Cbr>for the AI Era\u003C\u002Fh2>\n\n\n\n## Design Philosophy\n\nIn the broad discussion of game architecture, `Game Loop` and `Event-driven` can be seen as the two most fundamental top-level driving philosophies.\n\nModern game engines typically adopt `Game Loop` as the top-level design. Input collection, logic advancement, animation updates, physics simulation, and rendering submission are mostly organized along the same frame timeline. Event mechanisms certainly exist, but they serve more as an internal communication method within the loop, rather than the supreme driver of world state.\n\n**Cobweb takes a different approach by placing event-driven design above the `Game Loop`.**\n\nIt views a game first and foremost as a **deterministic state machine**: player inputs, rule triggers, phase transitions, and numerical changes are all essentially definable and verifiable state transitions. Logic and presentation must be loosely coupled; the Game Loop still exists, but primarily serves the presentation world, while the entire game is driven forward in units of events that produce state changes.\n\n### Architectural Code Comparison\n\n**Traditional Game Loop: Frame-based**\n\n```cpp\nwhile (running) {\n    processInput();\n    update();          \u002F\u002F Logic, animation, and physics often mixed here\n    render();\n}\n```\n\n**Cobweb: Event-based**\n\n```js\nengine.use({\n  events: { 'action:perform': {} },\n  rules: [\n    {\n      id: 'core:action',\n      hooks: {\n        'event:action:perform': `...`,\n      },\n    },\n  ],\n})\n\nState.emit('action:perform', { ... })      \u002F\u002F Event-driven rendering\n```\n\n> Because the sole entry point for rules is events, every rule derivation has complete boundaries: from the root event trigger to the end of the state chain, all intermediate state changes are produced internally. This means **the entire game process is recordable, traceable, and globally perceivable by generative AI** — all natural products of this architecture.\n\n---\n\n## Reading List\n\n> Understanding Cobweb is not about the code, but about the **event-driven architecture** paradigm it establishes.\n\n| Document | Why Read |\n|----------|----------|\n| **[Dual-World Design](docs\u002FDual-World-Theory.md)** | **Core architectural philosophy**. A complete derivation from \"Logic vs Presentation\" through state layering, rendering component autonomy, temporary states, and deterministic structure. |\n| **[How to Understand Dual-World Design](docs\u002FHow-to-Understand-Dual-World-Theory.md)** | **Developer paradigm shift**. Uses Rust's borrow checker, CQRS, and frontend state management as classical paradigms to answer how to map the theory to actual code. |\n| **[STS Reference](docs\u002FSTS-Reference.md)** | **Complete but concise**. A real STS combat system with bind + defs + match: cards, enemies, statuses, damage chain, turn loop. |\n\n---\n\n## Presentation Layer\n\nAfter separating the logic world from the presentation world, the latter faces a real engineering pressure: it cannot simply \"draw snapshots.\" Animations require time, transitions require interpolation, and interactions require immediate feedback. To solve this, Cobweb introduces the idea of frontend component autonomy.\n\n> **Presentation is not logic; the rendering layer holds presentation but not logic.**  \n> This is the cornerstone of Cobweb.\n\nRendering components are the smallest units of the presentation layer. Their essence is a **declarative state machine**: declaring what states it has, which transitions are valid, and which transitions need to be reported to the logic layer. `update(dt)` drives internal continuous animation for the state, but is not the core of the component. Rendering components are composable, nestable, and independently testable, and cannot privately modify the Logic Layer state.\n\n---\n\n## Dual-World Design\n\n> **[→ Read the full theoretical derivation](docs\u002FDual-World-Theory.md)**\n>\n> The following is a core overview of Dual-World Design. For the complete derivation (Logic vs Presentation, State Layering, Rendering Component Autonomy, Temporary States, Deterministic Structure, Boundary Judgment), please read the full theory document linked above.\n\nDual-World Design divides the system into two layers: the **Logic Layer** maintains game state, and the **Presentation Layer** maintains continuous perception.\n\nThe logic layer holds two things: the current world snapshot, and rule functions that process events. Each time an event arrives, rules run, state updates, and the change process is completely recorded. The presentation layer reads these results and presents discrete state changes as continuous audio-visual experiences.\n\nThe boundary of responsibilities between the two layers can be judged by a single criterion: **does this change the game state?** What modifies data belongs to the Logic Layer; what merely produces view side-effects belongs to the Presentation Layer. Character running, heavy rain, and flowing hair stay in the presentation layer; HP changes, equipment acquisition, and scene switching are reported to the logic layer as events.\n\n### State Layering\n\nBased on the lifecycle of state, the system's data naturally divides into three layers:\n\n| Layer | Responsibility & Features |\n|-------|---------------------------|\n| **Persistent State** | Cross-scene save data. Maintains long-term data (character level, inventory, quest progress), does not participate in combat calculations. |\n| **Logic Layer \u002F Scene** | The state deduction center for the current scene. All battle rules, event processing, and state changes happen here in absolute serial order. At the end of the scene, key data is written back to persistent state, and the rest is destroyed. |\n| **Presentation Layer** | A pure rendering component tree. Maps discrete state changes into parallel, continuous, multi-track sensory experiences. Holds no game state, can be rebuilt at any time. |\n\n### Architecture Diagram\n\n![Dual-World Architecture](asset\u002Fdual_world_architecture_en.svg)\n\n**Three-Layer Relationship:**\n\n- **Persistent State** — Save layer, shared across scenes. Loaded at startup, saved at key moments, synchronized on exit.\n- **Logic Layer** — Can be understood as a Scene, the state deduction center for the current scene, corresponding to a rendering component tree.\n- **Presentation Layer** — Visualization of the logic layer, composed of a declarative rendering component tree. Each rendering component autonomously manages state, animation, and interaction, and can gracefully self-interrupt when behavior is interrupted.\n\n---\n\n## Quick Start\n\n```bash\n# Install dependencies\npnpm install\n```\n\n**CLI Mode** (Terminal)\n\n```bash\npnpm sts\n```\n\n**Phaser Mode** (Game Interface)\n\n```bash\npnpm phaser\n# Open http:\u002F\u002Flocalhost:5173\n```\n","Cobweb 是一个面向AI时代、以逻辑驱动为核心的游戏引擎。它采用事件驱动的设计理念，将游戏视为一个确定性的状态机，玩家输入、规则触发、阶段转换等都作为可定义和验证的状态转换来处理。这种设计使得逻辑与表现层松耦合，游戏循环主要服务于渲染，而整个游戏进程通过产生状态变化的事件单元推进。特别适合需要高度可控性、可追溯性和全局感知能力的游戏开发场景，如策略游戏或复杂模拟系统。此外，Cobweb 的架构天然支持生成式AI的应用，因为整个游戏过程都是可记录和追踪的。",2,"2026-06-11 03:55:03","CREATED_QUERY"]