Status
SteamPeaks
ChartsSalesUpcomingPatchesNewsCalculator
New on SteamEvery app, DLC and depot the minute Steam creates itAppsEvery app on Steam, newest change firstPackagesSubs and bundles, and what each containsDepotsDepots, manifests and install sizesTagsSteam's user tags and the games under themDevelopers & publishersCompanies and their cataloguesTechnologiesEngines, SDKs and anti-cheat found in the filesChange historyEvery PICS changelist as it lands
SignalsNineteen readings of the whole catalogueCompareAny games side by sideRecordsAll-time peaks and the days they were setReportsWeekly and monthly write-upsAlerts & newsroomWatch a game, get told when it movesSteam statusIs Steam up, right nowWeb API explorerTry the endpoints in the browser
NewsSteam's own announcements and the sales calendarCalculatorWhat a Steam account is worth, and its pile of shame
/
Sign in
/
SteamPeaks
The ultimate resource for Steam data.
ExploreChartsSalesSales and festsUpcomingPatchesNewsRecordsTrendingSignals
DatabaseAppsPackagesDepotsTagsDevelopersTechnologiesChange history
ToolsCalculatorCompareSearchAlertsSteam statusAPI
SiteMethodologyFAQDiscordSupportSign in via Steam
Not affiliated with Valve or Steam. Game names and artwork belong to their owners. All times UTC.
PrivacyCookiesFair useStatus
GODBOXNewsDev Log #23 - AFFINTY AND BOONS EXPANDED
In-game event

Dev Log #23 - AFFINTY AND BOONS EXPANDED

GODBOX · published 24 Jul 2026, 20:02 UTC

All newsPlayers around this dateRead on Steam

The Affinity system was created as a way to solve an issue found with early GODBOX playtests. After spending some time optimizing their unit's code, players would often sit and watch the simulation run at five-time speed. There was not enough moment-to-moment gameplay, and players didn't feel incentivized to adapt their code. As a part of the solution, I introduced a system wherein rival deities would offer the player missions to complete. In exchange, the player would receive Affinity with that deity.

Affinity can be traded to momentarily gain access to the blocks owned by these rival deities, which in turn incentivizes players to revisit and further optimize their code. This can also be a strategic decision, since the rival deities will be unable to use these blocks while the player has access to them.

In the past, I was hesitant to put powerful blocks further away from the player's starting domain, and closer to rival deities domains. Those domains would be more likely to be taken by an AI deity, stopping the player from ever playing with those fun powerful blocks. Now with the mission / Affinity system in place, not only am I free to put powerful blocks near those rival deities, I have a good reason to do so. The stronger these blocks are, the more players will be incentivized to try to gain access to them, and to keep their rivals from using them.

To recap - players now have two ways of unlocking a block:

  1. They can unlock the domain the block belongs to, which is ideal. These will likely be the domain near their starting domain, but with some strategy and luck, possibly further out ones too.

  2. They can temporarily borrow the block by spending Affinity, which they gain by completing missions for rival deities

Each domain in the domains tree can potentially unlock a blueprint, a block, and a boon. Boons are non-codable objects that provide an advantage. Examples of existing boons are the shrine which Folk can pray at to give the player creation points, and the cairn which can act as a waypoint for directing agent movement.

I had always planned to include other boons in the game, but like blocks, felt unsure about making them too powerful while locking out the player's ability to access them. With the Affinity system in place, that issue too is gone. I am able to give rival deities powerful boons which players want to unlock, and that will act as incentive to complete missions that guide gameplay.

There is a slight difference to how boons work, since they are semi-permanent, placeable objects. Access to boons is not leased like access to blocks is. Players don't gain access to boons by spending Affinity, instead they unlock them by hoarding and maintaining high Affinity. Each boon has its own Affinity threshold, and once the player reaches that level of Affinity with the deity that owns the boon, they are able to purchase and place it.

If you've been following along with the dev logs, you will know I've kept the scope of the early development to only two deities: the gods of death and fertility. While I plan to have six total rival deities in Godbox, I would love to nail the gameplay loop with these two first. So I have given the death and fertility domains a powerful boon each to incentivize future playtesters to complete the missions and engage with the Affinity system.

The volcano is a sizable intractable boon. It grows in power passively over time. Once it has reached enough "volcanic power", the owning deity (the deity that placed it) can trigger an eruption! This causes flaming rocks to fall from the sky, dealing damage and spreading fires.

This powerful ability will be useful in clearing out rival deity blueprints (like Oshunik's perky dandelions, which spread viciously). It also scatters rocks around the world, which in the future will be used for crafting. Volcanos are also a prayer vector! Placing a shrine next to a volcano redirects Folk prayer away from creation points and into powering up the volcano faster.

The spring is much smaller in comparison. It creates a pool of water around itself, and any water tiles connected to that pool will infuse the soil with nutrients! This will mean the otherwise barren world will now have small pockets of fertile ground.

This interaction happens automatically, but the spring is also a prayer vector. Placing a shrine next to a spring will redirect its prayers towards it, increasing the amount of nutrients flowing out and how far the nutrient infusion reaches.

Both the spring and the volcano could potentially gain more abilities in the future. As more systems are introduced, like temperature and hydration, existing boons gain potential points of interaction.

In some ways, these boons go against my initial intentions for GODBOX. Programming using logic blocks is supposed to be core to GODBOX. There are certain philosophies I want to implement as I add more of these boons to the game that I hope will keep the game grounded as primarily a coding game.

The effectiveness of these boons are directly tied to prayer, and therefore tied to how optimally you code your Folk to pray, keep themselves alive and maintain the area around the shrine. Unlocking these boons will also require that players come up with coding solutions for the missions provided by the AI rival deities.

Thank you, as always, to those who keep up with the dev log. If you're excited to trigger a volcano explosion, please sign up to playtest in our discord server:

Join our Discord → https://discord.gg/8qWrUvqYZa

More from GODBOX

Other announcements

All news
In-game event17 Jul 2026Dev Log #22 - HOW MANY FOLK DOES IT TAKE TO BREAK GODBOX?HOW MANY FOLK DOES IT TAKE TO BREAK THE GODBOX MOVEMENT SYSTEM? This week I took some time to fix the previously very buggy movement system! Check out this short showing me stress testing the new and improved system. (Apologies. Steam doesn't let me insert youtube shorts. Grrr) Devlog Short -> Join our Discord →In-game event10 Jul 2026Dev Log #21 - BLUEPRINT VARIANTS AND ANIMATIONJoin our Discord →In-game event24 Jun 2026Dev Log #20 - MISSIONS & MISSION PROVIDERSIf you've kept up with these Dev Logs, you'll know the Tartarus build revealed some issues with moment to moment gameplay. Players would simply spend a good while optimizing their code, and then sitting back watching the simulation run in five time speed for the rest of the playtest. The first step in rectifying this was adding a cost to blocks, meaning that players would have to revisit code e…