[CvC] Call of Duty : Pythagorean Warfare

[Anaximander]

I dont think outrunning missiles is going to be a thing. Devs have illustrated that hit/miss is going to be based on skills and armor and that no attack will exist in the universe it will simply be a graphic. My guess is balance to missiles will be the cost, maybe range(fuel) and possible something like an anti-missile turret. If you have one it will take energy but will increase the miss chance of missiles attacks by some amount.

Well, the fuel part can be "researched" in by the player manufacturing rockets to give them an extra bonus in range of engagement for exmaple, or research the warhead of the missile, to add a greater damage bubble to each hit. Missiles, are the ammunition, not the weapon itself. The Missile Launcher can be, for example, researched to be able to reload faster, or have more barrels so it can shoot two missiles at once in its "Missile Launcher Lv. II" stage.

 

Armor by the way, comes in the form of Voxel HP (and possibly other gimmicks). For example, Cermanic Steel has a greater resitsnance to energy weapons but takes more damage from Kinetic weapons, while Titanium has a better reistance to Kinetic weapons but not against Energy weapons.

 

The lateral speed (the direction and angle in which you fly) is what dictates the miss chance and I firmly believe a weapon's "projectile speed" is what will dictate how much of that speed you can counter.

 

As of skills, I'm thinking of skills like Gunnery Training , then, Target-Leading, which reduces the enemy's speed bonuses by a certain margin.

 

The "miss chance", as I explained, could be dictated by random dispersion patterns in a cone of fire of weapon, with the cone of fire being narrower the longer you lock-on on a target before firing. If your target is 1% of your Cone of Fire surface area, chances are you'll miss all of your shots on the target, but if you reduce that cone of fire by taking time before shooting - with a kinetic weaponry as I said in my Original Post - you reduce the cone of fire, therefore you increase the chance of a Damabe Bubble occuring on the target's construct.

[Ripper]

If ships can jump to FTL, then I see no reason why a torpedo couldn't.

 

FTL torpedos would be faster than a laser, by definition.

 

I don't think any other form of combat should be possible in FTL, because the ships are already traveling faster than the munitions.

[Anaximander]

If ships can jump to FTL, then I see no reason why a torpedo couldn't.

 

FTL torpedos would be faster than a laser, by definition.

 

I don't think any other form of combat should be possible in FTL, because the ships are already traveling faster than the munitions.

... you can't even see someone in Warp, the universe bends around them :|

 

This is why ships will be possible to be pulled out of warp via interdiction fields. :|

 

Also, good luck getting into FTl in combat, the Devs will probably add a warm-up session for the FTL that requires the ship to not be in combat. If you are in combat, good luck going to Warp. :|

 

[Ripper]

I would prefer combat to be sub-FTL

[Lethys]

If there is no mechanic to pull someone out of ftl, then it will just be broken

[LurkNautili]

What you're describing is essentially mathematically equivalent to FPS (raytrace with cone of fire). Haven't they already stated that they won't have twitch based combat mechanics? I mean as an FPS player I'd love nothing more, and I've argued for it in the past -- but as it stands the developers seem set on having a system where you merely lock on to targets (i.e. target acquisition, impact probability, etc. are hidden behind abstractions rather than being simulated FPS style), fire, and then have some statistics (like shielding, piloting skill or whatever) based math figure out location and severity of damage and so on.

[Anaximander]

What you're describing is essentially mathematically equivalent to FPS (raytrace with cone of fire). Haven't they already stated that they won't have twitch based combat mechanics? I mean as an FPS player I'd love nothing more, and I've argued for it in the past -- but as it stands the developers seem set on having a system where you merely lock on to targets (i.e. target acquisition, impact probability, etc. are hidden behind abstractions rather than being simulated FPS style), fire, and then have some statistics (like shielding, piloting skill or whatever) based math figure out location and severity of damage and so on.

It's not twitch-based and it's not Simulation. FPS games have simulations, they simulate gravity on bullet drop and momentum loss that way and the Projectile itself a PHYSICAL presence in the game.

 

What I am describing, is an emulated version of that. It is emulation of FPS. There are not projectile bullet drop, there is Target's Speed and Muzzle Velocity, then it comes down to the Surface Area of the Target that is exposed to you in comparison to your Cone of Fire at such a distance, then how much your skills reduce your Cone of Fire to beigin with and a weapon's quality on Damage Bubble Dispersinon.

 

There's no Simulation in this. Simulations cost, Emulations are simple stat comparisons.

 

Think of the above mentioned "mining bubble". If you fire at a person's ship, a bubble would spawn at the person's location randomly, with its frequency depending your weapon's rate of fire as its "casting time" - if I was to use a WoW term - and its magazine size determining how many Damage Bubbles can be spawned before the weapon needs reloading.

 

 

WoW does this. EverQuest does this. Every MMO that utilises a form of Lock-on does this when it comes to Area of Effect Skills.

 

 

If you cast a Flame Strike in WoW, you click on the skill, then move your cursor to an area you want the Flame Strike to hit, then cast the spell for two seconds at the expense of Mana.

 

That in DUAL, would be in the context of scanning the target, then locking on the target for a moment or two to reduce your "AoE" Cone of Fire, then firing.

 

 

I would not call WoW as a First Person Shooter. If you did because of the aforementioned mechanic, then you clearly missed the memo on what an FPS simulated physics' grid is.

 

 

So no. What I propose is not First Person Shooter simulation. It's First Person Shooting emulation. 

 

 

