Going to Metal in Game Design
What happens when we start to understand game design in terms of hardware instead of just software? What happens when our design considerations push even further to include the electricity which powers said hardware? What happens when we “go to metal” as the software engineers like to say?
For the Trees, our forthcoming Minecraft modpack, will be downloadable and playable on any computer that can run modded Minecraft. It has been designed for an SMP experience that will launch on May 24th hosted on SunBlock Two, our second custom built solar-powered server based at the Milieux Institute for Arts, Technology and Culture at Concordia University in Montreal. SunBlock Two is a brightly spray painted Odroid H4+ (Intel N97, 48GB DDR5 RAM, 1TB NVMe SSD) running Ubuntu server 24.04 as the operating system and CubeCoders AMP to manage the Minecraft server instance. SB2 is powered by a 100Ah lithium-ion battery, charged by a 100-Watt solar panel set on a terrace nearby.
This hardware system interfaces with our custom API (sunblockcore-LL) to process the data collected by sensors in our Epever solar controller and the Odroid motherboard, and this is used by our various mods as part of the SMP game experience.
When you are playing For the Trees on SunBlock Two you will have an in-game HUD displaying real-time solar power data, the energy consumption of the server and the state of the battery. This information and players’ collective response to it becomes part of the gameplay over the course of our six-week game. Woe be to all if there happens to be unseasonably overcast weather in June.
There is more to the project however than just demonstrating how it’s possible to play Minecraft with renewable energy. What we want to do is make energy infrastructure playable… to make games with it and not just about it. I will talk more about why we might want to do this in future blog posts but for now I want to talk about the game design considerations for our system which amounts to configuring hardware for playability and not necessarily for efficiency.
With SunBlock, we need to get down to metal and expose that to the players as best as we can. Our server can’t be a virtual machine on a cloud server, it needs the physical hardware in the same geographical location as the server itself. And on top of that we need to recontextualize the “best practices” of server management and DevOps to a low powered, DIY-able, solar-powered system; and each descriptor carries weight here, each opens a different dimension. The local physical state of the server and its environmental context are part of how we make the energy infrastructure of the game legible for players. Being able to account for each component of the circuit is part of the process and as Rosie McDonald has already described so well, we end up doing more messing with electrical wiring than most game developers might see in their lifetime.
In addition, unlike a conventional game server, we know that this server will at times run out of power, so the idea of High Availability (HA) essentially goes out of the window… on purpose. We could always add more solar panels and batteries to generate enough redundant power to keep the server up 24/7 but again, making the system legible for players means introducing them to the conditions of failure. Software crashes and hardware glitches (port failures, lag) are to be expected with most digital games but beyond accidental power outages we don’t normally expect to run out of power when we play.
In the case of SunBlock, running out of power constitutes a kind of a lose condition for the game because it’s possible for players to take actions which can consume more or less power or preserve the battery to prolong server uptime as part of an overall strategy. This is a strategy that is, in turn, affected by real time weather around the solar panels and the specific material conditions of the hardware system (wire connections, temperature, battery condition). Interestingly, it is also a viable strategy in some cases for players not to play at all! If the battery does drain past a threshold the server will shut down and players will be booted. The server restarts automatically once the battery has charged back to a median state. In this sense playing on SunBlock is a kind of roguelike game… the server will die eventually.
Part of enabling player choices with respect to energy use involves a system design where we can control for all possible sources of power consumption so that we know what players can affect and what they can’t. Any additional hardware components (such as peripherals) or software layers (like operating systems) are going to consume additional power from the battery that players cannot control which will make individual player choices less palpable.
The design constraint here is that we need the leanest possible machine with measurable power consumption but we also need the system to be low power enough that players can see the effects of their own actions on the system. This often registers at levels less than a single Watt so a server which is drawing 100+ Watts would occlude any player driven effects. By the same token a low power SBC like a Raspberry Pi would allow player effects to be visible but it barely runs vanilla Minecraft, let alone our stunningly gorgeous modded worlds.
The headless Odroid H4+ does the trick, with idle power draw around 5-6W and peak draw playing our modded Minecraft games seldom going above 60W. This in turn is balanced against the power generation and storage. If we want players to care about the energy infrastructure and attend to the state of the battery and the solar panel then we need to balance the size of the battery and panel against the power consumption of the server. Since multiplayer Minecraft is usually played over days and weeks not hours or minutes, we tune the system so that on a sunny day our panel can charge our battery to full while players are online but no matter what there is a slow and steady degradation of battery capacity if players don’t manage the power impacts of their play. That is, as long as no one plays, the server should be able to idle indefinitely (at least from June-Sept in Montreal) and as the number of daylight hours decreases we have the option to add more solar panels (up to 300W) and even more batteries.
With the constraints of operating on not-unlimited power, having to manage the infrastructural complexity from metal to Minecraft, and building abstractions in ways that the system is reproducible, we find it useful to visualize the whole system in three layers. We propose the Physical Layer (PL), the Logical Layer (LL), and the Game Layer (GL). A visual summary is present in the figure below:
The physical layer comprises the solar panel, solar controller, battery, and a mini PC. The logical layer corresponds to everything that happens inside the mini PC, such as a web API, a database, real-time data access, etc. And the game layer corresponds to everything inside a Minecraft server instance i.e. the solar mods and the modpack.
On every layer you find a component called the SunBlockCore. And as the name suggests, it is core to the functionality of that layer. On the physical layer, it is the mini PC i.e. SunBlockCore-PL. On the logical layer, SunBlockCore-LL is a python program that is responsible for real-time instantaneous data, historic data logging, automated power management, etc. On the game layer, SunBlockCore-GL, is a Minecraft mod that brings in the solar data from the logical layer into the game and broadcasts it to connected clients on the multiplayer server. This data is then used by the mods we have made (a Solar HUD, power buttons, and solar tools) and can be used by other mods as well. SunBlockCore-GL essentially acts like a modding API for a solar Minecraft experience. This architecture invites other modders to make their own mods for a solar powered server. In this way, we have tried to design a system architecture which is accessible and scalable while inviting collaboration and innovation from users.
The point of all this then is not to build the most energy efficient server for playing Minecraft or even to reduce the overall carbon footprint of Minecraft play. Though these are laudable goals our aim is rather to engage the player directly in the conditions of the production of their own play no matter how energy intensive that may be. The energy transition is not about learning to play with less power so much as it is about learning to play with power differently. At high noon in the Montreal summer there is more than enough power to run the most energy intensive games we can imagine but this desire might need to be curbed under different conditions where other desires could be fostered. Similarly, we can see immediately how the solar server makes energy consumption and management into a collective social problem as battery capacity is a shared resource. This invites players to think creatively about how such resources might be managed in the context of a game and this in turn bares upon real world questions of community managed solar microgrids for example.
Finally, with the rise of plug and play balcony solar systems we anticipate that more and more microsolar systems will come online. The basic logistics and infrastructural requirements of these systems (100-500W panels, solar controllers, batteries) mirror the configuration for SunBlock. Players can find instructions building their own solar server, use and adapt our SBCore mod, and even develop their own solar mods both as way of developing technical literacy with what is fast becoming everyday consumer technology but also as a way of prompting new imaginaries for the use, innovation, and configuration of these systems in everyday and community contexts of play.