SRG Update #21

I’m feeling pretty excitebike about that!

Once I get the “we don’t store anything” privacy policy finalized and hosted, I’ll launch, and BAWD will officially be public.

With BAWD 1.0 most of the way out the door, I’ve started working on the next two SRG releases: BAWD Update 1.1, and a new as-yet-unannounced game.

I’ll talk more about the new game in the next update when I’ve got a little more ready to share.

Patchwork

BAWD 1.1 will be my first real patch of a game, and it’s given me the opportunity to think about what a patch should be, in the abstract. As players, we have patches we like and patches we don’t. I wanted to think more about what makes a patch good or bad, from my perspective.

I’ve mapped my thoughts into what I’ll dramatically call “Pillars”.

The 5 Pillars of Patching

The Pillars are rules of thumb I’m using to guide me. It’s easy to fall into a trap and build games that exist to extract profit, so this is one artificial guardrail I’ve built to try to prevent that. Essentially, these are some of the things I think a developer should be doing in order to build an enjoyable game, rather than a simply profitable one.

Games are in many sense about novelty. The Flagship represents a regular effort to bring enjoyable novelty to the game. It may be a new feature, or new content to be explored through existing features, but either way it’s something that isn’t in the game already.

This is likely what defines the release schedule for an update, since it will generally require the most indivisible work out of the pillars. It can also guide the other 4, since it will shine a light on certain parts of your game.

We should always be striving to streamline the play experience. Small QoL changes can breathe life into existing content by removing annoyances and tedium.

Because QoL works tends to focus on longstanding functionality, it will often be quite a bit “louder” than you would expect for what is changed. By sanding your rough edges, you reduce the forces pushing players to leave, too.

Of course every release should aim to fix bugs, but I have a special angle in mind for this pillar: fixing bugs that have been around a long time.

Bugs have a direct effect on player enjoyment, and we should always be aiming to squash bugs for that reason. However, bugs also have a subtler effect on player enjoyment: they impact a player’s sense of developer competency.

A player choosing to spend time with your game is investing their time, attention, and sometimes money, with you. They want to know that their investment is in good hands.

Long-standing bugs erode a player’s perception of your competence, and of your ability to control your own code. Fixing these long-standing bugs, I assert here without real evidence, can reverse that erosion.

Where QoL is about improving player interactions, Polish is about improving the subtler parts of your game, the things that create aesthetic and emotional joy.

These don’t have to be large changes, either. Finding a bit of UI that looks better with a darker drop shadow, changing layouts, adding some life to a particle effect… All qualify, and all gradually improve the experience.

Lastly, perhaps naively, and perhaps contentiously, I think that a part of every patch should be something that clearly, directly comes from player input and/or preference.

Any work of art, once published, shifts from exclusive ownership of the creator to joint ownership with the audience. Because games are complex and nuanced mirrors of internal human workings, they often remain heavily “owned” by the creator. Too much audience influence would produce a mess in almost all circumstances, and I think many developers use that position to argue that audience influence should always be filtered by developer perspective.

This pillar is about recognizing the audience’s ownership by trying to allow a mostly unfiltered voice through, where possible.

There are many ways to approach this, but as an example, imagine a game with a public “known issues” list where players can vote for what they want you to focus on.

Normally such a thing would be used internally as a weighting mechanism added into other ROI estimates, but what if each month your team would either (a) fix or (b) respond with why a fix isn’t coming out, for the top 3 issues in that list?

I think this would give players a sense of agency that doesn’t exist in most games, currently. So that’s what Pillar Five is about.

This isn’t something SRG or BAWD can do just yet, since I have no users nor forum mechanism to speak of. However, I will instead use this pillar as an effort to, y’know, enable the pillar.

—

That’s all for this update!