About Neon Arcade

Neon Arcade is an independent one-person studio run by Jayden Hwang. Every game on this site is built in-house with vanilla JavaScript and HTML5 Canvas — no engines, no licensed content, no third-party game feeds. If you are playing it here, it was written here.

That last part is worth spelling out, because most sites shaped like this one are not that. The usual browser-games site is a directory: a page of thumbnails wrapped around other people's games loaded from a feed, where the site itself has added nothing you could point at. Every game here is served from this domain because it was made for it, and each one ships with the thing a directory cannot supply — a page explaining how it plays and why it is built the way it is.

What the games are trying to be

The goal is narrow on purpose: short, finished games you can play in a browser tab without downloading anything, making an account, or waiting through a launcher. They are meant to be understood in about ten seconds and to keep being interesting after that, which is a harder constraint than it sounds and rules out most ideas.

How they get made: each game starts as one mechanic that seems worth ten minutes. Most do not survive being playable. The ones that do get a control scheme that works with a thumb as well as a keyboard, because roughly half of everyone who plays these arrives on a phone. The newest game, Feltling, breaks the pattern deliberately — it has no score, no timer and no failure state, and it is the direction the rest of the site is heading.

Nothing ships without passing the gates

Publishing a game here is not a matter of uploading a file. A build script runs every game through a set of automated checks and refuses to produce the site if any of them fail. It loads each game in a real headless browser at phone resolution and measures: how long it takes to become playable, whether the canvas is actually drawing anything, whether the frame rate ever collapses, whether the heap grows the way a memory leak grows, whether the touch handlers exist, whether the playing field keeps phone proportions on a desktop monitor, and whether the game responds to input at all. Separately it checks the page around the game: a single H1, a canonical URL, a share image, structured data that parses, a description within the length a search engine will actually show, and at least two real questions answered in the FAQ.

None of that list was designed up front. Every item was added the day the corresponding mistake was found in production — a game that silently rendered a blank canvas, a thumbnail captured one second before the game became legible, a set of pages that all claimed to be the same page. The long version is in the dev notes.

How this site is made, honestly

The games, the build system and the words on these pages are the work of one person, and the design decisions — what a game is about, what gets cut, what counts as good enough — are made by that person. AI coding tools are part of the toolchain here, the same way a compiler or a linter is: they draft and refactor code that is then read, tested and accepted or thrown away. Nothing is published without being played. Saying so plainly seems better than leaving you to guess.

The stack is deliberately small: no framework, no bundler, no runtime dependencies in the games themselves. Each game is a single self-contained HTML file. The site around them is generated by a Node script into static files and served as plain HTML. The full list of what is used, and where every asset came from, is on the credits page.

Get in touch

Questions, bug reports or business enquiries: see the contact page. Bugs are genuinely welcome — a game with a broken hitbox is worth more to me reported than politely ignored. If you would rather read than play, the dev notes cover the parts of this that were hardest to get right.