The Empire Within Woodlands

Overview

The Empire Within Woodlands is an RTS survival base-building game in which the player must manage resources and train soldiers to survive against enemy onslaughts. The game features a mechanism for base building, offering complete freedom in choosing where buildings can be constructed. Additionally, the peasants, who act as workers, are completely automated; the player only needs to build the required occupation buildings, and then the peasants are automatically assigned to their jobs.

‍
‍Genre RTS Base Building
‍
Game Engine Unity Game Engine
‍
Control Mostly relies on the mouse
‍
Team Project Yes, and my role was coordinator, lead developer, and concept artist.

Theme Low Poly
‍
Version Controlling PlasticSCM

Idea The idea of the game originated from a simple class assignment that asks for control of a flying object.
‍
Codes of Project LinkToCodes

Licenses

Technical Highlights

Unity Engine
Optimization Approaches
Multi-Threading
Custom Inventory Management System
Custom AI for creation of automation for workers
Custom Vision System
Design Patterns

Technical Details

Optimization Approaches

- Caching: caching was employed to reduce the frequency of GetComponent<>() and similar calls. This approach minimizes the overhead associated with frequent component lookups, a common performance bottleneck in Unity games.
- Multi-Threading: With the help of Unity's Job System, the load of Enemy and friendly units' AI is distributed to stop slowing the game's main thread. Also, I distribute the heavy load of the runtime NavMesh surface rebaking process before the runtime rebaking is removed from the game and Instantiating of Enemies' hoards.
- Layering: By modifying the collision matrix, I ensure that only layers that can collide with each other are considered for collision detection, thereby increasing the frame rates.
- LOD: Since the number of natural elements is considerably high, nature assets with built-in LOD have been selected.
- Data Structure: It may not seem immediately necessary in this game, but training in optimization for games that need every bit of efficiency is essential. Each time a data structure is required for a task, I carefully select the most optimized option. For instance, when both arrays and List<T> are suitable, I choose arrays due to their efficiency.

Custom AI & Vision System

The game involves three distinct types of AI systems: AI for peasants or workers, AI for friendly soldiers, and AI for enemies. The AI for workers requires a central management system assigning idle peasants (available workers) to jobs. These jobs are created when the player constructs a building that requires workers. Subsequently, the building enters a queue in the central management system, and available workers are assigned to it until no further workers are needed. The AI for workers is primarily focused on reaching their work location and ensuring that the appropriate working animations are displayed. Meanwhile, friendly soldiers are programmed to attack any enemy units within their range of view. As for the enemy AI, it is intentionally less sophisticated; enemies fixate on a specific target and do not differentiate between targets based on the threat level. The custom vision system is created based on a raycast that change its direction at each frame to ensure maximum vision within the vision range.

Design Patterns

Observer Pattern: Since the game involves multiple scenarios where many objects need to update an observer, the observer pattern is used to ensure the scalability and cleanliness of the code.
Singleton Pattern: Besides the Game Manager, there are several classes that act as central management systems for resource management and inventory, as well as a class that manages the job assignments of peasants. I use the singleton pattern to ensure that these management systems are easily accessible and efficiently handled throughout the game.

Unified Damaging System

Since the game features numerous objects that can be either killed or destroyed. To manage this, it employs a unified damage system, facilitated by an interface. This interface mandates that all damageable objects receive hits in a consistent manner. It ensures scalability and enforces uniformity in how damage is applied to all units, determining whether they are damaged or completely destroyed based on the amount of damage received and their remaining hit points.

Polymorphism and Class Hierarchy

To achieve a robust and scalable codebase, I have employed the principles of polymorphism and class hierarchies, ensuring that common functionalities are abstracted while allowing for extension and specialization where needed.
Unit Hierarchy: The abstract Unit class underpins all units, with the Soldier subclass introducing combat mechanics. Diverse soldier types, like Archers or Knights, inherit from Soldier, allowing for extensibility in combat unit variety. Additionally, the design allows for the seamless introduction of new unit categories, such as Giants, which would require unique features. These units would also be subclasses of the Unit class, forming new subcategories and expanding the game's diversity without the need for significant codebase changes.
Peasant Hierarchy: The Peasant base class is tailored to all worker units. Variations of peasants inherit from this base, providing a straightforward path for introducing new worker units.
Building Hierarchy: The Building base class encapsulates common features of all structures. This supports a wide range of buildings, from resource depots to barracks, enabling future expansion of our game's infrastructure.

Building Construction System

The building construction system requires the player to have sufficient resources to initiate construction. It ensures that the building being constructed does not overlap with other objects in the game environment. The newly constructed buildings are instantly available to be used.

Path Finding

The Unity NavMesh system is employed for this purpose. Although it offers significant advantages and is relatively easy to implement, it poses challenges due to the real-time baking of the NavMesh surfaces. Consequently, runtime baking is eliminated from the game, and NavMesh obstacles are used instead. This approach initially reduces the accuracy of the NavMesh, but after some fine-tuning, it becomes acceptable.

Problems & Solutions

Runtime baking of NavMesh Surface shutters main thread

The game employs a navigation system to move units across the map. The NavMesh surface component requires rebaking with each new building to prevent units from moving through the newly constructed building. As rebaking is CPU-intensive, it is offloaded to a separate thread using Unity's Job system, ensuring the game's main thread remains unaffected. Furthermore, the game map is divided into layers, allowing only the sections with new constructions to undergo rebaking. However, these approaches were not sufficient to ensure smooth gameplay, and sometimes, the parallel rebaking of the NavMesh caused glitches for the NavMesh agents. Consequently, all runtime rebaking was stopped, and instead, I added NavMesh obstacles to buildings. NavMeshobstacles do not create perfectly accurate holes in the NavMeshsurface, but they do the job in a way that does not have any effect on the gameplay.

Custom Vision System blind spots

Raycasts are the core element of the vision system mechanics. To address the issue of blind spots, the raycasts rotate in a circular manner to ensure they don't miss any enemies.

Ensure scalability and enable construction of multiple storages

To maintain scalability, the game features a central management system (CMS) that verifies resource availability before building construction or soldier training. All storages are connected to this CMS singleton, which acts as a hub for all observables affecting storage updates; these observables notify the CMS of changes, and it updates the relevant storage accordingly.

Multiple Objects should update UI & Resources

To ensure scalability and code cleanliness, the game uses the Observer pattern, allowing workers, select buildings, and unit creation to update both storages and the UI efficiently.

Assign & reassign idle peasants to buildings, new or destroyed

A central logical unit is responsible for managing these tasks. It tracks all newly spawned peasants and buildings requiring workers, and assigns workers to these buildings. Additionally, it ensures that a new soldier is created only if idle peasants are available.

A scene of the game that shows the game's environment

FIND ME @

Email LinkedIn GitHub