More complex game examples

[alice-i-cecile]

What problem does this solve or what need does it fill?

1. More complex code bases to allow us to better reason about the ergonomics of ECS features.
2. Better integration testing. This can also be used to help inform change lists and upgrade guides from Bevy versions.
3. More examples to show off and learn from :)

What solution would you like?

Extend the sample games from Breakout to include a larger variety of more complex games.

What alternative(s) have you considered?

1. We could use community example games for this, but they won't be as discoverable for beginners (use 3) or as useful for bikeshedding (1) or integration testing (2). A canonical list helps set the terms of discussion in a more concrete way.
2. We could put these examples in another official Bevy repo, which relies on bevy master as a dependency. This hurts discoverability, and won't block PRs being merged (I think this is probably net good), and risks falling out of sync.

Additional context

When adding games, we'll want to be mindful that their value is proportional to their upkeep cost. While there's a lot of possible use cases that would be nice to cover, we'll want to minimize overlap between examples to avoid duplication of effort. Demonstrations of specific features should be in minimal examples like we already have, while domain-specific tricks probably belong in awesome-bevy.

Upgrading the games as they break is also very easily delegated to community members: it's a fun task, their correctness is important but not critical and doing so requires no knowledge of the internal code base.

As is hopefully already the case, we'll want to avoid packaging these more complex examples (and any assets they use) as part of the standard cargo release of Bevy to avoid pointless bloat. Hopefully we can have each of these in their own dedicated subfolder within examples/games, with breakout as the first one.

[alice-i-cecile]

Here's my personal starting list of ideas, roughly in order of how important I think they are. There are a lot of other super iconic games that could be useful as teaching example (2D platformers, snake etc.) but they tend to share a lot of the code with others on this list (especially Breakout) so are probably better as community tutorials.

Breakout

Already exists, although could probably use some cleanup to be more idiomatic. Nice simple demonstration of controls, 2D graphics and eventually simple sounds.

Game of Life

Very elegant ECS design, and can be used for bikeshedding about how indexes and / or events should work.

Choose Your Own Adventure

A clean example of how to run Bevy without using the standard GUI plugins and in a non real-time fashion. Can also demonstrate dialog trees, state tracking and so on.

JRPG

Demonstrates how to implement turn-based mechanics in concert with simple animations and continuous UI events.

Minecraft-clone

Demonstrates common 3D interaction on a first-person basis and allows for some more complex ECS behavior. Also useful for bikeshedding on UI models. This may want to depend on bevy_rapier?

Isometric tower defense

Complex ECS behavior, isometric cameras, pick-and-place interaction paradigm, possibly some light performance stress tests.

Ecological model

Showcase Bevy's use for applications outside of classical games. Run in a fully headless mode at maximum speed, and demonstrate how to do nice logging.

[cart]

Yeah I dig this idea. I think in-repo is a good idea because it keeps everything in sync and makes discoverability easy. We should just maintain the "minimal" requirement we currently apply to examples. The games need to be "small", idiomatic, and easy to understand. Frivolous features should be avoided.

Eventually I'd like to have out-of-repo "template projects" for various game types, but imo those will have different constraints (ex: well documented, easy to clone and build off of, standalone, assets can be larger / bigger).

I think which games we build / what we build first should be dictated by:

1. Filling niches that aren't already filled (ex: a 3d game example is notably missing)
2. What contributors are motivated to build.

[mockersf]

I'm a big fan of having a few showcase games!

Having those showcases in external repos in bevy org makes more sense for me. Examples in bevy itself should be kept short and concise.

• having those games in the same repos will make it more scary to dive into
• blocking PRs on failure on a complete game will slow new contributors or people not accustomed to this game
• having the game deployed and runnable from bevy's website with wasm will greatly help its discoverability
• different repo means easier to setup permissions
• I like how Amethyst is doing it

[cart]

Yeah I think "showcase games" and "example games" would have different requirements. Showcase games don't need to be "minimal" and should definitely live outside of the repo.

[cart]

And there is an argument to be made that "showcase games" are more important than example games (maybe to the point that the distinction is not useful).

But I do like the idea of having a small number of "example games" in repo that serve as "tests" that break when apis change. And being able to easily clone the repo and run cargo run --example breakout is really nice imo.

[mockersf]

What should be the size of an example game? Looking at breakout (~250 LOC, 5 systems), something that can be done over a weekend by one person (and not a Ludum-Dare person, some of those are crazy over a weekend, a regular-with-a-family-and-sleeping person)

