Dandelion Void News

[p]Hi everyone! Welcome to another Tuesday dev blog. Today we’re going a bit “under the hood” and discussing the Lua scripting language – what it is, what it does in Dandelion Void, and why we chose it![/p][p][/p][p]Lua (Portuguese for “Moon”) is an ultra-lightweight programming language with only 23 keywords. Its stylistic simplicity and high performance make it popular as an embedded scripting language in video games. If you've played Garry's Mod, Project Zomboid, Don't starve, Roblox, or any of a dozen other games, you may have already enjoyed the benefits of Lua without knowing it![/p][p][/p][p]Before we get started, some housekeeping: some of our team will be out of office next week, so our next dev blog will be in two weeks on Tuesday September 30th.[/p][p][/p][p]When we say that Lua is embedded as a scripting language, this means that there are actually three programming languages involved in Dandelion Void. [/p][p][/p][p]The first is the C++ code used to write the Unity game engine. This comes to us already compiled, so we don’t touch it directly. Next up is C#, the standard programming language for Unity games. Things that you might consider our core technical systems – assembling renderers for entities, loading and unloading chunks, etc. – are all written in C# by us.[/p][p][/p][p]And then all the way at the top there’s Lua, where most of our “gameplay code” lives. Lua is what tells your hunger to tick down and eventually diminish your health, Lua is what determines the context menu options when you right click on a piece of furniture, and Lua is what tells the music system to play the combat theme when enemies approach.[/p][p][/p][p]Now, why would we go through the trouble of splitting ourselves between both C# and Lua? There are a few answers![/p][p][/p][p]C# is a compiled language. In practical terms, this means that every time you want to make a change and test it in the game, you need to wait a few seconds (around 5 to 30 depending on the project) for the code to compile. You also can’t recompile while your game is running, so if you want to make a change you have to stop the game, wait for the code to recompile, and start again. This can really slow down development!
[/p][p]As an interpreted language, Lua skips the compilation step. There’s no delay to see your changes take effect, and you can even edit files while the game is running. This is a godsend when you’re doing rapid iteration on a game design feature, or trying a lot of different solutions for a bugfix. [/p][p][/p][p]One of the other advantages Lua has over C# is that you don’t need to pre-declare all your data fields in advance; you can just make them up on the fly! This removes some pre-planning steps and makes it fast easier to write Lua in an “off the cuff” style.[/p][p][/p][p]These qualities aren’t just why we enjoy working in Lua – they’re also the reason it’s the programming language of choice for modders![/p][p][/p][p]Engineering and game design are different skillsets, and at large companies these roles are frequently performed by separate people. The simplest form of this team dynamic would be for a designer to come up with the ideas and then ask the engineer to implement them, but this is pretty inefficient. Important details can be lost in the game of telephone, and each person has to find something else to do while the other is working.[/p][p][/p][p]Lua and other scripting languages offer a nice solution. Lua code is far simpler than C++ or C#, and it’s pretty easy for designers to pick up. Once a designer is comfortable in the scripting language they can implement their ideas directly and test the results in real time, while the engineers can continue to support them by adding new hooks from Lua into the main engine of the game. Having Lua separated from the rest of the codebase is also a safety measure, as it means designers won’t be tempted to tamper with sensitive engine code that could lead to huge bugs or crashes.[/p][p][/p][p]The same qualities that make Lua good for designers also makes it good for modders. Lua’s simple elegance makes it accessible to hobbyists of many skill levels, whether or not one has a formal computer science education. The lack of a compilation step or time-consuming infrastructure also means that if you only have a few hours each day or week to spend on modding, that precious time isn’t being eaten up by loading and busywork.[/p][p][/p][p]Perhaps most importantly, Lua is good for modders because modders are used to using it in other games! Our game director Brian got his start as a modder, and creating a modding-friendly environment has always been a top priority for us. If you’ve already modded Roblox, Garry’s Mod, Project Zomboid, or similar games, you’ll already have a head start for modding Dandelion Void! [/p][p][/p][p]I have to admit, I rolled my eyes a little when Brian told me he was integrating a Lua scripting layer into our game. Each of our engineers has over a decade of experience working with C#, why put something else in our way? [/p][p][/p][p]But the more time I’ve spent working in Lua, the more I’ve come to appreciate its loose, gestural style. Writing C# and C++ is like building with wooden planks; you have to measure and cut all your material before you’re ready to build, and if you change your plans halfway through, you might need to just start from scratch. Lua is like working with clay; you can just get your hands dirty, squish it into the shape you want, and embrace happy accidents! There’s a certain element of spontaneity to Lua that captures the original joy of programming that drew us to this trade in the first place.[/p][p][/p][p]I’ve been having quite a lot of fun working in our Lua codebase, and I hope you do too! Until then, take care and have a great week – we’ll see you back on the 30th![/p]

