Bevy Rewrite

[zicklag]

Here goes nothing. 😉

Web Demo

Here's a web demo that auto-follows this branch:

https://jumpy.zicklag.spicy-lobster.katharostech.com/player/bevy-rewrite/

[zicklag]

Got the main menu working and tons of boilerplate done for localization, controller mapping, etc.

Next is the character select menu, and then map select menus.

[zicklag]

Got basic player selection screen. Needs some work, but it's good enough to move onto map loading.

jumpy-player-select.mp4

[erlend-sh]

Excellent!

We should start delving into the netcode (and subsequent Ultimate integration) as soon as is fitting.

[zicklag]

Got it. Networking is a requirement for shipping right? Or should we try to get a local-only version shippable first?

If it's required for shipping then I'd put effort into that earlier rather than if we wanted to just get a local version first.

[erlend-sh]

Yeah online version has highest priority now. Local was more important when playtesting was the primary objective, but now we’re going for production-ready MVP.

[zicklag]

Making progress on the editor UI and was able to theme Egui's default widgets so that it doesn't stick out as separate from the game as much.

[zicklag]

Got more of the editor workflow worked out. The editor can display the bevy world ( map loader coming soon ) and control the bevy camera, zooming in and out and panning. You can also click the play button to instantly switch to playing the game ( not that there's game to play yet ) on that map. Then from the pause menu, you can go back to editing the map. This should help the editing workflow a lot, so you can go back and forth between editing and testing very easily.

Oh, and I also added a background pan-and-zoom effect to the main menu. The effect started on accident while I was testing camera zoom, and then my brother said "oh that could look good". It might need tweaking, but I think it does kind of give an underwater feel a little bit.

I need to make the parallax work later, because for now it's just flat.

Also, the background panning is implemented with a script using the scripting API, so it's super easy to change and can be modified per custom asset pack without modifying the game.

jumpy-ui-demo-3.mp4

[zicklag]

Getting a better grip on the UI: did some organization and now I've got the map creation dialog:

map-create-dialog.mp4

Now that I've got the foundational UI and dialog structure in place, it shouldn't be too long before I've got the map layer creation and configuration working.

[zicklag]

Didn't get much time for this today, but I did get a map grid rendering, and bevy_prototype_lyon which I used for the grid will be useful for collision shape debug rendering, too.

map-grid.mp4

[zicklag]

Got the layer creation window and layer list made:

Soon I should have map layers rendering.

[zicklag]

Just finished a script that converts the old maps to the new format. That should save us some work and now we should have something to render.

Immediate next steps:

• Get tiles from the ported maps rendering in the game
• Get parallax background rendering for the map ( sort of ), no parallax movement effect yet
  • Make custom parallax plugin because bevy_parallax only supports horizontal parallax.
• Get map items and decorations spawning

---

Also @erlend-sh, what's a good deadline to attempt for finishing the whole MVP? I want to set a specific date to work towards.

[erlend-sh]

Ideally we’d have a functional (playable) MVP done by early November, so that we can dedicate most of November to polish and juicing ahead of the prospective crowdfunding event in December.

[zicklag]

Got a map rendering! Still plenty of work to do before it supports the rest of the map features.

[zicklag]

I got map kinks worked out now, and all of the maps have been migrated.

I also got the background spawning, but I'll have to make my own parallax system because bevy_parallax only supports horizontal parallax. Shouldn't be too big a deal, though, I don't think. I'm going to come back to that after working on getting map decorations spawning.

[zicklag]

Today I got map elements basically spawning, but doing absolutely nothing, so that doesn't mean much visibly. I tweaked some of the map element metadata so I'm almost ready to get a functional map item.

Most of the work today when into allowing scripts to create Bevy components with jakobhellermann/bevy_mod_js_scripting#26.

To clarify is not just for modding. My plan is to have all map elements spawned with scripts that add the necessary bevy components. So we may use scripts in a way that is conceptually similar to Bevy scenes. This makes it super easy for us to add new kinds of items and tack on different functionality by specifying different components.

The scripting API is maturing quickly and it's very easy so far to work around any limitations we run into, so my hope is that we'll be able to get started "right" with scripts out-of-the box, instead of rewriting things to use scripts later.

I'm being very conscious of how much time it's taking against our timeline. I think that having scripts now will also help accelerate the work we need to do in the Polish & Juicing phase, which is primarily asset driven and will benefit from the ability to iterate quickly on in-game items and artwork.

If scripting turns into a short-term obstacle instead of a benefit, it is easy to back out of and move to Rust + YAML to avoid it taking any more of our time.

---

Anyway, now that that's working, I'll work on getting the seaweed item created, which should be very simple. It will just be an item that get's spawned with an animation clip component.

After that I think I'll add collisions to the tile maps and spawn a player into the scene. Then, I work on the character controller.

Finally, that's probably a good time to delve into the networking code.

Once we sort out networking in it's basic form, then we can create the weapon items, and get some form of actual gameplay going. Hopefully all before the end of the month! I'm feeling good about the progress and speed so far, but there's still lots to do!

[zicklag]

Just got seaweed working!

seaweed.mp4

And because the editor is embedding a real game view, it's actually animated in the editor like it will be in the game!

[Zac8668]

Discussion from discord

I was actually working on something similar, and I tried using rapier polylines(I think you're using rapier too?), not sure if that even brings some benefit but I wanted to share, the result is something like this, without the unnecessary inside colliders, maybe that's better? it needs a collider "update" everytime you change the tiles tho

[zicklag]

I finished migrating the physics engine from the old Jumpy! I just have to add collision shape debug rendering, and then I'm on to developing the character controller and state machine.

It will be mostly copied from the state machine designed for Punchy, but the goal is to have all states implemented in scripts.

Because of the temporary limitation that scripts cannot create new components yet, we will probably represent the current state with a string, instead of a marker component, and then we can easily migrate to the more ECS-like solution of using components once that restriction is lifted.

[zicklag]

I think I've finished off the MVP matchmaking server! It can spin up Bevy game servers on demand, in response to requests to join games of a given number of players.

The QUIC network transport used to communicate with the matchmaking server now has Bevy resources for easily sending and receiving messages in the game systems and I'm ready to start working on the in-game flow of joining an online match, picking your player, and getting into the game.

[zTecna]

I used the character's sprite to make the sheet

[zicklag]

Perfect, that's exactly how I need it. Thanks!

[sailormoon]

Love your project -- I'm curious why you decided to rewrite into Bevy instead of Macroquad. I'm currently evaluating engines for a 2D game I'm writing.

[zicklag]

I haven't used macroquad myself very much at all, so I can't speak to it directly, but the previous lead developer on Jumpy did, and was feeling some limitations with it, and ended up starting work on a custom renderer for it. I'm not sure what the complete story as far as the limitations were.

As far as why I wanted to use Bevy, I like that Bevy is powerful and extremely modular so I knew I could write a plugin for anything that I might need that it didn't have. It has gotten a lot of attention, has some good people behind it with good ideas, and it's continued to develop and get better and better quite quickly. Building on Bevy has the advantage of having the option to leverage the many plugins that people are developing for it too, which might get you some fancy features for free, like 2D global illumination.

The disadvantage to using Bevy is that it is more complicated, and you may have to work out some things yourself or find plugins for some things that aren't easily built in yet. Bevy is also under heavy development, so you have to be read to update your code when they make changes to the engine. ( some of this points may apply to other engines, too, though )

Notably, for Jumpy, we have just about moved it away from using Bevy directly, and are now building it on top of our own Bones engine. There were a few things that we needed that weren't being provided easily with Bevy and it motivated us to write our own ECS and framework:

• Determinism and snapshotting - used for rollback networking support
• Easy hierarchical asset loading and user asset packs
• Scripting support for making mods

Jumpy is already using Bones ECS to get deterministic snapshot and restore, but it is still using Bevy at the same time for the main menu and other stuff outside of the main game loop. I've just recently finished the bones asset loader and foundation for scripting, and now we're in the progress of moving Jumpy completely over to the Bones framework so that it won't be using Bevy directly anymore.

The Bones framework still uses Bevy in the background to do rendering, audio, windowing, and input, but the bones framework is technically renderer agnostic and could actually run on top of something like Macroquad.

Bones still keeps some of the ability to build on Bevy plugins, though, for example, if you wanted to use the 2D lighting plugin for Bevy. It would require adding a little bit of integration code with Bones, but it's possible to write Bones plugins that add support for Bevy plugins, so we still get, to a lesser degree, the ability to leverage some of Bevy's ecosystem.

The idea with Bones is to be more opinionated and simple than Bevy and have everything we need to make 2D games like Jumpy. We want the developer experience to be as nice as possible, while balancing with simplicity, power, and performance, roughly in that order.

The Bones framework is nearly ready for other people to use it I think. As soon as I finish getting Jumpy completely ported to it, which is my top priority right now, it will be in a state where other projects should be able to use it, you wanted to try it out. It's extremely new, so there will be some rough edges, but at the same time, Jumpy will be using it, so it proves that it can actually make a game, and you can check out the Jumpy code if you want to see what a game in it looks like.

---

Another recently released option worth looking at is Comfy. It looks like a good option for starting a 2D game, and it is probably simpler than Bones, maybe more similar to macroquad. While macroquad and comfy ( as I understand ) probably give you simple ways render basic stuff like sprites, etc. in whatever way you want, Bones works more like a mini Bevy, being built around an Entity Component System ( ECS ), and that being the way that you interact with the engine.

---

I hope that helps! If you have any more questions I'm happy to help, you can ask here, or you can also join the Discord server, where I'm often available.