Jump to content

war

Alpha Tester
  • Content Count

    86
  • Joined

  • Last visited

About war

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://aliothnews.com

Profile Information

  • Gender
    Male
  • Location:
    Andover, England
  • Interests
    Voxels, Space Games, Programming, Technology
  • backer_title
    Ruby Founder

Recent Profile Visitors

404 profile views
  1. good point ... love that!
  2. discordauth:dJfN5oOgsHuFoj3uKF6l22zh6q9-l506Icl8oLtwE1Y=

  3. war

    Radar-system

    Lua scripting could provide this ... it could also be plugged in to some sort of ship identification module or something that provides the equivalent of a black box ident. Interestingly though pirates could abuse the system by faking the ident info just like in the real world. Or maybe this is something that NQ could offer up as an element so it can't be tampered with. I'm still curious to see how blueprinting will work ... for example if I blueprint a "radar system" then sell a radar unit to you ... how do the following things get confirmed ... I didn't write some script that empties your bank for turning it on You can use this thing and trust it to work as described The internal workings are my IP so you can't copy them Having solved those sorts of questions I think there's a ton of potential for lots of ships systems like ... Shielding controller Weapons controller door / loading bay controller Auth systems (to protect access to certain areas on a ship) General "mapping systems" to help people find their way around a large vessel (think star trek, wall mounted computers that can give directions) Radar / Identification systems (this post) News systems (connected information from the fleet or external sources) e.g. the sort of information my org would serve up https://community.dualthegame.com/organization/alioth-media-group I'm am sure there will be tons more stuff that would come up but the key is in the implementation of the blueprinting system IMO.
  4. Didn't JC already talk about this being possible in one of the dev diary posts ... but it's not something that NQ will provide ... someone is going to have to build that stuff with LUA and component parts like pistons.
  5. meh ... I'm with @Haunty ... Let them focus on the good stuff instead of pandering to our impatience
  6. At least you got in on that one day, i've been keeping an eye on NQ since before the kickstarter but apparently because i haven't been active much on the forum here I don't qualify. Just take it and be happy! I'm not too pissed about it though (jealous but only a bit) ... as @blazemonger puts it perfectly ... I suspect we should all be looking to really get stuck in some time in the new year when most of the really horrific kinks are worked out.
  7. Thanks @Shockeray ... exactly that, I could get more technical but the idea here is that any conclusion we come to it would be nice if it benefited the masses not just the few of us that understand complex algorithms like Dual Contouring. @Captain Jack It's not that I don't understand these things, maybe i'm just not explaining it well ... but given the length of my last post if that's the only mistake I made it's not all that bad surely! The fact is Voxel technology has been around for some time but has never made it in to the MMO world and for good reasons but as things like Minecraft become more popular people don't understand that Voxels are expensive, but I really don't think DU is using 1 meter cubed size Voxels and that's part of the reason why it appeals to many. I guess if anything my question boils to ... What is it that NQ have solved that the rest of the world hasn't? There's clearly a break through here which is seriously cool, but i'm grasping at various ideas in how they may have put the pieces together to get my head round why this works at all! It should also be noted that I have never claimed to be a game developer (written some game code before but i'm definitely not a game dev). Be nice, offer some ideas! I second that, maybe someone has some insight i'm missing here? Put another way ... 1. Minecraft (big Voxels, the low detail makes the work load achievable on the CPU) 2. Space Engineers (smaller Voxels, newer tech, they or other engines like Voxelfarm likely use the GPU to handle the Voxel workload processing) 3. There were games like used other techniques in the past (e.g. Outcast) to acheive the render load but no networking or editing was involved back then. None of these have any form networking that can handle the scale we are talking about here and likely will never do so. So how is this DU doing what seems like the impossible? My gut feeling: Maybe the answer is simply ... not handing around raw Voxels, and instead only handing round deltas / changes / some other form of data makes this work. but in an MMO where simply keeping everyones position in sync is hard work (aka large battle in eve) handing around "the shape of an object" is a major feat! If this makes me seem somehow less credible as a developer to someone on here ... tell me exactly what i'm missing don't just rant that I know nothing!
  8. dig dig dig dig dig .... oh look a floating ark ship!
  9. war

    Water ?

    They will likely have something similar to how Minecraft does water ... simple physics applied to a large mesh that represents the volume that they can distort over time. With modern GPU tech, this kind of thing isn't overly taxing and each client could handle this on their own and at various detail / quality levels based on local setting.
  10. Yeh I see the confusion now. I'm obviously (with the lack of input from NQ at least) making assumptions that may or may not be true. I also understand why NQ would not want to explain the inner workings of their tech ... they've basically got the holy grail of all things gaming going on here. But I will try to explain myself ... By this comment I meant something like (based on assumptions I was making about how "typical Voxel code i've seen works ") ... day 1: No data in the database, all planets, moons, asteriods, ect can be "procedurally generated" by client based code. Server load is trivial, clients can simply "compute their view on the fly" and all NQ serves up is "function trees" for use in compute operations (which could be downloaded as part of the client install). day 7: Lots of edits on the surface of a planet, each "Voxel instruction" resulting in a "net change" to a subset of an area of the starting planet (Alioth). Server load is higher as each user within range of those changes needs to be fed that data in order to compute the meshes on the client. ...... Then my perception changed. I went from thinking ... "NQ will serve up raw Voxel data to clients" ... to thinking ... "NQ will compute mesh data and serve that up to clients, edits all happen on the server and clients get the resulting mesh and thus never see any raw Voxel data". .... day 7: The changes have been applied gradually, each change results in a "server side mesh recompute for the affected chunk at various LOD's". Server load is reasonable as over time, those that come across the changed area are simply fed the updated "pre-computed mesh info" . day N: Massive changes to the planet, massive mesh changes, huge structures built (like space stations) all of this stuff is "pre-computed as various LOD meshes" and stored on the server. Server load per user remains effectively constant with the calculation of that being something like "meshes in range * number of LOD's" where range is "configurable" by NQ. Mesh data further away can be served up much slower than mesh data near by and there's only so much you can get in a scene but also unless a mesh is edited once a player has it they have it. My thoughts now: Over time, there's effectively (due to the nature of Voxel tech) an unlimited number of possible meshes that could be generated and storing that data could be pricey (in terms of raw drive space. But if NQ are smart ... a bunch of TB aint that bad ... the real issue I see here is "sharing that mesh information on demand in real time on top of normal network load". So consider this scenario ... It's now about 2 years after release, Stargate's have been a thing for a few months and I am early adopter of the Stargate system so i've migrated way from the bulk of Alioth to pursue some venture elsewhere. I'm in a Large org and my org needs me for a large battle ... So I jump in to my ship, pop through the nearest Stargate to Alioth and make my way to area where the battle is taking place. There are several things I need in order to render this battle ... 1. it's near the planet so I need mesh information of the view of the planet from space 2. I've been out of touch with the local market so I likely need a bunch of ship models 3. There's probably a new station near by I might or might not have seen before so I need that mesh data. All the while the same thing is going on for the 10,000 other users in the same fight but what they need may be the same set or a different set of data but we are all asking for what essentially amounts the sum total of either all or a portion of the scene in which we just entered in to. This work combined with the actual battle means ... Network load goes through the roof. So my question was more ... How is NQ going to handle this as there's only so much an "average internet pipe" from the server and too my machine that can be handled?
  11. ... and it shall be called "Nexus" ... I love this idea ... lets make it happen!!!
  12. I'm ever hopeful
×
×
  • Create New...