[p]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.[/p][p][/p][p]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. [/p][p][/p][p]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![/p][p][/p][p]Spoiler label: This post shows in-game art for a number of items along with their flavor text, but no mechanical data.[/p][p][/p][p][/p][p][/p][p]What a lovely pile of junk! Now, as promised, a bug story:[/p][p][/p][p]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. [/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p][/p][p]One of these things is not like the others...[/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p][/p][p]Thanks for joining us for another post. Everybody please take care and have a great week![/p]

[p]Hi everyone! Welcome to another weekly Dandelion Void dev blog. This past week we put a bit of spit-shine on our enemy vent spawning behavior, and so today felt like a good opportunity to give you all a rundown of the system![/p][p]One of the best tricks a horror game can pull is to create a "promise" of safety, only to break it later. In the first five minutes of Dandelion Void, players will observe that the plant-spider “uproots” dwell in the tall ponics that have overgrown the ship. This makes for a simple rule: vegetated areas are dangerous, clean rooms are safe.  [/p][p][/p][p]But if players are unwary, the relief of finding or making a plant-free room will be short-lived. As it turns out, the ship is full of convenient little back-door shortcuts for uproots to take: the air ducts! Originally built to circulate breathable atmosphere through the Pergola, these vents are the perfect size for a compact, flexible plant creature to crawl through.  [/p][p]A fun fact about the uproots of Dandelion Void is that there's currently one standing right behind you[/p][p][/p][p]These vent ambushes have prompted some the biggest emotional reactions we've seen from playtesters; in an instant their sense of safety is demolished, as bedtime turns into fight-or-flight.[/p][p]Smart players will only make this mistake once. The simplest way to block a vent is to lug a couch, desk, or other piece of furniture over the vent entrance. Alternatively, you can directly board up the vent using ponic stems from the jungle or wood from destroyed furniture. Note that weaker barriers will atrophy over time, so maintaining your barricades is just as important as constructing them. [/p][p]Blocking vents with furniture or boarding them up with stems are both valid ways to secure your base[/p][p]Vent spawning is an ideal game mechanic in that the rules are simple – vents can spawn uproots at night, barriers can block the spawns – but it has a high impact on the game experience. Having a visible source of danger to track contributes to the player’s general sense of unease. Making the vents blockable adds a satisfying little base-building step, and turns furniture and ponic stalks into useful resources.  [/p][p][/p][p]Most importantly, the vent system emphasizes the setting of Dandelion Void. The core of our game’s identity is the contrast between the human-built spaceship environment and the untamed jungle that’s overtaken it. Wild plant creatures having the run of these man-made airflow corridors embodies this dichotomy both mechanically and aesthetically, giving you an experience that is quintessentially Dandelion Void![/p][p]Thanks for reading. Until next time – seal all the entrances, and never let your guard down.[/p]

