Jump to content

Ability to build on a moving ship? technicaly feasible or not?


Jeronimo

Recommended Posts

Ability to build on physical moving space ship kinda tinckles me

 

We know the creation mod at first create non physical voxels until you activate its physics

 

Will the created voxel stand still on xyz position untill one wall of the ship bumps into it, and stops the whole spaceship?

 

Will created voxel automatically and instantly be linked to the physical properties of the ship, so that will create a physical voxel that will start bumping on the floor?

 

Will created voxel automatically and instantly be linked to the ship but with non physical properties, considering the air in between the ship voxels and the created voxels is solid?

 

What if my first created voxel is created in the air within the ship and not touching the ship?

 

What when i ll want to save my creation, if i save the whole ship blueprint with it?

 

 

I really consider this question tricky in terms of links and properties

 

What if it is technicaly impossible, and what will we do in spaceships during a month travel exept socialising?

Link to comment
Share on other sites

Voxels will have physics upon placement right now but ghost images could be considered. I don't think travelling will take months, just making instant travel jump gates will as you will have to tractor them apart (quantum link).

 

Floating voxels will exist, but they may be solutions for the terrain, but not for the ships. We will call that quantum struting when a flating part exists on a ship. But: it is possible to detect if a ship is cut in half thanks to baking (they talked about procedural mesh baking) so i expect them to be able to sample that baked mesh for separation. (There is probably a mathematical way to achieva that).

 

For the terrain we could just detect if the below neibors exist or not and if not detatch the block of dirt and let it fall and rejoin the ground underneath. See the terrafirmacraft mining system for more detail. It is not feasible for ships as the materials are too strong to be able to use that technique effectively even tho it may be adapted.

Link to comment
Share on other sites

 

For the terrain we could just detect if the below neibors exist or not and if not detatch the block of dirt and let it fall and rejoin the ground underneath. See the terrafirmacraft mining system for more detail. It is not feasible for ships as the materials are too strong to be able to use that technique effectively even tho it may be adapted.

 

yeah i have opened a topic for that, based on "7 Days to Die" physic principles, but they mentioned already that mountains will be floating if you cut the bottom

Link to comment
Share on other sites

Voxels will have physics upon placement right now but ghost images could be considered. I don't think travelling will take months, just making instant travel jump gates will as you will have to tractor them apart (quantum link).

 

Floating voxels will exist, but they may be solutions for the terrain, but not for the ships. We will call that quantum struting when a flating part exists on a ship. But: it is possible to detect if a ship is cut in half thanks to baking (they talked about procedural mesh baking) so i expect them to be able to sample that baked mesh for separation. (There is probably a mathematical way to achieva that).

 

Floating voxels, hum, but no i cant make me the idea how the computer will decide if it is linked to an other object or not

Link to comment
Share on other sites

Floating voxels, hum, but no i cant make me the idea how the computer will decide if it is linked to an other object or not

 

OMG, i got the best idea for an algorithm to detect if there are floating blocks with minimum power:

 

take all triangles and make the dot product to the forward unit vector and multiply by the area and add that, it will always be 0.

∑(dot(forward vec, normal) * area)

if not, the mesh has a hole.

why? because every real volume ever has a derivative topology of a sphere that has a 0 normal sum. 

then to detect if there is a separate chunk you do something similar:

do the same but:

a = ∑max(dot(forward vec, normal) * area, 0)

b = ∑max(dot(left vec, normal) * area, 0)

c = ∑max(dot(up vec, normal) * area, 0)

d = min(a, b, c);

if ((a > d && a % d == 0) || (b > d && b % d == 0) || (c > d && c % d == 0))

it has a separated volume guaranteed , but doesn't account for every case...

 

i shall think more about it. for now without taking in account relative position there is no way to know for sure.

Link to comment
Share on other sites

OMG, i got the best idea for an algorithm to detect if there are floating blocks with minimum power:

 

