Introduction
There are many ways to implement Twitch compatible stream plug-ins. In this document I look at the approach for the three main components of this project: the timer, donation notifications, and the stretch-goal game.
Potential Approaches
Although there are many different approaches to creating a Twitch plug-in, defined here as something that interacts with Twitch’s event system and APIs, I’ll be looking at three common approaches. These approaches are a desktop application, an ‘external’ website that can be used as a browser source within the streamer’s broadcast application, or a Twitch-integrated extension.
Desktop Application
The desktop application option is exactly as it sounds: an application that would run on the streamer’s PC. The streamer would launch an application executable and integrate it into their stream as a separate video source.
The application would need to be built with an ‘application development’ language. Ideally the language would have built-in support for HTML calls (to easily access the APIs), web sockets (for the Twitch event system), and a GUI system that makes iteration fast. Given these requirements, C# seems like the best candidate language for this solution.
Benefits of this solution
- No need to construct a local or hosted server for data storage. Anywhere in the application is able to write directly to disk. This gets around having to write a layer between the presentation and application layers of the program that would be required in a web-based solution.
- A more comprehensive IDE experience with Visual Studio.
- Built around object-oriented and composition designs as core paradigms.
- More familiarity on my part: C# is a language that I have experience with.
- No Twitch approval process aside from obeying their API guidelines.
Negatives of this solution
- If the streamer wanted to move this plug-in to a Twitch-integrated extension in the future, the application would need to be redesigned into a client/server architecture.
- Users can’t interact with this element in the stream at all (versus a Twitch-integrated extension where they can see additional info and minimize it).
- Because I am more familiar with this method of development, I won’t be learning as much while working on the project.
- Requires the streamer to launch a separate application.
- Only applicable to the stretch-goal game: C# doesn’t have a comprehensive game development framework out of the box. I’d likely need to use a game engine such as Unity (based on C#). Using an engine like this is likely overkill and adds additional complexity.
External Webpage
The external webpage option involves building a web application that just runs locally on the streamer’s PC. They will be responsible for launching the local web server but once they do that, they will be able to add browser sources to their stream manager. This is well supported functionality within the streamer’s broadcast software (OBS).
This solution would need to be built as a client/server architecture with a locally hosted backend server. For the frontend, HTML and CSS will be required and JavaScript will be used to add scripts. For the backend server language, I’d want something that I can learn fairly quickly with strong support for web sockets and HTML calls. There are a ton of languages available for this purpose, but after some research I boiled it down to two options: C# or NodeJS. NodeJS has the benefit of keeping the codebase within one scripting language (JS), so this is the option I will opt to go with for this solution.
Benefits of this solution
- No web-hosting solution required which means no additional costs to the streamer to pay for web services.
- JS and NodeJS are extremely forgiving scripting languages and make it very easy to prototype and iterate quickly.
- Streamer already uses browser sources within OBS, so this is a well-understood workflow for them.
- This would be easily ported to a Twitch-integrated extension in the future if the streamer wished to.
- No Twitch approval process aside from obeying their API guidelines.
- A more involved learning experience for me personally.
- Only applicable to the stretch-goal game: Has well understood game development framework called Phaser that is built with JS.
Negatives of this solution
- Users can’t interact with this element in the stream at all (versus a Twitch-integrated extension where they can see additional info and minimize it).
- This is a type of development I have very little experience with, so this may slow down my development time.
- Requires the streamer to launch a local server.
Twitch Extension
This option involves going through Twitch’s extension building workflow to make something that lives within the stream on Twitch’s side as opposed to the streamer’s machine. In order to have persistent data, a web server would be required. This can be a local server while testing but would require a hosted web server for the final production-ready implementation.
Twitch-integrated extensions are essentially just webpages overlayed on the stream, so I’d use the same languages and tools discussed in the external webpage section above.
Benefits of this solution
- Twitch hosts the frontend on their server, so web hosting would only be required for the backend server.
- Users can interact directly with the plug-in while watching the stream (view additional information, hide the overlay, etc.)
- Setup is ‘set and forget’. After the streamer does the initial setup of the plug-in with their twitch stream, there is nothing else they need to do for future streams.
Negatives of this solution
- Hosted backend server is required which means the streamer will have to maintain (or pay someone to maintain) a web-hosted server. This also brings new security concerns and requirements into play that wouldn’t be a problem for a locally hosted server.
- Plug-in must pass Twitch’s certification process which may be lengthy, and the plug-in could be rejected on non-functional grounds such as wording or coding methods.
Chosen Solution
I discussed the benefits and negatives with the client and overall the best solution for client-ease as well as my personal learning is to use an external website for the Twitch plug-in, the advanced donation notifications, and the stretch-goal game.
The benefits of this approach such as avoiding additional costs, ongoing web hosting concerns, and not having to wait on Twitch’s approval process, outweighed the negatives of losing user overlay interactivity and the ‘set and forget’ nature of the Twitch-integrated extension.
Given this, the languages I’ll be using are JavaScript, HTML, and CSS for the frontend, and JavaScript/NodeJS for the backend server. If I end up getting to the stretch-goal portion of this project, I’ll be using the JavaScript-based game library called Phaser.
As a result of this decision, the client and I have slightly revised the requirements document to fit any new constraints. I have also informed the client that I will write some simple batch scripts to help make installing prerequisites and launching the local server as simple as possible.