Honors Project – Video Game Conceptualisation Tool

Images may be missing at this time. Video incoming soon.

  1. Introduction

 

At University, especially in the school of computing, there are an abundance of opportunities to develop games, at game jams, free time or as part of a chosen/set module. One of the main challenges that these students face however is one of their own making. These students are often too focused on the technical aspects of the game that they forget the importance of design and graphics. These particular students often lack any real visualisation of their game as they try to cram together some gameplay elements. This is usually due to insufficient skills in design processes and asset development whether that is creating graphics, sound, animations or all of the aforementioned. This is known from experience as well as the findings found in my User Requirement Analysis research found at Appendix E

 

Small teams or individuals, outside of the safety net of university, can sometimes be in the same situation. These developers are often looking for some way to get funded by small publishers/companies or through kickstarter sites. The developers in the situations mentioned would lack the required skills to create the more visual elements and concepts of the game. This would likely result in the inability to acquire funding.

 

Through some of my own research I was able to prove my statements above, see Appendix A. This research queried respondents on specific parts of their conceptualisation processes. Some questions looked into how hard they found the process of conception from art assets to the hindrance their skills play in this process, whilst other questions looked into how the respondents felt about a tool that would help them in this process. Seven out of ten respondents said that they found it hard to visualise their game, this is a big percentage of developers that are saying this and as they are from Stage 4 Uni student developers and graduated developers it is a bit worrying.

 

My tool reduces the skill ceiling of the visual conceptualisation of game scenes as well as reducing the development time needed for such. Whether this be for initial game idea pitches, actual levels/scenes or a template to build the level/scene from. My tool makes use of procedural generation techniques to create dynamic content that is similar to what the user is looking for. This works through a form in the Unity project that allows users to modify options to get the result they are looking for. The state of the tool at the moment is limited by the assets currently gathered and produced and could be improved greatly with more focused models.

 

This report will be discussing the aims, planning, research, developmental processes and outcomes of the project titled Video-Game Visual Conceptualisation Tool.

 

This report discusses the motivations and market need for the project, this will then flow into the aims and objectives of the project and the final deliverables thereof.

 

  1. Project Background

  2.1 Project

 

For this project I have not found a client and am instead doing this out of my own motivations based upon my experience at Plymouth University whilst doing my degree. The main motivation here was the lack of my own ability to create a visual conception of any projects I worked on, particularly in the first year with this gradually getting better as I developed my skills. I had always found it hard in projects, especially games, to find reasons to put something, whether that is UI or an enemy, in a specific place: What is the reason this object is there? Why here? Is there a better place for it?  

 

The tool I am creating is within a Unity project to make use of the Unity Engine instead of creating my own. This means that I am able to have a wider user base as Mac and Windows users will be able to access this tool and use it as they please. Development has been made on Windows so there may be some issues when porting the project to Mac, but this is attainable should the user copy the root folder when attempting to transfer to Mac.

 

The tool has been developed for those like me, who had a lack of visualisation when creating a game. This therefore, is aimed at helping beginner game creators to visualise there game somewhat by generating ideas to their specific wants. The main issue with this tool is that, because their are so many different types of themes, eras, vegetation and architectural structures then it is almost impossible to have precisely what the user wants.

 

  2.2 Aim

 

The main aim of this project was to provide a tool that could help users with initial visual conceptions for those with a lack of skills or experience in this field. With this main aim it is clear that the generated visuals should be in some way procedurally generated to give users different results even if they used the same options again. This also meant that the tool needed some way to repeat the exact same result.

 

As the user is deciding on what they want in terms of theme and size of map, etc, then it was important to give users the ability to do this. One of the tools aims is to create an intuitive and explanatory user interface to allow them to interact with the different options available.

 

Overall the aim is to deliver a tool that allows users to choose from broad inputs to generate an environment that is close to what they are after.

 

  

2.3 Minimum Requirements

 

The minimum viable project is a different concept to that of the expected outcome seen on the PID. The minimum viable project would be missing some of the features that would be expected in this prototype and may be missing some of the core features (i.e. Increment 3).

 

My minimum viable project is expected to complete;

 

  • Proposal
  • Project Initiation Document
  • User Story Board
  • User Testing (in finished Increments, one for each)
  • Changes made to prototype based upon the feedback received
  • User Requirements Research and Questionnaire
  • Story and Video-Game Conceptualisation Tools Research
  • Procedural Generation Techniques Research
  • Conceptualisation Tool Prototype (Increment 1 and Increment 2, see PID for more information)
  • Conceptualisation Tool Instructions

 

This has been decided upon to allow me, if time does not permit for development on Increment 3, to focus on the first two Increments in more detail to deliver a prototype that fits the brief of the PID but may not be complete yet. As with all projects, this project is expected to see setbacks which is inherently the nature of software design and development. It is unfair therefore, to suggest that I will complete or start on all features mentioned in the PID. This however, will be addressed and evaluated as such in the conclusions of this document.

 

  1. Objectives

  3.1 Project Objectives

 

  1. To provide an accessible main UI that can be easily understood and used for the basic purpose of the tool
  2. To provide more in depth customisation options (than presets) that affect the outcome of the generation
  3. To provide more in depth customisation to the environment after the generation has happened
  4. To create scripts that are capable of terrain generation using Cellular automata and/or Perlin Noise to complement them
  5. To create scripts that are capable of seamlessly adding environmental and architectural objects into the generated environment in a way that looks believable
  6. To create scripts that are capable of adding detail to the already generated environment
  7. To create documentation that informs users on how to use the solution
  8. To develop a technology or deployment solution that allows for video-game concepts to be visualised based on broad inputs from the user that, characterise the theme of the concept (i.e. art style: realistic; theme: Japan, Samurai era, etc.) or/and characterise the terrain and environment.

 

  3.2 Planned Deliverables

 

Below are the planned deliverables that were decided upon at the start of the project. Although this project was more of an exploratory project to begin with, final deliverables should not be changed because of this, although each deliverable may be somewhat different than initially expected.

 

  • Proposal
  • Project Initiation Document
  • User Story Board
  • Roadmap
  • User Testing Consent Form
  • User Testing Feedback x 3 (one for each Increment of development)
  • User Requirements Research and Questionnaire
  • Story and Video-Game Conceptualisation Tools Research
  • Procedural Generation Techniques Research
  • Conceptualisation Tool Prototype
  • Conceptualisation Tool Instructions

 

  1. Research

 

As this project was initially in an exploratory phase, meaning I was unsure how to approach the solution fully, there was a lot research that needed to be done into three main areas. These three areas were User Requirements, Procedural Generation Techniques and Story and Video-Game Conceptualisation Tools. These three research tasks have been documented in a report style and can be seen in the Appendices, in the following places;

 

  • User Requirements Analysis                                                  – Appendix B
  • Procedural Generation Techniques                      Appendix C
  • Story and Video-Game Conceptualisation Tools   Appendix D

 

4.1 User Requirements Analysis

 

This first research task looked into the suitability of the project that I was proposing to develop, to ensure that there were other people in a similar position to me. As stated in the research, during the early stages of my University course, I find it extremely hard to visualise any parts of my game, which was somewhat down to a lack of knowledge in coding. This is further problematic due to the lack of experience I had in design processes and in art skills in general, which made it harder to visualise what the project could be or would be.

 

To understand a bit more of what people would want in the tool I was proposing, I created a SWOT analysis looking into how a solo developer or team with a lack of art skills and design process experience would develop their projects. The analysis found that there would be good developments in terms of mechanics and features but the overall visual elements of the project would be lacking or non-existent. The analysis also found that teams that are looking for investments would find it harder, as they would lack the visual imagery needed to secure these investors.

 

After completing the SWOT Analysis I created a mindmap to sort out what would be needed for this potential client-base, this also looked into existing tools that would help with this problem.The mindmap helped me get a good base idea of how this tool would need to be presented to the clients in terms of UI and what features it would need to be useful in any capacity. Whilst this mind map informed the design of my solution it did not touch on each aspect that I would like to involve into the solution in the future.

 

To help get a better idea of what these clients would want I created a User Story Board. To be able to create this board I had to put myself in the targeted users shoes, and understand what it was that they would want from a tool that had this purpose. By doing this, I was able to understand what developers without art skills or design processes experience would want. The User Story Board can be seen in the Appendices.

 

To find out other people’s opinions in this matter and to ensure the suitability of the project I created a questionnaire aimed at developers asking about their difficulties developing due to lack of visualisation and difficulties in developing visual assets e.g. 3d models. I feel that it was important for me to phrase these questions this way so that respondents were unlikely to be dishonest or upset that I would suggest that they could be deficient in these areas. In total I had 10 respondents fill out the form, this was a mixture between devs on my current course at Plymouth University as well as developers signed up to the facebook page Plymouth Game Devs. It would have been good to get more respondents but after waiting a week it was unlikely I would receive more respondents and had waited long enough before finishing this research piece.

 

The findings were as I expected, most of the respondents thought that they had a lack of experience in design processes and asset generation. This therefore, immediately created the need for my project and the finished solution. If you would like to see the research findings please see them in the appendices.

 

This research concludes on the findings and directs me as a developer on the way I should now develop the solution. Whilst the research found mostly what I thought it would, there were small findings that changed the direction of the project somewhat, like the focus on UI which was not a concern beforehand. To see this research in its entirety please see the appendices.

 

4.2 Procedural Generation Techniques

 

My second piece of research looked into the different techniques used for procedural generation in general, rather than specific ways of developing for procedural generation. As such this limited the research due to larger developers not sharing their techniques with the world, this is an obvious way to keep their techniques safe from competitors but leaves my research lacking.

 

I looked into six different techniques that I could find documented online which were;

 

  • Cellular Automata and Marching Squares
  • Perlin Noise with Octaves, Lacunarity and Persistence
  • Fractals
  • Tiling
  • Voronoi Diagrams
  • Wind based vegetation spread

 

For each of these techniques I evaluated their usefulness for each feature I was going to implement, this was therefore measured mainly against each increment mentioned in the PID. Each technique would also be considered based upon development time needed to make the feature useable and how well this would work. I tried to refrain from mentioning which increments each technique was not useful for, as this was useless information.

The summarised findings for each of these techniques were as the following;

 

  • Cellular Automata and Marching Squares – If the technique can be revered to create exterior spaces then this could be a great technique to create organically shaped play areas for Increment 1 Terrain. This technique could possibly take some time to develop and may be overambitious for the time I have.
  • Perlin Noise with Octaves, Lacunarity and Persistence – This technique seems great for Increment 1 Terrain and seems to be difficult to set up at first but is very flexible and can be changed and generated very quickly.
  • Fractals – This technique seems to have no uses within the project although this could change in the future when more features are considered.
  • Tiling – This seems great for 2D play areas, however since I am focusing on 3D for now this is not a great approach to Increment 1 or 2.
  • Voronoi Diagrams – This technique seemed not so useful as it would be an over complicated way of integrating Increment 2 and would allow me to know useless information.
  • Wind based vegetation spread – This technique created by Unreal seems like a perfect way to approach Increment 2 although the time needed to make a system like this would be too much and a project within itself. An imitation of wind based spread could be created using random starting points and crude calculations of spread. This could then be made better with sun based growth an idea of my own, again as a crude calculation based upon the amount of days the user would input into the generation.

 

I concluded this research with an overview of what seemed useful and what seemed useless for my project and made suggestions on how to approach each Increment of development. Please see Appendix G for the full documented research.

 

4.3 Story and Video-Game Conceptualisation Tools

 

This final piece of research looked into other similar tools that could be used for the same purpose. The tools that were researched lacked similarity to my own proposed tool due to the differences in the end result and effort put in. This research allowed for me to expand upon the details within my solution and consider other features that I may not fo thought of otherwise.

 

