Visuals First Development

I’ve made many games over the years, but not as many as I could have. If you look at my history, you’ll notice long breaks between games, periods in which I did no video game development at all.

Now, admittedly, this was mostly due to my terrible hardware (that did not allow running or developing games) and ever-changing interests. But the second reason for these breaks was my overall discontent with the entire process.

Every time I made a game, I tried a different approach. A different way to do things, to structure things, to plan tasks, to think about games in general, whatever. I wasn’t satisfied with the games that came out of this development, and I wasn’t happy with how hard it was for me to work on them 99% of the time, so I kept improving my process and trying new approaches.

For example, I used to have terrible standards for my folder structure and file naming. Or, well, a complete lack of standards which is what caused a terrible mess.

I also used to leave visuals and sound effects until the very end. Something lots of people, even experts, will recommend online, but which just doesn’t work for me.

Most changes to my process were a slight upgrade, but nothing really worked for me. So I’d finish a game, feel exhausted and dissatisfied, and take a long break before making the next game. That is, until I realized this was happening, and that I had to break that cycle. Because taking these breaks hampered my growth and my skills way more than any “non-optimal dev process” ever could. If I had just made more games, I would’ve been much further along in my journey than I am now.

Thus, some time ago, I finally made a Steam account and tried to launch my first, professional, paid Steam game. It taught me a lot, it made me exhausted again, but this time I did not take a long break before making the next game.

Steam forced me to think much more about marketing, pricing, appeal, finding the target audience. It forced me to focus on all sorts of extra details (accessibility, settings, localization, etcetera) that you would never really focus on in tiny (free) games.

And this showed me a way to change my approach again that worked much better than any other.

If you read the title of this article, you know what’s coming: Visuals First Development. To understand what it is, let’s start with a bit of background and why. (This is, in my view, almost always the best way to explain/teach anything so that people truly understand.)

Why?

Most game ideas, especially when you’re just starting out, are based on theme and genre. You have ideas like “I want to make a shooter!” or “I want to make a game set in the Stone Age!”

This is fine, but it’s not helpful. Those first few ideas never go anywhere because you only have an idea, but not actual game mechanics. You forget to answer the question of “but what do you DO all the time?”

So, your next ideas become more specific, focused on mechanics, systems, and gameplay. You have ideas like “What if we make a shooter where you have to retrieve your bullets again?” and “I want to make a game about gathering food and building shelters in caves set in the Stone Age!”

These are much more actionable. Your idea contains a set of systems to make, of verbs to implement, and you can get started and get something good.

That’s why I’ve had this approach for the longest time. But there’s a flaw! A big one!

People cannot SEE or HEAR your amazing systems and gameplay (without playing the game).

That’s, well, that’s just how it is. People can’t feel your fun gameplay through a screenshot. They can’t really know how satisfying it is to play your game through a trailer.

And then you realize that most successful games aren’t necessarily the best in terms of gameplay or the deepest in terms of content and strategy. They’re the games that were able to communicate they are good through their visuals. They successful games are the ones where players do get a sense of fun and excitement from seeing the game, which prompts them to actually play it (which hopefully confirms that feeling).

The other way around is, well, useless. Players see your game for one second, it does not communicate fun and excitement, so they … never play it and the actual gameplay you crafted for 6 months is irrelevant.

This realization explained a lot of my previous discontent with my own work. I’d build this game for weeks. Then, at the end, I could finally look at a screenshot or full trailer, and I could only think: “This doesn’t look very fun.”

It doesn’t matter if it is or not. (Though I’m also not happy with that most of the time …) It only matters that it doesn’t look like it would be a good time at first glance.

Most of the time this is just a byproduct of putting systems and programming before visuals. After building all my nice systems, I suddenly realize I need to display 5 icons for stuff, and then I realize there’s too little space on the screen, and I apply band-aid solutions, and … the result doesn’t look great.

But just as often, this has nothing to do with graphical quality or artistic skill. The game idea you picked, the systems you made, are at their core not easy to communicate visually. They are inherently not very (visually) appealing when you put it all together and polish it.

I would always end up with the feeling that I picked the wrong idea. That feeling of “darn this idea was NOT the best on the list after all”, simply because the idea made it near impossible for the final, polished visuals to really communicate itself.

It doesn’t matter if you spent 3 months “finding the fun”—and actually found it. If your game does not look fun to gamers passing by, nobody will play, you won’t earn enough money, nobody experiences that fun.

And that’s why I changed my process to Visuals-First Development.

What is it?

It means the project starts by creating the screenshots and marketing material.

Of course, these won’t be final products, these won’t look amazing and polished. You probably won’t even use those in the final marketing.

But the first thing you do for the game is ask yourself: what does an average screen state look like? What will the player be looking at most of the time, and what will therefore show up on my store page to market it?

And then you draw that.

Pick some suitable design basics for the game: fonts, color scheme, decorational elements. (Example: a game set in medieval times can communicate that instantly with a blackletter font. A game about nature can communicate this instantly with a green-brownish safari color palette.)
Pick a soundtrack. (No need to create your own music. Just pick a song, ambience, sound effects, something.)
Sketch the UI. (All of it, the whole thing, buttons in different states.)
Sketch the background and foreground elements.
Sketch some things happening. (Depends on the game. Units moving? Cars racing? Bullets flying?)

That final one is perhaps the most important actually. It takes skill to communicate action through a still image. It requires adding extra detail that communicates your games gameplay … and will also just instantly make it look way more polished.

Then step back and look at it. Does it look appealing? Does it look unique?

Can the player see the genre, the gameplay, the content through looking at the game?
Can the player hear these things from the sound (or a quick mockup trailer you made)?

You should be able to get some varied “screenshots” of the game that you’d typically use to market it. And there, in front of you, is your proof that the idea will work out … or not.

This process is much faster and cheaper than actually building out entire systems and a functional prototype. At the same time, this has been way more useful in sorting through my ideas.

An Example

For example, I once had an idea for a game for my educational online store. It was supposed to teach about money and financial responsibility, and was a mixture of management and incremental. I thought the game would be both a great learning tool and fun to play, with numbers going up and paying off debts. But when I actually sketched what you would probably be looking at … it looked like some boring accounting thing :p

Not because I’m a terrible artist, I think I’m experienced enough, but because the game idea itself was impossible to give an appealing look. The game idea was mostly about moving numbers around, getting money and then giving it away again, mostly through clicking buttons. The satisfaction from earning more and more money in this relatively static way is hard to communicate in a screenshot.

The optics weren’t great—I did not pursue the idea further.

Some time later, my mind came up with a somewhat related idea. Also about money, debts, loans, financial stability. But this idea had a few changes at its core that made it much easier to communicate the fun. For example, it had the idea of having some “curse” put on you while you’re in debt. This allows images such as a lightning strike hitting you (the curse) and a big red number (for debt) in the corner. The idea also made your money into physical objects, instead of just numbers, which allowed an image with a whirlwind of dollar bills flying around you.

These things are much more visually striking and communicate a lot more. And so the images I created were much more appealing. I could look at that and think: “if my final game looks like THIS, it should look fun and be appealing”.

Who cares about marketing? It’s about GAMEPLAY!

I get it. You think your idea is so amazing that people will obviously love it and buy it. You’re not going to “ruin” it by being all about marketing, by focusing so much on visuals that the game itself ends up being shit.

This is what most people think and feel, and what I felt for the longest time too. We’ve all seen games that look terrible become a success anyway. We’ve also all seen games that look amazing but end up a flop with terrible ratings because there wasn’t any meaningful gameplay inside.

In the end, you will always need a game that’s at least okay (in terms of gameplay and content). You will still spend a lot of time on that.

My point with this approach is really just to flip the order of operations.

To start with the visual communication, and then start actually building that.

To have some specific point you’re working towards. To have confirmation that, as long as you put in the work (and no major problems arise), the game will communicate how fun it is to anyone that sees it. To have an easier time programming the gameplay because your visuals already constrain what you can and can’t do—where things should or shouldn’t go.

This is great for motivation and for staying on track.

It also allows putting up your game’s page, and promoting it fully, very early on. I’ve already had a few games so far that had a public page—which looked at least good enough—from the first week of development. I was able to constantly link to it, show it off, refer to it, without ruining my reputation because the page only had gray boxes and programmer art. I was able to constantly refer to it as a sort of milestone to hit with the actual game.

