Turncoat Dev Diary: Experiments in Environment Creation

(This is part of a series. The first post in the series is here.)

Today, I'm going to talk about a little side quest I took while prototyping the game: painting and lighting one of the rooms. When I initially planned the level out in Blender, I did it almost entirely with cubes. I scaled and extruded and adjusted vertices, of course, but when you come down to it, it really was just a bunch of boxes. Of course, a lot of buildings in real life are just assemblages of boxes if you look at them from far enough away, but to try and make an environment that feels real, I knew I needed more than just boxes.

I selected one of the smaller room to paint up - a sort of locker / shower room part of the intake processing area. I chose it because it's small and because I should be able to texture it quickly using readily available stock textures. While the game is going to be set in the future, I want to base the look of it on the real world, so I started looking for reference images as well as tileable images suited to how I was picturing this room in my head. It's funny the kind of little details you don't really notice until you try to recreate something, though. In most cases, for example, doors just don't look right without some kind of molding or frame. It took me surprisingly long to figure out what it was about the doors in my prototype that bothered me. Just cutting a hole in a wall is perfectly functional, but it doesn't feel right because in the real world, doors almost always have a visible frame around them.

Another thing I noticed is that when you start looking closely, even at a relatively clean environment, there are marks, scuffs, and smudges on nearly everything. They're often subtle, but they're almost always there. Now, a lot of that subtle smudge detail in a normal room would fall below the fidelity of the medium, but in this case, I want to exaggerate it and make everything extra grimy. I want to convey not just that this is a depressing, unfortunate place to be, but I almost want a sense of neglect and even foreboding. I want it to feel like the people running the facility don't care about this particular place or the people it contains. Even before props or characters are added or dialogue is recorded, I want this level to convey a sense of desolation. Things are dark, dirty, and just generally unpleasant. This is an out-and-out bad place; escape is imperative.

After spending a few hours with Google's image search looking for inspiration and reference, I started adding some details to the cubes that made up the room I had chosen to paint. I cut out a window between the two rooms, added moldings to the doors and window. I cut out drains in the floor of the shower area and cut vents in the wall. I added planes to hold some signage and also for the ceiling lights.

I really don't know how much of this detail will survive through to the final version of the game, and it really doesn't matter. The goal here is to explore the process and to try and get a feel for whether I need to bring in a dedicated environment artist. If the actual work gets thrown out, that's okay. That's the nature of prototyping.

Once I had the details modeled, I started mapping textures from CGTextures, the Blender Texture CD, and a few other source onto the room's surfaces. I did this to give me a starting point. It's easier to work from something rather than painting on a completely blank canvas. 

Once I had all the surfaces mapped to textures, I "baked" them to a fresh texture map. Baking the textures to a single image will allow me to paint right on the 3D model directly using Blender's paint tools. Here is a reduced size version of the baked map for the shower room (left), along with how the room looks in paint mode in Blender (right):

It's certainly more realistic than my earlier white-walled prototype. Firing up Unity, this is what it looks like now:

It's definitely better, but it still falls way short of feeling real and it's way too clean and bright. On top of that, the current lighting just makes no sense. There's no visible light source, but the room is lit as if there was a light floating in the middle of the room. I'll fix the lighting later, but first, I want to work on the textures.

I went back to blender and started to filthy the place up. The grime will help make the room feel decrepit and it will also break up the repeating patterns from the tiled images I used, making it harder for the eye to pull them out. I loaded up an assortment of dirt, grime, and grunge images to use as brushes and started painting on the room's textures. It's a little weird painting on the inside of an object. Blender's Texture Paint mode works like Unity in that you can only see the "front" of polygons which, in this case, means the inside. Like one of those optical illusions, my eye wanted to think the texture was on the outside rather than the inside, but after a few minutes, I adjusted and work started going faster.

Doing something like this really makes you appreciate the power of undo.  I hit ⌘Z a lot while working on this, and it took me a long time to find an approach that gave results I liked. 

Once I had the new details and grime added to the texture, I pulled the new maps over to Unity to try them out. I also tweaked the shaders a bit, adding a distortion map to the window and creating normal maps for the tiles to give them a tiny bit of depth.

It's definitely an improvement. I might've been a little heavy handed with the grime, but I want to wait until I've done some work on the lighting to decide whether I should pull back on it. I envision this area being much darker and poorly lit than it is now, so I want to judge the texture in the correct lighting. 

In addition to being darker, I also want some of the lights to be flickering or burnt out. A little googling around found me a great light flickering script that gives just the effect I want. In Unity, I started placing lights around the room. Each of the two sections of the room has four light fixtures, but I decided that each section would have one light that was burnt out. The shower room would additionally have a flickering light and an an illuminated exit sign.

In order to keep performance reasonable with so many lights, I decided to bake light maps for the lights except for the one that flickers. "Baking" a light map essentially creates a texture map to store pre-calculated lighting information. They let you do lighting effects that are normally too processor intensive for real time calculation. The downside is that baked lights don't cast shadows on dynamic objects (like the player, moveable props, or bad guys). For a desktop computer or console version of the game, we'll probably want to make more of the lights real-time to get realistic shadows, but for mobile, we really have to be careful to limit the number of dynamic lights to keep the framerate up.

The Beast Lightmapper that's built into Unity is quite good and not that hard to learn, but calculating lightmaps is a fairly processor intensive task. Getting all the lights configured the way I wanted ended up taking a long time. I'd tweak one or two settings, then re-bake and wait five minutes or so. Lather, rinse, repeat.

After a while, I got the light maps baked mostly to my satisfaction. I started liking the overall look much better. The grime, which was kind of overpowering in the brightly lit room, feels just about right now. It still could use some furniture and other props, and the overhead lights could use some more detail, but on the whole, it's not terrible.

