top of page
Fig 5.001 - Cloth
Fig 5.002 - Ferris Wheel
Fig 5.003 - Cloth 02
Fig 5.004 - Cloth 03
Fig 5.005 - Clown Head
Fig 5.006 - Bunny Teddy
Fig 5.007 - Bunting
Fig 5.008 - Square Cobbles
Fig 5.009 - The Veranda side
Fig 5.010 - The Veranda Roof
Fig 5.011 - Column 01
Fig 5.012 - Column 02
Fig 5.013 - The Veranda Door 01
Fig 5.014 - The Veranda Door 2
Fig 5.015 - The Veranda Door 03
Fig 5.016 - The Veranda Door 04
Fig 5.017 - The Veranda Door 05
Fig 5.018 - The Veranda Door 06
Fig 5.019 - The Veranda Door 07
Fig 5.020 - The Veranda Door 08
Fig 5.021 - Wire 01
Fig 5.022 - Wire 02
Fig 5.023 - Balcony 01
Fig 5.024 - Balcony 02
Fig 5.025 - Balcony 03
Fig 5.026 Beam
Fig 5.027 - Balcony Floor
Fig 5.028 - Balcony Edge
Fig 5.029 - Trusses
Fig 5.030 Tram Tracks
Fig 5.031 - Tran Tracks
Fig 5.032 - Tram Cobbles
Fig 5.033 - Toilet Roof
Fig 5.034 - Toilet Wall
Fig 5.035 - Toilet Door
Fig 5.036 - Toilet Wall
Fig 5.037 - Toilet Door
Fig 5.038 - Toilet Column
Fig 5.039 - Sink 01
Fig 5.040 - Sink 02
Fig 5.041 - The Veranda Sign
Fig 5.042 - The Confectionary Sign
Fig 5.043 - Rue Royale Sign
Fig 5.044 - Shutter
Fig 5.045 Shutter 02
Fig 5.046 - Window 01
Fig 5.047 - Window 02
Fig 5.048 - Barrel
Fig 5.049 -  Rue Royal Door 01
Fig 5.050 - Rue Royale Door 02
Fig 5.051 - Rue Royale Door 03
Fig 5.052 - Rue Royale 052
Fig 5.053 - Rue Royale Window 1
Fig 5.054 - Rue Royale Window 2
Fig 5.055 - Rue Royale Window
Fig 5.056 - Rue Royale Window 4
Fig 5.057 - Rue Royale Corner
Fig 5.058 - Balcony
Fig 5.059 - Roof 01
Fig 5.060 - Roof 02
Fig 5.061 - Roof -3
Fig 5.062 - Floor Grate
Fig 5.063 - Cobbles Curve
Fig 5.064 - Gutter
Fig 5.065 - Curtain Detail
Fig 5.066 - Curtain Hang
Fig 5.067 - Rail 01
Fig 5.068 - Rail 02
Fig 5.069 - Rail 03
Fig 5.070 - PVC 01
Fig 5.071 - PVC 02
Fig 5.072 - Plywood 01
Fig 5.073 - Plywood 02
Fig 5.074 - Plywood 03
Fig 5.075 - Plywood 04
Fig 5.076 - Plywood 05
Fig 5.077 - Plant Pot
Fig 5.078 - hanging Moss 01
Fig 5.079 - Hanging Moss 02
Fig 5.080 - hanging Moss 03
Fig 5.081 - Hanging Moss 04
Fig 5.082 - Hanging Moss 05
Fig 5.083 - Nails
Fig 5.084 - Moon
Fig 5.085 - Sign
Fig 5.086 - Road
Fig 5.087 - Curb
Fig 5.088 - Locker Floor
Fig 5.089 - Locker Door 01
Fig 5.090 - Locker Door 02
Fig 5.091 - Locker Door 03
Fig 5.092 - locker Door 04
Fig 5.093 - Locker Mid
Fig 5.094 - Locker Shelf 01
Fig 5.095 - Locker Ticket
Fig 5.096 - Locker Shelf 02
Fig 5.097 - Curb 02
Fig 5.098 - Curb 03
Fig 5.099 - Beams
Fig 5.100 - Beams 02
Fig 5.101 - Ice Cream Top
Fig 5.102 - Ice Cream Cone
Fig 5.103 - Ice Cream Cone
Fig 5.104 - Grass 01
Fig 5.105 - Gutter Pieces
Fig 5.106 - Grass 02
Fig 5.107 - Grass Tall
Fig 5.108 - Steps
Fig 5.109 - Plant Pot
Fig 5.110 - plant Pot
Fig 5.111 - Plant Road
Fig 5.112 - Gazebo
Fig 5.113 - Flowers
Fig 5.114 - Flower Pot
Fig 5.115 - Flower Pot Empty
Fig 5.116 - Footpath Flags
Fig 5.117 - Turnstiles
Fig 5.118 - Turnstiles top
Fig 5.119 - Turnstiles
Fig 5.120 - Hero Tree
Fig 5.121 - Beam
Fig 5.122 - Column
Fig 5.123 - Beam With Detail
Fig 5.124 - Flat Fence
Fig 5.125 - Light
Fig 5.126 - Entrance Booth 01
Fig 5.127 - Entrance Booth 2
Fig 5.128 - Door
Fig 5.129 - Column
Fig 5.130 - Entrance Top
Fig 5.131 - Shutters
Fig 5.132 - Dolphin Teddy
Fig 5.133 - Crayon Teddy 01
Fig 5.134 - Crayon Teddy 02
Fig 5.135 - Crayon Teddy 03
Fig 5.136 - Leaves
Fig 5.137 - Light Stand
Fig 5.138 - Light
Fig 5.139 - Light
Fig 5.140 - Wall
Fig 5.141 - Roof Corner
Fig 5.142 - Roof Main
Fig 5.143 - Column 01
Fig 5.144 - Column 02
Fig 5.145 - Barrier
Fig 5.146 - Barbe's Ice Cream Entran
Fig 5.147 - Barbe's Entrance Window
Fig 5.148 - Barbe's Ice Cream Entran
Fig 5.149 - Barbe's Ice Cream Door
Fig 5.150 - Barbe's Ice Cream Door
Fig 5.151 - Barbe's Ice Cream Logo
Fig 5.152 - Machine Door
Fig 5.153 - Machine Main
Fig 5.154 - Balcony
Fig 5.155 - Asphalt Patch 01
Fig 5.156 - Asphalt Patch 02
Fig 5.157 - Asphalt Patch 03
Fig 5.158 - Arcade Edge
Fig 5.159 - Arcade Roof
Fig 5.160 - Arcade Wall
Fig 5.161 - Arcade Column
Fig 5.162 - Tree 01
Fig 5.163 - Tree 02
Fig 5.164 - Cobble Bricks
Fig 5.165 - Six Flags Sign
Fig 5.166 - Barrel 02
Fig 5.167 - Plant Pot 02
Fig 5.168 - Cloth 05

