What it does
This script lets you set up a keyboard for your Beam channel by defining a simple set of controls. When viewers use your controls, keys that are defined in corresponding files will do whatever you want them to do, for instance control your content.
This is especially useful for interactive streams.
See it in action on YouPlay!
Globally install the npm package.npm install -g beam-keyboard
Run the keyboard with your profile, like thisbeam-keyboard "path/to/my/profiles/GreatGame/myprofile.json"
Creating a profile
- Enter the Interactive studio.
- Create a new Project.
- Give it a name and optionally fill out other fields.
- Skip the Build section.
- At Code grab your version ID. You will need that later on.
Make sure you installed the NPM package.
Clone this repository or download it as a
config_exampledirectory to a place that makes sense
(You don't have to adopt the config directory structure here, but I think it's pretty organized the way it is)
Inside your own
auth.jsonand replace the dummy value with your OAuth token.
You will need following OAuth scope:
Check out how the NES example works and copy the directory to your own
Do a test run!beam-keyboard "./config/profiles/NES/profile.json"
How things work
- auth (String)
The path to your auth config file.
- handlers (Object)
This defines the handlers that will be used for your controls.
Currently there is only button, but support for others (like for joystick) will follow.
- path (String)
That's the path to where the handler NodeJS file is located.
You can also pass a name of a default handler (e.g.
The config your handler needs to get initialized.
Can be anything you want.
- path (String)
- layout (String)
The path to your layout config file.
- mapping (String)
The path to your mapping file.
- versionID (String)
The versionID for your interactive project (see above).
The layout files consist of a JSON object that holds following information:
This holds the path for a layout file this layout configuration should extend from.
This holds the available scenes (only default is used right now) as key-value.
The name of the scene is the key.
The mapping files consist of a JSON object that holds following information:
<control identifier> This defines a configuration for each button that's passed to the matching handler.
If your handler creates files (for whatever reason) and writes content to them, this is what your config could look like:
If you just want to press buttons, you could also just pass strings. It's up to you here, really.
As of now, you just need to extend the
AbstractHandler class and implement the
See the DefaultButtonHandler for an example of implementing it.
.tssource files in
buildcommand.npm run build
Run a profilenode index.js "path/to/my/profiles/GreatGame/myprofile.json"
Configuration of button actions
So that you can also let buttons switch scenes for a user, have them update other buttons or scenes or let them do other stuff than just pressing a button.
This could involve interaction with some kind of Socket or starting a program.
As of v0.2.0, we got handlers!
- Ban list
So that you can keep people from going wild on your buttons
- Moderator / team / role lists (may become the same system as ban lists)
So that you can allow certain people to press certain buttons.
- Layout extending
So that for example the SNES layout can inherit the NES layout and just add L and R
(Halfway done, just needs proper backend logic)
- Actual support of multiple scenes
Right now this only serves a default scene which is filled with generated buttons out of the config files.
- Visual feedback in the console
Some gauges or graphs, so that you can see what happens.
Right now it's just some prefixes of messages.
- Visual feedback on buttons, cooldowns and keyboard interaction
It looks like this isn't quite working with
I'll work on it as soon as it's supported.