Project Summary

Latest Update : Stream Quest is now available on Steam!

“Stream Quest” is a 16-bit style RPG that is entirely controlled by Chat inputs, which are in turn customisable by the host. It’s designed to allow Streamers the opportunity to engage with their community, keep them entertained during breaks, or as something they can play along with in its own right.

The game is controlled via a bot that reads the Streamers chat window and looks for specific commands input by the community. On detecting the first input, it opens a “voting window” of a length settable by the streamer (default 2.5 seconds) and, at the end of that, sorts all the inputs by count and acts on the highest-voted course of action. After that, the AI takes a turn.
By waiting until a valid input is detected before starting the timer, the AI will never get extra turns, and the game is unaffected by longer pauses in the chat window.

There is a gameplay demonstration available at, with thanks to Septeques for hosting the playtest!

My Role

I am the sole developer of the project. At current, I use visual assets purchased from the Unity Asset Store and
I am using my Twitch revenue and a Patreon account to raise funds to improve the project through commissioned artists and audio.


The Project started as an exploration into how to engage better with my Twitch audience and a frank conversation with my growing community about the kind of content they enjoy, which was agreed to be my Games development content and the associated commentary.
Dissatisfied by this answer, I thought about some advice from one of my Design Lecturers (Jeff Howard, @GameMagicArcana) about what he called “Turning it up to 11” and decided to do just that. Taking the concept associated with my goals – community engagement and games – and taking them to their logical extremes.

With these concepts in mind, I did a little research into Twitch integration and, with help from several YouTube videos, soon had a working prototype that would read Twitch Chat inputs into a Unity debug log.

Design Decisions

From there, I had to make some serious decisions about the direction of the game and what was important to me. To those ends, I settled on a few key points.

Input Detection is the core of the project and I made the decision early on to run the game with a “vote” system as opposed to acting on every input – firstly, because in larger audiences it would quickly become unplayable but also to override any deliberately negative inputs from disinterested or disruptive users within the chat.
The current system uses a timed vote – when the game detects a valid input, it records all the votes for a specified period before collating, ordering and then acting on the action with the highest vote.

Readability was of the utmost importance. In a game controlled by a multitude of people at any given time, the ability to quickly gain an understand of what was happening on the screen as well as grasping both the available actions and the priorities of them was essential.
This created the need for an Action Log, an output for the players to be able to see what had been done previously, to inform and provide context to new players who could join at any time. The Action Log displays the previous actions along with how many users voted for them.
It also limited the style of game, and was why I chose a 2D RPG. The top-down style is visually clean and recognisable, and such games are often used with a Grid-based system, which was another simple choice to make.
This allowed players to quickly grasp how far they could move and the distance to the various interactable entities that would occur.

Modularity was a decision that came earlier in the project when I realised the limitations of the art assets I possessed. By building modularity in the game, the individual assets became less important – a breakable item with loot in it made no issue what it was, as long as the code was adaptable. Similarly with spawning items or enemies.
For these, I leaned heavily towards the use of inheritance and interfaces within the codebase rather than coding each item as an entity – though this was something I already tried to do, this is by far the most successful instance of forwards planning when it comes to my coding experience.

Customisation is a consideration that came later – during the transition from Prototype to Project – but, when writing the codebase from the ground up, was quickly made a priority.
The ability for the streamer to adjust the name of the game, the inputs required and even the sprite of the player are all tools that will increase engagement within their respective communities, and add value to the project.

Moving Forwards

At present, Stream Quest is still in active development and is in the process of being listed on Steam as a solution for both signposting interested streamers, gaining additional development funds and addressing both version control distribution and unauthorised program sharing concerns.

Recent updates include multiple playable characters and a full, original OST.

I stream development most weekdays at where I am available to answer questions or demonstrate the games functionality.