---
title: 'I Vibe-Coded a Tycoon Game with PHP and Laravel'
source: 'https://youtube.com/watch?v=lx_fRq-azKA'
video_id: 'lx_fRq-azKA'
date: 2026-08-12
duration_sec: 981
---

# I Vibe-Coded a Tycoon Game with PHP and Laravel

> Source: [I Vibe-Coded a Tycoon Game with PHP and Laravel](https://youtube.com/watch?v=lx_fRq-azKA)

## Summary

The video showcases a large-scale 'vibe coding' project: an AI software tycoon game built with PHP and Laravel, totaling 33,000 lines of code. The creator demonstrates the architectural separation between the Laravel web layer and the pure PHP game engine, highlighting the benefits for testability and flexibility. The video also covers the game's features, simulation capabilities, and the iterative process of balancing the game based on user data.

### Key Points

- **Project Introduction** [00:01] — The creator built an AI software tycoon game using PHP and Laravel, emphasizing it was 'vibe coded' with AI assistance (GPT 5.6, Soul, Luna) over 86 commits, and deployed to Laravel Cloud.
- **Codebase Size and Goals** [00:32] — The codebase is 33,000 lines of PHP. The two main goals were to create a personal game for offline entertainment and to experiment with a large codebase for AI coding, moving beyond small demos.
- **Architecture Overview** [02:04] — The game uses Laravel and Livewire for the web interface. The main game logic is in a separate 'app/game' folder, which is pure PHP and independent of Laravel, allowing for flexibility and testability.
- **Action Submission Flow** [03:43] — The flow for submitting actions goes from the Livewire component to a service, then to the game engine, and finally to the database. The 'persisted game service' acts as a bridge, keeping the game engine decoupled from Laravel.
- **Separation of Concerns** [05:16] — Laravel-specific code (Livewire, services, models) is in 'app/Livewire', 'app/services', etc., while the game engine is entirely in 'app/game'. This separation means the engine could theoretically be used with other frameworks or a native mobile app.
- **Why the Complexity?** [09:25] — The complex structure is justified by two reasons: reproducibility (for testing game balance via simulations) and flexibility (to easily make changes like shortening the game from 24 to 12 months based on user behavior).
- **Simulation and Testing** [09:42] — The engine allows running simulations from the terminal (e.g., 'game simulate 50') to test different strategies and balance. This was crucial for tuning the game's difficulty and win/loss scenarios.
- **Iterative Balancing** [11:43] — Based on user data, the game was shortened from 24 to 12 months because players were dropping off early. This architectural change was made possible by the flexible design.
- **Replayability and Randomness** [13:16] — The game supports replay via saved JSON data, and randomization uses seed numbers to reproduce specific scenarios, making the game 'random, but not really'.
- **Personal Goal Achieved** [14:11] — The creator successfully achieved the goal of creating a game for personal enjoyment, with enough complexity to be interesting even for the developer.

### Conclusion

The video demonstrates a successful large-scale 'vibe coding' project, emphasizing the importance of a clean architectural separation between the framework and the core logic. This approach enables effective testing, simulation, and iterative improvements, making the game both fun and maintainable.

## Transcript

something really exciting. I've built or vibe coded AI software tycoon for myself in PHP and Laravel, but by saying vibe coded I didn't mean one shot. This was the tweet 86 commits mostly written with GPT 5.6 Soul and Luna on my way to
Laracon and during Laracon I deployed it to Laravel Cloud and you can actually play this game. And in this video I will show you the architectural code base which is pretty big. So this is one of the slides overview I will show in this
video. This is 33,000 lines of PHP. So there's a huge game engine of tycoon logic and scenarios and then Laravel and Livewire is a thin layer on top. With that game I had two goals. First goal is to build myself a
game to basically kill time on a plane while being offline, but also I wanted to experiment with some pretty big code base for my own experiments with Laravel and PHP and AI coding. So I said to myself enough of small demos and crowds
and various starter kits, let's go big. So it took me like full three days of prompting, reviewing and re-prompting and in this video I will show you the architecture, the main overview of the code base with various design patterns
inside which at first may seem over complicated and over engineered. So kind of a small first teaser you will see app game folder with a lot of sub folders game folder with a lot of sub folders like domain like factory strategies and
stuff like that. So this is the engine and well a lot of PHP code, not Laravel code, but along the way you will see the reason why it was structured this way for flexibility, for testability of that engine and flexibility to make changes
and simulations for the game even without playing it. So welcome to my AI software tycoon built with PHP. So, let's take a look at overall architectural structure. So, on the homepage you start a company which
starts a new game which is Laravel and Livewire component public page with play and generated ID. So, in the routes we have two Livewire components. Route
Livewire is full page Livewire component and new game is for homepage and then I land on play game which is game board Livewire component, this one. And then
the main kind of code magic starts when you choose some kind of set of actions like for example bootstrap launch which activates two actions and generate action basket. What happens if we submit the actions for the first month? Let's
do that visually and then I will show you the code. So, here we have a choice and this would be another action. Now the code. So, if we start from routes web we have Livewire components to play the game which is game board. Inside of
that game board we have a lot of classes like services, factories and stuff like that for internal behavior. And I'll get to some of those in a minute. The most important one for us is web game play service which will basically submit our
actions. So, this Livewire component or it could be a Laravel controller actually renders game board blade. And this is also a big file but what I want to emphasize is that button to submit actions. This is wire click but again it
could be a Laravel blade submit button that calls that method but for dynamic behavior I chose Livewire. And then the method submit actions in the Livewire component after some validation it calls
this. This is the main thing to submit actions. There are many, many more pieces of logic but I want to focus on the main architecture on the path of Livewire controller to service to database and so on. So, web game play
database and so on. So, web game play service is in app services, which has the purpose of controlling basically web game, which could be terminal game, game from somewhere else, but in the browser. For web, we have DB transactions to
start the game, for example, or begin month also DB transaction and submit actions also DB transaction, which calls persisted game service. And that persisted game service is a layer outside of app services, which is in app
game folder. And this is the main differentiation. So, everything that is differentiation. So, everything that is in app game folder is a PHP class and not Laravel. So, persisted game service works only with PHP logic and PHP
variables and some repositories here and there, but it doesn't know anything about Laravel. So, Laravel calls the service of game engine. So, in this case, that persisted game service submit actions has private method advance and
save, which has another private method. So, a lot of methods here and there. And actually is, but I want to simplify that for you. I asked Claude Code to draw a diagram. So, this is the main point. Everything that Laravel does is in the
folders of app Livewire, app services, app models, database layer and console commands. But then, whatever is called from the internals, it's in app game folder and everything down below is in app game, which doesn't know anything
about Laravel. So, PHP layer, the main game engine, the biggest part is totally separated from Laravel, which means that this part can be written in whatever
other framework actually changed from Livewire to just plain Laravel to controllers or something, maybe even Symphony. I haven't tried it. And also, I'm planning to build a native PHP mobile application, so that would be the
check of this if it remains separated. But that is actually the goal. And here on the left, you see the number. So those parts below contain 33,000 lines of code outside of Laravel. So Laravel is kind of thin layer, you would call it
thin for web visual presence. And how that game engine works in general, again, very brief overview is this public method advance, which you saw public method advance, which you saw already. In here, game advance is just
is built with factory in this case, but if we open the actual file that is responsible for implementation of that advance, it's actually command-driven game, which implements the interface. So implements game and inside here, we have
a lot of interfaces. Actually, app, game, and then No, actually outside of it. So game interface could be found in app game. Again, app game is a huge folder with subfolders. And here in the domain, we should see game here
somewhere. Yep, this is interface for the game with only one method advance. And then the implementation of that method for command-driven game in this method for command-driven game in this case is this. Depending on which command
it is, begin month, submit actions, or other incidents or events, then we, well, submit actions, for example, in this case. And then again, a lot of private methods inside of the same command-driven game. So the means are
apply actions, apply progress, apply this and that, and then continue turn for submitting the next action. So this is very, very brief overview, so you would understand how complex it is, the bottom part. And then in the database,
the games are saved in well, database. Some of them with user ID, but most of them public so people can register if they want after the game or during the game. But this is the JSON as I mentioned structure with replay if you
want to. This is another angle. So all the games can be replayed with saved data. So from the launch of this project I see already almost 300 games were
played. Cool. Also, I asked CloudCode to build this diagram how the data is actually traveling. So from Laravel have submit actions from Livewire in this service. You saw that already DB transaction, which calls persistent game
service, which is in the layer of game engine. And then game repository is the layer in contracts, which is basically the layer between Laravel and game
engine. Kind of translating and getting the data from and to. So game repository maybe not necessarily database, it may be text files for example, the game. So eloquent game repository is one of the implementation of game repository. So
now when we found the game and we have the game session, then we call game advance from the game engine, which does all the turns and details about that command and that session and that game. And then again, it is saved in the
database with game repository going back from game engine to Laravel level in app repositories. And we can take a look at that file eloquent game repository. And
here we see eloquent. Now, you may ask why so complicated? Why those different layers instead of just basically one folder of app game? For two reasons, at least two reasons. First, reproducibility of the game engine. So,
how to test the balance of the tycoon, what decisions affect other decisions and results, I wouldn't be able to test it myself manually. So, I needed reproducibility and simulations. And with that engine, I can simulate
quite a lot of things without playing the game. For example, in the terminal, I can do game simulate and how many runs, for example, 50. And in a few seconds, the game will actually be played with random strategies, and this
is how many victories. So, good results in terms of tycoon financials, then 24 survived and zero failures. If the game is played well the right way. But not only that, there are different scenarios and different strategies to use. So, for
example, one of the strategies is growth first, and in growth first strategy, the results of victories may be different. For example, one failure out of 50. So, business point of view, if you start growing too quickly, there's higher
risk, higher chance of failure of the business. So, those PHP classes allow me to play not only from the web, but from the terminal and do various simulations
those simulations don't touch the database. As you can see, they are reported as JSON in the same code base and the storage. So, this was actually what I've been doing over a lot of commits, trying to run the simulations
and looking at what numbers feel wrong and try to run like hundreds of simulations, and then refactoring the game engine, trying to push one or another decision strategy. And for games like this one, the tycoon, the strategy
games, this is the main point, the the the strategy, the win or loss scenarios and logic. And also, another reason for such complicated structure is flexibility because I don't know what I don't know. So, after the first run with
first users, what I noticed is that the game is too long. So, it was 24 months, which means 24 steps, and each step requires two actions. So, quite a lot of things to think about. So, I shortened it to 12 months because I saw in the
database that the users are playing until like month four or month five. So, it's too long for them. Probably, of course, they didn't expect that to take long. And also, I changed the texts on the homepage and stuff like that. But,
there was architecturally fundamental change in the engine from 24 steps to 12 steps, which affects basically all the game workflow. And with that, the game became easier, which was also one of the points because I saw that 24 months is
too hard to survive with current parameters. So, in the repository, there was a set of commits changes with version two campaign turning into version three campaign with different phases of refactoring. But, it was all
powered by internal files like scenarios. So, you can see AI support says this is the main kind of use case scenario of that game. Also, incidents, also strategies. So, again, balanced growth, first and other strategies which
were part of the simulation. And also, as I mentioned, reproducibility, as I mentioned, reproducibility, replayability of the game also has a lot of classes structure of how to replay the game by its JSON. Also,
randomization is not that random. So, I have some seed numbers to put into simulation to reproduce kind of the same scenario. Random, but not really. This is kind of a separate topic. So, yeah, this whole huge engine game engine of
33,000 lines of code just to change months to 12 from 24 and balance the game to have better options of winning and stay
profitable with cash. And also, as you can see under the hood, it is powered by a lot of numbers. So, this is just the beginning and here down below you see more metrics of company health. So, imagine how many things should be
calculated under the hood, and this is not all. There are detailed company stats. So, these are the metrics that define the actual outcome. So, I was having fun playing that game on the plane without internet because I didn't
know myself how to play and how to win. There are just too many parameters, which makes the game interesting. So, I did succeed with my goal to create the game for myself to have some downtime on the plane and simulate interesting AI
company scenarios. So, yeah, this was the brief overview of the code base of AI Business Tycoon. You can play it at ai-business-tycoon.laravel.cloud.
where I will increase marketing and hire a support specialist. And here I have MRR already on the right side. So, I wish that your MRR would be bigger than expenses and that you would be profitable not only in month number
profitable not only in month number four, but until the very end of month 12 of campaign. And if you want to see the full code base, I'm not making it public on GitHub. I'm making it invite-only for Laravel Daily Premium members. This is
member, not just courses and premium tutorials, but also on top there's a menu item project examples. So, I added those project examples month after month, and this is the new one, AI Business Tycoon. You can get GitHub
invitation if you are premium member, which means you want to support my work of continuing doing that with even bigger projects. So, I'm excited to experiment some more and show what I find on YouTube. And also, if you're
interested in some part of that code base or what questions you have about design patterns, ask them in the comments and then I will shoot a follow-up separate video because there are a lot of parts of the code base I
can talk about or maybe even a full course if there is enough room for questions and content. We'll see. What do you generally think about that code base, which was again mostly written by AI but with heavy human review on my
side? I had a lot of time on the plane while traveling to Laracon. So, this is kind of my version of vibe coding in mid-2026. you structure such code base in a different way? Let's discuss as usual in
the comments below. That's it for this time and see you guys in other videos.