How to Structure Game Projects (for people like me)

When you just start out with game development, your main focus is just to get a rectangle on the screen and just to write a few lines of functioning code. Once you’ve been doing it for a while, however, you naturally progress to asking the question: “how on earth should I structure or approach a bigger project?”

What should my hierarchy of folders and files be like? What tasks should I do first? How should I plan ahead? How do I ensure we keep a good pace and we don’t create problems for ourselves in the future?

And any time people ask this question, they quickly receive the answer to use a specific app/website/system to meticulously track and plan everything.

For example, Trello was a very popular one a few years ago. (I’m not sure if that’s still the case.) Many, many devlogs on YouTube show developers having these huge lists of tasks and milestones and what not.

If that works for you, great! This article isn’t for you. Enjoy whatever note-taking or project-management solution you’re currently using!

If you’re working in a team or for a large corporation, this article also isn’t for you. It’s mostly aimed at solo developers (or very small teams) with some basic measure of freedom in how they work or approach the project.

Instead, I’ve tried all those things, and they only made things worse. I tried planning all the steps and setting milestones, and it never did anything good for me.

That’s not too surprising, in hindsight. I am a hyperactive person, who hates planning and structure and certainty. If I already know exactly what I’ll be working on tomorrow (or the next week, or the next month), I have absolutely no motivation left for doing so.

So, in this article, I just wanted to briefly describe what I’ve learned after trying to create many games (big and small, different platforms, etcetera) and which approach works for me.

In case it matters, I maintain 5 large websites, coded over 50 games (video games and board games), and also write nearly 10 books a year. I will explain why I have almost no structure and what habits I have, and it will seem like it shouldn’t work to you, but I think I can prove that you WILL finish projects this way. A bit of a “trust the process” approach, I guess.

Why large/detailed planning doesn’t work for me

Human psychology

The first reason is a simple trick in our brains. When we write down that we should do a task, our brains tend to believe that we already did it and reward us for “completing it”.

Whenever I’d plan out the steps to creating a small game idea, I would always …

Lose an hour or two thinking about this and writing it out.
Then feel like I’m “done” or that I’ve accomplished something.
And not actually work on anything, at least not that day.

This is true for almost all people. But it only becomes a problem when you combine it with the next reason.

Overwhelming

Thanks to my hyperactive brain, I have a hard time focusing on one thing. It’s like my body/brain is always open to everything, which means I just can’t look at a long list of tasks and see only a part of it (i.e. the very next task ahead of me). When I plan out what I need to do, step-by-step, I’m just overwhelming myself and making it impossible to actually pick a task and do it.

So I guess the fourth bullet point (after planning or structuring a project) would be “Get overwhelmed and burned out, never actually make the game”

Our brains, in general, simply can’t handle that much information. Yes, writing out all the steps and all the general areas of the game that need to be made does help with understanding and categorizing a huge pile of tasks. But it doesn’t help enough to add true clarity. That planning is simply a more concise version of “too much information to handle, too many choices to make”.

Which leads into my third reason …

We can’t predict the future

Every single project I’ve done has been 99% failed predictions of the future. I’ve written so many books—I still can’t predict how my own story is going to unfold tomorrow. I’ve made so many games—and my best ideas still get proven wrong the very next day.

There are so many options, so many things to consider, and only so little we can hold in our heads and imagine/visualize/plan out.

Whatever plan you make, it’s a guarantee you will need to constantly rewrite it and do something different anyway.

Oh, you planned to work on the Enemy system for the entire next week? Well, unfortunately, testing the current game reveals that enemies would actually be a terrible addition and not fun at all.

Oh, you planned the six systems you needed to accomplish this specific game mechanic? Well, sucks for you, you woke up this morning and suddenly realized why the entire mechanic doesn’t work.

To me, the time spent on creating large-scale planning or structures for a project is completely wasted, because you need to do it over and over while getting too little benefit from it.

And for my final reason …

Being creative is the important part

The reason I or anyone becomes an artist is because of the inherent need to be creative every day.

