But we'll get this changed. While trying to get into contact with hundreds of people from the gaming scenes, building new connections and more I learned something, that the geek in my had totally failed to comprehend:
ADOM's version numbering scheme is a problem.
Today alone I had discussions with two potential video reviewers who were confused by the "Prerelease" appendix to the current version number. Not knowing ADOM they assumed that the game was not yet ready and only an unfinished prototype could be reviewed. We had to exchange a couple of mails to get this fixed but the problem is obvious: Many others might not even respond fearing to be exposed to yet another of the countless concept studies and prereleases (especially on Steam) of games that never will be finished. This alone IMHO is reason enough to seriously considering to change the version scheme.
But there is more:
- The current version number does not do justice to the progress of ADOM. I was stupid enough to only change the last version number before the resurrection (1.1.1) to 1.2.0 and never again adjust it. Considering the fact that we have new races, new classes, new quests, tons of bug fixes, the awesome graphical mode and NotEye integration, soundtracks, etc. pp. the jump in the version number from 1.1.1 to 1.2.0 is much too small.
- Jumping to 2.0.0 based on the previous observation also doesn't help as it would create confusion with ADOM II.
- It's very hard to judge if a change warrants a major or minor number and whatever you do - almost nothing can do justice to almost 20 years of history of ADOM (even with one long break).
To a single number.
As I dislike the way Firefox and Chrome handle version numbers (just increasing them by one with each new release) I consider a minor visual change: Not calling the future number a version number but a release number.
The next release number would be easily derived by counting all releases ADOM had so far:
- 23 prereleases since the resurrection.
- 3 releases after ADOM 0.9.9 Gamma 16 (1.0.0, 1.1.0, 1.1.1)
- 15 Gamma releases (0.9.9 Gamma 1 to 0.9.9 Gamma 15)
- 23 releases before that (0.2.0 to 0.9.9)
ADOM R65
And future releases always would increment that number by one.
What do you think?
Why "R"?
ReplyDeleteThis feels like quibbling, but if we're instituting a permanent change in how the game's going to be seen by many people, let's quibble.
More common would be V for version. I would recommend U for update -- an "update" has connotations of improvements after it was completed, which is closer to what ADOM updates are.
To me, saying ADOM gets an "update" feels more appropriate than getting a new "release" which seems more like something in the unfinished beta phase of production.
I can understand this. And it's probably better to be more understandable than using some letter nobody will understand. Good point.
DeleteGreat idea!
ReplyDeleteI'd say it tells absolutely nothing, just like the Firefox/Chrome new numbers do. Personally, I like the good old 1.major.minor scheme. 1 will be there forever, major should increase with major ;) content changes (like Ice Queen level, new races, etc), minor for minor changes and bugfixes.
ReplyDeleteI think this way it's easy for you to communicate new content: hey there's 1.3 now come see what's new! Whereas R65, R76, R125? Nobody knows what does it mean without reading the changelog.
Also, with this scheme I think nobody sane would expect you to keep savegame compatibility between majors :).
If 1 is forever, then we can drop it, can't we. It doesn't carry any meaning anymore. Particularly not for new players.
DeleteAnd I would argue that it tells something: The exact point (version / release / update) of the game you have. Nothing more, nothing less.
DeleteBeing a computer scientist I love major.minor.revision, too, but basically it also doesn't tell anything. The current versions of ADOM are a simple proof for that. The changes are sweeping (larger than anything since 0.9.9) and yet we do not move forward at all. It's completely crazy right now if you think about it. Besides an emotional value.
Well 1 means ADoM 1, as opposed to ADoM 2. Which is 0.3.2 or something... Now that's confusing. Then again, naming it 2.3.2 would mean it's better than 1.2.0, while it most certainly isn't at the moment. Should have stuck with JADE ;).
DeleteAnd yes, ADoM version numbering is completely crazy and always was (0.9.9 gamma 16 prerelease 3? :D). But maybe it's time to change it to something less crazy?
As I see it, current version numbers (1.2.0 prerelease xx) are meaningless. What's the difference between pXX and pYY? No idea, need to see changelog. If you change them to ADoM RXX, they still won't say anything, just in another (more aesthetically pleasing?) way. If I play R65, take a break, come back to see R72, I have absolutely no idea what does it mean. Was there a lot of new features added? Was there a lot of critical bugs so new releases had to come quick to fix them? Now, when I see that I played 1.3.0 and now it's 1.5.0, I know there was new stuff added. But if I see 1.3.12 instead, I know there were only minor changes and/or bugfixes. That's for me the only argument to stick with 1.x.y. Otherwise, it doesn't really matter :).
Admittedly it might be nice to have an indicator of "major / minor" change. Although the current numbering exactly does not indicate that. And actually never has for ADOM since 0.9.9 times ;-)
DeleteIf we were to have the discipline to differentiate between pure bug fixes and feature releases it might be useful to go to a "major.minor" scheme with minor changing for bug fixes and major changing whenever something new is added.
Maybe Steam will force such a more controlled development speed upon us although I personally would hate that.
Clinging to major.minor.patch IMHO only would make sense if we had a definition of what a major and what a minor change is.
For me:
- new classes => major +1
- new races => major +1
- new major map system => major +1
- new corruptions => minor + 1
- new monsters => minor +1 (if less than 10 or so)
Still ADOM currently would have to be something like 6.5 or so. And with major changes wiping out minor release numbers this whole thing again becomes very meaningless. I mean: "How big is the difference between 1.15 and 2.0 compared to the difference between 2.1 and 3.0?"
The longer we argue about this the more convinced I become that the whole major.minor.patch thing is totally stupid. Although I clung to it for like 20 years.
But it doesn't say anything, it doesn't mean anything and it just pretends to provide a precision that simply is not there.
So Google and Mozilla probably were right to change the numbering scheme. At least the new approach ends all discussions about whether something is a minor or major update. Probably a big time saver in organizations of their size ;-)
Well I'd agree with your definition of major/minor here, for what it's worth. Then again, jumping upto 1.6.5 so fast could be confusing indeed.
DeleteAnother possibility is milestones, as you were/are planning with JADE/ADoM2: ranged combat in 0.3, magic in 0.4, etc, etc. So, translating this to current releases, I'd say: adding 2 new races and classes would be 1.2.0, with following releases being minors. Ice Queen would be 1.3.0, and we're currently at 1.3.2. Next milestone, I'd guess Steam? is 1.4.0, anything before that is 1.3.x.
And personally, I hate these new Mozilla/Google version numbers. Few years back, I used to know where I was at. I used to know when to pay attention (version update or major update, check what's new!) and when not to (eh, bugfixes, ok I guess I'll install them). Now? I feel absolutely powerless and stopped paying attention at all. My FF says it's 28. I guess it's fine, as long as it allows me to write this message ;).
How's this for a compromise: Whenever a "major" change is made, it's ADOM Release xx. Whenever a "minor" change is made, it's ADOM Update xx.
DeleteEither way it still increments by one each time, but if someone was debating updating they could remember a rule of thumb along the lines of "If there are no new releases, it's not too important to update." (Also, should probably keep somewhere listing "most recent release" somewhere visible for people to check against.)
More complicated than using one word, but it does maintain a semblance of the old major/minor system.
My gut reaction to R65 is that it's aesthetically unpleasing.
ReplyDelete"ADOM: R65"
Doesn't have the same appeal visually to me as:
"ADOM 1.2.0 ..."
But I understand the problem.
Seems to me you've had four major phases of development. Given that, I would suggest something akin to breaking down the past releases into their major development cycles using the following format: ADOM A.B.C (where "A" distinguishes between ADOM I and II, "B" denotes which release cycle it belongs to, and "C" which number in the release cycle it represents.
So, the current release is labeled ADOM 1.2.0 p23. It would become ADOM 1.4.23. The next release being 1.4.24.
Maybe with the release of the steam version it could switch to 1.5.
Another neat idea would be to give it a release ID based on date of release. This would turn 1.2.0p23 into ADOM 1.05.10.14
Just some thoughts.
It would be
DeleteADOM R65
and not
ADOM: R65
;-)
I think ADOMR v65 will be nice. %)
ReplyDeleteI'm a fan of the Ubuntu-style date numbering scheme myself. But you should always put year first, so it sorts correctly in lists if you use it.
ReplyDeleteADOM 1.2014.05.29...
If that's too "non-mainstream", I would stick with 1.4.23 as James mentions above.
R65 is useless, as Qui says...
I'll second these ideas.
DeleteSorry, but that's unacceptable. What's the real usefulness of all that numeric garbage? Nothing at all? Who cares if a release happened on the 1st or 2nd of July. It doesn't matter to anyone if there is some number (or name) indicating which release you use. Too much detail without any tangible advantage.
DeleteI mean, you wouldn't want to add the hours, minutes and seconds of the release either, would you :-D ?
Well, I think ADOM 2014 sounds pretty good. And ADOM 1994 does sound ancient :) The only problem is that we probably want more than one release per year, so what about ADOM 2014 July?
DeleteI'll be the divergent voice and say that ADOM R65, etc. is fine with me.
ReplyDeleteI've seen similar, but in general, I'm not a big fan - especially not for ADOM. Why not - as a quick fix - change the numbering to 1.2.. Then the final adom can be 1.3. or something (or whatever, really).
ReplyDeleteWhat about giving each release a name (something like Ubuntu)...
ReplyDeleteADOM Drunken Dog, ADOM Smiling Shopkeeper, ADOM Offensive Orc. (Obviously I suck at creating those names, but you get the idea). ;)
No way. There is no natural ordering. IMHO a very geeky / nerdy / useless approach ;-)
DeleteHorrible. Someone who doesn't know ADOM will think R65 is part of its name and wonder why. Like Blacksite 51.
ReplyDeleteI'd say keep using x.y.z and loose the prerelease number. So, 1.3.1 would be the next step.
Most people don't even look to the version number, except when it's to download the update, so don't worry about it too much. With automatic updates, most people won't ever know the version number.
I must admit that I actually begin to really warm up on "ADOM Update 64", "ADOM Update 65". Maybe "ADOM Release 64" or "ADOM Release 65".
DeleteWill ADOM be an Early Access game? If yes, there's the possibility of having two branches of releases, like some other games do. People are given a chance to opt in the development branch, receiving more updates but knowing that their save games will be broken often too. Those who just want to play, can keep in the main branch, which will be updated less often, so their saved games will last longer.
DeleteAnd people can always deactivate the automatic updates.
How about just call it "ADOM". Who cares about the version number?
ReplyDeleteNew players coming to the game (and that's the whole point of the Steam release, right?) are just going to want to play it, not follow the dev blog and stash away lots of savefiles.
I've played Starcraft II for years and in my mind it's still plain old "Starcraft II" even though it's been tweaked loads since release. Sure, I can look up what patch number it's on if I care, but that's just it: I don't care.
I agree. You always need a technical version number (my Chrome says it's: Version 35.0.1916.114). But if the player does not care about it, just hide the version information in the "about" window, and don't show it at all (e.g. the windows title).
DeleteWe need it to be in a clearly visible place for one reason: Precision of bug reports. Which in turn IMHO forbids complicated numbers. Like the example above.
DeleteExcept if we introduce an online error reporting feature. But that would require Internet and thus probably is not a good idea. As long as we aren't going to be Steam-only. Which we do not want to be ;-)
Why not simply call it ADOM I 2.x.y? (Similar to the versioning scheme used by ADOM II...)
ReplyDeleteThat would be simple and avoid the whole "calling it ADOM 2.x.y would be confusing" issue.
Totally confusing. Try to say it aloud :-)
Delete"ADOM One two point one point one" and "ADOM Two one point two point three". Not understandable.
Just use ADOM build XX, maybe.
ReplyDeleteI can see doing that if build is better than release. But personally I still think that's too much "computer science thinking". 'Normal' people (e.g. non-programmers) do not think in builds ;-)
DeleteMaybe releases, versions or updates.
You could always try changing "prerelease" to "build #" or "patch." Alternatively, drop the last digit (you don't use it much, anyway) and go with something along the lines of "1.2 r24." I always thought of the X.Y.Z version numbering as being straight forward, and some people were just using it incorrectly. I hadn't realized that the incorrect usage had become the norm. 1.X.X means updates to a finished product, unfinished is what 0 is for. ...isn't it? I would want to suggest "development build" but that may carry similar implications to "prerelease." In a world where 1.0 no longer implies "complete product," I'm not sure what would unambiguously say "bug-testing precursor to a major update." This must be why we can't have nice things.
ReplyDeleteTo test this: Let's try to devise an understandable rule set that describes when I am allowed to change the first number, when I'm allowed to change the second number and when I'm allowed to change the third number.
DeleteI now have tried this for like 30 minutes and currently I fail :-)
I think James and Angelo's comments would probably capture the majority view of the game consumer world I've experienced.
ReplyDeleteCurrently my impression is that it captures the computer scientist and roguelike work view.
DeleteAs it did for me for many years :-)
So, why don't we just hide the version number (in the title) and only make it available in the "about" section or as a small number on the main screen? :)
DeleteAnd we could still use the x.y.z scheme, I think the next release should be ADOM 2.0.0. ;)
I certainly saw the (series),(release),(patch number) format used in my years in IT, but the reason it is familiar to average joe gamer is probably years of similar use by Minecraft and World of Warcraft.
DeleteDrop the version number from the name. Call it just adom. Keep the version scheme the same (without any prerelease/alpha/gamma/zeta gimmicks). Show the version in splash screen. Everything is fixed.
ReplyDeleteExcept for the ease of supplying the version/release/update/build number in bug reports and RFEs - which actually is very important for us in order to e.g. differentiate regressions from duplicates from new bugs. So it probably will need to be visible in a prominent place.
DeleteKeep the x.y.z scheme. It's easier to understand when there's major changes between versions, and it's just going to be even more confusing by suddenly changing the whole system.
ReplyDeleteBut I think the biggest problem is that you haven't made good use of the numbering system and have made it confusing by having a second number (prerelease) at the same time. Maybe call the 1.2.0 series done and call the next one 1.3.0, then continue from there with 1.3.1 and so on without unneeded prerelease/gamma/etc complications. Or merge the prerelease number into the standard version number, making prerelease 23 version 1.2.23 (why keep the 0 if the prerelease number has basically the same function?).
If we were to use the 1.2.23 idea we probably would have to introduce a sentient AI to be allowed to change the 1 to a 2 ;-) (when compared to the amount of changes in 23 patch levels).
DeleteA sentient AI would be nice. :)
Delete@John: Noted :-)
DeleteIt's funny, at first I was going to say yeah, r65 sounds nice. The other comments changed my mind. Hide the version number and just call it ADoM, use x.y.z so we(people who care) can still tell where we are. That's my opinion.
ReplyDeleteBut you can't tell where you are. Just look at the difference between ADOM 1.20p18 to p19 (minor changes) and the difference between p19 and p20 (huge list of changes). You wouldn't have known from looking at the number. And where is the line separating major from minor to patch changes. Try to find a definition, especially for major and minor. I currently can't and the more we discuss it the more I am sure that having but one number is the only reasonable way to go.
DeleteI love it how - after weeks of very few comments - a discussion about version numbering schemes awakens the whole blog community :-) Somehow I knew this was going to happen because I'm very emotional (for whatever reason) about version numbering schemes myself :-D
ReplyDeleteAnother interesting observation I currently can't appreciate with certainty: Nobody ever complained about me naming the series of releases "prereleases". Now that I want to change "version" to "release" the idea is not really appreciated. I'm not sure what this means but it's very interesting to observe this :-)
ReplyDeleteNah, please leave as it is.
ReplyDeleteUgh, yet another implementer using these newfangled Infocom release numbers! Just because it works for Enchanter, doesn't mean ADoM needs it! What next? Ur-grues? (Actually put that in, that would be really cool.) Anyway, I have an unverifiable anecdote that says at least 36 people only use ADoM because it's version 1.x and one of them says he'll quit when it gets to about v1.9 or so. It's time to reconsider.
ReplyDeleteFor public consumption, maybe do the familiar consumer software numbers instead of the geek chic a.b.c.d.e.f.g?
ReplyDeleteADOM RC 1 - the public build that just came out (release candidate)
ADOM beta N - prerelease number - 64, 65, 66...
ADOM RC 2 - the next public build
Then finally release ADOM with the final reset version you want. ADOM 1, or ADOM 3, or whatever. This should be much clearer for new and Steam users.
I like ADOM release 65. Or even ADOM (release 65). The version number in most games is hidden away and not nearly so prominent - there's no need to make such a big feature of it.
ReplyDeleteFor a newcomer, ADOM 1.3.xxx would be much better then ADOM R65, because "1.3" means that game is already past the stage where it was "1.0", i. e. released. And even more, it means that the game is supported and is under active development (at least 3 major updates). And R65 may mean anything including early alpha\beta.
ReplyDeleteI'd stick to old good 1.x.yyy, and, btw, when ADoM will be 1.9.xxx and new major version will be added, I would just make it 1.10.0.
My vote is for ADOM v1.65
ReplyDeleteIt lets people know that it is a full game, an improvement over previously released versions, and it's clean. The only potential issue is what to do when you pass v1.99. Personally, I'd just bite the bullet and go straight from there to v2.00 and beyond. Because ADOM II uses Roman Numerals, and has a subtitle, I don't think there will be significant brand confusion.
Bottom Line: So long as the game is still ADOM on the inside, you can call it whatever you want. A rose by any other name still smells as sweet… =]
I guess my solution would be to just continue past 1.99 to 1.100, 1.101 and so on. I don't see any real reason not to do so ;-)
DeleteThe reason I'd prefer "1.99 - 2.00 - 2.01, etc." to "1.99 - 1.100 - 1.101, etc." is that some people, who were unfamiliar with the game, might misread it as 1.1, and think it was a downgrade or an older version that got put up by mistake. Regardless, I imagine it will take a while to go from 1.65 to 1.99, so you could possibly even time it so v2.00 coincided with the 20th anniversary of version 0.7.0 (fast approaching!). That would be pretty neat. :D
DeleteHow about ADOM 1 (to prevent confusion with ADOM 2), U (for update) major.minor?
ReplyDeleteADOM 1, release 65.3. ADOM 1, release 65.42. etc.
You call traditional version numbering geeky, but in its "obscurity," it says a lot more than R65 does. It gives us CONTEXT.
ReplyDeleteEven to someone who isn't familiar with traditional numbering, a shift from 1.2.5 to 1.2.8 means a lot more than a shift from R65 to R71. With flat numbers, I have no idea how different my playing experience will be from release to release. With delimited numbers, I can say "Oh, 1.2.5 to 1.2.6? Probably don't need to download this one" or "Hey, 1.2.5 to 1.3.1! I'd better grab that!"
I'll take complicated but meaningful over simple but useless any day.
well, R65 and prelease 23 are both equally uninformative.
ReplyDeletePersonally I'd rather stick with x.y.z format.
X is probably forever 1 -* and the only thing it is supposed to mean that it is not unfinished/alpha version of game - anyway numeration change is meant to get rid of unfinished impresion, right?
Y probably should be increased with each public release and we should have more of these, IMHO, - that way it means for anyone not in campaign they can get new version. [p5, p18, p23 were public -- so we would be on 1.5.z I guess]
Z should be left for closed releases inbetween public ones.
It is not ideal system but at least has some logic in it and easy to follow meaning on y and z - which is more than most game/program numerations ever had.
Might I suggest a simple but clear notation?
ReplyDeleteIf you have a version number for versions that make notable changes, and simply a letter subscript for bugfix releases, it would make it obvious which versions are which. So if the current release is 17b, and you release a bugfix update to it, it would be 17c. But if it introduced new content, it would be 18a. And don't put it right after the name - it's not "ADOM 17a", it's "ADOM, version 17a". It makes the distinction between bugfixes and new versions clear, while also emphasising how much content has been added (the fact that it's up to version 17 speaks volumes).
Also a very nice one as far as I am concerned.
DeleteThis, this is the way to go! I myself was going to suggest a system with straightforward numbering that would use an appended letter to differentiate between notable revisions and quick updates/bugfixes, but this is basically just it anyway.
DeleteWe all love x.y.z formats, but yeah, I agree they can be a bit baffling to those who have no idea what it means. So, two things to consider here:
ReplyDeleteSteam, for the most part, auto-update games on it (you can tell it not to, but even so, most of the time you let it do its business), whilst direct download can have the version in the file name itself. This may well simplify the bug report issue quickly enough.
From what I understand you're using 'pre-release' as basically just another term of art for 'beta'. Plenty of games have beta-release or 'snapshots' which are buggy "don't expect to play without issue" builds for testing how changes, additions and fixes - and then have proper updates which compile all those small incremental changes into one large complete and fully functional change for major consumption - which is effectively what's happening here.
Things like minecraft and TF2 do this all the time, and have a 'current build' and a 'current beta/snapshot build' - feedback from anything other than the current one is useless really anyway.
The final thing to consider is 'patches', small "oh there was a bug here, and now its fixed" stuff. Which is largely meaningless to the *play* experience, but meaningful for bug reports.
As such I suggest ADOM Update 62 Patch 3 - for the public release, which if inclined can be shorthanded to ADOM U62 P23. For 'internal'/pre-release stuff, just call it a beta build with an extra incrementing number so ADOM U62 P3 B11 is the 11th pre-release change for the current public release.
Each time you release to the public you drop the B (and anything with a B is clearly a test build) and either increment the U number, and reset the P number to 0 or increment the P number. If you need to fix anything between public updates, without adding content, you increment the P by one, to signify minor changes which will affect stability of the build, but add nothing to game play. Each time you add meaningful content change (such as new areas, mobs, items, mechanics, etc) will directly changes the game with visible content, you increment U.
This means you can say things like: In "Update 14 Dragons were a lot easier, as Update 15 added more potent spell casting to all Dragons". However if someone says "When I get a wish at a pool and wish for dragons, the game crashes!", others can say, "oh yeah, that got fixed in the latest Patch, get Patch 11 to fix it - although I hear Update 16 will be coming out next week, which adds a bunch of new artifacts, so that'll fix the problem too".
However - what you have effectively done, is just add easier and clearer names for what is essentially just an x.y.z format, with x actually changing. I guess I'm hard coded to think in such ways now, but it also means those inclined can just call it ADOM 65.3.11 and be happy.
This comment has been removed by the author.
ReplyDeleteI don't think that R65 is the right move. After all, it still have this 'prerelease' taste. I would go for Adom 2.x. Confusion with Adom II is minimal (lesser evil), and can be solved by other means. 'R' is horrible, too. If you need to stick with 65, go for 'v' at least.
ReplyDeleteOr, like Apple did: 'The new Adom' ;)
If you do not want to get back to 1.major.minor kind of versions at least change them to date, 2014.05.31 or something like that. That is still slightly pre-releasey.
Dropping p20 suffix would be good, too, IMHO. If you are releasing 1.2.30 and increase last number quickly, it clearly communicates that we are after 1.x
I see only two real alternatives for version numbering and they can be used both at the same time.
ReplyDeleteThe first is Semantic Numbering as suggested by Tom Preston-Werner, co-author of GitHub (accessed from http://semver.org/):
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Second option is to use positive increments of an integer after the name. This is used mostly in production environments to make versioning sensible for users.
In any case you wouldn't publish your beta/rc/etc builds to Steam but major updates only and possible patches for updates if bugs weren't noticed in beta/rc/etc builds. Small updates are gathered to a larger release which will be released in a sensible package. This can be called Release XY or Version XY or Update XY in Steam even if you use semantic versioning.
So, Release XY is easy for customers and MAJOR.MINOR.PATCH is good for developers and testers why not to use both?
I like the x.y.z scheme. I guess the problem was using prerleases as an extra sub divider on this. One way to sort it could be to look at the releases that have been since the resurrection and decide which were bug fix releases and which were feature releases. So we'd be (at a guess and as an example) on something like 1.10.13.
ReplyDeleteAn alternative I thought would be on the release where save file compatability is implemented skipping the whole 2.x cycle and going to 3.x there's been major changes to the game since 1.x in my opinion this would be catching the numbers up with the huge amount of work you've put in rather than version number inflation. By skipping 2.x you remove any risk of confusion with ADOM II powered by JADE.
third idea, is renaming ADOM II with a subtitle and always using it. So could be something like ADOM II: The Return of Chaos. Or something better :p
Then you could have ADOM use the 2.x scheme without the verbal confusion implied.
I can see why we should drop "prerelease" from the name, but I'm not convinced why a single version number is better that x.y.z. Sure, the 1 at the beginning will probably never change, but it gives us some information - it's not 0, so the game should be in a finished state. It's a bit like vowels in words - they're not essential, but they provide some added usefulness.
ReplyDeleteThat said, I don't mind "ADOM, version/release X" either. But "ADOM R65" sounds like some military hardware.
I think the problem is the word "prelease", In the modern world that has different connotations. It's also not good that you make certain preleases public, confusing what's prerelease and what's just release.
ReplyDeleteSo I suggest renaming the prereleases to something like "trunk build x". Have the actual releases change the version number of the game. So we'd be on something like 1.2.5 now. And make the trunk builds a little less visible to the public. At some point you'll want to stop selling access entirely.
I second the idea of hiding the version number from the player. Yes, the devs do need this number in bug reports and RFEs, and this requires that the player knows how to find it. Assuming that most bug reports happen through the forums nowadays, you just need to put, in the 'Post new issue' form, a text that explains how to find the version number; add the same information to the official FAQ, in the questions about bug reports and suggestions.
ReplyDeleteIf you choose to keep the version number prominent and change the version scheme instead, my vote goes to the x.y.z scheme, and to rename ADOM II to something that doesn't create problems (because one day you will increase the x of classic ADOM from 1 to 2, otherwise, as you commented before, it would be not make sense to have x and keep it stuck to x=1 forever). Tbh, I liked JADE better than ADOM II, but I have to admit it didn't stand out in search engines.
Just make it ADoM 6.5! Then you don't have a permanent 1.x.x version, and you can better reflect the huge changes the have been made in the Resurrection prereleases.
ReplyDeleteThen upgrade the major and minor versions according to your own preferences:
> - new classes => major +1
> - new races => major +1
> - new major map system => major +1
> - new corruptions => minor + 1
> - new monsters => minor +1 (if less than 10 or so)
Each of those changes gameplay pretty significantly. I would also recommend at least minor +1 for quest updates.
You can then keep the R65 if you like as a suffix (e.g., ADoM 6.5 R65, ADoM 6.5 R66, ADoM 7.0 R67, etc.),
go to a more traditional alpha/beta/gamma (e.g., ADoM 6.5 alpha 1, ADoM 6.5 alpha 2, ADoM 7.0 alpha 1, etc.),
adapt the prerelease numbering scheme (e.g., ADoM 6.5 prerelease 24, ADoM 6.5 prerelease 25, ADoM 7.0 prerelease 26),
or something more clever, if the community can think of it.
This solution can't fix the confusion that may surround the 1.2.0 prereleases, but it would definitely cut down on the confusion over how much the game has changed from one release to the next for future Resurrection prereleases.
Once you feel the big changes from the Resurrection campaign are over, and development is more about refinement and bugfixing, then you can just drop the suffixes and revert to a x.y.z schema to reflect that the kind of development ADoM is going through has changed (e.g., ADoM 10.1.1, ADoM 10.1.2, ADoM 10.2.0), and still update the major version if you feel it is warranted ("Oh man, did you hear ADoM 11.0.0 is out? New quests await me!").
End note: Version numbering in the real world is ugly, inconsistent, and misleading, but people have developed expectations surrounding it. Don't just hide your version number because some people will be confused by it (and someone will ALWAYS be confused by it, no matter how hard you work to make it otherwise). Exploit users' expectations to your benefit (and theirs!): you WILL get people excited about the changes that a major version update holds AND fix a longstanding problem at the same time.
I like your idea of a simple number. Like KevinO, I think displaying it as "ADOM release 65" or "ADOM (release 65)" is ideal, because the lowercase use of "release" hints that it's not a part of the game title.
ReplyDeleteIt's simple, it's clear, and it's obvious for those who need to file a bug report. ..and you're right that reviewers won't feel that it's an incomplete game.
Thinks again: I too like the 1.x.x numbering system. But I'm from a computer-science background. I don't think regular people know the difference between a major and minor release.
ReplyDeleteAnd, let's face it, just about every ADOM release is a major one. ..a simple integer release-number doesn't hide any detail that can't be found from the change log. And most of us geeks are checking the change log, right? :)
Something else that probably warrants mention:
ReplyDeleteOverkill software, when updating PAYDAY 2 (and maybe their other games; not sure on them), have two separate numbering systems.
When making public releases and discussing it, it's referred to as Update #XX. Often there'll be an Update XX.1 or XX.2 for very minor changes (sometimes bugfixes don't even get a decimal change), but typically every new update comes with a whole new number. However, the main screen of the game has a more traditional version number: My copy is currently version 1.10.1, and it's Update 29.1.
So it has the simple numbering system for the public, and the traditional major/minor numbering system for internal/technical use.
But big commercial games do use major.minor.revision system too. For Example, according to Google, Starcraft is currently version 1.16.1 and Diablo III is currently version 2.1 (note that III is not considered a part of the version number, so it is "Diablo III Patch 2.1" or something). I think they have these numbers displayed in their main menus or some other visible place.
ReplyDeleteI think having the "1" as the first number is understood that the game is already complete (big games use this too). What is misleading is the "prerelease" word. Actually, I never liked it myself -- in lexicographic ordering adding something to the end can only make it larger, while "1.2.0 pre 18" is supposed to be earlier than just "1.2.0".
Anyway, ADOM is a big special case. Most games are released once, and only small patches happen later. When version number 1.0.0 came out, I thought it was deserved, but the version we are working on will clearly outshine it. And any new player will probably laugh that ADOM 1.0.0 had no graphics.
So, in summary: drop "prerelease", plan a more respectable version number than 1.2.0 for the "final" post-resurrection version.
How about "ADOM 1.2.0 Update XX" instead of prerelease? I dont think ADOM R65 makes much sense, and other games often use the x.x.x scheme, like Terraria.
ReplyDelete