Properly labeling the release quality level of your mod

正在查看此主题的用户

Has anyone else noticed M&B is seeing more mods lately that don't have very good descriptions at what level of development they are at? I know for anyone thinking of downloading the maker's mod this is going to be frustrating.

Normally software uses a path something like this:

.01-.30 pre-alpha testing - The birth stages of development. This is almost always nearly unplayable as a real game, the developer still needs to finish major structural work. Generally this shouldn't be released, but if it is you should expect to need to extensively document what you've done so far so people can figure out what it is.

.30-.45 alpha testing - This is another large step, the point where many features and ideas are starting to be honed down to their final form. It should be playable, but no one should expect good quality play yet.

.45-.95 beta testing - At this point, the majority of the balance and gameplay needs to put into good playable form. Features should not be added anymore, it's the time to perfect the ones that were chosen, not add tons more or the development will become unstable. By this point the game should be clear and understandable on it's own, you shouldn't need to explain what you've done because it will be evident.

.95-.99 release candidate - This should be a chance to iron out any bugs before the game is announced at finished.

1.0 final - This is a finished game. It shouldn't have any bugs left, the gameplay should be balanced and ready for someone to play a full campaign.

I think mod makers should try to be honest and stick to an accurate rating for your releases. Why? Well, if someone downloads something that's pre-alpha testing and you called it "My Mod 1.0" people won't trust you in the future, and think you don't know what you're doing. In short, you alienate your audience if you don't take the time to explain what your mod is accurately. First impressions are important, so don't put something up with so little description and such a final sounding name that people think it's fully playable and polished. The less you've done, the more you'll have to explain how it works and why you're releasing it.

Here's a wikipedia entry on development paths that says similar stuff basically: http://en.wikipedia.org/wiki/Alpha_release#Pre-alpha

Hopefully this was helpful to some modders. This is a great modding community, and my suggestions here are just to help your community better follow your work and not become confused or frustrated.
 
Not a bad idea.  I actually plan to try and understate development level when I finally make some releases.  Then move up according to real level based on feedback.
 
Yes most mods are kind of disorganised like that, but hey, its up to the modder to call it whatever version he wants, even though most mods shouldnt releas so many alpha versions, just a beta for bugtesters.
 
yeah, there aren't really any official guidelines, so i don't think they really need to follow rules. the best way to seeif a mod is worht playing is to try it out. worst case scenario, you've lost some time in your life. but forcing modders to abide by specific standards would use their time, and they shouldn't have to. they're providing a free service, so my mentality is to be happy wiht what you've got. sorry if that's too harsh, that's just how i see it.
 
If you want your mod to be taken seriously, go by those guidelines. They are clear, understandable, and intelligent. I, for one, will not download a mod if I don't know what it's about, how complete it is, or how well done it is. Judging from the listed downloads on mbrepository.com, other people feel the same. The poorly documented mods simply don't do as well.

However, if you are making a minimod or just don't care enough to release a quality mod, do whatever you want.
 
Or you could use the major/minor/misc system, which it looks like Armagan does (i.e. first digit is release number, usually 0 for unreleased, second digit is minor release number, indicating major additions, third digit is miscellaneous changes, i.e. bugfixes, spelling corrections and similar).
 
In general, I think that would be good to keep some conventions in mind. Release versions are going to be a little different for mods than for commercial software, however. Most of us are not doing this to have a final production (1.0) that will be sold. Rather, modding is a hobby -- we'll work on it, get it to a stable level, then add some new features, rinse and repeat. Consequently, I think it's reasonable to find major new features added at 0.7xx +, while a 0.4xx or 0.5xx mod might be a perfectly playable game in its own right. M&B itself also seems to work this way.
 
So what is the measurement this numbering is following? A released mod with a gun in it will be v1.0 if the mod is called "Gun mod", but maybe v0.01 if it is called a "James Bond mod". The "Gun mod" with two guns might be called "Gun mod v2.0". As I see it, it is an approximation to the amount of completion, so 1.0 is 100% finished, while 0.4 is 40% finished. My point being that version numbers doesn`t really tell much, apart from telling versions apart from each other. Especially since most mod projects neither have a real defined project plan, deadlines, a large team or a full description of the finished product. They should of course all include brief or detailed decscriptions of what`s inside though, what it adds to the game for a player.
 
With the major/minor/misc system then you get a rough idea. A major version increment would indicate that everything promised to be in the mod is in (i.e. the mod is 'finished'). Minor version increments indicate progress towards the final mod. For example, if you added in town capture, which was stated as a goal of the mod, but had yet to add in the new factions you'd said you'd include. Misc can be anything, from bug or spelling corrections to adding in a new quest or two (i.e. something you didn't state would be in the mod).
You'd use the same to go from 1.0 to 2.0. For example, if I complete my mod with town capture and two new factions, I then decide to add in another faction and sieges. You'd put them in (increment the minor version number when the faction was in but sieges weren't, for example) then increase the version to 2.0.

With an incremental system, then the player can see straight away what they're getting - Minor increments mean you've added something new, misc increments is more of a bugfix or possibly minor additions (for example, you've added one or two new quests, but otherwise the mod is the same as the last version as far as the player is concerned). For an example, if I had implemented all of the support code (that which the player won't directly see, but is necessary to add in the new features) then percentage wise I may have went from 20 to 80%, however if all the player sees is a couple of new quests and some weapon additions they'll be wondering what the hell happened. Conversely, if I release 0.0.8, then they'd understand that (as far as they're concerned) only a few minor changes have been implemented.
 
Pellidon 说:
yeah, there aren't really any official guidelines, so i don't think they really need to follow rules. the best way to seeif a mod is worht playing is to try it out. worst case scenario, you've lost some time in your life. but forcing modders to abide by specific standards would use their time, and they shouldn't have to. they're providing a free service, so my mentality is to be happy wiht what you've got. sorry if that's too harsh, that's just how i see it.

Just to be clear, I'm not suggesting these as "mandatory" official guidelines, more like something you should consider if you want the audience to notice your work. I know a lot of people have been ignoring mods for some time that have poor documentation and grammar in the release notes, because they've already had the experience of mods like these being hard to use, having errors the author didn't explain, and so on. Of course, you're right when you say it's your time and you can release it however you choose.
 
后退
顶部 底部