* (Mac?) Interface q's @ 2004-05-29 20:47 Tom Schaub 2004-05-29 21:17 ` Eric McDonald ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Tom Schaub @ 2004-05-29 20:47 UTC (permalink / raw) To: xconq7 I am concerned that my play habits may be sufficiently unorthodox that I may be unintentionally testing little-used portions of the Xconq code or little-explored interaction between code segments. Similarly, I fear that games I develop would be inadequately tested for "normal" users if I'm using a strange set-up. So... First, how common is use of the Sequential option? I prefer this form of play, since I am usually playing solitaire. Is the structure of the Xconq code such that separate testing of a game module is needed to assure proper behavior in simultaneous, multi-player mode? Second, what is the "standard" or most usual setup for the following interface parameters: 1) Move on click 2) Auto jump next 3) Auto end turn I keep get confused trying to find the most convenient way to play the games. Turning any of the above options to "true" is somewhat uncomfortable for my style of game play, but I have the impression that most players turn all 3 of these on (they are the defaults). Re auto jump next: I always turn this off, preferring to select which unit to move next manually. I use two different approaches (usually at the same time): A) I open a List window to view all my units and easily see which are idle and/or have unused ACP. Clicking in the list window changes the selected unit in the map window as well and auto-centers the map. B) I turn off "move on click" so that clicking on a unit in the map window selects it. But I get some strange behavior in this mode (see separate email for but report), so I suspect this is unorthodox. But I play this way because of the next question... Third, is there some way to manually select the next unit to give orders to when "move on click" is true? Using the list window works, but is there some command-click or character code that lets one select the unit using the mouse? With move on click true, clicking on another unit tries to move the already active unit onto/into the clicked unit. With move on click false, typing "m" in the mac interface sets the interface to interpret the next click as the target hex. Isn't there a similar "hotkey" with move on click on that will cause the interface to interpret the next map click as selecting a new active unit? Fourth, is there any way to control the order in which "auto jump" visits my units (at the player interface level, not the game design level)? Thanks in advance for your advice. Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (Mac?) Interface q's 2004-05-29 20:47 (Mac?) Interface q's Tom Schaub @ 2004-05-29 21:17 ` Eric McDonald 2004-05-29 21:23 ` Wrecking as a result of starvation Elijah Meeks 2004-05-30 5:54 ` (Mac?) Interface q's Jim Kingdon 2004-06-04 21:12 ` Hans Ronne 2 siblings, 1 reply; 7+ messages in thread From: Eric McDonald @ 2004-05-29 21:17 UTC (permalink / raw) To: Tom Schaub; +Cc: xconq7 On Sat, 2004-05-29 at 14:46, Tom Schaub wrote: > First, how common is use of the Sequential option? I prefer this form > of play, since I am usually playing solitaire. Is the structure of the > Xconq code such that separate testing of a game module is needed to > assure proper behavior in simultaneous, multi-player mode? The separate testing of the simultaneous play doesn't hurt. I think quite a few of the games in the library are sequential by default, and I think it is probably the preference of many people to play in sequential mode. As far as your Mac questions are concerned, Hans is probably the best one to answer those, since I don't even own a Mac that is capable of running Xconq right now. Unfortunately, Hans is going to be busy with the real world for at least the next week. I am assuming that Stan might be able help you with the questions though. As far as your fourth question is concerned: the next unit is scheduled at the level of the Xconq kernel. If an interface wanted to provide an alternate unit scheduling, it would have to run a scheduler at the interface level. I doubt that the Mac interface has a separate scheduler, but I haven't looked at its code too much. Eric ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Wrecking as a result of starvation 2004-05-29 21:17 ` Eric McDonald @ 2004-05-29 21:23 ` Elijah Meeks 0 siblings, 0 replies; 7+ messages in thread From: Elijah Meeks @ 2004-05-29 21:23 UTC (permalink / raw) To: xconq7 > Those ideas sound like they could open up fun > possibilities, and I can > think of interesting things I'd do with them, but > I'm concerned that once > we start down this road, I don't know where we'll > end up. It could easily > become a lot more complicated than you describe. > For instance, these > proposals also sound cool: > > 3. Maybe I want there to be more than one possible > wrecked-type. If a > human is killed by a vampire, *maybe* he rises as a > new vampire but maybe > he just remains dead. So all the entries in your > new tables and > properties should be weighted probability lists of > unit types instead of > just unit types. > > 4. Why should the consequences of death be only > vanishing or conversion to > a single unit of a new type? Some vampires can turn > themselves into > flocks of bats, so maybe when you "kill" one of > those he should be > replaced by several new units representing > individual bats. Other > vampires defend themselves by turning into a cloud > of smoke, so the death > of one of those should add a dice-spec controlled > amount of the smoke > coating terrain type to the current cell. Instead > of just weighted > probability lists of unit types, the table entries > all have to be weighted > lists of death consequence specifiers, which have a > yet-to-be-designed and > highly expressive syntax... While I'm all for giving designers more latitude through GDL, all that needs to be done right now with wreck-types is to do a side check and then a resulting kill and you'd already have the chance to do some fun tricks. For instance, you could have four sides: Zombies, Vampires, Body Snatchers and Humans. Now, zombies can only be owned by the 'Zombie' side, vampires by the 'Vampire' side, pod people by the 'Body Snatcher' side and, of course, humans by the 'Human' side. Then all you do is wreck-type the humans to vamps, wreck-type the vamps to pod people, wreck-type the pod-people to zombies. I think you also have to set up a capture table, I can't quite remember how I managed to work it before. If the code did what I think it's supposed to, then when a zombie kills a human, it would kill through the units his side was not allowed to have, until it got to a zombie. Of course, you'd have to explain to the player that only humans can be turned into vampires, while humans and vampires can be turned into pod people and anybody can be turned into a zombie, but this sounds like an added bonus. Actually, that sounds like a fun game. You could have different kinds of humans, different kinds of vamps, little pod dogs and, maybe fast zombies and slow zombies... Quick, somebody fix the wreck-type code, I've got a game to write!! __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (Mac?) Interface q's 2004-05-29 20:47 (Mac?) Interface q's Tom Schaub 2004-05-29 21:17 ` Eric McDonald @ 2004-05-30 5:54 ` Jim Kingdon 2004-05-30 6:21 ` Lincoln Peters 2004-06-04 21:12 ` Hans Ronne 2 siblings, 1 reply; 7+ messages in thread From: Jim Kingdon @ 2004-05-30 5:54 UTC (permalink / raw) To: tom_and_sue_schaub; +Cc: xconq7 > First, how common is use of the Sequential option? I prefer this form > of play, since I am usually playing solitaire. The screwy part is that Sequential affects the game balance (at least in the standard game). Basically, it is a pretty big advantage to move second, because the first-moving player will often expend their ACPs and thus be unable to counter-attack. The second-moving player doesn't have the chance to choose to spend the ACPs on movement rather than counter-attack, but they do have the ability to spend the ACPs on counter-attack if there are any attacks, and then use them for something else if there were no attacks. The only way the first-moving player can get a counter-attack is to put units in reserve, and taken to an extreme, this would mean never moving. Playing against the AI, if you set non-sequential, the AI will typically move first (unless you type pretty fast). If you set sequential, it depends on the order of the sides in the sides list. So for a challenging game, set sequential and make sure you are first on the list, before the AI(s). With human vs human, there is an incentive to stall. Stan once mentioned something to me about wanting some kind of feature to give a timeout or compulsion to move or something. I suspect that re-thinking the combat system might be a cleaner solution (although hardly a small one - even with all its flaws the standard game has generally been more balanced/enjoyable than most of the others that I've tried, including some combat model 1 games). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (Mac?) Interface q's 2004-05-30 5:54 ` (Mac?) Interface q's Jim Kingdon @ 2004-05-30 6:21 ` Lincoln Peters 2004-05-30 17:57 ` Jim Kingdon 0 siblings, 1 reply; 7+ messages in thread From: Lincoln Peters @ 2004-05-30 6:21 UTC (permalink / raw) To: Jim Kingdon; +Cc: Xconq list On Sat, 2004-05-29 at 22:54, Jim Kingdon wrote: > > First, how common is use of the Sequential option? I prefer this form > > of play, since I am usually playing solitaire. > > The screwy part is that Sequential affects the game balance (at least > in the standard game). Basically, it is a pretty big advantage to > move second, because the first-moving player will often expend their > ACPs and thus be unable to counter-attack. The second-moving player > doesn't have the chance to choose to spend the ACPs on movement rather > than counter-attack, but they do have the ability to spend the ACPs on > counter-attack if there are any attacks, and then use them for > something else if there were no attacks. The only way the > first-moving player can get a counter-attack is to put units in > reserve, and taken to an extreme, this would mean never moving. I tried to work around this issue in my games by using negative ACP's (see bolodd2.g, bolodd3.g, or the recently-posted knights.g). If a single unit is attacked by a horde of enemy units, it is likely that the unit will end the turn with a negative number of ACP's and will start the next turn with only 1 ACP. This happens no matter which side you're on. --- Lincoln Peters <sampln@sbcglobal.net> You mean now I can SHOOT YOU in the back and further BLUR th' distinction between FANTASY and REALITY? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (Mac?) Interface q's 2004-05-30 6:21 ` Lincoln Peters @ 2004-05-30 17:57 ` Jim Kingdon 0 siblings, 0 replies; 7+ messages in thread From: Jim Kingdon @ 2004-05-30 17:57 UTC (permalink / raw) To: xconq7 > I tried to work around this issue in my games by using negative > ACP's Hmm, interesting. I found the whole concept of negative ACP's a bit confusing when I first tried to play roman.g, but if it solves or helps the the problem with first vs second player, it might be worth a second look. (The key setting is, I presume, the setting of acp-min to a negative number). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: (Mac?) Interface q's 2004-05-29 20:47 (Mac?) Interface q's Tom Schaub 2004-05-29 21:17 ` Eric McDonald 2004-05-30 5:54 ` (Mac?) Interface q's Jim Kingdon @ 2004-06-04 21:12 ` Hans Ronne 2 siblings, 0 replies; 7+ messages in thread From: Hans Ronne @ 2004-06-04 21:12 UTC (permalink / raw) To: Tom Schaub; +Cc: xconq7 >I am concerned that my play habits may be sufficiently unorthodox that >I may be unintentionally testing little-used portions of the Xconq code >or little-explored interaction between code segments. Similarly, I fear >that games I develop would be inadequately tested for "normal" users if >I'm using a strange set-up. So... It is only good if you test little used options, since that is where we are going to find new bugs. Your testing of the Mac survey mode was helpful in revealing several bugs. >First, how common is use of the Sequential option? I prefer this form >of play, since I am usually playing solitaire. Is the structure of the >Xconq code such that separate testing of a game module is needed to >assure proper behavior in simultaneous, multi-player mode? It used to be the case that some games were simultaneous mode only, and some sequential only. However, I enabled both modes in all games when I updated the game library earlier this year. Similarly, the world-seen and see-all options were also enabled in all games. This in order to provide more variation and player freedom. If a game module works in sequential mode, it should also work in simultaneous mode, and vice versa. So you should not have to worry about this as a game designer. If you find a feature that works in only one mode, this is a bug. >Second, what is the "standard" or most usual setup for the following >interface parameters: > >1) Move on click >2) Auto jump next >3) Auto end turn The standard (default) option is to have all three on. However, the interfaces differ in how these three settings are handled. In the tcltk interface, move on click and auto jump next are always toggled on or off together. The two modes are called "move mode" (both on) and "survey mode" (both off) and you can toggle mode either by clicking the button at the top of the control panel, by switching mode in the Side menu, or by just hitting the "z" key. The "map" help node in the tcltk interface claims that auto end trun also is toggled off in survey mode, but this is not true. In fact, you cannot at present turn auto end turn off in the tcltk interface. This is either a bug or a documentation error, depending on how you look at it. In the Mac native interface, you have more freedom. All three settings can be toggled individually from the Side menu. In addition, move on click and auto jump next can be toggled together by clicking a control panel button or hitting the "z" key, just as in the tcltk interface. I have contemplated some changes that would make the two interfaces more similar to each other. Specifically, to add the ability to turn off auto end turn in the tcltk interface, and to eliminate the possibility of toggling move on click and auto jump next independently of each other in the mac interface. The latter possibility can give rise to confusing situations, as your play testing of these little used options revelaed. >Third, is there some way to manually select the next unit to give >orders to when "move on click" is true? No. I always switch to survey mode (by hitting the "z" key) if I want to pick the next unit myself. >Fourth, is there any way to control the order in which "auto jump" >visits my units (at the player interface level, not the game design >level)? Not at present. I guess one could write new interface code that prompts the player to select the new unit, but this would not be trivial to do. Hans ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-06-04 21:12 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-29 20:47 (Mac?) Interface q's Tom Schaub 2004-05-29 21:17 ` Eric McDonald 2004-05-29 21:23 ` Wrecking as a result of starvation Elijah Meeks 2004-05-30 5:54 ` (Mac?) Interface q's Jim Kingdon 2004-05-30 6:21 ` Lincoln Peters 2004-05-30 17:57 ` Jim Kingdon 2004-06-04 21:12 ` Hans Ronne
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).