Emulation is NOT Simulation. Emulations are cheap, simulations are not.

 

[LurkNautili]

It's not twitch-based and it's not Simulation. FPS games have simulations, they simulate gravity on bullet drop and momentum loss that way and the Projectile itself a PHYSICAL presence in the game.

 

Not all FPS games by any stretch of the imagination. For example, Quake is pure hitscan without any such simulation, and CS:GO is a game with a model similar to yours, where you have a cone-of-fire inaccuracy model.

 

 

What I am describing, is an emulated version of that. It is emulation of FPS. There are not projectile bullet drop, there is Target's Speed and Muzzle Velocity, then it comes down to the Surface Area of the Target that is exposed to you in comparison to your Cone of Fire at such a distance, then how much your skills reduce your Cone of Fire to beigin with and a weapon's quality on Damage Bubble Dispersinon.

 

There's no Simulation in this. Simulations cost, Emulations are simple stat comparisons.

 

What you're describing sounds exactly the same as a typical arcade type FPS shooter where ballistics aren't simulated. The problems the devs are highlighting as reasons not to do this come from the fact that firing events have to be networked between clients and servers, and the way they're doing their clustering or octree division of space into cells results in more delay from further away players and with less frequent updates.

 

Mind you, personally I've argued that you could probably still implement at least some semblence of a twitch shooter on top of such architecture, but I've yet to receive a response from the developers to my question post regarding this topic, so I cannot say for certain that it could be done. But some sort of compromise could probably be arrived at.

 

Rather, what the developers seem to be aiming for at present is a system where you merely "aim" at a target merely to indicate the entity/construct which you wish to fire upon, and then instead of doing ray-intersections and interpolation and lag compensation and all the other funky business that you have to deal with in shooter netcode they'd just do some kind of heuristic approximation of damage based on stats and maybe relative acceleration and such. So in that model there wouldn't be any "cone of fire", per se, but rather a probability value calculated server-side. This could, of course, be represented by a circle on the players screen to give visual feedback about the probability but the actual math running server-side wouldn't have anything to do with cone or ray intersections.

 

