17:44   gamedev , Level Design , MSc

MSc in Computer Games Technology - The Outcome

The previous post established what my MSc was about; The creation and iteration of a level design pipeline for a 'AAA' game, bei...

The previous post established what my MSc was about; The creation and iteration of a level design pipeline for a 'AAA' game, being created with a non-standard development. You can read it Here. While that post explained what the pipeline was and what the project was about, this post will establish how the pipeline was used, what was found and how the pipeline was adapted and changed in order to accommodate any findings.

Building Levels using the Pipeline - Design

Having created an initial version of the pipeline and met with my client about basic ideas for the levels I began the development process. 

The Preproduction Phase of the Pipeline as used for the MSc

The start of the pipeline is the Preproduction Phase which details the paper based design of the level. Using my personal level design template, created for use with the pipeline, I began filling in the information needed to detail the levels design, gathering references and inspiration and creating lists of required assets. 

For the client's project this began with the Story and Narrative Step as their game is very focused on the story as a core element of the experience. A section is written detailing how far into the story this level takes place in and any core knowledge the player has which will affect their gameplay experience. 

The Ideas and Reference Step took the form of collecting references for buildings and environments and bullet pointing any ideas for additions to the level. This included set-pieces, gameplay ideas and a moodboard of colours, inspiring artwork and doodles. This Step also sees the creation of floorplans which would detail space and layouts which could easily be used as reference when finally building the level.

The third Step was to write the Walkthrough of the level, a written account of the entire level from start to finish. This detailed everything the player would see, hear and actions they would take within the level. Included within this are references to the Asset Production List relating to the asset of the level. (eg. knowing I would need a specific tree which is a set piece in the level a reference is left in the Walkthrough as [MDL_01])

The final section of the design document is the Asset Production List which contains any information about specific sounds, models, textures or features that the level contains. This needs to be detailed enough to give to an artist or musician for them to use as a jumping off point for the creation of any required assets. This should be built alongside the rest of the Steps within the design document to keep a catalog of the required assets. 

Building Levels using the Pipeline - Development

With the design document finished it is time to switch from Design to Development. The second Phase of the Pipeline was Production, the in-engine building of the level. While the Phases have been progressed it is important to understand that this is an iterative Pipeline, it will most likely be beneficial for you to return to the previous sections of the pipeline periodically to reevaluate their content.

The Production Phase of the Pipeline designed for the MSc

Due to the client's brief of wanting greybox levels, and the lack of access to any mechanics, artwork or audio from the client, it was decided only some of the stages from the pipeline could be implemented. This reduced Phase is show below:

The reduced Production Phase of the Pipeline as used for the MSc

The first Step, which was added to the Pipeline between the development of the first and second level is the Tools & Assets Step. During the first levels development I found it hard to demonstrate ideas and functionality using the basic greybox objects and as such I was searching for and using free UE4 assets to help add to the atmosphere of the level. This Step was an attempt to rectify searching for these assets as and when they were needed and instead allowed time before development to create or source example models or functionality such as usable lifts and doors. 

Template models from free UE4 Packs (Infinity Blade environments) were used to assist the aesthetics as no assets were available. 

The next Step was to Block Out the levels using basic forms and shapes. This would give a sense of scale and pacing to the levels and detail the overall layout of the level. During this stage it was important for me to take into account elements such as line of sight, focal points, set pieces and movement flow. I worked from the design document using the floor-plans to build the basic shapes and layouts of the rooms and the Walkthrough to ensure the level had the correct locations and layouts for puzzles and encounters.
I left myself and other future developers notes based on each of the Aspects in order to assist with future development. This ranged from information based around the aesthetics or artwork needed to detail the level, puzzle & encounter ideas and narrative elements. These were viewable while playing the level as 3d exclamation points dotted around the level which would expand when the player gets close.

When building the greyboxes for the level I used the SuperGrid Starter pack by ZeOrb in order to get a nice uniform scaling and shape set. This tool saw me all the way through to the end of the project and I found it incredibly useful for every Step of development.

The lack of functionality and mechanics provided by the client made the Functionality Step nearly impossible to implement. I found myself designing small encounters and puzzles which used basic functions such as creating platforms and activating doors or machinery within the levels to progress. In order to counteract the lack of game mechanics designed for the project I began implementing spaces which could have puzzles dropped in by a future developer, when the mechanics were finally designed and implemented. To accommodate this I used a series of notes to explain possible mechanics, puzzles and uses for the spaces within the level.

The notes were added as an important definer for any future developer who has to finish the last Steps of the pipeline such as Art pass and Functionality.  

In order to add to the tone of the level level a basic Lighting and Effects pass was completed. The lighting was implemented including time of day and atmospheric lights. Using some visual effects from the free UE4 packs such as the Infinity Blade Effects pack I populated areas with details which would further the Aesthetics of the level including focal points such as a mining laser, and the smoke in the distance which is used to guide the player through the chapter of the game these levels take place in.

