Wameedh Mohammed Ali
Case study · Side project

Deadlock Items Build

A side project that recommends item builds for the game Deadlock, with an LLM doing the recommending and a full stack behind it.

Role
Full stack engineer, solo
When
2024 to now
Stack
React, TypeScript, Redux, Python, PostgreSQL, Supabase, AWS, Amazon Bedrock, Llama 3.2
Links
deadbuildlock.com

The problem

Deadlock is a team shooter with a deep item system. New players lose games because they buy the wrong items, and the guides they find are out of date the week after a patch. I wanted a tool that could answer "what should I build right now, for this hero, against this lineup" and stay current without me rewriting it every patch.

What I did

Front end. A React and TypeScript application with Redux for the build state, so a player can pick a hero, describe the match, and get a build they can edit.

Back end. A Python service on AWS with PostgreSQL through Supabase for items, heroes, and saved builds.

Recommendations. The build suggestions come from a large language model, Llama 3.2 through Amazon Bedrock, prompted with the current item data rather than trained on it. That is the part that keeps the tool current: when a patch changes items, the data changes and the model reasons over the new data.

What made it hard

Keeping the model honest. A language model will happily recommend an item that no longer exists. The fix was to ground every recommendation in the live item table and reject anything the model invents.

Result

The tool is live at deadbuildlock.com and is the project I use to try ideas I cannot try at work: retrieval, prompt design, and the shape of a product where the interesting logic lives in a model.

What I'd do next

Add match-history import, so the recommendation starts from what a player actually does instead of what they say they do.