Project: Sway The People!

Description

Sway The People! is a political simulation game for Linux, Windows and macOS. It is an Electron-based project, written in TypeScript.

I started developing it on July of 2026, and released the 1.0.0 version on August 11th, 2026.

In the game, players run a political campaign for leader of a fictional nation, against 3 other candidates, with events, debates, and public opinion in general being driven by LLM models. The premise of the game is to make the campaign (and the nation itself) as custom as possible, with the player being able to create their own policies and speeches in free text, and everything else in the game adjusting itself to that through generative AI models. While some parts use more traditional evaluation mechanics, the idea is for the bulk of the gameplay to be guided by LLMs.

While I enjoyed playing several campaigns, the game is mostly an exploration of how generative AI, and LLMs in particular, can be embedded in games to enable new experiences.

Context

The development of Sway The People! happened at the convergence of three threads: me experimenting with vibecoding, Anthropic's Fable 5 release and my interest in applying generative AI to games. I will describe each one here.

Vibecoding

After using generative AI for several purposes since early 2023, and starting to use coding agents around 2025, this year I am exploring development flows that use generative AI in even more pervasive forms. One of the furthest down the spectrum (and trendiest one) is vibecoding, in which the developer avoid as much as possible looking at the generated code, and drives the development just by talking with a coding agent and accepting whatever it produces - if something does not seem right, the developer just asks the agent to change it again. For Sway The People!, I decided to try this flow: I focused only on the requirements and the overall vision for the project, while delegating all the code concerns to the agent. I will go into more details about my flow further down in this post, in the highlights section. Suffice to say, I think I was able to achieve the vision I had for the project, but I had to follow a more organized and thoughtful approach than most vibecoder-gurus preach about. Despite the success, I still prefer the AI-assisted Engineering approach, in which coding agents are used to speed up the development, but the developer still remains very involved with the final code.

Fable 5

The second thread was the release of Fable 5. Earlier this year, Anthropic announced it had created a model representing a whole new class of intelligence, called Mythos, which it declined to release to the general public; instead, on June 9th of 2026, it released Fable 5, a version of the same model with additional safety measures. What followed was quite a saga: just three days after launch, the US government put export controls on the model and Anthropic suspended all access to it, only restoring it globally on July 1st. On top of that, Anthropic had said from the start that Fable would only be temporarily included in the usage limits of subscription plans, requiring separately billed usage credits afterwards... but the cutoff date kept getting pushed forward (it moved from June 23rd to July 8th, then July 13th, then July 20th), until Anthropic finally announced, two days before the last deadline, that the model would remain a standard part of the higher subscription tiers indefinitely. During those weeks of uncertainty, many people (myself included) rushed to experiment with the capabilities of the model while it was still accessible. Sway The People!, developed through July and August, was one of my main "Fable projects": I used the model for everything in it, precisely to explore what this new class of intelligence could do, expecting all the while that it would become unavailable to me at any moment. Which, fortunately, ended up not happening!

Generative AI embedded in games

The final piece of context has to do with my own interest. I have been following the generative AI boom since early 2023, and I have always had a huge interest in games - as a matter of fact, most personal projects I had before starting to explore AI Engineering were small games. So, it is very natural to merge both trends (I did a little bit of this with LicLacMoe, though that was a very tongue-in-cheek type of project). Now that I have a good understanding of, and experience with, AI Engineering, I feel ready to start experimenting more seriously with games that have generative AI embedded into them. I am very interested in how these models (both for language and image) can expand the set of experiences that games can offer. Especially, it seems to me that they allow for extremely customized experiences, to a level that could not even be dreamt before. Sway The People! was the first experiment on this line, and I already have several other ideas in mind that I expect to explore in the following months.

Highlights

Foundational guiding documents

As I mentioned before, for Sway The People! I decided to go the full vibecoding route, delegating all coding related concerns to the AI agents. In order for this to work without becoming a hellish mess, I chose to set the stage by using the AI agent to generate a few guiding documents beforehand. These documents steer all future work (and are updated whenever needed), ensuring a minimal level of consistency in the project. I used a PRD (Product Requirements Document), a Technical Requirements document and an MVP scope document.

