Optimisers, Wanderers and Spark-callers, It's November and it's getting dark, but we have our little pumpkin lights still on! At the end of each month, we set aside a day for everyone to work on their pet projects, learn new things, and try something out. For October, our 3d Artist, Anastasia, whipped up a spooky scene with our art assets for[url=https://linkin.bio/massiveminiteam] social media[/url]. Please enjoy! [img]https://clan.cloudflare.steamstatic.com/images//44489382/a46050faf3d2c6c09ff496d50e6fc9bc037df5bb.gif[/img] Let's talk more about the project and show you something we've been working on. We asked you what you wanted to see and the poll in our [url=https://discord.gg/crk387N2E8]Discord [/url]showed the next devlog should be about [b]Throwing Sparks at Workstations[/b]! So today, we have one of our programmers, [b]Lukas[/b], to get technical about the feature! [h3]Throwing Sparks![/h3] The concept of throwing Sparks has been around since the earliest stages of Oddsparks’ development. From the very beginning our Creative Director, Michael, wanted to create a game with a throwing mechanic. Now it’s a core feature of what ended up as Oddsparks, adding an exciting dynamic to gameplay. [h3]What can you throw around? [/h3] As we were exploring different game concepts, we discussed the potential of throwing Sparks and how it could be integrated into various tasks such as harvesting, fighting, collecting resources and assigning Sparks to paths. It only made sense to extend this throwing mechanic to workstations as well: simply throw a Spark onto a workstation to assign it. Similarly, you can call the Spark back from the workstation, just as you would from a path or any other task. However, it's important to note that this wasn't always the case. [h3]How it used to be[/h3] Looking back, it's fascinating to see how our ideas evolved over time. Initially, we had separate interaction systems for different tasks. Minions (the placeholder name we used for Sparks) couldn't be thrown onto paths; they had to be assigned through a user interface. [previewyoutube=fk2aXhdVr-E;full][/previewyoutube] Similarly, Sparks couldn't be thrown directly at workstations; they required assignment through a UI as well. The only tasks that initially supported throwing were harvesting and fighting. Through numerous iterations and playtesting, we were able to streamline the Spark interaction system to its current state, where throwing and recalling them is possible in almost any context. [img]https://clan.cloudflare.steamstatic.com/images//44489382/bd46dcef76f315f2e900d4cf4aead4f08b37ed37.png[/img] [i]We wanted players to have visibility into workstations, allowing them to see how many slots are still available and which slots are occupied. [/i] [h3]The secret life of a working Spark [/h3] From a technical standpoint, throwing the creatures to workstations was a unique challenge. The Sparks placed in workstations are no longer considered active Sparks. Normally, they follow the player character and perform various tasks based on their AI state—fighting, harvesting, following, and so on. However, when a Spark is thrown onto a workstation, it is removed from the game and added to the workstation's Spark inventory, effectively becoming an item. [img]https://clan.cloudflare.steamstatic.com/images//44489382/fe0939745963bc663feba09835d36acec78c6f8c.png[/img] Each workstation has its own inventory, responsible for calculating the production speed of the machine. The Sparks you see working at workstations are visual representations of this inventory and do not possess any AI behavior or belong to any player. [img]https://clan.cloudflare.steamstatic.com/images//44489382/5679e8d9416fd2f64e3a622688506abc45406548.gif[/img] [i]Throwing sparks at a workstation triggers a satisfying wobble animation, while a failed attempt to add a Spark results in a subtle deny-shake animation. This is the exact moment when a Spark becomes an item and no longer belongs to you[/i]. Calling back a Spark from a workstation differs from calling it back from a path or during a fight. In general gameplay, a Spark transitions from its current state to a follow state when called back—for example, from a fighting state to a follow state. Workstations operate differently. When a Spark is called back, we remove the item from the workstation and spawn a fresh Spark next to the workstation. This newly spawned Spark is then assigned to the player and set to the follow state. [h3]Other features this month! [/h3] We’ve also worked on a lot more things. Here’s a few topics that we’re thinking about for Devlog #3. Comment with what you’d like to know more about! [olist] [*] Playing together is great! But what if you don’t want to play with a certain friend for now? We’re making a feature to[b] prevent a friend from joining your game[/b]! [*] We did a big[b] Recipes Rebalancing[/b]! We can talk a bit about what we want from our recipes and why we did it. [*] We've crammed lots of information in the game into one convenient [b]Glossary[/b]! [*] We’ve had them for a while, but we can also talk about our [b]Spark Sounds[/b] and how we make them. [*] And we’d also love to talk about [b]Enemy Animations[/b], we’ll give you a peek behind the curtain to see how the Beelephant moves! [/olist] [i]Oddsparks: An Automation Adventure[/i] is of course, still being made, and some of these features might not make it into the game. If you’d like to know some more behind the scenes, hang out with us on [url=https://discord.gg/crk387N2E8]Discord[/url], and make sure to wishlist and share us with your friends!