[vaidhy]

It looks like a fun programming project..However, I am getting lost as to the purpose. Why write something so hard to comprehend just to get it into ~< 1K unless the only purpose is to get it small? Why not a larger game that is more fun to play? Why not a larger game that is still tight code, but good to teach game mechanics?

[KilledByAPixel]

Hi, I'm the author of the post. The reason I made it is because I've already worked on a ton of other games and I wanted to try something different!

I've worked in the AAA industry for years on many games. Just recently on Doom, I remember that code was so bloated you could open "hands.cpp" and just hold page down for days. I've also released many games on my blog, like close to 40 games on there.

So the main point is just try creating something different. Maybe for you it's not writing tiny code, maybe it's something else that seems pointless but you know you will have fun doing it and at least create something in the end. Trust me, it will be worth it.

[ilovetux]

IMO art is all about working within constraints. i think this might be some of the most beautiful (if not maintainable) code out there. No body needs to maintain a picasso, just preservation.

[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.

[rococode]

I think the concept here is like Code Golf. It can be fun to just write code that meets certain odd requirements, even if the end product is nothing super special.

https://codegolf.stackexchange.com/

[munificent]

Why play videogames at all? What does that accomplish?

[ToFab123]

Does it have to accomplish anything? Isn't it OK with you to do something for no other reason than is fun?

[Scarbutt]

Isn't it OK with you to do something for no other reason than is fun?

That was his point.

[munificent]

Ding ding ding!