My flow was as follows: I started with a dump of all my ideas for the project into a notes file. This initial file was really a brainstorm: very loosely structured, written with no care for grammar or syntax, and all over the place. I then started a session with an AI coding agent (Fable, through Claude Code), which I used throughout until the guiding documents were finished. I first asked it to read the notes and ask any questions it had to clarify any points, before writing the PRD - this document would only contain product definitions, without any technical decisions or assumption. It took a few back and forth messages until it was ready, and then we moved on to the Technical Requirements document - here would be where all the important technical decisions live, including things like which programming language, which frameworks, and so on. It also took a few messages to be ready. Finally, I asked it to work with me to define the MVP scope for the initial version.

Overall I think this flow worked out fine, and gave better results that what I usually get by jumping straight into asking for a project with some specific features. The documents I described were not the only ones, but they were the new ones I used for this specific mode: I also worked with the agent to create an AGENTS.md, a README.md and an ARCHITECTURE.md files to document all the relevant info and contribution guidelines (both for AI and human agents).

Fable 5 performance

I used Anthropic's model Fable 5 for everything in the development of Sway The People!. Part of the project was experimenting and understanding the capabilities of this model, as it was said to bring a new class of intelligence in comparison with the other frontier-level models (mostly Anthropic's Opus and OpenAI's GTP 5). I found the claims to be mostly accurate: working with Fable really feels substantially different than working with any other model. The thing that most impressed me was its ability to make autonomous decisions that were, by and large, spot on. While working with other models, whenever they would reach a point where something was not very precisely specified and had to make a decision by themselves, I would more often than not have to trace back and course correct it. With Fable, however, I almost always could just let it pick a path forward and run with it, only a few times having to ask it to change something.

Pacing dictated by LLM inference speed

A peculiar aspect of the resulting game is its pacing, especially when using local models. Although I already expected any game that relies on running LLMs locally to have a slow progression, actually playing the result made it very clear that these types of games have to be designed with plenty of waiting time in mind.

