Jump to content

LurkNautili

Alpha Tester
  • Posts

    150
  • Joined

  • Last visited

Everything posted by LurkNautili

  1. 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. 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. 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). 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.
  2. That still wouldn't work as well as the typical Sci-Fi dampeners. Even if you were immersed in fluid, it still wouldn't permit hundreds of g -- because although the surface that's accelerating you is now touching every part of your skin, your body is still non-homogeneous and the denser parts will concentrate towards the way you're being pushed from. And it would have to be completely solid or you'd just slowly drift through the material, depending on density -- so really a pod of some kind would be more desirable. The kinds I've seen in Sci-Fi books actually involve filling the lungs and other cavities in the body with the gel as well which further helps with structural integrity, but it only works down to the level of tissues (cells would still get ripped apart at centrifuge-levels of acceleration). The incorrect parts that I'm talking about specifically are where you say things like "absorb inertia", or that inertia increases with velocity, neither of which makes any sense. Inertia can't be "absorbed" or "transfered", unless you mean transfering mass (which is basically the same as inertia) -- you're probably talking about kinetic energy or momentum. Also, inertia (resting mass) is constant and independent of velocity, unlike for instance the aforementioned kinetic energy and momentum. You're confusing inertia (resting mass) with relativistic mass. I doubt the game will incorporate Einstein's theories of relativity, or have relativistic effects of any kind -- as I already stated. I avoided bringing up the topic as much as possible to avoid further confusing people who struggle with basic mechanics (a far simpler collection of physics principles than relativity). Relativistic mass arises from the mass-energy equivalence that comes into play at relativistic speeds. But as I said, I don't think there's any benefit (especially considering the cost of simulating things of such complexity, not to mention the difficulty of designing a game around such models) in including relativity. I won't go into the very complicated math/physics involved as I don't think there's much point in the context of a thread where people struggle with basics like the Pythagorean theorem -- and it wouldn't serve any purpose anyways. As for your comment regarding Kyrium, you either don't understand the notion of g-forces or you didn't read the part where I underline how there are more than just once force mediating particle (that, unlike gravitons, actually exist and are much more germane when examining things like collisions, where gravitons are not a factor). To re-iterate: things like touch (e.g. crashing into a planet) are mediated by particles that give rise to electromagnetic force (read: photons, not gravitons) and therefore Kyrium, as described by their lore, is useless when it comes to sustaining crashes and protecting the crew inside. I already explained possible use cases for such a material but they're few and far between and certainly not what the writer intended. [EDIT:] I also urge you to note how far off-topic this discussion is veering, and remind anyone still reading that we've addressed the OP's inquiry in that I think we all agree that the kind of system he's refering to (due to Space Engineers confusingly introducing a third use for the term in addition to the typical scientific and the typical Sci-Fi sense of the word) probably will be in the game in some form. So... /thread, I guess?
  3. 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 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). 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.
  4. Yes, exactly the kind of compromise with realism I was refering to. So since you're warping, you get to travel at relativistic velocities without having to deal with relativistic effects. Yay. Speed, not acceleration. And yeah, maybe, but it doesn't really matter. That's not the kind of simultaneity I'm talking about. Additionally, the difficulty in "leading" targets doesn't come from velocity (which is trivial to compensate for with simple extrapolation), but from acceleration (for which you can only have probabilistic models to predict with, in the case of non-formulaic, stochastic motion) and other, higher derivatives of position with respect to time (jerk, snap, etc.). A computer can predict a perfect shot on a target moving at constant velocity, and a human operator of the weapon can arrive at it with heuristically (shoot too far ahead, behind, eventually hone in). My guess is also that light speed will not be modeled as a finite quantity. That is to say, that the only delay between an explosion happening on the other side of the solar system would be the time it takes from it to arrive from the server responsible for simulating the explosion to your client machine, i.e. less than a couple hundred milliseconds. Mainly because it would not yield much benefit (as far as I can tell) and would add some overhead. I'm still not convinced you understand what inertia means, but regardless, I'm not advocating implementing inertialess (i.e. massless) ships. That's part of the reason why I corrected the usage of the term inertia and specified what I was talking about with inertial dampeners. The term "inertial dampeners" as it stands, is a misnomer -- the mechanism I described (also how it's used in popular culture) has nothing to do with inertia, per se. It is about applying acceleration uniformly, rather than only to, say, the back of a passenger (because they'll break down based on the sedimentary principle due to the force being applied as a pressure to the back rather than to every particle individually). Your earthquake analogy is not applicable. What's a more apt example of the effect is how it feels to be in freefall in earth's gravitational field, versus how it feels to stand on the ground. You can feel the strain the force the ground is exerting on you to stop you from being accelerated by the field is causing to your tissue (compared to falling, where you feel no such strain at all). In free fall, while you're still being accelerated at 1g, you can't feel it, because the acceleration is being applied by a gravitational field (I won't confuse you any further by bringing relativistic interpretations into this so we'll just treat gravity as a force/field). Similarly, you could accelerate at 10-20+g if you got close enough to Jupiter, for instance, and that 10-20+g would feel like nothing so long as you were being accelerated by the field rather than by being pushed by an object (analogous to a rocket). Also the whole "gather speed, hence mass" part is nonsense, if we're talking about inertial mass. What you're probably trying to get at is kinetic energy or momentum, which are different things entirely. And I've no idea where you called that indestructability thing from -- it's not a consequence of "inertial dampening", a function of the ship being applied inwards to its occupants, rather than to any parts of the ship itself -- and even if it was, external forces would still cause the same kinds of differentials that accelerating in a ship without dampening would cause, i.e. damage. Yeah, whoever wrote the lore on Kyrium doesn't seem to understand physics very well either if they imply that somehow blocking gravitons from entering the ship (which is the only real consequence of having "graviton absorbing ship material" or whatever, is that these particles would be blocked from entering or leaving the ship, thereby limiting the effect of outside gravitational fields from affecting the occupants, which could be useful near a blackhole or other strong non-homogeneous gravitational fields where tidal forces become problematic) would save the occupants from the detrimental effects of acceleration by pushing, which it most certainly wouldn't, since other force mediating particles (gluons and photons mainly) could still move through the Kyrium hull, not to even mention the fact that the passenger-surface interaction doesn't work through the hull at all, it's decisively internal and hence completely independent of any particle absorbing effects the hull might have -- the force carrying particles would have no issue whatsoever effecting the particles of the passengers' surfaces in the normal, destructive way in high acceleration situations. Putting all of that aside, however, I see no reason to just either forego simulating g-forces altogether or to add some sort of feathering effect based on how good your ship is or something -- and then give a physicist-friendly lore explanation for it (e.g. some BS about artificial gravitational fields somehow generated without lugging around actual planets with your ship -- still better than "graviton absorbing" at any rate).
  5. There seems to be some confusion in this thread about the physics and terminology. Inertia doesn't refer to motion or kinetic energy or whatever. Inertia is a property of mass, or in fact a numeric quantification of mass, that describes the propensity of the object possessing that mass to resist changes to its state of motion (i.e. resist acceleration, hence F = m * a -- acceleration due to a given force depends on mass, AKA inertia). To me, the sci-fi term "inertial dampener", refers to a technology that allows e.g. passengers of a vessel to accelerate at rates that would otherwise injure them (squish them like pancakes, rip their cells apart and turn them into a paste like a centrifuge would, etc). This is achieved by creating a force field that uniformly accelerates the occupants (only force I know that does this to all matter equally is gravity, but for argument's sake lets say an EM field of some special construction) instead of squishing them forwards mechanically. This is more or less a given in a game that involves interplanetary travel within play-session-sized time frames (a trip to Mars in a few minutes or hours? Well, you could do it in maybe a day or so if you accelerated half way at 1g, and decelerated the rest of the way -- but if you wanted to do it in minutes you'd be exposed to hundreds of times the equivalent of earth's gravitational acceleration and ... you'd die ... so you definitely need dampening for that). Other compromises in realism will also have to be made when you consider you'd be traveling at notable fraction of the speed of light in doing that, and we really don't want to model time dilation and other relativistic effects (Right, guys? Given the fact that the game is being played in a more or less inertial frame of reference where simultaneity is a given? It wouldn't make for fun gameplay -- it should play more like a space opera than ultra-hard sci-fi). On the other hand, hovering in place without user input, or bringing a moving ship to a halt on its own, represent completely separate mechanism, and refers to delegating the responsibility of applying force to the craft to an automatic control system rather than having a user micromanage thrusters individually. Given that the developers have already outlined roughly how ship building and scripting will work, and that in general we'll be allowed to program the behavior of elements such as thrusters and automate them to some degree, I can posit with pretty good confidence that it will be possible for individuals such as myself to create such automatic reaction control systems and the like at our leisure, and the OP needen't worry about it. As for realistic Newtonian physics being involved in space travel, or motion in general -- I'm all for it. Sure it might be difficult for a layperson to grasp that you need to decelerate to stop in a vacuum devoid of friction etc. but the aforementioned control systems and scripting should allow for players who do understand physics to make crafts that are automated to a degree that they seem intuitive for a layperson to pilot. I think it would be cool and worthwhile to have the underlying physics to be realistic, and just allow the players to build a layer of abstraction on top of that to make ships behave more like what people are used to on earth, or at least make things easy to pilot.
  6. 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.
  7. Yes, I concur. This is more or less my line of thinking as well. We can minimize the impact of any possible griefing by making it economically unfeasible as well as enabling players to forge systems to penalize such behaviors in whatever ways emerge as most effective and so on. His specific mechanics may be nonsensical, but overall the notion of collision damage isn't impossible at all, and a reasonable solution can be devised ... as previously discussed.
  8. My point is, they don't need my help. These developers are smarter and more experienced than I am. If I can think of ways to implement, they can do that many times better. I've already tried to give you a rough idea of the trade-offs involved, to steer the discussion back into the gameplay impact etc. Ultimately, neither you, I nor anyone else outside NQ can prove or disprove the technical feasibility of this kind of mechanic. So no, I haven't made up my mind, I'd just like to keep the discussion on topic, rather than focused on "dodging the issue" as you say, by asserting things about technical feasibility or making some grand, sweeping assertions about impacts on an abstract level, and then not addressing responses to those assertions. [EDIT:] I mean look, just present arguments for and against, let's not have this devolve into a sea of ad hominem. I think it's a good idea because it would make the world feel more alive and immersive, it would add an element of skill (either in piloting a bad ship, or designing a ship well that's easy to pilot), and it would give people reason not to fly too risky. So far the points I've read against it have been that it's not computationally feasible (I've demonstrated that at the very least, we need a developer to comment on that, as none of us can really determine this for sure -- but my semi-educated guess is that it isn't as bad as you think). And the other concern seems to be griefing. I think I've addressed both of these points -- if you have concerns with my responses, you should respond to my posts about these things rather than responding to the off-topic post I wrote for someone else. If you think there's some aspect of your message that I've glossed over, you'll have to point it out to me. So can we stay on topic?
  9. Oh you're going way more ham on this than I am, or that I anticipated you'd be. Godspeed I guess. o.o
  10. The effect isn't about IQ, it's about the tendency of people to overestimate their grasp on a topic if they don't understand it well enough to know where the gaps in their knowledge are. I don't know where you got the IQ-connotation from, but that's not what it implies and that's not what I meant to convey either. My whole point was not to target people's character (including IQ or credentials) but rather comment on the facts and structures in their posts. Are you deliberately misrepresenting what I said, or did you not read the block of text you're quoting? That was my point as well; we don't know if we don't try. I was just giving an oversimplified, first-order estimate. And I don't care who you are or what you do, as I've already stated. [EDIT: my proposed model is actually on the post after the one you quoted, but still, we agree on the difficulty/impossibility of intuiting performance impacts of rough ideas on an architecture that we don't know the details of -- seriously though read that post, as it may answer some of your worries] This has been already addressed in the thread prior to this, so I will try to be brief. It wouldn't make economical sense to create ramming ships, ammunition will likely be cheaper. You can create new characters and grief in a whole host of ways. You can use the same argument against including any game mechanic that can alter the world in some way. There might be ways to mitigate the griefing aspect, like (bad example) ability to pilot being revoked based either on reports or blacklisting people that exhibit these kinds of behaviors and shoot on sight, or a whole bunch of different things you could think of. You might also simply opt to not have ship-on-ship damage, if you still deemed it to be a problem, and strictly keep to taking damage from collisions with terrain. And that's an argument against discussing the idea in the idea section of the forum how exactly? It doesn't have to be the most important thing to enter into a conversation about. And I think it might be more important than some of the things you mentioned, like maybe animals or weather or whatever. The focus of this forum is supposed to be on bringing up possible features and avenues of development, and pointing out potential pitfalls and then iterating the ideas based on problems that arise. Your input, and that of many others, seems to be focused on negatives and absolutes, with the focus being on making sure an idea doesn't happen in any form and isn't even discussed. How is that constructive?
  11. Well, they've stated that they're using dual contouring, so in theory creating all sorts of shapes is possible, within the confines of the contour "stencils" or whatever you'd call those they'll end up providing. Right now they have a sphere, triangular prism (Toblerone basically), cube (basically no contour) and cylinder. Combining these, if I understand the technology correctly, would allow you to create more elaborate shapes within a 25cm voxel. E.g. if you place a sphere and erase everything except one border voxel, you'll have a round cap thing that could be used as like a rivet or whatever. [EDIT] As for sculpting tools and the like, I don't see why at least something like that couldn't be implemented, seems like the technology would allow it, and it wouldn't be any more resource intensive assuming they have some kind of a lower bound on the octree resolution, or however that works =p
  12. Yeah, that does seem reasonable. I'm not sure how we veered this far off-topic, though I'm not sure what more to speculate about their backend... Specific implementations of various microservices and such, assuming your Azure model?
  13. I think it's more like almost any mechanic can be used to griefing, and intuitively I'd say that the more freedom (and note, this is a sandbox game) you have, the more potential there is for griefing. So to mitigate it, I posit that instead of focusing on banning the mechanics that may enable griefing, we focus on: A. Creating mechanics that enable players to combat and report griefing B. Fostering a community that doesn't breed attitudes that incite griefing and other disruptive behavior (kind of a nebulous idea, but I might be able to provide some examples if prompted) That's kind of what we were discussing before the conversation veered into "it's not possible!" "yes it is!", which I felt like I needed to address. Polling frequency is a factor, yes. But it's a factor regardless of whether you have damage or just collisions. And I already presented a case for why you need at least the latter. Player input, trajectory prediction, etc. are not relevant. We're likely going to end up with an "a posteriori" collision model, so we don't check if something is about to collide, but whether bounding volumes are intersecting on a given simulation step. Regarding the last part, what? That's the definition of a collision in this model. An object is found inside another object -> collision is detected -> velocities and other relevant properties are retrieved and used to determine damage, new velocities, angular velocities and so on. This would put your system in the middle of my complexity range -- as I said, it doesn't have to be that realistic to satisfy me. (You can come up with some Sci-Fi BS like... the shield absorbs some of it or whatever, to justify using rounder colliders) I have a feeling there might be a simpler way, but I'd have to bust out a pen and paper and think about it (or do extensive googling to avoid re-inventing the wheel). The force splitting could just use the same coefficient that determines how elastic the collision is (it's kind of a measure of conversion of kinetic energy to something else, after all). So if you go thud and don't bounce, you're going to be hurt pretty bad. If you bounce, not a lot of energy went into breaking you. This is kind of oversimplifying, and it will be up to things like material properties and such. Personally I'd be fine if it just ignored conservation of energy, you can do convincing effects without. Regarding shields, yeah, makes sense. CvC combat is a stretch goal (which we might still reach, mind you), but collisions aren't. I'd wager the bulk of the complexity/work of implementing CvC combat would come from creating weapons, damage types, system damage (which, yes, would have to be in a collision damage model), etc. Most of the notions in a collision damage model are simple, and the bulk of it will be implemented (I'd assume, I mean surely we won't be able to fly through things no matter how badly development goes) regardless of whether you add the damage on top or not. The damage model to voxels isn't a trivial thing, I grant you, but you could just remove some based on some random distribution, weighted based on distance from point of impact, bounded by a sphere, sort of how I described earlier. Adding/removing voxels and elements is kind of a basic operation in the game. The rest of that block is mostly conjecture. Also, note that I'm not saying anything about how high on a list of priorities this should be, just that it's something that can and I think should be added by launch, or soon after it, for reasons that were outlined by me and others earlier on in this thread. I think a balance can be struck between simplicity, development time, believability, immersion and quality. [EDIT: Crap these character counts are getting out of hand] [EDIT: typos, grammar, formatting issues]
  14. I guess I was starting with the assumption that NQ would build their backend entirely by themselves. Is it more typical game servers (for the biggest games) get hosted by someone else? I'm guessing MS and other similar actors in this market provide tools to their customers that allow them to manipulate some well defined part of MS's cloud infrastructure? I'm more used to the kinds of systems where you do all the hosting yourself. So you just buy a connection in a datacenter, build a machine and park it there, or buy servers that are already in place. I thought you guys were talking about NQ building the cloud infrastructure themselves between the hardware they'd own, rather than building on an already existing layer of hardware and higher level protocols.
  15. So you're presupposing they're behind some kind of DDoS mitigation service, the kind that I mentioned in the post that you were quoting? I think we're in agreement, then.
  16. Wait, how are you creating IPs? In the system I'm familiar with, IP addresses are assigned to you by IANA, via your service provider -- you can't just make them up, right? And even if you select a different IP from a block of IPs assigned to you, the attack will still reach the link between the closest router to your endpoint, and saturate it, until you get your ISP to start dropping packets at the edges of their network that are trying to ingress to the address under attack, at which point the attacker just needs to get the new IP. You can pick another IP (let's assume we're on IPv6 and you have a large block to choose from), but when your service is back up, I connect with my legit user client again, get the new IP and start attacking that instead. And so on.
  17. My feelings? Not really. I'm just saying that if you want to be taken seriously, you need to structure your input in a different way, that's all. I don't care if you have a piece of paper that says you're qualified or not, I care about whether or not a proposed model or criticisms of that proposal make sense and are logical, or not. Oh and griefing will happen in a sandbox game, just about any mechanic can be used in that way so that's kind of a moot point, isn't it? To bring us back on topic, here's my take on actual implementation: So we know they must have some form of collision detection in place regardless. Why? Because if you don't detect when objects collide and take away their velocity or whatever your intended behavior is -- the objects will simply pass right through eachother. We also know the bounding boxes used will have to be at least somewhat sophisticated(read: concave hull of some kind encompassing the voxels belonging to the construct), since the devs have said they're planning on having ships be able to enter things like bays in other ships, which won't be possible if you use a concave hull type of bounding volume. I'd also assume that they'll implement collision physics of some kind, regardless of whether they have damage or not, since without collision physics, the whole "passing right through everything" thing still happens. The simplest model (barely even counts as physics) is that when two moving constructs intersect, you just zero the components of their respective velocities that point towards the other construct. In this model, objects that come in contact would sort of just slide off of eachother, or if they were moving directly towards one another, they'd simply stop. I don't think I'm alone in thinking that that would be ridiculous. A more sophisticated model involving forces, torques, momenta, angular momenta, friction and so on, would be required to have something that resembles real life. So if you want a ship to settle down flat on its feet when you land it, or if you want to bounce off of the surface you fly into too fast, you need physics simulated as well. Given those two things, all you need is a damage model, which can range from very simple to very complex, with corresponding increase in computational cost. A model on the simple end would do something like take the intersection point (already calculated) and apply damage in a sphere with radius proportional to velocity (maybe the square or sqrt, doesn't have to be linear, can have low/high cutoffs etc.) centered on that point. This would require very little calculation, but things like reads and writes to datastructures corresponding to the voxels and what have you would depend entirely on their implementation. Overall, if they do things "right" this model wouldn't have much larger impact than anything else in the game. A step up from that would be to have falloff in the sphere based on distance from the center. This is not a big increase in complexity (I think it'd be O(n)). To give an example of the extreme of the spectrum, you'd have things like material strength properties (tensile, shear, compression, all of that), you'd maybe have springs to simulate stiffness of the construct. Pieces could break off if they have enough force/torque exerted on them, you could have collisions within the different pieces. You'd also simulate tension in a rotating construct, where the tensile strength of the voxels and the angular momentum of the construct would determine whether it holds together or breaks apart. In terms of complexity and computational costs, this model is off the charts. It's almost certainly impossible, unless you make an MMO that's all about breaking things in realistic ways. Between those two extremes exists a continuum of possibilities, each of which would have to have its viability assessed on a case-by-case basis. So unless you're refering to a specific model, don't come here and say "that's not possible" without even defining what you're talking about, you only demonstrate how poorly you understand the topic. Thanks.
  18. All sectors hosted on that same server/datacenter would be affected, since my attack would be saturating their uplink. There are many bandwidth amplification attacks that make it kind of easy to block traffic in an entire region local to that endpoint (attacks of 10's of Gb/s of size are pretty common, several hundred Gbps not unheard of -- that will drown out an entire datacenter's traffic). [EDIT] And I think someone pointed out that they won't be hosting in several places across the globe, just in one or two places. If they want to not be subject to smaller DDoS attacks, they'll have to hire someone to do mitigation for them.
  19. But my point is, the IP addresses behind the DNS aren't going to be changing much while the server is running. Once an attacker knows where your server is, all he has to do is get enough traffic to concentrate somewhere in the logical viscinity of your server, and he'll bring that whole region of the network down. So within your system I could: 1. Set up packet capture locally. 2. Play the game normally, like any other legitimate customer would. 3. Obtain the NQ server(s) IP(s) by reading the traffic leaving my machine. 4. Use my C&C to issue an order to my botnet to nuke NQ servers. NQ servers are now offline. 5. ???? 6. Profit. Lesson? IP addresses aren't secrets, and you can't treat them as such in this kind of model. Point being, that there is no easy defense against DDoS, all the mitigation systems I know of primarily work based on distributing the load of the attack, but you can't do that if you just have the one or two servers. Only players like Google can do that sort of thing.
  20. How would you distinguish between a malicious user asking for your IP via DNS vs. an innocent user? Many DoS attacks spoof source IPs for instance, right? What would prevent someone from playing the game innocently on their computer, mapping out the backend IPs and attacking those IPs with a completely unrelated botnet? I don't see how it's possible to keep IPs secret, and treating them like secrets seems like a bad security practice. There's a reason why DDoS is an unsolved (possibly unsolvable) problem. See that's the sort of thing I meant might make more sense than using anycast (I still don't understand how that would work, I've never seen anything like what was mentioned -- as I don't work in that industry). If I can get a list of IPs as I mentioned above, I wouldn't have to have my hypothetical botnet connect via the provided interface at all, I could just launch an attack of my choosing on any of the IPs I've discovered. Distribution, on the other hand, is a valid strategy to mitigate against traffic concentration (network congestion) based DoS attacks, I agree.
  21. Yeah I realized I kinda derped with that remark, obviously you wouldn't actually store the IP in the client regardless of what backend you had, rather you'd find the first point of contact via DNS. I should've more specifically refered to the part about generating addresses algorithmicly. You have a point there, I somehow had the notion in my head that games I play use TCP, but now that I think about it, the ones I know about probably use UDP. Yeah ignore what I said about TCP, hah.
  22. Are you mentioning that first thing as an aside, or are you actually somehow equating a collision damage system to anarchy? By the way, many of us play DayZ and Rust as the hero type, including myself. In a game that touts being all about "emergent gameplay", it's up to the community to determine what kind of values gameplay will express, and it's up to us to foster the kinds of community values we want to see. Oh, and the beauty is that even two diametrically opposed sub-communities can exist within the game, if all the carebear types group together and create an entire solar system where nobody can harm anybody without facing heavy penalties, while the PvP anarchist guys can go have a nuclear war somewhere else -- and then you can have historic events if these two groups clash in game... anyway as I said, that's all tangential and off-topic. Regarding what's possible and what's not possible to code, how about you let the actual developers comment on feasibility, especially since we haven't even proposed a detailed enough model for you to evaluate it's feasibility or performance impact? You're kind of jumping the gun with such grand conclusions. This is the ideas/suggestions forum, after all -- you can't just shoot down everything because you have a negative knee-jerk reaction to it (i.e. it reminds you of something else that doesn't fit within your model of a perfect game -- e.g. the Rust anarchy remark way out of left field). Let's keep the discussion factual. Space Engineers is a different game, with a different engine. If I told you we were going to have a single-shard, continuous universe, with potentially tens of thousands of players, would you shoot me down because "Space Engineers and Minecraft can't do it!" ? Regarding the last part, you don't know me. You don't know my educational background, my gaming background or anything else about me. How can you just flat-out assert that I don't understand how multiplayer mechanics work? You don't see me undermining your intelligence; instead of focusing on arguing against your character, I argue against the factual/logical content of your posts and judge them on their own merits -- separate from your character. Regarding actual knowledge of game design, have you heard of the Dunning-Kruger effect?
  23. Doesn't TCP just do this own its own (sequence numbering in packet headers)? If I send that player A moves to point x, then y, then z, those TCP packets have to arrive in the order I send them and I don't need to worry about it, right? Or if you mean players A and B both in different regions distinct from mine and from eachothers' violating causality... Well I guess you'd have to maintain some sort of server simulation time indexing as well, which you could use to sort data arriving from different regions -- is this what you meant? [EDIT] That could cause delays, though, if you allow a lagged up packet from one region (at say, server tick 1500) delay the processing of events from other regions (at ticks 1501, 1600, whatever), right? It would have to be smarter than just a queue that you sort and execute in order. Is this what you're eluding to with read vs. write (some kind of analogy I don't get there)?
  24. Well, as stated, I don't know a whole lot about networking... However, wouldn't anycast require you to have access to the routing tables of the ISPs carrying the connections? Like, say I get an IP address for a US from Level 3, which is from a block of IPs assigned to them, how would I set that as the IP of e.g. a German server connected to the internet via Deutsche Telekom? I mean I know that as an autonomous system, you can set up anycast within your network, but how do you set something like that up for IPs you don't own (or from within networks to which that IP is not assigned to)? How does NQ who isn't even an AS do something like that? I'm confused. Also, what's the point of using DNS for a system where they make the client and the backend infrastructure? It won't obscure the endpoints clients connect to, IPs aren't secret information, you can just look at the traffic and aggregate a list of servers over time. Wouldn't it be best to have your client connect to a service (behind some IP, maybe the client could store a list of alternatives) to log in, and at the same time a backend service would negotiate a connection to a cluster local to you? As for DoS protection in general, the kind of architecture CodeGlitch0 mentioned would, on its own, go a long way against mitigating DoS, since an in-game region's corresponding cluster might be geographically disperse, DoSing would have unpredictable effects, and since you're probably trying to mess with some specific org or player, you can't point the attack very effectively (you'd have to know where they live, and target their closest NQ server). Of course if you're just trying to bring down game service across the board, you just target all the NQ servers, whose IPs would be public record -- just the nature of IPs and routing, nothing you can do about it. In order to protect the login service from being brought down by a cheaper DoS attack, the login backend would just have to be distributed across all the NQ servers as microservices, as CodeGlitch0 outlined above.
  25. Technical solutions to technical problems... If you give me thrusters, gyros, distance sensors and the like, I can build you a vessel that you cannot crash even if you try -- if that's the sort of digital life you wish to lead. Personally I'm like the dying breed of present day car owners, desperately clinging to the sense of danger and independence afforded by a car that doesn't drive itself. Oh and on the topic of lock-target combat for avatar vs. avatar, I'm really not happy about that, and am constantly trying to come up with some alternative that would allow me to keep my immersive FPS type combat that I've grown accustomed to. But that's a conversation for another thread. Also, I can assure you, I don't want griefing in this game any more than you do ( I mean do you *really* think I'm backing a game, posting on the forums, trying to improve the game, all for some sort of elaborate plan with the ultimate agenda of griefing people for some lulz? I assume that remark was tongue-in-cheek), and I am quite happy with missiles being VFX and stats based things with no corporeal form. This is purely a matter of immersion for me.
×
×
  • Create New...