I wish they went into more detail about how the rendering happens. Compiling Doom to WebAssembly via Emscripten and running it in your browser is great, but it has been done before countless times. Taking the output and plotting it as a time series in Grafana...that is incredible.
Hey Kostas here (one of the 3 people we did this). We are actually using a WASM port of chocolate-doom from which we are getting the frame buffer from WebGL. We use 256 time series to represent each color, and then we are using an algorithm to map pixel data to their corresponding time series. Since doom uses more than 256 colors, we are using a redmean approximation to find the closest match
Thanks a lot :) That was literally a last 30 minute hack. We wrote some dirty code that exposes player stats into the javascript space and then it was a matter of forwarding them into the data source.
All levels use the same set of palettes. Aside from the normal palette, there are palettes representing various levels of color tinting for pickup/pain/berserk effects, and a slightly green tinted one for the radiation suit.
Yeah this could be anything from "wow cool" to "holy smokes, how is THAT possible???". If all of the game state, output pixels etc were turned into time series data and reassembled in a dashboard in real time--THAT is pretty cool!
Honestly, from what I've seen indie game development is sorely lacking for an easy real time dashboard display/input.
being able to expose variables, edit them and see them update live, and maybe even rewind your game to retest different scenerios would be so helpful to many games.
I developed a habit of building these kinds of 'dashboards' from my time in game development, and ended up working on software to generalize the visualization and program data monitoring aspects of them so they could be more easily added to arbitrary programs (always focused on display though, not editing variables—main interest was creating 'ambient' feedback from evolving program data).
If anyone's curious to see this more concretely, I give a demo here of a small one I built for another app I was working on (you'll hear it referenced as "Disk Atlas"): https://youtu.be/TeIgXzvYdpY?t=40
The video also talks about some more sophisticated / general purpose software for doing this (with a focus on creating easily comprehensible displays of data structures evolving over time) called Lucidity (started in 2014, now abandoned).
I've recently come back to the idea, starting from scratch again, this time with less of a focus on showing algorithm execution and more on creating queryable dashboards of dynamic program state.
I threw together a quick demo vid to give a glimpse at the new one, named 'printeff' (you monitor bits of program state by calling `printeff(myData)`): https://www.youtube.com/watch?v=uH4l9n3DaZ4
curious if anyone has thoughts :) I'll put out a better video than this before long though.
I've heard (but have no direct knowledge myself) that PUBG publishes extremely detailed telemetry(?) for matches, so detailed that you can basically replay the entire match from their API. Maybe this? https://documentation.pubg.com/en/telemetry-events.html#tele... Pretty neat!
There's also a Prometheus exporter for Factorio (https://mods.factorio.com/mod/graftorio2), which of course exposes huge amounts of data about the current state of your factory. Makes me wish you could flag specific regions of a factory as being distinct so that you could then drill down to find out where the iron shortage is.
That API does seem to cover everything - location, inventory state, kills & assists, care packages, breakable walls… I think the only info you don’t get is shooting (unless that updates the inventory state?) and even if it does, direction of shots that don’t hit anything.
Not sure what youre thinking of but older games have demos that are recorded games. Those would work well for testing nowadays too imo. Mostly performance testing but still.