DEV Community: Ibrahim Kashif

How Campfire Displays An Interactive Game To The Users Browser

Ibrahim Kashif — Wed, 09 Sep 2026 07:17:24 +0000

Campfire is an Agentic System that builds entire games with simple prompts. You can think of it as a tool for the mind. A way to enhance an individuals creativity and find a way to turn that into a reliable source of income and enjoyment for them.

The perspective that Campfire is not made for "Developers" but rather "Everyday people" really matters and it's been the d*efining principle for the architecture of experience* surrounding Campfire.

We've tried our best to make it as easy as possible for the user to genuinely create. Understanding what they need to know and make decisions on. And not telling them anything about what genuinely does not concern them or what Campfire can handle on its own.

This is the perspective of the best Agentic Systems.

Picture Of Playing A 100% Campfire Generated Game.

However experience cannot bottleneck actual technology. And for Campfire to actually create games and iterate on a game and display it to the user we have to cheat a little bit to ensure we keep the beautiful elegance of Campfire's hidden architecture.

This article is meant to help you immerse yourself in the months of iteration to finally conclude the architecture of Display and Compilation as we have derived today. Please take time to really understand the flow, as if it were a river so that you may understand the peace and serenity of development and iteration and the excellence of flow.

The Problem:
A "Game Engine" is a collection of foundational tools and rules needed to build a video game. Every single game you've ever played has been built on a game engine. Something like "Unity, Unreal Engine etc".

These not only hold tools for a human to create **within the Game Engine software but also the fundamental scripts to **run logic like physics and lighting.

Campfire is an Agentic System that handles the "human creation" part within a game engine. We use the software's tools to do your part of manual labor. However we are still entirely reliant on the mercy of the game engine's "actual engine logic" to run whatever Campfire has built as the user has specified.

For this very reason one can conclude that for Campfire to work, we need the Game Engine's backbone, regardless.

Now imagine what this means, every single game **that's being created by Campfire needs a "process" of the game engine **open and running. And to open the game engine to run the "artifacts" Campfire has created we need a computer to run the game engine.

So does one have to assume that you need a computer running a game engine open for every single game someone wants to create using Campfire? Imagine 500 users creating a game in a day. Does that mean we need to rent 500 computers?

And how do we display the "running game" to the user's browser? The user is considered a 'non technical', he has no idea about "game engine". He doesn't want to see the overly complex UI of it either. So how could we possibly display something running on a computer to a user's browser. Without them waiting 10 minutes for a single compile or us having to rent 500 computers for 500 users.

Picture of the UI of a popular game engine software (Unity)

Here are the methods we implemented to solve exactly this problem and the limitations of each:
Preface: So we looked at this problem and we concluded that we should break this down into 2 separate problems:

Compiling the game
Displaying the compiled game

All the following methods that we invented and pioneered revolve around us trying to solve these 2 problems. Each method had its pros and cons. And the reason why we scrapped it.

**Method 1: WebGL Compilation on the users own computer

Displaying WebGL to the users computer:**
So at first before Campfire was even in a production environment we ignored the question about "How are we going to serve this to x amount of users" and instead focussed on the singular question of "How do we even get anything shown to the user?". We wanted very clearly to not show the "Game Engine" processes in front of the user because it would confuse them and destroy their creativity.

But the **only place **the game is actually viewable from is the engine's own "UI".

That was, until we discovered WebGL.

Picture of WebGL loading a Campfire Generated Game From A Singular URL

WebGL is a coding tool that lets websites show 2D and 3D graphics right inside your** web browser** without needing extra plugins. For the end users it's a simple "type this URL inside your browser and you can play the game". The most simplest of concepts. We thought it was perfect.

At the time we were using NGROK which was a way for our backend to talk to our frontend. We wired the frontend iframe to fetch the URL from the backend which would give it a local file path /files/ and that would be uploaded and downloaded on the frontend.

