Jump to content

Cores and Constructs


HamyMac

Recommended Posts

I'm not trying to be weird or anything, but, are things starting to get bogged down in 'limitation'? First, it's Territories, now it's Cores. 

 

Just spitballing, but... 
How hard would it be to remove static cores altogether and handle the Territory Unit itself as the Core for all static constructions on it?

'Tagging' honeycomb as generically 'static' (honeycomb that is not attached to a Dynamic or a Space core)  would remove the issue of having to add cores to expand a base on a Territory and release the 'player tension' related to core limitations.

If the actual limitation on constructions is really how much honeycomb you can stack on top of itself to make buildings, then you can remove the core limitations for ground constructs. 
 

For Mining Units and other (possible future) deployables, you could have a Deployable Core that can be placed as a temporary structure on Terrirtories a player wants use but not build a base on. A Deployable Core would preclude any further building on that Territory. 

On claiming a Territory, player could have to declare the nature of the claim by identifying it as an HQ Territory (of  the 5 permitted) of which the equivalent of an L Core area must be built on in order to substantiate the claim or as an Outpost Territory at a lower rate of rental on which only a Deployablle Core (smaller than an L Core) can be placed and no unattached honeycomb building can be constructed on that Terrritory. This way, you can build anywhere across your own HQ territories regardless, but if you wish to mine or place a temporary pvp outpost you can only have that single Deployable Core on that Territory. Thus the nature of the Territory defines what you can buld on it. Additional Territories could be claimed as Subsidiary Territory in the name of the player or Org. 

 

Sub-Plot:
If planet based pvp ever comes into play, then the Territory Unit itself could be the 'Capture the Flag' objective, rather than repetitive core destruction (as in space combat) and a Land Grab objective could be determined by the aggressive deconstruction with weapons of any constructs on the Territory or by taking possession of them with an area-defined, time-limited Battle Unit that asserts conquest from the aggressor that must then be neutralized by the defender or must time-out in order for the defender to repossess their property... perhaps it should take the placing of ten Battle Units to control a whole Territory so an aggressor has to decide on the amount of firepower to bring to the battle and whether they want to posess or demolish the Territory and its assets and a defender has to decide which assets require the most protection.   

 

Dev Blog Constructs

Link to comment
Share on other sites

Because of how voxel work, having a single large tile 'core' with 0.25m resolution would be MUCH more costly on the servers then the same amount of voxels distributed over several static cores each having a smaller local coordinate system.

Link to comment
Share on other sites

Ahhh... makes sense. But if you divided each territory into a dozen build zones, each with an integrated server-side virtual core, that could work, no?
ie: create an internal hex to the territory hex, about half the size and divide the whole thing into 12 segments, each highlighted on hitting the B key so you could see the build area available for that segment.                      

Edited by HamyMac
Link to comment
Share on other sites

45 minutes ago, HamyMac said:

Ahhh... makes sense. But if you divided each territory into a dozen build zones, each with an integrated server-side virtual core, that could work, no?
ie: create an internal hex to the territory hex, about half the size and divide the whole thing into 12 segments, each highlighted on hitting the B key so you could see the build area available for that segment.                      

Practically no difference from the current core-system :)

Link to comment
Share on other sites

3 minutes ago, Yoarii said:

Practically no difference from the current core-system :)

Yes, but you don't have to place them, or stack them... you would just build off the ground and up as high as you wanted, so no need for a hundred cores to build your towers. 

 

Link to comment
Share on other sites

what you're suggesting is just another alias of how data, on fundamental level is already partitioned with current core system, benefits of this are questionable at best, it just brings in more problems.  What you're suggesting has been done in second life 20 years ago. And they've been paying the price for it to this very day.

 

If we actually had proper way to do blueprint alignment, (snap to grid style) there would have been zero point to even talk to about this.

Link to comment
Share on other sites

3 minutes ago, Bazzy_505 said:

what you're suggesting is just another alias of how data, on fundamental level is already partitioned with current core system, benefits of this are questionable at best, it just brings in more problems.  What you're suggesting has been done in second life 20 years ago. And they've been paying the price for it to this very day.

I didn't know that... alternatively, could they not just make the cores all one size and flexible in area and height... so you place a core and choose the perameters, set volumes but different dimensions, so you could build a tower from one core or a massive landing pad a few metres in height?

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...