This is maybe over-broad for the stack: can anyone point me to some good resources for programming tile based physics systems from scratch - that include slopes? I'm finding that doing collision responses in particular is tricky with large characters that may collide with many tiles.

Searching for guides on how to implement physics as in classic Sonic games might be a good starting point.

You might want to consider a signed distance field data structure to help accelerate searches for potentially-overlapping tiles (this is done in the PixelJunk games if I recall correctly) if your character footprint is more thana handful of tiles wide.

gamedev.stackexchange.com/questions/212364/… this question got me thinking in terms of memory usage. How good/ bad is it to have a 5000x3000 source image, limit it to 2028 on import and scale it down in the scene to a maybe 200x150. From the looks of it they are going to display multiple such images (though not the same) at the same time - I would guess they will be similar high scale in the original.

Auto-scaling by powers of 2 usually looks decent, but scaling in between can look blurry or uneven. Some of the ugliness they're seeing could be coming from the double-whammy of first non-POT scaling 5000 down to 2048, then non-POT scaling again to ~200, so the distortion accumulates.

Box scaling is fast to compute but not very high-quality compared to the filtering modes used in image viewing apps that just display one image at a time and don't need to animate gameplay at 60+fps. If they're scaling over a large range, they may want to manually create their own mips to control the look at each scale (they can even simplify details at smaller sizes, vary line weights so they don't get too fine, etc)

This past Q&A might be useful to them - especially the point about not using "Normal Quality" compression for sprites - they'll almost always want to be uncompressed RGBA 32-bit, since compressed formats can mangle sprites:

I'll go share that link in the comments.