We had no issues with HTTPS or TLS certificates because the NGROK URL handled much of our problems. However unknown to us we were paying a major cost to take this through NGROK.

Imagine the flow: WebGL is produced on your Computer as a local folder (/g14/changes/c1). Then our browser gets the URL and fetches for it /files/g14/changes/c1. Our computer uploads the files over the internet to NGROKS servers and then the browser downloads it over the internet from NGROKS servers. Even though it's a local /file/ on the user's computer and so is the browser.

What did this result in? Well regardless of the actual compile time to produce a WebGL build inside the Game Engine. Just to download it to the browser took around 3–4 minutes and was entirely dependent on the mercy of your bandwidth which at times could be so slow that you'd be sitting there for **10 minutes just waiting **for the browser to download the "change" folder.

What was the size of our file? It was 50mb ish. Nothing. However because of this routing problem we had this issue and it was unknown at the time.

Compiling WebGl via the Game Engine:
Our major concern at the beginning however was not related to the browser download speed because 3 minutes was considered alright at the time. What really concerned us was the raw "compile time" for our game engine to turn our game into WebGL. It was 300 seconds.

Now for comparison Campfire created for you an entire game in roughly 400 seconds. Now imagine having an entire game created, all the code, all the assets, the ui, everything and then you'd have to wait 5 minutes just for it to compile and 3 minutes for it to display.

If that was bad, one of the core principles of Campfire is 9*0% good first output and 100% iteration tools. **We are absolutely with the concept of iteration as any good engineering project requires iteration. Imagine if you just did a singular script change or you resized or moved the character. A tiny change, you'd have to wait **8 minutes* to view that change. This killed the entire idea and at the time the only concept for viewing your game was "WebGL" so we knew we had to optimize the compile step.

Optimizing WebGL Compilation via the Game Engine:

This was our original baseline breakdown. Eventually we did a bunch of optimization steps to get the compile time down to:

**Asset-only changes: ~7s
Script changes: ~51s, breakdown:

Domain reload + script detection: ~2s
Scene re-authoring (549 FactoryCli calls): ~3s
ProducePlayerScriptAssemblies: ~1s
Compressed player packaging: ~4s
Postprocess (IL2CPP/Emscripten/wasm-ld/wasm-opt): ~39s, of which wasm-ld link alone ≈ 27s**

This was really good. However combine this with the bottleneck of WebGL - browser we'd still be waiting +5 minutes per iteration which was absurd and we did not want that for our users.

So we started figuring out new ways.

**Method 2: Renting Computers And Render Streaming To Users Browser

Render Streaming:**
We later heard of a new process of being able to display the compiled game to the frontend called "Render Streaming". Render streaming is a process much like twitch or any stream that you watch live. A technology that lets you run a heavy, high-quality 3D application on a powerful server or computer, and stream the live video and audio directly to a web browser on a smartphone, tablet, or low-powered laptop.

Picture Of Render Streaming (Using Sample Scene).

For this process we could ignore the entire WebGL pipeline which as you saw from the last method was the real cost (mainly in the displaying to the browser) but also in the compile breakdown: "Postprocess (IL2CPP/Emscripten/wasm-ld/wasm-opt): ~39s, of which wasm-ld link alone ≈ 27s"

We went ahead and tested it and were not impressed. This invited Latency + Resolution Bitrate Issues. But the major factor was that our users wouldn't have to wait (60 second compile time + 3–4 for webGL browser download) 5 minutes per iteration. It could be instant paying only the "compile time" which we knew was extremely short after removing WebGL entirely.

We went ahead and tested the latency and it was completely fine locally. The resolution was prone to fluctuations depending on your internet (obviously) but even at the best connection it couldn't stream much sharp edges and text was muffled. We thought it was a worthwhile compromise to ensure time, especially if we introduced a "Produce Build" manual button on Campfire for when users wanted to publish their build to s*how their friends before uploading it to steam in 2 clicks.*

