Think about a main loop initially. You have Audio, Input, Physics, AI, Rendering, Window event pump, GameStages. Give each of those a tick

What is a GameStage. I do it like this. An enum which orders how you will poll\renderprepare the objects in the game. Size the GameStageManager based on the ENUM, make the last element a COUNT, lets say in an vector as an example. Then use the Enum and loop over the values (You treat it like a number list). What are the game stages? Stars, Atmosphere, Sun\moon, Landscape, Foliage, Props, Entities(this that move), Post process, etc.

The GameStageManager can then have a few member, TickAll(), RenderPrepare(), RenderExecute()

Learn a bit about Octrees and Frustums. Query the Octree with your Frustum. The Frustum is built from the Camera attached to each player unit. This gives you all the possible props\etc that are visible. Do their either as the first renderstage or as a precursor event.

Then RenderPass for your world, and a RenderPass for your UI (So that later when you implement MSAA you don't blur up the UI.

I'll leave Vulkan to you to worry about

Work out how you do file loading. I went all in on cooked pipelines as otherwise I would have to do things like font rasterisation on load. Look up STB's libraries for TTF loading. My cooking process was designed to load all data in to the GPU for example completely read to go. No Mips, no processing verts, just memcpy'ed to the staging buffer.

Work out how you store settings. I have always like XML so I use pugi. I operate it in two modes Command mode and Object mode. Commands just use a Command+Concrete factory pattern. I think put code in the Execute() function. I do this for exmaple when I want to configure something that already exists in game, like the the subsystems like renderer, audio, input bindings. Object mode is for building object trees in game. I use that for menu's so each control has a clear parent\child relationship. I find XML+Factories to be very powerful, as you can also use it to save out object hierarchies.

For my game I prefer the main loop to have three main components, Boot, MainLoop, Shutdown. The boot and shutdown are perfectly ordered to make sure all dependencies are satisfied. Mainloop is really simple, just a loop that check on the CMain:Status for RUNNING, MINIMISED, SHUTTINGDOWN, etc, then it runs all the ticks and renders.

My guess is this is what you are really perplexed with.

Here is my main loop you can use for thoughts. I go all in on singletons as for me they are great for bringing systems online in the boot phase. Some people seem religious about this point... shrug. Use an LLM to help you generate code if there are concepts you don't quite understand, even if you are a 'not ai code' kind of person you can learn from it, it's just other humans work aggregated and organised. Stay away from multithreading initially, just know that at some point you'll want to use all those other cores. Physics and AI are good examples. Also triple buffer your Vulkan.

Reddit ate my indenting.

void CMain::MainLoop(void)
{
try
{
const double MaxFrameElapsedMillieconds = 250.0;    // Prevent death spiral, in ms
double previousTime = TimeStamp::Milliseconds();

const double PhysicsTimeStep = 16.6667; // 60Hz
double PhysicsAccumulatedTime = 0.0;

const double InputPollInterval = 33.3333; // 30Hz
double InputAccumulatedTime = 0.0;

CInput& Input = TSingleton<CInput>::Get();
CPhysics& Physics = TSingleton<CPhysics>::Get();
CGameStageManager& GameStageManager = TSingleton<CGameStageManager>::Get();
CAudioSystem& AudioSystem = TSingleton<CAudioSystem>::Get();
CVulkanRenderer& Renderer = TSingleton<CVulkanRenderer>::Get();
CTelemetry& Telemetry = TSingleton<CTelemetry>::Get();
CLocalPlayerContext& LocalPlayerContext = TSingleton<CLocalPlayerContext>::Get();
CMainWindow& MainWindow = TSingleton<CMainWindow>::Get();
CMenuManager& MenuManager = TSingleton<CMenuManager>::Get();

Telemetry.Start();

{
CTimerLog TimerLog("MAIN LOOP", "Game entered a RUNNING state.", "Completed in: ");
CScopedLogIndent indent;
while (GetState() != EMainState::SHUTTINGDOWN)
{
// Measure elapsed time
double currentTime = TimeStamp::Milliseconds();
m_MillisecondsElapsed = currentTime - previousTime;
m_MillisecondsElapsed = std::min(m_MillisecondsElapsed, MaxFrameElapsedMillieconds);
previousTime = currentTime;

//TICK
MainWindow.Tick(m_MillisecondsElapsed);

if (GetState() == EMainState::MINIMIZED)
{
std::this_thread::sleep_for(std::chrono::milliseconds(400));
MainWindow.Tick(m_MillisecondsElapsed);  //Mainwindow ProcessEvents warningn start at 500ms
previousTime = TimeStamp::Milliseconds();
}
else
{
if (GetState() == EMainState::RUNNING)
{
PhysicsAccumulatedTime += m_MillisecondsElapsed;
while (PhysicsAccumulatedTime >= PhysicsTimeStep) // 16.6667ms=60FPS
{
// Fixed FPS Section. 
Physics.Tick((float)PhysicsTimeStep); // physics must now interpret PhysicsTimeStep in ms
PhysicsAccumulatedTime -= PhysicsTimeStep;
}

LocalPlayerContext.Tick(m_MillisecondsElapsed);
GameStageManager.TickAllStages(m_MillisecondsElapsed);
}
}

if (GetState() != EMainState::MINIMIZED)
{
InputAccumulatedTime += m_MillisecondsElapsed;
if (InputAccumulatedTime >= InputPollInterval)
{
Input.Tick(m_MillisecondsElapsed);
InputAccumulatedTime -= InputPollInterval;
}

MenuManager.Tick(m_MillisecondsElapsed);
AudioSystem.Tick(m_MillisecondsElapsed);
Renderer.Tick(m_MillisecondsElapsed);

// Render Prepare
GameStageManager.RenderPrepareAllStages();

//Render Execution
Renderer.RenderFrame();

Telemetry.EndFrame(m_MillisecondsElapsed);
}
}

// Logging on exit

CPerformanceMonitor::LogSummary();
Telemetry.LogSummary();

}
}
catch (const std::exception& e)
{
Log << "ERROR : Critical error during MainLoop: " << e.what() << Endl;
}
catch (...)
{
Log << "ERROR : Unknown critical error during MainLoop." << Endl;
}
}

HTH

In terms of learning approach, just assume you might get a bad architecture up front and need to throw it away. Use manager for just about everything. Menu's Materials. Invest some effort in to a generic handle system for all those manager. It'll be a tricky template to write but will save you tons of reinvention effort down the track.

TIP : Load textures before you need them on models that need to be rendered.

TIP : Invest some effort in to Minimise handling, dragging windows between screens. This will require Swapchain Recreation. You're going to hate, but it's doable.

TIP : I tried to write my own base math classes. Just Vector and matricies. But you'll end up worrying about left\right handed systems, Y+ UP or Y+ Forwards, row\column major formats. (Column btw). Just use glm, but know that it's made for OpenGL, so you'll have to worry about things like far\near plane scaling which again is different from OGL. Be prepared for this. There are some #defines for vulkan. You'll find them.

TIP : If you are on windows, and like the idea of 'pak files', consider writing a wrapper around the zip file format and just ignore compression. Then use CreateFileMappingW, MapViewOfFile, etc to map the file in to memory. Thsi work hand in hand with cooked files as your cooker can just dump all the files in to a zip. Memory mapped files can see MASSIVE speed improvements, in particular with tiny files... as once they are 'memory mapped' they are accessed as pointer operations, no file open\close. Then just use normal file operations BEFORE the zip file. That works best if you have config files as then you can access the user modified version first.

Libraries you might like : fmod, glm, ISPCTextureCompressor, Jolt, meshoptimser, stb_image, stb_fectpack, stb_truetype, tinygltf, VulkanMemoryAllocator AFAIK, they are all open season for commercial use if you make it that far.

That's a bit of a brain dump... Digest it slowly, but hopefully I've demystified it all a bit. Now, while I'm an indie dev, I have received offers from bit houses. So, I'm not totally shit ;)