take all triangles and make the dot product to the forward unit vector and multiply by the area and add that, it will always be 0.

∑(dot(forward vec, normal) * area)

if not, the mesh has a hole.

why? because every real volume ever has a derivative topology of a sphere that has a 0 normal sum. 

then to detect if there is a separate chunk you do something similar:

do the same but:

a = ∑max(dot(forward vec, normal) * area, 0)

b = ∑max(dot(left vec, normal) * area, 0)

c = ∑max(dot(up vec, normal) * area, 0)

d = min(a, b, c);

if ((a > d && a % d == 0) || (b > d && b % d == 0) || (c > d && c % d == 0))

it has a separated volume guaranteed , but doesn't account for every case...

 

i shall think more about it. for now without taking in account relative position there is no way to know for sure.

 

well well well!

when you mention a mesh could have a hole, reminds me of HL1 first world creator that couldnt compile the world you create if your map had a hole, means if it is connected to the void

 

it could be a similar principal, if you completly seal your ship, with double door airlock entries, all air inside could be considered as a data point based on the voxel grid but with data 0.

So whenever you build within the ship, it replaces the data 0 (air) by a new data (the one you are creating through the build menu)

 

so if you are building a hoovercraft within a moving space ship, its physical properties could be only activated if the spaceship stops and enters a kind of non physical state allowing created blocks withing the ship to be unlinked

 

Unlinking voxels by creators, but hopefully the spaceship isnt a collective creation before

So might need to add some creation date data to each created voxels, to know which are new and which have been created after last physical state (begining of travel) of the ship

Link to comment
Share on other sites

I think you can build on a moving ship, the grid is relative to the ship, not like space engineers. In the video where jc builds a ship, it's pretty clear to me.

 

the grid applies to built voxels, air have a grid too, but need to make difference between air and void within a ship otherwise if void also have a grid, means the whole DU universe is a grid of data point separated by 25cm

 

i dont think fusioning all computers in the world could store that much data, even if it is 0, since even 0 still takes space on a drive

Link to comment
Share on other sites

nope, enclosed spaces cannot be detected without relative position, but you can detect some cases easily by doing the sum of all faces facing towards the center of mass, if it is zero, it is a simple hollow volume., more complex ones need the position to be able to detect those, as it is the reverse principle from detecting detached volumes

 

i would add too, free octree leaves can be interpreted as void or air, but making fluid dynamics within voxels for those gases is ludicrously complicated, but not impossible. i think it won't come before the final release.

Link to comment
Share on other sites

nope, enclosed spaces cannot be detected without relative position, but you can detect some cases easily by doing the sum of all faces facing towards the center of mass, if it is zero, it is a simple hollow volume., more complex ones need the position to be able to detect those, as it is the reverse principle from detecting detached volumes

 

i would add too, free octree leaves can be interpreted as void or air, but making fluid dynamics for those gases is ludicrously complicated, but not impossible. i think it won't come before the final release.

 

but you still agree that air data within spaceship, by any mean should be calculated and associated to the ship, and diferenciated from the void?

Link to comment
Share on other sites

but you still agree that air data within spaceship, by any mean should be calculated and associated to the ship, and diferenciated from the void?

I agree with your idea but not the implementation. Handling it block wise is extremely inefficient as if there is a breach or you enclose scaces you have to iterate over every block and update it. The best way to go in my opinion is to define an area and expand/contract it depending on the geometry around. When you are building, if you create a concave geometry it creates a new bubble that will be void while it is connected to void. When it becomes enclosed, it detects if there is a atmosphere generator or equivalent to insert that gas generated by it inside. This is efficient enough for if you breach a hull generate a force that pushes all gasses and you out :D.

 

Even then it would be quite expensive but way less than doing it block based.

Link to comment
Share on other sites

I don't mean to interrupt you guys' interesting discussion on algorithms, but I think an equally important discussion to have isn't can we build on moving ships, but should we be able to build on moving ships?

 