Iteration would be fast and reliable.

Renting Out Computers:
Now Campfire had been in development and testing for around 7–8 months and we were ready to move to the production environment. We rented a server to store Campfire's backend and got to the question of "How are we going to use a Game Engine when the user doesn't have one on their computer?".

Our idea was to rent GPU computers which had everything installed on it along with a launch script that launched the Game Engine and the related processes. Our backend would send files to it (Artifacts) via upload and download and it would stream P2P with the user (Browser to Computer directly).

Now we can't just keep GPU computers on indefinitely so we devised a solution called "Worker/Seat + Warm Pool Instances". The idea was a demand based orchestrator that launched computers based on flux of the userbase, kept a warm pool filled for quick start and reused ones that have gone idle before terminating them if no users needed to "claim" them.

We managed to optimise to get 2 users on a computer **instead of a singular computer for one user and could scale this to **3 or even 4.

Now besides the obvious fact that we now required to rent computers, this did introduce a latency issue **for the Render Streaming. Though render streaming was working **P2P directly from the users browser to the computer and back. This was obviously entirely dependent on where the user was and where the computer was.

Compared to the local host the latency went from** 1–5ms to 120–150ms** (if you were in the same continent) or over the pacific 300+.
Besides that the time to launch a worker (based on cold boot or warm boot) were roughly:

**Warm Boot:

Boot - 200s
Launch Unity - 200s
Compile - 60s Total: 7–8 minutes

Cold Boot:

Boot - 200s
Launch Unity - 500s
Compile - 120s Total: 13–14 minutes**

We thought we could hide this underneath the user's "first message" so we introduced the logic of "ensure capacity" which would (like the orchestrator) launch a computer for the user on their first message, anticipating a full build. If we follow how long it takes to build a full game (roughly 400s) then in the warm flow we are left with 60s total (460s - 400).

The real win on this was after the computer launched iteration was instant (guarded only on actual compile time no webGL anymore).

The Final System:
Now we looked at all of this data and concluded that regardless of what we do, we have to compromise on some place. Either on the time, or on the quality or on the user experience.

But then we asked ourselves the question: "What do we have access to?" We came to the conclusion that every "compile time" even with WebGL was good enough **(1 minute, varying by CPU capability of the device). Render streaming, though it managed to make **compiling practically instant, made everything look quality wise worse. We didn't want to compromise on quality and playing experience so we agreed we'd go to the WebGL path. The only problem left then, was the browser downloading WebGL. We agreed that we'd figure that out at another time and left the problem there.

The next question was about how to "Run a Game Engine" for the user.

So we took the "renting GPU" idea *and we switched it to *"using the user's computer to run their own game". This meant that all the work (computation) was happening on the users computer which it was more than capable handling.

And it meant that the user owned everything related to their project on their own computer. Campfire was just the Agentic solution that modified the project and controlled the engine running on their GPU.

But then we came back to "experience" where we didn't want the user to "set up all this stuff" and you know the long walk with 20 setup features like how some apps do it. But then it hit us that we can absolutely entirely automate this process.

Picture Of User Downloading Campfire Bridge (one time download).

Picture Of Campfire Bridge Running On User's Computer Via Singular Command.

The user didn't have to run around in circles. They just had to download a singular 'Campfire Bridge' file on their computer, run a singular terminal command and that was it.

Campfire would handle the rest. Downloading what it needs, modifying project files accordingly etc. It wouldn't touch anything inside the computer, just a singular folder we allowed it to touch called "Campfire" where everything related to Campfire would be. It was perfect and it worked well and was easy.

This also added the benefit that we didn't have to rent any architecture. No computers no nothing because the users free GPU was right there.

Now if we conclude: We got "compile" down to a minute on the highest end and we automated the process of running the game engine to the point where the user wouldn't even see anything which is exactly what we wanted experience wise **so as to not overwhelm them. We completely left render streaming meaning that there were no latency or resolution or bandwidth issues. **We gave the user control over their own project.

