Tartan Hacks 26: One Must Imagine the CS Major Happy

Thank you to my wonderful teamates: Sid Radhakrishnan, Nathan Ye, and Aayan Maheshwari. Additionally TartanHacks organizers, ScottyLabs, my fellow Terrier (the blazingly fast agnostic hackathon platform) devs

tl;dr here’s the link to the live demo with all games and prototypes and the repo, if we (gemini) locks in the demo will include all the protypes we made as well as our main game “Futile March” (alternately, “sisyphus”)

This was the first hackathon I’ve done in over a few years and back in my day we used to have to hand code everything. I lowkey went into this thinking we wouldn’t use that much AI but the inevitable occurs when you see how fast development is with Antigravity and how fast people are iterating. Luckily I am proud to say I feel like we did not make AI slop

AppLovin’s Axon track challenge was simple enough: make a fully featured game that ran in the browser and was fully self contained which was 15 KB when compressed. The special thing about this project is that we couldn’t use any frameworks making it slightly harder to use an AI model.

Idea Generation

The standard idea here is to make a well polish low resource 2D game. Focusing on innovation in game styles and technical aspects like compression and optimization of code, but that’s boring and makes it really hard to beat the HCI majors… Luckily Sid remembered something he saw a while ago: ray marching

Ray Marching

A model of a sphere is around 40 MB which is approximately 2700 times the 15 KB limit. A low poly version is 147 KB, 10 times our limit and now has a weird effect with sharp corners. So it isn’t feasible to store objects reliably in these formats. Instead we may mathematically define 3D objects and render them using equations in our code compressing a sphere to a simple 270 bytes.

Then using WebGL, we can render these equations on any browser in any device with arbitrary resolution using a technique called ray marching. Essentially we project a ray from the camera and open a sphere with increasing radius until we collide with an object. At the collision point we know where to draw an object. Then we apply shaders to create the full image. Sid could probably explain it better than I could, but heres the image we used:

Coding the thingy

We iterated quite a but for this project and the games we prototyped with were decent. One of the first games came from my agent and was a “flight simulator”. As you can see the graphics are mediocre but not bad for 15 kilobytes but there’s no real direction to the game and we have control and camera issues. We had similar issues with the (unreleased) racing sim by Nathan. Moreover, this game was 6 KB gzipped which was a severe underutilization of resources.

So what do we do with extra storage, add better graphics: ShaderToy has a plethora of shaders for us to use to improve our graphics, so we created a pipeline to make better games. One of the coolest looking games we created here was Sid’s fractal flier (aka LSD game) which showcases a fractal (a simple function) with some very colorful shaders. This was just 2 KB. Nathan added a water shader to the next game: Seascape.

Finally we needed to find a direction to make the game fun. Obviously, there’s not a lot fo things we can do in terms of unique controls and mechanics in 15 KB, so we got to work working simpler ideas. One was Aayan’s flyer and one was the main project on Sid’s laptop: Futile March. We largely abandoned the flyer because the physics weren’t as technically impressive as Futile March (also Aayan went to bed).

Discourse: Compressing

We quickly found that the 120 kilobytes of shaders and scripts that we had written was not going to compress well. As an intermediary script, then, we incorporated minifiers which brought us to ~60 KB and finally applied the hgihest level of brotli compression to read 15 KB (15311 bytes, to be exact 49 bytes short of the limit). We found that though we could compress the shader language it actually worsened compression likely due to the common string patterns breaking during Huffman.

Discourse: WiFi

Of course, a self contained game runs fully offline, but as an additional track we planned to add WiFi features. To implement this, I added a wifi button which enables a small piece of javascript which allows the website to use the internet to import one javascript file. This javascript file can contain references to others and essentially make the game modular and accesible via a CDN. The only “wifi feature” that was implemented was audio to import a full quality audio file. Despite this, one common point of future direction would be to include some kind of multiplayer extension, or a way to connect to an external gyroscopic controller.

Anyway, that was about it. It’s time to fix my sleep schedule and start doing homework.

IHTFP but a little less now and all it took was $125 :)