Tuesday, May 27, 2014

WWDC 2014

We're less than a week out from WWDC. The conference really snuck up on me this year. I never even got around to updating my WWDC First Timer's Guide. Re-reading the guide from last year, I don't think I would've changed much anyway. If you're coming to WWDC for the first time this year, last year's post is probably worth a read, as are several other similar posts. For a somewhat less serious take, Mark Dalrymple's 2013 first timer's guide is a fun read.

For the first time in a long time, I really don't have a firm idea what to expect this year. The past several years, I've had a pretty solid notion about what was coming. I usually didn't know the fine details of what was coming, but I usually had a solid idea about the broad strokes. This year, I have some guesses and some wishes, but nothing I'm super confident about. I don't have any real idea about what we'll see in iOS 8 or in Mac OS X Eureka¹

While I don't know what is coming, I do know how many of the Apple engineers feel about what's coming out next week, and they seem to be pretty excited about it all this year. That's enough to make me excited and confident that it's going to be a good year for developers.

It's been a strange WWDC lead up this year for me for a number of reasons, not the least of which is that this will be the first year since before the iPhone came out that I don't have a ticket. I'm not upset about that - I actually didn't even put my name into the lottery - but it does change the nature of my anticipation somewhat. I will, of course, be in San Francisco for the week. Even without a ticket, it's still my favorite week of the year.

I am a little saddened that the new, larger MartianCraft will have such little representation inside the walls of Moscone West, though. We have 48 people between our employees and full-time contractors and the vast majority of our work is iOS and Mac software development of one form or another. Around twenty of our people attempted to get tickets, and only one person got one. From what I've seen from friends and acquaintances in the community, that ratio is not out of line with what others experienced. The breaking of my seven-year streak pales in comparison with some other people who didn't get tickets this year. In fact, most people I personally know in the community are going without tickets.

I've noodled a bit in the past about how Apple might "fix" WWDC. My general opposition to WWDC becoming a mega-conference like JavaOne remains unchanged. But… I can't help feeling that the need for Apple to do something becomes more imperative every year. As a matter of fact, I think we're past the point where that something should already have been done. Apple needs to accept that a single 5200 person conference and a few scattered tech talks every year or three just isn't meeting the needs of the community. A lottery makes it as fair as such a thing can be, but it's addressing a symptom, not the actual problem.

While the WWDC sessions and labs are awesome, the WWDC moments that have stuck with me have been the chance meetings. It's been the opportunity to meet people who created something I use or to talk with people who have done things I admire. It's been the chance to sit down in a seat next to somebody I didn't even know I wanted to know.

It's the moments that have made me feel like I belong that stick with me and make me want to keep being part of all this. That's what WWDC has always been to me: the chance to connect and reconnect with the people in our community. Some of that has always happened outside Moscone West in the surrounding restaurants, bars, hotels, and even on the streets of San Francisco. Most it, however, used to happen inside the conference center. Even a lot of what happened in the surrounding areas happened because of connections originally made inside.

But that's no longer the case. It no longer can be the case as long as the conference stays the same size and the community grows.

The number of people who can attend WWDC has remained constant for over a decade, but the number of people coming into town for WWDC has risen steadily since 2008.  We've now reached a point where the importance of the actual conference has been eclipsed by what's happening in the surrounding areas. WWDC sets the time for when we all come into town, but it has already stopped being the center of the universe for us that week.

That's not a good thing for Apple or for us. Apple should be at the center of the universe for its third party developers. Session videos and documentation become available online. Keynotes are streamed. You don't need to be in San Francisco to take advantage of any of those things.

But having so many of us in one city at the same time for a week is still important. Personal connections matter. Sharing food and drink and war stories helps create and maintain a sense of community and makes us feel like we belong to something.  It allows our increasingly larger industry to keep some of the character that made it so special when it was small.

Hopefully, the fine folks at Apple realize that WWDC is not really sessions, labs, and boxed lunches.

WWDC is people. And because of that, I can't wait for next week.

