About a year into working on my game project, and posting several YouTube videos on my Mac OS port, I received a typical comment on my channel.
"Whats wrongs with just using a commercial game engine ? , I have a feel you will have great great grand children before a game is ever done with this."
That's interesting because the day after I saw that comment, I posted another video where it was way more clear that I had made progress beyond drawing some simple colored rectangles in a 2D world. A few months later, I had already made a game with about six hours of gameplay, something that keeps my friends entertained and seems to have some promise.
But on some level the guy leaving that comment isn't wrong. You can get started protoyping much faster if you use an off the shelf engine. Instead of it taking a year and a half of your spare time just to learn the basics, you can throw together a prototype in a few weeks knowing very little.
Of course, there are all kinds of holes you can poke in that argument too. If you use any of these engines, you have to learn them, and that takes time. I often find it also takes more time to build the right kind of systems when you can't drop to a lower level, since you're basically trying to force everything through someone else's APIs. It's like trying to finely chop garlic while wearing oven mitts.
Putting all of those arguments aside, however, the point stands. You can get a guy on the screen in a handful of hours, certainly not months or years.
I think if we want to get better at convincing people to make more things from scratch, we need to make more of a case that it's also something smart entrepreneurs would do. That means picking apart some common fallacies, and instead of preaching about speed and performance in general, we need to present the information in the language of Silicon Valley.
More of us need to read the so-called "cheesy" kinds of business books like "The Lean Startup", "The Four Steps to the Epiphany", etc. Because while it seems like most people come away from those books thinking you need to spend as little money/time as possible on your first prototype, I came away from it with a totally different mindset, one that doesn't go against the handmade philosophy but rather encourages it.
In those two books, they treat the creation of a new business as a scientist would treat the creation of a new scientific theory.
First, you write down all of your assumptions about the business.
- What problem does your product solve, and for whom?
- Where can people get your product?
- Are there any barriers to entry, things your customer needs to do before getting your product?
- Does your business have any external dependencies? If X goes away, does your business go away too?
- How will you reach your customers? Where do they tend to hang out?
Then you go about testing those assumptions by talking to your customers, protoyping, having potential customers use your product, talking to influencers, and more.
Oftentimes, people conflate "being a startup" with "needing to deliver lots of features as quickly as possible, with little to no consideration of performance," and if they pay attention to what is really said in these books, they might come to a different conclusion.
Being a startup isn't about getting lots of stuff to market quickly using whatever third party library will get you there fastest. It's about writing down your assumptions and testing them.
This happens on both the customer and the product fronts.
How many of you have worked on a product for months or years, shipped it, and then had the project cancelled because the startup ran out of money? It's probably because they didn't validate their assumptions before building some huge thing and trying to go to market with it.
Truly, it wouldn't have mattered if the thing you built was done in React Native or assembly language because the real problem had nothing to do with code. It failed because your team built something nobody wanted.
The real sickness is our hangover from the industrial revolution, this lingering Protestant Work Ethic that makes people feel like working harder or longer on their business will somehow magically make it successful. But it doesn't work that way. Those who are most successful in today's world don't get there by merely working hard. They get there by looking in the mirror and asking the difficult questions.
Can you quickly validate your business idea while also using the handmade approach? Of course you can! In fact, it's much easier becuase shifting the focus to testing a hypothesis means you will spend way less time building features with speculative value.
I could have built a 2D game engine that does "everything" most common 2D game engines do, but that wasn't my purpose for building one. I made an engine so I could make a game, so I could test a hypothesis about a particular game idea.
When I sit down to work on my game, I'm only ever building one thing at a time, to test one idea at a time. I usually don't start on the next gameplay idea until I've watched people play the game with the existing gameplay.
I'm not trying to make super robust graphics right out of the gate. The game doesn't even have sound. It only runs on one platform (but it can be ported to others with relatively low effort).
I will return to all of those once I know I have something people enjoy playing, a.k.a. testing the basic business hypothesis "does this entertain people?"
With a scope so limited, you don't need any third party engines because your game is only ever doing a handful of things. You just need to fully understand the things you've committed to, which ought to be fairly limited.
I think someone like Pieter Levels is the unsung hero of our community, because he is taking our ideas and putting them to the test in the businesses he builds. He made RemoteOK.io. It generates well over six figures a year. It's also a single PHP file.
Obviously, the site could run much faster, and it should. But reducing complexity and only building the absolute minimum feature set ought to be our mantra, because that's what gives you the ability to even consider such things from a business perspective.
It's much easier to justify optimizing an existing business that generates six figures a year than to do the same with a startup that hasn't found product market fit yet.
I use the handmade approach in my games because it's the right business decision. It frees me from vast swathes of external dependencies that could sink my business. I don't have to worry about what happens if Unity goes under or if some tool I currently use stops being supported. I built all of my tools. I understand them. They only change when I change them.
Does it take longer to get started? Sure. But once you've started, your chances of surviving the long haul are better.
Also, once you've made your first game engine, it becomes much easier to prototype new game ideas using some variation on it. You pay a single up-front cost so you can spend less time later and get a better final product.
Ultimately, this crazy Rube Goldberg-esque style of making software will implode on itself. All we need to do is stand to the side, make great products, and wait for an opportunity to seize customers from the burning rubble. They're already wishing to be rescued.
"Whats wrongs with just using a commercial game engine ? , I have a feel you will have great great grand children before a game is ever done with this."
That's interesting because the day after I saw that comment, I posted another video where it was way more clear that I had made progress beyond drawing some simple colored rectangles in a 2D world. A few months later, I had already made a game with about six hours of gameplay, something that keeps my friends entertained and seems to have some promise.
But on some level the guy leaving that comment isn't wrong. You can get started protoyping much faster if you use an off the shelf engine. Instead of it taking a year and a half of your spare time just to learn the basics, you can throw together a prototype in a few weeks knowing very little.
Of course, there are all kinds of holes you can poke in that argument too. If you use any of these engines, you have to learn them, and that takes time. I often find it also takes more time to build the right kind of systems when you can't drop to a lower level, since you're basically trying to force everything through someone else's APIs. It's like trying to finely chop garlic while wearing oven mitts.
Putting all of those arguments aside, however, the point stands. You can get a guy on the screen in a handful of hours, certainly not months or years.
I think if we want to get better at convincing people to make more things from scratch, we need to make more of a case that it's also something smart entrepreneurs would do. That means picking apart some common fallacies, and instead of preaching about speed and performance in general, we need to present the information in the language of Silicon Valley.
More of us need to read the so-called "cheesy" kinds of business books like "The Lean Startup", "The Four Steps to the Epiphany", etc. Because while it seems like most people come away from those books thinking you need to spend as little money/time as possible on your first prototype, I came away from it with a totally different mindset, one that doesn't go against the handmade philosophy but rather encourages it.
In those two books, they treat the creation of a new business as a scientist would treat the creation of a new scientific theory.
First, you write down all of your assumptions about the business.
- What problem does your product solve, and for whom?
- Where can people get your product?
- Are there any barriers to entry, things your customer needs to do before getting your product?
- Does your business have any external dependencies? If X goes away, does your business go away too?
- How will you reach your customers? Where do they tend to hang out?
Then you go about testing those assumptions by talking to your customers, protoyping, having potential customers use your product, talking to influencers, and more.
Oftentimes, people conflate "being a startup" with "needing to deliver lots of features as quickly as possible, with little to no consideration of performance," and if they pay attention to what is really said in these books, they might come to a different conclusion.
Being a startup isn't about getting lots of stuff to market quickly using whatever third party library will get you there fastest. It's about writing down your assumptions and testing them.
This happens on both the customer and the product fronts.
How many of you have worked on a product for months or years, shipped it, and then had the project cancelled because the startup ran out of money? It's probably because they didn't validate their assumptions before building some huge thing and trying to go to market with it.
Truly, it wouldn't have mattered if the thing you built was done in React Native or assembly language because the real problem had nothing to do with code. It failed because your team built something nobody wanted.
The real sickness is our hangover from the industrial revolution, this lingering Protestant Work Ethic that makes people feel like working harder or longer on their business will somehow magically make it successful. But it doesn't work that way. Those who are most successful in today's world don't get there by merely working hard. They get there by looking in the mirror and asking the difficult questions.
Can you quickly validate your business idea while also using the handmade approach? Of course you can! In fact, it's much easier becuase shifting the focus to testing a hypothesis means you will spend way less time building features with speculative value.
I could have built a 2D game engine that does "everything" most common 2D game engines do, but that wasn't my purpose for building one. I made an engine so I could make a game, so I could test a hypothesis about a particular game idea.
When I sit down to work on my game, I'm only ever building one thing at a time, to test one idea at a time. I usually don't start on the next gameplay idea until I've watched people play the game with the existing gameplay.
I'm not trying to make super robust graphics right out of the gate. The game doesn't even have sound. It only runs on one platform (but it can be ported to others with relatively low effort).
I will return to all of those once I know I have something people enjoy playing, a.k.a. testing the basic business hypothesis "does this entertain people?"
With a scope so limited, you don't need any third party engines because your game is only ever doing a handful of things. You just need to fully understand the things you've committed to, which ought to be fairly limited.
I think someone like Pieter Levels is the unsung hero of our community, because he is taking our ideas and putting them to the test in the businesses he builds. He made RemoteOK.io. It generates well over six figures a year. It's also a single PHP file.
Obviously, the site could run much faster, and it should. But reducing complexity and only building the absolute minimum feature set ought to be our mantra, because that's what gives you the ability to even consider such things from a business perspective.
It's much easier to justify optimizing an existing business that generates six figures a year than to do the same with a startup that hasn't found product market fit yet.
I use the handmade approach in my games because it's the right business decision. It frees me from vast swathes of external dependencies that could sink my business. I don't have to worry about what happens if Unity goes under or if some tool I currently use stops being supported. I built all of my tools. I understand them. They only change when I change them.
Does it take longer to get started? Sure. But once you've started, your chances of surviving the long haul are better.
Also, once you've made your first game engine, it becomes much easier to prototype new game ideas using some variation on it. You pay a single up-front cost so you can spend less time later and get a better final product.
Ultimately, this crazy Rube Goldberg-esque style of making software will implode on itself. All we need to do is stand to the side, make great products, and wait for an opportunity to seize customers from the burning rubble. They're already wishing to be rescued.
Edited by Ted Bendixson
on
Yes, doing things from scratch is often less work in total because one has to consider the whole life-cycle of the product. They will also get rid of bugs popping up from poor understanding of how someone else's highly subjective library works, which is much more common than making a mistake in your own implementation.
If depending on a closed source feature saved a few weeks in the beginning but later doesn't exist anymore, the company will then have to hack together their own implementation under time pressure and have the slightest deviation cause new bugs. The worst is when you depend on something complex to do a simple task and cannot cut out any irrelevant features.
If depending on a closed source feature saved a few weeks in the beginning but later doesn't exist anymore, the company will then have to hack together their own implementation under time pressure and have the slightest deviation cause new bugs. The worst is when you depend on something complex to do a simple task and cannot cut out any irrelevant features.
Edited by Dawoodoz
on
Ted that's probably the most useful mindset; I enjoyed your write-up. And thanks for highlighting RemoteOK and his background; we should really promote more of that stuff around here.
When you invest in an engine for a game, or vanilla libraries for your application, you become the true owner of these assets for your business. They'll pay dividends for years but it does take time, and yeah it stings to have users compare your initial work with the best that's currently out there. I'm glad you found some clarity from that YouTube comment rather than despairing!
I agree. How many of you here have struggled to explain to friends and family what Handmade is? It's often easier when you point to successful entrepreneurs, or when you point to mainstream institutions that support our philosophy.
Refer to this Twitter thread :)
A few months later, I had already made a game with about six hours of gameplay, something that keeps my friends entertained and seems to have some promise.
When you invest in an engine for a game, or vanilla libraries for your application, you become the true owner of these assets for your business. They'll pay dividends for years but it does take time, and yeah it stings to have users compare your initial work with the best that's currently out there. I'm glad you found some clarity from that YouTube comment rather than despairing!
I think if we want to get better at convincing people to make more things from scratch, we need to make more of a case that it's also something smart entrepreneurs would do.
I agree. How many of you here have struggled to explain to friends and family what Handmade is? It's often easier when you point to successful entrepreneurs, or when you point to mainstream institutions that support our philosophy.
Dawoodoz
The worst is when you depend on something complex to do a simple task and cannot cut out any irrelevant features.
Refer to this Twitter thread :)
Edited by Abner Coimbre
on
Reason: Typos.