What should be the workflow of a main menu coupled with a loading screen?

Help and Feedback Scripting Support
,
#1

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.

1 Like
#2

You can have checks to see if everything is going smoothly, whatever those checks may be. But I don’t see what’s ultimately wrong with implementing functions and placing the code within the function. This way, you get to control how the code works, and when the code will run.

Like have each of the three things in a function, and once one of the things is finished, call the next function.

local function lastThing()

  --end

end

local function secondThing()
  --do

  lastThing()

end

local function start()

  --do

  secondThing()

end

This type of logic works in a ModuleScript, so there’s a reason to use one.

#3

Throwaway functions aren’t really the key to solving my problem. The least that does is isolate my code into separate scopes which I can call later. It doesn’t differ from my current paradigm, which also opens scopes and throws them out once they’re finished execution. The code is only intended to execute once - the workflow is posted in OP.

Running


local function Last()
  -- Code
end

local function Second()
    Last()

    -- Code
end

local function Initialise()
    Second()

    -- Code
end

does not differ functionally from

do
    -- First (or "Last")
end

do
    -- Second
end

do
    -- Last (or "Initialise")
end

or

do -- Main initialisation scope
    do -- First
        -- Code
    end

    do -- Second
        -- Code
    end

    do -- Third
        -- Code
    end
end

The only difference is organisation, which I am a massive stickler for and hence why I did not code it in that functional paradigm before asking the question. I’m unwilling to sacrifice organisation and the format that I’ve set out for a paradigm that runs the exact same way, because that would not solve my issue or satisfy my question as determined in OP.

What’s your basis though? There’s no point putting my code in ModuleScripts. Everything is very forward and straight here. I don’t need to use anything from the initialisation section more than one time and it’s rather pointless to start fretting about unnecessary organisation that doesn’t impact the effectiveness of my code.

The LocalScript is strictly used to control the LayerCollector. The code I’m concerned about at this given time is initialisation, which includes preloading the LayerCollector’s descendants, playing a quick introductory animation and then making the menu visible. Everything else is precoded and ready to be shipped into the main build.

#4

Hm. Looks like I’ll be splitting them into modules after all. I really hate that I can’t shake off this whole thing about organisation. I have fairly silly worries when it comes to how I program, which results in an overall tank in productivity. It doesn’t even matter right now though.

Essentially, each window is represented by a ModuleScript that handles its work. A module isn’t required until its run of the fun is ready to be enacted. It doesn’t really reap the benefits of ModuleScripts and I shouldn’t need to put so much effort into a one-time menu, but again, silly worries over productivity. Ugh.

-- Code

return true

I honestly assume that I’m going to change my style within a few minutes, but I’ll see what I can do. Above all, I need to stop worrying about code organisation. Lol. There wasn’t really anything wrong with the first thing I mentioned.

1 Like
#5

Try it out. If you are not comfortable with it, just revert to what you originally did. It’s generally fine either way.

1 Like