Creating a Template Project (UE4 Tutorial)

Creating a template project can greatly speed up the development time of future projects. This post will detail some of the features and concepts I included while creating a first-person template project in UE4. 
Note - This is not a downloadable project or technical tutorial but rather a list of tips which may help others while creating their own set of tools.

My template project was created using UE4 and C++, however, the same concepts could be transferred to other game engines and programming languages. This is the way I personally like to set up a project and it may not meet everyone's needs or personal preferences. 

Feature List

• UI Interaction and Input system.
• INI/config file game options.
• Base User widget and custom widget components.
• Instance menus (Confirmation, message box etc).
• Generic player interaction system.
• Custom function libraries.
• Full gamepad and keyboard support.
• Progress and goal achievement system.
• Player statistics system.
• Keyboard and Gamepad rebinding.
• Health and damage systems.
• Unlimited save slots.
• Replay level feature.
• Custom console commands.
• Debug/Helper objects.
• Sprint/stamina system.
• Pickup physics objects.
• Simple player objective system.

Interaction

Personally, I feel one of the most important features to include is a robust player interaction system. In this project, I added multiple options here including click type (Single, hold or multiple clicks), what components an input will map to, a way to lock an input, outlines and display options for both keyboards and gamepads.

Making this as a component allows me to easily add player interaction to any object types, this would not be possible when using a base class method. This could be used for countless interactions including opening doors, picking up objects, unlockable chests etc.

User Interface

Custom UI Components
In this project, all UI components are children of a custom base class which includes many useful features e.g. easily customisable animations, selection/change data events, data saving, gamepad interaction and image/flat colour styling options. Many of these a wrappers for other classes with the extra functionality mentioned above.

Many inbuilt UI components will work fine for simple menus, however, as things become more complicated, with nested widgets this can become incredibly convoluted. These widgets abstract away their hierarchy and functions making designing game windows and gamepad interaction a much easier process.

 

Windows
In a similar way to the components, windows are children of a custom base class which makes it easy to create systems to manage the opening of windows and passing in player input (UE4 does not support key or gamepad input in User widgets).

Instance Menu
Another concept I like to use is what I call an 'instance menu'. This is a smaller submenu which will temporarily consume user input until closed. I have used these for message boxes, confirmation boxes, key remappers and number selectors. These can have delegates (Event Dispatchers) defined in C++ which can be overridden in the parent blueprint class providing a callback function. A menu callback can be seen below. 

 

UI Tutorials
I would recommend a system which can display a list of inputs which can be used on the UI. In this project, these automatically pull binding data and gamepad icons. This will dynamically update based on the last used input device.

Game Options

Game options are a good feature to include in a template project as they are fairly standard across all game types.

In this project, options are all saved within an INI file allowing them to be edited outside of the game if the player wishes.

Key Binding + Gamepad support

At the beginning of this project, I knew I wanted to ensure that the game had full gamepad and keyboard support. I found it was important to design around this from the beginning as retroactively adding it later can prove to be challenging (From a past experience). For my specific implementation, I have defined a data table to store all mappable bindings.

Saving

Although many game engines have acceptable saving options these are usually missing useful features. To overcome this problem, I created a new save system based on the default which stores additional metadata and supports instances of a save game. In addition to this, I abstracted the saving and loading process into a single node. 

Types of save game
Usually, I will create three types of save game.

• Main - Saves player progress throughout the game. Multiple instances.
• Options - Stores game options. Use of an INI file.
• Persistent - Stores any other information which does not get reset from save game to save game e.g. achievements, statistics and last loaded save slot (used for continue game button).

Although saving systems can change dramatically from game to game e.g.  Save at start of a level, save only key objects or saving everything (physics included) it's probably best to make some form of generic system which can be easily adapted to most situations.

Helper Libraries

Creating a set of globally accessible functions/methods for common actions can help keep code clean by abstracting away complex tasks. Including functions returning the casted version of the player can save you from rewriting the same code when you need to talk with the player. Other functions also include finding the corresponding gamepad icon for a button name, saving and opening levels a with a load screen.

Other Systems

As part of this specific project, I decided to implement several other larger systems. These are entirely optional but like many of the other features, they do not change greatly from game to game. They only need to be made once and can be continuously reused.

Achievements

Statistics

Health / Damage

Another system which can be useful in a template is a generic health system. Such a system can be made as a component allowing it to be used in multiple places from the player's health to harvesting resources in a survival game.

In my system, I included functions for taking damage instantly or over a set period of time. Having all damage based on a single component allows damaging code to know exactly which items can be damaged and how to apply it. A more advanced system could include other features e.g. Armor and types of damage (Impact, fire, explosion etc).

Helper objects and console commands

In this project, I created several assets which I call 'debug' or 'helper objects' which provide some specific functionality. Some examples include Autosave trigger, objective updaters and damage overtime trigger. These all have a hidden icon within the scene.

I have also made a set of custom console commands which can help with developing/debugging code. One of which will display the helper objects in the game world. Unfortunately, custom commands in UE4 can only be created in C++, however, can be implemented in a child blueprint class if you choose to do so. In other engines, a custom console or cheat menu may need to be downloaded or created.

Other features

There are many other features which may be useful depending on your preferences or the type of game you wish to make. Some of these things could include:

• Multiplayer/co-op support.
• Other Networking features.
• Quick saves.
• Base weapon templates/systems.
• Dialogue system.

Other Tips

• Use Data Tables
  • Defining data e.g. collectible items, mappable bindings and achievements as a table ensures it's easy to make additions when creating a real game. UE4 has this as a built-in feature. For Unity, you may need an external asset. I have already created an asset for this: https://samcarey.itch.io/simple-data-tables ;)

• Modularity
  • Designing modular systems can greatly decrease development time when it comes to actually creating a game. Features including the health and interact components are good examples of this modular design.
• Event systems / Delegates
  • The use of Delegates/event systems can greatly aid in the creation of modular features. These are used throughout many items in this project. More information about their use can be found here: https://docs.unrealengine.com/en-US/Programming/UnrealArchitecture/Delegates/ind... . In the Unity engine, a similar concept to this would be event systems.
• Quality of tools
  
  • When creating a project such as this it is better to spend extra time to ensure that your tools are created properly and are not just hacked together. These systems could be used for years to come if implemented correctly.
• Generic code and plugins
  • It's good practice to ensure that systems do not depend on project-specific classes. This can make it easier to move code to another project. Creating a custom plugin in UE4 can help with this by separating game code from systems and ensuring that all code is project independent.

Creating a feature reach template such as this can improve development speed and if made correctly can be easily adapted to fit most project types.