Jump to content

Multi block system/weaponry


OmnipotentVoid

Recommended Posts

Yeah you can basically ignore my first to paragraphs they were simply meant to point out that both games have their pros and cons regarding the topic, without going in depth.

 

Regarding the props, they are basically the components that translate engine power into movement, so they would be the flame exhausting things (don't know the correct term, nosel maybe?) on a thruster, at least in my eyes.

 

So to clearify how i think naval translates to space in terms of engines, thrusters and reactors:

Engine + Prop = Thruster

Engine + Generator = Reactor

 

The only idea i have regarding the skill system would be, that the whole thruster and the thruster components would be unlocked together. Maybe i have more if there is more about the skill and component unlock system.

 

Sorry if i have confused you my brain is currently a bit jumpy and sometimes i confuse myself, at least regarding this topic. The only thing i really want to say is, that i want a good made compromise between this two systems, because it would remove most of the cons of both systems.

Link to comment
Share on other sites

Space Engineers's building system is a lot more in depth than you make it sound. From the sounds of it, you only played creative. In creative, all you need is a single reactor, a single gyro, some thrusters, and guns. Weapons have infinite ammo, reactors last forever. It's not very fun.

In survival, however, you need to hook your weapons up to your storage so they can reload. You need to refill your reactors with uranium. Batteries need power to work (They ar also infinite in creative) You need to place all of these things so that you can access them without tearing half the ship off. In short, it's a lot more complicated than you think. Although, it's still pretty simple in my eyes.

I support the idea of MBSs though, it makes sense. If it fits inside DU, however, is another question.

Link to comment
Share on other sites

Space Engineers's building system is a lot more in depth than you make it sound. From the sounds of it, you only played creative. In creative, all you need is a single reactor, a single gyro, some thrusters, and guns. Weapons have infinite ammo, reactors last forever. It's not very fun.

In survival, however, you need to hook your weapons up to your storage so they can reload. You need to refill your reactors with uranium. Batteries need power to work (They ar also infinite in creative) You need to place all of these things so that you can access them without tearing half the ship off. In short, it's a lot more complicated than you think. Although, it's still pretty simple in my eyes.

I support the idea of MBSs though, it makes sense. If it fits inside DU, however, is another question.

I actually played fairly little creative in SE. However the piping system is pretty simple and I find it to be more of an annoyance than anything. You can do some neat things with it, but that takes a lot of effort and time, so most of the time it's connect points A and B. And uranium always gives the same amount of power per unit. In FTD, engines have a lot of depth in design as far as fuel consumption goes, balancing between power per fuel, power per volume and total size and the ability to keep the engine cool.

 

I don't play much of creative in SE, because all the advantages that SE has for me (I'm no programmer, or someone with the time to make the really amazing things) come from the exploration and difficulty of building things in SE.

Link to comment
Share on other sites

I actually played fairly little creative in SE. However the piping system is pretty simple and I find it to be more of an annoyance than anything. You can do some neat things with it, but that takes a lot of effort and time, so most of the time it's connect points A and B. And uranium always gives the same amount of power per unit. In FTD, engines have a lot of depth in design as far as fuel consumption goes, balancing between power per fuel, power per volume and total size and the ability to keep the engine cool.

 

I don't play much of creative in SE, because all the advantages that SE has for me (I'm no programmer, or someone with the time to make the really amazing things) come from the exploration and difficulty of building things in SE.

I suppose. However, keep in mind, FTD is primarily focused on ship against ship combat. Designing your ship is also a main focus, that isn't the case with DU. DU is focused on all of those things plus a whole lot more. As such, a MBS system may not be worth the time, effort and resources. 

Link to comment
Share on other sites

As DU is a game where the player has to design and build (almost) everything from scratch its not far removed from the building focus, though.

 

So something thats more involved than "connect A to B" would be nice to have.

Link to comment
Share on other sites

The point is for the game to be able to function. If a feature is hindering the game's smoothness on your scree, then said feature should not be implemented. Perhaps something easier, like the ability to shrink voxels, sure, but something more eleborate than "connect A to B" is quite the challenge on the technical aspects of the game.

Link to comment
Share on other sites

I think a way to work around the performance loss due to multi-block-structures, could be an entity editor in wich you could build and test your multi-block creations. if you then hit the finish button it would convert your creation into a single entity with fixed stats. So you have the best of both worlds, the customizability of FTD and Starmade and the less performance hungry single entity strategie from SE and Empyrion. And with such an editor you could not only build weapons and reactors, complex mechanical cotraptions would be possibly too.

 

