If you've kept up with these Dev Logs, you'll know the Tartarus build revealed some issues with moment to moment gameplay.
In this update2
Full notes
Full GODBOX update
Read the full published notes in a cleaner layout. The original post stays linked below.
What changed
0 fixes3 additions0 changes0 removals
Gameplay
UI and audio
addedIf 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! Steam post image
addedThe 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.
addedWHAT 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!
GODBOX changes
addedIf 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! Steam post image
addedThe 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.
addedIn 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!
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! Steam post image
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. Steam post image
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.
Steam post imageEach 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. Steam post image
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!