Just off the top of my head I can think of several balance issues with this, specifically when it comes to combat. What's to stop people from running around on extra-large ships and replacing/adding weapons mid fight? Or adding armor, shields, thrusters, etc? Even if you disable building while engaged in combat, there's the ability to quickly re-design your ship as soon as you anticipate a fight, which I suppose would depend on the range you can see people, but still. Then you have to worry about transport ships re-tooling for combat right before the pirates show up and start killing them. On the one hand, that could be very interesting gameplay... but how on earth do you manage to balance something like that?

 

Additionally, imagine the economic impact of being able to edit fully functional ships. Why would you ever buy more than 1 ship (or why would there be more than one type of ship on the market) if you can just re-tool them to your specific situation? Without knowing any of the specifics on how ships will work exactly, if you could edit ships at any time, why not just carry around a ton of parts and replace them when you need them? I'd just fly around in my combat ship until I found some nice resources worth mining, and then I'd replace the guns with mining equipment or whatever. Same goes for any specialized ship equipment. If people can do such things, then there stops being a need for ship types that have specific capabilities. Everyone would just buy the most efficiently customizable ship possible and swap things around as needed.

 

Needless to say, I don't like the idea of being able to do this, as it sacrifices a lot in terms of game depth.

Link to comment
Share on other sites

I don't mean to interrupt you guys' interesting discussion on algorithms, but I think an equally important discussion to have isn't can we build on moving ships, but should we be able to build on moving ships?

 

Just off the top of my head I can think of several balance issues with this, specifically when it comes to combat. What's to stop people from running around on extra-large ships and replacing/adding weapons mid fight? Or adding armor, shields, thrusters, etc? Even if you disable building while engaged in combat, there's the ability to quickly re-design your ship as soon as you anticipate a fight, which I suppose would depend on the range you can see people, but still. Then you have to worry about transport ships re-tooling for combat right before the pirates show up and start killing them. On the one hand, that could be very interesting gameplay... but how on earth do you manage to balance something like that?

 

Additionally, imagine the economic impact of being able to edit fully functional ships. Why would you ever buy more than 1 ship (or why would there be more than one type of ship on the market) if you can just re-tool them to your specific situation? Without knowing any of the specifics on how ships will work exactly, if you could edit ships at any time, why not just carry around a ton of parts and replace them when you need them? I'd just fly around in my combat ship until I found some nice resources worth mining, and then I'd replace the guns with mining equipment or whatever. Same goes for any specialized ship equipment. If people can do such things, then there stops being a need for ship types that have specific capabilities. Everyone would just buy the most efficiently customizable ship possible and swap things around as needed.

 

Needless to say, I don't like the idea of being able to do this, as it sacrifices a lot in terms of game depth.

well dont expect the death star be built in 1 day. it will be a traveling scafold for a while.

 

thats not an option to be able to edit, customize,repair a ship. thats already how the game is

 

 

last post were more about ability of crew members to build their own stuff while traveling on a spaceship. and this quite a game mechanic issue.

Link to comment
Share on other sites

well dont expect the death star be built in 1 day. it will be a traveling scafold for a while.

Neither of the Death Stars were built upon while in transit, and the second one never actually moved from its orbit around the forest moon of Endor.

 

There's already a similar thread about whether or not inertial effects should apply to constructs in transit in the Idea Box subforum.

Link to comment
Share on other sites

The detached  voxels on ships will be needed because the elements etc will fill the gaps. You don't want to waste mass by putting extra voxels inside the elements to bridge though them. You don't want clipping artefacts.  

 

In landscapes floating voxels and floating mountains are a consequence of wanting caves, without them all caving in randomly and becoming ditches. On world generation many cave generators produce either artefact: small and large floaters; Generally at the point where two or more cave propagation processes collide with each other or the surface mesh. It is less of a problem if you have mining as the only way to create a hanging voxel. 

