View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0002194 | AI War 1 / Classic | Suggestion - Campaign Management And Setup - Map Styles And Generation | Dec 28, 2010 4:27 pm | Dec 30, 2010 11:39 am | |
| Reporter | Sunshine | Assigned To | Chris_McElligottPark | ||
| Status | closed | Resolution | won't fix | ||
| Summary | 0002194: Search for seeds with *selected* ship types | ||||
| Description | Provide, next to the "New Map Seed" button, 16 drop-down menus from which you can select bonus ships, and the game will then display new map seeds with only those selected ships (and random other ships if there are empty search slots). It will make it a lot easier to find a map with a ship (or ships) you want, without giving players the power to structure the map in a certain way. It would be really useful for us over here, because we tend to play multi-planet starts and are usually looking for a specific combination of ships we want to try out, and it'll cut down on the clicking to find that. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
Yes please. I *do* appreciate the 16 planet start to save time, but I feel a better method of addressing this would be to allow us to pick ships for inclusion. |
|
|
As awesome as this would be, imagine the computational difficulty of finding a seed with the parameters specified. Unless the function that takes a seed and generates a map is reversible, this is infeasible. (Basically, if it is reversible, you can specify certain parameters the seed has an impact on and find a seed that matches those parameters without having to brute force or use trial and error. If it is not reversible, you have to use brute force or trial and error, both of which are totally unsalable solutions for the number of seeds available). Maybe it is time to move away from a manually specified seed map generation. Sure, it makes it harder to provide exact galaxy layouts succinctly, but instead you could export the layout to a more flexible data structure (xml, csv, something), and have the option to import that layout later. This also means you can change how maps are generated internally without having to worry about breaking how old seeds generate. It would also let fancier map generation parameters be able to be specified, like the one in this report. Basically, from a software engineering perspective, letting the user choose and have an expectation of a given seed is having the user rely too much on low level information, and ties the developer too much to old algorithms. |
|
|
I was not thinking that by providing ships for inclusion the game would actually find a seed with the parameters, so much as it would generate seed after seed until one by chance had the ship (perhaps this is just semantics, but I think it's an important distinction). And it is *no more* computationally intensive then what players have to do now, which is generate map after map and look at each. The only difference, computationally, is an additional check each for each seed to see if it has the specified ship, which the player does (and most certainly takes more time than a check by the computer). |
|
|
@Fleet True, but the report seems to be suggesting an ANDing of search ship types, not an ORing. An ORing would be pretty fast, but is not of much use beyond one player. ANDing can get really hard really fast. |
|
|
Alright, lets compare multiplayer ANDing scenarios between the current method and a computerized method. Current: I want Snipers, and my partner wants Beam Frigates. I generate a map, and look to see if it has both. It does not, so I generate a new map, and look at it...repeat until I see a map that has both. Cumputerized: I tell the computer I want a map with Snipers and Beam Frigates. It generates a map and checks if both are available. If they are not, it generates another map and checks. Repeat until it seems a map that has both. The seed/map generations is *no different* than before, it is doing the same blind generation and check method that I am doing. This never gets hard for the computer, and in fact having a computer check if a ship is present takes *less time* then a human visually inspecting the map. Even a more complicated one, like I want Beam Frigates OR Snipers AND my partner wants Raptors OR raiders, there is NO way that the computer doing a check with every map generated is SLOWER then my having to visually check each map, which is what I would have to do. |
|
|
This would be an increibly slow search. As it is, it's Kent to enclosed variety and experimentTion. There's a wiki post about this very thing. |
|
|
Sorry...I still don't get how this is slower then the current method. How is having a computer check if the map has a ship type possibly slower then me having to visually check? |
|
|
Again, if we are searching for ONE ship type to match among those listed, it would be fast. If we are searching for ALL ship types listed (>1 of course), it is way too slow, even if done by the computer instead of the human. The exponential decay of the probability of a map meeting the requirement means that even if a computer does the search, it will probably take a long time. Then again, if it is just 1 or 2 ship types, that probably would go very quick, so that may be a compromise. Any more than 2, no way is that feasible. Another compromise would be to make the search criteria OR with each other, not AND. That would also be fast. EDIT: PLEASE PLEASE PLEASE reopen for feedback about support for compromises like these that turn this search problem into something feasible. |
|
|
@Fleet For the whole humans doing the AND search thing. As I mentioned, 2 ships is not all that hard of a search. 3 ships, may take a while. 6 ships, you will probably be searching for days to weeks. A computer search may be able to shrink from "days to weeks" to "hours to days". In other words, faster, but still completely infeasible. Wait, what is the data type for the seeds? If it is something small, then searching the entire space won't take very long at all, and thus searching on any criteria is feasible. (Anything bigger than an unsigned int will probably take too long, and even an unsigned int is pushing it) Yes, more begging and pleading: PLEASE PLEASE PLEASE reopen for feedback about support for compromises that turn this search problem into something feasible. |
|
|
"The exponential decay of the probability of a map meeting the requirement means that even if a computer does the search, it will probably take a long time." I'm not saying that this will decrease the time it takes to find maps, but this is already exactly what players HAVE to do if they want certain ship types. Spend a long time generating map after map after map...The *only* change I'm suggesting is that the computer do this check and generate a new map if it does not have the ships. It is totally fixable and would not introduce some huge computational overhead that the player not ALREADY having to do. In the case where a player selects a combination that is unlikely, then they can wait for the computer to do its thing, which is NO worse then the current method of the player either being patient and generating map after map, or being more lenient. This change is not supposed to introduce new possibilities for generating maps with ships, or make certain ship combinations easier to come by. If the combination is unlikely, then just like the player who has to generate lots of maps and do lots of checks, the computer would generate lots of maps and do lots of checks. In either case the player has to make a compromise about how specific they want to be, vs. how important their time is. Lets say I want snipers and my friend wants beam frigates. We can sit down for a few minutes and find this combination. Two specific ships, NEXT to eachother, which is pretty unlikely, But even manually we can do it, just takes some time. So there is no exponential computational wall that the computer will hit, since it is not taking more memory...there is NO extra memory to check each map to see if it has, (extreme case), 8 ships. It just has to do more checks because that is an unlikely combination. PS: Tech, thanks for engaging in this extended dialogue without taking things personally. I know we are both trying to improve on the game. |
|
|
True. It will be faster with the computer in all scenarios. And it won't take any additional memory. (assuming the garbage collector does what it was built to do) The concern is whether faster will be fast enough. Generating and searching potentially millions of map configurations will take a long, LONG time even for a computer. I guess it comes down to whether the game can trust the users not to shoot themselves in the foot. Maybe the game can allow a large number of search criteria, but with the CLEAR disclaimer that each additional criteria can double or likely much more than double the search time. Thus, if you ask for a one in a trillion chance, the game will diligently search for it and you will have to wait for the days it will almost certainly take to get it because you were stupid enough to ask way too much. In return, we get a powerful tool to those (like you and me) who can use it without asking too much of it, then it becomes VERY useful. So with keeping the current map generation system, we have three choices, avoid the issue entirely, open up the tool but allow users to make obscene demands and probably wait WAY too long to get them, or give the tool but put sane (but nonetheless artificial) restrictions on it to keep the worst from (likely) happening. I think the third option is a reasonable compromise. EDIT: Oops, almost forgot: PLEASE PLEASE PLEASE reopen for feedback about support for compromises that turn this search problem into something feasible. EDIT2: Thanks fleet. I wasn't taking it personally. I'm just trying to see the issue from both the developer's side and the user's side and coming to a reasonable solution for both. |
|
|
If Sunny does not re-open, I will consider doing so. Anyway, I agree that it is a sticky issue of whether to put on limitations. I would consider not putting on limitations, but maybe have a warning (just like when selecting multiple homeworlds). If it takes too long to search, then the player can simply stop the search and change parameters, just as a player would do currently if they saw that after 15 seeds, they were getting impatient and would relax their parameters. But a restriction would also be acceptable to protect those fragile users. Sokath, his eyes uncovered! |
|
|
Fleet requested that I reopen, so here goes. |
|
|
Thanks so much for re-opening Sunshine. I'm especially interested in the devs thoughts about why this would be a slow search, and if they actually mean this would be slower then the current player manually searching method. Even if it is the same speed, I would consider this removing micro thats not required (it is reasonable for a player to have a ship preference). Tech, just as a sidenote, generally after I get the devs response to re-opening, I just go with that. Have to pick my battles, right? :) |
|
|
Yea, if they disagree even with the alternatives we listed, then we'll just assume that our sentiment is not a big enough concern for them to spend their time on it. I would be fine with that. I just wanted them to consider viable modifications to the original ideas and how we players would be willing to let a computer take time to search instead of us taking time to search, and to promise we will be sane with the search. P.S. Thanks Sunshine for reopening and letting us use your report as a way to bounce ideas. And thanks Fleet for bouncing ideas and for narrowing down what the real concern was. |
|
|
awesome idea i support it. it eliminate thus searches for 2 worm hole entry for one particular ship type down. |
|
|
Fleet -- the reason its slowness is a problem is that it will make the application look hung for perhaps dozens of seconds at a time, if not minutes. If we make a mistake (aka, let you search for a ship type that can't possibly show up with the current settings), it will just hang the application permanently. |
|
|
And, for more info for those curious on why the issue is closed: http://arcengames.com/mediawiki/index.php?title=AI_War_-_Design_Complexity#Why_Does_The_Game_Force_Variety_On_The_Player.3F |
|
|
Fair enough. Thanks for letting us discuss this so much. I can see your reasoning behind this. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Dec 28, 2010 4:27 pm | Sunshine | New Issue | |
| Dec 28, 2010 8:09 pm | Fleet | Note Added: 0007173 | |
| Dec 28, 2010 10:31 pm | TechSY730 | Note Added: 0007176 | |
| Dec 28, 2010 10:35 pm | Fleet | Note Added: 0007177 | |
| Dec 28, 2010 10:37 pm | TechSY730 | Note Added: 0007178 | |
| Dec 28, 2010 11:13 pm | Fleet | Note Added: 0007181 | |
| Dec 28, 2010 11:23 pm | Chris_McElligottPark | Note Added: 0007183 | |
| Dec 28, 2010 11:23 pm | Chris_McElligottPark | Status | new => resolved |
| Dec 28, 2010 11:23 pm | Chris_McElligottPark | Resolution | open => not fixable |
| Dec 28, 2010 11:23 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Dec 28, 2010 11:24 pm | Fleet | Note Added: 0007184 | |
| Dec 28, 2010 11:34 pm | TechSY730 | Note Added: 0007185 | |
| Dec 28, 2010 11:35 pm | TechSY730 | Note Edited: 0007185 | |
| Dec 28, 2010 11:36 pm | TechSY730 | Note Edited: 0007185 | |
| Dec 28, 2010 11:36 pm | TechSY730 | Note Edited: 0007185 | |
| Dec 28, 2010 11:42 pm | TechSY730 | Note Edited: 0007185 | |
| Dec 28, 2010 11:51 pm | TechSY730 | Note Added: 0007186 | |
| Dec 28, 2010 11:52 pm | TechSY730 | Note Edited: 0007186 | |
| Dec 29, 2010 12:08 am | Fleet | Note Added: 0007188 | |
| Dec 29, 2010 12:15 am | Fleet | Note Edited: 0007188 | |
| Dec 29, 2010 12:22 am | TechSY730 | Note Added: 0007190 | |
| Dec 29, 2010 12:23 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:23 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:24 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:28 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:29 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:38 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:38 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:42 am | TechSY730 | Note Edited: 0007190 | |
| Dec 29, 2010 12:47 am | Fleet | Note Added: 0007191 | |
| Dec 29, 2010 12:58 am | Sunshine | Note Added: 0007192 | |
| Dec 29, 2010 12:58 am | Sunshine | Status | resolved => feedback |
| Dec 29, 2010 12:58 am | Sunshine | Resolution | not fixable => reopened |
| Dec 29, 2010 1:13 am | Fleet | Note Added: 0007193 | |
| Dec 29, 2010 1:15 am | TechSY730 | Note Added: 0007194 | |
| Dec 29, 2010 1:17 am | TechSY730 | Note Edited: 0007194 | |
| Dec 29, 2010 1:23 am | TechSY730 | Note Edited: 0007194 | |
| Dec 29, 2010 1:23 am | TechSY730 | Note Edited: 0007194 | |
| Dec 29, 2010 4:00 am | soMe_RandoM | Note Added: 0007203 | |
| Dec 30, 2010 10:32 am | Chris_McElligottPark | Note Added: 0007254 | |
| Dec 30, 2010 10:33 am | Chris_McElligottPark | Status | feedback => closed |
| Dec 30, 2010 10:33 am | Chris_McElligottPark | Resolution | reopened => won't fix |
| Dec 30, 2010 10:34 am | Chris_McElligottPark | Note Added: 0007255 | |
| Dec 30, 2010 11:39 am | TechSY730 | Note Added: 0007260 |
