Mining Data Out of Minecraft

mateusriff — Wed, 27 Aug 2025 03:07:58 +0000

Can Minecraft serve as a powerful platform to generate useful data? This is the question I've been occasionally pondering for the past few months. I've been tapping into the player's in-game inventories and actions, logging them to databases and exploring the resulting data. I'm particularly interested in getting a feel for the economy of a Minecraft world from said data. The results I've been getting are quite interesting and I'd like to share them here, along with my methods.

On my latest experiment, I logged the player's experience gains along with some metadata to a time-series database during a gameplay session. I later queried the database and plotted the data to make some interesting visualizations and get my point across.

The rationale behind logging experience gains comes from a hunch I had, that experience points might serve as a proxy for in-game economic activity. After all, whenever a player mines coal, smelts iron ore into ingots, fights mobs, etc., they gain experience — and these are all economic activities in essence.

I did this using a Minecraft plugin I built myself for a Paper server running on my local machine. The plugin itself is quite simple, consisting of three basic components: (1) an event listener, which listens to an event triggered whenever the player's experience points change; (2) a cache where player experience gains are temporarily stored; and (3) a database client that flushes the cache to InfluxDB every 60 seconds. I went with a time-series database because the data I was working with was fundamentally time-bound. You can check out the plugin's full code, along with the InfluxDB compose file, here.

So, what were my results after playing by myself on my local server for a about 1 hour and 30 minutes? Below, you can see the first plot I made, showing cumulative experience gain over time.

As you can see, gains happened in bursts and were followed by periods of little-to-no gains. This correlates with my activity during the session: the bursts happened whenever I mined, fought off mobs, and smelt materials for the home I was building. The occasional freezes in experience gains happened when I was exploring or actually building the house itself once I had the materials.

Remember the metadata I said I saved along with the experience gains? It included the chunk where the player was when those gains happened. Below, use your imagination to picture a top-down view of a Minecraft world underneath the grid formed by the heatmap. Each square on the grid represents a chunk of the game's world. The lighter the color, the most experience gains happened there.

As expected, the chunk where the most activity happened was the chunk where I was building my home and constantly smelting materials, with a total of 49 experience points gained on it. You can see some activity too in the lower left quadrant of the grid, where there were some caves I mined.

If we add time as another dimension to the heatmap above, we can actually see when gains happened in each chunk as a function of time!

There's a story being told there. I started in the lower left quadrant, mining. Then, moved to the upper right quadrant, where I decided to build my home. I moved back and forth between my home and the mines as I needed more materials to build it.

I can only imagine how cool it would be to collect this sort of data on a server with dozens or even hundreds of players. That's definitely on my to-do list! But before, I want to implement a slighty different approach, from which I believe I could mine data to answer even more interesting questions and tell more detailed stories — follow me if you want to see what's coming up next.

Although it's in-game economics I'm interested at, approaches like this can be used to mine data out of Minecraft for all sorts of purposes. With Minecraft being an easily extensible sandbox game, our imagination is the limit here!

How to (Over)Engineer a Simple Static Website

mateusriff — Tue, 24 Dec 2024 14:46:41 +0000

Just over a year ago, I was tasked with developing a new website for one of my college’s R&D groups. Their old website was built on top of a jQuery template and generally hard to maintain. Having built user interfaces for about a year up to that point, I thought I had what it took to engineer a better website… I was wrong!

XKCD 974: The General Problem

The projects I had worked on prior to that all used React.js, some with and some without Next.js. As they say, “if all you have is a hammer, everything looks like a nail.” And so I chose these technologies to build a simple static website.

In hindsight, from the get-go it was obvious this could not end well. React.js is kinda awesome, actually, if you want to build highly interactive, dynamic user interfaces with data-driven content. Next.js is a fine accompanying framework that offers server-side rendering, routing and helps optimize performance (among many other things). However, the website I built was static, meaning it wouldn’t benefit from most of these features. Sure, it could be built with React.js and Next.js — and it was —, but at what cost?

The aforementioned tools are rather complex. To build websites with them, you need to know their ins and outs. You can’t just write markup and styles and call it a day, as those need to be written inside React’s paradigm of functional components and hooks, adhering to a component-based architecture and handling data flow through props and contexts… That’s all to say you’ll be writing more lines of code.

That’s not a problem by itself, of course. Your project’s requirements might be impossible to meet with just markup and styles, and you might waste time reinventing the wheel writing your own JavaScript code instead of using an off-the-shelf solution. But if the requirements can be met without this additional complexity, it’s wise to do so. Otherwise, you’ll overengineer and end up with a project that is much harder (and costly) to maintain than it should be.

This is how we’ve come full circle with the website. The old one had to be replaced because it was difficult to maintain. The new one now finds itself in the same — actually, in a worse 🤫— situation thanks to the brilliance of a young software engineer with limited repertoire. I guess we need a new new website now! I plan on throwing the current codebase away and rebuilding it with as little as possible aside from HTML and CSS. Perhaps I’ll consider a static website generator.

DEV Community: mateusriff

Mining Data Out of Minecraft

How to (Over)Engineer a Simple Static Website