LurkNautili

Care to explain, in detail, how that would allow you to render arbitrary things in 3D? Just specifying a location on your screen to draw something that's 2D doesn't allow you to draw arbitrary 3D shapes. You could possibly fake a limited subset of that but idk. You kinda need more support from the API than that. They did have a working Breakout clone in a video so I'm guessing they at least allow you to draw 2D primitives and animate their location. To me it seems like the overhead from that (on top of the fact that it's already running on Lua) would make drawing any kind of moving 3D shape in real time nigh impossible. I mean you're essentially emulating a rasterizer by printing dots on your screen where edges/faces of a mesh should be drawn. Even with just line segments and wireframe graphics it's a bit of a big ask, by my reckoning.

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

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

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. 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. 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.

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.

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.

Well that's what I was referring to (I see now, somewhat confusingly) as a "protocol" =p

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.

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.

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.

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).

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.

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.

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.

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.

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). 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. 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. 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. 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). 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.

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.