* Three thoughts @ 2004-08-20 16:22 mskala 2004-08-20 18:34 ` Eric McDonald 2004-08-22 3:09 ` Hans Ronne 0 siblings, 2 replies; 45+ messages in thread From: mskala @ 2004-08-20 16:22 UTC (permalink / raw) To: xconq7 I've been busy with other things and not really playing or thinking about Xconq much recently, but here are three interface thoughts, two of them TCL/TK specific: * If firing at specific units were to be a big part of some game, then it would be nice if it were easier to designate specific units when there are many of them, or nested occupant/transports, in a cell. As it is, even at the deepest level of zoom it's quite difficult to click precisely on one unit if there are a lot of them in the cell. One way to deal with this might be for an interface to be able to give me a dialog box with a list of units in the cell. * In the current TCL/TK interface (well, current as of my last CVS update), connection terrain is sometimes not drawn when at the highest zoom level unless "grid" is turned on. The "Lord of the Rings" game is a good one for observing this - zoom in on a section of the map where there are roads, and the roads suddenly disappear when you hit maximum zoom. They can be made to appear and disappear by turning "grid" on and off. And yet it seems to work correctly in the standard game regardless of the state of "grid". * I would really, really like to disable the automatic scrolling based on mouse position in the TCL/TK interface, and I sure hope that "feature" hasn't been incorporated into other interfaces. It makes games that require close-in zooming almost unplayable. This will probably be my project next time I have time to spend hacking on Xconq. As a general principle, I *never* want mouse position (without click) to change my interface state, especially not in a way that's hard to reverse. It's especially annoying because common actions require me to move the pointer between the map area and the menus or action buttons, and every time I do that I have to move the pointer through the magic scroll zone and risk getting a scroll that I didn't want. Making the auto-scroll user-settable would be okay, I suppose, but I'd keep the setting turned off all the time myself. Why can't we have scroll bars like everybody else? -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 16:22 Three thoughts mskala @ 2004-08-20 18:34 ` Eric McDonald 2004-08-20 21:17 ` Andreas Bringedal 2004-08-22 3:09 ` Hans Ronne 1 sibling, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-20 18:34 UTC (permalink / raw) To: mskala; +Cc: xconq7 Hi Matthew, long time, no see, On Fri, 20 Aug 2004 mskala@ansuz.sooke.bc.ca wrote: > * If firing at specific units were to be a big part of some game, then it > would be nice if it were easier to designate specific units when there are > many of them, or nested occupant/transports, in a cell. As it is, even at > the deepest level of zoom it's quite difficult to click precisely on one > unit if there are a lot of them in the cell. One way to deal with this > might be for an interface to be able to give me a dialog box with a list > of units in the cell. I think that Elijah may have also mentioned this last year, and I completely agree. Although I really don't want to do much Tcl/Tk hacking, this is something that I have been contemplating adding, depending on whether I let units carry armor (and weapons, once the necessary 'hit-chance' and 'damage' modifier tables are in place). Probably such a window could be brought up with the "i" key, since I think that is supposed to go to the next occ, IIRC. > myself. Why can't we have scroll bars like everybody else? Unless I am dreaming, I think the Tcl/Tk interface may have had scrollbars at some point, or, at least, I thought they were commented out in the Tcl code. I think Hans did improve the keyboard navigation in this regard a while back ago. Something about using the arrow keys or the numeric keypad, IIRC. You might want to see if you can dig up that mail; it might make your map navigation a little more pleasant. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 18:34 ` Eric McDonald @ 2004-08-20 21:17 ` Andreas Bringedal 2004-08-20 21:28 ` Eric McDonald 2004-08-20 22:03 ` Elijah Meeks 0 siblings, 2 replies; 45+ messages in thread From: Andreas Bringedal @ 2004-08-20 21:17 UTC (permalink / raw) To: xconq7 > On Fri, 20 Aug 2004 mskala@ansuz.sooke.bc.ca wrote: > > > * If firing at specific units were to be a big part of some game, then it > > would be nice if it were easier to designate specific units when there are > > many of them, or nested occupant/transports, in a cell. As it is, even at > > the deepest level of zoom it's quite difficult to click precisely on one > > unit if there are a lot of them in the cell. One way to deal with this > > might be for an interface to be able to give me a dialog box with a list > > of units in the cell. I've never understood why the interface has been so low on the priority list. Back when I played Xconq 5.4 the interface was ok. Today I can't bring myself to play the game anymore due to the interface and to a lesser degree the high dencity of cities. But since I don't program I can't really complain. I just wanted to say that with a better interface you'd get a whole lot more players and perhaps programmers. Andreas ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 21:17 ` Andreas Bringedal @ 2004-08-20 21:28 ` Eric McDonald 2004-08-20 23:57 ` Andreas Bringedal 2004-08-20 22:03 ` Elijah Meeks 1 sibling, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-20 21:28 UTC (permalink / raw) To: Andreas Bringedal; +Cc: xconq7 On Fri, 20 Aug 2004, Andreas Bringedal wrote: > Today I can't bring myself to play the game anymore due to the >interface and to a lesser degree the high dencity of cities. But When you refer to the high density of cities, which game are you talking about? The Standard game? Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 21:28 ` Eric McDonald @ 2004-08-20 23:57 ` Andreas Bringedal 2004-08-21 1:21 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Andreas Bringedal @ 2004-08-20 23:57 UTC (permalink / raw) To: xconq7 > On Fri, 20 Aug 2004, Andreas Bringedal wrote: > > > Today I can't bring myself to play the game anymore due to the > >interface and to a lesser degree the high dencity of cities. But > > When you refer to the high density of cities, which game are you > talking about? The Standard game? > > Eric Yes the standard game, but also some of the others. In one game I had seemingly half of all hexes covered with units. It became a chore moving the units. A ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 23:57 ` Andreas Bringedal @ 2004-08-21 1:21 ` Eric McDonald 2004-08-21 4:35 ` Jim Kingdon 2004-08-21 20:38 ` Jim Kingdon 0 siblings, 2 replies; 45+ messages in thread From: Eric McDonald @ 2004-08-21 1:21 UTC (permalink / raw) To: Andreas Bringedal; +Cc: xconq7 Andreas Bringedal wrote: > Yes the standard game, but also some of the others. In one game I had seemingly half of all hexes covered with units. It became a > chore moving the units. In the case of the Standard game, you can tweak the 'independent-density' table in 'lib/standard.g'. These values are per 10000 cells. If you find a set of values that you think is more reasonable, you could report it to the list, and either the Standard game could be changed or else a "Sparse Cities" variant could be created. The table looks like this: (table independent-density (town plains 3000) (town (desert forest mountains) 500)) As for other games, it is true that Bellum starts out with quite a few units inside the country borders, but things generally thin out as time progresses in that game. The Advances game is perhaps the worst culprit in terms of acquiring more units than you actually want to deal with. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-21 1:21 ` Eric McDonald @ 2004-08-21 4:35 ` Jim Kingdon 2004-08-21 20:38 ` Jim Kingdon 1 sibling, 0 replies; 45+ messages in thread From: Jim Kingdon @ 2004-08-21 4:35 UTC (permalink / raw) To: mcdonald; +Cc: anbring, xconq7 > In the case of the Standard game, you can tweak the > 'independent-density' table in 'lib/standard.g'. These values are per > 10000 cells. Hmm. This had been 100/0, but now is it 600/100 (depending on the terrain type). I had always imagined more independent cities made the game more interesting (because it gives you a reason to explore, rather than just moving units over vast stretches of empty terrain). But maybe I was wrong and there are downsides, like: * Too many units to move * Tilts the balance in favor of the human rather than the AI in human vs. AI games * Makes it too easy to move bombers around the world. Without all those independent towns to capture, you'd need to build bases, build carriers, and/or rely less on bombers. So yes, please do try changing that parameter back to 100 and let us know how it goes. We could either change it back in the main game, and/or make a variant. 2000-02-23 Stan Shebs <shebs@shebs.cnchost.com> * stdunit.g: Add more independent towns. Index: stdunit.g =================================================================== RCS file: /cvs/xconq/xconq/lib/stdunit.g,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** stdunit.g 28 Apr 1999 19:36:51 -0000 1.1 --- stdunit.g 23 Feb 2000 13:53:34 -0000 1.2 *************** *** 564,570 **** (* plains 40) ) ! (table independent-density (town plains 100)) (add land country-people-chance 90) (add plains country-people-chance 100) --- 564,574 ---- (* plains 40) ) ! (table independent-density ! ;; Most additional towns are in favorable terrain. ! (town plains 600) ! (town (desert forest mountains) 100) ! ) (add land country-people-chance 90) (add plains country-people-chance 100) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-21 1:21 ` Eric McDonald 2004-08-21 4:35 ` Jim Kingdon @ 2004-08-21 20:38 ` Jim Kingdon 1 sibling, 0 replies; 45+ messages in thread From: Jim Kingdon @ 2004-08-21 20:38 UTC (permalink / raw) To: mcdonald; +Cc: anbring, xconq7 > The Advances game is perhaps the worst culprit in terms of acquiring > more units than you actually want to deal with. Yeah, that's been my experience with Advances. Oddly enough, one of the games which I found tedious was a human vs. human game with Hans. He was having quite a good time. So I suppose there is no accounting for taste... I suppose the fact that he was winning didn't help :-P. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 21:17 ` Andreas Bringedal 2004-08-20 21:28 ` Eric McDonald @ 2004-08-20 22:03 ` Elijah Meeks 2004-08-20 23:27 ` Eric McDonald 1 sibling, 1 reply; 45+ messages in thread From: Elijah Meeks @ 2004-08-20 22:03 UTC (permalink / raw) To: Andreas Bringedal, xconq7 > > On Fri, 20 Aug 2004 mskala@ansuz.sooke.bc.ca > wrote: > > > > > * If firing at specific units were to be a big > part of some game, then it > > > would be nice if it were easier to designate > specific units when there are > > > many of them, or nested occupant/transports, in > a cell. As it is, even at > > > the deepest level of zoom it's quite difficult > to click precisely on one > > > unit if there are a lot of them in the cell. > One way to deal with this > > > might be for an interface to be able to give me > a dialog box with a list > > > of units in the cell. > > I've never understood why the interface has been so > low on the priority list. Back when I played Xconq > 5.4 the interface was ok. > Today I can't bring myself to play the game anymore > due to the interface and to a lesser degree the high > dencity of cities. But > since I don't program I can't really complain. I > just wanted to say that with a better interface > you'd get a whole lot more players > and perhaps programmers. I know the feeling. I didn't include city improvements in Opal, even though they'd improve the game, just because they end up making it look so cluttered*. And the TCL/TK interface is, let's face it, so ugly in comparison to the Mac interface and even the stripped down SDL interface (Which I'm still in love with. Really. When I play XConq in SDL, it looks like a *game*). Another thing to think about is the opening screen, which relates especially to Eric's game-image feature. If we could revamp that, then players would probably have an easier time choosing games and seeing something they like. *This, like Eric's items, would be fixed by an occupant dialog box. I've tried to work with units as items, though, and found difficulty with setting the game up so that a unit could pick up another unit. It seems like I have to give Item units ACP and movement, which is an annoyance to the AI and player and uglier gameplay. Anyone have any suggestions? I'd love an item-demo.g and, of course, if Eric throws in static improvements, I can rewrite Cast Iron Life, and even change the experience system in AWLS so that a unit carries an Experience unit that provides bonuses, rather than have five different units for each experience level. But that would probably necessitate an AI-recommendation table for building and and and... Ah, being a needy XConq designer sure is the life. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 22:03 ` Elijah Meeks @ 2004-08-20 23:27 ` Eric McDonald 2004-08-21 1:17 ` mskala 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-20 23:27 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 On Fri, 20 Aug 2004, Elijah Meeks wrote: > Another thing to think about is the opening screen, > which relates especially to Eric's game-image feature. I think Hans might have done that, actually. > *This, like Eric's items, would be fixed by an > occupant dialog box. I've tried to work with units as > items, though, and found difficulty with setting the > game up so that a unit could pick up another unit. I think that is another area that needs some work. >It > seems like I have to give Item units ACP and movement, > which is an annoyance to the AI and player and uglier > gameplay. Anyone have any suggestions? I'd see what Matthew Skala came up with. He was working on "cow patties" for a while. >I'd love an > item-demo.g and, of course, if Eric throws in static > improvements, I can rewrite Cast Iron Life, and even > change the experience system in AWLS so that a unit > carries an Experience unit that provides bonuses, > rather than have five different units for each > experience level. Interesting idea. I hadn't thought of it this way. I guess you're saying that you have some interest in some new modifier tables ('occupant-adds-hit-chance', 'occupant-adds-damage', 'occupant-multiplies-hit-chance', etc...)? Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 23:27 ` Eric McDonald @ 2004-08-21 1:17 ` mskala 2004-08-21 2:31 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: mskala @ 2004-08-21 1:17 UTC (permalink / raw) To: Eric McDonald; +Cc: Elijah Meeks, xconq7 On Fri, 20 Aug 2004, Eric McDonald wrote: > > seems like I have to give Item units ACP and movement, > > which is an annoyance to the AI and player and uglier > > gameplay. Anyone have any suggestions? > > I'd see what Matthew Skala came up with. He was working on "cow > patties" for a while. I couldn't get it to work. Like Elijah, I found that I had to give the "item" units some ACP and movement capabilities, but that still didn't allow me to get the kind of behaviour I really wanted. As I think I mentioned at the time, I had a lot of trouble preventing the item units from constantly waking up and demanding the user's attention even when the user didn't want them to do anything but sit there. I also wanted my item units to be indestructible - so they'd end up just sitting on the ground if their transport was destroyed for *any* reason - and it proved tricky to cover all the cases for that. When the fancy wrecking behaviour started to be defined, I realised that if I changed my game concept a little I could use fancy wrecking instead of item objects (basically, have one unit type for "has item" and one for "doesn't have item", although it also meant changing my vision of what that signified), and produce a more fun result. Wrecking seemed to be in a lot of flux and then my workload at school started to ramp up and so I decided to leave that project alone for a while, hoping that by the time I got back to it the fancy wrecking behaviour would have gelled into something I could use. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-21 1:17 ` mskala @ 2004-08-21 2:31 ` Eric McDonald 2004-08-21 4:33 ` mskala 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-21 2:31 UTC (permalink / raw) To: mskala; +Cc: xconq7 mskala@ansuz.sooke.bc.ca wrote: > On Fri, 20 Aug 2004, Eric McDonald wrote: > When the fancy wrecking behaviour started to be defined, I realised that > if I changed my game concept a little I could use fancy wrecking instead > of item objects (basically, have one unit type for "has item" and one for > "doesn't have item", although it also meant changing my vision of what > that signified), and produce a more fun result. Wrecking seemed to be in > a lot of flux and then my workload at school started to ramp up and so I > decided to leave that project alone for a while, hoping that by the time I > got back to it the fancy wrecking behaviour would have gelled into > something I could use. Do you find the wrecking and 'change-type' behavior to now be suitable for your needs, or is an ingredient still missing? (Also, I think you were the one who requested the 'remove-list' (as opposed to 'remove') capability, IIRC. That capability now exists in Xconq.) Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-21 2:31 ` Eric McDonald @ 2004-08-21 4:33 ` mskala 0 siblings, 0 replies; 45+ messages in thread From: mskala @ 2004-08-21 4:33 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 On Fri, 20 Aug 2004, Eric McDonald wrote: > Do you find the wrecking and 'change-type' behavior to now be suitable > for your needs, or is an ingredient still missing? Well, I haven't really decided yet exactly how I want to use the new features, and until I do, I won't really know if they do what I want, but my impression is that they'll probably be more than sufficient. > (Also, I think you were the one who requested the 'remove-list' (as > opposed to 'remove') capability, IIRC. That capability now exists in Xconq.) Yes - thanks. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-20 16:22 Three thoughts mskala 2004-08-20 18:34 ` Eric McDonald @ 2004-08-22 3:09 ` Hans Ronne 2004-08-22 6:38 ` Item Units Elijah Meeks 2004-08-22 14:00 ` Three thoughts mskala 1 sibling, 2 replies; 45+ messages in thread From: Hans Ronne @ 2004-08-22 3:09 UTC (permalink / raw) To: mskala; +Cc: xconq7 >* If firing at specific units were to be a big part of some game, then it >would be nice if it were easier to designate specific units when there are >many of them, or nested occupant/transports, in a cell. As it is, even at >the deepest level of zoom it's quite difficult to click precisely on one >unit if there are a lot of them in the cell. Firing at selected units is impossible unless you are using the Mac interface. See my post "The selective fire-at command". Fixing the tcltk interface so that you can do selective fire-at is on my todo list. It has never been possible to target occupants directly in Xconq, though I believe I suggested earlier this year that we should consider making it possible. As for selecting units in general, I never had any problems at the highest zoom level. What game are you playing, and how many units are there in the cell? >* In the current TCL/TK interface (well, current as of my last CVS >update), connection terrain is sometimes not drawn when at the highest >zoom level unless "grid" is turned on. I'll look into this when I have time. Graphics at the highest zoom level is not fully developed in any of the interfaces, so there are various glitches. >getting a scroll that I didn't want. Making the auto-scroll user-settable >would be okay, I suppose, but I'd keep the setting turned off all the time >myself. Why can't we have scroll bars like everybody else? Maybe you should get a Mac :-). Not only does it have selective fire-at, but this other feature that you are asking for (scrollbars that you can turn on or off) is also available in the Mac interface. Not that I ever use them. A better alternative to scrollbars is scrolling of the map using the arrow keys. I ported that feature from the Mac interface to the tcltk interface some time ago. If you use Windows, you can also scroll diagonally by using numbers 1-9 on the numeric keypad. For some reason, I couldn't get the numeric keypad to work properly under Linux, though. Hans ^ permalink raw reply [flat|nested] 45+ messages in thread
* Item Units 2004-08-22 3:09 ` Hans Ronne @ 2004-08-22 6:38 ` Elijah Meeks 2004-08-22 9:37 ` Eric McDonald 2004-08-22 14:00 ` Three thoughts mskala 1 sibling, 1 reply; 45+ messages in thread From: Elijah Meeks @ 2004-08-22 6:38 UTC (permalink / raw) To: xconq7 (Figured it deserved it's own thread) Eric, you'd mentioned additional tables and we've talked about the cow patties. It seems like the framework's in place for items, just add a fifth entry to the ferry-on-entry/departure tables that's "Full" (Or something similar). I'd thought, when I first worked with items as occupants, that "over-all" would've worked, but it didn't. "Full" would mean that the transport paid all necessary ACP costs for the occupant to move into the hex and load onto the unit. Problems: The AI, of course, would likely not get that these units were useful, and would probably pick them up and drop them at random. An initial workaround would be to set the ferry-on-entry to "Full" and the ferry-on-departure to over-nothing, which means that once the AI orders a legitimate unit to pick up an item, it's stuck with it. Not the best solution, of course, but it would work. I'd like to introduce three item types in Opal: Weapon, Armor and Gear. They'd come in two flavors, fine and magical. So far, so good (Heck, only six new units, I'll never reach 1000 like this). But we've all seen how a unit looks with three occupants, especially when it occupies a cell with another unit or two. Without an occupant dialog box, it'd just be too cluttered. Building each magic sword by hand is also a pain. So I'd love to see initial-occupant and occupant-when-created tables that call for, in the case of the former, a unit placed with said occupant and, in the case of the latter, an extra build to produce, if the builder is able, the additional occupants. The tables would be percentage based, especially useful with the initial-occupant table, because then some of your swordsmen might start with fine weapons or magic armor, adding a little randomness to the game. If the percentage is higher than 100, it would indicate more than one occupant, so that, say, a huge city could be set at: (initial-occupant (hugecity magicsword 350) ) And would always start with three magic swords with a 50% chance of a fourth. Tablewise, occupant-adds-hit-chance/fire-hit-chance, occupant-adds-acp, occupant-adds-damage and occupant-adds-hp would be a great start. And neural nets, and 3D units, and a fully 3D globe, and XBox support, and and and... _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Item Units 2004-08-22 6:38 ` Item Units Elijah Meeks @ 2004-08-22 9:37 ` Eric McDonald 2004-08-24 1:43 ` Lincoln Peters 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-22 9:37 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > It seems like the > framework's in place for items, just add a fifth entry > to the ferry-on-entry/departure tables that's "Full" > (Or something similar). I'd thought, when I first > worked with items as occupants, that "over-all" > would've worked, but it didn't. "Full" would mean > that the transport paid all necessary ACP costs for > the occupant to move into the hex and load onto the > unit. I think one problem with cow patties is that ideally one would like them to be actionless, and hence they could not be selected as active units. So, having a transport offer to pay for everything would not do much good for items that cannot even be selected as actors. A dedicated pickup/get command like most good dungeon games have would be nice. Another possibility would be to get Xconq's control range stuff working (if it's not already; I haven't experimented with it, but there does appear to be some support for it in the code). Then set the control range of regular units to be something like 1 or 2 cells for item units. Thus the item units would only be able to act (i.e., move) in the presence of a regular unit. > The AI, of course, would likely not get that these > units were useful, and would probably pick them up and > drop them at random. One thing that I have tried before, but with only partial success, was to set the 'ai-peace-garrison' of mobile transports, such as carriers, close to their occupancy max, and then set the 'ai-war-garrison' to 0. In the case of item units, I would guess that both garrisons should be at the occupancy max to encourage the AI to retain the items at all times. > I'd like to introduce three item types in Opal: > Weapon, Armor and Gear. I'm looking at Weapons and Armor for Wreckreation. Armor could already be done since the 'protection' (should really be called 'vulnerability') table already exists. > So far, so good (Heck, only six new > units, I'll never reach 1000 like this). Yeah, no kidding. And I thought it was 10000 in order to win the magic donut. >But we've > all seen how a unit looks with three occupants, > especially when it occupies a cell with another unit > or two. Without an occupant dialog box, it'd just be > too cluttered. IIRC, you suggested this when we were disucssing options for Cast Iron Life last year. I think it is a good idea. I have been quite tempted to try implementing it in the Tcl/Tk interface. I think I would improve formation selection first, before attempting that, since the improved formation selection stuff is likely easier. > Building each magic sword by hand is also a pain. So > I'd love to see initial-occupant and > occupant-when-created tables that call for, Yeah, the 'initial-occupant' idea has been at the back of my mind as well, and out of the same needs that you mention. It seems that you thought about it more than me though, since I didn't think of the randomness aspect. Hans just recently implemented part of another idea I had: units under construction being tougher than 1 HP. Had I implemented it, I would have redirected damage to CP instead of HP, and set up a HP-to-CP conversion ratio table. However, since he implemented it with a static HP value; I may still have the opportunity to do something more dynamic (scalable) like I had originally intended. The two solutions can probably exist side by side (though mutuall exclusive), if done right. > Tablewise, occupant-adds-hit-chance/fire-hit-chance, > occupant-adds-acp, occupant-adds-damage and > occupant-adds-hp would be a great start. You've already got 'occupant-adds-acp' and 'occupant-multiplies-acp'. I added those a while back ago. I think there is a fairly good chance that I will want to add 'occupant-adds-hit-chance', 'occupant-adds-fire-hit-chance', and 'occupant-adds-damage', and their multiplicative counterparts. I hadn't thought of the HP one. > And neural nets, and 3D units, and a fully 3D globe, > and XBox support, and and and... That "and and..." is becoming a trademark of yours. :-) Thanks for the thoughts. I hope to address at least some of them in the next month or so, but knowing how I always get sidetracked, I should stop quoting timelines. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Item Units 2004-08-22 9:37 ` Eric McDonald @ 2004-08-24 1:43 ` Lincoln Peters 2004-08-24 2:38 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Lincoln Peters @ 2004-08-24 1:43 UTC (permalink / raw) To: Eric McDonald; +Cc: Xconq list On Sat, 2004-08-21 at 23:39, Eric McDonald wrote: > I think one problem with cow patties is that ideally one would like them > to be actionless, and hence they could not be selected as active units. > So, having a transport offer to pay for everything would not do much > good for items that cannot even be selected as actors. > > A dedicated pickup/get command like most good dungeon games have would > be nice. In many respects, these "cow patty" units could be treated like facilities, so if someone implemented an easy way to pick up *and drop* such units, you might have something useful. On the other hand, the AI's understanding of facilities is a solid "brain-dead"; I honestly think that the AI will need to be radically re-engineered before it will ever truly understand facilities. > > Another possibility would be to get Xconq's control range stuff working > (if it's not already; I haven't experimented with it, but there does > appear to be some support for it in the code). Then set the control > range of regular units to be something like 1 or 2 cells for item units. > Thus the item units would only be able to act (i.e., move) in the > presence of a regular unit. I experimented with control-range in a game module involving necromancers and undead armies. The idea was that undead units would be helpless if they were more than 16 cells away from the necromancer, except for vampires and liches, which can function normally up to 24 cells away and can relay orders. It seemed to work decently, but it was around the time that the pathfinding code was radically re-engineered (and later radically un-re-engineered), so I ran into a bunch of problems that may have been totally unrelated to the control code and eventually lost interest in it. Maybe I should take another look at it. (This module might make a good addition to the library, but its premise *is* rather twisted.) > > I'd like to introduce three item types in Opal: > > Weapon, Armor and Gear. > > I'm looking at Weapons and Armor for Wreckreation. Armor could already > be done since the 'protection' (should really be called 'vulnerability') > table already exists. I tried to implement armor in a game module I wrote a while ago (the game module was never interesting enough to add to the library). I discovered that I could not provide more than one kind or armor without running into the following dilemma about how the armor "occupies" the knight: 1. If I use unit-capacity-x, I can prevent a knight from wearing two suits of plate armor, but I can't prevent a knight from wearing a suit of chainmail over a suit of full plate. (If I was to allow a knight to wear two suits of armor simultaneously, I'd want to find a way to adjust their ACP's and hit chances accordingly.) 2. If I use generic capacity, I can ensure that a knight can wear one and only one suit of armor, but I lose the ability to do anything similar with other items (different kinds of shields, helmets, magic rings...). I would have to make various kinds of armor, shields, rings, etc. fit in generic capacity; therefore a knight could wear one suit of plate armor normally, and one on his finger in place of a ring of protection (now *that's* a silly mental image). > > > So far, so good (Heck, only six new > > units, I'll never reach 1000 like this). > > Yeah, no kidding. And I thought it was 10000 in order to win the magic > donut. I guess I need to get back to work on knights.g! --- Lincoln Peters <sampln@sbcglobal.net> A quarrel is quickly settled when deserted by one party; there is no battle unless there be two. -- Seneca ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Item Units 2004-08-24 1:43 ` Lincoln Peters @ 2004-08-24 2:38 ` Eric McDonald 2004-08-24 2:51 ` Lincoln Peters 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-24 2:38 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list Lincoln Peters wrote: > I experimented with control-range in a game module involving > necromancers and undead armies. The idea was that undead units would be > helpless if they were more than 16 cells away from the necromancer, > except for vampires and liches, which can function normally up to 24 > cells away and can relay orders. > > It seemed to work decently, but it was around the time that the > pathfinding code was radically re-engineered (and later radically > un-re-engineered), so I ran into a bunch of problems that may have been > totally unrelated to the control code and eventually lost interest in > it. Maybe I should take another look at it. Yes. I bet it will turn up some bugs. Depends on how well the actor/agent (unit/unit2) separation has been honored and enforced in the kernel action code.... Actors are units which have ACP's and are doing the controlling, whereas agents are being controlled and using the actor's ACP's. Or, at least, that is my understanding of the code. > I tried to implement armor in a game module I wrote a while ago (the > game module was never interesting enough to add to the library). I > discovered that I could not provide more than one kind or armor without > running into the following dilemma about how the armor "occupies" the > knight: > > 1. If I use unit-capacity-x, I can prevent a knight from wearing two > suits of plate armor, but I can't prevent a knight from wearing a suit > of chainmail over a suit of full plate. (If I was to allow a knight to > wear two suits of armor simultaneously, I'd want to find a way to adjust > their ACP's and hit chances accordingly.) Encumberment should be able to be modelled with the 'occupant-adds-acp' table. I am thinking that I forgot to test it with negative values, but did deliberately set it up allowing values between TABLO (-32768) and TABHI (32767), and so it should be able to be used to model negative effects on ACP as well as positive ones. > 2. If I use generic capacity, I can ensure that a knight can wear one > and only one suit of armor, but I lose the ability to do anything > similar with other items (different kinds of shields, helmets, magic > rings...). I would have to make various kinds of armor, shields, rings, > etc. fit in generic capacity; therefore a knight could wear one suit of > plate armor normally, and one on his finger in place of a ring of > protection (now *that's* a silly mental image). Don't forget the 'occupant-max' table. You can set the total capacity high, and then limit certain types using 'occupant-max'. One exercise you can do is: Sit down and draw a square, say a 5x5 square, representing the unit's total capacity. Then, place, say, a 3x3 square inside the larger square, and let it represent the "armor slot". Then, lay out other squares and rectangles representing other contents the unit may have. You can, of course, use rectangles for your container instead of squares. After this, you have a crude visualization of your space consumption, and can fill out the various tables accordingly. >>Yeah, no kidding. And I thought it was 10000 in order to win the magic >>donut. > > I guess I need to get back to work on knights.g! I thought it was 'red-wizard.g' now. But, whatever it is called, I think it did have promise last time I looked at it. > A quarrel is quickly settled when deserted by one party; there is no battle > unless there be two. -- Seneca Quite true. (Publilius Syrus is still my favorite Roman author of such sayings, but Seneca isn't too bad either.) Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Item Units 2004-08-24 2:38 ` Eric McDonald @ 2004-08-24 2:51 ` Lincoln Peters 2004-08-24 3:32 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Lincoln Peters @ 2004-08-24 2:51 UTC (permalink / raw) To: Eric McDonald; +Cc: Xconq list On Mon, 2004-08-23 at 19:09, Eric McDonald wrote: > Lincoln Peters wrote: > > > I experimented with control-range in a game module involving > > necromancers and undead armies. The idea was that undead units would be > > helpless if they were more than 16 cells away from the necromancer, > > except for vampires and liches, which can function normally up to 24 > > cells away and can relay orders. > > > > It seemed to work decently, but it was around the time that the > > pathfinding code was radically re-engineered (and later radically > > un-re-engineered), so I ran into a bunch of problems that may have been > > totally unrelated to the control code and eventually lost interest in > > it. Maybe I should take another look at it. > > Yes. I bet it will turn up some bugs. Depends on how well the > actor/agent (unit/unit2) separation has been honored and enforced in the > kernel action code.... Actors are units which have ACP's and are doing > the controlling, whereas agents are being controlled and using the > actor's ACP's. Or, at least, that is my understanding of the code. The way it seemed to be working was that agents had their own ACP's, but they stopped working if they moved too far away from the actor. I didn't notice anything about agents using an actor's ACP's, although that wouldn't have made sense for this game. One thing that surprised me was that if an agent went out of range, it became not just impossible to make it act, it became impossible to select it at all! I don't know if this is how it's supposed to work. > > Encumberment should be able to be modelled with the 'occupant-adds-acp' > table. I am thinking that I forgot to test it with negative values, but > did deliberately set it up allowing values between TABLO (-32768) and > TABHI (32767), and so it should be able to be used to model negative > effects on ACP as well as positive ones. True, but I had hoped that I could prevent a knight from wearing two suits of armor at all, thus avoiding this whole issue. Although I might want to set up a game to allow knights in light armor to move faster than knights in heavy armor... Maybe I've got another idea to experiment with in 'knights.g' (or whatever I end up calling it once it's finished). > > > 2. If I use generic capacity, I can ensure that a knight can wear one > > and only one suit of armor, but I lose the ability to do anything > > similar with other items (different kinds of shields, helmets, magic > > rings...). I would have to make various kinds of armor, shields, rings, > > etc. fit in generic capacity; therefore a knight could wear one suit of > > plate armor normally, and one on his finger in place of a ring of > > protection (now *that's* a silly mental image). > > Don't forget the 'occupant-max' table. You can set the total capacity > high, and then limit certain types using 'occupant-max'. But can you limit groups of units, so that a knight can only wear one suit of armor even if I define multiple kinds of armor? > > One exercise you can do is: > Sit down and draw a square, say a 5x5 square, representing the unit's > total capacity. Then, place, say, a 3x3 square inside the larger square, > and let it represent the "armor slot". Then, lay out other squares and > rectangles representing other contents the unit may have. You can, of > course, use rectangles for your container instead of squares. > > After this, you have a crude visualization of your space consumption, > and can fill out the various tables accordingly. That had not occurred to me. However, I notice one possible exploit in this solution: Suppose that a knight's generic capacity is 24. A suit of armor is size 13, a shield is size 6, and a helmet is size 5. If a knight has no armor, he can carry 4 shields instead! Perhaps I could prevent this if unit capacity could be represented in two or more dimensions, but it would still be awkward and prone to error. > > >>Yeah, no kidding. And I thought it was 10000 in order to win the magic > >>donut. > > > > I guess I need to get back to work on knights.g! > > I thought it was 'red-wizard.g' now. But, whatever it is called, I think > it did have promise last time I looked at it. I've been re-naming it every time I decide to radically re-engineer it, so that (hopefully) I can re-trace my steps if some weird bug crops up. The current incarnation is called 'knightmare.g'. --- Lincoln Peters <sampln@sbcglobal.net> Keep your eyes wide open before marriage, half shut afterwards. -- Benjamin Franklin ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Item Units 2004-08-24 2:51 ` Lincoln Peters @ 2004-08-24 3:32 ` Eric McDonald 0 siblings, 0 replies; 45+ messages in thread From: Eric McDonald @ 2004-08-24 3:32 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list Lincoln Peters wrote: >>Yes. I bet it will turn up some bugs. Depends on how well the >>actor/agent (unit/unit2) separation has been honored and enforced in the >>kernel action code.... Actors are units which have ACP's and are doing >>the controlling, whereas agents are being controlled and using the >>actor's ACP's. Or, at least, that is my understanding of the code. > > The way it seemed to be working was that agents had their own ACP's, but > they stopped working if they moved too far away from the actor. Right. I had gathered that from the code. >I > didn't notice anything about agents using an actor's ACP's, although > that wouldn't have made sense for this game. I don't think there is any GDL support for this particular aspect, and I don't remember seeing much in the action-related code that would check any GDL props or tables before deciding that 'unit' and 'unit2' are not the same. I was just mentioning this as another aspect if "control" was fully implemented. > One thing that surprised me was that if an agent went out of range, it > became not just impossible to make it act, it became impossible to > select it at all! I don't know if this is how it's supposed to work. One should still be able to survey it, but I would expect that one could not select it for action. > True, but I had hoped that I could prevent a knight from wearing two > suits of armor at all, thus avoiding this whole issue. I see. I thought you were just wondering whether there was an encumberment mechanism. > Although I might > want to set up a game to allow knights in light armor to move faster > than knights in heavy armor... Thought so. :-) > But can you limit groups of units, so that a knight can only wear one > suit of armor even if I define multiple kinds of armor? Only through size (which is why I suggested a large square for it). This does break down somewhat with smaller items. One possible workaround, though quite hackish, would be to create container units that the unit carries. So you would have a "gloves and gauntlets" container which could only carry one instance of any of your assorted gloves and gauntlets types. And likewise for the other groups. This does create another layer of containment, which when coupled with the current Tcl/Tk interface, could be messy to navigate (per our earlier discussion). > That had not occurred to me. However, I notice one possible exploit in > this solution: > > Suppose that a knight's generic capacity is 24. A suit of armor is size > 13, a shield is size 6, and a helmet is size 5. If a knight has no > armor, he can carry 4 shields instead! If you have only one shield type, then you can limit it with 'occupant-max'. If you have more than one shield type defined, then, yes, this does break down. However, see my "container units" suggestion. I think, in the long run, the concept of "unit class" would be useful in areas: (1) This whole capacity restriction mess that we jsut discussed. The mess also appears with 'unit-capacity-x'. Consider a city unit which has exclusive capacity for 4 aircraft (it has an airfield, say). With the currently available, Xconq tools, you have no way of saying that only up to 4 aircraft of possibly varying types can be placed in the airfield. If you attempt to limit each type to 4 and you have 4 types then you would end up with the possibility of 16 aircraft in the airfield, 4 from each type. (2) Creating hierarchies in the help system, which would not only be useful for guiding a player to groups of related units, but would also help quell the tendency for oversized "Unit Types" sections in the menus as you and Elijah race onwards towards the 10000 unit mark. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-22 3:09 ` Hans Ronne 2004-08-22 6:38 ` Item Units Elijah Meeks @ 2004-08-22 14:00 ` mskala 2004-08-22 18:56 ` Hans Ronne 1 sibling, 1 reply; 45+ messages in thread From: mskala @ 2004-08-22 14:00 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 On Sun, 22 Aug 2004, Hans Ronne wrote: > As for selecting units in general, I never had any problems at the highest > zoom level. What game are you playing, and how many units are there in the > cell? I noticed the problem most in my game with the item units, because there I had some units with as many as 25 occupants that sometimes were occupants themselves. It becomes an issue even in the standard game with smaller numbers of occupants, though. Try putting a bomber (loaded with a unit of infantry) on a carrier that also has some fighters on it, and sailing some other ship into the cell. The infantry shrinks below the visibility threshold even on maximum zoom. Or, worse yet, try sailing the carrier into a port that also has a few other units in it. > them. A better alternative to scrollbars is scrolling of the map using the > arrow keys. I ported that feature from the Mac interface to the tcltk It isn't really the scroll bars I'd like to turn on or off, but the automatic scrolling based on mouse position. Arrow keys or scroll bars each serve the purpose better. I slightly prefer scroll bars for consistency with other software, and because then scrolling can be done with the mouse alone, but I'd be happy to just have the auto-scroll removed without being replaced at all. We still have the clickable world map in the corner, which is what I usually use in the current TCL/TK interface. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-22 14:00 ` Three thoughts mskala @ 2004-08-22 18:56 ` Hans Ronne 2004-08-22 19:16 ` Lincoln Peters 0 siblings, 1 reply; 45+ messages in thread From: Hans Ronne @ 2004-08-22 18:56 UTC (permalink / raw) To: mskala; +Cc: xconq7 >On Sun, 22 Aug 2004, Hans Ronne wrote: >> As for selecting units in general, I never had any problems at the highest >> zoom level. What game are you playing, and how many units are there in the >> cell? > >I noticed the problem most in my game with the item units, because there I >had some units with as many as 25 occupants that sometimes were occupants >themselves. It becomes an issue even in the standard game with smaller >numbers of occupants, though. I see. One thing that might solve this problem, if I may bring up the Mac interface again, is to implement unit closeups. This is how you navigate within the stack on the Mac: right-click on a unit to bring up a small floating window with unit info plus one image of each occupant. Right-click on any of these images to bring up a closeup of the occupant. And so on. There is also a clickable image of the transport in each occupant closeup, so you can navigate quickly up and down in the stack. The frontmost closeup automatically becomes the current unit for commands etc. Porting this to the tcltk interface is something that I have wanted to do for a long time, but it is easier said than done. The main problem is the lack of support for floating windows in tcltk. >> them. A better alternative to scrollbars is scrolling of the map using the >> arrow keys. I ported that feature from the Mac interface to the tcltk > >It isn't really the scroll bars I'd like to turn on or off, but the >automatic scrolling based on mouse position. OK. Making that a user preference shouldn't be too difficult. I'm about to leave for a trip, but I'll look into it when I'm back. Hans ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-22 18:56 ` Hans Ronne @ 2004-08-22 19:16 ` Lincoln Peters 2004-08-23 4:31 ` Jim Kingdon 2004-08-23 16:48 ` Three thoughts Eric McDonald 0 siblings, 2 replies; 45+ messages in thread From: Lincoln Peters @ 2004-08-22 19:16 UTC (permalink / raw) To: Hans Ronne; +Cc: Xconq list On Sun, 2004-08-22 at 07:01, Hans Ronne wrote: > >I noticed the problem most in my game with the item units, because there I > >had some units with as many as 25 occupants that sometimes were occupants > >themselves. It becomes an issue even in the standard game with smaller > >numbers of occupants, though. > > I see. One thing that might solve this problem, if I may bring up the Mac > interface again, is to implement unit closeups. This is how you navigate > within the stack on the Mac: right-click on a unit to bring up a small > floating window with unit info plus one image of each occupant. Right-click > on any of these images to bring up a closeup of the occupant. And so on. > There is also a clickable image of the transport in each occupant closeup, > so you can navigate quickly up and down in the stack. The frontmost closeup > automatically becomes the current unit for commands etc. Here's a rather crazy possible solution: Would it be possible to use TclTk *and* another toolkit, such as GTK+, simultaneously? That might allow us to not only use GTK+ to implement new features, but also to "phase out" the TclTk code (since nobody seems to like TclTk anymore) and replace it with GTK+ code. If I remember correctly, a few people have complained that it is often difficult to debug TclTk code, various quirks make it difficult to create certain keybindings, and it's just plain ugly. While GTK+ would still result in a game that looks like an Office app, it should be easier to debug (no useless "Error reading tcl" errors) and more versatile. Not to mention that GTK+ contains everything you need to make an application accessible to people with disabilities (might be fun just to make Xconq able to respond appropriately if you were to bark orders at it via a speech recognition engine). And I don't think it would be a step backward from the existing TclTk interface if the interface was re-implemented in GTK+ and ended up looking like an Office app. I've put together an example of what a "close-up" dialog might look like if implemented in GTK+, and I've posted it here: http://homepage.mac.com/lmpeters/cell-closeup.png (The icons are generic icons from the GTK+/GNOME library. Just pretend that they look like unit images from the Standard game.) The situation illustrated here is the city Sausalito and a fighter flying overhead. Within the city are infantry, armor, a bomber, a battleship, and a carrier. Furthermore, within the carrier are three fighters and another bomber. This would be almost completely unmanageable without a close-up dialog like this one. I envision the closeup dialog as something you could summon with a special mouse click (perhaps Alt-click or click with the middle button), and then use any time you need to click on a unit (choosing a unit to give orders to, board, attack, fire at, etc.). > Porting this to the tcltk interface is something that I have wanted to do > for a long time, but it is easier said than done. The main problem is the > lack of support for floating windows in tcltk. I'll add this to the list of reason not to like TclTk. I guess you could implement a close-up dialog like I illustrated above in TclTk, but it sounds like it would be more work. --- Lincoln Peters <sampln@sbcglobal.net> It is contrary to reasoning to say that there is a vacuum or space in which there is absolutely nothing. -- Descartes ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-22 19:16 ` Lincoln Peters @ 2004-08-23 4:31 ` Jim Kingdon 2004-08-23 13:04 ` Elijah Meeks 2004-08-23 16:48 ` Three thoughts Eric McDonald 1 sibling, 1 reply; 45+ messages in thread From: Jim Kingdon @ 2004-08-23 4:31 UTC (permalink / raw) To: xconq7 > http://homepage.mac.com/lmpeters/cell-closeup.png Although I think people should certainly be encouraged to experiment, and maybe if I tried the Mac interface I'd change my mind, but I do want to register non-enthusiasm for closeup dialogs. Sure, you can come up with a way to show what is in a cell which is deeply nested. But is it visually appealing? Does it mean you are always having to click or hit a key to expand/unexpand a unit? Do you have to go up and town the tree of occupancy just to find what you want to know? If the solution isn't a fancy "occupants navigator", then perhaps the solution is just change the game designs to reduce the problem. For example, one reason that the standard game only allows 16 units in one cell is to make them easy to draw and see. The standard game is lacking any such mitigation for the "infantry in a bomber in a carrier in a town" problem, however. I wonder what it would do to playability if a town/city could only hold 8 units? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-23 4:31 ` Jim Kingdon @ 2004-08-23 13:04 ` Elijah Meeks 2004-08-24 18:07 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Elijah Meeks @ 2004-08-23 13:04 UTC (permalink / raw) To: Jim Kingdon, xconq7 > If the solution isn't a fancy "occupants navigator", > then perhaps the > solution is just change the game designs to reduce > the problem. For > example, one reason that the standard game only > allows 16 units in one > cell is to make them easy to draw and see. The > standard game is > lacking any such mitigation for the "infantry in a > bomber in a carrier > in a town" problem, however. I wonder what it would > do to playability > if a town/city could only hold 8 units? I generally agree with this, and it's why I've fallen into using a four unit limit per cell with my designs. Still, even a game like civilization uses a seperate status window for cities, which near the end of the game would have dozens of what XConq considers units. So, if a designer wants to create a civ-like game that's visually appealing, we need some way to hide the ancillary units, which in general aren't combat units but rather units that somehow affect a 'mother' unit (Improvements in Civ/MOO/MOM, items in the case of fantasy/RPG-style games). Speaking of items, I'd like to add random piles of gold to Opal. I can do this in a way by making advanced 'Random Pile of Gold' units with an initial supply of 'gold' material that gives to the treasury, so that when a player captures the unit, the gold is tossed into their treasury (The independant side defaults to not using the treasury, so the gold isn't looted by greedy iplayers). This is, however, a cumbersome procedure, and I was wondering as to the feasibility of an capture-gives-material table. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-23 13:04 ` Elijah Meeks @ 2004-08-24 18:07 ` Eric McDonald 2004-08-24 20:59 ` Elijah Meeks 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-24 18:07 UTC (permalink / raw) To: Elijah Meeks; +Cc: Jim Kingdon, xconq7 On Sun, 22 Aug 2004, Elijah Meeks wrote: > looted by greedy iplayers). This is, however, a > cumbersome procedure, and I was wondering as to the > feasibility of an capture-gives-material table. Almost anything is possible. The question is when it will actually get done. Wrt this table, were you thinking in terms of specific quantities of certain materials being yielded up by the captured unit, or percentages of all materials being yielded up depending on who does the capturing and who is being captured? Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-24 18:07 ` Eric McDonald @ 2004-08-24 20:59 ` Elijah Meeks 2004-08-25 0:54 ` Unit-Image Bug Elijah Meeks 0 siblings, 1 reply; 45+ messages in thread From: Elijah Meeks @ 2004-08-24 20:59 UTC (permalink / raw) To: Eric McDonald; +Cc: Jim Kingdon, xconq7 > Wrt this table, were you thinking in terms of > specific quantities > of certain materials being yielded up by the > captured unit, or > percentages of all materials being yielded up > depending on who > does the capturing and who is being captured? Simply material and quantity if the unit is captured. What I'll do is set a seed unit so that the player destroys it and captures its wrecked-type, like so: (unit gold-chest (image "ang-chest-iron-small") (wrecked-type goldpile)) (table material-if-captured (goldpile gold 50) ) This way I can set a timer on the pile o' gold so that it evaporates after capture, to keep the map clean. I suppose I'd have to set its capture on the 'independent-capture-chance' table, so that it can only be captured when independent, because otherwise you run the risk of other sides capturing the pile of gold (And thus gaining free materials) before it evaporates. The better option may be a 'material-looted-chance' (or some, better-named table) that sets the possibility of gaining material from a unit you've destroyed. In this case, I'd simply set the goldpile unit to have x gold (Or an initial-supply, for random setups) and the table to: (table material-looted-chance (goldpile gold 100) ) I don't know which would be easier. Elijah __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 45+ messages in thread
* Unit-Image Bug 2004-08-24 20:59 ` Elijah Meeks @ 2004-08-25 0:54 ` Elijah Meeks 2004-08-25 4:58 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Elijah Meeks @ 2004-08-25 0:54 UTC (permalink / raw) To: xconq7 Just downloaded Hans' latest build and I've noticed that units no longer change their image when they auto-upgrade into a new unit or wreck-type into a new unit. I have a feeling this is related to Hans' new code to give individual units their own images. Elijah __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Unit-Image Bug 2004-08-25 0:54 ` Unit-Image Bug Elijah Meeks @ 2004-08-25 4:58 ` Eric McDonald 0 siblings, 0 replies; 45+ messages in thread From: Eric McDonald @ 2004-08-25 4:58 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > Just downloaded Hans' latest build and I've noticed > that units no longer change their image when they > auto-upgrade into a new unit or wreck-type into a new > unit. I have a feeling this is related to Hans' new > code to give individual units their own images. I put a fix for that bug into the CVS repository last Saturday. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-22 19:16 ` Lincoln Peters 2004-08-23 4:31 ` Jim Kingdon @ 2004-08-23 16:48 ` Eric McDonald 2004-08-24 0:55 ` Lincoln Peters 1 sibling, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-23 16:48 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list On Sun, 22 Aug 2004, Lincoln Peters wrote: > Here's a rather crazy possible solution: Would it be possible to use > TclTk *and* another toolkit, such as GTK+, simultaneously? That might > allow us to not only use GTK+ to implement new features, but also to > "phase out" the TclTk code (since nobody seems to like TclTk anymore) > and replace it with GTK+ code. I think it would be possible, but probably would be rather hackish. Both Tk and GTK+ have their own window hierarchies, and that would require a fair amount of bookkeeping on Xconq's part, to make sure that focus gets restored after a window closes, etc.... Also, the "widget styles" of the two toolkits are a bit different and so the resulting UI would end up looking like Frankenstein, I think. Your idea does have the merits you suggest, though. Interesting.... > The situation illustrated here is the city Sausalito and a fighter > flying overhead. Within the city are infantry, armor, a bomber, a > battleship, and a carrier. If the ship types corresponded to U.S. Navy naming conventions, I think you would have two carriers and zero battleships. Not that it really matters.... The closup view window that you propose is an interesting idea, but I agree that we should try to avoid extra work to fish out an unit, if possible (as someone mentioned in a later message in this thread). One idea that I thought of would be magnify the icon of an unit if the cursor passes over it in a manner similar to that little bar of icons at the bottom of the MacOS X interface (IIRC). Or maybe that magnification should only happen when a modifier key is being pressed when the mouse passes over the unit, so that the magnified view does not normally get in the way of other units in the same hex (and possibly surrounding hexes). Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-23 16:48 ` Three thoughts Eric McDonald @ 2004-08-24 0:55 ` Lincoln Peters 2004-08-24 2:09 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Lincoln Peters @ 2004-08-24 0:55 UTC (permalink / raw) To: Eric McDonald; +Cc: Xconq list On Mon, 2004-08-23 at 09:40, Eric McDonald wrote: > On Sun, 22 Aug 2004, Lincoln Peters wrote: > > > Here's a rather crazy possible solution: Would it be possible to use > > TclTk *and* another toolkit, such as GTK+, simultaneously? That might > > allow us to not only use GTK+ to implement new features, but also to > > "phase out" the TclTk code (since nobody seems to like TclTk anymore) > > and replace it with GTK+ code. > > I think it would be possible, but probably would be rather > hackish. Both Tk and GTK+ have their own window hierarchies, and > that would require a fair amount of bookkeeping on Xconq's part, > to make sure that focus gets restored after a window closes, > etc.... > > Also, the "widget styles" of the two toolkits are a bit different > and so the resulting UI would end up looking like Frankenstein, I > think. I'm not familiar with TclTk's (Tk's?) "widget style". Does it work based on a grid, where widgets are positioned by coordinates rather than through the use of containers (horizontal and vertical boxes, tables, etc.; as per GTK+)? From the references I can find on the Web, it looks like Tk can use containers in a manner similar to GTK+, but it has only had that feature since version 8.4. Would Xconq look any worse if it used Tk code and GTK+ code simultaneously than it looks now? As I see it right now, we have three possibilities: Current TclTk interface: ugly and unintuitive Proposed GTK+ interface: more intuitive than TclTk, but would look like an Office app In-development SDL interface: looks cool, more intuitive than TclTk, but more work to develop than the first two Over the long term, it might be worthwhile to try to develop a common UI based on SDL and GTK+/GNOME, since SDL could provide a more game-like (i.e. less Office-app-like) interface and GTK+ could provide a bunch of features where it doesn't particularly matter if they look like they belong in an Office app. For example, I think it would be fairly simple to implement the Xconq "Welcome" screen using a GNOME Druid. > > Your idea does have the merits you suggest, though. > Interesting.... There might be a few hardcore strategy gamers who would appreciate being able to use Mono to link Xconq to a spreadsheet application and do some intensive data analysis on games like advances.g (e.g. track production, technology, offensive/defensive power, over time). Of course, there are a *lot* of other things to deal with before worrying about spreadsheet applications! Perhaps it would be possible to avoid the "hackish" aspect of using TclTk and GTK+ simultaneously by completely switching from TclTk to GTK+ in one fell swoop, but that idea is probably even more scary for most developers. The closest I'd expect us to reasonably come to that scenario would be to implement GTK+ as a separate interface and then label the TclTk interface as a "legacy" interface. > > > The situation illustrated here is the city Sausalito and a fighter > > flying overhead. Within the city are infantry, armor, a bomber, a > > battleship, and a carrier. > > If the ship types corresponded to U.S. Navy naming conventions, I > think you would have two carriers and zero battleships. Not that > it really matters.... Honestly, I just used the names of the first two ships from "Star Trek" that I could think of. Last night, a local TV station ran "Star Trek IV: The Voyage Home" > > The closup view window that you propose is an interesting idea, > but I agree that we should try to avoid extra work to fish out an > unit, if possible (as someone mentioned in a later message in > this thread). One idea that I thought of would be magnify the > icon of an unit if the cursor passes over it in a manner similar > to that little bar of icons at the bottom of the MacOS X > interface (IIRC). Or maybe that magnification should only happen > when a modifier key is being pressed when the mouse passes over > the unit, so that the magnified view does not normally get in the > way of other units in the same hex (and possibly surrounding > hexes). Magnification as per the MacOS X dock would be a possibility, but an awkward one. Unless you have an intuitive way for the user to indicate when to zoom and when not to zoom, the user might be rather surprised when the mouse hovers over a cell and one unit suddenly gets bigger while the others get smaller. Of course, if you don't want to shrink the unit images, you'd probably have to shrink the neighboring hexes... In conclusion, this kind of zooming is probably more work than you had in mind. Another possibility might be to make the close-up dialog be a separate window that displays each unit in the same arrangement as on the main screen, but it draws every unit in the cell at the same size. Something like: http://homepage.mac.com/lmpeters/cell_closeup2.png (As before, I'm limited to the GTK+/GNOME stock icons, none of which look like an Xconq unit, unless I write some actual UI code.) --- Lincoln Peters <sampln@sbcglobal.net> "Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway" ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-24 0:55 ` Lincoln Peters @ 2004-08-24 2:09 ` Eric McDonald 2004-08-24 3:02 ` Lincoln Peters 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-24 2:09 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list Lincoln Peters wrote: >>Also, the "widget styles" of the two toolkits are a bit different >>and so the resulting UI would end up looking like Frankenstein, I >>think. > > I'm not familiar with TclTk's (Tk's?) "widget style". You're reading too much into what I meant by "widget style" (which was in parentheses for a reason). Perhaps another way to put it is simply, look-n-feel. > Over the long term, it might be worthwhile to try to develop a common UI > based on SDL and GTK+/GNOME, since SDL could provide a more game-like > (i.e. less Office-app-like) interface and GTK+ could provide a bunch of > features where it doesn't particularly matter if they look like they > belong in an Office app. Well, it was not too long ago that I revived this suggestion (having first made it during the Great Flame War of November 2003), and some of those who read it infused assumptions into its implications, such as that I would recommend using GTK components without "redecorating" them to fit their environment. It took a while to untangle that thread, and I would rather not go there again any time soon. > There might be a few hardcore strategy gamers who would appreciate being > able to use Mono to link Xconq to a spreadsheet application and do some > intensive data analysis on games like advances.g (e.g. track production, > technology, offensive/defensive power, over time). These are some of the benefits that crossed my mind as well when we last discussed this (last year). > Perhaps it would be possible to avoid the "hackish" aspect of using > TclTk and GTK+ simultaneously by completely switching from TclTk to GTK+ > in one fell swoop, but that idea is probably even more scary for most > developers. The closest I'd expect us to reasonably come to that > scenario would be to implement GTK+ as a separate interface and then > label the TclTk interface as a "legacy" interface. I have thought about this on and off in the past few weeks. After reviewing the SDL API and GTK API, and looking at the existing SDL code, I think that I am going to give SDL a try first. (After reading portions of both API's yesterday, I actually did sit down and fix some bugs in the SDL app.) >>The closup view window that you propose is an interesting idea, >>but I agree that we should try to avoid extra work to fish out an >>unit, if possible (as someone mentioned in a later message in >>this thread). One idea that I thought of would be magnify the >>icon of an unit if the cursor passes over it in a manner similar >>to that little bar of icons at the bottom of the MacOS X >>interface (IIRC). Or maybe that magnification should only happen >>when a modifier key is being pressed when the mouse passes over >>the unit, so that the magnified view does not normally get in the >>way of other units in the same hex (and possibly surrounding >>hexes). > > > Unless you have an intuitive way for the user to indicate > when to zoom and when not to zoom, See my suggestion above about pressing a modifier key. >the user might be rather surprised > when the mouse hovers over a cell and one unit suddenly gets bigger > while the others get smaller. Well, I never suggested that other get smaller.... Does the MacOS X icon bar have that property? I was just thinking in terms of making one image larger than the others, and then partially or totally obscuring its neighbors for the duration of the magnification. > In conclusion, this kind of zooming is probably more work than you had > in mind. I didn't have any amount of work in mind. It was just a suggestion. But, now that you mention it, I am not sure that it would be so much work. > Another possibility might be to make the close-up dialog be a separate > window that displays each unit in the same arrangement as on the main > screen, but it draws every unit in the cell at the same size. I think that is what Elijah and Matthew were suggesting (or something similar), and it is certainly what I had in mind until the "icon magnification" idea occurred to me. > http://homepage.mac.com/lmpeters/cell_closeup2.png 404. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-24 2:09 ` Eric McDonald @ 2004-08-24 3:02 ` Lincoln Peters 2004-08-24 18:12 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Lincoln Peters @ 2004-08-24 3:02 UTC (permalink / raw) To: Eric McDonald; +Cc: Xconq list On Mon, 2004-08-23 at 18:42, Eric McDonald wrote: > Lincoln Peters wrote: > > > > > I'm not familiar with TclTk's (Tk's?) "widget style". > > You're reading too much into what I meant by "widget style" (which was > in parentheses for a reason). Perhaps another way to put it is simply, > look-n-feel. Okay. I can see quite clearly how TclTk and GTK+ differ in look-n-feel. > > > Over the long term, it might be worthwhile to try to develop a common UI > > based on SDL and GTK+/GNOME, since SDL could provide a more game-like > > (i.e. less Office-app-like) interface and GTK+ could provide a bunch of > > features where it doesn't particularly matter if they look like they > > belong in an Office app. > > Well, it was not too long ago that I revived this suggestion (having > first made it during the Great Flame War of November 2003), and some of > those who read it infused assumptions into its implications, such as > that I would recommend using GTK components without "redecorating" them > to fit their environment. It took a while to untangle that thread, and I > would rather not go there again any time soon. Understood. I suppose that I started thinking about this stuff again after I saw a computer at Novell's booth at LinuxWorld where they were showing off what you can do with Mono (Novell merged with Ximian a while ago). > >>The closup view window that you propose is an interesting idea, > >>but I agree that we should try to avoid extra work to fish out an > >>unit, if possible (as someone mentioned in a later message in > >>this thread). One idea that I thought of would be magnify the > >>icon of an unit if the cursor passes over it in a manner similar > >>to that little bar of icons at the bottom of the MacOS X > >>interface (IIRC). Or maybe that magnification should only happen > >>when a modifier key is being pressed when the mouse passes over > >>the unit, so that the magnified view does not normally get in the > >>way of other units in the same hex (and possibly surrounding > >>hexes). > > > > > > Unless you have an intuitive way for the user to indicate > > when to zoom and when not to zoom, > > See my suggestion above about pressing a modifier key. Somehow I didn't see the suggestion about a modifier key earlier. Maybe I've been staring at my computer screen too long. > > >the user might be rather surprised > > when the mouse hovers over a cell and one unit suddenly gets bigger > > while the others get smaller. > > Well, I never suggested that other get smaller.... > Does the MacOS X icon bar have that property? No, but I imagine that if the size of the cell doesn't change, you'd have to shrink the other units to accommodate the enlarged unit image unless you were willing to obscure units by placing them underneath the enlarged unit image (which it looks like was what you have in mind). I guess that you could enlarge the entire grid so that every unit image fits on the screen at a reasonable size, but that could easily result in the most unmanageable map ever. Although I suppose that if there was an easy way to toggle between that view and the "normal" view, the only disadvantage would be the CPU load (which wouldn't be too bad except on old hardware). > > I was just thinking in terms of making one image larger than the others, > and then partially or totally obscuring its neighbors for the duration > of the magnification. I noticed that the SDL interface blows up the selected unit to fill the entire cell even if other units occupy the cell. I find it to be rather awkward, as it makes it hard to reach units underneath it (I often can't figure out where to click to select another unit in the same cell unless I de-select the current unit first. And sometimes it looks weird when several tiny unit images appear underneath a big unit image. > > > In conclusion, this kind of zooming is probably more work than you had > > in mind. > > I didn't have any amount of work in mind. It was just a suggestion. But, > now that you mention it, I am not sure that it would be so much work. Actually, it does sound like the simplest solution. > > > Another possibility might be to make the close-up dialog be a separate > > window that displays each unit in the same arrangement as on the main > > screen, but it draws every unit in the cell at the same size. > > I think that is what Elijah and Matthew were suggesting (or something > similar), and it is certainly what I had in mind until the "icon > magnification" idea occurred to me. I'm not sure which solution would work better. It might be necessary to implement both solutions and see which holds up better in practice. Maybe it will help to look at the corrected URL, below. > > > http://homepage.mac.com/lmpeters/cell_closeup2.png > > 404. Sorry; typo. http://homepage.mac.com/lmpeters/cell-closeup2.png --- Lincoln Peters <sampln@sbcglobal.net> It's a very *__\b\bUN*lucky week in which to be took dead. -- Churchy La Femme ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-24 3:02 ` Lincoln Peters @ 2004-08-24 18:12 ` Eric McDonald 2004-08-25 5:34 ` Jim Kingdon 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-24 18:12 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list On Mon, 23 Aug 2004, Lincoln Peters wrote: > > Well, I never suggested that other get smaller.... > > Does the MacOS X icon bar have that property? > > No, but I imagine that if the size of the cell doesn't change, you'd > have to shrink the other units to accommodate the enlarged unit image > unless you were willing to obscure units by placing them underneath the > enlarged unit image (which it looks like was what you have in mind). Right. > I noticed that the SDL interface blows up the selected unit to fill the > entire cell even if other units occupy the cell. I find it to be rather > awkward, As do I. I think a more traditional selection rectangle might be desirable. If one wants to see a full-sized "portrait" of the selected unit, it can be provided in the unit information panel. > I de-select the current unit first. And sometimes it looks weird when > several tiny unit images appear underneath a big unit image. Agreed. At first I thought I was witnessing a bug, until I realized what was going on. > I'm not sure which solution would work better. It might be necessary to > implement both solutions and see which holds up better in practice. That might be not be a bad idea. But, I am not going to volunteer to write both solutions. > http://homepage.mac.com/lmpeters/cell-closeup2.png Interesting.... Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-24 18:12 ` Eric McDonald @ 2004-08-25 5:34 ` Jim Kingdon 2004-08-25 17:16 ` Lincoln Peters 0 siblings, 1 reply; 45+ messages in thread From: Jim Kingdon @ 2004-08-25 5:34 UTC (permalink / raw) To: mcdonald; +Cc: sampln, xconq7 > I noticed that the SDL interface blows up the selected unit to fill the > entire cell even if other units occupy the cell. I find it to be rather > awkward, Well, I haven't actually played it, but I like it as an idea. It lets you see the details on each unit (by selecting them in turn), without the extra step of popping up a window. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-25 5:34 ` Jim Kingdon @ 2004-08-25 17:16 ` Lincoln Peters 2004-08-25 22:09 ` Jim Kingdon 0 siblings, 1 reply; 45+ messages in thread From: Lincoln Peters @ 2004-08-25 17:16 UTC (permalink / raw) To: Jim Kingdon; +Cc: Xconq list On Tue, 2004-08-24 at 21:58, Jim Kingdon wrote: > > I noticed that the SDL interface blows up the selected unit to fill the > > entire cell even if other units occupy the cell. I find it to be rather > > awkward, > > Well, I haven't actually played it, but I like it as an idea. The problem is that it doesn't do anything about the units that are still drawn underneath the selected unit. Unless those units are either hidden or otherwise obscured (maybe by making them semi-transparent), it really does look ugly when a lot of units, some overlapping, are in one cell. --- Lincoln Peters <sampln@sbcglobal.net> To Perl, or not to Perl, that is the kvetching. -- Larry Wall in <199801200310.TAA11670@wall.org> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-25 17:16 ` Lincoln Peters @ 2004-08-25 22:09 ` Jim Kingdon 2004-08-26 2:15 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Jim Kingdon @ 2004-08-25 22:09 UTC (permalink / raw) To: sampln; +Cc: xconq7 > The problem is that it doesn't do anything about the units that are > still drawn underneath the selected unit. Unless those units are either > hidden or otherwise obscured (maybe by making them semi-transparent), it > really does look ugly when a lot of units, some overlapping, are in one > cell. Ah, OK. I think the job may have been half-done. If I understood the design correctly, the idea was that the non-selected units would become very small and be arranged around the outside of the cell. So to try to render it in ASCII art: i i b f c IIIII f I c I f I d IIIII f d d f f where the big "I" is the selected unit, and the "i", "i", etc are the non-selected units. At least, I think that is one of the ideas that Stan had been playing with. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-25 22:09 ` Jim Kingdon @ 2004-08-26 2:15 ` Eric McDonald 2004-08-26 6:17 ` Jim Kingdon 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-26 2:15 UTC (permalink / raw) To: Jim Kingdon; +Cc: sampln, xconq7 On Wed, 25 Aug 2004, Jim Kingdon wrote: > If I understood the design correctly, the idea was that the > non-selected units would become very small and be arranged around the > outside of the cell. When you say around the outside of the cell, do you still mean inside the cell perimeter or outside of it? I think that outside the cell perimeter could create quite a bit of confusion about which cell an unit is actually in. >So to try to render it in ASCII art: Couldn't draw a hexagon? ;-) > where the big "I" is the selected unit, and the "i", "i", etc are the > non-selected units. I can think of some potential issues with this: (1) Scaling images to non-standard sizes would likely be necessary to accomodate the suggested scheme. (2) In the case of units that are using large icons, if one is blown up to normal size (44x44), then there is no room left in the cell (assuming that you mean to place the others inside the cell perimeter). So, either one would need to scale to a non-standard size or else half-size (22x22). In the case that only 3 other units were in the cell to start with, there would be no gain; rather, the selected unit would be centered in the cell, and the other 3 images would be scaled down. I see information being lost in this case. (3) Scaling down the images of other units would likely degrade their identifiability as certain types, which would cause problems (or, at least, squinting) if a player went to select another unit in the same cell. (All 3 of the above arguments also apply to why I don't think shrinking neighboring units when dealing with unit closeups is a good idea either.) I still think that putting a "portrait" of the selected unit in the unit info window would be better. But, that's just my opinion.... Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-26 2:15 ` Eric McDonald @ 2004-08-26 6:17 ` Jim Kingdon 2004-08-26 19:12 ` Eric McDonald 0 siblings, 1 reply; 45+ messages in thread From: Jim Kingdon @ 2004-08-26 6:17 UTC (permalink / raw) To: mcdonald; +Cc: xconq7 > When you say around the outside of the cell, do you > still mean inside the cell perimeter or outside of it? Probably inside, although I don't know whether the feature was ever thought through in that much detail. > (1) Scaling images to non-standard sizes would likely be > necessary to accomodate the suggested scheme. Or playing with the size of the hexes, or re-working the bigicons feature, or something. There are plenty of details that would need to worked out. But first one needs to think through whether the concept seems promising in general. > (3) Scaling down the images of other units would likely degrade > their identifiability as certain types The smallest image currently in use is about a 4x4? It is pretty small. I don't imagine you'd go smaller than that. > I still think that putting a "portrait" of the selected unit in > the unit info window would be better. But, that's just my > opinion.... Well, yes, the unit info window is useful in tcltk as it stands now, and making it more graphical/informative is certainly one way to approach this problem. But it is also worthwhile thinking about whether there is some way to provide some of the information with having to look back and forth to a window which is off to the side. Maybe it isn't center and edges, maybe it is top and bottom. In the tcltk interface now, the top half is for the transport and the bottom half is for the occupants. What if the top half were for the selected unit and the bottom half were for the others? With scaling and drawing otherwise the same as now. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Three thoughts 2004-08-26 6:17 ` Jim Kingdon @ 2004-08-26 19:12 ` Eric McDonald 2004-08-26 22:08 ` CXP??? Elijah Meeks 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-26 19:12 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 On Thu, 26 Aug 2004, Jim Kingdon wrote: > > (1) Scaling images to non-standard sizes would likely be > > necessary to accomodate the suggested scheme. > > Or playing with the size of the hexes, or re-working the bigicons > feature, or something. There are plenty of details that would need to > worked out. But first one needs to think through whether the concept > seems promising in general. Agreed. Certainly, the concept is an interesting one, especially if one ignores the small number of scaling bins in use and assumes an "infinite" number of them instead. > > (3) Scaling down the images of other units would likely degrade > > their identifiability as certain types > > The smallest image currently in use is about a 4x4? It is pretty > small. I don't imagine you'd go smaller than that. Agreed. But then what? If space constraints were to force one to go smaller, then what? Would this feature be selectively implemented to only work at high view powers, and be disabled for ones lower than the default one currently in use? > But it is also worthwhile thinking about whether there is some way to > provide some of the information with having to look back and forth to > a window which is off to the side. I agree. That is why I think some sort of selection rectangle ("crawling ants", blinking square, etc...) around the selected unit is a good idea. At small scales, it may be necessary to flash the entire unit icon to make it stand out from the crowd. >Maybe it isn't center and edges, > maybe it is top and bottom. In the tcltk interface now, the top half > is for the transport and the bottom half is for the occupants. Right. I had wondered about this approach as well. However, do we want to confuse paradigms? Top-bottom presently indicates transport-occupant; do we want to overload this for selected-unselected as well? > With scaling and drawing otherwise the same as now. I agree that it does have that benefit. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* CXP??? 2004-08-26 19:12 ` Eric McDonald @ 2004-08-26 22:08 ` Elijah Meeks 2004-08-27 1:50 ` CXP??? Lincoln Peters 2004-08-27 5:10 ` CXP??? Eric McDonald 0 siblings, 2 replies; 45+ messages in thread From: Elijah Meeks @ 2004-08-26 22:08 UTC (permalink / raw) To: xconq7 Okay, so you don't get cxp from ranged attacks, unless the ranged attack is performed against a unit in the hex adjacent? And you only get cxp if the attack misses?? I finally took a good look at cxp, after assuming that I wasn't paying attention before, but now that I have, it looks screwy. Does anyone have any firm rules on how cxp works and whether or not it's supposed to work like this? It seems haphazard. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: CXP??? 2004-08-26 22:08 ` CXP??? Elijah Meeks @ 2004-08-27 1:50 ` Lincoln Peters 2004-08-27 5:10 ` CXP??? Eric McDonald 1 sibling, 0 replies; 45+ messages in thread From: Lincoln Peters @ 2004-08-27 1:50 UTC (permalink / raw) To: Elijah Meeks; +Cc: Xconq list On Thu, 2004-08-26 at 12:12, Elijah Meeks wrote: > Okay, so you don't get cxp from ranged attacks, unless > the ranged attack is performed against a unit in the > hex adjacent? And you only get cxp if the attack > misses?? I finally took a good look at cxp, after > assuming that I wasn't paying attention before, but > now that I have, it looks screwy. Does anyone have > any firm rules on how cxp works and whether or not > it's supposed to work like this? It seems haphazard. The behavior you describe certainly sounds wrong to me. Since so few games use CXP, I'm not surprised that there are undicovered bugs in the code. --- Lincoln Peters <sampln@sbcglobal.net> Tell me what to think!!! ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: CXP??? 2004-08-26 22:08 ` CXP??? Elijah Meeks 2004-08-27 1:50 ` CXP??? Lincoln Peters @ 2004-08-27 5:10 ` Eric McDonald 1 sibling, 0 replies; 45+ messages in thread From: Eric McDonald @ 2004-08-27 5:10 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > Okay, so you don't get cxp from ranged attacks, unless > the ranged attack is performed against a unit in the > hex adjacent? And you only get cxp if the attack > misses?? I finally took a good look at cxp, after > assuming that I wasn't paying attention before, but > now that I have, it looks screwy. Does anyone have > any firm rules on how cxp works and whether or not > it's supposed to work like this? It seems haphazard. You may have found a bug, depending on one's interpretation of when cXP should be awarded. The following exists at the end of 'attempt_to_capture_unit': if (chance > 0) { if (atker->cxp < u_cxp_max(a)) atker->cxp += uu_cxp_per_capture(a, o); /* (should not increment if side just changed?) */ if (other->cxp < u_cxp_max(o)) other->cxp += uu_cxp_per_capture(o, a); } The "problem" is that experience is always being gained whenever 'chance' is greater than 0, even if the capture is determined to have failed. The misses that you are seeing are also attempted captures (restricted to range <= 1), which is why combat experience is being "incorrectly" gained. The other way to gain experience is with model 0 attacks and fires. However, looking at this code makes me realize that it may also be buggy, again depending on one's interpretation of combat experience. The question here is: should failed attempts gain as much experience as successful attempts? Eric P.S. It should be noted that the defender can gain cXP just being attacked or fired upon, and it gains the same amount as if it was the attacker. Defenders also gain experience from being captured and resisting capture (as seen in the above code). Both of these cases seem a bit odd to me. ^ permalink raw reply [flat|nested] 45+ messages in thread
[parent not found: <20040827050942.5961.qmail@web13122.mail.yahoo.com>]
* Re: CXP??? [not found] <20040827050942.5961.qmail@web13122.mail.yahoo.com> @ 2004-08-27 17:09 ` Eric McDonald 2004-08-28 2:51 ` CXP??? Elijah Meeks 0 siblings, 1 reply; 45+ messages in thread From: Eric McDonald @ 2004-08-27 17:09 UTC (permalink / raw) To: Elijah Meeks, xconq7 Elijah Meeks wrote: > I have yet to see a unit gain experience from a > fire-action, except in cases where the unit it's > firing on is adjacent. It would seem that someone was a bit sloppy with the code, and "recycled" the 'chance' variable for determining retreat chance, after using it for hit chance. So, if the defender's retreat chance is 0% (the default), then no combat experience is gained. This is a bug by any other name. I will fix it in my sources. Until you have a new Xconq release to play with, I would recommend that you set the 'retreat-chance' to 1% for all units (unless you wish them have a higher retreat chance for other reasons); this weird hack should allow for combat experience to be gained. > I think, barring seperate tables for cxp-per-attack, > cxp-per-hit, cxp-per-defend, cxp-per-capture and > cxp-per destruction, I say keep it all as cxp for each > attack and keep it two-way. You should get experience > for surviving certain attacks but, of course, it would > seem more realistic if you were able to tailor them. This is what I was getting at. However, I plan on leaving things the way they are for the time being. Eric ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: CXP??? 2004-08-27 17:09 ` CXP??? Eric McDonald @ 2004-08-28 2:51 ` Elijah Meeks 0 siblings, 0 replies; 45+ messages in thread From: Elijah Meeks @ 2004-08-28 2:51 UTC (permalink / raw) To: Eric McDonald, xconq7 > It would seem that someone was a bit sloppy with the > code, and > "recycled" the 'chance' variable for determining > retreat chance, after > using it for hit chance. So, if the defender's > retreat chance is 0% (the > default), then no combat experience is gained. This > is a bug by any > other name. I will fix it in my sources. Until you > have a new Xconq > release to play with, I would recommend that you set > the > 'retreat-chance' to 1% for all units (unless you > wish them have a higher > retreat chance for other reasons); this weird hack > should allow for > combat experience to be gained. Ah ha. Thanks for catching that, Eric. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2004-08-27 17:09 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-20 16:22 Three thoughts mskala 2004-08-20 18:34 ` Eric McDonald 2004-08-20 21:17 ` Andreas Bringedal 2004-08-20 21:28 ` Eric McDonald 2004-08-20 23:57 ` Andreas Bringedal 2004-08-21 1:21 ` Eric McDonald 2004-08-21 4:35 ` Jim Kingdon 2004-08-21 20:38 ` Jim Kingdon 2004-08-20 22:03 ` Elijah Meeks 2004-08-20 23:27 ` Eric McDonald 2004-08-21 1:17 ` mskala 2004-08-21 2:31 ` Eric McDonald 2004-08-21 4:33 ` mskala 2004-08-22 3:09 ` Hans Ronne 2004-08-22 6:38 ` Item Units Elijah Meeks 2004-08-22 9:37 ` Eric McDonald 2004-08-24 1:43 ` Lincoln Peters 2004-08-24 2:38 ` Eric McDonald 2004-08-24 2:51 ` Lincoln Peters 2004-08-24 3:32 ` Eric McDonald 2004-08-22 14:00 ` Three thoughts mskala 2004-08-22 18:56 ` Hans Ronne 2004-08-22 19:16 ` Lincoln Peters 2004-08-23 4:31 ` Jim Kingdon 2004-08-23 13:04 ` Elijah Meeks 2004-08-24 18:07 ` Eric McDonald 2004-08-24 20:59 ` Elijah Meeks 2004-08-25 0:54 ` Unit-Image Bug Elijah Meeks 2004-08-25 4:58 ` Eric McDonald 2004-08-23 16:48 ` Three thoughts Eric McDonald 2004-08-24 0:55 ` Lincoln Peters 2004-08-24 2:09 ` Eric McDonald 2004-08-24 3:02 ` Lincoln Peters 2004-08-24 18:12 ` Eric McDonald 2004-08-25 5:34 ` Jim Kingdon 2004-08-25 17:16 ` Lincoln Peters 2004-08-25 22:09 ` Jim Kingdon 2004-08-26 2:15 ` Eric McDonald 2004-08-26 6:17 ` Jim Kingdon 2004-08-26 19:12 ` Eric McDonald 2004-08-26 22:08 ` CXP??? Elijah Meeks 2004-08-27 1:50 ` CXP??? Lincoln Peters 2004-08-27 5:10 ` CXP??? Eric McDonald [not found] <20040827050942.5961.qmail@web13122.mail.yahoo.com> 2004-08-27 17:09 ` CXP??? Eric McDonald 2004-08-28 2:51 ` CXP??? Elijah Meeks
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).