* 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; 43+ 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] 43+ messages in thread
* Re: CXP??? 2004-08-27 17:09 ` CXP??? Eric McDonald @ 2004-08-28 2:51 ` Elijah Meeks 2004-08-28 3:47 ` Multiple Image Use Elijah Meeks 0 siblings, 1 reply; 43+ 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] 43+ messages in thread
* Multiple Image Use 2004-08-28 2:51 ` CXP??? Elijah Meeks @ 2004-08-28 3:47 ` Elijah Meeks 2004-08-28 4:02 ` Eric McDonald 0 siblings, 1 reply; 43+ messages in thread From: Elijah Meeks @ 2004-08-28 3:47 UTC (permalink / raw) To: xconq7 I've been trying to use Hans' new feature (multiple images for the same unit) but it doesn't seem to show up. At first I thought this was because I was only looking at start-with units and that it didn't support those units, but it doesn't seem to come into play with created units either. I've set up units as (image-name "image1" "image2" "image-etc") and it only uses image1. Have I missed something? _______________________________ 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] 43+ messages in thread
* Re: Multiple Image Use 2004-08-28 3:47 ` Multiple Image Use Elijah Meeks @ 2004-08-28 4:02 ` Eric McDonald 2004-08-28 4:33 ` Elijah Meeks 2004-09-01 7:30 ` Standard Game Graphics Elijah Meeks 0 siblings, 2 replies; 43+ messages in thread From: Eric McDonald @ 2004-08-28 4:02 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 Elijah Meeks wrote: > I've been trying to use Hans' new feature (multiple > images for the same unit) but it doesn't seem to show > up. At first I thought this was because I was only > looking at start-with units and that it didn't support > those units, but it doesn't seem to come into play > with created units either. I've set up units as > (image-name "image1" "image2" "image-etc") and it only > uses image1. Did you try: (image-name ("image1" "image2" "image-etc")) ? The code looks like it might be more amenable to that. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Multiple Image Use 2004-08-28 4:02 ` Eric McDonald @ 2004-08-28 4:33 ` Elijah Meeks 2004-09-01 7:30 ` Standard Game Graphics Elijah Meeks 1 sibling, 0 replies; 43+ messages in thread From: Elijah Meeks @ 2004-08-28 4:33 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 > Did you try: > (image-name ("image1" "image2" "image-etc")) > ? > The code looks like it might be more amenable to > that. That did it, thanks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Standard Game Graphics 2004-08-28 4:02 ` Eric McDonald 2004-08-28 4:33 ` Elijah Meeks @ 2004-09-01 7:30 ` Elijah Meeks 2004-09-01 16:18 ` Jim Kingdon 1 sibling, 1 reply; 43+ messages in thread From: Elijah Meeks @ 2004-09-01 7:30 UTC (permalink / raw) To: xconq7 Would anyone object if I changed all the unit graphics for the standard game from the pikemen to those found on the Trident set? __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-01 7:30 ` Standard Game Graphics Elijah Meeks @ 2004-09-01 16:18 ` Jim Kingdon 2004-09-01 18:30 ` Eric McDonald 0 siblings, 1 reply; 43+ messages in thread From: Jim Kingdon @ 2004-09-01 16:18 UTC (permalink / raw) To: elijahmeeks; +Cc: xconq7 > Would anyone object if I changed all the unit graphics > for the standard game from the pikemen to those found > on the Trident set? I think so. The Trident ones don't look like they'd work at low magnification. If you post a diff, then I can actually try it in xconq, rather than just look at images/trident.gif and try to guess what it would look like in a game. I also don't see units there for all the unit types found in the standard game, and of course it wouldn't look good at all to mix and match. I will note that this could be made a variant (see the existing silhouettes variant for an example). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-01 16:18 ` Jim Kingdon @ 2004-09-01 18:30 ` Eric McDonald 2004-09-02 1:43 ` Elijah Meeks 0 siblings, 1 reply; 43+ messages in thread From: Eric McDonald @ 2004-09-01 18:30 UTC (permalink / raw) To: Jim Kingdon; +Cc: elijahmeeks, xconq7 On Wed, 1 Sep 2004, Jim Kingdon wrote: > I think so. I would tend to side with Elijah on this one. >The Trident ones don't look like they'd work at low > magnification. This can be addressed by creating a custom image family using 'imf' directives. > I also don't see units there for all the unit types found in the > standard game, and of course it wouldn't look good at all to mix and > match. One reason why the Trident images look like they might not fit in is because they are 44x44, whereas the standard Standard images are 32x32, IIRC. If one just takes the Trident marine or mountain troop and rescales it to 32x32, I bet it would fit in quite nicely. As far as the other images (in Standard) go, I am not certain that they absolutely need to be replaced. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-01 18:30 ` Eric McDonald @ 2004-09-02 1:43 ` Elijah Meeks 2004-09-02 4:24 ` Eric McDonald 2004-09-03 2:30 ` Jim Kingdon 0 siblings, 2 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-02 1:43 UTC (permalink / raw) To: Eric McDonald, Jim Kingdon; +Cc: elijahmeeks, xconq7 I'll put together a demo, so we can see how it looks. I think there are enough graphics in the trident set to represent everything, we'll see. Also, there are certain graphics in Opal that seem to come out strange, these tend to be the graphics held in the korea.gif but referenced in opal-rules.g. This problem's cropped up before, it's as if XConq has loaded the old korea.gif and refuses to acknowledge the new one, any ideas? __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-02 1:43 ` Elijah Meeks @ 2004-09-02 4:24 ` Eric McDonald 2004-09-03 2:30 ` Jim Kingdon 1 sibling, 0 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-02 4:24 UTC (permalink / raw) To: Elijah Meeks; +Cc: Jim Kingdon, xconq7 Elijah Meeks wrote: > I'll put together a demo, so we can see how it looks. > I think there are enough graphics in the trident set > to represent everything, we'll see. I wasn't sure about the cities.... > Also, there are certain graphics in Opal that seem to > come out strange, these tend to be the graphics held > in the korea.gif but referenced in opal-rules.g. This > problem's cropped up before, it's as if XConq has > loaded the old korea.gif and refuses to acknowledge > the new one, any ideas? No clue. Are you restarting Xconq between modifications that you make to 'korea.gif'? Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-02 1:43 ` Elijah Meeks 2004-09-02 4:24 ` Eric McDonald @ 2004-09-03 2:30 ` Jim Kingdon 2004-09-03 3:01 ` Elijah Meeks 1 sibling, 1 reply; 43+ messages in thread From: Jim Kingdon @ 2004-09-03 2:30 UTC (permalink / raw) To: xconq7 > I'll put together a demo, so we can see how it looks. Great. That's clearly the next step. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-03 2:30 ` Jim Kingdon @ 2004-09-03 3:01 ` Elijah Meeks 2004-09-03 3:17 ` Eric McDonald 0 siblings, 1 reply; 43+ messages in thread From: Elijah Meeks @ 2004-09-03 3:01 UTC (permalink / raw) To: Jim Kingdon, xconq7 [-- Attachment #1: Type: text/plain, Size: 870 bytes --] Okay, so here's the updated standard.g, which includes a new 'Trident' option, so you can see the graphics in action. I found a freeciv pack with cities, which I added to korea.gif, and I think they'll serve as good replacements for bases, towns and cities. I think, but I don't know, because even with the proper imf references, all I see are the generic gray chips (The old graphics from korea.gif, in whose place I added the new neotrident images). So, I created a new gif, neo-trident.gif, that has these three images, and referenced that instead of korea.gif and it worked just fine. You'll need neo-trident.gif, which I'm going to send to Jim and Eric and anyone else who wants it. I think the game looks better. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush [-- Attachment #2: standard.g --] [-- Type: application/octet-stream, Size: 8352 bytes --] (game-module "standard" (title "Standard Game") (version "7.3+") (blurb "The standard Xconq game, loosely based on WW II ca 1945.") (instructions "Take over the world before you get taken over!") (variants (world-seen false) (see-all false) (world-size (60 30 360)) (sequential false) ("Mostly Land" mostly-land "Generate a world that is mostly (80%) land." (true ;; Adjust so that sea is 20% instead of 70% of the world. (add sea alt-percentile-max 20) (add shallows alt-percentile-min 20) (add shallows alt-percentile-max 21) (add swamp alt-percentile-min 21) (add swamp alt-percentile-max 23) (add (desert plains forest) alt-percentile-min 21) )) ("All Land" all-land "Generate a world that is all different types of land." (true ;; Adjust sea and shallows out of existence, let swamp take all the low spots. (add sea alt-percentile-min 0) (add sea alt-percentile-max 0) (add shallows alt-percentile-min 0) (add shallows alt-percentile-max 0) (add swamp alt-percentile-min 0) (add swamp alt-percentile-max 2) (add swamp wet-percentile-min 0) (add swamp wet-percentile-max 100) (add (desert plains forest) alt-percentile-min 2) ;; Counterproductive to try to set up near water. (add sea country-terrain-min 0) )) ("Ice-Age" ice-age "Generate a world that has normal amounts of water but almost all land is ice." (true (add swamp alt-percentile-min 69) (add swamp alt-percentile-max 70) (add (desert plains forest) alt-percentile-max 74) (add mountains alt-percentile-min 74) (add mountains alt-percentile-max 78) (add ice alt-percentile-min 78) (add ice alt-percentile-max 100) (set edge-terrain swamp) ;; Try to make it so there is room for countries. It still is harder ;; to meet the constraints in a many-player game than the non-iceage ;; variant, but there may be only so much we can/should do. (set country-radius-min 1) (add (sea plains) country-terrain-min (1 3)) (table favored-terrain add (@ plains 20)) ;; To get a somewhat similar number of towns per land, need more ;; towns per plains/desert/forest/mountains. (table independent-density (town plains 3000) (town (desert forest mountains) 500)) ;; In keeping with the ice-age theme change desert to tundra ;; (with no change in properties). (imf "civ-tundra" ((1 1) 214 255 231)) (imf "civ-tundra" ((44 48) (x 2 46 0) (file "civt44x48.gif" 186 152))) (add desert image-name "civ-tundra") (add desert help "Desert (tundra) is fairly flat but less hospitable than plains") ;; Now pick arctic country names. (set side-library '( (50 (noun "Norwegian") (emblem-name "flag-norway") (unit-namers ((town city) norwegian-place-names))) (50 (noun "Swede") (adjective "Swedish") (emblem-name "flag-sweden") (unit-namers ((town city) swedish-place-names))) (50 (noun "Finn") (adjective "Finnish") (emblem-name "flag-finland") (unit-namers ((town city) finnish-place-names))) (50 (noun "Icelander") (adjective "Icelandic") (emblem-name "flag-iceland") (unit-namers ((town city) icelandic-place-names))) (50 (noun "Canadian") (emblem-name "flag-canada") (unit-namers ((town city) canadian-place-names))) (50 (noun "Russian") (emblem-name "flag-russia") (unit-namers ((town city) russian-place-names))) (50 (noun "Mongol") (adjective "Mongolian") (emblem-name "flag-mongolia") (unit-namers ((town city) mongolian-place-names))) (50 (noun "Nepalese") (emblem-name "flag-nepal") (unit-namers ((town city) nepalese-place-names))) (50 (noun "Afghan") (emblem-name "flag-afghanistan") (unit-namers ((town city) afghan-place-names))) (50 (noun "Chilean") (emblem-name "flag-chile") (unit-namers ((town city) chilean-place-names))) ;; Not sure this image really works for a flag. ;; (50 (noun "Viking") (emblem-name "heroes-viking") ...) ;; (imf "heroes-viking" ((44 44) (file "heroes.gif" 140 354))) ;; Also would like: Tibet, Inuits, Aleutians )) )) ("Large Countries" large "Grow each starting country to take as much land as possible." (true ;; This is the same as country separation. (set country-radius-max 48) (add (town city) unit-growth-chance (100 20)) (add (town city) independent-growth-chance (20 0)) )) ("Noisy" noisy (true (set action-movies '( (move (sound "pop")) )) (set event-movies '( (side-lost (sound "thunder")) (unit-captured (sound "chirr")) (unit-completed (sound "chirr")) (unit-moved (sound "pop-2")) )) )) ("Silhouettes" silhouettes "Use silhouettes for unit display instead of color images." (true ;; No capability for alternate image sets, so do it the hard way. (add infantry image-name "soldiers-s") (add armor image-name "tank-s") (add fighter image-name "fighter-s") (add bomber image-name "4e-s") (add destroyer image-name "dd-s") (add submarine image-name "sub-s") (add troop-transport image-name "ap-s") (add carrier image-name "cv-s") (add battleship image-name "bb-s") (add nuclear-bomb image-name "bomb-s") (add base image-name "airbase-s") (add town image-name "town20-s") (add city image-name "city20-s") )) ("Trident" trident "Use freeciv graphics." (true ;; No capability for alternate image sets, so do it the hard way. (add infantry image-name "trident-riflemen") (add armor image-name "trident-armor") (add fighter image-name "trident-fighter") (add bomber image-name "trident-bomber") (add destroyer image-name "trident-destroyer") (add submarine image-name "trident-submarine") (add troop-transport image-name "trident-transport") (add carrier image-name "trident-carrier") (add battleship image-name "trident-battleship") (add nuclear-bomb image-name "trident-nuclear-missile") (add base image-name "nt-city-white-small") (add town image-name "nt-town-gray-medium") (add city image-name "nt-city-gray-large") (imf "nt-city-gray-large" ((32 32) (file "neo-trident.gif" std 0 0))) (imf "nt-town-gray-medium" ((32 32) (file "neo-trident.gif" std 0 1))) (imf "nt-city-white-small" ((32 32) (file "neo-trident.gif" std 0 2))) )) ) ) (include "stdunit") (include "nat-names") (include "town-names") (include "ng-features") (add B namer "junky") (add (T @) namer "random-town-names") (set default-namer "random-town-names") (set feature-types '(continents islands seas lakes bays (desert 10)(forest 10)(mountains 5) peaks)) (set feature-namers '((islands generic-island-names) (lakes generic-lake-names) (bays generic-bay-names) (seas generic-sea-names) (continents generic-continent-names) (desert generic-desert-names) (forest generic-forest-names) (mountains generic-mountain-names))) (set advantage-min 1) (set advantage-default 1) (set advantage-max 15) (scorekeeper (title "") (do last-side-wins) ) (set scorefile-name "standard.xcq") ;; Leave see-terrain-if-captured to zero. This is so that exploration ;; does not cease early in the game. Alternatives might be to ;; make all hexes within a fixed or randomly determined radius ;; from the captured unit visible, or even a make-terrain like ;; algorithm that generates one single random sized area of visible hexes ;; that nucleates at the captured unit. Some terrain info will leak ;; out via see-others-if-captured - that's a more appropriate quantity ;; than the all-or-nothing see-terrain-if-captured. (table see-others-if-captured (ship ship 50) (base u* 10) (town u* 15) (city u* 100) ) (add places already-seen 100) (add places already-seen-independent 100) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-03 3:01 ` Elijah Meeks @ 2004-09-03 3:17 ` Eric McDonald 2004-09-03 5:10 ` Elijah Meeks 0 siblings, 1 reply; 43+ messages in thread From: Eric McDonald @ 2004-09-03 3:17 UTC (permalink / raw) To: Elijah Meeks; +Cc: Jim Kingdon, xconq7 Elijah Meeks wrote: > You'll need neo-trident.gif, which I'm going to send > to Jim and Eric and anyone else who wants it. I think > the game looks better. Looks good. Personally, I would prefer if your 'Trident' variant was made into the default, and the old graphics were made into some sort of oldtimers variant. I mean, I think a major point of this exercise was to help Xconq present a more polished image to new players, and your new graphics do that much better than the old ones. But, that's just my opinion; I guess we'll have to see what others say. (I suppose some people have been looking at the old graphics for so long that anything new will seem alien and objectionable....) Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-03 3:17 ` Eric McDonald @ 2004-09-03 5:10 ` Elijah Meeks 2004-09-03 5:11 ` Jim Kingdon ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-03 5:10 UTC (permalink / raw) To: Eric McDonald; +Cc: Jim Kingdon, xconq7 > Looks good. Personally, I would prefer if your > 'Trident' variant was > made into the default, and the old graphics were > made into some sort of > oldtimers variant. I mean, I think a major point of > this exercise was to > help Xconq present a more polished image to new > players, and your new > graphics do that much better than the old ones. But, > that's just my > opinion; I guess we'll have to see what others say. > (I suppose some > people have been looking at the old graphics for so > long that anything > new will seem alien and objectionable....) I agree that it should be the default, but I also agree that it should be a group decision. The one problem, which I believe Jim pointed out and proved true, is that it doesn't look so good at the 16 unit/hex resolution. You can tell the difference between units because there are pretty good primary color distinctions (Infantry brown, armor green, fighter gray) but it's pretty ugly. The two solutions I see are: 1. Make specific imf 4 4 definitions that reference the old silhouettes, because they're more recognizable at that resolution. 2. Set unit limits per hex at four, which is the max amount of Trident units in a hex that are still recognizable and look decent. I like this both from the graphical viewpoint and the gameplay viewpoint, simply because I think more than four units in a hex is unweildy. You still have problems with cities and transports, but that'll be solved next week, when Eric's Occupant Dialog Box Fix is out... Right, Eric?* I think it's obvious that I prefer solution 2. And I still think we need a forum. And a better webpage (Christ, I've been here for two years and I still have a hard time finding the right link for downloads or mailing lists or manuals and everytime I see the XConq website, I think, "1992?"). And neural nets. And fully 3D units. And salaries for game designers. And groupies. And an XConq Company Cruise. 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] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-03 5:10 ` Elijah Meeks @ 2004-09-03 5:11 ` Jim Kingdon 2004-09-03 6:10 ` Jim Kingdon 2004-09-03 23:11 ` Standard Game Graphics Eric McDonald 2 siblings, 0 replies; 43+ messages in thread From: Jim Kingdon @ 2004-09-03 5:11 UTC (permalink / raw) To: elijahmeeks; +Cc: xconq7 > I suppose some people have been looking at the old graphics for so > long that anything new will seem alien and objectionable.... Well, sure, and I'm trying to separate the familiarity effect from the real pros and cons. * The bomber and fighter look fairly similar to each other, especially when they are incomplete units (there is no color difference in this case). * The infantry doesn't show up all that well against the forest terrain. As for not being easy to distinguish when they are small, yes, that seems true. For my own play, as long as it is a variant I'm sure I can figure out which one I like and pick it. But for people who don't play as much xconq, or are trying it anew, the decision we make is more important. On the one hand, I'm tempted to say try the trident images at least for a while, and see how they stand the test of time. That way at least it doesn't seem as if xconq is permanently and unalterably ossified. But my other impulse is to make the trident images a variant for a while and see if they get a following (that way, perhaps avoiding a mistake which might make xconq look bad, and giving a chance to notice/solve problems). > 1. Make specific imf 4 4 definitions that reference > the old silhouettes But then the shape would vary at different sizes. I think you'd want to concoct new 4x4's which are silhouette-like, but whose shapes are more similar to the larger versions. > 2. Set unit limits per hex at four Doesn't seem like a small change (either from the gameplay point of view, or the occupant point of view, or whatever). It might be a good idea - it just seems like it would take a while to get this right. In an unrelated matter, the help screens don't seem to list the fact that only cities (not towns) can develop nukes in the standard game. This would be acp-to-develop and tech-to-develop. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-03 5:10 ` Elijah Meeks 2004-09-03 5:11 ` Jim Kingdon @ 2004-09-03 6:10 ` Jim Kingdon 2004-09-03 17:18 ` Changing the Standard Game Elijah Meeks 2004-09-03 23:11 ` Standard Game Graphics Eric McDonald 2 siblings, 1 reply; 43+ messages in thread From: Jim Kingdon @ 2004-09-03 6:10 UTC (permalink / raw) To: elijahmeeks; +Cc: mcdonald, xconq7 > And a better webpage (Christ, I've been here for two years and I still > have a hard time finding the right link for downloads or mailing lists > or manuals and everytime I see the XConq website, I think, "1992?"). Diffs to the website are welcome (you can get everything from htdocs in CVS). This is easier to fix than a forum, because it doesn't require installing any new software or anything. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Changing the Standard Game 2004-09-03 6:10 ` Jim Kingdon @ 2004-09-03 17:18 ` Elijah Meeks 2004-09-04 2:06 ` Eric McDonald 2004-09-04 17:46 ` Lincoln Peters 0 siblings, 2 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-03 17:18 UTC (permalink / raw) To: Jim Kingdon; +Cc: mcdonald, xconq7 I think the 4 unit per hex limit is a major change, but I think it'd make for a better game. I believe, and maybe I'm in the minority here, in sort of a French Chef ideal of game design. That is, looking good is an important aspect of gameplay. I'm no FPS-junkie but I've never played the standard game because it looked like something I'd never have loaded on my Commodore 64. But (Shameless Plug Warning) after updating the graphics I found it was a fun little game. Much quicker than (Shameless Plug Warning) fine games like Bellum or AWLS. A four-unit per hex limit, while altering a major gameplay aspect from the old style, would improve the visual quality of the game immeasurably, regardless of whether we believe it would be a pure gameplay improvement. For most of the people who pop on here and post once or twice, this game IS XConq, and I think it would be a better first impression with Trident graphics and 4/hex limits. There's already one 'Classic' XConq, from ver. 5, so maybe the current Standard game could become 'Classic pre7.5' on the game list, and the Trident/4hex would be the new 'Standard Game'. After all, the players we can expect to look for such a 'Classic pre7.5' game on the games list are precisely the players who would want to play it, while the ones we'd expect to only try out the 'Standard' game are newbies, hence people less concerned about its resemblance to the old XConq Standard game and for whom it's more important that we show what XConq 7.5 can do. If they get into it, then they're welcome to start a retro movement and only play the pre7.5 or even ver5 or only in curses or on LED lights or punchcard or whatever. > Diffs to the website are welcome (you can get > everything from htdocs > in CVS). This is easier to fix than a forum, > because it doesn't > require installing any new software or anything. > If I changed the website (I reference my one site: castironlife.sf.net) it would be a sidegrade from Looks Old to Looks Crappy. I'm just hoping a friendly, brilliant, lurking web designer is reading this... _______________________________ 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] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-03 17:18 ` Changing the Standard Game Elijah Meeks @ 2004-09-04 2:06 ` Eric McDonald 2004-09-04 17:46 ` Lincoln Peters 1 sibling, 0 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-04 2:06 UTC (permalink / raw) To: Elijah Meeks; +Cc: Jim Kingdon, xconq7 On Thu, 2 Sep 2004, Elijah Meeks wrote: > and maybe I'm in the minority here, in sort of a > French Chef ideal of game design. As long as I don't have to pay $15 for a two-bite-and-its-gone appetizer. > little game. Much quicker than (Shameless Plug > Warning) fine games like Bellum or AWLS. I'm not sure that Bellum belongs in the "fine games" category. More like "unfinished development" / "early experiment".... I should probably get around to actually giving it official "unfinished" status one of these days. > improvement. For most of the people who pop on here > and post once or twice, this game IS XConq, I agree. > Trident graphics and 4/hex limits. There's already > one 'Classic' XConq, from ver. 5, so maybe the current > Standard game could become 'Classic pre7.5' on the > game list, and the Trident/4hex would be the new > 'Standard Game'. This sounds like it could be a reasonable solution. > can do. If they get into it, then they're welcome to > start a retro movement and only play the pre7.5 or > even ver5 or only in curses or on LED lights or > punchcard or whatever. Moving right along on the PDP-11 port for Xconq.... > Looks Old to Looks Crappy. I'm just hoping a > friendly, brilliant, lurking web designer is reading > this... Build a better Standard game and they will come? Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-03 17:18 ` Changing the Standard Game Elijah Meeks 2004-09-04 2:06 ` Eric McDonald @ 2004-09-04 17:46 ` Lincoln Peters 2004-09-05 1:48 ` Eric McDonald 1 sibling, 1 reply; 43+ messages in thread From: Lincoln Peters @ 2004-09-04 17:46 UTC (permalink / raw) To: Xconq list On Thu, 2004-09-02 at 23:10, Elijah Meeks wrote: > For most of the people who pop on here > and post once or twice, this game IS XConq A better interface (specifically a better "Welcome" screen) might make it clearer to most players that Xconq is not just one game (important for those who enjoy strategy games that are based on something other than World War II). I can envision a "Welcome" screen that looks like the following (which, as usual, I designed with Glade without having to write any code): http://homepage.mac.com/lmpeters/welcome1.png http://homepage.mac.com/lmpeters/welcome2.png http://homepage.mac.com/lmpeters/welcome3.png http://homepage.mac.com/lmpeters/welcome4.png http://homepage.mac.com/lmpeters/welcome5.png http://homepage.mac.com/lmpeters/welcome6.png What I did here was use a GNOME "Druid" to produce a setup window with multiple pages (known to Windows users as a "Wizard"), much like the existing "Welcome" screen for the TclTk interface but with a layout that (I think) is more visually appealing. Furthermore, as soon as you click "Apply", you could theoretically jump to the existing SDL interface and thus leave behind anything that even remotely resembles an Office app. --- Lincoln Peters <sampln@sbcglobal.net> Your good nature will bring you unbounded happiness. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-04 17:46 ` Lincoln Peters @ 2004-09-05 1:48 ` Eric McDonald 2004-09-05 6:02 ` Feature Request: Advance Prohibits Advance Elijah Meeks ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-05 1:48 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list Lincoln Peters wrote: > On Thu, 2004-09-02 at 23:10, Elijah Meeks wrote: > >>For most of the people who pop on here >>and post once or twice, this game IS XConq > > > A better interface (specifically a better "Welcome" screen) might make > it clearer to most players that Xconq is not just one game (important > for those who enjoy strategy games that are based on something other > than World War II). Well, I think that part of the problem might be simply that when you call one game the "standard" game, it implies that the others are either substandard or offshoots of it. When I first tried out Xconq back in 1999 or 2000, this was one of the things that kept me away from the other games. And I barely did more than open a few of the others before I abandoned Xconq then because the UI was not very good. Even when I came back to it in the middle of 2003, I started playing the Standard game on the Tcl/Tk interface, because I assumed (possibly correctly) that the Standard game would give me the best playing experience. There is this perception that the Standard game is brought to you by "the developers", whereas the other games are just made by "other people", if you know what I mean.... >I can envision a "Welcome" screen that looks like > the following (which, as usual, I designed with Glade without having to > write any code): Of course, code would still have to be added for event handlers for the various UI elements, so that a click on, say, a radio button will translate into the proper Xconq internals being updated. > http://homepage.mac.com/lmpeters/welcome1.png > http://homepage.mac.com/lmpeters/welcome2.png > http://homepage.mac.com/lmpeters/welcome3.png > http://homepage.mac.com/lmpeters/welcome4.png > http://homepage.mac.com/lmpeters/welcome5.png > http://homepage.mac.com/lmpeters/welcome6.png Looks interesting. > Furthermore, as soon as you click "Apply", you could theoretically jump > to the existing SDL interface and thus leave behind anything that even > remotely resembles an Office app. I would suggest the "Apply" button be relabelled to "Accept" or "Start Game". What you propose is interesting. This would certainly save time in the development of the startup screens, a task I have only half been looking forward to. The tradeoff is that the Windows installer would get quite a bit larger, because we cannot reasonably assume that a Windows user would have the GDK, GTK+, Pango, etc. libraries on his/her system. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Feature Request: Advance Prohibits Advance 2004-09-05 1:48 ` Eric McDonald @ 2004-09-05 6:02 ` Elijah Meeks 2004-09-05 16:25 ` Eric McDonald 2004-09-05 16:55 ` Lincoln Peters 2004-09-05 15:52 ` Changing the Standard Game Lincoln Peters 2004-09-05 20:14 ` Jim Kingdon 2 siblings, 2 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-05 6:02 UTC (permalink / raw) To: Xconq list As it stands, there's no way to simulate different tech paths. I'd like to have a way to shut off advances if certain advances are researched, so that sides can choose different directions to take. For example, if we have two spacefaring societies, we can have two techs, one being Ground War Focus and the other Stellar War Focus. The side that pics Ground War Focus spends less on developing AT-ATs and Battlemechs and more for its Cordships and A-Wing Starfighters while the other side has to pay extra to develop its hovertanks but manages to design galaxy-class starships and battlestars at a faster rate. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 6:02 ` Feature Request: Advance Prohibits Advance Elijah Meeks @ 2004-09-05 16:25 ` Eric McDonald 2004-09-05 16:41 ` mskala ` (2 more replies) 2004-09-05 16:55 ` Lincoln Peters 1 sibling, 3 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-05 16:25 UTC (permalink / raw) To: Elijah Meeks; +Cc: Xconq list Elijah Meeks wrote: > As it stands, there's no way to simulate different > tech paths. I'd like to have a way to shut off > advances if certain advances are researched, so that > sides can choose different directions to take. For > example, if we have two spacefaring societies, we can > have two techs, one being Ground War Focus and the > other Stellar War Focus. The side that pics Ground > War Focus spends less on developing AT-ATs and > Battlemechs and more for its Cordships and A-Wing > Starfighters while the other side has to pay extra to > develop its hovertanks but manages to design > galaxy-class starships and battlestars at a faster > rate. I'm wondering what the best way to model this is. I think that maybe instead of advances totally shutting out other advances, that maybe we should think about something like 'advance-adds-rp-requirement' and 'advance-multiplies-rp-requirement' advance-vs-advance tables. This would allow for a game designer to make researching certain advances arbitrarily more difficult (or easier). This way a "Ground War Focus" civilization could _eventually_ research the "Space War Focus" line and thereby get good at both, and vice versa. The ability to make researching advances easier is also interesting, because, for example, in a Civ-like game, after researching "Formal Logic" and "Empirical Science", a civilization might be able to make a whole slew of scientific and technological advances much more rapidly than it would otherwise. Taken to extremes, the proposed tables could shut off advances by boosting the RP requirement to some very large number (relative infinity?), or make gaining an advance trivial by multiplying its RP requirement by 0%. I'll think about it some more. I haven't dealt much with the advances aspect of Xconq before. If it's an easy feature to add (and test), I might go ahead and add it in the near future. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:25 ` Eric McDonald @ 2004-09-05 16:41 ` mskala 2004-09-05 16:54 ` Eric McDonald 2004-09-05 17:01 ` Elijah Meeks 2004-09-05 16:48 ` Elijah Meeks 2004-09-05 16:50 ` mskala 2 siblings, 2 replies; 43+ messages in thread From: mskala @ 2004-09-05 16:41 UTC (permalink / raw) To: Eric McDonald; +Cc: Elijah Meeks, Xconq list Can't we make some advances require particular materials? I think we already can, and if not, that would be easy to add. Then we could easily do both behaviours. For "you may only have one of these advances", there's a material of which you only get a little bit, and you need all of it to do either advance. Once you have done one, you can't do the other. For "it's very hard, but possible, to do both of these advances", it's a similar story, but you can eventually with a lot of work gain more of the special material. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:41 ` mskala @ 2004-09-05 16:54 ` Eric McDonald 2004-09-05 17:11 ` mskala 2004-09-05 17:01 ` Elijah Meeks 1 sibling, 1 reply; 43+ messages in thread From: Eric McDonald @ 2004-09-05 16:54 UTC (permalink / raw) To: mskala; +Cc: Elijah Meeks, Xconq list mskala@ansuz.sooke.bc.ca wrote: > Can't we make some advances require particular materials? I think we > already can, and if not, that would be easy to add. Then we could easily > do both behaviours. For "you may only have one of these advances", > there's a material of which you only get a little bit, and you need all of > it to do either advance. Once you have done one, you can't do the other. > For "it's very hard, but possible, to do both of these advances", it's a > similar story, but you can eventually with a lot of work gain more of the > special material. From kernel/table.def: DEF_AM_TABLE("advance-consumption-per-rp", am_consumption_per_rp, "amount of material consumed to add one research point to this advance", amconsumptionperrp, constamconsumptionperrp, 0, 0, TABHI, TABINT) If I understand what you're saying, you're suggesting that each side should have a finite quantity of a certain material in its treasury, and that material can only be used to research one, and no more than one, advance. The chosen advance then sets the tone for which other advances can be reserached (through the 'advance-needed-to-research' table). Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:54 ` Eric McDonald @ 2004-09-05 17:11 ` mskala 0 siblings, 0 replies; 43+ messages in thread From: mskala @ 2004-09-05 17:11 UTC (permalink / raw) To: Eric McDonald; +Cc: Elijah Meeks, Xconq list On Sun, 5 Sep 2004, Eric McDonald wrote: > If I understand what you're saying, you're suggesting that each side > should have a finite quantity of a certain material in its treasury, and > that material can only be used to research one, and no more than one, > advance. The chosen advance then sets the tone for which other advances > can be reserached (through the 'advance-needed-to-research' table). Right. With some variations, I think that kind of approach can produce most of the same behaviours as each of the proposed new features, and it already should work with the existing code. One way it might fall down would be if there are a LOT of independent commitments the side may make - ground or space battles AND opening boiled eggs at the big or the little end AND less filling or tastes great AND matter or antimatter-based warheads AND (and so on). In that case it might end up requiring one new material type for each choice, which could be a problem. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:41 ` mskala 2004-09-05 16:54 ` Eric McDonald @ 2004-09-05 17:01 ` Elijah Meeks 1 sibling, 0 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-05 17:01 UTC (permalink / raw) To: mskala, Eric McDonald; +Cc: Elijah Meeks, Xconq list --- mskala@ansuz.sooke.bc.ca wrote: > Can't we make some advances require particular > materials? I think we > already can, and if not, that would be easy to add. > Then we could easily > do both behaviours. For "you may only have one of > these advances", > there's a material of which you only get a little > bit, and you need all of > it to do either advance. Once you have done one, > you can't do the other. > For "it's very hard, but possible, to do both of > these advances", it's a > similar story, but you can eventually with a lot of > work gain more of the > special material. I attempted something like this with AWLS, in that hi-tech units produced more tech points specifically for researching the next tech (i.e. level-1 Carriers produced level-2 Carrier tech points). The problem is that, if the AI isn't researching Level-2 Carriers, then the research points just pile up unused. This wouldn't be too much of a problem, because they'd eventually be spent when that tech was researched, but on top of this comes the lack of a generic tech source, so now you can only research Level-2 Carriers with level-2 carrier tech. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:25 ` Eric McDonald 2004-09-05 16:41 ` mskala @ 2004-09-05 16:48 ` Elijah Meeks 2004-09-05 19:43 ` Eric McDonald 2004-09-05 16:50 ` mskala 2 siblings, 1 reply; 43+ messages in thread From: Elijah Meeks @ 2004-09-05 16:48 UTC (permalink / raw) To: Eric McDonald; +Cc: Xconq list > The ability to make researching advances easier is > also interesting, > because, for example, in a Civ-like game, after > researching "Formal > Logic" and "Empirical Science", a civilization might > be able to make a > whole slew of scientific and technological advances > much more rapidly > than it would otherwise. > > Taken to extremes, the proposed tables could shut > off advances by > boosting the RP requirement to some very large > number (relative > infinity?), or make gaining an advance trivial by > multiplying its RP > requirement by 0%. > > I'll think about it some more. I haven't dealt much > with the advances > aspect of Xconq before. If it's an easy feature to > add (and test), I > might go ahead and add it in the near future. This is a good and much more feature-rich solution, but there are two issues: 1) It's more complicated. Not having seen the code, I don't know how much, but a simple shut-off switch would, I think be straightforward. It would also allow the game designer to simulate much of what you're talking about, he'd just have to create a few more techs, so that you're getting the same tech, only cheaper, or you have to buy an extra 'Prelim' tech before to open up the full, which is the closest thing I can get to simulating something like this using GDL now (Except I have to manually set the focus of one group by using what I call limiters. You can see this in opal-rules.g, just search for 'limit') 2) The AI doesn't choose research very well. Really, this is for the AI, because a player will probably focus, anyway, while the AI will choose its research haphazardly and I wouldn't be surprised to see it short-circuiting by researching an almost-infinite-rp tech. Of course, if I'm wrong about these points, which is a decent possibility given my lack of familiarity with the research or AI code, then by all means I'd prefer a more featured implementation. _______________________________ 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] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:48 ` Elijah Meeks @ 2004-09-05 19:43 ` Eric McDonald 0 siblings, 0 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-05 19:43 UTC (permalink / raw) To: Elijah Meeks; +Cc: Xconq list Elijah Meeks wrote: > 1) It's more complicated. Not having seen the code, I > don't know how much, but a simple shut-off switch > would, I think be straightforward. You are possibly right in this regard. I'll think some more about it. >It would also > allow the game designer to simulate much of what > you're talking about, he'd just have to create a few > more techs, so that you're getting the same tech, only > cheaper, I see. So are you going to race Lincoln to 10000 advances to win an additional donut? :-) > 2) The AI doesn't choose research very well. Really, > this is for the AI, because a player will probably > focus, anyway, while the AI will choose its research > haphazardly and I wouldn't be surprised to see it > short-circuiting by researching an almost-infinite-rp > tech. Ah ha. Trying to make the AI look like it has a brain? That is also the mark of a seasoned Xconq developer. > Of course, if I'm wrong about these points, which is a > decent possibility given my lack of familiarity with > the research or AI code, then by all means I'd prefer > a more featured implementation. No. I think you made valid points. You are the one actually using advances. Like I said, I have barely touched the stuff. I'll think some more about it. But, right now, I am about to add support for prefix args to the SDL interface. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:25 ` Eric McDonald 2004-09-05 16:41 ` mskala 2004-09-05 16:48 ` Elijah Meeks @ 2004-09-05 16:50 ` mskala 2004-09-05 16:55 ` Eric McDonald 2 siblings, 1 reply; 43+ messages in thread From: mskala @ 2004-09-05 16:50 UTC (permalink / raw) To: Eric McDonald; +Cc: Elijah Meeks, Xconq list On Sun, 5 Sep 2004, Eric McDonald wrote: > The ability to make researching advances easier is also interesting, > because, for example, in a Civ-like game, after researching "Formal > Logic" and "Empirical Science", a civilization might be able to make a > whole slew of scientific and technological advances much more rapidly > than it would otherwise. I looked it up in the manual, and it turns out there's an advance-consumption-per-rp table which (assuming it's implemented) does more or less what I thought would be necessary. To force the side to choose ground or space battles, you have an advance for each which requires a point of "research commitment", and you only get one point of that, so you have to choose one or the other. To force choosing one or the other first, but eventually allow them both, make it require 100 points of research commitment, give the side 100 points, but then make it hard to produce additional points... so they can eventually make another 100 and take the other path, but it'll take a while. The "advances speed up other advances" thing could also be done easily with materials.... having "Formal Logic" increases your production of "journal papers", which are needed for other advances. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:50 ` mskala @ 2004-09-05 16:55 ` Eric McDonald 0 siblings, 0 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-05 16:55 UTC (permalink / raw) To: mskala; +Cc: Elijah Meeks, Xconq list mskala@ansuz.sooke.bc.ca wrote: > On Sun, 5 Sep 2004, Eric McDonald wrote: > I looked it up in the manual, and it turns out there's an > advance-consumption-per-rp table which (assuming it's implemented) does > more or less what I thought would be necessary. To force the side to > choose ground or space battles, you have an advance for each which > requires a point of "research commitment", and you only get one point of > that, so you have to choose one or the other. To force choosing one or > the other first, but eventually allow them both, make it require 100 > points of research commitment, give the side 100 points, but then make it > hard to produce additional points... so they can eventually make another > 100 and take the other path, but it'll take a while. This is an interesting thought. Among other things, it shows me that you are fit to be considered a "seasoned" Xconq game designer, because of demonstrated aptitude at twisting existing features to mimic non-existent features. :-) > The "advances speed up other advances" thing could also be done easily > with materials.... having "Formal Logic" increases your production of > "journal papers", which are needed for other advances. Depends on which journal, and who the author(s) and referee were. For some, I think formal logic serves as a detriment.... Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 6:02 ` Feature Request: Advance Prohibits Advance Elijah Meeks 2004-09-05 16:25 ` Eric McDonald @ 2004-09-05 16:55 ` Lincoln Peters 2004-09-05 17:01 ` Elijah Meeks 1 sibling, 1 reply; 43+ messages in thread From: Lincoln Peters @ 2004-09-05 16:55 UTC (permalink / raw) To: Elijah Meeks; +Cc: Xconq list On Sat, 2004-09-04 at 18:48, Elijah Meeks wrote: > As it stands, there's no way to simulate different > tech paths. I'd like to have a way to shut off > advances if certain advances are researched, so that > sides can choose different directions to take. For > example, if we have two spacefaring societies, we can > have two techs, one being Ground War Focus and the > other Stellar War Focus. The side that pics Ground > War Focus spends less on developing AT-ATs and > Battlemechs and more for its Cordships and A-Wing > Starfighters while the other side has to pay extra to > develop its hovertanks but manages to design > galaxy-class starships and battlestars at a faster > rate. You could probably get the same effect (or at least a very similar one) by making research dependent on multiple materials, which are in turn dependent on specific "gateway" advances. Suppose that you want to create a game based on the (admittedly very weird) movie "Wizards" by Ralph Bashki. Your big choice for research is whether to focus on technological marvels (tanks, stealth bombers, etc.) or magical marvels (magic weapons, scrying devices, etc.). You could handle this by using three materials: base-ideas, tech-ideas, and arcane-ideas. All advances require base-ideas, which therefore would be fairly common. Technological advances require a significant number of tech-ideas in addition to base-ideas, and the "Tech focus" advance would double (or more) the production of tech-ideas. Similarly, magical advances require a significant number of arcane-ideas in addition to base-ideas, and the "Arcane focus" advance would double (or more) the production of arcane-ideas. Basically, "Tech focus" and "Arcane focus" would use the advance-multiplies-production table to increase the production of tech-ideas and arcane-ideas, respectively. You could even make "Tech focus" reduce production of arcane-ideas, or make "Arcane Focus" reduce production of tech-ideas, by setting an advance-multiplies-production value less than 1. This would make it possible for a side to focus on one line of advances or another, or to generalize and gain both at a slower rate. It would also allow a side to focus on one line while picking up an occasional advance on the other line of research (thus allowing, for example, a wizard to quickly end a battle with another wizard by pulling out a handgun and shooting him). --- Lincoln Peters <sampln@sbcglobal.net> A soft answer turneth away wrath; but grievous words stir up anger. -- Proverbs 15:1 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 16:55 ` Lincoln Peters @ 2004-09-05 17:01 ` Elijah Meeks 2004-09-05 19:52 ` Jim Kingdon 2004-09-05 19:58 ` Lincoln Peters 0 siblings, 2 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-05 17:01 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list > This would make it possible for a side to focus on > one line of advances > or another, or to generalize and gain both at a > slower rate. It would > also allow a side to focus on one line while picking > up an occasional > advance on the other line of research (thus > allowing, for example, a > wizard to quickly end a battle with another wizard > by pulling out a > handgun and shooting him). Points for referencing the weirdest cartoon of the last half-century. Do you plan on creating rocknrule.g after that? The problem here is when the AI decides to research Arcane Focus and then wastes it's points researching overly expensive Technology rather than the more efficient Magic. I overcame this problem in Opal (Where the AI would research every magic type rather than, as I'd hoped, just one or two) by manually shutting off all but two 'Schools of Magic'. Otherwise, it shows remarkably poor choice in its research selections. That's why I'd like firm a shut-off like advance-prohibits-advance. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 17:01 ` Elijah Meeks @ 2004-09-05 19:52 ` Jim Kingdon 2004-09-05 20:16 ` Eric McDonald 2004-09-05 19:58 ` Lincoln Peters 1 sibling, 1 reply; 43+ messages in thread From: Jim Kingdon @ 2004-09-05 19:52 UTC (permalink / raw) To: xconq7 > The problem here is when the AI decides to research > Arcane Focus and then wastes it's points researching > overly expensive Technology rather than the more > efficient Magic. . . . That's why I'd like firm a > shut-off like advance-prohibits-advance. Maybe a shut-off which affects the AI, not the referee code. Similar to what we've been talking about in general - ways to manually hint the AI in cases where it isn't (yet?) smart enough to figure out the situation for itself. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 19:52 ` Jim Kingdon @ 2004-09-05 20:16 ` Eric McDonald 0 siblings, 0 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-05 20:16 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 Jim Kingdon wrote: > Maybe a shut-off which affects the AI, not the referee code. Good idea. I'll see what Lincoln does first. If it looks like the AI could still use a nudge, I'll try to find time to implement 'ai-advance-prohibits-advance'. It can probably be added to the advance autopicker code fairly easily. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 17:01 ` Elijah Meeks 2004-09-05 19:52 ` Jim Kingdon @ 2004-09-05 19:58 ` Lincoln Peters 2004-09-05 20:15 ` Elijah Meeks 1 sibling, 1 reply; 43+ messages in thread From: Lincoln Peters @ 2004-09-05 19:58 UTC (permalink / raw) To: Elijah Meeks; +Cc: Xconq list On Sun, 2004-09-05 at 10:01, Elijah Meeks wrote: > Points for referencing the weirdest cartoon of the > last half-century. Do you plan on creating > rocknrule.g after that? That's one I don't think I've seen. > > The problem here is when the AI decides to research > Arcane Focus and then wastes it's points researching > overly expensive Technology rather than the more > efficient Magic. I overcame this problem in Opal > (Where the AI would research every magic type rather > than, as I'd hoped, just one or two) by manually > shutting off all but two 'Schools of Magic'. > Otherwise, it shows remarkably poor choice in its > research selections. That's why I'd like firm a > shut-off like advance-prohibits-advance. I think that what we need here is a better AI. It should not be too difficult to at least improve the code that picks advances. I'll look into it. --- Lincoln Peters <sampln@sbcglobal.net> TAPPING? You POLITICIANS! Don't you realize that the END of the "Wash Cycle" is a TREASURED MOMENT for most people?! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Feature Request: Advance Prohibits Advance 2004-09-05 19:58 ` Lincoln Peters @ 2004-09-05 20:15 ` Elijah Meeks 0 siblings, 0 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-05 20:15 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list > > That's one I don't think I've seen. > Rock and Rule, from the imbd ( http://us.imdb.com/title/tt0086203/ ): A malevolent rock star kidnaps a female singer to force her to participate in the summoning of a demon and her band must help her stop him. Out of print, thankfully... > I think that what we need here is a better AI. Yes. But until then, if we implement one little table, I can engineer a bit of improvement with the current AI. It seems like the cost:benefit ratio for such a table would be pretty darned high. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-05 1:48 ` Eric McDonald 2004-09-05 6:02 ` Feature Request: Advance Prohibits Advance Elijah Meeks @ 2004-09-05 15:52 ` Lincoln Peters 2004-09-05 16:36 ` Eric McDonald 2004-09-05 20:14 ` Jim Kingdon 2 siblings, 1 reply; 43+ messages in thread From: Lincoln Peters @ 2004-09-05 15:52 UTC (permalink / raw) To: Eric McDonald; +Cc: Xconq list On Sat, 2004-09-04 at 10:45, Eric McDonald wrote: > Well, I think that part of the problem might be simply that when you > call one game the "standard" game, it implies that the others are either > substandard or offshoots of it. Perhaps, then, we should change the name of the Standard game to the Default game, or something else that doesn't imply that other Xconq games are sub-standard. At least, if _I_ saw that the first choice on the list was called the "Default game," I wouldn't be as inclined to doubt the quality of the other games. Or maybe it needs a more descriptive name. > > When I first tried out Xconq back in 1999 or 2000, this was one of the > things that kept me away from the other games. And I barely did more > than open a few of the others before I abandoned Xconq then because the > UI was not very good. Even more reason to build a better UI, although I think we all agree that bug-fixing usually takes precedence over UI building. > > >I can envision a "Welcome" screen that looks like > > the following (which, as usual, I designed with Glade without having to > > write any code): > > Of course, code would still have to be added for event handlers for the > various UI elements, so that a click on, say, a radio button will > translate into the proper Xconq internals being updated. Of course. Right now, I'm just trying to figure out what the interface should look like. > > Furthermore, as soon as you click "Apply", you could theoretically jump > > to the existing SDL interface and thus leave behind anything that even > > remotely resembles an Office app. > > I would suggest the "Apply" button be relabelled to "Accept" or "Start > Game". I'm pretty sure that there's a way to do that, but I'd have to write actual code (Glade won't let me change the labels of buttons when the buttons are part of a Druid widget). > > What you propose is interesting. This would certainly save time in the > development of the startup screens, a task I have only half been looking > forward to. The tradeoff is that the Windows installer would get quite a > bit larger, because we cannot reasonably assume that a Windows user > would have the GDK, GTK+, Pango, etc. libraries on his/her system. I'll have to study the Mono framework, but it might be possible to implement one UI that runs on both Linux and Windows with minimal platform-specific code or dependencies. It also looks like Novell (the company that now owns Ximian) is working on a Mono implementation for MacOS X, which might simplify things further (but not until there is a Mono-based interface that is actually better than the existing MacOS interface). If I remember correctly from that talk I attended back in 2002, the biggest stumbling block that the Mono project encountered at the time was the difference in widget styles (coordinate-based vs. hierarchical, although I don't think he used those exact words). However, since they've finally released Mono 1.0, I would assume that they found a solution to that problem. Based on their FAQ, it looks like an application written for Mono/.NET should work fine on UNIX/Linux or Windows with no difficulty as long as it is a "100% .NET application" (essentially it is fully compliant with the .NET standard and contains no platform-specific code). Although I have no idea how much work it would take to convert Xconq into a "100% .NET application," and I don't think any of us want to find out (at least not until post-7.5). And, of course, there's the possibility of drastically simplifying network games by implementing ZeroConf/Rendezvous (to make Xconq LAN parties easier to set up) and/or an Xconq game server (maybe just a modified IRC server to put Xconq players in contact with each other). Although that would almost certainly cause the appearance of Page 4 to change somewhat, and it's not something I'd consider a high priority. (Yes, I remember that the idea of using Mono was originally floated in the midst of last year's great flame war, but I think that it's an idea worth taking seriously, even if it was originally accompanied by a lot of hot air.) --- Lincoln Peters <sampln@sbcglobal.net> "Kill the Wabbit, Kill the Wabbit, Kill the Wabbit!" -- Looney Tunes, "What's Opera Doc?" (1957, Chuck Jones) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-05 15:52 ` Changing the Standard Game Lincoln Peters @ 2004-09-05 16:36 ` Eric McDonald 2004-09-05 20:09 ` Jim Kingdon 0 siblings, 1 reply; 43+ messages in thread From: Eric McDonald @ 2004-09-05 16:36 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list Lincoln Peters wrote: > On Sat, 2004-09-04 at 10:45, Eric McDonald wrote: > Perhaps, then, we should change the name of the Standard game to the > Default game, or something else that doesn't imply that other Xconq > games are sub-standard. I think that "Default Game" is a reasonable name. Especially since that is the default game that gets loaded by interface that don't bring up a game selector, such as Curses and SDL presently. >>When I first tried out Xconq back in 1999 or 2000, this was one of the >>things that kept me away from the other games. And I barely did more >>than open a few of the others before I abandoned Xconq then because the >>UI was not very good. > > Even more reason to build a better UI, although I think we all agree > that bug-fixing usually takes precedence over UI building. It depends largely on the severity of the bugs. To be honest, I have reached a frustration point regarding the lack of a good UI for Linux and Windows. We were told that the 7.5 release was "imminent" a year and half ago. Even though I have worked on this project for over a year now, I still have no idea when the 7.5 release is going to be. Up until recently, I have restrained myself from taking on any big projects (such as UI building) because I didn't want to have 7.5 announced while I was in the middle of one, and I certainly did not want to hold up a release on account of my work. At this point, I don't really care. If someone announces that the Macconq 7.5 release is looming, I'll just fork the sources and continue my work on the SDL interface; I've already got more than one foot pointed in that direction as it is (for other reasons). I am aware that there are some network bugs out there that need to be fixed. I consider the network setup bug (not more than 2 sides can join properly) to be something that Hans should look at it, since he is the last person to have mucked with that sort of stuff. I will eventually take care of it, if he doesn't, but that is not my focus right now. > I'm pretty sure that there's a way to do that, but I'd have to write > actual code (Glade won't let me change the labels of buttons when the > buttons are part of a Druid widget). I see. I think the prototyping work you are doing is useful, but I imagine that it would not take too much work just to generate all of the UI elements from code (once we settle on what it should look like from the prototypes). This would give us the possibility of a more dynamic layout. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-05 16:36 ` Eric McDonald @ 2004-09-05 20:09 ` Jim Kingdon 0 siblings, 0 replies; 43+ messages in thread From: Jim Kingdon @ 2004-09-05 20:09 UTC (permalink / raw) To: mcdonald; +Cc: xconq7 > I still have no idea when the 7.5 release is going to be. Up until > recently, I have restrained myself from taking on any big projects > (such as UI building) because I didn't want to have 7.5 announced > while I was in the middle of one, and I certainly did not want to hold > up a release on account of my work. Experience in other projects seems to be that the whole business of branching/freezing/etc doesn't work particularly well, and you are better off making sure that the mainline is always in good shape. For example, see http://lwn.net/Articles/95312/ Now, we could use better ways of keeping the mainline sane than we have now. My pet solution is automated tests, but since I'm not writing much xconq code (or tests) these days, that doesn't count for as much as what the more active developers do. Another way is to publish and encourage public testing of big, or risky, changes before checking them in. We're low on testers in general, which is the big risk factor with that one. As for wanting to keep working on SDL, if you are talking about code which is specific to SDL, I can't think of any reason to be at all reluctant to touch it on account of a supposedly-imminent 7.5 release. If it is non-SDL code, well, maybe then there's more of an issue. But the idea of stabilizing the SDL code by not hacking on it doesn't really make sense, given how much is missing in the current SDL code. > I am aware that there are some network bugs out there that need to > be fixed. Yeah, and I wonder if there is a better way to find these than "find another human who wants to play a network game and get a few turns in and get a loss of sync". AI vs AI network games are the traditional method, and perhaps the current problem is just that no one has tried one lately. Writing some kind of monkey tester might be another way (which generates random events, hopefully hitting corner cases which the AI happens not to hit). Finding a way to run these tests (whatever they are) more quickly/automatically would be a big step up. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-05 1:48 ` Eric McDonald 2004-09-05 6:02 ` Feature Request: Advance Prohibits Advance Elijah Meeks 2004-09-05 15:52 ` Changing the Standard Game Lincoln Peters @ 2004-09-05 20:14 ` Jim Kingdon 2004-09-05 20:40 ` Elijah Meeks 2004-09-05 22:09 ` Eric McDonald 2 siblings, 2 replies; 43+ messages in thread From: Jim Kingdon @ 2004-09-05 20:14 UTC (permalink / raw) To: mcdonald; +Cc: xconq7 > I started playing the Standard game on the Tcl/Tk interface, because I > assumed (possibly correctly) that the Standard game would give me the > best playing experience. My experience has been that the Standard game is the most playable of the ones I've tried. I wouldn't object to calling it Default game. But it does seem worthwhile to steer new users towards it, unless someone can tell me which other game we'd steer them towards. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-05 20:14 ` Jim Kingdon @ 2004-09-05 20:40 ` Elijah Meeks 2004-09-05 22:09 ` Eric McDonald 1 sibling, 0 replies; 43+ messages in thread From: Elijah Meeks @ 2004-09-05 20:40 UTC (permalink / raw) To: Jim Kingdon, mcdonald; +Cc: xconq7 > But it does seem worthwhile to steer new users > towards it, unless > someone can tell me which other game we'd steer them > towards. > Yeah, but with THOSE graphics? It's just so... ugly. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Changing the Standard Game 2004-09-05 20:14 ` Jim Kingdon 2004-09-05 20:40 ` Elijah Meeks @ 2004-09-05 22:09 ` Eric McDonald 1 sibling, 0 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-05 22:09 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 Jim Kingdon wrote: > My experience has been that the Standard game is the most playable of > the ones I've tried. I would agree. But, I haven't sat down to play a full game of Opal, AWLS, or Bolodd lately, so I don't know if this is still true or not. > I wouldn't object to calling it Default game. Good. I think I will make the change then, unless Stan magically appears and says otherwise. > But it does seem worthwhile to steer new users towards it, unless > someone can tell me which other game we'd steer them towards. Agreed. I think that only the title needs to be changed. The module name (which is treated specially: placed second in the games list) can remain the same. Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Standard Game Graphics 2004-09-03 5:10 ` Elijah Meeks 2004-09-03 5:11 ` Jim Kingdon 2004-09-03 6:10 ` Jim Kingdon @ 2004-09-03 23:11 ` Eric McDonald 2 siblings, 0 replies; 43+ messages in thread From: Eric McDonald @ 2004-09-03 23:11 UTC (permalink / raw) To: Elijah Meeks; +Cc: Jim Kingdon, xconq7 On Thu, 2 Sep 2004, Elijah Meeks wrote: > agree that it should be a group decision. The one > problem, which I believe Jim pointed out and proved > true, is that it doesn't look so good at the 16 > unit/hex resolution. Jim brought up a valid point, and I suggested a custom image family (i.e., one that specifies alternate graphics at lower resolutions) as a way to deal with it. > 1. Make specific imf 4 4 definitions that reference > the old silhouettes, because they're more recognizable > at that resolution. This might work. > 2. Set unit limits per hex at four, which is the max > amount of Trident units in a hex that are still > recognizable and look decent. This could severely alter gameplay. I would lean more towards option 1 than option 2. > Eric's Occupant Dialog Box Fix is out... Right, > Eric?* We'll see. :-) I am still getting accustomed to working on the SDL interface, and building up various tools to help me hack on it more easily. I haven't yet shifted into high productivity mode with it. Also, I think I am going to try the unit magnification approach first, before resorting to a dialog box. > still think we need a forum. And a better webpage Can't argue with that. > And salaries for game designers. And If you can get me a salary to work on Xconq or some derivative thereof, that would be great. :-) Eric ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2004-09-05 20:40 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 2004-08-28 3:47 ` Multiple Image Use Elijah Meeks 2004-08-28 4:02 ` Eric McDonald 2004-08-28 4:33 ` Elijah Meeks 2004-09-01 7:30 ` Standard Game Graphics Elijah Meeks 2004-09-01 16:18 ` Jim Kingdon 2004-09-01 18:30 ` Eric McDonald 2004-09-02 1:43 ` Elijah Meeks 2004-09-02 4:24 ` Eric McDonald 2004-09-03 2:30 ` Jim Kingdon 2004-09-03 3:01 ` Elijah Meeks 2004-09-03 3:17 ` Eric McDonald 2004-09-03 5:10 ` Elijah Meeks 2004-09-03 5:11 ` Jim Kingdon 2004-09-03 6:10 ` Jim Kingdon 2004-09-03 17:18 ` Changing the Standard Game Elijah Meeks 2004-09-04 2:06 ` Eric McDonald 2004-09-04 17:46 ` Lincoln Peters 2004-09-05 1:48 ` Eric McDonald 2004-09-05 6:02 ` Feature Request: Advance Prohibits Advance Elijah Meeks 2004-09-05 16:25 ` Eric McDonald 2004-09-05 16:41 ` mskala 2004-09-05 16:54 ` Eric McDonald 2004-09-05 17:11 ` mskala 2004-09-05 17:01 ` Elijah Meeks 2004-09-05 16:48 ` Elijah Meeks 2004-09-05 19:43 ` Eric McDonald 2004-09-05 16:50 ` mskala 2004-09-05 16:55 ` Eric McDonald 2004-09-05 16:55 ` Lincoln Peters 2004-09-05 17:01 ` Elijah Meeks 2004-09-05 19:52 ` Jim Kingdon 2004-09-05 20:16 ` Eric McDonald 2004-09-05 19:58 ` Lincoln Peters 2004-09-05 20:15 ` Elijah Meeks 2004-09-05 15:52 ` Changing the Standard Game Lincoln Peters 2004-09-05 16:36 ` Eric McDonald 2004-09-05 20:09 ` Jim Kingdon 2004-09-05 20:14 ` Jim Kingdon 2004-09-05 20:40 ` Elijah Meeks 2004-09-05 22:09 ` Eric McDonald 2004-09-03 23:11 ` Standard Game Graphics Eric McDonald
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).