1 Procedural Generation
1.1 Procedural over Manual
Very broadly speaking, in game development there are two primary ways to generate content for a project. The
most common and controllable way is to produce each piece of content by hand. The consequences, in the case
of this article, would be the production of a large 2D tile map by a manual process.
For smaller content sizes this isn’t a problem; it’s a relatively straight-forward process to declare each tile as an
element of a statically-sized 2D array and just draw those tiles to the screen in a single pass alongside, perhaps,
the drawing of different sprites layered on top of each tile to represent NPC’s or the player. But what happens
as a map grows in size? As it increases from a 32 × 32 map to a 256 × 256 sized map, or even larger? Even if
the programmer had created a time-saving, high-level system for creating maps as text files to be read in by the
program, it can very quickly become time-consuming and tedious. Although this is a valid way of generating con-
tent, in fact the developers on CD Projekt Red’s The Witcher 3: Wild Hunt did just that (Klepek 2015), most
programmers don’t possess the resources or manpower of a AAA game studio and therefore often must create
a better solution. So what’s the appropriate solution?
Procedural Generation algorithms are the solution
Indie game title such as Minecraft, Dwarf Fortress, and the upcoming No Mans Sky all make use of procedural
content generation to build enormous, beautiful, but seemingly random and unique worlds. We say seemingly
random for two reasons:
1. Computers can only produce pseudo-random numbers as the only truly random processes are analog, phys-
ically occurring phenomena, such as the measurement of cosmic radiation or noise signals in hardware cir-
cuits (Güneysu 2010).
2. These procedural generation algorithms are designed so that, with the same starting point, it will produce
the same result.
What is the starting point for this process?
The answer to that question is wide and varied and many games, such as in indie title Dwarf Corp., begin by sim-
ulating tectonic plate activity (Klingensmith 2013), erosion, or river formation to carve out their terrain - in a
similar fashion to how terrain forms in the real world (Huggett 2007, pp. 46). However, this article will be tak-
ing a different route and begin by generating a realistic height map stored in a 2D array of elements that each
hold a generated elevation value which will be used to base the remaining generation procedures off. We will use
this initial information to procedurally generate a 512×512 sized 2D continent-like map that can be navigated
by a player character. Furthermore, we will make heavy use of the SwinGame API to handle all graphics-related
functionality and briefly touch on other interesting concepts such as basic collision detection and drawing algo-
rithms, all of which will be coded using the Pascal programming language.
1.2 Diamonds & Squares
To generate a heightmap, it would be possible to design an algorithm from scratch, however that would take a
long time, would need to be rigorously tested, and the result probably wouldn’t be very effective, so the core of
our program will be based off a very well-known and well-tested one named Random Midpoint Displacement
(Fournier, Fussell, and Carpenter 1982), also known as the Diamond-Square Algorithm. At its core, the pur-
pose of this algorithm is to generate pseudo-random noise in a desirable pattern, i.e. one that resembles a re-
alistic spread of terrain height values. Each point of noise is stored in a data structure, in our case a 2D array,
and holds a single value - a number representing its elevation. The resulting map will look something like this:
2