[UE5] Five Settings to Check Right After Creating a Project

Once you create a project, you want to start building right away. But there are a few settings worth handling first.

"I changed a setting and it stopped working." "The game I shipped started from the wrong map." So those do not trip you up, confirm how to record changes and which settings are used at startup. This article introduces five places to check and ends with restoring a practice level from Git history. You do not need to change every value.

What You'll Learn

• Setting up source control (Git) and the thinking behind a UE5-specific .gitignore
• When to use Editor Startup Map versus Game Default Map
• Where to confirm whether the Enhanced Input System is already configured
• The editor's language setting and standard settings for lighter load
• Hands-on: recording a practice level and restoring a deleted Cube

---

Setting up source control (Version Control)

Source control is a system that keeps a history of file changes. In Git, recording the contents at a point in time is a commit, and the place that history lives is a repository. Like a game's save point, it lets you preserve "this much worked."

1. Installing Git: install from the official Git site and create a repository in the project folder (we do this for real in the hands-on section)
2. Linking with the UE editor (optional): Tools → Source Control → Connect to Source Control in the menu lets you review changes and commit from inside the editor

.gitignore — do not commit generated files

A project contains not only models and levels but working files UE creates. .gitignore is a list of files excluded from being newly recorded by Git. Put it at the project root (the same place as the .uproject).

What you keep includes Content (assets), Config (settings), and the .uproject (project information). If you use C++, also keep Source, Build where distribution settings live, and the required files of plugins you added. The diagram shows only the main folders.

# Generated files at the project root
/Binaries/
/Intermediate/

# Cache
/DerivedDataCache/

# Temporary files, logs, autosaves
/Saved/

