Your English is good, Neal. I like the idea, but would like to know more about the code mechanics, notably how much of the damage is handled server-side versus client side. If the server is tracking every single voxel in the game, then I shudder to think of the resources involved. I think grouping the ships is a good idea (and I voted as such). I do want to qualify my vote with the following information. My support of grouping is not to say that I would want to lose the elements of voxel-based ship design. I have a lot of fun thinking of defensive builds and being able to target specific systems! For example, placement of redundant thrusters and RCS can get you out of trouble if you stumble on a POI or unexpected PvP situation. If the server IS tracking each voxel, I think it would be best left to the client and just track a grouped mesh. That way damage can be assigned and processed more effectively by having a single collider pass information to the client machine, such as the location and angle of a strike, than figuring it out block by block on the server. (I apologize to the designers if I am speaking ignorantly on the topic). I would sacrifice seeing the ship mesh rendered for each hit if that would improve other aspects of the game experience (larger ships and bases, more players per planet, etc).
I feel the best way to handle this is to make all the steel blocks respond like hull/armor and absorb damage into adjacent steel blocks so that they can soak damage more effectively. Not actually make them all one object but allow them to share damage to a degree so they can work better as armor. Something like half the damage a steel block takes is distributed to all adjacent steel blocks or something.
It seems a bit like a shell game: yes, processing may be more expensive when the ship is made out of pieces, but it is also still expandable and repair-able easily. Once the pieces are merged- how would the system keep track of where to display damage? If the tail is shot, does this lower the strength of the front? If I shoot a hole in the side, does the container inside float out, and if so, how is that dependency tracked? The complexity of the game and the ships does not seem a simple thing to reduce without losing some of what makes the game interesting.
To simplify this idea, and yet make it more complex in a couple degrees, here's a couple thoughts. - The core itself, when aimed at, has a right-click, or interact, option, that allows the ship to be melded/unmelded. No need for the designated facilities, just physical access to the core OR the control panel? - I like the nature of armor, but the dozens of layers makes it complicated. Perhaps another use of the repair bay (or another device we don't currently have, or again, the panel) could be to add armor to a vessel. This armor would work as the current armored blocks do, and add a layer o defense. The armor cost would be calculated based on...number of blocks on the external surface (so, total surface area?) and could prevent X % of damage (the rest not being absorbed, thereby transferring to the squishy bits inside). As armor in an area (using a pre-set size, like say 10 m^2) is damaged, it becomes less useful, allowing more of that damage through, into the squishy bits? That might be beyond the scope of this idea though, even if they were related in some ways. This could bring up some interesting possibilities of different TYPES of armor, each weapon having different penetration values, and so on. It would also allow you to concentrate fire on one section of a ship, and eventually make it all the way through the armor, to the squishy bits, and squish them. This would also still allow players to continue massively upgrading the armor, provided they have materials, without a huge block increase for each layer, without altering the cost to do so; it would also still allow for focused fire, and for things like systems failures, internal damage, etc, in combat.
On the whole I like idea but have some doubts. Are we using a dubious measure of game speed here ? That has changed through that last few patches more that once. If this is based on the technical limits people are seeing. I am hoping those limits improve first before we ask for a work around. I being super optimistic here based on some passed bug fixes. Now and again we had something that slowed the game down. Once the root problem is fixed the game improved. Once we do hit a true limit then that will be the time to look for changes to game mechanics. How much speed will be made up in later optimization. We can only speculate. Another point is the problem might be limited to only a certain group of people that want 1:1 scale models of famous massive ships. If they are using hundereds of blocks as a "filling material" to just get size. What is really needed is a bigger block. To fill bigger gaps. Windows already can be made to cover 4 squares with a single block. How about letting them build say a 5x5 block of armour. At 25 times the cost in steel? Even bigger blocks are possible to give the same benefit. Less time comsuming to fix. Gives bigger ships. However not cheaper or better that what we have now. If they get destroyed the ship gets a really big hole in it. Same thing as happens now but we get lots of little holes. The effect is big ship with less blocks for the computer. Same in game cost as we now have. Same damage mechanic as we now have. This represents the same idea in smaller steps. Instead of hunderes of blocks to look after. There is a lot less for the system to store. However the overall game does not have to be changed so much. Apart from that. If the problem does exist on block counts and is big enough to worry about. Then I am in with a thumbs up. Yes to kinetic kills. Your looking for HESH warheads that sent shock waves through the hull. Those snap off stuff attached to the other side with no penetration of the outer layer. Pipes break, machines jam and computers fall apart when the walls they are attached to shake violently. Bits also chip off the inside surface and fly around like bullets. See https://en.wikipedia.org/wiki/High-explosive_squash_head. So if you want a reason for guns that don't poke holes in the ship. There is a good start. In game terms damage spreads to adjacent blocks with each hit. Less and less as it gets passed along through the armour. Unless it lands on something other that armour. Everything else accumulates damage and can blow up. So blocks fall off the inside of the ship. We don't track damage of the armour one block at a time. It either goes through and hits something else less sturdy or slowley builds up to total destruction of the whole outside shell. The bigger blocks idea is the lowest version of the concept. Without getting into using "chunks" of ship. The hope here is still less blocks improves performance. By giving a player the opportunity to use bigger blocks but less of them. We passing part of the problem of too many blocks back to the end users. Giving them an alternative way save on the total count. The question then becomes. How many blocks do we track before it becomes an issue again and bigger blocks will not help? There still lots of blocks here. Just the possiblity of using less of them to do a big build. If this still too much then we are going to try doing it by splitting a ship up like loaded chunks. A bit more difficult to manage but possible in the long run. It gives less for the computer to manage but it changes the game play. Something to carefully weight in. Yes indeed it would help. Less blocks either way is better. The only question is how many low PCs are we catering for here? This idea fixes the issues for slow computers that is for sure but at the risk taking away a more granular combat experience for everyone with average computers or higher computers. I am still in overall favour of this but it is a big decision. One that changes the gameplay significanly for a lot of people that might not have issues with game speed later on in development. In the long run I think people will go for bigger ships and more ships. Rather that detailed block by block damage. Despite the fact it does change the original game design path we started off with.
Damage is calculated once when it hits, regardless of if it hits one mega-block or one tiny fingernail. I don't think just chunking the health of the ship into one pool would actually result in so dramatic improvement in performance. The main problem is probably in rendering, not in damage calculations, and combining the ship into one 'mega block' would change nothing for rendering by itself. On rendering side the number of "blocks" (as defined by the game mechanics) means nothing, what matters is the number of vertices. While you could say it's the side product of blocks (since each block has particular vertices), just by arbitrarily combining a bunch of blocks, you can't cut out the vertices. You'd also need to do some more complex analysis of the resulting mesh, cut out and combine the redundant vertices, re-build the resulting mesh, and apply textures to the new faces that resulted. You'd need an algorithm that's aware of empty space both inside and outside of the ship, in order to generate the needed faces to show the ship hull from all directions. If you can accomplish all that, you'd probably be able to apply occlusion culling effectively to the ship - you'd be able to disable rendering of anything that isn't showing up, since the mesh would now be a single unit where no individual blocks are going to be removed (destroyed) - which can expose new faces of blocks that were previously hidden. So yes, technically you could end up with huge savings, but to accomplish all this would probably be rather monumental task. Any system that tries to combine random bunch of blocks will face this same problem - combining blocks for purpose of rendering them isn't as simple as just saying "these blocks are now one" (unless there's some kind of built-in function to accomplish this in the game engine, that would of course change a lot). One thing that could give big savings to rendering with relatively little changed, would be to go with ready-made larger blocks where it makes sense. This is same solution FTD (From The Depths) is using. Essentially there are beams of size 1, 2, 3 and 4, of various shapes (box, wedge, slope, corner etc) that you can use as building blocks. Since the shapes are standard, they can dramatically reduce the vertex count - a beam of length 4 uses same number of vertices as a simple 1 block box. If you look at the shapes available now, it's easy to see how many of the blocks could have 2-size variations (slopes and various corner pieces). A plain box is generally by far the most common piece, and also easiest to make a combination of. Beams of size 2, 3 and 4 would be useful. We could also go beyond that, and have wall blocks of 2x2, 2x3 and 2x4, possibly 3x3, 3x4 and 4x4. (metal block shapes of 'From The Depths') The change could use the existing mechanics, simply introduce several new blocks that are more economic to render. The whole thing would be entirely at hands of the builder - they could pick and choose where and when it works for their design. The new blocks would of course need to have the health relative to size they represent (combat steel cube has 2000 health, so 2x2 combat steel wall would need to have 8000 health). You'd probably need several templates for the blocks, since they should have different resource cost (1, 2, 3, 4, 6, 8, 9, 12 and 16 sizes). Probably this could be simplified to 3 or 4 different templates, and perhaps the reduced resource cost could act as an added incentive to use the bigger blocks. Another option would be to make bigger blocks cost more "block templates" to apply, so to apply 3x3 wall you'd need to have a stack of at least 9 blocks in your bar, and it would use up 9 of them - for the builder this would be by far the easiest solution, leaving out the tedious task of managing several different 'template stacks', both in inventory and in hotbar. Either way the important thing is they would have to have the health comparable to their size, or they wouldn't be used as hull blocks.. which is the entire point. I realize to get full benefits of this there would have to be hundreds of new blocks - all manner of slopes, pipes, half-height corners, thin walls.. of many different materials. But just making this for several of the most common shapes would probably be a big benefit. On a side note, I'd like to see this health increase applied to current blocks such as window / armored window. For example right now I often feel forced to use 1x1 armored window on critical areas like cockpit, even when 2x2 could be used - because by using 1x1 individual pieces I get four times as much health for the structure. -- edit -- On second thought there's one thing where just merging the ship into single unit probably would save resources - merging the ship into single 'hitbox'. I don't know how Empyrion handles this right now, but I'm guessing the ship would have one 'super-hitbox' that's used globally to see if an attack (or collision) hits the ship at all.. and if it does, then hitboxes of individual blocks would be tested to see what individual block is affected. Merging might ease the second part of the calculation. It probably isn't proportionally large strain to the system under normal conditions, but in large scale battle it might become significant (although then the rendering of 10+ capital ships probably tops that).
If that is the case it would be nice to have the option to jettison those section to gain increased maneuverability due to decreased mass. Also it would put pirates off if they had to loot several jettisoned compartments instead of fleeing after a quick kill. This would off players a chance to muster forced and retaliate.
That's my thought as well. Given that even a phone can be rendering millions of triangles each second, it seems like collision detection of large cubes shouldn't be the overwhelming factor in the cost of playing with a large spaceship....
Are there any updates on when and if they are taking interest in this merge feature? This would really be a great addition to the game. @Hummel-o-War @piddlefoot
As the votes are split 31 to 32 in favor, it seems this concept is not conclusively desired. There is no question this would simply the engine strain of combat but it would also make the game more cookie cutter, relying on generic HP pools to determine damage. Effectively you could fire on the thrusts all day and damage could appear on the nose first. Targeted Isolation of damage is one of the few things that makes Empyrion unique. It gives characters to the game.
We've been told that alpha 7 will have the option to copy and paste a selection of blocks. Theoretically we will be able to assemble ships from a selection of custom prefabs. If you applied some rules to the size of each copyable section(limiting how big each could be), and treated these sections as individual compartments then you have the mechanic to define individual bulkheads and damage per section. If you could name each section you could manage these from the control panel to monitor overall damage to the section, deactivate sections, (and lets not forget the possibility to repair from blueprint for each compartment). Limiting the size of these compartments/sections means that damage could be spread across the compartment and applied to blocks and devices in that section. Overall, you ship would have many bulkheads but probably still less to worry about than individual blocks. ...though I'd be happy with the current damage per block method but still have the named sections with a damage overview and nanagement
Sounds nice and if they can do it, would be nice but compounding blocks inside others is easily exploited in MP , and in SP it could become an issue if weights ever become a properly measured thing and also hitboxes for realistic damage I see problems there also, but yes it would make building pretty sweet to fill some of those gaps we all snicker over !
In the future of Empyrion when Crew and Interstellar travel are introduced, i think many ppl. will want to create bigger structures than now to house said crew and maybe bigger machinery (for FTL travel) and other things. I think that merging blocks (in one way ot the other) will become a topic then.
In my humble opinion; this is too much of a radical shift from what the game started off as. The only idea that would possibly make any sense in implementing might (and I use the word might lightly) fit into the game is the second idea. I do understand the need to enhance performance of the game but I just think it's too much of a shift. Just my two cents.
What specific suggestion are you talking about ? Because there are quite a few flavors in this thread.
I admit I was going off the first post and the poll. I'm a little late to the conversation and I haven't read all of the replies. Either way, changing the whole fundamental structure of the game in this fashion would be too much of a shift from what the game started off as I think. (and, quite frankly, such a radical change would probably be game killing in the sense that it would upset a large segment of the fan base who has bought into this game and supported it in early access) Right now, what we have here is a game that uses individual blocks, pieced together like Lego's, to build new items. Changing that game structure to something other than that would be a totally radical shift away from what the game started off as. Even if you still use blocks to build component structures to piece together to form a larger structure or something else... your still changing it radically. As I said before, I get the performance concerns... but this is too radical in my opinion. It would be game killing.
I get what you mention here, 3 times even more... But the idea is not to merge all blocks into one monolithic piece, but find ways to reduce calculations. For corners or diagonals, a space filling 4 x 4 x 4 m (2 block by 2 blocks) can contain as much as 18 "shapes", while the same size in horizontal or vertical only requires 4 or 8, as an example. Merging such a small section already cuts the triangle count in two, and it is still much smaller than many devices. Add weight to this and it also doesn't make much sense to have two similar volumes with 4x the mass just because using slopes / inverted slopes & corners.
Wouldn't that increase the amount of processed data even more? I'm not so sure about that since the game is still in Alpha state. I know ppl. are used to handle things in a certain way, as soon as a game gets successful (like minecraft). But to me it would make much more sense to handle things a bit differently than now. Regarding to damage being displayed on a merged structure, what about having some sort of burn marks made by decals (or however this is called nowadays), like this: There could even be weapon impact effects of much higher quality than just have some small blocks explode: Or various continous damage effects: To me, individual block destruction would be a minor thing to give up, if the game would allow much bigger and more complex ships, impressive destruction effects and more detail in general (like using small blocks on a CV/BA for example).
Look guys I'm not trying to debate and you all bring up valid, well thought out points. I just wanted to jump in briefly to throw out that if this kind of change is considered then it also must be stated that it will be a radical shift away from what the game started off as. It's almost like you start to bake chocolate chip cookies and end up making chocolate cream pie. They're both chocolate flavored but it isn't exactly chocolate chip cookies like you advertised. It's just something to keep in mind moving forward folks.