P.S. We're doing MartianCraft shirts again this year, with pickup at the conference available as long as inventory hold out.

1 - I honestly have no idea what city they're going to pick for the next version of Mac OS X. I don't like the sound of "Mac OS X 10.10", so I randomly picked a city name from a Wikipedia list. If it actually turns out to be "Eureka"… well… in that case, let's just say I should've bought a lottery ticket instead of writing this post.

Thursday, February 13, 2014

Announcing: Republic Sniper

Sorry for being so quiet of late. We've been busy at MartianCraft of late.

In addition to merging with Empirical Development, we've also been studiously working on the first game set in the Turncoat Universe™.

It's called Republic Sniper™.

Today, we released a teaser trailer for the game. This trailer was done entirely in-house. Most of the production was done over just a two week period by a team of four people, only one of whom who was dedicated full-time. They did a hell of a job and I need to give a special shout-out to Patrick Letourneau for not just carrying the ball across the goal line on the trailer, but running it the entire length of the damn field.  He accomplished an amazing amount in a completely ridiculous amount of time and we're both grateful and impressed.

We've also been sharing concept art, trivia, and WIP screenshots from the Republic Sniper twitter account.

We haven't announced a ship date for Republic Sniper, but you can sign up for our mailing list on the website to be notified as soon as we have more information to share!

Our much larger combined company has a dedicated game team with multiple in-house and contract games currently under development and we're always happy to talk with people about new game (or non-game) projects.

Thursday, October 24, 2013

Turncoat Dev Diary: The Grind

This "every week" commitment has turned out to be harder than I expected. I've been pretty heads down working on game mechanics of late. I actually found time to write a couple of posts that I can't publish yet because we're still trying to sort out a problem with our Apple developer account. We've got our domain reserved, but we don't want to reveal the game's name or details until we've also reserved the app name. At present, we can't do that. Hopefully we'll get that resolved this week.

But work continues on the game. The gun you get at the start of the game has now been fully modeled and textured and we've generated a low-poly normal-mapped version for the game.

The yellow paint denotes that this is a training range rifle - it will only be on the gun when you're on the training range, though we may end up going with a different color or ditching the paint altogether. While it looks pretty nice in the renders, it tends to blow out in the actual game when you're near lights.

We've also got the initial model for the RAR-14 assault rifle:

This is the standard Republic assault rifle, the gun from which the sniper rifle above was derived. If you look at the receiver, you'll see that it's essentially the same gun with a different stock and barrel. The sniper variant also uses slightly different ammunition, so the clip is a little longer to account for the longer cartridges it uses.

You can see from the orange marks that we're playing around with different color markings, trying to figure out what will look good in-game.

Before too long, we should have the training range done. The first five levels — a tutorial plus four challenge levels — will take place on the training range. The range will also be used for a training mode that will let players test out weapons and weapon modifications. The level has been blocked out and the area behind the shooter has been partially detailed:

I've also made quite a bit of progress on developing the game mechanics. I've got a working prototype with bad guys. There's no real AI to speak of yet, just an algorithm that I like to call "lambs to the slaughter". The bad guys will avoid obstacle and each other, but otherwise, they just walk towards the shooter until they get shot and die.

The basics are working, though. There's a basic hit point system with location-based damage adjustments, particle-blood on impact, and death animations. It's not exactly a game yet, but it's actually starting to actually be kinda fun testing the builds.

I was pretty depressed earlier this week, though. The test level was working great on desktop builds, but trying to play on any mobile device except the iPhone 5S resulted in really bad framerates, and this was without much in the way of dramatic lighting or complex models. The test level I was using has a relatively tiny poly count and the proxy bad guy models I was using do as well. The textures were reasonable in size and using hardware-supported compression and I was using only simple shaders designed for mobile use. Yet, on an iPad Mini, the level would start at 15fps and quickly drop to 3 or 4. It was playable, but not great at 15fps, but when it dropped below that, it became unusable.

