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.