How to organize your project?

I’m trying to figure out what the best way to start organize everything.

Currently, I’ve got a fork of UE4, and I’ve successfully compiled it, can get into the editor, etc… This lives at the root of my git tree.

Now when I open the editor and create a new project, is there any recommended way to organize it? Should this project live in its own git repository, or is it ok to put it within the same. I ask, because, I seem to get weird visual studio related issues when I want to edit the source for the project and the original engine code at the same time. Since visual studio is effectively opening the same folder twice, it runs into file locking-like problems.

What has worked for you guys when starting from a similar point? I’d like to have a good foundation for keeping everything in some sort of source control and living harmoniously together.

Hi ,

Ultimately, how you choose to organize your project is up to you. You want to find a method that fits your workflow and helps you keep track of where everything is. Here are a few ideas to get you started, but keep in mind that you don’t have to do things this way.

Folder Structure

When you first start a new project, you may have noticed that the Content Browser comes with a number of folders already created. Use these for storing your different assets for your game. This will help tremendously when it comes to finding and keeping track of your assets. Add your own folders and/or subfolders to help further organize your assets, but do this early in your project. As you get further along in your project, you may find that you are writing hard-coded file paths into your code to access certain assets, and changing your folder structure at that point means finding and updating each of those file paths in your code. Do some planning ahead of time and try to anticipate your needs as your project grows.

File Naming Conventions

Choose a file naming convention that will help you easily identify what an asset is and what type of asset it is. It may be a good idea to also include the date the asset was created/updated, especially if you expect to have a team working on your project and anticipate that some assets will go through several versions before the final version is placed in the game. For example, if I have a Blueprint that I made today that blows up a shed when a trigger event happens, I might name it BP_DestroyShed_20140527. Then, if I make a new version of it tomorrow, I would save it as a new asset named BP_DestroyShed_20140528. This way you can easily see which is the latest version of an asset, and by keeping all of the versions instead of overwriting them when you update them, you can easily go back to an earlier version if you like it better. You can also instantly tell what it does, as compared to an asset named Explosion11.

This applies to all of your assets: Textures, Meshes, Sounds, etc. If your composer creates an awesome piece of music for your game’s main menu theme, and gives you a file named Tears_Of_Orion because that is the name he decided to give to the piece of music, that won’t help you quickly identify the file in a list of hundreds of sound files. Renaming it to something like Theme_MainMenu works wonders.

Source Control

The type of source control you use, and how you set it up, is up to you. You don’t have to use any source control at all if you don’t want to, but it is definitely a good idea to use it. Each type of source control (Git, SVN, Perforce, etc) has its own functionality and quirks. There are a lot of similarities, and a lot of differences. This is not really the place for a discussion of the pros and cons of the different types of source control, you might want to ask on the forums for some input regarding that. At a bare minimum, you should be regularly backing up your project folder. The various source control software available will help with this, as well as providing additional helpful features depending on your budget.

In regards to working on a project within the fork of the UE4 source code that you made on GitHub, it might work best for you if you create a local copy of that fork and make a new repository based on your copy (just make sure you limit access to that repository since the source code in there must only be accessible by people with a subscription to UE4). You can then use your local copy for your project. By setting it up this way, you can keep your fork of the source code up to date with the source code from Epic, and then merge those updates into your own repository.

Source control is something that may take a while to learn how to use effectively, but it is definitely worth learning and implementing early.

Conclusion

A lot of what you end up doing to organize your projects will come from experience and, usually, making mistakes. Pretty much every project you do will teach you something about organizing the project, or show you something that could be improved. The first few game projects that I worked on as a student were horribly organized. I’m surprised any of them actually worked at all, though they were all quite small. But I got a little better with each project, and now I know I have a pretty good of at least finding any file I want in a project (and the Search function in UE4 essentially guarantees I will find it).

The most important thing I can say is to plan ahead. Before you start a new project, spend a few hours (or days, if necessary) thinking about what assets you will need to have in order to make the game work, and then try to figure out how to best organize everything so you can easily find what you need when you need it. You WILL get better at this, so don’t despair the first few times when things go crazy (and they probably will).

1 Like