Meticulously planning or outlining something beforehand, means all the creativity is locked in that moment, and afterwards you’re just following your own commands and checking things off a list. Sure, there might still be surprises, or gaps to fill with creative solutions in the moment, but it’s far weaker than actually being creative every day.

And I’ve learned that it’s a terrible idea to not be creative, in some way, every time you work on a project. It reduces motivation and productivity, if you don’t keep that part of your brain active then you will be less inspired and creative, until you don’t even want to make the game that you mapped out so carefully.

The important part is enjoying the day-to-day process of creating the game, until it is done. The important part is not that everything went according to plan or that you finished your self-imposed to-do list each day.

So, what do we do?

Over the years, I’ve found habits (such as how to take notes or determine tasks) that allow me to make projects at a good pace and with a clean codebase, without ever having an actual plan or clear overall structure.

In a way, the only structure I have is one that allows being structureless ;)

What do I mean by that?

Day-tight compartments

I don’t know where I heard this term first, but it’s the solution I stumbled on myself (after years of trying different habits) and that seems to work for many people like me.

The only thing that counts is today.

Every evening, I write out the general tasks for tomorrow. By hand, on a paper notebook on my desk.

That entire day, I am only concerned with those few things. I am only concerned with whatever I decided to focus on that day and anything tightly related to it. There is no further planning, no specific to-dos for the day after that, and I’m not even thinking about any of it. Why would I? That’s a worry for another day.

As stated, our brains did not evolve to accurately predict the future or be able to see very far ahead. We evolved to see the current day and use that very well, but not more.

For example, for today I wrote down.

Write that article about project structure.
Create the game design quotes images for the next few upcoming Wildebyte books.
- (Each of those books starts with a “game design principle” with certain parts crossed-out. The story obviously explores that, until at the end you get the full principle without blanks.)
Create cover for book #7 and #8 (start with 8, it’s the simpler one)
Write down my ideas I scribbled all over the place. (This was a collection of ~6 simple web/mobile game ideas that I got during the day.)

I woke up, and I felt most like doing item 2 first. So I did. I ended up finalizing these images for 12+ books in the future, waaay more than I originally wrote down (“the next few”).

Then I had even more ideas, so I did item 4 next, making sure they were all written down nicely in my general document of “tiny game ideas to try on a weekend”.

Then I exercised. Before I knew it, it was already getting late, so I wrote this article you’re reading right now.

I simply had no time (and apparently not much motivation today) for those covers. So I just wrote down that I’d do them tomorrow.

Without having any future planning or big goals, I made progress on all the things I’m doing. Without working that much and sitting in a chair all day, it was a productive day. Without actually fulfilling my entire to-do list, I still feel satisfied and have no issues moving stuff to tomorrow.

To summarize, the habit here is to …

Ask yourself (every evening): “What is the next step on my current project(s) that I could take tomorrow?”
You write those down.
And you use them a loose guide, picking the thing for which you feel the most motivation, and leaving enough gaps to be creative in the moment.

Knowing the best “next step” obviously comes from experience. Making lots of projects, in a different order or a different way, to figure out what a generally good order of operations is.

But … it doesn’t even matter if it’s the “best next step”, or even a sensible one. Which leads me to …

Consistency of Effort

Because we can’t predict the future, and creativity is fickle and mysterious, and our bodies and minds are equally inconsistent … I’ve found that it’s useless to plan everything around consistency of result.

Because that’s what many people will try. They will write down the desired results and then force themselves to follow within that framework. And then, if you have a few slow days where you’re not inspired or run into weird bugs, you suddenly lag behind, your entire planning is wrong, and you probably feel needlessly bad about yourself.

Instead, as I also mentioned in another recent article, I think it’s much wiser to go for consistency of effort.

Pick an amount of effort you’ll be able to put in, on average, each time you work on the project. A general number of hours you’d be able to work on it, a general number of problems you might be able to tackle before your head turns to mush. Then try to put in that effort every day, not caring about the results.

For example, I might write down the following tasks for the next day.

Get enemy pathing working.
Track score and create the UI element for it.
Fix the bug where it doesn’t generate a valid random map.

