Re: Design questions for a galactic civilization game (long)

[Lincoln Peters <peters2000 at mindspring dot com>]

Sorry I didn't get back earlier, but I've had an unbelievably busy week.

On Mon, 2002-05-06 at 09:09, Hans Ronne wrote:
> >1. This is a futuristic game, so I want to require units to tool up
> >before they can build anything (except maybe a level 0 civilization).
> >However, because I'm using lots of advanced, acp-independent units, I
> >need to limit tooling up using materials.  There do not seem to be any
> >tables that would let me set that up.  At the moment, I have the tool-up
> >code in working condition, but no matter what the tooling requirement
> >is, any acp-independent unit completely tools up in 1 turn!
> 
> The tooling up code is what we had before the advances. I wrote both the
> advances code and the acp-independent units at the same time, with the
> intention that they should be used together, to emulate Civ. You are
> probably right that the tooling up code does not work with acp-independent
> units. I'm not sure how easy that would be to fix. Have you considered
> using advances instead?

I was actually hoping to implement advances *and* toolup in the game
(although I haven't defined any advances yet).  It would seem to me that
the best solution would be to implement "material-to-toolup" and
"consumption-per-tp" tables, or something equivalent.  It should then be
possible to set up material consumption for each toolup point that would
prevent toolup from finishing so quickly.

As for the idea of non-advanced, acp-independent units, it makes sense
to me that a shipyard would be limited by the supplies that it has, but
it would not need to draw resources from the surrounding terrain.  I
could, of course, turn off the acp-independent property of the shipyard
and use an acp-occupant-effect to make it work faster if it is occupied
by one or more teams of engineers.

As for advanced units that are not acp-dependent, I'm sure there's
something out there that could be defined like that, but I'm not sure
what it would be.

> 
> >2. Is there any way to set up a unit or terrain alteration with the sole
> >purpose of increasing the production of that cell?  An example that you
> >can find in Freeciv is irrigating land so that it produces an extra unit
> >of food each turn.
> 
> Yes. Just define two terrain types (plain and plain-irrigated) with
> different production. And then let the engineers (or whatever) do the
> conversion by calling net_prep_alter_cell_action. I don't think it has been
> used in a game yet, and there is no AI support, but it should work in
> principle.

I don't think that I explained my idea very well.  What I want to do is
define units that can terraform a planet (e.g. transform a Mars-like
planet into an Earth-like planet).  The problem is that as far as I can
tell, any terrain alteration only takes one turn to complete.  According
to what I've heard, the time it would take to terraform a planet with
modern-day technology is on the order of 1,000 years.  Even in the
distant future, I doubt that a planet could be terraformed in less than
a year.

> 
> >3. I want to set up spaceports as facilities that quadruple the reach of
> >a civilization from 1 cell to 4 cells.  However, all I can figure out is
> >how to quadruple the number of cells that are within the 1-cell range of
> >the civilization.  Do you ever expect that to be possible?  I could just
> >increase the reach of a civilization to 4 cells, but it would be quite
> >unrealistic if, for example, Earth could mine resources from Pluto
> >without a decent spaceport.
> 
> When I wrote the advanced unit code, the idea was that different more or
> less advanced units should have different reaches. And then you would be
> able to upgrade your unit at a certain cost when discover a certain advance
> (like upgrading a tribe to a village after discovering "the-village"). The
> code for all this stuff is already there and different units with different
> reaches are even defined in advances.g (tribe: 0, village: 1, city: 2). The
> tribe and village units are not used in either the base module or the
> Ancient Near East game, but that is just because I didn't want to make the
> game too complicated. You could easily implement this stuff in your space
> game by defining your own units with different reaches.

I had been playing around with the idea of making different unit-types
for each level of a civilization (sort of like the types of cities in
"time.g").  I tried setting it up so that, like in "time.g", a
civilization can build the next level civilization, but disappears as
soon as the new one is completed.  However, when I tried that, Xconq
segfaulted as soon as the new civilization completed and the old one
vanished.

I tried using the "change type" mechanism as you suggested, but I can't
figure out how to actually do a change type now that I've set up
civilizations to be able to do so!  Is the "change type" command only
available on the Mac interface, or what?

> 
> >4. Is it possible to tell units exactly what they can and cannot share
> >with other units, short of disabling it in the out-length table?
> >In most games, that is not a problem, but in this case, it becomes
> >desirable to control what materials are going where, depending on what's
> >in short supply and what's plentiful.
> 
> The supply code does not work as expected even in the standard game and
> tends to mess up things really bad if you are using advanced units. I
> usually disable it (and the economy code) by adding this to the game file:
> 
> (economy false)
> (supply false)
> 
> Both are on by default, but I have been thinking about disabling at least
> the supply code by default.

Well, I could scrap the whole economy/supply line thing and move
supplies around using cargoliner ships, but then the game would be
*really* tedious to play (imagine moving a cargoliner from a planet to a
shipyard and back 65 times in order to build a Galaxy-class starship)!

I did notice that if advanced units can share food, one unit might suck
up food from another unit, causing the second unit to starve.  As soon
as I saw that, I completely disabled sharing of food.  Less critical
supplies such as ores can still be shared, though.

> 
> >5. I want to define nebulae as either a terrain coating or as a cloud
> >cover, but I've never seen any game that demonstrated cloud cover, nor
> >have I ever seen anything that makes sense of coatings.  Would either
> >system work for nebulae?  How would I set it up?
> 
> This is experimental stuff that Stan never completed, but it seems to work
> fine in those few games that use them. For clouds, check out the napoleon.g
> (the base module, not 1805). For coating (mud and snow) check out
> ww2-eur-42.g.

I looked at ww3-eur-42.g already, and I was able to play it and see mud
and snow in action, but I couldn't figure how how they were controlled. 
Do they require the temperature to be within an arbitrary range, or
what?

I also looked at napoleon.g, and I can see how the clouds are
implemented.  However, if "See all" is enabled, the clouds don't seem to
do anything, and if "See all" is disabled, Xconq segfaults.

Maybe I should define nebulae as cell terrain now and worry about
converting it into clouds or coatings later.


I did see an unrelated problem in napoleon.g, however: If a multi-part
unit (e.g. infantry) is active in Move mode and the player clicks on an
adjacent unit, the multi-part unit will try to attach to the other unit,
regardless of whether or not it actually can.  If the first unit can't
attach (e.g. it tries to attach to a cavalry unit), it will vanish. 
Shouldn't it just co-occupy the cell?

> 
> >6. Can I set up terrain to exchange material with adjacent cells?  My
> >idea is that I would define stars as cell terrain, set them up to
> >produce enormous quantities of solar energy (abbreviated as "solar"),
> >and that the material would diffuse through space.  That way, a planet
> >close to the star, such as Mercury, would be able to draw lots of solar
> >from the environment, but farther away planets, such as Pluto, would not
> >be able to draw as much solar.
> 
> I think the esiest way to achieve what you want is to make the stars units
> instead of terrain.

I'm guessing that what you mean is define stars as units that produce
solar and can send it to units up to a certain distance.  That would
work, but it would require the capture of stars first (that's a strange
concept), and it seems to me that unless some kind of falloff could be
defined, it would send the same general amount to units at all
distances.

It seems to me that the best solution would be that (a) vacuum terrain
can store up to 50 solar and consume 2 each turn (but not be damaged if
it runs out), and (b) if a cell is over 50% capacity, it can share its
materials with adjacent cells that can store that material.  Maybe there
should be in-length and out-length tables for terrain as well as units.

> 
> >7. Are there any plans to set up Xconq to allow players to choose which
> >cells an advanced unit is drawing resources from, like a player can in
> >Civ?
> 
> This is how things already work. As Jim explained, you just select the unit
> in the tcltk interface and click on the resource icons to move them. In the
> Mac interface, this is all done within the city dialog (see below) just as
> in Civ.

Well, as soon as I tried it, it worked fine.  Maybe I was in query mode
when I tried it before.

> 
> >8. Are there any current plans to work on the AI "Improving" code?  In
> >"advances" or "3rd-age" it can get away with building facilities
> >randomly, as it can produce everything it needs without any facilities
> >(although not as much), but it's not that way in the game I'm writing.
> >If a player neglects to produce an antimatter plant, it becomes
> >impossible to power starships.
> 
> Plans yes. Current no. Gotta get 7.5 out of the door first.

Sounds logical.  Maybe until then I can make some sort of "AI
compatibility mode" that causes civilizations to produce matter and
antimatter without any of the appropriate facilities.

> 
> >9. Is there any mechanism I can use so that, if a starship enters a
> >shipyard, it can be upgraded?  I imagine that it would be similar to
> >when in Civ, if an obsolete unit is in a city, it can be upgraded (e.g.
> >cavalry to armor).  Of course, in this case, it would be like the
> >Starship Enterprise being re-fit with more powerful engines and
> >shields.  Of course, such an upgrade shouldn't happen instantaneously
> >like it would in Civ.
> 
> Yes. You can tell one unit to change the type of another. The ability to
> change is limited by acps and available materials. See the
> acp-to-change-type and material-to-change-type tables.

Well, I'll need to figure out how to issue the "change type" command
first, but I'll try this.

> 
> >10. Are there any plans to implement any kind of semi-AI-control, so
> >that a player could assign a "Defensive" plan to a star fighter, an
> >"Exploratory" plan to a Constellation-class starship (the kind of ship
> >with 4 warp nacelles instead of 2), and a "Colonizing" plan to a band of
> >settlers, and then let them act automatically?  This would be like in
> >Civ if a fighter was set to "Auto-attack", a destroyer was set to
> >"Auto-explore", and a team of engineers was set to "Auto-settler".
> 
> Semi-automatic AI control is on of my pet projects, but still unfinished. I
> had working code for this once, but it's way out of date now. I'll look
> into it again after 7.5.

It sounds to me like a good idea.  When a game reaches a large enough
scale, it is quite convenient to be able to give general commands like
"auto-attack" to various units.  Otherwise, the game could get quite
tedious and quite boring fairly quickly.

> 
> >11.  I have seen that the computer always plays especially badly in
> >other space-themed games (e.g. "space" and "galaxy"), probably because
> >it can't figure out how to transport armies across terrain that is
> >inhospitable to the armies.  Are there plans to create a "Transport"
> >plan any time soon?
> 
> Same answer as #8 :-).

I guess I need to learn C and get my hands dirty.

> 
> >12. Is there any way other than doctrines to tell a unit how many of
> >another unit to build?  When engineers are building space stations, or a
> >shipyard is building starships (e.g. the starship Enterprise), it makes
> >sense to build only one when given a "build" command, but with armies,
> >engineering teams, or space shuttles, it can be inconvenient to
> >repeatedly issue "build" commands (they take less time to build than
> >starships).
> 
> It's the run length that decides how many units of the same type you build.
> The doctrine usually contains a default run length, but you can still set
> it manually for each unit.

I don't see any command for that.  Is it one of the long commands that
you have to type in?

> 
> >13. When an advanced unit grows, it appears to decide what new cell(s)
> >to use based on the materials that it needs to live and grow.
> 
> True, this is how the AI works right now. And there is a very good reason
> for this. In Civ type games, it is always the side that grows fastest that
> wins. Production is nice, but nothing beats growth.

That's not really the problem.  What's happening is that once a
civilization covers all of the habitable planets within its reach (i.e.
all that produce at least 1 unit of food each turn), as it grows, it
just fills in by sequentially covering all cells from the northeast edge
of its reach to the southwest edge.  Most often, these cells are vacuum
that only produce 2 solar each turn.  From a logistical standpoint, it
is much more useful to cover the inhospitable planets that are within
its reach (i.e. cells that produce varying amounts of ores and fuel but
not food) before covering vacuum cells.

Solar can be a limiting factor when building anything, but I don't think
that it has as much impact as ores and personnel (or maybe I programmed
the usage of solar incorrectly).

> 
> >14. In this game, outposts are essential to a civilization's ability to
> >conduct trade.  A civilization can send and receive supplies up to 8
> >cells away (if it has a spaceport), but it is quite rare for
> >civilizations to be that close together.  Outposts solve the problem by
> >sending and receiving anything (except food) up to 8 cells away.  Can
> >the AI figure that out and take advantage of that and build outposts
> >between its civilizations?
> 
> Not unless somebody writes the AI code for this ...

I guess that I *really* need to learn C and and get my hands dirty.

> 
> >15. When a game reaches a scale this big, Xconq's user interface seems
> >to make things somewhat difficult.  Are there any plans to incorporate
> >any sort of city dialog like the one in Civ?  If you're interested, I
> >could design some dialog boxes with GTK+ that might be appropriate.
> 
> The Mac interface already has a complete City dialog very similar to that
> in Civ. It even has a small clickable map where you can change the cell
> usage. I absolutely agree that a dialog-driven interface is esier if you
> have many units. Again, this is how the Mac interface works. When a city
> completes its current build task, a small dialog (the build dialog) pops up
> where you are prompted to pick a new build task from a menu. This is in
> addition to the city dialog, where you can do other things as well.
> 
> There is also a simpler version of the Mac city dialog (the simple closeup)
> which works with non-advanced units such as cities in the standard game.
> You just control-click on a unit to bring up the dialog (simple or
> advanced). Witihin it, you will find all the occupants as a list of
> clickable units that bring up their own dialogs.  If you are in one of
> these, the transport has its own icon that you can click on to get back to
> its dialog. Very handy for moving around between different units within a
> city and checking out what they are all doing.

Are there any screenshots of this?  I can see from the screenshots on
the website what you mean about the build dialog, but I don't see any of
the city dialog.

I did also notice that the Mac interface uses smiling faces and frowning
faces to indicate which sides are trusted and which are not.  This
doesn't appear in the tcltk, and could be quite handy in games like
"Lord of the Rings" and any of the WW2 advanced games.

> 
> If you want to impement these dialogs in the tcltk interface, please go
> ahead. That would certainly improve things. Unfortunately, I never had time
> to do it myself. The code is in the macunit.c file.

I know how to make UI's for GTK+, but not tcltk, and I've never
programmed anything beyond text-only programs on a Macintosh.  I'd be
willing to look at the code, but I can't guarantee that I'd understand
any of it.

> 
> >16. Sometimes I want to be able to build multiple facilities of the same
> >type (e.g. 15 antimatter plants on 1 planet).  It seems to work, but it
> >grows unwieldy rather quickly (try figuring out at a glance what
> >occupants are in a unit with 15 of *any* facility).  Could I define
> >facilities as being multi-part (like infantry in "napoleon") and still
> >get the same combined production or effect as I would from the
> >individual small parts?
> 
> I guess you could. Don't know if it would solve your problem, though. With
> Mac style dialogs, managing all these facilities would be a lot easier.

After seeing the problems that arise with multi-part armies in
"napoleon.g", I don't think I want to try it, at least not until I've
ironed out the rest of the game.