If you could squeeze a number like 15 into 3 bits you would have solved all my memory problems.

# Ardumon Mockup Image

**Pharap**(Pharap) #163

```
000 = 8
001 = 9
010 = 10
011 = 11
100 = 12
101 = 13
110 = 14
111 = 15
```

Problem solved. `:P`

**Gaveno**(Gavin Atkin) #166

0000 (base 2) = 0 (base 10)

1111 (base 2) = 15 (base 10)

A quick way to turn a base 2 (binary) number into a base 10 (decimal) number, is to just put it into an online calculator like this one. If you want to know the maximum value that can fit into n number of bits (assuming a start value of 0), convert n 1âs into base 10.

**Freezingsnail**#168

Iâm very serious this discovery of how to fit 16 numbers In two bits will change computers forever.

2^n also works

**Gaveno**(Gavin Atkin) #169

Sarcasm is not inherently apparent through text. If I assume heâs joking, the picture becomes no more clear for those who may not understand binary values. Iâd rather go the route of clarification than add to the murkiness

**Mr.Blinky**#170

You can squeeze the level and monster into 6 bits if you combine/share two level bits with monster bits. In other words limit the number of different monsters per level to 4

**filmote**(Simon) #171

Yes you are right âŠ posts in social media and forums can often be read two ways. My smart-arse comments donât help either. Thank god for the emoji

**Freezingsnail**#172

By level I mean the exp level

Like lv99 caterpillar

Not like game floor level. If you ment character level I donât understand what you mean.

My idea still kind of works if each monster only has 1 move set determined by what level they are but thatâs kind of lame since part of the fun is being able to use 1 monster for different tasks.

**Mr.Blinky**#173

Ah right. I was thinking about game level

If you canât fit all the data in a single byte you could consider storing the remaing data in packed byte array. something like:

```
uint8_t extraData[] ={0,...,0}; //your packed data
value = (extraData[index >> 3] >> (index & 7)) & 1; //array of 1 bits
value = (extraData[index >> 2] >> ((index & 3) << 1)) & 3; //array of 2 bits
value = (extraData[index >> 1] >> ((index & 1) << 4)) & 15; //array of 4 bits
```

**Freezingsnail**#174

I think I was aproacing this the wrong way since I was considering compressing the players party as well.

Really this type of compression would be best for the npcs that are all preset.

Since theyâre all preset too I thought of an interesting way to pack this better.

So 4 bits for the 16 possibilities 3 bits for the level out of 8

1 bit to determine wich preset move set theyâll have.

The trick Iâm thinking is since each monster is preset you only need 8 numbers or 3 bits to represent 24 levels. Since if itâs monster 2 in a 3 tier trian lvl 0 equates to level 9 when the monster would evolve. Downside is this type of compression canât account for the level cap without maybe using some tomfoolery with the moveset bit if itâs the third tier monster

**drummyfish**(Miloslav ÄĂĆŸ) #175

Yep, unless you allow the user to cancel evolution like in PokĂ©mon, which you shouldnât because this type of compression is too good to give up and people donât cancel evolutions very often anyway.

For compression itâs really better to think in terms of how many *distinct numbers/values* youâre allowed to store, as opposed to *what values* you want to store. You can compress GTA V or World of Warcraft into 1 bit if they are the only games you allow to be compressed (0 = GTA V, 1 = WoW). So try to think about grouping things together to reduce the number of possible combination.

What do you mean by the *level cap*?

**Freezingsnail**#176

Normally thereâs a max level you can reach. I believe it was 32 in arduventure. With what I layed out you could only get levels 0-23 or 1-24. If the cap is 32 youâre missing 8 levels.

Iâm not really informed in this tbh, I have no idea what @Mr.Blinky is talking about with that array magic.

Also I donât inted this to be for the players monsters, only the preset npcâs

**drummyfish**(Miloslav ÄĂĆŸ) #177

I seeâŠ so you can actually have a bigger struct representing the monster, e.g. 2 bytesâŠ the players party monsters will have this stored directly, and the wild and NPC monsters can just be a 1 byte index into a preset table. The monsters can then be allowed even 100 levels.

EDIT: Or actually why not generate it completely procedurally? For each world area youâd have one function to generate wild monsters. Then each manually placed NPC could have some small hint parameter from which all their monsters would be generated. No need to have any monster presets anywhere.

**Freezingsnail**#178

@drummyfish I figure 32 levels would be enough since the scope of the game is severely reduced.

Another notion is end game. The battle towers normally have cups that auto level you to 100. An area like that wouldnât even need levels stored. And at the same time randomising teams would be even more applicable.

I donât think randomised NPCs fits the character of the game normally though since most areas are characterized. Like people with bugs in forests, water monsters in water routes etc. Boss fights ect also shouldnât be random but those are special cases

**drummyfish**(Miloslav ÄĂĆŸ) #179

I mean not *completely* random â what I meant was each NPC (or even a whole area) could have a small hint, e.g. 1 byte, that would say something like: generate 2 to 5 monsters of bug type leveled from 10 to 15. For some very specific NPCs you could specify the monsters exactly, but procedural generation would suit most cases.

If you take e.g. a forest with 5 NPCs, each with 3 monsters, each of which would take 1 byte, and consider replacing this all with one hint for the whole forest area, you get some 1/15 compression ratio.

EDIT:

Letâs see what the hint could look like:

- 3 bits for 8 level ranges:

e.g. 0 - 3, 4 - 7, 8 - 15, âŠ - 3 bits for monster types, assuming e.g. 4 types A, B, C, D:

e.g. A, B, C, D, ABC, ABD, ACD, BCD - 2 bits for number of monsters:

e.g. 1 - 2, 1 - 3, 4 - 6, 2 - 5 - 0 bits for moveset, that could be completely randomly chosen from the possible set of moves of that monster on that level.

Now since there would be only one hint per area, you could get away with giving it an extra byte to allow for more precise (possibly full) specification, or more hints. Some helper formulas:

- If you have
*N*numbers (e.g. 32 levels), you can represent all possible ranges with*(N * (N + 1)) / 2*values (Gauss formula). If you feed that to base 2 logarithm (and round that up), youâll get the number of bits you need for that, which for 32 levels is 10, with some fractions of bits unused. So with 10 bits you can represent an arbitrary range within 32 levels. - If you apply the same to the number of monsters, e.g. 6, you get 5 bits, again with some leftovers.
- To represent all subsets of a set of size
*S*(e.g. all possible combinations of monster types) you need simply*S*bits (if you feed the number of elements of a power set to*log2*, you get*log2(2^S) = S*), so for 4 types youâll need 4 bits (each bit says whether the corresponding monster type should be considered for the random generation), but the value for an empty set will never be used because youâll always want at least one type to be there for the monsters to choose from. You can use that as a special value for something clever (it could possibly mean that the remaining bits of the hint are actually an index to the preset table or something, allowing for manual specification for special NPCs etc.).

So this together gives 19 bits, with some unused values, which you could push down to 16 bits of 2 bytes by throwing away some weird values (e.g. youâll probably never want to randomly generate monsters in the full level range of 0 - 31, so you can throw these wide ranges away). Would also be good to fiddle with the numbers to not get bit fractions that waste space.