Справа в тому, що при маленькій зміні числа, яке означає колір, колір може змінитись досить сильно — порівняйте кольори в прикладі вище. Алгоритм може знати, що це різні кольори, і тому в цьому місці кодування буде неоптимальним.

Така оптимізація може й допомогти, на більш-менш рівнинній карті. За умови, що є підходяща структура даних: не масив, а словник, у якого по одному ключу є доступ до багатьох елементів, з типовою операцією вибору ключа за значенням. М’яко кажучи, нетривіальна штука.

я тут порахував, при карті 2000х2000 (а в мене вона 400х400), я буду мати 40000 клітинок. Так, як по цих клітинках будуть ходити моби, то я зроблю, аби вони ходили саме по клітинках. Тобто щоб не можна було б перейти з клітинки 1 в 1.5, а тільки в 2, ну тобто в ціле значення, а якщо не можна - то не йдемо. От, і дивіться, якщо висоти будуть дуже різними, то мені всі їх треба позначити числом, якщо використати ushort, то ми отримуємо десь ~65 тысяч висот. Мені здається, що цього предостатньо. І тоді ми будемо мати 40000*2 байти інформації, котру треба буде постійно тримати в оперативній пам'яті. А це всього навсього 80кб, тобто це дуже мало, тому до дупи всю ту компресію.

2000*2000=4000000 (4 мільйони).
400*400=160000 (160 тисяч).

ну я прост рахую такий - угу, 2000 на 2 - 4000, одже 2000 на 2000 це в 10 раз більше 

Наче схоже? угу?

ну не знаю, якщо потрібні відтінки сірого, то я би брав тільки типу aaaaaa - тобто тільки 256 варіантів. На крайняк можна допустити девіацію на 1 в одному з кольорів, тоді кількість варіантів буде 7*255=1785. - цього достатньо?

Я вже писав: PNG використовує для стиснення алгоритм DEFLATE, доступні реалізації якого є практично на всіх мовах програмування. Нащо втягати додаткові сутності (картинки), якщо результат буде такий самий?