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 #20 - MISSIONS & MISSION PROVIDERS
In-game event

Dev Log #20 - MISSIONS & MISSION PROVIDERS

GODBOX · published 24 Jun 2026, 22:21 UTC

All newsPlayers around this dateRead on Steam

If 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 every once in a while to optimize it once they got enough creation points, and to consider how many creation points they want to use coding, versus how much they want to save towards unlocking their next domain or placing down a blueprint. The second step was introducing the "block access" system in which players can trade with other deities for access to their blocks. In the past couple of weeks, I have been working on the third step of the solution. Missions!

The primary point of missions will be to give player smaller tasks to complete, in order to increase the moment to moment engagement. It's also another way to incentivize the player to adapt their code for specific purposes, and to actively track how well their code is performing with measurable mission requirements.

Rival deities don't just hand the player a list of quests. They generate missions based on what's going on in the world!Every deity has a set of "Mission Providers". These are things like the domains they control, the blueprints they have unlocked, and even the code they've chosen to run in their blueprints. When a deity needs a mission to give out, they ask every provider they own. Each provider hands the deity a mission, and the deity chooses from them.Making domains a provider gives missions a thematic coat. Deities that have unlocked the Harvest domain will give very different missions than one that has unlocked the Hunt domain, for example. Making code itself a mission provider gives missions a strategic edge! If a deity is employing code that makes their mushroom poisonous, it might give the player a mission that asks their Folk to eat a number of mushrooms.


Each provider keeps an ordered list of missions it can offer, working through them in sequence, one at a time. These are like quest lines, with one twist. Certain missions are flagged as repeatable. When a provider has run out of their sequential missions, it shuffles these repeatable missions and gives the deity that option instead.

The most exciting part of this system, to me, is that missions are actually context sensitive! Even (especially) repeatable missions, so that while the mission design is the same, the details of them might be different. Let me explain. Each mission contains a generator method. This is a small piece of logic that takes in the deity giving the mission, the receiver (the player), the history of previous completed missions, and then looks at the current state of the world. With this information, it decides what to include in the new mission. This means the same mission definition can produce completely different results depending on how your playthrough is going! A mission asking you to grow the population of a blueprint you own might target the one you have neglected the most. Another mission might ask the player's help in specifically sabotaging the most powerful rival deity. Imagine the god of death giving you a mission to kill blueprints belonging to the god of fertility, for example.

WHAT IS NEXT?

In a devlog called "The Art of Overscoping" I talked about how GODBOX is not only technically challenging, but also incredibly creatively challenging. I have to come up with ideas for a bunch of different domains, each with unique block unlocks, plants and animals with their own strategic twists, different ways that rival deities score points... Now, I have added to that list mission providers. This means that I also have to design (and code!) missions for every domain and blueprint out there. So, that is next. While I have created the system for missions and the corresponding UI, it's time to actually create these missions. Fingers crossed that all of this work will pay off in the next build. We will find out if these new additions will have been enough to increase the moment to moment fun. The next build will likely also feature a new deity! For more news, keep reading these dev logs. If you'd like to participate in the next playtest, and help me test out this mission system, please join our discord!

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

More from GODBOX

Other announcements

All news
In-game event24 Jul 2026Dev Log #23 - AFFINTY AND BOONS EXPANDEDThe 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 deitie…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 →