IMPORTANT: when the plugin is updated, you must delete the WorldSmithClient and WorldSmithServer folders under game.ReplicatedStorage and game.ServerScriptService if you wish to use the updated built-in components and systems. If you have defined custom components or systems, make sure to either copy them or have them stored somewhere else before you update and delete!
What does it do?
WorldSmith is an ECS framework combined with a plugin interface. The interface provides a simple way to tie components to instances and edit them, allowing a developer to easily create varied game objects with no dependency issues.
WorldSmith will generate two folders - one called âWorldSmithClientâ under game.ReplicatedStorage and one called âWorldSmithServerâ under game.ServerScriptService. WorldSmithClient.WorldSmithClientMain and WorldSmithServer.WorldSmithServerMain must be required by the client and the server, respectively.
The future of WorldSmith
I will be continuing to work on this framework over the coming months to extend and improve its capabilities, and increase its ease of use. Coming soon is entity/component serialization and deserialization, which will let you do fun things like save your entire game state to a data store
A difference in architecture - the component pattern in general doesnât specify where the method implementation for components lives, whereas in a âtrueâ ECS their method implementation is provided by systems of the same aspect
note that this isnât the only difference, but it is one of the key differences
And adding a component is creating a ModuleScript structured like this:
local EntitySystem = require(script.Parent.EntitySystem)
local DeathBrick = EntitySystem.Component:extend("DeathBrick", {
BreakJoints = true,
KillPlayers = true,
})
function DeathBrick:added()
self.maid.touchConn = self.instance.Touched:Connect(function(part)
local humanoid = part.Parent and part.Parent:FindFirstChild("Humanoid")
if self.KillPlayers and humanoid then
humanoid:TakeDamage(100)
else if self.BreakJoints then
part:BreakJoints()
end
end)
end
return DeathBrick
I was aware of yours - it almost put me off of creating my own until I looked closer and saw that it wasnât a ârealâ ECS.
Your interface is 100x better than mine, however; my user interfaces tend to land more on the side of âhastily thrown togetherâ rather than âcarefully planned outâ
components are now identified with a numeric ID; their human-readable names are now stored in a ._metadata field which is serialized by Component.lua, so human-readable names may still be used by the programmer when creating and indexing components
components are no longer represented by Folder and ValueBase instances during run time (these are still created by the plugin because there is no other way to have the data persist, but are destroyed by the server on initialization)
systems are now expected to return a single function - EntityManager:StepSystem(systemName, deltaT) may be used to step a specific system
âshow componentsâ window sometimes doesnât display all of a componentsâ parameters; can be worked around by changing the corresponding ValueBase instances in Studio
Due to time constraints I was only able to make two example systems on the client - they demonstrate how components may be used to tell another component to do something