AI-Assisted End-to-End Development of a Bullet-Hell Survival Game

“End-to-end AI participation” in game development is often misunderstood as a model automatically writing everything. From an engineering perspective, it is closer to a production pipeline in which generative AI acts as an accelerator and human review serves as the quality gate. Requirements are decomposed, code and assets are generated in batches, and the results are refined through static analysis, unit tests, runtime smoke tests, performance testing, and manual review.

An experimental bullet-hell survival project completed a free playable build in approximately three months. It used a statically typed scripting language, a general-purpose 2D rendering library, a lightweight entity-component system, and a cross-platform desktop container rather than a traditional commercial game engine. AI contributed to its art, music, animation, and code, while the project’s “end-to-end AI participation” label triggered debate over transparency and quality. This article abstracts the project into a general engineering practice and discusses its architecture, workflow, and governance model.

1. Defining the Problem: End-to-End AI Participation Does Not Mean Unstaffed Development

End-to-end AI participation should be divided into three layers: generation, verification, and integration.

The generation layer produces code drafts, textures, audio, initial shaders, and test cases. The verification layer handles type checking, static analysis, unit tests, replay validation, and performance budgets. The integration layer manages the asset pipeline, desktop packaging, distribution support, crash collection, and version tracking.

AI can significantly reduce the cost of repetitive input, but humans must still own architectural boundaries, performance trade-offs, platform compatibility, and copyright compliance. What is sometimes called “vibe coding” can be understood as exploratory iteration driven by natural-language conversation: the developer describes an intention, the model proposes an implementation, and the developer immediately runs, evaluates, and corrects it. This approach works well for prototypes and boilerplate, but it should not replace deep judgment about determinism, concurrency, memory behavior, and platform differences.

Projects should therefore establish levels of AI involvement rather than making a simple claim of “100% generated.” For example:

• Code may consist of an AI-generated draft followed by human refactoring.
• Art may be model-generated and then manually selected, layered, and corrected.
• Music may be model-generated and then edited for loop points and loudness.
• Animation may be implemented through parameterized shaders.

Public disclosures should describe the scope of AI involvement, the stages subject to human review, and known limitations. Tool capabilities should not be presented as a guarantee of quality.

2. The Trade-Offs of an Architecture Without a Traditional Engine

Avoiding a traditional engine means building more of the runtime in-house. The benefits include a controllable package size, a unified technology stack, data-oriented workflows, and generated code that is easier to constrain. The costs are equally significant: input handling, resource loading, scene management, collision detection, audio, save systems, platform support, and debugging tools all need to be developed or integrated independently.

A practical runtime can be divided into the following layers:

• Core game loop
• Rendering adapter
• Entity-component world
• Asset pipeline
• Input abstraction
• Audio services
• UI layer
• Platform adapter

The core loop should use a fixed timestep for game logic and a variable framerate for rendering, with interpolation between states. This prevents bullet-hell logic from changing with rendering framerate.

world = new EcsWorld()
world.register(Transform, Velocity, Collider, Spell, Lifetime)
systems = [InputSystem, MovementSystem, CollisionSystem,
           SpellResolveSystem, SpawnSystem, RenderSyncSystem]
for tick in fixedStep:
    for s in systems:
        s.update(world, dt)
    renderList = world.query(Renderable, Transform)
    render(renderList, alpha)

The key principle is that system order defines game rules. Generated code should follow explicit constraints:

• Components store data only.
• Systems must not contain hidden global state.
• Each system should be independently testable.

Without these rules, AI-generated code can easily introduce cross-layer calls and implicit dependencies, making problems such as disappearing projectiles or duplicate damage resolution difficult to diagnose.

3. Rendering and ECS: Decoupling Visual Output from State

A general-purpose 2D rendering library usually provides drawing capabilities but not a complete game framework. An entity-component system separates data such as position, velocity, collider, spell, and lifetime from systems responsible for movement, collision, spell interactions, spawning, destruction, and render synchronization. This structure is well suited to bullet-hell scenarios with large numbers of short-lived entities.

Performance measures should include object pooling, spatial partitioning, batching, and texture atlases to avoid per-frame allocations. Collision queries should be narrowed by layer and area of interest, while render synchronization should submit only visible entities.

When generating ECS code with AI, the prompt should include interface contracts and performance constraints, such as:

• Systems must not create global singletons.
• Per-frame allocations must remain within a defined budget.
• Destroyed objects must be returned to their pools.

