(re)joining an indie game studio

2023-09-08

Recently I rejoined a game studio I worked at around a year ago for a new project. At the time of this blog I've been here for 2 days and I already feel like I can write a good few posts about my experiences. So here begins my "100 Days To Offload" a blogging challenge where you publish 100 posts in one year (find more here).

This first blog post will be about designing videogames, and the clash between a project lead and a fresh programmer coming onto the project (me!) during a design meeting.
During the meeting I was told of the design philosophy of this project - design mechanics that match an obstacle. An example of this is creating a projectile firing system to destroy targets. While this is a perfectly valid approach to game design, it has several flaws that I will discuss.

Rigid implementation

The core issue of this approach is that you do not inherently plan for flexibility around the mechanics and therefore the gameplay suffers as a response. If each mechanic solves one type of obstacle, it becomes a matching game for the player and they will lose interest in testing the mechanic in other places. Have the mechanic be a perfect solution to one obstacle, but also have it as an (inefficient) solution to other obstacles! Then, the player can decide if they want to carry on using that mechanic because it feels good to them.

Forgettable uses

If every obstacle has a unique mechanic to solve it, there's eventually going to be a point where specific mechanics are only used once and never again. Even if the mechanic is really interesting and well-implemented, if the player only uses it for one short, specific moment then what was the point of including it in the first place? A mechanic should either be applicable to many situations as a generic tool or the scenario that the mechanic applies to should be significant enough to warrant a unique mechanic tied to it.

Stale gameplay

If you focus specifically on "a mechanic must be a solution to an obstacle", then you lose the ability to characterise that mechanic and make it truly unique and special. Take practicing rallies in tennis as an example. At its core, the obstacle is hitting the ball back to the intended target. Therefore, the solution, and mechanic used, is to hit the ball straight. This is one-note and quickly becomes forgettable.
How can we improve this? By adding special shot types! Let the player hit a curving shot, or a lob, or even a hard smash. Sure, it doesn't affect the solution of hitting the target, and yes occasionally it may hinder the player if they curve it by accident, but there's now character to the mechanic. The player can show off, they can create a story in their head of a flashy player who constantly adds curve to the ball, or who will smash it down at whatever chance they get. Or they can play it safe.

Mechanics shouldn't just be a one-note solution to a problem, they should be applicable to several problems across the entire game, or memorable moments that the player won't easily forget.
- tavi

#gamedev