LurkNautili
-
Posts
150 -
Joined
-
Last visited
Posts posted by LurkNautili
-
-
Yeah, but making a 3D game with that? You'd have to bake the projection matrix from world coords to screen space into the SVG animation.... but then how do you choose an arbitrary rotation around an object that you're trying to animate or something? Do you make an SVG file for every possible camera path? That's an uncountably (well, technically countable since we're dealing with computers that don't have *actual* real numbers) infinite set of SVG files
-
8 minutes ago, Groogy said:
Not what I meant, just that there isn't much point to reinvent the wheel.
And hey the first 3D games were done using vector graphics so SVG is enough.
Not really the same thing though
If what they have is a way for you to bring in a static SVG file, how do you animate that? Just because they both use parametric curves doesn't mean they're interchangeable =O
If, on the other hand, they have some functions that allow you to draw vectors with Lua directly... That would be something you could use to actually animate things.
[EDIT: Btw I'm aware of being able to have SVGs animate in a sense, but not in an interactive way -- getting that to be interactive enough to constitute a game would be quite hacky]
-
This is where I learned Lua years ago: https://www.lua.org/pil/contents.html
(for Garry's Mod and later Multi Theft Auto: San Andreas)
It's the online version of the 1st edition of the book mentioned earlier in this thread.
On 8/16/2017 at 10:51 AM, Helik said:I have the 5.1 programming in Lua paper book, I would like to know if I need to buy the new one since the current version is 5.3.4.
The Fourth Edition is for 5.3: https://www.amazon.com/exec/obidos/ASIN/8590379868/lua-pilindex-20
I don't think enough will have changed that you would have to buy a whole new book for it -- just google what has changed.
On 8/11/2017 at 0:56 AM, ATMLVE said:WARNING: Do not search for a pdf version of the book. There is a pdf version available for free, but of course it is illegal. Again, do NOT search for the pdf version of the 4th edition, or you will find the free illegal version.
This is the e-book version (pdf as well): https://feistyduck.myshopify.com/products/programming-in-lua-fourth-edition-ebook
This is not pirated or illegal, it is linked on the authors' website.
Personally, I don't plan on getting either of these, as the free online book is for version 5 and the information on what's changed between versions is public knowledge.
-
They looked more like pure triangular meshes rather than a part of their voxel system to me -- but it's kind of hard to tell with dual contouring.
If I had to wager a guess, I'd say they haven't really thought about it yet, or at least haven't implemented any of that yet -- so it'd still be up in the air.
Quite likely it'll be a mesh selected from some subset of possible trees, possibly with some procedural generation, that just goes "poof" when you harvest it (if it's even harvestable at all).
Of course all of this is 100% speculation, and we need the devs to weigh in on this to be sure.
-
3 hours ago, pcfreak9000 said:
it would be cool to have real water dynamics later. but for that the server hardware has to get better...
Well...
Depending on how much they're willing to commit to it, in terms of resources, some system might be possible (due to the innate scalability of their system, you kind of only have to worry about "density of computation" rather than necessarily overall cost -- as well as how much it costs w.r.t. all the other stuff, since there's no point spending 99% of server CPU time on fluid sim).
Basically, you can more or less forget about Navier-Stokes and Boltzmann right off the bat. I don't think even anything particle based (SPH or something) would work for them, unless they know something I don't. However, I've seen some really impressive and surprisingly efficient systems based on cellular automata that may be just about on the fringe of feasibility, where it becomes more a question of whether there's enough ROI on the computational resources it would cost them...
So basically it might be technically just about possible with enough simplification, where it becomes more about whether it's worth the trade-off even then or not.
-
Other than omitting it from terrain generation entirely and sticking with completely dry planets, I guess that's as good as you can hope for, barring some brilliant hack.
I mean there are quick-ish ways to cheat fluid simulation but idk if any of the ones I'm familiar with would be fast or flexible enough.
-
5 minutes ago, ShadowLordAlpha said:
You don't need to install something to listen for a connection its there with a socket.
Obviously the server needs to have a program running that has the socket in it. Unless we're talking about a web server then that's not going to automagically be there.
The reason I say there should be a small program doing the mediating is that the DU client would refuse to send *larger* packets before it got permission from the other end. This would make most forms of DDoS more difficult to accidentally or intentionally do. Limit the scope of what you can send and suddenly modern DDoS (talking about magnification attacks here) is not possible anymore. Just allowing the user to have
raw web sockets (confusing term)unfettered access to a socket is kind of a bad idea in that sense. -
1 minute ago, yamamushi said:
That's what the handshake is for.
Well that's what I was referring to (I see now, somewhat confusingly) as a "protocol" =p
-
1 minute ago, yamamushi said:
I don't even think that's necessary, I'd rather just have the ability to open an outbound socket so that I can send whatever data I'm getting from LUA upstream into my own application to parse and render.
None of this requires developing a whole new protocol, as it puts the onus on the application devs, not NQ. The only thing we'd want from the LUA side is some error handling to make sure that scripts keep working as intended even if they're not able to push data out a socket upstream somewhere for collection. Hence the handshake idea - does a host work? Great, start sending data. Does it not work? Great, skip publishing for this script.
I'm not sure you're addressing JC's concerns there, though. If you can send traffic to any server you want, you can end up in the DDoS type of scenario he mentioned. Also, the script being client sided only limits things to a degree since presumably these same scripting functionalities could be used on scripts that propagate from player to player on constructs sold on the market or whatever.
Hence why I'd suggest adding some mechanism to restrict what you can send and in what amounts, e.g. lightweight, rate limited packet streams to attempt to start a connection, which a server that didn't want to accept potentially malicious script traffic could just ignore. I mean honestly well implemented web servers and the like probably ditch badly behaving traffic anyway, but I'm just mentioning this as a potential counter to JC's concerns.
-
Just now, ShadowLordAlpha said:
no but listening and not accepting or accepting is the servers responsibility not the client. LUA would be a client so filtering based on something makes more sense
But what I'm getting as that e.g. Google couldn't get DDoS'd by DU scripts because they haven't installed a thing that listens for a connection. That way you wouldn't need to waste NQ resources on a screening process of IPs or domains, but rather users of the internet connecting scripts would be able to set up both ends of the connection themselves. This shifts responsibility to the users, which, if the subset of operations/features is kept nice and controlled and well-vetted, should get rid of both DDoS and security problems.
-
1 minute ago, ShadowLordAlpha said:
No developing a whole new protocol would be far more restrictive normally than simply allowing sockets and the list would not be to protect others but allow a few to be access. I don't know how you think developing something new would be less restrictive but whatever. Scripts could also send payloads or have the IPs they connect to hidden in which case any poorly designed script would be the fault of its creator and not a user.
It's less of an issue of attributing blame and more of an issue of avoiding the thing in the first place.
Having to be listening for connections explicitly and dropping connections that you're not expecting isn't a difficult thing to write. It's generous to even call it a protocol.
-
1 minute ago, ShadowLordAlpha said:
The OP mentions intentional DDoS not incidental as well as abandoned projects but that is normal with scripts in general. They could monitor it ingame but you run into other problems like copy pasted scripts and other things like that
I'm not sure we're talking about the same things anymore, so let me take the liberty to better define some stuff here.
So you have the client Lua scripts (call them internet capable DU scripts or something like that maybe)whose developers want to access the internet with them. Then you have the servers online (called... internet DU script targets, maybe) that would be what they want to connect to with their scripts. The concern in terms of DDoS, if originating from within the scripts running in people's game clients, would be that the connections would be either entirely unsolicited (probably what you meant, I now realize) as part of a malicious Lua script developer's DDoSing campaign (kind of an unlikely scenario since there are easier ways to DDoS, imo -- also easily stopped), or as a result of poorly designed scripts that idle around pinging web servers (what I was initially thinking about) without any real need to do so. Or just the sheer popularity of a script overwhelming unconsenting server endpoints (maybe this is what JC was refering to with his million DU users specifier).
Defining a small list of IPs would serve to protect e.g. web servers that haven't been included in the list from being flooded with any type of traffic from within the client, but that would already be solved by a consent-based two-ended protocol type of deal that OP posited. Restricting access by IP would also have the downside of being less flexible without much added benefit imo.
Idk if I left anything important out, but I tried to be a bit more verbose to prevent further miscommunication (whereas usually I try to keep things terse for the sake of short attention spans, as nobody likes walls of text).
-
Just now, ShadowLordAlpha said:
the type of DDoS you are talking about is normal and in general is fine because its nature of more traffic than expected. Also he only mentions DDoS not the type. To get on the list would depend whatever they decide but would allow them to track who added what to the list or things like that. Also the system would be less restrictive than simply not having it in the first place
Well, though that might reduce the volume of traffic that they'd have to monitor, they'd be able to monitor it even without having a whitelist of IPs or domains, since the traffic originates from within their program (barring hacking and such but that's a whole other can of worms that I won't get into now).
Based on the context of what JC said: "I'm concerned with potential DDoS attacks with dormant scripts inside popular ships..." -- I'd be inclined to believe he is talking about the incidental kind. This, for the simple fact that there are much easier ways to implement intentional DDoS attacks. And yes, I agree, this is type of traffic spike or other "more traffic than the webserver bargained for" situation is pretty common on the web regardless, but this is what I believe both my post and OP were addressing.
-
Just now, ShadowLordAlpha said:
a registration system would not need to be hardcoded and you could update it as things change.
Right, a changing list, fair enough.
Still, would that not restrict the system excessively? And if it were possible to get yourself onto that list, what does it change exactly?
It still doesn't address the type of incidental DDoS to those IPs, the type that JC mentioned in his tweet. However, OP's suggestion in principle would.
-
Just now, ShadowLordAlpha said:
I was talking about a list of valid, registered and approved IPs that LUA applications could connect to so how in the world is that a whole front and back end?
I see... The whole "registering an external app" part confused me.
I'm not sure if hard coding in a bunch of IPs would result in the kind of functionality OP is asking for.
For one, only people with access to servers on these IPs could realistically use the luasockets type system, right? Secondly, domains and IPs change, so you'd need to have it be more dynamic than that, imo.
-
1 minute ago, ShadowLordAlpha said:
how about just registering an external app or something with them as anything else would take far to much development time and still be vulnerable to all the same things. The limits already should limit the DDoS type things because its much easier to just ping the server with a false IP then work around them most of the time
Well, we're talking more about incidental DDoS rather than intentional. You think writing a custom back-end and front-end for a fully fledged application would be easier than just writing a communications protocol and building a web frontend for it? I'm not sure I follow entirely
-
In terms of security concerns, I think they'll have to design their own custom implementation regardless to close out the possibility of any exploits, so regardless there would be quite a bit of development time involved as it's a section of the program at high risk for exploitation.
In terms of DDoS concerns, even with a neutered set of operations I agree that you'd need some kind of a protocol set up between the web server end implementation and the clients with lua. I.e. you couldn't form connections with just any server out there, you'd have to install the API on the server you want to connect to as well, with some kind of a protocol (at least in spirit) similar to what was suggested in OP.
I do think it would be useful to have this, but I can also see it being a headache to implement and iron the bugs/exploits out of. It's the sort of thing I wouldn't deploy in the live version of the game, but rather either early in the testing phase or on a dedicated testing branch to reduce impact on at least the in-game economy.
-
The rings are most likely a representation of a predicted path based on current velocity and acceleration. It looks like the rings are spaced at fixed intervals, but the length of the interval changes in discrete steps (in the full video you can see it switch step size if I'm not mistaken).
It probably uses the same numeric integrator that does the actual physics simulation with the same state and inputs (in terms of like, a phase space), except that it steps further (many seconds) into the future of the actual physics simulation. I mean it might be a different, more inexpensive integrator or larger step size or something if they're worried about the overhead, but it doesn't really matter. Point being that it's clearly a predicted path of the ship, given it's current state (velocity, acceleration).
[EDIT: The whole state space idea is kind of weird in this context, I'll grant you. I mean, in this case the way I've described it, the space (the vector field) would kind of evolve with time if the acceleration isn't constant. The concept isn't as useful in systems that aren't deterministic even in principle, I guess. I'm just used to thinking of simulations in terms of multidimensional state evolving through time, like in a simple mass-spring system or something. The basic idea still applies, though -- it's integrating numerically in discrete time-steps based on current position, momentum and acceleration.]
-
In short, my intuitive take on this is:
Though functionally infinite, the amount of planets and land on the planets (& other celestial bodies) actually accessible at a given time will be limited, and the discovery of new territory (and developing logistics to that location to actually make it useful) will be rate limited.
Therefore, there will be scarcity, but it will be transient/fluctuating in nature, and the extent of it will depend on how NQ balances the mechanisms that enable the discovery of new resources.
As sort of eluded to by other posters, the value of an area will have stages/modes/layers associated with it. I'm not sure what sequence things will happen in, but the utilization of an area can be broken down into at least:
- usage for the raw resources/minerals,
- usage for land and living spaces,
- as well as usage as a population/trading/social hub (and possibly other stages/layers).
These all have economic value associated with them, and will deplete at different rates. It's a difficult problem to consider more concretely without seeing the exact implementation.
-
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.
-
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.
-
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.
-
[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.
-
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.
Are you going to Lua in DU?
in General Discussions
Posted
Exactly my point, dude...
If all you have is drawSvg("test.svg") or whatever, you can't realistically do a 3D game with that.
If, on the other hand, you can for example drawLine(Point start, Point end), you can make your own spline implementation, sample the spline to a polyline, do the math, and draw whatever you like. Of course if you're drawing a 3D cube you wouldn't bother with vector graphics, you'd just do the view transforms and culling etc. to the cube and draw the visible line segments in screen coordinates.
I'm not arguing that it could never be done under any circumstances, I'm merely pointing out that your initial statement of "And hey the first 3D games were done using vector graphics so SVG is enough" is false. You can't realistically make 3D games if all you have is the ability to draw contents of an SVG file on screen.
Perhaps that's not what you meant, but that was my interpretation of what you said, and it's what prompted the response. =P