Impromptu LAN party, only four of us showed up. No problem there, but under normal circumstances we've never been able do a decent NS game with only four people. WB just wasn't good enough to hold it's own against us, even when favored in numbers. Well, we gave it another shot, as I've seen some real improvements in 1.05. WB did much better, and we had a much harder time beating it. Granted, we still played 4 on 9, but it didn't just seem like wave after wave of skulks, it was wave after wave of just about everything. The bots still wouldn't have won, but we were reduced to turret farming some choke points just to keep the bots off our back long enough to set up some really strategic points. But that was with completely default configs. I think allowing the bots a full range of lifeform choice (i.e. max_fraction_onos=1.0) will really make the challenge harder. We may even have to make it evenly numbered teams. I'm excited about the possibilities.
I do have a small gripe, though.
My gripe is that the chamber order is hardcoded. A friend at the LAN party thought that the bots might have gone sensory first, and wanted some scanner sweeps. I had to regretfully inform him that that was impossible, as the chamber order isn't decided by the bots. I think that is a shame. I think it promotes laziness in the players, because they already know what upgrades the bots have, just by how many hives they have. Now I'm not advocating pure randomness, but rather some user selectable weights in the whichbot.txt file. In the system I'm envisioning, server operators would set votes for each chamber type, and then the bot could get a percentage chance that a particular chamber type would be the next put down.
For example, the votes could be d=6, m=3, s=1. In this case, the numbers add up to ten, but they wouldn't have to. These values would mean that for the first chamber, 60% (6/10) of the time Defense would be placed first, 30% (3/10) of the time Movement would be placed first, and %10 (1/10) of the time Sensory would be placed first. For the second chamber, the bot would take the relative weights of the remaining two chambers, and so in the case that Defense was placed first with these votes, then three of the four remaing votes (75%) would be for Movement as the second chamber, and one (25%) for Sensory as the second chamber.
If a server operator really wanted to set the order consistently to DMS, they could set the votes as such: d=1000, m=1, s=0. These votes would mean that Sensory would never be chosen as the first or second chamber, and that Movement would only be chosen first once every thousand rounds or so.
Benefits of server selectable upgrade paths:
Players become less lazy, because they can't be exactly sure what upgrades the bots might have. The experiences will be different between rounds, and across servers. It can be one more step towards a humanlike bot.
The benefits of using this system over another:
Server operators only have to enter one set of variables, and they don't have to worry about making sure the numbers add up to anything specific. Server owners get a lot of freedom about how the bots choose upgrades, and it will be difficult for them to input invalid data.
Drawbacks of server selectable upgrade paths:
The bots will be slightly weaker in specific rounds from choosing weaker upgrades.
Drawbacks of using this system:
It is complex, and not easily explained. It makes perfect sense once you understand it, but it's not a straight-up percentage system. And while it's difficult to input really invalid data, it could be difficult to make the bots do what you intend if you don't really understand how it works.
Comments?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like this idea. For one, it'd let you practice vs. other chamber aided bots, right from the break. I'm all about putting almost every variable that can/should be tweaked into the config file and letting the users tweak as needed/wanted. I suppose this complicates bug testing, but it lets users be tweakers without munging around in the CVS and having to know C.
I think the drawback you mentioned about the bots being weaker sometimes would be far outweighed by removing the cmdrs ability to know exactly what the bots were going to do. This element of surprise would, as it did in your case, keep the cmdr spending res on extras they wouldn't spend on otherwise and add a good element of suspense.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As to the chamber order, it's not hardcoded, it's in the config. I too like the idea of having an option to make it random. I have found making them build mc's first works best.
The config file doesn't explain the chamber order so I'll do it here. At the top of the strategy/builder section you'll see chamber_order='4.0 5.0 6.0' , change these numbers to alter the build order. The meaning of the numbers is as follows:
defense = 4.0
movement = 5.0
sensory = 6.0
So if you wanted them to build movement,defense then sensory you would put -
chamber_order='5.0 4.0 6.0'
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, hardcoded isn't perhaps the right term. I saw that line in the config, and it made sense, but I really was hoping for something where we couldn't be absolutely sure at our lan which upgrade the bots had chosen until we had seen it in action. I suppose that the current implentation is good enough for the time being, and it really is a small gripe, but there are so few simple things left.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree a random element would be cool. I would favour a "weighting" system, where perhaps you had 10 points to divide between the chambers in the configs and the weight given to each chamber in the config would determine the probability of the next one being built. So if I gave it 6, 2, 2, defence, movement, sensory, then the chance of the defence chamber being built first would be 6 out of 10. It would be simple to implement I think and easily understood. If you wanted to make it even more configurable you could make it 15 points and allow one decimal place which would make it easier for players to configure it in a way to ensure that a certain order would almost always be followed, if that was what they wanted.
Having said that, I actually had a chance to play against the bots with a group of guys for the first time on Saturday night, and I was truly impressed. They still didn't build as many chambers as I would like to see (I realize for the really good players they think lots of chambers are a waste of rez, but on servers with fewer players having lots of chambers built makes the game more challenging and more fun), but overall the bots are playing much better than they were. They navigate ladders and obstacles much better, and they use all their abilities. All in all they are much more fun than they were.
Good job! is all I have to say, and looking forward to whatever you have to offer in future versions. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Impromptu LAN party, only four of us showed up. No problem there, but under normal circumstances we've never been able do a decent NS game with only four people. WB just wasn't good enough to hold it's own against us, even when favored in numbers. Well, we gave it another shot, as I've seen some real improvements in 1.05. WB did much better, and we had a much harder time beating it. Granted, we still played 4 on 9, but it didn't just seem like wave after wave of skulks, it was wave after wave of just about everything. The bots still wouldn't have won, but we were reduced to turret farming some choke points just to keep the bots off our back long enough to set up some really strategic points. But that was with completely default configs. I think allowing the bots a full range of lifeform choice (i.e. max_fraction_onos=1.0) will really make the challenge harder. We may even have to make it evenly numbered teams. I'm excited about the possibilities.
I do have a small gripe, though.
My gripe is that the chamber order is hardcoded. A friend at the LAN party thought that the bots might have gone sensory first, and wanted some scanner sweeps. I had to regretfully inform him that that was impossible, as the chamber order isn't decided by the bots. I think that is a shame. I think it promotes laziness in the players, because they already know what upgrades the bots have, just by how many hives they have. Now I'm not advocating pure randomness, but rather some user selectable weights in the whichbot.txt file. In the system I'm envisioning, server operators would set votes for each chamber type, and then the bot could get a percentage chance that a particular chamber type would be the next put down.
For example, the votes could be d=6, m=3, s=1. In this case, the numbers add up to ten, but they wouldn't have to. These values would mean that for the first chamber, 60% (6/10) of the time Defense would be placed first, 30% (3/10) of the time Movement would be placed first, and %10 (1/10) of the time Sensory would be placed first. For the second chamber, the bot would take the relative weights of the remaining two chambers, and so in the case that Defense was placed first with these votes, then three of the four remaing votes (75%) would be for Movement as the second chamber, and one (25%) for Sensory as the second chamber.
If a server operator really wanted to set the order consistently to DMS, they could set the votes as such: d=1000, m=1, s=0. These votes would mean that Sensory would never be chosen as the first or second chamber, and that Movement would only be chosen first once every thousand rounds or so.
Benefits of server selectable upgrade paths:
Players become less lazy, because they can't be exactly sure what upgrades the bots might have. The experiences will be different between rounds, and across servers. It can be one more step towards a humanlike bot.
The benefits of using this system over another:
Server operators only have to enter one set of variables, and they don't have to worry about making sure the numbers add up to anything specific. Server owners get a lot of freedom about how the bots choose upgrades, and it will be difficult for them to input invalid data.
Drawbacks of server selectable upgrade paths:
The bots will be slightly weaker in specific rounds from choosing weaker upgrades.
Drawbacks of using this system:
It is complex, and not easily explained. It makes perfect sense once you understand it, but it's not a straight-up percentage system. And while it's difficult to input really invalid data, it could be difficult to make the bots do what you intend if you don't really understand how it works.
Comments?
I like this idea. For one, it'd let you practice vs. other chamber aided bots, right from the break. I'm all about putting almost every variable that can/should be tweaked into the config file and letting the users tweak as needed/wanted. I suppose this complicates bug testing, but it lets users be tweakers without munging around in the CVS and having to know C.
I think the drawback you mentioned about the bots being weaker sometimes would be far outweighed by removing the cmdrs ability to know exactly what the bots were going to do. This element of surprise would, as it did in your case, keep the cmdr spending res on extras they wouldn't spend on otherwise and add a good element of suspense.
Glad you had fun.
As to the chamber order, it's not hardcoded, it's in the config. I too like the idea of having an option to make it random. I have found making them build mc's first works best.
The config file doesn't explain the chamber order so I'll do it here. At the top of the strategy/builder section you'll see chamber_order='4.0 5.0 6.0' , change these numbers to alter the build order. The meaning of the numbers is as follows:
defense = 4.0
movement = 5.0
sensory = 6.0
So if you wanted them to build movement,defense then sensory you would put -
chamber_order='5.0 4.0 6.0'
Well, hardcoded isn't perhaps the right term. I saw that line in the config, and it made sense, but I really was hoping for something where we couldn't be absolutely sure at our lan which upgrade the bots had chosen until we had seen it in action. I suppose that the current implentation is good enough for the time being, and it really is a small gripe, but there are so few simple things left.
I agree a random element would be cool. I would favour a "weighting" system, where perhaps you had 10 points to divide between the chambers in the configs and the weight given to each chamber in the config would determine the probability of the next one being built. So if I gave it 6, 2, 2, defence, movement, sensory, then the chance of the defence chamber being built first would be 6 out of 10. It would be simple to implement I think and easily understood. If you wanted to make it even more configurable you could make it 15 points and allow one decimal place which would make it easier for players to configure it in a way to ensure that a certain order would almost always be followed, if that was what they wanted.
Having said that, I actually had a chance to play against the bots with a group of guys for the first time on Saturday night, and I was truly impressed. They still didn't build as many chambers as I would like to see (I realize for the really good players they think lots of chambers are a waste of rez, but on servers with fewer players having lots of chambers built makes the game more challenging and more fun), but overall the bots are playing much better than they were. They navigate ladders and obstacles much better, and they use all their abilities. All in all they are much more fun than they were.
Good job! is all I have to say, and looking forward to whatever you have to offer in future versions. :)