Gameboy Development Forum

This is certainly something you can do, in principle. The tile memory is RAM that your program can edit. But there are a couple of issues.

One issue is processing and memory bandwidth. You can only write to VRAM during the vertical and horiztonal blanking periods, VBlank and HBlank, which limits how much data you can update in a single frame.

You also need to put the draw the sprites onto the tile data, which requires things like shifting the data in a byte so it ends up on the right pixels. The hardware can't do this for you and place it in the right place. The GB is using tile based graphics. There's no framebuffer mode.

Another issue is with color palettes if you're targetting the GBC. A tile can only be assigned a single 4 color palette. If you have 2, 3 or even 4 balls intersecting the same tile you might run out of color palettes to color all the balls correctly. This is not an issue with sprites, since each sprite has its own palette.

Also, I wonder about the idea conceptually. You might have a situation where all balls are moving simultaneously, (particularly during the break) so you may not gain much by doing it as you describe. I'd probably rather try to draw the balls as sprites as much as possible, and fill in the rest of the balls using background as necessary. Why would do I saw as necessary? There's a limit of 10 sprites per scanline. Any more than that, and additional low priority sprites are not drawn by the hardware. In some situations you may therefore need to put things in BG. But since this will be done rarely, you can pretty easily space out any balls that need this fix so they don't overlap and thus don't have the GBC palette issue described above.

There are a couple pool games for the GB, you could load one of those up into a debugger like BGB and look in the VRAM what they're doing for inspiration.

So, everything is a tradeoff that depends on the exact thing you want to make. When you said pool, I assumed a classic 15 ball snooker game. This is a bit different, so the design requirements are different. Would it always have just 2 balls, or do you imagine 3 or more balls as well?

There are to main sprite limitations you need to be aware of.
1) The 10 obj per line limit. (I see from your latest bsky post that you aware of this limitation.)
2) The 3 color per obj limit, which comes from one color being reserved for the transparent color. I at least suspect you already aware of this limitation as well based on how the mockup is designed, in that the "ball" version of the characters only use 3 colors each.

You need to take 1) into account when deciding how many and how big sprites you want to use. You can get around 2) by layering objs within the same sprite, but at the expense of using more objs per line which means you could exceed the budget.

Again though, I feel like you've already discovered these things and are already designing within the parameters, so I don't think I need to say much. The ball (sprite) versions of the characters are limited to 24 pixels wide (3 objs) each which means you have a budget of 10-6=4 objs wide to make the collision animation, which seems to be exactly what you're doing. From your mockup, drawing the static versions of the sprites in BG makes sense.

One subtle aspect of doing it this way is that you can easily draw message boxes on top of everything just by modifying the map. If you were using sprites, you would need to figure out a way to clip the sprites so they end up "below" the message box.

I think you've got this conceptually already, but feel free to ask if you have any other questions.