In some games only some voxels can fall. The minecraft solution but you could add one that is stone not gravel or sand. (falling blocks actually comes from dwarf fortress) Hit that gravel and the gravel above above falls. There is a catch the JC mentioned in more than one interview. Every falling block in minecraft is three voxels: top falling, mid falling and landed. Mojang, I believe, is now optimising by creating one falling block with an inventory that can hold any other block and spawns it on landing. However it is still a lot of block up dates. Lag and desynching in multiplayer with lots of falling blocks is bad, and that's with 1 metre blocks. 

 

With 25 cm blocks it is worse because our mining tools will not be the same scale. They will be 2-3 m spheres not one voxel at a time. A single 2 metre deletion leaves ~200 voxels with air under them. If they fall that's 600 falling voxels! and then the one's above them fall, another 200 and so on. A recipe for massive lag even in single player game and this is a multiplayer game. 

 

There are some solutions but they are mostly not alpha or beta stuff. You just can' t test for every voxel in the world. We could not even test for every surface voxel [can see sky]. There are too many of them.

 

  1. We could in theory test for every floating voxel at high LOD to clear some extremely large floaters. 
  2. We could make caves, and world gen tunnels propagate up into the sky far enough to kill most small floaters. Some floaters are a consequences of the cave algorithm ending at the surface. This would mean fewer over hangs at cave entrances. 
  3. We could make the corner voxel in each chunk unmine-able without special tools and no drop. We could make caves also not able to remove this voxel in world gen. This would create a support grid to eliminate large floaters. 
  4. We Should do a closed surface test only in the forward arc of the player out to 30 metres. This reduces the number we are working.
  5. It change could thus count as a player made change even though the player does not see it. However in some terrain that will add up fast.
  6. In the context of 5 we could do a migration test on rock and dirt. Any voxel that can see sky and has air under it turns to an unstable state voxel USV. This then infects any rock near it propagating, if it meets another USV it will Spawn a columb of voxels in all air voxels below. USV time out after 5 cycles. This may be a player proximity up date and count as a player change. This may wall off some caves.  
  7. Or in the context of 5 we could do a per cent air in sphere volume on any voxel that can see sky and has air below it. And despawn the voxels if The percent air is two high. This would smooth some terrain a lot. That may kill canyons, ledges and edges. 
  8. In mining we could replace the falling voxels with a sprite cloud and just delete some voxels above. Then create a rubble voxel on the floor. Add terrifying noise. This even worked in a mine in Second Life! All done with prims. 
  9. We could do the above tests 5 & 6 and spawn vegetation or rock piles to hide small floaters. 
  10. We could add a super cheap gravity gun that allows the players to delete any offending floaters at long range. 

In short the floating voxel bits and pieces are needed on ships.

It's not needed in the worlds but they are hard to eliminate in world.

It can be done only if you segment the job down to the local player movement/ changes level.  

But you can make it an 'unconscious' player process.

Link to comment
Share on other sites

The detached  voxels on ships will be needed because the elements etc will fill the gaps. You don't want to waste mass by putting extra voxels inside the elements to bridge though them. You don't want clipping artefacts.  

 

In landscapes floating voxels and floating mountains are a consequence of wanting caves, without them all caving in randomly and becoming ditches. On world generation many cave generators produce either artefact: small and large floaters; Generally at the point where two or more cave propagation processes collide with each other or the surface mesh. It is less of a problem if you have mining as the only way to create a hanging voxel. 

In some games only some voxels can fall. The minecraft solution but you could add one that is stone not gravel or sand. (falling blocks actually comes from dwarf fortress) Hit that gravel and the gravel above above falls. There is a catch the JC mentioned in more than one interview. Every falling block in minecraft is three voxels: top falling, mid falling and landed. Mojang, I believe, is now optimising by creating one falling block with an inventory that can hold any other block and spawns it on landing. However it is still a lot of block up dates. Lag and desynching in multiplayer with lots of falling blocks is bad, and that's with 1 metre blocks. 

 

