Project Ogre
Why?
This game is largely a façade to create a system which generates interesting data for me to continuously learn. I use the data it generates to always have novel additions for final projects when I take continuous learning courses. As such, the UI is the tip of the iceberg. The UI interacts with a REST API . The subsystems behind the API are where much of my focus lies. There is an analytics pipeline and processes for procedurally generating, altering, and updating the game.
Screenshots
System Architecture
The front-end is written in Angular. I have been prototyping a Unity plugin for a "2.5D" graphics.
The back-end is a .NET API which interacts with a relational database. The overworld jobs are written as Azure Storage queues and/or jobs tables. The battle data is written to BLOB storage for consumption in an analytics pipeline.
A server-less function is triggered by the creation of a battle data BLOB file. These JSON files are turned into a batch of event messages for the Azure Event Hubs pub/sub resource. I have two working consumers of these messages:
Front-End
Prototypes
I have made several front-end prototypes for this project using different technology stacks as needed to learn for school or work.
C++ & SDL Prototype
Python & Django Prototype
C# & Unity Prototype
Typescript & Angular Prototype
Back-End
Procedural Generation of Character Classes, Weapons, Armor, and Spells
The game is driven by the data representing all of these game objects. The initial data is seeded procedurally using a Markov process. If the game designer (me) changes the parameters, the seed data is reconciled automatically during the app restart. In the future, I want to use AI/ML to learn how to tune this to achieve a balanced game. That is where the data processing back-end of the system's architecture comes into play.
Skirmish Replay System
The auto-combat system from Ogre Battle is enhanced within this game to contain most elements from modern MMORPGs (character resource systems, spell selection, targeting, area of effects, damage/healing over time, buffs/de-buffs, spellcasting interrupts, etc.) while honoring the high-level approach to Ogre Battle's skirmishes. This data feeds into the analytics pipeline.
Game Balance Analytics Pipeline
All of the battle data is persisted as files within Azure Storage. The creation of these files triggers a "server-less" function to parse the data and queue it for processing in the analytics pipeline. This data will be used by the game designers for analytics and any AI/ML in the future.
Overworld Generation
The overworld creation is not included in the live demo, yet. It is an iteration of another project which you can find details of here.
Inspiration
This project was inspired by Ogre Battle: The March of the Black Queen (1993) on Super Nintendo.
Character & Unit Customization
Autonomous Battles
District & Overworld Maps
Development Process
I believe in a test-first Agile SDLC. My backlog contains vertically-sliced product increments which I prioritize and then complete an entire design->develop->test cycle for that increment. I add to the UI, API, and data layers as necessary to solve the problem at hand adding automated testing as I go. I emphasize a test pyramid with unit tests as the base through SOLID OOP and a dash of end-to-end tests as needed to prove the requirements are fulfilled. After each increment, I demo the progress to a user group, gain feedback, and adjust.
Product backlog items (PBIs) solve a problem for the user which adds business value. Technical debt is paid off as tasks within user stories to prevent diminishing returns on development output as a product of time. PBIs are not a wish list of technical solutions to hypothetical problems. In this context, I am adding elements to the game, but I manage other projects in a similar fashion.