Modularity

Intro to Modularity
Example 01
Example 02
Example 03
Issues with Modularity
References
Intro to Modularity

Modularity has, and will always be an integral part of creating environments for video games. The benefits to creating modular pieces and assembling them in engine are incredibly vast, and as a result almost every game in existence uses this system when creating their worlds. The necessity for modularity typically comes from the scale of the environment - creating one asset and re-using it throughout the environment is undeniably more efficient in terms of time and man-hours, but modularity is also much more efficient in engine as the asset only needs to be loaded into memory once, and simply refreshed for each instance. Thus, modularity not only benefits the speed at which an environment can be assembled, but also its efficiency during run-time.

Indeed, the use of modularity is important in every type of game, but it becomes increasingly important when a game's scale reaches a certain size. As a result, many open world games have perfected the use of modularity, and were a constant source of inspiration throughout the course of the project. I drew particular inspiration from Fallout 4 and The Elder Scrolls V: Skyrim's approach.

Joel Burgess of Bethesda Game Studios describes the approach in detail at the Game Developer Conference (GDC) in 2016. Burgess compares the modular game pieces to Lego blocks⁷ , and describes how using a uniform and prespecified footprint in the beginning of your project allows for the quick and easy snapping of modules throughout the course of the project. "The design of a Lego brick is highly specific, and that specificity is what permits it to work as a part of a system.". By predetermining the proportions of this footprint (i.e, the modelling grid), the modules naturally snap together, and work cohesively within the same system. Burgess describes the base footprint used by their team throughout the project was an equilateral cube of 256 dimension. Due to my architectural background, however, I found it much easier to divide my equilateral cube into real-world units, and so the base cube from which I created the majority of my assets was a 1m cube, which I could then divide down into 10 modular units. The grid was then set to 10cm increments, and assets typically conformed to this measurement.  

1m = 100cm
1m = 10 modular units

