It became pretty obvious that visuals had to be my next major improvement area.
The type of game I picked is already well known. There are dozens of games on the market with similar mechanics. So if I wanted anyone to notice mine, I couldn't rely only on gameplay. It had to look different enough and appealing enough for someone to actually want to try it.
That pushed me towards custom assets.
Procedural vs custom
The easiest way I found to think about procedural and custom assets is how they are created.Procedural assets are basically built from geometry, coordinates, rules and formulas. They can usually scale quite predictably between different screen sizes because the game knows how to redraw them.
Custom assets are drawn images. They normally look much better and can give the game a more unique style, but they are also much more annoying to work with. They have a fixed resolution, fixed proportions, fixed framing, and you somehow need to make all of that work across phones, tablets and PCs.
Obviously, real games usually mix both approaches. UI can be procedural while characters, backgrounds and other decorative elements are custom.
There is no one correct way.
The problem for me was that I had basically zero game-art or design skills. Creating nice procedural assets myself would mean learning another whole area.
Custom assets felt easier because modern image generation tools could create things I simply could not draw.
So that was the path I went with.
Generating an image is not the same as generating a game asset
ChatGPT image generation produced some really nice artwork for me.
The problem started when I tried to actually use it in the game.
Images would be the wrong size, wrong format, framed incorrectly or contain elements I didn't need. Sometimes the artwork looked great on its own but became completely unusable once placed into the actual game.
My first idea was, naturally, to solve this GenAI problem with more GenAI.
Codex and other coding agents can write very decent Python scripts for manipulating images. Cropping, resizing, removing backgrounds, converting formats, all of that.
So I tried to build a basic pipeline where I could take generated artwork and automatically turn it into something ready for the game.
It sort of worked.
Which was actually worse than not working.
The files came out. The images were cut. But there were always small problems. A few pixels missing here, too much empty space there, transparent edges looking strange, different images framed slightly differently.
For a normal script, being 95% correct can be great.
For visual assets, that last 5% is often exactly what makes something look wrong.
That's where Canva came to my rescue.
Not exactly the most advanced game-development pipeline, but it had one major advantage: I could understand it.
I could take the generated artwork, crop it manually, resize it, clean it up and export it in the dimensions I needed.
And this mostly worked.
It was also very manual and quite boring.
For a few images, it's fine. For dozens of assets and variations, it becomes a real job.
But it got me moving again.
One lesson I learned the hard way is that resolution alone doesn't tell you enough.
Two screens can have similar resolutions but still make the same design look very different. Screen size matters, pixel density matters, scaling matters, display type matters.
Text and small UI elements were especially noticeable.
This is where it really sucks to be a perfectionist because there are just too many combinations.
Different phones. Different tablets. Different monitors. Different aspect ratios. Different scaling settings.
You can spend forever trying to make everything perfect.
At some point, I decided not to.
A released product seemed more useful than a theoretically perfect product that never gets released.
So I tested on the devices I had. I sent builds to friends and family with different phones and computers. I fixed obvious problems.
Then I decided that was enough for prerelease testing.
My thinking was simple: if real users later tell me something is broken on a particular device, I can fix it then.
A good rule is to create images bigger than you actually expect to display them.
Either think about the biggest screen where this asset might appear, or create it several times larger than the smallest size you plan to use.
Scaling things down usually works pretty well.
Scaling things up is tricky.
I didn't know that when I started.
So I ended up with one set of assets that looked pretty good on phones, okay on tablets and not quite as good on larger PC screens.
Could I have done better? Absolutely.
Did I want to go back and regenerate and rebuild all the artwork at that stage? Absolutely not.
It was good enough to continue.
And “good enough to continue” became the key rule for this whole project.
I basically went from “I need game art” straight to “let's generate some images”.
What I probably should have done first was spend a bit more time learning how games normally handle assets, scaling, textures, screen sizes and UI.
LLMs were helpful here, but sometimes maybe too helpful.
They kept helping me solve the problem I gave them. The way I understood that problem.
If I had a bad image, they helped me resize it.
If my workflow wasn't working, they helped me fix it. Even if it was the wrong workflow from the beginning.
If I had already made the wrong decision two steps earlier, they were still perfectly happy to help me with step three.
And because things kept appearing on screen, it felt like progress.
And progress it was, but probably not the most efficient kind.
I think if I had spent a little more time understanding the theory first, I would have found a cleaner workflow and probably ended up with better results as well.
For some reason I didn't approach this one the same way as everything else. I didn't start by asking an LLM how I should build some sophisticated audio pipeline.
I just Googled sound libraries.
And there are loads of them.
Free sound packs, donation-based libraries, cheap asset packs. I went through a few, found sounds that fit the game and asked my coding agents to implement them.
Compared with the visual side, this was almost suspiciously easy.
The downside of existing audio libraries is that you need to find the right sounds, and they can be quite generic.
If you want something more unique, eventually you probably need to make your own.
For my next game, I actually tried that. I generated a lot of the sound effects and music myself using modern audio generation tools.
I used ElevenLabs and was genuinely surprised by how good it had become. I managed to generate dozens of effects I needed within the cheapest subscription tier I tried.
And that was another reminder of how quickly all of this is changing.
About a year earlier, I had experimented with some early game-generation tools and coding agents. They were pretty hopeless, very basic. What I was seeing on my screen now didn't feel possible back then. At least - not possible for me.
Now I had a game that looked more or less how I wanted it to look, sounded almost how I wanted it to sound and was actually playable.
That was exciting.
I really thought I could see the finish line.
The game worked. I tested it. Friends and family tested it. I fixed the obvious problems.
All I had to do now was publish it.
How hard could that be?
The problem started when I tried to actually use it in the game.
Images would be the wrong size, wrong format, framed incorrectly or contain elements I didn't need. Sometimes the artwork looked great on its own but became completely unusable once placed into the actual game.
My first idea was, naturally, to solve this GenAI problem with more GenAI.
Codex and other coding agents can write very decent Python scripts for manipulating images. Cropping, resizing, removing backgrounds, converting formats, all of that.
So I tried to build a basic pipeline where I could take generated artwork and automatically turn it into something ready for the game.
It sort of worked.
Which was actually worse than not working.
The files came out. The images were cut. But there were always small problems. A few pixels missing here, too much empty space there, transparent edges looking strange, different images framed slightly differently.
For a normal script, being 95% correct can be great.
For visual assets, that last 5% is often exactly what makes something look wrong.
That's where Canva came to my rescue.
Not exactly the most advanced game-development pipeline, but it had one major advantage: I could understand it.
I could take the generated artwork, crop it manually, resize it, clean it up and export it in the dimensions I needed.
And this mostly worked.
It was also very manual and quite boring.
For a few images, it's fine. For dozens of assets and variations, it becomes a real job.
But it got me moving again.
Not only size matters
The next issue was making everything look good on different devices.One lesson I learned the hard way is that resolution alone doesn't tell you enough.
Two screens can have similar resolutions but still make the same design look very different. Screen size matters, pixel density matters, scaling matters, display type matters.
Text and small UI elements were especially noticeable.
This is where it really sucks to be a perfectionist because there are just too many combinations.
Different phones. Different tablets. Different monitors. Different aspect ratios. Different scaling settings.
You can spend forever trying to make everything perfect.
At some point, I decided not to.
A released product seemed more useful than a theoretically perfect product that never gets released.
So I tested on the devices I had. I sent builds to friends and family with different phones and computers. I fixed obvious problems.
Then I decided that was enough for prerelease testing.
My thinking was simple: if real users later tell me something is broken on a particular device, I can fix it then.
Start bigger than you need
One thing I really wish I knew before I started was that source asset size matters a lot.A good rule is to create images bigger than you actually expect to display them.
Either think about the biggest screen where this asset might appear, or create it several times larger than the smallest size you plan to use.
Scaling things down usually works pretty well.
Scaling things up is tricky.
I didn't know that when I started.
So I ended up with one set of assets that looked pretty good on phones, okay on tablets and not quite as good on larger PC screens.
Could I have done better? Absolutely.
Did I want to go back and regenerate and rebuild all the artwork at that stage? Absolutely not.
It was good enough to continue.
And “good enough to continue” became the key rule for this whole project.
A little theory goes a long way
Working on the visuals taught me something very simple: sometimes spending a little time learning how something is properly done can save a huge amount of time later.I basically went from “I need game art” straight to “let's generate some images”.
What I probably should have done first was spend a bit more time learning how games normally handle assets, scaling, textures, screen sizes and UI.
LLMs were helpful here, but sometimes maybe too helpful.
They kept helping me solve the problem I gave them. The way I understood that problem.
If I had a bad image, they helped me resize it.
If my workflow wasn't working, they helped me fix it. Even if it was the wrong workflow from the beginning.
If I had already made the wrong decision two steps earlier, they were still perfectly happy to help me with step three.
And because things kept appearing on screen, it felt like progress.
And progress it was, but probably not the most efficient kind.
I think if I had spent a little more time understanding the theory first, I would have found a cleaner workflow and probably ended up with better results as well.
Bonus: what about sound?
I was making a video game. Video games need sounds.For some reason I didn't approach this one the same way as everything else. I didn't start by asking an LLM how I should build some sophisticated audio pipeline.
I just Googled sound libraries.
And there are loads of them.
Free sound packs, donation-based libraries, cheap asset packs. I went through a few, found sounds that fit the game and asked my coding agents to implement them.
Compared with the visual side, this was almost suspiciously easy.
The downside of existing audio libraries is that you need to find the right sounds, and they can be quite generic.
If you want something more unique, eventually you probably need to make your own.
For my next game, I actually tried that. I generated a lot of the sound effects and music myself using modern audio generation tools.
I used ElevenLabs and was genuinely surprised by how good it had become. I managed to generate dozens of effects I needed within the cheapest subscription tier I tried.
And that was another reminder of how quickly all of this is changing.
About a year earlier, I had experimented with some early game-generation tools and coding agents. They were pretty hopeless, very basic. What I was seeing on my screen now didn't feel possible back then. At least - not possible for me.
Now I had a game that looked more or less how I wanted it to look, sounded almost how I wanted it to sound and was actually playable.
That was exciting.
I really thought I could see the finish line.
The game worked. I tested it. Friends and family tested it. I fixed the obvious problems.
All I had to do now was publish it.
How hard could that be?