Inspiration
While brainstorming for HackSC, we discussed previous hackathons, and realized that presentations were a real pain for all of us. Without much time to practice, and without much sleep, it was easy to lose track of what was going on and the presentation became rough and disorganized. We wanted a new way to organize our presentations, keeping us in sync and allowing for more fluid transitions.
What it does
Scriptus is a software to sync users’ positions in a script together across different devices, even with different screen sizes.
We believe it was important to curate our product to the industry standard. In the movie and film industry about 95% of productions use Final Draft for creating their scripts. Thus, we decided a great use of our tool was allowing people to upload their .fdx type scripts, and use our proprietary reader technology to display it. We believe our technology would prove invaluable for professional actors and producers at screen readings: keeping everyone on the same page.
How we built it
- We used Cloud Run in two isolated containers; one for our website and one for our socket
- We used NodeJS to build our website and sockets
- We used SocketIO to manage our sockets
- Syncing Algorithm: After the text is loaded into the browser, we count the number of words in each line, and store references to each word. We store a reference to the start, end, length, etc of each line to avoid less computation in other places To find the final word in lines, so we can be aware of when lines end, we get all the children of the div, then put words in groups based on their distance from the top of the document. Every time we hit a new word that isn't at the same level as the last, you know it's a new line. We then calculate which line is closest to the center of the screen vertically and which word in that line is most likely the active word.
- We learned that .fdx is actually just a subset of a .xml file. Thus, to parse it, we allow users to upload their .fdx, and we convert this to json. Then we send this to our socket.io server and proceed to a custom room at the route /filename. Then the server sends back the data and we read it in the ways described above We set up Tailwind CSS, but forgot to use it
Challenges we ran into
- Syncing with socket io and state issues have been very challenging, along with making it scalable, and able to run multiple isolated scripts at the same time.
- File uploads.
- Dealing with different screen sizes and how they function together.
- Ben’s dog is really pushy, and distracted him from coding for a while.
- Parsing FDX documents (Industry standard for film and theatre scripts) was extremely hard.
- Creating a simple permission system was hard, as we weren’t sure how we wanted to structure it.
Accomplishments that we're proud of
We needed it to work across several different screen sizes at the same time, so we developed an original algorithm to detect words that occur right before line breaks, this is the real secret sauce of the project.
What we learned
Sleep is quite enjoyable. We learned how to organize sockets with state. While originally, we built them by updating data locally, sending the data, and then having a receiver function, we realized a better structure is to send the data without updating the website initially, then re-send the data back from the socket which will be the same every other client gets, keeping everything in sync.
What's next for Scriptus
Adding more features:
- We want to add the ability to share and link to individual parts
- We want a stronger permission system
- Toggle for parser visualisation
Log in or sign up for Devpost to join the conversation.