Mostly UI, only other GameScene, or a mixture of both for my tycoon game

So I'm trying to make a 2D tycoon like game (like Adventure Capitalist). I was wondering if to make the main game, should I use:

Almost all UI
Like barely UI
A mixture

I was going to do mostly the other Game Scene, but then I realized that I needed modifiable number, so I thought I must use UI. However, it's hard to make the buttons/other AND the scene work together. Should I just UI instead?

 

That game looks like it could be almost entirely UI.

You should be aware of some of the performance pitfalls of UI, which shouldn't be hard to work around. See here (@ 23:40):

 

So I watched the video, and I saw that keeping my non-changeable image and (always changing) current money would be a bad idea. Should I have one canvas with 2 or more child canvases, with one as the images, one as the current money you have, and so on? I might use a parent canvas because I want most things to scroll together.

 

Yes, that's that right approach. I'd probably do 2 canvases: one for rapidly changing stuff and another for static stuff. More than 2 canvases may be appropriate if you have different clusters of objects that update together, so you'd split them into canvases by what is most likely to update at the same time.

2 is probably the right way to start, however, and if you think you can improve more then split.

 

Upon furthur consideration, would it be good preformance wise if I make EACH "money-generator" inside a child canvas? I was considering this but with empty game objects because there were variables I wanted to work together (and I don't want to make them static because of performance problems.)

Maybe I make each "money-generator" a child canvas with a script attached to manage the "money generator", or should I make a empty game object to manage it instead?

 

Maybe. It's hard to say. The minutiae needs to be examined with the Profiler.

If it updates at the same time, then they could share the same canvas.
If they update at different times, then perhaps they should be separated.
An additional reason to separate is to make sure things sort correctly.

Canvases iirc break batches so you might also consider how fewer vs. many canvases affect the batch #.

Ideally, you would have the fewest # of canvases where each canvas has to rebuild at the same time. But that should be weighed against simplicity, against visual pizazz. That's why it might be good to go for a simpler solution first then once you understand all the features you need reordering and breaking things apart. But if you feel it's simpler to give ea. thing its own canvas from the start then later merge if you can, do that.