Legacy:Mychaeel/Modding Etiquette

This page is a collection of ramblings of mine. Do not edit, but feel free to comment. (Scroll down for comments.)

I might change my mind on the matters discussed on this page without notice. Part of the reason I'm writing them down is that I want to validate them for myself; that's much easier if I have to reflect on how to put them in words.

Modding Etiquette

So you want to make a mod? Great! Welcome to the modding community.

First of all, there is a variety of ways you can learn things – the hard way, or by listening to advice of people who have been there. Nobody expects you to take that advice without reflection or by anybody's (actual or self-proclaimed) authority. Just think about it. When you actually start thinking about the stuff people more experienced than you are telling you, you might end up realizing that there's some truth in them.

This article is not about the technicals of modding – I'm assuming that you're familiar with them or know how to become that way. It's about the Etiquette of Modding – how to make people like your mod.

Understand Your Audience

The key to making people like your creation is looking at it from their point of view, not yours.

Yes, I know you have put hard work and lots of dedication into your mod, without getting any revenue from it. And most people don't care; that's a simple truth. But then again, they don't owe you anything – you have no deal with them; they didn't hire you or promise you anything.

Now that your mod is released, the people out there are spending time and effort downloading and installing it. It might be negligible effort compared with what you put into creating the mod, but that comparison doesn't apply – as I said, they don't owe you anything to start with. Only in the moment they're actually trying out your mod, you're starting to have a deal with them: They invested time and work in attempting to try out your mod, so you better make it worthwhile.

That simple realization immediately leads to a couple of points:

Don't Raise False Expectations

More than obviously misleading statements the lack of a statement can lead people to fall back to default expectations that don't apply for your mod. The only thing you can gain by people believing in promises that your creation can't keep is a mob of disappointed, flaming users. That is something you should avoid.

• Public alpha and beta versions have their place, but that place is equipped with big flashing red warning sign. (Don't take this literally; any sort of unmistakable warning suffices.) That means, everywhere, not just hidden somewhere on the download page and in the readme file. Your audience should never even start believing that they're dealing with a release-quality product if they aren't. If you're ashamed of admitting that your release is just a beta yet, don't release it. (I'll pick that up later again.)

• Unreal Tournament mods are, by default, platform-independent. Thus, if you don't expressly state otherwise, your users will expect nothing else; so the same big red flashing warning thing applies as well if you release a mod that is, for instance, Windows-only – be it because you put some native code in or just released your mod in shape of an .exe installer. Mac and Linux users will hate you if they click on a download link in happy anticipation just to learn that they've been purposely left out. If that realization occurs only after an hour-long download, even worse. (And would you blame them?)

• People expect mods to work both online and with bots. See to it.

Make Your Mod User-Friendly

The average user will neither read a FAQ, nor a readme file, nor a manual unless he or she is hard pressed to or highly motivated. You can assume neither to start with. The best way to deal with that is making reading FAQs, readmes and manuals optional – in other words, spend some time to design your mod in a way that works as the user expects it to. If you're unsure whether that extra design time of yours is worthwhile, just think of all the time you'll save yourself by not having to groan "Read the FAQ" or "It's all in the manual."

• Use existing facilities the user is familiar with rather than inventing your own, even if you think that you could do it marginally better. Stick to UMod installers and plain zipped distributions if you can help it. Use the built-in mod launcher instead of creating your own flashy external launcher the user first has to look for (after reading the manual) in the System directory. Plug your server browser tab into Unreal Tournament's built-in server browser. Make in-game controls work as users are used to them.

• Don't impose arbitrary restrictions on how your mod works. Mutators, for instance, are by design and by default cross-compatible to each other; but of course that doesn't mean that it's impossible for you to create a mutator that won't play well with others (by subclassing PlayerPawn, for instance). If there's an actual need for such a restriction, make it inherently obvious. Otherwise, investing time in coding something a less straightforward way to achieve the same goal while keeping compatibility is time very well spent. An arbitrary restriction mentioned in a FAQ or readme file will just shift people's perception of it from "bug" to "known bug," nothing else.

• Actively provide guidance for things that aren't obvious. Don't assume people have read the manual and know that pressing this-or-that button will pop up a menu crucial for gameplay – put that information somewhere on the HUD, for instance, at a reasonably unobtrusive, but visible location. (And add an option for advanced users to switch that extra help off.) Strangelove does that for its flight controls, Jailbreak for scoreboard sorting options.

