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!
I also present a new screenshot:
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.
A medium size conversation.
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.
EDIT – Much of the information pertaining to the game in this post is outdated now. The game has been evolving and its not the same as it was at the time this was written. The vitality bars have been removed. The inventory menu has been redesigned.
I’m a subscriber to the up-and-coming idea that games have potential to invoke a much broader range of emotions than what we’ve been seeing so far. Jenova Chen has pointed this out very eloquently in a number of interviews and talks. One emotion that I’m consciously trying to procure in Eastshade is safety. I think this medium is particularly suited to do this effectively, since in a game, one must overcome danger themselves, rather than sit back and watch events unfold as in a book or movie. In traditional RPGs, I love the feeling of returning to the safety of an inn after surviving a treacherous dungeon.
To effectively create that wonderful feeling of safety, there has to be some danger. While there are no hostile AI in Eastshade, the world itself is as dangerous as it is beautiful. You have to pay attention to your malady, cold, exhaustion and hunger, and as you travel, you’ll deal with “conditions” that the environment will inflict on you. Jumping in water will make you wet for some time, which makes you colder. Walking without boots in rocky tide pools will give you a deep cut, which continues to affect your Malady bar until you bandage it. The tent pictured above, safely perched on a seaside bluff, restores the players exhaustion, and the fire keeps them warm.
Of late, I’ve been working on inventory systems and GUI. On the left is your stuff and on the right are the schematics you’ve acquired (crafting recipes). At the bottom are your vitality bars. The lovely icon art is being made by my girlfriend, Jaclyn. She’s an artist as well. Our avatar is doing pretty good at the moment. On each side of the vitality bars are equipment slots. You won’t be able to equip an acorn (as indicated in the image), because I tried equipping one in real life today and it had little effect. For some reason I thought it would give me resistance to poison. Provided you’ve the schematic and the necessary materials, you’ll be able to create vehicles (a means of travel) and gear (protection from some of the “conditions” the environment will give you). Items will be sprinkled throughout the world, but the schematics will be particularly valuable, and will primarily be acquired by reaching new places. I have a novel idea for the way which rewards are delivered but for moment I don’t want to talk about it until I’ve actually tried implementing it. I will say that whatever this delivery method ends up being, it definitely won’t be a loot chest.
Currently, I’m diligently at work on the dynamic night and day cycle for the game world. Soon I hope to have a video showing, among other things, the ominous celestial eclipses that happen twice a day on this strange planet. Of you who have taken interest in Eastshade since its humble unveiling two weeks ago, I know at least some are eager to see a video! But for now I’ve only this single morsel.
