[MaulingMonkey]

One always has constraints, if only in time/budget/imagination. And those are some pretty boring, vanilla constraints.

Different constraints encourage or force different approaches, which gives you different results. You're not going to have a budgeting meeting over a <1K demo. You're not going to contract out to an artist. You're not going to use a large engine. You're not going to make a doom clone. You're not going to hum and haw over what middleware to use. It limits how much over-engineering you can invent. <1K is a pretty extreme constraint... but it's not that far off from what the demoscene does, and they discover some fascinating techniques and tricks in the process.

[emptybits]

That's an excellent description of why I recall the days of inherent constraint as fondly as I do. I was an 8-bit console programmer back in the day. I've also worked in a later era of sophisticated engines, huge teams, artists and coders often assigned narrow specialties, managed by tiers of development directors and producers and administrative staff. Pros and cons, for sure.

So in hindsight, two more joyous aspects of constraint in game development (whether inherent or self-imposed):

1. Bugs, testing, quality. When you know your binary will be burned into a cartridge with no hope of a patch or update, one tends to code and test carefully! You fill your allocated ROM banks with as much "fun" as you can (code and content) but you know it must be well tested for both play balance and bugs because you can't release a version 1.1. :-)

2. Scope creep. This is much easier to avoid when you're given (e.g.) four 16KB banks of ROM for all your code and assets. So you burn midnight oil for mere months, not years, before you find out if your game is a hit or a stinker. Short feedback loops. More variety per year. Refreshing.