With 25 cm blocks it is worse because our mining tools will not be the same scale. They will be 2-3 m spheres not one voxel at a time. A single 2 metre deletion leaves ~200 voxels with air under them. If they fall that's 600 falling voxels! and then the one's above them fall, another 200 and so on. A recipe for massive lag even in single player game and this is a multiplayer game. 

 

There are some solutions but they are mostly not alpha or beta stuff. You just can' t test for every voxel in the world. We could not even test for every surface voxel [can see sky]. There are too many of them.

 

  1. We could in theory test for every floating voxel at high LOD to clear some extremely large floaters. 
  2. We could make caves, and world gen tunnels propagate up into the sky far enough to kill most small floaters. Some floaters are a consequences of the cave algorithm ending at the surface. This would mean fewer over hangs at cave entrances. 
  3. We could make the corner voxel in each chunk unmine-able without special tools and no drop. We could make caves also not able to remove this voxel in world gen. This would create a support grid to eliminate large floaters. 
  4. We Should do a closed surface test only in the forward arc of the player out to 30 metres. This reduces the number we are working.
  5. It change could thus count as a player made change even though the player does not see it. However in some terrain that will add up fast.
  6. In the context of 5 we could do a migration test on rock and dirt. Any voxel that can see sky and has air under it turns to an unstable state voxel USV. This then infects any rock near it propagating, if it meets another USV it will Spawn a columb of voxels in all air voxels below. USV time out after 5 cycles. This may be a player proximity up date and count as a player change. This may wall off some caves.  
  7. Or in the context of 5 we could do a per cent air in sphere volume on any voxel that can see sky and has air below it. And despawn the voxels if The percent air is two high. This would smooth some terrain a lot. That may kill canyons, ledges and edges. 
  8. In mining we could replace the falling voxels with a sprite cloud and just delete some voxels above. Then create a rubble voxel on the floor. Add terrifying noise. This even worked in a mine in Second Life! All done with prims. 
  9. We could do the above tests 5 & 6 and spawn vegetation or rock piles to hide small floaters. 
  10. We could add a super cheap gravity gun that allows the players to delete any offending floaters at long range. 

In short the floating voxel bits and pieces are needed on ships.

It's not needed in the worlds but they are hard to eliminate in world.

It can be done only if you segment the job down to the local player movement/ changes level.  

But you can make it an 'unconscious' player process.

 

there is a simple solution, and a minecraft mod already did it. This can only be used for terrain.

when a block is updated it tests in a circle of voxels directly underneath him if there is a connecting voxel, if there is it doesn't collapse, if there isn't it falls and reattaches itself to the floor. This can be done if voxels are updated after every interaction, even terrain gen. if a terrain voxel collapses, it updates nearby voxels. here is the terrafirmacraft post

Link to comment
Share on other sites

I don't mean to interrupt you guys' interesting discussion on algorithms, but I think an equally important discussion to have isn't can we build on moving ships, but should we be able to build on moving ships?

 

Just off the top of my head I can think of several balance issues with this, specifically when it comes to combat. What's to stop people from running around on extra-large ships and replacing/adding weapons mid fight? Or adding armor, shields, thrusters, etc? Even if you disable building while engaged in combat, there's the ability to quickly re-design your ship as soon as you anticipate a fight, which I suppose would depend on the range you can see people, but still. Then you have to worry about transport ships re-tooling for combat right before the pirates show up and start killing them. On the one hand, that could be very interesting gameplay... but how on earth do you manage to balance something like that?

 