I reached out to some friends who have more experience with Unity for advice. With their help and the help of Instruments and Unity's excellent profiler, I found a couple of things that were just killing performance by forcing the physics engine to re-create a bunch of objects every frame. A few hours of poking around and asking questions and I had the prototype running at 30fps even on an iPad Mini and even with a dozen or more bad guys visible.

Once I got performance working well, I started playing around with Unity's light maps and light probes, which let you do fairly impressive lighting without the use of performance-killing rendered lights. I'm really happy with the results I've gotten so far and can't wait to see what we can do with these features on an actual artist-created level.

Overall, things are moving along well.

Saturday, October 12, 2013

Turncoat Dev Diary: Going Ballistic

We're still working on getting our ducks in a row administratively so we can actually announce the name and basic details of our first game, but as I've mentioned before, it is going to be centered around the use of guns. The Turncoat universe is set four hundred years in the future, so there will be fancy futuristic weapons available, but I wanted the first weapons you get access to in the game to be essentially more advanced variants of modern ballistic firearms.

You could argue that by the year 2400, cartridge-based combustion-propelled firearms will be horribly obsolete. Certainly many fictional futures have taken that route and opted for only rays guns, lasers, blasters, phasers, ion cannons, and other such options.

But, if you think about it, the sophisticated modern firearms of today are based on the exact same principles as weapons created in the fourteenth century. Using combustion to propel a small piece of metal very, very fast has proven to be a very effective way to harm living things. Firearms have been around for seven hundred years without becoming obsolete, so there's no reason why they wouldn't still be in use in some form four hundred years from now alongside whatever other new ways of killing get created.

When it comes down to it, however, it really doesn't matter how likely anything is in reality. From a gameplay perspective, we want to have many options for our players. We want them to be able to use different kinds of guns with different gameplay characteristics and to be able to upgrade those guns in numerous ways. Our goal is to add variety to the experience of playing the game, not accurately predict the future of weaponry.

As I started prototyping the gun mechanics in code, I found a lot of examples and tutorials scattered around the Internet about how to do guns in Unity. Most of those tutorials recommended a simple raycast (combined, of course, with sound and visual effects). You cast a ray out from the gun's barrel and see if it collides with something. If it does, you have a hit and the result of that hit happens immediately. And why not? As far as human senses are concerned, bullets from modern guns might as well be instantaneous except at the very longest range of the most powerful sniper rifles.

But that approach is no good for our game. One of the main benefits of the later advanced weapons in the game is that they don't suffer from some of the problems that ballistic firearms have. For example, when shooting at long range with a sniper rifle, you have to account for the trajectory of a bullet, the fact that gravity pulls the bullet downward as it moves forward, and the fact that other forces, like wind, can act on the bullet. Ray guns don't have that problem. They're simply point and shoot, so to speak, and raycasting makes perfect sense for those later, more advanced weapons. But raycasting doesn't take the realities of a physical world into account for a ballistic firearm.

I want the firearms in the game to "feel" real, and I want the bullets to behave the way a real bullet would. I'm all for cheating when it makes for a better experience and raycasting bullets is a great solution for many types of games, but the mechanics I've been working on really put the behavior of the guns front and center, so I really want the bullets to be part of the physics simulation.

I did find some tutorials and code examples that created bullets as rigidbody objects and applied force to them, which is the basic approach I wanted to use. There are some problems with this approach, however. First and foremost is simply that bullets travel very, very fast, and physics calculations only happen so many times a second. On mobile devices, those calculations tend to happen less times per second than on a desktop computer or console because there's simply less computing horsepower available. What can happen as a result, is that bullets can pass right through objects they should have hit. In one frame, the bullet is on the near side of the target, and by the time the next physics frame rolls around, the bullet is on the other side of it, and no collision is detected.