And again, I'm not for this personally and will be sad if we can't have something that at least resembles twitch shooting, at least in avatar vs. avatar combat (ships I can believe would have automated targeting so it won't wreck my immersion as much).

 

 

WoW does this. EverQuest does this. Every MMO that utilises a form of Lock-on does this when it comes to Area of Effect Skills.

 

 

If you cast a Flame Strike in WoW, you click on the skill, then move your cursor to an area you want the Flame Strike to hit, then cast the spell for two seconds at the expense of Mana.

 

That in DUAL, would be in the context of scanning the target, then locking on the target for a moment or two to reduce your "AoE" Cone of Fire, then firing.

 

 

I would not call WoW as a First Person Shooter. If you did because of the aforementioned mechanic, then you clearly missed the memo on what an FPS simulated physics' grid is.

 

As someone with some experience in reverse engineering MMORPG netcode, I feel fairly confident in saying they don't use CoF. Rather, they keep track of player positions server-side (with noticeably lower frequency than FPS, usually, mind you), and when a client fires an AoE spell, they create a circle (basically a cylinder volume) on the ground and simply test intersection with that, which is a really fast and inexpensive process, also it's less time-sensitive than shooting bullets -- as well as less frequent -- and it's precisely placed on the ground rather than being randomly placed based on some probabilistic spread. Also, lock-on attacks don't even have to involve dodgeable area of effect spells, which are actually kind of similar to FPS (in that they suffer from the same problem of having to maintain consistency of events in different clients, like whether I actually dodged a spell on your screen or not). In its simplest form a spell is just something that either hits or doesn't based on some evasion change and hasn't got to worry about netcode. A game like guild wars is surprisingly similar to FPS in terms of what the servers have to do, and as such I feel the devs are just as unlikely to implement your type of avoidable cone/circle of fire AoE attacks as they are to implement FPS.

[Anaximander]

Wall of Text

Have you even bothered looking at the game's overall workings ? :| I'm convinced you haven't.

 

 

The idea I propose operates on the same logic as casting an AoE spell, with the turret locking onto a target construct and spawning damage bubbles in a cone surface area on the construct the weapon is aimed at. That's because of the Devs already saying they are planning using the Voxel editability to emulate damage on ships. The damage bubbles, are the same thing as the mining bubble used in videos when they dig a place. Now, if the Gunner on the Turret has skills invested, their cone of fire is tighter, thus the area they spawn damage bubbles is minimised. The probability of the damage bubbles hitting the target construct, are proprotional to the target's print on your Cone Of Fire. If their print is 50% , then those bubbles have 50% chance of spawning on the construct itself, with accuracy and the SIZE of the bubbles, dictating the rest. A missle may do 5 meters radius damage bubble, while a torpedo may do 25 meters in radius, thus damaging the enemy construct in its explosion, rather than a direct hit. Furthermore, the "animations" of the missiles, lasers and torpoedos, are a visual indicator of "incoming damage" to the enemy, NOT physical projectiles. They are the fireball a mage casts in WoW, that takes 1.5 second to hit you at max range, giving a warrior the time to pop up the Spell Reflect.

 

 

And since you went technical, let me go techical. Source Engine is a modified Quake Engine, that's why both CS : GO and Quake are Hitscan based, because they were developed for those 90s era "3D" games, and that's why CS : GO is a twitch-based shooter, it requires reflexes to hit someone. In Planetside 2 for example, your weapon has a muzzle speed factor, which determines how fast your projectile flies and the projectile is physical, which means, it can be intercepted. That's also a twitch-based shooting game.

 

 

Dual, acts on a model called Active Lock-On, check TERA Online for more info, which is basically a mouseover targeting system, with your reticle acting as your mouseover.

 

In WoW, if you macro'd a skill to be acted on a mouseclick over, you could hold your mouse over someone, use Blind as a rogue and blind them without going into portrait targeting on them. DUAL's Avatar V Avatar operates on that principle. Its bullets do NOT teleport right on the target. If the target moves, there's a comparison of geometrical distance between you and your target, your weapon's muzzle speed and the target's lateral motion.  If you move to your left facing them and the target moves to his right facing you, then the lateral motion is reduced, leaving only distane + speed to determine hit chance. If the distance is X and your weapon has 2X muzzle speed, then you are guaratneed to hit the target no matter what. THAT, is called an Emulation. There are no physical projectiles, it's all math and values. It doesn't take into account factors like people stepping in the path of the bullet, because it is NOT a simulation so to have phyiscal projectiles.

 

So no, it's not a twitch-based shooter like CS : GO, because CS : GO has no skills that dictate CHANCE TO HIT, nor does the range between people matter, as bullets teleport.

 

[LurkNautili]

Have you even bothered looking at the game's overall workings ? :| I'm convinced you haven't.

 

I have, in great detail. I wasn't going to back something I wasn't convinced was possible to accomplish -- so I read up on it. All the dev blogs, all the KS updates, the whole KS page, many forum threads... etc.

 

 

The idea I propose operates on the same logic as casting an AoE spell, with the turret locking onto a target construct and spawning damage bubbles in a cone surface area on the construct the weapon is aimed at. That's because of the Devs already saying they are planning using the Voxel editability to emulate damage on ships. The damage bubbles, are the same thing as the mining bubble used in videos when they dig a place. Now, if the Gunner on the Turret has skills invested, their cone of fire is tighter, thus the area they spawn damage bubbles is minimised. The probability of the damage bubbles hitting the target construct, are proprotional to the target's print on your Cone Of Fire. If their print is 50% , then those bubbles have 50% chance of spawning on the construct itself, with accuracy and the SIZE of the bubbles, dictating the rest. A missle may do 5 meters radius damage bubble, while a torpedo may do 25 meters in radius, thus damaging the enemy construct in its explosion, rather than a direct hit. Furthermore, the "animations" of the missiles, lasers and torpoedos, are a visual indicator of "incoming damage" to the enemy, NOT physical projectiles. They are the fireball a mage casts in WoW, that takes 1.5 second to hit you at max range, giving a warrior the time to pop up the Spell Reflect.

 

You could have something functionally equivalent to that but there wouldn't be any aiming involved, since by definition that would constitute twitch/FPS combat. Also your use of the term CoF is peculiar, seeing as it implies that some kind of ray/cone-intersection is happening, which seems unlikely at least in any aimed sense. You could define an area on the ship to target but calling it a cone of fire is reduntant as it doesn't actually simulate firing projectiles as you yourself point out in your "emulation" vs. "simulation" speech.

 

 

And since you went technical, let me go techical. Source Engine is a modified Quake Engine

 

The two have about as much in common as Quake and Guild Wars 2, despite being distantly related. Point being that all multiplayer games have similar mechanisms with netcode. Most employ some kind of client-server infrastructure with a central server that does most of the simulating (whether that's a ray-intersection or proper ballistics doesn't really matter) and then relays changes in state to clients, with some rare exceptions having peer to peer networking models (e.g. my beloved GunZ the Duel).

 

 

Dual, acts on a model called Active Lock-On, check TERA Online for more info, which is basically a mouseover targeting system, with your reticle acting as your mouseover.

 

In WoW, if you macro'd a skill to be acted on a mouseclick over, you could hold your mouse over someone, use Blind as a rogue and blind them without going into portrait targeting on them. DUAL's Avatar V Avatar operates on that principle. Its bullets do NOT teleport right on the target. If the target moves, there's a comparison of geometrical distance between you and your target, your weapon's muzzle speed and the target's lateral motion.  If you move to your left facing them and the target moves to his right facing you, then the lateral motion is reduced, leaving only distane + speed to determine hit chance. If the distance is X and your weapon has 2X muzzle speed, then you are guaratneed to hit the target no matter what. THAT, is called an Emulation. There are no physical projectiles, it's all math and values. It doesn't take into account factors like people stepping in the path of the bullet, because it is NOT a simulation so to have phyiscal projectiles.

 

So no, it's not a twitch-based shooter like CS : GO, because CS : GO has no skills that dictate CHANCE TO HIT, nor does the range between people matter, as bullets teleport.

 

Let me break this down for you.

 

If you're saying:

We should have a system where the server keeps track of projectiles as they travel through space, simulate their movement, and they have their velocity set by the player aiming at a point in space around them-- that's basically how shooters work, and that's the kind of system the devs have stated they won't be making (though I disagree with this decision). It doesn't matter whether its hitscan, whether you model bullet velocity or other ballistics or whatever -- the same networking problems arise in any such case, which is the devs' cited reason for rejecting such a system.

 

If you're not saying that:

Why do you introduce the notion of a cone of fire at all? Why do you talk about having to lead your targets? If the player him-/herself doesn't do the aiming, all of that is delegated to the server and the latency issues disappear. This is the model the devs are currently planning to implement. Casting your spell at a target (or a given portion of them) and calculating the damage and probability of impact does not require the notion of a cone of fire on the client side, or aiming on the client side -- or on the server side for that matter. It merely entails plugging some numbers into an equation (which will have some spatial component, but won't involve time-sensitive simulation steps like intersecting rays or cones with volumes) that pops out damage values for given voxels.

 