Additionally, imagine the economic impact of being able to edit fully functional ships. Why would you ever buy more than 1 ship (or why would there be more than one type of ship on the market) if you can just re-tool them to your specific situation? Without knowing any of the specifics on how ships will work exactly, if you could edit ships at any time, why not just carry around a ton of parts and replace them when you need them? I'd just fly around in my combat ship until I found some nice resources worth mining, and then I'd replace the guns with mining equipment or whatever. Same goes for any specialized ship equipment. If people can do such things, then there stops being a need for ship types that have specific capabilities. Everyone would just buy the most efficiently customizable ship possible and swap things around as needed.

 

Needless to say, I don't like the idea of being able to do this, as it sacrifices a lot in terms of game depth.

 

I like the way that you are looking at this, thinking about the game-play implications is important.

 

My solution would be to disable building while in combat, if you are "on" (touching or in a seat) a construct that has taken pvp damage you get a PVP flag set which disables the building tools until some time after a cool down period. This would prevent long drawn out battles where the winner is basically the person who can rebuild faster and brought the most resources.

Link to comment
Share on other sites

I like the way that you are looking at this, thinking about the game-play implications is important.

 

My solution would be to disable building while in combat, if you are "on" (touching or in a seat) a construct that has taken pvp damage you get a PVP flag set which disables the building tools until some time after a cool down period. This would prevent long drawn out battles where the winner is basically the person who can rebuild faster and brought the most resources.

 

that is a simple solution, but the best way to do it in my opinion is to disable the offensive systems while building in designer mode, in real block placement, the AOE of the weapons will probably kill you. This would allow for people to repair their ships to some extent while fleeing thus increasing survival rate. it could be extended to removing the defensive capabilities too, except the ones that are projected onto it from another construct/vessel (star wars VI with the endor shield generator), if that fleeing construction seems to be OP.

Link to comment
Share on other sites

 

My solution would be to disable building while in combat, if you are "on" (touching or in a seat) a construct that has taken pvp damage you get a PVP flag set which disables the building tools until some time after a cool down period. This would prevent long drawn out battles where the winner is basically the person who can rebuild faster and brought the most resources.

 

I absolutely agree, this would be a good work-around for the mid-combat refit problem. But it doesn't solve the issue of people refitting ships in deep space, thus removing the need for specialized ship hulls. I think that would be a major mistake because it removes an awful lot of gameplay depth.

 

I would suggest adding a "completed" mode that disables all functions (shields, weapons, engines, etc) until the ship is fully built, but once a ship is complete you can no longer add blocks. In this model I would consider "repairing" to be a completely different process that only re-builds destroyed blocks.

 

I realize that idea has some issues, like having to build massive ships quickly because they're vulnerable the whole time they're being built, but I don't think that's necessarily bad gameplay; and I really fear the consequences of having ships that can be edited at any time anywhere.

 

Perhaps include a shipyard modual for space stations so that ships can only be edited at an established space station? In addition to being a way to balance combat and building, it would help justify the need for massive space stations. If each "Drydock" can only repair or build 1 ship at a time, then you'd need tons and tons of Drydocks for all the building and repairing that will be going on in this universe. Some of them would have to be truly huge as well if you wanted to make really big ships.

Link to comment
Share on other sites

I absolutely agree, this would be a good work-around for the mid-combat refit problem. But it doesn't solve the issue of people refitting ships in deep space, thus removing the need for specialized ship hulls. I think that would be a major mistake because it removes an awful lot of gameplay depth.

 

I would suggest adding a "completed" mode that disables all functions (shields, weapons, engines, etc) until the ship is fully built, but once a ship is complete you can no longer add blocks. In this model I would consider "repairing" to be a completely different process that only re-builds destroyed blocks.

 

I realize that idea has some issues, like having to build massive ships quickly because they're vulnerable the whole time they're being built, but I don't think that's necessarily bad gameplay; and I really fear the consequences of having ships that can be edited at any time anywhere.

 

