2
\$\begingroup\$

We have a team of 3 designers and 2 developers with no prior industry experience working on a Unreal Engine 4 project. The designers will be creating assets & laying the scene out in the editor while developers work on the functionalities in C++ side. What's a general strategy of partitioning work for such setup? More specifically, how do you have the team collaborating so that the project can be worked in parallel with minimal conflicts?

I understand that you can partition the map into sublevels and make sure that only one sublevel is being worked at a time. Well, what if you needed the designer to modify the scene while the developer adds some functionality to a sublevel? Is this not possible in Unreal?

Then there's the matter of source control. Ideally, I'd like to setup a git repository but the designers probably doesn't know how git works at all. Do game companies generally educate the designers so that they at least have working knowledge of source control to do what they need?

I'm just very confused about what the proper workflow should be.

\$\endgroup\$
3
\$\begingroup\$

Stock Unreal uses a binary file format for its assets; switching this would be prohibitively expensive and is thus effectively a no-go. That means you have to life with binary assets, and the problem with binary assets is that they don't merge well, if at all. This complicates collaboration.

Unreal has built-in support for most major source control systems, and where possible (e.g., with Perforce integration) will encourage you to use a system of exclusive checkout on asset files, so that only one developer can be making modifications to a file at a time (excluding some workarounds that are generally only good for temporary, scratch work one won't check in). There is some basic support for diffing certain binary assets within the Unreal editor, but it's not great, and merging support isn't really a thing.

So the best strategy is to partition your work: where feasible, break up data into different asset files so different people can modify individual files as they need. Use Unreal's sub-level support to partition your world in a fashion that works well for your design process. For example, you might put the terrain in one sub-level, major, broad-strokes environment art in another, set dressing and minor detail work in yet a third, and audio stuff in a fourth, et cetera. Such an organization would in theory let four different developers work on the same area concurrently so long as they only need to check out one of those levels.

Of course it is still possible for, say, an audio developer to be laying out a bunch of audio volumes around a building to get correct reverb settings while somebody else is busy moving that entire building somewhere else, thus creating a logical conflict. You can basically only avoid these through communication and coordination, and by paying attention to who has what other levels checked out. With a small team, this isn't that hard.

You could alternatively split the world up into several small chunks in a grid-based fashion and just dictate that everybody work in different regions of the world at once. This helps solve the major downside of the first approach (except maybe at the seams of the levels), but can also make more bottlenecks when people need to make changes to the same region of the world at the same time. This also requires communication to resolve.


The above mostly applies to developers who need to work on the binary assets (levels, art, Blueprints). It usually excludes programmers who work on the C++ side of things. Generally, so long as C++ programmers are not making destructive or other major file-format changes, they can work on anything concurrently with the asset-focused developers, and can use standard source control and collaboration techniques (merging, et cetera) to synchronize work with other programmers.

Where you can run into trouble with C++ changes is in scenarios where your non-programmers do not build the entire editor from scratch themselves -- that is, when they're using a pre-built binary of your editor version from a build server or whatever.

If a programmer makes certain changes, for example, if they change a file format, they generally have to be careful not to check in new assets in that format until a build is available to the non-programmers. If they check in assets in a new format before a new binary is available, and an artist syncs those new assets from source control, the artist may no longer be able to load the assets and end up blocked or even crashing, depending on the nature of the change.

This sometimes means programmers have to do this annoying dance of checking in changes with shim code supporting both old and new versions, letting that build go in, and then later removing the old shims. There are processes you can put into place to enforce these rules, and even tools you can build to help enforce it, but nothing really comes with Unreal itself.

\$\endgroup\$
0
\$\begingroup\$

Unreal has source control built in, I recommend checking out git, and setting up a local git server to track the users and their changes.

Good practice includes working in a separate branch per sub project. for example. If I am working on a blueprint script for a light switch I would create a branch called light switch, and after it has been tested I can merge the branch into the main branch. This prevents issues that can break the entire project until they are resolved or files from being inadvertently deleted.

As for partitioning the project, Take the overall project, and decide what components need to be built or designed, assign those to a group, then split those down into tasks. assign each group member a task based on their skills.

Slack can help in organizing communication within each group, and overall. I recommend no more than having meetings 3 times a week. This helps the programmers a lot. mainly due to the common requirement of maintaining the overall code they are working on in their head until it is complete in code.

Be sure that the code is properly commented. I can't stress how important that is especially in large projects.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.