What is the ideal project structure here (Persistent Level & Sub Levels vs Independent Levels)?

Development Programming & Scripting
, ,
1

IMG_2118.PNG
IMG_2118.PNG1313×1009 119 KB

I am trying to make a game which the structure looks like the picture above (simplified for clarity).
It is all shooting game, but has 3 game type, A/B/C, and weapons/rules/enemy are unique to those game type. Each game type has 3-5 stages each, following the rule defined by the game type but has slightly different settings, like number of enemies, allowed miss shot etc. The stage itself is common across all game type, so there are no huge environmental changes.

I am wondering how people usually implement game like this. Should I create 3 persistent level for each game type and create sublevels for the stages, or should I just make 1 persistent level encapsulating all game type, all stages? In my understanding, if I create new level for each game type, I need to reload the save data every time I load different level, right? Is this common thing to do in UE game development?

I’ve never created a game consisting of multi play mode with multiple stages, and I have no idea how to approach them. Sorry if the question doesn’t make sense; I would do my best to clarify my thoughts if you need them to answer my questions. I would highly appreciate your help…!

1 Like
2

Everything here is widgets, apart from this

image
image1140×884 121 KB

Widgets can load on top of anything, so you have a special widget level, or you can load them over what has just played etc.

From what you’re saying, in the actual gameplay area, you have 9 levels. From your description thus far, these can totally be separate levels, opened simply with ‘open level’. It’s only when you have more subtle requirements, you might start looking at World Partition, or streaming, or level instances.

As far as using a save game goes, you will need that :slight_smile: Unless you expect someone to play through this whole thing in one go, they will need the ability to save and load things, even if automatically. It’s a very common feature of game dev, regardless of the engine.

1 Like
3

I think you going really ahead with project planning, imo. too far.

first make simple blocked out level. Then make player movement, single AI enemy, and some fighting system (like single attack and dodge) any fighting system that lets you judge needed space will do.

next fight few times run/sprint around etc. Decide if game needs climbing, or maybe whole parkour.

Now when you have idea of how big levels should be you can make first prototype level. And do only small (not pretty) rough level for developing CODE first. Do not bother with making levels first, because any change in gameplay may make whole level obsolete and unfit for what you need.

Simplest example: you made 20km x 20km landscape level, imported heightmap from app like GAEA, made nice landscape material, it looks great. However level is so huge your player character needs 30min walking to climb mountain. And for game you want mountains, grass hills and ocean beach. In real life that is 2-3 weeks of walking (unless iceland where it is 8 hours or so).

So again: decide how levels look and how big they are based on movement and fighting.

My usual order for game development:

  • player character with player movement,
  • camera type and behavior
  • simple ai eneny (using same movement code as player) with state tree AI
  • designing communication system. Player with hud widgets, input actions, player with actors in levels etc.
  • designing materials and material functions, naming all material parameters
  • finally SIMPLE and SMALL level for testing only, does not need to be preety

and last (for when i feel le dumb and cannot code) i am making preety level to find feel lighting and artstyle for my game.

And for your problem: make all systems frist, like communication, if you use class inheritance or coustom components, maybe GAS, gameplay tags retc.

When you make all base sytem components, and have prototype levels for all gaame modes, prototype widgets for managing load out etc.

So when you have all base systems, and everything works together. Selecting how top level logic flow goes can be changed in 10min of swapping some variables.

For first time designing code for some project “Bottom > UP” way is only solution imo.

2 Likes