Perhaps include a shipyard modual for space stations so that ships can only be edited at an established space station? In addition to being a way to balance combat and building, it would help justify the need for massive space stations. If each "Drydock" can only repair or build 1 ship at a time, then you'd need tons and tons of Drydocks for all the building and repairing that will be going on in this universe. Some of them would have to be truly huge as well if you wanted to make really big ships.

 

your points are good, make repairing readily available, but at a cost of drones/modules, and enable building only while landed on the surface or docked at a spaceport, or when disabling all power sources which disables the ship.

 

What i would like to see too is the merging of voxels: you can slam together two voxels, thus allowing to void-weld things together in space (could be prohibited with a deflector module). this would allow to do this:

star-wars-rogue-one-death-star-wallpaper

or do something like merge blocks.

Link to comment
Share on other sites

that is a simple solution, but the best way to do it in my opinion is to disable the offensive systems while building in designer mode, in real block placement, the AOE of the weapons will probably kill you. This would allow for people to repair their ships to some extent while fleeing thus increasing survival rate. it could be extended to removing the defensive capabilities too, except the ones that are projected onto it from another construct/vessel (star wars VI with the endor shield generator), if that fleeing construction seems to be OP.

 

This is also a good idea, but still doesn't solve the issue of people re-fitting ships in deep space for purposes they were not designed for, which in my opinion basically removes the need for specialized ship hulls. For example, how much fun would EVE Online be if every ship was only defined by the moduals you put on it? In DU, what's to stop people from just re-building the same ship over and over to suit their changing needs? That would completely cripple the market for ships and put all of the emphasis on gear.

 

Personally, I'd still have multiple ships, because that's cool, but you have to plan for the worst-case scenario of what hardcore players will do; and they will always go for the most absolutely efficient method. I'm afraid that if you allow refitting after "completion", then you'll see major organizations all flying around in the same ship modal 24/7 that can easily be swapped out with the pieces they need. In my mind that's just a globe with the guns sticking off the sides, so you can quickly run around outside and switch them out for whatever weapons or utilities you need at that very moment.

 

That sort of meta does not promote interesting gameplay, in my opinion.

Link to comment
Share on other sites

This is also a good idea, but still doesn't solve the issue of people re-fitting ships in deep space for purposes they were not designed for, which in my opinion basically removes the need for specialized ship hulls. For example, how much fun would EVE Online be if every ship was only defined by the moduals you put on it? In DU, what's to stop people from just re-building the same ship over and over to suit their changing needs? That would completely cripple the market for ships and put all of the emphasis on gear.

 

Personally, I'd still have multiple ships, because that's cool, but you have to plan for the worst-case scenario of what hardcore players will do; and they will always go for the most absolutely efficient method. I'm afraid that if you allow refitting after "completion", then you'll see major organizations all flying around in the same ship modal 24/7 that can easily be swapped out with the pieces they need. In my mind that's just a globe with the guns sticking off the sides, so you can quickly run around outside and switch them out for whatever weapons or utilities you need at that very moment.

 

That sort of meta does not promote interesting gameplay, in my opinion.

 

withe the script system they plan i doubt people will stop at a ship. it will be one man fleets, that can be controlled purely with scripts you buy on market.

Link to comment
Share on other sites

your points are good, make repairing readily available, but at a cost of drones/modules, and enable building only while landed on the surface or docked at a spaceport, or when disabling all power sources which disables the ship.

 

What i would like to see too is the merging of voxels: you can slam together two voxels, thus allowing to void-weld things together in space (could be prohibited with a deflector module). this would allow to do this:

 

 

 

I would also like to see massive space stations and the Death Star (we all know there's going to be one) built in this manner, because it would be very very cool. But imagine the technical difficulties in doing something like that?

 

In the end, I imagine that space stations will need to have different rules that space ships.... but the Death Star is really just a massive space ship, so I have no idea how that could be worked out. At least the Devs have a few years to think about it, because that's how long it should take to make something like a Death Star. Heck, if they do it right I hope it takes a couple months just to make the first stargate.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...