# Visual Studio artifacts
/*.sln
/.vs/

# macOS
.DS_Store

This is a starting point for a small practice project. Some plugins ship without source and require the distributed Binaries. Do not blanket-exclude same-named folders inside plugins. Saved also contains autosaves. Excluding something from management is not the same as it being safe to delete.

Files such as images and models that are hard to treat as text diffs are called binary assets. Before bringing in large materials, also check the Git LFS setup that manages them (→ Git workflows for UE projects). While the Git history also lives only on the same PC, it is not protection against hardware failure. Use it alongside a backup elsewhere.

---

Default map and game mode settings

Deciding up front "which level opens at startup and under which rules it runs" improves both development speed and the accuracy of your testing. Configure it under Project Settings → Maps & Modes.

• Editor Startup Map: the level opened when the editor launches. Choose the level you usually work in.
• Game Default Map: the first level when the exported game launches. If you have no title screen yet, you can point it directly at the playable level.
• Default GameMode Class: designates the GameMode used as the project-wide default (for example BP_MyGameMode). A GameMode bundles "the character used, spawn points, and game rules" (→ UE5 Core Concepts, and in detail Understanding the Game Framework)

The diagram shows an example separating a development level from a title screen. On a small project the two map settings being identical is fine. A normal "Play" starts in the level you currently have open, so that alone does not verify Game Default Map. Verifying after export is covered in the packaging article.

Also, if a level's "World Settings → GameMode Override" is set, it takes priority over the project-wide GameMode. If the template character is moving, leave that setting alone at first and confirm its role.

---

Input settings (Enhanced Input System)

The Enhanced Input System conveys keyboard and gamepad input to the game. You use it when building new controls. Templates such as Third Person already have it configured, so there is no need to rebuild input that works.

The core of the system is separating "the intent of an action" from "the key assignment."

• Input Action (IA): defines the intent of an action such as "jump" or "move"
• Input Mapping Context (IMC): defines which keys and buttons are assigned to that intent

You can change the button assigned to jump while leaving the "jump logic" untouched. Note that a feature letting players change and save keys from a settings screen is built separately.

Where to check: whether Enhanced Input is enabled under "Edit → Plugins," and whether the Default Classes under "Project Settings → Engine → Input" are EnhancedPlayerInput / EnhancedInputComponent. If it is already set up, leave it. On an existing project using its own input classes, do not replace things wholesale. Creating IAs and IMCs and receiving input in Blueprint is covered in Enhanced Input Basics.

---

The editor's language setting

Choose the display language under Edit → Editor Preferences → General → Region & Language.

Matching your learning material's language makes on-screen items easier to find. This blog also lists English item names so they can be searched. Grasping the overall picture in your language and switching to English later is fine too. If your current display is not causing trouble, changing it can wait.

---

Editor performance settings

These are the items to check when operation is sluggish or the fan keeps spinning even while idle. If it is comfortable, move on.

• Realtime rendering: toggle from the viewport's menu or with Ctrl + R. Turning it off stops continuous updating, so it is worth trying for static work like placing boxes. Turn it back on when checking moving clouds and effects.
• Load while in the background: search Use Less CPU when in Background in "Editor Preferences." It is a setting that reduces load while you operate other applications. It is not a setting that caps FPS while you work.

Scalability settings adjust quality such as shadows and draw distance together. They can lighten the editing display, but do not judge the shipping build's quality from that appearance alone. Confirm the game's own quality settings and how it actually looks in the exported game.

---

Hands-On: starting the time machine with your first commit

Here we record a Cube placed in a practice level, delete it, and restore it. Git restores the contents of recorded files. Let's also confirm that it cannot bring back changes you never committed.

Use a small practice project you just created. Open a terminal in the folder containing the .uproject, put the .gitignore above in place, and run the following. git add selects the changes to include in the next record and git commit records those contents into the history.

git init
git status --short
git add .
git commit -m "Initial commit"

Look at the list with git status and confirm Saved and Intermediate are not included before adding. If your first commit asks for a name and email address, follow Git's guidance to configure them and commit again. Once you have committed, move on to the experiment.

1. Create a plain "Empty Level" with "File → New Level" and place one Cube. We do not choose "Open World" or "Empty Open World" here.
2. Save it as Content/Maps/L_BackupPractice. The map's file name becomes Content/Maps/L_BackupPractice.umap.
3. Run the following in the terminal to record this level.

git add -- Content/Maps/L_BackupPractice.umap
git commit -m "Add backup practice level"

Next, delete that Cube in the editor, save the level, and close the editor. Do not commit the deleted state; run the following.

git status --short
git restore --source=HEAD --worktree -- Content/Maps/L_BackupPractice.umap

HEAD points at the current commit, which here is the moment you recorded the level with the Cube. This command replaces the specified practice map's uncommitted changes with those contents. Reopen the project and success is the Cube back in L_BackupPractice.

We used a normal level that saves Actors inside the map. On levels configured to save Actors to separate files, restoring one map is not enough. That workflow is covered in the Git and One File Per Actor article.

If Saved and friends show up as tracked, check the .gitignore's location and name. Also check whether it gained an extension and became .gitignore.txt. Exclusion rules written later are not automatically applied to files already added to Git.

There are two key points.

• Commit at each work boundary: "one mechanic works," "assets are organized" — making it a habit to plant a flag whenever things work means you can always return to "the last time it worked"
• Details go to the dedicated article: Git LFS setup and the UE-specific workflow avoiding binary conflicts (One File Per Actor) are covered in Git workflows for UE projects. To start with, "commit = save point" alone is plenty to work with

Bonus: Good to Know Up Front

Setting	Purpose	Where to check	Best practice
1. Source control	Managing history and safety	Project root + [Tools] > [Source Control]	Exclude generated files with a UE5 .gitignore
2. Maps & Game Mode	Confirming startup level and rules	[Project Settings] > [Maps & Modes]	Check the map for working and for game launch
3. Input settings	Confirming Enhanced Input	[Project Settings] > [Engine] > [Input]	Leave it alone if already configured
4. Editor language	Making tutorial items easier to find	[Editor Preferences] > [Region & Language]	If nothing is troubling you, defer it
5. Performance	Reducing PC load	Viewport's [Realtime] and Preferences	Adjust according to how heavy work feels

Summary

• Record a working state with Git and test that you can get back. .gitignore is the setting that chooses what gets recorded.
• For startup maps and input, confirm the current values and roles. If they are set, there is no need to rebuild.
• Adjust display language and rendering load when they cause trouble in your work.

With your footing set, put operations into your hands with Editor UI Basics and learn how to grow a folder structure in Asset Management Basics. The overall learning picture is in the UE5 learning roadmap.

Once the deleted Cube is back, try leaving a commit at the moment your own mechanic works. Naming it so you can tell what you recorded makes the boundaries of your trial and error visible.

Further Reading

For file layout, see Epic's Directory Structure and Plugins; for how restoring and excluding behave, see Git's git restore and gitignore.

For rendering updates and background behavior, see Viewport Controls and Editor Performance Settings.