Defining A Pipeline

Tasks are assigned to individual people, based on their roles and desires, through sprint tasks. Tasks which are set every two weeks, updating group members of where we should be with the project- and what we expect to get done. I always keep these tasks open for change, in case there are any issues with work assigned or complaints. This is all managed within our shared Discord server, where we have frequent calls and discussions about the game. Frequently, we work together also, but this usually happens in person-- as the majority of our group lives together, and most of us are happy to come into class whenever.

Sprint tasks are usually link to their associated Trello boards, which I'll cover later. Below are some examples of sprints.

Pipeline Of Producing An Asset

Everyone would refer to the designated style guide, and example assets beforehand. Quick hand drawn concepts of assets are produced by our artists; Harrison and Abbie. These are then passed along to me and Owen, to be modelled. Me and Owen handled unwrapping for most assets, as we are already handling them, but Abbie and Harrison may do this alternatively. Due to some assets being more complicated than others, and they have specific plans on how they hope to unwrap and texture them. Harrison and Abbie then handle texturing, hand painting each individual asset. Assets are finally implemented in engine by Me, Abbie, Harrison and Owen. I usually implement them for testing, Owen handles the story telling side of the environment, and the Artists (Harrison and Abbie) handle the composition of said assets.

Throughout this whole process, members refer to documentation within the “Asset” folder. I included pipeline, scale (for Blender and Max), FBXs for scale, custom naming prefixes/ suffixes, naming convention and camel case references.

The Asset Trello Board broke assets up into their stage in production, and who is working on them. They can be annotated for priority, commented upon for any specificities, and concepts can be linked to them. Created by Harrison.

Issues had:

Due to our heavy lack of pre-production or definition of style. A majority of the group were unsure to how assets should be produced, creating much confusion when passing assets between one another. Breaking the flow of the pipeline, as we frequently returned to an asset to attempt it once more, or make small changes. This issue could be boiled down to the lack of communication between the group, early in the project. However, when I took over the project manager role, I made sure to focus on the pre-production and set-up frequent talks between the group. Midway through the project, the majority of the group were on the same page, and it was smooth sailing from there.

Another obvious issue, is the overwhelming volume of assets that needed to be hand painted. Also due to a lack of pre-production, we never truly optimised this side of the pipeline. Once I took the project manager role, and pulled the project back to pre-production. Easing this area of the pipeline. See my blog post on "Substance Designer" for my plans with Substance Shader API and Procedural Texturing. Instead, I insisted on the implementation of tiling maps, similar to those of World of Warcraft. So simple assets, such as wood, which we had plenty of, could be textured quickly. With the added advantage of less draw calls. This also led into the idea of using already predetermined textures to create entirely new assets, used extremely frequently for developing varied foliage.

Knowing we were going to produce foliage in such a manner earlier in the project would of been much more beneficial. As UV's and textures could be further adapted with such a plan in mind. However, Harrison made excellent work of what he had available to him. We had an issue with assets needing to be finalised before progress could be made in engine, fortunately this is no longer issue. But, it did cause some problems in early stages of environment design (white-boxing and grey-boxing), I'll cover these soon.

Pipeline In Unreal:

A general concept of the mechanic will be planned; how it effects gameplay and how it works alongside other mechanics that are planned, or already implemented in-engine. This is jotted down and explained in depth by Abbie on the TDD -- usually with accompanying pseudocode/ flowcharts. This planning allows for both programmers to be on the same page, and communicate their ideas efficiently to one another. Once the mechanic is implemented the game is tested for bugs by Abbie. Abbie further optimises code, cleans it up, and variables are in place for easy edits at later dates.

The In-Engine Trello Board broke tasks up into their stage in production, and who is working on them. They can be annotated for priority, commented upon for any specificities, and concepts can be linked to them. A colour key is provided to further distinguish tasks. I built this board as a separation of in-engine tasks.

Issues had:

One of our programmers lacked communication, and didn't document any work or follow the steps of pre-production. The documentation was weak, leading to confusion between the two. Furthermore, there was a backlog when assets were not finished. As someone was adamant on not progressing without finalised assets, we also lacked a clear white-box or grey-box, meaning finalised assets had not set placement. For example, someone white-boxed trees with mega-scans and unnecessary plugins; cluttering the project. After I removed all this clutter the project shrunk from 8gb to 80mb. Furthermore, the landscape was extremely underdeveloped, as you'll see soon. We were producing assets with no obvious purpose, with the risk of them not being used. Any asset requires information and purpose to create, for example:

• How close is the asset to the camera?

• Where should the asset be placed in engine?

• Is there a pre-existing block-out?

• Are there any reference pictures?

• Will this asset be rigged?

• Is there a special shader being used?

• Is there any special requirements for the asset?

Without this the group was lost for months, production was extremely slow. Additionally, for reasons I don't want to share, we had no access to the project for months, to independently make said changes. These issues have been cleared up now; as the group reverted back to pre-production, at a later date, to clear up any confusion.

This lack of pre-production, lack of access, communication, and the engine and it's processes also had a knock on effect on optimisation. Planning techniques of optimisation weren't possible, by the time we had access to the engine, it was too late to implement such techniques as heavily as I would've wanted to.

Later on in the project, we had issues on the engine side with distribution of work. Promises of work being done, but never finished and being forced onto other members of the group. This project has really helped me develop skills of communication between those you work with, and find solutions to such problems.

Version control also would've been very helpful for managing the in-engine project. However, we worked round this issue -- for more on this, see my blog post; "GitHub LFS".

Below is the development of the white-box to grey-box: