Which one describes you best?

Most of us game developers are bottom-up thinkers. Personally, I am not. I’m a total top-down thinker & developer (and unjustifiably proud of it).

This quote may be from an altogether different domain, but it’s still applicable when dealing with bits and bytes as with dollars and cents.

Each approach can be quite simple—the top-down approach goes from the general to the specific, and the bottom-up approach begins at the specific and moves to the general.

Bottom-Up

Say we’re tasked with developing a game prototype. It’s a game about skateboards. There’s 3 main phases to the game…. Build, Practice, and Compete. In the build phase, the player assembles a skateboard from skateboard parts. The practice phase is single player free-style in a sandbox with your fancy new skateboard. The Compete phase is multiplayer.

Most of us are bottom up. We start with a small piece, build a few more pieces, and work our way upwards until we have a game.

We might start with the building phase, start defining exactly what a “part” is. We might write some code that lets the player move the part around. Then, maybe we start writing code that glues the parts together to make a basic skateboard, etc.

Or, maybe we’d start with the practice phase. We’ll write some code that lets the player get on/off the skateboard. Then, allows the skateboard to roll. Then, allows the player to jump. Etc.

Start with the details and build upwards.

Top-Down

A Top-Down developer like me, though, works the other way. We start with the highest level concept. Then, we break it down into slightly smaller pieces and put placeholders in for each.

As we sweep through each area of the game we repeat the process, filling out just enough detail to be a representative placeholder. It’s not a concern to leave a bunch of details dangling out there, that’s the whole point. We’re building firstly and foremostly a system and secondly the parts to the system. Starting with the system’s parts is a source of anxiety - how do we know we’ll even need those parts if the system’s likely to change anyways? Do we really want a bunch of obsolete code generated by obsolete thinking polluting our code because we started filling out details before we even knew what parts we’d need?

I describe it as being like a painter who paints with the broadest brush strokes first and works their way down to ever finer strokes.

Somewhere out there, there may be an artist who chooses to start portraits by painting eye details first, then very detailed ear, etc - his name was probably Pablo Picaso.

More often you get something like bad fan art.

Even elephants start with broad strokes.

In the skateboarding game above a Top-Down thinker will probably put a giant placeholder in for “Build”, “Practice”, and “Compete”. Then, they might break “Compete” down into “Playing”, “Win”, and “Lose” placeholders. Then, maybe a gameplay rule that the player with the most points wins, and then perhaps a “player_jumped_rail” event that tallies a few points. Etc.

Being a Top-Down thinker it’s only natural for me to describe it a bit more rationally than to describe the other way. Sorry, bottom-uppers.

More archetypes, more problems…?

No, not exactly. And what happens when your team has a mix of the two styles of thinking? Can the two see eye to eye and collaborate productively?

In my experience, yes! In fact, they’re complimentary as long as they understand how each other’s thought processes differ, and are free to work in the manner that’s comfortable to themselves and entrust in the other side to deliver.

Jon

In fact, a fellow developer named Jon is one of my favoritest ever co-collaborators… And, also one of the most bottom-up thinkers I’ve had the pleasure of working with.

Early on, Jon and I often found ourselves concerned about completely different things. My concern might be getting the very simplest placeholder backend service running so at least we had an API endpoint. Jon might (rightfully) show a lot of concern about not having precise code standards in place. His mind focused great attention to detail on the very smallest piece of our existence - “What line do I put this curly brace on?” Everything else works its way on up in Jon’s mind.

In my own thinking - everything was placeholder code. If it’s all placeholder, why put energy into code standards at this point?? By the time we’re done we might be so over Unity and C# and onto Unreal Engine and C++… Let’s figure all that out first!

So, we’d go round and round about the details of how we do this or that in conversations that felt premature to me, and I’d try to pull Jon’s focus higher up in conversations that felt premature to him.

Meeting in the middle…?

And then we figured out, he thinks bottom-up. I think top-down.

At that point everything clicked into place between us.

Jon handled details I firstly. And, I trusted him to handle them. Meanwhile, I built systems, slamming together placeholders to bring up the big picture.

We didn’t meet in the middle so much as worked in parallel.

If you’re ever in need of a smart multiplayer developer, look up Jon.

TL;DR

Recognizing top-down vs bottom-up thinking can help your group function complimentaryily. Duh. :)

What type of thinking are you?

Note: I originally wrote this post thinking about the two top tier Game Engines, Unity and Unreal Engine. My thoughts are that Unreal Engine by is bottom-up centric and encourages working in that direction, while Unity works equivalently either way. Unity is much more general purpose, and placeholder objects can more quickly be emplaced and removed later.