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 http://www.nga.gov/content/ngaweb/features/robert-frank/the-... for an example of Robert Frank's contact sheets and how he homed/honed in on an image.
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.
95% of the time I won't know if a shot is "worthwhile" until after I cull/process but it's all about setting up environments that promote the chance of that happening.
Major respect for the people who used to do it in Film, much more discipline and technique required back then.
That's really intriguing. Do you have any more info or background on this?
The scheme is to write down what happened in the first pass. Then the second pass is to make things follow -- fix plot holes, clarify motivation, iron out chronology, etc. The third, "inevitable", pass is, of course, key. It is to hide the seams, to make the story/book appear as if it came whole cloth.
One (counter) example would be Faulkner's first novel, "Soldiers' Pay". In it you can see the hand of the author, self-conscious characterizations and manipulation of scene. It's educational to read, as it clarifies his technique in a way that his accomplished and inevitable-seeming books obscure.
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.
You have to consider that a prototype can be very, very rough. If it takes 12 months to make a prototype of a video game, then that's the wrong way to go about making a prototype. This is assuming that the core premise of the game doesn't involve inventing something impossible or solving the halting problem. Even if it involved something tough, you would just have to "fake it" until you figure out what you want to make, anyway.
You should also pick a platform that lets you do things easily, and limit the time you spend. If what motivates you about a game idea is the art and you spend most of your time designing characters or worlds, then after a while you have to treat that as your prototype or put in the minimal effort to combine them, instead of making cut-scenes and making a Final Fantasy game from everything.
The audience for the prototype isn't the final audience either. Maybe it can be friends if they're uncritical but you should really just make it for yourself if you're still in the picking an idea phase.
I suspect that people who play lots of different abstract games have a lot of prototype components on hand—stuff like different size square and hex boards, generic abstract pieces. Hex is a classic of the genre, and yet has gone long periods without affordable commercial sets being widely available—it's easy to build. Slither is a game you play with a Go set. Catchup you would just need a printed Hex board and some glass gems.
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.
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.
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.
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?
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.
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".
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.
In waterfall, he will do big upfront design for every game. Nothing will be implemented until the design documents were very detailed.
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.
every turn, +1 food every turn, 50% chance of .. etc
it's pretty detailed, worth looking into
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