The timing will definitely vary a lot based on the hardware of the player and the chosen model. I have a fairly good computer (at least by 2024's standards, when I bought it) with 16GB of VRAM plus 64GB of RAM, and mostly played with models in the 20B-30B range. For me, each creation would take a couple of minutes, making each day take anything between 10 and 30 minutes to play (depending on if it had events, influencer content creation, debates, etc.). Running the game with an 8B model made the pace dramatically faster. Different hardware, as well, should change this by a large factor. This variability seems to me one of the most complex considerations for any game aiming to use local LLMs as the main driver.

Regardless of the variability, the fact that generations always take some time (even the hosted ones) means several structural support things need to be built around them in the game. One such things I had to use in Sway The People! is a generation queue, which makes sure that generations happen asynchronously, sequentially and their results are smoothly integrated back into the game once they are complete. I consider the asynchronous aspect to be mandatory for any game using current generative AI tech in its core, otherwise the game will hang for a prohibitively long time and the user experience will be horrible. Making the generations sequential is also mandatory for most local setups (current customer hardware struggles to supply inference on even a single request at a time, let alone multiple), though it can be optional when using hosted options. And making sure that the results are smoothly integrated into the game is the most tricky one of them all, but it is absolutely essential to keep the user experience fluid. I might consolidate my thoughts about these new architectural concerns intrinsic to generative AI native games on a future blog post, and I will surely keep updating my understanding of them as I develop more projects like this one.

For me, the pacing worked very well. I am used to having several different things going on at the same time and alternating my attention between them, so I played the campaigns as a "background game", making some decisions and then turning to something else for several minutes before coming back to play the "next turn". But I admit I am probably part of a very small slice of the population that would find games with this pacing fun!

Sandbox and customization

The central idea behind using LLMs for the gameplay was to make each campaign extremely custom, in the sense that it would react to the player's choices and words in a way that is not possible with traditional coding. I am fairly confident to say that the final result proved the point.

I ran some really wild campaigns, choosing policies that ranged from fairly conventional to completely unsuited for a nation-wide program. Each time, the game reacted appropriately, even accurately raising the difficulty to an impossible level when the agenda would make no sense for a political campaign. So much so, that I had to put some arbitrary balancing constraints on the initial public opinion, so that even crazy ideas would have a minimal chance of winning the campaign based on the player's performance.

I think the influencers mechanic was particularly nice in this aspect: being able to read how each character would mold the party's agenda in a way to communicate with their particular audience really drove home how unique the new capabilities that LLMs bring for interactive entertainment are.

AI Usage statement

Outside of the software engineering and startup-pilled bubble, the current sentiment with regards to Artificial Intelligence in society is extremely negative. Especially in games, the public opinion is overwhelmingly that AI is a cheap way for companies to extract more profit while providing a lower quality product.

Due to this, I chose to write an AI usage statement for the project. In this statement, I describe why and how I believe AI can be used to provide new and unique experiences in games, and the way I used it while developing Sway The People!. I argue that not only AI makes unproven game genres more viable, but also that it can make each player's experience more unique and customized (as I talk about a few sections above in this post). I understand that the way in which large companies use AI, as a cheap way to quickly produce mediocre assets and cut off personnel costs, leads to a drop in quality and a worse ecosystem state overall, but I also believe that there are other ways in which AI can be used, which are much more beneficial for everyone. By building positive examples of such usages, hopefully we can build a better alternative and steer this technology into a better path.

I expect to include something similar in future projects, at least for the near future.

Other game genres

After having built Sway The People! as a proof of concept for using LLMs as a core mechanic for a game, I look forward to explore the same idea with other genres. While I like the idea of political sims, and enjoyed playing this game in particular, it is not really a genre I play very often. I chose it mostly because of the obvious appeal to use free text during debates and policy definitions (and also the fact that we are on an election year here in Brazil, so it is being talked about all the time).

I already have several ideas for other games using the same approach, or expanding it. All of them in different genres. I expect to be able to finish at least one more project within the year, and maybe a couple for next year. I will, of course, write about them in this blog once I release their first versions.

Future Expansions

I do not plan to expand Sway The People! much further, as I would like to move on to new projects that apply generative AI on other game genres. However, there are a couple of things I still want to implement, and some other ideas that I will leave queued up in case I decide to come back to it in the future.

Nations

The main improvement I want to make is on nations. In the MVP of the game, for every campaign a totally new nation was created by the AI model based on the chosen agendas. There were two problems with this: first, that campaigns were not replayable, if the player wanted to try to run another campaign on the same setting they would need to save at the very start of the campaign and later load that save to replay the entire campaign; and second, that nation creation is probably the most time-consuming part of the entire game, so before even starting to play the player was stuck for about half an hour waiting for the setting to be created.

For the initial release (version 1.0.0), I implemented default nations. Now the player can choose one of 3 pre-defined nations when starting a campaign, so that both of the problems mentioned before disappear. The player can also still choose to have the AI generate the entire nation if they desire, but that is a choice rather than the only possibility.

I want to implement three features related to nations (two of each I am almost certain to do before moving on from the project, the third one I am not sure yet if I will do or keep for a later time): saving the current nation during a campaign, so that the player can replay a setting they really liked; loading custom nations, so that the player can use a saved nation to start a new campaign on (which also has the nice side-effect of allowing for sharing custom nations between players); and finally, an in-game nation editor, so that the player can manually set all parameters of the nation. Saving and loading should be relatively simple features, so I intend to do them in the near future. The in-game editor is a more complex one, so I am still debating whether to implement it or keep it on hold (as long as the load nation feature is available, players can just edit the nation files to handcraft anything they like, anyway).

Campaign lengths

Currently, the game has a fixed length of 14 days for all campaigns. While I discussed briefly with Fable 5 about which length to use for the MVP, this was mostly a dummy value so that I could focus on the rest of the development. I think overall it works pretty well, though I did no research to figure out how common this length in real countries, nor did any comprehensive playtesting to determine if it is the optimal choice.

My idea is to make the length of the campaign a choice when starting a new one, just like games such as the Civilization series usually let you choose to play a short, medium, large or marathon-style session. I will probably settle for something like 14 days for a short campaign, 30 as the medium length and 90 for an epic campaign.

The main concern here is checking whether any balancing needs to be adjusted in all the public opinion calculations in order to make all campaign lengths fun. I think events and debates should not have much problem, as they can both improve and degrade the player's candidate popularity, and opponents also have their own fluctuations; but the influencer system might need to be adjusted, as their impact is always a straight bonus which might become overwhelmingly decisive on longer campaigns.

Media assets

Finally, in order to make the game an actually enjoyable experience for more people instead of a proof of concept, I would need to include media assets: music, images, animations, etc. The simplest route would be to either license or build assets and include them in new releases of the game. I might do this for a few ones: for instance, even during development I inteded to make the background image for the debate screen an actual debate stage (I even had the image to use), but I just never got to it and did not feel it was missing when playing. For simple things like that, I might still include assets.

My long term vision, however, is to also explore how image generation can be embedded into games (as I briefly explored in Chargen), much like Sway The People! already does with text generation. Once I start exploring this, I might circle back to this game and implement it here, for instance by procedurally generating image avatars for councilors, candidates, influencers, etc., or maps for nations with their regions clearly visible. I think it could add a lot of fun to the game. But I don't feel that the current state of the technology and customer hardware available is sufficient to make this feasible yet. My previous experiences trying to have an application that depends on having both an LLM and an image generation model running at the same time in the local machine does not give me much confidence that even people with generally good computers would be able to run it efficiently, and I do not know of any image generation hosted service that allows for a generous amount of free generations each day, like OpenRouter does for text generation. So this is mostly something for maybe 3 to 5 years in the future.

Setup

I developed Sway The People! intending it to be a portfolio project. For such projects, I have a set of minimal criteria I always use. Here is how it complies with those criteria, and in which ways it differs:

I use Github Actions to generate new releases for Sway The People!. Here I made a small update from my previous approach: in all previous portfolio projects, I always configured the workflow to generate the release when code was pushed to the main branch, this reflected my experience in the industry for a long time and worked fine for me through many years. However, it was somewhat clunky in the sense that I always had to keep the main branch stable and do all the development in a separate dev branch, which is overkill for a single developer project, and involved a lot of ritual around the main branch, while also having to rely on arcane commit message conventions to manage versioning increments. For Sway The People!, I changed it so that the release workflow happens triggered by a push to a version tag. This simplifies the process significantly: the version is always obvious from the tag itself, and the main branch is freed from any ritual, better reflecting the state of development.

I have a changelog file and a file with guidelines about contributing, beyond the usual readme file as documentation. This is in addition to all the vibecoding-related documents (PRD, Technical Requirements, etc.) I mentioned before.

I also included automated tests for everything except the UI code. In previous portfolio projects, I always made sure to keep a high test coverage, and favored using TDD (Test-Driven Development) while developing the projects. Since in Sway The People! my approach was to delegate all coding to the AI agent, instead of using TDD I worked together with the agent to include instructions on AGENTS.md, ARCHITECTURE.md, and all other relevant documents, guiding any contributor (AI or human) to extensively use tests for any new development. I think this worked pretty well. Despite not having directly checked the total coverage, I found very few bugs while playtesting (much less than I would have expected from a project of this scope), and while watching the logs as the agent worked I saw that several times it caught errors and bugs on its implementation by running automated tests, fixing them before completing the task. I do not know yet if this is a characteristic of Fable 5, or if other models of different intelligence classes would also achieve the same.

Links

Source code: Github

Executable: Releases