This.  If I recall correctly, it was stated somewhere that this is how the ships will be handled; as opposed to existing as constructs of multiple blocks like SE, they'll be "merged" into a single entity for the sake of performance (I know, links or it didn't happen; I couldn't find the reference).  It stands to reason that you could create sub-components the same way which could be merged into single entities with fixed qualities and then incorporated into larger designs.  A system like this would add tremendous depth and flexibility and open up a market for custom sub-systems that other players could incorporate into their own designs.

Link to comment
Share on other sites

The point is for the game to be able to function. If a feature is hindering the game's smoothness on your scree, then said feature should not be implemented. Perhaps something easier, like the ability to shrink voxels, sure, but something more eleborate than "connect A to B" is quite the challenge on the technical aspects of the game.

 

when you do it properly a multiblock device wouldnt need more resources than the same amount of simple steel blocks plus one functional component.

the individual voxel parts wouldnt need to be called and analysed all the time, only when certain conditions are met they'd have to be handled as something not a simple block. for example when the ship gets damaged you check if any multiblocks got damaged and then recalculate the stats of the relevant device.

you dont poll their functions all the time, you calculate the effectivity of the complete device once and then only use the stats from that calculation until you have to recalculate for changes in the local objects grid.

Link to comment
Share on other sites

@Cornflakes

When you create something in a voxel grid space, you replace the colouring essentially of a voxel to make a whole set of them.
If you make smaller voxels, not by virtually shrinking them but actually raising the number of them by making them smaller, the game will literally take a proportionally amount of hinderance. Let's say the game is an image. An image has pixels. Let's say your image is 2048x2048 pixels. Each of these pixels is a color square. Same applies for Voxels. Now think of amplifying the resolution to 4096x4096. Sure, you got a more detailed picture but an also heavier picture memory-wise. If they figure out a way to make virtual voxel shrinking, then cool, it will change the aesthetic of the game, but amping voxel count in the grid to make "cool multi-voxel construcs" is, in my humble opinion, a pointless endeavor. Perhaps in depth of time, when everyone will have GTX 1080 like me, we could have an amplification of voxel-count in the grid, but for now, let the Devs figure out how to pack more players in an area and just wait to see if the voxel building system they have in mind can satisfy you.


Peace.

Link to comment
Share on other sites

when you do it properly a multiblock device wouldnt need more resources than the same amount of simple steel blocks plus one functional component.

the individual voxel parts wouldnt need to be called and analysed all the time, only when certain conditions are met they'd have to be handled as something not a simple block. for example when the ship gets damaged you check if any multiblocks got damaged and then recalculate the stats of the relevant device.

you dont poll their functions all the time, you calculate the effectivity of the complete device once and then only use the stats from that calculation until you have to recalculate for changes in the local objects grid.

Your statement is true.  It would be less stressful if you ran it that way.  Up to a point.  It merely delays when those calculations are made.  When those "certain conditions" are met all of a sudden it becomes a MASSIVE drain on system resources as it now it has to calculate all the values for the affected voxel parts at once.  This factor could be compounded even further if multiple ships are being damaged in the same area simultaneously.

 

Not saying the idea doesn't have merit just that it would require something else along with it to make it work.  For instance, I thought a possible solution would be calculating that information before hand and it could be part of the blueprint.  Especially if you limited it to voxel and mesh based "elements".  All the calculations would be done already and on the client side.  But this has the disadvantages of taking up an extreme amount of room on a players computer.  (You would need all blueprint information, even for blueprints you don't have.)  It would need micro updates occurring every time someone makes a blueprint, and it would be highly abusable by cheaters.  So, more ideas?  Possible solutions?  Information from the devs that will address this entire thread?  :D

Link to comment
Share on other sites

@Cornflakes

 

When you create something in a voxel grid space, you replace the colouring essentially of a voxel to make a whole set of them.

If you make smaller voxels, not by virtually shrinking them but actually raising the number of them by making them smaller, the game will literally take a proportionally amount of hinderance. Let's say the game is an image. An image has pixels. Let's say your image is 2048x2048 pixels. Each of these pixels is a color square. Same applies for Voxels. Now think of amplifying the resolution to 4096x4096. Sure, you got a more detailed picture but an also heavier picture memory-wise. If they figure out a way to make virtual voxel shrinking, then cool, it will change the aesthetic of the game, but amping voxel count in the grid to make "cool multi-voxel construcs" is, in my humble opinion, a pointless endeavor. Perhaps in depth of time, when everyone will have GTX 1080 like me, we could have an amplification of voxel-count in the grid, but for now, let the Devs figure out how to pack more players in an area and just wait to see if the voxel building system they have in mind can satisfy you.

 

 

