DF-21 Forums

[lucius]

I have a question for you guys: Would you rather I make major builds with several features in a "complete" package, like build 8 or the planned Build 9 or make each major feature/change into a new build. For example Build 9 could be broken up into several builds: 1) iMuse build, 2) Portal/Tesselator fix build + rended opts., 3) Test base + secondary fire and so on.

*Larger builds allow complementary features that form a cohesive package - similar to a game patch. These will have some features that everyone cares about so they should be somewhat exciting for everyone.

*Smaller builds are more frequent but may have features that people don't notice or care about or may not be very exciting themselves. For example, rendering optimizations may not matter if the game already runs at 60fps for you.

Which kind of builds would you like to see from now on (atleast until its appropriate to change)?

_________________
DarkXL....http://darkxl.wordpress.com

[dinohog]

Hi Lucious,

Blow us away with a suite of new features and levels. And either way, keep up the great work, much appreciated.

Dino.

[lucius]

Thanks for the feedback.

_________________
DarkXL....http://darkxl.wordpress.com

[The MAZZTer]

Smaller builds.

Let me explain why to whoever jumped at the "bigger" option:

Let's say we get smaller builds, and we get a build a week. Larger builds will be once every three weeks, we say.

Let's say lucius puts features X Y and Z into a large build, if he were to wait. Other wise he only has time to do one a week.

Oh wait. In three weeks time we have exactly the same build.

So it is better for the smaller builds. If you want larger builds, only download every Nth build and pretend the other ones don't exist.

The rest of us can enjoy the new features before you do. :p

Another way of looking at it is that lucius can't magically put more time into coding if you ask for larger builds. So there's really no point.

_________________
http://www.mzzt.net/ | I am a respectable admin with a respectable sig.

[sheepandshepherd]

Good way of putting it, MZZT. Either way, lucius is spending the exact same amount of time on the features. Why wait three weeks for X, Y, and Z if we only have to wait one week for X and two for Y?

Are there even any disadvantages of doing small builds? I mean, is it inconvenient for anyone at all?

[lucius]

If anyone has differing opinions (and I know some of you do based on the poll so far) then feel free to voice your opinions and reasons for them. I already know The_Mega_ZZTer's logic, which is very valid, but I'd like to hear the logic from the other point of view as well. Of course you're not required to submit a post with your vote but the more people's opinions I have the better.

Oh and sheepandshepherd, you lost feature Z when moving to smaller builds.

Thanks for your feedback everyone.

_________________
DarkXL....http://darkxl.wordpress.com

[Gez]

I think incremental builds are better:

- It lets each new feature gets more playtesting as it is added, since everybody will be eager to test what's new. So any issue is discovered sooner. With large builds, some new features might be overlooked. Features X and Y take all the spotlight and few people pay attention to feature Z (see how MZZT forgot it entirely? ).
- It makes the forum more active as well, and keeps interest in the project alive. With infrequent large builds, you get a rash of "wow, neat!" messages that last a couple of days, and then it dies until the next build. With frequent incremental builds, activity (and thus feedback) stays constant, so people don't forget about the project.

[Fenwar]

Unless it creates a lot of extra work for you, I vote for smaller builds

That said, I'm a bit behind and haven't actually tested the latest major build (due to a looming deadline at work which I am foolishly trying to get done before I go on holiday )

[Geoffrey S]

Larger builds. It means moments of release are central: more people testing at one time, and it prevents possible issues with people testing differing build simultaneously. Makes things far easier to keep track of by focusing attention and testing around the new, larger builds, leaving more time open to correct issues and work on new features after that testing period. Regular, smaller builds may be harder to keep track of and lose the focus that larger builds provide in coordinating testing.

[C. Zoui]

I voted for the larger builds with longer development time. This is purely for my own convenience, though, because it would assure that I could test at my leisure; I wouldn't have to worry about testing everything before the next update was out, possibly fixing things I was about to report. I'm waiting for Build 9 to jump in.

Ultimately, I'm for whatever maximizes the effectiveness of the general testing populace and/or makes Lucius' work easier and more efficient.

