Aetherus | In-Engine Progress (Whiteboxing and Model Designs)

Last update covered the new vision behind the game and the world of Aetherus. Now, it’s time to reveal some of the in-engine progress I’ve made within the past week. To preface, I am using Unity 2019.2.17f1 to build this game. I’ve chosen not to upgrade to 2019.3+ due to interface and other changes.

This update will be split into two parts: the first will cover the original level layout and my design philosophy behind the included in-game models, and the second will go into the changes made to the layout after a round of playtesting. Unless otherwise stated, all models and terrains were made by me. Let’s jump right into it!

Part One: Early Whiteboxing and Model Designs

The first iteration of the level layout. Note the seven bridges and the single, large island.

As you can see, the level is relatively large. Due to time constraints, I needed to limit how large the map would be, but I still wanted to make it large enough to give the player enough to explore and roam around in. I used Unity’s built-in terrain asset system to create the bulk of the map. Experience from RTS map editors, such as Battle for Middle-Earth’s Worldbuilder, helped me sculpt ideal shapes for mountains and hills. As I mentioned in the previous update, I actually ended up turning what would have been tall, daunting mountain ranges into rolling hills instead, giving the player the opportunity to navigate the map over these “obstacles”. Mobility and navigation were important concepts that played into the map design.

Side profile of the map. Note that the island was sculpted in-engine from a single terrain asset.

Model Designs

Overall, I sought to use a geometric style of modeling alongside a fantasy-medieval look. I began with the bridges first, the largest structures with a design that includes tall pillars interconnected with flat railings.

The bridge model I created using Unity’s ProBuilder. The entire bridge is a prefab made up of several different parts. Note the capped pillars and flat railings.

I designed the towers after the bridges. Because the tower system is based on powering dormant towers that already exist on the map, I needed to build a variety of towers and identify the best locations to place them. I couldn’t have them simply scattered everywhere, as I needed to keep enemy pathing and player pathing in mind. Too little towers and defense would become terribly difficult to manage. Too many towers and defense would become too easy.

I ended up making three different tower models. Tower I is the standard defensive tower with an average rate of fire, and I modeled it based on a medieval castle-style tower. Tower II is a larger structure with a higher, area-of-effect attack, based on a more sci-fi look. Tower III provides the player with a buff if they are nearby, and is based on a medieval-style torch-carrying tower.

Tower I. A basic defensive tower based on a medieval castle’s tower.

Tower II. A sci-fi-style tower whose design reflects its high damage output and attacking style. The “cap” of the tower floats above the body and slowly rotates.

Tower III. A specialized tower that doesn’t attack, but rather provides a buff to the player when they are near. It is modeled after a medieval-style torch-holding structure, and the final model will include a torch-like object housed within the head of the tower.

I also needed a crystal for the player to defend, and a surrounding structure that would be the Auria Stabilizer. I modeled the Stabilizer in two identical parts with protruding “arms” – the final model will include curved beams of energy that flow between the arms of either half. In the center is the Aureum crystal. Because I was in the process of learning how to use Maya to sculpt, I used an asset from the Unity Asset Store to represent the crystal. The crystal floats inside a “pit” in the ground, and planned animation will have it slowly rotate and bob up and down.

The Aureum and Auria Stabilizer. The final model will see the crystal bob and rotate, and energy beams pulsate between the arms of the Stabilizer halves, reflecting the structure’s magical nature.

After these various structures had been modeled, I scattered them across the map. I made sure to consider pathing, and adjusted tower placement based on where I planned to map enemy AI pathing.

The center of the map, where the player spawns. Eventually I plan to build this up into a stronger base of operations, including more buildings and structures the player can make use of.

Another look at the map, from a different angle. Note the variety of towers scattered across the level.

Part Two: Playtesting, Feedback, and Updating the Whitebox

It took me several hours across two or three days to finish the original whitebox layout. Afterwards, I had several people playtest the level to explore the map and identify what they liked, what they didn’t like, and suggestions for changes or additions.

