Wow, you guys work fast

[TechSY730]

It was what, last night you released 0.256, and already 0.257 has about 2/3rds the number of entries in its release notes. And even that insane rate pales in comparison to your multiple betas a day you had a few weeks ago. How do you guys do this?

P.S. Should this moved to the development forum?

[PlasmaChroma]

released 0.256, and already 0.257

Slight dyslexia there

Arcen seems to do pretty well at actually executing "Agile" software practices.  It's been a buzzword going around the software industry, some companies manage to effectively use it and others manage to bomb projects into oblivion with it.  The polar opposite being "Waterfall" model, where everything has to be established up front.  And there are reasons to use both, Arcen seems to benefit a lot from an "Agile" style.

The important bit is being able to integrate continuously and always have a "working" build.  And from what I've seen, the builds are working quite well.

[Hearteater]

Does Arcen actually use Agile?  It seems more like they are following the "Get Shit Done" paradigm, a rare design practice possible only in smaller companies that don't yet have managers to complicate things.

[x4000]

Buzzwords are fun, but only so useful.  I'd say that we use something along the lines of Agile practices, but I think every company's interpretation of that is different.

For us, there are three main things we try to balance:
1. Fun new features that are smaller (enemies, abilities, and other kinds of content).
2. Fixes and balance tweaks (these individually are usually very fast to implement, leading to giant release notes, but the time adds up and we could do nothing but this if we weren't careful).
3. Larger features that take days or weeks, and don't create excitement short-term, but lead to longer-form wins (multiplayer, intro mission, crests, etc).

The key is to evaluate all these various things and try to fit them into a daily schedule that makes sense and that is attainable, and most importantly to mix them together in a way that maximizes the amount of work done.  If I am implementing a certain bugfix or feature, and I remember some other kind of related stuff to that, I'll hit them up while I'm there and get a big time savings.

[KDR_11k]

Agile is still a strict process, it just doesn't use separate planning phases and instead works on principles like test driven development that basically turn the code into the planning. I don't think Arcen follows that, agile doesn't mean faster, just more flexible. Small indie teams usually don't need a fixed process, that's more for keeping larger teams organized.

[x4000]

Yes -- I've read in some detail about Agile and other various practices, but I find them too structured to be useful.  When I say that we use something along those lines, I mean that I took the parts that I liked and use those in a small team environment rather than sticking strictly with any external methodology.  I did the same thing with a small team at my old employer, too, so it's not new to me with Arcen.

[@B0FH]

My favourite methodology ever, and I stick by it to this day in as many walks of life as possible, is JFDI (learned from an Oracle guru).  The polite version is "Just Do it" like hearteater's post.

[PlasmaChroma]

Agile is still a strict process, it just doesn't use separate planning phases

I just tend to look at anything iterative and sorta hand wave think "agile-ish" as a basic feel rather than something solid.  Most software development practices seem to be born from the enclosed world of academia.  I think adaptation is probably pretty much the norm.  I don't really believe any of the indies are _that_ rigid.

The talk Johnathan Blow (developer of Braid) gave at CSUA highlights some of the realities of indie development (http://the-witness.net/news/2011/06/how-to-program-independent-games/).  According to him, as a small shop you basically have to be something like 10x as efficient as the supposed "industry standard" to be successful.  And unless you adapt to what you need specifically and no more, those efficiency gains are probably impossible.

[x4000]

According to him, as a small shop you basically have to be something like 10x as efficient as the supposed "industry standard" to be successful.

I've always said 3x, but I've been speaking about general business programming at tiny companies compared to their midsize counterparts.  When you start getting into the behemoth companies, in the gaming industry or outside it, I could see where 10x would perhaps be a more appropriate scale.