• Provide a convenient and thorough uninstaller for your mod, and make sure it works as advertised. If people are unsure whether your mod is worth a try, they'll be much more inclined to give it a chance if they know that they can quickly get it off their harddisk again in case they don't like it. Also, if somebody wants to uninstall your mod but can't figure out how (and possibly ends up reinstalling the game in order to get rid of it) that's a surefire way to make certain he or she will never try any future version of your mod again.

Be True To Yourself

I've actually come to think that a team's chance of success is inversely proportional to the amount of time spent on the web site.

: fragbert

If people get the impression that you're overrating your work, they'll be much less inclined to add to all the credit you're already giving yourself.

• Keep the hype at a reasonable level. That goes hand-in-hand with the "don't raise false expectations" issue mentioned above.

• Don't fancy yourself of making a Total Conversion if the differences to what you're converting don't justify it. There's no less honor in making a great mutator or a fun game type as there is in making a Total Conversion. All those mod types have their place and uses, but thinking of a Total Conversion as the epitome of a game modification is simply wrong. If you ever try to deal with the issues imposed by people's expectations of a game type mod or a mutator (for instance, cross-compatibility with other types of custom game content), you'll be left without any doubt of that assessment. The demands of making a Total Conversion are different, but not necessarily more sophisticated.

• A custom launcher, splash screen, look-and-feel don't make your mod look professional – just like smoking doesn't make you look cool. (Generously quoting luquado from Nali City, "that only works for cool people" – or professional mods, for that matter.) Add those things as fancy final touches if you must, but don't think of them as a requirement for your mod's professional appearance.

Dealing With Critics

After your mod is released, you'll get all sorts of feedback – both positive and negative. You can reduce the negative feedback to a minimum by following the advice in the section above (keep in mind: disappointed users will be the least forgiving ones), but even then there'll still be people who just don't like your mod, or some aspects of it.

First off, ignore the trolls among them. You can recognize them by their habitat and their behavior; since their goal is to provoke an (offended) reaction, they'll say their piece where a lot of people can read it, and it will be designed to insult you. Just ignore trolls. They're perfectly aware of what they're doing, and what they want you to do, and you're in no position to insult them by questioning their statement's validity. Mock them, gently, with a smile on your face, if you like – that'll drive them mad. Just by no means take them seriously or behave that way.

