Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


I understand that the game is being "run" client side... how are the other components (health, ammo counters) talking to each other? Very cool btw!


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.


Hold on - so this isn't an April Fool's joke?


No, it is not :D It was part of an internal hackathon. You can actually try it (there are links on the blog post)


Actually in DOS Doom only uses 256 colors for rendering and its palette.


256 at any one time. But, the game has different palletes on different levels. I guess they have to map each pallete to a single display method.


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 know it's not quite what you had in mind, but the game I play has a publicly documented API so I wrote a Prometheus exporter for it and visualise the stats in Grafana. https://joshhunt.grafana.net/dashboard/snapshot/TJv1Wu64IykH... https://github.com/joshhunt/prom-destiny-exporter

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!

(FYI, I work at Grafana)


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.


Unity 3d has this where you can update variables directly from the editor, some scripts can be reloaded aswell, maybe you meant for network games ?


this sounds neat on paper but once your game is beyond a sufficient complexity threshold this quickly becomes untenable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: