![]() ![]() Portals work fine (transport just the head, and everything will follow through a portal), different body parts aren't an issue, it's easy to split a snake, it can be grid or open world, works fine with barriers, is somewhat easy to add new states, and velocity changes/etc are easily applied in sequence (without having to consider the impact of uniform application of velocity). I like this approach in part because it is super-flexible with no shortcuts. There are a lot of ECB calls during the destroy or grow phases, but they should only trigger occasionally, so I see it as acceptable. Just pass in player data and run it on every single snake body entity. Since every snake-body entity has a reference to it's "player-owner" and can check its state from there, it's easy to trigger destruction for all entities in a single pass without the need to cascade. Run DestroySnakeCheck, then run GrowOrMoveHead (setting the head's desired position), and finally MoveAll. So, essentially, run a collision check on each head, set the state on the player-owner as "move, destroy, or grow", and set it's move-to position (or however you handle the movement after checking). One way or another, pass in the player input, check collision and set the state. Movement just needs to give the orientation to the current head (it's a follow the leader situation), so run a job on entities that do not have a parent ("heads"). Every snake-body entity would have a reference to its player-owner's entity/data. I'm fuzzy on the exact ease of getting an entity reference from the ECB because I haven't had to do it, but I believe it's possible.įor movement and destruction, I'd use the entity/data that already holds player data - it should also hold its snake state. ie: the current head is no longer a head because it has a parent component, and the new entity is the new head because it does not have a parent component. Eat-grow would trigger spawning a snake-body without a parent, and adding a parent component with that reference to the just spawned new head. It's also only the head that triggers a collision in a way that it "eats" or "dies". A "head" is one that has no reference to a parent, and player input only operates on the entity that has no head. To eat and grow I would avoid thinking of tagging an entity as a "head". In my case, it was a tile map of 250,000 doing 4 neighbor equivalent operations in sequence - about 20ms. That might not be the actual solution for a snake game, but it's very ECS friendly. Complete that system, then run the second system to set the new position based on its 'want-to-move-to-position'. ![]() The movement would have two systems - first system just copies the location of the parent's position into the "want move to". I'd make each snake-body entity have a reference to its 'parent' entity, its current position, and the position it wanted to move to (along with rendering stuff, and its ID, and from below, a reference to the player's data). It also makes it more flexible (eg: different body part types won't work with flipping tail to head, etc). I'd love to hear the flaws in my thinking below - but I'm trying to stick with the "the whole snake needs to move" non-trickery thinking as that is what I had to deal with. I'm new to DOTS/ECS, but had to build something that has a similar logic. this said if the max size of the snake is not known, just due to better memory management having each body part as an entity wins the competition. in fact maybe fastest way would be to not represent each snake body part as an entity and instead represent the snake using a single dynamic buffer which a move function works on when you want to move it. You chose a good problem since it is not linear access all the way ad can challenge you. O speed it up you need to know the relative size of snakes compared to relative size of the list for change direction commands and number of snakes in the game. InputSystem (which adds direction points)Ī collection for the list of direction changes is needed as well. Head, smake and tail components are needed for identification, a forward component and a few systems: You can remove a change direction point if a tail entity is passed of it. Now foreach entity you can check if it is at a direction change point or not and if yes then change direction and t then move forward, therwise just move forward. Whenever input happens a change direction command will be added to a point which any entity at that point should process. Looking at it the data oriented way I would see a set of body parts which can move forward and can change direction. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |