Improve documentation on Update vs FixedUpdate schedule dichotomy (#14600)
# Objective When looking at documentation for the `Update` schedule, its not entirely obvious that developers should actually be using the `FixedUpdate` schedule for most of their game logic. We should directly cross-link between the two, and give examples of which systems to put in which schedules. ## Solution Do just that.
This commit is contained in:
parent
3a664b052d
commit
039bf90817
@ -94,8 +94,16 @@ pub struct FixedFirst;
|
|||||||
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
||||||
pub struct FixedPreUpdate;
|
pub struct FixedPreUpdate;
|
||||||
|
|
||||||
/// The schedule that contains most gameplay logic.
|
/// The schedule that contains most gameplay logic, which runs at a fixed rate rather than every render frame.
|
||||||
|
/// For logic that should run once per render frame, use the [`Update`] schedule instead.
|
||||||
///
|
///
|
||||||
|
/// Examples of systems that should run at a fixed rate include (but are not limited to):
|
||||||
|
/// - Physics
|
||||||
|
/// - AI
|
||||||
|
/// - Networking
|
||||||
|
/// - Game rules
|
||||||
|
///
|
||||||
|
/// See the [`Update`] schedule for examples of systems that *should not* use this schedule.
|
||||||
/// See the [`FixedMain`] schedule for details on how fixed updates work.
|
/// See the [`FixedMain`] schedule for details on how fixed updates work.
|
||||||
/// See the [`Main`] schedule for some details about how schedules are run.
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
||||||
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
||||||
@ -128,9 +136,15 @@ pub struct FixedLast;
|
|||||||
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
||||||
pub struct FixedMain;
|
pub struct FixedMain;
|
||||||
|
|
||||||
/// The schedule that contains app logic. Ideally containing anything that must run once per
|
/// The schedule that contains any app logic that must run once per render frame.
|
||||||
/// render frame, such as UI.
|
/// For most gameplay logic, consider using [`FixedUpdate`] instead.
|
||||||
///
|
///
|
||||||
|
/// Examples of systems that should run once per render frame include (but are not limited to):
|
||||||
|
/// - UI
|
||||||
|
/// - Input handling
|
||||||
|
/// - Audio control
|
||||||
|
///
|
||||||
|
/// See the [`FixedUpdate`] schedule for examples of systems that *should not* use this schedule.
|
||||||
/// See the [`Main`] schedule for some details about how schedules are run.
|
/// See the [`Main`] schedule for some details about how schedules are run.
|
||||||
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
|
||||||
pub struct Update;
|
pub struct Update;
|
||||||
|
Loading…
Reference in New Issue
Block a user