-
Notifications
You must be signed in to change notification settings - Fork 4
Blog
For this week I met with Akeyl who is joining on as a contributor for the semester. I described the current state of the project along with my ongoing work in making a text based interface for our directed graph. I explained how I had already done the work to parse choice based nodes from visual novels written with the engine NScripter. After having a conversation on ways we could more broadly generalize this method of parsing such that we are taking into account the actual structure of the language it was brought up that not many games actually use the engine. More modern games use a engine called Ren'Py. To expand this tool out to more games Akeyl decided to look into parsing from this other language while I decided to put my attention towards making this utility interactive and eventually expanding it out to a desktop application. To this effect I am currently debugging problems with the generation of a text based tree.
This week I continued with work debugging the text based tree as well as the initial setup for the electron.js user interface. Both of these project are progressing and some initial boilerplate for the electron.js app should be out next week though the text based printing of the choice network might require some more extensive refactoring. In terms of the electron.js app, this should use the React library as well as a canvas with node components. On click these components should bring up a menu from where you can interact with the node as well as retrieve desired information. For the text based tree problems are arising with how graphs with more nodes are being rendered. The reason this text based tree is important is that it both serves as a proof of concept for creating a simplified network layout that is easy to render, as well as a prototype for how the electron.js app will render the nodes in it's choice tree. Once both components are ready work can begin creating a frontend as early as next week and at latest by the week after.
This article from the Verge and this article from showcase a practice of introducing security vulnerabilities in open source software for the purposes of activism. When I first thought about working on this project I decided early on to open source it so that I could get more engagement from the community as well as more interest on the development side. So far everything I have is very much in a prototyping phase but hypothetically this project will have the ability to touch game files and worse a lot of the core modules would be abstracted away over time. Hypothetically in the future if another actor took up development of the project and had control of the primary codebase, they could introduce whatever malevolent features they sought. If for example they really disliked a particular part of the visual novel community they could introduce bugs to corrupt those users game data. I think that manipulating open source software for the purposes of activism sets a scary precedent even if the cause is justified. To me open source is built on some level of trust between members of the community and taking actions that harm this trust is worse for everyone involved, the users don't get free software, and the devs don't get any feedback or interest. For that reason I don't think I can approve of the actions taken in the situation of colors.js and faker.js as well as node-ipc.
Sources: