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

[Hans Ronne <hronne at pp dot sbbs dot se>]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

Hans

Hans Ronne

hronne@pp.sbbs.se