Predefining this modular footprint prior to the modelling process was incredibly important, as each asset created in this way could be quickly and easily assembled in engine without a need for specific pieces. That said, not everything in environment could revolve around this module, as some assets needed to be more organic or specific scaling options were better suited, and thus this measurement was a guide rather than a strict rule.

Joel Burgess also discusses a similar modular approach in the creation of worlds in Skyrim and Fallout 3 on his own website⁸. He presents this modular approach in the form of a piping system, which draws striking parallels to the gutter system I used within my environment, despite the fact they use a different scale module. This confirms that the scale of the modular system is not the priority, but that each asset sticks to the same system. This would be particularly important in a team, where multiple artists work on assets that must snap together seamlessly.

Fig 5.169 - Fallout 3 Pipe Kit from Joel Burgess' website
Fig 5.170 - Gutter kit from my abandoned theme park
Example 01
Ticket Booth

x2

x2

x4

x2

x1

x4

This is an example of how a couple of modular elements, constructed using the same grid, can quickly snap together to form a ticket booth. Most of the assets are re-used within this one ticket booth, and many are even reused throughout the rest of the environment.

x2

Example 02
The Veranda

x1

x1

x1

x1

x1

x1

x1

x1

x8

x1

x3

x1

x6

x2

x5

x8

x4

The facade of The Veranda building is an example of a much larger collection of modular pieces assembling to create one of the most important buildings in the environment. Because each asset was created with every other asset in mind, and revolves around the predefined grid, each asset can still snap together in engine very quickly. Here, the benefits of modular construction become evident. Some meshes, like the balcony floor get used in eight different places without the need for eight separate meshes.This not only expedites the modelling and assembly process, but it is also more efficient in game as it only needs to be loaded into memory once.

During the modelling process I experimented with breaking each of these modules down even further and grouping them in engine via blueprints, Unreal Engine's propitiatory scripting system. As you can see from the image above, the mesh for each of the doors and windows is its own separate mesh, and not duplicated anywhere else, despite sharing similar attributes. While they are assembled in Maya using the same modular system as the rest of the scene (Fig 6.1), the process of importing each individual piece became tedious and very time consuming, particularly when organising pivot points and ensuring they aligned to the grid perfectly. Thus, I decided to group these assets in Maya before hand, and export them as one solid mesh each (Fig 6.2). This is obviously not very efficient in game as the engine has to load numerous similar meshes, but it was a trade-off between efficiency and time. On reflection I should have dedicated the necessary time to optimising these meshes, but given the small size of each mesh and that they all share a mutual material, the savings in engine would be minuscule.

Fig 6.1 - Separate pieces in Maya
Fig 6.2 - Exported as one mesh. Not very efficient.
Example 03
Lockers

x2

x1

x1

x1

x2

x4

x1

x1

While the modular elements of The Veranda demonstrated how exporting large meshes from Maya was not very efficient, the above lockers demonstrate using Unreal Engine's Blueprints to assemble smaller meshes into larger, more manageable pieces within the engine itself. This is more efficient, because Unreal Engine understands the similarities between each mesh, and it does not need to load duplicate pieces unnecessarily. The most noticeable benefit, however, is that the meshes can be re-assembled in various ways within the game engine, creating numerous variations quickly, easily and efficiently, demonstrated below (Fig 7.1). This highlights the prosperity of modularity clearly, particularly in the context of a game environment (Fig 7.2 and Fig 7.3).

Fig 7.1 (above) - Modular Blueprint assembly.
The issue with modularity

In summation, modularity is incredibly valuable when constructing a game environment. Not only does it benefit the engine, allowing games to run smother, but it also makes assembly and re-use far more efficient. But there are some major drawbacks to constraining artists to a modular kit. The biggest barrier with modularity has to be the monotonous and repetitive aesthetic of the design. When confined to a predefined kit of parts, it becomes increasingly difficult to add variation to your models as repetition of assets is paramount to the modular system, as visible from the repetition of the modular ticket booths discussed previously (Fig 8.1, 8.2 and 8.3 below). When duplicated, repetition becomes evident, and the illusion of realism is broken. This issue plagues every game using modularity. This project uses a variety of techniques to minimise the appearance of repetition, discussed later in this retrospective.

References

⁷ Burgess, J. (2016) ‘Fallout 4’s’ Modular Level Design, 4:53 Available at: http://www.gdcvault.com/play/1023202/-Fallout-4-s-Modular / (Accessed: 4 December 2016).

⁸ Burgess, J. (2013) Skyrim’s modular level design. Available at: http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html (Accessed: 4 December 2016).

bottom of page