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!

SRG Update #20

This month has been about getting to Done. 

Blocks All the Way Down is Done.

Seeing the true end of a to-do list that has seemed so endless is quite a thing, but so is the way in which new to-dos assert themselves the whole time.

E.g., in spite of there being so much written on it, I still find app store submission extraordinarily baroque. At least, it is from the perspective of the uninitiated. Some requirements are simply tedious, but others are just a tangled mess with no clear answer.

As I’ve worked through it, many parts evaporated into triviality, but others have instead turned into significant research efforts.

That said, everything is winding down at long last. The build is in the store, waiting for 1-2 small changes before I click ‘Submit for Review’.

Coincidentally, I was looking through some of the early journal entries from when I started on this game. In fact, I found the very day I made the core mistake that drove this bus off a cliff.

So I thought I’d share here one of the most important lessons I’ve learned over these years: You should probably be “aggressively un-precious” about your ideas.

The right thing to do on that day would have been to change the core game mechanic and move on with the small scope I wanted then, and ultimately am roughly shipping with now.

As I’ve leaned into my various “game design process” tools, I’ve come to really understand just how fungible game ideas are. It could be argued that maybe I just haven’t found a truly amazing idea, but I’d counter with this: I’ve never even seen a truly amazing game idea, in my own head or in the wild. In the entire history of the industry, I think every game has been marred by the same chaos that, even today, every game idea will be marred by.

That is: a human mind produced it, and human players must play it. It must run on computers, it must be economically feasible to some extent, it must be interfaced with via a handful of very simple HCIs we’ve settled on.

Whatever it is, it’s not worth the delay.

This year could mark the 10th or 20th game I’ve shipped, not the first. Even though I planned when I started on BAWD to keep development time under 100 hours (yes, really), even though I was aware of all the risks that threaten such plans and tried to head them off… It still caught me.

This idea isn’t new, and I had certainly read it myself before making that mistake. As with so many life lessons, it’s hard to internalize someone else’s idea. “My situation is different!” we say without anything truly grounding that claim. So if you’re in a similar situation, I hope you’ll try to ask yourself a little more intently. It could save you multiple years.

Ah well, much has been learned along the way. I just wish I’d learned more of it on code that I ultimately shipped.

The parts of BAWD I cut out to make this release, I may bring back in, gradually. Some of them are fine ideas, and I think add to the fun. I’m already planning on a few content patches over the course of 2020, so maybe some of that code will yet see the light of day.

Realistically? It’s for a different game than what BAWD is now. In the process of violently culling scope, I redefined the game in my head. It already feels a little bit bloated, somehow.

In any case, see you next time for the first proper 25h/”conveyor” installment!