Knowing what a unit is standing on

Say you are building a Pokémon map. Walking into tall grass has to start an encounter, and the grass is scattered all over the map. Done with locations you run out of the 255 almost immediately. But where the grass is, is already written in the map file - you are the one who laid it.

A map's terrain lives in a chunk called MTXM, two bytes per tile. Read the whole thing at compile time into a small table of labels - this square is grass, that one is water - and at run time the check is the unit's position divided by 32 and one array read. No loop, no location.

# 컴파일할 때 (eudplib 쪽) / at compile time, in the eudplib half
MTXM = bytearray(GetChkTokenized().getsection("MTXM"))
for y in range(h):
    for x in range(w):
        i = w*y + x
        v = MTXM[2*i] | (MTXM[2*i+1] << 8)
        tileClass[i] = classify(v >> 4)      # v >> 4 가 그룹 번호 / the group

// 게임 중에 / at run time
const x, y = posread_epd(epd + 0x28/4);
const kind = tileClass[(y/32)*mapW + (x/32)];
if (kind == 1) { /* 풀숙 / in the grass */ }

You read the tile number straight out of ScmDraft: click the tile in the terrain palette and a number like (1231.00) appears at the top. The first part is the group, the second its index inside that group, and the value the map stores is group×16 + index. Going the other way, divide the stored value by 16 to get the group back.

The 32 is there because one megatile is 32 by 32 pixels. Unit coordinates are in pixels and tile indices are in squares, so the number between the two is always 32.

Work out the size of the array first. A 256x256 map has 65,536 squares, and an EUDVArray spends one trigger - 72 bytes - on each, which is about 4.7 MB. It may compile, but nobody will download it. Store a small class number rather than the tile id, use a 4-byte EUDArray, pack several squares into one entry, or build the table only for the region the mechanic actually uses.

Creep cannot be found this way, and in Remastered cannot be found at all. Creep spreads after the game starts, so it is not in the terrain you read at compile time. If the design was "units move faster on creep, like StarCraft II", that design has to go.

A surprising amount falls out of this one check: terrain that reacts when stepped on, an ability usable only on a particular ground, a cliff you can walk down, a mount that crosses water. All of it reduces to "what is the square under me", and none of it spends a location.