Dev Log #16 - THE ART OF OVERSCOPING

As a developer, I have seen conventional wisdom swing back and forth between "make small games", and "make big games". This framing of scope as size has never been useful to me. What has helped me in the past as an artist is to think about scope in terms of ambition. The useful question is: what feels just out of reach? What will certainly be very hard to accomplish, and what I might fail at? As an artist, you learn not to be afraid of failure, because (at least at clown college where I learned my art) an ambitious failure is better than an unambitious success. This has led me to many, many failures, but I have seen myself countless times achieve things I did not think were possible. I overcame challenges I thought were beyond me with solutions varying from hacky to elegant, born from the necessity of seeing an "overscoped" project through.

This is the philosophy I use to approach every project I embark on, and it is the philosophy behind GODBOX. Working on GODBOX, I have already surprised myself multiple times with what I'm capable of, and how fast I can learn. I can't limit myself to what I *think* is possible, because I have been wrong about what is possible many times.

That said, I am at least (maybe just) self-aware enough to realize which features are going to be hard. I am now four months into development, and would like to take some time to talk about my progress in overcoming those challenges.

Creating a logic block coding engine is an obviously ambitious task. For one, it is used by the player to create emergent agent behaviour which is certain to be a big source of bugs. The engine's interface is also an incredible UI challenge, since it needs to communicate a lot of information intuitively to the player like which ports are mandatory, what can connect to what, etc. The appeal of a logic block engine is the accessibility of it (versus a game that requires you to learn a coding language), and so nailing the interface is important.

PROGRESS SO FAR:

• - The engine, which I've called "Hiveforge Engine", was the very first thing I started to work on. I could not start working on GODBOX until I knew I could do something like it.

• - It is currently in a good spot! It is stable and mostly bug free (which, of course, is necessary for playing the game at all).

• - It is however, missing lots of quality of life features like the ability to copy and paste blocks.

The great thing about the state of the engine is that those QoL features can now be added incrementally on odd days between bigger tasks. Recent additions include:

• Updated port displays (arrow icons for flow ports, circle icons for data ports).

• Group select, which allows you to move many blocks at once

I am incredibly proud of the Hiveforge Engine. It is a great example of something I surprised myself with. If done well, it has the potential to outlast GODBOX, and be a tool that I can use for other potential coding games in the future.

GODBOX will feature rival deities that compete with the player for divine domains. This was another feature that general wisdom would have me scrape. It's ambitious because it requires me to simulate decision-making agents, including which domains to unlock, and perhaps most demanding of all, coding a way for these AI deities to effectively code its own plants and animals (called "blueprints").

This feature was not in the concept trailer at all, but it separates GODBOX from being simply a simulation game, and makes it a strategy game. More importantly, it creates a more authentic, challenging and exciting simulation of how nature and evolution actually work! In a game where you can code everything but there is no antagonism, you would end up coding your blueprints to over-cooperate. You would code a gazelle to jump into the mouth of a lion, for example. If you're only coding a gazelle, or only coding the lion, you're challenged to optimize your code so that your animal outperforms another animal whose code you don't control. Challenging the player to adapt their code to changes in other animal's codes creates an emergent simulation of the genetic arms race that is evolution -- though admittedly more deliberate. Perhaps it is better described as competitive intelligent design?

PROGRESS SO FAR:

• The theory of how rival deities make decisions is fully designed, and significant coding progress has been made. Fine tuning is still needed.

• When selecting domains, deities prioritize domains that open more future possibilities, and ones that match their personality.

• When it comes to these deities coding their own plants and animals, solution is deliberately "hacky." Rather than coding a true AI that writes code, they choose the code for their blueprints from a pre-written library of behaviour graphs for each blueprint, filtered by which blocks can be used by what blueprint, and which blocks they have unlocked.

This, I think, is a clever enough solution for what GODBOX needs, but it presents its own challenge. Creating this vast library of different behaviour graphs will be take a lot of work. The next step is finding a way to automate generating those graphs to create as many sensible variations as possible.

Making the concept trailer which got me the opportunity to pitch GODBOX in one-bit (black and white) was a practical decision. It removed the need to worry about color, which simplified the work that went into making the art for the trailer considerably. It also looked unique and stood out among the other trailers in the competition. However, it was not something I was married to at the time. I experimented with adding color to the game, and while it is helpful in some ways (like grouping types of blocks and making them easier to find), I have since decided to "commit to the bit". The one-bit.

This creates a big challenge: information communication. A game like GODBOX requires players to make informed decisions, which means a lot of information needs to be immediately readable. Doing that in black and white is genuinely hard.

PROGRESS SO FAR:

• - Some creative solutions are already in place. A main one is a scanner overlay, which is not full screen but something you move around like a magnifying glass that reveals information like soil nutrients locally without flash-bombing the player with white data.

The honest status, however, is that a lot of the challenges with the one-bit art style are probably still undiscovered. The game still uses color in a lot of places, and the I imagine a lot of the challenges will reveal themselves once I begin reworking the art.

In GODBOX, players compete with rival deities on the same shared skill tree. The tree has many nodes representing different divine domains like Knowledge, Harvest, Fire, and so on. Each domain unlocks at least one plant or animal, and at least one unique block for the player. In the current design, with six rival deities, there are 36 total domains. That means AT LEAST 36 total plants and animals (ideally more), and 36 game changing blocks. That is a LOT of plants and animals to design.

With so many blueprints, it is important that each one is interesting and distinct enough on its own. They have to be different and complex enough that when a player unlocks it, they have to take a moment to figure out how to optimize it and fit it into their existing systems. It can't be overlooked! My solution is to design each new blueprint to not only be a new unit type, but also add new layer of complexity to the systems the player is already engaging with, or even allow the player to interface with systems they hadn't even unlocked yet!

PROGRESS SO FAR:

• - I started with two rival deities (Death and Fertility), which are on opposing sides of the player's unlock tree, as well as the domains that branch towards them from the center (player) domain.

• - I already found it challenging to come with blueprints for these, which confirms this is just going to get harder going forward.

The ugly truth is that I did not foresee this being such a big challenge when I started this project, and it is just going to be harder going forward. There is no way to optimize or shortcut this. The labour is purely imagination and game design. What helps is having played a lot of board games, especially asymmetrical ones where different players play by slightly different rules. I suppose a lot of the labour in this kind of imaginative work happens in the background, while you're "ruminating".

(I just had this idea while writing this - what if there was a "ruminate" block that allows herbivores to gain calories by just standing still for a long time as they regurgitate and rechew their food?)

IN CONCLUSION

The mixed bag of significant progress I have made in tasks I thought would be the hardest to accomplish, and the staggering hurdles in the creative design challenges I thought would come easy shows me that I am not that... good at estimating difficulty. That is not necessarily a bad thing! By employing a bias towards choosing ambitious projects I have learned that most of the time I can overcome even the challenges I thought would be hardest. I'm often surprised by how easy some of them turn out to be, but even the challenges that do end up being more challenging than I thought push me to come up with creative solutions. Overcoming these challenges creatively is what makes the work rewarding to me! Thank you for reading this lengthy piece. The goal was to share both an update on how the game is going and the challenges I have been facing, as well as a bit of the philosophy I bring to art. If you're interested in following the development as it happens, having an input on the game, or helping me solve creative problems like designing new blocks and domains, join the discord server: https://discord.gg/8qWrUvqYZa