I had a similar experience to yours -- when I was in college. LD was run on an infrequent basis then. I participated in two, as well as some student-run ones, and figured, "ah, I think I've done enough jams, I should do bigger games. These little ones aren't serious, they aren't what I want to be doing."
Years later, LD started getting run more frequently and got more popular. Remembering having a good time with it previously, I participated again and put in a lot of effort, thinking I could crush it with more experience, and soon realized I was wrong about both my experience and my prior perspective. Here's what I realized:
- Most of the time I spend on a big project is spent on learning something specific to that project. Minimizing the schedule means that I only learn things necessary towards finishing. This is not an easily dismissed skillset. It isn't the only skill, but it's your most easily monetized one.
- Tangibility is really really important towards motivating future work. This is why prototyping software is worthwhile in the first place. When it's finished, you have a reference, one which you own and probably understand better than anyone else. The reference isn't the code(which is probably butchered) or the assets(which are necessarily cheap) but in the possibilities suggested for future improvement.
- Prototyping - and creation itself - is a fractal endeavor. Each time you build a new feature, you have to do the same kind of work that goes into a game jam in order to prove and flesh out its capabilities. This is repeated the whole way up the ladder, until the project is complete. At each step you can prototype until you hit tangibility, polish it a bit, then move on to the next feature, etc.
While I agree that of 1000 entries, most are going to be half-baked, that's kind of the point. You're being encouraged to go in and pick up the experience of every stage of the project, so that when you want to expand scope, it's not hard or surprising, it just involves more learning and specialization.
As well, it helps you in identifying bad, unmarketable ideas faster, which is the real problem that plagues game developers - a lot of time and money sunk into something that could never sell.
I absolutely see the value in "getting down to it" and producing and MVP or demo or whatever. I think iterative, agressive development is the way to go when making any software product (which is what I do for a living).
My point is to criticize the emphasis on turning out "just enough" and then moving on. This isn't only within LD but I've seen plenty of it in the indie game development community in general as well. As a strong undercurrent in the community I think it's harmful.
If LD is to be about game development as a craft in its entirety (and maybe that's not LD's role) then I think it has to be about more than just producing a quick demo of an idea.
Years later, LD started getting run more frequently and got more popular. Remembering having a good time with it previously, I participated again and put in a lot of effort, thinking I could crush it with more experience, and soon realized I was wrong about both my experience and my prior perspective. Here's what I realized:
- Most of the time I spend on a big project is spent on learning something specific to that project. Minimizing the schedule means that I only learn things necessary towards finishing. This is not an easily dismissed skillset. It isn't the only skill, but it's your most easily monetized one.
- Tangibility is really really important towards motivating future work. This is why prototyping software is worthwhile in the first place. When it's finished, you have a reference, one which you own and probably understand better than anyone else. The reference isn't the code(which is probably butchered) or the assets(which are necessarily cheap) but in the possibilities suggested for future improvement.
- Prototyping - and creation itself - is a fractal endeavor. Each time you build a new feature, you have to do the same kind of work that goes into a game jam in order to prove and flesh out its capabilities. This is repeated the whole way up the ladder, until the project is complete. At each step you can prototype until you hit tangibility, polish it a bit, then move on to the next feature, etc.
While I agree that of 1000 entries, most are going to be half-baked, that's kind of the point. You're being encouraged to go in and pick up the experience of every stage of the project, so that when you want to expand scope, it's not hard or surprising, it just involves more learning and specialization.
As well, it helps you in identifying bad, unmarketable ideas faster, which is the real problem that plagues game developers - a lot of time and money sunk into something that could never sell.