I wanted the shower room to be even less well-lit than the outer room, possibly to be used as a hiding place in the final game. This is how it looks after re-doing the lighting and baking the light maps:

It's not perfect by any stretch of the imagination, but the overall effect is roughly in line with what I want to achieve for the final game, and it only took me two days of experimenting to get to this result.

Here's a short video if you want to see it in motion.

At this point, I've done enough to believe we can do the environment work in-house. I understand the technical process well enough, so if I team up with one of our designers who has a better aesthetic sense than I do, I think I can get an environment that looks the way I want it to look.

Well, enough of this side quest. I think it's time to return to prototyping. Before that, however, I want to talk a little about the game's characters.

Next Up: Thinking About Characters

Previous: Just Getting Something Running

Turncoat Dev Diary: Just Getting Something Running

(This is part of a series. The first post in the series is here.)

Once I had made the list of tasks that had to be accomplished in order to get the game created, my brain started going in a lot of different directions all at once. I kept flitting between thinking about different tasks, trying to judge whether I could do the task, one of our existing MartianCraft developers or designers could do it, or if I'd need to go out-of-house to get it done at the level of quality and finish I wanted. A few items, like sound effects and music, I felt comfortable pushing to the back burner for now, but I felt a need to do an informal triage of many of the tasks. Some of them would require finding either freelancers or new hires and that adds time. I wanted at least some idea of what kind of outside talent I would need.

After about a half day of bouncing between the various tasks and just generally being a disorganized mess, I realized I was putting the cart in front of the horse. I need to just get something running to make sure the core idea was even worth pursuing. The greatest art and sound can't rescue a game that's not enjoyable. So, I pushed aside all my other concerns and thoughts to try and get a simple prototype up and running.

Fortunately, with Unity, that can be done pretty quickly. It took me less than day to get a prototype level built so that I could navigate it. Today's dev diary is about that process.

Unity doesn't have a level editor, per se. It has a scene editor with some basic primitives and some really good terrain tools. Levels are generally built in the scene editor using components built in an external 3D program, unless it's an outdoor environment, in which case you can often do everything right in Unity.

From the time I first thought of the escape game concept, I had some idea of how I thought the level should look and about it's overall layout. Now, that layout wasn't really driven by gameplay concerns, but rather by storytelling concerns. I had certain information I wanted to get to the player and some information that I wanted to make available to more adventurous players who explored beyond what was strictly necessary to escape. I envisioned the basic map as looking something like this:

