* Just say no to bungee paratroopers. [not found] <1088896371.19592.ezmlm@sources.redhat.com> @ 2004-07-03 23:21 ` Henry J. Cobb 2004-07-03 23:55 ` Eric McDonald 2004-07-04 1:14 ` Jim Kingdon 0 siblings, 2 replies; 56+ messages in thread From: Henry J. Cobb @ 2004-07-03 23:21 UTC (permalink / raw) To: xconq7 I've gotten rather tired of the bungee paratrooper trick of having a bomber fly around somebody's coastline capturing towns with the same infantry unit over and over again so I wrote a patch that applies two rules: If you capture something and you can fit inside it then you move in as part of the capture. If you attempt to capture something from inside a transport and you fail then you drop out on the ground or sea under the transport as you're pushed back. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-03 23:21 ` Just say no to bungee paratroopers Henry J. Cobb @ 2004-07-03 23:55 ` Eric McDonald 2004-07-04 0:55 ` Hans Ronne 2004-07-04 1:14 ` Jim Kingdon 1 sibling, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-03 23:55 UTC (permalink / raw) To: Henry J. Cobb; +Cc: xconq7 Henry J. Cobb wrote: > I've gotten rather tired of the bungee paratrooper trick of having a > bomber fly around somebody's coastline capturing towns with the same > infantry unit over and over again I assume you're referring to the Standard game. >so I wrote a patch that applies two > rules: > > If you capture something and you can fit inside it then you move in as > part of the capture. I am not sure that this would be desired behavior in all cases, but for want of a good counterexample, your proposal does sound fairly reasonable. > If you attempt to capture something from inside a transport and you fail > then you drop out on the ground or sea under the transport as you're > pushed back. I don't know about this. Consider troops attempting a capture from a helicopter unit; they ought to be able to return to the helicopters if the capture fails.... Regards, Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-03 23:55 ` Eric McDonald @ 2004-07-04 0:55 ` Hans Ronne 2004-07-04 1:39 ` Eric McDonald 0 siblings, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-04 0:55 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >>so I wrote a patch that applies two >> rules: >> >> If you capture something and you can fit inside it then you move in as >> part of the capture. > >I am not sure that this would be desired behavior in all cases, but for >want of a good counterexample, your proposal does sound fairly reasonable. I would concur. Even in non-paratrooper games, it makes sense for a capturing unit to move inside. Right now, it will wait outside for one turn or even move away, until the capture task has been changed to an occupy task. I've been planning to improve how the AI handles such cases. A lot can happen in one turn ... >> If you attempt to capture something from inside a transport and you fail >> then you drop out on the ground or sea under the transport as you're >> pushed back. > >I don't know about this. Consider troops attempting a capture from a >helicopter unit; they ought to be able to return to the helicopters if >the capture fails.... The key question is if captures (or attacks) from inside transports should be allowed at all. In principle, I think not. Paratroopers should jump into an empty cell, then attack on the ground from there. Jumping on top of enemy positions is suicide, as several examples from history show, so it should not be supported as a viable attack mode in Xconq. You could argue that troop transports at a fortified beach or marines in a spaceship outside a planet are cases where attacks from inside transports should be allowed, since there is no empty cell into which they first can land. However, also in this case, the troops are committed once they attack and cannot return to their transports. Only overrun actions should be allowed in such cases, and the attackers should perish if they fail. These were some general thoughts on the subject. I'm not sure it can all be easily implemented. Changes to the AI might be necessary as well. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 0:55 ` Hans Ronne @ 2004-07-04 1:39 ` Eric McDonald 2004-07-04 3:17 ` Hans Ronne 0 siblings, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-04 1:39 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hans Ronne wrote: > I would concur. Even in non-paratrooper games, it makes sense for a > capturing unit to move inside. Right now, it will wait outside for one turn > or even move away, until the capture task has been changed to an occupy > task. I've been planning to improve how the AI handles such cases. A lot > can happen in one turn ... Are we talking about teaching the AI to do something or are we talking about an implicit action. I was under the impression that we were talking about the latter and not necessarily the former. As I mentioned to Henry off-list, I am not sure that it is wise to impose a certain action "granularity" or time scale on game designers. Some games may dictate the kind of implicit action we are talking about, but others may not. I am not sure that capture always implies a forceful overrun followed by garrisoning. It may imply that the defender felt forced into surrender by the immediate presence of the capturing unit (independent of surrender chances). > The key question is if captures (or attacks) from inside transports should > be allowed at all. In principle, I think not. Paratroopers should jump into > an empty cell, then attack on the ground from there. Jumping on top of > enemy positions is suicide, as several examples from history show, so it > should not be supported as a viable attack mode in Xconq. That is one perspective. However, a game with a somewhat different time scale and different take on actions may be better served by having, say, the troops leave a helicopter, attempt capture, and then get back on the helicopter all as part of the capture action. Here again, I think we can ultimately be better served by a modular combat system that gives us the flexibility of turning on or off such behavior, instead of hacking an entire combat model and telling everyone that they have to do things the same way. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 1:39 ` Eric McDonald @ 2004-07-04 3:17 ` Hans Ronne 0 siblings, 0 replies; 56+ messages in thread From: Hans Ronne @ 2004-07-04 3:17 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >Hans Ronne wrote: > >> I would concur. Even in non-paratrooper games, it makes sense for a >> capturing unit to move inside. Right now, it will wait outside for one turn >> or even move away, until the capture task has been changed to an occupy >> task. I've been planning to improve how the AI handles such cases. A lot >> can happen in one turn ... > >Are we talking about teaching the AI to do something or are we talking >about an implicit action. I was under the impression that we were >talking about the latter and not necessarily the former. My point was that the AI is too slow in occupying captured units. I have been thinking about fixing this, but if captured units are occupied automatically, the AI problem would be fixed anyway. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-03 23:21 ` Just say no to bungee paratroopers Henry J. Cobb 2004-07-03 23:55 ` Eric McDonald @ 2004-07-04 1:14 ` Jim Kingdon 2004-07-04 3:37 ` Henry J. Cobb 2004-07-04 6:13 ` Henry J. Cobb 1 sibling, 2 replies; 56+ messages in thread From: Jim Kingdon @ 2004-07-04 1:14 UTC (permalink / raw) To: hcobb; +Cc: xconq7 > I've gotten rather tired of the bungee paratrooper trick of having a > bomber fly around somebody's coastline capturing towns with the same > infantry unit over and over again Yes. I'm quite a heavy user of that trick, but I'll agree that it throws off the game balance. I suppose if my opponents (currently AIs) were better at keeping enough fighters around to shoot down said bombers, it wouldn't seem so lopsided, but the AI isn't smart enough to do this with enough consistency. > If you capture something and you can fit inside it then you move in as > part of the capture. Sounds fair. Note that this also brings up new possibilities, for example an armor captures a coast town with their first ACP, and then uses their second ACP to capture a town one in from the coast. I'm not sure whether this is good or bad. However, what really makes the bungee paratrooper trick powerful is the failure case, so we'll proceed to that one: > If you attempt to capture something from inside a transport and you fail > then you drop out on the ground or sea under the transport as you're > pushed back. Well, if the goal is to make attacking from a transport harder, this would have that effect. It would put a premium on finding a beachhead, so you can land your infantry/armor, rather than just attacking from a transport ship (or bomber which is over water). I kind of suspect the show-stopper here would be the AI. Unless it is smart enough to look for beachheads, this change might make the AI even less of a contender than it is now. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 1:14 ` Jim Kingdon @ 2004-07-04 3:37 ` Henry J. Cobb 2004-07-04 6:13 ` Henry J. Cobb 1 sibling, 0 replies; 56+ messages in thread From: Henry J. Cobb @ 2004-07-04 3:37 UTC (permalink / raw) To: xconq7 Jim Kingdon wrote: > However, what really makes the bungee paratrooper trick powerful is > the failure case, so we'll proceed to that one: > >> If you attempt to capture something from inside a transport and you fail >> then you drop out on the ground or sea under the transport as you're >> pushed back. > > Well, if the goal is to make attacking from a transport harder, this > would have that effect. It would put a premium on finding a > beachhead, so you can land your infantry/armor, rather than just > attacking from a transport ship (or bomber which is over water). > > I kind of suspect the show-stopper here would be the AI. Unless it is > smart enough to look for beachheads, this change might make the AI > even less of a contender than it is now. Actually it seems to do OK, but that may do with the Makin Island patch I put on the standard scenario giving subs the ability to transport 1 Inf. It keeps grabbing my coastal bases and towns. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 1:14 ` Jim Kingdon 2004-07-04 3:37 ` Henry J. Cobb @ 2004-07-04 6:13 ` Henry J. Cobb 2004-07-04 15:13 ` Hans Ronne 1 sibling, 1 reply; 56+ messages in thread From: Henry J. Cobb @ 2004-07-04 6:13 UTC (permalink / raw) To: Jim Kingdon; +Cc: hcobb, xconq7 OK, here's my patch. combat.c capture_unit(atker, other, H_UNIT_CAPTURED); if(valid(check_enter_action(atker, atker, other))) do_enter_action(atker, atker, other); ... report_combat(atker, other, "resist"); if(alive(atker) && atker->transport && type_can_occupy_cell(atker->type,atker->transport->x, atker->transport->y)) do_move_action(atker,atker,atker->transport->x, atker->transport->y,atker->transport->z); -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 6:13 ` Henry J. Cobb @ 2004-07-04 15:13 ` Hans Ronne 2004-07-04 18:01 ` Jim Kingdon 0 siblings, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-04 15:13 UTC (permalink / raw) To: Henry J. Cobb; +Cc: xconq7 I have checked in your first patch. Thanks for submitting it. I made two changes. First, I moved it inside capture_unit (which is called from several places). Second, I added code for trying to enter the same cell if the capturing unit is unable to enter the captured unit itself. The second problem (what to do if an attack from within a transport fails) is a little more complicated and requires additional thought. Perhaps we should make the fate of such units a GDL option, as Eric suggested. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 15:13 ` Hans Ronne @ 2004-07-04 18:01 ` Jim Kingdon 2004-07-04 21:38 ` Hans Ronne 2004-07-09 1:17 ` Henry J. Cobb 0 siblings, 2 replies; 56+ messages in thread From: Jim Kingdon @ 2004-07-04 18:01 UTC (permalink / raw) To: hronne; +Cc: hcobb, xconq7 > First, I moved it inside capture_unit (which is called from several > places). Second, I added code for trying to enter the same cell if the > capturing unit is unable to enter the captured unit itself. One interesting feature of this patch (both versions) is that entering the captured unit uses up whatever ACP would have been needed to do the enter action. In the case of the standard game, this means that an armor which captures from a troop transport will not have an ACP left when it gets inside the town which it captured. I'm not sure whether this is better or worse than the other choice, which would be to give the enter action for free, but I thought it was worth noting. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 18:01 ` Jim Kingdon @ 2004-07-04 21:38 ` Hans Ronne 2004-07-04 21:57 ` mskala 2004-07-09 1:17 ` Henry J. Cobb 1 sibling, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-04 21:38 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 >> First, I moved it inside capture_unit (which is called from several >> places). Second, I added code for trying to enter the same cell if the >> capturing unit is unable to enter the captured unit itself. > >One interesting feature of this patch (both versions) is that entering >the captured unit uses up whatever ACP would have been needed to do >the enter action. > >In the case of the standard game, this means that an armor which >captures from a troop transport will not have an ACP left when it gets >inside the town which it captured. > >I'm not sure whether this is better or worse than the other choice, >which would be to give the enter action for free, but I thought it was >worth noting. You are abolutely right, and I think this is the correct way to do things. There are actually some freebies in the kernel code, too. One example is the ACP-less counterattack, and even counter-capture, that an attacked unit may engage in. Another, I think, is the ACP-less escape of occupants into an adjacent cell when the transport is captured. But I have always regarded these freebies as aberrations. It makes much more sense to charge the full price whenever you do something. There may be restrictions built in by the game designer, such as if the enter action requires more ACPs than the unit can possess. In that case, ACP-less entry by capture would clearly be a bug. Anyway, the fact that the captured unit is occupied immediately, and not the next turn, is in itself an advantage to the attacking side. Doing it free of charge would be too much of an advantage. What this means, of course, is that the attacker will not be able to enter the captured unit if it has used up all its ACPs for the turn. This, I think makes for a more interesting game. Situations like that are not uncommon in Civ. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 21:38 ` Hans Ronne @ 2004-07-04 21:57 ` mskala 2004-07-05 3:30 ` Hans Ronne 0 siblings, 1 reply; 56+ messages in thread From: mskala @ 2004-07-04 21:57 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Sun, 4 Jul 2004, Hans Ronne wrote: > But I have always regarded these freebies as aberrations. It makes much > more sense to charge the full price whenever you do something. There may be > restrictions built in by the game designer, such as if the enter action > requires more ACPs than the unit can possess. In that case, ACP-less entry In fairness, the designer may also be intentionally exploiting the freebie behaviour. I've been off doing other things instead of xconq for the last several weeks, but I remember in my game where I had the inanimate counters, at one point attempting to set them up so that certain units could not deliberately drop their counters, but the counters would escape to terrain on capture or destruction of the transporting unit. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 21:57 ` mskala @ 2004-07-05 3:30 ` Hans Ronne 0 siblings, 0 replies; 56+ messages in thread From: Hans Ronne @ 2004-07-05 3:30 UTC (permalink / raw) To: mskala; +Cc: xconq7 >On Sun, 4 Jul 2004, Hans Ronne wrote: >> But I have always regarded these freebies as aberrations. It makes much >> more sense to charge the full price whenever you do something. There may be >> restrictions built in by the game designer, such as if the enter action >> requires more ACPs than the unit can possess. In that case, ACP-less entry > >In fairness, the designer may also be intentionally exploiting the freebie >behaviour. True. Provided that he knows about them, of course. But I doubt that many game designers were aware of the kernel freebies, at least not before this thread got started :-). Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-04 18:01 ` Jim Kingdon 2004-07-04 21:38 ` Hans Ronne @ 2004-07-09 1:17 ` Henry J. Cobb [not found] ` <40EDFCDE.9000902@phy.cmich.edu> 1 sibling, 1 reply; 56+ messages in thread From: Henry J. Cobb @ 2004-07-09 1:17 UTC (permalink / raw) To: Jim Kingdon; +Cc: hronne, hcobb, xconq7 Even with this patch I can still take down any star empire in galaxy2 that I can get a loaded transport within 5 hexes of one core planet. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
[parent not found: <40EDFCDE.9000902@phy.cmich.edu>]
* Re: Just say no to bungee paratroopers. [not found] ` <40EDFCDE.9000902@phy.cmich.edu> @ 2004-07-09 3:37 ` Henry J. Cobb [not found] ` <40EEAD66.50109@phy.cmich.edu> 0 siblings, 1 reply; 56+ messages in thread From: Henry J. Cobb @ 2004-07-09 3:37 UTC (permalink / raw) To: xconq7 > Henry J. Cobb wrote: >> Even with this patch I can still take down any star empire in galaxy2 >> that >> I can get a loaded transport within 5 hexes of one core planet. > > I'm not a galaxy2 player. Are you saying there is a problem with the > galaxy2 game module or a more general problem with Xconq? And, what > exactly is it that you don't think is right? > > Eric My patch would help galaxy2 a bit if troopers died in space. The basic problem is that a loaded transport is almost 100 percent certain to take any world in time to land itself and avoid counterfire. It's also nice to take light cruisers, move out four hexes, take one shot at somebody then launch a fighter that pounds on them (fighters don't have working ammo limits.) Then the fighter returns to the cruiser and the cruiser returns to the planet and the AIs then take their turns without targets. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
[parent not found: <40EEAD66.50109@phy.cmich.edu>]
* Re: Just say no to bungee paratroopers. [not found] ` <40EEAD66.50109@phy.cmich.edu> @ 2004-07-09 16:02 ` Henry J. Cobb 2004-07-09 16:10 ` Hans Ronne 2004-07-09 16:47 ` Just say no to bungee paratroopers Jim Kingdon 0 siblings, 2 replies; 56+ messages in thread From: Henry J. Cobb @ 2004-07-09 16:02 UTC (permalink / raw) To: xconq7 >> My patch would help galaxy2 a bit if troopers died in space. >> >> The basic problem is that a loaded transport is almost 100 percent >> certain >> to take any world in time to land itself and avoid counterfire. >> >> It's also nice to take light cruisers, move out four hexes, take one >> shot >> at somebody then launch a fighter that pounds on them (fighters don't >> have >> working ammo limits.) >> >> Then the fighter returns to the cruiser and the cruiser returns to the >> planet and the AIs then take their turns without targets. > > OK, thanks for the more detailed analysis. If I get some time this > weekend, I will try to figure out what to do about this (either a change > to galaxy2 or more changes to the capture logic). > > Eric Both these cases have the same problem. Time is being used twice, once by the transport and again by the passengers. So the transport gets to use the entire time of the turn and then each passenger gets a full turn. The fix is to count the transport's movement against the passengers as well. So if the transport uses up half it's movement before launching a passenger then the passenger has only half of its own movement remaining. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-09 16:02 ` Henry J. Cobb @ 2004-07-09 16:10 ` Hans Ronne 2004-07-10 4:38 ` Henry J. Cobb 2004-07-09 16:47 ` Just say no to bungee paratroopers Jim Kingdon 1 sibling, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-09 16:10 UTC (permalink / raw) To: Henry J. Cobb; +Cc: xconq7 >Both these cases have the same problem. > >Time is being used twice, once by the transport and again by the passengers. > >So the transport gets to use the entire time of the turn and then each >passenger gets a full turn. > >The fix is to count the transport's movement against the passengers as well. > >So if the transport uses up half it's movement before launching a >passenger then the passenger has only half of its own movement remaining. I'm not sure I agree with that. Many games depend on this feature, see for example the Flattops game where the ability to launch an air strike after forward deployment of a carrier is important. The mplayer is also quite good at using this strategy. I rather think that it is the galaxy2 game that needs some fixes. It should be harder to capture planets, particularly if they are adequately defended. We could probably use some GDL tables from the advances game which is very much about defending important transports (in tha case cities). Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-09 16:10 ` Hans Ronne @ 2004-07-10 4:38 ` Henry J. Cobb 2004-07-12 1:25 ` Carrier groups Henry J. Cobb 0 siblings, 1 reply; 56+ messages in thread From: Henry J. Cobb @ 2004-07-10 4:38 UTC (permalink / raw) To: Hans Ronne; +Cc: Henry J. Cobb, xconq7 >>Both these cases have the same problem. >> >>Time is being used twice, once by the transport and again by the >> passengers. >> >>So the transport gets to use the entire time of the turn and then each >>passenger gets a full turn. >> >>The fix is to count the transport's movement against the passengers as >> well. >> >>So if the transport uses up half it's movement before launching a >>passenger then the passenger has only half of its own movement remaining. > > I'm not sure I agree with that. Many games depend on this feature, see for > example the Flattops game where the ability to launch an air strike after > forward deployment of a carrier is important. The mplayer is also quite > good at using this strategy. > > I rather think that it is the galaxy2 game that needs some fixes. It > should > be harder to capture planets, particularly if they are adequately > defended. > We could probably use some GDL tables from the advances game which is very > much about defending important transports (in tha case cities). > > Hans Just change the AI to run occupants first then the carrier so it does its air strike, returns the aircraft and pulls out of range of the surface forces. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Carrier groups 2004-07-10 4:38 ` Henry J. Cobb @ 2004-07-12 1:25 ` Henry J. Cobb 2004-07-12 3:27 ` Hans Ronne 0 siblings, 1 reply; 56+ messages in thread From: Henry J. Cobb @ 2004-07-12 1:25 UTC (permalink / raw) To: xconq7 Every time I see a lone empty unescorted aircraft carrier wandering around my coastline my respect for the AI goes down a bit. While I don't have a full topology and fractal fix for the AI I think we ought to be able to define standard unit combinations for it in the game files. So a carrier strike group would be defined as a group of units centered on a carrier. (With a full load of fighters and a battleship.) The entire group moves with the carrier and withdraws with it when the carrier is low on fuel, ammo or aircraft. When a carrier is first built it recruits the rest of the strike group to it and marks up a scorecard for priority production if it can't get enough aircraft or escorts. The aircraft assigned to the carrier will always return to it if they can and no other aircraft will land on the carrier except if they are assigned to a free slot. (This keeps the carrier from launching a strike then filling up with land based aircraft that will then crowd out the returning airwing.) Once the aircraft carriers are survivable we can worry about making amphib operations work correctly. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Carrier groups 2004-07-12 1:25 ` Carrier groups Henry J. Cobb @ 2004-07-12 3:27 ` Hans Ronne 2004-07-12 7:00 ` Henry J. Cobb 0 siblings, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-12 3:27 UTC (permalink / raw) To: Henry J. Cobb; +Cc: xconq7 >So a carrier strike group would be defined as a group of units centered on >a carrier. (With a full load of fighters and a battleship.) > >The entire group moves with the carrier and withdraws with it when the >carrier is low on fuel, ammo or aircraft. What you are suggesting is in effect the possibility of having side doctrines for setting formations. This would certainly be possible. However, the AI doesn't know how to use formations, so one would first have to write some new AI code. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Carrier groups 2004-07-12 3:27 ` Hans Ronne @ 2004-07-12 7:00 ` Henry J. Cobb 0 siblings, 0 replies; 56+ messages in thread From: Henry J. Cobb @ 2004-07-12 7:00 UTC (permalink / raw) To: Hans Ronne; +Cc: Henry J. Cobb, xconq7 >>So a carrier strike group would be defined as a group of units centered >> on >>a carrier. (With a full load of fighters and a battleship.) >> >>The entire group moves with the carrier and withdraws with it when the >>carrier is low on fuel, ammo or aircraft. > > What you are suggesting is in effect the possibility of having side > doctrines for setting formations. This would certainly be possible. > However, the AI doesn't know how to use formations, so one would first > have > to write some new AI code. > > Hans Yeah, but nothing really heavy, just subordinate certain units to follow a leader around. -- Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes and workarounds. http://www.io.com/~hcobb/gurps/gvb_faq.txt ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-09 16:02 ` Henry J. Cobb 2004-07-09 16:10 ` Hans Ronne @ 2004-07-09 16:47 ` Jim Kingdon 2004-07-09 16:54 ` Elijah Meeks 1 sibling, 1 reply; 56+ messages in thread From: Jim Kingdon @ 2004-07-09 16:47 UTC (permalink / raw) To: xconq7 > So the transport gets to use the entire time of the turn and then each > passenger gets a full turn. > > The fix is to count the transport's movement against the passengers as well. That's a very interesting suggestion. I guess in the case of an infantry in a bomber in the standard game, it would mean the bomber could move zero to two hexes, and the infantry would still have an ACP. That's assuming a particular rounding rule - other ways of rounding would get 0-5, 0-3, or 0 only. Assuming the 1-2 rule, it wouldn't make the bungee paratrooper tactic totally go away, but it would constrain it. This seems worth considering. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-09 16:47 ` Just say no to bungee paratroopers Jim Kingdon @ 2004-07-09 16:54 ` Elijah Meeks 2004-07-09 17:00 ` Wrecking Issues Elijah Meeks ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: Elijah Meeks @ 2004-07-09 16:54 UTC (permalink / raw) To: Jim Kingdon, xconq7 --- Jim Kingdon <kingdon@panix.com> wrote: > > So the transport gets to use the entire time of > the turn and then each > > passenger gets a full turn. > > > > The fix is to count the transport's movement > against the passengers as well. > > That's a very interesting suggestion. > > I guess in the case of an infantry in a bomber in > the standard game, > it would mean the bomber could move zero to two > hexes, and the > infantry would still have an ACP. That's assuming a > particular > rounding rule - other ways of rounding would get > 0-5, 0-3, or 0 only. > > Assuming the 1-2 rule, it wouldn't make the bungee > paratrooper tactic > totally go away, but it would constrain it. > > This seems worth considering. > If this was introduced as a true/false table, it should work fine. This way it could be turned on in cases where it made sense and left alone in games where it doesn't. Right? __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Wrecking Issues 2004-07-09 16:54 ` Elijah Meeks @ 2004-07-09 17:00 ` Elijah Meeks 2004-07-09 17:16 ` Eric McDonald 2004-07-10 21:40 ` Eric McDonald 2004-07-09 17:45 ` AI Help Elijah Meeks 2004-07-09 18:09 ` Just say no to bungee paratroopers Hans Ronne 2 siblings, 2 replies; 56+ messages in thread From: Elijah Meeks @ 2004-07-09 17:00 UTC (permalink / raw) To: xconq7 Is there any chance someone could patch the wrecking code so that a half-built unit doesn't wreck into a fully functional version of its wreck-type? Maybe a wreck-type-if-insufficient-cp or something? __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Wrecking Issues 2004-07-09 17:00 ` Wrecking Issues Elijah Meeks @ 2004-07-09 17:16 ` Eric McDonald 2004-07-10 21:40 ` Eric McDonald 1 sibling, 0 replies; 56+ messages in thread From: Eric McDonald @ 2004-07-09 17:16 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 On Fri, 9 Jul 2004, Elijah Meeks wrote: > Is there any chance someone could patch the wrecking > code so that a half-built unit doesn't wreck into a > fully functional version of its wreck-type? Sounds like a bug. I'll take care of it. Thanks for the report, Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Wrecking Issues 2004-07-09 17:00 ` Wrecking Issues Elijah Meeks 2004-07-09 17:16 ` Eric McDonald @ 2004-07-10 21:40 ` Eric McDonald 1 sibling, 0 replies; 56+ messages in thread From: Eric McDonald @ 2004-07-10 21:40 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > Is there any chance someone could patch the wrecking > code so that a half-built unit doesn't wreck into a > fully functional version of its wreck-type? Maybe a > wreck-type-if-insufficient-cp or something? I just checked in what I think is probably a suitable fix. If the unit being wrecked is incomplete, then the damage code simply disposes of it. If there are cases where this is unsuitable, then the alternative would be to make the change-type code (used by wrecking) to scale the wrecked type's CP to the unwrecked type's CP, in a manner similar to what is already done with ACP and HP. But, I'll leave the fix like it is for now. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* AI Help 2004-07-09 16:54 ` Elijah Meeks 2004-07-09 17:00 ` Wrecking Issues Elijah Meeks @ 2004-07-09 17:45 ` Elijah Meeks 2004-07-09 18:15 ` Hans Ronne 2004-07-11 9:44 ` AI Help Jim Kingdon 2004-07-09 18:09 ` Just say no to bungee paratroopers Hans Ronne 2 siblings, 2 replies; 56+ messages in thread From: Elijah Meeks @ 2004-07-09 17:45 UTC (permalink / raw) To: xconq7 Managing to build an AI that can function as well for games involving zombies as it can for games involving battlefleets is a daunting task. I'm wondering, though, if there's a way to take a little pressure off the coders and put it into the hands of the designers. As it stands, the AI pretty much analyzes everything and comes up with its own ideas based on that (With a little help from tags like, 'air' and 'naval', but it doesn't seem like much). So maybe there could be some Roshambo tables to give the AI a little help. I say Roshambo, or rock-paper-scissors, because much of game design follows a strategy of X beats Y. You could have a preferred-opponent table that reads something like this: (table preferred-opponent (infantry archers 100) (infantry infantry 75) (infantry cavalry 50) (infantry killer-robot 0) ) This would be an override to the AI decision code, so that in this case, if the infantry unit ever had a chance to attack an archer unit, it'd take it, while it would have a 25% chance to consider a different course of action for other infantry units (Which may still result in an attack, but may result in continuing to move somewhere else or attacking a different unit). While a table like the example would reduce XConq to mob warfare, a less aggressive table like: (table preferred-opponent (army place-types 15) (army aircraft-types 10) (army evil-dictator-types 20) ) Would make the AI a little more opportunistic on the unit level, where I see it avoiding easily destroyed and expensive units in favor of, apparently, some earlier plan. This would also help with AI for some more esoteric games, such as if you want to make Zombies or the Borg or whatever and you want them to be utterly singleminded: (table preferred-opponent (zombies has-brains-types 100) (borg redshirt 50) (borg junior-officer 75) (borg important-guy 100) ) I'm looking at this not from an ai-tactical-range view, but from a purely adjacent, target of opportunity view (Which may be a better name for this table). I think the idea would also be good for unit building, to create a table that forces the AI to build based on set guidelines, rather than overarching strategy. (table ai-build-queue (city legion 50) (city fleet 10) (city facility-types 10) (city wonder 5) ) Again, this would be a suggestion table, so that the AI would first check through each of the entries and if it came false, it would instead choose to build what it wanted on its own. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AI Help 2004-07-09 17:45 ` AI Help Elijah Meeks @ 2004-07-09 18:15 ` Hans Ronne 2004-07-09 18:26 ` Eric McDonald 2004-07-11 9:44 ` AI Help Jim Kingdon 1 sibling, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-09 18:15 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >Managing to build an AI that can function as well for >games involving zombies as it can for games involving >battlefleets is a daunting task. I'm wondering, >though, if there's a way to take a little pressure off >the coders and put it into the hands of the designers. > As it stands, the AI pretty much analyzes everything >and comes up with its own ideas based on that (With a >little help from tags like, 'air' and 'naval', but it >doesn't seem like much). > >So maybe there could be some Roshambo tables to give >the AI a little help. I say Roshambo, or >rock-paper-scissors, because much of game design >follows a strategy of X beats Y. You could have a >preferred-opponent table that reads something like >this: <snip> >I think the idea would also be good for unit building, >to create a table that forces the AI to build based on >set guidelines, rather than overarching strategy. > >(table ai-build-queue > (city legion 50) > (city fleet 10) > (city facility-types 10) > (city wonder 5) >) I think there is a lot of merit to your suggestion. Basically, it would be an extension of the side doctrines to cover more than just construction run lengths and resupply trigger levels. This is something we already discussed on the list, and I am in favour of it. In fact, I suggested something very similar for the same reason: that the game designer usually has a better idea of what various unit types are best at than the AI can ever have using its standardized unit worth functions. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AI Help 2004-07-09 18:15 ` Hans Ronne @ 2004-07-09 18:26 ` Eric McDonald 2004-07-09 19:03 ` Elijah Meeks 0 siblings, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-09 18:26 UTC (permalink / raw) To: Hans Ronne; +Cc: Elijah Meeks, xconq7 On Fri, 9 Jul 2004, Hans Ronne wrote: > I think there is a lot of merit to your suggestion. As do I. And, these thoughts have certainly crossed my mind before. Also, I have been contemplating weighted garrison tables, as well. I don't think it is enough just to set a few unit props that give a quantity. There should also be some way to determine proper unit types with which to garrison. >Basically, it would be > an extension of the side doctrines to cover more than just construction run > lengths and resupply trigger levels. This is something we already discussed > on the list, and I am in favour of it. In fact, I suggested something very > similar for the same reason: that the game designer usually has a better > idea of what various unit types are best at than the AI can ever have using > its standardized unit worth functions. I agree, even if it does take some of the fun out of trying to design good standardized unit worth functions... :-) Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AI Help 2004-07-09 18:26 ` Eric McDonald @ 2004-07-09 19:03 ` Elijah Meeks 2004-07-09 19:45 ` Side Selection Bugs Elijah Meeks 2004-07-11 1:47 ` AWLS: Korea 2006 Eric McDonald 0 siblings, 2 replies; 56+ messages in thread From: Elijah Meeks @ 2004-07-09 19:03 UTC (permalink / raw) To: Eric McDonald, Hans Ronne; +Cc: Elijah Meeks, xconq7 > >Basically, it would be > > an extension of the side doctrines to cover more > than just construction run > > lengths and resupply trigger levels. This is > something we already discussed > > on the list, and I am in favour of it. In fact, I > suggested something very > > similar for the same reason: that the game > designer usually has a better > > idea of what various unit types are best at than > the AI can ever have using > > its standardized unit worth functions. > > I agree, even if it does take some of the fun out of > trying to > design good standardized unit worth functions... :-) > > Eric I agree that the best solution would be AI code that figured it out based on the game setup but I've noticed that the AI is leery of building some units. In some cases won't build them for no discernable reason, but will build them when you make what seems to an unrelated change, as an example, in Korea-2006, the AI refuseed to build Air Wings but, when I gave it the option of building Air Defense Networks, it suddenly started building Air Wings just fine (And won't build ADNs). I don't get it and I know it's indicative of some internal procedure that should be fixed, I'm sure, but a suggestion table would give it a push in the right direction. If the table was side-specific, that'd be great, but if it was AI-specific, that'd be even better. I'm pretty happy with mplayer, but if you could have, say, six mplayers, then you could use the tables to set up mplayer-1 to be "naval-oriented", mplayer-2 to be "armor-oriented", mplayer-3 to be "random". It would resemble, I suppose, something like this: (set mplayer-1-name "Standard AI") (set mplayer-2-name "Naval Oriented") (table mplayer-2-build-preference (destroyer 50) (cruiser 25) (battleship 15) (carrier 10) ) Just theorizing. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Side Selection Bugs 2004-07-09 19:03 ` Elijah Meeks @ 2004-07-09 19:45 ` Elijah Meeks 2004-07-09 19:46 ` Hans Ronne 2004-07-11 1:47 ` AWLS: Korea 2006 Eric McDonald 1 sibling, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-09 19:45 UTC (permalink / raw) To: xconq7 There are two issues with side selection, both regarding inactive sides: 1. If a side is set to 'inactive' and you cycle through the list of available sides once, then you'll switch the AI to nobody after you've cycled past the inactive side. 2. If side #1 is set to inactive then starting a game and hitting the 'exchange' button will result in a crash. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Side Selection Bugs 2004-07-09 19:45 ` Side Selection Bugs Elijah Meeks @ 2004-07-09 19:46 ` Hans Ronne 0 siblings, 0 replies; 56+ messages in thread From: Hans Ronne @ 2004-07-09 19:46 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >There are two issues with side selection, both >regarding inactive sides: > >1. If a side is set to 'inactive' and you cycle >through the list of available sides once, then you'll >switch the AI to nobody after you've cycled past the >inactive side. You should not be able to cycle into an inactive side (and you cannot in those games that I tested). What may happen is that you cycle into the Independent side which is usually hidden in the list. Click "Reveal Indepside" to see what actually happens. >2. If side #1 is set to inactive then starting a game >and hitting the 'exchange' button will result in a crash. Anything that crashes the game is a bug by definition. Probably the bug in this case is assigning the human player to side 1 by defualt without first checking that it is active. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* AWLS: Korea 2006 2004-07-09 19:03 ` Elijah Meeks 2004-07-09 19:45 ` Side Selection Bugs Elijah Meeks @ 2004-07-11 1:47 ` Eric McDonald 2004-07-11 4:16 ` Elijah Meeks 1 sibling, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-11 1:47 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 I did some playing on the updated Korean War game earlier. It seems that the American/S. Korean/Japanese alliance is now quite a bit stronger and more aggressive. The N. Koreans and Chinese have a much tougher slog than last time I played. One thing that I noticed is that, for some reason, N. Korean armor cannot attack S. Korean armor, or so it seemed. Made it a bit of a nightmare trying to contain the S. Korean armor without taking massive infantry casualties. (A S. Korean armor had already broken through earlier and taken out N. Korea's only air support.) Aside from this problem (and some issues with ZOC's being exerted by unseen units, which is a Xconq problem, not a game module problem), the game seemed to be quite fun. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AWLS: Korea 2006 2004-07-11 1:47 ` AWLS: Korea 2006 Eric McDonald @ 2004-07-11 4:16 ` Elijah Meeks 2004-07-13 2:40 ` More Feedback on " Eric McDonald 0 siblings, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-11 4:16 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 --- Eric McDonald <mcdonald@phy.cmich.edu> wrote: > I did some playing on the updated Korean War game > earlier. It seems that > the American/S. Korean/Japanese alliance is now > quite a bit stronger and > more aggressive. The N. Koreans and Chinese have a > much tougher slog > than last time I played. Try it with the Aggressive China option, where half the Chinese military just happens to be stationed on the PRC/DPRK border. I find that option, along with turning off the American support, to make for a tough game as Japan. Of course, the American AI doesn't send the Nimitz in, just the surface vessels, but if I can't figure out why, I'll station it closer, until it finally takes advantage of it. > One thing that I noticed is that, for some reason, > N. Korean armor > cannot attack S. Korean armor, or so it seemed. Made > it a bit of a > nightmare trying to contain the S. Korean armor > without taking massive > infantry casualties. I just looked through awls-rules.g and noticed that the following line: (armor-types armor-types 3) was missing from the acp-to-attack table. I'll check in a fix tonight. > Aside from this > problem (and some issues with ZOC's being exerted by > unseen units, which > is a Xconq problem, not a game module problem), the > game seemed to be > quite fun. I'm glad you liked it. The next one will be a ground war between Russia and China, which should pose less problems with the AI. Elijah __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ^ permalink raw reply [flat|nested] 56+ messages in thread
* More Feedback on AWLS: Korea 2006 2004-07-11 4:16 ` Elijah Meeks @ 2004-07-13 2:40 ` Eric McDonald 2004-07-13 3:48 ` Elijah Meeks 0 siblings, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-13 2:40 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 I see that Hans checked in the armor vs. armor stuff. That helped game play some. One of the most annoying things that I am encountering now is Chinese units being garrisoned in N. Korean cities by the Chinese AI. This prevents the N. Korea player from producing anything since the capacities of cities seem to be 1. Perhaps they could be made to be larger; even 2 would be a big improvement as long as the damn Chinese don't hog both slots (set the 'ai-war-garrison' at 1) and actually let their ally produce something. I would actually garrison the cities with N. Korean forces if they had a greater capacity. Also, the Kitty Hawk's improved carrier group seems to be pretty strong. I had a N. Korean coastal sub blasting it with torpedo after torpedo, but it didn't seem to be getting any weaker. And, finally, it seems that the big American submarines can very easily dispatch coastal subs even if the coastal subs are striking first. (Perhaps the sub counterattack modifiers should be lowered to something less than 100% in the 'counterattack' table.) When I played the N. Korean side, I had a problem with the American subs coming up and attacking my one port city (with cruise missiles presumably, even though those would probably be classified as firing), and I really couldn't do a whole lot about it. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: More Feedback on AWLS: Korea 2006 2004-07-13 2:40 ` More Feedback on " Eric McDonald @ 2004-07-13 3:48 ` Elijah Meeks 2004-07-13 4:42 ` Eric McDonald 0 siblings, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-13 3:48 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 > One of the most annoying things that I am > encountering now is Chinese > units being garrisoned in N. Korean cities by the > Chinese AI. This > prevents the N. Korea player from producing anything > since the > capacities of cities seem to be 1. Perhaps they > could be made to be > larger; even 2 would be a big improvement as long as > the damn Chinese > don't hog both slots (set the 'ai-war-garrison' at > 1) and actually let > their ally produce something. I would actually > garrison the cities with > N. Korean forces if they had a greater capacity. I just tested this, and even if your city is occupied, it should be able to produce ground units, because places have a terrain size of 12, while units have a terrain size of 50 (The unit, rather than being placed in the city, would be placed in the same hex but outside the city). I'm loathe to have more than one unit in a place, because of how XConq handles occupant combat. The problem that I see with this is in the creation of new naval units, which need to be placed in the city since, obviously, they can't go on the ground. > Also, the Kitty Hawk's improved carrier group seems > to be pretty strong. > I had a N. Korean coastal sub blasting it with > torpedo after torpedo, > but it didn't seem to be getting any weaker. I'm going to create wrecked-type table entries for sub-ship combat, to represent that a sub isn't fighting a carrier air wing when it hits a carrier group. I've already done this with air wings and adns in regard to damage from armor and infantry, (I'm not sure if the most recent check-in has this, though). There is, though, a method to this. Trying to sink the USS Kitty Hawk with a diesel sub is a poor bet at best. > And, finally, it seems that the big American > submarines can very easily > dispatch coastal subs even if the coastal subs are > striking first. > (Perhaps the sub counterattack modifiers should be > lowered to something > less than 100% in the 'counterattack' table.) I think the US side has too many nuclear subs in theatre. But, again, those greenwater fleets that the Koreans, Japanese and Chinese have are outclassed by their nuclear counterparts. It's part of the design that an American nuclear submarine outclasses a diesel-electric, but I think you're right, I've never seen a nuclear sub sunk by one, and that should happen occasionally. I'd prefer that XConq allowed dice larger than 13, because I'd give those coastal subs a 1d71-20 damage against all naval vessels, to represent the very real possibility (Though improbable) of scoring a critical hit on a capital ship. The other possibility is to split up surface and carrier groups, which are meant to represent a collection of ships, and implement Destroyer Squadrons, Cruisers and make the Carrier Air Wing a seperate unit transported by Carriers, which gives you a chance of sneaking your coastal sub through the fleet and sinking (Or critically damaging) that damned Kitty Hawk yourself. It'd make more sense, because as it stands there's only one carrier tech, which theoretically improves both fighters and the carrier itself, as well as better simulating battle, which could wipe out a carrier air wing while leaving the vessel itself unscathed (Right now Air Defense Networks damage carriers, somewhat silly in certain situations). But, I have a feeling the AI wouldn't deal so well with that. > When I played the N. > Korean side, I had a problem with the American subs > coming up and > attacking my one port city (with cruise missiles > presumably, even though > those would probably be classified as firing), and I > really couldn't do > a whole lot about it. That, to misquote Microsoft, is not a feature, but a bug. The subs in the game right now are all attack subs, no boomers, so they should only be able to attack naval units. I'll make sure to fix it. I'm implementing rules for nuclear weapons right now (As an optional rule), which'll include the introduction of missile subs, but I figured that cruise missiles weren't militarily effective enough to justify the trouble of modelling them. I thought about doing so with subs and surface fleets, giving them a fire attack that consumed 'Cruise missile' materials, but the AI doesn't like a unit that utilizes both Attack and Fire. The other option would be to create a 'Cruise Missile Volley' unit that ships could carry, but I find the inclusion of more than four units in a hex or as occupants to be aesthetically displeasing. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: More Feedback on AWLS: Korea 2006 2004-07-13 3:48 ` Elijah Meeks @ 2004-07-13 4:42 ` Eric McDonald 2004-07-13 17:20 ` Elijah Meeks 0 siblings, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-13 4:42 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > I just tested this, and even if your city is occupied, > it should be able to produce ground units, because > places have a terrain size of 12, while units have a > terrain size of 50 (The unit, rather than being placed > in the city, would be placed in the same hex but > outside the city). I wasn't seeing this, but maybe the cities were just out of materials. Those poor N. Koreans, you know.... > The problem that I see with this is in the > creation of new naval units, which need to be placed > in the city since, obviously, they can't go on the > ground. Right. And that was one of the worst cases. N. Korea only has one port city, and the moment a Chinese unit enters it that port is lost for naval (read, coastal submarine :-) production. And that somewhat diminishes N. Korea's ability to put S. Korean, Japanese, and American tonnage at the bottom of the Sea of Japan and E. China Sea. > I'm going to create wrecked-type table entries for > sub-ship combat, to represent that a sub isn't > fighting a carrier air wing when it hits a carrier > group. I've already done this with air wings and adns > in regard to damage from armor and infantry, (I'm not > sure if the most recent check-in has this, though). Sounds like a plan. Alternatively, you might be able to make an actual carrier air wing unit that can occupy carrier groups. > There is, though, a method to this. Trying to sink > the USS Kitty Hawk with a diesel sub is a poor bet at > best. Is there some implicit ASW capabilities in the group, like a screen of picket ships or maybe some ASW choppers on the carrier's deck? Even then, I think that might give an added detection boost against subs (choppers trawling sonar cans in the water, etc...), but if the sub does manage to get in and strike first, then what? >>And, finally, it seems that the big American >>submarines can very easily >>dispatch coastal subs even if the coastal subs are >>striking first. >>(Perhaps the sub counterattack modifiers should be >>lowered to something >>less than 100% in the 'counterattack' table.) > > > I think the US side has too many nuclear subs in > theatre. But, again, those greenwater fleets that the > Koreans, Japanese and Chinese have are outclassed by > their nuclear counterparts. It's part of the design > that an American nuclear submarine outclasses a > diesel-electric, Sure. I understand that. The nuclear sub should be tougher and meaner. I'm not saying that the little diesel boat should be able to run up and blow it away in one or two pops, but the little sub shouldn't necessarily be guaranteed to die if it gets first strike, either. > The other possibility is to split up surface and > carrier groups, which are meant to represent a > collection of ships, and implement Destroyer > Squadrons, Cruisers and make the Carrier Air Wing a > seperate unit transported by Carriers, I think the Carrier Air Wing is a good idea. It would decouple two different aspects of the present Carrier Group units, and save you from having to make a bunch more special wrecked types based on who does the killing. >which gives you > a chance of sneaking your coastal sub through the > fleet and sinking (Or critically damaging) that damned > Kitty Hawk yourself. Actually, I'm pretty much pro-Kitty Hawk, except when I'm playing "Kim Jung Il's advocate" (N. Korea is the default first side). Hopefully, I'll be able to make some time to play as some of the other sides later on. It would be cool if the Russians were in the game. Then I could defend that one chunk of land on the Amur river (IIRC) that they and the Chinese skirmished over a few decades ago. >It'd make more sense, because as > it stands there's only one carrier tech, which > theoretically improves both fighters and the carrier > itself, as well as better simulating battle, which > could wipe out a carrier air wing while leaving the > vessel itself unscathed (Right now Air Defense > Networks damage carriers, somewhat silly in certain > situations). But, I have a feeling the AI wouldn't > deal so well with that. It might do okay with it, if you allow carriers to produce carrier air wings over time. > them a fire attack that consumed 'Cruise missile' > materials, but the AI doesn't like a unit that > utilizes both Attack and Fire. Hmmm... That seems odd. It should do okay in that situation. I guess I will have to make a new Windows installer, so that you can see whether Hans' victim finder and hit-unit improvements help things any. One more thing that I forgot to mention earlier. It seems that the N. Korean cities can produce Carrier Groups but not Air Wings. That strikes me as a bit odd. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: More Feedback on AWLS: Korea 2006 2004-07-13 4:42 ` Eric McDonald @ 2004-07-13 17:20 ` Elijah Meeks 2004-07-13 17:28 ` Combat result tracking? Elijah Meeks 0 siblings, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-13 17:20 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 > > The problem that I see with this is in the > > creation of new naval units, which need to be > placed > > in the city since, obviously, they can't go on the > > ground. > > Right. And that was one of the worst cases. N. Korea > only has one port > city, and the moment a Chinese unit enters it that > port is lost for > naval (read, coastal submarine :-) production. And > that somewhat > diminishes N. Korea's ability to put S. Korean, > Japanese, and American > tonnage at the bottom of the Sea of Japan and E. > China Sea. The build code has been changed the most throughout the game, because there are certain combinations that the AI likes and, because I use wreck-typing, there were unforeseen consequences of build times over 1 turn in length. As it stands, the AI doesn't build military or civilian transports or carriers, but it seems pretty good at building a good mix of everything else. Looking back on it, though, I should have made sure to give cities a build-range of 1 (Or 2, I can't remember if 1 is same hex or 1 hex adjacent) for naval units. I think I ran into a problem with this, but I'll put it in and see. > Is there some implicit ASW capabilities in the > group, like a screen of > picket ships or maybe some ASW choppers on the > carrier's deck? The surface groups and carrier groups are considered to have abstracted integral destroyer and cruiser support. At this scale, considering a coastal sub can cover so much distance and make an attack in one turn, it seemed good to give them such a high counterattack. On reflection, though, I think you've shown that coastal subs deserve increased effectiveness, and I'm going to tweak the rules a bit to give them a better chance in the current ruleset. > > Even then, I think that might give an added > detection boost against subs > (choppers trawling sonar cans in the water, etc...), > but if the sub does > manage to get in and strike first, then what? snip > Sure. I understand that. The nuclear sub should be > tougher and meaner. > I'm not saying that the little diesel boat should be > able to run up and > blow it away in one or two pops, but the little sub > shouldn't > necessarily be guaranteed to die if it gets first > strike, either. I think with adding more nuance to the manner in which units are detected, and tweaking attack values, that there shouldn't be any counterattack for units attacked by a sub of either type. If you know where a sub is, it's a pretty fragile piece of machinery, but if you don't, it's not like it has to surface to fire. Now, if the counterattack code took into account see-chance, then I could give units a counterattack chance that would be defeated by the fact that it couldn't see the unit. Right now, if I guage the results properly, it doesn't, so removing counterattack altogether against subs seems the best course of action. > I think the Carrier Air Wing is a good idea. It > would decouple two > different aspects of the present Carrier Group > units, and save you from > having to make a bunch more special wrecked types > based on who does the > killing. Oh happy day, the chance to make another 30 units! As the onetime advocate of 800 unit games, I have to say it is a damn tedious process, but I think it's justified in this case, Carrier Groups are simply too abstracted right now. > It would be cool if the Russians were in the game. > Then I could defend > that one chunk of land on the Amur river (IIRC) that > they and the > Chinese skirmished over a few decades ago. I've been harassing Hans to give me a map of Eastern Russia and China (He has a Mac, which apparently has better design tools with the maps, which allows you to crop pieces of, in this case, the earth-50km.g map), with which the next scenario in the series will be a major land war between Mother Russia and the Chinese juggernaught (With the help of Kim Jong Il, leader of a newly united Korea). > One more thing that I forgot to mention earlier. It > seems that the N. > Korean cities can produce Carrier Groups but not Air > Wings. That strikes > me as a bit odd. The North Koreans shouldn't be able to produce Carrier Groups. I thought I turned that advance off for their side, I'll have to go back and check. There's some advance (I think 'Modern Surface Vessels') that needs to be turned on or the AI won't build anything (I don't know why), maybe that's it... But Air Wings can only be produced in Aerospace Facilities, which represent the infrastructure necessary to produce modern jets. Originally, Armor Groups, Advanced Armor Brigades and Air Defense Networks could only be built in Industrial Centers, but the AI didn't like that, so they're all built in cities, now. What's noticeably missing is a tech tree for armor and air. It's not so big a deal with infantry, but the North Koreans are fielding 30-50 year-old tanks and any fighters that China produces can't really match up with American and Japanese counterparts. Right now I abstract it by giving the North Koreans 'wrecked' and 'damaged' armor groups and their one Wrecked Air Wing (Mostly, from what I've read, composed of Mig-17 Fresco, Mig-19 Farmer and Mig-21 Fishbed fighters), but there should be at least three levels of Fighter Wing and Armor Group, like the Carriers are now. Only, when you account for experience, that's another 120 units. Did I say something about tedium... __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Combat result tracking? 2004-07-13 17:20 ` Elijah Meeks @ 2004-07-13 17:28 ` Elijah Meeks 2004-07-13 17:46 ` Eric McDonald 0 siblings, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-13 17:28 UTC (permalink / raw) To: xconq7 I'm tweaking submarines in AWLS: Korea 2006, and I thought, 'Gee, it'd be nice to know how many ships they're sinking' so that I could just set all the sides to AI and come back in twenty minutes. But now I'm thinking, this seems like a pretty good feature, anyway, and I'd think it would be relatively easy to implement. Maybe just a number of units destroyed? Also, are there any plans to add a little depth to the experience system? It would be nice to give more or less experience based on whether an attack was successful or not. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-13 17:28 ` Combat result tracking? Elijah Meeks @ 2004-07-13 17:46 ` Eric McDonald 2004-07-13 18:10 ` Hans Ronne 0 siblings, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-13 17:46 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 On Tue, 13 Jul 2004, Elijah Meeks wrote: > I'm tweaking submarines in AWLS: Korea 2006, and I > thought, 'Gee, it'd be nice to know how many ships > they're sinking' so that I could just set all the > sides to AI and come back in twenty minutes. Xconq internally keeps track of some attack stats. It would be nice to report these things. I have been considering adding them to the help system, as some additional information in a side summary or with the individual unit information (for the side). Probably it would be better to have a separate stats window though. > Also, are there any plans to add a little depth to the > experience system? It would be nice to give more or > less experience based on whether an attack was > successful or not. I've thought about this too, and plan to do something about it at some point, unless someone else beats me to it. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-13 17:46 ` Eric McDonald @ 2004-07-13 18:10 ` Hans Ronne 2004-07-13 18:57 ` Eric McDonald 0 siblings, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-13 18:10 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >On Tue, 13 Jul 2004, Elijah Meeks wrote: > >> I'm tweaking submarines in AWLS: Korea 2006, and I >> thought, 'Gee, it'd be nice to know how many ships >> they're sinking' so that I could just set all the >> sides to AI and come back in twenty minutes. > >Xconq internally keeps track of some attack stats. It would be >nice to report these things. I have been considering adding them >to the help system, as some additional information in a side >summary or with the individual unit information (for the side). >Probably it would be better to have a separate stats window >though. This is already available in the Mac interface. It has a History window that keeps track of combat results etc. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-13 18:10 ` Hans Ronne @ 2004-07-13 18:57 ` Eric McDonald 2004-07-13 19:10 ` Elijah Meeks 2004-07-13 23:01 ` Combat result tracking? Hans Ronne 0 siblings, 2 replies; 56+ messages in thread From: Eric McDonald @ 2004-07-13 18:57 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Tue, 13 Jul 2004, Hans Ronne wrote: > This is already available in the Mac interface. It has a History window > that keeps track of combat results etc. Well, that's nice. Are you, by any chance, interested in adding this feature to the Tcl/Tk interface, the UI of choice for most of us non-Mac "peasants"? Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-13 18:57 ` Eric McDonald @ 2004-07-13 19:10 ` Elijah Meeks 2004-07-13 20:23 ` Eric McDonald 2004-07-13 23:01 ` Combat result tracking? Hans Ronne 1 sibling, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-13 19:10 UTC (permalink / raw) To: Eric McDonald, Hans Ronne; +Cc: xconq7 --- Eric McDonald <mcdonald@phy.cmich.edu> wrote: > On Tue, 13 Jul 2004, Hans Ronne wrote: > > > This is already available in the Mac interface. It > has a History window > > that keeps track of combat results etc. > > Well, that's nice. Are you, by any chance, > interested in adding > this feature to the Tcl/Tk interface, the UI of > choice for most of > us non-Mac "peasants"? > No no no! Hans is only allowed to work on the SDL interface. Down with Tcl/Tk!!! Whoa, sorry about that, I've been drinkin a lot of coffee this morning... I've achieved a minor victory, by the way, thanks to your new wreck-typing table, Eric. You had to initialize units in order when you used the unit property (wreck-type), now I don't, so all the buildable units show up at the top of the Tcl/Tk list. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-13 19:10 ` Elijah Meeks @ 2004-07-13 20:23 ` Eric McDonald 2004-07-13 23:08 ` AI Motivation for non-combat units Elijah Meeks 0 siblings, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-13 20:23 UTC (permalink / raw) To: Elijah Meeks; +Cc: Hans Ronne, xconq7 On Tue, 13 Jul 2004, Elijah Meeks wrote: > No no no! Hans is only allowed to work on the SDL > interface. Down with Tcl/Tk!!! I agree with the "down with Tcl/Tk". I have pretty much made up my mind that I am not going to bother becoming proficient enough in Tcl/Tk to improve that interface. I like learning new languages and everything, but__ I really feel that Tkconq is not worth the hassle. I plan on digging into SDL once 7.5 has been released. > I've achieved a minor victory, by the way, thanks to > your new wreck-typing table, Eric. You had to > initialize units in order when you used the unit > property (wreck-type), now I don't, so all the > buildable units show up at the top of the Tcl/Tk list. That's good. It was kinda annoying having to scroll all over the place to pick out units. Another way to achieve the same effect is not to set an unit's wrecked type when you first define it. If you do something like: (add utype-1 wrecked-type utype-2) after all of the unit types have been defined. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* AI Motivation for non-combat units 2004-07-13 20:23 ` Eric McDonald @ 2004-07-13 23:08 ` Elijah Meeks 2004-07-14 0:33 ` Hans Ronne 0 siblings, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-13 23:08 UTC (permalink / raw) To: xconq7 I'm in the middle of implementing Carrier Air Wings in AWLS, and I just wondered, is it worth it? Once I'm done, carriers will no longer have an Attack or Fire Attack, so doesn't this mean the AI won't use them as a combat unit? I know it doesn't deal with transports well, but if I allow for disembarking of Carrier Air Wings (A somewhat logical event), won't it just bump into some piece of land somewhere and dump them right next to a Crack Reinforced Armor Group? Any hints on how to tag a Carrier so that the AI deals with it well after it's lost its attack? Should I leave it with a minor Attack or Fire Attack? __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AI Motivation for non-combat units 2004-07-13 23:08 ` AI Motivation for non-combat units Elijah Meeks @ 2004-07-14 0:33 ` Hans Ronne 0 siblings, 0 replies; 56+ messages in thread From: Hans Ronne @ 2004-07-14 0:33 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >I'm in the middle of implementing Carrier Air Wings in >AWLS, and I just wondered, is it worth it? Once I'm >done, carriers will no longer have an Attack or Fire >Attack, so doesn't this mean the AI won't use them as >a combat unit? I know it doesn't deal with transports >well, but if I allow for disembarking of Carrier Air >Wings (A somewhat logical event), won't it just bump >into some piece of land somewhere and dump them right >next to a Crack Reinforced Armor Group? > >Any hints on how to tag a Carrier so that the AI deals >with it well after it's lost its attack? Should I >leave it with a minor Attack or Fire Attack? I would suggest copying the Flattops game as far as possible. It is one of the best working Xconq modules, and it handles carriers very well. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-13 18:57 ` Eric McDonald 2004-07-13 19:10 ` Elijah Meeks @ 2004-07-13 23:01 ` Hans Ronne 2004-07-14 1:04 ` Skeezics Boondoggle 1 sibling, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-13 23:01 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >On Tue, 13 Jul 2004, Hans Ronne wrote: > >> This is already available in the Mac interface. It has a History window >> that keeps track of combat results etc. > >Well, that's nice. Are you, by any chance, interested in adding >this feature to the Tcl/Tk interface, the UI of choice for most of >us non-Mac "peasants"? I doubt it would be worth the trouble. The Mac interface has many features that I never use, and this is one of them. I think it would be more useful, particularly to game designers, if the output was saved to a file so that you could examine it afterwards. You do of course have the saved history events in the game file, but the History window output is more human-readable. Hans P.S. I share the view that we should limit our work on the tcltk interface. But then I said so already two years ago, and I have hacked the tcltk code a lot since then :-). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-13 23:01 ` Combat result tracking? Hans Ronne @ 2004-07-14 1:04 ` Skeezics Boondoggle 2004-07-14 1:20 ` Eric McDonald 0 siblings, 1 reply; 56+ messages in thread From: Skeezics Boondoggle @ 2004-07-14 1:04 UTC (permalink / raw) To: xconq7 On Tue, 13 Jul 2004, Hans Ronne wrote: > P.S. I share the view that we should limit our work on the tcltk interface. > But then I said so already two years ago, and I have hacked the tcltk code > a lot since then :-). as long as we poor unix users aren't completely left behind... the tcltk interface is playable even on my somewhat beefy sparc 20 (4x125mhz) as long as you're careful with "click-ahead"; it's plenty fast on my ultra2 (2x300mhz). i can't believe that anyone with a nGhz ppc or x86 box would have any performance complaints even with the tcltk version, but if sdl is faster/better/sweeter smelling/easier to build, then i'm all for it. seems there's been so much going on lately, and so many new features and bug fixes getting rolled in i haven't done a solaris build in quite some time. but i suppose i ought to try out the sdl version and see what state that's in, if it's buildable on solaris and if there's any feedback to be given... -- chris ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Combat result tracking? 2004-07-14 1:04 ` Skeezics Boondoggle @ 2004-07-14 1:20 ` Eric McDonald 2004-07-14 15:27 ` Counterfire Elijah Meeks 0 siblings, 1 reply; 56+ messages in thread From: Eric McDonald @ 2004-07-14 1:20 UTC (permalink / raw) To: Skeezics Boondoggle; +Cc: xconq7 Hi Chris, Skeezics Boondoggle wrote: > On Tue, 13 Jul 2004, Hans Ronne wrote: > as long as we poor unix users aren't completely left behind... As long as you guys are still out there, I am interested in supporting your platforms. Unfortunately, I have to rely on the feedback of others to support non-Linux systems, since I don't have any working Sparcs, etc... right now. (I do have an old version of Solaris for x86 floating somewhere; I suppose I could try installing that in a virtual machine and see what happens.) As far as SDL goes, it looks like you might have to build it from source on Solaris boxen. I didn't see any Solaris binaries at http://www.libsdl.org >the tcltk > interface is playable even on my somewhat beefy sparc 20 (4x125mhz) as > long as you're careful with "click-ahead"; it's plenty fast on my ultra2 > (2x300mhz). i can't believe that anyone with a nGhz ppc or x86 box would > have any performance complaints even with the tcltk version, but if sdl is > faster/better/sweeter smelling/easier to build, then i'm all for it. For me, the main advantage to the SDL interface would be not having to hop back and forth between Tcl and C, which is a slight PITA when doing development and debugging, IMO. Also, in terms of configure/make, I have had to do quite a bit a work to support the building of Tkconq on diverse platforms, because different '{tcl,tk}Config.sh' set different important variables on different platforms. The 'sdl-config' scripts are much more uniform in the way they report things. Another consideration is that Tkconq is not a pure Tk app; it has some raw X11 calls as well, and this has led to deficient functionality on non-X11 platforms. I wouldn't classify the performance of the Tcl/Tk interface as being totally smooth under Linux on my 1.4 GHz Athlon XP+. In a virtual machine (on the Linux host) running Windows XP, the performance is not that good at all (I haven't tried improving the nice level of the VM to see how is just a result of the lack of scheduler attention, though). > seems there's been so much going on lately, and so many new features and > bug fixes getting rolled in i haven't done a solaris build in quite some > time. but i suppose i ought to try out the sdl version and see what state > that's in, if it's buildable on solaris and if there's any feedback to be > given... That would be great. I also did a pretty massive overhaul of the configure/make stuff, and I would like to know if anything broke on Solaris. Thanks, Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Counterfire 2004-07-14 1:20 ` Eric McDonald @ 2004-07-14 15:27 ` Elijah Meeks 2004-07-15 16:04 ` Counterfire Eric McDonald 0 siblings, 1 reply; 56+ messages in thread From: Elijah Meeks @ 2004-07-14 15:27 UTC (permalink / raw) To: xconq7 There was some discussion of giving units the ability to do counterbattery work (A unit fires and then another unit with enough ACP and in range returns fire). I'd love to see a 'counterfire' table and an 'overwatch' table, which would be something akin to counterfire, except that the responding unit would actually fire first with effects (Unit destruction, ACP-to-defend) that may cancel the initiated attack. So how much of a pipe dream is this? __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Counterfire 2004-07-14 15:27 ` Counterfire Elijah Meeks @ 2004-07-15 16:04 ` Eric McDonald 0 siblings, 0 replies; 56+ messages in thread From: Eric McDonald @ 2004-07-15 16:04 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > There was some discussion of giving units the ability > to do counterbattery work (A unit fires and then > another unit with enough ACP and in range returns > fire). I'd love to see a 'counterfire' table and an > 'overwatch' table, which would be something akin to > counterfire, except that the responding unit would > actually fire first with effects (Unit destruction, > ACP-to-defend) that may cancel the initiated attack. > > So how much of a pipe dream is this? Well, I think it is primarily an issue of finding time to explore these ideas further and write some code. As far as the overwatch concept was concerned, this could probably best implemented in terms of the existing ZOC, or perhaps some new type of zone, maybe a zone of overwatch (ZOO?), which would have a max range defined by a table, but would also be limited by the unit's vision range. Currently, I am working on an extension of the help system, which allows help files to be automatically generated for every game in the Xconq games library. The help files can be produced in either plain text or HTML format. I am also making the framework generic, so that support for other formats can easily be added in the future. I still have a lot of work to do on this, so I will probably be occupied with it for the next few weeks. When I finish, I will put all the HTML help files for all the games in the library on the Xconq Web site. Eric ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AI Help 2004-07-09 17:45 ` AI Help Elijah Meeks 2004-07-09 18:15 ` Hans Ronne @ 2004-07-11 9:44 ` Jim Kingdon 2004-07-11 10:08 ` Hans Ronne 1 sibling, 1 reply; 56+ messages in thread From: Jim Kingdon @ 2004-07-11 9:44 UTC (permalink / raw) To: xconq7 > I'm wondering, though, if there's a way to take a little pressure off > the coders and put it into the hands of the designers. Seems like a good thing to have. I especially like the idea of being able to tweak the AI with some parameters, and play the resulting AI's against each other. That's the big problem with oplayer/mplayer/etc - it is just too hard to create new AI's so we haven't really been using the different AI's to experiment with different techniques. I do kind of wonder whether the designers will necessarily make the most advantageous choices. Did the designers of the standard game anticipate that the optimal strategy was to build no ships, for example? (in my experience that is true, although of course I could be biased from too much play against the AI and almost none against humans). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AI Help 2004-07-11 9:44 ` AI Help Jim Kingdon @ 2004-07-11 10:08 ` Hans Ronne 2004-07-12 18:07 ` Jim Kingdon 0 siblings, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-11 10:08 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 >> I'm wondering, though, if there's a way to take a little pressure off >> the coders and put it into the hands of the designers. > >Seems like a good thing to have. I especially like the idea of being >able to tweak the AI with some parameters, and play the resulting AI's >against each other. That's the big problem with oplayer/mplayer/etc - >it is just too hard to create new AI's so we haven't really been using >the different AI's to experiment with different techniques. > >I do kind of wonder whether the designers will necessarily make the >most advantageous choices. Did the designers of the standard game >anticipate that the optimal strategy was to build no ships, for >example? (in my experience that is true, although of course I could be >biased from too much play against the AI and almost none against >humans). True. One could of course implement this as setup options. The main problem in that case is that you also have to write new interface code, and we have several interfaces. Just adding a new doctrine or GDL table that is set from within the game file is much easier. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: AI Help 2004-07-11 10:08 ` Hans Ronne @ 2004-07-12 18:07 ` Jim Kingdon 0 siblings, 0 replies; 56+ messages in thread From: Jim Kingdon @ 2004-07-12 18:07 UTC (permalink / raw) To: xconq7 > True. One could of course implement this as setup options. The main problem > in that case is that you also have to write new interface code, and we have > several interfaces. Just adding a new doctrine or GDL table that is set > from within the game file is much easier. Agreed on this. Just because game designers might get things wrong isn't a reason to avoid having the feature. Sure, I can imagine all kinds of future directions (e.g. a GUI doctrine editor, decoupling the doctrine from the game design, etc), but we need to start somewhere, and putting the hints in question into doctrine or GDL tables is the right place to start. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-09 16:54 ` Elijah Meeks 2004-07-09 17:00 ` Wrecking Issues Elijah Meeks 2004-07-09 17:45 ` AI Help Elijah Meeks @ 2004-07-09 18:09 ` Hans Ronne 2004-07-11 6:01 ` Jim Kingdon 2 siblings, 1 reply; 56+ messages in thread From: Hans Ronne @ 2004-07-09 18:09 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >> > The fix is to count the transport's movement >> against the passengers as well. >If this was introduced as a true/false table, it >should work fine. This way it could be turned on in >cases where it made sense and left alone in games >where it doesn't. Right? I think any change to the basic action/move code would have to be implemented as a GDL option, in order not to break existing games. Regarding this particular idea, there are some problems due to how the kernel works. The kernel doesn't count "time" or movement points. Instead, it counts action points (acps). if you want to limit the ability of an occupant to move because its transport already moved, you would have to bleed off its acps. Now, that would work fine in games where units have many acps and use one per move. However, a more common situation is that the unit only has one or two acps, and is able to move several cells using one acp (how far is determined by the GDL variable speed). In that case, the unit might not be able to move at all if you take away an acp. Another problem is that operting ranges are important, both in the task execution code and in the AI code. And some of the derived variables are precomputed to save time. I think that with the proposed hack we would see many more messages of the type "Your fighter has run out of fuel and crashed." Then there is the point I already alluded to, and that is that being able to do rapid forward deployments makes most games more interesting. There is nothing more boring than a stalemate "West Front" trench war situation. I am not saying that a transport hack is impossible, but it would take a lot of work to get it right. I think that in the case of the galaxy2 game, the basic problem is that planets are to esy to capture, regardless of how you go about it. For the bungee paratroopers that this thread started with, the obvious fix would seem to be to require that they leave the bomber before being able to attack. This is, after all, how real paratroopers work (jump first, then shoot). And there is already a GDL variable, occupant-combat, which can be used to limit the ability of occupants to fight. Setting it to 0 instead of the default 100 for (infantry bomber) should do the trick. Hans ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Just say no to bungee paratroopers. 2004-07-09 18:09 ` Just say no to bungee paratroopers Hans Ronne @ 2004-07-11 6:01 ` Jim Kingdon 0 siblings, 0 replies; 56+ messages in thread From: Jim Kingdon @ 2004-07-11 6:01 UTC (permalink / raw) To: xconq7 > Then there is the point I already alluded to, and that is that being able > to do rapid forward deployments makes most games more interesting. There is > nothing more boring than a stalemate "West Front" trench war situation. Good point. All too many xconq games verge on this problem already ("yeah, I'm pretty sure I'll win, but it is too boring to prove it"), so we should be wary of anything which might make it worse. ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2004-07-15 14:03 UTC | newest] Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1088896371.19592.ezmlm@sources.redhat.com> 2004-07-03 23:21 ` Just say no to bungee paratroopers Henry J. Cobb 2004-07-03 23:55 ` Eric McDonald 2004-07-04 0:55 ` Hans Ronne 2004-07-04 1:39 ` Eric McDonald 2004-07-04 3:17 ` Hans Ronne 2004-07-04 1:14 ` Jim Kingdon 2004-07-04 3:37 ` Henry J. Cobb 2004-07-04 6:13 ` Henry J. Cobb 2004-07-04 15:13 ` Hans Ronne 2004-07-04 18:01 ` Jim Kingdon 2004-07-04 21:38 ` Hans Ronne 2004-07-04 21:57 ` mskala 2004-07-05 3:30 ` Hans Ronne 2004-07-09 1:17 ` Henry J. Cobb [not found] ` <40EDFCDE.9000902@phy.cmich.edu> 2004-07-09 3:37 ` Henry J. Cobb [not found] ` <40EEAD66.50109@phy.cmich.edu> 2004-07-09 16:02 ` Henry J. Cobb 2004-07-09 16:10 ` Hans Ronne 2004-07-10 4:38 ` Henry J. Cobb 2004-07-12 1:25 ` Carrier groups Henry J. Cobb 2004-07-12 3:27 ` Hans Ronne 2004-07-12 7:00 ` Henry J. Cobb 2004-07-09 16:47 ` Just say no to bungee paratroopers Jim Kingdon 2004-07-09 16:54 ` Elijah Meeks 2004-07-09 17:00 ` Wrecking Issues Elijah Meeks 2004-07-09 17:16 ` Eric McDonald 2004-07-10 21:40 ` Eric McDonald 2004-07-09 17:45 ` AI Help Elijah Meeks 2004-07-09 18:15 ` Hans Ronne 2004-07-09 18:26 ` Eric McDonald 2004-07-09 19:03 ` Elijah Meeks 2004-07-09 19:45 ` Side Selection Bugs Elijah Meeks 2004-07-09 19:46 ` Hans Ronne 2004-07-11 1:47 ` AWLS: Korea 2006 Eric McDonald 2004-07-11 4:16 ` Elijah Meeks 2004-07-13 2:40 ` More Feedback on " Eric McDonald 2004-07-13 3:48 ` Elijah Meeks 2004-07-13 4:42 ` Eric McDonald 2004-07-13 17:20 ` Elijah Meeks 2004-07-13 17:28 ` Combat result tracking? Elijah Meeks 2004-07-13 17:46 ` Eric McDonald 2004-07-13 18:10 ` Hans Ronne 2004-07-13 18:57 ` Eric McDonald 2004-07-13 19:10 ` Elijah Meeks 2004-07-13 20:23 ` Eric McDonald 2004-07-13 23:08 ` AI Motivation for non-combat units Elijah Meeks 2004-07-14 0:33 ` Hans Ronne 2004-07-13 23:01 ` Combat result tracking? Hans Ronne 2004-07-14 1:04 ` Skeezics Boondoggle 2004-07-14 1:20 ` Eric McDonald 2004-07-14 15:27 ` Counterfire Elijah Meeks 2004-07-15 16:04 ` Counterfire Eric McDonald 2004-07-11 9:44 ` AI Help Jim Kingdon 2004-07-11 10:08 ` Hans Ronne 2004-07-12 18:07 ` Jim Kingdon 2004-07-09 18:09 ` Just say no to bungee paratroopers Hans Ronne 2004-07-11 6:01 ` Jim Kingdon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).