For a desktop game, this is easy to rectify; you just crank up the physics frame rate (which is distinct from the display framerate in Unity) so that the calculations happen more often. For a mobile game, that's not an ideal solution. You have to use the available CPU (and GPU) power efficiently on mobile if you want an overall experience to be good. Fortunately, there's a good solution to this problem on the Unity Wiki. You have your projectile do short ray casts in any physics frame where it travels far enough between frames to have missed a collision.

The bigger problem for me was trying to figure out just what values to use in the physics system. How much mass should the bullet have? How much force do we need to apply to that bullet?

The examples I found seem to have arrived at values by pure trial and error, and they all felt "off" to me. Many of the examples I found used the default mass value for the bullet, for example. In Unity, the default value of "1" is equivalent to 1 kilogram. If you've ever held a bullet, you know that it masses nowhere near a kilogram. Even the giant .50 caliber BMG round doesn't come close. You know what shoot bullets that weighs a kilogram? Battleships, not rifles.

Instead of taking the same trial-and-error approach to getting mass and force values that feel right, I decided I'd do a little research. There's a lot of science behind guns and a lot of people who are interested in guns, so I figured it couldn't be too hard to find real data on real bullets.

It ended up being even easier than I thought it would be. Wikipedia has gathered that data for pretty much every modern form of ammunition, including the exact mass of the bullet, the muzzle velocity, and the amount of energy used to propel the bullet to that velocity.

So, I gathered up that data for an assortment of assault, sniper, and high-powered hunting rifles in a spreadsheet. You can download that spreadsheet here, if you're interested.

Using the bullet's mass in Unity's physics system is easy enough. Just divide the grams by 1000 and that gives the value to use as the projectile's rigid body mass. But, how do we know how much force to apply to the bullet? Unity's documentation for the AddForce() method doesn't say what units it wants for input.

After digging around, I found that somebody had actually gone through the process of figuring out the answer to that while trying to counteract gravity for an object in their game. They determined that the AddForce() method uses 1/50th of a joule as its unit. Since we know how many joules of energy propel each of these modern bullets, we just multiply the number of joules by 50 and feed that value to the AddForce() method.

Great! But modern guns also spin the bullet as it travels down the barrel. In fact, the name "rifle" comes from the grooves in the barrel that cause that spin. After experimenting a bit, I came to the conclusion that for purposes of the game physics, rifling really isn't needed. Rifling helps deal with real world problem that just aren't present in the game's physics engine unless we add them.

But, I decided I still wanted the bullets to spin.

That may seem like an unnecessary bit of realism, but there's actually a reason for it. In some situations, like if you finish a level with a head shot, we're going to slow down time and follow the bullet to its target with the camera. It's a little clich├ęd, but it's still a cool effect when used sparingly. When we do it, though, I don't want people noticing that the bullet isn't spinning.

And they will.

In the real world, the twist rate of rifling is measured a couple of different ways, including revolutions per minute and the length required to complete one revolution inside the barrel. What it's not measured in is joules. And since this is just for show, I don't want to actually model the rifling into the gun's physics model, because that would be a lot of work and would force the physics engine to do an awful lot of calculations. Instead, I just want to spin the bullet right the moment it is spawned. Unity will let me do that in one line of code using the AddTorque() method. This method takes the same 1/50th of a joule input as AddForce().

But how much torque in joules should I add to the bullet's Z axis?

Honestly, I have no idea, and I really don't think it's worth spending a huge amount of time trying to figure it out since it doesn't actually affect the bullet's trajectory. I know it's a lot less force than is used to propel the bullet itself, so I'm going to start with a small number - 100 units (2 joules) - and see how it looks when we switch to the bullet cam. I'll then tweak the value if it doesn't look right. Sometimes trial and error is the right approach. Or maybe it's the lazy approach. Maybe it's both. Regardless, it's the approach I'm taking here.

I threw together a quick shooting gallery to test my real-world-based gun physics. Yes, it's an ugly shooting gallery. This is what you get when a developer throws something together quickly instead of asking his artists to make it for him.  Despite the ugliness, I'm actually pretty darn happy with the results. Here's what it looks like shooting a gun based on values taken from the .300 Winchester ammunition:

