I’m currently attempting to create a main menu which has three screens: the loading screen (a percentage counter comprised of assets in my preload queue), an intro screen (a quick display of the group’s logo and the game name) and finally the main menu itself.
I’m not particularly pleased with the current workflow of the menu screen, since it’s a format I’ve been applying since who knows when. I’m not sure whether or not this is fine, or if there’s a better approach I can take towards it. I also had to scrap some functionality in regards to it.
Currently, all of this work is being done in a LocalScript directly descending the LayerCollector for the main menu. I have thought about splitting it into modules, but there’s no reason why I should.
-- Services -- Constants do -- Looped tween for a single object, since doing it for 4 produced uncomfort do -- Place items in an asset queue -- Call PreloadAsync per child in an isolated table and update percentage end -- Hide TextLabel descendants of preload screen, wait(1) after (ew) -- Custom method TweenAsync to tween both group logo and game name -- Has a wait statement (fine for this case, since I need thread to sleep) -- Hide intro screen, show main menu end
Everything after the above code becomes an event-driven process that requires user input to proceed. It doesn’t matter whether it ends up above or below the above code because it’s event driven. The main concern I have is this sort of forward-coding.
Is this fine, or is there a better way to accomplish this? Setting up the main menu overall is no sweat. Determining how a Gui should initialise from screen to screen without any input or events has me biting my nails.