Sergio Pulido

About

An isometric, single-player RPG where you control five characters simultaneously to conquer challenging bosses, bringing the MMO group experience to solo play.

Info

Role: Designer/Lead programmer

Team size: 2

State: In development

Time frame: undefined

Introduction

Orion is my innovative approach to bringing the dynamic combat experience of MMOs to a single-player, offline environment. In Orion, a single player takes command of a group of five characters, each with distinct roles and advantages. The game distinguishes itself by allowing players to queue up actions that can be implemented while the game is paused, placing the main focus firmly on strategic decision-making rather than quick reflexes.

Orion has been an exciting journey that has not only brought this unique concept to life but has also enabled me to craft a wide array of in-house tools from the ground up. These tools, ranging from data storage and retrieval to an intricate aggro system, stat modifiers, temporal status effects, dynamic inventories, and responsive UI, have been instrumental in shaping the rich gameplay experience Orion offers.

This project has also been a platform for honing my skills in creating custom editors for Unity's MonoBehaviour classes and scriptable objects, effectively bridging the gap between code and design. By streamlining variable assignments based on class use, it has elevated the project's efficiency and overall quality.

Additionally, Orion has provided an exciting opportunity to implement a bespoke procedural generation algorithm. This algorithm empowers designers to craft prefabricated rooms and seamlessly integrate them into the game world based on its structure. Set in an isometric environment, Orion features multiple biomes, enriching the gaming experience.

In sum, Orion has been a cornerstone of my professional growth, equipping me with enhanced skills in backend content creation and a profound understanding of diverse design architectures. These skills position me as a valuable asset for implementing and maintaining a wide range of internal game subsystems.

Map generation

Map generation in Orion can be done both procedurally or manually. Most levels are generated procedurally in order to improve the length and difficulty of the game. However, for special events in the game, rooms are handcrafted. Procedural level generation is done through the creation of complex and interconnected level layouts. It operates based on predefined room types and their connections. Its main features are the following:

Palette-Based Room Selection: The algorithm uses a predefined palette of room types, allowing the designer to create a variety of rooms that can be used to build the level.
Connection logic: It places rooms in a way that ensures logical connections between them. The algorithm considers the number of doors (connections) in each room and makes decisions based on these connections to ensure that rooms are placed in a logically connected manner.
Randomization: Randomization is a fundamental part of the algorithm. It selects a starting room randomly and also selects candidate rooms for connections randomly, providing variety in the generated level layouts.
Iterative generation: The algorithm operates in an iterative manner, generating rooms and connections step by step. It continues generating rooms until specific conditions are met, ensuring that the level is complete and well-connected.
Dynamic room copying: The algorithm dynamically copies rooms onto the level, aligning them with the grid and tilemaps to create the level layout.
Seed option: It offers an option to use a random seed or a specific seed number for reproducible generation.
Efficiency and Optimization: The code is designed with efficiency in mind, including checking for previously filled areas to avoid unnecessary room duplication.
Parameter Configuration: The designer is able to configure parameters such as the number of rooms to generate, the origin tile for starting placement, and the palette of room types to use, providing flexibility in defining the level's characteristics.
Multilevel Support: The code supports the generation of multi-level levels by iterating over individual tilemaps to create complex level layouts.

Procedural generation of 100 and 500 rooms, respectively.

What I've learned...

Subsystems

While my approach to Orion's subsystems may not be groundbreaking, I take pride in the fact that they are my own creations. These subsystems are designed with a modular structure and a commitment to SOLID principles, which ensures their flexibility and ease of maintenance. Below, you can explore some of the key subsystems utilized in Orion.

Save System

Effective data management is the backbone of seamless gaming experiences. Orion's Save System offers a well-structured approach to storing and retrieving player progress. It consists of two key structures: Settings data and Progress data.

The save system consists of two structures: Settings data and Progress data.

Settings are shared globally among all save files in the game, while Progress saves specific information for each playthrough of Orion.

Data is serialized as a JSON file, encrypted, and saved locally.

Future plans include implementing cloud-based saves for enhanced security against player manipulation.

A Data Migration class is available to convert old save files to the latest game version.

Inventory System

The Inventory System in Orion is a vital component, providing efficient item management for players. It is designed to enhance the gameplay experience by offering streamlined storage and retrieval of in-game items.

Item and Inventory Structure: The system is built around two main components: items and inventories.

Abstract Item Class: Items are represented by the abstract Item class, which allows for dynamic properties like the quantity of items held, as well as static properties defined through a scriptable object, such as their name, description, and type.

Efficient Linking: Each item is assigned a unique ID, simplifying the connection with its scriptable object without the need to save all static properties, thereby improving storage efficiency.

Type-Specific Inherited Classes: To maintain modularity, we've implemented an inherited class for each type of object (e.g., supply, loot, or equipment).

Inventory Slots: Inventories are made up of slots, each indicating the item currently stored within. This structure allows for the creation of functions for each inventory, which in turn call functions for each slot, ensuring an efficient and organized use of the inventory system.

Threat Management

In the world of game development, an effective threat management system can define the intelligence of enemies and their decision-making. In Orion, we've implemented a robust threat management system inspired by MMOs.

Strategic Decision-Making: Each enemy in Orion maintains a list of player characters and the level of threat they pose. This threat assessment is dynamic, depending on the actions taken by each character. In most scenarios, enemies prioritize targeting characters that represent the highest threat to them.

Dynamic Threat Generation: Our system ensures that combat actions generate threat. When a player character inflicts damage, the enemy experiences an increase in threat. Conversely, healing actions generate threat among all active enemies, making healers a tempting target.

Protecting Vulnerable Allies: Some character abilities are designed to generate threat strategically, safeguarding more vulnerable team members. This dynamic element enhances the tactical depth of the game.

Efficiency and Accessibility: Orion's threat management system is expertly handled through a singleton using graph theory. This design choice ensures not only efficiency but also ease of access, contributing to a seamless gaming experience.

Preview of the current state of Orion's HUD.