Howdy Prospectors! We've been working on TerraTech Worlds for some time now, and many of the games’ systems and features have undergone many - [i]many [/i]- iterations, and that couldn’t be more true than for crafting, conduits and automation. So, before we talk about what’s to come for conduits and automation in TerraTech Worlds, let's talk about how we got here. Please note that this Dev Diary contains quite a few images and design ideas that are work in development/prototype pieces: they may not all make it to the final game! [h2]In the Time of Pull[/h2] Not too long ago, TTW’s crafting was actually a “Pull” crafting system, which - in manufacturing - is a system where the current demand dictates what is produced and when. [img]{STEAM_CLAN_IMAGE}/44238226/8988fa19434b64d3034fbd6fe45462be52247737.png[/img] Back then, crafting was queue-based and when crafting was completed, the item would be placed on an Output queue. The “flow” of items was set by the structures themselves. Each machine had directionality and items would come into a machine from the Start (Green arrow) and output through the Exit (Red arrow). Conduits were bi-directional and would transfer items along depending on the direction set by the machine. When a machine needed an ingredient, it would pull from any available source along the pipeline. [img]{STEAM_CLAN_IMAGE}/44238226/b13468ee76eda9a4305a86b708016bb1cfe69dd0.png[/img] Overall, the system was functional and straightforward, but - ultimately - ephemeral, as it lacked the robustness to respond to how production-heavy the game is intended to be towards the mid to late game. [img]{STEAM_CLAN_IMAGE}/44238226/f85e1586d5fae06d4e02c96b8972722515236d81.png[/img] [h2]From Pull to Push[/h2] Late in 2023, after much back and forth, the team decided to go back to the drawing board on how crafting worked. We’ve always wanted to have different gameplay aspects that appealed to different types of players, and the Pull system, while useful, simply made crafting too flat for the depth we were after. With that (and with much debate!), we started working towards a “Push” crafting system. In manufacturing terms, production in a push system is set by understanding and predicting demand, making it a standard for producing a wider variety of products in mass over a long period of time. This approach appealed to us and our inner industrialists. With this system, crafting goes from a complementary system to one of the games’ core features which focuses on being analytical, strategic and resourceful. In more practical terms, it meant changing machines to have no set direction. Conduits became what defined the “flow” of a pipeline. Items - if the target Input allowed it - were to move down a pipeline indiscriminately, and it was up to the players to set the right flow logic, stopgaps, filters, etc to make sure their pipelines were efficient and operating at capacity. [b]“Move down a pipeline”[/b] Many references are made to things “moving” and/or being “transferred” by Conduits, but to clarify - Conduits don’t move actual “physical” items. Our experience with TerraTech (and games of a similar genre) made us weary of actually going down the “conveyor belt” approach and transporting items - physically - from A to B. As such, a key component of automation in TTW was that there is no physical distribution of items, and something is either in machine A’s inventory or B’s. [h2]Inputs/Outputs & APs, and Conduits[/h2] Changing the game to a Push system had a knock-on effect on many of the games’ systems and features - many of which we’re still tackling today. [h3]Inputs/Outputs & APs[/h3] Now that items were being pushed into machines, we couldn’t use the queuing system. We needed a way to contain and hold the items until the machine was set to use them. [img]{STEAM_CLAN_IMAGE}/44238226/b990c201dafe6630ce99e68ebecb56007c26e244.png[/img] On top of that, we didn’t want an Input (or Output) to be able to receive any overflow from another Input (or Output) slot, as this could lead to items being inadvertently moved around and would - ultimately - invalidate the player’s role. Suffice to say - this was an iterative process, with a lot of back and forth. [img]{STEAM_CLAN_IMAGE}/44238226/738ba5c2f55aa3193a5cb5857306f3fd30b855f4.png[/img] As we iterated on these ideas, we arrived at some key concepts we wanted to explore: [list] [*] These Input/Output “inventories” are not size specific; [*] These special APs are dynamic and can be both Input or Output; [*] The external APs are related to what’s displayed in the machine’s UI; [/list] [img]{STEAM_CLAN_IMAGE}/44238226/d95cc5a5a0bdd6c225ebbba805129c79f851c835.png[/img] We weren’t fully committed to this approach. It had the elements that we wanted, but it was clunky, overcomplicated and unclear. And our concerns were echoed by the community. With that in mind, we kept brainstorming about the best way to marry all the ideas that we wanted to reflect with this design. [img]{STEAM_CLAN_IMAGE}/44238226/d66a13d8bd9f095edc35ac75a96955f7f3db3df7.png[/img] At that point, we moved away from the Left Input & Right Output panels concept in favour of an approach where all slots were neutral. When an ingredient was needed, that slot would - temporarily - be an Input, and inversely so for Outputs. Lastly, when a Conduit was connected in (or out), it would overwrite the slots’ neutrality. This enabled us to bring everything together into a more cohesive, intuitive system. This approach also puts an emphasis on the parity between these slots and the Attachment Points displayed on the mesh, and that these are the set number of slots you can work with. Some recipes might require less ingredients, so more slots can be used as Outputs. Other recipes might require more ingredients, which reduces the amount of Outputs and therefore you’ll have to make some sort of depot to eject items into. [h3]Conduits[/h3] As mentioned before - with a Push crafting system - Conduits were now what set the flow’s direction, and with that we opened the proverbial Pandora’s box that is… “making things explain what they do without having to rely on a lot of words and/or UI”. [img]{STEAM_CLAN_IMAGE}/44238226/3637835e370c485d219e556e393c1b1e1f9a1631.png[/img] To that point, we attempted to integrate as many elements as possible so directionality would be self explanatory, but - it goes without saying - still wasn’t doing the job. So we continued iterating. [img]{STEAM_CLAN_IMAGE}/44238226/a5d4fd6ee03e6eff166ba58c303d2bd77650ddd1.png[/img] As we moved away from the now infamous “Red-to-Green” APs, we started focusing more on more direct signalling with arrows/chevrons. [img]{STEAM_CLAN_IMAGE}/44238226/7adc925a2016b8b55933e66200204d67e7b05eab.png[/img] They felt like a solid way (pun intended) to physically display on the mesh a Conduits’ directionality, while also being somewhat playful. Not to mention the filament-like aesthetic married the concept of Conduits not transferring physician items in them perfectly! [h3]Splitters & Mergers[/h3] Armed with new Conduits, we continued to work on a fan favourite - Splitters and Mergers. Now, we’ve had many iterations of these… from T-Junctions to Conduits with branching-off ends, but we felt that we wanted these to be more… “souped up”. And that led to plenty of iterations: [img]{STEAM_CLAN_IMAGE}/44238226/cd7f1d08c8398aecc31505c63cc393d8a098a6ed.png[/img] We decided to start with 2 types of Splitter/Merger behaviour: Alternating and Priority, both of which have “primitive” behaviours, with the idea of having more configurable versions down the line. Each iteration got us closer to what we wanted. At the same time, we started tackling how we communicate the state of things. With a more conventional approach (e.g. conveyor belt), the player can see whether the flow is interrupted or if the pipeline is not working properly. Since there is nothing physical inside the conduits, the messaging needed to be quick and more like a “debug” feature than anything else, similar to how factory machines inform workers of issues. [img]{STEAM_CLAN_IMAGE}/44238226/a5f29f00fda50e55062ba99bf4aae28442f5d486.png[/img] Full disclosure - we’re very much STILL working on many of these things. We like the direction things are taking, but - bugs and technical issues aside - the communication is still a problem we’re actively iterating on. [h3]What’s to come?[/h3] There’s many issues we’re currently working on revolving around this subject, things like what recipes go on what structure, UI improvements, recipe balancing and whatnot, but - overall - we’re trying to take smaller but more surefooted steps to keep improving the system. As for new stuff, players can expect: [list] [*] Ways to make it easier to lay out and modify conduit paths [*] Ways to make it easier to read how conduits, splitters and mergers are connected, how items flow through them, and identify blockages [*] Make it easier to understand the flow of items and identify blockages [*] Advanced splitter & merger functionality for setting priority and filtering [*] Higher bandwidth conduit transfers [*] Overall quality of life improvements [/list] These are some of the things the team has discussed and are set to be worked on, and we have even more ideas being discussed, but we need to keep some mystique about what we’re developing. We’ll have more to show you soon, so stay tuned for more! And let us know what you think of the current system in the comments below!