Contains ideas, possible fixes and upgrades for the engine. Features should be distilled from this

• I just realized: if i add some dependencies to gameplay.dll, and hotload gameplay dll, can't i consider the dependencies as being hotloaded too? Is this an easy way to allow split dll hotloading?
• Let hotloading work on fields instead of properties? Or should these properties remain forced public as to force the coder to see these as possible access paths?
• Support multiple gameplay dlls. (Also note the one core plugin loader idea)
• Note that the original idea was to have hierarchial hotloading, where not every subpart is hotloaded, in my quickfix above everything is relinked.
• Maybe support multiple gameplay dlls, to allow faster compiling, and put each testcase in a seperate dll.
• Let wizards engine compile, disable edit and continue in vs, this could potentially allow continuous debugging!!!
• Create a 'kill-thread' which monitors the thread that runs gameplay simulation (maybe even the rendering thread), and aborts it when it fails to send regular heartbeats.
• Thoroughly check hotloading and removal of objects , something

• Engine Automatically remove all references when object is destroyed!
• Engine Use Expression framework of C# to update invariants automatically on change, detect what changes to listen for using this expression framework.
• Engine Maybe use postsharp aspect in conjuction with change model to automatically fix bidirecitonals?
• Engine Find something for bidirectional associations Engine Allow encapsulation of properties again in the modelobjects! (use direct field injection?)
• Engine Think about a 'looping simulator system', where methods are attached to object change events, and the simulator simulates until all change events are simulated!
• Engine A lot of bidirectional associations appear in my code: create something for this (cart holding item, item held by cart etc)
• Engine Think about extending to an event based system?
• Engine idea: there should be no relations between data fields in modelobjects (or the fields containing pure data should be indicated). Functionality should be added to allow properties that are forwards to other data. Automatic caching support for bidirectional (and maybe other) associations should be added!
• Engine Should these properties remain forced public as to force the coder to see these as possible access paths?
• ENGINEIdea: allow using interfaces as direct modelobjects. It is not necessary for them to to be implemented, automatic implementation (or simple public autoproperties) are probably good enough? Find a way to do this.
• Give each modelobject invariant functions, which are evaluated on reads. Writes are still dead, writing to modelobject properties does not invoke any other code except for change notification.
• Also: try this system by allowing empty setters, and fixed getters!
• Add safety check to see that ModelObjectChanged attribute was added to all IModelObjects !!!
• Create a List<> that fires changes to modelobjects
• Since simulators seem te become more like method binders to a specific order, maybe introduce a way to directly bind the methods instead of writing a new class every time, and provide new simulators which are Bundles of bindings for general usage.
• Idea: instead of making seperate code in tests for initialization and test code, simply block all TW.Data methods when not initializing??
• Automatically store all fields that contain modelobjects in a simulator in a “virtual” 'MySimulator.Data' modelobject.
• Idea: Dont allow global access to objects :) Isn't this actually a massive singleton global access to everything leak?? Maybe only allow global access to the parts? Think about this
• Idea: unreferenced objects could automatically be deleted (or garbage collected). All method an property calls could be changed to throwing an exception using postsharp when they are gc'ed.
• Think about adjusting the modelobject simulator system to a delayed event system:
• Now what actually is happening is that the simulators are observing changes on objects, but they process the events at a later rate. This could be extended to simulators who can listen to any event, but process their events in a delayed fashion, as to decouple the code causing the event and the code acting upon the event. This could allow for game-maker style events.