This is super cool. Love the quantity goal - I think that's super important, as opposed to "I want to make the perfect game." Would love to experiment like this with something like 100 products (digital / physical) in 5 years, or some similar time period.
I remember as a 14 year old reading André Lamothe's Windows Game Programming for Dummies. I think in one of the Appendices he has a tip, something like:
"Your first 10 games are going to suck, so get those out of the way as quickly as possible."
That advice has stuck with me through the years when learning new things. Don't freak out about perfection, just get something "finished". Repeat N times and watch yourself improve.
I guess this guy went for N=100. It would be cool to see an analysis, even by a friend, of his games to see at various points where he goes from derivative games to sparks of creativity to ruts and so on.
I am a perfectionist, and so far this has been holding me back massively. To the point where it's getting frustrating. I am trying to enter the Open Source world and that's only making it worse. Showing off things you aren't entirely proud of.
I never considered quantity a worthwhile alternative goal, but maybe I should reconsider that. Thank you.
The Engineering mindset is to make the best possible thing while minimizing cost, time, and complexity. I find that somewhat freeing as perfection off the table.
It works for a huge number of things two. Hmm I wonder if I can do this in 15 minutes, or I wonder how compact I can get this, or whatever as long as it's not abstract like make it pretty.
Another way to state the problem is "you have to do it badly before you do it well". Not strictly true in every case, but software is in a broken state for most of its development and then suddenly works at the end, which is really weird and off-putting to human intuition. When the code just barely works then it works forever(given the same environment and inputs), while with most other processes it would be a improvement in success percentages or yield rates or other measures.
It also leads to an issue with never really knowing what good code looks like, because we have to consider both the "it's still in development and therefore expected to be broken but easily debugged" state and the "it's in production and should be fast, reliable, practical" state. It can be great at one and not the other if the stakeholders aren't approaching it in a balanced way.
Sometimes it never gets to a "working" state and plods along in a "mostly not prone to errors."
This works for games but when you get to payment systems, autopilot cars, and operating systems... Well it's not a good enough way of thinking. You need tools to help you think at a certain level of difficulty. Even for programmers we shamelessly glorify that level isn't very high... Yet hubris sometimes pushes us to make silly claims.
I cannot disagree that "practice makes perfect." That applies at so many levels. One has to be comfortable with throwing things away and trying again. Practice dutifully and intentionally. Then realize what you don't know and where your limits are and have the humility and boldness to find ways to reach beyond them.
Motivate your inner perfectionist by telling it that the perfect way of learning is trying a lot of different approaches and not one perfected approach.
That way you can satisfy the meta-perfectionist while violating perfectionism on the day to day level (as long as you assume life is a learning process).
One way to beat perfectionism is to try to pursue it to absurdity. If you are a painter, try to make the perfect painting. But recognize that, in order to do this, you will have to mix the perfect paint first. So now put your focus on the mixing paint. Recognize that each of the constituent base colors have to be perfect. Focus now on one color. Et cetera.
Quickly, you notice that perfectionism really doesn't work. Everything is about making compromises. And the "perfect" painter is the one making the best compromises.
It is very common to suggest to people new to the game of go to lose the first 100 games as quickly as possible [1]. Not "play", "lose". The fact is you will lose a vast majority of the first 100 games you play because the initial learning curve is so steep. It's hard to even imagine what moves might be reasonable when you start playing. So the idea is to not focus on trying to win or thinking through what your best moves might be, but to just get accustomed to some basic patterns, common positions, etc first. You have to build up a certain body of knowledge before you can really think about what moves you might want to play. So just play a lot of quick games and accept that you will lose and come out better on the other side.
I recall a tale from a pottery teacher, half the classes work would be judged on quality, the other just the weight of the finished pieces, those who threw lots of pots aiming for weight consistently produced better quality by the end of the process, some things you can only learn by doing!
A lot of people say the same thing about drawing ("draw a lot of random sketches, don't obsess over single drawings for hours/days trying to get it right"). It's too bad that obsessing is just so much more pleasant than spewing out tons of ugly crap :)
I disagree, if you can become comfortable with imperfection in your work you'll derive more satisfaction from the process of creation -- or at least that has been my experience. It requires a concerted and conscious effort but pays dividends both in terms of quality of work (eventually) and peace of mind.
I read about the 100 10 1 rule that came up in an article about game dev a while back, write down the first 100 ideas for games that come up, prototype the best 10, and then pick one to build.
I think I've finished maybe four games in my life. Three javascript games I wrote ages ago, which no longer exist, and a Space Invaders clone in C++ which I barely finished within a year (but to be fair, I started that knowing almost nothing about game development, SDL, or anything.)
This year, I wanted to do something like this, but what started as my January 1 Game A Month project is still ongoing and is not even remotely done. And it's literally going to be a slightly improved version of Berzerk. I probably could have gotten several small games done by now, but I keep getting thrown off on tangents and destroying and rewriting stuff for one project at a time.
My problem is, I think, I feel like I have to improve everything that can be improved.
An article like this is both inspiring and incredibly depressing.
I'd be surprised if I've cmpleted 100 games in my lifetime, and I've been hooked since the original NES. I noticed in school that there was a vast gap in talent and achievement between those of us who got into comsci because we spent so much of our childhood playing computer games, and those who spent an equal amount of time on the computer but very little time playing games.
(Then there's Woz, who can be a world Tetris champ and also nearly-singlehandedly create the Apple I and Apple ][)
Wait, are you saying that those who didn't play computer games as kids generally made better programmers?? 100% the opposite of my experience in the late 80s/early 90s, where the kids who excelled in high school cs courses were invariably those who had been exposed to/attracted to computers from a really young age thanks to games. Like everyone in class who wasn't a gamer was so far behind the rest it wasn't even funny.
He said that amongst those who got hooked early by computing, the non-gamers were superior at non-gaming tasks. Hardly surprising, given the lack of truly successful regex-ninja games.
I'm talking about the folks in college who managed to get hooked on computers without the gateway drug of video games. They were in it for the love of hacking
> "When I was little, I would smash the buttons on arcade machines during the 'Insert Coin' preview screen, believing I was playing the game. You'll see kids do it today too," says Cox.
I did this too. I was completely obsessed by arcade machines, but never had the quarters to play them.
People should more concentrate on quality than on amount.
App/Android Stores are full of such '100 games in 5 years', '1 game every week', '1 new app every day'.. it sucks.
Those guys are not making their games for you, they're doing for themselves, for their learning or their enjoyment.. The fact that they allow you to play them in the app stores is just a side effect, you should consider it as a bonus..
well, i can see where he's coming from. app stores are so polluted these days, it's kinda annoying. while i do love this X in Y strategy, there's no need to publish them in the stores if these games aren't bringing much to the table.
30 comments
[ 4.7 ms ] story [ 74.1 ms ] thread"Your first 10 games are going to suck, so get those out of the way as quickly as possible."
That advice has stuck with me through the years when learning new things. Don't freak out about perfection, just get something "finished". Repeat N times and watch yourself improve.
I guess this guy went for N=100. It would be cool to see an analysis, even by a friend, of his games to see at various points where he goes from derivative games to sparks of creativity to ruts and so on.
I never considered quantity a worthwhile alternative goal, but maybe I should reconsider that. Thank you.
https://www.youtube.com/watch?v=4j4Q_YBRJEI
It works for a huge number of things two. Hmm I wonder if I can do this in 15 minutes, or I wonder how compact I can get this, or whatever as long as it's not abstract like make it pretty.
It also leads to an issue with never really knowing what good code looks like, because we have to consider both the "it's still in development and therefore expected to be broken but easily debugged" state and the "it's in production and should be fast, reliable, practical" state. It can be great at one and not the other if the stakeholders aren't approaching it in a balanced way.
This works for games but when you get to payment systems, autopilot cars, and operating systems... Well it's not a good enough way of thinking. You need tools to help you think at a certain level of difficulty. Even for programmers we shamelessly glorify that level isn't very high... Yet hubris sometimes pushes us to make silly claims.
I cannot disagree that "practice makes perfect." That applies at so many levels. One has to be comfortable with throwing things away and trying again. Practice dutifully and intentionally. Then realize what you don't know and where your limits are and have the humility and boldness to find ways to reach beyond them.
If I want to complete a project, I make sure to scope a minimal set of features.
https://vimeo.com/5895898
Quickly, you notice that perfectionism really doesn't work. Everything is about making compromises. And the "perfect" painter is the one making the best compromises.
https://news.ycombinator.com/item?id=10631115
[1] http://agfgo.org/pages/learn2.php
edit: source, https://nickbentleygames.wordpress.com/2014/05/12/the-100-10...
This year, I wanted to do something like this, but what started as my January 1 Game A Month project is still ongoing and is not even remotely done. And it's literally going to be a slightly improved version of Berzerk. I probably could have gotten several small games done by now, but I keep getting thrown off on tangents and destroying and rewriting stuff for one project at a time.
My problem is, I think, I feel like I have to improve everything that can be improved.
An article like this is both inspiring and incredibly depressing.
(Then there's Woz, who can be a world Tetris champ and also nearly-singlehandedly create the Apple I and Apple ][)
I did this too. I was completely obsessed by arcade machines, but never had the quarters to play them.