There’s a level in Yoshi’s Crafted World that got me thinking about our relationships with tools in #gamedev.

The level has sandy blocks that Yoshi can make crumble in a neat simulated way. This makes enemies on them fall or makes fun Godzilla-feeling block breaking sequences

One person might say “the game was made in Unreal and it allowed the sand simulation, so learning the tool is most important.”

Another would say, “The designer’s creativity allowed them to see this tech and say ‘ah ha, I have an idea for how to use this!’”

A designer should develop both, but it’s foolish to teach the tool over all and just let folks’ natural creativity handle how the tool is interpreted. We can teach and cultivate creativity.

If someone’s sense of design is well-developed, they can make a great work in most any engine. They learn to read the tool’s affordances and design with them rather than be limited by features.

I feel like classes that are “the Unity class” or “the Maya class” severely cripple students because they don’t teach them to think in processes. They teach them to think in features.

This is why when someone says, “I need to use this engine because it lets me paint paths on my 3D terrain or make bendy pipes.” I ask “Are paths and bendy pipes vital to your game experience or do you think you need them because they are part of the tutorial set that you did?”

I’ve also found that this severely hampers workflow. I see folks who mainly do tutorials dive into environment art features right away, and when I say “so you’ve grayboxed everything, right?” They look totally lost. They’re learning features with little thought to sequence.

To fix this, I like to craft project briefs that focus on a creative problem (“make a choose your own adventure that re-interprets a short story”) but which loosely require a specific tool (I say loosely because I’ll listen to pitches alternatives within reason)

So the student gets to sample a tool for a project but not focus on a checklist of features, must making an experience work in whichever way the can. Sometimes this is being clever with features, sometimes this is refactoring their plans to fit the tool.

The point isn’t learning a tool’s features, but gaining experience with several such that they learn to start projects with more of an open mind (“I have an idea, which tool can I make it happen with?”) instead of letting the tool make your game (Open Unreal, make 3D action game)

Back to that Yoshi level, people who can think in this more (I’ll say it) design thinking way can see a feature of something like sand in Unreal and be like “what experience can I make with that” instead of “ooo graphics.” Tools should inspire creativity, not be creativity

One last thing: sometimes I use the phrase “fishing with dynamite” when someone uses a tool that’s TOO BIG for what they want to do. It’s usually when someone wants to use something like Unreal to make a game that could be easily made in Game Maker or Construct.

The danger of using what you’re used to or did tutorials in is that maybe its affordances don’t support the thing you’re trying to do. Maybe that retro game won’t feel retro because the beefy 3D tool will make it hard to go 2D or won’t allow easy access to non-smooth movement

In the 90s, kids argued on the playground over SNES or Sega because ultimately, we were arguing for the way we chose to spend our money and time against the insecurity of not choosing the other cool toy. Game engines are all free to access, so no need to go Console War with them.