Mobile AI Comic Drama MVP in 8 Days: Architecture, Character Consistency, and Async Pipelines

1. Background and Goals: Why Build AI Comic Drama Creation on Mobile

The core of AI comic drama creation is not just “generating a few images” or “compositing a video.” It is a production pipeline that connects inspiration, script, character settings, scene settings, storyboard descriptions, image generation, video generation, and final editing into a traceable, editable, and recoverable workflow. There are already many desktop-browser-oriented creation tools with relatively complete features, but mobile experiences for creating anytime, quickly capturing inspiration, and advancing projects in fragmented time are still clearly lacking. This article discusses an MVP for a mobile-oriented AI comic drama creation app: the user enters one sentence of inspiration, the system helps generate a script, characters, and scenes, then automatically generates storyboard images and storyboard videos, and finally composites them into a complete comic drama video.

This goal may sound like “stacking multimodal large model capabilities,” but in real implementation developers quickly encounter four types of problems. First, the generation chain is long, and failure at any step affects downstream steps. Second, character consistency is difficult, and character appearance tends to drift between storyboard shots. Third, mobile devices are not suitable for long blocking waits, so asynchronous tasks and progress feedback are required. Fourth, invocation costs are hard to control, and repeated retries and long prompts quickly increase expenses. Therefore, the key to completing an MVP in eight days is not to pursue a large and comprehensive product, but to define boundaries clearly: first connect the main chain from “one sentence → structured script → character/scene assets → storyboard image → storyboard video → final video,” and make editing, retry, preview, saving, and open-source engineering solid.

2. MVP Boundaries and Requirement Breakdown

At the MVP stage, avoid making a “professional editor” the first goal. The first mobile version is better suited to a “lightweight director console”: users handle creativity and key choices, while the system handles structuring, generation, and composition. The capabilities can be broken down as follows:

1. Inspiration input and script structuring: The user enters one sentence or a short description, and the system outputs a structured result containing a title, synopsis, character list, scene list, and shot list. The structured output must be verifiable. For example, each shot must include a shot number, visual description, character references, scene references, suggested duration, and dialogue or narration.
2. Character and scene asset library: A character is not just a block of text but a reusable asset profile, including name, appearance description, style constraints, reference images, and prohibited features. Scenes similarly need constraints such as style, lighting, time, and viewpoint.
3. Storyboard image generation: Generate keyframes based on storyboard descriptions, require the same character to maintain relatively high consistency across different shots, and allow users to replace, regenerate, or locally adjust images.
4. Storyboard video generation: Generate short clips based on storyboard images or keyframes, control camera movement, duration, and rhythm, and allow failed generations to be retried.
5. Final video composition: Concatenate multiple storyboard videos in order, add basic capabilities such as transitions, subtitles, and audio tracks, and output a final video that can be previewed and downloaded.
6. Project and draft management: The mobile app must automatically save drafts, support resumable uploads, task status recovery, and failure retry.

Among these six items, what really determines the experience is “editability” and “recoverability.” If users can only generate once and must start over after a failure, the MVP will be hard to accept. Therefore, the data model and task state machine should be designed earlier than generation prompts.

3. Overall Architecture: Lightweight Mobile Frontend + Orchestration Service + Async Tasks

A practical architecture can be divided into five layers:

• Mobile interaction layer: Handles inspiration input, script editing, character/scene management, storyboard preview, task progress display, and final video playback. The mobile app does not directly hold sensitive keys or directly call generation capabilities; it only communicates with the business orchestration service.
• Business orchestration layer: Provides business APIs for projects, scripts, characters, scenes, shots, tasks, and final videos; validates structured data, assembles prompts, creates asynchronous tasks, and maintains state machines.
• Generation capability adapter layer: Abstracts text generation, image generation, video generation, voice/subtitle, and other capabilities into unified interfaces for easier replacement and degradation. Business code should avoid directly coupling to a specific model invocation method here.
• Async task and media processing layer: Drives long-running tasks through a message queue or task table, stores images, videos, and final videos in object storage, and uses logging and monitoring services to record pipeline latency and failure reasons.
• Data and configuration layer: Stores project metadata, asset references, task records, prompt template versions, and cost statistics; keys are injected through server-side configuration or key management capabilities.

