It is Basil writing again, and today i am going to discuss our gameplay philosophy of regarding almost anything in the game as an interactive object and especially, looking at a subset of it as collectable and buildable objects.
On Castle Come
Everything buildable, everything damageable
From early stages of the game on (paper prototypes even, I remember laying them out on our living room table), a core part of the game experience was about packing as many objects as you could onto your mecha. In the beginning, this idea was only applied to objects being deemed a "component" which included items like weapons. This already opened up lots of player freedom of where to attach those items and questioning which to take along in the first place, as space on the fortress is limited of course.
Still, this reduced approach somehow felt like there could be more consistency to it, as if it was not fully thought out and the final consequences in the design were lacking. This finally changed when we needed some footage for the trailer of the player assembling the mecha and drag and dropping in crew members.
Since the start of the project we, internally, regarded crew members as "buildable" items, as they, in broad terms, behaved similarly to other attachable, non human objects. They could be assigned ontop of components (or jump onto them, for quality of life) in the same way players would build items on the mecha. Looking at this behaviour for the crew, we realized that it introduced an entire framework on how to think about interactions between the player and their mecha.
Reexamining the approach
The longer we thought about it, the clearer the picture became: what if we would investigate every gameplay action between player and mecha in the form of "building" and components? What if we approached the specialisation, updating, repairing, protecting, customising and late run branching as an action done through packing objects onto the walking castle?
It seemed to us like an interesting avenue, to fully lean into this almost "LEGO" like approach of stacking your player character together.
Want to repair something?
Hit the broken component with a according kit!
Want your a different shield around the core?
Just replace it with something you found, two clicks.
Want to change the main energy source, holiest of the cores itself?
Sure, just drag and drop a new one in to the center of your castle.
Treating those objects in this manner also meant that they would hold separate instances of the same properties, e.g. single items now would bear a unique health value and could now take separate damage instead of a single global system handling health for the entire mecha.
This "federalisation" also opened up a variety of other gameplay options, like repairing individual mecha components, role assignment to crew members with drag and drop items, enemies targeting single components (e.g. the hooking type enemy, which fires a harpoon like projectile and pulls off parts of your castle, without damaging the objects) or the ability to take random rock pieces and debris with you on the mecha.
Comment Sam:
When the game started out we used a unified health source and each component you added expanded that pool.
Initially once a health bar got depleted a random (not the last you added) weapon or part got detached and destroyed.
While being a really arcady mechanic it disconnect the mecha physically from the actions in game and you didn’t understood why you are loosing weapons.It’s a rather complex problem of where are you displaying information and moving most info onto the mecha, (by giving each weapon it’s own health bar) and only have the player’s eyes jump from themselves to the enemies and potential dangers, instead of searching around on the screen to find essential gameplay information is just better :)
Further systems as a consequence
To streamline and amplify those separate properties we also introduced a variety of other subsystems, like our Destructable State Handling; every object would now exist in 3 states, which are communicated to the player: Alive, Broken and Gone
Taking too much damage or repairing would let items transition between those states and display different abilities or incapabilities depending on the current state. For example, Alive weaponry can be used by the player. If it breaks, it can stay attached to the walking fortress, but is not part of the active items pool anymore – for this it would need repairing. If it takes even more damage, it will switch to being Gone, a state from where there is no return anymore.
Overall, we are very happy with the decision to further work in the direction of "everything buildable" and separating as many properties as we could.
It creates a richer, more interactive game experience which asks of the player to truly develop agency within the systems and world we are creating in Castle Come.
It also creates the baseline circumstances for arising complexity, a gameplay philosophy we have been chasing with our project since the beginning.
Until next time
Basil
