Posted February 17, 2022 by Ash K
#post-mortem
Radio Bubbles design was informed by its aesthetic. While discussing a bunch of possible options of what to do for the theme — rituals, Ash was playing around with shaders and sent me (Brin) some pics of shaders that we both really liked.
These lines reminded me of radio reach maps. We started talking about making something with radios. Coming to the actual theme, rituals, I wanted to make something that would make you want to return to it every day.
The idea of a slow social media, one that limits you in how much you can post is nothing new. Twitter would be the most popular (and least effective form of it), limiting you to 255 characters. Something like slowly allows you to send messages but they take physical time to “arrive” at the destination, encouraging thoughtful and long discussion.
Radio Bubbles is a mix of this. It allows you to send a message once per day, hopefully encouraging you to come back. But that message is small, lowering the barrier and hopefully making it more open to offhand comments. Requiring to send a message before being able to see other ones is also a way of inviting the player to “just put something in there” to be able to see the messages. This creates something like a bucket of comments where one swims on top, every so often.
Let’s end it on the note of frequency. Both in the randomly assigned number to each player and the frequency of messages. Your MHz is something that is not unique to you, which I think is wonderful, because in real life you could also have multiple people broadcasting over the same frequency at different times. And well, Radio Bubbles are all about async communication.
Lastly, frequency of messages. I thought at first that it would be send 1, get 1. But that’s stupid, we need a reason to look at Ashe’s nice shaders.
The game actually runs in a regular window. To achieve the effect that you see a number of simple tricks was used:
(seriously, why does Godot have so many options that all need to be turned on to enable a single thing??)
After that is done you have an empty and invisible something on your screen that can render things inside of it and accept inputs. Good for virtual pets and such
The blob that shows the procedural art and has moving edges is just the noise shader from SnakeAcid(read how it’s made here), but inverted this time, and instead of rendering noise it renders a viewport texture of a viewport that has all the procedural art inside of it.
The procedural art that grows and morphs over time was created using a number of shaders, textures and particles. I myself don’t really comprehend how it works but i will try to explain it.
the patterns you see are bigger than in the game because they render based on screen UVs and recording large res gifs is a pain. Also the neon green is the placeholder color for the transparent bits (godot can’t display transparency in-editor).
P.S. There’s like 8 floating point variables in this shader that can be changed at runtime while keeping the movement of the images continuous, they are not touched in engine because it was hard to animate them in an compelling way while running out of time.
The whole messaging system runs off google spreadsheets. We’re using HTTP Requests to send data via a google form. The google form is converted is feeding the data to a google spreadsheet. There is a GScript inside of the google spreadsheet that is converting the spreadsheet into a json that is hosted on googles servers. We end the whole cycle by pulling that JSON into the engine with a HTTP request.
It’s extremely janky but it works. We will write a tutorial at a later point on how to do replicate it in godot/any engine with http request.