If you mean the latter -- we're (probably) in agreement, but your description of it is quite misleading and has confused me this whole time.

 

 

[EDIT] Oh and by the way, it looks like TERA's combat is FPS (you aim and fire projectiles which the server tracks, and you probably have some kind of lag comp as well, though that doesn't matter it would be FPS without it anyways) unless I'm missing something. Can attacks miss if you aim off target? If not, then it's just a client-sided UI thing that allows you to have "aiming" but it's just a wrapper on top of essentially what I described in the latter chapter.

[EDIT2] Fixed above edit.

[Anaximander]

 

Let me break this down for you.

 

If you're saying:

We should have a system where the server keeps track of projectiles as they travel through space, simulate their movement, and they have their velocity set by the player aiming at a point in space around them-- that's basically how shooters work, and that's the kind of system the devs have stated they won't be making (though I disagree with this decision). It doesn't matter whether its hitscan, whether you model bullet velocity or other ballistics or whatever -- the same networking problems arise in any such case, which is the devs' cited reason for rejecting such a system.

 

If you're not saying that:

Why do you introduce the notion of a cone of fire at all? Why do you talk about having to lead your targets? If the player him-/herself doesn't do the aiming, all of that is delegated to the server and the latency issues disappear. This is the model the devs are currently planning to implement. Casting your spell at a target (or a given portion of them) and calculating the damage and probability of impact does not require the notion of a cone of fire on the client side, or aiming on the client side -- or on the server side for that matter. It merely entails plugging some numbers into an equation (which will have some spatial component, but won't involve time-sensitive simulation steps like intersecting rays or cones with volumes) that pops out damage values for given voxels.

 

If you mean the latter -- we're (probably) in agreement, but your description of it is quite misleading and has confused me this whole time.

 

 

[EDIT] Oh and by the way, it looks like TERA's combat is FPS (you aim and fire projectiles which the server tracks, and you probably have some kind of lag comp as well, though that doesn't matter it would be FPS without it anyways) unless I'm missing something. Can attacks miss if you aim off target? If not, then it's just a client-sided UI thing that allows you to have "aiming" but it's just a wrapper on top of essentially what I described in the latter chapter.

[EDIT2] Fixed above edit.

You can't intercept projectiles mid-air in TERA. If I shoot an arrow at someone and the animation is over, even if someone steps in front of that target my attack is meant for (after my attack animation is over), the arrow will pass through the target tthat stepped in btween and hit the target behind them. When you "lead" a target in TERA, you simply begin an attack animation and estimating where they will be when it's over so the hit can home into them. It seems like Call of Duty, but it's not. The projectiles can trael through wall and Home-in to someone you've locked the attack onto.

 

Same thing I'm suggesting. You LOCK on a construct (the ship has a Core Unit as you know, which is the centerpiece of the ship, that creates the voxel rig in which it declares its own). Any attack or damage calculations is homed towards THAT construct and your turrets follow THAT construct from that point onward. The cone of fire, dictates where the damage bubbles will happen and by "compensating" as I suggested, you narrow the cone of fire to get more concentrated groupings of damage bubbles on the target before you fire the turret. You keep track of 1 construct and as far as the server is concerned, you are calculating damage against 1 particular construct.

 

Think of it this way. When you Lock-On a target, you acquire their telemetry, or their distance and keep track of that distance. That's the height of the Cone of Fire with your POV being the Appex (or Vertex w/e). The weapon itself, has a starting Cone of Fire, given its quality or level of research or anything. That Cone of Fire, is then reduced by the skills the player has (which are all passive, check on EVE's skill system the devs took inspiration from). Those skills, give you a better STARTING angle at which the cone starts in, then with other skills, you speed up the time it takes to compensate fully (100% Lock-On) and reaching the weapon's predifined MINIMUM Cone of Fire. 

 

Now, given the distance between you and the target (which you keep track of regardless), the server compares your weapon's speed and arranges when the damage bubbles will pop up around the area of the target (given their angle towards you when you fire) and given the target's speed, it arranges a random pattern around them. IF your weapon's projectiles move slow, tough luck, your chances are minimised, if your weapon is fast, you get more consistent hits. The initial lock-on emulates "leading" the target. You know, it's not actua leading, the gameplay mimicks that part.

 

Now, if your target is LARGER than your minimum cone of fire (or however much you let it compensate), then you are guaranteed the Damage bubbles will spawn with precision on the target's armor, or maybe you went for an engine, therefore destroying the engine. If the target though is 1% of your minimum Cone of Fire (which means they are either too small to hit, or too far away), the damage bubbles spawn around them, but don't actually hit them. 

 

Beyond that, your weapon may have explosive rounds or whatever, which may cause a LARGER Damage Bubble, which can cause some grazing hits to the target. The Devs have said the damage bubbles will spread damage, which means a uniformal pattern (Youtube AMA video). Or your weapon may have armor piercing rounds, which would be emulated via a smaller damage bubble, for higher damage on their epicenter. If you did your job properly, you will get 10 or 20 rounds on the same spot with your AP rounds, which means you gut the enemy ship.

 

 

Tell me which part of that is twitch / reflex shooter. You would be seeing the enemy from thousands of kilometers away coming towards you and you only have to :

 

1) Lock-On

2) Compensate

