Hmmm, I believe both styles you mentioned are examples of 3rd person cameras. The only qualifier being the Playable Character being rendered in a 3D environment within the view frustum so as the player can see them. Usually the PC (or the camera) will be latched, and offsetted so that they both stay within a relative position of one another regardless of where they are in World Space.
Insofar as turning the character with the camera being turned is a matter of gameplay, and style. I wouldn't care for such a feature in a platformer, but in other genres, or sub-categories (actually thinking of the Hog vehicle in Halo) it works ok.
I don't know your background in Game Development, or what experience you may have in any frameworks/engines/APIs, but if you want some nitty gritty on camera systems this site has plenty of articles

What's wrong with being a Sonic Ripoff? The early Sonic games kicked butt. Unless you're ripping off the new ones O_o Take what they did in Sonic, and improve on it. Taking in what they did, distilling it, see why it worked, and do it better. Greatness is usually achieved by standing on the shoulders of those who came before you.

It's almost impossible to find design that is 100% unique in this day, and age. Art Style, Good Design, and more important than all of that is the fun factor. If the game is fun, that's all you really need. Of course, the former certainly lend their hand to the latter. But game design should never be focused in making it as "Unique" as possible, but as intuitive, and fun as possible. If that's a philosophy that is echoed a lot, than maybe there is a science to that.

kinda looks like a bias issue. the depthmap is of limited precision, so shadow acne (shimmering), or peter-panning (shadows that are biased too much, and become dis-attached from the occluder) are usually related to biasing.
What value do you have in your second pass pixel shader that serves as the bias? Maybe try toggling that a bit, and see what it gives you, it can be very scene dependent.

This is the nature of contracting out your workloads for a, "confidential product" If you simply cannot trust anybody with the workload you plan to give them, than you simply need to learn how to do it yourself. You could always attempt to STIFF the workstation they are likely to use. I.e. disable USB ports, setup web-proxies, ect.
But even than, there is always a work around.

Have them sign an NDA. It really will come down to Contract law. Obviously, once they have access to the source, they have access to the source. You can't force your contractors to not be nefarious, but you can certainly promise legal repercussions to such actions.
You may want to get an Attorney, or at least schedule a consultation with one. At the end of the day, "trust" is the keyword here. If you have any reservations of the people you are onboarding, then simply don't bring them on.

haha, manually tagging each one would be a pain for a large map. When you initially create your tiles, loop through them, and assign the respective tile type. So let's say, a trivial example, I'm utilizing an array for my data set for tile creation. 0 = side_walk, and 1 = road
like so:
int map [] = { 000000111000000
000000111000000
000000111000000
000000111000000
000000111000000
000000111000000 };
You may be using a different data set for your map creation, an image, a text file, whatever, but the key is to know what data you're working with to generate your tiles, and to give it meaning within your application.
So with the above example, since I've denoted 0 = side_walk, and 1 = road. I can loop through my dataset, and create my tiles with those appropriate types in mind
like so:
for (int i = 0; i < MY_ARRAY_SIZE; i++)
{
if (map[i] == 0) myMapVector.push_back(new Tile(SIDE_WALK));
if (map[i] == 1) myMapVector.push_back(new Tile(ROAD));
}

Are you talking about excluding the road from a search area? Say like excluding it from the Open List of an algorithm like A*. If so I'm assuming you already have some internal structure representing Tiles. You could expound on this by adding an enumeration for type. like, uh, say
enum tile_type { ROAD, SIDE_WALK, DIRT, ECT };
And than just conditionally parse through your tiles come search time and omit the tiles you don't want in the proposed search area.

Have you given RPGMaker a shot? Considering you already know Ruby, it should easy for you to modify the default battle system within the engine. If that's not an option, there are a plethora of engines available for general purpose uses. Unity, Ogre3D I think is one, Unreal, ect.
If you find no engine that meets your need, you could always just program for your game at the API level. Though, that's usually not very conducive to pushing out anything fast.

And how is that working out for ya?
I don't see the significance of a real one either.
No, I guess I'm to busy making games.
You seem to forget, whilst your making long winded posts justifying your ideas existence (Evidently due to the lack of outside validation) that we're here to make games. We're here to make fun interactive experiences, and to help others to do so. We're not here to validate you in any sense if we see nothing worth validating. If you have a problem with that, there is a phrase in the Anglo-Saxon language known as a, "Personal Problem".
Nobody wants your idea. Your disillusions of grandeur couldn't be more self-evident. If you choose, at some point, that you want to implement your idea. I think you'll be pleasantly surprised at this community, and it's dedication to prospering hobbyists. You don't need to spill the beans of your revolutionary idea either to receive this help.
We are anxious to see your game. It couldn't be more obvious from your text that you are indeed enthralled with it. I'm sure every member here would love to be engaged in this euphoric simulation as you so proposed. So what are you waiting for? You're on a site called, "GameDev". Go develop your game.

It's a complete shot in the dark, but how about implementing the dot product yourself, and seeing what that yields? I once ran into a similar issue with a pow() method in a mobile environment where on one device it would give erroneous results, and on the other correct. Though, haha, it was a mobile environment.
But, yeah. The dot product is a relatively simple operation to implement, and other than tooling around with your drivers, you can eliminate that as a variable. Though, tbh if you are experiencing this same issue on different generations of GPUs, i'm not sure it's the right direction either. But, hey who knows.

The biggest issue here is your referencing D3D11 materials, and trying to apply that to 12. These APIs may have similar looking methods, but they couldn't be any further apart in the pipeline configuration. I only know a little about 12, but I'm pretty sure there wouldn't be an easy way to integrate the deprecated effects framework with it, not at least without getting very creative.
The shader itself may accomplish pushing the vertices/texels to the rasterizer, but that still doesn't address the multiple issues you may have on the app side. Especially with 12...Are you syncing correctly? Are you handling your command Allocators, and Queue appropriately? How's does the PSO look? Even in D3D11 you had a lot of points of failure. D3D12 is even worse.
I'm gonna parrot your previous thread and say use PIX at the very least. Or, if nothing at all. At least use the built in Visual Studio Graphics Debugger so you can ascertain which stage may not be running.