Goals

Provide a relatively easy to use, adaptable, and customizable system for pathfinding and calculating an objects available moves.

Write-Up

Adaptable, replaceable, and extensible.

Provide a basic movement system and allow it to be replaced as needed.

Features for Release

• Multiple units in tile selection
• Movement Component with basic movement information
• Backend to handle the movement system events and update resources with support for any implementation easily
• Default movement system implementations - advance wars style
• Option to override a tiles movement cost over it's terrain cost and support it in the backend. Either through objects or through the actually tile. Ex. Building a road on the tile and updating the movement cost through that //-- Tiles currently use a unique component for their move costs. Nothing stops anything from updating this and changing it. It wont get automatically changed back to the default terrain cost if its changed though.
• Option on objects to override their allowed terrain types for specific other objects. Ex. A bridge building object that allows land units to go over the water and prevents water units from going onto it. // Implemented optional ObjectMovementTypeRules. If assigned to an object it checks the tiles during the TileMoveCheck phase to see if there is an object on the tile that has a rule related to one of the rules in the objects ObjectMovementTypeRules component

Notes

Marking this as a placeholder to come back later. Should eventually update the entire project with some form of tracing and debug stuff to help development. No idea what it would look like though

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

I want to use bevy_sparse_tilemap for several projects that this crate is built to support instead of bevy_ecs_tilemap. Mostly due to performance reasons. This crate is currently hard locked to bevy_ecs_tilemap which is not ideal.

I would like to either swap it to bevy_sparse_tilemap or create some kind of abstraction that would allow using any tilemap crate.

Is your feature request related to a problem? Please describe.

There is currently no game state management in the framework. There is no way to describe turns, whose able to move, turn based mechanics, nothing. All this is essential for a turn based game.

Describe the solution you'd like

Implement a custom game state management system. Ideally a robust system for basic game state management that can be extended by end users. Turns, teams, players, events at separate parts of the overall turn and the individual players turn to enable custom logic and functionality.

Describe alternatives you've considered
End users could roll their own but that is antithetical to the idea of the framework.

Is your feature request related to a problem? Please describe.
Texture_Index is part of TerrainType. This works for simplicities sake however is not very future proofed and would be easier to deal with as its own component.

Describe the solution you'd like
Create a new component to handle the texture information of the tile

Describe alternatives you've considered
We can leave it as is for now, or potentially just use the Bevy_ecs_tilemap component. Leaving it works for now, however eventually it needs to be removed from the terrain information or updated to be more versatile

Is your feature request related to a problem? Please describe.
Currently only one object can have any moves listed in the resource CurrentMovementInformation, essentially meaning only one object can ever be moving at once.

Describe the solution you'd like
CurrentMovementInformation should be adapted to be a component that is held on the entity that has those moves. It should not always exist but can be added and removed depending on what the state of that entities movement is.

Goals

Write a basic getting started guide now with the currently implemented features. Doing so makes it easier and simpler to update it and add more once the project gets bigger rather than writing it all at once

Goals for this feature

Current information is minimal on what the next phase will look like. This tracker is intended to track them as they are finalized.

Write-Up

Features for Release

Misc Notes

Explore alternate ways to structure ObjectMovement rules (eg, movement/mod - ObjectMovement / ObjectTerrainMovementRules) with an implementation that is generic and trait based. Make it so that movement rules are defined using traits and generics so that a new type of movement rule doesnt require its own unique logic, setup, etc. Ideally make some way to iterate through the generic items and check them all automatically.

Both ObjectTerrainMovementRules and ObjectTypeMovementRules have essentially the same systems and definitions. We could just make them one generic struct potentially

Blocked on:

• bevy_ecs_tilemap
• bevy_ascii_terminal

Goals

Provide a basic guide/tutorial that explains the movement system.

It should explicitly provide the following:

• The parts of the movement system
• How the parts work together
• How to implement the movement system in a project
• What the user needs to do when they implement a default system into their project
  • TileMoveChecks
  • Etc
• How to modify the movement system
• Basic guideline on how to write their own MovementCalculator