For general cloud service selection, object storage can carry media assets, message queues can carry asynchronous tasks, and logging services can provide observability. If cloud vendor capabilities are mentioned, they should remain at the level of general categories such as “object storage, message queue, logging service, and monitoring/alerting,” without binding to specific APIs.

4. Key Pipeline 1: From One Sentence to a Structured Script

The first step in script generation is not “letting the model freely create,” but defining a stable data contract. It is recommended to use structured output and perform server-side validation, for example:

{
  "title": "Project title",
  "logline": "One-sentence synopsis",
  "characters": [
    {"id": "c1", "name": "Character A", "appearance": "Appearance constraints", "style": "Style constraints"}
  ],
  "scenes": [
    {"id": "s1", "name": "Scene A", "lighting": "Lighting", "time": "Time"}
  ],
  "shots": [
    {"id": "sh1", "sceneId": "s1", "characterIds": ["c1"], "description": "Visual description", "duration": 5}
  ]
}

The server needs to validate whether the characters and scenes referenced by each shot exist, whether the duration is within a reasonable range, whether the description is empty, and whether character appearance constraints are missing. When validation fails, the error should not be exposed directly to the user. Instead, a “repair-style regeneration” should be triggered, using the validation errors as context for the model to correct. Prompt templates should be versioned to facilitate rollback and effect comparison.

In addition, script generation should distinguish between the “creative layer” and the “production layer.” The creative layer can be divergent, while the production layer must converge into executable shot descriptions. For example, storyboard descriptions should include subject, action, environment, shot size, camera movement, lighting, and style keywords, avoiding non-executable expressions such as “very exciting” or “very cute.”

5. Key Pipeline 2: Character and Scene Assets to Improve Character Consistency

Character consistency is a core difficulty in AI comic drama. Simply repeating character descriptions in every storyboard prompt is usually unstable. A more reliable approach is to turn characters into “asset profiles”:

1. Fix character profiles: Save character name, age impression, hairstyle, clothing, color palette, signature features, prohibited features, and style constraints.
2. Anchor with reference images: Generate or upload reference images for characters and use them as reference conditions during storyboard image generation. For multiple characters in the same frame, clarify primary/secondary roles and occlusion relationships.
3. Template storyboard descriptions: Each shot must reference character IDs, and the prompt should concatenate a summary of the character profile rather than repeating free-text descriptions.
4. Regeneration strategy: When a user is dissatisfied with a storyboard image, prioritize keeping the character profile and scene constraints, and adjust only action, shot size, or expression to avoid drift caused by full rewriting.
5. Consistency checks: After generation, perform lightweight validation, such as checking the number of people, whether the main character appears, and whether style keywords are hit. The goal is not fully automatic judgment, but marking suspicious results for user confirmation.

The same applies to scene assets. A scene profile should record spatial structure, main props, lighting atmosphere, and time state to prevent the same scene from becoming a completely different space across shots.

6. Key Pipeline 3: Storyboard Images, Storyboard Videos, and Final Composition

Storyboard image generation should support both “single-image regeneration” and “batch generation.” During batch generation, concurrency must be controlled to avoid sudden cost spikes and task congestion. After each image is generated, it should be immediately stored in object storage, and the task table should record the asset address, prompt version, model configuration summary, and cost estimate. After a user replaces an image, subsequent video generation should reference the new asset, forming a traceable version chain.

Storyboard video generation is a long-running task and must be asynchronous. It is recommended to maintain an independent state for each storyboard video: pending, generating, succeeded, failed, and canceled. Failure reasons should be categorized, such as non-compliant input, timeout, media processing failure, and insufficient quota, and limited retries should be configured. Retries must be idempotent to avoid repeated charges for the same shot or multiple untraceable assets.

