In the last dev log, I wrote about starting Bravado over with a better foundation.
Looking back at it now, the difference is kind of ridiculous.
The project has advanced much faster than I expected, but not because I suddenly found a magic way to generate an entire game.
If anything, I learned the opposite.
The biggest improvement came from stopping trying to work on "the game" and starting to work on very small pieces of it.
Small iterations changed everything
Coming from a development background, this probably should have been obvious to me sooner.
AI is much better when I tell it exactly what I want.
Not:
"Build this big system."
But:
Here is what already exists.
Here is the behaviour I want.
Here is where the state should live.
Here are the things this change is allowed to touch.
Here are the rules that cannot break.
Now implement this one piece.
Then I test it, look at what happened, and move to the next piece.
If something feels too big, I split it again.
That simple change has massively reduced the amount of mistakes AI makes.
Instead of trying to generate entire interconnected systems in one pass, development has become a long series of small, controlled iterations.
And those iterations compound.
A system I finish today becomes infrastructure for something I build tomorrow.
That is where the speed really started getting strange.
This also suits how I have always liked developing
I have been a developer for years, but strangely enough, writing code has never really been my favourite part of development.
I can do it.
I just don't particularly enjoy spending hours writing boilerplate or implementing something I have already completely solved in my head.
The part I have always liked is designing systems.
Figuring out where things should live.
How systems communicate.
What should own a piece of state.
How a feature behaves when something goes wrong.
And, probably most importantly, how someone is actually going to use it.
I like building systems that make life easier for the user rather than systems that force the user to understand how the developer decided to build them.
AI-assisted development has pushed me much further toward that part of the job.
I spend more time designing the architecture and behaviour, breaking problems into manageable pieces and deciding what should happen.
Then AI handles a lot of the mechanical implementation.
I still review it.
I still test it.
I still find things that make me ask what the hell it was thinking.
But I am spending a much larger percentage of my development time on the parts I actually enjoy.
Bravado is becoming a game
The funny thing is that all of those tiny iterations eventually stop looking tiny.
Since the previous dev log, Bravado has gone from having the basic foundation of a strategy game to having a lot of interconnected systems actually running together.
Villages now have levels and building slots.
Buildings exist as individual instances rather than just abstract upgrades, and multiple copies of the same building can exist when it makes sense.
Buildings can be constructed, upgraded and demolished.
Resource production, storage and population are tied into those buildings.
Armies can be recruited, moved around the map and sent to other villages.
Different unit types have different purposes, including offensive troops, defensive troops, ranged units and scouts.
Villages can be attacked and captured.
Scouting has its own information rules instead of simply revealing everything.
AI factions expand, develop villages and fight.
There is a campaign clock, different game speeds, day and night, and weather can affect gameplay.
There is now a proper trade system where villages can create recurring trade routes, including telling a village to keep a minimum reserve of a resource instead of blindly exporting everything it has.
The geography has started mattering as well.
Rivers can block movement and trade.
Bridges can open those routes.
And because these mechanics are being added on top of existing systems rather than built as isolated features, one change can naturally affect several parts of the game.
A river isn't just something pretty drawn across the map.
It affects whether an army can reach its target.
It affects trade.
It affects what the AI can do.
It affects what the player needs to build.
That is the kind of interaction I wanted Bravado to eventually have.
It is happening much earlier than I expected.
The game is starting to build on itself
This is what I mean when I say development has felt almost exponential.
Not literally exponential in some measurable mathematical sense.
It is the compounding effect.
At the beginning, implementing something meant first creating everything that thing depended on.
Now a lot of those foundations already exist.
If I add something involving construction, there is already a construction queue.
If something needs to happen over simulation time, there is already a campaign clock.
If something needs to know whether two places can interact, there is already route evaluation.
If a system needs information from a village, there is already an established runtime state.
If I add another screen, there are already UI components and patterns it can reuse.
The project slowly becomes a toolbox for building more of the project.
That is when development really accelerated.
AI didn't replace the architecture
This has also changed how I think about using AI for development.
There is a massive difference between asking AI to make decisions for you and using AI to implement decisions you already understand.
I don't really want the AI deciding what Bravado should be.
That is the fun part.
I want to decide how armies should work.
I want to decide what information the player should have.
I want to figure out whether a mechanic is annoying, interesting or completely unnecessary.
The AI is extremely useful once I can turn that decision into a concrete engineering problem.
The more specific I am, the better the result tends to be.
And when AI produces something wrong, very often the solution isn't writing a more aggressive prompt.
It is reducing the size of the problem.
That lesson has probably improved my workflow more than any particular model upgrade has.
I am also terrible at recording this
Something else I am trying to do more of is actually record development.
This is surprisingly difficult for me.
Not technically.
I am just not used to documenting what I am doing while I am doing it.
Normally I open the project and immediately disappear into whatever problem I am working on.
I jump between Unreal, code, logs, tests, UI, random notes and occasionally drawings.
I might spend twenty minutes investigating something, realise my original idea was stupid, undo half of it and go in a completely different direction.
That feels completely normal while developing.
The moment I press record, suddenly I become extremely aware that I am supposed to be showing something.
So the videos are probably going to be rough for a while.
They aren't trailers.
They aren't carefully scripted showcases pretending the game is further along than it is.
They are basically snapshots of whatever state Bravado happens to be in when I remember:
Oh yeah. I should probably record this.
Hopefully I get better at that part too.
There is still a lot missing
Bravado is still very early.
There is placeholder art everywhere.
There are systems I know I will redesign.
There are parts of the UI that need a lot more work.
Balancing is barely something I can seriously talk about yet because so many numbers are still changing.
And there are bugs.
Obviously.
But the important difference compared with the previous dev log is that I am no longer mostly building the foundations required to eventually make the game.
I can actually start making decisions based on how the game feels.
Does attacking feel worthwhile?
Is information too easy to obtain?
Does geography create interesting decisions or just annoy the player?
Does managing several villages become interesting or does it become admin work?
Those are much more interesting problems to solve than:
"How the hell am I going to make all of this communicate?"
So... what now?
When I started Bravado, one of the biggest questions was whether I could realistically build the game I had in my head.
That question hasn't completely disappeared.
The scope can still very easily become stupid if I let it.
But it isn't the question I think about most anymore.
Now it is more:
How far can I take this while keeping the systems simple, understandable and fun to use?
Which, conveniently, is the part of software development I have always liked the most.
At the end of Dev Log #2, I felt like I finally had the foundation.
Now I'm starting to see what happens when you keep building small things on top of it.
Turns out they add up pretty quickly.