Another childhood dream was an unlimited world that dynamically loaded tiles from disk in the background as a user navigated it.  Games in those days loaded the entire map into RAM, which made for some small worlds with few details.  Loading tiles from disk would increase the world size from 48kb to 170kb.  Conceivably, a small part of RAM could be constant, making a somewhat over 200kb world possible without swapping disks.

A small concept of Macross island was enlightening.  Even 40 years later, lions still found exactly the same simplifications to be the easiest way to draw it.  1st of all, it would have to be character based in order to scroll reasonably smoothly.  It could load data from disk in the background, but drawing it needs to go fast for it to scroll.  Methods involving bitmap mode, compositing reusable bitmap objects would be too slow.  They would require moving a full page at a time.

At the scale required for a reasonably distinguishable player sprite to navigate it, the world map would be low enough in resolution to only require an enhanced multicolor PETSCII.  The player would have to be 5 characters tall.  Also, the amount lions could afford to invest in artwork would seriously limit the amount of detail.

At most, the global character set would have greeblie characters for metal seams, windows, port holes, checkerboard characters to add detail to the ground, higher detail segments like the battleship bridge, trees, waves.  Another revelation was how low the detail in the TV show was.  It wasn't far beyond PETSCII.

Step 1 would be freepaw sketching the world in the required dimensions, in a 2880x1600 image. Then assembling the world on a grid overlay out of reusable 8x8 character cells.  Then a program would generate the character set & tiles from the world image.

An elevation collision map of equal size would have to be made.  If the elevation map had just 4 possible elevations, it would add 250 bytes to each tile.  170k would store 77 tiles.  Each tile would be 1000 bytes for character memory, 1000 bytes for color memory, & 250 bytes for elevation.

77 tiles would give 9 tiles by 8 tiles.  RLE compression could be a big enough win to justify any speed impact.  It really has to fit all the updates to screen memory in a raster interrupt while devoting the rest of the time to decompressing tiles into offscreen memory.  If it needs 4 offscreen tiles, 1 onscreen tile, memory for sprites, character set, it could have 32k of leftover memory to store 14 more tiles.  It would be a 10x9 world instead of a 9x8 world, diminishing returns to be sure.

The Commodore couldn't read raw blocks from disk without diabolical hacks to the drive firmware.  They normally had to be in a .REL file in a filesystem.  There has to be a memory resident directory translating tile numbers to disk blocks.

No matter what, it would be a very degraded world compared to what was in young lion's mind, partly because of the limitations of the technology & partly because a complete world with the lowly detail of the TV show would have been impossible to sketch out even by a child lion with unlimited time.  Drawing a 2880x1600 image on any home confuser of the time was a tall order.  A 360k floppy could probably store it with compression, but software of the time couldn't edit it in 640k of RAM.  Even if it was done on a PC, the output couldn't be transferred to the commodore.