Jump to content

CodeGlitch0

Alpha Tester
  • Content Count

    409
  • Joined

  • Last visited

About CodeGlitch0

  • Rank
    Novark Citizen

Profile Information

  • Gender
    Male
  • Location:
    Alberta, Canada
  • Interests
    RL: Programming, games, exploration, many other things, indoors and out.

    DU: Builder role / Construct DPU scripting, trade empire
  • backer_title
    Gold Founder
  • Alpha
    Yes

Recent Profile Visitors

437 profile views
  1. Wow, this system is going to make it hard to both design ships AND test them early on. If there are skills for basic things like "flying hover engines" and "flying with ailerons," that will severely limit the ability to build something you can actually test well until much later in game and will likely cause a lot of discouragement in people just learning the game and trying to build things.. I'm sure it'll work out fine by release (and later on in your DU career), but It will make for a ROUGH start. Hopefully there will be better balance simulation/analysis tools when building. As an analogy: allowing the ability to write code while essentially disabling (or severely limiting) the ability to properly "unit test" or "debug" it seems like a really bad idea at first glance. We'll see how it goes, I suppose.
  2. "Directly" being the operative word, I guess. Voxel structures aren't based on edges and vertices like most 3D models. Edges and vertices for display are derived from voxel data. That doesn't mean it can't be done, it requires something to do the conversion. In fact, the NQ team did just that to import models into the game for demo videos, etc. But, by nature of the gameplay, that won't be available to the general player. We'll have to manipulate the voxels the old fashioned way.
  3. @Thainz: "CAD" functionality such as sketching, dimensioning, and measuring aren't directly compatible with a voxel engine. You could use a CAD system (such as onshape.com, which I use) to draw up a schematic, but you'll still have to translate that into voxels yourself. It wouldn't automatically convert in-game. Sure, if you were a NQ employee, you could use their tools to import 3D models into voxels, but that won't be available in game. However, you can certainly use an engineering schematic created in an external CAD program with measurements to be far more precise with your voxel placements to make the most precise final version possible..
  4. Yes, well, I'm something of a nerd. Talking about it got me wondering what the actual latency on something like this might be. So, now I want to put together a quick test to see how it actually might perform... EDIT: I'm also a hobbyist/aspiring game dev (at some point in my life, not that I'll ever get around to it). But something like this may actually end up useful?
  5. I'm currently working on a diagram of the model. I'll post in the next day or so hopefully. Then we can rip that apart until we have something that feels like it might be a viable back-end for DU. Then I will probably tinker with an implementation of it for performance checking and we can go from there.
  6. To buy and build a cloud yourself would be insane. The kind of infrastructure that DU would require would have enormous front-end cost. Certainly, at least 100s of thousands, but in the millions probably. NQ has stated (referenced earlier on this thread) that they will be using a cloud service. At launch, at least. So my speculations assume they make the sane choice: a pre-existing cloud, with pre-made and configured core infrastructure as with something like Azure or Amazon cloud, and not reinvent the wheel. If, by chance, they do decide to try to create their own cloud.. I would be willing to make bets that initial launch would be a complete catastrophe. The intention was an in-depth software/developer discussion, moreso than IT.
  7. In your typical service provider patterns, yes you're assigned personal IP addresses. But in a cloud situation, providers like Amazon and Azure, etc are assigned huge blocks of IP addresses which are used as needed by various clients. If you're using static, very long-term IPs in a cloud provider, you're probably not making full and true use of the full power of cloud. The full power of cloud comes from throwaway virtual machines and dynamic, fluid hyperscale capabilities.
  8. Yeah, there are definitely options out there. But I imagine something like DU won't actually require a huge amount of network traffic per client. Latency will be first an foremost. But without a requirement for twitch combat (ie. FPS shooter), the traffic will likely be mostly game events (voxels added/broken, shot fired/target and player movement. It can probably be accomplished within 50-100 kbps (~5-10 KB per second) on average per player. I could be way off on this number, but hey! It's wild speculation day! Also, an ingress layer helps immensely with that. The responsibility of those nodes is solely: accept traffic, decrypt it, validate/authenticate it, pass on to game services. The major difference between cloud/microservices and tradional game servers is that the cloud doesn't require every single bit of processing to happen on a single node. So, you aren't required to micromanage performance issues in the same regard as traditional. The distribution means you can handle a lot more than normal. EDIT: But you are right. UDP is generally better for things like gaming. When the game logic is primarily server-based though, it might become a different beast. Dropped packets, except for movement and the like, can be really bad in that scenario. Possibly a hybrid/dual streams is the best choice.
  9. I'm talking in the context of a "dumb" ingress layer. Yes, at the TCP level, packets would be ordered and retry as normal. But once through to the ingress nodes, that traffic is authenticated, validated, decrypted, and passed on to the actual game logic nodes. It is at this level that I image a queuing system might be necessary. If you have 100 ingress nodes and no queuing, that is a lot of asynchronous traffic (100 streams) being dumped into the game services (let's say 20 server nodes) and it all needs to be handled and processed at once. By implementing a queue (either in process or separate/distributed) you can quickly accept that traffic, then process it as quickly as possible without fully flooding the services. If you use something like Azure Service Bus or Event Hubs (again, sorry for always posting M$ tech), then those cloud services can ingest the millions of messages per second and use Message Queue "topics" to intelligently route to only the nodes that requires the message. instead of the connected node receiving EVERY message, always. Again, it's a trade-off between raw performance or adding a bit of latency to be more intelligent and reduce overall traffic ingestion on specific nodes.
  10. I apologize for constantly going back to Micro$oft tech. I use M$ dev stack every day, so it is what I know best. There can be a number of benefits to having a level of protection at the DNS level. With the advent of things like Azure DNS, you can go even further than just security with it. In the cloud, IP addresses can be very fluid. There isn't a whole lot of need to hold on to a single public IP for long periods of time, unless that is how your system is designed. In microservices approach, they can come and go and it wouldn't really matter. DNS protection would only help with the initial connection attempt for each client. Most clients will cache results and then just use the same given IP until something fails and it attempts a reconnect. Diving in... What can you achieve with a DNS layer protection system? A couple of things. Primarily: automatic geographic distribution, initial load balancing, and DDoS protection. Because IPs can be in flux, a cloud-based DNS server can protect against DNS-level DoS attack by simply blocking evil IPs from the DNS layer. That prevents a level of DoS traffic from even getting to your app. This is more beneficial if IP change regularly. However, most app public access points are fairly static. Secondly is geographic distribution and load balancing. In something like the cloud DNS, you can have the server know about a number of affinity points for your app. (read: datacenter location specific) Lets say you have "connect.dualthegame.com" as your primary connection point. This service is distributed amongst 30 nodes/IPs in 3 geographically dispersed data centers. The DNS layer can know that you also have "america.connect.dualthegame.com," "europe.connect.dualthegame.com," and "asia.connect.dualthegame.com." When that initial IP resolution query comes in, the DNS service can look at your IP, check it's geographic location and return the appropriate CNAME for your region. It is also possible to select based on latency, I believe. Each of the geographic CNAMES has a list of IP addresses for each cloud load balancer on the connection point for that datacenter. When multiple IPs are returned, the client will essentially just choose one at random and connect to that. This gives a degree of initial load balancing before your client even tried an actual connection to the app. The malicious botnet will be mitigated in some respect on that initial connection attempt, if it uses DNS resolution. The cloud DNS/front-end load balancers can pick up a list evil IP based on network traffic and prevent before it even touches your app. The load balancer denial also protects your app from direct IP address attacks. If the hackers get through even that, the ingress layer has it own protection now, as I mentioned, because individual nodes are fluid and disposable.
  11. @Ripper: Those are some great points! The addition of ANYCAST perhaps through something like new cloud DNS services) would definitely be required for the initial connections and help greatly with geographic distribution and DDoS protection. That would pair wonderfully with the Authentication/Connection reservation/encryption key generation I mentioned. This brought to mind a couple of other benefits about having an abstracted ingress gateway layer. The ingress layer would be responsible for all encryption/decryption of over the wire traffic to players and would easily reject any other connections attempts that have not been reserved. If they we targetted by DDoS attacks, it would be easy to scale up additional instances and just dump the attacked nodes. Player connections would simply reconnect to a new ingress node and they would only notice some lag until automatic failover happens and the blip of that reconnection attempt. Everything else would happen behind that ingress layer in traffic that is inaccessible publicly, and actual regions wouldn't actually be affected. The primary downside would be a slight addition to latency, but because it is all part of the cluster it is pretty much just traffic over a local network switch, so we're talking singles or less of ms. @LurkNautili: Connections between nodes would be direct yes, but messages would need to be queued once received to ensure they happen sequentially. But once in the queue, they can be processed and acted on asynchronously, with some intelligence to resolve conflicts. Individual services, such as the region, can also make use of replicas to allow certain read operations to occur across nodes, while write operations would happen on a single primary node to protect the system integrity. A lot of this can just happen automatically thanks to the cloud services / service fabric layer. Because data-center connections are much more likely to be consistent and predictable than player connections, geographic distribution and synchronization might actually make a lot of sense in a cloud situation. There might be some lag for events from players in one RL region to players in another RL region, but that would happen regardless of implementation. It is inevitable. Distributing RL geographic regions via only the cloud, would likely actually normalize a lot of those inconsistencies. Now you got me thinking even deeper. Perhaps I need a diagram... That'll be later.
  12. Yeah, I was going to cross-post to the Kickstarter, but I figured there would be far less chance of it getting buried on the forums and I didn't want to duplicate questions. Thank you for responding, though. Sorry it became necessary. I should have noticed the answer in the KS update, but I glanced over that line apparently. My mistake, and I am happy to own up to it. It's unfortunate that the post exploded, when I just looking for a response or an official source. I'm kind of glad that this discussion didn't happen on the KS page though. Anyways.... Moving on! Thanks again.
  13. Funny, it sounds like you are trying to start an argument. A simple like on his post would have sufficed. Fortunately, I won't bite.
  14. Thank you! You are a gem. You saved me from having to write a lengthy response that should never have been necessary anyway. I will put this link on the opening post.
×
×
  • Create New...