But not everybody publicly bashing your work is a troll; be very careful before you dismiss somebody's criticism as simple trolling. (It's all too easy to go that way rather than facing the fact that people are genuinely unhappy with your mod.) There's practically no other reason for somebody not liking your mod and expressing it in your face than being disappointed by it. Disappointment is the result of expectations that weren't met. And there are two ways you can deal with that: Either lower the expectations (won't help people who already had them), or meet them.

There are a couple of things you should never tell people criticising your work:

• "Do it better." The different roles of developers and users are clearly defined: You (the developer) are investing time in order to get a positive response; the user is investing time in order to be entertained. If your mod fails to deliver the latter to the user, you can't expect the user to deliver the first to you. It's not a matter of switching roles.

• "It's just a beta/an alpha." Alpha and beta versions shouldn't be released to the general public in the first place (see below). In any case, that your released product is still in alpha or beta stage certainly doesn't invalidate users' complaints or make the developers any less responsible for it, so pointing out that "it's just a beta" is a pointless thing to do.

• "You didn't pay; you're not entitled to complain." Remember what I wrote above about having a deal with your users – they don't owe you, you don't owe them, until they invest time and work in trying to get your mod up and running. They have every right to complain if that investment turns out to be wasted. (If you actually do deliver what you promised though, it's your turn to have a right to get a positive response from them.)

Public Alphas and Betas

Alpha and beta versions are by definition unfinished and should in fact never see a release to the general public. Looking around in the Unreal modding community you could almost think exactly the opposite was true, though: Mods are in "public beta" stage for years, and mostly without an actual release on the horizon too.

Quoting somebody else [1]:

 ; Alpha : Software undergoes alpha testing as a first step in getting user feedback. Alpha is Latin for "doesn't work."

; Beta : Software undergoes beta testing shortly before it's released. Beta is Latin for "still doesn't work."

So you're releasing software that doesn't work? If you are, do yourself a favor and do it to a limited test crew that's steeled as to what's expecting them. Saying "But it's just a beta!" in a hurt (or annoyed) voice to end users that bicker about your bug-ridden beta version isn't going to make anything better. Besides, end users are notoriously bad bug reporters – if you'd like to get useful bug reports, you can brief your beta tester crew, but you won't succeed in doing that with a mob of end users.

In fact, most of the time developers seem to misunderstand what "alpha" and "beta" actually refers to. "Alpha" and "beta" are indicators for a release's quality, not its completeness in regard to what the development team envisioned as the ultimate goal. (Note: That's to be differed from the notion of feature-completeness. The latter is subject to what you defined to belong on the current release's feature list.)

It's very understandable that development teams, especially those not expecting any other revenue than (positive) user feedback, are yearning to get their product out as soon as possible. Cutting the mod's quality is certainly an ill-advised choice though. If you see that you can't complete your mod to the full extent of what you envision it to be in the timeframe you want to keep, take smaller steps: Define subsets of that full feature list that make sense on their own. If you plan a Total Conversion (see above) with five game types, you could restrict a first public release to a single game type. But make it work in a quality as if it was a mod of its own.

When you begin writing a mod you should start small. Don't plan to write a Total Conversion from the very start. If you set goals that are too hard to reach, you'll get frustrated in the process of working towards them. It is much better to set a series of small goals and work to each one in turn. Start with a simple idea that could be expanded into a larger game.

Always work on small, managable chunks that could each be released in their own right. If you do undertake a large project, organize your features into a release schedule. If your game is going to have five new weapons, make a release with three while your work on the others. Pace yourself and think about the long term.

: Brandon Reinhart, Mod Authoring

Those intermediate releases deserve an alpha and a beta stage in their own right. There's no need to label the finished intermediate releases "beta" when they aren't. It's perfectly possible to make them just as feature-complete and bug-free as any other release. Time you spend making intermediate releases post-beta quality won't be lost when you continue working on your larger goal.

In any case, if you release intermediate versions, make them quality and don't call them beta.

Related Topics

RegularX's ModSquad column:

ucc make (1.4): Patching the Beta

ucc make (1.5): Fixing "Patching the Beta"

Comments

Mychaeel: My intention here, as stated above, is trying to find out whether my stated notions make sense or not. If they do, I strive to present them in a kindly, reasonable way that doesn't make anybody who's reading this feel as if I was saying "You're an idiot for not doing it that way." – I'm obviously stating my own opinion here and am not likely to feel offended by it, but what do other people think – from a user's and a developer's point alike?

Tarquin: They make sense to me. A very valuable addition to "never join a mod with only a website".

Mychaeel: Thanks for your opinion. I had to get this off my chest sometime...

Tarquin: okay, two criticisms about this page: it's too cleanly structured to be a ramble & it's too rationally thought-out to be a rant ;)

Mychaeel: Damn. Gotta practice harder rambling and ranting.  ;-)

EntropicLqd: Good page. Very well written – I can hear the restraining chains in the background though :). About the only thing I'd be inclined to add is that if you do release intermediate versions give the packages their own release numbers (e.g. CTFPlus100.u, CTFPlus150.u). I wished I'd done it after I wound up with 4 seperate versions of the mod on my HD and the only way to tell them apart was buy looking at the CTFPlusGame.uc file - duh!

Birelli: Yeah, very nicely written Mych. Some of the things you pointed out kind of shaped into one statement my general feelings on things like alpha/beta releases and especially responses to critics. I witnessed the utter disaster that EV:Nova was (a mac-only game from Ambrosia). I saw a lot of "do it better" responses from the development team, which was assaulted by an angry mob of disappointed fans who had been being hyped up about the game for years. I didn't end up buying the game, and have never regretted the decision, as the game needed a lot of work that the development team wasn't willing to admit it did and the public was bashing them for not doing. Basically, the largest revenue source of a great gaming company was dashed because the developers they hired didn't follow these rules, so nice writing :-)

Tarquin: Completely unrelated, but it's an equally well-written set of sensible guidelines that many people don't follow: Mac osX commandments: http://www.panic.com/audion/rights.html (nice screenies too)