I have one minor, tangentially-related quibble: labeling updates by the number of times you've updated instead of by build number seems superfluous, and it was a bit confusing to me at first. If you do move to a shorter build system, I would recommend labeling threads by build and not update number for organizational purposes.

[lucius]

[Burning Gundam]

I guess when it all boils down to it, it's the same amount of work getting done in the same amount of time. My only convenience I can think of as far as smaller build releases is that certain bugs get addressed faster and testing comes in a steady flow rather than tons all at once. Of course, releasing larger builds allows for more implementations and features at once and pointing specific bugs out much faster.

Either way, it shows the work you put into this (Which I can't get enough of praising).

_________________
I don't think outside the box... I customize it.

[sheepandshepherd]

Now that I think about it, probably the biggest advantage of small builds is that lucius will be able to fix unique issues that don't affect everyone, such as the crash Burning Gundam was having a while back. That ensures that everyone gets to play DarkXL and help out. Otherwise, someone might be having crippling problems with the game and lose interest while waiting for the next large build.
Of course, you could always plan large builds but make exceptions for situations like this, only fixing the unique and serious bugs before releasing the next planned build . . .

[lucius]

[Burning Gundam]

Good call.

_________________
I don't think outside the box... I customize it.

[sweatervest]

I think smaller builds allow bugs to be pin-pointed more easily. Remember when BlazingPheonix had the crashing problems for a while after a build was released that updated both the graphics and sound engine? People spent weeks scratching their heads over what it could be (including lucius putting out several builds that attempted unsuccessfully to fix the problem) before it was discovered that the rendering/graphics updates didn't cause the problems but it was the change to the sound engine (if I remember all of this correctly). If small builds come out with one or two changes and something goes wrong then we will know it is one of those two changes, instead of putting out a build that say redoes half the program and when that causes bugs who knows what actual changes are causing them.

I think it is a similar situation as when one is actually coding something. I learned first-hand not to write a huge program in one pass and see if it runs, then try to find all the bugs in it. By writing short pieces and testing them as they are implemented bugs can be removed as they are created. In a similar way, the community can test smaller updates on different hardware to find bugs more efficiently.

[Marley]

[Patrick Haslow]

Yeah if you are working on this as an open project, a few tasks at a time, the public here is pretty much you're QA department. Better to go with the small builds to keep em working for you.

[Magic_Al]

It sounds like the smaller builds are better for testing, while bigger builds are more convenient for those who are here intermittently. If the version numbers have a decimal, people who can check on it less often will hold out for the bigger number increments while those doing issue-by-issue testing would grab every point release.

_________________
----- MagicAl`s DARK FORCES Niche -----
http://wayback.archive.org/web/*/http://homepage.mac.com/anewmanagn/magic_al/

Armed only with a blaster pistol and an intimate knowledge of
Imperial methods, MagicAl prepares to go to lunch....

[lucius]

Thanks for the votes and responses everyone. I was leaning toward smaller builds myself, but I wanted to get the general concensus. My idea is similar to Magic_Al's, there will be major builds similar to build 8 and build 9. Then there would be a "point release", as Magic_Al calls it, for the various features that lead up to the major build.

Using the current scheme, iMuse could be build 8e. Then each major feature leading up to build 9 would be 8f - 8? and finally Build 9 when all the planned build 9 features are complete. So some people can just pay attention to the major builds and those interesting in seeing features earlier or testing early can try every build.

If I'm going to do it this way, though, then I should switch to a decimal system. So the next build will probably be build 8.05 - probably confusing at first but it will simple enough. The following build would be 8.06 and so on. The major builds will then move to the next whole number (build 9.00 for example). How does that sound?

_________________
DarkXL....http://darkxl.wordpress.com

[Fenwar]

Makes sense to me

[Emon]

From a process standpoint, frequent, iterative releases makes a lot more sense. Bugs are introduced in small batches and are easier to detect. You get feedback in smaller, more manageable quantities and you get it more often.

Large, infrequent releases are falling by the wayside as software becomes more complex. It's a broken process model, even for small projects. It made more sense 10 years ago when software was released on expensive, physical media.