All that was left was the tiny annoyance of browser download WebGL speed.

We looked at the process again and instantly understood what we were doing wrong. The real build file as specified previously was barely anything** (50mb). The problem was the network hopping **(computer to network to server to network to browser) when both the browser and the folder existed on the same computer.

Our fix for this was to change it so that the computer directly streamed to the browser via a secure TLS HTTPS server. **This gave us real **I/O disk speed (The same speed as copying and pasting something on your computer).

Conclusion: We managed to get the parts of Campfire that the user didn't need to know about, away from them. Managed to get them to own their own project and not cost us any architecture and got compile and iteration down to **under a minute **depending on the change.

There are a few limitations to this method **like the fact that now that the user's computer is running the game engine so we are left to the **mercy of their own specs. A normal computer can handle our game engine normally with 0 problems (you wouldn't even notice). If your computer is slower with less general specs then the compile time would just be slower, nothing else would change. So a user may have 20s compile and another may have double that at 40s. But overall it's a massive increase in fluidity compared to renting GPU Computers and waiting 13 minutes for it to do anything.

Note: We started writing this while still stuck on the rented-instance approach and it made us rethink our architecture. A few days in, we landed on the local execution model instead, which is the version we've dubbed "The Final System" and is what's currently implemented.

How Campfire Can Create An Entire Game's Assets And Animations From A Single Prompt.

Ibrahim Kashif — Wed, 02 Sep 2026 13:32:02 +0000

I’d like to take time out and discuss one of the core fundamental systems behind Campfire. Its entire Asset generation pipeline.

Campfire is an Agentic system that builds entire games with system prompts. Imagine going back and forth with a few prompts and then having it build everything you need, art, code, game design the whole shablam.

For a system like Campfire to even exist, we need to be able to take every human's basic inputs (A beginner will never describe in as much detail as is required) and turn that into an actual full game loop. And a full game loop not only requires base assets but you also need animations which are like 5-10 different images of the same base asset. Multiply this between enemies, tilemap, UI, sky, low level and high level decorations and you really need a robust system to reliably get base sprites and animations.

Over the last few months we’ve taken a great deal to really go over every possible process to see what produces the best results. This is really one of our most researched divisions as it's so essential to what we need Campfire to be so reliably. A means for everyday people to express their creativity without the limitations of our old crude learning practices of becoming an entire game developer to build a game.

When it comes to generating sprites and animations using AI there are 2 known methods:

Using a Video generation model like Wan1.7, Grok etc.
Using a Image generation model like Images 2 GPT or NBPro

I will go on to break down both of the known methods and some of the things that we have done to produce reliably enough results in Campfire. Everything labelled below has taken months of research and development through various testing and consultations between experts in this division.

Image Generation:
An image generation model is a model that generates static single png files. It can create remarkably well images especially in pixel art which is what most 2D platformers (currently all Campfire supports) choose as their art style. There is a known problem of “Mixels” which is where if you really zoom in you’ll see that the Image generation model is generating FAKE pixels but to the normal eye it's genuinely not noticeable. We’ve chosen to ignore this problem in Campfire because it's just a mere “nice to have”. The reason it generates mixels is because it's taught to generate not in specific pixels but in “whole chunks of the image” and there really is no work around to getting an image generation model to generate specific pixel perfect images for you.

As for sprite sheets, image generation has increased exponentially to be almost perfectly style consistent when generating different frames for an animation inside a singular png of a specific character. The problem does not lie with style, rather pure reasoning logic. In a non loop animation, say a sword swing, an accurate animation sequence would be: frame 1 ( idle), frame 2 (rising up), frame 3 (about to attack), frame 4 (climax of attack), frame 5 (cooling down), frame 6 (back to idle). A sort of incremental sequence of movements. However most often then not AI hallucinates this process, you get unnecessary frames like a frame 5 that instead of cooling down just points the sword up randomly. Or an issue where it may get the motion correct but it decides to switch the hand in which the character is attacking or just makes the sword disappear.