Anonymous: This is almost a list of all the things Team Orbit did / does wrong. Don't quote me.

Dante: Very good. But I don't share the same opinion with alpha/betas. Even if "they" meant something else, they are even published by commercials. If you make a mod and your final product will take a looong time, but you want to hand something out earlier, a "beta" stamp does fit very well. People will understand, if they find any bugs. But if you didn't test it enough ( and so, almost always ), and you say it's 1.0 - and people find bugs in there, they won't be as forgiving. I remember, when I worked in Front Line Assault ( 2001 ) and the team was small, and developers were rare ( as they still are ) - we finally published an alpha. That was, because some members were lazy, some had too much RL. It was really crap, much bugs, and netplay ( omg I'm ashamed I did it ) was uhm - nm ;) But the point is, that all people who have spoken too me said "Yeah, it's buggy, but it's really cool for an alpha". We also got reviewed, and got a good rating. So I would suggest, only release things non-alpha/beta which really fit your design doc and don't have much "known" bugs.

Mychaeel: My basic point is: Don't publicly release buggy software. Never. For me, as a developer, that's a matter of professional attitude; and for me, as a user, it's something I simply expect from developers with professional attitude. An annoying bug doesn't get the least bit less annoying just because the developers said "it's just a beta."

Dante: Don't release buggy software, that's impossible ;) Today, I share your opinion. But, I think, better have an annoying bug than no game at all. If you have the resources to finish a project off, then you should finish it before releasing it. But if you don't know if you can finish it as you wish, and people keep beggin for a release, it's very hard to say No.

Mychaeel: Public alpha and beta releases are the equivalent to websites with "Under Construction!" signs everywhere.

Dante: There's a big difference imho. "Under Construction!" means Dead. You maybe don't like public alpha and beta releases, but it's still a lot of work to get there, and it shows that you've done something.

Mychaeel: "Under Construction" doesn't mean "dead," it means "prematurely released." (The fact that things that are released prematurely frequently never get completed is a different matter.) The very idea of having an alpha and a beta stage is to do quality assurance before the product is publicly released so that it can be of high quality when it is released. Publicly releasing alpha and beta versions completely defeats the point of having them in the first place. If you have an alpha- or beta-quality product and release it publicly, it doesn't become a "public alpha/beta version" but a "release version with alpha-/beta-quality." I have yet to see when a premature release of a product, especially a highly anticipated one, yielded anything positive at long sight.

Dante: Even if I don't like it, but - Counterstrike. It had tons of betas, and IIRC many bugs in it's first stages. But now it's played by most of the community. Yo, I've really tried to tell them that CS is shit (j/k I would be dead afterwards)

Mychaeel: Alleged third-party authority makes a bad argument. I'd rather say that Counter Strike is popular despite being initially released with tons of bugs, not because of it. For that matter, look at CSHP and UTPure – they're still labeled "Release Candidate," even though they're most obviously released already. It just makes no sense.

To me, releasing alpha or beta versions can mean either of the following things (or both): The team didn't bother with making their product release quality before releasing it; or they're using the alpha/beta label as a shield against user feedback. "It's just a beta." Or: "It's pretty good, for a beta." Releasing a product as a public alpha or beta is something a mod team does solely for its own sake, not for the users', and it's entirely unrelated to the actual notion of the alpha and beta stages every good product goes through (just not publicly).

Dante: I didn't say that it's so popular because of it being released as beta initially. And you wanted an example, so my arguments fits in really good. Yes, mod teams, which release betas etc., do this for their own sake. Calling something RC and publishing it is wrong, there's where I share your opinion. But still, releasing a public beta is different.

I on my own think of a beta, as a snapshot of their actual development. Of course a public beta shouldn't be too buggy. But if I like a mod, and the developers say "Hey, we could release a public beta. We got most of the bugs we found out. There's only one bigger thing: you'll need to rejoin after each round. Should we fix all bugs and release later instead?", I wouldn't open my mouth and say "go on, fix everything, I don't want it now"...

Mychaeel: Without continuing this discussion much further, I'd like to remove everything from it except your first statement; this is, after all, a "Comments" section and not a "Discussion" one.  :-) Any objections? We can carry on with this discussion somewhere else if you like. (Besides, a Wiki isn't the ideal place for such discussions anyway.)

