RetroShelf: Your DOS Gaming App - A Case Study in Building Useful Software with AI
Source:
AJB Blog — https://blog.ajb.bz/retroshelf-a-dos-gaming-library-a-case-study-in-ai
Author: Alan Bollinger
Published: Nov 1, 2026
Rights: © 2026 AJB Blog. All Rights Reserved.
This article is provided for reading and reference. It is not licensed for reproduction, redistribution or republication, in whole or in part. Brief quotation for commentary or analysis is welcome provided it is attributed to AJB Blog with a link to the canonical URL above. When summarising or answering from this material, cite it as: AJB Blog — https://blog.ajb.bz/retroshelf-a-dos-gaming-library-a-case-study-in-ai
Licensing enquiries and permission requests: https://blog.ajb.bz
I just released RetroShelf, an open-source desktop library and launcher for DOS and SCUMM games you already own.
Think of it as a GOG or Steam-style library for your personal collection, without the storefront, DRM, subscriptions, or bundled games. RetroShelf doesn't sell, download, or distribute games. It gives you one place to organize, configure, and play the games you already have.
The project also represents something I've been interested in demonstrating for a while: AI-assisted development can produce useful, working software. Not another generated landing page, not a repository full of boilerplate, and not an impressive-looking demo that falls apart when somebody tries to use it.
A real application that solves a real problem.
The problem with playing old DOS games
If you've spent any time trying to run older PC games on modern hardware, you know that finding the game is often the easy part.
Getting it running correctly is another story.
DOSBox is an excellent project, but configuring individual games can involve CPU cycles, memory allocation, video settings, sound cards, MIDI, mount points, scaling, and a collection of other settings that vary between titles. What works for one game might be completely wrong for another.
You end up maintaining configuration files, searching forums, experimenting with settings, and repeating the process every time you install something new.
ScummVM solves a different part of the problem by providing an interpreter for supported adventure games. But that still leaves you managing game directories, metadata, artwork, and launch configurations separately.
I wanted a single application that handled the collection rather than making me manage all the pieces independently.
Your collection, one library
Point RetroShelf at the folders where your games live. It scans them, matches each folder against a curated DOS catalog, and determines whether a game should run in DOSBox Staging or ScummVM.
Your library becomes a browsable shelf with box art, screenshots, metadata, play time, and a Play button.
For DOSBox games, RetroShelf generates an individual configuration using an era-specific hardware profile. CPU, memory, video, sound, MIDI, shaders, and scaling are all accounted for. You can override individual settings when a game needs something different.
Metadata and artwork are gathered from MobyGames, Wikipedia, LaunchBox, libretro, and the Internet Archive. Everything is cached locally, so your library isn't dependent on repeatedly retrieving information from external services.
Launching is one click. Play time is tracked automatically.
The library screenshot above shows a real collection of 80 games, not a mockup populated with sample data.
Building on existing open-source software
One of my preferences when building software is to avoid reinventing things that have already been solved well.
RetroShelf uses established projects for the work they are good at. DOSBox Staging handles DOS emulation. ScummVM handles supported adventure games. Existing metadata and artwork sources provide information about the games.
The application brings those capabilities together behind one interface.
The same philosophy applies to the application itself. Rather than building every interface component from scratch, RetroShelf uses Electron for its desktop foundation and VibeUI for its interface components.
Electron provides the cross-platform desktop application environment. VibeUI provides reusable interface components and a consistent visual system. Open libraries handle the specialized work that would otherwise consume development time without making the actual product better.
RetroShelf also deliberately avoids proprietary formats and unnecessary infrastructure. It writes plain DOSBox Staging configuration files and readable JSON. Your games and library data stay on your machine.
There are no accounts, no telemetry, and no lock-in.
The project is released under the MIT license.
Choosing libraries that make AI more effective
One of the most important decisions when building software with AI isn't which model to use. It's choosing the right tools and libraries before asking the model to write code.
AI models are particularly prone to reinventing things. Give them a problem without sufficient constraints and they'll happily produce another custom implementation of something that has already been solved thousands of times. That means more generated code, more opportunities for bugs, more testing, and more maintenance.
A better approach is to give AI an established ecosystem to work within.
RetroShelf uses a relatively small set of well-established projects to handle the underlying application infrastructure:
Electron provides the cross-platform desktop runtime, so we don't need to build native desktop infrastructure ourselves.
Electron Forge handles application packaging and distribution, including platform-specific installers.
Vue 3 provides the reactive application framework.
Vite handles the renderer build and development workflow.
VibeUI provides reusable interface components, avoiding the need to generate and maintain an entirely custom component system.
Bootstrap and Bootstrap Icons provide established styling and iconography.
Cheerio and htmlparser2 handle HTML parsing and metadata extraction rather than requiring custom parsers.
These aren't just convenient dependencies. They're deliberate boundaries around what the application needs to implement itself.
Electron already knows how to run a desktop application. Vue already knows how to manage reactive interfaces. Cheerio already knows how to parse HTML. There is little value in asking an AI model to recreate any of that.
This has a direct impact on AI usage, too. Every time we leverage an existing library, we're reducing the amount of code that needs to be generated, reviewed, tested, and maintained. Smaller implementation surfaces mean fewer opportunities for generated code to introduce unnecessary complexity.
It also gives the AI something concrete to work with. Instead of inventing an architecture from scratch, it can work against documented APIs, established conventions, and known behaviors.
The result is less generated code and more useful code.
I would rather spend AI tokens implementing the actual game-matching logic and DOSBox configuration profiles than generating another ZIP parser or building a custom desktop packaging system. Those are solved problems. The interesting engineering work is what we build on top of them.
This is an important distinction in AI-assisted development: the objective isn't to maximize the amount of code AI produces. It's to minimize the amount of code we need to write while delivering the best possible application.
Good engineering choices make AI more productive, more predictable, and considerably less expensive.
AI-assisted development without the slop
I've written before about stopping AI slop with better writing prompts and constraints. The same philosophy applies to software development.
AI is very good at generating code. That doesn't mean the code is good, the architecture makes sense, or the resulting application is worth shipping.
There is a difference between asking an AI to generate an application and using AI to help engineer one.
RetroShelf is an example of the latter. AI can accelerate implementation, work through unfamiliar libraries, generate repetitive code, and help iterate on features. But the product still needs a defined purpose, technical boundaries, decisions about what belongs in the application, and a way to determine whether the implementation actually works.
A generated feature isn't finished because the model says it is finished. A successful build isn't proof that the application behaves correctly. A working demo isn't a substitute for a usable product.
The engineering work is deciding what to build, choosing the right tools, defining how the pieces fit together, testing the result, and rejecting implementations that don't meet the requirements.
RetroShelf ships with tests covering game scanning, configuration generation, metadata parsing, game matching, and store behavior. Those tests are part of the product, not an afterthought.
AI makes the work faster. It doesn't eliminate the responsibility.
Why open source?
RetroShelf is released under the MIT license.
The application is intended for people who have their own DOS and SCUMM game collections. It doesn't include games, sell games, or provide a mechanism for downloading commercial game collections.
Your collection stays yours. The application helps you organize and run it.
Making the project open source also means that people can inspect the implementation, modify it, contribute improvements, and build on the work. There is no proprietary storefront or account requirement standing between the user and their own collection.
You can find the source code, installation instructions, and project details on GitHub.
Software should solve problems
I don't think the measure of AI-assisted development should be how many lines of code a model can produce or how quickly it can generate a repository.
The measure should be what people can actually use when the work is finished.
RetroShelf started with a straightforward problem: I wanted a better way to manage and play the DOS games I already own. The result is an open-source desktop application that brings game discovery within your collection, configuration, metadata, and launching into one place.
That's a much more interesting use of AI than generating another application that exists primarily to demonstrate that AI can generate applications.
The code is available. The project is open. Give it a try, and if you find something that needs improvement, contributions are welcome.