First of all, I'm really excited that you chose .Net for the scripting engine. Really looking forward to being able to write my own scripts. I have a few suggestions for the scripting engine, however:
- Use .Net naming conventions: Unity fails at this nearly everywhere, but it's important because it helps improve readability. There are official .NET naming conventions - please follow them consistently.
- Don't reinvent the wheel: Use actual .Net events instead of something hacked together with reflection like Unity does. Or better yet use the Rx extensions library for Observable<T> like the hip folks do.
- Be Type Safe: for example, instead of using reflection to detect at runtime if a script has an OnSomeEvent method (like Unity events), use an IOnSomeEvent interface that scripts can implement. This lets you type check that the actual OnSomeEvent method that the script implements follows the signature you're expecting, and it makes it easier for users to implement because they can just right click the IOnSomeEvent interface and have their editor fill in a stub for the method.
- Support out-of-app code editors and IDEs for scripting: don't just have a text editor where you type C# code into - generate a csproj and let users write their scripts in an IDE with type checking and debugging and so on.
- If you do have an in-game editor, use the open source OmniSharp project to provide full intellisense and type checking - not just syntax coloring.
- Support .Net best practices: for example, it's OK to support public fields as script "properties" you expose to the UI, but also support actual C# properties.
- Testable scripts: implement a dependency injection mechanism, and use interfaces where possible for the script engine dependencies to help make scripts testable. This will help content creators manage larger projects with unit testable scripts.