Pixel Art Game
Work in ProgressA Pokemon-style interactive game where visitors explore a pixel art world to discover my career story. Walk through themed buildings, talk to NPCs, and navigate a world that represents 15 years of building products.
This is the most ambitious project on the site — and the most honest page about it. Here's what works, what doesn't, and what I learned about the limits of AI-assisted game development.
Play the current versionWhat Works
- Grid-based character movement with 4-directional walking
- Overworld map with themed buildings (Innovation Labs, Leadership Tower, Tech Hub)
- Building interaction system — walk up, press Enter, get dialogue
- Pokemon-style dialogue box with professional content
- Animated water with wave effects
- Mobile touch controls (D-pad overlay)
- Dynamic loading via Next.js dynamic import (no SSR for Phaser)
Walls Hit
Building a game inside a web framework designed for documents is full of friction. Here's every major problem encountered — solved or not.
Phaser.js + Next.js SSR conflict
SolvedPhaser requires the DOM and window object. Next.js server-renders by default. Every Phaser import crashed the build. Solution: dynamic(() => import(...), { ssr: false }) wrapper. Took multiple iterations to get right.
Programmatic sprites look amateur
OpenThe initial approach generated pixel art via HTML5 Canvas at runtime — colored rectangles for buildings, basic shapes for the character. It works technically but looks like a prototype, not a portfolio piece. Professional tilesets are needed.
Character sprite proportions
OpenAI-generated pixel art characters kept having wrong proportions — heads too big, limbs misaligned, walk cycles that looked robotic. Pixel art is a specialized skill that current AI tools struggle with at small sprite sizes (16×16, 32×32).
Tileset consistency
OpenMixing programmatic sprites with hand-drawn or AI-generated tiles creates visual inconsistency. Everything needs to share the same palette, pixel density, and art style. This requires either commissioning a tileset or finding a cohesive free pack.
Mobile performance
ManagedPhaser.js game engine running inside a React app inside a mobile browser is three layers of overhead. Touch controls need to be responsive without interfering with browser gestures (scroll, back swipe). Ongoing tuning.
Name attribution in forked assets
SolvedThe game was initially forked from another developer's portfolio. Original names were embedded deep in sprite filenames, frame references, and game config. Required a full audit to rename every reference — 15+ files touched.
Technical Decisions
Phaser.js over CSS animations
Needed real game mechanics: collision detection, sprite management, camera following, tile maps. CSS can't do this.
Dynamic import, no SSR
Phaser needs window/DOM. Wrapping in dynamic(() => import(), { ssr: false }) isolates it from Next.js server rendering.
Programmatic sprites (for now)
Faster to iterate than managing sprite sheets. Will replace with professional assets once the game mechanics are solid.
Separate /game route
Game is heavy (~200KB component). Isolating it prevents impact on homepage load performance and SEO.
Architecture
Game Engine
Phaser.js 3Handles rendering, physics, input, sprites, camera. Runs in a canvas element inside the React tree.
React Wrapper
Next.js dynamic importHomepageGame component (208 lines) loaded client-side only. Manages Phaser lifecycle within React.
Assets
Programmatic (Canvas API)Sprites generated at runtime via Canvas. No external sprite sheets yet — this is the main quality bottleneck.
Interaction
Keyboard + TouchArrow keys on desktop, virtual D-pad on mobile. Enter key triggers building dialogues.
Roadmap
- ○Professional tileset — cohesive 16-bit art style
- ○Proper character sprite with smooth walk animation
- ○Interactive career exploration — enter buildings to learn about each role
- ○NPC dialogues with career highlights
- ○Sound design — ambient music, interaction sounds