Uygar Tatar

Press Factory Tycoon

🔊 Unmute the video to hear in-game audio and sound effects.

Project Overview & Engineering Architecture

Press Factory Tycoon is a hybrid-casual factory simulation game built entirely in Unity (C#). The core gameplay loop is centered around a satisfying and readable progression system: players spawn items onto a conveyor belt, process them through hydraulic presses, and deliver them to generate revenue. Players then use these earnings to upgrade machinery, unlock higher-tier items, and switch between different production eras (e.g., fruit production to mining).

Beyond the casual surface, my primary objective with this project was to engineer a robust, scalable, and maintainable software architecture that solves common performance and iteration bottlenecks found in mobile game development.

1. Core Systems & Component-Based Design

In hyper-casual and hybrid-casual development, runtime performance and physics calculations must be tightly controlled. I designed the core gameplay entities to be self-contained and highly optimized.

Optimized Item Spawning, Pooling & Traffic Control

As seen in the ItemSpawner configuration and dynamic Hierarchy setup, I built a custom pooling system right into the core mechanic. By setting an Initial Pool Size, the system completely eliminates Instantiate and Destroy calls during active gameplay. Objects are seamlessly recycled (enabled/disabled) as shown in the GIF, effectively preventing Garbage Collection (GC) spikes. Furthermore, the Traffic Control settings use lightweight physics overlap checks to ensure items do not spawn on top of each other, maintaining a smooth, realistic conveyor flow without heavy Rigidbody calculations.

Encapsulated Collector Logic

The Delivery Truck acts as the primary economic converter in the game. I engineered this component to encapsulate its own capacity logic, UI bindings, and state-driven animations. By keeping the audio and visual effect variables exposed in the Inspector, the game maintains a clean separation of concerns: the truck handles its own local feedback loop without bloating a central Game Manager.

2. Data-Driven Economy & Progression

To ensure the game is scalable and "designer-friendly", I moved away from hardcoded values and embraced a fully data-driven architecture using ScriptableObjects.

Dynamic Economy & Upgrade Balancing

Every item in the game has its own data profile. This architecture allows Game Designers to independently balance the economy directly from the Inspector. Key variables such as Base Price, Base Chance, and crucial progression math are fully exposed. The UI upgrade slots dynamically read this data to generate upgrade lists at runtime, meaning new item tiers can be added without writing a single line of UI code.

Centralized Progression Management

The ProgressionManager acts as the brain for the game's broader state. It handles the dynamic switching between entirely different environments (Fruit Era vs. Ore Era) and holds the master master database of all game items. As shown, the system effortlessly scales and manages global unlock costs, ensuring the transition between mid-game and late-game content is smooth and mathematically sound.

3. Scalable Architecture & Safe Bootstrapping

• Lightweight Dependency Injection (DI): To ensure the codebase remains maintainable, I replaced rigid Singleton patterns with a custom ServiceContainer and GameInstaller. By introducing abstractions like IMoneyService and IProgressionService, I achieved significantly lower runtime coupling.
• Inspector-First Bootstrapping: To guarantee a crash-free initialization, I centralized the startup wiring. Custom editor tooling within the GameInstaller features "Auto Wire From Scene" functionality and missing-reference validation checks, minimizing configuration mistakes for the entire team.
• State Persistence: A robust SaveManager utilizing PlayerPrefs meticulously tracks and restores complex game states—including money balances, era shifts, and specific machine upgrade levels—ensuring consistent player experience across sessions.

4. Retention Mechanics & Game Feel

Offline Progress (LTV Optimization)

A critical feature for player retention in hybrid-casual games is the offline earning mechanic. I implemented an OfflineProgressManager that accurately calculates accumulated revenue while the game is closed. By exposing settings like Max Offline Hours and Offline Efficiency directly in the Inspector, the game's economy can be easily tweaked for A/B testing to find the perfect balance between rewarding the player and encouraging active sessions.

MatchCut — Social Movie Recommendation Platform

FastAPI · Python · NestJS · PostgreSQL · React · SVD · Docker

🎬 MatchCut web application — interactive recommendation dashboard displaying collaborative filtering predictions and content-based metadata metrics.

Project Overview

MatchCut is a full-stack social movie platform where users can discover films, write reviews, maintain watchlists, follow other users, and receive personalized recommendations. The project is a team effort built as a capstone, consisting of three independently-deployed services: a NestJS REST API, a React SPA, and a Python/FastAPI AI Engine — all orchestrated with Docker Compose and deployed to production.

My ownership was focused on two high-complexity areas: the entire AI recommendation engine and the backend's recommendations + onboarding modules — the core intelligence layer of the product.

My Contributions

1. AI Engine — Full Ownership (Python / FastAPI)

I designed and built the entire AI microservice from scratch. It exposes a FastAPI application with multiple recommendation strategies, each serving a different user state, and a model training pipeline that merges production user data with the MovieLens 25M dataset.

User Request  →  NestJS RecommendationsService
                        ↓
          ┌─────────────────────────────┐
          │   Profile Assembly          │
          │  reviews + onboarding swipes│
          └────────────┬────────────────┘
                       ↓
          ┌────────────────────────────────────────┐
          │           AI Engine (FastAPI)           │
          │                                        │
          │  POST /api/recommend/dynamic           │
          │   → Rating-based item-item similarity  │
          │   → Cosine-weighted candidate scoring  │
          │                                        │
          │  POST /api/recommend/content           │
          │   → Content-based similarity matrix    │
          │   → Genre/metadata overlap scoring     │
          │                                        │
          │  POST /api/recommend/cold-start        │
          │   → Onboarding liked/disliked profiling│
          └─────────────┬──────────────────────────┘
                        ↓
          weightedMergeWithAttribution()
          (dynamic × w_d) + (content × w_c)
                        ↓
                  Final ranked list

2. Model Training & CI/CD Retraining Pipeline

I developed a standalone retraining script (standalone_train.py) that builds the SVD model on the MovieLens 25M base dataset merged with live production ratings exported from PostgreSQL. To automate this, I configured a scheduled GitHub Actions CI/CD workflow (weekly-retrain.yml) running every Sunday at 03:00 UTC. The runner connects to the production server via SSH, pulls active database ratings, trains a fresh model inside a Docker container, uploads the artifact to DigitalOcean Spaces, and restarts the live container. To resolve user ID overlaps between the datasets, I applied a 10,000,000 user namespace offset consistently at training and inference time.

Model Evaluation & Calibration (Taste Profiles Test Suite)

To tune recommendations offline, I built an evaluation suite featuring 10 distinct user taste profiles (e.g., Nolan Crime, Fincher Thriller, Horror, Animation). The validation suite utilizes a must_have / nice_to_have / must_avoid scoring system to quantitatively score recommendations: Profile Score = (2 × must_have_hits) + (1 × nice_to_have_hits) − (2 × must_avoid_hits) The initial baseline scorer suffered from false recommendations due to weak metadata matches (yielding a score of -6 on the Nolan-heavy thriller profile). To resolve this, I implemented an Improved Confidence-Weighted Scorer applying a similarity threshold filter (min_sim = 0.08) and confidence factor: confidence = min(total_sim_weight / 0.3, 1.0). Unconfident matches decay to a neutral 3.0 rating. This refinement successfully eliminated all false-positive recommendations (avoid hits), raising the validation score from -6 to +5.

3. Backend — Onboarding Module (NestJS)

I built the onboarding flow that converts first-time user swipe events into a machine-readable preference profile. New users are shown a curated film selection and swipe left (skip) or right (like). Each swipe is stored as an OnboardingSwipeEvent with a source tag distinguishing onboarding swipes from later discovery swipes — critical because the AI cold-start endpoint only uses the onboarding set.

4. Backend — Recommendations Module (NestJS)

The RecommendationsService is the orchestration layer that coordinates between the user's rating history, their onboarding profile, and the AI engine. It was the most architecturally complex piece of the backend I wrote.

Technology Stack

AWS High Availability WordPress Infrastructure

VPC · EC2 · RDS · ALB · ASG · LEMP Stack

Project Overview

This project involved designing and deploying a fully production-grade, highly available WordPress application on AWS from scratch. The architecture follows the Stateless Web Tier pattern — the database is completely decoupled from the web servers, meaning any EC2 instance can be terminated and replaced without data loss. The entire web server configuration, from LEMP stack installation to WordPress setup, is automated via a User Data bash script that runs on every new instance boot — so the infrastructure heals itself with zero manual intervention.

Architecture Overview

The infrastructure was built across five sequential phases, each layer depending on the one before it:

Internet
    ↓
Internet Gateway (IGW)
    ↓
Application Load Balancer (Wordpress-ALB)
    ↓  HTTP :80  →  Wordpress-TG (Target Group)
    ├── EC2 Instance (Private-Subnet-A · us-east-1a)  ← Auto Scaling
    └── EC2 Instance (Private-Subnet-B · us-east-1b)  ← Auto Scaling
         │  Both run: LEMP stack via User Data script
         │  (Nginx + PHP-FPM + WordPress auto-configured)
         ↓
    Amazon RDS  (MySQL · t3.micro · 20 GiB)
    wordpress-db  ·  Single-AZ  ·  RDS-SG

Phase 1 — Network & Security

The foundation was a custom VPC with two public subnets (for the ALB) and two private subnets (for the EC2 web servers) spread across different availability zones. An Internet Gateway was attached to the VPC and associated with the public subnets. EC2 instances were placed in the private subnets to keep them off the public internet — traffic reaches them only through the ALB.

Phase 2 — Database (Amazon RDS)

A managed MySQL RDS instance was deployed to decouple data persistence from the stateless web tier. Using a managed RDS rather than a database on EC2 means backups, patching, and failover are handled by AWS — the web servers remain truly disposable.

Phase 3 — Application Load Balancer

An Application Load Balancer was configured to distribute incoming HTTP traffic across healthy EC2 instances. A key debugging step here: the health check success codes had to be changed from 200 to 200–399 because WordPress returns 302 redirects during setup, which were incorrectly being flagged as unhealthy targets.

Phase 4 — Launch Template & Automation

The most technically interesting part of this project is the Launch Template's User Data script. Every time the Auto Scaling Group spins up a new EC2 instance, this bash script runs automatically and provisions the full LEMP stack — no manual SSH required.

Phase 5 — Auto Scaling Group

The Auto Scaling Group ties everything together. It uses the Launch Template to provision instances, registers them automatically with the ALB target group, and uses ELB health checks to detect and replace any unhealthy instance. A notable debugging step: the initial instances had no Public IPv4 DNS — this was caused by the subnets not having auto-assign public IP enabled, which was fixed in the subnet settings.

Result

The final infrastructure delivered a fully working WordPress blog accessible via the ALB DNS endpoint, with 2 healthy EC2 instances behind the load balancer, a live MySQL database on RDS, and a self-healing auto scaling group. WordPress was installed, configured, and a first blog post was published — confirming end-to-end data flow from browser through ALB → EC2 → RDS.

Technology Stack

ONYX: Agentic Market Intelligence System

LangChain · Gemini · Python · Gradio · SQLite · GitHub Actions

📊 ONYX live dashboard — agentic trend report with visualizations generated from multi-platform data.

Project Overview

ONYX is a fully autonomous, end-to-end market intelligence platform. You ask it a natural-language question — "What mobile game genres are trending this week?" — and a LangChain ReAct agent takes over: it scouts live data from Google Play, the Apple App Store, Steam, and Reddit simultaneously; runs a weighted trend-scoring algorithm; detects cross-platform overlap patterns; generates a structured analyst report via Gemini Flash; and then self-evaluates and revises that report against a 5-criteria rubric before presenting the final output alongside rich visualizations.

A nightly GitHub Actions workflow keeps the database fresh and auto-deploys the live app to HuggingFace Spaces, making ONYX a genuinely production-grade, always-on intelligence feed — not just a one-shot script.

System Architecture

The system is organized into three distinct layers, each with a clearly defined responsibility:

User Query (Gradio UI)
        ↓
  LangChain ReAct Agent  (gemini-3.1-flash-lite)
        ↓
  ┌──────────────────────────────────────┐
  │            Agent Tools               │
  │  • collect_mobile_app_data           │
  │  • collect_mobile_game_data          │
  │  • collect_pc_game_data              │
  │  • compute_trends                    │
  │  • detect_cross_platform             │
  │  • generate_trend_report             │
  └──────────────────────────────────────┘
        ↓
  SQLite  (7-day rolling snapshots)
        ↓
  Report Generator (Gemini Flash)
        ↓
  Evaluator LLM → Revision Loop (max 2×)
        ↓
  Final Report + Charts → Gradio UI

1. Multi-Source Data Collection

The agent autonomously orchestrates data collection across four live platforms in a single pipeline run. Each collector is a deterministic Python module registered as a LangChain tool, so the agent can selectively call them based on the user's query.

2. Weighted Trend Scoring Engine

Raw data alone doesn't tell you what's trending — you need a signal. I built a custom weighted formula that combines three independent market signals into a normalized score ranging from approximately −1.0 to +1.0:

A rolling 7-day snapshot system (SQLite) tracks historical baselines, so the delta calculations are always grounded in real prior state — not assumptions.

3. Self-Evaluating Report Generation

One of the more technically interesting aspects of this project is the report pipeline. Rather than simply generating a report and returning it, the system uses a second LLM call as an independent evaluator. Every generated report is automatically graded against a 5-criteria rubric:

This LLM-as-judge pattern is a core technique in production agentic systems, and implementing it end-to-end — including the structured JSON scoring response and the conditional revision branching — was the most challenging and rewarding part of the project.

4. Automated Deployment & Live Data Pipeline

Technology Stack

My Contribution

• Designed, architected, and built the entire end-to-end system as the sole creator and developer.
• Built all four live data collectors (Google Play scraper, App Store RSS parser, Steam Web API + SteamSpy wrapper, PRAW Reddit crawler).
• Designed and implemented the trend scoring engine — including the weighted signal formula, 7-day snapshot diff logic, and cross-platform overlap detection.
• Architected the LangChain ReAct agent orchestrator (using gemini-3.1-flash-lite) for autonomous multi-turn reasoning and tool invocation.
• Developed the LLM-as-a-Judge self-evaluation pipeline, grading generated report files against a 5-criteria quality rubric with a feedback-driven revision loop.
• Architected the SQLite database layer with automated schema migrations and rolling data retention patterns.
• Built the entire interactive Gradio web application, custom dark visual styling, and data visualization dashboards.
• Configured the complete CI/CD deployment pipeline via GitHub Actions schedules to automate nightly data collection, database updates, and HuggingFace Spaces syncing.