I started writing a post on this earlier this week, because it gets really annoying when you only have a few roster slots and you constantly have to go in and feed away 1- and 2- star heroes just to free up space to collect the rest of them from your training camp. I didn’t post, however, because I thought about the condition where folks let these feeders build up in their training camps over days, weeks, or longer so they can insta-max that shiny new toy when it finally drops. Does that create an issue where this massive collection of feeders is too large for the data structure used in the code to record a player’s roster?
As a former programmer (a long time ago), I’m thinking that the roster either has to be stored in some kind of fixed-length (and very large) array or something dynamically allocated like a linked list. In the former case, you’d theoretically have the possibility of overrunning the length of the array, our you’d have to dimension the array much larger than most people would need in order to (largely) prevent that possibility, thus wasting a ton of memory in defense against a worst-case scenario. In the latter case, you could have a situation where you literally allocate all the available memory on the user’s device by trying to dynamically allocate, even though that allocation is probably very short-lived (i.e. you are about to feed away most of the heroes that the memory was allocated to store).
Perhaps I’m making too much of this. If the data structure for storing a hero requires a negligible memory allocation, it might be possible to allocate enough memory (either up-front or dynamically) for several million heroes without taxing the user’s device, but without access to the code, it’s impossible to know for sure.
On the other hand, this may just be a QoL improvement that SGG has no interest in making because it plays upon the user’s annoyance to convince them to spend gems for more roster space. 