There is a stage in life when the things you were obsessed with as a teenager are expected to become pleasant anecdotes. You mention them over dinner, everyone smiles, somebody says it is charming that you once spent entire evenings trying to make a computer do something it clearly had no intention of doing, and then the conversation moves on to mortgages, pensions, blood pressure and whichever household appliance has recently become financially important. We made a reasonable attempt at this transition. The obsession itself was less cooperative.
Bad Omen Bureau is a small independent game studio started by people who first tried making games in the 1980s. The Commodore 64 was among the machines we learned on, and at the time it felt wonderfully close to the metal. You could still persuade yourself that if you read enough manuals, copied enough code from magazines and spent enough evenings changing things to see what broke, the whole machine might eventually surrender its secrets. We made little games, experiments and half-finished ideas, often with ambitions that bore only a distant administrative relationship to the amount of memory available.
There were no game engines in the sense we would use the term today, and certainly no asset stores or searchable libraries of tutorials explaining the problem you had just invented for yourself. Information arrived through manuals, magazines, friends, fragments of code and patient trial and error. This was occasionally frustrating, frequently inefficient and, looking back, an excellent way to learn that computers are very literal colleagues: they will do precisely what you asked, including when what you asked was idiotic.
From cassette tapes to proper PCs
The machines improved and we moved with them. The Commodore years gave way to PCs, then 386s, 486s and Pentiums, each new generation making yesterday's impossible idea look almost embarrassingly manageable. Games changed at the same time. They became bigger, stranger and more convincing, and we kept playing them, tinkering with things and arguing about why some worked so much better than others.
Long before we had tidy phrases such as combat feel, systemic design or replayability, we cared about the underlying questions. Why did one attack feel satisfying while another somehow felt like completing a small tax return? Why could you remember the geography of one game years later while another dissolved the moment you closed it? Why did certain systems produce stories almost by accident, while other games worked very hard to tell you that something exciting was happening?
Then life performed the traditional manoeuvre and we became employable. Careers arrived gradually, along with clients, deadlines, companies, projects, management and the discovery that a surprising amount of adult professional life consists of arranging conversations in which everyone agrees to arrange another conversation. Games never disappeared, but making one properly kept moving into the very well organised category marked "later".
The problem with later
For a long time that seemed perfectly reasonable. We had real work to do and making games was something we had once done for fun, something we still talked about and occasionally returned to in small experiments. Every few years somebody would say that we should make a game properly one day, everyone would agree, and the entire project would be completed at remarkably low cost because none of us actually started it.
The difficulty is that a genuine obsession is extremely bad at taking hints. Technology changed, careers changed and decades passed, but the idea survived all of them. By the time you are broadly in your fifties, "one day" begins to sound less like a plan and more like a clerical error. You also know enough by then to understand that starting an independent game studio is difficult, uncertain and quite capable of consuming every spare hour placed within reach. Curiously, this information was less discouraging than one might expect.
We had reached the useful age at which we understood exactly how unreasonable the idea was and had become old enough to find that a poor argument against doing it.
Experience changes the calculation. We have spent years learning how projects expand when nobody is watching, how quickly enthusiasm can disguise bad scope, and how much easier it is to start something than to finish it. None of that makes game development easy, but it does make us much less interested in pretending difficulty is the same thing as ambition. If we were finally going to do this, the aim had to be to make something distinctive and finish it.
Why Bad Omen Bureau?
The name grew out of a fictional organisation we imagined existing somewhere behind the scenes of a particularly unfortunate universe. It is not the department that prevents disasters; that would imply authority, funding and an alarming degree of competence. The Bureau documents them professionally. Curses receive reference numbers, unexplained manifestations are passed to the appropriate desk, and if a village has vanished overnight somebody will eventually establish whether the correct disappearance procedure was followed.
That joke turned out to be a useful description of the tone we like. We enjoy dark worlds without wanting them to be relentlessly miserable, absurd situations presented seriously enough that nobody has to point at the joke, and stories that leave enough unsaid for players to notice things themselves. The Bureau can calmly record that everything is proceeding according to procedure while the procedure itself has clearly ceased to have any practical relationship with events.
It also keeps us honest about what the studio actually is. Bad Omen Bureau is not an ARG pretending to be a government department. It is a small game studio with a suspiciously official name, making games about situations that have generally deteriorated before the player arrives.
Case File 001
Our first game is Until the Bells Stop, a dark-fantasy survival roguelite set during one increasingly inconvenient night in Blackwood Parish. A church bell keeps ringing, there are nine bells in a run, and each one changes the world rather than merely advancing a clock. New threats enter, routes change, places open or become corrupted, the night becomes stranger and eventually the parish begins to behave as though normal geography was only ever a provisional arrangement.
You begin as the Gravedigger with a shovel and a small number of deliberate actions. The combat is manual: you aim, swing, dodge, choose when to spend stamina on a heavy attack and decide when to use your special. Around those actions the build grows, so a simple shovel swing can eventually feed bone effects, knockback chains, grave interactions, shockwaves and other consequences that would cause a responsible groundskeeper to request immediate reassignment.
We use a simple shorthand for the character's progression. Early in the run the feeling should be, "I have a shovel." Later, after the player has assembled a build and the screen has begun producing consequences wildly disproportionate to the original gardening equipment, the feeling should be closer to, "I built a catastrophe." The important word is built. The player should understand how the disaster happened and feel responsible for making it work.
Why now?
Modern tools are obviously part of the answer. A very small team can attempt things today that would have required a much larger operation when we first started messing around with computers. Engines, digital distribution and production tools have changed the scale of what is possible, although they have not yet developed a reliable button labelled "make this good", which feels like an oversight.
The larger answer is simply that we never stopped wanting to make games. After several decades, continuing to postpone it began to look more ridiculous than attempting it. We have done enough other work to know that nothing worthwhile arrives without deadlines, compromises and occasional evenings spent wondering why something that worked yesterday has developed principles. That is manageable. Regretting that we never tried would be less so.
Somewhere between the Commodore 64 and now, nearly everything about game development changed. The part that mattered to us did not: make something, put it in front of another person, watch them understand it, then discover the interesting things they do that you did not predict. We took a rather elaborate route back to that point, but Bad Omen Bureau is operational now. The paperwork has been filed, which is comforting, although experience suggests it will have very little effect on what happens next.