3) Fire at the right moment, to maximise your damage bubbles on their construct.

 

While your ship's navigator or pilot, only has to :

 

1) minimise the area of exposure or bringing the reinforced side of the ship towards the enemy's turrets.

2) maneuver before the engagement to goad the enemy gunners in firing with less accuracy.

3) fly the ship in an angle that maximises the gunner's target surface area.

 

If you can't see the difference in that and a twitch shooter, then I can't do much about it :| It's an adaptation of the Tab-targeting system which is what the Active Lock-On system is. You don't point and click on a target, you got to keep them in your crosshairs to lock on to them and have to do it every single time to keep attacks landing. That's how TERA works and that's what I'm suggesting here. An Emulation of FPS gameplay for CvC. And what I suggest is a very very VERY cheap emulation to do. Once you Lock-On, you only got to be patient and don't act too quickly or panic, which is something twitch-shooters lack and can't bring to the table when it comes to tactics. Trigger discipline, which is what JC was referring to when he said the combat would be more about tactics. These examples I provided? That's called tactics. And since ammo is limited on a ship, those twitch-monkeys who can't be patient and see camping and patience as [insert homosexual slur here], will be disregarded by serious organisations, as they would be money-sinks when it came to Hit/Miss ratios. Bullets cost mate

 

Cheers!

 

P.S. : Source Engine is a modified Quake Engine, no matter how you spin it. Its hitscan methods can't be neglected because of the gravity gun Its real saving grace is that it is in active development for the past 12 years, but unless they add bullet physics, they will still be like father like son to me.

 

[Velenka]

That cannot happen though, because at long distances the refresh rate is slower. The lateral movement and player skills along with weapon stats can emulate that leading while not having to actually lead the target.

 

 

As for missiles, you forget that missiles have fuel. That means that the missile mechanics can work in a much shorter cone area, and they are unavoidable, since they are smart missiles, they will guide themselves to the enemy.

 

I disagree. I say it can happen.

 

Shorter range is another balance solution, but there's no reason they need to be smart missiles. Not all missiles need to track. Those which are smart will have higher accuracies than ones that don't.

 

And it doesn't just matter if missiles cost a lot. They need to be balanced in a strategic sense, also.

[Anaximander]

I disagree. I say it can happen.

 

Shorter range is another balance solution, but there's no reason they need to be smart missiles. Not all missiles need to track. Those which are smart will have higher accuracies than ones that don't.

 

And it doesn't just matter if missiles cost a lot. They need to be balanced in a strategic sense, also.

Well, we can have missiles for ships and torpedos for static targets, like space stations, with torpedos having a larger blast radius but being impossible to to hit a very agile target.

 

As I said, they are balanced by the fact they are meant for shorter ranges. You can't make a grenade deal the same damage as a 7.22 bullet, nor you can make an assault rifle have the same effective range as a grenade's blast. Missiles bring variety of warheads involved. EMP missiles for example. If a ship's shields are down and you got the missiles you go for the engines (if you can that is).

 

And the missiles can have material cost on their manufacturing dictating how powerful they are. They are not slubs of copper or iron you put in a railgun and shoot them. They have intricate parts and the fact they can compensate for a ship's speed is also requiring high-grade computation, thus the reason for their cost becomes apparent. Given that missiles can be researched by a player even deeper, the missiles may be getting more blast radius in their explosion more range, at a material cost. It balances out on its own.

 

 

And as of strategy, a faction that manages to have very very deep pockets, should be able to have ships with only rocket launchers on them and demolishing their opposition. Counter-play to that you may ask ? EMP blasts. They are missile launchers, they are not immune to EMP. :|

 

 

So yeah, the damage types are solid on the balance department.

[LurkNautili]

[snip]

 

So... I guess the latter, then? I reckon we might be in agreement, and that I've been thinking about a similar system as a compromise for avatar vs. avatar combat (thought about making a thread outlining it but haven't gotten around to it) with possibly one key difference, but I won't get into that here.

 

However, there are a couple of things that confuse me about the way you phrase things.

 

Firstly, it's not quite clear what you expect to be happening on the client side and what on the server side. It seems like you're saying that the client will determine a cone of fire based on some stats (I still maintain that relative velocity isn't what you should be using to determine degree of inaccuracy, as it can be compensated for with a simple galilean transformation that any targeting computer or even human can do -- rather it should be factors like changes in velocity, recoil of the weapon etc.), which then determines where you'll be doing damage. This then would be sent to the server to do some calculations based on shielding etc. and then to actually do the editing of the voxels. While this might seem OK on the surface, it's actually a terrible idea to let the client do much of anything aside from acting as an interface for the user, since otherwise you make it trivial for people to cheat by pwning the client or by messing with the outgoing packets (i.e. just place the "damage bubbles" where you want and the server will either just accept it or you'll have to implement some weird heuristic type checks on the serverside to screen all the inputs from clients). So it's better to have those sorts of things on the server. You spend a lot of time talking about a sort of general mathematical model for for depicting accuracy (with some slightly weird notions about what affects sizes of groupings) but you don't really address the practical implementation, which is at the crux of actually developing a game, and sort of the point I've been trying to get at.

 

Secondly, the part where you talk about "firing at the right moment" sounds concerning, since timing critical operations are exactly the sort of thing the devs are saying rule out twitch based combat. FPS based combat in terms of the networking (which is the limiting factor in their architecture) is basically about firing in the right direction at the right time. Having the "at the right moment" aspect in your design makes it basically at least half-FPS, since you still run into the same problems regarding varying update frequency from cells further away (with maybe delay as well when you account for waiting for interp) -- which JC has pointed out as reasons not to have FPS mechanics.

 

