One of the goals of the new version of my personal website has been to, not just produce writing at an increased pace, but to also make small interactive demos that can be played on the front page. The purpose of this is sort of like a taster for some other work that I will be exploring and experimenting with, and obviously to also to make the website more dynamic and engaging for those who find no value in reading the ramblings of an unemployed graduate.

The first demo of the site

Below is a screenshot of my website featuring my first demo, a clone of a mobile game "Desert Golfing", one that I used to play during my classes when I wanted to do anything but the work I was supposed to be doing. The game is very simple, so simple that it requires no menus or title screens, and can be started and played immediately. Like the mobile game that preceeded it, the game picks up wherever you leave it, and can be played as a PWA on mobile (which is an interesting topic on its own). With all of this in mind, the biggest challenge I was facing in making this small game was the fact that I didn't want to make it at all. I knew what I wanted, I knew how I could get there, but the idea of implementing the game itself was not appealing to me in the slightest. As per the initial post on this site, I did not want to spend too much time on the website outside of the writing itself, so the friction in having to spend time to make a small demo in JavaScript (a language I'm not too familiar with) was quite the task. I had created some small games during my time in university, none that were really much more than a proof of concept. These were mainly to introduce me to a new technique or idea to put in my toolbox. I recall the first game I had to make in university was in Java using the Processing library, and it was a simple top down 2D game where you had a character that had to dodge falling objects. It was my first and last 100% on a university assignment!

So if I didn't want to make the game, but still wanted the demo, then how would I be able to achieve this? It turns out, the agents workflow I had been using to work on the website was also rather good for making other software projects. I found that while the idea of "one shotting" an agent to make a full game would be very funny, it would also be very unrealistic. This is less a limitation of the technology, as the agents are now quite capable at making products that work, and more a limitation in the user-to-agent communication, which is a skill on its own. I call it a communication issue is for the simple reason that the agent is a tool, and it does not have the experiences nor the context to understand the users intent unless it explicitly written. The tools have gotten really capable in "reading between the lines" and assuming a lot of context, but for a video game, it less about making a product and more a work of art, something that the machine cannot do on it's own.

So then what is the fix for this issue? Well, more requirements of course! The workspace I am using currently is Google Antigravity, specifically the IDE variant where I can still see the code, but where the agent is able to modify the files directly in the editor as well. In the interface that you communicate with the agent, there are multiple different actions that you can choose to take that will execute certain behaviours, my favourite two being the /plan and /grill-me actions. The plan action allows the agent the freedom to take a little more time to "think" something through, creating notes and checking itself to understand if it is doing the correct thing. The /grill-me action on the other hand is a very useful tool that allows the agent to ask questions directly that can help guide the course of the implementation. I find using this latter action to be very handy at catching gaps in my specifications to the agents, and I always find myself using it to provide those extra tokens of context that I would have otherwise missed.

I place a lot of emphasis on context, as with more, you need do less. Thankfully, the model I am using, Gemini 3.8 Flash (High), has a very large context window, meaning I can provide a lot of information without having to worry about it running out of tokens during a single conversation. This also means that when using those actions in tandem, I can make it so that the agent can really understand the goals of the task at hand, and provide me with a plan it will execute that is most likely to be equivalent to what I am looking for. The accuracy of the agent then means that when it does create a first draft in the iterative process of game dev, it will be very nearly what I am looking for already, with only minor visual tweaks and code adjustments required.

So to make Desert Golfing, I get the agent to first create a specification document of what I want, I review and comment on the document, to which it is further refined. After repeating this process a few times, the agent can be told to proceed with implementation. It creates the file structure, sets up the project, and begins writing the code. Soon enough, Desert Golfing now exists, and a playable demo is featured on the homepage. There a still a few issues I need to work out, but so far it seems to be working great.

If games are art, then where is the soul?

I think this is a good philosophical question to pose to the software companies of today who are integrating AI into the creative process, but it is also a question I find myself asking when using agents for projects that are of more personal interest to me. I like to think that with these projects, the use of agents is really just to handle the grunt work, with the 'soul' of the project coming from the unique problems I ask the agent to solve. Some call this coping, but I think it is similar to the use of rasterised image editing tools, or digital audio workstations, as these tools do not make the art on their own, but rather are used as a means to create art. There is still an argument to make that the amount of effort required is still much less than with those other tools, and this is especially evident with seeing image or music generation tools stealing the limelight of well deserving artists.