Now suppose enemy pathing is proving harder than I thought, and then I can’t figure out that bug. Before I know it, the day is done, and I’ve only done one and a half of the tasks.

When I was younger, I would feel very bad about this. Maybe work for much longer, past a reasonable bed time, trying to complete the tasks according to the planning. This is obviously a bad idea. Bad for your health, bad because you start making all sorts of mistakes, bad because you lose your common sense or creativity.

Now, I will know that I put in my 6–8 hours of effort/work, and I’m fine with moving the unfinished things to tomorrow and going to bed.

So many times, I’ve woken up the next day and instantly realized the origin of the bug. I fixed it in 10 minutes, the next item was also a breeze, and now we’re suddenly ahead of schedule.

And also so many times, I worked for too long trying to get my desired result for the day, and merely wrote terrible code that brought me into trouble later. There have even been numerous occasions where I wrote an entire system for 4 hours straight, only to wake up the next morning and realize the complete system is not needed at all.

You have control over the effort you put in. You have no control over the result or the outcomes.

Taking a tiny step every day will still finish the project. It’s a guarantee: if you put in consistent effort for long enough, then any project will be done.

And those steps don’t need to make sense or follow any order. They really don’t. Only people with a very strong desire for control usually convince themselves that there is one right way to structure projects or one right way to code, and that’s that.

Feel like making the music for your game now? Do it. Follow the creativity. Your game will need music anyway, so why not make it now? Sure, there will be a voice in your head saying that sound should “come later” or “the core systems aren’t even finished”. But what do you gain by finishing the core systems first, if this makes you far less productive?

Feel like drawing a logo? Do it. Perhaps choosing the fonts and colors for it will reveal to you what art style the game and UI need, simplifying those tasks later.

Feel like trying a silly idea for a level? Do it. Perhaps it will reveal what should actually be the most fun part of your game, or a bug you would have never spotted any other way.

All that matters is putting in consistent effort, not the end result or taking the “best next step” towards finishing the game.

What if I can’t do that? What if I just feel like doing nothing today? Then try to find a task that makes you feel something. Invent some crazy task that will get you going! I can’t emphasize this enough: pick whatever step that lets you put in consistent effort. If it means some crazy thing that will probably never make it into the final game, that is fine.

Write all that shit down—but don’t plan ahead

Just like our brains can’t predict the future, it can’t remember things (objectively, or at all).

Any thought you have, write it down. Any idea you have, write it down.

Make it easy to write things down. Invent a simple syntax for yourself to easily find that information later, or create nice categorized locations for these notes.

For example, I regularly write @TODO: code that does X when working on a game. Today, I am currently focused on some other task on the game, so I don’t feel like writing that piece of code. But it has to be written at some point, so I write down what should go there and instantly move on.

Usually, a few days later, there will be a moment where I’m like “ah, I can’t clearly see my next step—let’s just CTRL+F all @TODO statements in the project and handle them”

By working on the project, you automatically and organically realize the remaining work that needs to be done.

I just don’t see the point of planning or structuring things beforehand. Try to make the thing, you’ll automatically create gaps that need to be filled later, and that is your planning if you want. But this planning came for free and is based on the actual needs and iterations of the game project.

I have similar methods to mark other areas of the project, such as @DEBUG for something that I should make sure is turned off before publishing the final project.

For every game, I have a single, short todo.md markdown file that contains my most immediate tasks and any quick notes/bugs/should-not-forget-this.

If I ever see this file growing too large, I know that I am writing down too much ahead of time. I am planning and structuring … while I should actually be working on the game.

When I was younger, I would have created a big heading for every major part of the game (such as Sound or Enemies), then listed in detail what needed to be done for each one. As stated, this just made me overwhelmed, gave my brain the idea that I’d accomplished something already (when I clearly hadn’t), and never led anywhere.

Nowadays, I only write down vague next steps. At some points, the todo file will say stuff like: “Sound, Particles, Animations need to be done completely”

At some point in the project, I will actually get there. I will judge that my next step should be starting on sound, so I remove that and merely write down the next one or two steps.

