Xconq UI thoughts

Xconq UI thoughts

[Stan Shebs]

So many ideas flying around, I can hardly keep up! But here are some 
thoughts
based on having built a half-dozen separate UIs for Xconq over the 
years, and
having heard the player feedback.

1. Xconq should follow the prevailing trends in game interface design, 
and it
should be informed by the A-list games rather than the obscure ones. That
means custom interface design, not cookie-cutter-GUI-builder stuff. That's
the motivation for the SDL experiment; it's a cross-platform kit that has
been used for some high-quality commercial games.  The downside is that
you have to develop more widgets and create more artwork for them. Another
downside is that what is cool today will soon become dated.

2. Office apps are not fun. Multiple overlapping windows, floating palettes,
etc, all get a big "yechh" from players, and very few use them. (Developers
think they're cool, but do you want your audience to be game players or game
developers?)

3. Players are willing to tolerate less efficient interfaces if they are
entertaining to use. The standard video game preference panels are nasty
modal things, but developers dress them up with animation and sound effects,
and players are OK with that.

4. Players are not programmers; complicated automation features will
likely not be used. Players are perfectly happy to do repetitive actions
if they're being entertained while doing them.

5. Players hate to type; they would rather roll around a bunch of buttons
and popups than hit a single key on the keyboard. (Programmers love 
keyboards,
but see #4.)

6. All this applies to game design too. Only a handful of the most hardcore
want to write GDL, scripts, or whatever; that's as true of Quake as it is
of Xconq, Quake just has a much larger fan base from which to recruit the
hardcores.

Stan

RE: Xconq UI thoughts

[Brandon J. Van Every]

Stan Shebs wrote:
>
> 1. Xconq should follow the prevailing trends in game
> interface design, and it
> should be informed by the A-list games rather than the
> obscure ones.

"Should," but, there are the dictates of budget and doability.  Where's
your team of artists?  Your army of programmers to provide custom GUI
work?  Your project management infrastructure on par with something
like, say, the Nebula 3D engine?
http://nebuladevice.sourceforge.net/cgi-bin/twiki/view/Nebula/WebHome

AAA titles are into multi-million dollar budgets now.  You have to
implement a UI you can afford with volunteers.  If anybody knows of UI
that has been achieved by volunteers that have AAA production values,
great, show it to me.  We'll learn from whatever they did.  But I have
not seen it.  People generally reserve that level of polish for things
they intend to make a living from.

And not to state this unfairly, but there's a developer breeding
mechanism at work in such things.  People who really value AAA
production values, and who are capable of producing them, move on and
find a way to make those things in commercial products.  People who
don't, generally stay behind in hobbyist freeware projects like Xconq.
I'd love any pointers to specific exceptions that break the general
rule.  But from where I sit, the people with the drive and talent to
produce what you're suggesting, generally aren't available as volunteer
labor.

> 2. Office apps are not fun. Multiple overlapping windows,
> floating palettes,
> etc, all get a big "yechh" from players, and very few use
> them.

I agree totally.

> (Developers think they're cool,

Not all of 'em.  This one certainly doesn't.

> but do you want your audience to be game
> players or game developers?)

Actually, my personal agenda is what Xconq (or any suitable 4X TBS
platform) can do for *Game Designers* as an experimental medium.  I am
not primarily concerned with trying to reach as many players as
possible.  I want to reach many more players than Xconq currently does,
but I certainly wouldn't set myself up for AAA production values in
order to reach some mega-goal.  I will have long since returned to my
own proprietary efforts before that happens.  For me personally this is
about prototyping some game design ideas.

> 3. Players are willing to tolerate less efficient interfaces
> if they are
> entertaining to use. The standard video game preference
> panels are nasty
> modal things, but developers dress them up with animation and
> sound effects, and players are OK with that.

No, they are not all ok with that.  But again, I am circulating in game
designer circles such as http://groups.yahoo.com/group/gamedesign-l/ and
news://comp.games.development.design  My main agenda is that all the
mouseclicks and sloth has to die.

> 4. Players are not programmers; complicated automation features will
> likely not be used.

Thus, it is paramount to design simple ones.

> Players are perfectly happy to do repetitive actions
> if they're being entertained while doing them.

And the main problem with the 4X TBS genre, present incarnation of Xconq
included, is that *many* players are *not* entertained by all the
mindless gobbledygook they must slog through to finish a game.  As far
as I'm concerned, this is strong evidence that players are *not*
entertained by repetitive actions after a certain threshold.

> 5. Players hate to type; they would rather roll around a
> bunch of buttons
> and popups than hit a single key on the keyboard.

I agree.

> (Programmers love keyboards, but see #4.)

No, not all of them do.  I hate 'em.

> 6. All this applies to game design too. Only a handful of the
> most hardcore
> want to write GDL, scripts, or whatever; that's as true of
> Quake as it is
> of Xconq, Quake just has a much larger fan base from which to
> recruit the hardcores.

Yes, one has to be mindful of building lotsa technological
infrastructure on the premise that someone wants to use it.
Infrastructure should be built for people who are *actually* using it,
as they actually *need* it.  If you run around trying to provide general
purpose capabilities, you will never produce any content and you will
eventually get bored.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: Xconq UI thoughts

[Eric McDonald]

> And not to state this unfairly, but there's a developer breeding
> mechanism at work in such things.  People who really value AAA
> production values, and who are capable of producing them, move on and
> find a way to make those things in commercial products.  People who
> don't, generally stay behind in hobbyist freeware projects like Xconq.
> I'd love any pointers to specific exceptions that break the general
> rule.  But from where I sit, the people with the drive and talent to
> produce what you're suggesting, generally aren't available as volunteer
> labor.

Of course this totally overlooks the segment of developers that 
have both the drive and the talent, but have made other career 
choices that they find more fulfilling, __who simply work on a 
project as a hobby in their meager free time.

> > (Programmers love keyboards, but see #4.)
> 
> No, not all of them do.  I hate 'em.

This explains much....

> Infrastructure should be built for people who are *actually* using it,
> as they actually *need* it.

Could it be?! He _finally_ gets it! Now he understands why there 
was no red carpet and royal fanfare waiting for him wrt the 
Windows build process. Amazing, he _finally_ gets it....

growth agendas and OO

[Brandon J. Van Every]

Eric McDonald wrote:
>
> Of course this totally overlooks the segment of developers that
> have both the drive and the talent, but have made other career
> choices that they find more fulfilling, __who simply work on a
> project as a hobby in their meager free time.

Yes, I suppose that is true.  But the proof is in the pudding, right?
Like I said, show me the freeware projects with the AAA production
values.  I've never seen one, and I suspect they're few and far between
if they exist at all.  It matters naught if someone actually has the
talent to produce all the eye candy, if instead they apply their
hobbyist talents to AI code.  Priorities are priorities, time outlays
are time outlays.

> > Infrastructure should be built for people who are
> > *actually* using it, as they actually *need* it.
>
> Could it be?! He _finally_ gets it! Now he understands why there
> was no red carpet and royal fanfare waiting for him wrt the
> Windows build process. Amazing, he _finally_ gets it....

Do you understand why Xconq won't get any bigger without certain
infrastructural layouts?  This is quite late in technological history to
be doing C code.  But... some have a growth agenda, and others don't.

If you want to see a project with a real growth agenda, check out
http://nebuladevice.sourceforge.net/cgi-bin/twiki/view/Nebula/WebHome
That's project management for growth.  Now admittedly, it's not a fair
comparision.  There's a company still driving a lot of Nebula's
development, even though they license the engine BSD style.  But the
point is, you get external investments in proportion to how easy you
make it for others to join your project and contribute to it.

I am willing to contribute to the OO-ification of Xconq, if you want to
pursue that agenda.  If you think that agenda is misguided, then it's
best to find out now.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: growth agendas and OO

[Bruno Boettcher]

On Thu, Nov 20, 2003 at 01:43:52AM -0800, Brandon J. Van Every wrote:
> I am willing to contribute to the OO-ification of Xconq, if you want to
> pursue that agenda.  If you think that agenda is misguided, then it's
> best to find out now.
wasn't there allready someone slowly pushing into that direction? the
first step was to get xconq compiled with g++, AFAIK we are at this
step..

so maybe we need a design phase here which reorganizes the sources? 

as i told Eric prvately, indeed if we had a simple to understand OO
model of xconq i would be willing to add a CORBA layer to it, for
(remote) connections (from remote UI's over xconq-servers to distributed
ai connections...) even if its in C++ :D

but i fear migrating xconq to OO will be quite some work.... 

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

RE: growth agendas and OO

[Brandon J. Van Every]

Bruno Boettcher wrote:
>
> wasn't there allready someone slowly pushing into that direction? the
> first step was to get xconq compiled with g++, AFAIK we are at this
> step..

Apparently so.

> so maybe we need a design phase here which reorganizes the sources?

We do not, I repeat, *not* want to do this top-down all at one go.
Rather, we need a migration path.  We want an incremental, hodgepodge,
piece here, piece there approach.  That's what's appropriate for the
volunteer labor actually available to Xconq.  A hodgepodge OO approach
may sound bad, but it's better than Xconq's current C code.  The C code
is actually not totally far off from OO, it's just too flat.
Improvement is the point, not creating tons of work that has no fungible
value to anyone.  Also, incremental testing is the point.  You cannot
move a big system like Xconq over to something else all at once.

Once Xconq has done "hodgepodge OO" for awhile, it may become feasible
to turn it into "highly structured OO."  Also, more ambitious
improvements become possible.  For instance, it is really not feasible
or sane for most people to attempt new GUIs with the code being the way
it is.  Some OO paradigm simplifications are necessary first.

In short, there really is nothing to argue about as to what the
structure of the OO should be.  Rather, pick an OO language tool, and
start OOing some minor things, with the hope of that leading to major
things.  I'm picking Python.  Others could pick C++ if they like that,
or some other language if they're terribly motivated.  Then it becomes a
matter of who actually codes, who actually uses the language tools.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

RE: growth agendas and OO

[Jakob Ilves]

Hello planet Earth!

 --- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev: > Bruno Boettcher wrote:
> >
> > wasn't there allready someone slowly pushing into that direction? the
> > first step was to get xconq compiled with g++, AFAIK we are at this
> > step..
> 
> Apparently so.
> 
> > so maybe we need a design phase here which reorganizes the sources?
> 
> We do not, I repeat, *not* want to do this top-down all at one go.
> Rather, we need a migration path.  We want an incremental, hodgepodge,
> piece here, piece there approach.  That's what's appropriate for the
> volunteer labor actually available to Xconq.  A hodgepodge OO approach
> may sound bad, but it's better than Xconq's current C code.  The C code
> is actually not totally far off from OO, it's just too flat.
> Improvement is the point, not creating tons of work that has no fungible
> value to anyone.  Also, incremental testing is the point.  You cannot
> move a big system like Xconq over to something else all at once.

Absolutely!

(Hodgepodge being offered?  That sounds delicious, maybe I should consider returning to earth!)

This is a very good way of developing, introducing (and needing to kill) just one bug (if any) for
every step.  Sure, one can do large chunks and exterminate all those bugs all at once but they can
become awfully persistent if they gang up against the poor developer.  They are far nicer to
eliminate one at a time (trust me, I've used both approaches ;-).

Given that Xconq is rather large, a good test suite would be most useful.  That way the developer
can reasonably quickly check if the last step in the development caused an bug or not.

Multiple migration paths could be nice, that way one developer can turn one piece into OO on
his/her box while othes deals with other pieces.  Then both check in their pieces into the
development CVS.  Yes, coordination will be needed among parallell OO migraters so their changes
don't happen to clash (for example, check out the entire current CVS source and do a run against
test suite in order to identify any incompatible OO migration pieces checked in).

Having one developer alone doing the OO work probably is a bad idea, IMHO.  That person will be a
bottleneck for the project and the risk is big that the person get's fed up with the task or even
worse, what must not happens do indeed happen: that the developer no longer find it fun to develop
Xconq.

> Once Xconq has done "hodgepodge OO" for awhile, it may become feasible
> to turn it into "highly structured OO."  Also, more ambitious
> improvements become possible.  For instance, it is really not feasible
> or sane for most people to attempt new GUIs with the code being the way
> it is.  Some OO paradigm simplifications are necessary first.

> In short, there really is nothing to argue about as to what the
> structure of the OO should be.  Rather, pick an OO language tool, and
> start OOing some minor things, with the hope of that leading to major
> things.  I'm picking Python.  Others could pick C++ if they like that,
> or some other language if they're terribly motivated.  Then it becomes a
> matter of who actually codes, who actually uses the language tools.

Um... Java?  Using the Apache Batik SVG for the graphics?  With XGDL for defining games and with
Javascript for snippets in the game definition code.  What a fantasy!

Seriously, Java have advantages but I don't see any way of incrementally migrating Xconq to Java
from C.  Too bad, but such a monolithic migration would likely be suicide.  C++ could be a choice,
or at least an intermediate step.  Once the OO is there, be it "hodgepodge" or "highly structured"
flavor, it would be a less painful suicide to do a migration, all at once, to say Java or some
other language.

For an excersice in utter programming perversion (which is fun at times ;-), we can go for Perl
and Perl-tk.

> Cheers,                     www.indiegamedesign.com
> Brandon Van Every           Seattle, WA
> 
> Taking risk where others will not.

/IllvilJa  (still in orbit ;-)

Having fun where others will not ;-)  (Sorry could not resist that one).



=====
(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: growth agendas and OO

[Brandon J. Van Every]

From: Jakob Ilves [mailto:illvilja@yahoo.com]
>
> (Hodgepodge being offered?  That sounds delicious, maybe I
> should consider returning to earth!)

We serve 'em fresh 'n' tasty.  Of course if you've seen "Spirited Away,"
you know what happens when you eat too many of them!

> Having one developer alone doing the OO work probably is a
> bad idea, IMHO.  That person will be a
> bottleneck for the project and the risk is big that the
> person get's fed up with the task or even
> worse, what must not happens do indeed happen: that the
> developer no longer find it fun to develop
> Xconq.

Yes, having only one guy do OO is not a realistic way for migration to
proceed.  The OO paradigm has to be accepted and used by a lot of
people.  I am hoping that by embedding Python into Xconq, and showing
people how it can be used, people will become willing to use it for
various tasks.  Eventually people become "sold" and "hooked" on Python.

> /IllvilJa  (still in orbit ;-)
>
> Having fun where others will not ;-)  (Sorry could not resist
> that one).

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: growth agendas and OO

[Jim Kingdon]

> Given that Xconq is rather large, a good test suite would be most
> useful.  That way the developer can reasonably quickly check if the
> last step in the development caused an bug or not.

If you think of a test suite big enough to detect most bugs throughout
xconq, it gets really scary.

But the good news is that test suites are fairly easy to write one
test at a time (starting with the code you are about to tear apart or
feature you are about to add, for example).

I've written a few tests, but more contributions are welcome.  Here's
the section I just wrote for the hacking manual.  Running the tests
(or at least autotests) as described here would be a good first step
for someone thinking of helping out in the testing area.

    There are a variety of tests, some more automated than others.
    Running `make check' gets you all of them.  Warning: some of them take
    a very long time to run.  Generally speaking most of the tests should
    be interpreted to fail if xconq dumps core, and succeed in most other
    cases (some error messages might be considered failures).

    Perhaps the most interesting tests are the autotests.  These are
    written in a unit test style, meaning that the test code links into
    the code under test, which is good for speed and makes it easy to test
    particular parts of the code rather than end-to-end behaviors.  They
    should run fast enough to run them every time you make a change to
    xconq.

       To run just the autotests:

	 $ cd kernel
	 $ make skelconq
	 $ cd ../test
	 $ make check-auto

Re: growth agendas and OO

[Eric McDonald]

On Thu, 20 Nov 2003, Brandon J. Van Every wrote:

> Do you understand why Xconq won't get any bigger without certain
> infrastructural layouts?  

The C infrastructure is pretty good (as Peter points out in a 
later message); in fact, it is good enough that Xconq has gained 2 
developers in the past 5 months. Not bad....

As far as building the game goes (since that is actually the 
question at hand), the answer is: sure, it would be nice to have 
some additional infrastructure. You seem to have this "me vs. 
them" mentality though. When I suggested that _you_ could 
contribute your VS project, you became rather defensive, thinking 
that I somehow doubted your efforts. It would be nice if you would 
understand that, within the open source community, there is a kind 
of "altruism", that if you accomplish something positive then you 
share it with others.

I didn't build this particular piece of infrastructure because I 
didn't *need* it.

>But... some have a growth agenda, and others don't.

I have a personal growth agenda for Xconq. It goes something like 
this:
  Pre-7.5:
    (1) Fix all known stability issues and crashing bugs.
    (2) Verify documentation correctness and add more exposition 
where necessary. Possibly spiff up the HTML version of the 
manuals.
    (3) Make sure that all the test cases pass muster. Possibly 
enhance the testing system. (Although the normal use of skelconq 
is to be invoked with arguments, it should probably not assume 
that this is the case, as you pointed out and as I also noticed 
some time ago.)
  Post-7.5/Pre-7.6:
    (1) Make a badass AI.
    (2) Do some work with the tasking/planning system (related to 
AI work, but some make-user-life-easier things also).
    (3) Possibly extend GDL.
    (4) Possibly extend the standing orders syntax.
    (5) Possibly work on SDL/? interface.

> I am willing to contribute to the OO-ification of Xconq, if you want to
> pursue that agenda.  If you think that agenda is misguided, then it's
> best to find out now.

I don't think that this is necessarily misguided in the long term. 
But the C infrastructure works pretty darn good at present. We 
even have some "polymorphism" due to nifty macro magic....

Xconq currently attempts to be at a C89 compliance level to make 
sure that we are supporting as many platforms as possible. If you 
say that we should just ditch those platforms, then you are simply 
stating an opinion which is not even all that pragmatic.  I 
actually did put out a feeler a while ago, to see about moving the 
compliance level to C99; the conclusion I reached is that the 
time is not right yet.

Eric

Re: growth agendas and OO

[Eric McDonald]

Ooops, forgot one agenda item that I've been mulling the last 
couple of months:

On Thu, 20 Nov 2003, Eric McDonald wrote:

> I have a personal growth agenda for Xconq. It goes something like 
> this:
>   Pre-7.5:
>     (1) Fix all known stability issues and crashing bugs.
>     (2) Verify documentation correctness and add more exposition 
> where necessary. Possibly spiff up the HTML version of the 
> manuals.
>     (3) Make sure that all the test cases pass muster. Possibly 
> enhance the testing system. (Although the normal use of skelconq 
> is to be invoked with arguments, it should probably not assume 
> that this is the case, as you pointed out and as I also noticed 
> some time ago.)
>   Post-7.5/Pre-7.6:
>     (1) Make a badass AI.
>     (2) Do some work with the tasking/planning system (related to 
> AI work, but some make-user-life-easier things also).
>     (3) Possibly extend GDL.
>     (4) Possibly extend the standing orders syntax.
>     (5) Possibly work on SDL/? interface.
     (6) Possibly modularize the combat system, and then recast 
models 0 and 1 in terms of the modular system by setting the 
appropriate combat behavior flags.

Eric

altruistic VS 2003 Solution files

[Brandon J. Van Every]

Eric McDonald wrote:
>
> When I suggested that _you_ could
> contribute your VS project, you became rather defensive, thinking
> that I somehow doubted your efforts.

No, I went through a triage of why you would possibly bother to phrase
your question as you did.  I eneumerated the possibilities:

- you didn't believe I had created VS 2003 Solution files
- you didn't approve of VS 2003 Solution files
- you were worried that I might have done them badly

All 3 ended up with the same result: why bother to ask the question as
you did?  The proper question would have beem more like, "Could you
please .ZIP up your VS 2003 files so we can stick 'em into the source
pool?"  Or, "are they ready for the source pool yet?"  And I answered
that: no, they're only 95% complete.

> It would be nice if you would
> understand that, within the open source community, there is a kind
> of "altruism", that if you accomplish something positive then you
> share it with others.

Which has nothing to do with the question you asked.  I had already
built the VS 2003 Solution files.  My altruism is not at issue; you may
want to make it an issue, but it is misguided of you to do so.

It's like, you never really got the idea that amidst all the screaming
and gnashing of teeth, and us getting on each other's nerves, that I was
actually building things for Xconq.  I think that's because you were
tuning out my various status messages like "I've got the Tk client built
now," "Hey! I've got the SDL client built now."  Why did you think I
wrote those things, to lie to you and say "4A! 4A!  Read it and w33p
loz3rz, I'm not giving you didly doo!" ??  Sometimes I think you are
used to working with a very low class of people in hack3rz forums,
because you seem to have these paranoid ideas about what my motives are,
when I'm always pretty blunt and clear about my motives.

Anyways, you need to accept that there's altruism, then there's
difference of personal style, and finally there's unviability.  I am
only interested in the intersection of our common agendas.  I'm not here
to just give freely, I give because there are things I want to get in
return.  For instance, migrating a C codebase and getting lotsa happy
novice Python programmers / game designers jammin' on Xconq is of direct
career benefit to me.  If successful, not only would I enhance my
stature as an Indie Game Designer / Programmer, but I can consult that
skill for big bucks.  The technical term for that is a Win-Win
Situation.

Of course that's a best case, and I'm a gambler.  If I embed Python and
nobody uses it because of developer climate and people's energies, at
least I will know some things about how efforts fail.

Other issues you raised are sold separately.  :-)


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: altruistic VS 2003 Solution files

[Eric McDonald]

OK, you managed to troll me once again.

On Thu, 20 Nov 2003, Brandon J. Van Every wrote:

> - you didn't believe I had created VS 2003 Solution files

No, I believed you. I just couldn't believe how long it took you.

> - you didn't approve of VS 2003 Solution files

No. If you think that I am close-minded or dogmatic in that 
regard, you really haven't learned anything about me. (Though that 
doesn't surprise me, since you don't really listen.)

> - you were worried that I might have done them badly

This is a possibility, one which can't be ruled out unless they 
see the light of day.

> you did?  The proper question would have beem more like, "Could you
> please .ZIP up your VS 2003 files so we can stick 'em into the source
> pool?"  

As if I would ever type that....
There is no way I would beg or prod you for something that is of 
uncertain quality or value. I simply suggested that you could 
try to contribute something to the Xconq project. You are a wee 
bit paranoid if you are reading anything more into what I said.

> Which has nothing to do with the question you asked.  I had already
> built the VS 2003 Solution files.  My altruism is not at issue; you may
> want to make it an issue, but it is misguided of you to do so.

I have no intention of making it an issue. You make it an issue 
almost every time you send an email to this list. Your attitude 
and motives speak for themselves just fine without my help.

> actually building things for Xconq.  I think that's because you were
> tuning out my various status messages like "I've got the Tk client built

Tuning out, no. ROFL, yes.

There is a lesson that I learned from this though. I should keep a 
page of gold stars to hand out for the next time some egomaniac 
starts blowing such gas all over the place. "Look, mommy! Look 
what _I_ did today."  Jeeezus. Grow up.

> loz3rz, I'm not giving you didly doo!" ??  Sometimes I think you are
> used to working with a very low class of people in hack3rz forums,

Nope. You're about the lowest I've gone.

Eric

So let's get right to the point

[Brandon J. Van Every]

Eric McDonald wrote:
> Brandon Van Every wrote:
>
> > Sometimes I think you are used to working with a very
> > low class of people in hack3rz forums,
>
> Nope. You're about the lowest I've gone.

I see, Eric.  I'm not going to retract my apology to you, I've
apologized for what I should have.  But it's clear that you have never
been interested in moving on.  You basically don't accept the
differences of style between us.  That might change years from now, but
it won't change in any timeframe that matters to present ventures.

So let's get right to the point.  How many things that I propose, are
you going to obstruct out of your need for personal animosity?  I think
it's best that you make the list now.  That way, we don't have to waste
time with people talking about it, me implementing it, and you blocking
it.  State your turf, the things you certainly aren't going to give
ground on.

We'll make this partly a multiple choice test.

1. Python required in the kernel
a) yeah, that's awesome!
b) hell no.  Go away.

2. Kicking 7.5 out the door so that new features can be added
a) yeah, any week now!
b) I want my months before you even think about touching my source pool.

3. Recruiting a horde of Windows C# .NET developers
a) the more the merrier!
b) get out of here you Micro$quish suckup bastard

And, these are questions I expect firm answers to.  The number of (a)
answers determines whether Xconq is a good use of my time.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: So let's get right to the point

[Lincoln Peters]

On Thu, 2003-11-20 at 23:09, Brandon J. Van Every wrote:
> So let's get right to the point.  How many things that I propose, are
> you going to obstruct out of your need for personal animosity?  I think
> it's best that you make the list now.  That way, we don't have to waste
> time with people talking about it, me implementing it, and you blocking
> it.  State your turf, the things you certainly aren't going to give
> ground on.

I had hoped that this arguing would be over by now, but you both still
seem to get on each other's nerves.  I'm not sure why.

I'm not going to try to take sides, but I will try to answer some of
these questions (although none of them make good multiple-choice
questions).

> 
> We'll make this partly a multiple choice test.
> 
> 1. Python required in the kernel
> a) yeah, that's awesome!
> b) hell no.  Go away.

I don't think Python is required, but Python would make it easier to do
things that are difficult or impossible right now (which have already
been discussed over the last few days).  And it might improve Xconq in
ways that we can't predict now.

The catch is that none of us want to add Python support to Xconq until
other bugs are fixed (see #2).  No matter how many cool things a game is
supposed to be able to do, nobody will play it if it doesn't work.

> 
> 2. Kicking 7.5 out the door so that new features can be added
> a) yeah, any week now!
> b) I want my months before you even think about touching my source pool.

I think that it's quite clear that we all want to fix as many bugs as
possible before releasing 7.5.  Although it seems that we're getting
close.

Remember, open-source projects (usually) do not have marketing people
screaming at them.  Xconq 7.5 will be released when it is ready, and not
a moment before.  A lot of software companies (especially Microsoft)
could have saved themselves a lot of trouble by working this way.

I don't think that anyone is worried about you "touching our source
pool" beyond that you might introduce something that has unexpected
results.  That's why anyone with CVS access tests a piece of code as
thoroughly as possible before committing it.

> 
> 3. Recruiting a horde of Windows C# .NET developers
> a) the more the merrier!
> b) get out of here you Micro$quish suckup bastard

"Micro$quish?"  That's a new one.

I originally brought up Mono because I thought that it would make it
easier to add components to Xconq in languages other than C.  Although I
suppose that it would make it possible to add lots of new features to
the Windows version, I would be reluctant to add anything that would not
work on all Xconq platforms.  For example, I would be willing to add
code to Xconq that would let it talk to MS Excel, but only if it was
possible to do the same thing with at least one other spreadsheet
application (e.g. Gnumeric) on other operating systems (e.g. Linux).

My interest in Mono has nothing to do with its cross-platform nature,
although it is a feature that could save us a lot of effort in the long
run.  If Microsoft pulled the plug on Ximian, Mono would not lose any of
the features I originally pointed out.  And I would expect it to be
possible to maintain a separate implementations for Mono and .NET in a
similar way to how we maintain separate interfaces now.

Getting back to your question, if a horde of Windows C# .NET developers
could make a contribution to Xconq without causing problems in the UNIX
and MacOS versions of Xconq, I'd be inclined to welcome them.

> 
> And, these are questions I expect firm answers to.  The number of (a)
> answers determines whether Xconq is a good use of my time.

Are the answers I provided firm enough?


By the way, I think that it would be worth looking your VS 2003 Solution
files.  I'll assume that they work reasonably well, as I doubt you would
have said anything if they didn't work.  Although that doesn't mean that
we shouldn't test them before committing them to CVS.

Is there anyone else on this list who has VS 2003 and would be willing
to take a look at the files?

Why Eric doesn't like my personal style

[Brandon J. Van Every]

Lincoln Peters wrote:
>
> I had hoped that this arguing would be over by now, but you both still
> seem to get on each other's nerves.  I'm not sure why.

It is a simple matter.  Eric does not like my personal style, he thinks
I'm an arrogant SOB.  He is somewhat correct, and I'm not going to
change how I do business for him.  His options are to get over it and
accept that people with different personal styles can accomplish
different things for an organization, or we will go our separate ways.

I don't really have a problem with Eric, which is what's interesting
about this situation.  Eric has a problem with me.

If you want a deeper psycho-managerial explanation, you will find it
reading
http://www.teams.org.uk/shaper.htm .  I am a Shaper.  Not sure what Eric
is, although I have some guesses and he's definitely not a Shaper.


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.

Why Eric doesn't like my personal style

[Mark A. Flacy]

>>>>> "Brandon" == Brandon J Van Every <vanevery@indiegamedesign.com> writes:
Brandon> 
Brandon> It is a simple matter.  Eric does not like my personal style, 

Neither do I.

Brandon> he thinks I'm an arrogant SOB.  

I also believe that you are an arrogant SOB.  

Brandon> He is somewhat correct, and I'm not going to change how I do
Brandon> business for him.

No doubt that's the secret to your success.


Brandon> His options are to get over it and accept that people with
Brandon> different personal styles can accomplish different things for an
Brandon> organization, or we will go our separate ways.

Please find something else to do or simply DO something and shut the fuck
up about it.


-- 
 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!
"Be flattered when I assume ignorance. It's more complimentary than
 the alternative." -- Jerry Avins

RE: Why Eric doesn't like my personal style

[Brandon J. Van Every]

Mark A. Flacy wrote:
>
> Brandon> He is somewhat correct, and I'm not going to change how I do
> Brandon> business for him.
>
> No doubt that's the secret to your success.

Do you want to define "success?"  You're working on a hobby project with
a small number of developers.  What do you know about "success" in game
development?  You some kind of principal at a well-known and
well-respected game company, just moonlighting here?

> Please find something else to do or simply DO something and
> shut the fuck up about it.

Well, it is true that I am looking around for codebases where I don't
actually have to convert people about what to do.  That are in better
shape from an OO and higher level functionality / make major changes
standpoint.  People like you make it easier not to worry about
"generosity" as one of the factors.  It's as though you think people
should just gladly do things for Xconq, without regard for basics like:

- whether anyone would actually use, desire, or test the Python code.

- whether it would actually get checked into CVS in any timeframe of
relevance to me.

Without even these basics, why would anyone with my priorities develop
anything for you?  Nevermind all the flat C code.  Sure it works, but in
2003 it's not an attractive development platform.  You know this; the
question is whether you have any energy to change it, or if you're
satisfied that "it's working for you."  If it works for you I don't
begrudge you that fact.  But it doesn't work for me, nor a lot of other
OO developers out there.  We simply couldn't do the things we want to do
in Xconq without changes to the infrastructure.  We are disinclined to
write major, painful buckets of C code.

FWIW the conversation with the Freeciv guys has been nicer, because I
had already gone over the personality land mines here and I didn't feel
the need to repeat them there.  I never expected the Freeciv guys to
change their ways, so I didn't set it as a goal to try.  Rather, I
thought I'd check to see if I might be pleasantly surprised, and I'd try
to understand something about why C coders stick to their guns.  Turns
out someone did do some Python once upon a time, and it fell by the
wayside.  Guess if you build it, people don't come eh?

Since you've seconded Eric's attitude, I'm outta here.  Some of you will
be glad; I'm glad, because at least it's a resolution.  What I've
learned from this experience, is team dynamics (or lack thereof) is as
important a factor as anything else.  Some kinds of people, with some
kinds of priorities, I simply cannot work with no matter how many
appeals to altruism or freeware do-goodery people might try to hide the
problems in.  What it gets down to, is you have your agenda, I have
mine.

"Thanks," at least, for helping me to clarify my agenda.  I'm pretty
clear on what it is now, this has been a good exercise for me, if not
for you.  And hey, you got VS 2003 files out of the deal, I've paid my
bar tab.  Next move is I'll either find a project that intersects with
my agenda, or I'll start my own.  Maybe I'll ping you guys about what
happens at some point.  Some of your lurkers I think would actually
prefer to work on something ala Python.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

RE: So let's get right to the point

[Brandon J. Van Every]

Lincoln Peters wrote:
>
> I'm not going to try to take sides, but I will try to answer some of
> these questions

Lincoln, thank you for taking the time.

> (although none of them make good multiple-choice questions).

It's a better multiple choice quiz than you might at first think.  I'm
laying out some requirements for me to do certain things.  But, I'm open
to the possibility that some of my requirements may be overly narrow.
If people have a way of addressing my concerns, I'll listen to them.

> > 1. Python required in the kernel
> > a) yeah, that's awesome!
> > b) hell no.  Go away.
>
> I don't think Python is required,

If I am to do "hodgepodge OO migration" for/with you guys, it is
required.  And it must be in kernel.  "It's not required" is synonymous
with "thanks for offering, Brandon, but we're not ready to move on
this."  If I do the work, it has to be in my preferred language, and it
has to be forcibly stress tested by anyone who runs Xconq.  I see no way
to achieve these 2 objectives other than "it is required."

I am not excluding the possibility of interop solutions with other
languages.  I am saying, if I am working, there will be Python and it
will be required for Xconq's operation.  Others might make similar,
reasonable demands regarding C++, Perl, or whatever.  But equally, they
will need to provide the interop solution.

> but Python would make it easier to do
> things that are difficult or impossible right now (which have already
> been discussed over the last few days).  And it might improve Xconq in
> ways that we can't predict now.

Yes, I agree there are many benefits to Python.  I think it will be an
easy sell once you have example code doing something in kernel.

> > 2. Kicking 7.5 out the door so that new features can be added
> > a) yeah, any week now!
> > b) I want my months before you even think about touching my
> source pool.
>
> I think that it's quite clear that we all want to fix as many bugs as
> possible before releasing 7.5.  Although it seems that we're getting
> close.

Well, here's the rub.  What's your timeframe?  I'm a businessman, and
I'm not interested in waiting.  Certainly not in waiting indefinitely
for when someone "might" kick 7.5 out the door.  For me it's
unacceptable to have a bottleneck like that in my critical path.  If
you're going to Do something, you Do it.

Are you amenable to forking the source?  A stable bugfix release, vs. a
next-generation-let's-get-started release?  It's what people often do to
overcome this sort of problem.

> Remember, open-source projects (usually) do not have marketing people
> screaming at them.  Xconq 7.5 will be released when it is
> ready, and not a moment before.

If that's your shipping culture, we won't be able to conduct business.
It's not aggressive enough for a comercially-oriented developer such as
myself.  Also, it doesn't inspire people or keep the project growing.
What I've been hearing is that people would like to see some of these
Python features, but I doubt anybody's getting excited about waiting
until 6 months from now to see them.

> A lot of software companies (especially Microsoft)
> could have saved themselves a lot of trouble by working this way.

You've gotta be kidding.  If you believe that, you totally don't
understand the Microsoft release model.  I live in Seattle, and I do, as
do most people around here.  Microsoft deliberately barfs the first
version.  They put it into the field and force the customers to find the
bugs, that's part of how they make money.  They use aggressive marketing
to push their early crap.  The first version of any Microsoft product
sucks.  The second one is so-so.  The third one is ok.  The fourth is
often decent.  The fifth is usually pretty good.  Pretty soon, nobody
can possibly catch up to the combo of their technical improvements +
their marketing mindshare.  It is one of the main methods by which they
have conquered the computer industry.

I don't know any commercial developer who takes the attitude of "sit
back and wait."  That's a hobbyist idea.  If the disconnect is too
strong here, that's ok, we'll go our separate ways and no hard feelings
on my part.

> I don't think that anyone is worried about you "touching our source
> pool" beyond that you might introduce something that has unexpected
> results.  That's why anyone with CVS access tests a piece of code as
> thoroughly as possible before committing it.

I'm on board with that culture.  It's what we always did at DEC, and we
achieved the highest level of OpenGL Conformance in the industry at the
time with such methods.  I always apply fascist testing and source
control methods in my own work.

> > 3. Recruiting a horde of Windows C# .NET developers
> > a) the more the merrier!
> > b) get out of here you Micro$quish suckup bastard
>
> "Micro$quish?"  That's a new one.

Not really, it's common.  Try Googling for it, albeit without the $.

> Although I
> suppose that it would make it possible to add lots of new features to
> the Windows version, I would be reluctant to add anything
> that would not work on all Xconq platforms.

C#, .NET, and Microsoft-specific stuff is not my first priority.
However, considering how aggressive I am once I'm doing something, it
may come up sooner than you'd guess.  It's how I'll be writing GUI code,
when / if I'm ready to do that.  Also, putting on the "cheerleader" hat
I'll be trying to get people with the Windows mindset into your project.
If you don't really feel "the more the merrier," if that actually makes
you squirm in your chairs, we'd probably better know that about each
other's attitudes and intents up front.  In that case, it would be
better for me to depart and lead a Windows-centric project.

> For example, I would be willing to add
> code to Xconq that would let it talk to MS Excel, but only if it was
> possible to do the same thing with at least one other spreadsheet
> application (e.g. Gnumeric) on other operating systems (e.g. Linux).

I can help you with things needed for .NET / Mono interop, but you would
have to be point man for Mono.  For instance, I'm not setting up a Linux
box.  And, you should understand that language interop is my agenda, not
cross-platform implementations for everything in Xconq.  If Python runs
in kernel on all platforms and C# .NET implements a Windows-specific
GUI, my needs are spoken for.

> Getting back to your question, if a horde of Windows C# .NET
> developers
> could make a contribution to Xconq without causing problems
> in the UNIX
> and MacOS versions of Xconq, I'd be inclined to welcome them.

I think that's a simple matter of separating kernel concerns from GUI
concerns.  I'm not saying C# should be in the kernel.  My view is, C# is
going to be the preferred language for Windows GUI programming for the
forseeable future.  Meanwhile, Python is to be preferred for platform
independent code, AIs, and game design scripting (if you guys decide to
augment or replace GDL).

I am evolving a hybrid Python / C# business model, you guys are my
guinea pigs.  :-)

> Are the answers I provided firm enough?

Yes I would say so.  It remains to be seen what other people's opinions
are, and what the dominant consensus of your group is.  And also,
whether Eric wants to raise enough of a stink about anything to
effectively exert "veto power."


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

RE: growth agendas and OO

[Brandon J. Van Every]

Eric McDonald wrote:
>
>   Post-7.5/Pre-7.6:

Ok, so when is 7.5 going to get kicked out the door?

> > I am willing to contribute to the OO-ification of Xconq, if
> > you want to
> > pursue that agenda.  If you think that agenda is misguided,
> > then it's best to find out now.
>
> I don't think that this is necessarily misguided in the long term.
> But the C infrastructure works pretty darn good at present. We
> even have some "polymorphism" due to nifty macro magic....

Nifty polymorphism with macro magic?  You are scaring me.  I appreciate
that you're working with a legacy codebase, and that a working codebase
has inherent value.  But surely, in the year 2003 you do not expect
people to take this as serious OO.

> Xconq currently attempts to be at a C89 compliance level to make
> sure that we are supporting as many platforms as possible.

The kernel, fine.  But we've established that not all GUIs are equal on
all platforms, nor are all build environments.

> If you
> say that we should just ditch those platforms, then you are simply
> stating an opinion which is not even all that pragmatic.

Python runs everywhere, so I don't see any issue with sticking it in the
kernel, other than making sure it works.  You might resist that idea
now, saying "No no!  We don't want instability and change!"  But that is
the price of moving on.  I think you'll like Python, you'll start using
it, then you won't object anymore.

> I
> actually did put out a feeler a while ago, to see about moving the
> compliance level to C99; the conclusion I reached is that the
> time is not right yet.

You know, when I compile the stuff using VC 2003, I get all sorts of
warnings.  I don't see what would be such a big deal about killing all
those warnings, they're mostly trivial int conversion and comparison
warnings.  I'm not volunteering to undertake that task right now.  I'm
just saying, if this is what's in the way of the "C99 compliance," it is
not a big deal to take a day to get rid of all of those warnings.

But, I don't know beans about what C99 compliance implies, nor do I
care.  The Windows way is to force people to upgrade.  And by that I
don't mean grabbing Micro$oft's new OS every 2 years.  I hate them for
doing that, and I won't!  I mean that in 2003 you don't support Windows
95 anymore.  It's a waste of development time that benefits almost
nobody.


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: Xconq UI thoughts

[Andreas Bringedal]

> > 5. Players hate to type; they would rather roll around a
> > bunch of buttons
> > and popups than hit a single key on the keyboard.
>
> I agree.

I strongly disagree.  If there is a paranthesis in the menu which tells you
what keys to press to achieve the same result then those _will_ be used.
'm' for map being one of the most used ones.  F9, F11 for quickload/save are
also very handy. Ctrl-S Ctrl-L for regular save/load. 's' for sentry/sleep,
'b' for build, 'f' for fortify, 'w' for wake are also common to most
players, especially for Civ players.

The problem is when you have to search through documentation to find the
keys.  When you have the relevant key binding listed in paranthesis behind
the relevant popdown menu choice you automatically learn it and use it.
Another important thing is to use the standard key binding used most
commonly in other games.  Having different key bindings for each game you
play makes it harder to learn and therefore harder to use.

However a permanent menu choice like in Panzer general where you have a row
of choices along one side of the screen is easier than key bindings and far
easier than popdown menues.  Panzer General's good menu system, pleasant
game coulors, and easily surveyable map/units is half it's reason for
success. (The other half being a good game/combat system)


Andreas

keys and menus

[Brandon J. Van Every]

Andreas Bringedal wrote:
>
> > > 5. Players hate to type; they would rather roll around a
> > > bunch of buttons
> > > and popups than hit a single key on the keyboard.
> >
> > I agree.
>
> I strongly disagree.  If there is a paranthesis in the menu
> which tells you
> what keys to press to achieve the same result then those
> _will_ be used.

Yes, but they should never be required.

> Another important thing is to use the standard key binding used most
> commonly in other games.

Caveat: some genres only have perceived standards, not actual ones.  But
I must admit, I found Xconq keys rather "wack" compared to Civ keys.  I
don't know if Xconq keys are based on Empire keys that were different or
something.  Anyways, the standard solution in this case is a user
configurable keymap, plus some keymap profiles for common layouts that
people use.

I thought it was very strange that in a hex game, the movement keys were
not in fact laid out in a hex on the keyboard, seeing as how that shape
is readily available on the keyboard.

> However a permanent menu choice like in Panzer general where
> you have a row
> of choices along one side of the screen is easier than key
> bindings and far easier than popdown menues.

What's a "popdown" menu?

I've been thinking in terms of a "right-click always gives you a popup
menu of specific icons" style of interface.  I'm willing to train the
user that they always need to right-click, using a scripted tutorial.
It is not a difficult convention for Windows users, it's how you get
around Windows.  That way, permanent screen real estate does not have to
be allocated, and you don't have to waste movement mousing over to the
icon bar.

> Panzer General's good menu system, pleasant
> game coulors, and easily surveyable map/units is half it's reason for
> success. (The other half being a good game/combat system)

I agree that they nailed playability and ease-of-use.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: Xconq UI thoughts

[Bruno Boettcher]

On Thu, Nov 20, 2003 at 11:07:57AM +0100, Andreas Bringedal wrote:
> 
> > > 5. Players hate to type; they would rather roll around a
> > > bunch of buttons
> > > and popups than hit a single key on the keyboard.
> I strongly disagree.  If there is a paranthesis in the menu which tells you
same here.... i play xconq essentially with the kbd....
on the other hand i am regularly called a 'dinosaur' by my students....

> The problem is when you have to search through documentation to find the
> keys.  When you have the relevant key binding listed in paranthesis behind
yup, and i remind in some games keys to select units to build were there
twice making the move to the mouse an obligation....

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================