Use your phone as a wireless gamepad in Godot. Similar to jackbox.tv but more realtime.
Caution
The project is under very active development and is missing many important features. It's changing everyday so there isn't even the roughest of roadmaps.
Also note the following:
- Horrible and even misleading documentation.
- No real world testing... I will get to that later.
- Lack of vital security measures. โต ( !!! )
Note
The following may be out of date.
- Install a mono version of Godot
4.2.X
(tested on4.2.1
).
- The repository already contains compiled code for the web interface. If you want to develop for it then follow these steps.
- Open a terminal in
addons/godot_remote/web
. - Run
pnpm i
to install dependencies. Don't have PNPM? - Run
pnpm run watch
to watch and compile code.
- Open a terminal in
Tip
Check out /docs
for more info on development! (may be out of date)
- Open
addons/godot_remote/scenes/autoloads/remote.tscn
- Define desired driver and api scripts
- At the moment only 3 drivers exist: WebSocket, WebRTC*, and SIP. You can find them in
addons/godot_remote/scripts/drivers/
.
- At the moment only 3 drivers exist: WebSocket, WebRTC*, and SIP. You can find them in
- Script:
websocket_driver.gd
- Status: Perfect but slow
The most reliable but slowest of all the drivers. Everything should work perfectly when using this driver but ping is way to high for realtime games.
- Script:
webrtc_driver.gd
(Uses the webrtc-native GDNative addon) - Status: Not implemented
Currently this driver has not be implemented yet. At the moment I am having trouble getting it to work and I'm waiting on this issue for more info.
WebRTC is an overkill communication standard however it is the only widely supported way to quickly send data over the internet (see Why WebRTC?). Under the hood the driver uses the WebSocket driver to establish it's connection, pretty cool right?
- Script:
sip_driver.gd
(uses C# and theSIPSorcery
.NET package) - Status: It works but needs some work
There are two kinds of fundamental types of internet transport protocols: TCP and UDP. You can count on TCP packets (little messages) being sent to their destination but that reliability comes at a cost. On the opposite side of the coin there is UDP which is very fast but that comes at the cost of reliability. You won't even know if your messages have been delivered! The downsides of UDP are almost irrelevant for the project because the controller in always sending information about the controler plus we can choose which of the two protocols we want to use, playing into each others' strengths and weaknesses.
Unfortunately web browsers are really restrictive about what kinds of protocols they will let us use. The only two ways to send UDP (or UDP like) packets is either with WebRTC or WebTransport, the latter of which is lacking support in Safari, a big deal for phones.