# Bevy Engine Users

The purpose of this document is to help us evaluate designs for the Bevy Editor by identifying:
+ Who is going to use the editor,
+ How they will expect it to work,
+ What they will want to do with it,
+ And whether or not we need to support that use-case.

This isn't intended to be super prescriptive: it's just a basic tool for prioritization and talking about our users.

## Overview

In general, we have two broad categories of users:
+ **Technical Users**: Users who are comfortable with rust. Programmers, in short.
+ **Non-Technical Users**: Users who are not comfortable with rust. Artists, Writers, Game Designers. They may know basic programming, but they are not Programmers.

These people may work as individuals or in teams. The main difference between teams is size:
+ **Individuals**: Don't have to worry much about versioning or collaboration. Their time is precious, so they are concerned about ergonomics and development speed. They hate things that feel slow, tedious, or repetitive.
+ **Small Teams**: Say teams or 2 to 20. Prioritize specialization and diversity of workflows. Everyone on their team is going to use the editor in a different way, for a different reason.
+ **Large Teams**: Teams of 20 or more. Prioritize management, control, correctness, and collaboration. Large teams worry about version conflicts, corrupting data, and irreversible changes.

Teams and users are **Commercial** (as opposed to **Non-Commercial**) if they have funding for their work, or plan to use Bevy to make money.

One of the other key difference between teams is their willingness to hack bevy's internals:
+ **Mainline Teams**: Uses the latest or stable release of Bevy, and uses the mainline editor.
+ **Patching Teams**: Ships mainline, but is willing to submit patches to the engine or editor.
+ **Forking Teams**: Maintains their own fork of either the engine or the editor.

Users can be further differentiated according to many other less general aspects:
+ Their reasons for using bevy, and the goal they want to accomplish.
+ Their concerns and goals while using the editor.
+ Their level of experience with the engine or editor.
+ Their level of expertise in their own discipline; game design, art, programming, etc.
+ What other tools they use in their development process.
+ How frequently they use the editor.
+ Whether they prefer coding or graphical user interfaces in a given context.
+ How much they enjoy writing Rust (many skilled programmers do not).
+ Whether they choose to use bevy or are forced to by external constraints.

## Current User-base

Bevy has a large user-base of of **Non-Commercial Technical Individuals** (hobbyist programmers). Most of these people are **Mainline**, using the most recent release of bevy as a dependency. They do not build the engine from source, modify the engine internals, or submit patches to the repo.

We have a smaller set of **Forking/Patching Technical Individuals** (engine contributors). These are mostly **Non-Commercial** as well, and work on bevy in their spare time. One of Bevy's greatest strengths is that "Bevy App developers are Bevy Engine developers, they just don't know it yet," which means this set of users is porous and constantly expanding.

There are a small number of **Commercial Technical Individuals** like Dustin Deweese (Noumental) and Pressing Thumbs Games (Times of Progress). Dustin is **Forking**, and upstreams mainline changes to his private branches. Pressing Thumbs is keeps **Mainline**.

We have basically no **Non-Technical Individuals** currently. But that's to be expected; it's a code-forward engine.

Moving on to teams, we've got more diversity. **Non-commercial** teams seem to be uniformly **Mainline**. They don't have the resources to fiddle with the engine or editor. Most **Commercial** teams seem to be **Patching** or **Mainline**, including Foresight and Dead Money (Architect of Ruin). This is likely due to our non-existent legacy support and our policy of not back-porting critical patches to older versions; a hard fork is not an easy thing to maintain. One notable exception is Pounce Light (Tiny Glade) who went **Forking** very early on (to great success).

## Prioritization

For the MVP, we are going to focus on supporting:
+ Small to midsized **Commercial Teams** (2 to 20 people),
+ Who are either **Forking** or **Patching**
+ And who have a mix of **Technical Users** and **Non-Technical Users**.

I'm going to call people from these sorts of teams *Category A*.

Why focus on these people? First of all, it is commercial teams that ship most games and provide the bulk of the Bevy Foundation's funding. It's also commercial teams where you will currently find most **Non-Technical Users**. And **Forking/Patching** teams specifically are able to provide support and customization for their **Non-Technical** members, a burden that would otherwise would fall to us. These teams are also the most likely to contribute patches to the editor once they start using it.

So what shouldn't we prioritize? Bevy is explicitly not targeted at **Non-Technical Individuals**; someone on your team needs to know rust to use bevy.

The remaining group, **Mainline Technical Users** and their **Non-Technical Teammates**, are a second-class priority. Features that support these users are good; but it's not what we should focus on. I'm going to call these people *Category B*.

