Looks awful but this is how tic tac toe game will look in ECS spirt
And only small pieces in the type's impls
As the rule of thumb if more than 1 system needs it - put it into type's impl or free function
But, for example, checking winning condition should be in
WinningConditionSystem
Another system can read input events and place new Xs and Os
Surely, small systems that tied together can be merged into one, but two separate system illustrate ECS approach better
Is it possible to iterate over all component types in a world? For normal functions the ecs system model works great, but I'm trying to make an inspector that exist outside of the purview of the ecs and needs to show data for all components an entity might implement. It happens before the ecs dispatcher actually runs, so I don't care about the mutability or anything of particular component stores, I just need a way to check if an entity has a certain component, and get the values from the components stored in world
Right now I'm thinking I might have to register component types with a macro and iterate over a list of strings, but I'd rather avoid that :P
Can you, for example, write signature for function that will "iterate over all component types in a world"?
Can't you get a resource with try_fetch_internal or get_mut_raw? If so, you can have a function like "register_component_with_inspector" that takes the world its registering to, and also has a vec of typeID's, and save the type id for the type that you are adding, and then at runtime iterate over a list of those typeid's using try_fetch_internal or get_mut_raw, or am I misunderstanding somethign?
You still need an actual type
What you can do is to prepare a closure for each registered resource/storage
Which can downcast and do some predefined operations with it
i.e gives you closure that internally knows the type, casts and does what it needs to be done
It can't return downcasted type, cuz, you know, all those closures should have same signature
hm, well I thought about trying to combine specs with some methods to "bulk simulate" find entities that have specific components and instead of doing something for each of them, do it for the amount of them instead and save the relative change to then be able to lazyily retrieve it when acting on a single entity for example. Though I'm not sure how feasible that is and how big the performance improvement really could be. especially when you have to save these things for 1000s of component combinations and also have to calculate changes for broader combinations, when having changes to more specific ones... maybe I got a bit carried away
@danaugrs_twitter You can use https://docs.rs/specs/0.15.0/specs/storage/struct.Storage.html#method.insert to add components to existing entities.
Is there any way to modify the order that entities/components are obtained from a
.join() iterator? e.g. for z-ordering?
@torkleyy Is there reason for not implementing Send for Dispatcher? I asked this in slide-rs/shred#147 but never got answer and now it's merged
Hey everyone, sorry if this is a noob question(or if there is an example somewhere, although I couldnt find any), but how would I go about "comparing" entities to each other when running a system, i.e. pairwise iteration, for something like collision detection? If i also want to mutate in that system? Or is it better to separate collision detection and collision handling into 2 systems? - Thanks in advance if anyone is able to help!
Hi, I've been working on the movement system and got an issue:
impl<'a> System<'a> for DestinationMovement {
type SystemData = (
Entities<'a>,
WriteStorage<'a, Position>,
ReadStorage<'a, Speed>,
ReadStorage<'a, Destination>,
ReadExpect<'a, Timings>,
ReadExpect<'a, Map>,
);
fn run(
&mut self,
(entities, mut positions, speeds, destinations, timings, map): Self::SystemData,
) {
for (_entity, speed, destination, position) in
(&entities, &speeds, &destinations, &mut positions).join()
{
let destination_position = positions.get(destination.0).cloned().unwrap();
// rest of the code is irrelevant
}
}
}Some entities have a destination, which is wrapper over Entity, and to calculate a path to destination I need to retrieve destination's position. Naturally, I also want to have own position of the current entity itself.
Issue is that iterator mutably borrows positions, so I cannot use it inside loop. For me it looks like a very common issue, so maybe there is known solution for this problem?
I could remove positions dependency from join and get both entity and destination position inside loop, but I don't like that it will relax component requirements for this system. Another potential solution I can think of, but haven't tried, is to collect all new positions into separate Vec and then assign them with another loop. I don't like performance implications of this approach and unsoundness of it.
Is there anything else I can do?
@malynome You can do
join within join by using just Entities to get both entities, then compare them for inequality and then access storages. In our game I think we first did that, but now were doing simple sweep-and-prune by using flagged storage to maintain internal data structure.
Or is there another way to get components of an entity if you know the entity already?
For that matter, it's unclear as to whether Judy arrays (the data structure that Rudy aims to implement) are even any faster. They were designed a while ago, so modern CPU's might have different performance bottlenecks.
world.insert(unsafe { transmute::<&'_ DebugOverlay, &'static DebugOverlay>(surface.debug_overlay()) });
I'm profiling my code and seeing that DispatcherBuilder::add eventually starts to take a long time (~400ms). A RawVec realloc is what's taking up the whole time. The only thing I can think of is that there's some global state associated with each System that keeps getting added to when I make a new Dispatcher each frame. I wanted to try making the Dispatcher once, but I can't figure out how to have one as a member variable on my struct because I don't know what lifetimes to template it with.
hey, can someone tell me if a VecStorage will ever shrink in size?
Looking at the VecStorage implementation of UnsafeStorage it seems that when entities as entities are added the vec grows, but the only way it can shrink is when it is cleaned, where all entities are removed. Is my thinking correct?