Crafting Conversations

Crafting Conversations

There was once a time where I was unsure of whether Eastshade would feature non-player characters. My initial plan was to make the game as if there weren’t going to be, and then add them if I had time/money left over. After much head scratching, I started to feel like the design challenges of creating intrigue without characters loomed larger than the technical challenges of implementing these characters. I think we are inherently interested in our fellow humans, and while there is charm in desolate worlds such as Myst, I’m more excited by the prospect of an inhabited world. I can only prescribe narrative excuses for scattered notes and recorded messages so many times before the tactic wears thin.

At this point in development, characters are a pillar of Eastshade’s world design, and many points of interest in the world rely on them. I’m trying my hardest to make them feel like inhabitants, rather than info booths or quest pickup points. In my efforts, I’ve created a scheduling system so that they can be programmed to go about their daily business, and have conversations with one another as well as with the player.

The dialogue interface. NPC model is WIP.

The dialogue interface. The character model is a work in progress.

With NPCs now a massive part of the game, there came the need for an elegant way to wire up conversations. I could immediately sense that scripting every conversation in C# would not do, so began my journey to find a solution. The first thing I tried was Unity’s Asset Store, as there are a number of dialogue suites for sale there. I’d settled on one for a while. The tool had some quirks that made things more difficult than they needed to be, but at the time I felt creating my own tool would be a net loss time-wise. After about 10 conversations, I grew to loathe the task. Because of how much I dreaded doing it, I found myself avoiding the creation of new conversations, opting to focus on anything else I could conjure up an excuse for. When I came to realize this, I made the decision to roll my own solution. I decided that even if it turned out to be a net time loss, net joy is also something worth considering in production.

I initially tried to make a sort of conversation markup language, where I defined each conversation stage with an ID and tags for the data. I opted to make something very specific for my needs rather than using XML. I’d write these text files, and I had a parsing function in C# that read all the strings from these text files and stored the data in a serializable class to be saved in the Unity prefab. Clearly this was an ingenious idea. Except that it wasn’t. Authoring these text files turned out to be even more nightmarish than the asset store tool I’d been using. It was impossible to keep a mental image of which choice went to which stage of the conversion.

convo-markup

The markup language. Perhaps “string data format” is a more suitable name for it.

So my first attempt turned out to be a failure, but not all was lost. I’d written a GUI Manager and data structure that worked very well, I just needed a different way to author the data. I now knew that I would need to take the more conventional route of a visual node based editor to wire up my conversations. I’d already lost days on my first failure, and was rabid to kick the problem in the face with vengeance. I thought hard about how I’d go about it. Writing a unity editor extension seemed sensible, but after some research, it seemed zooming (ABSOLUTE NECESSITY FOR A NODE EDITOR) was going to be tricky to implement. I contemplated writing a standalone app, but as a fairly green programmer, I’m not terribly familiar with any GUI libraries other than Unity’s. Then I had a crazy idea…

fake-convo

This is a fake conversation to demonstrate how the system works.

Of all the GUI libraries I’ve used, Unity’s new run-time UI (UnityEngine.UI) is the one I understand the best. With that one, I knew I could crank out a node editor with flying colors. I could even build the project as a game itself, and have myself a standalone app to work in. I would author my conversations in this game/app/tool monstrosity, and it would save out these text files in the markup I’d created. With my conversation assets being human readable text files, I could open them to make quick edits that didn’t require seeing the whole node tree. I could run any search and replace functions a text editor has at its disposal. So this turned out to be the winning solution.

With the conversation crafter “game” being a portable standalone app, as well as highly specialized for Eastshade’s needs, an understanding of unity scripting is no longer needed to implement conversations into the game. This has enabled my partner, Jaclyn, who is creative and like-minded, but isn’t a programmer, to contribute weird and interesting characters to the world! All in all, this detour took a week or so, which isn’t substantial considering how much more palatable this aspect of development is now. I no longer have the trepidation when I need a new conversation, and that has been well-worth the price.

big-convo

A medium size conversation.

Without Combat, What Do You Do?

The title of this post is a ridiculous question to me. At the very least it should be a ridiculous question to any game designer, but I also think it should be a ridiculous question to any gamer. It appears the latter is not the case, because its a question I’ve gotten more than a few times when I try to describe what this game is to people. I suppose it makes sense, because games wherein you control a single avatar tend to be about killing enemies in one way or another, and people may not have considered how very specific that paradigm is.

I’m not saying there isn’t innovation left to be done inside that box, or that I think people should stop making these kinds of games. Combat is human, and its an engaging subject to make games about. But there are other aspects to humanity that we can explore through games. I have nothing against dude-killing games, but I do think its odd how many game designers seem to only think inside of that particular box. There are certainly many genres that typically don’t involve combat, but when I describe Eastshade as a single-player, first-person, open-world game, people usually think Role Playing Game. And everyone knows that the particular role you play in a Role Playing Game is the role of a hero. And everyone knows that heroes live primarily in worlds where 90% of the population are wandering bandits waiting to be killed.

So the question “If there is no combat how will the game be interesting?” makes the same amount of sense to me inverted: “If all you do is kill dudes how will the game be interesting?” To a person who’s played mountains of games wherein you spend most of your time killing dudes, the latter seems like a ridiculous question. When you strip away the weird box thinking part about dude-killing, the question becomes “What will make the game interesting?” which is basically asking “Will the game be good?”.

So will Eastshade be any good? The game has changed a lot from what I initially set out to make. There used to be survival mechanics, which gave people something to grab onto when trying to understand what the game is (courtesy of Minecraft). Those mechanics are gone now. So what’s left? If I said its like a first-person, open-world adventure game it wouldn’t be totally off the mark. But the state of a traditional adventure game’s world is completely dependent on the player’s state through the game. The guard won’t move from the door until you do some absurd chain of lock and key puzzles to make it happen. Eastshade goes on without you, and the feedback from the world is more systemic, predictable, and granular.

What if I put it to you like this: Eastshade is not a game that you play, but rather a place that you go. There are daily solar and lunar eclipses, the conifers are purple, much of the architecture is spherical, and the people look like monkeys. Stuff happens. Do you want to visit?