I've met and spoken with some of the "instant successes" in Flash gaming. DTD, Filler, etc. From the little bit of discussion I had, I got the impression that they didn't really have any profound understanding of how or why the game they made became hugely popular. Mostly, they were benefiting from right-place-right-time effects, from being relative outsiders to gaming, and from having just enough skills to do the job.
Basically, trying to crank out games quickly isn't really a recipe for success. It is a good starting place for creative ideas, though. You can start a project with one thing in mind, build it up to a certain stage, leave it a while to think about, and later come back and iterate on the whole concept.
But if you are looking for reliable success in games, the time spent is way more important.
Type systems have been getting better - more nuanced, more accurate/helpful static checking, though the mainstream is proving very, very slow to go away from the C model.
I'm going to speak in terms of techniques rather than tools. These are the best/fastest techniques I've found:
1. Procedural generation in your own code. People forget about this option because classical 2D games were too processing/memory-constrained to allow for anything but tiles loaded direct from ROM, but it's really great for environments. It works out to be very fast to produce because you can iterate and randomize and come up with a lot of variations without extra work, but you have to know what you're going for first. The download size savings is a bonus too.
2. Characters are cheapest to do with 3D only because of animation time. If you don't have a lot of anims, hand-drawn tends to give a more lively result, especially in low-res pixel art styles, but even then, painting over 3D will reduce your error rate. Invest in a Wacom if you want to get serious about drawing on computers, but start with the smallest size: you rarely need more.
3. When I need a clean cartoony look I drag out Inkscape and do a vector trace over the image I'm working with. This can take quite a while, but the results are really good when you go all-out and use two vectors per outline to give them variable width.
The default state of the world is free. Non-free happened because people decided that controlling content distribution for profit was a good idea, several hundred years ago. What if it isn't, or isn't anymore?
I can provide an example of how non-free would hurt you. If every site HN linked to was a pay-site then HN itself, Digg, Reddit, all those sites would suddenly cease to exist. All the fluidity of trading links back and forth would be gone as nobody would be able to afford to investigate what content is good anymore.
In fact, even Google would be in trouble if everything were a pay site. How could they possibly afford to pay to crawl every site on the internet? And, for that matter, what about all those startups that are based around data-mining existing web content?
The argument goes, "We can afford to produce better content by putting it behind a pay-wall." But when taken to the extreme, it's inefficient. No content is so good that it can replace the service of Google and other search engines. Or worse, in the ultra-non-free-world, Google would go from being a de-facto monopoly to a regulated monopoly; they strike up a pay-to-play deal for a site to even EXIST on their search engine and the entire Web is at their mercy. (we're not even talking about placement here)
It sounds ridiculous, but it's exactly the kind of thing we've let happen to copyright and patents in the past. By entering into these complex arrangements of enclosure, you end up with a battle between governments and big business that squashes the rights of individuals beneath regulation and fees.
He starts from the thesis(previously established) that money earning interest is the source of our massive wealth inequality problem - interest ultimately favors a concentration of wealth on one person, and it also favors destructive practices that make a large sum of money immediately and earn interest exceeding the value of a sustainable solution.
From there he points to multiple alternatives that might bring us towards an equal economy without top-down planning.
The one that always bugged me but seems to be true for most dynamic languages is immutable types being passed by value and everything else passed by reference.
A similar-looking symptom I've seen with IE6 is that links won't "take" if I click and then move the cursor away. IE will display a message in the status bar when I click, but for some reason it is noticeably less likely to actually load the page if I don't keep the mouse on the link. This was particularly bad on dialup.
I've been deep in the depths of hacking a new feature into an existing language - adding a reflective/referential data definition language on top of haXe. (It's called XReflect, if curious you can get it off haxelib)
Essentially, the problem I keep running into with referential data structures is that haXe, like most popular languages, will only let you set them up in an imperative fashion, one dependency at a time, which tends to both spread out and bloat application code. What I want is to write my dependencies in any order and let the resolution be sorted for me.
I'm pretty sure a language with AST access and quoting like Lisp makes it relatively easy to write something along these lines, but in haXe, I had to write about 500 dense lines of code, most of it going to parsing and fighting the limitations of the type system. It still has some major bugs that I'm trying to resolve with a refactor at the moment.
The funny thing is, I know I'm not just fighting haXe here, I'm also running into the limitations of the platforms that haXe compiles to. The newest strategy I'm applying to resolve references is to add a "__parent" field to the reference stubs, which refers to the container(an array or record type) of that reference. I use that later, after all references are resolved, to drop the final value into the place of the stub, but as it turns out this causes difficulty printing out the working structure. Neko will recognize the value of __parent as "....", but Flash 9/10 will recurse into the field again and get a stack overflow.
So I had to add more code to write a pretty-printer which is aware of such traps.
Or if you want a strictly economic explanation: The law is a cosmetic blemish upon what could be a top-to-bottom free system.
The high level would be original free software and media - tools and inspiration.
The medium level is derivatives; things made using the tools and media built upon other media.
The low level is the consumer level, where the best things are filtered and distributed to the public.
The system takes the lowest-cost option at each step: remixing material and building on open source is easier than starting from scratch. Digital distribution is easier than physical distribution.
But it is entirely dependent upon the source material being permissive-use. When it isn't, derivatives become illegal material, and people will subsequently choose not to make value-added derivatives because any profit motive that would have existed is gone; settlement and legal fees are likely to wipe out any gains.
This doesn't affect the consumers of media, however, because consumers are largely anonymous and hard to target by the legal system. Thus you get widespread piracy, but few derivatives.
Unsalted nuts. They store really well. Walnuts in particular have plenty of calories but if you have too many in a day you'll be overloaded on omega-3, which will make your hands and feet swell painfully as pressure is applied; the blood vessels in them start breaking too readily.
So nuts aren't the bulk of my calories, but they help make everything else taste better.
It's like going back to the days when ROM BASIC was built into every "microcomputer." Only this time they're going for a full OS instead of just BASIC.
Basically, trying to crank out games quickly isn't really a recipe for success. It is a good starting place for creative ideas, though. You can start a project with one thing in mind, build it up to a certain stage, leave it a while to think about, and later come back and iterate on the whole concept.
But if you are looking for reliable success in games, the time spent is way more important.