This is the Greatest Gamedev YouTube Channel

Tim Cain's game development insights are second to none, particularly if you have anything to do with RPG-style mechanics...

My favourite game development YouTube channel is undoubtedly the Fallout co-creator’s CainOnGames. Unlike the majority of gamedev YouTubers, Tim is speaking from decades of real-world experience on hugely popular titles - he's an eloquent, measured communicator who can be passionate and emphatic while admitting his own biases, blindspots and preferences.

Reactivity, player agency (and its consequences), diversity of character creation and grey moral choices all feature heavily. With RPG elements finding their way into most genres these days, Tim's focus on gameplay which allows players to truly play a role of their own invention is generalisable to many different use cases.

There is a wealth of content here encompassing everything from narrative to company dynamics and beyond but I thought I'd focus on 7 design insights because apparently the global infrastructure of the internet is propped up by numbered lists…

1. Players never do what you think

One good place to start with Tim's content is "The Origin of Reactivity" in which he recounts a few stories from his tabletop RPG adventures. Creating systems that account for player creativity and all of the bizarre and inexplicable behaviour that comes with that is a critical skill in modern game design. This is a useful lens for any designer approaching those issues.

2. Setting, Story and Systems in that order

This is a great tip and one which runs counter to a lot of generic gamedev advice: work on your setting first, then story, then systems. This sequence should then be mirrored in your design documentation, usually with the addition of design pillars at the outset to define the overall direction even further.

Context is critical here: this advice is primarily for narrative-heavy RPG's and needs to be applied with care and consideration. However, "story" here encompasses the player's journey through the game and if you take "setting" more broadly and think about it in terms of theme (or as Tim suggests, "elevator pitch"), then you can start to generalise.

The main thrust of this sequencing is to establish a through-line which starts at a conceptual or thematic level and then extends down into individual mechanics.

For Setting, Tim favours starting with something classic and recognisable, then adding a twist to it: one example would be Arcanum's fusion of magic and technology. This sets the stage for a thrilling and provocative landscape of possibilities for players to explore.

Story needs to cover everything that all players of the game should experience: where do they start, where do they end up and how do they get there? It can be as much a "user story" as an in-game narrative. The point - as with setting - is not to bog everybody down in tedious meandering lore but to create something that can be referenced more widely. The story must be something that "players want to do" and often includes an open premise to allow for reactivity.

Finally, you reach Systems. Now you know the tone you want to establish, you can select mechanics which are consonant with it. In your design document, mechanics should have a stated goal or purpose (a point that Tim credits to Josh Sawyer): this can help prevent later arguments which waver between the goal of a mechanic and its execution.

3. Success has many fathers but failure is an orphan

This is a fairly straightforward one that I think most designers in lead roles will recognise! Being the person who has to integrate the entire design together, make trade-offs and take a view on any number of issues comes with a further requirement: taking all of the blame and divesting all of the praise.

4. Heroes aren’t perfect, so give the player flaws

There is an ongoing theme in Tim's content around flaws (ie the opposite of perks) as both a means of balance and as a way of adding mechanical flavour to player characters.

Older RPG's tended to feature character attributes which start in the middle, then give a penalty or bonus depending on the stat's deviation from that baseline. In more recent years, there has been a trend towards only using bonuses and Tim highlights this as an important subtlety which may remove some nuance in character creation.

The entire video on Attribute Design is one of his best in my opinion - if you're working on a game which uses RPG systems then I strongly recommend it.

5. Give XP on completing quests

Similar to the Attribute Design video above, both of these videos on XP are essential viewing. Tim favours giving XP on quest completion, as this allows the player to complete the quest in any way they see fit as well as aligning player goals directly with those of the designer. XP boosts for individual actions or skill usage creates weird incentives - personally, I always think of players constantly jumping everywhere in Oblivion when this topic of conversation comes up.

There's some great details on XP allocation in these videos as well - I particularly like the idea of assigning 80% to main quests and 20% to side content.

6. You can account for player expectations without distorting your design

This is a subtle point that emerges from Tim's discussion of character respec, which is becoming an expected feature in modern RPG's. He has a maxim that any character build should be able to complete a game's main quest and dislikes respec as a "bandaid" for fixing "design bugs" related to this. However, he acknowledges it as a current player expectation and a feature which might allow for greater expression, permitting players to have different experiences without restarting the game and building a new character. So, it can be accommodated but only when incorporated into an intentional design which still maintains its integrity.

7. Fix design problems in four steps

Finally, Tim lays out a clear framework for remedying design issues: Notice, Confirm, Fix and Test. While this might seem trivial to a lot of experienced developers, it's hugely surprising how often design issues send teams into a panic. The use of telemetry in both the Notice and Confirm stages is also something that smaller devs would do well to consider - there are tools and systems out there which aren’t too hard to integrate and can really save on time spent tracking down issues.

The Legacy of Cain

I would love more veteran developers to take their cue from Tim and share their experiences in whatever format they find easiest. CainOnGames has really proved that high-frequency YouTube content (at one point he was doing daily videos!) doesn't have to be trite or annoying, in fact quite the opposite. One thing the games industry sorely needs to do is stop hoarding knowledge, and channels like this are a hugely valuable counterbalance to the inevitable rise of dodgy gamedev influencer mush which is starting to creep into our feeds.