So if you actually track a player's view ray server side (the cone you're referring to) as well as log precise timings associated with firing the weapon "at the right time", you've basically got an FPS networking model -- which is ruled out at present by the devs. If you have that on the client side, then that just allows people to cheat very easily. Basically what you could have is a visual representation of aiming client side with UI like a targeting reticule or whatever that you move onto a target to "lock", which is just an abstract way of saying to the server "I target this ship over here". Though if you make it a tricky thing to do on the client side then people can still cheat away the skill portion of that, so I'm not convinced about that idea either...

 

And by the way, Source is only distantly related to GoldSrc which, while based on Quake's engine is basically just borrowing some basic concepts that are a part of every single multiplayer game engine nowadays as far as networking is concerned, which is what I was trying to point out. If you're trying to argue that Source = Quake and other games are very dissimilar from the two in terms of networking architecture then you're just plain misinformed.

[Anaximander]

So... I guess the latter, then? I reckon we might be in agreement, and that I've been thinking about a similar system as a compromise for avatar vs. avatar combat (thought about making a thread outlining it but haven't gotten around to it) with possibly one key difference, but I won't get into that here.

 

However, there are a couple of things that confuse me about the way you phrase things.

 

Firstly, it's not quite clear what you expect to be happening on the client side and what on the server side. It seems like you're saying that the client will determine a cone of fire based on some stats (I still maintain that relative velocity isn't what you should be using to determine degree of inaccuracy, as it can be compensated for with a simple galilean transformation that any targeting computer or even human can do -- rather it should be factors like changes in velocity, recoil of the weapon etc.), which then determines where you'll be doing damage. This then would be sent to the server to do some calculations based on shielding etc. and then to actually do the editing of the voxels. While this might seem OK on the surface, it's actually a terrible idea to let the client do much of anything aside from acting as an interface for the user, since otherwise you make it trivial for people to cheat by pwning the client or by messing with the outgoing packets (i.e. just place the "damage bubbles" where you want and the server will either just accept it or you'll have to implement some weird heuristic type checks on the serverside to screen all the inputs from clients). So it's better to have those sorts of things on the server. You spend a lot of time talking about a sort of general mathematical model for for depicting accuracy (with some slightly weird notions about what affects sizes of groupings) but you don't really address the practical implementation, which is at the crux of actually developing a game, and sort of the point I've been trying to get at.

 

Secondly, the part where you talk about "firing at the right moment" sounds concerning, since timing critical operations are exactly the sort of thing the devs are saying rule out twitch based combat. FPS based combat in terms of the networking (which is the limiting factor in their architecture) is basically about firing in the right direction at the right time. Having the "at the right moment" aspect in your design makes it basically at least half-FPS, since you still run into the same problems regarding varying update frequency from cells further away (with maybe delay as well when you account for waiting for interp) -- which JC has pointed out as reasons not to have FPS mechanics.

 

So if you actually track a player's view ray server side (the cone you're referring to) as well as log precise timings associated with firing the weapon "at the right time", you've basically got an FPS networking model -- which is ruled out at present by the devs. If you have that on the client side, then that just allows people to cheat very easily. Basically what you could have is a visual representation of aiming client side with UI like a targeting reticule or whatever that you move onto a target to "lock", which is just an abstract way of saying to the server "I target this ship over here". Though if you make it a tricky thing to do on the client side then people can still cheat away the skill portion of that, so I'm not convinced about that idea either...

 

And by the way, Source is only distantly related to GoldSrc which, while based on Quake's engine is basically just borrowing some basic concepts that are a part of every single multiplayer game engine nowadays as far as networking is concerned, which is what I was trying to point out. If you're trying to argue that Source = Quake and other games are very dissimilar from the two in terms of networking architecture then you're just plain misinformed.

Well, as crazy as it might sound, I was more fond of Quake than GoldSrc. All them pretty colors, so rad, so 90s. Networking is not what I debate, but their core features. You can put rocket boosters on a bike, but it's still a bike with rocket boosters, that's what I'm getting at.

 

But anyhow, my suggestion on Lock=> Compensate => Fire, can be adjusted to the AvA system. If you can see only 20% of the enemy's body, that means you got 80% less Hit Chance, after distance and skills and weapon quality and grade are taken into account. You got a person in your cross-hairs, you see a circle filling up (compensating on the target) then fire. If you took time to charge to 100%, you get 100% of the hit chance you get after distance, lateral speed, projectile speed and etcetera are applied, as well as exposure, either to light or their body (3D Mesh) exposure to you, as mentioned. I have a thread made on the light exposure idea here.   Feel free to drop your two cents in if you like to.

 

The Cone idea, is for damage bubbles to appear behind the target on a miss, in a relative distance determined by the velocities involved with the projectiles and the speed / distance of the target. Each Turret Element in the game, has limitations and when one of those turrets' blueprint is made, it has an ID on the server, letting it know of what it can and can't do. Trying to vary that result on the server won't work, in fact, it would flag as a cheat immediately if the server sees "Muzzle Velocity 600 m/s" and you tell it "600000 m / s" by trying to cheat, so yeah, making calculatiosns will be part on the client's side (when you fire and at wihch distance) as well as the server checking what Turret ID to make adjustements for to make the bubbles appear in a relative place behind the target you are aiming at. 

 

