Working together both can cover each other's backs and build systems that deliver on the concept while staying feasible.
I love talking about the split between design and implementation. If you've got an opinion or want to talk more about this, drop me a DM and lets chat!
It's on the designer to translate outcomes into specific inputs. It's on the engineer to build tools versatile enough to support working outside their intended functionality.
Working together both can cover each other's backs and build systems that deliver on the concept while staying feasible.
Ex-Halo AI Engineering Lead Damian Isla touched on this in a 2009 GDC talk: designers want to be focusing higher outcomes, not basic inputs.
Bridging the designer/engineer divide is about understanding that each may be speaking with different goals in mind.
To him I wasn't using the right tool for the job and he was right.
But having the correct tool wasn't my priority. I didn't care if the edges were rough or warped as long as the end experience resembled what I wanted.
Both aren't wrong but that misalignment causes communication issues. A months back I was testing a new direction by brute forcing systems into a staged result. When my engineer found out, he was confused.
He asked "why are you doing it like this?"
The designer's focus: "what experience do I want this idea to invoke?"
They want to understand how they can create a sandbox that delivers the idea to the player. Less concerned with the individual ingredients, more with what feeling the final dish creates.
The engineer's focus: "what systems are going to make this idea possible?"
They want to understand the details and mechanisms to get the concept functional. What needs to be done.
The initial process of game development is bringing a concept to an initial implementation.
Both the designer and engineer may have an idea about how to handle this, but they tend to focus on different things.
Sometimes it can feel like designers and engineers are speaking different languages, jumping between vision and implementation.
But once you understand they're making two separate decisions, both sides get a clear. 🧵
I played feed the void yesterday and really enjoyed it
barribob.itch.io/feed-the-void
When building tools that span broad systems it can be tempting to create a whole system but creativity and expression live in the details. Its important to keep in mind the tech designer's role is not to author the final gameplay but empower others the flexibility to build a great, unique experience
So instead I eventually landed over a more "building block" focused approach with individual components like spawners, door triggers, gameplay rules, and enemy spawns all working interchangeably to give the designer direct control.
In actual use a designer wants a set of flexible rules they can easily alter or ignore in the same way they'd edit a map layout which a top down manager system could not easily account for.
Building encounters I found is equal parts about the placement and flow of the encounter than what the encounter is actual spawning.
While the data table system was readable and straight forward it was also RIGID.
You can see in the video I was pretty jazzed about this approach but I eventually ran into a problem, not with how the spawning worked but with how I naturally wanted to build encounters.
So I built with that in mind, creating preset spawn tables and a nice data table system where you can easily modify things based on time and player clear
www.youtube.com/watch?v=KRiu...
When I started the project I start with the thought of "what does an end encounter look like". So in my head I pictured something like this:
Every so often a group of enemies will spawn at a location and then go to attack the player
www.youtube.com/watch?v=LHiH...
Over the past year I've been working replicating Halo CE's AI in Unreal Engine building NPC behavior and encounter systems that let you easily build complex gameplay.
I want to talk about why it's important to build tools based how people actual use things versus how you expect to use then 🧵
Check out my games at dyingsungames.com!
We've got:
a doomed world building, boss fight
a chaotic, print-and-play card rpg
a somber, solo journaling monster hunt
Letting players play their own game and have their choice matters is not just about providing options but how those options stack up in relation. Not every choice needs to be "optimal" or top tier but players should feel like they're getting a "good deal" no matter what route the choose
a variation of #3 is the "magic bullet" option where given too options that have the same risk but one just provides more, the one that provides less is an irrelevant choice.
For example the risk of a "glass cannon" power is balanced by it's reward. A choice that gives a random reward is balanced off the potential for that outcome to be an above average payoff for the risk of getting nothing.
This is not to say their should not be unequal risk/reward between choices but if I am taking a minimal or non-existent initial reward for my choice I should expect an eventual payout that equalizes things.
#3 is "too minimal a reward". In contrast to 2, assuming choices have a meaningful advantage/reward, choosing something with too niche a payout causes a feeling of "why even bother".
When players have access to too many choices they can easily swap between, committing feels flippant or suboptimal. When those choice are too similar (in form or outcome), players feel their choice is invalid because it doesn't drive meaningful change in their gameplay experience.
#2 is "no clear differentiation of choice" where the player's choice does not feel impactful. This can come from having too much access to options or does options not having a meaningfully different impact on gameplay.
Gating is basically "planned obsolescence" where the designer has decided your choice is not longer usable. The usual answer to gating is some type of "the same but better" upgrade. Gating shouldn't be confused for "the right tool for the job", being sub-optimal is different to being ineffective.
#1 is "gating". Gating is basically when certain choice becomes irrelevant when used against a higher tier or challenge. This can happen as a gradient where your choices becomes so ineffective to be effectively useless or as an exclusion where the choice is just "not a valid answer".
I want to talk about 3 reasons your game choices in games might not matter🧵