I think that although the trope of "the guy with the idea" and the guy that actually makes the product splitting the share 50/50 is a funny one, it is quite relevant when discussing the use of agents, as the "idea" now becomes the harder part to execute exactly right. After all, even if everyone could make a game with a prompt, it still wouldn't be a bestseller. The execution isn't just in the implementation of the code, but also in the data that drives it. "Game feel" is a topic that many discuss quite often, with it being the defining factor between getting Doom or one of its many clones, and that is something that cannot be prompted into existence without knowing exactly what you want.

Large studios usually have a team of producers that can assist steering the direction of games, with the actual developers and artists that make the systems identified as a requirement are given the opportunity to put their own spin on the features. Indie games are by definition the developers soul manifest into a program for your enjoyment. So with this being said, the question of whether or not an agent can make a game becomes, who's soul is it that is being put into the game? The soul of the programmer guiding it, or the soul of the model that implements the code, and taking the naive assumption that both of those scenarios have no further nuance, it could be argued well that there is no longer any meaning to the art that is created. The program runs, it does something like what you wanted it to do, then it ends. Nowhere along the way was the hand of the artist present, only the intentions and ideas of a human at the helm of an extremely capable tool.

I would like to say my answer to the question posed by the heading is that the soul is still present, just in a less present form than that of a traditional indie game. The difference between me telling an agent to make a game exactly how I like and me spending hours meticulously tuning the parameters of a behaviour system or the animations of an actor in a game engine, is the sheer amount of output I can get from the agent in a short amount of time. You would expect it to be a good thing to be able to do so much with so little time, but then you question the quality and authenticity of the output, and when consuming a product, a good signal for quality is how much care had gone into creating it.

For the desert golfing demo, I like to think that there is still some soul present, but the game does feel cheap, and the small issues that occasionally pop-up due to implementation errors don't make it feel any better. I want to say that the first attempt at purely "vibecoding" a small game went well, but there are some notes I have taken that will most likely create better results in the future. As for the next demos, I will most likely be using another engine rather than continuing development in JavaScript, as I am unable to fully grasp the codebase once it starts getting too big.

The Happy Medium

To make golfing on the endless sand dunes better next time, I maintain that providing context to the agents on certain requirements and vision is good, however it is not the complete picture I once thought it was. From this vibecoding experience, the happy medium would be to follow the paradigms of Test Driven Development (TDD) and Data Driven Development (DDD) closely. These two styles are not mutually exclusive, in fact they work very well together. The idea I would have is to get the agent to create a skeleton of what you want, have it implement the behaviours and logic of all the components and systems that happen at runtime, but allow for the data for the game to be defined externally to the code by the developer. The tests are in place to ensure that the agent is doing what you want it to do, and the data is in place to ensure the developer has an input in that fabled "game feel".

This idea at least works well for games I am interested in, usually very simulation heavy, realistic in their physics or economies, many independent but interacting systems. For games that abstract the complexity away from the player to create more hand crafted worlds with mechanics that don't follow our laws of physics, this approach could be even better, as the more knobs and dials that you get the agent to create for you, the more opportunities there are to inject your own ideas into the systems it creates. Can you fully replace a game developer with AI? I don't think that will ever happen, but the tools available are getting more capable at allowing those with a different primary expertise to at least experiment in what is normally considered the hardest part of the game development creative process: the implementation of the ideas. The barrier for understanding software development is getting lower, and it is now more accessible than ever to understand the purpose of a function without reading the source code. I don't believe that fully relying on LLMs to explain code in natural language will ever be perfectly right, nor vice versa with natural language to code. Programming languages have a much higher precision bandwidth, while natural language has a higher conceptual and emotional bandwidth. The natural language of the developer in their prompt then, can prove to be the source of the soul in a project fully coded by agents.

I hope this little reflection provided another perspective on a very topical conversation, although I will likely be sure to add more as time goes on and I have more thoughts on the matter. Let me know if you have any personal opinions, I am always looking for more perspectives from others to consider.