With the rewrite to Rust, the Medusa system is moving from a Javascript prototype-based engine (half OO, half data-driven) to a strictly typed entity component system, which is a somewhat confusing model to wrap one’s head around.<\/p>\n\n\n\n
My best understanding to date for the entity component system is along the lines of, a warehouse of colorful pallets with ID numbers printed on the front (entities as the pallet, entity class as the pallet color, and components as objects on the pallet), and workers\/machines that pull pallets from the warehouse and change them according to some logistics (ie, systems). <\/p>\n\n\n\n
If you want everything on a pallet, you can pull it by ID – maybe you’re going to clear the pallet out, or you have a use for everything present.<\/p>\n\n\n\n
Maybe you just want the pallets that have food items so you can assess allergens, so you pull all pallets containing allergens to check at the machine.<\/p>\n\n\n\n
Maybe you have all baseball items on red pallets, so you only want to pull red pallets when readying a shipment to the local sports store.<\/p>\n\n\n\n
So on and so forth – you mix and match criteria about what is on the pallets or identify by the pallet ID itself to accomplish goals, and just like machines you can process the inventory in a dependent order or freely as the stock comes in.<\/p>\n\n\n\n
(There are some breakdowns in metaphor, but that’s the rough mental model I’m starting on.)<\/p>\n\n\n\n
Medusa’s current engine needs to be broken down into its entities, components, and systems. Entities is simple, since we’re using Bevy – everything in the ECS is just part of the same overarching Entity type. That’s one easy hurdle over, but it means that we no longer have a way to paint our pallets a certain color.<\/p>\n\n\n\n
To overcome this, we can introduce a new type of component – a tag component. Tag components exist only to “paint the pallet” – we can use them as a way to pull entities of a certain category. This seems like a good second place, so we’ll start with one Tag component for each type of entity we have in the game; we can remove unused tags if needed later.<\/p>\n\n\n\n
That’s a starting point, we can at least spawn these into the framework now when loading a map, though not much else – they won’t even render. We’ll need some real components to give them some meat, and some systems to, er… cook that meat… <\/p>\n\n\n\n
…maybe no more metaphors. <\/p>\n\n\n\n
We can start with a simple system first, the render system. Thankfully, Bevy comes prepackaged with everything we need for that, so we only need to provide a component for the sprites! Anything we want to render will need a sprite (conveniently ignoring non-sprite rendering)<\/em> so we’ll add that to every entity. We’ll use Next, all of these are located somewhere on screen. As such, they need a position – this can be handled just on transforms, but since we may want to mess with the visual position without affecting the game world position, we’ll opt to have a dedicated We’ll want a system to calculate the transform positions based on the objects’ game world positions and update it accordingly, so we’ll add a That gives us enough of a starting point to get these fellas on screen, so I’ll go do that now. Next post on the topic, we’ll look at entity-specific behaviors and try to build up something simple: a rotating mirror.<\/p>\n","protected":false},"excerpt":{"rendered":" With the rewrite to Rust, the Medusa system is moving from a Javascript prototype-based engine (half OO, half data-driven) to a strictly typed entity component system, which is a somewhat confusing model to wrap one’s head around. My best understanding to date for the entity component system is along the lines of, a warehouse of…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-97","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=\/wp\/v2\/posts\/97","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=97"}],"version-history":[{"count":4,"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=\/wp\/v2\/posts\/97\/revisions"}],"predecessor-version":[{"id":101,"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=\/wp\/v2\/posts\/97\/revisions\/101"}],"wp:attachment":[{"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=97"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=97"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jdkendall.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=97"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}TextureAtlasSprite<\/code> for this, as it will make animation easier later.<\/p>\n\n\n\nPosition<\/code> component with x<\/code> and y<\/code> integers as fields. While we’re at it, many of the entities have a direction they face as well, so let’s throw in a Facing<\/code> component which contains a direction enum field as well.<\/p>\n\n\n\nPositionSystem<\/code> for that which for now will just set the transforms for our sprites to match our positions on screen through a camera transform.<\/p>\n\n\n\n