Re: Marketing Xconq?

Re: Marketing Xconq?

[Bill Macon]

>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

Re: Marketing Xconq? + battle isle suggestion

[Andreas Bringedal]

>   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

better Windows UI

[Brandon J. Van Every]

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.

RE: better Windows UI

[Erik Jessen]

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.

Re: Marketing Xconq?

[Eric McDonald]

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

RE: Marketing Xconq?

[Brandon J. Van Every]

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.

RE: Marketing Xconq?

[Erik Jessen]

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.

New Interpreter (was RE: Marketing Xconq?)

[Eric McDonald]

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.

RE: New Interpreter (was RE: Marketing Xconq?)

[Erik Jessen]

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.

RE: New Interpreter (was RE: Marketing Xconq?)

[Eric McDonald]

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

setgid (was: RE: New Interpreter (was RE: Marketing Xconq?))

[Lincoln Peters]

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?

Re: setgid (was: RE: New Interpreter (was RE: Marketing Xconq?))

[Jim Kingdon]

> 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.

Python in Xconq

[Brandon J. Van Every]

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.

RE: Python in Xconq

[Erik Jessen]

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.

OT Python stuff (was RE: Python in Xconq)

[Mark A. Flacy]

>>>>> "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."

RE: OT Python stuff (was RE: Python in Xconq)

[Erik Jessen]

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."

Re: OT Python stuff (was RE: Python in Xconq)

[Bruno Boettcher]

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
===============================================================

Re: OT Python stuff (was RE: Python in Xconq)

[Eric McDonald]

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

GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Jakob Ilves]

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

RE: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Brandon J. Van Every]

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.

Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Eric McDonald]

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

Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Bruno Boettcher]

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
===============================================================

Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Jakob Ilves]

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

RE: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Brandon J. Van Every]

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.

RE: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Jakob Ilves]

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

One Hex Combat Resolution, and jeweled teeth

[Brandon J. Van Every]

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.

Re: One Hex Combat Resolution, and jeweled teeth

[Eric E Moore]

[-- 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 --]

Re: One Hex Combat Resolution, and jeweled teeth

[Jakob Ilves]

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

Re: One Hex Combat Resolution, and jeweled teeth

[Emmanuel Fritsch]

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

Re: One Hex Combat Resolution, and jeweled teeth

[Eric E Moore]

[-- 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

Re: One Hex Combat Resolution, and jeweled teeth

[Eric McDonald]

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

What is Python really good for?

[Brandon J. Van Every]

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.

Re: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq)

[Bruno Boettcher]

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
===============================================================

RE: OT Python stuff (was RE: Python in Xconq)

[Erik Jessen]

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

cheating

[Brandon J. Van Every]

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.

Re: cheating

[Eric McDonald]

> 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

RE: cheating

[Brandon J. Van Every]

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.

Managing "Designers disgust". RE: cheating

[Jakob Ilves]

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

RE: Managing "Designers disgust". RE: cheating

[Brandon J. Van Every]

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.

RE: Managing "Designers disgust". RE: cheating

[Jakob Ilves]

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

RE: Managing "Designers disgust". RE: cheating

[Brandon J. Van Every]

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

RE: OT Python stuff (was RE: Python in Xconq)

[Brandon J. Van Every]

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

RE: OT Python stuff (was RE: Python in Xconq)

[Erik Jessen]

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
===============================================================

Re: Marketing Xconq?

[Dr Eric Edward Moore]

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

Re: Marketing Xconq?

[Eric McDonald]

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

Re: Marketing Xconq?

[Lincoln Peters]

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.

Re: Marketing Xconq?

[Eric McDonald]

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