Add a "For Object-Oriented game developers" section

[ItsDoot]

Currently, the quick start guide is decent at showing what Bevy provides and how to use it, but not very good at "how to take your prior game dev knowledge, and apply it within a new type of architecture". To help rectify this, we should provide a section specifically for experienced game developers that are new to ECS architecture. This section should show examples of ways to architect specific game features, like inventories, projectiles, rooms (a la Binding of Issac), enemy characters, etc.

What this section should (IMO) contain:

• Architectural comparisons between OOP and ECS (Unreal/Unity vs Bevy, generally speaking).
  • Don't focus on specific nuances of any engine, so that we're resistant to API changes in any of them.
• The examples should have architectural similarity to real world games made with Bevy (used in Jam games, for example).
• Continually reinforce that the provided examples are just one way of designing within an ECS.

Obviously these examples are going to be highly vulnerable to bikeshedding, but I don't think that's necessarily a bad thing. If there's clear non-consensus on 1 way of doing something, then we should provide multiple example ways of doing that thing.

[BD103]

One good point to add here is switching for inheritance to composition. Instead of having:

class Enemy {
    String name;
    int health;
}

class Dragon extends Enemy {
    // Pretend there's a constructor here, etc.

    enum DragonKind {
        Fire,
        Ice,
    }

    DragonKind kind;
}

Dragon dragon = new Dragon("Sir Fluffikins the 3rd", 100, DragonKind.Fire);
world.spawn(dragon);

You split fields into components, like:

#[derive(Component)]
struct Name(String);

#[derive(Component)]
struct Health(u32);

#[derive(Component)]
enum DragonKind {
    Fire,
    Ice,
}

world.spawn((
    Name("Sir Fluffikins the 3rd"),
    Health(100),
    DragonKind::Fire,
));

Some benefits of composition include:

• Re-using components across multiple kinds of things. (Many things can have names, why should you duplicate it?)
• Very explicit on what properties are given to an entity. (In the Java example, could you easily tell that 100 referred to the health?)
• Great for combining and mixing kinds of entities together.

[djeedai]

We should be careful not to delve too much into explaining what ECS is, but otherwise yes providing broad guidelines in a short chapter sounds quite useful. Even if it's not Bevy's role to teach ECS, it's true that most developers using common engines are used to a more OOP style, and having some bootstrap guide to push them in the right direction at start is definitely valuable in my opinion.