capt. k.: grrr. I had this big long comment all written up and ready to post.  :P

Mychaeel: If it's a comment relating to the article, feel free to post it.  :-)

Dante: Nevermind, just remove it. I'm still happy with the overall Etiquette.

ExTReMe: My favorite phrase: My software doesn't have bugs. It just develops random features :)

Aphelion: I think this article is very good. However, it seems a little hazy in regard to talking about prereleases. The impression I get at times is: don't release anything until you're finished" while at others it is "if you do release, never CALL it beta or alpha" with some qualifying remarks and an injunction never to release at least very buggy mods. Firstly, this seems a bit confused to me. Secondly, it doesn't really deal with people who want to play your mod from the word go and want to see what you're doing in bringing them this mod that, they hope, will fufill their expectations once it is complete. I saw a lot of this in Unreal Fortress, a conversion mod of the fortress gamestyle where people were openly wanting a UT Fortress mod and prepared to take time and effort to get it.

Mychaeel: It's a bit of both, actually. Firstly, it seems to be somewhat fashionable among mod teams to call their releases "betas" without thinking much about that; even if they were actually able to release a full-fledged, high-quality, bug-free product. At the same time this attitude makes them procrastinate any decent quality control (that a beta stage should take care of, actually), which results in low-quality "public beta" releases for no other reason than that the team simply couldn't be bothered with actually going through a beta stage. (A beta stage doesn't sound like fun, I know.) And people who want to play buggy mods should be (internal) beta testers. There's really no need to subject everybody to that.

Mychaeel: Have a look at this posting of mine over in BuF. I'm trying to explain the importance of internal beta testing there.

Jesco: Err, Mychaeel, you never had latin in school, did you? Or ancient greek? I could live with the explanation of 'alpha' and 'beta', but they are greek letters and no latin words, man. :p ;)

Mychaeel: That's a quote, Jesco (see the sentence before). I'm also aware that "alpha" doesn't, in fact, is properly translate as "doesn't work."  ;-)

Dante: I might have explained myself above a bit wrong... But I still think "alpha" works fine for "many bugs, don't release". It's just a subjective opinion of how to call your internal version. And I still think releasing a beta is good. Again, it's just your own decision if you call it beta, demo or whatever. But, and that's also right, you should never release anything with known bugs. I, and most players, except beta's to miss some things of the "final" version. ( In the case of UT2003, which I consider beta/demo, the redeemer ie. ). Of course bugs in any public version are the way to death of your mod.

You: I wish to argue with the above Beta argument as well. IMO, an alpha is strictly internal, it is used for any piece of code which compiles, but still has several (sometimes hard to find) logical bugs. After that, a Closed Beta should be administered to a test audience (mostly the developers, but other peopel too... sometimes developers subcosciously stray from behavior that would break a mod). After the closed beta comes the Open Beta, where it is practically a demo. Any problems that users encounter at this stage shoul dbe taken to heart, and revisions should be frequent/etc... The reasoning behind this is that there are several bugs that you won't be able to find with a small test group, or subtle flaws in gameplay issues that you may disreguard, but others find annoying. A good example of this is the "Fatigue" system in Counterstrike... It was a novel solution, and it *did* work, but was quite annoying. I heard that they recently removed it because of that.

Githianki: Mychaeel is perfectly right to criticize modders who think that software is beta because they have 5 out of ten eventual "planned" features implemented. In the modding community Alpha and Beta are pretty loosely used terms, but there are more precise definitions (which vary from company to company :)). I have even seen a misuse indicating the user thought that Alpha was a higher degree of completion. I guess this was based on believing Alpha is 'higher' than Beta in the alphabet. For most companies, Alpha means feature complete, with all features locked down, placeholder art/sounds in place, and all levels/quests playable. From there it is on to testing and optimizing and putting in final assets. This is in fact how several developers have described alpha and beta in various interviews and articles.

