From cradle to grave - game flow

So, I’m working on a game. Yup…figured it’d be easy. I’m more of a modeler than programmer, but blueprints make things so much easier…kind of.
See, I can make a button work a door, or a cool effect happen when you touch your player to a certain spot of the floor. Now that UMG is out there, I can even do a basic menu and timer. I can play 1 level in my game from the editor.
What’s hard is putting it all together from start to finish. For example, do I start with a blank level that only has the main menu, then opens a level to start the game play? What about that menu that shows which levels you’ve already played? (think FLOW or Angry Birds). How about storing best times for each level and letting the player know if they’ve bet it? Now on to the next level…load that blank main menu back up?
So my concern is how to create the entire game flow, from the first time it’s installed, to continued game play and end game.
Does anyone know of a tutorial that steps all the way through like that? I’m also curious how you game designers lay out the whole game flow. Do you draw out flow charts or just wing it?
Newb stuff here, I know. But I was just wondering how the cradle to grave process goes.

This can be different for every project I’m sure, but planning things out is always the best method! Even if things change planning is always key! There are reasons to have a design document. :slight_smile:

Like yourself I am a modeler as well and have found BPs to make it easy for me to build simple prototypes and work in gameplay much more readily than I could with UDK. This is the awesomeness and ease of use of BPs. There’s still a lot of programming concepts that carry over with it, especially when you get more involved with some setups, but it’s great for those starting out with game engines for the first time!

I’m not sure of any full on tutorials out there that go over an entire setup for a game from beginning to end with UE4, but some of things you want to do shouldn’t be that complicated to setup. You’ll need to setup multiple levels and menus though and it will require using BPs that cast information in order to track some things.

Let’s look at two of our example content provided on the marketplace that provides menus and start screens.

Tappy Chicken and ShooterGame

ShooterGame has a loading screen that is simply another map with a large plane mesh in it’s own map.

Tappy Chicken uses static meshes that when clicked by getting mouse position will perform different actions. There could be a main menu with Tappy Chicken if that was setup in a different map and then when clicking start it loads another level map. The same for if you had multiple levels like the Angry Birds setup where you see Level 1-12 and clicking each number button will just load a different map.

For tracking information there may be something in the BP section of the forums or in the tutorials section that may help. :slight_smile:


Thanks for the reply, Tim. I understand there are plenty of ways to approach the game flow depending on the game type.
My game is a simple (casual) maze-type game. I anticipate 100+ levels. Do I make a level for each maze or bunch them into a few large levels that hold , say, 20 mazes each?
My timer finally works! I was able to pass the “StopTimer” event to my UMG Widget timer. No I need to figure out how to store it and where…and how to get to the next level.
I often have a hard time knowing where to put stuff. What I mean is, what goes on the level blueprint? The character blueprint? The widgets? Am I even right putting the counter on the timer UMG widget? Should it go elsewhere?
It’s that kind of thing that eludes me…if that even makes sense:)
So, I’ll just keep prodding everyone for advice. This is something I’d like to figure out, but need guidance (not someone doing it for me).

What I find that helps me is to work with state machines; basically you create a system for yourself based around States and Transitions.

The States could translate to your levels for example your Main Menu. The buttons when clicked would cause a transition to the next “State” of your game: Main Menu (exit button clicked) -> transition to the Exit Game state which would display a screen asking “Are you sure?” for example.

PlayMaker for Unity is a great example of a tool that lets you develop your game based on States and Transitions.