Each tool was evaluated by me based upon its suitability and options available to the user, with most of these tools being simple story generators that gave little choice and relied upon random generation to give users quick results. The following tools were looked at;

 

  • Plot Generator
  • My Self-Insert Story
  • Story Idea Generator
  • Random Plot Generator
  • Story Generator
  • Seventh Sanctum Story Generator
  • ConceptStart
  • Environment Generator
  • World Machine

 

Each of these tools gave me some insight for my project whether that was features or options that I could include or ones that I would want to avoid. Seeing the lack of different conception tools for games or stories made me aware of how little of them there are for developers in the situation mentioned in the Introduction, which further increases the demand and need of a tool like the one I have proposed.

 

The two more interesting researched tools to look at were Environment Generator and World Machine due to their use of actual visual aspects that can be created using procedural generation techniques.

 

The Environment Generator seemed to be a small prototype that was in early stages of development and was the type of thing that I was looking at expanding upon. With the tool having lacklustre options for users I knew that I would have to create a tool with a lot more options to allow users to create unique environments. It was not mentioned in the research but it should also be considered that the tool is limited by the assets contained within it, i.e. medieval assets can only be used for medieval environments.

 

World Machine was very interesting to look into as it is a full fledged application developed by a great development team. The program has many different options for users to create terrain and textures using different techniques which include procedural generation techniques as well. It was a shame that the tool is so different to my proposed one in terms of focus with World Machine focusing on creating terrain rather than an environment. The tool needs some investment to be able to utilise it fully and create great looking terrain, whereas, my own goes for a more considered approach to lower experienced developers to procedurally generate an entire environment based upon their needs.

 

The research concludes with an overview of how these tools can help in different ways and how it was unfortunate that I was unable to find tools that were very similar to my own, in a completed state. I then make suggestions based upon my findings which mainly consider the form elements of the project. These form elements will be what the users interact with and so must be clear to the user and make sense, so that the user is able to pick what they want and get the outcome that they wanted.

 

  1. Method of Approach

5.1 Project Management

To help with the process of development I have decided to adopt an Agile methodology to allow myself to stay on task and work towards clear goals. More specifically, I have decided to use the ScrumBan methodology for clear weekly targets and the chance for self-reflection for each sprint. This methodology also allows me to work past the set targets should I manage to complete them and continue working as fast as possible on other tasks. As this is a solo project I have decided that if I get stuck on a non-essential element of the solution then this will be dropped and potentially revisited towards the end of the project cycle.

 

To help with the project management aspects I will create a Trello board and adhere to PRINCE2 control techniques, as referenced in the PID, see Appendix E “PID, 6.1”. Whilst Agile is an amazing developmental approach, and is regarded as a highly successful one, it usually lacks any form of project management. As this is the case here, in my take on a mixture of a SCRUM and Kanban approaches, PRINCE2 will be followed. To allow myself to track what has and has not been completed yet I will have an online Trello board. This board will allow me to mark tasks as completed, in progress, or, to be done, which will help me to understand what needs focusing on next. This board will also be used to store online copies of documents and other important information for the project, where it can be accessed quickly as needed.

 

5.2 Pre-Development Approach

Before any development began I had a very different idea of what my project would be compared to where I am now (evidence of this can be seen between proposal/PID and PID v2). The initial plan for this project was to have a more 3D modelling focused project that depicted an alternative sequence of events centred around the Cuban Missile Crisis, in which nuclear weaponry was fired on both America and Russia. As this project was less technically demanding than most this wasn’t actually a good idea for an honors project in a Bachelor of Science Degree, this became very apparent after my first meeting with my project supervisor Paul Watson.

 

Furthermore, after drafting a secondary PID and creating a new project idea, I found that most of what I was touching on to be quite new to me.Therefore the objectives became much more focused around research and were quite deterministic on the results of this research. Due to this, I created a tertiary PID to clarify what the project objectives were, based upon my findings. Approaching the project in this way really allowed me to clarify exactly what I was trying to achieve by the end of the project and gave me insight into how I would achieve the end result.

 

After my research had been completed I decided it would be best to use someone else’s code as a good base start for the terrain generation aspects of the project. This not only saved me a lot of time and allowed me to focus on development of other aspects within the project, but meant that I didn’t need to reinvent the same way of generating terrain, on my own. Few modifications have been made to the code to allow me get the terrain generation working as I need it to and some parts of code have been completely removed as they are unnecessary for my use of it. Please see Reference 1.

 

5.3 Version Control

To allow the project to be free from the limitations of one computer, and many other reasons, version control was utilised for this project. Version control was an instrumental tool in this project, allowing me to reverse any changes made or recover ones that had been removed whether by accident or through data lossage. Whilst this wasn’t used in this capacity for this project, yet, it is an important tool to use to save the project from any data lossage or corruption.

 

Whilst there are many options out there for version control I decided to use git, mainly due to my experience only being with git. There are many hosting services for git which is great for options, I decided to use GitHub rather than BitBucket (the two services I have used) so if I work on a public computer I won’t have to install a fresh copy of Sourcetree.

 

Due to the management of my project and my lack of success using Git Flow I decided to opt instead for a solitary branch whilst in development. Whilst this is not a good practice this helped me to focus on what is important for this solo project rather than worrying about issues that would only be a major concern if I were part of a team.

 

5.4 Legal, Social and Ethical Issues

Due to the nature of the project there are likely to be some issues arise in regards to legal, social and ethical aspects. The issues I am expected to encounter are already documented within the PID which can be seen at Appendix D.

 

One issue I am likely to encounter is Ethical issues within User Testing. As user testing had already been approved for this module there was no need to pursue approval from the University for this. There were some rules however, for the user testing in this module. To keep within these I created a consent form for each user and made sure that they understood the terms and conditions of the form. I also made the testers aware that they were free to leave at any time and without reason, should they need to. Users were also free to withdraw from video or audio recording whilst still participating in the study. For the comfortability of the testers I decided it would be best to not video or audio record the testers.

 

Another issue that I am likely to encounter are legal issues with the repurposing, re-use or utilisation of assets made by others. To allow myself to not be unlawful I will ensure that all assets gained are not copyrighted or otherwise in any way that would affect my software in a non-commercial form. At the present time it is unlikely that this software will ever be released to the public or to a client, but if it should it will be important to know which assets are copyrighted or otherwise lawfully unusable in my project so that these can be dealt with before a commercial or educational release.

 

One way of dealing with this would be to create my own assets whcih would be a good direction to go in as I get to create my assets how I want them. This would be very time consiming however and is unlikely to be the main way that I acquire assets for the project. I will instead be relying upon copyright free assets that will be lawfully useable within my project. I will make sure that any assets that are gained from sources outside of the Unity Asset Store are copyright free. The reason I will not have to check assets founf on the Unity Asset Store is because they are automatically copyright free as they have been sold (even if they are free) to me the consumer as an asset that I am able to use within any of my projects, these assets may still be copyrighted in a way that will not allow them to be used have they not been acquired through the store and will not allow me to copyright them.

 

  1. Development

Development is taking place within a Unity project to make use of the built in features of Unity, such as the Editor feature that allows me to add on to a Unity Editor tab, as well as it being a great IDE for a small scale project that deals with 3D models.

 

6.1 Increment 1

 

This part of the development was focused on the terrain generation within the solution. Since this was the start of development I also decided to include the Unity Editor form in this Increment as this needed to be created to allow the choices of users.

 

From researching online at how I would roughly go about creating procedurally generated terrain I found a tutorial made by a Youtuber called Sebastian Lague. This Youtuber had also done some tutorials specifically for Unity themselves. When going through the videos he had done I decided that since my project was so ambitious it would be good to utilise the code he has done to get a base for how I am generating my terrain. This has informed the final version of the PID found at Appendix D. His tutorials were very extensive covering many different areas of the terrain generation with most of them being some quite advanced techniques that I would otherwise likely have no idea about. To explain exactly what I have taken from the code Sebastian Lague has developed I will be breaking down each of his tutorial videos that he has done and comment on what exactly I have taken from each of them.

 

6.1.1 E01 Introduction

This video looks into some explanations of noise, octaves, amplitude, frequency, persistence and lacunarity. This was useful to understand what exactly would be happening when applying these to the generation.

 

6.1.2 E02 Noise Map

This video looked into returning a noise map and displaying it on a plane that was added to a Unity Scene. This video covers a total of four different scripts, which, generate a noise map, generate a map using the previously mentioned noise map, displays the map and allows additions to the inspector tab of the map generator also known as an Editor. I used all of the code found in this video which could easily have been created by me as this is some simple code.

 

6.1.3 E03 Octaves

This

 

After implementing this code from Sebastian Lague I started to work on the inspector form attributes that the users could change to get their suited outcome.

 

6.2 Increment 2

 

  1. User Testing

7.1 Testing

 

User testing is an important part of any serious project when it comes to software development for many reasons. These reasons can vary depending on the targeted user base and the type of software in development. As my own project is aimed at developers it is assumed that users will understand how to use a computer in an excellent capacity, therefore not needing to test the complexity of the software on users new to computers.

 

To test the usability and validity of the features incorporated within the solution, user testing was applied. For this solution I decided it would be best to collect the information first hand to reach a higher level of understanding with the testers and ask questions more relevant to their experiences. To make each session of these user tests fair, I chose to use the same three people in all instances. In my opinion this was good for a few of reasons, this allowed for quick, easy access to the same three people, as I live with them, this allowed me to ensure that each tester understood the concepts of programming and UX, etc, and also kept each session focused on particular areas of development i.e. Increment 1, Increment 2. This does mean however, that I had no way to gauge how well a new person to the program would interact with the solution, this also meant that things the testers missed were less likely to be picked up on.

 

7.2 Terrain – User Testing

 

This User Testing session was conducted after Increment 1 was mostly finished. That is to say that the majority of the core features were implemented for Increment 1. Increment 1 consisted of the terrain generation features and at this point of development was able to produce terrain that was randomly generated and could be influenced majorly by the users choices.

 

For this session I had three testers to test each feature of the form that changes the way the environment is generated or the outcome of the generation. The main goal was to see if the testers could understand what each of the attributes did before they changed the values and whether the outcome was what they expected. For the most part the testers seemed to understand what was happening although they may not get the result they expected or may not know what one or more of the attributes was alluding to.

 

Some of the good comments made from the testers included;

 

  • Terrain Type in Options seems very useful for quick presets
  • Liked the change in colours available to the user
  • UI easy to understand for Unity users
  • Understands the need for one main overarching menu, and why this would have a secondary one – likes the fact that if one changes the other does as well, less confusing
  • Likes the automatic update on a change as it shows what has changed instantly

 

From these comments we can see that the overall design of the form is in the right place and that the features are useful whilst using the tool.

 

Some of the criticisms from the testers included;

 

  • Finds it hard to understand what each attribute will do
  • Some attributes seem not useful or don’t do anything
  • Why does the flat terrain type still have mountains and snow
  • No explanation of what each attribute is for/or does at first glance, some experimentation needed for the user to understand, make it a bit more intuitive

 

From these comments we can see that each attribute in the form doesn’t explain itself properly with it’s title this was an obvious oversight and something that should be fixed for future testing sessions. We can also see that there appears to be some issues with presets not fully doing exactly what the testers thought they should encompass. This was still in progress and should be fixed for future testing sessions.

 

In one of the testing sessions one tester changed the value of the octaves attribute over 78 which immediately froze my computer. This is an obvious bug that needs fixing as this was done on a high-end computer, therefore I have introduced a cap of 20 as this is when the mesh of the terrain begins to break and look featureless, this should also stop the crashes. Another change implemented so far is that each attribute now has an explanation when the user hovers over the option, fully detailing what that attribute will change in the next generation.

 

