Ardumon Mockup Image

(Simon) #162

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

(Pharap) #163
000 = 8
001 = 9
010 = 10
011 = 11
100 = 12
101 = 13
110 = 14
111 = 15

Problem solved. :P

(Simon) #164

Yes, yes very good. Thank you.


00000000 -> 0
00000001 -> 15

That’s how this works right?

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

(Simon) #167

@Gaveno … he was joking.


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

2^n also works

(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 :wink:


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

(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 :slight_smile:


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.


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


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

(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?


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

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


@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

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


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.