Peace.

 

thank you captain obvious, but where did i say to increase voxel density?

the density they showed in the announcement video on that fighter is more than enough to do some multiblock equipment design.

 

 

Your statement is true.  It would be less stressful if you ran it that way.  Up to a point.  It merely delays when those calculations are made.  When those "certain conditions" are met all of a sudden it becomes a MASSIVE drain on system resources as it now it has to calculate all the values for the affected voxel parts at once.  This factor could be compounded even further if multiple ships are being damaged in the same area simultaneously.

 

Not saying the idea doesn't have merit just that it would require something else along with it to make it work.  For instance, I thought a possible solution would be calculating that information before hand and it could be part of the blueprint.  Especially if you limited it to voxel and mesh based "elements".  All the calculations would be done already and on the client side.  But this has the disadvantages of taking up an extreme amount of room on a players computer.  (You would need all blueprint information, even for blueprints you don't have.)  It would need micro updates occurring every time someone makes a blueprint, and it would be highly abusable by cheaters.  So, more ideas?  Possible solutions?  Information from the devs that will address this entire thread?  :D

 

why would you do those calc on the client side?

and why would you have to update them when anyone in the universe updates a blueprint?

 

the client does nothing of importance, never, and only gets the data that he needs and not the whole game database.

 

when a ship gets built, calculate the equipment effectivity on the server (and on clients who are near enough to it to check the data, for lag hiding) and store it on the server to be transmitted to relevant clients when the ship loads in.

 

and most clients dont even need most of the data of a piece of equipment anyway, because its the servers job to keep clients in their capability bounds.

Link to comment
Share on other sites

thank you captain obvious, but where did i say to increase voxel density?

the density they showed in the announcement video on that fighter is more than enough to do some multiblock equipment design.

 

 

 

why would you do those calc on the client side?

and why would you have to update them when anyone in the universe updates a blueprint?

 

the client does nothing of importance, never, and only gets the data that he needs and not the whole game database.

 

when a ship gets built, calculate the equipment effectivity on the server (and on clients who are near enough to it to check the data, for lag hiding) and store it on the server to be transmitted to relevant clients when the ship loads in.

 

and most clients dont even need most of the data of a piece of equipment anyway, because its the servers job to keep clients in their capability bounds.

The calculations wouldn't be done client side only the RESULTS would be saved there.  It was an unconventional idea to relieve system stress server side.  Nothing more.  As for the database of blueprints, it would be necessary if all resultant data was stored client side.  But I thought of it as a POSSIBLE solution.  One that I largely dismissed because of all the problems it would create.  Unless someone else had an idea to resolve it.  Got any of those?  If not you can pretty much ignore the post.

Link to comment
Share on other sites

the result storage would be tinytinytiny compared to all the other stuff they already have to store.

 

and the blueprints themself could be stored on the client of the respective player, if theres an external editor to do so, before the player does anything with them in-game.

but then it'd be annoying to have your creations bound to your computer instead of your account in a MMO.

 

and as many many blueprints will already be traded on the market which have to be stored server side to be made available to other players, im not sure it would give so much relief.

Link to comment
Share on other sites

the result storage would be tinytinytiny compared to all the other stuff they already have to store.

 

and the blueprints themself could be stored on the client of the respective player, if theres an external editor to do so, before the player does anything with them in-game.

but then it'd be annoying to have your creations bound to your computer instead of your account in a MMO.

 

and as many many blueprints will already be traded on the market which have to be stored server side to be made available to other players, im not sure it would give so much relief.

I'm not sure it would be of great benefit either.  Just throwing ideas out.

Link to comment
Share on other sites

@cornflakes

 

 

How big of an item you wanna build? Five square feet or something? Cause I got the impression you aimin' for lower than that, which will need more voxels on the grid.

Link to comment
Share on other sites

@cornflakes

 

 

How big of an item you wanna build? Five square feet or something? Cause I got the impression you aimin' for lower than that, which will need more voxels on the grid.

 

im aiming for something sensible.

 

but from what i have seen in the video the grid size seems to be on about the same scale as from the depths cubes, and there it works reasoably fine for designing stuff

Link to comment
Share on other sites

If we had muti-block-systems would that not encourage team efforts in building a ship. People could specialize in a specific engineering role like weapons , shields , power systems. I could see groups of players forming clans or something of the sorts just based on this. would make the industry side of the game more involved and cooler if there was a team and social element in it.

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