Another dream besides mastering the bitmapped graphics model was creating a caching tile system.  To laylion eyes, games to this day load the entire world map in RAM.  Can't remember 8 bit guy ever mentioning tile caching.  They might separate levels into different files, but the entire map for a level has to fit in RAM. 

Young lion dreamed about dynamically loading tiles from disk as needed, to create an unlimited map size.  Seem to remember 1 trick with the commodore was it could load from disk without interrupting a program.  It might have been restricted to the native slow loader.  The disk size was 170kb.  RAM was lucky to hold 48k of map data.

It would be a simple demo where a player could joystick around a 2D map.  The algorithms of caching & prefetching were far beyond young lion. The general idea is to keep all tiles within a certain distance of the player position in RAM.  Keep other tiles around based on age.  The radius would extend beyond the screen borders.  That way the player can hit the screen edge usually without waiting.

Goog maps was the 1st widespread use of cached tiles, but to this day it has a relatively easy job of only loading what's currently visible & making the user wait. 

Like most games it would use character set mode.  Another problem afflicting young lion was creating the most optimum character set for the tiles.  The PETSCII set was the most versatile but looked the worst.  Make it too specialized & the world size becomes limited by the character set.  Bitmap mode was seen as too slow & limited to just wireframes.  Even after all the modern optimizations, glxgears was damn slow on a C64.  Forget about a fully shaded polygon world.

There might be general purpose characters for edges of objects & specialized characters for textures of an object.  Landscape characters could be more general purpose than structures.

Young lion's original idea just involved an aircraft carrier, buildings, water, & maybe a forest.  The aircraft carrier was a big investment for something which only appeared once.  Another idea might have been to dynamically load character sets based on position.  That would have slowed down gameplay & been a nasty algorithm.

The most optimum system might have defined a map of tile ID's in 1 part of the disk, & the bitmap data for each tile ID in another part of the disk.  The bitmap data would be a 8x8, 16x16, or 32x32 bitmap assigned to each tile.  The program would dynamically fill regions of character memory with the tile bitmaps, using the same caching rule as the map, but it might have to also flush essential tiles by age.  There would be times when a visible tile was resident but its bitmap wasn't so it would have to go to disk to draw that tile. 

The sector size was 254 bytes, so the tiles would have to be loaded in groups.  The caching would have to be done by groups of tiles.  Bitmap caching would be similarly coarse.

There was also the need for collision boundaries, maybe defined by a bit in the map data.  Collisions would need some kind of direction rules so the player could cross bridges from only 2 points & skip regions to cross under bridges.  A flying game would need a Z value for each tile.  Finally, the tile loads have to be sorted to optimize the seeking.  It's a pretty complicated problem to this day.