At the final composition stage, heavy media processing should not be performed on mobile devices. The server pulls video clips in storyboard order, unifies resolution, frame rate, and encoding parameters, then adds transitions, subtitles, and audio tracks, and outputs a preview version and a high-definition version. The preview version can be low-resolution and quickly generated, while the high-definition version is triggered on demand. Composition tasks also need a state machine and failure recovery.

7. Engineering Implementation Points: State Machines, Idempotency, and Observability

Long-chain applications fear “state inconsistency” the most. It is recommended to use explicit state machines to manage projects and tasks:

Project: Draft -> Generating -> Editable -> Compositing -> Completed
Storyboard image: Pending -> Generating -> Succeeded / Failed
Storyboard video: Pending -> Generating -> Succeeded / Failed
Final video: Pending composition -> Compositing -> Succeeded / Failed

Each state transition should write a task record containing task ID, project ID, shot ID, idempotency key, retry count, start time, end time, and error code. Use an idempotency key when creating tasks to prevent duplicate tasks caused by repeated user clicks. When polling or pushing progress, return only necessary fields to avoid frequent large-object pulls on mobile.

Observability should at least include task success rate, average latency, failure distribution by stage, invocation count per project, cost estimate per project, and object storage write failure rate. Logs should not record full sensitive prompts or user privacy content; desensitize when necessary.

8. Mobile Experience and Cost Control

The first mobile version should be lightweight: six main screens are enough—inspiration input, script cards, character cards, shot list, task progress, and final video preview. Draft autosave should use “local cache + server incremental sync”: save locally first on weak networks, then sync after connectivity recovers. Long-running tasks should not block the page; use a task center to display progress uniformly and allow users to exit and return later.

Cost control should start from five aspects. First, model tiering: use lower-cost text capabilities for creative drafts and call stronger capabilities only for key storyboards. Second, cache reuse: character profiles, scene profiles, and prompt templates can be reused to avoid repeated generation. Third, limit retry counts and concurrency. Fourth, generate low-resolution previews first, and generate high-definition versions after user confirmation. Fifth, track invocation volume and cost by project and set threshold alerts. In the practice described in the original article, total invocation cost was kept at a low level, which shows that at the MVP stage, through scope convergence and cache reuse, cost is not uncontrollable, but metering must be implemented from day one.

9. Security, Compliance, and Open-Source Delivery

AI comic drama involves text, images, video, and voice, so security and compliance cannot be postponed. At minimum, the app should perform basic moderation on user input and generated content; require users to confirm authorization for character reference images; warn about risks when real-person likenesses are involved; add AI-generated labels to final videos when needed; minimize collection of private data; and use keys only on the server side. For open-source delivery, provide a clear directory structure, environment variable examples, deployment instructions, data model documentation, prompt template examples, and known limitations. Do not commit real keys, user assets, or unauthorized reference images. Choose an appropriate open-source license and clarify the usage boundaries of third-party assets.

The key to completing an MVP in eight days is “main pipeline first, engineering in parallel”: Day 1 defines the data model and state machine; Day 2 connects text structuring; Days 3–4 complete the character/scene and storyboard image pipeline; Days 5–6 complete storyboard video and asynchronous tasks; Day 7 completes composition and mobile integration; Day 8 adds logging, cost statistics, README, and open-source cleanup. Intelligent coding assistants can be used for scaffolding, API integration, bug fixing, and documentation generation, but core data contracts, state machines, and consistency strategies still need to be designed by developers.

Overall, the technical barrier of a mobile AI comic drama app is not single-point generation, but long-chain orchestration, asset consistency, asynchronous task reliability, and cost observability. It is more consistent with engineering principles to first stabilize the MVP main pipeline and then gradually expand editing capabilities and the template ecosystem.