If you Google “Understanding State Machines”, you’ll come up with a decent list of explanations such as this one](

You can then sit down with a piece of paper or a MindMapping program and develop your states and transitions to your satisfaction and then carry over that concrete design back into UE4 and implement it without any questions as to what you need to do or why since you’ll already have the design well thought out.

While Blueprint looks similar to say PlayMaker and certainly should have the necessary functionality, I never thought about using BP in a “state machine” type paradigm or fashion where you’re developing everything based around States?

This subject now has me wondering what it would take to create say a “State Machine Subsystem” using Blueprints in a reusable fashion to simplify controlling the progression of your game through the use of “states”.

Good luck and great topic - let us know how you make out!


Honestly, it really depends on you.

For the amount of mazes in one level, it’s hard to say.
Remember, you have to make sure that everyone can play the game.
Even avid gamers don’t have 4770ks (or the best GPU) at times and you have to account for that.

If it were me, I’d do 100 different levels. Just to be safe, and slightly because I’m a level designer (I lied, its only because I’m a level designer!).
But then again it depends. If the mazes are more or less in the same “episode” so-to-speak (DOOM-wise I mean, do the mazes have the same colors, textures, etc…) maybe make 5 mazes per level, 20 mazes per episode?
Just a thought.

Good Luck!
Feel free to ask for help at anytime!
~ Jason

Thanks again for the replies. Jason, I’m still thinking about the levels. They will all have themes in common…color mostly. I’m tellin’ ya, it’s a simple game. Very few assets with not many textures. Mostly just colors. I’ll post some images once it’s a little further along. But i was thinking a lot of mazes can fit on one level…but then tracking best times for each maze might get even more confusing than it is now.
I’ve managed to get my main menu working as well as the timer, pause menu and end of level menu…all UMG widgets. I put the timer on the player controller instead of the timer widget. That’s the kind of thing that gets me…where to put the different functions and stuff. At any rate, it’s a start. My next goal is to tackle level saving and loading. That’ll be a doozy!

If it’s simple and loads each map quickly, then you really should keep them separate.

  • As you said it becomes more clear which specific maze a player is supposed to be in.
  • Updating a single maze of a group won’t affect other mazes.
  • You’ll be encouraged to put shared logic outside of the level blueprint, which will help make it easier to make new mazes.
  • If you end up working with someone else on this project at some point you can each work on different levels without affecting the other.

I suppose I’ve got a question along similar lines. Starting to see more and more that I can put functionality into multiple places. Like, I can put movement in a character BP, or the controller BP, or a charactermovementcomponent. I can store variables all over, grab them from multiple places, put them somewhere else. This is indeed really helpful, but quite often I get the feeling that this is far from optimal, if not completely wrong at times. So, threw together a quick test setup. Idea isn’t so much to fine tune functions or come up with detailed mechanics, but more like “Hey, I want to start a game, this the basic outline so these are the classes I need with the basic jobs each will have.”

Does this look accurate? What should change?

Thanks for this reply. It help with some decision making. So, what you’ve put about shared logic on the level blueprint…what should and should not (absolutely) go on a level blueprint? Right now, only adding the main menu to the viewport is on my level blueprint. Is that OK?
So, update on progress: My level plays fine (still need some neat start and end effects). The timer counts up. At the end of the level, it checks for a saved game (creates one if none exists), compares the saved time with your level time and reports if you have a new best time, then saves the new best time.
I’m stuck there. The “EndLevel” menu has an option to replay (reloads the level), play next level, or go back to main menu. So, here’s the new question: HOW do I get it to go to the next level? Let’s say my level names are “Maze_001”, “Maze_002”, etc.
Also, so far, my saved game only stores the best time. I need to save best time (integer) AND level complete (boolean), So I can check and start at the next incomplete level rather than level 1.

I don’t have enough experience to be certain myself, but in my current project I’m also running a level blueprint that loads the menu. I have it in a separate map containing nothing else, and from there I can load into the level the user selects. Right now I only have one level while I pin down mechanics though, so there’s not yet any official way of keeping track of available levels and letting the user select them, instead the load buttons load directly into my testbed level.

There’s a node for loading a new map, I believe it’s called Open Level. (Threw me off for a few minutes as I searched for “Load Level” and derivatives.)

I have the Open Level in my BP. I’m wondering if there’s a way to index the levels so I can open them easily. I want to have a “grid” of the levels that shows which has been completed and which has not. Then the player can select to replay any completed level or chose to play the next never-completed level. Each level will have (so far) 2 pieces of info: Completed and Best Time.
I imaging I’ll need a variable for the completed (boolean) and best time (integer)…currently, I have the best time saving for the level…but it uses that best time for both of my levels. Does that make sense? It’s like a single value being stored and not a value for the specific level.
Anyway, that’s the next hurdle:) Always can use the help!

Fantastic chart! I don’t know where you would want to fit this in, but the UMG Widget for your hud should be created through the player controller and cast from there in the Widget for the best results. As a note, movement could be done in either the player controller or the individual characters easily, it just depends on what you want(imagine a game where you swap characters with different movement styles, but keep other stats through the controller). I’ll have to come back and look over this more.

UMG in the character controller…that makes so much sense, not even sure why that didn’t jump out at me before. Thanks! From my desktop programming experience, have become so accustomed to building the skeleton of each program before diving into each window or control element. As in, if the program requires 5 windows, two with tabs, and a help window, I’d get that done first. Somehow I started UE4 in an opposite way, and keep questioning the overall layout. Sometimes questioning it poorly :slight_smile:

Anyway, appreciate the tip. As always, you folks over at Epic rock!

Yeah, I ended up with most of the UMG stuff in the player controller. Well, the main level has the main menu on the level blueprint, but after that, it’s all on the player or other blueprints. For example, I’ve been trying to get it in my head how to work the saved games. Currently, I can save and load one level. I’ve looked at a good tutorial for saving check points and level for multiple levels. It uses an Enum list.
Then, in my level, I have a start point BP and and end point BP that loads and saves as needed. I get it in concept…but putting it into practice is not clicking with me yet.
Firstly, can I save more than one piece of info in the saved game? I just need “best time” and “is level complete”.
Secondly, using an Enum list…won’t that create a separate save game file for each level? Seems like that can be messy.
Third, I want my main menu (on the base level) to show which levels have been completed…like any typical multi-level game…in a grid format (my example is the game FLOW). So I’d need to check each saved game for level complete. If I have 100 levels (and 100 saved games) would that be the right choice (using Enum list for levels)? I’m just not sure how to do this.
Anyway, if a level has not been complete, you won’t be able to progress to the next one. You can only play level 2 once level 1 has been complete. Get it?
How would you tackle this level saving/loading?