The idea on the Cone also, is that if a target's size is larger than your circle reticule, you get bonus accuracy against said target (no brainer, I know), but you still got things like projectile speed going against the target's lateral speed. If the target is smaller than your circle reticule, yoou gt a miss chance. with the distance determining the hit chance loss. You CAN call that an AoE cylinder given the circle reticle (as you've mentioned), but the term Cone of Fire, applies for weapons and it's much easier understood (by people other than you, apparently ) . Also, the Cone idea, can by adjusted for lasers so they can spread their damage given the surface at the distance you aim at, emulating loss of intensity. unless you want lasers that are a solid beam for millions and millions of kilometers. In the case of Lasers, the "Compensation" mechanism transforms into "Focusing", which would make the laser have less intensity loss at a distance, which could be X amount of seconds given a Turret's level and quality and be reduced by Y % margin by skills training.

 

It's really not that complicated. It's just that we don't communicate very well you and I.

[LurkNautili]

If you can see only 20% of the enemy's body, that means you got 80% less Hit Chance, after distance and skills and weapon quality and grade are taken into account. 

 

But you can't check for that without it being networked like an FPS (to determine if a target is in cover or not, a raycast has to be made, can't really get around that as far as I can tell) which JC has expressly said they won't be able to do (again, I think there might be some unexplored middle ground, but that deserves its own thread).

 

 

The Cone idea, is for damage bubbles to appear behind the target on a miss, in a relative distance determined by the velocities involved with the projectiles and the speed / distance of the target. 

 

Again, I'll pretend like you're saying "acceleration" because constant velocities like that don't matter (simple galilean transformation, us humans can do that in our heads intuitively).

 

[EDIT] To be more correct, figuring out where to shoot isn't quite that kind of transformation, but it's still simple and absolute -- no inaccuracy involved. Assuming you know their position and distance and velocity, you can figure out an exact point to aim at (the point where they'll be in the amount of time it takes a projectile of the kind you're using to reach). It's not quite as simple as I implied, but we humans can do it in our heads with the kinds of speeds and distances and velocities we've evolved to deal with (e.g. hitting a running gazelle with a spear). For space scales, you'd have a computer do the pretty trivial math for you and draw a target on your HUD for where to aim at to hit them -- or just do the firing itself. My point being: velocity isn't a source of inaccuracy, it's completely solvable and predictable. The only way to actually dodge bullets is to change your velocity (read: acceleration). Other sources of inaccuracy on the shooter's side of things I've already mentioned earlier.

 

Each Turret Element in the game, has limitations and when one of those turrets' blueprint is made, it has an ID on the server, letting it know of what it can and can't do. Trying to vary that result on the server won't work, in fact, it would flag as a cheat immediately if the server sees "Muzzle Velocity 600 m/s" and you tell it "600000 m / s" by trying to cheat, so yeah, making calculatiosns will be part on the client's side (when you fire and at wihch distance) as well as the server checking what Turret ID to make adjustements for to make the bubbles appear in a relative place behind the target you are aiming at.

 

That's exactly the kind of gimmicky heuristic I was talking about that's not a great idea. Firstly, if the client's doing the math then all the server gets is the locations for the spheres or maybe the cone and does the intersection itself. If it want's to determine whether that is impossible given the type of weaponry being used, it has to do verifying math as well which negates the whole purpose of having that on the client side in the first place. 

 

 