Environmental effects were added to add to the atmosphere of the level, even in a greybox state.

As with the Lighting and Effects Step the addition of Sound & Audio was kept within the reduced Pipeline to assist with displaying the tone of the level. Sourcing some royalty free sounds online I built a small library of effects which could be easily added into the world. The sounds were split into 3 varieties within the Pipeline; Decorative sound such as the wind or rocks are used to detail the level and Interactive sounds which activate or adapt based on player actions such as doors opening or a combat music track. Finally Sound Effects which are the non-diegetic sounds such as pressing buttons within a menu, or stings of sound used to inform the player.
For these levels I focused on the Decorative and Interactive sounds, adding ambient sounds including the wind effects on the cliffs, rockfall within the caves, bug sounds within the jungle and the sounds of doors opening.

Levels open up to wider locales to separate the smaller and tighter environments

The final Step of the Pipeline is the Refinement section of development. This takes into account the playtesting, notes throughout development and any final thoughts for the levels development. During this Step there should be no dramatic changes to the level, only small adjustments and additions should be implemented. This is to ensure there are no major bugs added at the end of development before the handover to the client. Small changes including updating models, lighting adjustments, aesthetic detailing and bug fixing are the elements which are encouraged, but addition of puzzles, mechanics and major features should be avoided. If any of these are needed it should be done though another iteration of those Steps. 

When creating my levels I used this Step to add extra detailing meshes such as trees and rocks, adjust the lighting effects to create a more uniform look to the scenes and add a few final sound effects. 

The smoke was used to guide the player towards the end point of the level, this was intended to be a theme which ran across the act of the game that both developed levels sit within. 

Overall the Development of the levels was a success, a set of levels were created and each of the Steps from the reduced pipeline worked well. The downside was the inability to complete the art and functionality passes which I fell hindered the overall quality of the levels. However for this project it kept within the criteria of the client brief, meaning the development was a success. This was backed up by the client's positive feedback during the project handover.

Refining the Pipeline

Having created 2 levels for the client my final stage of the project was to refine and update the pipeline for distribution to the students on the project. Having already adapted the initial pipeline after the creation of the first level I found the second level a lot quicker and more defined during development.
My final task before handing the levels and pipeline over to the client was to turn it into a single unified resource for distribution to students or staff on the project at the university. I turned the pipeline into an eBook, collating all of the previous versions and adapting the text to make it easier to understand and more streamlined.
The Aspects had a more integral effect on the design and development than originally thought. rather than simply being elements which were used to design the levels; they became the contexts for the design, informing how the world works and how the environments should look and feel.
The Pipeline eBook was finally given an introduction which explains how it can be used, the methodology for its use and information on how the Pipeline is not only a method for creating levels, but also a communication tool for teams creating game levels. This was then provided to the client along with both of the levels as a final handover.  

Conclusion 

During the start of my MSc the criteria for testing the projects success were decided upon as follows:

• Has a functional pipeline been created?
• Is the pipeline optimal for the client’s use?
• Was the pipeline successfully used to develop levels for the client's specific game?

Each of these criteria has been met during the course of development of both the levels and iteration of the Pipeline. The Pipeline was built based on current level development practises and understanding of the client's project. As the Pipeline was built for use with the client's project specifically and tested alongside the client it was deemed optimal for their use. And finally the Pipeline through its numerous iterations was used to develop 2 Levels for the client's game project.

It was a shame that I couldn't use the entire pipeline due to a lack of assets and Mechanics from the client, this did cause issues in the way the levels were made which in the end I found to be a bit bare.
I found design and development process for the client's game to be a bit misguided, the lack of any solid gameplay mechanics or functionality meant it was hard to design the areas and encounters the player would have. While the client had asked for only the greyboxed versions of the level it ended with mostly bare spaces which need to be filled at a future date. Some small functionality ideas were added and the levels and I left notes on the Aesthetics, Architecture, Geomorphology and Audio of the scene for when it is completed.

Were this a more narrative focused game or 'Walking Simulator', the lack of mechanics would not have mattered and the levels could have been created to the point that only art would have needed to be implemented. However as it is intended to have a strong focus on puzzle solving I fear the levels I have created will feel like the mechanics are simply tacked into them. 

Final Thoughts and Download

Overall I felt that my MSc project was a success, I hit all of the criteria which was given by the client and I was happy with the overall level development Pipeline. While I had issues with the inability to implement every Step and the client's involvement with the project, I did feel that I did the best with the tools that I had available. I feel that this Pipeline would work very well in its entirety for a project which has defined mechanics and assets.

I am using this pipeline to see how it works when completing a full game project with the sole focus being on game development, without removing Steps. This is part of the development process for Landfall and will hopefully result in an enhanced version of the Pipeline being created upon release.

If you would like to look at the pipeline which was developed and submitted along with the MSc feel free to follow this link to its page on itch.io or use the widget below.