Crystal wedges, no extra IDs needed

[Mr.Steam]

my cats breath smells like cat food

 

[Qweesdy]

There are more than four values of armor types right now.

The good thing about software is that it's "soft" (easily changed). If there are more than 4 values for armour (which I doubt - I thought there was only 0%, 33%, 66% and 100%) then it's easy to change it so there's only 4. More than that wouldn't make a noticeable difference to game-play.

Even so you would need a lookup table to have a balanced armor system with only a few bytes. Schema has clearly decided that having things run as fast as possible isn't for the best when it requires more RAM.

It doesn't use more RAM. 3 bytes is 3 bytes (even when 1 byte is in one place and the other 2 are in another place).

Multiplying the HP by a given value won't change that you can't store more information in those bits. If you have a values from 1-64, if you multiply by 8, you can only get multiples of 8. In other words, the HP is effectivly the same, since you can't have a value like 13.

Should we shift to full double precision floating point so that we can have HP values like 3.1?

Given that most of the time the damage is either too little to matter or so much it obliterates the block in one hit, are you sure anyone playing the game would notice if it changed to (e.g.) only 2 bits for HP? I'm not.

 

[ltmauve]

The good thing about software is that it's "soft" (easily changed). If there are more than 4 values for armour (which I doubt - I thought there was only 0%, 33%, 66% and 100%) then it's easy to change it so there's only 4. More than that wouldn't make a noticeable difference to game-play.

Except no, it would, especially if the armor system is switched to a (damage/armor), which means that armor is much more versatile in values. Locking the armor down to only 4 values which can't be balenced without a lookup table is certainly stupid in that sense.

Should we shift to full double precision floating point so that we can have HP values like 3.1?

Given that most of the time the damage is either too little to matter or so much it obliterates the block in one hit, are you sure anyone playing the game would notice if it changed to (e.g.) only 2 bits for HP? I'm not.

That's not what I'm saying. What I'm saying is that increasing the "HP" for each value of the HP bytes doesn't give you more flexibility. I'm saying do away with giving blocks different starting HPs and give them different armor values to get the same effect as you had before (different blocks require different amounts of damage to destroy)

 

[OvermindDL1]

Using the initial posts values of how the bit layout currently is
```
Blue is block ID bits: 11 bits, 2048 possible values.
Red is HP bits: 8 bits, 256 possible values.
Green is Activation bits: 1 bit, 2 possible values.
Yellow is orientation bits: 4 bits, 16 possible values.
```
Would it not make more sense to change the Block ID bits to instead of being a blunt 11 bits be something more like breaking the 11 bits up so that a few of them define the shape and the rest are for ID, perhaps something like:
```
If the first bit is not set then the block is a cube and the bit format of the remaining ten bits is:
Bit(s) - Usage
--------------
3 - This should equal the 'Shape' size below, and only if these X number of bits are all zero then the remaining bits of this ten (7 in this example) are the material types of the cube type for efficiency reasons, if any/all of these X number of bits are non-zero then the entire range of 10 bits if the ID for a specific non-material block type, like a Ship Core, or a Storage block.

If the first bit is set then the block is a non-cube, and the bit format of the remaining ten bits is:
Bit(s) - Usage
--------------
3 - Shape, things like slope, corner, anything that is non-cube... Make this as large as there are possible shapes, you could make this fairly large if you keep the material count down
7 - Material, this is what the block type is, like a blue crystal or whatever, this may be more less bits depending on how many shapes there are.
```

In essence the possible bit layouts of the 11 ID bits would become:
```
M = Bit used for Material
S = Bit used for Shape

0000MMMMMM
0XXXXXXXXX
1SSSMMMMMM
```

This format would allow for highly efficient lookup without needing to lookup block types for shapes in an array or so (Is it a cube, is the first bit a zero? Is it a wedge, are the first few bits 0110 or whatever?), it also allows for quick testing of material types as well. All in all this would be a highly efficient design that would allow for a lot of collision testing, material lookups, and more, without needing to do more memory fetches. And of course the shape and material bits may be a different size depending on how many shapes are actually planned. And if there are any special block planned that will be non-cubes then you could just reserve, say, 0111 as the starter bits for them as well.

If the byte count was ever increased for 4 bytes then I would highly recommend expanding the rotation states to 5 bits, that way you could represent all 24 possible axis-aligned rotations. I would really love to be able to specify my docking blocks to rotate the docked ship a different way that is not 'forward' on my ship... In addition the extra rotation would allow for a great shape variety, especially as you could expand those bits as well.

(P.S. Why does this forum not support any form of standard markup?)

 

[ltmauve]

The thing is that your solution doesn't actually give us extra IDs. In order to rearrange the bits in the stored data we would have to import the entire database, and your solution doesn't justify that. A better armor system (like the one I proposed) will result in the HP-bit value being more flexible in representing a larger range of HPs, so we need fewer bits in HP and can give them to orientation.

 

[OvermindDL1]

The thing is that your solution doesn't actually give us extra IDs. In order to rearrange the bits in the stored data we would have to import the entire database, and your solution doesn't justify that. A better armor system (like the one I proposed) will result in the HP-bit value being more flexible in representing a larger range of HPs, so we need fewer bits in HP and can give them to orientation.

Correct, I meant it as an efficiency improvement on top of any ID extension methods.

 

[ltmauve]

The point of this suggestion is that all the shapes would be condensed into a single block for each type. You wouldn't have seperate IDs for each shape anymore.

 

[OvermindDL1]

The point of this suggestion is that all the shapes would be condensed into a single block for each type. You wouldn't have seperate IDs for each shape anymore.

Ah yes, my mistake, site is oddly huge on mobile and I missed a bit...

Then yes, the rotation field should be a shape field instead, with the rotations just being other shapes to handle all cases without wasting data, though it would still be best to move it to be with the ID field as you could still encode a little overlap.

 

[HolyCookie]

Geez man.... you people can almost make your own block ID game or something
since when is scripting and that sort of stuff primairy knowledge?

 

[Megacrafter127]

Geez man.... you people can almost make your own block ID game or something
since when is scripting and that sort of stuff primairy knowledge?

Since nerds are in the community :P

 

[ltmauve]

Ah yes, my mistake, site is oddly huge on mobile and I missed a bit...

Then yes, the rotation field should be a shape field instead, with the rotations just being other shapes to handle all cases without wasting data, though it would still be best to move it to be with the ID field as you could still encode a little overlap.

I'm not sure how efficient having the shape/rotation bits sharing with the ID bits would be. I do know that some blocks (like the light-rods and plants) will not be able to have full orientations anyway, so there will have to be a bit of lookup for collision calculation anyway.

 

[NeonSturm]

Since nerds are in the community :p

Came up with 2 complementary ways of storing blocks in RAM

All ways have a 8 byte (= 4x4x4 bit) array for a 1-2 m block.

The header maps all global IDs to a few local available IDs, greatly reducing RAM-usage for sub-blocks.
Additional RAM is saved by storing HP for a larger entity. (1*2^n byte |vs| 1 byte + 1*n bit )

1. 2|3x 8 byte 3D-array for each ID[x]
   • Bit set = block there
   • requires 8 bytes for a matrix of set blocks [any ID], thus you need 8 byte additional.
   • Current and max HP are stored for all sub-blocks at once.
   • Wedges are generated automatically per 2x2x2 sub-blocks (maybe toggle-able in header or by ID infos)
   • Advantages:
     
     1. allows for more than one block at the same place
     2. many shapes, easier transitions (glass block<->hull wedge problem)
2. The whole macro-block is one block
   • Major advantage = highly configurable, more bits for logic, (injected lights|power|...), ....

I hope it will be possible to display(console) or render(textured) a block made of many overlapping overlays which apply only on some parts and to have both ways on the same object, switch-able by 1 bit in the super-block header.

Whatever we choose, I think damage values should NOT consume 1/3 of bits.

Nobody ever spends that close attention to the damage details and despite that the game is not just about fighting with TINY guns but also creativity and community.​

If the game would allow 7 different block-IDs in 2x2x2m with bit-maps for 0.5m blocks and use these for HP,

it would add the possibility of smooth block-block transitions within 1x1x1m and scalability of small (0.5m) parts.

At the expense of the many HP-bits, these sub-block bits must be HP-segment-counters.

Full blocks (computers, logic) could always be visible/present as long as one of 8 bits for the 1x1x1 cube is present.

As non-hull blocks have a lower HP value, you just need the lower resolution without the "sub-blocks being a HP-segment" feature.​

Ideally we could have 1m thick walls textured differently on it's two sides (use texture of adjacent position) and 2m thick walls with a 1m stair/ramp inside it.

 

[ltmauve]

Okay, we have 12 bits in HP and orientation. That's not changing. Though I am honestly not sure how using the shape as HP will work. If you blast one of the corners off from a tetra, you'd get a narrow wedge, meaning some material gets moved around
[DOUBLEPOST=1424207700,1424207594][/DOUBLEPOST]EDIT: You can get the single 45-at-45 block if I'm interpreting your idea. Let's look at that.

 

[ltmauve]

Um, so we could take 8 of the bits and use them to represent each corner. Is that what you were thinking? But what about the sprites?