You CAN call that an AoE cylinder given the circle reticle (as you've mentioned), but the term Cone of Fire, applies for weapons and it's much easier understood (by people other than you, apparently )

 

I was talking about how an AoE effect works in an MMORPG, which is different from a conical intersection with a view frustum. The former doesn't use the user's view to determine the shape of the area of effect, the shape is determined by the skill used and it's merely spawned in a location determined by some user interaction (could be view based, could be character location, etc.) and intersected pairwise with a list of potential target elements. But that's almost completely irrelevant to this.

 

 

Also, the Cone idea, can by adjusted for lasers so they can spread their damage given the surface at the distance you aim at, emulating loss of intensity. unless you want lasers that are a solid beam for millions and millions of kilometers. In the case of Lasers, the "Compensation" mechanism transforms into "Focusing", which would make the laser have less intensity loss at a distance, which could be X amount of seconds given a Turret's level and quality and be reduced by Y % margin by skills training.

 

Lasers aren't rays anyways, they actually are tightly focused beams of light, and they physically spread their intensity in exactly this manner, based on the energy being spread over an area. Lasers don't actually just attenuate over distance all willy-nilly -- assuming a perfectly ray-like, focused beam, it doesn't lose intensity as you describe -- but such a thing is an impossibility.

 

[EDIT] For example, a perfect, Gaussian, red laser 10 km away will have spread to cover a circle of radius 3m or so. This is oversimplifying in many ways but that's the gist of it.

 

Anyways, although that would work and is a more or less valid way to describe how weapon damage is spread in a mathematical sense, it's not a wise way to actually implement it, in my opinion. It'd be better to just have an arithmetic expression rather than doing intersections with volumes (for example:  <actual damage> = <base dmg> - <base dmg> * clamp((<target distance> - <effective range>) / <cutoff distance>, 0, 1)   -- or something similar).

 

 

It's really not that complicated. It's just that we don't communicate very well you and I.

 

Well, I think it's because you seem to be talking about user experience and how it would come across and a sort of general mathematical way of describing how you want the effect to behave -- whereas I'm talking about practical implementation and what sorts of limitations are imposed on your model by the nature of how DU's networking will be implemented based on JC's interview/AMA answers.

 

So in many places we're talking apples and oranges. I think understand where you're coming from for the most part, and maybe something functionally equivalent to what you're describing can be made, but I don't think you're describing it in the most useful way. In the future I think it would be helpful if you could also delineate what you consider to be a model to describe behavior (kind of like the requirements or domain of software engineering), what you consider aspects of user experience and how things should be graphically represented, what you consider to be the actual code implementation and finally, what you think of as the networking model and client/server division of the tasks (which is sort of beginning to be touched on). Currently most of these things are sort of muddled together and it's not clear which aspect you're trying to communicate.

[Anaximander]

 

So in many places we're talking apples and oranges. I think understand where you're coming from for the most part, and maybe something functionally equivalent to what you're describing can be made, but I don't think you're describing it in the most useful way. In the future I think it would be helpful if you could also delineate what you consider to be a model to describe behavior (kind of like the requirements or domain of software engineering), what you consider aspects of user experience and how things should be graphically represented, what you consider to be the actual code implementation and finally, what you think of as the networking model and client/server division of the tasks (which is sort of beginning to be touched on). Currently most of these things are sort of muddled together and it's not clear which aspect you're trying to communicate.

Feel free to elaborate then on a suggestion of yours, this IS a suggestion after all, you are the one who turned it into a debate. And I did provide the user experience part and how many things are tied to such a mechanism as a CoF :|

 

I provided my suggestion, you can do it as well. The only thing you try to do so far is to prove me wrong by going back to "it's not going to be a twitch / reflex base gameplay" - to which I did say in the original post that it ain't - as it requires time and planning on when to fire and if you should wait or go for it with a less chance to hit. Your problem is... where the server would generate damage bubbles... huh, yet so far you have not provided any alternative suggestion. I am standing by own interpretation on how they should behave.

 

You lock, you take time charging up the lock and fire at an optimal point that the opponent's maneuvering has for X, Y, Z reason stopped and you got a chance of hitting them. Everything else stats-wise, is just emulated by the server on where damage bubbles will errupt, given the target's path to emulate missing hits.

 

Unless you like seeing "Dodged" floating letters and weapon shots going through the enemy ship because there's no emulation on a miss, in which case... preferences, everyone has them.

 

So, feel free to provide your suggestion.

 

 

But you can't check for that without it being networked like an FPS (to determine if a target is in cover or not, a raycast has to be made, can't really get around that as far as I can tell) which JC has expressly said they won't be able to do (again, I think there might be some unexplored middle ground, but that deserves its own thread).

I guess you've never seen the VATS system from Fallout 3 (and beyond) then. The Devs would only have to take into the entire body only though as a mesh (instead of Fallou's body parts / mesh selection) and utilise weapon stas like speed / accuracy / movement-to-accuracy loss / etc. as factors into an equation on hit chance. As far as AvA goes that is, this system can work just fine, down to the sights increasing the effective range of a weapon as far as the equation is concerned, heck, they can even add an ADS emulation with your accuracy getting a bonus if you ADS but you move slower, so it becomes a matter of tactics and choice. Hits would still home-in on the target you aim at, there's no hit scan involved. And as of close quarters, the Devs have spoken of an autolock mechanism possibly being implemented ( similar to Soldier 76's ability in Overwatch ).

[LurkNautili]

Fallout 3 isn't even networked, though... 

 

It's not that I'm trying to debate for the sake of it, I just don't think you understand the implications of what you're saying, and what the software architecture requirements are for a given model.

 

As I said, I'm reasonably confident that something that's gameplay-wise equivalent to your suggestion can be created, but your description of the implementation/math is flawed.

 

When it comes to alternate models, I've already described what I think NQ is currently planning in terms of the actual behind-the-scenes stuff, but how it actually manifests in user experience is at least somewhat fluid -- hence the point above. As for my own compromise solution, I'm planning on making it a thread of its own, and I think I still need more information regarding the server backend to know if my concept is feasible or not (as it has to do with the details of how messages move on the server side, how entities outside your local cell are represented, how update frequency decreases based on distance between cells, and so on).

 

In short, on the surface what you're describing is gameplay mechanics, and I don't have any issue with the general theme/direction -- I was just trying to point out some flaws in the way you're presenting it.

[Anaximander]

Yeah, well, these are uncharted territories NQ goes into. Maybe they have already thought of my suggestion long in advance, maybe not.

I do believe though the Lock On is happening the way I see it, due to how the Core Units seem to operate on a construct.

As I said, battles won't be slugfests, mobility will be a thing and the way I suggest it, would make missing hits have their damage bubbles spawn behind a ship's path, while hits will be on the ship directly.

We;ll just have to wait I think.

And yes, Fallout 3 or 4 are not netcoded, sure, but the aiming method and stats are what we discuss here and methods of manipulating the hit probablity on a person in AvA and in my opinion, 3D mesh partial concealment to hit chance loss can be done. As I said, if you see only the foot of a person as they hide behind cover, you'll get the foot-to-body ratio out of your own hit chance on them.

And the CvC idea can also be implemented for ground vehicles the same way. Core Unit => Localised Voxel rig treated like an editable mesh => Tank hides behind a rock => less hit chance for enemy tanks.


 

[LurkNautili]

The problem with that, as I explained, is that in order to update a value like that in real time you'll have to do visibility checks that are functionally equivalent to what FPS games do in terms of networking, as far as I can tell. In other words, to determine if I can see someone's head or not constitutes the same kind of ray cast that firing a weapon in twitch-fashion does, unless I'm overlooking something.