Another issue related to image generation for sprite sheets is that it fails to keep each frame inside a specific box and you result in “frame spillage” where frame 3’s sword tip falls into frame 4’s box. And besides that issue there is also the obvious problem (if not the hardest problem) of the character jumping and jittering around inside its “Dedicated canvas zone”.

A proper animation sequence requires a known canvas size to draw each frame in relative to a specific anchor point.

The point being when you first see the result it looks promising however when you try to take that result and actually use it in an animation by just removing the background you’ll see minor inconsistencies like this that ruin everything. And because of this you need a lot of post processing methods, some labelled below:

Chroma Key Removal
Cut to image bounds
Anchor Point Alignment + creating your own unified canvas throughout all the animations and inter animation frames.

You can negate the lack of reasoning by increasing your prompt description to give frame by frame explanations but of course as any generative AI you will never get 100% perfect results.

GOOD RESULT VS BAD RESULT IMAGES
Good Sprite Sheet Results:

Bad Sprite Sheet Results:

As for a singular sprite, like a character's “Base” asset which is what we use to provide as reference for all the animation generations. The image generation model does a remarkably good job with the caveat that it fails to reliably produce a “solid flat base” for the character. A 2D side scrolling platformer requires a character with a solid leveled base. When you are generating the asset with chromakey as the background (the only way to properly remove the background from the generated sprite) the character generated is essentially “floating” within this chroma background which results in a subtle tilt on the character. What that looks like is essentially a: right foot lower than left foot type thing (just subtle enough to cause a problem):

You can try your best to fix it with prompt enforcement but as mentioned before you won’t get 100% results. The way we’ve understood to solve this is by enforcing a “Chromakey base line” in the same color of the chromakey background differed slightly so it’s visible but still easily removable. This enforces the character to have a solid base and works reliably well:

A few examples:

The only major restriction with generating using an image model is, regardless of what you try to do it will never manage to get a loop cycle animation. Suppose a run cycle or a swim cycle or anything that is supposed to loop. You can try to increase your results by providing skeletal pose annotations of the animation sequence but its still extremely unreliable and theres the fact that you have to create them specific for the type of character (e.g chibby proportions etc). The right way to handle loop animations is to go off singular sheet generation entirely and look into video generation.

Example of using Image Generation for run animation:

Video Generation:
This is by far the only way that we’ve managed to generate loop animations. A 3 second video describing a run cycle actually generates roughly 90 frames (depending on your settings) which is definitely more than what you require. Inside these 90 frames the character probably loops multiple times. And you wont have any “inter frame alignment” issues because its a video that has been generated coherently nor will you have terrible reasoning for the same benefit.

It seems like a perfect solution you just cut the middle frames e.g 30 frames and write an algorithm to determine the loop cycle.

*However what seems perfect on the top can only truly be understood inside post processing. *

To ensure a clean background removal we must add a chromakey background to this generation request, however during the animation the color of the chromakey mixes with some of the outer edges of your character within some animation frames so the character's ‘boot’ looks greenish in frame 12 and normal in frame 14.

This inconsistency in color doesn’t break the illusion of a smooth looping animation but it's noticeable enough for someone to point out “why does my character turn green when it starts running”.

Besides this, the biggest problem is probably specifically related to pixel art. Video generation models are not trained on pixel art animation, they're mainly trained on real life video. Because of this they make very mushy pixels during the animation. If you use the right model however, from the perspective of the user the mushness is as less noticeable as the mixels are. As for the color leakage we currently have not implemented any solution for that but thoughts do come to mind by creating a unified color palette using the base asset provided as reference along with the normal frames without color leakage and using that to fix the color leakage frames. We will test this and will update you on how it went or any other solution we ended up using.

What's the biggest problem Campfire has with using AI generation for base sprites and animations?

