Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)

> You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff.

None of which matter. The idea being if you are working on a component for version 2.0, even with all these "costs", it's better to iterate quickly. The only thing that is close to mattering is programmers' time, but even that is addressed in the article. Simply that it's faster to fail fast and iterate until you get the correct solution than it is to spend all that time planning.

I hope this doesn't come across as snarky, but this is very apropos for me.

I'm currently taking 6.856 at MIT, Randomized Algorithms, and one of the core lessons from the class is that random guessing is frequently a superior strategy. You can have Las Vegas algorithms which find a correct solution and probably execute quickly, or Monte Carlo algorithms which execute quickly and probably find a correct solution. The users are employing a Las Vegas strategy here.

So, perhaps he just didn't take the right classes at MIT :-).

For a neat example, check out finding a min-cut of a graph in a randomized fashion: http://en.wikipedia.org/wiki/Karger%27s_algorithm

I think this illustrates one of the biggest reasons many of the most popular mobile games have variable solutions and some sort of "star" rating for the solution. A lot of these games work on the idea that people ripping through it achieve the 1 star solution and go to puzzle 2. It has a "secondary" or "advanced" mode built right in for the person who wants to get 3 stars on each.

Common things to grade with stars:

Speed

fewest 'widgets' to solve

total 'impact' (Think damage a la angry birds)

etc.

We can also combine these sorts of things in the rating system. There is a great game, "Cargo-Bot", that is essentially a programming game. The rating system there only takes into account the number of instructions used but it could do something where it takes into account the number of instructions used and the run time of the "program" produced.

I guess my point is, designing games with singular solutions is probably cheating the gamer out of some additional fun (go back and finish on hard) and cheating the designer out of exploring some interesting concepts around "scoring".

I'm pretty sure MIT teaches some sort of AI 101.* CSP, local search (and genetic algorithms) is what you're looking for. Also make sure to check out the paper by Wolpert and Macready on "no free lunch in search and optimization" for a perspective on "best way"

*I also think it's a non-trivial connection to make that these types of problems are covered in AI or at least that's the feedback I get from students. "Oh didn't expect this search stuff thought it was about brainnnnnnz"

Pretty cool read though, thx for posting.

This is something that I've noticed myself. I find that it's much easier to write a paper for school by just writing something, no matter how simple, and using it as a framework for the next iterations. It makes it much easier for me to think of the paper one piece at a time. I've started trying to apply this strategy more rigorously lately. For a four page paper I had to write yesterday, I started by just writing out the structure of the paper:

"Start with a relevant 'hook.' Now lay down your thesis statement. I got to my thesis by starting here. Then I went and saw this. That turned into the other, and here you have the thesis."

Then I took each bit and replaced it with what I actually wanted to say there and continued to iterate from there. In this case, my professor has a very specific structure that he looks for in our papers so putting that first iteration together didn't take much effort.

Similarly, when I'm working on a programming project, I find it's much easier to start with a working iteration, even by stretching the definition of "working," and improving it until I'm happy with it.

It is, of course, important to look at the paper (or other work) holistically to make sure that it all flows together once the pieces are in place.