As we’re developing the game, having others playtest is invaluable and essential. We can hypothesize about how the flow of the game will go, but hypothesize is all we can do until someone else has played it. For Eastshade, there is one type of playtest that is particularly important: Not a speed run from myself or Jaclyn (who helps me with writing and design), not a thorough test for bugs or performance hot spots, but a tissue test! (I think kleenex test is the common way of saying it but I like the double T.) A tissue test is where you watch someone who has never played the game before, play without explaining anything or guiding them along. The more unfamiliar they are with your game and the less you speak while they play it, the better. They call it a tissue test because a someone can only be a first-time player once. As creators, we’re unable to see the game from fresh eyes; we know the hooks for every quest; we know where to find every item and we know every nuance of navigating the menus. Only from a tissue test can we can see if the UI is intuitive, or if a certain quest goal isn’t being communicated clearly enough.
Every few months, I’ve been trying to schedule a play test with a one or two folks who are unfamiliar with the game. As I’ve said before, I’m trying to be frugal with the amount of fresh eyes I use up, and I usually get so much feedback from just a few tissue tests that it keeps me busy for a month or more. Just recently, a test session took place (long over due!), and I’m happy to report it went astoundingly well! The content took longer to complete than anticipated, which is a good thing (as long as it wasn’t because something was unintentionally tedious or frustrating). The successful impact of certain quest moments filled my heart as a designer.
Despite these hopeful tidings, we still have mountains of work to do. We found we needed more gameplay “breadcrumbs” all around, to lead the player on the interesting paths. In fact, I’ve found there can never be too many breadcrumbs! As long as the hints are diegetic (in the actual game world rather than in a UI or something) and don’t spell things out too much so as to spoil the player’s sense of discovery, adding more breadcrumbs decreases the chances of the player getting lost or stuck.
In addition to the in-person play tests, I’ve attempted to give the build to some friends to test remotely, and I learned a valuable lesson from this: At this point in development, remote testing is far less fruitful than on-site testing! Without being able to see exactly how certain moments go down, I’m completely in the dark as to how to interpret feedback. In addition, the game has to be really polished for this kind of testing to be of any use at all. Little bugs or unfinished things can be devastating when the player has no idea what went wrong and I can’t be there to set things right with a console cheat.
Some days I look at the work left to do on this game and think “Who am I kidding? I’m in way over my head!” And other days anything seems possible. I find it hard to put a percentage on how complete the game is because of the volatile nature of production. The portion of the game currently being worked on is about a third of the total planned content, and this portion feels close to being done. Once this part is A-Z, the next section of the world will be kind of like Eastshade 2, because we can use the experience gained so far to go back to the drawing board with designing new content. So, onward we go!
In an altogether unfocused effort to share my development progress, I present… Dev Lapse 2! This one doesn’t document my culinary expertise, however, in this 10 minute production, I share part of my process for making a virtual building!
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. 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.
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…
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.
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?
I am now one year into the development of Eastshade, and something very important has happened. For the past three months, I’ve been focused on a small section of the game, determined to bring that one area up to a quality that is representative of what the final game might be like. In the games industry this is known as a vertical slice. Though the slice I have is not yet fully worthy of the name, within the last month, it has reached an important milestone nonetheless…
I now have a roughly playable piece of Eastshade.
Three months ago, Eastshade was a muddle of tech demos and disjointed systems. Many indie games are playable after the first two days of development. It seems mostly unanimous amongst game designers that the sooner one can produce a playable prototype the better, and I’m certainly past due on this. I could attribute my tardiness on this to the nature of the game I’m making, but my greenness as a game designer is more likely the culprit. As I’m careful to use wisely my stock of truly fresh eyes, only a few friends and collaborators have actually played through the slice, but from these few play tests, there is a general consensus that the game doesn’t suck! It came as a total surprise to me. My spirits are high and things are going well.
Because of how focused I’ve been, I feel I’ve targeted the essence of what I want Eastshade to be, and as a result the game has gone through massive mechanical changes. The addition of NPCs is a notable change. I’m currently working on an AI system for making the people of the world go about their daily business.
In addition to the in-person play tests, I’ve attempted to give the build to some friends to test remotely, and I learned a valuable lesson from this: At this point in development, remote testing is far less fruitful than on-site testing! Without being able to see exactly how certain moments go down, I’m completely in the dark as to how to interpret feedback. In addition, the game has to be really polished for this kind of testing to be of any use at all. Little bugs or unfinished things can be devastating when the player has no idea what went wrong and I can’t be there to set things right with a console cheat.