This testing session was a great success with the testers pointing out good areas of my project, great criticisms that I can take away and work on and exposed a bug within my solution. This overall will make the project more polished and usable by people in the future. There were a few comments made by the testers about the use of the tool right now in from a users standpoint is almost useless, which was expected as the tool is in no way at a stage where it could be deployed for its intended use.

 

7.3 Environment – User Testing

 

  1. Deliverables Presented

  8.1 Deliverables

 

  • Proposal
  • Project Initiation Document x3
  • User Story Board
  • Roadmap
  • User Testing consent form
  • User Testing x2
  • User Requirements Analysis Research
  • Story and Video-Game Conceptualisation Tools Research
  • Procedural Generation Techniques Research
  • Conceptualisation Tool Prototype (unfinished as per PID)

 

  8.2 Features Delivered

 

  • Perlin noise terrain Generation with height differentiation, textures and colour
  • Reversed Cellular Automata and Marching Squares without height differentiation, textures and colour
  • Housing areas

 

  1. Project Evaluations

  9.1 Objective Evaluations

 

Due to the nature of the project it was unlikely that I would have a finished solution within the time limit given for the project. With the aim of the project to have a prototype tool that is capable of generating an environment within users choices the project delivers somewhat with some obvious lack of choices in certain areas detailed within the PID which can be found at Appendix D.

 

The initial project objectives have been met in at least some capacity, these are listed below;

 

  1. To analyse existing tools that aid in conceptualisation of video-game concepts

An analysis of similar existing tools was done and can be found at Appendix G. The features of each tool was noted and evaluated by me based upon how suitable they were and the options available to users. This research gave me insight on some features to include and some to not include within my solution.

 

  1. To analyse the user requirements for the video-game visualisation tool in line with the business needs and objectives set out.

An analysis of User Requirements was done and can be found at Appendix E.

 

  1. To research and analyse possible procedural generation techniques that could be used in the solution.

An analysis of procedural generation techniques was done and can be found at Appendix F.

 

  1. To conduct UX testing to make the solution more user friendly.

UX testing has been conducted to direct the design of the UI and suitability of the features within the project. The two different UX/User Testing sessions can be found at Appendix K and L.

 

  1. To provide an accessible main UI that can be easily understood and used for the basic purpose of the tool.

The main UI has been created and adjusted based upon feedback from UX/User Testing sessions and as such seems to be accessible to the user. With game developers being the target audience it is unlikely that they wouldn’t know how to use a Unity Inspector tab anyway, however descriptive labels have been given to each attribute in the inspector to ensure understanding.

 

  1. To provide more in depth customisation options (than presets) that affect the outcome of the generation.

A secondary UI has been created on another object within the scene that will allow users more options than the standard options and presets that are currently within the main UI. All changes on the main UI are also made on the secondary UI to make this less confusing for users.

 

  1. To provide more in depth customisation options to the environment after the generation has happened.

Within the UI users are able to keep what they have generated by ensuring that “Use a random seed” is turned off. This therefore allows users to change individual parts of their generation at any time whilst keeping everything else about the generation the same. This can be taken the other way where they have this option turned on that allows for a random generation every single time whilst still being within the scope of what they asked for.

 

  1. To create scripts that are capable of terrain generation using Cellular automata and/or Perlin Noise to complement them.

Both of these techniques have been implemented to allow for terrain generation although the Perlin Noise technique has a lot more options and features available to it. Perlin Noise terrain has access to textures, colours, height maps and more that allow the terrain to feel like terrain and be unique based upon the users broad choices. The Cellular Automata technique however is underdeveloped at the moment, and whilst it can still generate a flat piece of organically shaped land it does not have any of the features that the Perlin Noise technique does. This could be remedied by adding these features within this method of terrain generation, however, I did not have time to do this as Increment 1 took much longer to develop than anticipated.

 

  1. To create scripts that are capable of seamlessly adding environmental and architectural objects into the generated environment in a way that looks believable.

This objective has not been met in its entirety as the addition of architectural objects into the environment is currently not in a believable state however they can be added to the scene. This comes down to the fiddliness of adding the architectural objects to the scene in a way that can be dynamic, allowing the users choice, and within a pattern that allows the objects to look normal (i.e. in this case man-made). The vegetation additions to the scene can be seen as believable.

 

  1. To create scripts that  are capable of adding detail to the already generated environment.

Whilst this objective was supposed to be indicative of Increment 3 being completed (please see PID V2 at Appendix C) this has since been changed to dealing with detail within the terrain and environment. It could be argued that this has been met albeit it not very well. With the way the tool works it is possible to add different detail to the scene that has already been generated without changing anything else within the scene. This is limited to the features and assets integrated within the project at the current time.

 

  1. To create documentation that informs the users on how to use the solution.

Documentation has been created and can be seen at Appendix M. This document details the use of the program and how a user may go about using the features within the tool.

 

  1. To develop a technology or deployment solution that allows for video-game concepts to be visualised based on broad inputs from the user that, characterise the theme of the concept (i.e. art style: realistic; theme: Japan, Samurai era, etc.) or/and characterise the terrain and environment.

Whilst the first part of this objective has not been met (note or) the other part of the objective has. The user is able to give broad inputs which will change the output from the generation giving particular characteristics within certain inputs.

 

  9.2 Project Post Mortem

Too much time spent on finalising project details and direction as well as research pieces for the direction of the new project.

 

  1. Conclusions

  10.1 Lessons Learnt

  10.2 Further Development

  10.3 Final Thoughts

 

  1. References

 

  1. Appendices

 

Appendix A

 

PRCO304 – Alternative Experience: Cuban Missile Disaster – Proposal

 

Key Words/Phrases

Story Driven Alternative Experience | 3D Modelling | Level/Environment Design | Sound design | 3D Animation | Potential for VR

 

Possibility of adding 3D Animation and VR Compatibility: 3D animation of humans could be avoided with additions to the story on why you don’t get to see Khrushchev or anyone else, VR will only be added if it adds to the game and doesn’t subtract from the experience – This looks likely as there are no combat mechanics and the game is essentially a walking simulator.

 

Final Deliverable

The final deliverable will be, roughly, a 15-30 minute game that takes users on an interesting journey through an alternative timeline involving the Cuban Missile Crisis. Documentation will also be included detailing research, planning, creation, testing, improvements, reflection and self-evaluation.

 

Initial Brief (subject to change)

The alternate timeline will involve America and Russia exchanging nuclear missile fire in 1962, October. With few nukes going off before a ceasefire is called and talks begin. The character will play the President of the USA. Gameplay scenes will involve;

 

(cutscene) The game opens as the Russian First Secretary Nikita Khrushchev and the PoTUS have an argument (only audio). The graphics will show the staging and firing of nuclear missiles and the impact of them. The camera will pan out showing the Earth and the explosions of the nuclear warheads in the USA and Russia.

 

A car journey through a serene beautiful part of American countryside that as the car moves slowly becomes more destroyed as you make your way towards the outskirts of one of the nuclear missile impact sites (this will be where the President’s parents lived before being obliterated).

 

A look through the destroyed remnants of the town the President’s family lived in.

 

A look through your parents house strangely in pristine condition as all buildings around you have fallen apart into piles of rubble. Interactable objects allow the user to get some insight (likely to be audio only: this could be expanded if time permits to add the visual gameplay to this as well) into the Presidents upbringing and journey to becoming the President. After the player is finished exploring they will be prompted to leave and find that the house was just a pile of rubble after all.

 

The Russian First Secretary Nikita Khrushchev and the PoTUS have negotiation talks. The player will have dialogue options that will have to satisfy Khrushchev. If the player fails there will be an all out war between America and Russia. The choices in this scene will be involved ones, on how Khrushchev thinks of you, are you endangering his people, are you polite, etc.

 

This scene will pertain to the outcome of the negotiation talks (previous scene). If the player fails then there will be a cutscene of nuclear devastation. If the player succeeds and does not sacrifice too much intelligence or strategic resources (like placements of nuclear missiles in Italy and Turkey) then there will be a cutscene showing the president paraded down the street to the cheer of a massive crowd. If the player succeeds but sacrifices too much there will be an angry crowd trying to attack the President. The latter two of these might be first person.

 

There will likely be no human models animated in this game so that there is a higher focus on the story elements and overall asset quality.

 

Approach

Game Editor – Unity