SaveGame is something that’s been on my mind too. Unfortunately, like many things, I dwell too much on the concepts before just trying it out. In another thread I got this link which might help (which you’ve probably already seen, but linking for anyone else):

I’m almost thinking an Enum list of levels might be more of a “this is the latest level the player completed” sort of thing. Like maybe in the SaveGame there would be a variable “LatestCompletedLevel” which would get updated to 1, 2, 5, etc., based on the Enum value. Then I figure there’d have to be something that looks at this value from the savegame, says to itself “So, they cleared level 4, let’s load up level 5”. Then it has some other kind of reference to look at to figure out which map is level 5, maybe the Enum itself has the mapname. Thinking it shouldn’t make a new savegame for each enum, in fact if I’m reading some things right, unless you specify otherwise it’ll just save to a “slot01” kind of thing, where you might have to manually configure it to save for slot02 and on. So with each level save it would just overwrite the previous savegame file.

But, I also am having some difficultly putting it into practice, or at least *seeing *the flow of data. Before I was thinking it would be cleaner to have a single class, like GameMode, gather all the savegame data and handle committing it to a savegame file. Then I thought it might be better to have each controller save data for each individual variable pertinent to themselves…but when I imagine that, I imagine classes all over the place trying to write data to the savegame all the time and something about that idea bothers me. Overthinking it most like.

Ah yeah. That’s a good idea to just store a level number for the “completed”. So 1 saved game with 1 value can let me know which level has been completed. That seems like it can translate over to a grid display of levels…something with equal or less than “last completed level” can display a start or check mark or something denoting a finished level. Incomplete levels will just have the level number displayed on the grid.
the purpose of the level grid is to let the player go back to any level and replay (again, using FLOW as the idea).
But I’m still not sure how to get the best time stored. How can that be done in a single save file? Can I store an array? If so, how do I index that per level to make sure I’m saving/loading from the right index?

Yup, that sounds about right to me. Not had a chance to try FLOW yet, but looks like a fun game. Maybe instead of a number (1,2,3…) for each level you have a starting coordinate and can save the location of the furthest reached point. Like a checkpoint system.

I’d be curious to see recommendations for a global savegame, but I have a feeling it’s as simple as creating a new function and saving to a slot I’d choose to call “ScoreBoard” or something. Looking at the TappyChicken example on the BP_MainGame blueprint, I think this might just do the trick. In fact, this example might solve quite a few questions, the biggest one I’d have moving forward would be if there’s a more elegant way of passing data to SaveGame from multiple actors, gamestate variables, scene data, etc.

Ok, I think I’ll approach the level saving and loading this way:
A Boolean Array for level complete flag.
An Integer Array for best time for the level.
the load and save setup will be on the Start and End “Tile” BP of my game. When the level is loaded, a variable that is level-specific will hold the index number for the array and will pull from and save to that index as needed. Those values can be passed around as needed (like the your time-best time comparison for the UI). So, on OpenLevel, the completions flag is read from the array. If it’s not set, the hitting the end tile will set it to true and save it to that level’s index in the array. On OpenLevel, the time for that level index is read. Hitting the end tile will compare your time with the best time. If yours is worse, it will tell you how much of a slacker you are. If it’s better, that variable is updated and saved, same index.
So, that moves that functionality outside my player control. But does that sound like a good method?

Hey folks. Thought I’d update this thread and give a status report and ask for some more guidance.
So, I got my game flow working well. I can save the game (best time, complete, unlock, level name…all arrays). When I load the level, it loads up the data and you play the level. At the end, your level timer is compared to the saved time. If your time is better, you are notified and the new time is saved in that slot (array index is set per level). The next level is loaded by taking the current index, adding one, and getting the name of the level from the level name variable (plus that one index…so, next level).
So far, so good! The best time is saved and when I play again, it reports the best time at level start and I try to beat it.

My next hurdle is the grid menu for level loading.
I want the Levels to be listed in grid format (right now, just 5 levels). The display is just the level numbers for now (1 through 5). They are all set to a subdued grey color and not clickable by default. So, I want to read the game data and: if the level is “complete”, the text for that level number will be green. If the level is “unlocked” (that would be the level AFTER the last one completed), the text will be bright white. Locked levels will remain grey and unclickable. So this will give the player a choice to replay levels already played or to progress to the next level.
I am so far from any idea on how to do this. Any ideas?