Users of my iOS Game Teach Me a Lesson MIT Didn’t (2011)
blog.aaroniba.net
blog.aaroniba.net
Thus I found it hilarious when Blizzard thought it would take people months to completely finish Diablo 3. Real time? A week or two.
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".
This is the same thing but with people instead of CSP-solving algorithms.
I had a similar experience when I published an iOS game in 2011. I was still in high school, so publishing a game available on the App Store was quite a big deal to the other people at school. I became known by a bunch of people for making this game. One day, someone I'd never spoken to comes up to me and shows me 'a bug'. It turns out this guy had developed an optimal strategy that would win the game every single time, with an almost perfect score. I totally failed to anticipate this way of playing the game. In retrospect, it was quite naive to assume that players would play how I would. When I played my own game, I had the technical knowledge of how the game functioned - and it seems as if this context clouded my vision of more creative ways to play this game. Players didn't think about collision detection, trajectories, the scene graph, parallax scrolling and z-indexed sprites. Instead, they saw the game as world to interact with, and having zero knowledge of what was going on behind the scenes afforded them a lot of room for creative exploration (and exploitation)
I have this same problem when I test my own software.
Unit tests never catch everything. The problem with them is they can only test everything the coder thought to test. There is value in testing all of those things the coders never thought of.
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
This made me chuckle. I think this says more about the MIT mindset than about the users. Also, the total surprise at the guessing strategy is characteristic of a mathematician.
Nevertheless a fun little article to read.
"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.
it's probably easier when, as the author designed his game,
> each puzzle has only one possible solution-path given the starting conditions
the risk of iteration is having gone through the "wrong" branch at one point and being stuck in a local maxima: it works, but it does not work as well as it could. This may or may not matter given the constraints of the situation (and in most situations, it will probably work well: the goal is to get there rather than to exhaustively maximize "brownie points")
It is if you have no additional cost in building/destroying something, as in this game. If you had a pot of money and every piece you placed/destroyed cost you money (or even more than a fraction of a second in time) - as is often the case in real life - then the picture could well be very different.
But for programming ? You don't have those kind of costs.
Where did you get this strange idea from? 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.
[1] http://www.infoq.com/interviews/agile-software-architecture-...
At the simplest level, 5 days of coding something that you realise doesn't do what you want is 5 days you'll never get back.
At places like mine, where you've got multiple third parties that you're interfacing with, sending them off to develop something before being 100% certain that they are doing the right thing could - and reasonably frequently does - have many thousands of pounds of cost implications, and many months of delay, when you realise that a particular call needs to real time instead of batch for example.
In product (prototype) development, there's a maxim that's followed by a lot of people "Plan to throw the first one away" or something to that effect. Sure, it may not work for every case. But, for lots of projects, it's useful to accept the notion that you will learn enough building the first one to get more value out of throwing it away than by keeping it. There are just too many things that can't be seen without a (probably) unattainable level of diligence.
*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.
It confirms one of my opinions about proficiency in general. Proficiency has a lot to do with pattern recognition and having access to multiple tools, each tailored to solving a particular problem. Figuring out which tool to use for a given problem is a key aspect to proficiency, but the time it takes to carefully select the proper tool can often be trumped by simply choosing always the same tool and succeed or fail really fast. More often than not, the pattern matching after the first pass will be simpler because parts of the problem will be solved already.
I started thinking about it when I was a kid discussing the best football (as in soccer) players with my friends. I always favoured players who could use both feet and their head equally, able to figure out the path of least resistance every time, but one of my friends would say that the very best players would only use one foot, their best foot, and focus on their placement to maximize the use of it in every occasion. In other words, when the stars align they are unmatched, and their whole strategy revolves on making those stars align as often as possible, rather than on figuring out how to play on a given spot.
It made a lot of sense back then, as the one-trick-ponies could easily and consistently out-play the jack-of-all-trades if they had a whole team dedicated to serve their right foot as often as possible. I find it eerie that it still does make sense in the context of your game, and many others. When time is of the essence and wrong moves only cost the time they take to perform, you can either spend your precious time thinking of the correct play, or spend it doing something that doesn't require you to think at all, and adjust as you go using pattern recognition on smaller subsets.
That's why startup founders need to be experts in their domain. It takes too long for someone new in the space to gain a deep understanding until they have their unfair advantage.
I was inspired to write this post about my experience - https://news.ycombinator.com/item?id=5453761
http://en.wikipedia.org/wiki/Software_prototyping#Throwaway_...
The game looks good though. I'll probably try it out.
I don't think my version of that class was very useful, TBH.
For fun: if you can encode a human's cognition and spatial awareness for things like this, you can probably do the same for NLP, then write a tl;dr app that massively outperforms summly and sell it to Google for more than $30M. :)
Indeed, many things in real life follow this pattern.
Well done!
If anyone is interested in game design, I'd recommend this book [1]. Yep, the most important part is make something, give players to fiddle around and iterate to next version.
Though, I don't think a hill climbing algorithm is going to be too helpful when there's only 1 solution.