Feedback Received:

Indicate clear boundaries around the map to show the limits of where players can move.
Reduce the number of bridges.
Consider scale versus tempo (map size and layout in comparison to mobility).

Non-Map-Related Feedback:

Add fall damage.
Include an indicator to show wave progress.
Allow the player to expand the planned mini-map to show a larger, detailed map.

Addressing Feedback

Following the playtest session, I went to work on updating the level layout based on feedback I had received. All playtesters loved the scale of the map and the use of terrain – however, some brought up concerns about mobility and navigation, and felt that it was difficult to scale certain areas of the map. One mentioned that they weren’t sure what areas were meant to be scalable or not, thanks to the jagged terrain sculpting. I would fix this by smoothing out the terrain overall, giving the map a more rolling feel without the sharp points and edges of the original terrain.

A look at one corner of the map that originally had several jagged peaks. Smoothing the terrain rounded out these peaks, making it easier to traverse. Also note the shrine structure hidden here.

Another playtester mentioned how it would be useful to consider the importance of scale versus tempo – that is, the idea of map scale versus mobility. Would I want to focus on how large or intricate the map was, or on how easily the player could move around the map? After careful thought, I decided to add another “level” to the layout. The map already had plenty of verticality – why not make use of this verticality? I did this by raising the height of several mountains, and modeling a series of islands in Maya to “attach” to these mountains. This accomplished two things: it gave the player a second, higher “level” of the map to defend, and a new cavelike area underneath this new level to explore. Indeed, I included a new shrine structure in one of these dark areas.

A look at part of the new “upper level”. Note the shrine structure hidden here. Perhaps the player can come here to pick up new weapons after each wave?

A closer in-game look at the same area (hence the UI placeholder at the bottom of the screen).

The addition also addressed the number of bridges by moving two to an upper area, though the number remains the same. I have an idea to actually close off the “cave” area by actually making a cave system – I would need to raise the rest of the mountain range in this area, and then re-model the “islands” used for the upper level into one larger model that would cover the entire area. Doing this would also remove the lower bridge in this area, reducing the number to six and making it easier for the player to defend. A cave system would also mean I could add a number of new features unique to the area, and give the player more to explore! I think this idea has potential – I will need to find feedback first, and then work on re-modeling the upper level.

A bird’s-eye view of the upper level. If I extended this level to also cover the circled area, the northern bridge could be removed and the player would have both more of the upper level to traverse and a new cave area to explore. Food for thought!

Finally, I plan to address all feedback not related to the map or level layout once I begin coding the various mechanics and designing the UI.

The Updated Map

After numerous changes, major and minor, we now have this version of the level map! Navigation around the map should be easier with the smoothed-out hills and mountains, and the player now has the beginnings of a cave system to explore, as well as an upper level of the map to defend.

Some angled views of the updated level layout. You can see the newly-added upper level in the north. Its slanted areas allow enemies to move down to ground level, and the player to move up.

I also thought of other defensive structures I could add, like gates. The island now boasts two gates on either side of the map that guard key locations – by default, they are closed and block enemies from passing. However, at a certain wave, gate-busting enemies will start to appear – if they break down a gate, enemies will now be able to pass through that shorter path. Gates can be rebuilt with enough Auria.

The western mountain-range without and with the gate. Enemies could approach the Aureum if this path was left open (or if the gate was destroyed).

The second gate guarding the eastern bridge. With the gate blocking the fastest path to the Aureum, enemies approaching from this bridge must instead take the long path towards the northeastern bridge and then circle around.

Work Continues

Overall look at the map before and after changes.

Good progress has been made so far! My next goals are to finish the final, overall level layout (including whether the cave system will be implemented) and to start either on scripting mechanics or on adding textures and materials to the map.

Thanks for following Aetherus’ development thus far, and keep an eye out for the next update post!