Implement it using std::hash on the path of the resource, do it from the resource base type.

Build a custom reflection engine using clang to ingest the source code. Output should be more source code that other tools can link to.

We need a directory watcher to notify us when assets (shaders, models, textures, scripts, etc.) get updated on disk so we can hotload them automatically for a seamless user experience.

ESFW is a cross platform file watcher without dependencies (beyond OS + stdlib), so I think it's a good place to start.

The documentation for the World type needs to be written.

Building on #5 and #6, implement deserialization so that a C++ instance of an object can be constructed from its JSON representation.

per Entity.inl line 17, multiple model components cannot currently exist
assert( this->Has( ) == false && "An entity may only be associated with a single instance of each component type." );

Test case: Create an entity with a cube model. Add several smaller cube models to orbit around this one, and have them move together as one.

Question: Should each smaller cube then be it's own entity, or would it be wise to allow a CModel component to house multiple model references?

Currently the only way to do is with a:
Remove;
Add("newmodel.obj"); //Remove fix pending

Suggested solution:
EntityRef::Update()("newmodel.obj")

• Points the model component to the new model reference, and loads it if it isn't already loaded

Ensure that the current model is only deleted from memory when there are 0 references to it.
I.E. Create a few clones, update the model on just one without breaking the others.

those get defined inside pilcrow/dependencies but they need to be defined in pilcrow/ because we need them in pilcrow/*

Playfab provides a variety of live ops services, including telemetry an analytics. We should integrate so we can start recording telemetry for analysis and get in the habit of instrumenting our code with telemetry.

With the new changes to convert the project to use CMake, issues arise.
The engine no longer points to the correct resources.

To resolve #34, entity hierarchies need to be implemented. This should be done in the form:

EntityRef parent;
EntityRef child;
child.SetParent(parent);

Behind the scenes:

1. The parent should have child added to a vector of children
2. The child should have its parent handle set to its new parent
3. Any component with a member of the form ComponentHandle<T> Parent; on the child should have the Parent member set to the parent's component of that type, if it has one.
4. Any component with a Parent member where !std::is_same_v<T, Component> should result in a compile time error
5. Any component containing a Parent handle should have its parent set when added to a child entity.

Enhancement / Feature.
1 line macro to output text to a buffer of a batching system.

Ideally we would have three separate buffers, 1 for errors, 1 for events, and one for everything else, i.e. general debugging. Separating out message types allows us to more easily filer and navigate the output. The batching system would collect all of these and then output them at the end of the frame to wherever we want, based of those filters. This way, all text output can easily be switched to or additionally output to a log file, or any other source we desire on the file without editing any of the individual lines feeding the buffers.

Potential Examples:
//usage
ERROR_TEXT("Graphics failed to initialize! value of window handle: ", pWindow);
DEBUG_TEXT("Just checking to see if the code hits this line.");
EVENT_TEXT("Model loaded: ", m_name);

//directing output
TextBatcher.eventBuffer.outputMode = TextBatcher::eOutputModes::Logfile;
TextBatcher.errorBuffer.outputMode = TextBatcher::eOutputModes::Screen;
TextBatcher.debugBuffer.outputMode = TextBatcher::eOutputModes::Console;

This would replace all std::cout text output currently in the engine and eliminate a building tech debt in this area.

Discuss. Also, as we're planning to eventually have automatic formatting, is this something we need to worry about?

ConstrainedEntityRef should hold pointers to the components it has been constrained for. When they move in memory, the ComponentPool should send out an event so that the ComponentAggregate can update those held pointers with the new memory location of the moved data.

The expected outcome of this change is better performance for component lookups.

It would be great to be able to use SInput for all our input needs.

slot_map is an excellent solution for storing the callbacks as it generates a unique ID which can be used to remove the callback later if the event arena outlives the listener

Currently include(../cmake/clangfmt.cmake) is in pilcrow/CMakeLists.txt, but it should be in the root CMakeLists.txt.

Bonus points if you can have it simply not check the dependencies folder, instead of checking and then removing them.

PR#47 implements undo and redo using a singleton. This may cause issues with multiple editor instances running on one machine.

Build a serialization layer that consumes the output of #5 to convert entity and component data to JSON.

The editor runs in a browser, so it will need a WebGL renderer.

By implementing typescript versions of engine types such as World and Entity, it becomes easier to abstract functionality built on the editor side. It would be effectively typescript as a scripting language with the REST API as the communication medium.

Having typescript scripting available could make it easier to build custom tooling going forward, and would keep the REST API coupling of the Editor/View isolated into a few small areas.

The core engine currently only has a native C++ API. To make it more accessible for external tools, a REST API should be built that exposes the data to external clients for IE developing a game editor.

REST API v0.0

Game Properties

Entity Properties

Causes compiler errors when used on an existing component.
Test code used in main, after spawn nanos block:
EnemyA.Remove();

Documentation for the Entity type needs to be written.