When I’m done with those, I figure out the next one or two steps.

At no point do I have a full list of what needs to be done for any area or milestone. Which means that, at no point, I can get overwhelmed by that or feel like I’m just doing drudgework all day.

And yet, at some point, the entire huge task of adding background music + sound effects to the entire game will be done.

So write down all your ideas or sparks of inspiration, write down any should not forget this and I’d love to try this idea. Often times, the best parts of any project turn out to be some tiny idea I wrote down a month ago and rediscovered. Something that would’ve never happened if I’d trusted my memory to do this for me.

Do not write down too many future tasks. Focus on this day, and the next one or two steps.

Make it tangible and modularize

Finally, a more technical habit or tip.

Many people develop their games in a broken state, until, at the finish line, it is finally functioning and complete. They’ll spend weeks working on all sorts of abstract classes, systems they will “need later”, and any other sensible and reasonable building blocks.

This, however, makes it very hard to apply the habits I outlined above.

I distinctly remember a conversation with my best friend about this. I was making another game, and had finally given it up after a few months again. And they remarked: “You’re very good at making the building blocks and creating a nice blueprint. But then you burn out before you have an actual game or anything tangible.”

And they were right!

I think any game project should always be kept in a playable state. This doesn’t mean it’s complete, of course, or pretty, or anything close to the final product. But at any point, you should be able to start your game and perhaps let others play it.

How do you do this?

Just like working in day-tight compartments, work on tasks in a focused and self-contained way. Work on your Camera until it functions in a basic way, instead of doing a tiny bit for it, then switching to something else, then starting on another system that will depend on the Camera in the future. No! Chase the carrot! We want a functioning Camera now, so create something usable from start to finish before jumping into something else.
Make it very easy to toggle everything on or off in your game. Even systems you think are “crucial” to the game, even code you deem “necessary”, still make them optional. You should be able to completely leave that “module” out and the game will still start and do something.
- All my latest game projects have loads of rule changes or optional features built into them.
- I coded them, playtested them, experimented with them, all by quickly toggling things ON or OFF. I am free to wake up the next day and code an entirely new, crazy game mechanic the entire day, because I know I can just turn it off if it doesn’t work. No harm done, not getting in the way of anything else.
- And in the final game, obviously, only the best parts are left ON.
If you do this, you’ll naturally end up with folders per major area in your game, and small self-contained files inside. Things depend on each other as little as possible. It is easy to pick a new thing to work on tomorrow, because you don’t need to look up how systems A, B and C worked before daring to make any changes.
- You can even transfer these entire folders to other projects, re-using functionality you already created before.
- Or you can just completely delete one when it turns out that particular system/mechanic was a bad idea and has no place in the final game. Clean-up! Keep the project itself simple, light, and not-overwhelming.

As you see, this all comes back to making it easy to find a new task and put in consistent effort. Structuring the entire game and filesystem to make it easy to find anything and get a tangible result at the end of the day.

At the end of the day, you should be able to give the current game build to anyone and they should be able to play it in some capacity.

This, again, is simply how our brains evolved. We feel good when get tangible results and direct rewards for our effort. Any long-term rewards, indirect progress, non-tangible results … will never feel remotely as rewarding or motivating.

Woah, aren’t you contradicting yourself now? Saying we need to focus on one thing and finish it, AND saying to not have a planning and our next step doesn’t matter?

Well, it might seem so, but no!

Learning how to pick a good next step for any project is still very useful and a skill you should always be honing. It’s literally the fundamental requirement for how to make any project: find the next step to do and do it. (The same way full 400-page novels are still written by putting one word after another.)

So yes, you have the freedom to pick any next task you want for the next day. But simple practical principles like these will often help you pick a better one than you otherwise would have. And as stated, as you make more projects, you’ll naturally gain even more experience about how to pick tasks in a way that suits you.

That is my experience, at least.

Some very specific things about my workflow

I would recommend …

