Problem is with using 'realisitic speeds' of projectiles is the pure lack of animation which is part of customization. It also does not resolve issues of all possible physical movement based animations prior to emission of a projectile. Afrer all animation is more than just the projectile speed as there is more than the single animation pose of typical shooters happening in this game. Which also applies to melee application. Average human reaction speed in twitch combat games tends to hocer around .255 seconds. If character responsivenes is 'decent' as not 'sluggish at all' with little latency impacting reaction times we are starting off at a total animation speed - from first frame to final including trajectory based impact at .255 seconds. Even tripling that for all factors puts animations gives players plenty of reaction timing.

Fun fact, one particlar game has what is referred to as extemy slow animation making it a difficult attack to pull off. It does plenty of damage but in this fast paced game it takes either great skill or luck to pull off. That animation speed? 1.5 seconds. Lower than the average animation in the cityof games.

To summarize, players learn to read movements of characters just like they read body language on real combat. Animation time must acount for the first frame when any movement begins through any trajectory to impact. Either all the animations are designed to curb any possible twitch combat which results in alot of very fast animations all around, or we hold to our promises and design a game tat plays like cityof did with some different ways of handling certain aspects of combat so that even of handled differently the feel is the same.

Tannim222 wrote:

To summarize, players learn to read movements of characters just like they read body language on real combat. Animation time must acount for the first frame when any movement begins through any trajectory to impact. Either all the animations are designed to curb any possible twitch combat which results in alot of very fast animations all around, or we hold to our promises and design a game tat plays like cityof did with some different ways of handling certain aspects of combat so that even of handled differently the feel is the same.

And to refine the point that I was making, Tannim ...

Any sort of "Target Lock" functionality involving a TAB button would mandate the use of an [url=http://www.urbandictionary.com/define.php?term=Aimbot]Aimbot[/url] built right into the game itself, as opposed to being a 3rd party piece of cheater software. In the context of City of Titans, there aren't hit "locations" per se, so there's no bonus damage for making headshots (for example), so in that respect the playing field is level.

Which means that as far as reacting to a "realistic" projectile speed attack, what you'd really be keying onto is the animation prior to launching the projectile downrange. However, the Aimbot functionality wouldn't be "finalizing" the trajectory of the projectile until the "launching" of that projectile as part of the animation sequencing for the avatar.

So, simply for the sake of argument and illustration, let's say you've got a 1.5 second animation, where there's a 1 second windup and a 0.5 second recovery from firing a single shot. This means that at the 1 second mark, the projectile is launched. When it's launched, the Aimbot function computes the trajectory to use to hit the target and factors in the target's current velocity vector at the time the projectile gets launched towards the target. Thus, the only "variable" in the equation as to whether or not the projectile will hit or not is the velocity of the projectile (which could be very high indeed). This would therefore mean that if you aren't under (hard?) cover by the time the attacker's animation reaches 1 second, the projectile stands an excellent chance of actually reaching you and inflicting its effects. Bullet speed projectiles would arrive in 0.3 seconds or less (usually less) using ranging and target vector information from the time the projectile was launched, with the default target point being "center of hitbox" for best means of preventing a miss due to movement/changing vectors (ie. slopover margin of error).

So yes, the time to dive for cover is BEFORE the bullets start flying, as opposed to after ... which I personally would consider to be rather fair, all things considered. Since City of Titans is going to eschew a "cover" mechanic for damage reduction based on how exposed your hitbox is to incoming fire, the result is effectively going to be a system in which attacks made at closer range will be more likely to hit a moving target (just like you'd expect) due to the shorter interval of projectile flight time.

As for slow moving "homing" projectiles, those could be programmed to make use of the same Pathing System that NPCs use to move around and reach their destinations.

All of that said, it would still be a lot of fun methinks to also include extremely slow moving "breaching" projectiles that do tremendous damage like a slow moving Volume of Effect wrecking ball flying in a straight line that are easy to dodge by stepping out of the way. That way, you've essentially got a slow moving Area Denial power with a lot of "clobber" to them which amount to "don't stand/hover there" if you hate being punitively Debuffed (which could be Hit Points, it could be Mez, it could be a Drain, there's a lot of possibilities). So think more like Siege Engine of the battering ram variety, and how you wouldn't want to be where such a thing is striking (it would be "bad").

I was referring to blocking line of sight, as opposed to some sort of snap to grid system.

Tabula Rasa has a cover calculation system for it that was pretty simple. The target's hitbox was divided up into a 3x3 grid and a ray trace from each of the points on the grid got drawn back to the attacker. The number of line of sight blocks for that 3x3 array determined how much cover you had against the attacker. So crouching behind a terrain feature and shooting over it (such as a log or a ridgeline) or hiding behind a vertical feature like a wall corner or a standing tree offered cover. Thus, you basically got "credit" for how well you were positioned relative to your attacker (and vice versa). Very simple basic system. The 3x3 grid was just an "add them up" sort of deal with none of the elements weighted more in value than the others, and of course if the entire 3x3 grid did not have Line of Sight then the damage reduction from Cover was 100%, making you impervious to the attack (except perhaps by splash damage from an AoE). Also, in Tabula Rasa you could Crouch, which of course altered the shape of your hit box, making it easier to use terrain to your advantage.

This may sound complicated as an explanation, but when playing the game it was just smooth and seamless, and you quickly learned to seek cover against incoming fire, wherever it could be found.

So I was thinking specifically in terms of the PC deliberately moving into locations that block line of sight voluntarily, instead of having any sort of "snap to location" assistance from the game. Figured that was worth clarifying.

Snickerdoodle1429 wrote:

Input on the "Cover" mechanic, the only possibly way i could imagine this working is by having characters be able to "SNAP" to the environment... This is great for console games given the limited mobility of game controllers however in a PC world this game style feels very very clunky.. GTA V is exactly like that...boy is it frustrating when you are trying to move down an alleyway while you are snapping to all the walls and ledges along the way :/

+1

I dont think i would like that playstyle for my heroes. :{