In the past year or so, it has been very difficult to organize live demoscene parties. On the other hand, it has become possible to have very specialized online events that feel just as important and magnificient as the online versions of the biggest parties such as Revision or Assembly. One of these was Lovebyte 2021 organized in the second weekend of March.
The defining quirk of Lovebyte was that the competitions were for size categories of 256 bytes and less. So, whereas the arc of a normal demoparty builds towards the climax of the practically unlimited (multi-megabyte) main demo competition, here the climax consisted of 256-byte demos for three different platform categories ("oldschool", "fantasy" and "high-end"). This provided an interesting shift of perspective: at usual demoparties, the smallest size category is often the 4K, but for Lovebyte, even that was an order of magnitude too big and mainstream.
But there was something profoundly silly in this event: it was streamed over Twitch. So, in the 32-byte compo, the video file for an entry might have been a million times as big as the executable, but even that was not enough for some entries: the codec just couldn't handle all the pixel swarms. Wouldn't it have been better to just have the watchers execute the code and have the Twitch stream as a backup plan?
*
The idea: have a client program that implements all the supported platforms. The party takes place on a server that takes care of sending the entries to the viewers and running them. For livecoding contests and gigs, the server also forwards the performers' input events, properly synchronized, to the watchers, so everyone would be seeing the same thing at the same time.
This would be particularly non-problematic for an event that "celebrates the small", running tiny programs on smallish platforms that are mostly virtual to begin with. If the constraints for entry size, memory size and execution speed are all small enough, the system and bandwidth requirements for watching or even hosting the event would be rather trivial.
The clients would be running arbitrary code from arbitrary users, yes, but the code would have no access whatsoever to resources outside of the sandbox implicit to the platform, so no chances for exploiters. It wouldn't be a web browser running arbitrary Javascript.
For a minimal proof of concept, one could think about a TIC-80 party based on a version of TIC-80 extended to have server connectivity and a suitable control protocol. This fantasy platform was already hugely popular at Lovebyte, and even the live coding contests ("byte battles") were based on a modified TIC-80.
* *
I already had a somewhat overlapping idea back in 2015, but I never publicized it before life took me to areas where this project did not feel very relevant.
The system I envisioned would have been called CUGS, or "Computer Underground Simulator". The point was to replicate certain creativity-inducing aspects of the old microcomputer culture but in a somewhat friendlier way.
The user would be running a program that implements one or more fantasy platforms and/or emulators. There would be a programming environment for making programs, as well as a terminal for connecting to BBSes. The terminal would be somewhat like an oldschool text terminal but would also have a protocol for running code in the client-resident virtual machines. This would enrichen the BBS environments and make it easy to share one's own creations in these environments. There would be a central BBS but anyone would be free to host their own BBS, MUD or whatever else they can imagine.
I was partially inspired by Pico-8, the "fantasy console" that was released earlier that year. Pico-8 manages to capture a lot of the original creative joy and immediacy of the old microcomputers and distill it even further by removing many worries. Nothing needs to be initialized, the pixel framebuffer has no quirks, and everyone has the same configuration. The low resolution combined with a sufficient execution speed also helps level the playing field: there is still room for cultivating excellence, but beginners don't have to be ashamed of their first creations.
My hope was that extending the concept to include telecommunications would help maintain and create cultural forms where DIY coding is a central activity and a way to gain social prestige. I did not consider the streaming aspect at the time, but now I think it would fit quite well with the general idea. In addition to contests, gigs and basic "gameplay streaming", many kinds of co-creative scenarios would become possible.
* * *
I don't know yet if I'll start implementing this idea, but at least it's public now.
I still call it "CUGS 2.0" in my notes, but that's unlikely to become its final name. "Computer Underground" tends to refer to rather specific subcultures that have suffered from elitism and narrow demographics, and I want this project to be much more inclusive, maybe even to have some mass appeal. (Minecraft wasn't supposed to have mass appeal either, and Lovebyte wasn't supposed to get hundreds of competition entries, so why not dream big?)
In the big picture, I see this project as contributing to a cultural shift away from the kind of growth fetishism that is destroying the world. An increasing portion of global energy use is taken up by computing and telecommunications, and the esthetic preference for things like maximal video bitrates play no small part in it. This is why I consider it crucial to design "CUGS" to encourage a "small is beautiful" mindset and to prevent resource use beyond a fixed limit. Also, when concentrating on the small, the virtualization overhead becomes a relatively small issue.
Additionally, I see the project as educational and as something that can deepen people's relationships to the "bits and pixels" at the grassroots of computing. Even though the virtuality makes the thing rather "soft" or "unrooted", this is compensated by the "hardness" of the platform definitions. To my experience, even an emulated 8-bit computer feels more material than the complex hierarchy of shaky abstraction layers that the modern mainstream computer is.
For me as a demo artist, this could be a (meta)platform for artistic and technical DIY-from-scratch experimentation, but with an additional possibility of experimenting with interactive and multiuser mechanisms. The code-centricity would make the system quite flexible while being freer and safer than the web, so it is quite difficult to envision all the possibilities. We'll need to implement this idea to find out where it can take us.
Written by Ville-Matias "Viznut"
Heikkilä, 2021-03-25.