Describe the bug
Movement/backend/move_object function will panic if there are more than one tilemaps because of use of .single_mut().

To Reproduce
Spawn two tilemaps at once and try to move an object.

Expected behavior
move_object should be updated to use the MapHandler resource instead.

Goals

Provide guide/tutorials explaining the parts of the Object System, what they mean, and how to use them. Provide meta insight into what the aim is for the object system and how it should/will be used

Is your documentation request related to a problem? Please describe.
There's no easy baseline explanation, example, or documentation on how to implement the movement system. This hinders learning and implementing it in other projects.

Describe the documentation you'd like
In code module level documentation explaining the system, general path, and how to implement. A dedicated minimal example of the movement system in the crate is also necessary help. Ideally one focused on getting a minimal movement system working. Additionally a meta-doc github discussion overview, walkthrough, and smaller examples would be very helpful as well.

Provide a basic guide/tutorial that explains the movement system.

It should explicitly provide the following:

The parts of the movement system
How the parts work together
How to implement the movement system in a project
What the user needs to do when they implement a default system into their project
TileMoveChecks
Etc
How to modify the movement system
Basic guideline on how to write their own MovementCalculator

Is there already documentation related to this issue?
There is no documentation or meta-docs relevant

Goals

Provide the foundations of a combat system. Methods for specifying an objects range, the tiles it can attack, and the criteria to check against each tile in range to see if it has any available attacks.

Write-Up

Adaptable, replaceable, and extensible.

Support for custom combat types. Keep two basic types in mind.

• Advanced Wars style where you assign a damage amount for each unit for each other unit in the game
• More generic strength/defense based system in the style of something like civilization.

Features for Release

• Combat Resolver System
• Series of combat components for objects that detail the basic universal combat related stats. Range, etc. As well as base other components, attack damage, attack type, etc. The latter would not be necessary for the backend of the system however would be necessary for any default implemetations made.
• Integration with Object system to have universal buffs, nerfs, and other affects on any objects of a specific class or group. Game wide and team wide

Notes

Range - can most likely use the movement system algorithm for this along with an optional post calculation prune to sort any special cases out.

Is your feature request related to a problem? Please describe.
Currently the framework extensively uses Entity to track relations, targets, moves, commands, etc. This has certain problems in that stuff like commands that track entities are in danger of failing if an entity is despawned in the command history. EG: If you spawn an entity in commands, move it, then rollback to before the spawn and then rollforward, the move will fail because its tied to the entity id, which is no longer correct.

Describe the solution you'd like
Implement a custom object id tracking system. The initial system can be simple but essentially it should allow tracking a different id that we can persist or assign through despawns and respawns to enable correctly assigning commands and such. This shouldn't be too hard to get but advanced use cases like networking will require additional future work.

Describe alternatives you've considered
I'm not aware of other alternatives since a big problem with entity ids is that they dont persist through despawns

Is your documentation request related to a problem? Please describe.
The object system is a fundamental system that is hugely important for every other system. It provides the baseline for everything else but it currently does not have much if any documentation, no meta doc guides, and no dedicated examples.

Describe the documentation you'd like
A dedicated crate level example showing how to code the object system. A dedicated guide to explaining how the object system works, the important components, and general guidelines. And lastly a reworked module documentation would be helpful.

Is there already documentation related to this issue?
There is no meta docs or example. There is crate level documentation but it's not sufficient due to a lack of detail.

Additionally, if you zoom in or out it will fix the issue and so far hasn't popped back up

Describe the solution you'd like
Movement should optionally have the capability to rely on something like Fuel. Objects should be able to specify both a component that holds the amount of whatever they have and a thing that requires that, eg movement. Then Movement should take that into consideration for calculations and such. This would be easy to add third party but having a basic version implemented would help a lot for most simple use cases

Is your documentation request related to a problem? Please describe.
MoveEvent enum documentation in Movement/mod.rs doesn't tell the user anything about what MoveEvent does, is used for, or how to use it.

Describe the documentation you'd like
Clarify what MoveEvent is used for in the backend, how the player should use it, and what it should do when they do use it.

Is there already documentation related to this issue?
It has documentation but its useless