Script Editor – Visual Studio Community 2015 (C#)

3D Modelling Editor – 3DS Max

3D Animation Editor – Unity

Texture Creation Editor – Adobe Photoshop

Time Management Tools – Trello w/ Elegantt | ProductPlan (Roadmap) | Coggle (Brainstorming)

Methodology – Scrumban: Give myself targets to achieve, if I smash them continue with work on other elements of the game, if not reflect at why this happened, learn, adapt targets. If I get stuck on a non-essential game element drop it until able to complete.

 

Requirements

If VR is looking likely I will be looking to buy my own HTC Vive so I can ALWAYS test the game when needed as soon as possible. This might however be added towards the end, after the core game is completed and a purchase would not be needed.

 

Learning

In preparation for this project I will be looking to learn;

 

Creating “bones”/”joints” for human models

3D Animation techniques and preparation on human models

Better my sound development skills

Creating high quality cutscenes in Unity (potentially with VR compatibility – i.e head turning)

Concepts behind good level/environment design

Realistic texture creation

Creating a crowd/illusion of a crowd with acceptable performance

Research household items of the 1960’s i.e. a family isn’t going to have a flat screen tv

 

Risks

I feel that there are few risks with this project as many aspects of the game can be adapted to suit my skills if they are not up to scratch at the time of creation. The main risk therefore is that I end up doing too little as I am not able to add any substantial improvements over what was delivered in Stage 2, AINT 253. No Assets or other elements will be taken from the previously submitted project for AINT 253.

 

One other risk is using the likenesses of real people. Although Nikita Khrushchev is not alive I still will have to be careful and may have to refer to him as Russian First Secretary.

 

I will have to be careful when it comes to designing the inside and outside environments as households had different items around the house in the 1960’s, streetlights looked different, etc.

 

Finally, if I don’t end up involving animated human models the game may seem a bit devoid of other life. This may make the game seem not as impressive as I would otherwise like it to be and end up taking away from it as I adapt the scenes to it. For example it might not be engaging for the user to be speaking to Khrushchev on the phone or the driver through an intercom.

 

Appendix B

 

Project Initiation Document V1

 

  1. Introduction

In the past few years video games have become increasingly more complex, time consuming and costly to create with the demands of the end-users becoming increasingly more difficult to achieve whilst maintaining a profitable business. As a result of this we have seen a huge surge of “indie” developers that have started to create shorter and less complex games that usually offer unique twists to already defined game genres.

 

Short story driven experiences have become increasingly more popular with the rise of Telltale Games and other lesser known developers like The Odd Gentlemen and SkyGoblin. With the rise of these indie developers their ideas have become more convoluted and frankly not as good as they increase staff to meet the demands of the end-users, ending up with too much scope on each project. This is indicative after the recent shortcomings of the games created by Telltale Games that have had plot holes, some poor animations and many visual and gameplay bugs.

 

Players expectations have also risen in regards to the players consequences to their choices. This is obviously quite limited due to development time and costs to the developer but the game portrays every action as a choice, which I feel is it’s major flaw. More of the story should be just that, story, and should not give the player choices with how their character responds. This would give the player a more direct and focused story, whilst still allowing the player to inquire on certain topics to get more information about backstory and side-plots, etc. This would then limit the amount of development time needed to develop scenarios based upon the players choices and make the player feel as if all the choices they made had an impact.

 

Essentially, the story elements of the game should be more self-driven and directed rather than involving player input, similar to make your own adventure books. These books have set choices like the story-telling genre does, but each choice has a direct and immediate impact upon the story, making the reader feel more in control of their characters future. With the gamification of this style of books, player input has inevitably been added to give more engaging gameplay than some rolling cutscenes and a couple of choices, which helps to give the player objectives and a sense of investment in the characters and world.

 

In a short timeframe I will be attempting to create a 3D First Person Story-Driven prototype that looks into an alternate history of the Cuban Missile Crisis that took place in 1962. This will include  the creation of all assets apart from potentially human models, that may or may not be implemented in the prototype. I will focus on telling this story through voiced lines and enriching this with a detailed environment that sets the theme and tone of the story. Player choice will also be added to the game that helps to define certain outcomes and consequences the player will face based upon their actions. This will however, be limited to certain aspects of the story that the player should be able to define themselves, i.e. they shouldn’t need to have a choice between saying “hello” to a character or saying “how are you”, it should be something that has a much more widespread/direct consequence, like, is your character going to die?

 

  1. Motivation

During my second year of University I attempted to create a similar, considerably shorter experience for a 20 credit module and I ended up with great results for it, both academically and content-wise. I thoroughly enjoyed the process involved in creating this interactive experience but I was somewhat annoyed that I didn’t have time to expand upon what I had created.

 

Before starting this course I had always wanted to become an environment/level designer and when starting the module described above, I knew that this was what I enjoyed doing, what I wanted to do after graduating.

 

Now that I have had the experience to create a small interactive game with story elements I am more excited and driven to create a larger scale prototype, with clearer ideas and a more detailed and involving story that can be altered by the users input, improving upon the formula that has given new life to the genre, but is quickly stagnating.

 

  1. Project objectives
  1. To analyse existing detailed environments within games and understand how to recreate this within set theme in a way that adds to the story
  2. To create a short story-driven experience that is engaging, coherent and comprehensible
  3. To give users choices within the game that will affect the outcome of the story in a logical way
  4. To create and implement sound in a way that can evoke emotions or response from a user/player
  5. To create and implement 3D models in a form that is meaningful and understandable
  6. To create and implement 3D animation that helps to enrich and develop the story
  7. To implement player choices into the game that will have a direct consequence on the outcomes, whilst avoiding those that don’t, unless they offer extra story detail or/and an explicit emotional response

 

  1. Initial scope
  1. Research will be completed that looks into several detailed environments and a short document that records any findings will be written to ensure understanding of why elements in the environment help to purvey story or otherwise enrich it.
  2. Storyboarding will be completed to ensure a tangible story that will be shown to several “testers” who will then be asked to relay their understanding of the story. The results will be documented both in audio and written form. This will ensure that people are able to understand the story concepts and the story is therefore comprehensible. Furthermore, the game will be tested throughout development to ensure that users feel engaged and still understand the story elements of the game, this will again be documented in audio and written forms.
  3. Throughout the testing phases users will be prompted to and have a chance to comment on the different assets in the game and give their opinion on how they affected the game, whether negatively or positively, documented in audio and written forms. Users will also be prompted to fill out an anonymous form that will allow them to give more truthful answers on each aspect talked about.
  4. Simple movement and interaction mechanics will be implemented to allow the player to progress through the game.
  5. A speech selection mechanic will be implemented to allow for player choice and with the help of Unity Scenes I will be able to change the outcome of the story.
  6. Some less important story elements may be told through environmental design and/or optional content that does not need to be interacted with to progress or understand the story, giving users more freedom and choice within the game as well as more reason to explore.

 

  1. Method of approach

Development will consist of many aspects that may intertwine at some points but the bulk of each aspect should be developed and completed roughly at the same time, i.e. most 3D models will be completed at the start of the project, however additions may need to be added later on in development like a chair that is needed for an animation

 

The development of my game will follow a logical approach which will first need the models (as the game will not be script heavy) and textures. I will then assemble the assets into Unity scenes and research into and implement environment design. I will then implement the player mechanics like movement, interaction and speech selection mechanics. This will be followed by the creation of the main 3D animations in their separate scenes as well as the consequence animations. Once the game is in a playable state I will then focus on creating the sound assets that will enhance the experience. Finally, I will polish up any elements that are not as good as they should be and ensure that I have created detailed environments throughout the playable game.

 

I have considered and decided upon the programs that I will use to create this project and they are as follows;

 

Game Editor – Unity

Script Editor – Visual Studio Community 2015 (C#)

3D Modelling Editor – 3DS Max

3D Animation Editor – Unity/3DS Max

Texture Creation Editor – Adobe Photoshop

Sound Creation Tools – Audacity, NanoStudio and Foley techniques

Sound Editing Tools – Audacity

Time Management Tools – Trello w/ Elegantt | Undecided roadmap app | Coggle (Brainstorming)

Methodology – Scrumban: Give myself targets to achieve, if I smash them continue with work on other elements of the game, if not reflect at why this happened, learn and adapt targets. If I get stuck on a non-essential game element drop it until able to recommit.

 

  1. Initial project plan

 

6.1. Control plan

 

I will be adhering to the PRINCE2 control techniques listed;

 

Highlight reports as dictated by the PRCO304 module

End-stage reports

Review meetings with the project supervisor as stated by the PRCO304 module: additional meetings may be held as needed

Risk management (see section 7), communication plan (see section 6.2), quality plan (see section 8) and exception reports when and if necessary

 

6.2. Communication plan

 

Review meetings will take place as stated by the PRCO304 module and additional meetings may be held if and when needed with the project supervisor.

 

  1. Initial risk list
Risk Management Strategy
Schedule Overrun Time has been added into the plan to allow for overrun of schedule as it is expected to some degree. Highlight reports and review meetings each week will provide monitoring of the schedule. An exception plan will be developed, and approved by the project supervisor, in the event of more than 1 week’s slippage.
Difficulty developing Lighting System This is a non-essential part of the project and thus can be dropped if it is felt that it will be to difficult or timely to implement.
Technology Failure Version Control will be implemented in the form of GitHub to ensure that a recent copy of the project is kept at all times, and the versions that came before the most recent. In the event of my home computer or Uni computers failing or otherwise becoming unusable during the project, I have a laptop that I can use, already set up to deal with this scenario.
Contradicting User reports In some cases some users may have different opinions to others on some aspects of the game, during testing. This will be dealt with in a logical manner and feedback will be asked for from the project supervisor along with members of the CGD team. This will allow for a clear picture on why they could have thought this or whether it has been misinterpreted or written wrongly.
Corrupt audio recordings of testing There is a small possibility that the recordings of the user’s feedback upon testing may become corrupt. For this reason I will be documenting their feedback in a written form at the same time.
Testers not wishing to be recorded Some users may not want to be recorded as is their right as a tester. In this case I will only have a written form of their feedback, which is fine, although I may miss some feedback whilst trying to write it down.

 

  1. Quality plan
Quality Check Strategy
Requirements Requirements will be checked to ensure that they are correct, complete, achievable and demonstrable. The requirements will also document required product quality criteria (e.g., usability). Prototyping, user interviews/testing and walk-through will be employed.
UX User testing will be employed and feedback taken to help improve features and design of the game towards a more user friendly experience
Story Content User testing will be employed to ensure that testers understand the story, can follow it easily and feel engaged throughout
Environment Design Research will be conducted to attempt to learn how a digital environment is set up akin to a real life environment. User testing will also be employed to ensure that testers feel like the environments are real places and that extra story elements can be gleaned through details in the environment
  1. Legal, social, ethical and/or professional issues
Issue Description
Legal As I am re-enacting the Cuban missile crisis in an alternate history it is important that I do not use any likenesses of people that are protected from this usage. As I am sure to only use the likenesses of two people in power over the USA and Russia, these should be in the public domain and freely available to use the likenesses of. However, I will try to first create the experience without using their likenesses to protect from any form of legal action, now or in the future.
Ethical As I will be conducting User tests I will have to ensure that I provide these testers with consent forms which must be filled out prior to testing and ensure that they understand that they are free to withdraw from testing at any time should they need to leave or otherwise want to leave. I will also have to stress to them that although I want to record the audio of each testing session they should not feel obliged to allow me to record and can tell me that they do not wish to be recorded. If this is the case I will ensure that I do not record the testing session. User testing has already been approved for this module should I follow the rules outlined by the University of Plymouth, which I intend to do and which the description of this paragraph should satisfy.

 

Appendix C

 

Project Initiation Document V2

 

  1. Introduction

In the school of computing, at least at the University of Plymouth, there are plenty of opportunities to create games whether that is during game jams, free time or as part of a chosen/set module. One of the many challenges of creating a game in this area though is that many of these students are solely focused on enhancing their coding and software development abilities. When designing and creating a game of any kind, many students lack visualisation of their intended game. This is usually due to insufficient design processes and experience in the art side of game development, whether that is creating graphics, sound, animations or all of the aforementioned.

 

The same could also be said about small teams or individuals in this area that are looking to acquire funding from sites like kickstarter or by some external investor that seems interested. They may lack the required developers that have the skills to create the more visual elements of the game and no budget or resources to allow for learning in this area until funding is acquired. It would be important then to acquire this funding, which could be more achievable with a visual representation of what the game would/could look like.

 

  1. Business Case

 

2.1 Business Need

 

Some teams or individuals in the games development area are lacking in art skills of some form that are required to create an engaging game. All of these teams or individuals will most definitely have to pitch their idea to others for some reason or another, whether this is for user testing purposes, to acquire funding of some kind or to pitch to the team and/or boss/investor/s. This can be a hard task to successfully do when there is no visual representation of what the game would/could look like when finished as there is no proof of well structured and thought-out planning of the project. As a result this could lead to misinformed user tests, insufficient funding or conceptualisation issues within the team. All of these could ultimately result in the demise of the project and indeed the teams/individuals dissolvement/involvement in the video games industry. To help with this issue I will be developing a solution that will be able to generate a rough visual representation of the users video-game concept.

 

2.2 Business Objectives

 

To allow for teams/individuals to create a visual representation of their video-game concept in a way that;

 

  1. Aides prior visualisation concepts
  2. Aides teams/individuals with no/low artist staff with concept prototyping
  3. Creates a rough estimation of what the game should look like
  4. Allows teams/individuals to give broad inputs to affect the end results
  5. Creates varying visual representations that should remain thematically the same even if the broad inputs were to remain the same
  6. Allows for different thematic visual representations of different inputs from the user

 

  1. Project Objectives

 

  1. To analyse existing tools that aid in conceptualisation of video-game concepts
  2. To analyse the user requirements for the video-game visualisation tool in line with the business needs and objectives set out
  3. To research and analyse possible procedural generation techniques that could be used in the solution
  4. To develop a technology or deployment solution that allows for video-game concepts to be visualised based on broad inputs from the user that characterise the theme of the concept (i.e. art style: realistic; theme: Japan, Samurai era, etc.)
  5. To conduct UX testing to make the solution more user friendly
  6. To create documentation that informs users on how to use the solution

 

  1. Initial Scope

 

  1. Existing video-game conceptualisation tools will be researched and analysed to discover what allows them to conceptualise aspects of the video-game and to inform the development of the solution.

 

  1. User requirements will be set out using a user stories map and, potentially, interviews with teams/individuals lacking in art staff/skills.

 

  1. Procedural generation techniques will be researched and analysed to inform the design of the solution.

 

  1. Functionality should include a form structure that allows users to give broad inputs on the design and thematic aspects of the scene which will affect the procedural generation of the terrain, environment and detail within the environment. Considering using seeds to allow for repeatable results.

 

  1. User testing will be conducted, and documented, on the solution to inform the design of the solution’s user interface

 

  1. After the solutions’ completion or finalisation, documentation will be created to inform users on how they can use the solution and what benefits there are to utilising this tool

 

  1. The proposed solution will allow users to define their video-game concept through set attributes (e.g. art style: realistic or cartoon-like)which will in turn create a visual representation of their concept.

 

  1. Method of Approach

 

The development of the solution will employ an incremental approach, with three increments focusing on (i) terrain generation (generation of the terrain: hilly, mountainous, flat); (ii) environment generation (generation of the environment: vegetation, architecture, potentially bodies of water); (iii) detail generation (generation of the everyday objects and other objects around the scene: food, lampposts, power-lines, potentially animals and people).

 

I have considered possible technologies that would be used throughout this project, although these are subject to change;

 

Unity might be used to develop the solution in c#, this means I would use Visual Studio for scripting purposes.

 

Assets for this project, like trees, etc., will be found, likely from the Unity asset store or other sources which will be checked for copyright and legal restrictions before being used. The authors of these assets will be documented and given credit. Some assets may be made by me in a relevant program like 3DS Max, Adobe Photoshop or Unity.

 

Time Management Tools – Trello w/ Elegantt | Undecided roadmap app | Coggle (Brainstorming)

Methodology – Scrumban: Give myself targets to achieve, if I smash them continue with work on other elements of the game, if not reflect at why this happened, learn and adapt targets. If I get stuck on a non-essential game element drop it until able to recommit.

 

  1. Initial Project Plan

 

Stage Expected Start Date Expected Completion Date Outcomes
Analysis of video-game conceptualisation tools 05/02/18 11/02/18 Documentation on different aspects of these tools that help to conceptualise the video-game and suggestions of user input fields (e.g. art style)
Analysis of user requirements 05/02/18 11/02/18 Interviews completed and analysed, documented in a user stories map
Research and analysis of procedural generation techniques 12/02/18 18/02/18 Research undertaken into procedural generation techniques and the analysis and experimentation of/with these techniques to show how successful these techniques could be with my solution
Increment 1 19/02/18 04/03/18 Acquiring/creating terrain assets.

Creating user input fields affect the procedural generation of the terrain

Increment 2 05/03/18 25/03/18 Acquiring/creating environment assets.

Creating user input fields affect the procedural generation of the environment

Increment 3 26/03/18 22/04/18 Acquiring/creating detail assets.

Creating user input fields affect the procedural generation of the detail

User testing 23/04/18 27/04/18 Conduct, document and analyse user tests to inform solution design. Make any changes necessary based upon feedback
Instructions guide to solution 28/04/18 28/04/18 Instructions on how to use the solution effectively
Final report and compilation of deliverables 29/05/18 15/05/18 Finished final version of report and compiled all deliverables, submitting them to the relevant places as outlined in the Assignment Brief

 

6.1 Control Plan

 

I will be adhering to the PRINCE2 control techniques listed;

 

Highlight reports as dictated by the PRCO304 module

End-stage reports

Review meetings with the project supervisor as stated by the PRCO304 module: additional meetings may be held as needed

Risk management (see section 7), communication plan (see section 6.2), quality plan (see section 8) and exception reports when and if necessary

 

6.2 Communication Plan

 

Review meetings will take place as stated by the PRCO304 module and additional meetings may be held if and when needed with the project supervisor.

 

  1. Initial Risk List

 

Risk Management Strategy
Schedule Overrun Highlight reports and review meetings will allow for me and my supervisor to monitor the schedule closely each week. Should I slip on the workload by more than one week then an exception plan will be developed and approved by the project supervisor.
Difficulty adapting procedural generation techniques effectively During the research and analysis phase of procedural generation techniques I will be conducting some prototyping to check for suitability and adaptability of the techniques.
Technology Failure Version Control will be implemented in the form of GitHub to ensure that a recent copy of the project is kept at all times, and the versions that came before the most recent. In the event of my home computer or Uni computers failing or otherwise becoming unusable during the project, I have a laptop that I can use, already set up to deal with this scenario. I will also be storing the most recent copy of the project on a usb, my computer and my laptop to deal with internet lossage at any stage.
Contradicting User Reports In some cases some users may have different opinions to others on some aspects of the solution, during testing. This will be dealt with in a logical manner and feedback will be asked for from several family members, friends and from people in the area of computing for a more wide variety of sources. This will allow for a clear picture on why they could have thought this or whether it has been misinterpreted or written wrongly.
Corrupt audio files of recorded user testing interviews There is a small possibility that the recordings of the user’s feedback upon testing may become corrupt. For this reason I will be documenting their feedback in a written form at the same time.
Not able to find enough users to test my solution with As my target audience will be developers I believe that I will be aiming to get solely developers to test the solution (most likely only undergraduates). This however will be a busy time for them as they will have the same workload as me on their final projects. This could cause issue getting suitable testers and may mean getting testers not used to developing software. I will attempt to bargain with potential testers by offering to be a tester for them.
  1. Quality Plan

 

Quality Check Strategy
Requirements The requirements will be checked for correctness, achievability and demonstrability. Prototyping and user testing will be employed to check for suitability.
UX User testing will be employed and feedback taken to help improve features and design of the game towards a more user friendly experience. This will also be used to quality assure the final visuals from an end user perspective.

 

  1. Legal, Social, Ethical and/or Professional Issues

 

Issue Strategy
Ethical As I will be conducting user tests I will have to ensure that I provide these testers with consent forms which must be filled out prior to testing and ensure that they understand that they are free to withdraw from testing at any time should they need to leave or otherwise want to leave. Participants have the option not to be recorded. If this is the case I will ensure that I do not record the testing session. User testing has already been approved for this module should I follow the rules outlined by the University of Plymouth, which I intend to do and which the description of this paragraph should satisfy.
Legal As I will be utilising other people’s assets in this project I will have to ensure that these assets are copyright and trademark free to ensure that the solution will be freely available for others to use. Also, as part of creating my own assets I will likely have to cut content made in 3DS Max due to licensing issues if I release the content for monetary gain, although this is not what I am intending to do with this solution.

 

Appendix D

 

Project Initiation Document (Updated) V3

 

  1. Introduction

In the school of computing, at least at the University of Plymouth, there are plenty of opportunities to create games whether that is during game jams, free time or as part of a chosen/set module. One of the many challenges of creating a game in this area though is that many of these students are solely focused on enhancing their coding and software development abilities. When designing and creating a game of any kind, many students lack visualisation of their intended game. This is usually due to insufficient design processes and experience in the art side of game development, whether that is creating graphics, sound, animations or all of the aforementioned.

 

The same could also be said about small teams or individuals in this area that are looking to acquire funding from sites like kickstarter or by some external investor that seems interested. They may lack the required skill sets to create the more visual elements of the game and no budget or resources to allow for learning in this area until funding is acquired. It would be important then to acquire this funding, which could be more achievable with a visual representation of what the game would/could look like.

 

  1. Business Case

 

2.1 Business Need

 

Some teams or individuals in the games development area are lacking in art skills of some form that are required to create an engaging game. All of these teams or individuals will most definitely have to pitch their idea to others for some reason or another, whether this is for user testing purposes, to acquire funding of some kind or to pitch to the team and/or boss/investor/s. This can be a hard task to successfully do when there is no visual representation of what the game would/could look like when finished as there is no proof of well structured and thought-out planning of the project. As a result this could lead to misinformed user tests, insufficient funding or conceptualisation issues within the team. All of these could ultimately result in the demise of the project and indeed the teams/individuals dissolvement/involvement in the video games industry. To help with this issue I will be developing a solution that will be able to generate a rough visual representation of the users video-game concept, that has enough depth to allow for experienced users to achieve more with the tool.

 

2.2 Business Objectives

 

To allow for teams/individuals to create a visual representation of their video-game concept in a way that;

 

  1. Aides prior visualisation concepts
  2. Aides teams/individuals with no/low artist staff with concept prototyping
  3. Creates a rough estimation of what the game should look like
  4. Allows teams/individuals to choose presets that represent the initial concepts of their game, to affect the outcomes
  5. Can create varying outcomes from the same presets with a virtual impossibility of getting the same result, unless you intend to (i.e. seeding)
  6. Allows for different thematic visual representations
  7. Allows users to directly alter the generation, after the generation has happened, by adding, removing or otherwise changing specific objects/object properties (i.e. a tree, a tree’s position, etc.)

 

  1. Project Objectives

 

  1. To analyse existing tools that aid in conceptualisation of video-game concepts
  2. To analyse the user requirements for the video-game visualisation tool in line with the business needs and objectives set out
  3. To research and analyse possible procedural generation techniques that could be used in the solution
  4. To conduct UX testing to make the solution more user friendly
  5. To provide an accessible main UI that can be easily understood and used for the basic purpose of the tool
  6. To provide more in depth customisation options (than presets) that affect the outcome of the generation
  7. To provide more in depth customisation to the environment after the generation has happened
  8. To create scripts that are capable of terrain generation using Cellular automata and/or Perlin Noise to complement them
  9. To create scripts that are capable of seamlessly adding environmental and architectural objects into the generated environment in a way that looks believable
  10. To create scripts that are capable of adding detail to the already generated environment
  11. To create documentation that informs users on how to use the solution
  12. To develop a technology or deployment solution that allows for video-game concepts to be visualised based on broad inputs from the user that, characterise the theme of the concept (i.e. art style: realistic; theme: Japan, Samurai era, etc.) or/and characterise the terrain and environment.

 

  1. Initial Scope

 

  1. UX testing will be carried out in stages for each Increment (see Section 6 Project Plan) with the findings being used to inform the design and ease of accessibility of the UI form.

 

  1. Secondary UI’s/Advanced options will be created to allow users more freedom and choice for the environment generation, allowing users to more clearly define their concepts.

 

  1. Most (if not all) objects within the scene that are generated will be customisable to some extent. This may be the ability to regenerate, remove, add, reposition or resize. The options available to each object will be dependant upon the object itself.

 

  1. Code created by Sebastian Lague will be used for both cellular automata and Perlin noise solutions. My contribution in this area will be reversing the cave-like effect found in the cellular automata solution to create an exterior landmass as opposed to an interior one. Also my contribution will include allowing these two solutions, for terrain generation, to operate in the same way to allow users to choose either or.

 

  1. Vegetation will be added from random starting points that are “suitable” and algorithms will be able to decide where the vegetation should be able to spread and grow to based upon imitations of/pretend wind and sun simulations. The height map will have to be altered in some form to allow for the architectural objects to be placed properly and look natural (in a man-made way). This should also follow the thematic choices the user has chosen (i.e. cartoony house if the user chose a cartoony art style).

 

  1. Items will be generated in the scene at specific points to add detail to the environment, which would be completely dependant upon what was in the scene and the thematic choices of the user. These items will be placed almost akin to what we would expect (e.g. we don’t expect a keyboard on a desk to be perfectly straight).

 

  1. Documentation will be developed to instruct users on how to use the tool in a basic manner as well as more advanced options at the users disposal. Opportunities will be taken to document this within the tool itself (i.e. when hovering over a property in a Unity inspector window, there should be some text that indicates what the property does).

 

  1. Accessible UI as well as sound (if rushed) functionality will allow users to quickly generate environmental concepts to save on development time and the requirement of art skill sets.

 

  1. Method of Approach

 

The development of the solution will employ an incremental approach, with three increments focusing on (i) terrain generation (generation of the terrain: hilly, mountainous, flat); (ii) environment generation (generation of the environment: vegetation, architecture, potentially bodies of water); (iii) detail generation (generation of the everyday objects and other objects around the scene: food, lampposts, power-lines, potentially animals and people).

 

I have researched possible technologies that would be used throughout this project, although these are subject to change;

 

Unity will be used to develop the solution in c#, this means I would use Visual Studio for scripting purposes.

 

Assets for this project, like trees, etc., will be found, likely from the Unity asset store or other sources which will be checked for copyright and legal restrictions before being used. The authors of these assets will be documented and given credit. Some assets may be made by me in a relevant program like 3DS Max, Adobe Photoshop or Unity.

 

Research into techniques for the development of Increment 1 – Terrain Generation have been very successful giving me two main approaches to the terrain generation. Both of these will likely be used to give the user a choice of a square tile of land (Perlin Noise) or a more organically shaped terrain (Cellular Automata). The main code of these two techniques has already been developed by Sebastian Lague, as such there seems to be no reason to “reinvent the wheel” so instead I will use this code. I will contribute to this by changing, removing or adding anything that I may seem necessary/unnecessary and finding a way to make these two techniques options for the user without breaking the functionality of the tool itself.

 

Research into techniques for use with Increment 2 and 3 have not gone well and have been very inconclusive due to many factors. Some approaches seem promising but very time consuming whereas others are just not appropriate for the task at hand. As such I will be using pseudo random number generators to randomly select positions for spawning detail and environmental objects (which will first be checked for suitability, if not a new position will be generated). With regards to Increment 2, the vegetation objects will have algorithms predicting the spread and growth of the vegetation (based upon a crude imitation of the wind and sun) which will affect the spread and growth of the vegetation. With the more architectural objects in Increment 2 the height map will need to be adjusted to create a more flat area for roads and houses, etc. whilst ensuring the rest of the map can be hilly, or otherwise how the user wanted it to be. With regards to Increment 3 there will be algorithms to spawn detail in the scene and will have adjustments to make so that objects are not out of place or strangely arranged (i.e. keyboard completely straight on a desk).

 

Time Management Tools – Trello | Roadmap | Coggle (Brainstorming)

Methodology – Scrumban: Give myself targets to achieve, if I smash them continue with work on other elements of the game, if not reflect at why this happened, learn and adapt targets. If I get stuck on a non-essential game element drop it until able to recommit.

 

  1. Initial Project Plan

 

Stage Expected Start Date Expected Completion Date Outcomes
Analysis of video-game conceptualisation tools 05/02/18 11/02/18 Documentation on different aspects of these tools that help to conceptualise the video-game and suggestions of user input fields (e.g. art style)
Analysis of user requirements 05/02/18 11/02/18 Interviews completed and analysed, documented in a user stories map
Research and analysis of procedural generation techniques 12/02/18 18/02/18 Research undertaken into procedural generation techniques and the analysis and experimentation of/with these techniques to show how successful these techniques could be with my solution
Increment 1 19/02/18 04/03/18 Acquiring/creating terrain assets.

Creating user input fields affect the procedural generation of the terrain

Increment 2 05/03/18 25/03/18 Acquiring/creating environment assets.

Creating user input fields affect the procedural generation of the environment

Increment 3 26/03/18 22/04/18 Acquiring/creating detail assets.

Creating user input fields affect the procedural generation of the detail

User testing 05/03/18

26/03/18

23/04/18

12/03/18

02/04/18

27/04/18

Conduct, document and analyse user tests to inform solution design. Make any changes necessary based upon feedback
Instructions guide to solution 28/04/18 28/04/18 Instructions on how to use the solution effectively
Final report and compilation of deliverables 29/05/18 15/05/18 Finished final version of report and compiled all deliverables, submitting them to the relevant places as outlined in the Assignment Brief

 

6.1 Control Plan

 

I will be adhering to the PRINCE2 control techniques listed;

 

Highlight reports as dictated by the PRCO304 module

End-stage reports

Review meetings with the project supervisor as stated by the PRCO304 module: additional meetings may be held as needed

Risk management (see section 7), communication plan (see section 6.2), quality plan (see section 8) and exception reports when and if necessary

 

6.2 Communication Plan

 

Review meetings will take place as stated by the PRCO304 module and additional meetings may be held if and when needed with the project supervisor.

 

  1. Initial Risk List

 

Risk Management Strategy
Schedule Overrun Highlight reports and review meetings will allow for me and my supervisor to monitor the schedule closely each week. Should I slip on the workload by more than one week then an exception plan will be developed and approved by the project supervisor.
Difficulty adapting procedural generation techniques effectively During the research and analysis phase of procedural generation techniques I will be conducting some prototyping to check for suitability and adaptability of the techniques.
Technology Failure Version Control will be implemented in the form of GitHub to ensure that a recent copy of the project is kept at all times, and the versions that came before the most recent. In the event of my home computer or Uni computers failing or otherwise becoming unusable during the project, I have a laptop that I can use, already set up to deal with this scenario. I will also be storing the most recent copy of the project on a usb, my computer and my laptop to deal with internet lossage at any stage.
Contradicting User Reports In some cases some users may have different opinions to others on some aspects of the solution, during testing. This will be dealt with in a logical manner and feedback will be asked for from several family members, friends and from people in the area of computing for a more wide variety of sources. This will allow for a clear picture on why they could have thought this or whether it has been misinterpreted or written wrongly.
Corrupt audio files of recorded user testing interviews There is a small possibility that the recordings of the user’s feedback upon testing may become corrupt. For this reason I will be documenting their feedback in a written form at the same time.
Not able to find enough users to test my solution with As my target audience will be developers I believe that I will be aiming to get solely developers to test the solution (most likely only undergraduates). This however will be a busy time for them as they will have the same workload as me on their final projects. This could cause issue getting suitable testers and may mean getting testers not used to developing software. I will attempt to bargain with potential testers by offering to be a tester for them.
  1. Quality Plan

 

Quality Check Strategy
Requirements The requirements will be checked for correctness, achievability and demonstrability. Prototyping and user testing will be employed to check for suitability.
UX User testing will be employed and feedback taken to help improve features and design of the game towards a more user friendly experience. This will also be used to quality assure the final visuals from an end user perspective.

 

  1. Legal, Social, Ethical and/or Professional Issues

 

Issue Strategy
Ethical As I will be conducting user tests I will have to ensure that I provide these testers with consent forms which must be filled out prior to testing and ensure that they understand that they are free to withdraw from testing at any time should they need to leave or otherwise want to leave. Participants have the option not to be recorded. If this is the case I will ensure that I do not record the testing session. User testing has already been approved for this module should I follow the rules outlined by the University of Plymouth, which I intend to do and which the description of this paragraph should satisfy.
Legal As I will be utilising other people’s assets in this project I will have to ensure that these assets are copyright and trademark free to ensure that the solution will be freely available for others to use. Also, as part of creating my own assets I will likely have to cut content made in 3DS Max due to licensing issues if I release the content for monetary gain, although this is not what I am intending to do with this solution.

 

Appendix E

 

User Requirements Analysis

 

Introduction

 

In this document I will be analysing the user requirements for the proposed tool described in the Project Initiation Document (PID). I have collated some questionnaire data from developers to support this and created a SWOT analysis, mind map and user stories to back this up with.

 

SWOT Analysis

 

I started by creating a SWOT analysis based on teams or devs that lacked an artist or art skills. The strengths suggest that the more mechanical and gameplay features become more pronounced and engaging as they are focused on much more heavily by the team/dev. This also allows for faster prototyping as the team/dev likely won’t worry about any art directions or creative aspects at this point.

 

Looking at the weaknesses we see how the art side of the project is majorly let down from the lack of skills within the team/of the dev. Through research there also appears to be insufficient tools and resources to help teams/devs through this situation as they will likely be lacking in the creative processes needed for these tasks. This ultimately will lead to a lack of artistic expression and direction which could be a massive detriment to the final game should the team/dev not seek to hire an artist or develop any skills in this area.

 

Mind Map

 

After completing the SWOT analysis I looked into mind mapping the user requirements for the tool that could aid this process. What could be implemented to aid a team or dev in this position and how could this be made an easy and approachable task to these developers that do not have creative processes or artistic skills.

 

I looked into four main categories which were Design, Requirements, Existing tools/resources and Features. This gave an all encompassing view of the tool I was creating as I was looking at what was available to these developers currently and what could be created to allow for these developers to have a faster and more intuitive experience/task.

 

The mind map allowed me to clearly list most of the form elements I think I will be including in the final tool for the developers to allow for a procedurally generated environment based upon the users/developers requests/inputs. This does not indicate the final intended goal as some information is still to be collected from questionnaire data and user testing feedback, research is also still to be undertaken on procedural techniques for suitability purposes which will likely inform further on strategies and fields that can be used.

 

User Stories

 

The next step was to collate the data from the SWOT analysis and the mind map and translate this into user stories to define what the users requirements are, what are their needs.

 

I decided to define three key areas which were features, design and end result, to demonstrate the users requirements. Within these key areas I defined the users requirements and essentially the scope of the project with a minimal viable project. I expanded upon the MVP with further user requirements that would enhance the use of and outcomes of the tool for the developers targeted.

 

This has helped me to identify where I needed to focus my efforts and development time on this tool.

 

Questionnaire

 

To expand my look into the needs of my targeted users I created a questionnaire aimed specifically towards them (this questionnaire can be viewed on my trello page at – https://trello.com/invite/b/zBI62FSw/1bc9703f72e2bb6a9b71b8474b3c2ac0/honours-project).

 

I decided to give this out to my classmates as well as the Plymouth game devs facebook group and got a total of 10 replies, at the time of writing. As a developer myself I thought it was best not to partake in my own questionnaire for fear of biased information towards user requirements only I saw, and of which I already know of.

 

The questions looked into several different areas within the development of games and specifically at certain scenarios developers might be in at the moment. Overall, they focused on the difficulty of creating a game with a lack of artistic talent (which would be dependent upon the developer themselves, which I had no control test group specifically to rely upon) as part of a team and as a solo developer. Most questions were yes and no answers with follow up questions pertaining to the how and why of the previous question.

 

As I had expected (due to the Plymouth University having a module based upon design processes, and most developers in Plymouth focusing on the art side, due to Plymouth College of Art) most developers who partook did not find it hard to visualise their own game ideas and concepts. However, what was interesting, is that 8 of the 10 respondents did find it hard to create art assets on solo projects with 5 of the 8 thinking that it limited their success.

 

Further in the questionnaire 9 of the 10 respondents agreed that tools could aid in visual conceptualisation of their games and projects. So it seems, from this dataset, that most all developers are thinking that tools can and could aid them in their concept design and planning tasks, which could mean they are open to trying out my tool once it is finished, considering it serves its intended purpose and functionality. This also suggests that these developers think they spend far too much time on the concepts of the games they are creating.

 

To expand my understanding of the areas that the developers would like control over, within the tools procedural generation that is, I asked more inquisitive questions asking for their opinions on what they thought could help their projects and why a tool like this would help them. The responses were as I thought they would be, the developers knew that this type of tool would save them a significant amount of time. Since most lacked the more artistic art skills necessary for game development they thought that the tool would help conceptualisation immeasurably. This in turn would allow for projects to be more focused and fleshed out and would help to secure funding and the sharing of the concepts involved within their games which 9 out of 10 respondents agreed with.

 

Finally, I asked the respondents what they would suggest adding into the tool that was mentioned in the questionnaire in terms of control points (i.e. art style, location) and why they think this should be added. The responses saw some generic options that were already listed, some gave actual options within those categories, whilst some gave some good input that will help in the final product. The developers seemed to agree that these options should be added as it makes the generated environment truly suitable, unique and targeted towards the users requirements, whilst also being entirely encompassing, not needing another tool in conjunction with my own.

 

This questionnaire was truly eye opening for me, as I understood from my own problems, through the University modules so far, I have always struggled to visually conceptualise my own games without doing some art work prior to conceptualising. To see these responses from other developers it reinforces what I have claimed to be a problem within the industry for solo developers and small teams. The questionnaire also gave me a lot of information regarding the users requirements and needs for this tool meaning I will be able to make a much more suitable and targeted tool.

 

Conclusions

 

Through the processes outlined in this document I have come to understand the users requirements much more and have a firmer grasp on the concepts behind the tool I will be creating because of this.

 

I understand now that there are developers out there like me who struggle on their projects, whether as part of a team or as a solo developer, due to insufficient conceptualisation tools/resources or artistic skills (creative processes or asset creation). These developers have given me some guidance on some areas they would like control over within the tool itself, giving me a clearer picture on the scope of the tool that would suit the users requirements. Most of these I already knew but it helps to back them up with a real dataset to inform and check the use case and requirements.

 

To get a clearer picture on the full list of control points within the tool I will be looking at using user test sessions to find a more in-depth description of exactly what should and shouldn’t be controlled by the user. I will also expand upon the dataset retrieved with user interviews for a more in depth and detailed answer from the users where I can push them to give a “correct” answer (correct regarding the question, they will fully understand the question). This will be mixed with my own personal judgement in terms of the project scope and the timeframe I have to implement these features.

 

As it appears that there is a lack of tools that meet the problem I have found, I will be looking to create a broad conceptualisation tool that aims to reduce the negative effects of this problem. I will first be focusing on developing a tool that will be able to generate an environment that is broadly/roughly what the user/s where pursuing. With secondary objectives to make the environment easily customisable, so the tool can act as more of a guideline with additions made by more experienced users. This will create a tool that has great accessibility but with depth that allows more experienced users to get a better result that is closer to what they intended.

 

The main basis for the tool is still for the rough conceptual design of the environment from user choices within the tool. These choices will be in the form of public variables in a Unity Inspector tab, which could be value based, tick boxes or drop boxes. After the user has decided on their choices they will have to hit a generate button (this may be automatically generated with each subsequent choice made but it is impossible to tell what problems this may cause at the moment) to generate the environment. This will then create the rough concept that the user was looking for whilst still in edit mode of Unity, allowing for changes to be made if necessary. More experienced users will then be able to use this template to create a much more focused concept, whilst the inexperienced users will have a much better environment design than they likely could have made themselves, in just a minuscule amount of development time.

 

Appendix F

 

Environmental Procedural Generation Techniques

 

Introduction

 

Procedural generation in games is often a misunderstood term for games that provide a significant amount of random content but this term could relate to any randomly generated element in the game. Usually however this term is only stamped on games that provide some sort of randomisation within the maps or characters within the game. Procedural generation in terms of a video games environment relates to a set of rules/algorithms that dictates a random map generation. These rules are used to create a more realistic/fun environment for gameplay and replayability purposes.

 

In this document I will be looking at different procedural generation techniques that relate specifically to the map generation as opposed to anything character related.

 

Cellular Automata & Marching squares

 

This technique seems to focus more on inclusive spaces including caves and the insides of buildings, however this could be reversed to be suitable for outside spaces like terrain generation. The technique doesn’t appear the best for this situation though and doesn’t seem suitable for use in positioning of the environment detail and detail within the scene.

 

This technique could however be reversed when creating the walls/boundaries of the explorable area. This would then create an exterior area as opposed to an interior one. This technique seems to create a more organically shaped environment and would be an excellent candidate for use within the tool.

 

Perlin Noise with Octaves, Lacunarity and Persistence

 

This procedural technique focuses on using Perlin noise to create a randomly generated terrain controlling the random factors with octaves, lacunarity and persistence. Octaves determine the amount of individual layers of the Perlin noise there are which allows a user to change the amount of difference in the map. Lacunarity allows for the control of increase in frequency within each octave, whilst the persistence allows for the control of decrease in amplitude within each octave. With no extra coding this creates a cloudy looking texture which can then be used to generate the map itself by adding colour and extrusion/height through coding. This seems like a very promising technique to implement for increment 1.

 

Fractals

 

Within the world there are many natural looking objects that cannot be defined by primitive shapes (i.e. a bush is not circular). Natural shapes are usually irregular and fragmented with a complexity incomparable to conventional geometry. Fractal shapes usually contain little copies of themselves within the original (i.e. Koch’s Snowflake). Fractals also contain infinite detail, with infinite amounts of iterations there will always be more detail within the next iteration.

 

Ferns for example can be a great example of a fractal shape, as each fern leaf can be made up of smaller versions of itself and achieve a great effect looking realistic and natural. This however seems to be more focused on objects that contain self-similarity, which is not exactly what I am looking for.

 

Tiling

 

Tiling has traditionally been used in games in a 2D nature to create the map space within a game. The tiles themselves are designed in a way to allow for multiple different configurations creating an endless amount of possibilities with the map design, although thematically the maps are limited by the content that is driving it. Tiling has been used in some games procedurally to create procedurally generated maps for players for a more replayable game that isn’t as repetitive. Some of these games are Rogue (1980), Elite (1984), Diablo (1996), Spelunky (2008), Terraria (2011), The Binding of Isaac (2011), Nuclear Throne (2015), Darkest Dungeon (2016). These games allowed for mass replayability through the randomly generated maps which the player would explore focusing on game mechanics and gameplay that went hand in hand with this map generation to make the gameplay more challenging and mysterious. Recently these games have been gaining significant attention due to the focus on Roguelike mechanics (Rogue 1980 is considered the forerunner and namesake of the genre).

 

This appears to be a very effective procedural strategy for 2D based games, due to the fact that I will be designing an application for use with 3D world space this is not an applicable strategy to use. However, in the event that I broaden the scope during some part of development this would be an ideal technique to implement for 2D environments. It is likely that there will be an easier implementation than this technique if this were to be done after the main three increments of this project.

 

Voronoi Diagrams

 

Voronoi diagrams are a decomposition of metric space that has predetermined “seeds” that partitions the space into areas that are closest to each seed. This means that each line is equidistant from the two nearest “seeds”. This creates several cell like areas that are called Voronoi cells. This technique has been widely used before procedural generation in many different areas including spatial analysis, geology, robotics and ecology. This technique, with regard to procedural generation, has long been used to create cellular looking textures for such surfaces like bark or skin.

 

I could use this technique in my tool to determine where the starting nodes of vegetation will be and then use this to determine how much will spawn around that node based upon the terrain. Using this technique would allow me to know the distance between each node, although this might not be needed and may just overcomplicate things. Other systems could be integrated in to determine the spread of the vegetation and growth/size of it.

 

Wind based vegetation spread in Unreal Engine

 

The developers for the Unreal Engine created an algorithm for procedurally generating some vegetation within scenes in a realistic fashion. This comprised of randomly picked starting areas that these plants would start in and based upon the wind over time would start to spread to the areas that the wind would carry the plants seeds. With certain areas being inhospitable to plants, like rivers, they would obviously not grow in these areas and so would not grow there in the simulation. This is a very interesting way to create natural and realistic environments that seriously raises the bar above and beyond what procedural generation has largely become in video games to date.

 

This seems like an ideal and interesting strategy for determining the location and amount of vegetation within a scene and could even be expanded upon with more realistic measures like sunlight exposure that would determine a plants’ growth and would scale the plant accordingly. This would however be very time consuming which might mean that this gets put down to a stretch goal for the project as I am working within a timeframe. This could however be calculated without building systems to supplement the calculations so the user is given a duration modifier to change the spread of vegetation and the growth of each node of vegetation. This could then be supplemented with a Voronoi diagram to determine the starting positions of vegetation and other objects.

 

This type of algorithm might also work to deal with increment 3 within the project to determine detail within a scene (i.e. where a plate is on a table) with algorithms calculating how often this object would move in the real world and adjusting position and rotation accordingly to create a more natural and lived in world. Problems that would arise from this is texture generation and again time constraints. The textures would be problematic as scuffs on objects or dirt, grime, etc would be none existent on these objects unless they were textured as such. This would require more work to create these decals for each object that could appear in the scene increasing the scope of this project massively.

 

Conclusions

 

There seems to be two main techniques that would be best for the three increments involved in the projects’ workload, whilst staying within time constraints. A third technique could be crudely implemented to supplement these techniques and create a more varying environment. These techniques are Perlin noise, Voronoi diagrams and Wind based vegetation spread. These techniques seem the most promising based upon my research and experimentation.

 

A couple of the techniques covered above (Tiling and Fractals) appear important to the history of procedural generation within games but seem incredibly useless with regard to my own project. I do not see a use for these two techniques in any capacity, however this could change over the course of development and it is important to remember what they do and how they work, to be able to utilise them in the future if needs must.

 

Whilst experimenting with the cellular automata and marching squares technique I did notice that the current code I was looking at was creating a cave system using this technique (an interior space) but the way the walls are made could be reversed so that instead of an interior space, you get an exterior one. This would then be reminiscent of a landmass that could then utilise Perlin noise to create differing heights in the terrain.

 

Suggestions

 

I suggest using Perlin noise with lacunarity and persistence for increment 1, with a chance to implement a reversed cellular automata and marching squares technique for a more interesting terrain shape. These two different techniques will create different types and shapes of terrain which could be used to give users more choice and differentiation between results.

 

With regard to increment 2 it seems suitable to use random points (rather than Voronoi diagrams) to determine where on the height map houses would be suitable and flatten out the height map in this area. Houses would then be clustered in this area, obviously avoiding water and mountains, then connecting house areas by roads. After this random points would again be used to determine where nodes of vegetation will spawn, with constraints of not spawning in the water or on mountains (rock and snow). These nodes will then have calculations crudely simulating the wind and sun to determine the spread and the growth of the vegetation. I also plan to have a duration feature that will be worked in to determine how long the vegetation has, to spread and grow.

 

For Increment 3 I will likely not be using any techniques found above and will instead focus on spawning the detail items in suitable places (i.e. a chair inside a house, a fork on a table) and then using calculations to determine the rotation and position of these over a duration of time. At the moment, at least until development starts with increment 3, I cannot think of any techniques that would be plausible or helpful for the development of increment 3.

 

Appendix G

 

Story Generators and Procedurally Generated Environments Analysis

 

Introduction

 

Conceptualisation of games and stories in any manner is an important aspect of the development process. In this document I will be looking at different tools that help to aid that process and look at key aspects of those tools to understand why they are used and if a similar method could be utilised in my own tool.

 

Plot Generator[1]

 

Plot generator gives us many options when it comes to designing our procedural story from the title to the names of characters, the opening of the story and the resolution of the conflict. This story generator sticks to a simple template that is then altered with the inputs given by the user. So instead of protagonists name it uses the name you gave the protagonist in the exact same context. This makes the story generation quite static although it is procedural.

 

There are plenty of options for users to make changes to the templates but some of these seem very abstracted from my idea as this application focuses very heavily on the story aspects of procedural generation. I may be able to use some of the more generic fields as part of my projects form (i.e. Location, currency).

 

My Self-Insert Story[2]

 

This application asks for some general information about your name and a partners name, and an ex of that partner. The story then asks the user for a selection of the plots which seem great individually but lacks the connectivity plots usually have with each other and even seem to conflict at times. This is a great example of what I should look out for when creating my own procedural generation application as conflicting information will be detrimental to the overall conceptualisation of games for the users (i.e. if there were guns in a setting of Vikings, this didn’t exist in that time period, maybe though this is the setting of the game, Vikings with guns).

 

This application uses more inquisitive questions to try to get more information from the user about the direction of the plots although this is limited to what has been produced so far. This is unlikely to be used in my application as there are no direct story elements planned for the application as it is more about environment/level/art concepts.

 

Story Idea Generator[3]

 

This application is based upon different principles which suggest to the user an idea with a question to spur them to write about the idea and focus on the question to elaborate. This is in the scope of an entire main plot, giving the user the main story focus needed but with non-restrictive descriptions that allow the users to branch out into different sub-plots and scenarios. This is an interesting technique that with just a few ideas could give users many different outcomes.

 

My own application will be similar to this as I will be giving users a sort of template to work from, a place to start and expand upon (although this will be visual aid in environment/level/art concepts, not story/idea concepts). This tool however offers no new information for me as this was an intended direction from the beginning of the project.

 

Random Plot Generator[4]

 

This application uses procedural generation in a different way to create an interesting plot with broad guidelines to what the plot should consist of. You can use the six buttons to roll/reroll the random elements of the characters, setting, situation, theme and actions. This brings together a truly random plot that may make no sense whatsoever but allows the user to change certain aspects with a click of a button. One downside to this is that the user may have to keep clicking the buttons for ages to get a nice plot, it took me a while to get one although this may have been by chance due to the random nature of the generations.

 

This gives me some reasoning and credence to add a “random” checkbox into my form which will fill the form with a set of random attributes that will make an environment based off of those. This can help to give some more creative ideas to those that are having creative block or else at least help to give some more creative thinking. One downside to this would obviously be the random attributes creating a nonsensical environment, however, if this is the intended direction it has some merits.

 

Story Generator[5]

 

This application gives the players some “TVTropes” to make their story with, some great descriptive articles explaining what each of these tropes are but there is just far too much reading for any user to reasonably use. The app gives the users a setting, plot, narrative, hero, villain and a couple other tropes to construct their story with, with no real plot help and only general guidelines to follow which seems to miss the point of a story/plot generator, to form a good idea in the user’s head.

 

I feel that this is a good tool to look at when I need to see what I am not going to implement or make my tool similar to. This tool seems to lack the point, in my opinion, however, this could easily help others in their creative thinking processes.

 

Seventh Sanctum Story Generator[6]

 

This story generator offers up ten random scenarios that consist of a character/main plot, a location, and a major plot. There is often other pieces of information that offer up some interesting sub-plots or themes for the story. This is an interesting tool that helps by giving some weird and very random scenarios. Having ten different story ideas on the screen at any one time seems to be a good direction to go with a story tool as the user can easily piece together different aspects of some of the stories to get one that wasn’t initially generated by the tool, which helps to drive the creative processes of the user.

 

Unfortunately this doesn’t seem to be able to fit into my own tool which will be dealing with the environment/level/art concepts rather than the story ones apart from the random generation of each field in the form.

 

Conceptstart[7]

 

This tool seems to be a more design focused tool that helps users to create art pieces of the generated idea within some constraints to challenge the user. The tool has a setting, mood, must have, era, medium, time frame and other fields that help to focus the user to create a specific piece of art. This tool has some interesting fields that I should definitely take a look at when designing my own.

 

This appears to be a great tool that helps users to keep drawing even when they are creatively blocked for ideas. Helping to allow the user to create more art and within constraint to show to themselves that they are able to work towards set goals and targets which would be similar to a real life working condition. Some of the fields like era, weather and setting will be important in my own tool for user choice.

 

Environment Generator[8]

 

This tool is a more closely related tool to the one I want to create with environment generation taking place and options for the users to choose from in terms of detail in the scene (i.e. sunlight, land, fog, etc.). This is the sort of program that I will be intending to expand upon and make a better version of.

 

This has given me a wider picture of what I can include in my own form to allow users to alter their own concepts generation.

 

World Machine[9]

 

World machine is essentially a terrain generation software that utilises height fields to displace geometry in different ways depending on the chosen modifiers. The software is node based, running left to right, similar to how texturing works in 3DS Max. Each modifier allows you to alter the outcome in different ways as they are different in functionality (e.g erosion, distortion, etc.).

 

This tool seems extremely capable at creating interesting and visually impressive terrain if left in the right hands but this seems like a very advanced tool that is not easily learned (similar to how one would learn creative/design processes, it takes time). The terrain that can be made is definitely a bit more impressive than what I would be aiming for within my own tool as it is only for conceptual purposes, not actual world building (although lower fidelity games could certainly attempt to use this tool for that purpose). I would be aiming to make my tool a lot more accessible and easy to understand than this, with the main emphasis on the user doing as little as possible to get the result they wanted.

 

This program seems like some stiff competition as part of my tool will be focused on the terrain generation aspect as this tool is (in its entirety). However I feel that I don’t have to worry too much as my tool will differ greatly with the emphasis of procedural generation of the terrain, vegetation, architecture and detail within scenes, with a very small amount of time spent on the task as opposed to the big undertaking of learning how to use World Machine and then developing just the terrain.

 

World machine costs

Limitations of Unity Terrain (import aspects)

 

Conclusions

 

We can see by these story and plot generators that there are many ways to help users identify a plot or story that they can focus on and expand upon. Getting the plot is the first part of the story with a need to expand and focus in on small details and interactions between different characters, factions and environments.

 

With an unfortunate lack of finding environment generators that are not static (i.e. have no options for users to change the outcome instantly), I was unable to get enough data in this area to reliably come to any conclusion on these tools. The only conclusions therefore is that there are either not enough tools in the public space for this area, showing a probable likelihood of companies having internal private tools which they use for this process or otherwise do not use at all.

 

Suggestions

 

From this research I have found some interesting tools in a similar space that attempt to create a similar process for the users and are, for the most part, successful at what they do.

 

From this I suggest that a form be created in my tool that allows users to alter the outcomes of the environment generation in a way that gives the end result similarities to the users’ concept. This will however be limited by the produced/collated work although this can always be expanded to include more options/assets at a later date. The research I have done has given me a few fields already for this form I am to create and this shall be expanded upon with use of a SWOT Analysis and Mindmap. This should allow me to think of all possible needs with the help of the user requirements analysis. Should I feel that I have an incomplete form or one lacking in any attributes I will set up some interviews with friends, family and/or developers and get them to weigh in on the form to identify any strong, weak or potential attributes in/for the form.

 

References

 

[1] Plot Generator. 2018. Story Generator. [ONLINE] Available at: https://www.plot-generator.org.uk/story/. [Accessed 8 February 2018].

[2] The Self-Insert Story Generator. 2018. The Self-Insert Story Generator. [ONLINE] Available at: http://suegen.azureye.net/mygame/index.html. [Accessed 8 February 2018].

[3] Bookfox. 2018. The Best Story Idea Generator You’ll Ever Find. [ONLINE] Available at: https://thejohnfox.com/2016/05/story-idea-generator/. [Accessed 8 February 2018].

[4] Random Plot Generator. 2018. Random Plot Generator. [ONLINE] Available at: http://writingexercises.co.uk/plotgenerator.php. [Accessed 8 February 2018].

[5] TV Tropes. 2018. Story Generator – TV Tropes. [ONLINE] Available at: http://tvtropes.org/pmwiki/storygen.php. [Accessed 8 February 2018].

[6] Seventh Sanctum. 2018. Seventh Sanctum – Story Generator. [ONLINE] Available at: http://www.seventhsanctum.com/generate.php?Genname=storygen. [Accessed 8 February 2018].

[7] Administrator. 2018. Environment Design Art Prompt Idea Generator. [ONLINE] Available at: https://www.conceptstart.net/environment-design-generator-idea-prompt#environment. [Accessed 8 February 2018].

[8] Environment Generator | ScriptSpot. 2018. Environment Generator | ScriptSpot. [ONLINE] Available at: http://www.scriptspot.com/3ds-max/scripts/environment-generator. [Accessed 8 February 2018].

[9] World Machine Software LLC. 2018. World Machine : The Premier 3D Terrain Generator. [ONLINE] Available at: http://www.world-machine.com/. [Accessed 28 February 2018].

 

Appendix H

 

Appendix I

 

CONSENT TO AUDIO- OR VIDEO RECORDING & TRANSCRIPTION FOR THE USABILITY STUDY OF THE VIDEO GAME CONCEPT TOOL TITLED “Procedural Environment Generator”

 

CARRIED OUT BY:

RYAN WILDISH

 

This study involves the audio or video recording of your interview with the researcher. Neither your name nor any other identifying information will be associated with the audio or audio recording or the transcript. Only the research team will be able to listen (view) to the recordings. The tapes will be transcribed by the researcher and erased once the transcriptions are checked for accuracy. Transcripts of your interview may be reproduced in whole or in part for use in presentations or written products that result from this study. Neither your name nor any other identifying information (such as your voice or picture) will be used in presentations or in written products resulting from the study. By signing this form, I am allowing the researcher to transcribe my thoughts, reactions and comments and/or audio/video tape me as part of this research.

 

I understand that I can opt out of audio or video recording of the interview, whilst still participating in the usability study by not ticking the checkbox below. In this case I understand that the researcher will transcribe my thoughts and opinions whilst maintaining no mention of my identity or any factors that may link the transcribed information back to me.

 

I understand that my participation is voluntary and that I am free to withdraw at any time without giving any reason, your legal rights will not be affected.

 

Are you willing to opt in to audio or video recording?

 

Participant’s :

 

Signature: ___________________________________________Date:__________________

 

Appendix J

 

Appendix K

 

User Testing – Terrain

 

User 1

 

  • No understanding of Perlin noise, Lacunarity, Persistence, etc.
  • Finds it hard to understand what each attribute will do
  • Some attributes seem very understandable and useful after experimenting with
  • Some attributes seem not useful or don’t do anything
  • *CRASH* Octaves went higher than 78 and it crashed computer, limit to 20 as this is when it breaks the mesh
  • Terrain Type in Options seems very useful for quick presets
  • Needs labels so that each attribute is understandable before experimenting with it
  • Liked the change in colours available to the user
  • Why does the flat terrain type still have mountains and snow
  • “Good features but a few bugs or missing features, pretty damn cool though”

 

User 2

 

  • UI easy to understand for Unity users
  • Bit confusing having same options in two places
  • Understands the need for one main overarching menu, and why this would have a secondary one – likes the fact that if one changes the other does as well, less confusing
  • Presets need more work but otherwise good idea
  • Change of colours is good optionality for users, incorporate this into presets?
  • Two currently non-working drop down lists (Environment Type, Terrain Generation Technique)
  • Labels would make each attribute more understandable to people not familiar with this area
  • Most attributes were understandable/predictable
  • Some preset optimisation with colours would help
  • Why is there the Generate button if this is all done automatically? (Missed the AutoUpdate checkbox, maybe off by default? Header?)
  • Didn’t really understand the Mesh Height Curve without explanation
  • “This seems really good for devs, but definitely some issues and more features needed”

 

User 3

 

  • No explanation of what each attribute is for/or does at first glance, some experimentation needed for the user to understand, make it a bit more intuitive
  • Presets are good, could use some more work though with colours
  • Two non-working drop downs
  • Likes the automatic update on a change as it shows what has changed instantly
  • Understood attributes after experimenting with them
  • Likes the utilisation of Unity’s UI over creating own
  • Weird having same options in two different places
  • “There’s no real use for this at the moment but this could be something that saves a lot of time in the future”

 

Conclusion

 

It is very clear from the users feedback that they can understand how to use this tool after a bit of experimentation and explanation on what the tool is supposed to do. While this is to be expected from a user (that they would understand the purpose of the tool) they may not necessarily know exactly how to utilise the tool in a manner to create what they want from it. From the feedback in this area I will be implementing labels to each editable area which will give a brief description of what that field does. This will allow users to have a clearer idea of what they are doing and a higher chance understanding what is about to happen when they change it. There were also a couple of bugs found within the testing sessions which will be looked into and fixed accordingly.

 

The only other feedback received seemed to be related to the actual use case of the tool, in which it’s in no state to be used in any capacity right now. The testing session was not to measure how effective the tool is but rather how the user experience feels with the terrain generation UI at the moment, and to find changes to be made to this. This again will be the focus of the next two testing sessions (for each increment) where after the third session is completed and changes made, an overall session will be completed to test for missing features and the like.

 

Appendix L

 

Appendix M

 

Appendix N

 

Appendix O

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s