Pokémon Unite Build Tracker
Project information
- PlatformWeb
- ToolsASP.NET, C#
- Duration2 months
- Medium Blog
- Github Project
Pokémon Unite Build Tracker is a web application created using ASP.NET Core MVC to help players optimize their gameplay in Pokémon Unite, a 5v5 MOBA where players control Pokémon with unique abilities and equip three held items pre-game to enhance their stats. The app allows users to create, view, and manage builds for various Pokémon, offering a personalized alternative to external resources like UniteDB. Designed as a mockup, it combines gaming strategy with web development to provide a streamlined solution for tracking and experimenting with item combinations.
Initial Concept Doc
Process
Step 1 — Entity Framework and Model Design
Click here for detailed process!
To start the Pokémon Unite Build Tracker, I created a basic MVP to calculate stats after adding items. I set up Entity Framework using a code-first approach to simplify database handling. The core models are Pokemon, HeldItem, and BattleItem. The Pokemon class includes base stats, role/style info, and image links, with many-to-many relationships to items.
The HeldItem and BattleItem models have IDs, names, images, stat boosts, and are linked to Pokémon.
DTOs
For each model, I created corresponding DTOs (PokemonDTO, HeldItemDTO, BattleItemDTO). These DTOs serve several purposes:
- Data encapsulation
- Improved performance by transferring only necessary data
- Flexibility in API responses
Step 2 — LINQ and Data Transfer Objects
Click here for detailed process!
In this step, I built out the API layer for the Pokémon Unite Build Tracker using LINQ and DTOs to manage data efficiently. I created controllers for Pokémon, Held Items, and Battle Items, each with endpoints to list, find, create, update, and delete entries.
The actual data operations are handled using LINQ within service classes, providing clean, readable queries. DTOs help shape the API responses, exposing only necessary fields and simplifying complex entity relationships.
All API methods are fully asynchronous for better performance, with basic error handling (e.g., NotFound(), BadRequest()) and tested via Swagger UI.
Step 3 — Services and Relational CRUD
Click here for detailed process!
In this step, I created service interfaces for Pokémon, Held Items, and Battle Items, defining clear contracts for listing, finding, creating, updating, and deleting. These interfaces enable dependency injection and keep the architecture clean and scalable.
Each service interface was implemented using Entity Framework Core and LINQ to perform async database operations like ToListAsync, FindAsync, Add, and Remove. Data is mapped to DTOs, ensuring consistent and secure data transfer between layers.
Basic error handling is built in (e.g., null checks, entity existence validation, try-catch for concurrency). Services remain asynchronous and loosely coupled, promoting maintainability and responsiveness across the application.
Step 4 — ViewModels & Relational UI
Click here for detailed process!
In this step, I introduced ViewModels to better shape the data for UI rendering. These ViewModels act as a middle layer between the data models and views, allowing for a clean, UI-specific structure. I created PokemonViewModel, HeldItemViewModel, and BattleItemViewModel, each containing the key properties required for display and input validation. These were integrated into the view logic to streamline data flow and improve user interaction with forms and data listings.
The PokemonController was enhanced to support relational CRUD by managing Pokémon along with their associated items. A new CreateBuild action was added to allow users to create builds by selecting a Pokémon, Held Items, and a Battle Item. It dynamically loads available items via API calls and calculates total stats for the build. Error handling and validation were implemented to ensure robust user input and handle network failures gracefully, enhancing both functionality and user experience.
