Always seen as the hardest step is tile loading.  5 algorithms are required for just the 4 cartesian scrolling directions & a full page refresh.  Diagonal scrolling would probably not fit.

The mane trick with debugging tile rendering was making test pattern worlds.

Much diabolical assembly yielded the 1st B&W screen draws, properly spanning 4 tiles.  The tile cache & all the gaps required to align the VIC buffers left 18991 contiguous bytes for the program & just the B&W drawing engine took 6012 bytes.  There are actually 2168 & 504 byte gaps between the VIC buffers.  Some subroutines & tables could be loaded there.  Those would probably be direct sector reads with the fastloader.  It's proven more efficient to use the disk as raw storage instead of bothering with a filesystem.

Helas, a  bug in makeworld artificially reduced the character set.  The real world needed more  like 105 characters instead of 55.

SDF-1 started materializing.  Tempting to go with B&W.  Decompressing color is a big job, but color is what young lion envisioned.  The big challenges are reusing characters by remapping colors & unpacking colors.  Color encoding was solved failure case by failure case.

The SDF-1 was finally revealed. 

Sadly, because the I/O is dictating an extremely slow scrolling speed & the screen drawing is going pretty fast, it might make sense to do full screen redraws for all the scrolling instead of the border routines.  The big question is where to do asynchronous disk I/O if it's always accessing the tile memory instead of copying the bitmap memory.  It would need to happen between screen redraws.

For the test world, the $d800 color RAM only ended up used in 1 cell for the entire world & it would require a small tweek to work around.  Updating the color RAM is going to be extremely slow & burn 4500 bytes for data that's never going to be seen.  The color RAM itself only has 4 bits per byte implemented so it's of limited use in another role.  If the world had photo quality graphics or dithering, the color RAM could be used.  This would use up the character set fast & slow the IO way down.  These factors make the color RAM unlikely to ever be used. 

If the world had only 2 unique colors + black in each cell, it would still be ahead of character mode. Character mode only allowed 1 unique color in each cell with 3 other global colors.  Greeblies are 1 area where color RAM could be important.  Without greeblies, the way it is now, it's in the territory of vector line art.  A vector line art world would need vastly less IO & probably scroll a lot faster.  Instead of a tile cache, the screen or the borders would be rendered from scratch.  The entire world could fit in RAM.  It wouldn't be as unlimited as a disk world, but the largest world young lion envisioned would fit in RAM.

There's still a desire to use elements which couldn't be drawn with line art, like trees.  Those could still be character based objects drawn on top of the line art.  The line art engine would just draw lines, filled triangles, & filled rectangles.  That could possibly end up slower than character tiles.

A quick demo with keyboard navigation had a lot of glitches but revealed what young lion's scrolling tile world would have really looked like.  The initial reaction was it would be pretty hard to navigate through such a small pinhole.  It would need a map inset or a lot more detail.  It was no more than a static image a player couldn't interact with & with no moving objects.  At least bungeling bay had an interactive, animated world.

It was much  the same situation young lion ended up in, day after day.  He would arrive at a gist of a game engine that wasn't heading towards anything useful & the initial impression ended any motivation to continue with it.