There's still a lot of work to be done on my gun class. I need to get recoil in there, for example, as well as muzzle flash. But, I've got most of the basics down for building a variety of weapons by simply configuring parameters in Unity's inspector. Change the weight and force and a handful of other parameters and you get a gun that behaves and feels very differently. Change the 3D model as well, and you basically have a new, different gun.

On a related note, my early prototypes used the gyroscope for aiming on mobile devices. It had a really natural feel that I loved, but it proved problematic when you zoomed in very far. The tiniest movements from holding the device in your hands would translate into very noticeable, unwanted movement. That movement actually felt like actual shake and scope drift, but beyond about 4x magnification, the game became basically unplayable. I spent some time trying to add stabilization and smoothing to the gyroscope input, but was never happy with the result or the amount of control we had over it.

After a while I admitted defeat and ended up ripping out the gyroscope code and replacing it with code that used the accelerometer for aiming. I then added scope drift back in algorithmically and created a parameter for it. That means we can easily change how steady a gun is when used. A rifle with a bipod, for example, will have almost no drift, while a large gun used while standing will have a fair bit more.

Thursday, October 3, 2013

Turncoat Dev Diary: Concept and Mechanics

As I mentioned in my last post, we now have dedicated game artists working on Turncoat, and we've mostly decided on the mechanics and basic structure of our first game. I'm not quite ready to announce the game's name or share much detail about it until we've finalized that decision and taken some administrative steps such as reserving the app and domain names.

For the first game, we've decided not to make it story-driven. This was a tough call, because our eventual goal is to create large, story-heavy cinematic games. However, we also need to run this as a business. Long cutscenes and story-driven plot would greatly increase the budget and timeline of this first game and probably wouldn't greatly increase our sales.

So, what we're doing is a game that's smaller in scope but set in the universe and takes place in and around the main storyline. Developing a more casual game will allow us to build up a library of game assets to eventually be used in the full story-driven game yet still keep a reasonable timeline for shipping something.

In the last post, I showed you the selection of gun silhouettes that Alex came up with:

We decided to start working with the silhouettes J and K (which are similar) for the first gun the player gets to use. I did a write-up of the characteristics of the gun and wrote a little in-universe history for it to help Alex while visualizing it. My thought was that the player would start with a more general purpose gun; something modular that came in several variants. We settled on an assault rifle that came in regular, sniper and tactical variants. After noodling around for a bit, Alex came turned that into these designs:

When he first sent it to me, I really wanted to find something that needed to be improved. I pretty much failed to find fault with the designs, though. They're pretty much exactly what I was hoping for. The only flaw I found was in the variant names. The "X" designation only applies to the sniper variant. The tactical variant is the RAR-14T, and the regular version is the RAR-14.

RAR stands for "Republic Assault Rifle", and it's pronounced "rawr fourteen".  I was originally going to drop the first R, making "Republic" assumed.  "AR-14" or "Republic AR-14" sounded more like a gun to me than "RAR-14". It turns out, there was a reason for that. The original name of the M16 rifle was "AR-15". Even today, the civilian semi-automatic variant of that gun is sold under the trademarked designation AR-15 by Colt. To keep our distance and not sound too derivative, I decided to stick with the original three-letter acronym pronounced like a word.

Patrick, our other game artist, took Alex's designs and started working on the 3D model for the gun. The model's not finished, but it's looking pretty sharp so far:

Meanwhile, needing a break from designing guns, Alex started working on concept art for the game's first level. We decided that the first level would be a shooting range on board a ship. Our earliest idea was to make a small, long, windowless range. In Deep Fleet ships, space is at a premium, so I initially wanted the space to feel cramped to reflect that, almost as if the designers of the ship had to make room for the rifle range as an afterthought. We explored that idea for a while, but after talking through it, we opted to go in a different direction. We decided that the first level the player sees needed to have a little "wow" to it, and a cramped, dingy range squirreled away in the bowels of the ship just wouldn't give us that. It makes sense in-universe, but it doesn't work for the game.

