It’s been a while since the last time we did an update about how we make the game content. Today seemed like a good opportunity to delve into it a little bit more.

But first, some general facts about the team (in case you didn’t already know them). There’s five of us working right now on the game and each person is responsible for one specific discipline (code, art, design, writing and audio). The way we built this game was designing a static world and then defining timeframes in which certain elements change. That static world would be the main characters, random NPCs, maps, mechanics, etc. All that has a default state, the way it behaves if nothing new is happening.

Then we have the story events, quests or however you may call them. There’s over a hundred of them. They’re basically lists of changes to apply to the world, from creating a new object to setting a new dialogue/routine for a certain character. So these are the core of the game, which doesn’t mean the rest is easy or fast to produce (quite the opposite).

But how does each of these events get created, produced and implemented?

Since “A Place for the Unwilling” is a narrative-focused game, everything starts with the story. A situation is created, the very-bones, a short “pitch” of what’s happening. Let’s use a quest as an example, one where Myles (our charming troublemaker boy from the poor quarter) wants the player to paint a graffiti in the church. That’d be the pitch.

Then the designer would break that down into steps. When is this taking place? Saturday? No, that day is way too crowded. Maybe we put in on Wednesday, but we need to do this small change so it fits. What’s Myles doing on Wednesday? Does the quest have any time-sensitive elements? What happens while the event isn’t active yet? Then they build the dialogue logic, create a template with a part where the character receives the quest and takes the necessary steps to complete it. During this step, we also list special requirements that will involve other disciplines. Do we need a new icon? A new asset? Do we need to code a special behavior or mechanic?

We tend to use placeholder texts that are short (and usually include silly jokes) to check if logic works. The quest is implemented and we do a very quick test. At this point the quest is already working, it might have bugs, missing text and any kind of art (it’s also probably unbalanced as hell). But it’s working (even if clearly unpolished).

(it’s important to keep all the information well-organized)

And while doing all this, you’ll also come across some flaws in the static world. For example, there are certain characters you can trade with, so you go and talk to them and the trading starts. Easy, right? Well, what happens when they are involved in a certain quest? If you want to trade and they start telling you this long story you don’t want to hear, it’s going to be very annoying. If you are just given two options (trade or ask them how things are going) it’s not very intuitive. So we tried a few things and we ended up creating a new logic system, traders greet you, say some opening (like “You won’t believe what happened to me today”) and then the player is given the choice to learn more about it or just get to trading.

And there’s dozens of silly glitches and flaws that you can spot. NPCs bumping into you and blocking your way, a case where we didn’t think about a certain interaction players would do, etc. Games, and specially open-world ones where time never stops, are filled with these tiny details that take time to figure out and implement. That’s why they take so much time to make. This was just a very short explanation of the workflow we follow when working on quests (which is just a part of the project).

We’ll be back in two weeks with yet a new update. Meanwhile, why don’t you join our Discord? Hang out with the dev team, get updates before anybody else and ask us anything you want about the game.