I think that Mychaeel has laid down some good advice on this page and in others. It should be made the basis for a set of open pages on the subject (respecting that these are Mychaeels's opinions and he wishes them to be labelled as such).

Also, I made an edit to fix Brandon's name (Reinhart not Reinhard).

AlphaOne: I just want to say that I've downloaded your bot spectator mod. The thing that amazed me is the fact that you've included a directory structure in the zip file. It's so much easier to install the mod that way. When installing other mods I sometimes confuse .uax with .usx. Great job! To others - include a subdirectory structure of your mod in your zip file!!!!!!!!!!!!!!!!!!

Spark: I completely agree... Coming from the Quake world, it amazed me how lazy most Unreal developers are when it comes to packaging their mods and maps. I could barely believe my eyes when I downloaded a popular mod and read "installation instructions", telling me where to place each of a plethora of files. This isn't 1998 anymore, users should (allowed to) be lazy, not developers. :)

Mecha: Strictly speaking, that's the entire point of a UMOD file–to autoinstall everything for you. I thought I heard they had some teething problems when UT2k3 was released, but Wormbo's seem to work OK, so there's no real excuse there anymore.

Mychaeel: ...just that some people still don't have the latest patch installed, still aren't entirely comfortable with them and there still are a few subtle bugs happening for people using other language localizations than the default international one. I will always provide a plain .zip distribution even if I make a .ut2mod installer as well, but for something as small as the Spectate Botmatch mutator I felt making a .ut2mod installer was more hassle than worth for everyone.

Chazums: A very interesting piece and i igree with pretty much all of it, although i feel that the mod comunity has effectily re-defined the term Beta as something related to time. Purhaps you'd like to add something about using release candidates as an alternate method. Something else that would be good etiquette would be organised version numbering so users know what sort of update to expect compared with the last version.

ZxAnPhOrIaN: Err.. that was twenty cents, not two cents!! :P

Piglet: I can appreciate your want to close down this discussion. However i cant help but add my views. Pesonally i agree with the definition of alpha versions, and agree that there release is normally a very unwise thing to do. However i disagree with your views on beta. If alpha means 'Doesn't Work' then i feel beta should be defined as 'Nearly Works'. In short whilst alpha's should never be released, beta's should be considered for release. If a beta isn't ready for partial release then it isn't a beta yet, it's still a beta. Just my views, but hey :)

Mychaeel: I've had some time to think about my stance on that since I wrote this article. I think what actually bothers me when I see a mod team releasing a "public beta" is the following: Too many mod teams use the term "beta" for indefinite lengths of time to avoid having to tackle the more annoying parts of development (such as fixing bugs) and as a shield against criticism – "Hey, it's just a beta!" On the other hand, a serious limited-time public beta is fine with me, provided the software really is in beta stage already and the team doesn't sell its public beta to the general public like an actual release.

RegularX: There is no real difference between a beta and a release candidate other than with an RC you are making the guess that it might be production worthy. Public Betas/Demos/Previews are also pretty much the same thing. It's an agreement that someone gets to look at an early version, but knows it's not necessarily production code.

As Mychaeel is saying, it's not kosher to just continually release betas, particularly to form the response 'Well, it doesn't work right because it's beta'. And if it is a beta, or a demo - then label it clearly that it's a beta, or a preview, or a demo. When someone sends out an news blast three times in as many weeks, that mod release better not be a preview. Likewise, when I download something and end up say, falling through a map three times in my first dry run of it - don't call it ready for the public.

Basically, beta is a stage in development - not an excuse.

MadNad: I just wanted to mention that I used an alpha test to catch early bugs in the multiplayer code, however, this alpha test was not a public test. I ran a private beta test later...accomplishing the same thing. When I finally did have a public Beta test, I had removed most of the bugs and gotten the gameplay about where I wanted it. This test was to get feedback and to test the MOD on a server loaded with people. Again giving me a better understanding of what the public wanted to see in my MOD, and what sort of requirements I may have to specify for running the mod.

They were very beneficial to me, but I was very careful not to let it out too early giving everyone false impressions of what the final version will be.

Mychaeel: ...and I hope this public beta was soon followed by a release. Was it?  :-)

Mozzie: Great Stuff! I'll go post a link to on my Mod's Development Forums... And whats a Good way to Recruit people when you have NO product, my Team is 3 people, Mapper/;write (me), A Writer/Voice Actor, and a Webesigner/Quality Control.. AND NONE OF US EVEN HAVE THE GAME YET!! (U2) How the Hell I'm a gonna Muster Support? ITS SO CONFUSING! >:@ Nice Page MyChaeel.

MadNad: Yes, it was released after about a month and a half after those tests. http://planetquake.com/excessive I released it last Sunday 2-23-03.

