* Re: Marketing Xconq?
@ 2003-11-17 15:42 Bill Macon
2003-11-17 18:55 ` Marketing Xconq? + battle isle suggestion Andreas Bringedal
2003-11-17 21:56 ` Marketing Xconq? Eric McDonald
0 siblings, 2 replies; 49+ messages in thread
From: Bill Macon @ 2003-11-17 15:42 UTC (permalink / raw)
To: vanevery, xconq7
>do you guys make any effort to market Xconq?
I mentioned a couple weeks ago that I posted a message on the forum at
Wargamer.com. Jim Cobb, one of the game reviewers, mentioned that he would
take a look at it. If you guys want to attract wargamers who are interested
in designing their own games, Wargamer is a good place to start. I think
there's potential.
It's fair to mention that many gamers are using a Windows platform and
not Mac or Linux, so a Windows version is important. Also, most gamers are
not programmers and some are practically computer illiterate, so a simple
complete download like Eric has developed will be most helpful for expanding
the Xconq user base. Even I have had trouble figuring out CVS, so I don't
bother any more. Simple patch downloads to supplement the full install
should also be considered.
I've tried the recent download and it works somewhat, but there are still
bugs and graphics problems. At least on WinMe that I'm still using, and I'm
too busy with other things right now to spend time troubleshooting Xconq.
And so are most of your potential customers, so the sooner a clean v7.5 can
get completed and released the better. Once that happens, marketing efforts
should be more effective.
There were two items I mentioned a long while back that would improve
Xconq's appeal to traditional wargamers. One is some way of providing
conditional events within the game, like If-Then statements. There's no way
to simulate politics and diplomacy by having some sides or forces inactive
until something happens (declaration of war, surprise attack, specific
objective taken, etc.) There are a lot of possibilities with this. The
other is some way of providing multiple unit attacks and standard combat
results tables based on odds. Like three units against one getting 3-1
odds, or whatever when other factors are computed, and a "die roll" resolves
the combat all at one time. The current combat models do not lend
themselves to doing this well. So maybe with the newer Xconq programmers on
the list now, someone can think about addressing these things.
Bill
_________________________________________________________________
From Beethoven to the Rolling Stones, your favorite music is always playing
on MSN Radio Plus. No ads, no talk. Trial month FREE!
http://join.msn.com/?page=offers/premiumradio
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Marketing Xconq? + battle isle suggestion 2003-11-17 15:42 Marketing Xconq? Bill Macon @ 2003-11-17 18:55 ` Andreas Bringedal 2003-11-17 22:04 ` better Windows UI Brandon J. Van Every 2003-11-17 21:56 ` Marketing Xconq? Eric McDonald 1 sibling, 1 reply; 49+ messages in thread From: Andreas Bringedal @ 2003-11-17 18:55 UTC (permalink / raw) To: xconq7 > There were two items I mentioned a long while back that would improve > Xconq's appeal to traditional wargamers. Another thing is to update the game interface. It's too cumbersome and not player friendly enough. I believe Civ's great success was due to it's very appealing and intuitive interface. Somewhat warm and bright colours are also good as it isn't as depressing as a brown/grey/dark map. Civilization and Heroes is a good example of the color type I mean. If Brandon or someone makes some windows interface that's better I'll be a very happy camper. Another thing that might appeal to some wargamers is to make a Battle Isle clone. By that I don't mean Battle Isle's combat rules but the game type. In Xconq you start with a few units and grow larger and get a zillion units which is very combersome and boring. When I play Xconq I'm constantly reminded of a locus swarm as the screen is nearly filled with units. In Battle Isle you start with quite a few forces deployed and you can't build more. This means that the game has a very strategic beginning with units placed in intersting and premade setups and that the game goes faster and faster as units are killed. This makes for fast and interesting games. If you can ensure good scenarios you are nearly guarantied a fun and exciting game every time you play. Battle Isle games does however star with the whole map revealed. If it isn't if greatly favours the player that has played the map before, naturally. It also has a high score. The score is based on how fast and how great losses you took. The score is interesting when playing solo as trying to best your own score (or others) gives replayability. Ie you try different tactics and see if you can get a better result. This way it doesn't matter as much that the AI sucks as you want the best score possible. It is also very possible to make scenarioes that are heavily stacked in favour of one side which naturally would be the AI side. This is another advantage. I've missed playing Battle Isle for many years. The two first versions were the best. The third and fourth were not good as far as I recall. Historyline(same game but using WW1 units) was also good but it had the great flaw that you could had a steady influx of production points so you could get a better score by prolonging the game. Battle Isle had only a finite amount of production points(you could only build a small amount of units) which allowed you to try different tactics(building different units). Andreas ^ permalink raw reply [flat|nested] 49+ messages in thread
* better Windows UI 2003-11-17 18:55 ` Marketing Xconq? + battle isle suggestion Andreas Bringedal @ 2003-11-17 22:04 ` Brandon J. Van Every 2003-11-18 3:12 ` Erik Jessen 0 siblings, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-17 22:04 UTC (permalink / raw) To: xconq Andreas Bringedal wrote: > > Another thing is to update the game interface. It's too > cumbersome and not > player friendly enough. I believe Civ's great success was > due to it's very > appealing and intuitive interface. Somewhat warm and bright > colours are > also good as it isn't as depressing as a brown/grey/dark map. > Civilization > and Heroes is a good example of the color type I mean. > > If Brandon or someone makes some windows interface that's > better I'll be a very happy camper. I'm going to work on a better Windows UI from an ease-of-use, speed-of-mouseclicks, not-cumbersome standpoint. Eye candy and production values will need to come from someone else. I have artistic ability but no mastery of digital art tools, so this is a tedious / cumbersome area for me. I'm willing to incorporate someone else's better art assets into the UI, however. You got any artists? Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: better Windows UI 2003-11-17 22:04 ` better Windows UI Brandon J. Van Every @ 2003-11-18 3:12 ` Erik Jessen 0 siblings, 0 replies; 49+ messages in thread From: Erik Jessen @ 2003-11-18 3:12 UTC (permalink / raw) To: 'Brandon J. Van Every', 'xconq' I did a bunch of tinkering with terrain colors/combos, as a part of seeing what looked nice on the screen. No promises, of course... Now I just gotta find it... Erik -----Original Message----- From: xconq7-owner@sources.redhat.com [mailto:xconq7-owner@sources.redhat.com] On Behalf Of Brandon J. Van Every Sent: Monday, November 17, 2003 2:07 PM To: xconq Subject: better Windows UI Andreas Bringedal wrote: > > Another thing is to update the game interface. It's too > cumbersome and not > player friendly enough. I believe Civ's great success was > due to it's very > appealing and intuitive interface. Somewhat warm and bright > colours are > also good as it isn't as depressing as a brown/grey/dark map. > Civilization > and Heroes is a good example of the color type I mean. > > If Brandon or someone makes some windows interface that's > better I'll be a very happy camper. I'm going to work on a better Windows UI from an ease-of-use, speed-of-mouseclicks, not-cumbersome standpoint. Eye candy and production values will need to come from someone else. I have artistic ability but no mastery of digital art tools, so this is a tedious / cumbersome area for me. I'm willing to incorporate someone else's better art assets into the UI, however. You got any artists? Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Marketing Xconq? 2003-11-17 15:42 Marketing Xconq? Bill Macon 2003-11-17 18:55 ` Marketing Xconq? + battle isle suggestion Andreas Bringedal @ 2003-11-17 21:56 ` Eric McDonald 2003-11-17 22:38 ` Brandon J. Van Every 2003-11-18 1:13 ` Marketing Xconq? Dr Eric Edward Moore 1 sibling, 2 replies; 49+ messages in thread From: Eric McDonald @ 2003-11-17 21:56 UTC (permalink / raw) To: Bill Macon; +Cc: xconq7 Hi Bill, On Mon, 17 Nov 2003, Bill Macon wrote: > take a look at it. If you guys want to attract wargamers who are interested > in designing their own games, Wargamer is a good place to start. I think > there's potential. Yeah, I went over there and found your message(s). Thanks for giving Xconq a mention. > It's fair to mention that many gamers are using a Windows platform and > not Mac or Linux, so a Windows version is important. Right. That is why I have made some efforts regarding that platform. > the Xconq user base. Even I have had trouble figuring out CVS, so I don't > bother any more. There is a new Windows build/install document called INSTALL-win.txt. You might find the description of how to use WinCVS useful. (If you don't, please let me know what can be improved.) >Simple patch downloads to supplement the full install > should also be considered. Hmmm.... Maybe. I'll have to look at what the largest files are and how frequently they end up being changed. I'll think about it. > I've tried the recent download and it works somewhat, but there are still > bugs and graphics problems. Bugs in the installer or Xconq? > And so are most of your potential customers, I'm not sure that Xconq really has "customers". >so the sooner a clean v7.5 can > get completed and released the better. Once that happens, marketing efforts > should be more effective. Once Xconq 7.5 is ready, and if it looks stable and playable, I will probably send out some announcements to relevant newsgroups. (Unless of course Hans or Stan want to do it, since their contributions to the project have been so vast.) > Xconq's appeal to traditional wargamers. One is some way of providing > conditional events within the game, like If-Then statements. There's no way > to simulate politics and diplomacy by having some sides or forces inactive > until something happens (declaration of war, surprise attack, specific > objective taken, etc.) Similarly, I think Xconq could benefit from a reinforcements model, where forces simply appear at certain turns. However, like other ideas, I think most of these should wait until after 7.5 is released. There are still a number of bugs that must be addressed, in addition to documentation and miscellaneous improvements (Windows Xconq needs to be able to successfully be launched from a working directory that is other than its installation directory; I had hoped to address this over the past weekend, but other things came up. Also prefs.xcq needs to be renamed, now that .xcq is associated with Xconq savefiles. Etc, etc....) Regards, Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: Marketing Xconq? 2003-11-17 21:56 ` Marketing Xconq? Eric McDonald @ 2003-11-17 22:38 ` Brandon J. Van Every 2003-11-18 3:15 ` Erik Jessen 2003-11-18 1:13 ` Marketing Xconq? Dr Eric Edward Moore 1 sibling, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-17 22:38 UTC (permalink / raw) To: xconq Eric McDonald wrote: > > > And so are most of your potential customers, > > I'm not sure that Xconq really has "customers". A "customer" is anyone who makes a decision to try Xconq as opposed to some other life activity. The transactions potentially attainable from the customer are: 0) they give a negative mention of Xconq to others 1) they give a positive mention of Xconq to others 2) they become regular Xconq players, and hence possibly tester guinea pigs 3) they become Xconq developers > Once Xconq 7.5 is ready, and if it looks stable and playable, I > will probably send out some announcements to relevant newsgroups. > (Unless of course Hans or Stan want to do it, since their > contributions to the project have been so vast.) What about marketing to potential developers, before any of this? Seems to me you guys could use a few more hands around here. What about Xconq might be appealing to a developer? What would make it more appealing as a development platform? Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: Marketing Xconq? 2003-11-17 22:38 ` Brandon J. Van Every @ 2003-11-18 3:15 ` Erik Jessen 2003-11-18 3:39 ` New Interpreter (was RE: Marketing Xconq?) Eric McDonald 2003-11-18 5:17 ` Python in Xconq Brandon J. Van Every 0 siblings, 2 replies; 49+ messages in thread From: Erik Jessen @ 2003-11-18 3:15 UTC (permalink / raw) To: 'Brandon J. Van Every', 'xconq' Brandon, I think having an interpreted language (v. the current Lisp-format datafile) would put Xconq way ahead of the competition (like ADC2 et al). Of course, this would mean adding the interpreter, and then translating at least some of the existing games as test cases, plus defining how the interpreter would interact, but one could see how powerful this would be. "if", "for", "while" statements are incredibly powerful... ISTR that Perl has a module/docs on how to add a Perl interpreter onto almost any C program. Perl is OO (though in a weird sort of way, but that's not such a bad thing). Also, Perl has TCL support, so one could, at least in concept, create a pop-up in Perl to either notify the user, or to get input. But, I'm no guru on these sort of things - there are a number of languages (Python, Einstein, etc.) I've heard of, but know nothing about. Erik -----Original Message----- From: xconq7-owner@sources.redhat.com [mailto:xconq7-owner@sources.redhat.com] On Behalf Of Brandon J. Van Every Sent: Monday, November 17, 2003 2:14 PM To: xconq Subject: RE: Marketing Xconq? Eric McDonald wrote: > > > And so are most of your potential customers, > > I'm not sure that Xconq really has "customers". A "customer" is anyone who makes a decision to try Xconq as opposed to some other life activity. The transactions potentially attainable from the customer are: 0) they give a negative mention of Xconq to others 1) they give a positive mention of Xconq to others 2) they become regular Xconq players, and hence possibly tester guinea pigs 3) they become Xconq developers > Once Xconq 7.5 is ready, and if it looks stable and playable, I > will probably send out some announcements to relevant newsgroups. > (Unless of course Hans or Stan want to do it, since their > contributions to the project have been so vast.) What about marketing to potential developers, before any of this? Seems to me you guys could use a few more hands around here. What about Xconq might be appealing to a developer? What would make it more appealing as a development platform? Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 49+ messages in thread
* New Interpreter (was RE: Marketing Xconq?) 2003-11-18 3:15 ` Erik Jessen @ 2003-11-18 3:39 ` Eric McDonald 2003-11-18 4:01 ` Erik Jessen 2003-11-18 5:17 ` Python in Xconq Brandon J. Van Every 1 sibling, 1 reply; 49+ messages in thread From: Eric McDonald @ 2003-11-18 3:39 UTC (permalink / raw) To: Erik Jessen; +Cc: 'xconq' Hi Erik, On Mon, 17 Nov 2003, Erik Jessen wrote: > I think having an interpreted language (v. the current Lisp-format > datafile) would put Xconq way ahead of the competition (like ADC2 et > al). In past discussion, with Bruno I think, I jokingly referred to this as GDL++. But seriously, I run into things that I would like to do in Xconq that GDL cannot presently handle. Foremost among my desires are definitions based on forumlae rather than just static tables. It would also be nice to script events into certain games. However, if one writes a new interpreter, it would still need to work within the limitations of the backend data structures. Writing a new, more powerful interpreter is an ambitious project, but it would certainly be fun to do sometime. (As would expanding the standing orders syntax.) Regards, Eric P.S. How are the Xconq example "games" coming? If you have them ready, we can toss them into CVS, perhaps under lib/examples. ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: New Interpreter (was RE: Marketing Xconq?) 2003-11-18 3:39 ` New Interpreter (was RE: Marketing Xconq?) Eric McDonald @ 2003-11-18 4:01 ` Erik Jessen 2003-11-18 4:05 ` Eric McDonald 0 siblings, 1 reply; 49+ messages in thread From: Erik Jessen @ 2003-11-18 4:01 UTC (permalink / raw) To: 'Eric McDonald'; +Cc: 'xconq' My thought was this: - add an interpreter, using a standard language (like Perl) that can simply access existing data-structures. The hard part (at least to me) is: how do you decide when to execute the new programs? It's easy to load data-structures at initialization time & then have canned code execute it (what we do today). It's harder to say "execute this subroutine any time combat occurs". Alas, I've not been able to locate my examples (I hope they weren't on my system that had the HDD crash), but I'm hopeful of backups. Erik -----Original Message----- From: Eric McDonald [mailto:mcdonald@phy.cmich.edu] Sent: Monday, November 17, 2003 7:34 PM To: Erik Jessen Cc: 'xconq' Subject: New Interpreter (was RE: Marketing Xconq?) Hi Erik, On Mon, 17 Nov 2003, Erik Jessen wrote: > I think having an interpreted language (v. the current Lisp-format > datafile) would put Xconq way ahead of the competition (like ADC2 et > al). In past discussion, with Bruno I think, I jokingly referred to this as GDL++. But seriously, I run into things that I would like to do in Xconq that GDL cannot presently handle. Foremost among my desires are definitions based on forumlae rather than just static tables. It would also be nice to script events into certain games. However, if one writes a new interpreter, it would still need to work within the limitations of the backend data structures. Writing a new, more powerful interpreter is an ambitious project, but it would certainly be fun to do sometime. (As would expanding the standing orders syntax.) Regards, Eric P.S. How are the Xconq example "games" coming? If you have them ready, we can toss them into CVS, perhaps under lib/examples. ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: New Interpreter (was RE: Marketing Xconq?) 2003-11-18 4:01 ` Erik Jessen @ 2003-11-18 4:05 ` Eric McDonald 2003-11-18 10:37 ` setgid (was: RE: New Interpreter (was RE: Marketing Xconq?)) Lincoln Peters 0 siblings, 1 reply; 49+ messages in thread From: Eric McDonald @ 2003-11-18 4:05 UTC (permalink / raw) To: Erik Jessen; +Cc: 'xconq' On Mon, 17 Nov 2003, Erik Jessen wrote: > My thought was this: > - add an interpreter, using a standard language (like Perl) that can > simply access existing data-structures. > > The hard part (at least to me) is: how do you decide when to execute the > new programs? It's easy to load data-structures at initialization time > & then have canned code execute it (what we do today). It's harder to > say "execute this subroutine any time combat occurs". Well, with the Tcl/Tk interface we access a Tcl interpreter from C code all the time. As long as whatever language you have in mind can expose its interpreter to C in some for or another, you can call back into the interpreter and ask it to do things on your behalf. And vice versa, if the interpreter can call C functions. Then it is simply a matter of putting hooks into the relevant code sections. But my experience with Tcl and Xconq is that this sort of arrangement is harder to debug. Also, with a full blown interpreter being used, one must consider the security aspect. Especially since Xconq has the setgid bit set on Unix/Linux systems.... > Alas, I've not been able to locate my examples (I hope they weren't on > my system that had the HDD crash), but I'm hopeful of backups. Good luck finding them (and anything else you lost). Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* setgid (was: RE: New Interpreter (was RE: Marketing Xconq?)) 2003-11-18 4:05 ` Eric McDonald @ 2003-11-18 10:37 ` Lincoln Peters 2003-11-18 15:52 ` Jim Kingdon 0 siblings, 1 reply; 49+ messages in thread From: Lincoln Peters @ 2003-11-18 10:37 UTC (permalink / raw) To: Eric McDonald; +Cc: 'xconq' On Mon, 2003-11-17 at 20:01, Eric McDonald wrote: > Also, with a full blown interpreter being used, one must consider > the security aspect. Especially since Xconq has the setgid bit set > on Unix/Linux systems.... What does Xconq do that requires it to be setgid? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: setgid (was: RE: New Interpreter (was RE: Marketing Xconq?)) 2003-11-18 10:37 ` setgid (was: RE: New Interpreter (was RE: Marketing Xconq?)) Lincoln Peters @ 2003-11-18 15:52 ` Jim Kingdon 0 siblings, 0 replies; 49+ messages in thread From: Jim Kingdon @ 2003-11-18 15:52 UTC (permalink / raw) To: xconq7 > What does Xconq do that requires it to be setgid? High score list. In fact, it runs just fine without being setgid, just without the high score feature. Are people using the high score feature? I looked at this a little, but I didn't figure out exactly what it did. How interesting is a high score in last-side-wins games? See for example record_into_scorefile in score.c. Anyway, if we want to get rid of having xconq be setgid without getting rid of the functionality, one way would be to write a small setgid high score program (which, I suppose, xconq authenticates itself to or something), so that the setgid-ness only affects a small chunk of code. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Python in Xconq 2003-11-18 3:15 ` Erik Jessen 2003-11-18 3:39 ` New Interpreter (was RE: Marketing Xconq?) Eric McDonald @ 2003-11-18 5:17 ` Brandon J. Van Every 2003-11-18 11:33 ` Erik Jessen 1 sibling, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-18 5:17 UTC (permalink / raw) To: xconq From: Erik Jessen [mailto:ejessen@adelphia.net] > > I think having an interpreted language (v. the current Lisp-format > datafile) would put Xconq way ahead of the competition (like ADC2 et > al). I agree. Adding Python support is my next agenda item after Windows UI. I do not believe in Perl. It's ok for scripting, but it is a wholly inappropriate language for building systems. Python can handle both simple scripting and complex systems building. I'm not one to eneumerate Python's many features, but for instance it has list processing and hash tables / dictionaries built right into the language. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: Python in Xconq 2003-11-18 5:17 ` Python in Xconq Brandon J. Van Every @ 2003-11-18 11:33 ` Erik Jessen 2003-11-18 13:37 ` OT Python stuff (was RE: Python in Xconq) Mark A. Flacy 0 siblings, 1 reply; 49+ messages in thread From: Erik Jessen @ 2003-11-18 11:33 UTC (permalink / raw) To: 'Brandon J. Van Every', 'xconq' Perl has all that as well - I know, because I use them on a regular basis. Also, there are a great many modules others have written, to enable things like network play (RPC/IPC/IRC/etc.). But again, I've not seen Python, so it may do all those things in a much nicer way. Erik -----Original Message----- From: xconq7-owner@sources.redhat.com [mailto:xconq7-owner@sources.redhat.com] On Behalf Of Brandon J. Van Every Sent: Monday, November 17, 2003 8:37 PM To: xconq Subject: Python in Xconq From: Erik Jessen [mailto:ejessen@adelphia.net] > > I think having an interpreted language (v. the current Lisp-format > datafile) would put Xconq way ahead of the competition (like ADC2 et > al). I agree. Adding Python support is my next agenda item after Windows UI. I do not believe in Perl. It's ok for scripting, but it is a wholly inappropriate language for building systems. Python can handle both simple scripting and complex systems building. I'm not one to eneumerate Python's many features, but for instance it has list processing and hash tables / dictionaries built right into the language. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* OT Python stuff (was RE: Python in Xconq) 2003-11-18 11:33 ` Erik Jessen @ 2003-11-18 13:37 ` Mark A. Flacy 2003-11-19 15:08 ` Erik Jessen 0 siblings, 1 reply; 49+ messages in thread From: Mark A. Flacy @ 2003-11-18 13:37 UTC (permalink / raw) To: 'xconq' >>>>> "Erik" == Erik Jessen <ejessen@adelphia.net> writes: Erik> Erik> Perl has all that as well - I know, because I use them on a regular Erik> basis. Also, there are a great many modules others have written, to Erik> enable things like network play (RPC/IPC/IRC/etc.). Erik> Erik> But again, I've not seen Python, so it may do all those things in a Erik> much nicer way. My running joke is that Python has a very simple syntax while Perl has a shitload of syntaxes. If you know C, C++, or Java, you won't find very many syntax surprises in Python. You can write a lot of code without using any of the Python "odd" constructions. Even so, you can write such gems as... dirList = [ [k , v] for (k, v) in tmap.iteritems()] ...which converts a hashmap of tuples into a list of lists or ... webClientDirs = [os.path.join("com", "mycompany", "argle", "cap", "web", "ua", "base", "session"), os.path.join("com", "mycompany", "argle", "cap", "web", "ua", "pca", "appl"), os.path.join("com", "mycompany", "argle", "foundation", "awt", "layout"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "base"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "events"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "model"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "type"), os.path.join("com", "mycompany", "argle", "mw", "gui"), os.path.join("com", "mycompany", "argle", "mw", "sdp", "jni"), os.path.join("com", "mycompany", "bargle", "base") ] fulldirs = map(lambda x: os.path.join(self.config.compileDest, x), webClientDirs) ...which created a list of subdirectories (in a cross-platform fashion) and then prepends a root directory to each element of the list producing another list for later processing. http://www.linuxjournal.com/article.php?sid=3882 is written by the guy that wrote fetchmail. Worth a read. -- Mark A. Flacy Any opinions expressed above are my own. Any facts expressed above would imply that I know what I'm writing about. Sometimes, I do! "Just because you're paranoid doesn't mean they aren't out to get you anyways." ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: OT Python stuff (was RE: Python in Xconq) 2003-11-18 13:37 ` OT Python stuff (was RE: Python in Xconq) Mark A. Flacy @ 2003-11-19 15:08 ` Erik Jessen 2003-11-19 16:44 ` Bruno Boettcher 0 siblings, 1 reply; 49+ messages in thread From: Erik Jessen @ 2003-11-19 15:08 UTC (permalink / raw) To: 'Mark A. Flacy', 'xconq' Oh, In Perl, I just write: @files = Find(); To get a list of all files in the current subtree. But that's just me - there may be quicker ways to write it in Perl, as I make no claims to be a Perl guru. :) Seriously, any OO language is preferred (IMHO), because it will be more maintainable (C++?). And a scripting language is seriously preferred, because it will permit so much more stuff. If we add a scripting language, then I would submit that we write a simple porting script to convert GDL to that language, and drop GDL. IMHO, GDL is just a way to fill in data-structures, and any language can do that. A nice GUI-builder (anything well-known & portable like TCL) would be very useful, because the scripting language could then create new popups as needed, and if we're aiming for flexibility, then people who do political games are going to have lots of popups saying "Country X has proposed trading 3 steel, 4 oil and 5 herds of cattle, in return for a peace treaty. What is your answer?". Might as well get all the flexibility there... And that sort of thing is something that no other game-builder program has, but shouldn't be that hard to add to Xconq. Erik -----Original Message----- From: xconq7-owner@sources.redhat.com [mailto:xconq7-owner@sources.redhat.com] On Behalf Of Mark A. Flacy Sent: Tuesday, November 18, 2003 5:30 AM To: 'xconq' Subject: OT Python stuff (was RE: Python in Xconq) >>>>> "Erik" == Erik Jessen <ejessen@adelphia.net> writes: Erik> Erik> Perl has all that as well - I know, because I use them on a regular Erik> basis. Also, there are a great many modules others have written, to Erik> enable things like network play (RPC/IPC/IRC/etc.). Erik> Erik> But again, I've not seen Python, so it may do all those things in a Erik> much nicer way. My running joke is that Python has a very simple syntax while Perl has a shitload of syntaxes. If you know C, C++, or Java, you won't find very many syntax surprises in Python. You can write a lot of code without using any of the Python "odd" constructions. Even so, you can write such gems as... dirList = [ [k , v] for (k, v) in tmap.iteritems()] ...which converts a hashmap of tuples into a list of lists or ... webClientDirs = [os.path.join("com", "mycompany", "argle", "cap", "web", "ua", "base", "session"), os.path.join("com", "mycompany", "argle", "cap", "web", "ua", "pca", "appl"), os.path.join("com", "mycompany", "argle", "foundation", "awt", "layout"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "base"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "events"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "model"), os.path.join("com", "mycompany", "argle", "base", "ccpe", "type"), os.path.join("com", "mycompany", "argle", "mw", "gui"), os.path.join("com", "mycompany", "argle", "mw", "sdp", "jni"), os.path.join("com", "mycompany", "bargle", "base") ] fulldirs = map(lambda x: os.path.join(self.config.compileDest, x), webClientDirs) ...which created a list of subdirectories (in a cross-platform fashion) and then prepends a root directory to each element of the list producing another list for later processing. http://www.linuxjournal.com/article.php?sid=3882 is written by the guy that wrote fetchmail. Worth a read. -- Mark A. Flacy Any opinions expressed above are my own. Any facts expressed above would imply that I know what I'm writing about. Sometimes, I do! "Just because you're paranoid doesn't mean they aren't out to get you anyways." ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: OT Python stuff (was RE: Python in Xconq) 2003-11-19 15:08 ` Erik Jessen @ 2003-11-19 16:44 ` Bruno Boettcher 2003-11-19 17:58 ` Eric McDonald ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Bruno Boettcher @ 2003-11-19 16:44 UTC (permalink / raw) To: xconq7 On Wed, Nov 19, 2003 at 07:14:26AM -0800, Erik Jessen wrote: > @files = Find(); yup :D :D > Seriously, any OO language is preferred (IMHO), because it will be more > maintainable (C++?). uhm uhm perl is gettin OO'ish ;) and its not the language that causes most problems but the programmers and their lack of discipline, that's why you get the impression that more restrictive languages are easier mantained, but its an impression.... i have a C++ project to take over and its utter horror.... a perfect example of commercially produced 'high efficiency' and 'professional' piece of software.... > And a scripting language is seriously preferred, because it will permit > so much more stuff. yah :D > If we add a scripting language, then I would submit that we write a > simple porting script to convert GDL to that language, and drop GDL. > IMHO, GDL is just a way to fill in data-structures, and any language can > do that. oh? that sounds like a nice idea? > A nice GUI-builder (anything well-known & portable like TCL) would be > very useful, because the scripting language could then create new popups > as needed, and if we're aiming for flexibility, then people who do > political games are going to have lots of popups saying "Country X has > proposed trading 3 steel, 4 oil and 5 herds of cattle, in return for a > peace treaty. > What is your answer?". uhm perl-gtk, perl-tk? -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: OT Python stuff (was RE: Python in Xconq) 2003-11-19 16:44 ` Bruno Boettcher @ 2003-11-19 17:58 ` Eric McDonald 2003-11-19 21:18 ` GDL, XML and others...Re: " Jakob Ilves 2003-11-20 4:38 ` Erik Jessen 2003-11-19 22:14 ` OT Python stuff (was RE: Python in Xconq) Brandon J. Van Every 2003-11-20 3:10 ` Erik Jessen 2 siblings, 2 replies; 49+ messages in thread From: Eric McDonald @ 2003-11-19 17:58 UTC (permalink / raw) To: bboett; +Cc: xconq7 On Wed, 19 Nov 2003, Bruno Boettcher wrote: > > And a scripting language is seriously preferred, because it will permit > > so much more stuff. > yah :D And that can also be a problem. Think about the possibilities for cheating. And we would have to be more cautious about security too. > > If we add a scripting language, then I would submit that we write a > > simple porting script to convert GDL to that language, and drop GDL. > > IMHO, GDL is just a way to fill in data-structures, and any language can > > do that. > oh? that sounds like a nice idea? Here are a few more points: (1) Richard mentioned to me yesterday that each additional piece of external software that becomes an Xconq dependency is an additional annoyance. If you build tkconq then you need Tcl/Tk, and if you build sdlconq then you need SDL. Do we really want to say that we also need Perl (which is fairly ubiquitous on Linux, but not necessarily so on other platforms) or Python (which is admittedly a nice language, but still not as widespread as Perl, AFAICT)? (2) Richard also raised the idea of using Tcl as an Xconq scripting engine. This partially eliminates the concern just raised; however with the SDL interface this would still be regarded as an additonal dependency. (3) A full-blown scripting language can open many doors for cheating, as I mentioned above. (4) GDL actually does usefully serve an important niche: game designers who are uncomfortable with a larger language. If we replace GDL, then we are raising the entry barrier for some of those who wish to design game modules for Xconq. I am not against adding a scripting engine to Xconq based on external software, but I do urge caution and consideration.... Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-19 17:58 ` Eric McDonald @ 2003-11-19 21:18 ` Jakob Ilves 2003-11-19 23:13 ` Brandon J. Van Every 2003-11-20 5:12 ` Eric McDonald 2003-11-20 4:38 ` Erik Jessen 1 sibling, 2 replies; 49+ messages in thread From: Jakob Ilves @ 2003-11-19 21:18 UTC (permalink / raw) To: Eric McDonald, bboett; +Cc: xconq7 Hello folks! <disclaimer> This is quickly written (I'm as everyone else awfully short of time, the combined curse and blessing of having a family and a job :-). I'm also rude enough to brainstorm about Xconq in spite of the fact that I don't have time to implement any of my ideas. (or even have time to run one single test game of "Bellum Aetarnum".) </disclaimer> First of all: Be careful when dismissing the declarative characteristics of GDL. The fact that GDL in itself isn't a procedural language is a STRENGTH, not a weakness. Replacing the ENTIRE game module language with a procedural language like Python, Perl, Tcl, Ficl (sp?), Javascript etc is overkill if all you want to achieve is the ability of doing a few "if-then-else" or "foreach" things here and there. It's even overkill if you want to do more elaborate coding here and there in the Xconq game definition. Sure, you can do "anything" with Procedural languages but that "anything" includes shooting yourself in the foot in the most amazing ways, especally if the procedural language is the only thing available for creating Xconq games (that is, if there's no declarative language). Also, with the risk of getting my head cut off here, I believe that this approach promotes game definitions which is hard to maintain. As I see it, Xconq still benifits from having a declarative framework (like GDL as of today or XML & co) but that framework can be enhanced by adding the capacity to add procedural (Perl, Python, Javascript etc) code. Of course, such code is added only _if needed_ by the game developer! Those who don't want to do any scripting, they can stay strictly declarative in their game development which I'm bound to believe will greatly simplify their task. In a declarative language, there is no such thing as an "infinite loop" which hangs the application or a "system() call" which happens to wipe out a lot of files. The worst thing that can happen is that your Xconq game behaves strange :'). Having a full fledged procedural language as an option when creating an Xconq game is nice (even if it is potent enough to blow off ones own and others feet). Having such a language _forced_ upon oneself is a bad thing though. Another aspect is how make the AI player understand the scenario if parts of it consists of procedural code. Of course, if the procedural code is executed only at the initial setup of the game in order to "build the setting" then it's a breeze. Just let the code run (perhaps automagically setting up some parts of the scenario such as adjusting starting positions, starting units etc, setting up unit capabilities and other "laws of nature" etc) and once that is done and all procedural code is evaluated, the AI has all it needs to understand the picture (because once the unit capabilities and other "laws of nature" has been defined at the start of the game they remain fixed from then on). However, if pieces of code in the procedural language is supposed to invoked later on in the game, for instance in order to find out if an inactive side will suddenly decide to declare war on some other side, then the AI will have a hard time (harder than usual ;') to find out how to act in order to trigger (or not trigger) that declaration of war. Or even worse, what if the victory condition is expressed as a snippet of code in a procedural language? Well, the AI can just evaluate the expression in order to answer the question "Am I victorious" but the AI will have a problem in order to answer the question "How do I get victorious" (which is the answer we REALLY are intrested in that the AI finds out, in order to have meaningful games against it). Another area where we don't want a full fledged procedural language is the standing orders, especially as those are exposed to the users fingers through the GUI. Imagine player Z trying to setup some spiffy loop in the standing order for a unit, only to find that the standing order loops infinitely. Actually, a potential way to sabotage the game intentionally :'(. One solution can be to define a small language, perhaps a subset of an existing language and then bite the bullet and create an interpreter for that language. How complex language do we need for standing orders? For adjusting the set of units a player starts with depending on the proximity to water? For triggering the declaration of war or the declaration of cease fire for a specific side? For determining if a side has won or not? Are different languages appropriate? I think so. The standing orders, being exposed to the users, should probably be defined in a way which makes them both easy enough to use but still powerful enough for what's needed. The other stuff like in the scenarious themselves might need to be more powerful but don't need to be as streamlined as the standing order syntax. Of course, one could use the interpreter of an existing full fledged language to interprete snippets of code but prior to do so, ensure that the snippet contains nothing but the subset we want to use and if the snippet contains code outside of the subset, then we reject it with an error. However, creating that test, to see if the snippet is within the accepted code subset, will be pretty much work too, so one could as well consider writing a new parser instead. Also, what about those small additions which can help a lot. We don't need to add full procedural capacity to GDL for removing several issues for game creators. For instance, the ability to use more primitive stuff like arithmetic expressions, if-then-else, case expressions etc and so on might go a long way. Even if I like Perl and find it highly productive and useful I would NOT like to have it replace GDL! However, there is XML. What GDL do today can be carried out by XML tomorrow or rather, we can defined an XML language called XGDL, eXtensible Game Design Language. Given the immense support for XML in the industry, there's plenty of open source tools and libraries etc one can use to to create an XML parser for XGDL so it can read scenarious in XML. Also, as XGDL is XML, a lot of already existing tools can be used to assist in the authoring of XGDL files or for displaying them on a wep page in an easy to read format, generate Help files etc. For tiny snippets of procedural code, one can use ECMAscript (aka Javascript). Sure, not the most fantastic language. I don't find it suitable language for writing 10000+ lines systems but luckily that don't matter to Xconq as only snippet is what we need. The Mozilla project has a ECMAscript parser called Rhino. So what I envision is a file with XGDL, containing (or loading external files with) snippets of ECMAscript being used in order to setup certain things like terrain/units or carrying out certain adjustments/interpolations/extrapolations of things which would be tedious to do by hand in the XGDL code. Also, one can use XML events to create small triggers to be executed to test for victory and so on. But of course, as much power as possible should be put into the XGDL language itself, to minimize the need for ECMAscript code. Adding ECMAscript code to a game setup adds fragility to the overall XGDL document and also more easily makes the AI even more confused (as discussed above). Hm, while we are doing XML/XGDL, we have the potential of interacting with other XML languages such as XHTML and SVG. Oh, anyone for using SVG to define the graphics... I swear, SVG is the coolest thing since sliced bread. Antialiazed vectored graphics, in XML. Imagine scaling the units to different sizes in that (works LOVELY :-) and even changing their different orientations. Ok, enough on this thread, I'm getting carried away... (Should not have mentioned SVG. Oh, fantastic SVG ;-). Best regards /IllvilJa aka Jakob Ilves, who don't have time to develop Xconq a bit but in spite of that insists on having ideas and opinions ;-D. --- Eric McDonald <mcdonald@phy.cmich.edu> skrev: > On Wed, 19 Nov 2003, Bruno Boettcher wrote: > > > > And a scripting language is seriously preferred, because it will permit > > > so much more stuff. > > yah :D > > And that can also be a problem. Think about the possibilities for > cheating. And we would have to be more cautious about security > too. > > > If we add a scripting language, then I would submit that we write a > > > simple porting script to convert GDL to that language, and drop GDL. > > > IMHO, GDL is just a way to fill in data-structures, and any language can > > > do that. > > oh? that sounds like a nice idea? > > Here are a few more points: > (1) Richard mentioned to me yesterday that each additional piece > of external software that becomes an Xconq dependency is an > additional annoyance. If you build tkconq then you need Tcl/Tk, > and if you build sdlconq then you need SDL. Do we really want to > say that we also need Perl (which is fairly ubiquitous on Linux, > but not necessarily so on other platforms) or Python (which is > admittedly a nice language, but still not as widespread as Perl, > AFAICT)? > (2) Richard also raised the idea of using Tcl as an Xconq > scripting engine. This partially eliminates the concern just > raised; however with the SDL interface this would still be > regarded as an additonal dependency. > (3) A full-blown scripting language can open many doors for > cheating, as I mentioned above. > (4) GDL actually does usefully serve an important niche: game > designers who are uncomfortable with a larger language. If we > replace GDL, then we are raising the entry barrier for some of > those who wish to design game modules for Xconq. > > I am not against adding a scripting engine to Xconq based on > external software, but I do urge caution and consideration.... > > Eric > ===== (Jakob Ilves) <illvilja@yahoo.com> {http://www.geocities.com/illvilja} Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-19 21:18 ` GDL, XML and others...Re: " Jakob Ilves @ 2003-11-19 23:13 ` Brandon J. Van Every 2003-11-20 5:12 ` Eric McDonald 1 sibling, 0 replies; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-19 23:13 UTC (permalink / raw) To: xconq Jakob Ilves wrote: > > this [procedural language] approach promotes game > definitions which is hard to maintain. But the tradeoff is that the widely used scripting languages are procedural. You get more people who already know the language, more volunteers, and thus something to actually maintain. ;-) "I want to tweak games in Python / Perl" is not the same sentiment as "I want to tweak games in GDL for Xconq." One is a wider net than the other. > Those who don't want to do any scripting, they can stay > strictly declarative in their game > development which I'm bound to believe will greatly simplify > their task. Ok, some reality checking here. Are a great many people developing Xconq games in GDL? If not, then we have to face the fact that no matter what theoretical merits it may have as a declarative language, people don't use it. So you need a language that is more popular, and in theory we could pick either a procedural or a declarative one. The list of likely suspects in the procedural camp is obvious. What about the declarative camp? Name me a wildly popular declarative language. > In a declarative > language, there is no such thing as an "infinite loop" which > hangs the application or a "system() > call" which happens to wipe out a lot of files. The worst > thing that can happen is that your > Xconq game behaves strange :'). This is a sandboxing issue, not a procedural vs. declarative issue. If you can find any bug that causes the declarative language to hang, or you can alter any game resources to achieve the same effect, you can have denial-of-service attacks. > Another aspect is how make the AI player understand the > scenario if parts of it consists of > procedural code. Of course, if the procedural code is > executed only at the initial setup of the > game in order to "build the setting" then it's a breeze. > Just let the code run (perhaps > automagically setting up some parts of the scenario such as > adjusting starting positions, starting > units etc, setting up unit capabilities and other "laws of > nature" etc) and once that is done and > all procedural code is evaluated, the AI has all it needs to > understand the picture (because once > the unit capabilities and other "laws of nature" has been > defined at the start of the game they > remain fixed from then on). AIs are going to get written by whomever in their favorite language. Trying to force procedural vs. declarative languages on an AI programmer is irrelevant. It's a huge amount of work, the programmer will inevitably choose the language he likes, or find a different project to contribute to. > One solution can be to define a small language, perhaps a > subset of an existing language and then > bite the bullet and create an interpreter for that language. Of course, you didn't volunteer to implement any of your brainstorms, so that's quite a primrose path you're laying out for others. Solving perceived problems by writing scripting languages from scratch is utter foolishness. > So what I envision is a file with XGDL, containing (or > loading external files with) snippets of > ECMAscript being used in order to setup certain things like > terrain/units or carrying out certain > adjustments/interpolations/extrapolations of things which > would be tedious to do by hand in the > XGDL code. Also, one can use XML events to create small > triggers to be executed to test for > victory and so on. I can't comment, I'm not a XML guy. I think your vision is flawed in that you're not volunteering to implement it, and it sounds like a lot of work. > Oh, anyone for using SVG to define the graphics... I swear, > SVG is the coolest thing since sliced > bread. Antialiazed vectored graphics, in XML. Imagine > scaling the units to different sizes in > that (works LOVELY :-) and even changing their different orientations. Might be a good web-oriented approach. When I last looked at SVG it wasn't ready for prime time, but I can't remember if that was 1 or 2 years ago. I'm not up on it lately. I'm also not a web-oriented developer. You'd need to scare those up to do those kinds of things. > Ok, enough on this thread, I'm getting carried away... > > aka Jakob Ilves, who don't have time to develop Xconq a bit > but in spite of that insists on having > ideas and opinions ;-D. Indeed! Back to Earth, flyboy. ;-D Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-19 21:18 ` GDL, XML and others...Re: " Jakob Ilves 2003-11-19 23:13 ` Brandon J. Van Every @ 2003-11-20 5:12 ` Eric McDonald 2003-11-20 8:54 ` Bruno Boettcher 1 sibling, 1 reply; 49+ messages in thread From: Eric McDonald @ 2003-11-20 5:12 UTC (permalink / raw) To: Jakob Ilves; +Cc: bboett, xconq7 On Wed, 19 Nov 2003, Jakob Ilves wrote: > I'm also rude >enough to brainstorm about Xconq in > spite of the fact that I don't have time to implement any of my >ideas. I personally don't consider this rude. You are making thoughtful contributions to the discussion. Thank you. > (or even have time to run > one single test game of "Bellum Aetarnum".) When you get a chance. :-) > First of all: Be careful when dismissing the declarative >characteristics of GDL. The fact that > GDL in itself isn't a procedural language is a STRENGTH, not a >weakness. Replacing the ENTIRE > game module language with a procedural language like Python, >Perl, Tcl, Ficl (sp?), Javascript etc > is overkill if all you want to achieve is the ability of doing >a few "if-then-else" or "foreach" > things here and there. It's even overkill if you want to do >more elaborate coding here and there > in the Xconq game definition. I agree. > Sure, you can do "anything" with Procedural languages but that >"anything" includes shooting > yourself in the foot in the most amazing ways, especally if the >procedural language is the only > thing available for creating Xconq games (that is, if there's >no declarative language). Yes, this is true. > Javascript etc) code. Of course, such code is added only _if >needed_ by the game developer! > Those who don't want to do any scripting, they can stay >strictly declarative in their game > development which I'm bound to believe will greatly simplify >their task. I agree. > call" which happens to wipe out a lot of files. The worst >thing that can happen is that your > Xconq game behaves strange :'). Been there. Done that. :-) Actually, I have been able to create crashes with GDL. Setting a certain value to 0, for example, and then finding out that Xconq divides by that value somewhere without checking to see if it is 0 first. But this is rare. > Another aspect is how make the AI player understand the >scenario if parts of it consists of > procedural code. Yes. Stan alludes to this in his recent comments. Also, this is discussed in the "GDL Design Decisions" section of the Xconq Hacking Manual: http://sources.redhat.com/xconq/manual/hacking_9.html#SEC9 > other side, then the AI will have a hard time (harder than >usual ;') :-) > loops infinitely. Actually, a potential way to sabotage the >game intentionally :'(. Yes. I have also expressed this concern. > bite the bullet and create an interpreter for that language. >How complex language do we need for > standing orders? Not very. That is why I suggested merely extending the standing orders syntax. > Are different languages appropriate? I think so. The standing As do I. > Also, what about those small additions which can help a lot. >We don't need to add full procedural > capacity to GDL for removing several issues for game creators. Absolutely. And this is the development path I certainly favor. >For instance, the ability to use > more primitive stuff like arithmetic expressions, if-then-else, >case expressions etc and so on > might go a long way. Yes. And if one incorporates certain arithmetic expressions into GDL, the AI need not get confused, because the expression would be evaluated when it was interpreted and the underlying data structure would be manipulated accordingly.... All I really had in mind would perhaps look something like this: (table fire-hit-chance (u* u* :hit-chance:*50%) ) which would reference all entries in the hit-chance table and multiply them by 0.5, and store the results in the corresponding fire-hit-chance entries. > Even if I like Perl and find it highly productive and useful I >would NOT like to have it replace > GDL! I don't think I would either. > However, there is XML. What GDL do today can be carried out by XML tomorrow or rather, we can > defined an XML language called XGDL, eXtensible Game Design Language. Given the immense support > for XML in the industry, there's plenty of open source tools and libraries etc one can use to to > create an XML parser for XGDL so it can read scenarious in XML. The section I cited above: http://sources.redhat.com/xconq/manual/hacking_9.html#SEC9 also demonstrates how GDL is less cumbersome to deal with. > For tiny snippets of procedural code, one can use ECMAscript >(aka Javascript). Sure, not the most > fantastic language. I will look at it. Thanks for the suggestion. (I now have quite a bit of reading to do this weekend.) > Oh, anyone for using SVG to define the graphics... I swear, SVG is the coolest thing since sliced > bread. Antialiazed vectored graphics, in XML. Imagine scaling the units to different sizes in > that (works LOVELY :-) and even changing their different orientations. > > Ok, enough on this thread, I'm getting carried away... (Should not have mentioned SVG. Oh, > fantastic SVG ;-). I will look at it. Thanks for the suggestion. (I now have even more reading this weekend.) > aka Jakob Ilves, who don't have time to develop Xconq a bit but >in spite of that insists on having > ideas and opinions ;-D. That is not a crime, especially if you have a family. And to be honest, there are some days that I don't feel like working on Xconq, so I just play it. ;-) Thanks again for your thoughts; I think you have the right idea (IMO) about many things. Best regards, Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-20 5:12 ` Eric McDonald @ 2003-11-20 8:54 ` Bruno Boettcher 2003-11-20 11:01 ` Jakob Ilves 0 siblings, 1 reply; 49+ messages in thread From: Bruno Boettcher @ 2003-11-20 8:54 UTC (permalink / raw) To: xconq7 On Wed, Nov 19, 2003 at 11:37:31PM -0500, Eric McDonald wrote: > > bite the bullet and create an interpreter for that language. > >How complex language do we need for > > standing orders? > > Not very. That is why I suggested merely extending the standing > orders syntax. hmmm as long as this extension covers the use cases i send some time ago (e.g. a true sentry standing order) as long as i don't confound again with a doctrine.... > > However, there is XML. What GDL do today can be carried out by XML tomorrow or rather, we can > > defined an XML language called XGDL, eXtensible Game Design Language. Given the immense support > > for XML in the industry, there's plenty of open source tools and libraries etc one can use to to > > create an XML parser for XGDL so it can read scenarious in XML. > > The section I cited above: > http://sources.redhat.com/xconq/manual/hacking_9.html#SEC9 > also demonstrates how GDL is less cumbersome to deal with. yep, what GDL uses most are tables, and that's a structure that is really hard to manage easily under XML... i gave it a shot some time a go to make a grammar for GDL, but the result was very cumebrsome.... and unless we make a proper editor for it, not very human readable, thus worse than actual GDL.... > > For tiny snippets of procedural code, one can use ECMAscript > >(aka Javascript). Sure, not the most > > fantastic language. uh... why that? > > Oh, anyone for using SVG to define the graphics... I swear, SVG is the coolest thing since sliced yep, its only unfortunate that still most browsers can't interpret that stuff, since i agree, this really cool! -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-20 8:54 ` Bruno Boettcher @ 2003-11-20 11:01 ` Jakob Ilves 2003-11-20 11:19 ` Brandon J. Van Every 2003-11-20 11:36 ` GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) Bruno Boettcher 0 siblings, 2 replies; 49+ messages in thread From: Jakob Ilves @ 2003-11-20 11:01 UTC (permalink / raw) To: bboett, xconq7 Hello again! --- Bruno Boettcher <bboett@adlp.org> skrev: > On Wed, Nov 19, 2003 at 11:37:31PM -0500, Eric McDonald wrote: [ Some lines trimmed, to cut down my email SOMEWHAT in size ;-] > > > However, there is XML. What GDL do today can be carried out by XML tomorrow or rather, we > can > > > defined an XML language called XGDL, eXtensible Game Design Language. Given the immense > support > > > for XML in the industry, there's plenty of open source tools and libraries etc one can use > to to > > > create an XML parser for XGDL so it can read scenarious in XML. > > > > The section I cited above: > > http://sources.redhat.com/xconq/manual/hacking_9.html#SEC9 > > also demonstrates how GDL is less cumbersome to deal with. > yep, what GDL uses most are tables, and that's a structure that is > really hard to manage easily under XML... i gave it a shot some time a > go to make a grammar for GDL, but the result was very cumebrsome.... and > unless we make a proper editor for it, not very human readable, thus > worse than actual GDL.... Oh, what a bummer. But wait, XML very much resembles.... let's see... HTML!! Actually, it's VERY similar! And, so would XGDL be too. Tons of non programmers out there on netland do write HTML. Heck, KIDS do write HTML these days. Tons of people out there would apply their HTML (or preferrably, XHTML, I know ;-) skills to the XGDL files to find out how they work. Trouble with managing tables in XML languages? Yes, maybe there are but again, many HTML editors accept the way tables are managed in HTML, so they wouldn't groan too much in XGDL. (Ok, they would perhaps groan, a little, when dealing with the attack tables for all units vs all units in the standard game). So, I think that XGDL could attract quite a few people. Remember, XML is _WIDELY_ adopted in the industry. Today, GDL resembles... LISP. Fun for me, who have studied computers science and thus knowing that the language were invented in the 1950s. Of course, LISP and dialects have survived all these years for a reason. Compared to how easy it is to implement, it's amazingly powerful. So I think GDL in itself might frighten some developers who would approach it if it were XGDL instead. But yes, maybe XGDL is overall less attractive than GDL. (But I have my sincere religous beliefs). Of course, regardless of language you define the Xconq games in, the document probably always will be frightening ;-). It's a fairly complex task in any case... hm, what about... <troll type="flamebait"> ...game design GUIs anyone? </troll> > > > For tiny snippets of procedural code, one can use ECMAscript > > >(aka Javascript). Sure, not the most > > > fantastic language. > uh... why that? Well, the OO implementation is sure OO, but I find it amazingly lightweight. Like as if Monthy Python (no pun vs Python language intended) would have designed it. But as I said, that's no problem, only charming... > > > Oh, anyone for using SVG to define the graphics... I swear, SVG is the coolest thing since > sliced > yep, its only unfortunate that still most browsers can't interpret that > stuff, since i agree, this really cool! Actually, it will get there. The best two implementations are the XML projects SVG package named Batik (http://xml.apache.org/batik), and the Adobe SVG plugin (http://www.adobe.com/svg) for MS Internet Explorer and Netscape. Also, Mozilla has a project for SVG support in the browser, even if they don't consider the code production ready yet it's making nice progress. Intresting with the Batik package is that it supports that you use it for Java applications in order to draw the graphics in your GUI. Java Xconq anyone ;-)? Also, for those who want to check out SVG implemented in C there is Sodipodi, an open source vector graphics editor which is written in C and uses pure SVG as it's document format (both save and load). Ooh, I'm talking about SVG _AGAIN_... I _REALLY_ refuse to get back to earth, don't I ;-)? Have a good time all of you! Best regards /IllvilJa (... calling planet earth!) > -- > ciao bboett > ============================================================== > bboett@adlp.org > http://inforezo.u-strasbg.fr/~bboett > =============================================================== ===== (Jakob Ilves) <illvilja@yahoo.com> {http://www.geocities.com/illvilja} Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-20 11:01 ` Jakob Ilves @ 2003-11-20 11:19 ` Brandon J. Van Every 2003-11-20 12:59 ` Jakob Ilves 2003-11-20 11:36 ` GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) Bruno Boettcher 1 sibling, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-20 11:19 UTC (permalink / raw) To: xconq Jakob Ilves wrote: > > <troll type="flamebait"> > ...game design GUIs anyone? > </troll> Let's get to usable OO game design APIs before even bothering to waste a brain cell on that. For instance, I'd like to see a fledgling game designer / mediocre programmer write a Python script that implements a One Hex Combat Resolution system. With that sort of API tool, Xconq doesn't have to be a game about hiding outside of cities you've just taken over. You could have a GUI to implement various kinds of OHCRs, someday, but first you need an API for OHCRs. No point visually programming what you don't even know how to manually program yet. > Well, the OO implementation is sure OO, but I find it > amazingly lightweight. Like as if Monthy > Python (no pun vs Python language intended) would have > designed it. But as I said, that's no > problem, only charming... Ministry of Sillycoding? > Ooh, I'm talking about SVG _AGAIN_... I _REALLY_ refuse to > get back to earth, don't I ;-)? Who knows, you may yet talk yourself into coding XML / SVG stuff. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-20 11:19 ` Brandon J. Van Every @ 2003-11-20 12:59 ` Jakob Ilves 2003-11-20 13:54 ` One Hex Combat Resolution, and jeweled teeth Brandon J. Van Every 0 siblings, 1 reply; 49+ messages in thread From: Jakob Ilves @ 2003-11-20 12:59 UTC (permalink / raw) To: Brandon J. Van Every, xconq Hello again! --- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev: > Jakob Ilves wrote: > > > > <troll type="flamebait"> > > ...game design GUIs anyone? > > </troll> > > Let's get to usable OO game design APIs before even bothering to waste a > brain cell on that. For instance, I'd like to see a fledgling game Oh no, there's a lot of people on this list who _LOVE_ to waste braincells on stuff! We will continue to do so, regardless if the things we suggest gets Xconq anywhere or not. The truth is, you don't know what idea or whatever there is that sparks of some good leaps in Xconq development. (Ok, someone might actually manage to inspire folks do develop Xconq into some totally disastrous direction but I consider that risk neglible). Seriously, you appear to be very focused and ambitious which is good. That's the attitude I have towards software development (mine and others) when I'm at work. However, when I get into the Xconq world, I don't want to "get to work" again. I don't want that "life and death" kind of attitude towards software development which I have at my job, I want to have a software project I can have a relaxed attitude to. And therefore, I don't take Xconq _THAT_ serious and I think many other people on the list feels the same. Sure, Xconq would in a way benefit if we made all the right decisions and never went down the "wrong tracks" and analyze things carefully before every step and so on. But that would be _BORING_ because we would not do any experimentation, no "we try this out and if it don't work we'll scrap it". Many of us are here to make mistakes as well as clever decisions. Actually, some of us find mistakes made in a relaxed environment quite rewarding. (Actually, that's why I'm into strategy games. My life is good and comfortable, so I have a need for simulating situations where I'm by no means are safe but instead might be obliterated in quite fascinating ways.) Xconq has been developing slowly in a sense and I can see that if you're impatient, that can be frustrating to see other people reluctant to force the development pace. Another intresting thing, given that Xconq don't develop at the speed of light is that the Xconq project actually can monitor other, not ready, projects for useful tools to use in a year or two. Some unfinished stuff out there WILL be finished and Xconq can actually count on using them once they are ready. > designer / mediocre programmer write a Python script that implements a > One Hex Combat Resolution system. With that sort of API tool, Xconq > doesn't have to be a game about hiding outside of cities you've just > taken over. Oh, yes, I know! Take the city with ONE tank... And don't leave any other units in it when the enemy is nearby. But cannot GDL be written such that unless you kill or route away all units of a certain type, you cannot capture the unit? Isn't there a "occupant-defend" or such? Or maybe that just means they counter attack and if they fail to slay the attacker the attacker then has a chance to capture the city ANYWAY? I remember when I first saw Xconq in 1988, it was a hacked up version at Chalmers university and in that game, you _STUFFED UP_ your cities with all kinds of infantry, mechinf and armor and an attacker had to slay ALL of them to capture the city. Sure, if all defenders had the experience level "green" (lowest) and the attacker were a commando unit with experience "Ramboid" (highest level) that attacker could actually carry out one attack and destroy them all defenders in a row and then march in. Of course, that commando would then better leave, because commandos were not excellent city defenders in that game. <offtopic> Ah, I'll write a separate mail about that, Brandon, about that old hacked Xconq! You've already triggered my "sentimental asshole" state by mentioning 6502 assembler and such things from the early 80's. (CBM 64... lovely system! 1MHz CPU. No machine code instructions for multiplying or division. 16 colors video. :-). So, as a counter strike against you personally I mention these things: Metagaming's "Ogre" and "Chitin:II", Task force game's "Starfire" series, GDW:s "Asteroid", "Dark Nebula" and "Imperium". Of course... "Advanced Dungeon and Dragons". Let's see if that struck you with sentimentality as well! (of an enjoyable kind of course :-) </offtopic> > You could have a GUI to implement various kinds of OHCRs, someday, but > first you need an API for OHCRs. No point visually programming what you > don't even know how to manually program yet. Well, at least one point... it's an exercise in coding the stuff. Of course, it might or might not be frustrating to see that code being unable to run due to the API changing. But that's life when developing with bleeding edge stuff. Scrapping code one have written in the past... > > Well, the OO implementation is sure OO, but I find it > > amazingly lightweight. Like as if Monthy > > Python (no pun vs Python language intended) would have > > designed it. But as I said, that's no > > problem, only charming... > > Ministry of Sillycoding? :-D! Javascript is nice for code you bolt together on the fly in a .CGI script before you send it in a HTML page to the eager webbrowser. > > Ooh, I'm talking about SVG _AGAIN_... I _REALLY_ refuse to > > get back to earth, don't I ;-)? > > Who knows, you may yet talk yourself into coding XML / SVG stuff. The awful thing is that I'm already there in my job. Being a real masochist, I write the graphics in a text editor (anyone else who's a _real man_ ;-). Seriously, that's the only way to learn well enough to successfully create .CGI scripts which are capable of emitting useful SVG code for the end user. But I'm evaluating editors. Sodipodi is closest to my needs. See, another open source project where I might need to contribute in order to get what I want. There so many of them :-). But who knows, I might have time in February next year to do some sabotages by infecting Xconq with XML/SVG... "XML Batik? xpat? Oh no, not yet ANOTHER software package needed for Xconq, I've already installed Perl/Python/MSExcel/Mozilla/Slammer etc". > > Cheers, www.indiegamedesign.com > Brandon Van Every Seattle, WA > > Taking risk where others will not. Best regards /IlvJa ===== (Jakob Ilves) <illvilja@yahoo.com> {http://www.geocities.com/illvilja} Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html ^ permalink raw reply [flat|nested] 49+ messages in thread
* One Hex Combat Resolution, and jeweled teeth 2003-11-20 12:59 ` Jakob Ilves @ 2003-11-20 13:54 ` Brandon J. Van Every 2003-11-20 17:06 ` Eric E Moore 0 siblings, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-20 13:54 UTC (permalink / raw) To: xconq From: Jakob Ilves [mailto:illvilja@yahoo.com] > > > designer / mediocre programmer write a Python script that > > implements a > > One Hex Combat Resolution system. With that sort of API tool, Xconq > > doesn't have to be a game about hiding outside of cities you've just > > taken over. > > Oh, yes, I know! Take the city with ONE tank... And don't > leave any other units in it when the > enemy is nearby. But cannot GDL be written such that unless > you kill or route away all units of a > certain type, you cannot capture the unit? Isn't there a > "occupant-defend" or such? Or maybe > that just means they counter attack and if they fail to slay > the attacker the attacker then has a > chance to capture the city ANYWAY? Maybe all of these things can be done in GDL already. The question is, does anyone know they can do them? Is it a fungible API? Is it OO, hiding details you don't want to deal with at present? I will be making a judgement this weekend, as I attempt to embed Python into Xconq. > I remember when I first saw Xconq in 1988, it was a hacked up > version at Chalmers university and > in that game, you _STUFFED UP_ your cities with all kinds of > infantry, mechinf and armor and an > attacker had to slay ALL of them to capture the city. Sure, > if all defenders had the experience > level "green" (lowest) and the attacker were a commando unit > with experience "Ramboid" (highest > level) that attacker could actually carry out one attack and > destroy them all defenders in a row > and then march in. Of course, that commando would then > better leave, because commandos were not > excellent city defenders in that game. Do game developers and game players have easy ways of switching to whatever they prefer? Do different variants get played regularly? If not, why not? > <offtopic> > "Advanced Dungeon and Dragons". > > Let's see if that struck you with sentimentality as well! (of > an enjoyable kind of course :-) > </offtopic> "S1: Tomb Of Horrors." The first dungeon module! I have always been a sucker for Egyptian tomb crawls. I can't possibly think bad of movies like The Mummy, it goes deep into childhood. Trapping your soul in a floating skull's teeth, that's gaming! With the dancing dagger of the sample dungeon in the basic D&D blue book a close second. I was a big fan of the Sinbad movies. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: One Hex Combat Resolution, and jeweled teeth 2003-11-20 13:54 ` One Hex Combat Resolution, and jeweled teeth Brandon J. Van Every @ 2003-11-20 17:06 ` Eric E Moore 2003-11-20 17:37 ` Jakob Ilves 2003-11-21 2:16 ` Eric McDonald 0 siblings, 2 replies; 49+ messages in thread From: Eric E Moore @ 2003-11-20 17:06 UTC (permalink / raw) To: Brandon J. Van Every; +Cc: xconq [-- Attachment #1: Type: text/plain, Size: 2260 bytes --] "Brandon J. Van Every" <vanevery@indiegamedesign.com> writes: > From: Jakob Ilves [mailto:illvilja@yahoo.com] >> >> > designer / mediocre programmer write a Python script that >> > implements a >> > One Hex Combat Resolution system. With that sort of API tool, Xconq >> > doesn't have to be a game about hiding outside of cities you've just >> > taken over. >> >> Oh, yes, I know! Take the city with ONE tank... And don't leave >> any other units in it when the enemy is nearby. But cannot GDL be >> written such that unless you kill or route away all units of a >> certain type, you cannot capture the unit? Isn't there a >> "occupant-defend" or such? Or maybe that just means they counter >> attack and if they fail to slay the attacker the attacker then has >> a chance to capture the city ANYWAY? > > Maybe all of these things can be done in GDL already. Yes, "protection" applies to capture attempts. something vaguely like: (table protection (infantry city 0)) (table capture-chance (infantry city 100)) (table acp-to-capture (infantry city 1)) would make infantry capture cities 100% of the time, unless there's an infantry in the city, in which case they need to kill it first. > The question is, does anyone know they can do them? Yes. > Is it a fungible API? It's a declarative language, more akin to HTML than a real programming language. The fact that a game can be statically analyzed without having to solve the halting problem is a major win for AI writing and many other similar things. I think, at least, before you decide to throw out GDL you should try using it to design a game (or part of one) to at least get some feel for what's there, and what it does. > Is it OO, hiding details you don't want to deal with at present? Most of the tables have sensible defaults, and can be ignored. > I will be making a judgement this weekend, as I attempt to embed > Python into Xconq. Like others, I think replacing GDL with python would be a mistake. > Do game developers and game players have easy ways of switching to > whatever they prefer? Do different variants get played regularly? If > not, why not? Yes, and Yes. -- Eric E. Moore [-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: One Hex Combat Resolution, and jeweled teeth 2003-11-20 17:06 ` Eric E Moore @ 2003-11-20 17:37 ` Jakob Ilves 2003-11-20 17:47 ` Emmanuel Fritsch 2003-11-20 19:53 ` Eric E Moore 2003-11-21 2:16 ` Eric McDonald 1 sibling, 2 replies; 49+ messages in thread From: Jakob Ilves @ 2003-11-20 17:37 UTC (permalink / raw) To: Eric E Moore, Brandon J. Van Every; +Cc: xconq Hello Folks! Would it be OK to amend the standard game or rather, create an experimental variant of it where certain ground units defend a city until death from being captured (and where garrisson fighters prevent bombers to drop bombs on their city)? I would very strongly insist on having that feature made permanent into the standard game. (And Eric McDonald, Bellum Aetaernum could consider it too). I can have a quick stab at it this weekend! No, I don't have time to contribute to Xconq, it's Brandon's fault, he tricked me into it :-). My apologizes for a short email ;-). And no, this should not be taken as me getting back on the ground! --- Eric E Moore <e.e.moore@sheffield.ac.uk> skrev: > "Brandon J. Van Every" <vanevery@indiegamedesign.com> writes: > > > From: Jakob Ilves [mailto:illvilja@yahoo.com] > >> [ Lines deleted, to save your precious time as a change ;- ] > > Do game developers and game players have easy ways of switching to > > whatever they prefer? Do different variants get played regularly? If > > not, why not? > > Yes, and Yes. I personally love this "variants" feature in GDL. I use it all the time and it has potential for enhancements. I try out most of the different kinds of features, at least in the standards game. ("Ice age" variant in standard.g is my fault. It was a tiny contribution of perhaps 20 lines of GDL code in order to create an intresting scenario and others refined it to limit down the number of nations to those living in cold areas. That's my way of doing development. I fly around like a vulture, let others do the inital efforts of 30000+ lines of code then I identify a place where I can add 20 lines which add value. It's fun being a open source scavanger... ;-) /IllvilJa the Orbiter ===== (Jakob Ilves) <illvilja@yahoo.com> {http://www.geocities.com/illvilja} Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: One Hex Combat Resolution, and jeweled teeth 2003-11-20 17:37 ` Jakob Ilves @ 2003-11-20 17:47 ` Emmanuel Fritsch 2003-11-20 19:53 ` Eric E Moore 1 sibling, 0 replies; 49+ messages in thread From: Emmanuel Fritsch @ 2003-11-20 17:47 UTC (permalink / raw) To: Jakob Ilves; +Cc: Eric E Moore, Brandon J. Van Every, xconq Jakob Ilves a écrit : > > Hello Folks! > > Would it be OK to amend the standard game or rather, > create an experimental variant of it where certain > ground units defend a city until death from being > captured > > (and where garrisson fighters prevent bombers > to drop bombs on their city)? Once upon a time, I tried to enrich the greek game with realistic naval battle. I wanted boat to be able to sink boat, even when the sunk boat contains infantry. I wanted contained infantry to attack boat, kill the contained infantry, and captur the boat. But for that purpose, the "protection" table should be splited into two tables : one for protection against capture, the second against hit. a+ manu ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: One Hex Combat Resolution, and jeweled teeth 2003-11-20 17:37 ` Jakob Ilves 2003-11-20 17:47 ` Emmanuel Fritsch @ 2003-11-20 19:53 ` Eric E Moore 1 sibling, 0 replies; 49+ messages in thread From: Eric E Moore @ 2003-11-20 19:53 UTC (permalink / raw) To: Jakob Ilves; +Cc: xconq [-- Attachment #1.1: Type: text/plain, Size: 0 bytes --] [-- Attachment #1.2: Type: application/pgp-signature, Size: 184 bytes --] [-- Attachment #2.1: Type: text/plain, Size: 617 bytes --] Jakob Ilves <illvilja@yahoo.com> writes: > Hello Folks! > > Would it be OK to amend the standard game or rather, create an > experimental variant of it where certain ground units defend a city > until death from being captured (and where garrisson fighters > prevent bombers to drop bombs on their city)? I would very strongly > insist on having that feature made permanent into the standard game. > (And Eric McDonald, Bellum Aetaernum could consider it too). You might want to try playtesting with the attached patch to standard.g. I think it more or less does what you want. -- Eric E. Moore [-- Attachment #2.2: Type: application/pgp-signature, Size: 184 bytes --] [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: Patch to add \"invincible cities\" option --] [-- Type: text/x-patch, Size: 881 bytes --] --- /home/ph1eem/software/src/xconq-7.4.1/lib/standard.g 2000-11-22 16:36:16.000000000 +0000 +++ standard.g 2003-11-20 18:07:50.000000000 +0000 @@ -56,6 +56,21 @@ (unit-moved (sound "pop 2")) )) )) + ("Invincible Cities" invincible + "Cities cannot be captured/damaged while occupied" + (true + (table protection add + (i places 0) + (a places 25) ; armor alone may be captured with a place + ) + (table capture-chance add + (i places (90 80 70))) + (table capture-chance add + (a places (90 80 70))) + (table independent-capture-chance add + (i places (100 90 80))) + (table independent-capture-chance add + (a places (100 90 80))))) ("Silhouettes" silhouettes "Use silhouettes for unit display instead of color images." (true ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: One Hex Combat Resolution, and jeweled teeth 2003-11-20 17:06 ` Eric E Moore 2003-11-20 17:37 ` Jakob Ilves @ 2003-11-21 2:16 ` Eric McDonald 2003-11-21 3:03 ` What is Python really good for? Brandon J. Van Every 1 sibling, 1 reply; 49+ messages in thread From: Eric McDonald @ 2003-11-21 2:16 UTC (permalink / raw) To: Eric E Moore; +Cc: xconq Hi Eric, On Thu, 20 Nov 2003, Eric E Moore wrote: > language. The fact that a game can be statically analyzed without > having to solve the halting problem is a major win for AI writing and > many other similar things. Yes. > I think, at least, before you decide to throw out GDL you should try > using it to design a game (or part of one) to at least get some feel > for what's there, and what it does. I absolutely agree. Otherwise it is just to easy to take the "seagull manager" approach (no offense to the at least one manager who is subscribed to the list), namely: fly in, crap over everything, and then fly out. Regards, Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* What is Python really good for? 2003-11-21 2:16 ` Eric McDonald @ 2003-11-21 3:03 ` Brandon J. Van Every 0 siblings, 0 replies; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-21 3:03 UTC (permalink / raw) To: xconq Eric McDonald wrote: > > I absolutely agree. Otherwise it is just to easy to take the > "seagull manager" approach (no offense to the at least one manager > who is subscribed to the list), namely: fly in, crap over > everything, and then fly out. Given people's comments about GDL, I actually don't think replacing it with Python is the big benefit Python has to offer. At least, not right now. That will happen in time if people become sold on Python, but for now, GDL seems to be suiting a lot of your purposes. The big benefit of Python is turning your C development into bona fide OO development. It is a general migration strategy. Skip the C++ phase, go straight to a modern garbage collected high level OO language that most people find far easier to work with. Changing the kernel to implement non-trivial new features becomes more pleasant and viable. Newcomers interface to Xconq code more easily because paradigms are OO. In particular, things are inherited. Also it is a mainstream freeware tool. I imagine you won't protest about that aspect of it. Just about everyone thinks it's better than TCL, and there are PyTk bindings if anyone wants to modify extant GUI code. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) 2003-11-20 11:01 ` Jakob Ilves 2003-11-20 11:19 ` Brandon J. Van Every @ 2003-11-20 11:36 ` Bruno Boettcher 1 sibling, 0 replies; 49+ messages in thread From: Bruno Boettcher @ 2003-11-20 11:36 UTC (permalink / raw) To: xconq7 On Thu, Nov 20, 2003 at 11:59:33AM +0100, Jakob Ilves wrote: > Oh, what a bummer. But wait, XML very much resembles.... let's see... HTML!! Actually, it's true, then what? make some slt sheets to transform GDL grammar into xhtml and back?? > HTML. Heck, KIDS do write HTML these days. Tons of people out there would apply their HTML (or uhm.... you looked at how actual kids nowadays write HTML? ever heard of frontend and other crap of that sort? if i look at my students, in contrast to my (optimistic?) forecasts the number of people beeing able to read plain HTML before entering at university is dropping rapidly... :( > Trouble with managing tables in XML languages? Yes, maybe there are but again, many HTML editors then we are back to needing a GUI of some sort to edit the GDL files... wasn't the purpose of all this to get a file format that should be easily be interpretable in its raw format? > accept the way tables are managed in HTML, so they wouldn't groan too much in XGDL. (Ok, they > would perhaps groan, a little, when dealing with the attack tables for all units vs all units in > the standard game). that's exactly my point.... the game definitions are mainly tables, and those look plain ugly in raw XML... either way you turn it ;) > So, I think that XGDL could attract quite a few people. Remember, XML is _WIDELY_ adopted in the heh i am using it extensively myself, i know that, but in the same scope i seldom have ot edit that stuff by hand.... i nearly allways have some program making this for me.... > Today, GDL resembles... LISP. Fun for me, who have studied computers science and thus knowing don't get it wrong, i was never comfortable with the actual GDL, Stan and the other might remind my pathetic attempts to make some games.... > But yes, maybe XGDL is overall less attractive than GDL. (But I have my sincere religous > beliefs). :D > Of course, regardless of language you define the Xconq games in, the document probably always will > be frightening ;-). It's a fairly complex task in any case... hm, what about... > > <troll type="flamebait"> > ...game design GUIs anyone? > </troll> yah hit him hard!! :D > Actually, it will get there. The best two implementations are the XML projects SVG package named i am aware of that stuff, but i won't migrate my pictures to SVG a long as this stuff isn't easily available to most of the www-population... having to install an old version of mozilla instead of my (hated/loved) galeon is a pain in the a.. and the purpose of SVG is somewhere to replace stuff like flash and lots of pictures which are in fact bitmapped vector graphics (all my result charts for example which are all 10x smaller in SVG than in png...) so having an external plugin rendering doesn't yield at the moment the same effect... uh quite offtopic ;) > order to draw the graphics in your GUI. Java Xconq anyone ;-)? aww not that again.... we can admit that that attempt was a plain failure, as Stan foretold :D i should still have the code snippets of our 2 tries lying somewhere around..... -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: OT Python stuff (was RE: Python in Xconq) 2003-11-19 17:58 ` Eric McDonald 2003-11-19 21:18 ` GDL, XML and others...Re: " Jakob Ilves @ 2003-11-20 4:38 ` Erik Jessen 2003-11-20 10:19 ` cheating Brandon J. Van Every 1 sibling, 1 reply; 49+ messages in thread From: Erik Jessen @ 2003-11-20 4:38 UTC (permalink / raw) To: 'Eric McDonald', bboett; +Cc: xconq7 Well, I guess, there are two approaches: a) play with people who don't cheat. b) create crypto systems, etc. so that only clever people can cheat. There's some small company out there, that all they do is catch cheaters in some of the large MMUDs. They're actually getting paid by EverQuest et al, I read, to catch cheaters. My vote is: 1) let's get the game good enough (and popular enough) that we'll have cheaters. 2) then deal with security. That's better than making a totally secure game that nobody plays. Most of the time, in my experience, you play with friends, in any case. Erik -----Original Message----- From: xconq7-owner@sources.redhat.com [mailto:xconq7-owner@sources.redhat.com] On Behalf Of Eric McDonald Sent: Wednesday, November 19, 2003 9:25 AM To: bboett@adlp.org Cc: xconq7@sources.redhat.com Subject: Re: OT Python stuff (was RE: Python in Xconq) On Wed, 19 Nov 2003, Bruno Boettcher wrote: > > And a scripting language is seriously preferred, because it will permit > > so much more stuff. > yah :D And that can also be a problem. Think about the possibilities for cheating. And we would have to be more cautious about security too. > > If we add a scripting language, then I would submit that we write a > > simple porting script to convert GDL to that language, and drop GDL. > > IMHO, GDL is just a way to fill in data-structures, and any language can > > do that. > oh? that sounds like a nice idea? Here are a few more points: (1) Richard mentioned to me yesterday that each additional piece of external software that becomes an Xconq dependency is an additional annoyance. If you build tkconq then you need Tcl/Tk, and if you build sdlconq then you need SDL. Do we really want to say that we also need Perl (which is fairly ubiquitous on Linux, but not necessarily so on other platforms) or Python (which is admittedly a nice language, but still not as widespread as Perl, AFAICT)? (2) Richard also raised the idea of using Tcl as an Xconq scripting engine. This partially eliminates the concern just raised; however with the SDL interface this would still be regarded as an additonal dependency. (3) A full-blown scripting language can open many doors for cheating, as I mentioned above. (4) GDL actually does usefully serve an important niche: game designers who are uncomfortable with a larger language. If we replace GDL, then we are raising the entry barrier for some of those who wish to design game modules for Xconq. I am not against adding a scripting engine to Xconq based on external software, but I do urge caution and consideration.... Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* cheating 2003-11-20 4:38 ` Erik Jessen @ 2003-11-20 10:19 ` Brandon J. Van Every 2003-11-21 1:46 ` cheating Eric McDonald 0 siblings, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-20 10:19 UTC (permalink / raw) To: xconq Erik Jessen wrote: > > My vote is: > 1) let's get the game good enough (and popular enough) that we'll have > cheaters. > 2) then deal with security. Well argued! Xconq would be fortunate to have such problems. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: cheating 2003-11-20 10:19 ` cheating Brandon J. Van Every @ 2003-11-21 1:46 ` Eric McDonald 2003-11-21 2:32 ` cheating Brandon J. Van Every 0 siblings, 1 reply; 49+ messages in thread From: Eric McDonald @ 2003-11-21 1:46 UTC (permalink / raw) To: xconq > Erik Jessen wrote: > > > > My vote is: > > 1) let's get the game good enough (and popular enough) that we'll have > > cheaters. > > 2) then deal with security. I suppose I could go to Microsoft's Technet security bulletins and search for all the script-related Outlook, Outlook Express, Exchange, and IE exploits.... No, security should be dealt with when you're doing the things that require security. Perhaps it takes some self-discipline, but that discpline pays off in the long run, rather than a headlong rush to put in new features. Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: cheating 2003-11-21 1:46 ` cheating Eric McDonald @ 2003-11-21 2:32 ` Brandon J. Van Every 2003-11-21 9:30 ` Managing "Designers disgust". cheating Jakob Ilves 0 siblings, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-21 2:32 UTC (permalink / raw) To: xconq Eric McDonald wrote: > > No, security should be dealt with when you're doing the things > that require security. Perhaps it takes some self-discipline, but > that discpline pays off in the long run, rather than a headlong > rush to put in new features. Eric, I am $60K+ in debt from thinking that way. Even a volunteer hobbyist developer has to have a "business model" of some sort, as to how they spend their time. Lotsa things can be done now "to prevent problems later." But if you are mostly deferring to expected future benefits, you will go "bankrupt." One of the basic laws of Getting Things Done [TM] is you have to mostly deal with your present concerns, not your future concerns. There's a budget for future concerns, but it has to be kept on a diet, it cannot be allowed to consume you. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Managing "Designers disgust". RE: cheating 2003-11-21 2:32 ` cheating Brandon J. Van Every @ 2003-11-21 9:30 ` Jakob Ilves 2003-11-21 9:33 ` Brandon J. Van Every 0 siblings, 1 reply; 49+ messages in thread From: Jakob Ilves @ 2003-11-21 9:30 UTC (permalink / raw) To: Brandon J. Van Every, xconq Hello earthlings! --- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev: > Eric McDonald wrote: > > > > No, security should be dealt with when you're doing the things > > that require security. Perhaps it takes some self-discipline, but > > that discpline pays off in the long run, rather than a headlong > > rush to put in new features. > > Eric, I am $60K+ in debt from thinking that way. Even a volunteer > hobbyist developer has to have a "business model" of some sort, as to > how they spend their time. Lotsa things can be done now "to prevent > problems later." But if you are mostly deferring to expected future > benefits, you will go "bankrupt." One of the basic laws of Getting > Things Done [TM] is you have to mostly deal with your present concerns, > not your future concerns. There's a budget for future concerns, but it > has to be kept on a diet, it cannot be allowed to consume you. Agreed. On rec.games.design, someone brought up something he called "Designers disgust", the phenomenom that happens when there is too much work for something in relation to the progress of the project. This leads to that the designer finally get's tired on working on the game and also makes it harder to throw away bad designs, because their implementations were so much work. (Ok, in this mailinglists context this phenomenom could be called "coders disgust" by those who so inclined) So, as a hobby hacker, by strongly handling future concerns one gets a win ONLY if one has strong immunity against the "designers disgust". That is, being very (extremely?) patient and persistent. But what levels of patience is appropriate for a project is pretty much dependant on the people working on it, at least in the hobby programming area. Some folks prefer to invest in managing multiple future concerns simply because they can afford it without running into "designers disgust". They're patient enough. In such environment, it's tough to make them change their minds to shift more of their focus on today's fetures because their current allocation of work on between current and future concerns are working for _them_. If one isn't that patience an extreme solution for a hobby hacker can be to ignore future concerns alltogether in order to speed up short term development. That can lead to a horrible product implementation which is rewritten over and over again but it might on the other hand be written by a very amused developer. For that "pentahexahepta" thing I've lately been considered to do the latter. Take all virtues like structured programmed, OO design, security and _LOCK THEM IN SOMEWHERE IN A CLOSET AWAY FROM ME_. Yes, I know these locked in virtues will be screaming to me that "the project is doomed without us", "it never will run", "nobody will like it" but I'll just ignore them... :-). Just merrily produce that vomit of Perl code. Could be an intresting experience. And likely to be a crime against all programming ethics ;-). /IllvilJa, on a brief visit on earth. Very brief though! Back to orbit! > > > Cheers, www.indiegamedesign.com > Brandon Van Every Seattle, WA > > Taking risk where others will not. > ===== (Jakob Ilves) <illvilja@yahoo.com> {http://www.geocities.com/illvilja} Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: Managing "Designers disgust". RE: cheating 2003-11-21 9:30 ` Managing "Designers disgust". cheating Jakob Ilves @ 2003-11-21 9:33 ` Brandon J. Van Every 2003-11-21 12:36 ` Jakob Ilves 0 siblings, 1 reply; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-21 9:33 UTC (permalink / raw) To: xconq From: Jakob Ilves [mailto:illvilja@yahoo.com] > > So, as a hobby hacker, by strongly handling future concerns > one gets a win ONLY if one has strong > immunity against the "designers disgust". That is, being > very (extremely?) patient and persistent. I had 9 months' worth. Then I broke. At least the code I wrote is solid - overengineered really. It'll be there for me when I resume a year from now. But man, what a lousy way to handle one's morale. > But what levels of patience is appropriate for a > project is pretty much dependant on > the people working on it, at least in the hobby programming > area. I think you have to provide exceedingly quick rewards to developers in any arena where they're not getting paid. > Some folks prefer to invest in > managing multiple future concerns simply because they can > afford it without running into > "designers disgust". They're patient enough. In such > environment, it's tough to make them change > their minds to shift more of their focus on today's fetures > because their current allocation of > work on between current and future concerns are working for _them_. "Masters of DOOM" by David Kushner is illustrative in this regard. John Carmack put his developers through *hell* as he was perfecting his engine. It was working for John's technological needs, it wasn't working for other people's game design needs, and it tore the company apart. > If one isn't that patience an extreme solution for a hobby > hacker can be to ignore future concerns > alltogether in order to speed up short term development. > That can lead to a horrible product > implementation which is rewritten over and over again but it > might on the other hand be written by > a very amused developer. > > For that "pentahexahepta" thing I've lately been considered > to do the latter. Take all virtues > like structured programmed, OO design, security and _LOCK > THEM IN SOMEWHERE IN A CLOSET AWAY FROM > ME_. Yeah, if you *can* succeed in barfing out code in this way, it's a good idea to do so. Any working scaffold, however heinous, is better than sitting around methodically planning without really cutting code. The risk of course is when the project does in fact require highly structural discipline to pull off. Some neato technologies, you can just pull out of your ass by shoveling them. Others, you really do have to sit down and be an Architect / Disciplinarian. I think Python is the right language for people who want to barf. It's a dynamically typed language, you don't get any more flexible than that! In contrast, people who do C++ tend to "wax architectural" and get sucked into optimizing their code. They end up missing the forest for the sake of the trees. It's a disease I've had as a 3D graphics optimization jock, and I've learned the very $$$$$ hard way to get away from it. I can't even fathom people willingly using plain C in 2003 without pay. That mentality is utterly alien to me, there are far better and more interesting programming tools available out there for free. Python is merely a common one that has nascent market momentum behind it. I think library, tools, community support, and proven real world use are all valuable, so that's why I champion it. > Just merrily produce that vomit of Perl code. Yes, Perl is also an appropriate vomit language. It's just that, I don't think you can turn Perl into non-vomit afterwards. But maybe Perl is a moving target that I'm just not up on. > Could be an intresting experience. And likely to be a crime > against all programming ethics ;-). There are no ethics, only tradeoffs. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: Managing "Designers disgust". RE: cheating 2003-11-21 9:33 ` Brandon J. Van Every @ 2003-11-21 12:36 ` Jakob Ilves 2003-11-21 14:28 ` Brandon J. Van Every 0 siblings, 1 reply; 49+ messages in thread From: Jakob Ilves @ 2003-11-21 12:36 UTC (permalink / raw) To: Brandon J. Van Every, xconq Hello again! (Xconq mailing list folks, if we are getting to chatty here, just tell us to slow down... The volume of traffic here has, well, peaked...) --- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev: > From: Jakob Ilves [mailto:illvilja@yahoo.com] > > > > So, as a hobby hacker, by strongly handling future concerns > > one gets a win ONLY if one has strong > > immunity against the "designers disgust". That is, being > > very (extremely?) patient and persistent. > > I had 9 months' worth. Then I broke. At least the code I wrote is > solid - overengineered really. It'll be there for me when I resume a > year from now. But man, what a lousy way to handle one's morale. Um, I don't consider your case to be viable for a "designers disgust" discussion. You've not run into this on as a hobbyist programmer. You've run into issues out on the disgusting battlefield known as "commercial game programming" and that's a completely different story. You did not take the risk of just getting a morale break or getting tired of your project. You took a major economical risk in an environment full of competitors and scavengers and bumped in a wall! I know people making (or trying to make) a living as artists, by making comics, by programming games, by making music etc. All that kind of creative stuff which is fun as a hobby but which I think is a mere nightmare as a life. All stories about scrupolous bastards ripping these people off, competitors stealing ideas. Imagine never knowing if the next months rent can be paid or not (yeah, income can be SCARCE). I'm impressed by you people (yes, you are included Brandon) because of the economical risk you CONSCIUSLY expose yourselves to. As long as I've got my two kids to think of, I would never do such a thing. (Who knows in 10 years though, Carl Barks was 40 when he started to draw his classical Donald Duck comics ;-) I just want to make it very clear that I never intended to compare the "designers disgust" of a hobbyist with the economical disasters professional artists, comic drawers, game programmers etc risk to experience. > > But what levels of patience is appropriate for a > > project is pretty much dependant on > > the people working on it, at least in the hobby programming > > area. > > I think you have to provide exceedingly quick rewards to developers in > any arena where they're not getting paid. Well, it depends. Sometimes volunteers appears who don't want to get quick rewards, they are just impressed of a project and have decided to contribute to it, sometimes taking on quite difficult tasks which DO take time to solve, especially in a hobby based open source project. But your right, if people have the patos in themselves, they NEED to be rewarded to work for free. Or, to get a rather quick "payback" by managing to add fairly quickly a feature to an open source product they need in their work. > > Some folks prefer to invest in > > managing multiple future concerns simply because they can > > afford it without running into > > "designers disgust". They're patient enough. In such > > environment, it's tough to make them change > > their minds to shift more of their focus on today's fetures > > because their current allocation of > > work on between current and future concerns are working for _them_. > > "Masters of DOOM" by David Kushner is illustrative in this regard. John > Carmack put his developers through *hell* as he was perfecting his > engine. It was working for John's technological needs, it wasn't > working for other people's game design needs, and it tore the company > apart. The open source ImageMagick was resently divided into two projects: ImageMagick and GraphicsMagick. I don't know if any situation with similarities with "hell" caused that split but there were different ideas in the group about where the project should lead so... A good example that open source project isn't immune in any way against some of the issues commercial projects/companies are facing from time to time. > > If one isn't that patience an extreme solution for a hobby > > hacker can be to ignore future concerns > > alltogether in order to speed up short term development. > > That can lead to a horrible product > > implementation which is rewritten over and over again but it > > might on the other hand be written by > > a very amused developer. > > > > For that "pentahexahepta" thing I've lately been considered > > to do the latter. Take all virtues > > like structured programmed, OO design, security and _LOCK > > THEM IN SOMEWHERE IN A CLOSET AWAY FROM > > ME_. > > Yeah, if you *can* succeed in barfing out code in this way, it's a good > idea to do so. Any working scaffold, however heinous, is better than > sitting around methodically planning without really cutting code. The > risk of course is when the project does in fact require highly > structural discipline to pull off. Some neato technologies, you can > just pull out of your ass by shoveling them. Others, you really do have Good news, that I know how to do! ;-) > to sit down and be an Architect / Disciplinarian. Argh. Why do I always end up with such tasks, why do I always want to do complex things? Or maybe I'm too stupid to even manage "shovel tasks" without architecture and discipline :-q. (Nothing is so easy that it cannot be darn impossible if being stupid enough ;-) > I think Python is the right language for people who want to barf. It's > a dynamically typed language, you don't get any more flexible than that! > In contrast, people who do C++ tend to "wax architectural" and get > sucked into optimizing their code. They end up missing the forest for > the sake of the trees. It's a disease I've had as a 3D graphics > optimization jock, and I've learned the very $$$$$ hard way to get away > from it. I know. I really enjoy being a pathological perfectionist. Bad news is that time never permits, I constantly have to do trade offs. The only good thing is that I'm usually aware of which corners I cut and what stuff it is that will get back to me later and bite me (and the latter happens...). > I can't even fathom people willingly using plain C in 2003 without pay. > That mentality is utterly alien to me, there are far better and more > interesting programming tools available out there for free. Python is > merely a common one that has nascent market momentum behind it. I think > library, tools, community support, and proven real world use are all > valuable, so that's why I champion it. Why use C anno 2003 for an open source project? That's an intresting question. A few reasons might make it a reasonable choice: Quick answer: performance and portability between platforms (C has been around for three decades so it's solid in that respect). Also, there are apperently some developers (including good ones writing good products) that don't consider OO to be that much valuable. (Don't ask me how they come to that conclusion, I am a OO fan). More elaborate answer: * Performance. By profiling a highlevel program in Python, Perl or Tcl and realizing a small chunk is doing 99% of the CPU usage, you can speed up things considerably by writing that chunk in C instead. This is how the open source Perl program MRTG (Multi Router Traffic Grapher) was speeded up by a factor 20. MRTG was initially 100% Perl but then a user submitted a small special purpose C program (called "rateup") to be included in the MRTG package. That program was used to replace the Perl code pieces responsible for writing and reading graph data on disk as well as generating the graph GIF images. By running those tasks by calling that external C program the performance boosted. The Perl code handling the polling of statistics and web page generations were left intact. * Stringent portability demands. The above mentioned "rateup" executable (being a part of MRTG) were later on spun into a stand alone product called RRDtool, usable for MRTG as a replacement for "rateup". RRDtool could of course be used in other statistics frameworks, not only MRTG (it can be used in Xconq to display statistical graphs for the game as it proceeds). That software is written in C for performance and I think one reason C were preferred over C++ was that the author wanted to make the program run on as many platforms as possible. C++ compiled with GNU g++ was percieved as being slightly less portable than C compiled with gnu gcc. I've heard that comment elsewhere as well, that some people considered C a more solid platform than C++ and I recall I found it surprising at the time. I was, until then, thinking everybody ought to "prefer" C++ over C in all circumstances but maybe that's a bit naive. Over the years, I've started to get the feeling that OO is a programming paradigm among many others, being justified at many places but problematic at some. For the curious, the two projects are here: http://www.mrtg.org, http://www.rrdtool.org. /IllvilJa ===== (Jakob Ilves) <illvilja@yahoo.com> {http://www.geocities.com/illvilja} Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: Managing "Designers disgust". RE: cheating 2003-11-21 12:36 ` Jakob Ilves @ 2003-11-21 14:28 ` Brandon J. Van Every 0 siblings, 0 replies; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-21 14:28 UTC (permalink / raw) To: xconq From: Jakob Ilves [mailto:illvilja@yahoo.com] > Brandon Van Every wrote: > > > > I had 9 months' worth. Then I broke. At least the code I wrote is > > solid - overengineered really. It'll be there for me when > I resume a > > year from now. But man, what a lousy way to handle one's morale. > > Um, I don't consider your case to be viable for a "designers > disgust" discussion. You've not run > into this on as a hobbyist programmer. You've run into > issues out on the disgusting battlefield > known as "commercial game programming" and that's a > completely different story. You did not take > the risk of just getting a morale break or getting tired of > your project. You took a major > economical risk in an environment full of competitors and > scavengers and bumped in a wall! It's not that different a story. I am a lone wolf indie game designer, with serious commercial intent. I've put my money where my mouth is, and I've lost a lot of money. The difference is just frame of attention span. Maybe my 9 months is like some hobbyist's 3 months or something. I am not sure. The question is, how much time do you spend before deciding something is beyond a PITA? > I know people making (or trying to make) a living as artists, > by making comics, by programming > games, by making music etc. All that kind of creative stuff > which is fun as a hobby but which I > think is a mere nightmare as a life. I wouldn't call it that. I'd call it a difficult learning curve not for the weak of stomach. Eventually I think certain types of people figure out how to swim through it, be productive, and be happy. But it takes aggressive process improvement and self-growth. Otherwise you do not make it, you never learn how to produce. > Imagine never knowing if the > next months rent can be paid or not > (yeah, income can be SCARCE). I am not imagining. When you go through these "pounding heart" scenarios often enough, you eventually realize that for someone who was so imminently doomed so many months ago, you're still very much alive. If anything, there's a danger in completely losing your fear of material consequences. > I'm impressed by you people > (yes, you are included Brandon) because > of the economical risk you CONSCIUSLY expose yourselves to. > As long as I've got my two kids to > think of, I would never do such a thing. You could probably take more risk than you allow yourself to think about, though. Something scaled appropriately to your situation. Most people do not face their fears of self-editing and self-censorship. It is worth facing them, because when you do, you discover that they go away. The time I was actually the most fearful was when I was best funded, right at the beginning! Because I didn't know anything. I was $20K in the positive and I didn't know how far the money would go. If I had the wisdom of hindsight, I would have done a whole lot of crazy, fun things because really I was safe as can be and didn't know it. > I just want to make it very clear that I never intended to > compare the "designers disgust" of a > hobbyist with the economical disasters professional artists, > comic drawers, game programmers etc > risk to experience. Well, I've probably run into what you're talking about anyways though. It certainly rings true enough. > > to sit down and be an Architect / Disciplinarian. > > Argh. Why do I always end up with such tasks, why do I > always want to do complex things? Or > maybe I'm too stupid to even manage "shovel tasks" without > architecture and discipline :-q. Probably because you haven't lost $60K+ over it. There are no consequences for you, so you never learn. Once you get burned, you realize that the goal of indie game development is to create something simple, get a website going, and start creating a revenue stream. *Then* deal with the magnum opus, *later*. Indeed, I want every project I work on to incrementally contribute a piece to the ultimate puzzle of Ocean Mars. I'm not giving up on hugely complicated works, but I know I do have to incrementally build components for them. Ship many small products to provide the infrastructure for 1 big product. > I know. I really enjoy being a pathological perfectionist. I did that for 11 years as a 3D graphics optimization jock. Finally, after losing enough money, I learned about missing the forest for the sake of the trees. Nowadays I know that if I'm working on ASM code, I have lost track of the goal. > Bad news is that time never permits, > I constantly have to do trade offs. So one of the tradeoffs is to use higher level garbage collected languages, such as Python. And forget about / shaft people who tell you there's some kidn of virtue in performing a lot of low level manual labor. To hell with them! You aren't a better person for RTFM all the day long about someone's stupid picky API or codebase. > Why use C anno 2003 for an open source project? That's an > intresting question. A few reasons > might make it a reasonable choice: > > Quick answer: performance Game programmers usually think they need tons of control and tons of performance, and on current computers, all that buys them is a sheer waste of time. For instance, consider Xconq. I think Stan said it's taking 98% of its time in the Tk pig layer? There's nothing you could possibly do to the C kernel to improve its performance, it's not the bottleneck. > and portability between platforms > (C has been around for three decades > so it's solid in that respect). Lots of programming languages are portable to the degree necessary for application purposes. It's nothing special about C. > Also, there are apperently > some developers (including good ones > writing good products) that don't consider OO to be that much > valuable. (Don't ask me how they > come to that conclusion, I am a OO fan). I write them off as old farts who like what they know and don't want to change. Maybe they have a better argument than that, but I know what the tangible productivity values of OO are, as does the vast majority of the computer industry by this late date. Most people cannot take "What's wrong with C??" guys seriously. We might agree that C++ ain't no treat, but C++ is not the only OO out there. > More elaborate answer: > > * Performance. By profiling a highlevel program in Python, > Perl or Tcl and realizing a small > chunk is doing 99% of the CPU usage, you can speed up things > considerably by writing that chunk in > C instead. But that's different. That's using C as glorified portable ASM for 1 teeny tiny routine. Not your main project development. C and ASM will always have their place. It's just that that place keeps getting smaller and smaller and smaller. I don't see that C has relevance to application development anymore, it's only the province of OS kernels and device drivers. *Really* low level stuff. > * Stringent portability demands. Not true of a game, or even most apps. Sounds again like a rather low level issue. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA "Desperation is the motherfucker of Invention." - Robert Prestridge ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: OT Python stuff (was RE: Python in Xconq) 2003-11-19 16:44 ` Bruno Boettcher 2003-11-19 17:58 ` Eric McDonald @ 2003-11-19 22:14 ` Brandon J. Van Every 2003-11-20 3:10 ` Erik Jessen 2 siblings, 0 replies; 49+ messages in thread From: Brandon J. Van Every @ 2003-11-19 22:14 UTC (permalink / raw) To: xconq Bruno Boettcher wrote: > > uhm perl-gtk, perl-tk? There is also Py + tk, pygtk, pySDL, pyKyra... basically Python has all those typical bindings too. Everyone is going to have their favorite language. If we can't settle on someone else's language, then we need interop capabilities. Which furthermore implies an architecture where that's possible / reasonable without pouring blood on the table. I think a major OO-ification of the code base needs to happen to make it usable / extensible to people who aren't intimately familiar with it already. We need an OO migration path. Nobody has the resources to swallow the problem all at once, there are hundreds and hundreds of functions to contend with. Eric McDonald wrote: > > (1) Richard mentioned to me yesterday that each additional piece > of external software that becomes an Xconq dependency is an > additional annoyance. If you build tkconq then you need Tcl/Tk, > and if you build sdlconq then you need SDL. Do we really want to > say that we also need Perl (which is fairly ubiquitous on Linux, > but not necessarily so on other platforms) or Python (which is > admittedly a nice language, but still not as widespread as Perl, > AFAICT)? If you are a developer, and there are docs on how to install all these packages, and they actually work, then you have no buisiness complaining. If you are a game player, then everything has to install as one big app, so that people don't have to chase it. Python has to be embedded, Perl has to be embedded, TCL has to be embedded.... Cheers, Brandon ^ permalink raw reply [flat|nested] 49+ messages in thread
* RE: OT Python stuff (was RE: Python in Xconq) 2003-11-19 16:44 ` Bruno Boettcher 2003-11-19 17:58 ` Eric McDonald 2003-11-19 22:14 ` OT Python stuff (was RE: Python in Xconq) Brandon J. Van Every @ 2003-11-20 3:10 ` Erik Jessen 2 siblings, 0 replies; 49+ messages in thread From: Erik Jessen @ 2003-11-20 3:10 UTC (permalink / raw) To: bboett, xconq7 Bruno, I'm trying to be flexible here - I personally know Perl, and it has lots of libs, but it's better to have any scripting language, than fight over which one is perfect (which is usually a religious war). Erik -----Original Message----- From: xconq7-owner@sources.redhat.com [mailto:xconq7-owner@sources.redhat.com] On Behalf Of Bruno Boettcher Sent: Wednesday, November 19, 2003 7:32 AM To: xconq7@sources.redhat.com Subject: Re: OT Python stuff (was RE: Python in Xconq) On Wed, Nov 19, 2003 at 07:14:26AM -0800, Erik Jessen wrote: > @files = Find(); yup :D :D > Seriously, any OO language is preferred (IMHO), because it will be more > maintainable (C++?). uhm uhm perl is gettin OO'ish ;) and its not the language that causes most problems but the programmers and their lack of discipline, that's why you get the impression that more restrictive languages are easier mantained, but its an impression.... i have a C++ project to take over and its utter horror.... a perfect example of commercially produced 'high efficiency' and 'professional' piece of software.... > And a scripting language is seriously preferred, because it will permit > so much more stuff. yah :D > If we add a scripting language, then I would submit that we write a > simple porting script to convert GDL to that language, and drop GDL. > IMHO, GDL is just a way to fill in data-structures, and any language can > do that. oh? that sounds like a nice idea? > A nice GUI-builder (anything well-known & portable like TCL) would be > very useful, because the scripting language could then create new popups > as needed, and if we're aiming for flexibility, then people who do > political games are going to have lots of popups saying "Country X has > proposed trading 3 steel, 4 oil and 5 herds of cattle, in return for a > peace treaty. > What is your answer?". uhm perl-gtk, perl-tk? -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Marketing Xconq? 2003-11-17 21:56 ` Marketing Xconq? Eric McDonald 2003-11-17 22:38 ` Brandon J. Van Every @ 2003-11-18 1:13 ` Dr Eric Edward Moore 2003-11-18 1:31 ` Eric McDonald 1 sibling, 1 reply; 49+ messages in thread From: Dr Eric Edward Moore @ 2003-11-18 1:13 UTC (permalink / raw) To: Eric McDonald; +Cc: Bill Macon, xconq7 Eric McDonald <mcdonald@phy.cmich.edu> writes: > Similarly, I think Xconq could benefit from a reinforcements > model, where forces simply appear at certain turns. Like the "appear" unit property? It's used in gettysburg.g -- Eric E. Moore ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Marketing Xconq? 2003-11-18 1:13 ` Marketing Xconq? Dr Eric Edward Moore @ 2003-11-18 1:31 ` Eric McDonald 2003-11-18 2:34 ` Lincoln Peters 0 siblings, 1 reply; 49+ messages in thread From: Eric McDonald @ 2003-11-18 1:31 UTC (permalink / raw) To: Dr Eric Edward Moore; +Cc: xconq7 Hello Eric, On Mon, 17 Nov 2003, Dr Eric Edward Moore wrote: > Eric McDonald <mcdonald@phy.cmich.edu> writes: > > > Similarly, I think Xconq could benefit from a reinforcements > > model, where forces simply appear at certain turns. > > Like the "appear" unit property? It's used in gettysburg.g Similar, but "appear" is a unit property, and not a unit-type property. When I wrote the above remark, I wasn't really thinking in terms of pre-built scenarios, but something more general, as an alternative (or complement) to creation/building. But, yes, I will concede that a reinforcements model does exist in the sense that you mention. Regards, Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Marketing Xconq? 2003-11-18 1:31 ` Eric McDonald @ 2003-11-18 2:34 ` Lincoln Peters 2003-11-18 3:11 ` Eric McDonald 0 siblings, 1 reply; 49+ messages in thread From: Lincoln Peters @ 2003-11-18 2:34 UTC (permalink / raw) To: Eric McDonald; +Cc: Xconq list On Mon, 2003-11-17 at 17:13, Eric McDonald wrote: > Hello Eric, > > On Mon, 17 Nov 2003, Dr Eric Edward Moore wrote: > > > Eric McDonald <mcdonald@phy.cmich.edu> writes: > > > > > Similarly, I think Xconq could benefit from a reinforcements > > > model, where forces simply appear at certain turns. > > > > Like the "appear" unit property? It's used in gettysburg.g > > Similar, but "appear" is a unit property, and not a unit-type > property. When I wrote the above remark, I wasn't really thinking > in terms of pre-built scenarios, but something more general, as an > alternative (or complement) to creation/building. But, yes, I will > concede that a reinforcements model does exist in the sense > that you mention. It sounds like you're talking about random units being created at random places on the map for random sides, although none of those are likely meant to be 100% random (e.g. it would be ridiculous for a nuclear bomb, owned by your opponent, to randomly appear next to *your* capital city!). I recall thinking that something like that might be interesting in bolodd.g: Every so often, an independent unit (perhaps goblins at low levels, with more powerful stuff as the game progresses) appears out of nowhere (but preferably in an area that nobody can see) and wreaks havoc with any non-independent units it can find. Of course, I don't expect anything like that to become possible until well after 7.5. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Marketing Xconq? 2003-11-18 2:34 ` Lincoln Peters @ 2003-11-18 3:11 ` Eric McDonald 0 siblings, 0 replies; 49+ messages in thread From: Eric McDonald @ 2003-11-18 3:11 UTC (permalink / raw) To: Lincoln Peters; +Cc: Xconq list Hi Lincoln, On Mon, 17 Nov 2003, Lincoln Peters wrote: > It sounds like you're talking about random units being created at random > places Possibly, if the game designer thought it would fit the game. > on the map for random sides For random sides? That's an interesting thought, though game balance could be unduly influenced in this manner. >, although none of those are likely > meant to be 100% random (e.g. it would be ridiculous for a nuclear bomb, > owned by your opponent, to randomly appear next to *your* capital > city!). I don't think I mentioned randomness. But now that you bring it up, I must say that it has possibilities.... :-) > I recall thinking that something like that might be interesting in > bolodd.g: Every so often, an independent unit (perhaps goblins at low > levels, with more powerful stuff as the game progresses) appears out of > nowhere (but preferably in an area that nobody can see) and wreaks havoc > with any non-independent units it can find. Yes, this is more like what I had in mind. But also I was thinking that one could design semi-specific scenarios with reinforcement zones (countries being a good candidate for these), where each side is _guaranteed_ to get certain forces at regular intervals, but without the designer needing to create each unit that can be brought in. And as I mentioned earlier, some form of regular production could (but need not) accompany reinforcements. Another possibility would be to reinforce based on territory held. This would go some way towards making a game such as Risk or Warlords (that Alan mentioned) more feasible on the Xconq engine. > Of course, I don't expect > anything like that to become possible until well after 7.5. Nor do I. To be honest, aside from possibly spiffing up the compound terrain effects that I put in awhile ago, I have entered a self-imposed feature freeze. My focus is on bug fixes, packaging, and documentation until 7.5 (are we shooting for a Dec 25th release date, Hans? :-) Regards, Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: New Interpreter (was RE: Marketing Xconq?)
@ 2003-11-19 12:28 Richard Hunt
2003-11-19 16:54 ` Eric McDonald
0 siblings, 1 reply; 49+ messages in thread
From: Richard Hunt @ 2003-11-19 12:28 UTC (permalink / raw)
To: xconq7
>Well, what platform are you on?
>If the platform is Linux or Solaris, then chances are >good that
>Tcl/Tk is already installed.
I am using Debian, but I am a bit anally retentive (how do you spell that :) so I do my installation entirely using dselect, which seems to avoid installing a lot of packages that I want. I tend to avoid tcl/tk programs simply because they tend to be slow on my old computer, and xconq is the only tcl/tk program I still want to run.
Another thing I just remembered: with the version that I am using (a CVS checkout from about a month ago, since I don't have internet access on my pc during term time) there is a config.cache file in the xconq directory which means that eg. the --tclconfigdir and ---tkconfigdir flags are ignored.
Richard Hunt, 0102806h@student.gla.ac.uk
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: New Interpreter (was RE: Marketing Xconq?) 2003-11-19 12:28 New Interpreter (was RE: Marketing Xconq?) Richard Hunt @ 2003-11-19 16:54 ` Eric McDonald 0 siblings, 0 replies; 49+ messages in thread From: Eric McDonald @ 2003-11-19 16:54 UTC (permalink / raw) To: Richard Hunt; +Cc: xconq7 On Wed, 19 Nov 2003, Richard Hunt wrote: > I am using Debian, but I am a bit anally retentive (how do you >spell that :) AR ;-) >so I do my installation entirely using dselect, >which seems to avoid installing a lot of packages that I want. I >tend to avoid tcl/tk programs simply because they tend to be slow >on my old computer, and xconq is the only tcl/tk program I still >want to run. I understand. Up until the beginning of last year, I was in the same situtation. Even now, I am very discriminating about what I install; I guess old habits die hard. > Another thing I just remembered: with the version that I am >using (a CVS checkout from about a month ago, since I don't have >internet access on my pc during term time) That is probably better for the grades (marks), I imagine. :-) >there is a >config.cache file in the xconq directory which means that eg. the >--tclconfigdir and ---tkconfigdir flags are ignored. Hmmm... That probably shouldn't be there. You should be able to do a "make distclean" to make it go away though. Or "rm". Eric ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2003-11-21 12:36 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-11-17 15:42 Marketing Xconq? Bill Macon 2003-11-17 18:55 ` Marketing Xconq? + battle isle suggestion Andreas Bringedal 2003-11-17 22:04 ` better Windows UI Brandon J. Van Every 2003-11-18 3:12 ` Erik Jessen 2003-11-17 21:56 ` Marketing Xconq? Eric McDonald 2003-11-17 22:38 ` Brandon J. Van Every 2003-11-18 3:15 ` Erik Jessen 2003-11-18 3:39 ` New Interpreter (was RE: Marketing Xconq?) Eric McDonald 2003-11-18 4:01 ` Erik Jessen 2003-11-18 4:05 ` Eric McDonald 2003-11-18 10:37 ` setgid (was: RE: New Interpreter (was RE: Marketing Xconq?)) Lincoln Peters 2003-11-18 15:52 ` Jim Kingdon 2003-11-18 5:17 ` Python in Xconq Brandon J. Van Every 2003-11-18 11:33 ` Erik Jessen 2003-11-18 13:37 ` OT Python stuff (was RE: Python in Xconq) Mark A. Flacy 2003-11-19 15:08 ` Erik Jessen 2003-11-19 16:44 ` Bruno Boettcher 2003-11-19 17:58 ` Eric McDonald 2003-11-19 21:18 ` GDL, XML and others...Re: " Jakob Ilves 2003-11-19 23:13 ` Brandon J. Van Every 2003-11-20 5:12 ` Eric McDonald 2003-11-20 8:54 ` Bruno Boettcher 2003-11-20 11:01 ` Jakob Ilves 2003-11-20 11:19 ` Brandon J. Van Every 2003-11-20 12:59 ` Jakob Ilves 2003-11-20 13:54 ` One Hex Combat Resolution, and jeweled teeth Brandon J. Van Every 2003-11-20 17:06 ` Eric E Moore 2003-11-20 17:37 ` Jakob Ilves 2003-11-20 17:47 ` Emmanuel Fritsch 2003-11-20 19:53 ` Eric E Moore 2003-11-21 2:16 ` Eric McDonald 2003-11-21 3:03 ` What is Python really good for? Brandon J. Van Every 2003-11-20 11:36 ` GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) Bruno Boettcher 2003-11-20 4:38 ` Erik Jessen 2003-11-20 10:19 ` cheating Brandon J. Van Every 2003-11-21 1:46 ` cheating Eric McDonald 2003-11-21 2:32 ` cheating Brandon J. Van Every 2003-11-21 9:30 ` Managing "Designers disgust". cheating Jakob Ilves 2003-11-21 9:33 ` Brandon J. Van Every 2003-11-21 12:36 ` Jakob Ilves 2003-11-21 14:28 ` Brandon J. Van Every 2003-11-19 22:14 ` OT Python stuff (was RE: Python in Xconq) Brandon J. Van Every 2003-11-20 3:10 ` Erik Jessen 2003-11-18 1:13 ` Marketing Xconq? Dr Eric Edward Moore 2003-11-18 1:31 ` Eric McDonald 2003-11-18 2:34 ` Lincoln Peters 2003-11-18 3:11 ` Eric McDonald 2003-11-19 12:28 New Interpreter (was RE: Marketing Xconq?) Richard Hunt 2003-11-19 16:54 ` 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).