Currently the process to create a new sim is rather tedious.
It is documented in the code base here: ./docs/creating_sims.md.
It would be preferable to be able to bootstrap a new sim by clicking a button or some kind of UI wizard.
Tasks
[x] Create a button/menu item on the toolbar to start the process.
[x] Create a pop-up module that takes the inputs (Sim Name, Title, Instructions, Descriptions)
[x] The sims listed on the toolbar drop-down menu need to become data-driven. Add a data file so sims can be dynamically added.
[x] Create a bare-bones TOML scene file for the new Sim.
[x] Simplify the registration of the various functions (e.g. renderers).
[x] Find a home for simulations.
Considerations
User defined simulations need to not live in the source code. The'll be overwritten if the app is upgraded.
On the Sims menu it should probably be organized into Examples and Your Sims.
Perhaps a tooltip for the Your Sims should say where they're located.
User defined task functions have the same challenge as simulation files. Where should that Python code live? The location should be user specified.
The DearPyGUI File Dialog is a hot mess.
Agent Playground User Project
The current design leverages three registries that are used to stitch a scene together; ENTITIES_REGISTRY, RENDERERS_REGISTRY, and the TASKS_REGISTRY.
The user needs a way to add and organize code. There are two obvious options.
Create project specific directories.
Create a universal directory.
Project Specific Workflow
For option 1, this is how most creative software works. The user somehow creates a new project and the software creates a folder or encapsulating file. This project is self contained. The benefit of this is it avoids collisions between projects and enables forking for fast experimentation. A basic workflow for this approach is.
Launch the Agent Playground App. Imagine this is installed as a wheel.
File -> New Simulation
Open the New Sim wizard. This includes selecting a directory for where to create the sim project.
Create a directory based on the user specified location and name.
Populate the directory with the templates.
Dynamically add the relevant paths to the Python app (how does development work?).
Launch the new simulation.
Development Workflow
Thoughts
The project could be populated with a Makefile.
The user needs the ability to write tests in their environment and add 3rd party dependencies.
The user opens that project in VSCode
The recommended practice is to have a parent directory that contains multiple projects.
How does python files get dynamically added to a running application? This probably needs to work like a plug-in architecture. Python can dynamically load modules (at runtime) either by using the __import__() method or the impimportlib module. I believe both approaches would required building the user's code into a module at File Open time. There would need to be some kind of bootstrapping magic.
How does virtual environments help or hinder with this?
How does dependencies work? For example the renderer functions will probably need access to dpg.
This makes me think of writing custom extensions for Blender.
Perhaps a preferable workflow would be to flip the relationship. Make the Agent Playground be a module that is imported into a project. Then launched with that project's code somehow. In this approach, the Simulations menu goes away.
If the Agent Playground isn't changing from the user perspective, then loading the simulation should be from their project's perspective. Once scenario is that the Playground is running and they've got their sim open in VSCode.
Then they just keep hitting a reload button as they're making changes. Another scenario is they're launching the Playground from their sim project. This is how SimPy works.
The idea that a Simulation Project is really a python module is pretty powerful. We could have something like:
my_sim (directory)
_init_.py
scene.toml
src (directory)
tasks (directory)
renders (directory)
entities (directory)
updaters (directory)
Universal, Flat Directory
For option 2, there is a shared directory that everything is stored in. This is similar to how tools like Maven create a global repository. It could be flat. The benefit is this can save hard drive space (who cares) and allow reuse of functions from sim to sim. In this approach it is up to the user to maintain a naming convention to avoid collisions.
Some Directory
simulations (TOML files)
tasks (Python files that get registered that can then be used )
Currently the process to create a new sim is rather tedious. It is documented in the code base here: ./docs/creating_sims.md.
It would be preferable to be able to bootstrap a new sim by clicking a button or some kind of UI wizard.
Tasks
Considerations
Agent Playground User Project
The current design leverages three registries that are used to stitch a scene together; ENTITIES_REGISTRY, RENDERERS_REGISTRY, and the TASKS_REGISTRY.
The user needs a way to add and organize code. There are two obvious options.
Project Specific Workflow
For option 1, this is how most creative software works. The user somehow creates a new project and the software creates a folder or encapsulating file. This project is self contained. The benefit of this is it avoids collisions between projects and enables forking for fast experimentation. A basic workflow for this approach is.
Development Workflow
Thoughts
impimportlib module. I believe both approaches would required building the user's code into a module at File Open time. There would need to be some kind of bootstrapping magic.If the Agent Playground isn't changing from the user perspective, then loading the simulation should be from their project's perspective. Once scenario is that the Playground is running and they've got their sim open in VSCode. Then they just keep hitting a reload button as they're making changes. Another scenario is they're launching the Playground from their sim project. This is how SimPy works.
The idea that a Simulation Project is really a python module is pretty powerful. We could have something like: my_sim (directory)
Universal, Flat Directory
For option 2, there is a shared directory that everything is stored in. This is similar to how tools like Maven create a global repository. It could be flat. The benefit is this can save hard drive space (who cares) and allow reuse of functions from sim to sim. In this approach it is up to the user to maintain a naming convention to avoid collisions.