[p]Hi everybody! Welcome to another Tuesday dev blog. Today we are talking about a new readable book system in Dandelion void, the content we’re writing for it, as well as some thoughts about narrative delivery mechanisms in games![/p][p][/p][p]Our team draws a lot of inspiration from science fiction literature, and we’ve been doing a lot of worldbuilding for Dandelion Void over the last few years. Like many titles in the “explore a cool abandoned structure” genre, our story is delivered through little scraps and pieces that you find in the world. Up to now this has been through item descriptions, but this week we've added readable books! [/p][p][/p][p]Books have technically been in the project for over a year, but mechanically they were just an alternate type of “food” that lowered your boredom instead of your hunger (for a while, we even had an audio bug where your character would chew loudly while turning the pages) These food-books worked fine, but most playtesters were disappointed that they didn’t get to see what their character was reading.[/p][p][/p][p]So as of this week, each unique book now has a short excerpt that appears above your player's head as you read! Most of them have between three and six sentences which you can read consecutively, or take a break in the middle if you like. [/p][p]
[/p][p]Showing this text over the character instead of via a menu means that you can continue exploring while you read, without having to pause the game. Just be careful to not bury your nose too deep – distracted bookworms make for great uproot fertilizer.[/p][p][/p][p]Displaying some text is easy; writing is the hard part! In particular, we've put a lot of thought into the format of our in-game texts.[/p][p][/p][p]A common device in games is to deliver your story through diegetic documents; your character is finding actual emails, letters, diaries, etc. that are written from a first person perspective. When done well this can create immersion and intrigue, but the constraints of the format often lead to a formulaic and contrived tone.[/p][p][/p][p]When people communicate in real life, they typically have a high level of shared context...[/p][p][/p][p][/p][p] But the goal of video game narrative is to communicate exposition to the player, so the writer frequently needs to make characters restate information that should be obvious to both parties: [/p][p][/p][p]“Dear Samantha: as you know, today Horace from management implemented the new surveillance policy. The iris scanners, the fingerprinted doors, cameras tracking you everywhere you go – it’s creepy! Things have just been getting worse and worse since Arnold Kramer and the New Romans party came into power. I’m terrified what will happen to us if there’s another leak.[/p][p]-Janie” [/p][p][/p][p]While this is just a silly example, it really is hard to write documents like this that sound natural. Samantha knows that Horace is a manager, she knows what the surveillance policy is like, and she certainly knows the name of the president and his political party – but the player doesn’t, so Janie has to spell it out. You also see this problem a lot in audio logs, only there, there’s the added issue that you have to justify why the character is keeping an audio diary in the first place.[/p][p][/p][p]With this in mind, we’re experimenting with something different: straightforward, honest-to-goodness, third-person prose. Most book excerpts are written as if they were snippets of a novel; dialogue is quoted, the reader has access to the interior thoughts of the protagonist, and a narrator can describe the scene.[/p][p][/p][p]We will be the first to say that this makes less diegetic sense than the first person, “found-document” style. Our in-canon explanation is that these are biographical novels on the lives of important characters, but yes, that’s a bit of a hand wave. On the other hand, not having to justify the premise for every document gives us a lot of flexibility and lets us skip the “Dear friend, I’m writing to you because…” filler. We also think the third person format captures some of the energy of the science fiction novels that have been such an inspiration for the game. [/p][p][/p][p]In fact, to get in the sci-fi-spirit, our first batch of books come from a series of short stories set in the Dandelion Void universe which Robin wrote last year to serve as “narrative concept art.” This was just meant as a worldbuilding exercise, but these stories have ended up being a nice primary source from which we can harvest snippets for in-game use.[/p][p][/p][p]As always, this dev log is just a snapshot of our current thought processes. The final game might very well end up going with first-person documents, or even a mix of styles. Or who knows – maybe we’ll give up on the whole “words” thing and just stick a couple skeletons next to toilets. Instant game narrative.[/p][p][/p][p]That’s all we have for today – it’s time for us to hit the books![/p]