The black area I envisioned as a somewhat standard prison cell block, although probably a little more futuristic looking than a prison you might find today, and the light blue boxes I thought of as solitary confinement cells, some of which would be used as starting points for the level. The darker blue areas would be administrative areas: the guard break room and the supervisor office. Marked in red is a series of ducts that can be used by some characters (those who aren't too big) to hide from guards and navigate around the map where the guards can't see them. The green area I think of as "the theater." The ventilation grates in those rooms don't open and the player can't actually go into them, but if you they are in the ducts and get close to the grates in any of those rooms, it will trigger in-game animation sequences (and not necessarily always the same one). These sequences will hint at additional ways of escaping the level and also fill in more background information about the universe and why the character has been imprisoned.

The goal of the game is to get to the security elevator, which is outlined in gold. It looks like a straight shot up the center from the isolation cells — and it is — but that hallway is well lit and well guarded. Plus, you can never go directly to the elevator. You always have to do something first before you can go there. You might have to disable a force field, find a key, or restore power to the elevator before going to it makes any sense. Once you've done that, then you need to get past the various guards without being detected in order to escape.

Once I saw the map laid out, I realized it wasn't enough. There needed to be more than one way to get to the elevator so that we could give the game some amount of replayability and also give the player more stuff to explore. I felt that there needed to be more rooms outside of the main prison block to give the player places to hide and explore.

I came up with the idea of adding on an "Intake Processing Center". The existing entrance to the elevator would be the one that guards and other staff used, but new inmates would come in a different way. They would come in through a series of rooms where their belongings were stored, mugshots were taken, and prison clothes were issued. I added on a series of rooms to the map for this purpose, as can be seen in purple below.

I originally started trying to draw out the level map old-school style. But, it wasn't really working for me. It was keeping me from thinking in three dimensions. So, I fired up Blender and started planning the map in 3D. The maps above are actually screenshots of the top orthographic view in Blender that I added some color to using Photoshop.  As you can see, it's actually a three dimensional map:

Working in 3D seemed to make sense, since the file I created can be exported right to Unity for prototyping. At least, it can if I built it right. There was only one way to find that out, though: export it from Blender and import it into Unity to try it out.

My first attempt didn't work out very well. I dropped a First Person Controller (something provided by Unity for creating first person games) onto my map so that I'd be able to navigate around the map. For the final game, I won't be able to use the provided Unity component, but it will work plenty well for letting me look around my map. 

I hit play, and saw… nothing.

Oh, right. Lights! The "real" lighting for the game will be done much later in the process, but I needed some light to see anything. I could've just turned on global ambient lighting, but that wouldn't give any shadows to judge shapes or distances. Instead, I dropped a somewhat random assortment of real time point lights onto the map. Performance won't be good, but at least I'll be able to see well enough to navigate the map. Since I'm using my dev machine to navigate around the prototype level right now, I'm not overly concerned about performance issues yet.

Once I had the lights added, I hit play again. And saw… nothing. Again.

Then I swore at my computer.

Fortunately, I realized what the problem was before the swear words were even completely out of my mouth.  Blender (and, I'd imagine, most 3D programs) assume that objects are going to be viewed from the outside, not from the inside. While Blender supports two-sided polygons, Unity doesn't, so when designing interior architecture, you have to make sure your objects are built, essentially, inside out - with the face normals — which mark the forward or visible direction of the polygon — pointing inwards.

You can see in the Blender screenshot below that the normals (the light blue lines) are facing outward. Most 3D objects get created this way so they can be seen from the outside when you're using one sided polygons.

Outwards, in our case, is bad. Outward pointing normals mean you can see this room from the outside, but not when you're standing inside of it. Fixing it was a simple matter of selecting each room in Blender, going into Edit mode, selecting all faces and then hitting the "Normals / Flip Direction" button in the left toolbar.

Once I fixed the normals, I re-exported, went back into Unity, waited for the level to re-import, then hit play. This time, I actually got something:

Well, yay! I've got a map and I can even walk around the level. I haven't written any code yet, but I can actually navigate from the user's perspective and get a feel for the level. I'm really liking my decision not to try and write my own game engine right now.

I found it kind of hard to maneuver, though. It is soooo white in here that it's hard for the eye to grab onto anything, especially when you're not near a point light. Even for a throwaway prototype, I needed some textures for the eye to grab onto, so I pulled down a few tileable images from CGTexture. 

Using repeating textures won't cut it for the final game. That was the state of the art a decade or two ago, but not today. The human eye is just too damn good at picking out patterns for us to rely on repeating images for very much. But, for testing, getting any kind of texture on the floor and ceiling was going to make a big difference. I also made the cells a different color than the hallways, which helped quite a bit as well.

It's not going to win any awards for level design or aesthetics, but it's a starting point. I can walk around, find the more glaring problems, and get a feel for how the layout will work. The first thing I did was to make sure I could get everywhere I wanted the player to be able to go. I found a few mistakes along the way - polygons that should've been deleted to make doors and normals that didn't get flipped. I also found a few gaps between rooms that were noticeable. Those were all pretty easy to fix in Blender, which I did.

The one thing that did strike me, as I walked around the map, was that the level is too small. Probably a lot too small. At a walking speed that feels natural, you can navigate the entire map fairly quickly. Even accounting for the fact that you'll be sneaking and avoiding guards much of the time, it's still too small. I'll have to go in later and make it bigger. But this is enough for an early prototype - to test out game mechanics and bad guy AI.

Now, if I were focused, this is the point where I would start working on some actual game mechanics. I'd drop in a few bad guys with simple AI so I could start actually playing the prototype and figuring out what works, if anything. But, I'm not focused. I'm the kind of person who…

Ooh, look! A shiny object…

What was I saying? Something something, focused… oh, right. There are some tasks that I know we're going to have to go out of house for, and some that I know we can do in-house. Then, there are the ones that I'm just not sure about yet. One task that I think we can handle in-house with existing talent, but don't know for sure, is painting and lighting the environment. So, I allowed myself to be distracted from the prototype to do a quick paint-up of one room on the level. That room will probably need to get re-done at least once before we ship, but it seemed a worthy experiment and something that would be kind of fun. Plus, it would help me get familiar with some Unity functionality that I've not used before (light maps), some new 3D painting improvements in the latest version of Blender, and it will just generally help with the decisions that need to be made about the overall aesthetic feel of the game. I'm a visual person and sometimes need to see something to know if I like them, because they always look good in my imagination.

Next Up: Experiments in Environment Creation

Previous: Deciding on Tools and Frameworks

Turncoat Dev Diary: Deciding on Tools and Frameworks

Once we knew our platform, it was time to start figuring out the toolset or frameworks that we were going to use to make the game. The essential decision we had to make was whether to build our games from scratch, essentially creating our own game engine in the process, or leveraging one of the many existing commercial or open source game engines that are available. Although the idea of creating our own game engine had some appeal, we knew that practical considerations weighed heavily in favor of using an existing one. Although there are costs associated with using many engines, and even though it makes you dependent upon somebody else's work, the cost/benefit equation really makes the decision pretty simple. We want to tell a story and create games; we don't want to reinvent the wheel, and writing a 3D game engine from scratch is very much reinventing the wheel.

It actually didn't take us very long to figure out which engine to use. We ruled out a few very quickly. Cocos2D wouldn't work because we want to create a full 3D game. Cocos3D is still a little too immature for us to be comfortable relying on it. Since we want to keep our options open for releasing on other platforms, some other engines were ruled out. Sio2, although a good mobile engine that supports both iOS and Android, doesn't have desktop or console support.

Ogre3D, a well-regarded open source game engine, just has too many rough edges for my tastes. The cost savings from the fact that it is free and open source seemed to be far more than offset by the additional time and headache involved in using it. I'm all for open source software when it's the right tool for the job — Blender is still my general purpose 3D app of choice — but the gap between Ogre3D and the commercial engines is pretty wide, not in terms of what you can achieve, but in the amount of effort it takes to achieve it.

We very easily got the list down to just three: the UDK, the Source Engine, and Unity3D. Then, two of those three got quickly crossed off the list, as well.

Although the UDK is an amazing engine, we ruled it out for one simple reason: the toolset is entirely Windows based. Although it can create iOS and Mac games, most of the work involved in creating the game has to be done on Windows. We're almost entirely a Mac shop and I, personally, am much more productive and happy when working on a Mac. Even if I didn't mind spending much of my day in Windows, I'd still have to compile, test, and upload to the App Store using a Mac, which seems a rather convoluted and inefficient process. It's probably not much overhead for a large game shop, but it's more hassle than I'd want to deal with.

The Source Engine has similar limitations. Although Valve has been promising Mac tools for a while, they have not shown up yet and there have been no recent comments from Valve about Mac support, leading me to question whether that they've dropped the plan. On top of that, Valve hasn't delivered official support for any mobile platforms yet. There are rumors of a Source 2 engine in the works that will likely address these issues, but we can't develop with something that's not out yet.

Before long, there was only one engine left standing: Unity3D. We've used Unity for a few client projects in the past and I'm, frankly, rather impressed with it. I thought that I would really hate working in C# but it turns out I don't mind it at all. I don't like it as much as Objective-C, but I don't have the kind of hatred for it that I seem to have developed for Java and C++ over the years. Like all languages, it has its quirks, but I don't feel like the language is working against me and I don't have problems context shifting between Objective-C and C# like I do with Objective-C and Java. Objective-C and C# are surprisingly compatible languages given their differences.

Although I've only got a few hundred hours of experience with Unity under my belt, it strikes me as having the right balance between ease of use and power. The development environment runs natively on the Mac (and Windows also) and it is capable of generating iOS, Android, Mac, Windows, and Linux executables. It's even possible to build your apps for the Xbox, PS3, and Wii, though doing so requires contacting Unity and negotiating separate licenses. There is, of course, some work involved to account for the various platform differences, but a surprising amount of it is handled for you.

Once we got the licenses squared away, it was time to get something built. There's one school of thought in game development that says you should try and get a prototype up and running as soon as possible. The earlier you start being able to play, the faster you'll know whether the game's going to work. So, let's get a skeleton of our level hashed out so that we can get our first rough prototype stood up.

Next Up: Just Getting Something Running
Previous: Platform Decisions

Turncoat Dev Diary: Platform Decisions

In our earliest brainstorming for Turncoat, there wasn't really any debate about which platform we were going to target. The iPad was going to be our first priority: our reference platform, if you will. We would also ship on iPhone if our game mechanics worked well on, or could be adapted to, that device's smaller screen. We'd look at porting to the desktop or to Android devices later if we felt the response warranted it.

Our earliest visions for Turncoat were, quite honestly, driven by the potential we saw in the iPad's big, beautiful Retina screen as a storytelling medium.

After more than a year of developing the idea, this is still the approach we're going to take. But, there is one thing about targeting the iPad as our principle platform that honestly gives me a little bit of pause: the App Review process.

Because of the size and makeup of the iOS market, it's really the best platform for what we want to achieve, but, the arbitrariness of app review and the vagueness of the review guidelines really  do concern me. The fact that Apple's official App Store Review Guidelines glibly adopt the famous Potter Stewart line about pornography and puts it forth as a valid approach to reviewing Apps borders on being childish.

They'll know it when the see it?

Really?

Worse than that, Apple says, flat out,

We view Apps different (sic) than books or songs, which we do not curate.
 If you want to criticize a religion, write a book. If you want to describe sex, write a book or a song, or create a medical App. [emphasis mine]

They say "Apps are different" but clearly what they're implying is that "Apps are less". They're telling us that if we want to do certain things, we shouldn't try and do them in an App, regardless of context, regardless of value, regardless of how well-suited an App might be to the task. Apps, Apple tells us, are a less valuable means of expression. They're less appropriate for challenging people and making them think. They're less valuable for making a personal or a social statement or for pushing any kinds of boundaries.

See, this notion is exactly, 180° turned around from what I think. I think Apps, and especially immersive Apps for the iPad, not only have the same potential as books, movies, and songs, to challenge, educate, and enlighten people… I think they have tremendously more potential. They can be made to interact. Stories can be told, but can be customized to the viewer or changed based on any number of inputs or conditions.

Put simply, Apps are a medium with nearly unlimited potential as a storytelling tool. Apps can be more than useful utilities and fun diversions. They could be used to really explore human interactions, to play on emotions, to let people experience life from the perspective of others, to force people to think, or to challenge what they think they already know. Given the chance, Apps could surpass the far more limited traditional forms of media that the App Review Guidelines seem to hold in such high regard. But right now, nobody's going to take a chance on doing anything like that, because Apple has decided to set themselves up as gatekeeper, and as gatekeeper, they have decided that the App, as a form of communication, must remain in perpetual adolescence and never grow up.

Apps are the Lost Boys of media.

And that's really a shame, because there is so much that can and should be done with these amazing little devices we all carry around every day.

Even worse than the fact that Apps are viewed, by Apple, as less than books, movies, and songs is the fact that Apple never lays out definitively what is okay and what is not okay. The rules aren't fixed or concrete.  There's no way to predict whether specific content will be allowed onto the App Store until after you have already invested the money to create it. Content similar to material that is available on the iTunes Store in R rated and sometimes even in PG-13 rated movies can, and have, been grounds for rejection in the App Store.

Where's the line? We don't know. Apple won't tell us.

They'll know when they see it.

We know there are some things you'll never get on the App Store, like hardcore pornography. Or, maybe you will if you're Brian K. Vaughn, but probably not if you're anybody else. But there's a huge amount of gray area short of that. There's an awful lot of content that might be okay and might not. There's a lot of stuff that might get in one day but not the next, or that might be allowed by one reviewer but not another. Developers are expected to invest substantial time and money into creating apps and then submit them to Apple knowing full well that they might get rejected for violating some unwritten rule. We're all expected to be okay with the fact that the fate of our app will be a subjective decision made by some faceless stranger who will probably have, at most, twenty minutes to look at and judge our app. And we're expected to be okay with all this despite the fact that we have no alternative market for our creation. If Apple rejects us, we can go nowhere else with our creation easily.

This situation creates what First Amendment attorneys call a "chilling effect". Content creators tend to intentionally stay well behind the line of what they think will be accepted because the financial implications of crossing the line are high. But at least nobody will be offended, nobody's world views will be challenged, and nobody will ever have to think. What a brave new world it is.

I'm not arguing that Apple doesn't have the right to be gatekeeper and decide what content gets put on their store: they most certainly do. I'm just saying that as a writer, developer, and content creator, this ambiguity and treatment of Apps as a less mature and less worthy medium bothers me and seems more than a little short-sighted. It saddens me that Apple is actually discouraging creators from exploring this new medium to its fullest.

Go write a book or a song.

But, I don't want to write a book to tell this story. I don't want to create a song about these people. I want to leverage everything that an App has to offer to make the most impact and to make people care and think.

I don't think any of the scripts written for Turncoat so far would be particularly offensive to most reasonable, mature people. I'm not on a mission to get embroiled in controversy or push any boundaries.

But I am on a mission to tell a story, and that story has pleasant and unpleasant parts. Things happen that people won't like, and the characters have a strange knack for acting like real people.

It concerns me that by targeting iOS as the primary platform for Turncoat, the power to decide whether I can tell the story I want to tell, the way I want to tell it, will reside with some anonymous app reviewer sitting in Cupertino working a thankless job and doing the best they can to follow intentionally vague guidelines.

For that reason, and that reason alone, I seriously debated trying to convince Rob that we should target Desktop computers first, and then maybe bring the Turncoat games to the iPad later. But, when it comes down to it, iOS is just too big and desirable of a market. The Turncoat Escape game, and likely every other Turncoat game we're able to produce, will target iOS first. If we run into problems with App Review, we'll take whatever steps are necessary to pass review.  Then, maybe, we'll release the full version on another platform so people can see the story the way it was intended.

It's funny, though. I can't help but think about another medium as I write this. See, I stopped watching television around 1991. For a very long time, didn't watch any television at all. I still owned a TV, but I had not cable or satellite – not even a UHF antenna. I stopped watching for practical reasons; I was very busy at that point in my life and quite literally had no time to watch. But for the next decade or so, any time I thought about starting to watch television again, I found myself unable to invest myself in the medium. Between the fact that a third of the airing time was devoted to grating, obnoxious advertisements and the fact that stories had to follow all the unwritten rules of the medium, I found any attempt to get back into watching television again annoying. I mean, it's hard not to lose your suspension of disbelief when a hardened mob boss says "fudge" instead of "fuck", or a major character waxes poetic about some brand of automobile for no apparent reason. After being away from it for a while, the flaws of the medium became really obvious to me, and I continued not to watch.

But something happened. Television — or at least some of it — became good. By the time the TV and Netflix were available (which is when I started watching some television shows again), there was a lot of halfway decent television to watch and there was some that was very good.

What changed? I can give you my theory.

The Sopranos changed. The Sopranos, and other cable television shows like it that didn't have to try and guess at and conform to the arbitrary guidelines of the FCC or the demands of advertisers. Freed from the possibility of being fined for random violations of unwritten rules, television got better as a medium, and some of it became great. Some people might be tempted to point at technological advances for the fact that television became better, but I really don't think that's the real reason. TV got better because the writers were allowed to write without having to worry about what some bureaucrat might do as a result of what they wrote or what some uptight zealot in Utah might put in a letter to their member of Congress.

The more things change, the more they stay the same. App developers are stuck back in the world where Lucy and Desi had separate twin beds.

As you can probably tell, I don't like the present situation. I don't mind constraints, but I want to know what those constraints are so I can work around them intelligently, and I want them to be reasonable rather than catering to the least common denominator. I don't think the way Apple handles App Review right now is a good long term strategy but, hey… you play the cards you're dealt.

Someday, though… I do hope Apple will decide to let Apps grow up and we can start seeing some truly great storytelling happen on our platform.

Next Up: Deciding on Tools and Frameworks
Previous: Finding a Smaller Game in the Universe

Turncoat Dev Diary: Finding a Smaller Game in the Backstory

After investing a lot of time into Turncoat, we started pre-production, with our first task being to figure out just what it was going to take to make the series of games we had envisioned. We didn't go too far down that road before we realized it was going to take an awful lot of work and resources. Too much work and too many resources: far more than we could swing without outside funding.

That's not exactly the kind of realization you enjoy having, but we were happy to have realized it before we actually started sinking money into development. At this point, we had really only invested our time, and since we had enjoyed the process, it couldn't really be considered a loss. So, we decided to put the larger Turncoat story on the back burner, but use the universe we had created for it as the setting for another game of smaller scope. The tricky part here was that Turncoat was designed as a mystery with a complex backstory, most of which exists to support that mystery. Any number of facts from the existing story could spoil Turncoat for players if and when we're finally able to revisit the original concept.

We started investigating ideas for both 2D sprite-based games and full 3D games. We came up with several ideas, and decided to actually run with two of them. One is a take on a traditional 2D platformer that we're going to use the new SpriteKit framework for. The other is a stealth-based 3D game. It's the latter that we've already started working on and which I'm writing this dev diary for.

In this game, you have to escape from a jail-like facility using a combination of stealth and problem solving with maybe an occasional spot of violence. It will have things in common with several existing stealth-based first- and third-person shooters, but the focus will not be on combat. If you get in a firefight, you've probably already failed. Funny thing about jails; they're harder to escape from if the guards know you're trying to escape.

The game will take place about a hundred years before the original Turncoat story, during the "Last Great War" — the war that led to the creation of a single Earth government. During that war, several of the nation states created internment facilities and rounded up a certain class of people. There were no mass killings or attempts at genocide like in the Holocaust, but the treatment was degrading and often violent and the inmates were treated as less than human. Though there were no systematic executions, many inmates were killed for one reason or another.

Exactly who these inmates are and why they were imprisoned won't be revealed at first, but we'll drop some hints throughout the game, both in regular dialogue and in hidden easter eggs that will give the player pieces of the game's puzzle. We'll also throw in few small hints about the mysteries of the larger Turncoat Universe. The important thing that we'll convey to the player at the start, though, is that they have been imprisoned unfairly, that they are being treated poorly, and that they really need to get the hell out. That's all they really need to know to get started, but we want them to be able to discover more about why they've been imprisoned and more about the world they live in as they play the game.

Once we had decided on a basic concept, next up was figuring out what we need to do to actually build it, keeping an eye on creating something polished and professional while keeping the scope of the game reasonable. Here's the initial, high-level list I came up with of things that need to get done, in no particular order:

1. Level Design. We need a place to escape from. To keep scope down, we're going to limit ourselves to a single level for this project, though we're going to leave the possibility for additional levels in the future if the game is well received. To increase re-playability for the one level, however, there will be multiple starting points and multiple ways to get out. Some options will always be available, others may only be available from a certain starting point or using a character with certain attributes.
2. Script Writing. We're still trying to tell a story, even if it is a much smaller story than our original vision, and to tell that story, we need dialogue. We'll need an opening cinematic to set up the game's scenario and make sure the players knows what they need to do. We'll need to figure out what the guards and other people in the facility say if the player gets near them. There are going to be hints about the world that will be dropped through dialogue in certain places. When a player escapes, there will be another ending cinematic to tease possible future levels and to reward them for their accomplishment, and it will probably be a different cinematic for each possible exit. All of that dialogue needs to be written.
3. Overall Aesthetic. We needed to figure out, stylistically, how everything will look. Will we try and make it realistic, or will it be somehow stylized? Will we favor bright colors or muted ones, or will that vary depending on some factor. 
4. Environment Design. Once we have a level, we have make it feel like a real place by layering textures and lighting to create an environment that is believable and immersive. 
5. Character Design. A story means people, so we need to figure out who the people in our story are — both the protagonist and antagonists. We need to know why they're in the facility, what they're going to look like, and at least a little bit about their background.
6. Character Modeling. Once we know what characters are going to look like, their models have to be created. For some characters, we'll need both high resolution models for cinematics and low-resolution models for game play. For others, we'll only need the game-resolution models.
7. Game Mechanics. We need to figure out how the player maneuvers around the level and what tasks they have to accomplish to get out. 
8. Sound Design and Foley. An environment won't feel real if it's dead silent. Even games set in the vacuum of space (which, in reality, should be silent) don't feel right without some kind of sound. 
9. Music. Just like with movies, games need music to set the mood. Music, like other sounds, can also be used to give the player feedback. We might have a different musical theme playing, for example, when the player is heard by guards, arousing their suspicion and putting them on alert.
10. Animation. Although we can use stock animations from companies like Mixamo for some of the character and enemy movements, there will likely be some game-specific motions that we're not going to be able to buy, so we'll need to animate them or use motion capture to create them.
11. "Finding the Fun". This is a term that a friend of mine who has worked in the game industry uses. It describes the process of iterating over the basic game mechanic until you find something that's enjoyable to play. Unfortunately, you can't "find the fun" until some of the other work has been at done. You don't have to have a fully polished game to start, but you need something. If you can't find the fun, the game should be abandoned or drastically overhauled, so it's best if you can start this process early.
12. Voice Acting and Direction. Dialogue means voice acting, so we're going to need to find voice actors and we're going to need to direct them to make sure they say lines the way they were intended.
13. Branding and Marketing: Even a free product is a product and it does no good if people don't find out about it.
14. Testing, Testing, Testing: Just like any other kind of software, games need to be tested extensively before they can be shipped. Fortunately, it's often easier to find people willing to try out an unfinished game than, say, an unfinished productivity tool.

Yikes.

I know I've probably missed a few things, but I think that covers the bulk of the tasks at a very high level. I'm not sure about you, but to me, that's a pretty intimidating list, but also one with a lot of potentially fun, cool tasks. It's also not nearly as intimidating as it would be for an individual developer.  Fortunately, we have a team and resources to hire freelancers to handle those tasks we can't handle in-house.

Although many of these things can be done in parallel by different people, some of the tasks have to happen before others can be started. You can't really begin character modeling until you've got character designs, for example, and you can't really begin working on game mechanics or "finding the fun" until you have at least part of a level to maneuver around. None of these things happen in a vacuum, though, and none can be considered completely done until the game has shipped. Characters might get redesigned, for example and the level will almost certainly need to be tweaked as we test. As with any software development, the process will be one of iteration, so we can't get too married to anything.

Before we can begin even the first task, though, we need to decide what platforms we're targeting and what tools or libraries we're going to use to build the game.

Next Up: Platform Decisions
Previous: Life in the Turncoat Universe

Turncoat Dev Diary: Life in the Turncoat Universe

Since much of the Turncoat Universe's history exists to provide the backstory for a mystery, I'm hesitant to say too much very specific about it, but throughout this series of blog posts, I'll be talking about the process and the motivation that went into building our universe as well as the nuts and bolts of building the actual game. For the former to make any sense, you'll need at least a little context.

The original Turncoat story is set in the late 24th century during a war being fought between Earth and its former scientific colony on Mars. People of Earth call the people of Mars "Seditionists" or "Seds"; they only rarely call them "Martians" and never "Colonists".

This is not a civil war, however. Though no Earth government ever officially recognized Mars' sovereignty, neither had there ever been any attempt to prevent the secession. The two planets had been peacefully coexisting until about thirty years ago. The Mars Colony actually seceded a century earlier during a bloody multi-nation (but fortunately, non-nuclear) conflict on Earth, a conflict that led to the eventual creation of a single, unified Earth government.

Why are Earth and the Mars Colony at war? What started it, and why can't the two planets find a peaceful resolution? Those are some of the bigger mysteries of the Turncoat Universe; the player and the major characters don't know all the forces that are driving the conflict. In fact, most of what they do know is based solely on propaganda from their own side. What the player does know for sure from early on is that the war was started by the Seditionists who launched a surprise attack on Earth using devastating long-range weapons. Why the Seds attacked Earth is the subject of much conjecture, but the real reasons are not known on Earth. Players also find out quickly that the war has been going on for a very long time and shows no signs of ending any time soon.

In the Turncoat universe, there is no faster-than-light travel and there are only a handful of humans who have ever left the solar system. Travel between Earth and Mars is still a danger-frought six to eight week journey depending on the relative positions of the planets. That makes the war difficult and expensive to carry on. Large scale engagements are relatively rare, and only a small percentage of Earth citizens are involved in fighting the war. War happens "out there" and doesn't really affect the day-to-day life of average Earth folk who aren't in the military.

But "out there" is a dangerous place. Ships don't have shields like in Star Trek, nor do they have FTL capabilities. They're operating millions of kilometers away from home with very little in the way of support. When a ships takes a hit from enemy weapons, people die and parts of the ship become unusable.  But these ships have a job to, and if a ship is still able to fight, it stays "out there" and fights.

The player in Turncoat sees events from the point of view of elite Earth soldiers stationed on one of Earth's "Deep Fleet" ships. The Martians are the "bad guys". They're the mostly-nameless and mostly-faceless soldiers who are trying to kill them. At first, we don't even really see them as people. They're represented by enemy ships and mirror-faced space suits that are shooting at the player.

While players don't know much about the culture, history, or internal politics of these faceless enemies, at least at the start of our story, they do start finding out about life on 24th century Earth right from the get-go, so we had to put a lot of thought into what life would be like in our 24th century Earth.

One of the nice things about writing fiction is that you get to decide how things play out. We decided that we wanted our 24th century Earth to be, on whole, better than now. We want to present an optimistic outlook, but one tempered by reality. There will always be problems and conflicts; we do not want to present a utopia. People are still self-interested and petty. There are still rich and poor, and there are still people willing to profit at the expense of others.

But, overall, life is better for most people than in the past thanks to steady advances in medicine and technology and other fields.

Thinking forward nearly four hundred years is not as easy as you might think. If you work backwards that same amount of time, you'd be in the early seventeenth century. To put that in perspective, the early seventeenth century was the dawn of the Age of Sail. Firearms existed, but were not the primary weapons used to wage war. Only one of the American colonies had been founded. It would be nearly two hundred years before the British Empire would outlaw Slavery and over two hundred and fifty years until the American Civil War and the Emancipation Proclamation would do the same in the United States. Throughout most of the world women were considered property, without the right to vote or hold title in their own name. People were wildly xenophobic and superstitious. In the early sixteen hundreds, people were still being put on trial and often hanged or burnt at the stake for witchcraft and heresy, and both the Spanish and Portuguese Inquisitions were in full force.  It would be another two hundred and twenty-five years, give or take, before Darwin’s voyage on the HMS Beagle.

A person from the early seventeenth century would have a very hard time comprehending the modern world. It would be naïve and more than a little arrogant to think we would do any better comprehending life four hundred years from now. Realistically, we can't change our fictional world as much as the real world will actually change by then, and even if we were capable of doing so, we probably wouldn't want to because our player would feel out of place and uncomfortable.

But we need to convey to the player that social mores and culture have, in fact changed. In my mind, to be science fiction, rather than just futuristic fantasy, social mores and cultural standards have to be different from today. Those changes can be for the better or for the worse, but there have to be tangible differences in how people think about the world and how they interact with others, otherwise you're just creating General Hospital in Space. With lasers.

Not that there's anything wrong with that, but it's not what we're going for with Turncoat.

So, what cultural changes did we decide on for our Twenty-Fourth Century Earth?

First, we decided that the entire world had moved to a single-unified government. People are no longer citizens of countries, they're citizens of Earth. Countries are more like states or provinces or maybe even counties in today's world, and the existence of a common enemy has reinforced this feeling of planetary patriotism. To the mainstream twenty-fourth century Earthling, all other affiliations and identitifications are secondary to world citizenship, whether it's cultural heritage, ethnicity, religion, or anything else. Those things still have some importance to some people, but they're almost always of secondary importance.

There are a small number of people in the twenty-fourth century who consider their association with a cultural group, ethnicity, race, or religion to be more important than their citizenship. Those people are called "Traditionalists", and they tend be looked down upon by mainstream citizens, much the way many people today might look down upon uneducated rural people (but more so). There aren't a lot of these Traditionalists, though, and they tend to live in isolated communities far away from population centers.

A world-wide government doesn't come without its problems, of course. There is a lot of bureaucracy and waste in both the civilian government and in the military. Even with four hundred years of technological advancement, logistics are never handled perfectly. Just like today, large bureaucracies mean mistakes get made and change is often slow. Shipments and personnel often arrive at ships completely wrong. A ship might requisition food and end up with parts for equipment that the ship doesn't even have. They might desperately need a repair technician but be sent a trauma nurse instead.

Second, not only has racism been defeated, but few people in the twenty-fourth century outside of historical sociologists would even understand what the term means. Most people in the twenty-fourth century have ancestors from many ethnic backgrounds. It's not uncommon for people to have a surname from one culture, a first name from a different culture, and the physical traits that today we would associate with a third culture. You might have someone, for example, with a Japanese surname and a Portuguese first name,  but who has blue eyes, pale skin, freckles, and red hair. Essentially, there are no rules when it comes to names or physical characteristics. The world has become a true melting pot.

Third, twenty-fourth century Earth has long-sinced achieved true gender equality. Women fight alongside men, and both the civilian and military leadership have nearly identical numbers of men and women at all levels of leadership. We decided to have a little fun with this idea, though. We made that equality almost — but not quite —  universal. We decided, for grins and giggles, to put in one little tiny bit of subtle gender bias in our universe, but in just a single occupation. The job of fighter pilot, in the Turncoat universe, is a job heavily weighted toward women. We thought it would be interesting to reverse the situation of today. We decided to play "what if", and make it so that in the Turncoat Universe, for some reason, women just tend to be better fighter pilots in zero-gravity. We don't go into why — whether it's genetic or cultural or what, but the CAG, LSO, wing commanders, and most (but not all) of the accomplished pilots we meet in the Deep Fleet, are women. In literally ever other job in the universe, though, there is absolute and complete gender equality. 

Fourth, we decided that the world had evolved in terms of sexuality and sexual relations, but that this will be something that's more of a background element rather than something we put right out in front of the viewer. Mainstream Earth citizens have mostly moved beyond caring about things like sexual orientation or sexual identity. Except for Traditionalists, people just aren't uncomfortable with the idea that other people are different than they are. Related to that, the 24th century has no body modesty taboo. The ship's facilities — showers, bathrooms, barracks, and locker rooms — are all mixed gender except for a small portion on some ships that are set aside for "Borderliners" - Traditionalists who have chosen to try and live in mainstream society for one reason or another.

Overall, the citizens of twenty-fourth century Earth are generally rational, literate people. Public education systems are fairly good and most people have at least a basic foundation knowledge of the maths, sciences, and history. Most people are also not overly superstitious. There are some exceptions to that, though. One area where most people are very superstitious is with regards to the Seditionists. People just don't have much hard information about the Martians because it's been over seventy-five years since there was any meaningful communication with the red planet. As a result, there are a lot of rumors, stories, and myths about them, ranging from the plausible to the completely absurd. Almost all of these stores are completely untrue and yet many are fervently believed by some and are given some credence by many.

This view of Earth people towards the Martians is actually inspired by U.S. attitudes about the Soviet Union during the Cold War, especially the Reagan era Cold War. If you look at popular culture back then, you see a lot of examples of "red fear" in movies and television shows. Stories like No Way Out, Red Dawn, and Little Nikita  played on American fears about the threat posed by the Soviet Union and possibility of embedded Soviet "sleeper" spies living in America. While entertaining, these stories were fueled as much by half-truths and ignorance as they were by reality. Earth beliefs about Martians are similar, but the stories are even more dramatic and even more dramatically wrong.

In addition to cultural changes, there are also some important aspects of twenty-fourth century Earth that will color the events and decisions made by characters. The most important of these is that Earth is teetering on the brink of overpopulation and starvation. Restrictions on population growth combined with advances in agriculture and genetics, and the use of the moon and several agricultural space stations to grow food mean there's enough sustain Earth's population, but just barely. People on Earth live on a rationed 1800 calorie diet except for the very wealthy, and most of that comes from processed foods. Fresh fruits and produce are relatively rare treats for the middle class and almost unheard of for the poor. Only the very wealthy ever have meat, and it is looked upon by the non-wealthy the way some people today look upon caviar and foie gras: as unappetizing foods the wealthy eat just to show off the fact that they're wealthy.

For the Deep Fleet, keeping everyone fed is a challenge, and it's not uncommon for the ships to go on "starvation rations" of 1000 or 1200 calories a day for days at a time, sometimes even longer. Supply convoys are often targeted by the Seditionists and bureaucratic mix-ups often result in too little food being sent in the first place. There is a thriving (and tolerated) black market in the fleet that uses foodstuffs as the primary currency, and several larger ships have taken to converting unused space into makeshift hydroponics bays.

More than one Earth politician has looked at the sparsely populated and lushly terraformed Mars as an option for alleviating the overpopulation problem once the war has been won.

There's more to the Turncoat Universe, of course. In fact, there's several hundred pages more, but this should give you enough context to play along at home without spoiling anything too important.

Next Up: Finding a Smaller Game in the Backstory
Previous: Origin of the Universe

Turncoat Tool Time #1: The Story Bible and Scrivener

After posting the first Turncoat Dev Diary post yesterday, I received a number of questions from people about what software was featured in the screenshot of our Story Bible. The software we're using to write the Story Bible is Scrivener by Literature and Latte.

We looked around a little bit for apps designed specifically for game design, but nothing we found really jumped out at us as a good tool for what we needed. A few months ago, a program called Articy came out. If it had come out a year earlier and if it weren't Windows only, I might have taken a hard look at it. I'm not bashing Windows, it's just that I'm comfortable and therefor more productive when using a Mac.

But, I had used Scrivener quite a lot and it seemed like an awfully good fit for what we wanted to do, especially since we didn't completely know what we wanted to do. Scrivener is great at collecting and organizing research and it lets you write styled or unstyled text and then easily reorganize what you've written. One of the nicest feature for what we were doing turned out to be something called "Binders".

Binders allow you to organize a subset of your Scrivener project's files, sort of like virtual notebooks (hence the name). We have our big Turncoat project, but then we also have a binder called "Story Bible", which stores all the information about our universe and the characters, but none of our research or game-specific information. We have individual Binders for game concepts we came up with, but also have a binder called "Scripts", which contains all the scripts from all the various game ideas we came up with in order. Items can be in more than one binder and stay automatically in sync, so they're incredibly useful when you have a lot of information that might need to get presented in different ways at different times or to different people.

Scrivener is quite easily one my favorite pieces of software ever. It's like an IDE for writing. It doesn't matter what type of writing you do, either. Whether it's fiction, screenplays, academic theses, or something else altogether, Scrivener can make the process better. I always hated that I was never able to find a way to use Scrivener in Apress' publishing workflow without problems.

If you do any serious amount of writing, you should probably take a little time to check out Scrivener. It's got a bit of a learning curve, but the instructional videos are well done, and once you get over the learning curve, it's a huge help.

My only complaints about Scrivener is the fact that it doesn't have better collaboration tools, and that it can be a little tricky using it with source control. You have to make sure you never, ever commit when the program is open. Those are relatively minor quibbles, though, and I don't think I could write without Scrivener these days. Well, maybe I could, but I wouldn't want to.