Survivors of a mysterious apocalypse in which an artifact has caused Dreams to intrude on your dimension, you find yourselves in the only inhabitable space left. Get to work developing protections from the Dream Haze, head out into the unknown, and exploit the new resources this apocalypse has brought forth to rebuild a new society, grow strong with fantastical powers, and destroy the source of the intrusions for the good of all.

We've been spending the last few weeks working on Synonauts, and as we approach a point where it's ready to start showing off, we want to just talk about the technical progress we've made, and our experience organising and working on this project in Godot.

To start things off, we should say that we've been using Godot 4.0 beta for Synonauts, for several reasons;

• The new Tilemap updates, particularly Terrains, are game-changing, especially for a procedurally generated game with an emphasis on very different biomes. It has been much more of a pleasure to use the new system than the old Autotiles were, though the biggest difficulty has always been simply finding tilemaps with a complete set of tiles!
• New and improved GDScript, with better support for static typing and resources, and generally nicer syntax across the board.
• In theory, GDExtension, which makes integration of external C libraries (and creation of custom nodes) way easier and better integrated. Whether we use this is yet to be seen, but of particular note, this makes FMOD way easier to integrate and use. We're unlikely to do C coding ourselves for this purpose, but it looks like this new system will result in much better support of external libraries.
• This is going to be a multi-year project if all goes right, so we'd rather start in the new and improved engine now, rather than worry about converting a much bigger project down the line. The improvements that are already in, and planned for, Godot 4 are non-trivial and if we didn't start in Godot 4, we absolutely would be upgrading in the future, when the engine reaches a stable release.

Now, let's get into the details of our workflow and approach to making this game. The biggest revelation in development of Synonauts has been learning to make custom Resources, as prompted by this youtube video. Our inventory system is heavily based on this tutorial, and we then followed the same logic to develop Recipes, which are basically just a list of items for the input, and a list of items for the output. We also wrote up Drop Tables, which were somewhat more complicated, so we'll go into the design here:

Drop Tables contain a list of Drop Table Entries. A Drop Table Entry has reference to an Item, a min and max quantity, and a chance to drop. When prompted for a list of drops, the Drop Table will go through every Drop Table Entry in its list, roll a die, and if the number is below the chance to drop, it will add the item to a drop list, with a random quantity between the min and max. There is also a subtype of Drop Table Entry, called Drop Table Entry Exclusive, which contains a list of Drop Table Entries, and will pick only one of them from the list, using their chance to drop as a weight. We are likely going to extend this slightly, so that a Drop Table Entry can contain a Drop Table itself, allowing an Exclusive Entry to pick between multiple Drop Tables, rather than single items, but right now the thought is giving us a headache.

Aside from a myriad of custom Resources, we've also put together some components that use these resources and their interfaces. We a standardised Collectible Item object that will fall to the ground and display a sprite, and holds a reference to its item type and an item count. Next we made an Item Collector component that detects these Collectible Items in its area, and sends a signal that can be connected to an Inventory, so the Inventory can store the items if there is space. Lastly, we made a simple component that will roll for items on a Drop Table, and spawn the results as Collectible Items, so destroying objects or defeating enemies can actually give you things, when we make them.

So essentially, we have a lot of the basic building blocks that make a game like this work. With very little additional coding, we could simply add a ton of content and have a fairly simple but fully functional crafting game. We could add any number of items, have them drop from enemies and blocks, and then they could be combined in a recipe to produce new things. That right there is progression, already! But there are several more mechanics we want before the game goes live, and a LOT more coming before it's done. Eventually we want automation, we want distant bases, we even want you to set up your own 4G network (not even really joking). But what do we want right now?

• Crafting stations. This isn't that difficult, but we do want to figure out how we will be handling recipe lists. Our current plan is for all recipes to be universal, and each crafting station will just have a list of Recipe resources that it has access to. As the game gets larger, this might get unwieldy, so we may need a better solution, or at least a good interface. Maybe a matrix?
• Health and damage. For this game, this is pretty fundamental, because the world is hostile, even if it's not brutally difficult. We need the player and enemies to be able to take damage, we need to know what happens when their health reaches 0, and just like our previous components we need it to be flexible. Small enemies should die and drop their loot, players should respawn and optionally drop their inventory, bosses should be able to advance their phase or initiate dialogue or who knows what else.
• Object placement. This will be most important for building and placing crafting stations at the start, but building is obviously a bit of a fundamental part of a survival crafting game. Which actually leads us directly on to
• Terrain destruction. We actually want to limit your ability and need to "mine" in this game, making most of the world undiggable until much later in the game, so you instead rely on developing safe routes and methods of transportation. Still, we want you to be able to at least do some degree of landscaping, and a bit of digging for treasure, so we'll need the system in there.

But ultimately, the thing we're going to be working on next is much less impactful, but arguably more important: Visuals. Without an appealing set of visuals as a base, we can't effectively share our progress and get people interested in the game itself. With unappealing visuals, it's that much harder for people to look past them and see the fun of the gameplay, and imagine themselves and their friends taking part. So visuals are necessary for driving interest at this early stage, in the lead up to early access.

We have a lot of assets from various humble bundles, so we're going to go through, pick out a lot of sprites that work well together, and start populating the game with a variety of basic items and objects and recipes. We'll also reserve some sprites to use for some simple basic enemies and crafting stations, so that when we implement those functionally, we can show them off visually too. Lastly, we'll make note of any gaps in our art - If we just can't find anything that works for a flying enemy, or there's nothing that resembles an amulet, then we'll have to just make it ourselves. Maybe we'll finally get good at art.

That's all there is to say about Synonauts right now. Next week, we'll see if we can make a post about CGA Hell, where we left it off, and our plans for where to take it when we come back to it. Keep an eye out for that one, because it'll contain a lot of visual intrigue!