[p]Hi everyone! Welcome to another weekly dev blog. Last week we talked about Sickle, the editor we use to make levels for Dandelion Void. We actually had so much fun talking about the tool that we ran out of time to discuss what we were making with it. So today, let’s talk level design![/p][p][/p][p]As with last week, please know that the content shown in this post is very WIP. Level design is one of the most iterative gamedev disciplines, and we would be surprised if even a single room pictured below makes it into the final game. This post is about the journey, not the destination![/p][p]Designing maps for survival-crafting games is a balancing act. The sandbox aspect of the genre means that your levels can't be fully linear; players want a sense of exploration! They want to pick a direction, walk until they find something cool, and feel the satisfaction of discovering the world themselves. Do anything, go anywhere![/p][p][/p][p]But at the same time, the survival-crafting genre is also very progression based! Part of the fantasy is starting off with just the shirt on your back, then clawing your way up to more and more powerful gear from more and more dangerous environments. This implies at least some amount of linearity; from low to high tool tiers, or from early-game to late-game areas.[/p][p][/p][p]Different games exist at different locations on the spectrum: some lean sandbox (Minecraft, Project Zomboid, etc.) while others lean more on the progression (Subnautica, Valheim, etc.) gameplay. But whether your maps are made by hand or generated procedurally, It is up to the developer to find a harmony between both of these aspects.[/p][p][/p][p]This brings us to Dandelion Void! We recently conducted an internal playtest with some game industry colleagues. What we found was that our friends had a great time early on as they struggled to survive their first few nights. But once they built a safe room and built up a supply of food and water, they felt a sense of not knowing what was next. Part of the issue was that the test level they played was extremely circuitous and open-ended. There were different regions to discover, but players didn’t know how to find the paths between regions, or how to understand what was an “early game” versus a “late game” area.[/p][p][/p][p]Some of this can be fixed simply with game balance and more content. We can tweak the survival mechanics to make it harder to stabilize, and harder still to keep that stability. And as we add new furniture, tilesets, and hazards, we can increase the average differentiation between any two given areas. With that said, we wanted to experiment with what a level design based solution could look like![/p][p]Sid Meier of the Civilization series has a famous motto on game balance: “double it, or cut it in half.” Rather than tweaking something 5% here and 5% there, you get the most information as a designer when you make large, sweeping changes, even if they end up being an overcorrection. If your combat is feeling too easy, bumping enemy damage from 5 to 6 won’t feel very different. Try it at 10, and go down from there![/p][p][/p][p]When we found that our test level lacked a sense of progression, we made a new one which represents the other extreme. “Pergovania” is a hub-and-spoke map divided into small, discrete areas that can only be accessed by obtaining a tool from the previous area. Four areas – the safe closets, the administrative offices, the plumbing corridors, and the pollen farm, are connected by a central reactor pool. In order to get into the admin offices, you’ll need a bludgeon from the reactor pool to break down a broken door. Meanwhile, the hallway to the plumbing corridors has lost power and requires a backup battery which you can find and charge in the admin offices. As you’ve probably guessed, this test map is inspired by the lock and key mechanics characteristic of the Metroidvania genre.[/p][p][/p][p]We start with an extremely rough sketch[/p][p][/p][p]And throw it into Sickle[/p][p][/p][p]From a design perspective, we expect Pergovania to be an overcorrection. Our current vision for Dandelion Void is more on the open-ended side of the spectrum, whereas Pergovania is highly linear. But we have a lot of questions for which we expect this level to provide insight:[/p][p][/p][p]How compelling are the different tools to use? How can we artistically distinguish a dangerous late game area from a safer early game one? Will players chafe at the enforced progression, or will they enjoy the momentum it gives their gameplay? What are the areas that they would have wanted to explore in more depth?[/p][p][/p][p]The rough sketch realized...[/p][p][/p][p]We can’t tell you the answers to these yet, because we still need to put our colleagues through another test! But we are very optimistic that by using an extreme test case, we will get the data we need to create a final map which satisfies all types of players.[/p][p][/p][p]We hope this dive into our level design iteration philosophy has been interesting! We would love to hear from you all about your favorite survival game levels, and/or the aspects that you most value out of a game map. Until next time, give doubling a try for yourself – it’s twice the fun![/p]