Using a statically typed programming language. I’ll have another article about that debate soon.
Putting images into spritesheets and audio into audiosprites.
- This simply means far fewer assets to load and manage, and also makes your game faster, so win-win.
- I can’t tell you how often younger me was frustrated by making a typo or missing a single image when a game loaded like 40 individual images … which could’ve just been one spritesheet. And if that one spritesheet loaded, then everything was guaranteed to be fine.
Opting for 2D and stylized unless you really need 3D.
- This is partially personal preference.
- But game projects in 2D are much easier and faster than in 3D. Stylized graphics are faster and look better. The idea that games must look realistic or that only 3D games are “serious games” is ludicrous and will only hurt you.
Keeping it simple and light. Pick a small game engine, only introduce the dependencies or features you truly need, just track things in plain text (markdown) files. Do not add stuff “in advance” or because it’s supposed to be “good practice”. Use what you need right now, in practice, leave the rest out of it.
To help with this, one might even consider creating the game on the worst device you can find. Its limitations will force you to write simple code, find simple solutions to problems, focus on one thing at a time.
- Even if I wanted to, I can’t open multiple programs at once on my terrible laptop. Most of the time, I even have Wi-Fi off completely and spend hours coding before I press the button to actually test.
- Even if I wanted to, I can’t download and open the behemoth that is Unity or Unreal Engine on that device. And so I learned, a long time ago, that there are many other game engines which are far smaller and still do all I’d ever need.

Conclusion

I really try to keep these articles brief, but there’s just always so much to say about topics!

I hope this at least gave an idea about my workflow. How my hyperactive, hyper-creative brain manages to be productive and finish projects (quite easily) without having any structure or long-term planning.

Put in consistent effort.
Only worry about one day at a time.
To achieve this, pick the tasks for which you feel most motivated or inspired at this time. Even if it seems crazy, or in the wrong order, or whatever.
To make this easier, keep all parts of your game modular (turn on/off whenever, files and folders hyper-focused on one thing) and give yourself tangible results at the end of each day. Preferably by having a somewhat playable game build.
Then trust the process. Know that consistent effort every day will finish the project. Know that experience, after many projects, will guide you to picking better and better next steps on the fly.

I guess my biggest revelation from the past year or so, of which I was reminded while writing this article, is the following.

Almost any problem in a game project is a game design problem, NOT a planning, structure or technological problem.

If you’re consistently feeling like you’re lagging behind or not achieving as much as you should on the project, this is most likely not a planning issue. It means you must shrink the scope of the game. You’re making something too large, you’re trying to work on systems that are too large, etcetera.

If you feel like your game has a terrible structure for its current gameplay, this is most likely not an issue with your project management. It means there’s a mismatch between the current gameplay and the intended gameplay. You coded things in a certain way because you wanted a certain outcome, but now you accidentally designed the game in a different way.

(And even if this is just an issue of messy or thoughtless structure on your end, you can still SOLVE it by changing the game’s design. If one thing is simply far easier to code, with the current way in which you set things up, then … maybe just pick that one thing as the game design direction?)

If you feel like your device is too bad, or your game engine is lacking crucial features, or whatever other technological problem … you guessed it, turn it into a game design problem. You’re probably trying to work against the computer’s inherent strengths. You’re probably trying to approach something the wrong way, which is why there is seemingly no support in the game engine for this one thing you want to do!\

For example, many people complain about physics engines. Maybe they made a game, but at random moments their bodies get stuck inside each other or fly all over the place! Surely the physics engine is broken! But no, in most cases, your game design is broken. You are asking the physics engine to do something it cannot do, such as teleporting bodies, placing a body in a space that’s just too small, giving your bodies ridiculous masses or speeds, etcetera.

As such, I’ve learned that any mistakes or setbacks from my admittedly loosey-goosey approach, can be fixed by re-evaluating your game design. There are always countless ways to turn your ideas and mechanics in a different direction to circumvent other issues.

Don’t force a square peg in a triangular hole—if your reality is simply a triangular hole at the moment, then redesign the peg to be a triangle too.

Anyway, those were my thoughts and my current habits or tips.

Keep playing,

Pandaqi