One of the many challenges which Nibbits faces, is the ability to let users find exactly what they want, without them knowing they want it.
However, one very simple choice we can let you make, is the ability to view UMS, or Melee maps. So we're going to be adding this very soon, and it should be able to be detected automatically by our parser.
I wanted to get some feedback from everyone that uses our SC section (it seems we really are the #1 resource now), about how else we can improve the site, and the ability to find maps you're looking for.
hmm, I think one thing I could come up with would be the ability to edit details on your own uploads. For instance I know I made a mistake on one of my map's tags and I have no way of fixing it myself.
New tags for difficulty levels such as Novice, Experienced, and Expert. Could also add Noob and OMGWTF (half joking :P)
Also, I wanted to know if there might be any issue with me uploading maps that aren't of my own creation. I have roughly around 500-700 UMS maps that I've run across while gaming that aren't mine that I could contribute.
Other than those minor things, I can agree, this is the best SC Maps site I've been able to find, no wonder it was the first option after a google search. Thx for making it ;)
Feel free to upload any map you find. Nibbits is dedicated to the open mapping idea, and therefore authorship is only determined by the map parser itself (which I don't think it can do with StarCraft).
To my mind the resource will benefit if you make it more socially directed.
The main tool of grouping maps should be labels. The issule with predefined maps classification (for example UMS and Melee categories) is once defined it could not be easily extended. The idea behind labels is that new groups appear on fly when people find out new common features of maps. These groups could intersect, include one another or be absolutely divided.
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
A more improoved labels seach system should be implemented. For example I want to find UMS maps which are either RPG or Sniper but not Singleplayer. Each registered member should be able to apply new labels to maps. As far as maps labeling is a social task there should be a system of labels ratings. Every member should be able to vote how each particular label fits the particular map.
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
For example one could have three choices: -1, 0, +1. You see, right now the label is either assigned to the map (0) or not (1). All maps which have the same label assigned fall into one category. With a labels voting system you would have a continous scale from 0 to 1 which displays *certanity* whether the map is falling into the category or not. The formula computing the certanity value might be ( ((<number of positive votes> - <number of negative votes>) / (2 * <total votes>)) + 0.5 ) and 0.5 if noone has adjusted the label to the map yet. The search engine should show only *positive* certanity results (when the certanity value is strictly greater than 0.5).
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
Considering automated UMS and Melee detection I join an opinion stated by azala in the http://www.nibbits.com/sc/forums/6/view/71/ thread: >>You shouldn't need to make an automated system to determine whether a map is UMS or not. Map tags are better, because: >> >>1) They have the advantage of generalizing to cover many more categories as well as overlapping categories >> >>and >> >>2) They have worked well in other map databases.
Once more, the labeling system should be the main tool for grouping maps in categories and everyone should be able to take part in this process. One man is not able to group the huge amount of maps but we can do it together!
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
And if one makes a mistake we should not instantly punish him by banning from applying labels further (the resource is only looses from this). Instead of this others simply should be able to fix his mistake.
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
How I see the solution: The wiki-like field named "authors" should contain *those and only those* authors which are specified in the map itself (probably not only in map's description though), or an "anonymous authour" if not specified. Initially, (when the map is discovered) the field should contain "no author specified yet" which differs from the "anonymous author". "Anonymous author" should be used only when the field is edited by a human who is sure there is no author info in the map. There should be a search by the author field and especially search for maps with the "no author specified yet" value to help people wishing to contribute nibbits.
Once more, the authors field contains only (nick)names specified in the map *regardless* they are true or not and filled by humans.
When one wants to report the map stealing fact the proposed "based off" function comes in. I see the "based off" function as some kind of set of relations connecting various map files (I intentionally use more narrow term then the "map"). A map file could be "based off" various map files in different ways, but before I continue with the description of particular types of a "based off" relation, I introduce a *similarity* relation.
Two map files are called "similar" when their terrain or triggers (or both) are similar in common sense. The human's work is to estimate the similarity of map files. Looking forward, unlike determining authors, the maps similarity based on terrain and triggers compairison could be done automatically, but is somewhat more difficult and presents a seperate problem.
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
I am describing different types of "based off" relation now:
-1.0 Two map files are similar, have the same file size but differ *only* by system filename. In this case I say the first file is the *clone* of the second. Obviuosly if one file is the clone of another then the other file is the clone of the first one, therefore this is an *equivalency* relation, which divides all maps on non-overlapping equivalence classes. Everything (except probably similarity) up to this point could be checked automatically by the discovery engine. A similarity in the simple case of two files with the same size is simple, it is just byte comparison of two files.
One particular file should be chosen from each class (by human in case the class contains more than one map) as a *representative*, others should be marked ("reported") as having "inappropriate filename" and thus not appear in the search results. Almost all assosiated content (name, description, authors, votes, labels, comments and threads) except only discovery date, downloads, and thus achievements should be shared between all maps from one class. When someone wants to download a non-representative map file an appropriate notification should appear to prevent spread of map clones. Each clone should contain link to the representative (or to all other maps in his equivalence class in case there is no representative). The representative should contain links to all his clones and moreover this probably should be *the only* way to reach his clones.
-2.0 Two map files are similar, one file differs from the other by the author field in the way the set of the authors of one file does not include and not equal to the authors set of the other file and vice versa. This is the case when editors of the initial map don't give credits to authors of the original work. Though we dont know which file is the *original*, we do definetly know there is something wrong and one of them is the original. So this is an equivalence relation too and such maps should also be connected together in an equivalence class like in the point 1.0. There should be links from each map of the equivalence class to all other maps of the class. The inclusion of the authors sets could easily be checked by the engine when both sets are provided.
-2.1 Unlike from the point 1, maps found in an equivalence class from the point 2.0 are not *equivalent*. We just dont know what map file is the original yet. One can make this yet equivalence relation more exact by specifying the original(s). In case of disputes the editing of this particular "credits" relation could be locked until the final decision is made. Generally having an ability to lock the *particular* wiki-like field of the map in case of disputes seems to be usefull.
When the original is determined, links pointing to the original from the other maps of an equivalence class from the point 2.0 should be marked in one way (to obtain justice), links from the original to his modified copies in another way (to make Otaku108 proud :p), and links between still undecided maps should not be marked like just all other links from the point 2.0.
-3.0 Two map files are similar, but we have inclusion of provided sets of the authors. This happens when the map file was modified. In case the inclusion is strict, after determining maps are similar, we can determine which map is the original automatically. In case sets of authors are equal these maps could be placed in one equivalence class until someone (most likely the author) specifies the original. Also a place for the list of modifications could be provided.
-4.0 The authour could specify maps where he has borrowed the idea of his work. By saying "the author" I imply everyone could change this field but most likely only the author knows this for sure.
Probably others I cant think of at the moment...
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
Dcramer, your map database should definetly have an option to somehow connect the author name specified in the map with a forum account. I suggest divide the problem on two: how to connect the author name specified in the map with the battle.net account and how to connect a battle.net account with the nibbits forum account.
Usually authors nicknames written in maps textually match the ones they have on battle.net or somwhere else, for example on forums (or at least one of them). Considering this I suppose matching the author nickname written in the map with all textually matching names *anywhere*. For example, I write "Map by Wormer" in my maps, thus everyone who has the nickname wormer everywhere is connected with the author name: wormer@games.podolsk.ru, wormer@USEast, wormer@Europe, wormer@staredit.net, wormer@gmail.com for example.
But this matching does not play any role as far as these names are matched with the nibbits account. Matching nibbits account with mail servicies is easy and could be automated. The author names specified at the authors map field on nibbits are linked *only* with those nibbits accounts which are connected to at least some of those names (wormer@games.podolsk.ru, wormer@USEast, wormer@Europe, wormer@staredit.net, wormer@gmail.com and etc.). Thus several nibbits accounts could be linked with the particular author name. They are sorted by "confidence": basically having more such account connected should result in having more confidence, particular rules could be tweaked later.
You can ask, how to connect a nibbits account with the battle.net one? This should be the problem of the one who wants to connect them. Take me for example. After I specify the account wormer@USEast on my personal page on nibbits I can ask you to verify the wormer@USEast account. You send me a password through a nibbits pm message and we agree the meeting date and time on battle.net where I am telling you the password. Once you sure I have a wormer@USEast account you can confirm that near the wormer@USEast account on my nibbits page. More people have confirmed my USEast account it becomes more tightly connected with the nibbits account. Now I can confirm other forum accounts and so on. The same thing is with the forum and other accounts.
I want to point out that someone with the nibbits account sdf112 connected (and confirmed) with the battle.net account wormer@Europe could also pretend on authorship and will display in the nibbits accounts list connected with the wormer nickname specified in the map. The list of such accounts should be sorted by confidence as I wrote.
"I bet at this stage we could code a better Starcraft engine from scratch ourselves. :P" - Tuxlar
One of the many challenges which Nibbits faces, is the ability to let users find exactly what they want, without them knowing they want it.
However, one very simple choice we can let you make, is the ability to view UMS, or Melee maps. So we're going to be adding this very soon, and it should be able to be detected automatically by our parser.
I wanted to get some feedback from everyone that uses our SC section (it seems we really are the #1 resource now), about how else we can improve the site, and the ability to find maps you're looking for.
hmm, I think one thing I could come up with would be the ability to edit details on your own uploads. For instance I know I made a mistake on one of my map's tags and I have no way of fixing it myself.
New tags for difficulty levels such as Novice, Experienced, and Expert. Could also add Noob and OMGWTF (half joking :P)
Also, I wanted to know if there might be any issue with me uploading maps that aren't of my own creation. I have roughly around 500-700 UMS maps that I've run across while gaming that aren't mine that I could contribute.
Other than those minor things, I can agree, this is the best SC Maps site I've been able to find, no wonder it was the first option after a google search. Thx for making it ;)
Feel free to upload any map you find. Nibbits is dedicated to the open mapping idea, and therefore authorship is only determined by the map parser itself (which I don't think it can do with StarCraft).
any word on if we'll be able to edit details on our uploads if we make a mistake?
You can request the changes from me, other than that I'm not sure how I'll handle changes yet.
To my mind the resource will benefit if you make it more socially directed.
The main tool of grouping maps should be labels. The issule with predefined maps classification (for example UMS and Melee categories) is once defined it could not be easily extended. The idea behind labels is that new groups appear on fly when people find out new common features of maps. These groups could intersect, include one another or be absolutely divided.
A more improoved labels seach system should be implemented. For example I want to find UMS maps which are either RPG or Sniper but not Singleplayer. Each registered member should be able to apply new labels to maps. As far as maps labeling is a social task there should be a system of labels ratings. Every member should be able to vote how each particular label fits the particular map.
For example one could have three choices: -1, 0, +1. You see, right now the label is either assigned to the map (0) or not (1). All maps which have the same label assigned fall into one category. With a labels voting system you would have a continous scale from 0 to 1 which displays *certanity* whether the map is falling into the category or not. The formula computing the certanity value might be ( ((<number of positive votes> - <number of negative votes>) / (2 * <total votes>)) + 0.5 ) and 0.5 if noone has adjusted the label to the map yet. The search engine should show only *positive* certanity results (when the certanity value is strictly greater than 0.5).
Considering automated UMS and Melee detection I join an opinion stated by azala in the http://www.nibbits.com/sc/forums/6/view/71/ thread:
>>You shouldn't need to make an automated system to determine whether a map is UMS or not. Map tags are better, because:
>>
>>1) They have the advantage of generalizing to cover many more categories as well as overlapping categories
>>
>>and
>>
>>2) They have worked well in other map databases.
Once more, the labeling system should be the main tool for grouping maps in categories and everyone should be able to take part in this process. One man is not able to group the huge amount of maps but we can do it together!
And if one makes a mistake we should not instantly punish him by banning from applying labels further (the resource is only looses from this). Instead of this others simply should be able to fix his mistake.
Note: this post and the following two posts are also an answer to the thread: http://www.nibbits.com/sc/forums/6/view/84/
I think Wiki approach is the best.
How I see the solution:
The wiki-like field named "authors" should contain *those and only those* authors which are specified in the map itself (probably not only in map's description though), or an "anonymous authour" if not specified. Initially, (when the map is discovered) the field should contain "no author specified yet" which differs from the "anonymous author". "Anonymous author" should be used only when the field is edited by a human who is sure there is no author info in the map. There should be a search by the author field and especially search for maps with the "no author specified yet" value to help people wishing to contribute nibbits.
Once more, the authors field contains only (nick)names specified in the map *regardless* they are true or not and filled by humans.
When one wants to report the map stealing fact the proposed "based off" function comes in. I see the "based off" function as some kind of set of relations connecting various map files (I intentionally use more narrow term then the "map"). A map file could be "based off" various map files in different ways, but before I continue with the description of particular types of a "based off" relation, I introduce a *similarity* relation.
Two map files are called "similar" when their terrain or triggers (or both) are similar in common sense. The human's work is to estimate the similarity of map files. Looking forward, unlike determining authors, the maps similarity based on terrain and triggers compairison could be done automatically, but is somewhat more difficult and presents a seperate problem.
I am describing different types of "based off" relation now:
-1.0 Two map files are similar, have the same file size but differ *only* by system filename. In this case I say the first file is the *clone* of the second. Obviuosly if one file is the clone of another then the other file is the clone of the first one, therefore this is an *equivalency* relation, which divides all maps on non-overlapping equivalence classes. Everything (except probably similarity) up to this point could be checked automatically by the discovery engine. A similarity in the simple case of two files with the same size is simple, it is just byte comparison of two files.
One particular file should be chosen from each class (by human in case the class contains more than one map) as a *representative*, others should be marked ("reported") as having "inappropriate filename" and thus not appear in the search results. Almost all assosiated content (name, description, authors, votes, labels, comments and threads) except only discovery date, downloads, and thus achievements should be shared between all maps from one class. When someone wants to download a non-representative map file an appropriate notification should appear to prevent spread of map clones. Each clone should contain link to the representative (or to all other maps in his equivalence class in case there is no representative). The representative should contain links to all his clones and moreover this probably should be *the only* way to reach his clones.
-2.0 Two map files are similar, one file differs from the other by the author field in the way the set of the authors of one file does not include and not equal to the authors set of the other file and vice versa. This is the case when editors of the initial map don't give credits to authors of the original work. Though we dont know which file is the *original*, we do definetly know there is something wrong and one of them is the original. So this is an equivalence relation too and such maps should also be connected together in an equivalence class like in the point 1.0. There should be links from each map of the equivalence class to all other maps of the class. The inclusion of the authors sets could easily be checked by the engine when both sets are provided.
-2.1 Unlike from the point 1, maps found in an equivalence class from the point 2.0 are not *equivalent*. We just dont know what map file is the original yet. One can make this yet equivalence relation more exact by specifying the original(s). In case of disputes the editing of this particular "credits" relation could be locked until the final decision is made. Generally having an ability to lock the *particular* wiki-like field of the map in case of disputes seems to be usefull.
When the original is determined, links pointing to the original from the other maps of an equivalence class from the point 2.0 should be marked in one way (to obtain justice), links from the original to his modified copies in another way (to make Otaku108 proud :p), and links between still undecided maps should not be marked like just all other links from the point 2.0.
-3.0 Two map files are similar, but we have inclusion of provided sets of the authors. This happens when the map file was modified. In case the inclusion is strict, after determining maps are similar, we can determine which map is the original automatically. In case sets of authors are equal these maps could be placed in one equivalence class until someone (most likely the author) specifies the original. Also a place for the list of modifications could be provided.
-4.0 The authour could specify maps where he has borrowed the idea of his work. By saying "the author" I imply everyone could change this field but most likely only the author knows this for sure.
Probably others I cant think of at the moment...
Considering authors verification.
Dcramer, your map database should definetly have an option to somehow connect the author name specified in the map with a forum account. I suggest divide the problem on two: how to connect the author name specified in the map with the battle.net account and how to connect a battle.net account with the nibbits forum account.
Usually authors nicknames written in maps textually match the ones they have on battle.net or somwhere else, for example on forums (or at least one of them). Considering this I suppose matching the author nickname written in the map with all textually matching names *anywhere*. For example, I write "Map by Wormer" in my maps, thus everyone who has the nickname wormer everywhere is connected with the author name: wormer@games.podolsk.ru, wormer@USEast, wormer@Europe, wormer@staredit.net, wormer@gmail.com for example.
But this matching does not play any role as far as these names are matched with the nibbits account. Matching nibbits account with mail servicies is easy and could be automated. The author names specified at the authors map field on nibbits are linked *only* with those nibbits accounts which are connected to at least some of those names (wormer@games.podolsk.ru, wormer@USEast, wormer@Europe, wormer@staredit.net, wormer@gmail.com and etc.). Thus several nibbits accounts could be linked with the particular author name. They are sorted by "confidence": basically having more such account connected should result in having more confidence, particular rules could be tweaked later.
You can ask, how to connect a nibbits account with the battle.net one? This should be the problem of the one who wants to connect them. Take me for example. After I specify the account wormer@USEast on my personal page on nibbits I can ask you to verify the wormer@USEast account. You send me a password through a nibbits pm message and we agree the meeting date and time on battle.net where I am telling you the password. Once you sure I have a wormer@USEast account you can confirm that near the wormer@USEast account on my nibbits page. More people have confirmed my USEast account it becomes more tightly connected with the nibbits account. Now I can confirm other forum accounts and so on. The same thing is with the forum and other accounts.
I want to point out that someone with the nibbits account sdf112 connected (and confirmed) with the battle.net account wormer@Europe could also pretend on authorship and will display in the nibbits accounts list connected with the wormer nickname specified in the map. The list of such accounts should be sorted by confidence as I wrote.
Stop using my email in your examples, damn you
81.228.187.xxx