CURSED.EXE — Touch Grass. Collect the Evidence. 🌿🎴

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

What if touching grass gave you loot?

Meet CURSED.EXE, a chaotic little project that turns ordinary things from the real world into collectible, AI-generated pixel-art trading cards.

The concept is simple: we spend so much time staring at screens that we sometimes forget the interesting stuff sitting right outside our doors. CURSED.EXE gives us a ridiculous excuse to go outside and look around.

Found a weird-looking tree? Photograph it.

Spotted a cat? Photograph it.

Found a suspicious banana in your kitchen? Unfortunately, that counts too. 🍌

Upload the photo, and CURSED.EXE transforms it into a collectible entity card featuring colourful, classic 16-bit RPG-inspired pixel art, an AI-generated name, a class, rarity, two randomized stats, a quirky one-liner, and completely unnecessary fictional lore.

Your banana might become Bananazon. Your cat might become Sprite. Your sandwich might become a level-one Gluten Shield mob from the Breakfast Sector.

I'm not questioning the AI's decisions anymore.

Every card joins your personal collection, turning ordinary observations into a growing bestiary of real-world anomalies.

The goal isn't to build another game that keeps people glued to their screens. It's to make the world outside feel a little more like an adventure.

Go outside. Find something weird. Capture the evidence.

Demo

GitHub repository: https://github.com/krvnium/cursed-exe

The project runs locally as a Streamlit application. The repository contains the source code and setup instructions.

The screenshots below are examples of cards generated during development:

• A cat reimagined as a pixel-art RPG creature.

• Jarvis, a household entity with a deeply concerning relationship with sandwiches.

Code

Explore the source code: krvnium/cursed-exe

The project is built with Python and uses Streamlit for the interface, Pillow for image processing and card rendering, and SQLite for the persistent collection.

The main pipeline looks like this:

1. Capture: Upload a photograph of something from the real world.
2. Pixelate: Process the image into a colourful, retro-inspired pixel-art representation.
3. Identify: Send the image through a vision-capable AI model to identify its subject and generate contextual metadata.
4. Randomize: Assign rarity and generate Chaotic-ness and Grass Meter stats.
5. Collect: Render the result into a custom trading card and save it to your collection.

The card images can be exported as PNGs, and the collection persists locally.

How I Built It

This project was a one-night experiment in getting an idea out of my head and into a working application.

I started with an initial implementation generated with Gemini, then used GitHub Copilot in Zed to inspect the codebase, debug the AI integration, improve the card renderer, redesign the interface, and prepare the project for GitHub.

The stack:

• Python — application logic and metadata handling.
• Streamlit — interactive web interface.
• Pillow — image pixelation and trading-card rendering.
• SQLite — persistent local collection.
• Groq-hosted vision model — image understanding and generation of contextual entity metadata.
• GitHub Copilot — agent-assisted debugging, implementation, and release preparation.

The interface uses a pastel NeoBrutalist aesthetic: thick black borders, offset shadows, a subtle grid background, pastel pink, lime and lavender, and Bricolage Grotesque typography.

The cards themselves follow a horizontal layout inspired by collectible trading cards, with the pixel art taking centre stage and the entity's stats and lore on the side.

One of the biggest debugging challenges was getting the AI integration working reliably. The configured endpoint was being constructed incorrectly, and the previous vision model configuration was unavailable. After correcting the configuration, I verified the integration with a real image inference request.

The project also preserves generated cards and their metadata locally, so your collection isn't supposed to change every time you reopen the application.

Why Does Open Innovation Matter?

For a small project like this, open innovation makes experimentation accessible.

I could combine an open development stack, a vision-capable model, image-processing libraries, and an AI coding agent without having to build every component from scratch.

Using an open-weight model through a hosted inference provider let me experiment with image understanding and structured metadata generation without needing to run a large model locally on my own hardware.

That distinction matters: the model is open-weight, while inference in this implementation is hosted rather than local.

Open-source libraries also made the rest of the project easier to understand, modify, and share. Someone else can inspect the pipeline, replace the model provider, change the card template, or extend the collection system instead of treating the whole application as a black box.

A closed API could also support this kind of project. The benefit of open innovation is not that closed systems are incapable of it; it's that accessible components and inspectable code give builders more freedom to experiment, learn, and adapt.

And that's exactly what this project was about: taking a silly idea and making it real in one night.

My Agent Session

I used Gemini for the initial code and GitHub Copilot in Zed for subsequent implementation, debugging, testing, and release preparation.

CURSED.EXE — Touch grass. Collect the evidence.

Now excuse me. I have a suspicious banana to investigate. 🍌