## Preliminary Conclusions

Here are some general conclusions about category A.
+ The Editor is for both technical and non-technical people.
+ We can expect non-technical people to rely on their technical team-members for support.
+ Much like bevy itself, technical editor users are editor contributors.
+ The editor source code must be easy and friendly to fork and modify.
+ The editor does not need to be modifiable or extensible *at run-time* however.
+ The editor expects to operate in a cargo workspace, and for rust tooling to be installed.
+ But it should be fairly easy for Non-Technicals to install the editor along with the rust tooling.
+ And it should be easy for Technical Users to package and deploy custom forks of the editor.
+ It should be easy to fork the editor without having to fork bevy.

## User Workflows

Now let's imagine a few little teams of this sort, and follow along as they go about their work. This is a slight adaption of the typical "User Stories" which is better suited to making broad technical decisions.

### Lynn and Kate

We'll start with simple two-person game studio: Lynn (programmer/level-designer) and Kate (artist/writer/level-designer). Lynn is great with rust, Kate has some programming experience but not in rust. Both know how to use version control. Neither has used Bevy before.

### Puzzle Platformer
Our two-person studio is designing a 2d puzzle-platformer, the exact mechanics of which are not important.

The first thing Lynn has to do is install bevy and the editor on both of their machines, set up a project, and check it into version control.

> This screams *template* to me. It's probably fine to ship this as a command line tool, since it's Lynn's job to do this part. Not something we need for a prototype, but important for the MVP.

Meanwhile, Kate makes a sprite-sheet for different tiles. They check it in to version control, and wait for Lynn to show them how to start making maps.

Lynn decides to add `bevy_ecs_tilemap` to the project and does some very minimal setup. Then she opens the editor, because she wants to make a test-map to learn about how queries work.

> Ideally, she should be greeted by an editor that knows about the important components defined by `bevy_ecs_tilemap`.

What Lynn needs to do next is spawn an entity with a `TileMapBundle` (or the `bsn` equivalent).

> How does she do this? More importantly, how does she know she needs to do this?

Let's assume the `TileMapBundle` she spawns is empty. She selects the tile map entity so she can edit it.

> Perhaps she clicks on it in some sort of hierarchy explorer? It won't be visible yet.

She is presented with a widget that shows the different properties of the components on that entity. She configures things like the size, shape, and transform, and connects up Kate's sprite-sheet as a texture.

> How does Lynn get feedback that what she is doing is correct? Pcwalton suggests loading a serialized form of `Schematic` data from the main app.

Now Lynn wants to add some tiles to the tile-sheet. This is complicated; `bevy_ecs_tilemap` contains an index, which records the position of different entities. She discovers that she has to spawn each tile entity manually, then go and update the index with it's position before it shows up.

> Obviously this isn't ideal, but for the purposes of this user-story let's assume `bevy_ecs_tilemap` has no extra editor support; it's just a WYSIWYG editor for entities and components.

Lynn gets frustrated. But she has heard that Bevy's editor is supposed to be painlessly extensible, so she clones the editor repo, asks for help on discord, and it's not long before she has extended the editor with a widget that lets you spawn and position a tile in a single step.

> I'm going to end it here, with the question: How does Lynn get her widget onto Kate's computer? Does she compile a binary and send it to her, or does she check the editor into a new repo (maybe even the game repo?) and let Kate build it?

## Editor's Note

The existing team is supposed to represent a pair of expert game devs who are new to Bevy, and want to evaluate it for their next project.

In future, I'd like to do another pass on their personas. I'd also like to think about the following cohorts
+ Expert programmers who are new to Game Dev and Bevy. (We have to ask ourselves, why are they here?)
+ People who dislike Rust but who try bevy because they like the ECS design. (credit pcwalton)
+ People who are interested in using our advanced rendering features, but who may not be very interested in rust or bevy. (credit pcwalton)
+ People creating mods for some Bevy game who are using Bevy in anger. (credit pcwalton)
+ Students/novices/complete beginners. (credit IQuick)
+ Researchers/arcademics who want to use bevy as a research platform.
+ Participants in a game jam.

Obviously, not all of these groups should be prioritized; but it is good to consider as broad and diverse a user-base as possible. People *always* always find unexpected ways to use software.

I would also like to add some consideration of commercial/funded vs non-commercial groups to the overview section. In some sense, I think it really is commercial groups the editor aught to target initially, if only because we need more sources of funding the non-profit.

Please feel free to modify this document however you see fit.