Custom Procedural Generator

Date of Conception:
1/17/16
Author:
Garrett Reuscher

TEAM:
Garrett
Reuscher

Technical Field
This project involves the technical fields of Game Programming, UI/UX, Procedural
Generation, Pathfinding, Data Structures, Advanced Algorithms, and Level Design.

Background Information
Procedural generation of game levels has been employed in the industry for several decades now,
starting with a famous game by Michael Toy and Glenn Wichman developed in the early 1980s.
What set this game apart from other games of the time was the use of a random number
generator to create the games levels, allowing for a nearly infinite amount of levels for users to
play. Many different algorithms and procedures have been developed to create levels since then,
but each game tends to have its own specific set of requirements for the levels to work. This
meant that procedural generation algorithms barely received any input from the user end. This
project hopes to give the user a huge amount of control over how the level is generated.

Prior Art
The procedural generation methods used in this project are derived from existing algorithms such
as the Prims algorithm and an algorithm designed by Bob Nystrom
(http://journal.stuffwithstuff.com/2014/12/21/rooms-and-mazes/).

Project Description
The Custom Procedural Generator is a demo application that will be built in the Unity game
engine, with C# as the programming language. It allows users to use pre-made algorithm
pieces to assemble their own procedural generation algorithm. The user is able to change
which algorithm pieces to use and in what order. To further add to the customization potential,
users are also able to use certain rules to change the level after it is generated (changing the

playability of the level). More algorithms and level design rules will be applied over time, with
the system eventually being included in a game.

Innovation Claim
This project is innovative because it gives the user a vast amount of control over how the level is
generated (as opposed to it being determined by the programmer).

Usage Scenario
The project could be used as an educational tool to teach game programmers about different
algorithms used for procedural generation, or even beginning level designers about principles of
level design. The user would start up the application and be greeted by a screen which allows
them to enter a seed, map dimensions, and several other basic settings. Next, they will proceed to
a screen in which they can load in a pre-made algorithm or create their own. Finally, the user will
proceed to a screen in which they can select which rules should be applied to the level after it
generates. After the user confirms their selection, the level will generate based on their choices,
with the user being taken to a loading screen while this happens. The user can choose to watch
the level generate (with slower times) or wait until it is finished (with faster times). The user can
then go back to the main screen whenever they are done looking at the generated level.

Evaluation Criteria
The following questions will identify the successful completion of the project:

Can the user start the application?

Can the user enter a seed for the random number generator to use?
Can the user choose the dimensions of the level?
Can the user assemble their own algorithm using the provided pieces?
Is the user provided with sufficient information to create their own level?
Can the user pick level design rules to be applied to level generation from a list of at least
two different rules?
Is the user taken to a loading screen after confirming their selection?
Can the user choose to watch the level or wait until it is finished?
Does the level generate according to the users instructions?
Can the user save and load their algorithms?
Can the user exit the application?

Milestones and Tasks Associated with the Project

Milestone 1
Start: January 17th, 2016
End: January 24th, 2015

Begin research involving procedural generation of game levels and decide on two pre-made
algorithms to be implemented. Begin research into traversal algorithms to be used to check the
levels after generation. Design structure and restraints of procedural generation system.

Milestone 2
Start: January 24th, 2016
End: January 31st, 2016
Implement basic user interface for application.

Milestone 3
Start: January 31st, 2016
End: February 7th, 2016
Implement one of the chosen algorithms and have the level generate and display on the screen
after the user confirms their selection.

Milestone 4
Start: February 7th, 2016
End: February 14th, 2016
Implement the other chosen algorithm and ensure that the correct algorithm is being used based
on the users selection.

Milestone 5
Start: February 14th, 2016
End: February 21st, 2016
Add algorithm settings and descriptions. Polish the user interface.

Milestone 6
Start: February 21st, 2016
End: February 28th, 2016
Implement both chosen level design rules and ensure they are applied to one of the generated
levels.

Milestone 7
Start: February 28th, 2016
End: March 20th, 2016
Bug fixes. Additional features based on time. Fill out remaining sections of Innovation Brief.

Description of Design Prototype

The design prototype for this project is a technical design document detailing the layout of the
procedural generation system. The document describes how user will be able to create their own
algorithms, as well as how the application will use said algorithms. It also contains a mockup
design of the user interface and a description of expected user interaction with the system.

Evaluation Plan
Testers will start up the application and first attempt to enter basic settings. After that they will
select the first pre-made algorithm and select some of the level design rules available. They will
then watch the level generate and ensure it worked as intended. After they are done analyzing the
level, they will go back to the title menu and repeat with as many algorithms as they desire.

Project Completion Assessment

The Custom Procedural Generator was a difficult application to make, but this was due to its
focus on user experience. Having a design that was primarily user-driven meant that the user
interface had to be polished and the application mostly bug free. In addition, the beginning
milestones involving backend design ended up taking much longer than intended. Ultimately, the
project functioned as intended, with maximum expandability and portability.

Appendices
Appendix A: Technical Design Document
Appendix B: Executable Application