Koosh: I think alpha means "It works, but it has bugs" and beta means "There aer few if any bugs, and we want your opinion" and a numbered release means "We showed it to people and they liked it.

Mychaeel: See? There's the misconception. "Alpha" and "beta" have fixed meanings. "Alpha" means "feature-incomplete," and "beta" means "feature-complete, in testing." Since testing and bug-fixing is nothing end users should ever be subjected to, beta versions should never be publicly released unless the public is made very well aware that they're dealing with program that hasn't been thoroughly tested yet.

RegularX: Alphas are intended to test out basic gameplay ideas. They are buggy, incomplete and evil. Anyone playing something marked "alpha" should know they are buggy, incomplete and evil or walk away from playing/testing them. Betas are also buggy and evil, but are supposed to represent what the game is actually going to be. I then actually distinct between beta and a Release Candidate. An RC should be innocent and good, but maybe have some hidden bugs. Semantics aside (since nobody understands the terms anyway) - I think the moral of the story is to test the (expletive) out of your stuff and don't expect your players to be so wowed by a fancy model/skin/weapon/HUD to excuse the fact that they just fell through the floor of your map and into the void of BSP.

Foxpaw: There certainately are a number of various conceptions of what alpha and beta mean - it seems to be fairly agreed upon that alpha is an early "proof of concept" kind of stage, not feature complete but enough to tell if the game is going to be fun or not.. Beta seems more debated, I would say that a beta should happen directly before a release and should have no known bugs - simply a stage to try to find any bugs that may have been missed by the alpha testing group. (Like the duping bug in Diablo - this was probrably not apparent to the programmers, and is the sort of thing beta testing is intended to find out about.) That's my definition anyway.

Mychaeel: I'm simply fed up of mod developers not even wanting to get past "beta" with their mod. Instead, they think as soon as they have reached something they can call "beta" they're ready for a grand public release and it's time to focus on a new version of their mod instead of finishing this version first.

Draconx: I like this quote: There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Mysterial: Re: the uninstaller, not only should they PROVIDE an uninstaller, they should TEST the uninstaller. Especially with convenient and automated (in theory) uninstallers like the Unreal one for UMODs a lot of groups don't even bother to test it to see if it works. I've lost count of the number of uninstallers that either a) failed to actually delete anything, b) left files behind, or c) deleted too much and took files required for other things with it.

Mychaeel: You have a point. Then again, a mod team should test everything before releasing it.  :-) (Sadly enough we both know that isn't true, especially given the number of alpha- and beta-stage mods that are publicly released.)

Dirk Fist: I agree with Mychaeel, No matter how you try to define it BETA means NOT DONE. And Releasing something with a BIG RED NOT FINISHED on it is just wrong. If its solid enough for release then its version 1.

W0RF: Two shining examples of this kind of behavior in the community:
Apocalypse Weapons is a great example of why you shouldn't release early beta work publicly. The first beta of Apocalypse Weapons was the first mod / mutator in the history of ModSquad to actually receive a rating of 0. That's right, 0. It was that bad. Subsequent releases saw marked improvement, and by the time it got to around beta 5 or 6 it was one of the best weapons muts available for UT. So at least it had a happy ending. But any mut that receives a zero isn't erady for public consumption, and there's really no reason to submit the same mut to a review site seven times.

Jailbreak was the polar opposite. It was constructed in a modular fashion, so it could be completed (and tested) in pieces, it's extraordinarily well-documented, and oh yeah, it's one of the most popular gametypes ever. And I'm not just saying that because it's Mychaeel's project.  ;)

Ryan: Mychaeel is absolutely right in this article, it's not fair to expect people to put up with shoddy work. Missing features are one thing but bugs are another. The audience for mods includes the casual gamer as well as the script master general. To widely release suggests some level of completeness, at least not obviously bugged. The cry of "it's only a beta" cuts no ice. Either the developers knew of the bugs or they didn't. If they did, shame on them. If they didn't accept it and fix it.

For perspective, I'm a total newbie modder. My background is commercial software for financial institutions. I'm just coming to the end of a very long (18 month) beta trial of a system I wrote with a client. They've found bugs but they knew what was going on and are very supportive. In the end it all goes back to audience again. The system will not go out for general consumption (other banks) until we're all satisfied with it.