Open pablomayobre opened 1 year ago
Here are my thoughts:
For debugging and the above point, we can use UI's like Slab to cater this. I have a lot of simple widgets that can just be used in projects that can give users the benefit of trees, inspecting, watching, and what not like a real debugger/ui.
.foo
or ["foo"]
can be tricky. Perhaps we should have a standard for accessing components or standard for naming components? Type system sounds good as well.
Here I plan to detail some areas where developer experience is lacking and we could spend some time and improve on it:
Debugging
75
This is an area where we know there is a big opportunity to improve DX, Concord has exposed a lot of events and information that can be used to debug, profile, inspect and replicate the current state of a World.
We have
World:beforeEmit
andWorld:afterEmit
to detect and profile events, it also tells us which Systems received the event, and also allows us to prevent the propagation of a given event, this could allow us to stop all events and pause all mutations to the World for a period of time.The World knows at all times which Systems are registered and enabled/disabled, which callback each System listens to and since it can reference them, it also know which Filters and Pools are associated to them.
Components has a list of all the available and registered Components and we can use them to query the World for a Filter and list all Entities available at the time. Alternatively the World knows about all the Entities with an ID.
With an Entity we can inspect the current set of Components given to it, which Pools contain this Entity, and serialize/deserialize it's state entirely or partially. Which could allow for dynamic mutations in real time.
We could also make mutations remotely like the ones we discussed but also give Components to the currently inspected Entity and then use that information to render a box around it for example, or enable/disable a given System, and maybe even support hot reloading a System or Component.
Type Systems
71
The need for a type system in Lua has been growing, and some options are available out there. Unfortunately none support the features needed for Concord, but can we find a way, even if by making plugins or external tools, to give type system support for Concord?
The ideal state would allow us to type our components entirely, and then be able to type our entities and systems based on that. Ideally we could also type events and only be able to emit events that are used by systems.
Something we could add to these type systems is that it would be nice to know roughly how many times a given event is emitted or handled by using the "References" feature most code editors have nowadays. This could also be used for Components, showing every time the component is accessed in an entity or referenced by a filter definition.
Bootstrapping / Boilerplate
This should be an easy win, there are no templates on how to setup Concord properly and quickly, there is a lot of code duplication in a code base and most Systems and Components are just boilerplate. Can we speed this up?
There are various ideas, from code snippets to complete CLIs to domain specific languages for defining components and systems. All of them are valid and we can explore around here.
Testing and Documentation
Not many care, but Concord offers an API that would allow you to easily define unit tests for your Systems, Components and Assemblages.
Can we provide utilities to make this feature more obvious and a selling point for Concord? Could we also help with generating documentation for Components, Systems or other pieces of code?
Refactoring
A pain point when working with Concord is refactoring. How do we know all the places where a given Component type is accessed? How do we know all the places a given event is emitted? How do we know we are not reusing an event's name? How do we know we have updated all the places when changing our Component internal structure?
I think this is mainly fixed by a better Type System integration, and testing could help though would require more user intervention, but could we also do something in Concord's code to make this changes easier to address? Are there other tools that could help here?
Tutorials
36
We know how lacking the current docs and API docs are. We know we want guides and other resources
But can we also provide exercises, tutorials and other tools for learning Concord?
Ecosystem
Can we solve hard problems like UI, Physics, Tree structures, etc for everyone? Can we find common patterns and code that can be reused and share them? How do we make this easy? Can we create an ecosystem around Concord?