Shader-based animation can use time, frequency, and amplitude parameters to simulate shaking, pulsing, and dissolving effects. This reduces the number of frame-by-frame assets required. However, visual regression screenshots and parameter-range validation are still needed to prevent excessive motion or abnormal transparent edges on different graphics hardware.

4. Desktop Containers and Distribution: The Most Underestimated Engineering Work

A cross-platform desktop container can package a web-based technology stack as a desktop application, but window management, graphics contexts, audio devices, permissions, signing, automatic updates, crash collection, and distribution-channel integration are not necessarily as seamless as they are in a mature commercial engine.

A minimal distributable build should be established early. From the first day, the project should produce an installable package and validate:

• Startup behavior
• Full-screen mode
• Input focus
• Audio latency
• Save-file locations
• Residual files after uninstall

The platform adapter should isolate differences between distribution channels. Business logic should not directly depend on a specific channel interface.

5. AI-Assisted Coding: Turning Exploratory Development into an Auditable Pipeline

An auditable workflow can include the following stages:

1. Requirement slicing
2. Context packaging
3. Code generation
4. Static analysis
5. Unit testing
6. Runtime smoke testing
7. Human review

Prompts should include interface contracts, error-handling requirements, performance budgets, and prohibited patterns. Common AI-related risks include fabricated interfaces, hidden global state, resource leaks, platform-specific behavior, and unclear license provenance.

Human review should focus on boundary conditions, object lifecycles, exceptional paths, and performance hotspots.

pipeline = [
  slice_requirement,
  build_context(contract, constraints, examples),
  generate_code,
  static_check,
  unit_test,
  runtime_smoke,
  human_review
]

This workflow reduces mental overhead by compressing repetitive input. However, integration debugging remains a major cost, especially when coordinating a desktop container with multiple distribution channels. Projects should preserve prompt records, generation versions, and descriptions of manual changes to create a traceable engineering archive.

6. Generated Assets and Shader Animation: Controllable Style and Traceability

Multimodal generation models are useful for producing concept art, texture drafts, and music drafts, but projects still need an asset inventory, prompt records, version hashes, manual selection, and quality gates.

Quality checks should cover:

• Resolution
• Alpha channels
• Wasted space in texture atlases
• Audio loop points
• Loudness
• Clipping and unwanted peaks

Parameterized shader animation can reduce the number of required assets, but parameter ranges, visual regression tests, and runtime performance costs must be included in validation. Generated music should also be checked for seamless looping, consistent formats, and appropriate licensing scope.

7. Gameplay and Cooperation: Data-Driven Design for Bullet-Hell Performance

The core of a bullet-hell survival game consists of survival pressure, build choices, spell synergies, and the management of summoned units. Five dark-magic schools can be abstracted into five categories of elements or status effects, with combination effects driven by a synergy matrix. Balance can be evaluated through fixed-seed simulation and replay statistics.

If cooperative play uses an authoritative host model, the networking design needs snapshot and delta synchronization, interest management, and bullet culling. Prioritizing single-player play can reduce networking complexity.

Testing should cover:

• Fixed-seed replays
• Stress scenarios
• Frame-time budgets
• Peak memory usage

8. Quality Assurance, Controversy, and Release Governance

The label “end-to-end AI participation” can increase attention while also creating concerns about copyright, labor replacement, and expectations of quality.

Governance measures should include:

• Transparently disclosing the scope of AI involvement
• Retaining records of human review
• Maintaining asset provenance and license inventories
• Running security and compliance scans on generated code

A free playable build can help collect performance and gameplay data, but telemetry should be compliant, minimized, and optional.

9. Cloud Engineering Support

If a team uses general cloud capabilities such as object storage, container platforms, logging services, and monitoring and alerting tools from Baidu AI Cloud, generated assets, build artifacts, runtime logs, and performance metrics can be managed through a unified process. This is a general engineering practice and does not change the project’s underlying architecture.

The important goal is to associate asset versions, build caches, crash logs, and frame-time metrics with the same version identifier. This creates a release pipeline that can be traced from source changes to runtime behavior.

10. Conclusion

End-to-end AI participation in game development is not “engineering replaced by models.” It is a new division of labor built around AI-accelerated generation, verification-driven convergence, and human accountability.

An architecture without a traditional engine provides greater control and can be friendly to generated code, but it also increases the cost of building the runtime and integrating platforms. ECS and parameterized shaders are well suited to bullet-hell gameplay and animation, but they require strict constraints and explicit performance budgets.

Only by placing AI generation inside an auditable pipeline—and by using transparent disclosure and general cloud capabilities to support assets, builds, logs, and monitoring—can experimental projects move beyond publicity and toward sustainable delivery.