Essentially, we decided to let aesthetics trump in-Universe realities, and went with a range with large (very bullet proof) windows through which stars, the sun, or maybe even Mars or Earth can be seen. Alex isn't done with the concept art for the shooting range yet but he's off to a good start if you ask me.

The range has a large overhead window looking into space that prevents the room from feeling cramped or small. The shooting stalls can slide in for individual practice, or can be slide out for tactical training. The large pyramid above with the catwalks extending off of it is a holographic projector. Although some elements on the range are real physical items, the targets themselves will be projected holograms. We were originally going to go with targets that pop up the way they do on modern tactical training ranges, but then decided we wanted to go a bit more futuristic.

It'll be interesting to see how much of this changes before we ship the first version of the game, but so far I'm incredibly happy with the progress we're making. On the game mechanics side, I've been experimenting with the gryoscope and trying to make a decision about whether it can be used for certain game mechanics. What I've found is that it's quite well suited to certain situations, but not to others. For example, when you use a scope like the one on the rifle above, and zoom in far, the tiniest movements of your hands cause large movements in the scoped view. While this is somewhat realistic for shooting at long range - holding a gun absolutely perfectly still is impossible - it takes scope drift out of our control.

We need to be able to control things like that. How do we make a gun on a bipod more stable than a gun that's just held, otherwise? How do we make a large, heavy gun behave differently than a smaller one? Contrariwise, how do we keep them from stabilizing their device on a table?

No. Scope drift has to be something we have precise control over. It can't be a byproduct of our control mechanism.

Although I really like the feel of the gyroscope for shooting, I'm becoming convinced that it's not the right mechanism for this game. That being said, I think it might be the right way to control the view in at least some situations when you're not using a scope. The gyroscope is far more accurate than the accelerometer, and any control mechanism that requires screen touches would require screen real estate we're going to need for other controls.

We're making progress and I look forward to sharing more designs with you as we go along. Once we have our ducks in a row and have finalized the game's name and basic story, I'll also share that.

Tuesday, September 24, 2013

Turncoat Dev Diary: Visual Design Begins

We're starting to narrow in on our first game after putting the stealth game on the back burner. I'll be ready to share more about that in the next week or so. Today's post, though, is not about game mechanics, it's about the look and feel.

We've brought two excellent visual artists — Patrick and Alex — on board to help establish the visual style of our game universe and the first game.

You can check out Patrick's work at his Tumblr and on his blog. You can also follow him on Twitter… um… if you dare.

You can see some of Alex's stuff on his blog and follow him on Twitter.

I'm really excited to be working with these guys and can't wait to share some of the stuff they create.

In one of my next few posts, I'll talk about the mechanics of our first game, but for now, I'll just say that guns — and especially scoped rifles — are an important element of the game, so one of the first things I wanted to explore was what those guns might look like in the 24th century.

The process started with silhouettes. Alex came up with a sheet of different gun outlines based on both historical and modern weapons as well as taking inspiration from a variety of fictional sources. Here is a low-res version of the first silhouette sheet:

Talk about decision paralysis. So many cool looking guns silhouettes!

While we'll have multiple guns in the game when it ships and we'll eventually explore several of these designs, we have to start with one. Picking just one wasn't easy, though. Instead of deciding based on aesthetics, I decided to look at function. Our protagonist needs to start with a gun, but we don't want them to start with the coolest, fanciest, or biggest gun. Rather, we want them to start with something practical and multi-purpose. Both J & K looked to me like assault rifles that have been modified for sniping, and that feels like a good starting point for the default weapon. It's the weapon of a newly-qual'd sniper deployed with his or her squad.

So, Alex is now working on variations of J & K to come up with the design of the first gun our players will use. We'll be exploring some of the other silhouettes later and evolving those into finalized designs as well.

