You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pool allocation: Complete
Game update logistics: Complete
Tools-time content: The component system supports placing components on any type that implements IHasComponents and this interface can be used by the component to get whatever it needs (i.e. owning world, owning entity, owning entity proxy, etc.). These functions should be implemented in a best-effort way, i.e. it would be appropriate for World::GetOwningEntity() to return null. World-level components shouldn't use that function. At some point it would be nice to add some validation that components assuming they get put on an object of type X do not get put on an object of type Y, but as for being able to do tools-only components, the current implementation will function (and is already allowing us to have entity components and world components).
"Cooking" data - This is the asset system's responsibility. Components can consume any data provided by the asset, so this is essentially ready to go. Although we may want to look closer at how assets should be allowed to cook data.
The whole system will get minor improvements as time goes on, but it already meets all the requirements above, except the final one which in my opinion is an asset issue rather than a component issue. Let me know if you feel that one or more of these issues is not sufficiently addressed by the current design/implementation.
It needs to support pool allocation and host game update logistics as well as tools-time content hosting and generation of game-side run data.
The text was updated successfully, but these errors were encountered: