Metal panels crumple like tissue paper on the third swing of the sledgehammer, as the entire door apparatus is torn from its socket. Once sealed by decades of disuse, this room is now permanently unlocked. On the other side, your reward: tools and tchotchkes, bits and bobs, and all manner of artifacts gleaming in perfect condition. Welcome to the junk drawer.
Hello, and welcome to another Tuesday devlog! Today we are continuing a repeating feature called Tales from the Junk Drawer, where we show you a series of items from Dandelion Void with no context other than their in-game descriptions. At the end we also have a story about how we generate these item renders, and a humorous bug that occurred when the system was pushed too far.
But first – in response to reader feedback, we are going to start labeling the types of "spoiler" content in each post. Any information about an unreleased game could technically be considered a spoiler, but in practicality most players will only care about "going in blind" for certain aspects. Whether that's the story, strategy, or the scariest horror moments, our goal is to give you the tools to decide for yourself!
Spoiler label: This post shows in-game art for a number of items along with their flavor text, but no mechanical data.
What a lovely pile of junk! Now, as promised, a bug story:
All of our items and furniture are represented by 3d models when placed in the world. But once you pick something up, it appears in your inventory grid as a pre-rendered 2D “thumbnail” image. In most games these thumbnails would be generated by the developers and packaged with the game download.
But to support a modding environment, thumbnails in Dandelion Void are instead generated by the player's computer. This is useful because if someone changes the model or texture for an item, its preview can be automatically be updated without additional work from the modder's end.
To maintain a consistent level of fidelity, items that take up multiple inventory tiles get larger previews. The 1x1 book above generates at 48x48 pixels, while the 4x2 couch is 192x96. Each item also gets a second render at three times scale for the zoomed-in detail screen.
This system has worked great for years, but one day we noticed our startup times had increased considerably. We even saw a few crashes! Eventually we decided to print out the name and size of every generated thumbnail, and discovered with horror that one item was requesting a 14,246 by 14,246 texture.
One of these things is not like the others...
As it turns out, Robin (yours truly) had marked a piece of immovable furniture as 99 inventory tiles wide and 99 tiles tall. She liked that this showed a cheeky “no room (99x99)” message when you tried to pick it up, but the thumbnail system didn’t know that you weren’t actually supposed to be able to get it in your inventory. So on startup, it tried rendering a thumbnail over 10,000 times the pixel count of the couch’s. Some people's GPUs didn't much appreciate this, and the rest is history.
This is a great reminder that in a systems-heavy game, you have to consider every context a piece of game data might be used in; changes that seem small can have big impacts! While this was a thorny bug, we were happy to see it resolved with a simple solution – and a good story.
Thanks for joining us for another post. Everybody please take care and have a great week!