I tried this for gamedev, just for some background. I've been putting off starting some sort of one-off game in Unity even though people scream at me "just make something!!". I thought about why I was hesitating to do so, and wrote down a Blank Page. Here's a few notable things I came up with:
---
> It's too hard on my own.
Games are multimedia projects. They incorporate audio, video, input, networking, etc. Game development teams are composed of experts in each of the fields the game touches. It's like making a movie, and making an entire movie on your own is somewhere between extremely difficult and laughably impossible.
> It involves a lot of planning.
In order to make games the "right" way, you need to design the right way from the very beginning. There's a lot of prep work ("preproduction") that involve determining gameplay systems, art and sound direction, and a whole bunch of other things in advance.
> It's not something I already know how to do.
True, nobody is born knowing how to make a game. But that just means you need to gain the skills in order to do so, which involves learning said skills, which involves time and effort. Therefore...
> It's a big time investment.
Making a game is in fact a significant time investment. Even if you're offloading graphics and netcode work to someone or something else, you still have to write gameplay code, playtest, debug, redesign, and iterate. Games can and often do take on the order of years to develop. And even outside of developing the actual game itself, the skills needed to even start (e.g. programming, game design, art, etc.) are things that people spend their entire lives mastering.
> I won't really be able to make something worthwhile.
Even if you do spend your free time putting your game together to the point where you're happy with its polish and development, it can still ultimately be an uninteresting failure - in which case, all that time and effort is arguably time not well spent. That's a huge blow, especially in a day and age where free time is at a premium. This makes trying to make a game a much less appealing prospect. And even if someone can make something worthwhile, it'd be after a few games that aren't as great anyway, so that time and effort spent multiplies.
---
Writing this down actually helped me put my concerns into words: games are not single-person endeavors, even for relatively simple ones. Books can be written by a single person since they only touch upon a very specific subject and field that's reasonable for a single person to handle, but games are a very different beast that tie together many different disciplines. To put it in software development terms, books are comparable to web apps and command-line utilities, while games are more comparable to operating systems and enterprise software.
That's not to say the Blank Page exercise isn't worth it, not at all - it's very helpful for organizing your thoughts and for self-reflection, and you can see how it helped me. But sometimes, if you procrastinate so much over doing something, the reality is that you might just not want to do it in the first place.
It'd certainly be fun to work as a game developer and learning about game design is fascinating (if mindblowingly complicated), and I might be open to working as a game dev on a team sometime in the future, but at that point, it's much like any other dev job. I like games, I can tell you that, and I want to see more games of the kind that I like, but I'm certainly not learned or developed enough to put those games together myself.
After making some small things like that, you'll see how easy it is to just jump into some cool idea you've been thinking about. If you don't do this, and instead just plan out some big multi-person hobby project, there is literally 0% chance it will ever get finished, or even started. It's literally never been done before.
https://hero.handmade.network/episodes
I think it's really cool to see Casey walk through all the steps that go into figuring out how to make the game on stream. I skipped the very beginning, as it was pretty windows specific, but the first episode I watched was really cool:
https://hero.handmade.network/episode/win32-platform/day021
He sets up auto-hot reloading of the C++ game code, to cut down on dev time.
It's actually a large body of work, (more than 100 hours!), and even watching at x2 speed, it'll take a long time to get through all the videos, but I think they are pretty informative, and fun to watch.
> It's too hard on my own.
It can be, but it really does depend on the scale of what you're making: there's a large class of games that aren't too difficult for individuals, and a large class that are; and, in the class of approachable games, there are still fun, interesting, novel projects that can be undertaken.
> It involves a lot of planning.
This is one thing you'll learn to find a balance with by writing games. There is too much and too little planning. Don't worry too much about making them the 'right' way to begin with. In my own case I intentionally didn't look up any info. on the correct way of making games until I'd tried my own way first (which is much more fun and worked out fine). After doing that, looking up established practices was way more interesting (and my own approaches were laughably bad in comparison—but ya learn!).
> It's a big time investment.
Some are, some aren't. As others have mentioned, you can make a quick game in two days or so. More importantly though, I'd say to try it out and see if you enjoy the process: if you don't, then the time investment probably will be too much, and you could end up spoiling your love for games in general. If you do enjoy it then, whatever the final outcome of the game, it was time well spent.
> I won't really be able to make something worthwhile.
You may get ambitious about it one day after you've developed your skills to a certain extent, and find yourself with a greater interest in sharing an experience through your game than in working on it. If you get to that point, you're now in the realm of working on art, and that's got its own whole host of difficulties.
You should scale your expectations down, come up with the most simple, minimum viable product. If you still don't feel the scale is small enough, try to break off a chunk of that MVP you think you /can/ complete.
Then try.
You're probably going to make an initial version as you're learning, and your design is either going to radically change as you learn more about the problem you're actually trying to solve and the tools you're solving it with, or you'll end up throwing it away and refactoring the entire thing when you do have an understanding.
Then, when you've got something that works, you'll start tweaking it. Making X better, or adding Y; or even removing Z because you realize it isn't something that should be there.
That's the programming equivalent of the 50 pots thing. Each iteration you run being like a small test-firing, and each deployment being like a pot you actually feel like putting through use tests.
I didn't interpret it as a way of getting creative in the qualitative sense of "creative" but rather in the "productive" sense. To that end, the exercise you went through and shared supports that notion.