This has some relation to the "Disney Method" (<a href="https://en.wikipedia.org/wiki/Disney_method" rel="nofollow">https://en.wikipedia.org/wiki/Disney_method</a>) where one delays self-criticism until after one has engineered out the problem, and delays engineering things out until one has dreamed up ideas. Of course the Disney Method is cyclical, and requires returning to the dreaming-up state and on from there.<p>This also reminds me of how 35mm street/photojournalists work (see, for example, Garry Winogrand, or Josef Koudelka, or Robert Frank). One makes tens of thousands of images, culls them down via work prints to hundreds, then choose a few dozen to print well as the final work. The final images appear inevitable, though it's unclear if there was something magical in the moment of the photography, or the culling process is the secret. See <a href="http://www.nga.gov/content/ngaweb/features/robert-frank/the-americans-1955-57.html" rel="nofollow">http://www.nga.gov/content/ngaweb/features/robert-frank/the-...</a> for an example of Robert Frank's contact sheets and how he homed/honed in on an image.<p>EDIT/ADDITION: A fiction writer I met teaches her students to make three passes at their work. As I recall, she described the first being for ideas, the second for intentions, the third is to make it read as inevitable.
I assumed this was about video game design, and it took me a minute to catch on that it was board games.<p>Phase two of this approach, developing 10 prototypes over the course of 6 to 12 months, sounds incredibly labor intensive. Perhaps prototyping board games is easier than prototyping video games. But this seems like it would be a difficult phase to get through, either as a side project, or doing it commercially full time.
For the people talking about automated or evolutionary design of board games, this has indeed been tried. The most successful one I know about is Ludi¹) which produced the game Yavalath²), which I think is a pretty darn good game.<p>¹) <a href="http://www.doc.ic.ac.uk/~sgc/papers/browne_cig11.pdf" rel="nofollow">http://www.doc.ic.ac.uk/~sgc/papers/browne_cig11.pdf</a><p>²) <a href="http://cameronius.com/games/yavalath/" rel="nofollow">http://cameronius.com/games/yavalath/</a>
Could be interesting to adapt this slightly for a small scale one person startup-generator and give it a shot. I usually try to work on one idea but...
1) Identify 100 problems worth solving
2) Narrow down to 10 and build MVPs for all of them in parallel
3) Go deeper on the most promising one(s)<p>I think the key is how to go from 2 to 3. I feel like an idea worth trying is to not focus on growth and instead monetize all 10 MVPs from the start and focus on the one(s) that can get to cash flow positive the quickest.
I love Fogus's take on 100:10:1. As opposed to this highly linear ever-winnowing flow, Fogus uses 100:10:1 as a way to keep a list of spitballed ideas, a list of things he might want to work on that all have sincere promise, and one thing picked to focus on. Instead of being process driven, focusing on getting one thing done well, Fogus lets himself switch among his 10 picked items. The 10 is a way to swap out when interest wanes. <i>100:10:1, my approach to open source-</i>
<a href="http://blog.fogus.me/2015/11/04/the-100101-method-my-approach-to-open-source/" rel="nofollow">http://blog.fogus.me/2015/11/04/the-100101-method-my-approac...</a><p>This process speaks to me a ton (a whole lot more than Nick's rigorous phased development process). When my attention and care for an interesting, creative project wanes, I can either dig in my heels and try to make myself code, or preferably I can switch to some other promising piece of development. Having a deck of other ideas decreases the context switch time- when a project is in a lul, there's already other great gems prepped, and one of them can re-inspire me.<p>Quite the contrast. I wonder how much of it is due to Fogus's focus on developing open source software, versus Nick' focus working on physical board games.
>> Based on some selection criteria (which depend on my design goals and which I discuss below), I pick 10 of the 100 concepts<p>I used to try this as a teenager with QBASIC. I'd start writing down game ideas, but I'd always pick the 5 or so that I already knew I wanted to make. So why write down 2 pages of them?<p>I would probably have been better off drawing them out of a hat, working on them for a day and then just seeing where each one went.
At first I was thinking that the methodology described appears to be waterfall approach to innovation with bing bang brainstorming and selection.<p>All 3 games I have seen are quite innovative pieces which took the author years to implement and perfect. The games are quite impressive, and are equivalent to innovating "chess".<p>On the other side one can argue, an incremental evolutionary approach to innovative games, or an agile approach would fit the current times, better, due to the rapid rate platforms maturing and disappearing. For example, I could take "chess", or mahjong and create variations to it in quick iterations with a focus on process.
Basically just spitballing ideas. Pretty classic process for anyone creating things. Throw out a ton of ideas, and see if any stick. I try to get a new web project developed every month, if it gains some traction, continue development, if not, moved on to the next idea.
Interesting read and approach, though you'd have to be pretty committed to pursue it in the 10 stage.<p>It's interesting that he talks about software, I've thought a couple of times if it's possible to produce generic board game design software but I'm still not sure.
Motown used a similar method where songwriting teams had to deliver x number of ideas per week and then the best ideas were pulled out for demos. The best demos were produced.
This had me thinking how could I apply this to features of my side project.<p>I am not sure if I can. The first thing that came to mind was a set of micro services that provide some feature. These micro services would be composed into a UI using some type of bandit algorithm