KlatuSatori
-
Posts
331 -
Joined
-
Last visited
Posts posted by KlatuSatori
-
-
I think there are some good qoutes to take from devblogs here. In the multiplayer ship blog
Besides the specialized weapons allocation to various crew members, the fact that the ship is a real object and not some formal 3D image allows for incredible things: partial structural damage that must be repaired (crew members racing to fix this broken hull - FTL anyone?)
So it sounds to me like they want repairing damaged components of a large ship to be an active task that players need to focus on. Maybe there will be automated, less efficient ways of doing patch up jobs - these would be essential one man vessels, of course - but for a large ship, the best (only) way to fix something is by having a player go and fix it. How this would work, I don't know. Perhaps literally going taking voxels and putting them in place? I'm not sure, as that wouldn't really make sense considering that there will be automated mass production of items using blueprints
Another interesting quote:
Players will always be encouraged to take electronic snapshots of their constructions, if not blueprints when appropriate (the difference is that a snapshot cannot be traded, it's a personal asset), together with insurances, in order to be able to rebuild if necessary. However, rebuilding after destruction is costly, as neither the materials nor the time required by the auto-rebuilder can be avoided.
That's not the only time construct snapshots are mentioned for repairing damaged items. Auto-rebuilding is mentioned here. But maybe physically re-building something is the fastest way to do it and in the heat of battle you want fast repairs.
About shields - I'd love for shielding to be completely modular. Like you can have shielding around specific subsystems of your vehicles, shielding around specific sections of the hull - whatever design you can come up with. Let's say there are 5 different sizes of shield generator and you can adjust how large an area you want them to shield - the larger the generator the larger the area it can protect but the more power it requires; the larger the area you want to protect the less shielding is provided; and the shielded area can be increased and decreased with manual or automated control systems and the power supplied to the generators too.
-
Lots of agreement from me on Saffi's post. That is exactly how I think overheating will be implemented assuming it is. And the stuff on fuel as well - there might be some types of thruster that require a fuel source, others that only need a power source. Then there's fuel for power sources - probably the same again here?
The atmospheric pressure and temperature thing was something I asked about a long while back. This was the answer:
Implementing space void as a mortal environment is something we’re thinking of.
But it will remain quite basic at the beginning.There will be three environment types: Planet Atmosphere, Construct Environment and Space Void.When your character is in one of the two first environments, he will be safe.If for some reason he ends up in Space Void, there are two possibilities:– If he is wearing a space suit, he’ll still be safe.– If not, this will mean instant death for him.Physical properties like pressure or atmosphere dilution when a breach is done in a Spaceship Hull won’t be implemented, at least not for now.We might develop this in the long run if we think it is feasible (remember that we plan to handle large-scale battles. And such mechanics are really resource-greedy in terms of calculation. This could definitely be a feature for a single player game. But we still need to test if that can be done for a MMO at a reasonable cost). -
Maybe this is too complex.
What is required to be plugged into a thruster DPU slot for it to function?
Does it need power from a battery or reactor?
Does it need fuel?
Does it need to be attached to a control unit?
Does it need to be attached to a cooling unit?
What is its "health" and how does this affect performance (loss of thrust, more fuel, power, or heat)?
At absolute minimum functionality a thruster might not need anything other than an attached power source to work. But it depends on how power is supplied to units that need power... it might require a control unit.
So, more speculation but:
If thruster fuel is required, it is supplied by a fuel tank.
If power is required, it is supplied by a power source.
If the power source requires fuel then supplied by the same or a different fuel tank.
If overheating of elements is a thing, a coolant system should be attached to each element that might overheat.
In addition you'll want a sensing device to check the amount of fuel left, unless this functionality is provided by the tank itself.
Sensing devices to check the temperature of the elements.
I would guess that everything there is an element and has a DPU, so throw in a Control Unit with some functions that:
- listen for fuel below a certain capacity and react - maybe provide visual and/or audio cues to a HUD
- listen for temperature above a certain level and react - provide info as above, or automatically reduce speed in order to allow the elements to cool down, or increase coolant power or coolant levels if available
- listen for damage/health above/below certain levels and provide HUD feedback, or call defense system functions to increase power to shielding in that area
- functions for increasing/decreasing thrust and setting thrust levels
- functions for increasing and decreasing power/fuel supplied to the thruster in order to increase performance or divert power to other systems that need it more
- auto functions that make the above decisions themselves based on simple logic - maybe not the best option but if you're shorthanded or in a tight spot and need to focus attention elsewhere it could be useful.
-
Started that earlier and only just read the other posts... sorry Ripper I may have missed the point too
-
It might be useful to look at what subsystems real spacecraft have.Structures and MechanismsObviously needed for building. Mechanisms aren't essential but useful in some cases, like docking. NQ have mentioned moving parts, so if they've implemented them then they are surely controllable with a DPU.Thermal Control SubsystemAmbient temperature of the environment isn't going to be implemented but that doesn't mean there won't be overheating of powered constructs when they're left for too long or stressed.Communication SubsystemProbably not needed because teamspeak. On the other hand remote communication with a receiver could be very cool, as DevisDevine points out. Actually, maybe a comms system could also allow communication with nearby entities who you don't know, but it depends on what the in-game chat system will be like.Propulsion SubsystemAlready confirmed. Is fuel confirmed? Didn't think it was but I might have missed it. Definitely lots of scripting potential here for auto-piloting and such.Attitude Control SubsystemHopefully this will be included if the spaceflight model is some kind of Newtonian physics. Lots of scripting potential for performing preset manoeuvres.Power SubsystemAlready confirmed. Whether diverting power to different systems to give them a boost or priority will be a thing, I don't know, but it would be really cool. You could have Star Trek style "Red Alert" and "Yellow Alert" modes amongst others.Command and Data Handling SubsystemAs Ripper says, there are DPUs but will it be necessary to have some kind of data storage device for stuff like exploration data? Also, there might be some interesting architecture options here. A central DPU that controls everything, or a decentralised system where each subsystem does its own thing, or an event driven architecture, and many more that I need to read up about...Life SupportI don't think this will be implemented as all construct environments will be safe, unless that's changed.Other things I can think of:Anti-gravity DeviceDepends on whether this will be automatic for construct environments. Might be cool to have the option to not include one, or to be able to turn it off. There's another recent thread that discusses this. https://board.dualthegame.com/index.php?/topic/528-zero-g-ship-interior/WeaponsProjectiles, missiles, particle beams, etc, etc. Same scripting options here as with any weapons, though you might be able to tie it in with manoeuvres mentioned above. Ultimately though, I think manning guns will be the best option by far. Scripting might useful for reloading in some instances or at least helping with it.DefencesShields, armour, cloaking devices, etc, etc. Hard to say what kind of stuff you could do here as we have virtually zero info.SensorsI can imagine a whole vast array of sensing equipment. Planetary mapping, territorial resource scanning, asteroid field composition scans, anti-cloaking scanners, ship scanners, etc. Again, hard to say what can be done here.NavigationThis was mentioned by DevisDevine and by NQ a while back. Not really sure what this would be like.FTL DriveAgain, hard to say what kind of stuff can be done here without knowing anything about the mechanics.
-
Scripts should be attached to the 'Master blueprint' of the construct, you sell the construct you sell the script attached. But if you sell a copy of the blueprint (the one off spawning blueprints) you don't get it to edit but you can use it, just like the copied voxels in the blueprint.
We'll be able to script Control Unit DPUs, and package them up as components which we can name and then sell as a product. Whether DPUs will be a part of your construct blueprint or not isn't really clear. Maybe a component DPU will be one of the "materials" needed to build the thing. Or maybe it's as you describe. Or maybe you can choose whether to include a prescripted DPU as part of the blueprint or not... or maybe it will be a completely different system altogether.
-
Hello there,
If you are worried about programmers getting an unfair advantage, there is an elegant and simple solution in theory (it may have a lot of practical concerns to address) : all programs must be open source and everyone can copy the programs if they want to.
Regards,
Shadow
I second Azrael's strong objection to this. As I described in my post above, LUA scripting will just be for writing control systems for your constructs. Why would you make players' DPUs open source but not their construct blueprints?
-
Unless we encounter some unsolvable scenario where it could stuck players, we will avoid the "artificial resource respawn" at all cost.
That is a fine statement. Good, strong position to take. I'm with you.
-
Will the organizations having talented coders in their ranks get an edge over others? Probably.
But the same could be said for organizations having pro-gamer level players, that can win fights on 1 vs 3.
The same could be said for organizations having 10, 20 times the number of people than others. There is strength in number as well.
This is part of the game too.
This! And as many other things like this that give players/organisations with particular talents a way to leverage them.
-
I recommend you check out what was posted as I clearly talked about design. What's more, including design as an element of gameplay that only a small fraction of players can contribute will only turn people away. As for not coding gameplay mechanics, this is good news but it will still make DUAL chaotic and, well, unappealing for those who enjoy immersion. Personally, I really don't think it is necessary to make a game that is all things to all people > DU should focus on making a solid universe with reliable gameplay first, especially gameplay that hasn't even been achieved yet. This is reminding me a bit of Star Citizen - the sky was the limit but they simply couldn't understand that a solid foundation was needed.
"Design" might have been a poor choice of words.I think you are greatly overestimating what is possible with in-game scripting functionality. For the most part it will simply be calling predefined functions of predefined elements in a way that makes sense. Let me try to make a few things clear because there's terminology that might confuse matters.Voxel-based Elements are basically shapes made of one or more materials. They have no function beyond structure and aesthetics. Players will be able to create their own voxel-based elements. No lua scripting here.Mesh-based Elements (referred to as "Elements" for short) are predefined functional components that you can add to your designs. Every one of these has a Distributed Processing Unit (DPU) with predefined, non-modifiable lua code that defines what that element can do. All functionality falls under either broadcasting an event (e.g. enemy spotted; aircraft altitude dropping) or performing some function (e.g. fire at enemy; increase throttle). Again, everything about these is predefined and unmodifiable - size, shape, and DPU.A Construct is a player creation - something that players build by putting together Voxels and Elements.A Control Unit is a mesh-based element whose DPU is not predefined and can be modified. This is the only place where players can write lua code. You plug in the DPUs of other elements that are a part of your construct into the DPU of your Control Unit and write lua code that calls the functions of those elements in a way that makes sense. A typical function will probably have structure like: receive broadcast event, perform some calculations, broadcast one or more events, perform one or more functions. Note that ultimately, everything comes down to calling predefined functions, it's just when, how and why that is player controlled. In other words, players can code control systems for their constructs (as the name Control Unit suggests).Actually there is one other place that players can write code. There is a DPU that isn't linked to any Element called the "System DPU". This is mainly for defining keyboard controls for your Control Units, but can also broadcast events at regular intervals.I think your other concern is continuity of designs. I think this is an aesthetic concern if I understand you correctly and is completely unrelated to scripting. There's already been a discussion about that and Nyzaltar responded. I want able to find that thread but I was able to find a quote from Nyzaltar that answers the question:As explained before in this thread, We'd love to give full customization powers to players, but we also need to maintain an artistic style for the game. And if we would offer the ability to players to upload textures, you won't have that anymore. While we can expect most of the players to "play by the rules", there will always be some who won't, uploading "funny textures" that can destroy a big part of the immersion. We want to give to the community a realistic, immersive world, and that comes to a price: not allowing all players to upload custom textures.The other solution is to make sure uploaded textures will be compatible with the artistic vision of the game by going through an approval process. Some games have already done that in the past, and we "might" (no promise there, nothing guaranteed) go this way in the future. Just keep in mind that having an approval process can be time consuming, pondering the number of requests of such type. The artists will have already their hands full of other tasks, as it is planned to have very different materials and props (while the game will start on a planet quite similar to Earth, some other planets are supposed to be far more "alien"). But for now, consider you will have access to predesignated palette.Nyzaltar Thread on Voxel Tools
If you already knew all that and think it's OP, fair enough. Personally, I don't think there's any problem.
If anyone thinks I've misinterpreted anything , please chime in.
-
+1 cool ideas
-
It sounds like you're concerned about lua scripts changing game mechanics. Lua scripting will basically be another part of the building and designing process. You can script different functional elements of your constructs to work together - reacting to events by performing a corresponding function. There won't be graphics generated by player written lua scripts or anything like that.
I recommend you check out the scripting blog https://devblog.dualthegame.com/2015/09/18/lua-script-and-distributed-processing-units/
-
There will be one arkship which all new players emerge from at launch. NQ don't want to split up their player base when it is still small. As the game develops and the player base grows, they may consider landing a second arkship on another planet, but it is a decision for quite far down the line.
-
Hi rodier! The kickstarter campaign is planned for the end of this year, a few months before they start the alpha testing phase. In the mean time you should check out the devblogs. There's loads of great information in there. Welcome to Dual Universe!
-
I agree with Saffi that there could be a whole lot of different roles for spaceship crew members, but not with his estimates of how many people will be manning said ships. From the above, they are definitely not going half way with multiplayer ship crews. A battleship, I mean real huge ship like 250+ metres (820+ft) long really would require dozens or maybe even hundreds of real players to fly at full strength.(Posted Friday 30th of January 2015 on the DevBlog)
/snip/
The first ship you will pilot will likely be a single seated one-person ship, mostly for transport or small cargo jobs. The experience of piloting such a ship will be similar to the classical cockpit first person/third person view we mentioned at the beginning (you will be given ways to choose which type of view you want).
/snip/
The control of this multiplayer crew ship would be distributed to several players according to their specialization. People for navigation, some others for left bank/right bank weapon systems, missiles, others for repair facilities, radar, energy systems, com, or for the faster-than-light engine, etc. You would need real team play to fly an interstellar mothership, creating emergent “professions” ingame as people specialize in certains aspects of ship control.
Now, imagine combats. Besides the specialized weapons allocation to various crew members, the fact that the ship is a real object and not some formal 3D image allows for incredible things: partial structural damage that must be repaired (crew members racing to fix this broken hull - FTL anyone?), but also even more exciting is the possibility to board another ship after having cracked open its hull. In my opinion, from an emergent/strategic point of view this is a very interesting alternative to the classical way of completely destroying any enemy ship during combat: instead, board it and take control! Note that we don’t know yet how much of this will be playable in the alpha or beta stage, but it will definitely be something we will support in the long term.
Automation will be relatively basic. Droids will be used primarily for simple repetitive tasks.
EDIT
There's a caveat to all that though. Players will design ships themselves. So you could build a ship the size of battleship which has limited functionality such that its full complement is just 5 players but could be piloted by even just a single player. Would this ship be able to compete with a 100 man ship of a similar size? Would you be better off with a much smaller 5 man corvette?
-
Problem is, you could ask all them questions but i think Nyz is bound by the devs to not say anything that can be taken wrongly, and only give out 100% accurate information.
So the chances that anything about the gravity and transferring from planet to planet will be confirmed is low for the time being sadly
.. Unless Nyz's is feel generous Shhh... I was angling for a devblog
-
I've been curious about how gravity will be implemented too, and what its effect will be, if any, on the space flight model, atmospheric flight model, the transition between the two and in-space constructs.
I think I could ask a hundred more questions on launching into space, the physics of piloting a spacecraft, the different types of engine and their effect on piloting, etc, etc, etc.
-
Yeah a simple LUA script will not be a proper substitute for a player sitting at the controls. At best it will be a back up if you are shorthanded or the character gets taken out while shooting or something.
-
Welcome Carl! As TheSlaxx said multiplayer ship piloting is planned for the game. Here's some linkage https://devblog.dualthegame.com/2015/01/30/multiplayer-ship-crew/
-
Yeah I'd love to see ocean worlds, and submarines and underwater buildings.
NQ have said in the past that stuff like pressure and temperature will be too resource hungry to implement for an MMO. And that sea vehicles will not be in the alpha but maybe further down the line. I doubt that's changed at this point.
-
I like what you are saying but my understanding is there will be millions of star systems to colonize, mine and fight over, but if there is no one there then DU becomes for the most part co-op mode or a single player experience, much like Elite Dangerous is now outside a small sliver of space. So I would have to ask why make the galaxy so big in the first place if there are so many assets in the interstellar regions? Not that I don't mind the concept of heading out into the void and finding a secluded planet/and or moon to build on (I plan to do exactly that) but it would be nice if I had the occasional passerby, even if it meant fending them off. But this scenario becomes much less likely if there is plenty of content between systems - why bother to colonize the galaxy when everything you need is within reach?
Anyway, love the idea but think it would work better on much smaller scale, maybe 1000 systems as opposed to millions.
I definitely understand where you're coming from. However I think NQ are looking at gradually expanding the frontiers of the game universe rather than immediately making everything accessible. My understanding is that this will be done by revealing new technologies or improving existing ones as the player base grows. Initially everyone will be on a single planet - the frontiers will be remote regions. Then people will make it to space and in-orbit will be the frontiers. Then perhaps the closest planets will be visited and frontier towns will appear there. And this process will continue as long the player base grows. There will always be a central core of heavily populated and we'll tread areas, gradually trailing off as you extend out from that to frontier towns on the edges of civilised space, perhaps some crazy hermits further out from there, and a few intrepid explorers reaching further than anyone else ever has.
I say this not with any insider knowledge, but this is the impression I have just from having followed the game development and NQ's communications over the past year and a half or so.
-
I persoanlly prefer a FTL/Warp drive scenario with fictional speeds, but I would also like hte option of warping for 3 hours to some distant galaxy that the rest of you will never vist because you dont' want to sit at the PC for 3 hours of warp.
I love the concept of no mans sky as far as the size of hte universe. What I dislike is hte liklihood of you ever running into someone else. I think dual should meet this idea in the middle. Allow for fast "local" systems travel, but with also the ability to reach a distant galaxy.
I say this because I am not sure how the pvp balance will eventually work out. In space engineers its difficult to build a medium or large sized ship unless you are playing with a small group of friends. I do not want my work constantly attacked by players (I know there will be safe zones, but still).
I have played mostly PVP games in my online gaming life, so it's not a matter of pvp, but more a matter of wanting to create some really cool and fun stuff for the game but have it taken away by a griefer. There has to be a balance.....soooo
That being said. I would prefer to build far far away from everyone on some distant planet, even then I will make an underground base and even then it will have locks on the doors and plenty of defense systems. This is also a great way for empires to start forming and riches saved. Attacking a small ship will be fun, but sieging a city with an army will be even more fun....but there has to be some way to regain your stuff. I am just not sure how permanently lost items/resources will be.
I would prefer slower combat, combat where it takes a raid a good amount of time to break through a larger ship (unless focus fired by a giant army). Think of it as a boss fight vs getting a 1 shot head kill in an FPS.
Basically, there needs to be away to appeal to casuals or pacifists and a way to appeal to hard core at the same time. My solution is to get the hell away from everyone.
Oh you have a very similar vision to me, my friend especially in terms of getting lost. And this should scale with available tech too. Like at the start of the game, build a quick and dirty land vehicle and travel for hours to a remote jungle on the other side of the planet. Build a little base in a perfectly secluded hidden spot, complete with well camouflaged colours.
-
Whenever NQ has mentioned stargates it has usually been with a casual "that players can build" thrown in, but nothing explicitly saying that they're definitely won't be any pre-existing ones. However it would be in keeping with the general direction that NQ are taking the game.
Personally I don't get the appeal in stargates. They suck the fun out of exploration and if overpowered compared to other travel are too much of a superweapon. If they are player built only, single point to single point, limited in range and capability, and are destructible, then they are fine.
-
@DevisDevine
Yes, it is travel time between points of interest that really matters. And that is partly what inspired this thread. However, how do you reconcile the time it takes to get from one planet to another at a given speed with the time it takes to get from one star to another at that same speed? Suddenly exponentially increasing the speeds that are possible is a bad solution for many gameplay reasons. Plus who could possibly be against more content in any case?
@Ripper
No wacky baccy for me for like 5 years. Already made my points in that thread.
@Experia
I don't see there being any boundary between interplanetary and interstellar space. It would be seamless. They are just convenient labels that describe how far away you are from the nearest star / planet orbiting a star.
Repair and shield systems
in The Gameplay Mechanics Assembly
Posted
I can set that as being a tactic, but with drawbacks. If you want shields extending way beyond your hull then you should need shield generators that are very large on comparison to your hull size and hence a comparatively large power source. So essentially your drones would be flying shields with virtually no fire power because there's no room left. That would make sense to me as there is push and pull, and natural balance.