This approach still allows deviating from it, of course. If you want, you can completely change everything halfway through, though it’s not recommended :p If you feel your focus on visual appeal is ruining the game, by all means abandon it.

If you’re just making games for fun, with no intent to sell or acquire other players, then you can obviously ignore this too. This entire approach is about communicating to others that your game is fun so they will buy it! If you don’t care about any of that, then great, do whatever you want.

But if you do want other players or income from your games, then I feel like this is the way. (And I’ve seen many other developers confirm it since.)

Only developing what you “feel like making right now” is a recipe for unfinished games without a target audience. Believe me, I’ve been there. Numerous times.

Believing all your ideas are so amazing that anyone will immediately understand is just a recipe for desillusion. I’ve been there as well. Numerous times.

In short

Your biggest marketing challenge will always be communication.

Communicating something as complex as an interactive game to strangers, in the blink of an eye, with static images or maybe even text.

So,

Discard any ideas that inherently make this impossible or very hard. Don’t fight an uphill battle—game dev is hard enough as it is—find a better idea.
Do some quick sketches and mockups of what various parts of the game will look like in the end. Most importantly, make mockups that show fun things happening, which will tell you whether it’s possible and what kind of gameplay/visuals you need for that.
Make these good enough that you could put them on a Steam page and already set it to public without feeling (too) ashamed. They obviously don’t have to be amazing pieces of art (better not waste time on that), but they should be polished enough that you can actually make that judgement call about appeal.
Now you should have a clear target for your actual game to hit, while you can start finding an audience and validating the idea from day one.

You might still feel that this is putting the cart before the horse. Putting shiny visuals and superficial stuff before actually making the game and testing if it’s fun. But it’s not. If you have an image that looks fun, then you can surely program your way to achieving that image … and then the game will likely be fun.

I’ve been at this for a while now. You can see my game dev website or my Itch.io profile and find 15+ years of games. Every approach I tried did not really work for me. In fact, it was so demotivating and exhausting that I took long breaks.

Many things I tried were “golden rules” or “advice from experts”, such as the well-known “finding the fun” and “the game should be fun with gray boxes, only add the visuals at the end”. These things made development a bit faster, or led to slightly better games, but they never brought me any real success or even satisfaction. Because I’d focused on the game loop and the content first, the final game always ended up looking wonky (because I hadn’t realized visual constraints) OR it just did not look fun (because I hadn’t realized my core game loop was hard to communicate with a screenshot).

Sure, maybe I knew the game was quite fun. Maybe my friends and family that tested it were like “it’s a lot of fun, I’m sure some people will buy this”, but that’s because they played it. Your customers, the typical shopping gamer, has obviously not played it and only has the first impression of visuals and sound to go on.

This new approach allowed me to instantly reduce hundreds of ideas I thought “had potential” to a more manageable number. It only takes an hour or two (for an experienced illustrator) to get representative mockups, and they tell you a lot. They even tell you a lot about other ideas if they’re somewhat similar.

I only found success after 15+ years once I used this visuals/marketing-first approach. That’s saying a lot.

The approach I’ve outlined has a lot of common with the pitch deck approach that I’ve seen other successful developers talk about.

They pretend they have to sell this idea to some publisher or their boss.
They make a slide presentation about the game: concept art, elevator pitch, marketing plan, release specifics
They really try to make that presentation look as polished, professional, and convincing as possible.

I’ve tried this as well. It has similar positive effects to the visuals-first approach, but I thought it was less effective and too much work for small games. For one bigger game idea of mine, this felt natural and worthwhile to make. (Which makes sense, because that bigger game idea is actually something for which you’d try to find investors or publishers, who always ask for a pitch deck.)

In the end, the idea is the same, though. You’re required to think about convincing someone that your game is fun (from text/images/presentation alone). If you can’t do that easily, it doesn’t matter how amazing your execution of the idea is, selling it will be an uphill battle.

One nice benefit of this approach is that you have a really nice archive for your idea. I dropped that big game idea of mine, then found my pitch deck years later, and it was so detailed/specific and convincing that I wanted and could have immediately started to make the idea. (… if I wasn’t busy with something else already and still felt like I should make some smaller games first.) It’s just a nicer and more robust way to mark down ideas than some text document.

Those were my thoughts for today,

Pandaqi