As for image generation, base sprites are generated remarkably well as mentioned. The main problem is with the** post processing singular canvas + anchor point for animation generation.** To help you understand let me take an example of a character's true animation requirements:

Let us picture a “Lumberjack with a gun” player. The basic animations required are as follows: Run, Shoot, Jump, Idle, Death, Reload

Not only do we have to run post processing and remove the jitter between a singular animation sequence (shoot for example known as the “inter animation frames alignment” but we also have to normalize a singular canvas and anchor point so that all other animations (already inter-aligned) can be aligned with each other.

A transition from Idle - Run cannot put the character on the right or move it up within the same canvas otherwise the transition isn’t smooth right?

What is the proposed solution to fix this?

Well it seems obvious what we must do to fix this, we must determine a canonical anchor point for the character itself. Something distinct that we can reference throughout every single animation (swim, run, jump, death, custom animation 1) whatever. Let us suppose when we are generating the base asset we specify a singular distinct anchor point. Something like the users right boot or a ghost's tail. Now when generating the animation sheet we reference this ‘anchor point’ inside the “Frame by Frame Description” and on the top level of the prompt: “Keep the character's right boot locked on the same anchor position throughout all frames”.

This doesn’t promise the character doesn’t jitter. What this promises is that the character's right boot looks the same (shape and color) throughout all frames wherever they choose to spawn inside its dedicated canvas space on the singular sprite sheet. Then we can use basic pattern matching to align all the frames. *And since we’ve agreed that this is the *“canonical anchor throughout this specific character” a jump, idle, shoot all share the same “right boot locked rule” so we can pattern match animation sequence 1 (idle) with animation sequence 2 (shoot) and it works amazingly. Quadruplets or characters like a bat or whatever imaginary character can also follow this method. The point is enforcing that every character or asset that we will generate has a “distinct” part of it that is easily recognizable.

The limitations to this method:
This is when there is a clearly distinct part of a character. What happens when the character is a slime blob? What happens when in the last frame of a death animation the character collapses entirely? How do you enforce a “lock right boot at the same place” while your frame by frame description says: "Collapse the character entirely as if he’s lying down”. And what happens when the character leaves the ground? Inside the raw generated sprite sheet he physically moves inside the canvas and the animation requires the boot to change into a more “pointed” way.

We’ve tested and we’ve gotten these “inconsistencies” to be caught best we can through ample prompt principles + other special case fine tuning methods but it's never 100% perfect.

Rest all problems are merely an increase in prompting logic and fine tuning here and there in post processing to get more accurate results.

Other game assets
AI Image models reliably produce all the relevant aspects of a game, the UI, the tilemap, the decorations all while maintaining style consistency.

The way Campfire does it so well is we use a multi agent architecture which just means we have a singular planning agent that decides beforehand the entire experience of the game and the style and the feel and then we have other sub agents that can interpret this “Design spec”.

The hard part isn’t producing a single static image (UI, tilemap etc), it’s mainly in the animations due to the fact that we turn a singular image to up to 40 different images (4-5 different animations) of the same base image. Needing to be style + Incremental logic sequence consistent.

My conclusion
The fundamental principle of Campfire is giving the user enough proof of concept and providing them with reliably enough iteration tools for them to fall into the creative cycle. We prefer to give the user only WHAT they need to know. Campfire is not for game developers or technicals it’s for their counterpart: Everyday people. An everyday person doesn’t care about canvas alignment or animation consistency they just say: “I want a run animation for this zombie and also throw in a bite one”. 100% of the process Campfire has to handle because the users job as we believe is High level intent where they belong.

Generating using AI 100% is prone to hallucination. That's why we’ve preferred to make it easy to iterate on an undesirable output. It's definitely not perfect but the prospect is here that these models are only ever getting *cheaper and better. *

To generate an entire game's assets have gone from thousands of dollars or hiring someone to spend 100s of hours to mere seconds and less than 5 dollars per game. It's incredible what this can allow and enable.

The loose end really is in how you get animations to be aligned well enough on their own that you see no jitter at all or no out of the ordinary frame or frame leakage throughout all your animations for all your characters. There's a lot of moving parts and post processing steps that rely on each other and if one fails it doesn’t matter how good the other steps worked the animation feels off.

Why game developers are scared to say they used AI

Ibrahim Kashif — Mon, 15 Jun 2026 06:13:02 +0000

Why game developers are scared to say they used AI

A friend of mine recently posted in a game dev Discord asking whether he should include "AI used" in his Steam page description. The replies were unanimous. Don't do it. Players will **skip your game **before they even read the description.

That fear is** real**. And it's worth talking about honestly.

About 70-85% of all digital content created today has touched AI somewhere in the workflow. Whether that's idea generation or actually producing output. The problem is that people see the term "AI used" and immediately picture the same slop they scroll past on social media. Cheap generated videos, hollow images, content that took 3 seconds to make and looks like it. Their prejudice is understandable. It's just not accurate.

There is a fine line between people who waste time producing below average content and people who are using this technology to enhance their own capabilities. AI is a bicycle for the mind. Nothing more, nothing less. Where an artist creating game assets would take 500+ hours to generate all the artwork for a game, AI can take that artist's intent and generate it in minutes. Where a programmer would spend months **defining and refining code, a single prompt to a context filled model gets it **done in seconds.

We as humans know exactly what we want. We know the correct feeling. We are the architects. We've never been the fastest creature or the most sturdy. We gained dominance because we knew how to invent tools that suited us. AI is exactly that.

Majority of Claude's code is generated by Claude itself. Majority of Google's code is generated by Google's own AI. Nobody has a problem with that. Because the output is real, it works, and real people built something with it.

Having a game touched by AI in the development process is a self filter. If it truly is just slop, nobody plays it. Simple. But if you forget that label for a second and just look at the actual game, you'll find out pretty quickly whether it's good or not. The label was never the point.

When I heard some of my Game Developer friends were scared to put the term “AI used” inside their info for the game they're working on in fear that people won’t play it, what's the hope for *Campfire? *

Generated 100% from Campfire. Game Assets, tilemap, ui, logic, terrain, entity placements etc. Took a few natural human-like planning prompts.

Campfire is something that we’ve been building for the last 6 months now. It’s an agentic system that builds entire games from simple prompts. Backed by a real game engine. If people shun at “AI Used” what about** “Entirely built by AI”. But the truth is, if you produce something real. It doesn’t matter*. Like google, like claude. If the output is real, and you’ve done your due diligence to iterate and refine and update then your outcome is **more powerful than any label.* Campfire isn’t a means of removing creativity, its just a means of lowering the barrier of entry so that people can have ALL their focus on creating instead of figuring out how to loop an animation.

It’s definitely not perfect, but its the first thing we’ve seen that shows us that a time will come where everyday people will actually be able to express their ideas as well. In the same way Claude Code or lovable, lowered the barrier of entry to developing real software products. Campfire is doing the same for games.

Here, this is a video of Campfire creating a game, its not 100% but its more than a proof of concept: https://www.instagram.com/p/DYd_-MEtOQ1/

Campfire, create entire games in simple prompts. This is why current Game Development is broken.

Ibrahim Kashif — Wed, 10 Jun 2026 12:52:02 +0000

The part time game dev communities are full of the same post:

"I wish I could quit my day job and just build games but games don't pay the bills."

The truth is, the world is filled with hidden flowers waiting to bloom. However the barrier of entry to create has been the sole cost of them not chasing their dreams. Lets examine if someone woke up with an idea to create a game, what would it require? There are 3 currencies everyone has and each increase or decrease depending on the person:

Time
Money
Skills

If someone really wanted to build a game and wanted to do it the most efficient way possible, you could average a few tens of thousands of dollars (20-35K). Hollow Knight was 50K with a skilled dev team. You would need to hire talent and lead them, having no idea of the basics, lets say 3 people (code, art, planning). And you would need months or even years of full time commitment to get things right. And remember, you only reap the rewards **after **the game is finished. Now if you tell this to an everyday person who has that idea for the next GTA level game, they're going to bed happy with their day job.

Instead of coming up with an idea, learning programming and art design and the rest of the game dev process, taking years, tens of thousands of dollars and most likely relying on a team just to express that very idea. Everyday people can do this in just a few back and forths with Campfire.

That's the essence that Campfire is built on. Campfire is an Agentic Solution that builds entire games with simple prompts. It's not a tool meant to be used by a game developer that wants to speed up a task, rather for an everyday person to one day wake up and realise they have a chance to do something incredible and express their creativity in a way never seen before.

And I want to be clear, this isn't a means of skipping or removing creativity. Rather the opposite. We're not giving people a shortcut, we're opening a new door. If Campfire can in a few prompts produce a well enough output, and provide people with good enough iteration tools, you'll find them more creative than ever. I myself am proof of this, having sold software using no code solutions because I had an idea, a willingness to make it happen and most importantly the barrier to entry was reduced by these agentic systems.

The eventual goal is not just to empower creativity for individuals to allow hidden gems to bloom. But it's also to allow those very people to turn this into a sustainable business for themselves, soon enough for it to be worth it. A means of sustaining their creative endeavors and chasing their dreams.

We've already seen this metric and this change in tools like Claude Code, Lovable.dev, Replit. These are softwares that have changed the entire engineering industry because they lowered the barrier of entry to create and enhanced an individuals ability to create.

The difference between a programmer and a non programmer in building something real like a software product is just an idea and the willingness to express it.

People tell me that this seems like cheating. That if someone really wanted to build a game they'd sacrifice the years and the effort and make it real to them. Well, not everyone can do that. People have kids, they have jobs. People won't even try yet because the cost of success is too high. That's what Campfire reduces. An everyday person is flexible unlike a dev. They won't say: "Give me a 16 frame loop animation of a run of this specific character". They'll just say: "Make the character run" and then Campfire handles the rest. And imagine a kid trying to express creativity. No responsibilities true but in the attention economy they need something proven to activate their natural creativity loop.

You see where I'm going with this? One path takes 15 steps and previous experience of redundant information to know. And one path is just: "Give me what I want." That's the point of Campfire.

Generated 100% from Campfire. Game Assets, tilemap, ui, logic, terrain, entity placements etc.

Imagine a process where you go back and forth with Campfire, debug, iterate and create a game to your liking. And then it's a 2 click upload to Steam. Something like that. Where people can turn their creativity into a revenue source.

Another argument may be that because of this every game will just become cheap and lame.** That is hardly the case.** 90% of games already are those cheap web games you see around, not a proper game like GTA or RDR. If more people are creating games, then the games that come out on top are the ones that are the most fun. People who want to express their ideas will have to actually try if they want to succeed. That never changes. The end result? Better games for everyone and people being able to make a life off their passions.

Campfire is certainly not done right now. We're trying really hard and it's a lot of work. To generate any game in the future we do have to start small (2D sidescrolling platformers), there are some things that are still buggy, but it does a really good job at producing a provable outcome and done some things remarkably great.

My theory is simple. If we can build a 75% good output on the first planned run, and provide 90% good iteration tools, people naturally fall into the creative spirit of iteration and engineering. That's truer than anything.

Telling is boring though, I want to show you guys, it's easier that way.

Here, watch Campfire create a game: https://www.instagram.com/reel/DYjAyvXjEPB/

The video does the talking.

Ibrahim Kashif is the founder of Campfire, an agentic AI system that generates complete playable games from simple prompts.
Follow the build on Instagram: https://www.instagram.com/ibrahimkashai_/reels/