Jump to content

CodeGlitch0

Alpha Tester
  • Posts

    420
  • Joined

  • Last visited

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

1242 profile views

CodeGlitch0's Achievements

  1. The balance of the game is focused on people with 8-20 hours a day to play the game, not casual players. So, your best option at this point is to join an active organization that can provide you with resources for designing things. Going solo is not really an option for casual players. Unfortunately, this is by design.
  2. It is because NQ systems could not keep up with the level of industry people were creating after beta launch. So they increased minimum batch sizes to lessen the number of server calls required and save the servers. It is mostly likely a temporary measure, but we do not know for sure or for how long.
  3. As @Helediron said, just push the button. If you look a little closer at the screenshot you posted, you will see it says "[saved email]" and "[saved password]" in the fields, indicating it doesn't need to be re-entered. The values are hidden for security. In particular, for people that stream the game.
  4. Previous reply was a bit terse and could use additional explanation... 9800N will cancel the effect of gravity if aligned in opposing direction to gravity. It will do nothing else. If you want to move anything (additional acceleration), you need multiples of that. How much depends on what you are tryong to achieve. 4X (4g) is probably about minimum, 10g gives most flexibility.
  5. At 1g, it takes about 9800 N to cancel out (not lift!) 1000kg of mass.
  6. This should be moved to NDA section, but the problem was that you didn't balance your ship properly. Extra weight (interia) exacerbated the problem.
  7. "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.
  8. @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..
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...