Enhancing Bevy Engine Schedules With Input Parameters

Introduction to Bevy Engine and Schedule Customization

Bevy Engine, a data-driven game engine built with Rust, offers a flexible and efficient architecture for game development. One of its key features is the use of schedules, which allow developers to organize and control the execution order of systems. Systems are the fundamental building blocks of Bevy applications, responsible for processing data and performing game logic. However, the current implementation of schedules has limitations when it comes to passing input parameters to systems, particularly in the context of scene loading and customization. This article delves into the challenges and proposes solutions to enhance the capabilities of Bevy schedules by introducing support for input parameters, thereby improving the flexibility and efficiency of game development workflows.

Schedules in Bevy are crucial for managing the execution of game logic. They define a sequence of system runs, ensuring that dependencies are met and that the game’s various components interact correctly. By default, systems within a schedule operate without explicit input parameters, relying on shared resources or global state. This approach simplifies the architecture but can restrict the ability to pass context-specific data to systems, especially during processes like scene loading where domain-specific metadata is often required. The goal is to extend the functionality of Bevy's scheduling mechanism to accommodate systems that require input parameters, allowing for more dynamic and tailored game logic execution.

The Need for Customization in Scene Loading

Consider the scenario of scene loading with bevy_trenchbroom, a Bevy plugin for importing levels created with the TrenchBroom editor. During scene loading, developers often need to customize various aspects of the scene based on metadata associated with the level or specific objects within the scene. For example, you might want to adjust the properties of materials, apply different components to newly created entities, or load external dependencies based on the scene’s configuration. This level of customization requires a mechanism to pass specific data to the systems responsible for processing the scene data.

The challenge lies in how to pass this contextual data, such as a LoadContext, to the systems within the schedule. The current architecture requires either adding the context as a static resource (which isn't possible because LoadContext isn't 'static') or passing it via the run_system_with method. However, since the schedule graph uses Systems, which bounds systems to use In = (), the direct use of schedules to handle this becomes impossible. This is where the proposal for input parameters in schedules becomes relevant.

The Proposed Solution: Adding Input Parameters to Schedules

The core of the proposed solution involves modifying SystemWithAccess, Systems, ScheduleGraph, and Schedule to accept type parameters for input and output, which default to (). This change wouldn’t alter the fundamental implementation but would allow developers to define systems that accept input parameters. Users would still be responsible for managing the order of execution concerning inputs and outputs. The new method for these types would only be available for the <(), ()> instantiation, and users would use Default::default() for other versions. Additionally, Schedule::run(..) would only be available for Schedule<(), ()>. The way to run these systems with input parameters would be to use topsort_graph and run the systems in sequence.

Implementation Details and Minimal Changes

This is a very minimal change but would enhance the quality of life for developers using schedules outside the context of an App or wanting to run a one-shot schedule. The introduction of input parameters would enable developers to create more flexible and adaptable game logic. Systems could receive contextual data, such as loading configurations or scene-specific metadata, allowing for dynamic behavior tailored to the specific game environment. The use of topsort_graph and sequential execution of systems provides a straightforward approach to managing the execution order while handling the input parameters.

Alternatives and their Limitations

The standard approach involves loading assets and processing them in the main loop to address the need for custom scene loading. While this method works, it has several drawbacks that the proposed solution aims to mitigate.

Issues with Current Approaches

• Main World vs. Separate World: Systems operating in the main world may cause frame drops if significant processing is required. Processing in the main loop can potentially lead to performance bottlenecks, especially when dealing with complex scenes or extensive data transformations.
• Access to Assets: Lack of easy access to assets before handles have been created, such as if you want to modify an image before applying it to a material. Developers may need to perform extra steps to make assets CPU-accessible, complicating the workflow.
• One-Shot Loading: Loading is a one-shot process, and these systems should not ideally be in the main loop. Running loading systems in the main loop is inefficient, especially when scenes are instantiated repeatedly.
• Re-instantiation: Processing needs to be redone every time a scene is instantiated, rather than once at load-time. Redundant processing leads to unnecessary overhead and impacts performance.

Benefits of Input Parameters in Schedules

The introduction of input parameters would provide a more elegant and efficient solution. Systems could operate on a separate world and potentially in a separate thread. This design helps prevent frame drops and keeps the main loop clean. It enables developers to modify assets before handles are created, streamlining the loading process and providing more control over how assets are handled. Loading can be designed as a one-time process, eliminating redundant processing and improving overall game performance. This approach leads to more dynamic, adaptable, and optimized game development processes.

Streamlining Development Workflows

With input parameters, developers can create customizable scene loading mechanisms that react dynamically to the game environment. This flexibility allows for better support for a range of different scene types, which is essential in a variety of game genres. The ability to pass context-specific data to systems also promotes better code organization, as systems can be tailored for specific tasks without relying on shared resources or global state. The overall effect is to make game development more efficient and more enjoyable.

Conclusion: Improving Bevy's Schedule System

The enhancement of Bevy Engine schedules with input parameters is a significant step towards improving the engine's capabilities. By enabling the passing of contextual data to systems within schedules, developers gain greater flexibility, efficiency, and control over their game development workflows. This change directly addresses the limitations of the current schedule system, particularly concerning scene loading and customization. Although the changes are minimal, they would improve the quality of life for any developer using schedules outside of the context of an App or wanting to run a one-shot schedule. The proposed solution offers a robust and adaptable framework for creating dynamic and optimized game development processes.

For further information on Bevy and its architecture, please visit the Bevy Engine website.