Workflow & Tools

So far, none of the categories of embeddability are really different from what one would expect from a regular scripting language. In fact, what literature says is that they are nearly matching, and Software Engineering Stack Exchange confirms it. The major difference explained in literature by B.Myers already in 1989 in “Taxonomies of Visual Programming” [1] and in the works of Nystrom and J.Gregory [23], [27], the biggest challenge for a VSL is the UI/UX aspect and mainly the visual scripting environment (VSE). A VSE can be seen as the integrated development environment (IDE) for VSLs. The thesis concluded that among all aspects, workflow and tooling are the most important.

Unfortunately, there is not much existing research on what qualifies a good visual scripting environment within the domain of game development. If we look outside of the game industry, there are a few papers on this topic, but they mostly describe the design of visual scripting environments for block-based languages, since they are mainly used for educational purposes. Although the industry professionals participating in the study shared some important insights, proper academic research would be needed to make academic claims. However, for this prototype the statements of industry professionals and the scarce UI / UX research on visual scripting environments will base the foundation for Noodle’s UI / UX.

The industry professionals stated that one cannot just use Notepad or Visual Studio to edit the “source code” of a VSL, therefore they would expect either a fully-fletched editor to come with the VSL or a flexible API to allow them to bind an editor themselves. One of the participants stated that they would use the provided editor to get acquainted with the language and then use the API to build their own that matches the paradigms and needs of their own ecosystem. Hence, Noodle will come with a prototype of an editor and a flexible API that allows the user to bind a custom editor.

For the first prototype, the language will come with a Visual Studio Code extension that enables the editor to understand Noodle files, while the editor will communicate with the Noodle runtime via the WebSocket API by using the protocol described later. Whenever a change occurs in the editor, the updated graph will be sent to the runtime and the runtime user can decide if it is needed to recompile the current graph and swap it with the new changes. The goal is to provide an embeddable editor view written in C or C++ as an external tool on top of the Noodle APIs.

The mentioned WebSocket-based API allows network communication to other software that might be the editor. The VS Code extension will be part of the first prototype to demonstrate this communication feature. A network-based communication might be more suitable for games that separate game runtime and editor runtime, while the API communication via the C interface might be better suited for custom game engines that have a built-in editor. Important to mention is that the WebSocket API is purely optional.

Since debugging and visualizing what is happening within the VSL has been classified as very important, Noodle should come with an ability to attach a debugger to it. In the first prototype we can try to make use of the VS Code Debugger framework and provide the ability to connect to it.

A Noodle document will be in JSON format that can be parsed with any JSON parser and can be checked in source control like a normal text file. The main reason why JSON has been chosen is that it provides a better source control management support. Also, it can be diffed without big issues, while for example a binary file format would cause source control issues (google ‘Blueprints and source control’).