Jump to content


Alpha Tester
  • Posts

  • Joined

  • Last visited

Profile Information

  • 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
  • Gender
  • Alpha

Recent Profile Visitors

1055 profile views

CodeGlitch0's Achievements


Newbie (1/14)



  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. 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.
  8. "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.
  9. @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..
  10. 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?
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...