[cart]

Yeah I think "breakout sized" is the target (with some wiggle room of course). I agree with your definition. Imo example games should be build-able in a day or so (maybe less) and should have very low code complexity (which makes them easy to read/understand and easy to keep them up to date).

[cart]

Whereas the only constraint for showcase games would be "high quality and idiomatic"

[alice-i-cecile]

So it sounds like there are five classes of examples:

1. Unit examples:, which showcase a minimal example of a specific feature. These live in the main repo in the corresponding folder and are synced to master.
2. Cookbook examples: useful code snippets for performing common tasks using Bevy. These can live here or we can take that repo into the fold of the Bevy org.
3. Example games: a minimal example of a useful class of game with limited overlap that serve as integration tests. These live in the examples/games folder and are synced to master.
4. Template games: idiomatic starters for a specific game genre that have all of the useful, standard functionality. These live in their own repos and are synced to the latest crates.io version.
5. Showcase games: high-quality, open-source idiomatic complete games. These live in their own repos and are synced to the latest crates.io version.

[ValorZard]

I think its a really good idea to have a 2d platformer example. It's a staggeringly common type of game, and if you add collision, you could also show off how to integrate something like rapier into your game.

[alice-i-cecile]

I think its a really good idea to have a 2d platformer example. It's a staggeringly common type of game, and if you add collision, you could also show off how to integrate something like rapier into your game.

Yeah, I think a 2D platformer is a perfect candidate for the first template game. Create something high quality and genuinely fun, with working functionality for all of the common gimmicks that users can strip out as they see fit (because ECS makes modularity really easy).

[cart]

Yeah I think thats a good call. I also think theres a very natural progression from "game template" to "showcase game". Once you have a minimal template, adding new features / real assets should be relatively easy. And they can feed back into each other when improvements are made.

[mockersf]

I gave a go at a small 3d example there: #1252

[inodentry]

Ecological Model: Showcase Bevy's use for applications outside of classical games. Run in a fully headless mode at maximum speed, and demonstrate how to do nice logging.

This would serve as an amazing ECS performance benchmark!

It would be a realistic usage of the ECS, rather than the current suite of (mostly) micro-benchmarks stressing specific ECS operations.

[CleanCut]

I made a small showcase game, Punch Ball, to experiment with Gamepad input. You're welcome to include and/or copy it in any sort of showcase collection if you like. Currently you need to have at least one gamepad connected or it doesn't do much.

[shironecko]

I'm interested in creating a tower-defence small showcase game. Been interested for a while tbh, the only thing that held me back was the lack of support for a fixed timestep, which has landed recently. That's pretty important for a TD since it makes things like slow-down/accelerate time trivial + added benefits for adding online play.

[alice-i-cecile]

@shironecko you might find bevy-tick-timers even better suited to this purpose :)

[shironecko]

@alice-i-cecile Huh, I took a quick look at the crate but the description is sparse. From what I understand it helps to schedule a one-off system run in n ticks (120 ticks per second by default) but for my purposes I need a way to run a bunch of systems at 33ms interval for example, while rest of the systems would be running as fast as possible interpolating the results of two runs of fixed time systems.

I have actually ran into another road block, I'll need an immediate 3D drawing plugin, like egui but for lines, boxes etc. Couldn't imaging doing anything remotely complex without such a lib. So I started to create one myself, outside of Bevy at the moment. I'm not a render programmer so Bevy's render machinery overloads my brain a bit. I plan to create a POC with WGPU and then integrate it into Bevy. Bonus points if I'll be able to make it render-agnostic, like ImGUI or egui.

[erlend-sh]

There’s a nice collection of ECS demos made by Unity devs here:
https://github.com/Unity-Technologies/DOTS-training-samples

[alice-i-cecile]

itch.io's Bevy tag has some nice examples. We could consider adapting one of those open source games for these purposes.

[LarsDu]

I'd be willing to donate StarRust to the community as an ongoing FOSS example project.

I'm working off of bevy main due to the breaking api changes that are incoming for 0.9 which has prevented me from incorporating plugins like kira audio and bevy hanabi to the project.

Once 0.9 lands, I'd like to add things like volume control and particle effects and open up contributions to this game from more folks (maybe in the vein of SuperTuxKart).

[alice-i-cecile]

Oh neat; that may be compelling. There's a ton of polish that you could add. Something more feature complete (ala Nova Drift) may be a nice showcase that remains approachable. Would you be willing to continue managing the project @LarsDu?