Combat Item Catalog / project hub
Systems Analysis & Design · Course Project

KoL Combat Item Catalog

KoLmafia (Mafia) is a community-maintained tool that adds quality-of-life features to the browser game Kingdom of Loathing. It already helps players manage equipment, consumables, potions, and buffs through the Modifier Maximizer, but nothing gives players the same insight into combat items. Information about these items is scattered across wiki pages, item descriptions, and player knowledge, and much of it is out of date. The proposed system is an independent, structured catalog of combat items, organized by categories and searchable properties such as elemental damage, restoration, combat effects, unusual behaviors, inventory quantity, and Mall price. It is designed for Mafia users, script authors, and wiki maintainers. The analysis and design work is mostly complete, and the remaining work is revision, feasibility analysis, and final integration.

The project

Purpose & direction

Problem statement

Combat items are hard to use intelligently

Players have to consider many factors before using a combat item, including what they own, how powerful it is, and how rare or valuable it is. Today they must look items up manually, guessing at the best option, or rely on wiki lists that are likely out of date. Because of this, it often feels easier to ignore combat items entirely. The lack of per-item insight also increases the risk of using up a reserve of expensive or limited-time items that can’t easily be replaced, such as Bottle of Fire. Players may also overlook a cheaper item they own in large quantity, or waste a banish on a monster they wanted to fight again. An information system is appropriate because the data is large, structured, changes with the game, and needs to be queried by both people and scripts.

Project vision

A structured catalog players and scripts can query

Vision: The system will give KolMafia users a structured catalog of combat items that lets them identify, categorize, and query items by their effects and other useful properties, so they can make better-informed decisions about how to use their inventory.

The initial build focuses on stat-based behaviors that are easy to quantify, such as damage and restoration, and looks for common patterns before adding categories for unusual items.

In scope
  • A combat item database with basic properties and effects, where an item can belong to more than one category
  • A companion script that queries by damage or restoration type, quantity owned, and current Mall price
  • A data validation (“spading”) script that helps verify the data
Out of scope
  • Integration into the Mafia codebase itself
  • Every possible combat-item behavior; damage and restoration come first
  • Non-combat items
Success looks like
  • Users can find items that perform a specific function
  • Similar items can be compared by quantity, strength, and Mall price
  • Scripts can read the catalog when making combat decisions
Design principle: start with clearly defined, stat-based item behaviors and a manageable catalog. Validate entries before expanding into harder-to-classify special cases.
Key dates

Major milestones

The next upcoming milestone is highlighted automatically.

MILESTONE 01Project hub live
MILESTONE 02Stories, use cases, requirements, ERD, data dictionary, and business rules revised
MILESTONE 03Feasibility analysis complete
MILESTONE 04Prototype feedback collected and business case sections complete
MILESTONE 05Revision memo complete
MILESTONE 06Draft final report complete
MILESTONE 07Narrated presentation complete
MILESTONE 08Final report, presentation, and memo ready to submit
System design work

Current deliverables

Status of each project artifact. Links are added as files are finalized.

01

Project Proposal and System Problem Statement

Complete, revising Open PDF ↗
02

System Vision, Scope Statement, and Stakeholder Analysis

Complete, revising Open PDF ↗
03

Requirements Gathering Plan and User Story Set

Complete, revising Open PDF ↗
04

Use Case Narratives and Functional Test Plan

Complete, revising Open PDF ↗
05

Process Model and Data Dictionary Revision

Complete, revising Open PDF ↗
06

Prototype or GUI Mockup with Design Rationale

Complete, revising Open PDF ↗
07

Development Approach Recommendation Memo

Complete, updating Open PDF ↗
08

Project Schedule, PERT/CPM Exercise, and Project Web Page

Complete Open PDF ↗
09

Feasibility Analysis

Not started Link added when finished
10

Final Systems Analysis and Design Report

Not started Link added when finished
11

Narrated Presentation

Not started Link added when finished
12

Final Revision Memo

Not started Link added when finished
Diagrams and prototype

Models & prototype

Select an image to open it at full size.

Context diagram with the KoL Combat Item Catalog at the center, connected to KolMafia users, KolMafia script authors, and KoL Wiki maintainers. Each group sends queries and receives matching combat item information.
Context diagram The catalog and the three groups that query it, with the queries each group sends and the results they get back.
Data flow diagram. Catalog maintainers submit item information that is validated and stored in the combat item catalog. Catalog queries are processed, optionally using live game data, and query results go to users, script authors, and wiki maintainers.
Process model (data flow diagram) How item data is maintained and validated, and how a query becomes formatted results.
The prototype screens (Search, Results, and Compare) are in deliverable 06 above. The data model is in deliverable 05.
Project management

Planning documents

Documents used to organize, schedule, and monitor the remaining project work.

01

Project Activity List

Major project activities, their descriptions, estimated durations, dependencies, and resulting deliverables.

Prepared for schedule development Open PDF ↗
02

Project Schedule

Planned start and finish dates, activity dependencies, overlapping tasks, deliverables, and completion status.

In progress; update as needed View on this page ↓
03

PERT/CPM Diagram

Activity sequence, dependencies, estimated durations, and the critical path used to identify schedule-sensitive work.

Complete; verify before submission Open PDF ↗
04

Milestone Plan

Major checkpoints for requirements and data-model revisions, feasibility, prototype review, report completion, and final submission.

Planned; review against assignment deadlines View on this page ↑
The activity list, schedule, and PERT/CPM diagram should agree on activity names, dependencies, and durations. Revise them together when the project plan changes.
October 25 – November 9

Project schedule

Weekends are working days. The chart and the table show the same plan.

Critical path (no slack) Has slack Done Buffer, Nov 10–12 (due Nov 12, 10:59 PM CST) Today
IDActivityStartFinishDependenciesDeliverableStatus
ABuild project hubOct 25Oct 25NoneProject hub with linksHub created
BReview completed project documentsOct 26Oct 26NoneRevision listUpcoming
CRevise user stories, use cases, requirementsOct 27Oct 27BUpdated stories, use cases, requirements, test checklistPlanned
DRevise ERD, data dictionary, business rulesOct 27Oct 28BUpdated data model and rulesPlanned
EFinalize process model and narrativeOct 29Oct 30DContext diagram, DFD, narrativePlanned
FRevise prototype screensOct 29Oct 30C, DUpdated clickable prototypePlanned
GPrototype review with 2–3 usersOct 31Nov 2FFeedback summaryPlanned
HFeasibility analysisOct 31Nov 1A, D, EFeasibility sectionPlanned
NBusiness case, recommendation, deploymentNov 2Nov 2HBusiness case and deployment sectionsPlanned
IUpdate development approach memoNov 3Nov 3G, HFinal recommendation memoPlanned
MWrite final revision memoNov 4Nov 4IRevision memoPlanned
JAssemble final reportNov 4Nov 6A, C, E, G, H, I, NDraft final reportPlanned
KPrepare narrated presentationNov 6Nov 7J (starts on final day)Narrated slide deckPlanned
LProofread and reviseNov 8Nov 9J, K, MFinal submissionPlanned

Dates are the planned dates for this project. Activities may overlap when dependencies allow. Mark an activity done by changing its status pill to state done; the progress bar at the top updates itself.

Finish strong

Final checklist & next steps

Check items off as you complete them. Your checks are saved in this browser.