Overview
Alright, so the basis is that you are always locked onto an enemy. Most games that use a lock-on system have it so you're free roaming until you physically hold down or press a button telling the game that you want to lock onto that enemy. While you are locked onto that enemy, your attacks will always be pointed toward whatever you are locked onto, and you will always face toward that enemy.
In my idea though, instead of making the camera face directly at the enemy when locked on, make only your gun point at the enemy. The camera can/will be free to rotate and zoom with the mouse. Splinter Cell is a great example of this, where the camera rotates around the main character as a center point, and opens the ability to see all around him easily without actually moving the character.
Anything in the room that is visible to be locked onto, will automatically be locked onto. That way when you decide to shoot at it, all you'll have to do is pull the trigger and it'll be shot at. When more than one thing is in the room, you'll automatically be locked onto the enemy that's closest to the center of the screen. Because locking on doesn't cause you to face the enemy, switching which enemy you lock onto is as simple as pointing the camera toward another enemy. As soon as the desired enemy is closer to the center of the screen than the currently locked on enemy, the crosshair will jump to the desired enemy making them the enemy of focus.
<!--
This is a prototype video demonstrating the lock-on system. It is using the Doom 3 engine with in game footage taken from the mod Chex Trek. The yellow indicator is added post production so I could visually see what it would look like. It is NOT actually coded into the game.
For a few more video clips of earlier prototypes, watch this video HERE.
Both videos use music created by Neurological.
Page 2 is all about implementation ideas.
In-Game Theories
<!--
<!--
An invisible line could be created from the current placement of the camera that gets refreshed continuously. The end point of that line is on whatever surface is in the center of the screen. In essence, the computer is constantly calculating an invisible laser pointer that starts from the cameras current position and ends at whatever it is facing. Whether or not this line is just code or if it is actual material that is just invisible is not known. I do know that it shouldn't be hard to code though because the link guns secondary fire is one long beam that stops at whatever surface it comes into contact with. Using the link guns code as reference could help.
Anyway, a constant check could be issued by this invisible line to see which enemy is closest to any given point on the line, and once that enemy is decided, assign the crosshair to be locked onto that enemies most current position.
So the invisible line checks to see which enemy is closest to any given point in the line. The computer reads its unique variable and tells the lock on crosshair to always be at the unique variable's position. As soon as that variable changes, the lock on crosshair jumps to the new coordinates.
One thing that I can see causing a problem is that enemies could be locked onto in the wrong order due to depth perspective. For example, if the line is doing a check to see which enemy is physically closest to it, then enemies that are closer to the camera will be closer to the line than an enemy that is all the way across the room and that is further from the line physically, even though it is closer to the center of the screen visually due to perspective.
To make things simple for the player controlling the camera, the enemy across the room should be the one locked onto because it is closest to the center of the screen and not the closest to the line.
I'm not sure of the easiest way this could be fixed. Perhaps devising a way to check what's closest to this line in a cone instead of pure distance from any point on the line.
That would actually work the best I think. Then the system could check all the way around the camera in a sphere like fashion until it reaches directly behind the cameras viewport direction. That seems fairly system intensive... I don't know, but seems like it could be. So to cut back on resources, the distance check code could have checks within it to tell the system to stop searching out for enemies as soon as one is found, and just restart the search from the center point again. It would only complete the entire sphere if nothing is found before it gets to that point.
