MSc in Computer Games Technology - The Topic
Over the past two years I have been working part time on my Masters in Computer Games Technology while working at the University of Port...
In this post I will discuss the topic and focus of my MSc and the following post will look at what I found and how the project turned out.
Project Aims
The initial goal of the project was to work for a client, in this case a team of academics at the universityto develop level greyboxes for their game. All I can share about the game is that it is a first person adventure title still in the very early stages of development, with students creating the content for it.As the client had asked for these level greyboxes it was clear that the project couldn't just be about blocking out levels for the game. It was decided along with my supervisor that this project would also provide a pipeline which could be used to develop the levels for their game as only making levels would not give me enough to write about as a MSc. As their game is not being made with a traditional game development process, the level development process would have to be able to accommodate the way the projects management was creating the game. The main difference of their process is that the story has been laid out and the general gameplay is in a basic state (eg. first person, no/minimal combat, puzzle solving using a companion) but no specific mechanics of game systems had been (at the time of this MSc) laid out. The rest of development is supposed to be undertaken by students as parts of their course units if they wish to be involved.
The pipeline, and by extension the levels needed to accommodate the following criteria:
- Game design without mechanics
- Game project without functionality or art available
- Usable in the Unreal Engine (Though the pipeline is intended to be engine neutral)
It was decided at the very start of the project that the methodology for both the creation of the pipeline and the creation of the levels should be very fluid and iterative. Because of the unrefined nature of the game project many elements would be subject to change as the project progressed. In order to accommodate this, a workflow which would allow constant updates and version changes was built alongside the pipeline, allowing for the client feed into the design and development process with their ideas and recommendations. This also would allow my own skill enhancements to feed back into entire level creation process, enhancing the final level outcome.
Creating the Pipeline
To start the creation of the pipeline I did some initial research into level design and development pipelines used by other developers. I looked into the methods used by developers on how they begin the creation of the levels and the various stages which are found in many of their processes.
Working with a member of the academic development team I created some design documentation using a template I had made for level designs. This was based on a number of online templates or documents which I found during my literature review. The main influence on this document, along with my own personal needs of a design document was the Preproduction Blueprint by World of Level Design. This eBook was invaluable to my documentation process for the levels I would build for the MSc. We worked on the basic idea of the level including theme, location and key story events before I began my personal design and development.
The creation of the level was split into two Phases Design & Development, which were further divided into a series of Steps. The Phases are the two overarching segments of level creation process, namely the Design; featuring as the paper based development of the level, and the Development phase; the implementation of the level in a game engine. The Steps fit inside the Phases and detail the individual tasks which should be completed in order to build the level.
The final tier of the pipeline are the Aspects of level design. These are keywords which make up the contexts which influence the design decisions during the Steps within the pipeline. The diagram below shows the Phases, Steps and Aspects of my level development pipeline:
The Steps are split between the two Phases and each of the Aspects feeds into the Steps. These Aspects detail and inform the design based on research and current understandings. For example; Architectural principles will feed into many Steps during the level development process. While this will vary from game to game based on the setting and style (eg. a surreal platforming game will have less of an emphasis on realistic architecture) the rules of architecture will often come into consideration during the design, blocking out, art and narrative Steps.
Each of these Aspects were considered & implemented because they give a broad set of contexts to the design and development of the level and help to inform any design decisions within the level development life cycle. The diagram below shows how the Aspects feed into the Phases and Steps of the pipeline:
At the start of this project these Aspects were less refined but as the development of the levels continued and the pipeline was adapted they gained actual definitions. The diagram above shows which of the Steps each Aspect was used in during the final round of level development. Using an iterative methodology during the project allowed me to constantly reevaluate the Phases, Steps and Aspects until they were at a state I was happy with. This was a major positive to my workflow and so was integrated into the final pipeline as the overarching methodology.
This post has detailed the aim of the project and the creation of the pipeline. This was then used to develop greybox levels for the clients game while iteratively adapting and adjusting the pipeline.
The following post will detail the use and iteration of the pipeline and the outcomes & findings of the project. It will also contain a link to download the final Pipeline developed for the MSc as an eBook.
Working with a member of the academic development team I created some design documentation using a template I had made for level designs. This was based on a number of online templates or documents which I found during my literature review. The main influence on this document, along with my own personal needs of a design document was the Preproduction Blueprint by World of Level Design. This eBook was invaluable to my documentation process for the levels I would build for the MSc. We worked on the basic idea of the level including theme, location and key story events before I began my personal design and development.
The creation of the level was split into two Phases Design & Development, which were further divided into a series of Steps. The Phases are the two overarching segments of level creation process, namely the Design; featuring as the paper based development of the level, and the Development phase; the implementation of the level in a game engine. The Steps fit inside the Phases and detail the individual tasks which should be completed in order to build the level.
The final tier of the pipeline are the Aspects of level design. These are keywords which make up the contexts which influence the design decisions during the Steps within the pipeline. The diagram below shows the Phases, Steps and Aspects of my level development pipeline:
The Steps are split between the two Phases and each of the Aspects feeds into the Steps. These Aspects detail and inform the design based on research and current understandings. For example; Architectural principles will feed into many Steps during the level development process. While this will vary from game to game based on the setting and style (eg. a surreal platforming game will have less of an emphasis on realistic architecture) the rules of architecture will often come into consideration during the design, blocking out, art and narrative Steps.
Each of these Aspects were considered & implemented because they give a broad set of contexts to the design and development of the level and help to inform any design decisions within the level development life cycle. The diagram below shows how the Aspects feed into the Phases and Steps of the pipeline:
At the start of this project these Aspects were less refined but as the development of the levels continued and the pipeline was adapted they gained actual definitions. The diagram above shows which of the Steps each Aspect was used in during the final round of level development. Using an iterative methodology during the project allowed me to constantly reevaluate the Phases, Steps and Aspects until they were at a state I was happy with. This was a major positive to my workflow and so was integrated into the final pipeline as the overarching methodology.
This post has detailed the aim of the project and the creation of the pipeline. This was then used to develop greybox levels for the clients game while iteratively adapting and adjusting the pipeline.
The following post will detail the use and iteration of the pipeline and the outcomes & findings of the project. It will also contain a link to download the final Pipeline developed for the MSc as an eBook.
