Comments (2)
Here are my two cents on this:
Forgoing the difficultly of implementation; I think the main problem at hand here is one of design. Here are some issues that come to mind:
-
How do we handle specific SDK code, that's available in one language sdk, but not another? E.g. in the lua library, if there are helper functions related to lua only, how do we handle that, say if you want to change your compile target to C++? Do we only allow these in a lua build? That would break portability; if you write out a massive visual system which is build for compilation to lua, then decide that you need the extra speed of C++. Do we not allow specific library code to be used at all? If so; how do we mark certain methods as "unusable". Do we just disallow any language specific library code, and treat visual scripting as a first class language; giving it it's own SDK which can be pollyfilled/implemented in the compile target language?
-
Debugging. This is a big one; while I understand visual scripting is mainly aimed towards those who do not have any experience with traditional programming, and debugging would likely be too advanced a concept for them; IMO debugging support is needed. Do we have the debugger run on the compile target language, and have comments explaining what code is generated from what node? We'd need a pretty comprehensive guide for that, imo. Do we try and make our own debugger? If so, how do we go about that? Hook into the compile targets' native debugger and try and act as a "middle man"? Do we write our own node-based intepreter and debug that instead, for debug builds only?
-
Errors. How do we handle that? Do we parse stack traces from the compile target and have some sort of "source map" system that related compile-target method calls and invocations to the node representation? What about language specific errors; e.g. a type error or common throw expression? And what about errors that aren't generated by us; e.g. an IndexOutOfBoundsException would make no sense to someone who is trying to use node based scripting - and there isn't a clear cut way to "translate" that between the node based 'syntax' and the scripting based syntax.
-
Language specific features. How do we handle something that is possible in one language; but not in another? I.e. asynchronous programming. What if we support a language that doesn't have the concept of async? Do we not expose a node-based concept too? Do we only expose it if the compile target supports it? If so; portability is again an issue.
I think a visual scripting/node based system would be amazing. I'd love to see this as a first class citizen - there are many benefits to this and it'd really help us target a wider audience - however I feel these issues are things that do need to be resolved and chewed over, I'd love to see some discussion and ideas for any resolution!
Thank you for the suggestion!
from novelrt.
The way I'd visualise this working is basically Ink script generation. Since Ink will always be available as a core feature and is how were handling all our dialogue support, we could also extend this to "C# components by default", so to speak, though I think if we want to support custom components that would be later down the line.
I feel this addresses point 1 since it'd be exclusive to an engine feature.
As for debugging I feel this is affected by my opinion on custom components. If we choose to not support custom components, at least at the start, then there isn't really anything to debug as an end-user.
This, by extension, means any errors that happen would need to be output to a log file that can be sent to us to fix things internally.
As for language specific features, things like asynchronous programming would exist within the context of user-defined custom components. They could debug that themselves and I can't imagine us providing anything along these lines OOTB.
I think if we limit the scope quite heavily, its doable. It just depends if people would still want it in a limited state.
from novelrt.
Related Issues (20)
- Install Vulkan SDK CI command stalls GH Actions occasionally
- Replace reinterpret_cast with `NovelRT::Utilities::Misc::BitCast` where appropriate
- Introduce Universal Binaries for macOS
- C API needs casing fixed for function names HOT 3
- Nrt_Event needs unit tests to ensure functionality HOT 3
- CMake Dependency needs updating due to use of VS 2022 Generator HOT 1
- Doxygen generation appears to be wrong for some definitions. HOT 3
- Add switch to enable C++ 20 compilation
- Create a plugin interface for physics HOT 2
- Consider migrating all `Try` methods to return `std::optional<T>` instead of `bool` with some kind of out `T&`. HOT 2
- Vulkan causes an exception to be thrown when receiving VK_ERROR_OUT_OF_DATE_KHR with X11.
- Getting an error during the building process HOT 11
- Readme doesn't list Python HOT 1
- Input resets from KeyDownHeld to Idle on each frame
- Inconsistent NovelRT.h dependency HOT 1
- [GHA] Clang-format does not seem to agree with local clang-format.
- Inline functions cause cyclic dependencies
- Need to add Controller support for input
- If you create a NovelRT::Ecs::SystemScheduler as a variable which is then later initialised, this causes a crash HOT 1
- spdlog causes build issues on latest VS2022
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from novelrt.