While Alex is exploring guns, Patrick has been exploring environments. The logical starting point for him was to create a rifle range for practice and training levels. We don't want players to worry about enemies shooting back at them until they've had a chance to at least try out their gun against inanimate objects, so Patrick is working on figuring out just what the rifle range on a 24th century spaceship might look like. None of the environment stuff is far enough along to share yet, but I'm looking forward to when we can.

Tuesday, September 17, 2013

Turncoat Dev Diary: Touch Controls are Hard… Let's go Shopping!

I haven't been making my "every week" blog post commitment for the last couple weeks. I apologize for that. There are few reasons on top of the ordinary work life busy-ness that have caused it.

First… well, touch controls are hard. I've got a partially written post exploring the use of touch controls for stealth games, but I haven't been able to hone in on something I'm 100% happy with. I've got something that I like better than any stealth-based iOS game I've found, but it's still nowhere near being shipworthy. Part of that is because this type of game grew up in the console world, where you have controllers like this:

Have you ever thought about the sheer amount of input that you can take through one of these modern joysticks?  The Xbox 360 controller, for example, has two analog joysticks, each of which allows analog input on two separate axes. That's four inputs that accept a range of values each, letting you (for example) not just specify that you want to move forward, but to actually specify the speed at which you want to move.

But there's actually another two analog controls on top of those. The left and right triggers are not buttons, they're also analog controls with one axis each. The harder you press them, the higher the value received. The DPad is the equivalent of eight tac buttons. There are four standard buttons (A,B,X,Y) and two shoulder buttons (RB, LB). Even without counting the start, Xbox, and back buttons, and without using combinations of buttons, we're talking about 14 buttons and 6 analog axes. Oh, but wait… each of the analog sticks can be pressed down and used as a button, so it's 16 buttons and 6 analog axes. If you count all the buttons, it's 19 buttons and 6 axes. You can also chord the A/X, A/B, X/Y, and B/Y buttons, allowing the equivalent of an additional four inputs.

That's an awful lot of input. These controllers are well designed, so you don't think about just how much data you're able to submit to a game using them, but as a game designer, it's something you have to think about.

If you look at the most successful and popular iOS games, they're not (generally speaking) copies of console games. There are exceptions, of course, like the recent Deus Ex game but, frankly, that one got by on its production value and franchise nostalgia. The controls are actually quite frustrating. A sloppy combination of direct manipulation, virtual joystick, and on-screen buttons that's hard to learn and hard to use.

I still believe that there's a way to do a stealth game on a touchscreen well without using an external controller, but I haven't found it yet. I think I'm going to put this idea on a back burner and return to it in a little while, maybe for the second or third game in the series. 

Another reason I haven't blogged recently is because I've been busy recruiting some pretty amazing artists to work on Turncoat. Pretty soon, I should be able to start posting some concept art and pictures of game assets. I'll tell you more about these artists in a future post but, for now, I will say that I'm super excited to be working with them and I can't wait to start showing you some of the art they create for the game.

So, where are we going from here? Well, we're probably going to be focusing on some high level look-and-feel stuff for the next few weeks and are also going to explore alternate game mechanics for the first game. It's important to me that the first game be really solid and also that it be produced in a timely manner. I just don't think that's going to happen with our original concept.

I'm also thinking about getting away from the prequel idea. There's something in the backstory that I was going to have to reveal if we kept going the prequel game as originally imagined, and it's something I really don't want to reveal yet for a couple of reasons. Instead, I'm thinking about focusing on origin stories for the main members of the squad. Everybody who gets recruited into The Squad, did something to get noticed. Some act of heroism, selflessness, or brilliance that caused the Squad's Commander to recruit them.

So, instead of going a hundred years in the past, we're going to only go back 2-5 years. We're in the same universe, dealing with a lot of the same characters, but they're not on The Squad yet. These will be fairly self-contained stories that can be told without having to reveal any of the secrets of the universe.

At this point, I know which character's origin story we're going to do first, but I don't know for sure the game mechanics that will be used to tell that story. I've got some ideas that I'm going to explore, though, so look for future posts.