next »

[Glaiel-Gamer]

Mine was definitely Blockslide 2.

It is probably my biggest released game to date (biggest, not best). Course, that was the problem in it. It was TOO big, and most didn't draw on common elements of similar puzzles. Instead, I opted to creating new rules for many of the 25 or so block types, and how they interacted with the other blocks. That's hundreds of interactions, and many of those had completely arbitrary rules (ice slid on grass but not on ice was probably one of the worst). 25 levels in the tutorial wasn't even enough to cover everything, and most people thought it was the whole game.

That's not to say the game wasn't good. By all means if you managed to learn the rules of it, the 150 puzzles in it plus the editor and the (about 800 by now) fan network puzzles were challenging and entertaining to solve, and well made. The barrier of entry though is just through the roof, and as a result, nobody enjoyed it but me and a couple of other people who cared enough to learn the rules.

And yet, its failure has continually played a huge roll in the development of all my projects since then.

[ஒழுக்கின்மை (Paul Eres)]

an rpg i was working in in the ohrrpgce for around seven years which had around 2800 pages of design document (plus tons of sketches and index cards) but which i never finished for obvious reasons

(that doesn't mean it won't ever show up in some form, just that it was a big project that taught me not to be overly ambitious with projects, but instead make something a human can actually finish)

[Gold Cray]

Seeds of Insanity, a procedurally generated Cave Story clone. I failed 4 times before I realized that I wasn't ready yet.

I learned what my limitations were, and especially during the fourth iteration, I learned about the damage that over-ambition and feature bloat can cause.

I also learned a lot of basic stuff about video game programming along the way, though.

[Glaiel-Gamer]

Seeds of Insanity, a procedurally generated Cave Story clone. I failed 4 times before I realized that I wasn't ready yet.

Care to elaborate what exactly you learned from it?

Also I probably should state (as I expect to see 90% of the comments be "i started something that was too ambitious") that "biggest project" doesn't necessarily mean most ambitious project, I mean it in relation to how much you learned from failing or half-failing. Blockslide 2 wasn't really a huge failure just because it hit under-par for me, but as I mentioned before it taught me much more about design than say, the rpg I never finished.

[Kaelan]

I spent around 7 years on a single game engine and built maybe five dozen game demos and prototypes with it during that time. I never finished any of them (though a couple got relatively close).

On the bright side, I did learn a lot from the process. I still find myself visiting the sourceforge page and grabbing code snippets out of it, usually for math/animation related tricks or design ideas.

And it was what finally cured me of the desire to use Visual Basic! Finding bugs in your compiler has a way of doing that.

I think about half of the things I know now about proper software architecture, OOP, game programming, etc. came from the project, which is pretty good considering the tools I was using. Of course, I ended up with tons of bad habits to unlearn. :/

I remember having a couple long-lived RPG projects in stuff like RPG Maker and ZZT, too, but most of them never went anywhere. Too easily distracted, I guess - never spent enough time on them to learn much from the process.

Man, ohrrpgce. That brings back memories.

[I_smell]

I've got a couple learning games I never released or never finished.

The Fuckin Awesome Quest was my first attempt at an isometric beat-em-up. I really wanted to make one but was finding it to be just about the most complicated kind of game to make. I wanted for it to be huge, but hadn't planned any of it at all, the scripting was all broken and the animation was really boring and slow, the design of all the art was also boring.
I took what I learned from that and later made Crunchdown, which has many of the same problems, but it's not nearly as bad.

I'm doing a fucking stupidly massive game right now that I so hope doesn't come out looking stupid.

[Aik]

Well, pretty much all of my projects fail but teach a lot, although the most useful one was probably the 2D sidescrolly-adventure thingy I was writing in Python that turned into a horrible goop of tightly coupled classes where every change meant changing stuff in two or three other classes. Thinking things through before vomiting out a bunch of code seems to help avoid this, so now I'm doing that.

[fish]

fez

[Anthony Flack]

Six years on Cletus Clay and counting...

What have I learned? That if you make an asset-heavy game, you spend all your damn time making assets? That it IS possible to do everything yourself, but it might not be much fun to be that person?

That releasing games is more satisfying than not releasing them. That everybody needs to earn money sooner or later. That having somebody else be my producer is a good thing. That managing a team is both a blessing and a curse. That deadlines are both necessary and evil. That I tend to make games way too slowly for my own liking.

And I think in future I would like to split my time between larger commercial projects where I am more of a designer/director and less of an asset monkey, and small freeware games that I do solo.

[Bood_war]

My current project Arsenic Cookies. It's taught me to plan before doing.

[siiseli]

Learning c++ by making a platform engine.

[Frog]

Broadcast: Robots (the platformer I'm working on) is turning out to be a fairly tricky process but my coding skills have improved drastically since I started.

[Klaim]

fish & Anthony Flack > I sympathize. +2.5 years on my game and no really playable version yet.

[Glyph]

On Commander Jetpack, I learned noone wants to play a really hard game where you can't even find the first save point. There was a lot of content in it, and I'm pretty sure only a handful of people ever saw most of it. I definitely learned from that, and it was the hard way, for sure.

[aeiowu]

  dinowaurs

Honestly though, I wouldn't trade that experience for anything else. Had it been an "easy" project to complete, we would have learned very little. Now our skin is stone.

I see games like these (successful or not) are kind of like purple hearts in the indie world. Kind of how you earn your wings or cut your teeth; it's where you truly learn about the importance of stamina and attitude. Coming out of the haze, you're a battle-hardened soldier. I like to think (and probably wrongfully so) that that's how us indies learn, through the birthing pains, while AAA devs are more like the impotent parents who find a bunch of surrogates to birth their game for them.

[Gravious]

I've got 5 games that I'm desperate to make, all different genres, i gave up on the RPG as my lead project when it became apparent they're rock hard to do

Now I'm making an engine first and foremost, with a general aim for one of the 5 games steering the way.

Saying that though, after every challenge comes an even more perplexing one :s

[DragonSix]

With IceWolf, I learned that I shouldn't ever begin a game with other people involved right off the bat.
It can only work correctly when you bring them on later in production, when the feeling of the game is already well defined and the whole design less likely to change drastically.

I also learned that I should never wait after the promises of a middleware provider, they never deliver on time. I now know that I must only take a middleware as it is now and not what it could be in the months/years to come. If it doesn't fit perfectly to the project right away, replace it for another middleware immediately (or make yours).

[Kaelan]

With IceWolf, I learned that I shouldn't ever begin a game with other people involved right off the bat.
It can only work correctly when you bring them on later in production, when the feeling of the game is already well defined and the whole design less likely to change drastically.

Really important lesson, that. People tend to want to scale up a project early, so they can go at full speed, but in practice it's hard to hold a team together if you haven't figured out what your game 'is' before you bring them on board. Vision!

[aeiowu]

With IceWolf, I learned that I shouldn't ever begin a game with other people involved right off the bat.
It can only work correctly when you bring them on later in production, when the feeling of the game is already well defined and the whole design less likely to change drastically.

Really important lesson, that. People tend to want to scale up a project early, so they can go at full speed, but in practice it's hard to hold a team together if you haven't figured out what your game 'is' before you bring them on board. Vision!

meh, i think it's one way to do it. Certainly has its disadvantages though.

If you bring in people after all the big decisions are made then ownership of the ideas fall more on your shoulders and people you bring in later don't have as much of an emotional/intellectual investment. Sometimes that investment is the only currency we can offer to collaborators... Instead of it being "my" game, it is "our" game. I think that's an important distinction. If you work with people that want to scale up a project early, well.... maybe those are simply the wrong people to work with...

[hatu]

Mine is Whiflash. Who hasn't tried to make a epic RPG though?

Even though I came up with some pretty good ideas to cut down on the amount of content needed, it still was pretty impossible to do enough in reasonable time and I had to severely cut back the scope of the game halfway through.

I did learn a better order of doing things, shitload of technical stuff, what to avoid doing and not to try to make any epic 50 hour games alone.

Also that small(relatively) polished game is much better than a big unpolished one.