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

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

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

This could certainly be done. It would require some coding, though.

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

Well, what you could do is to limit terraforming by materials and acps. It
is actually a two-step procedure (remove-terrain then add-terrain) and both
require acps as well as materials. See do_alter_cell_action for details.
I'm not sure if this is all implemented yet outside the kernel, though.
Something for the TODO file.

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

Xconq should not segfault even if you tell it to do something crazy. This
is a bug. I will look into this if you send me the game file that triggers
the segfault.

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

Looking at it, it seems that it is not implemented in any interface right
now. Clearly something more for the TODO file ...

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

I guess its either fix the supply code or do without it right now.

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

Since this is experimental stuff that Stan wrote, I really don't know how
it's supposed to work. You would have to examine his code to find out.
Defining nebulae as cell terrain makes sense, however.

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

Weird. Did you get any message when the unit disappeared?

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

Couldn't you just make the stars independent units? That is how the
minefileds work in the Gazala game, for example.

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

Well, first we would have to fix the supply code so that it works at all.

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

On the Mac, you can set the run length in the build dialog. In the tcltk
interface, you give the run length as a command prefix. Simply type "5"
then "P" then "i" if you want a city to build exactly 5 infantry units.

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

Well, whatever resource you programmed as necessary for growth is what the
the AI will look for first.

>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'll send you a screenshot separately. Don't want to spam this list with
big attachments.

Hans

Hans Ronne

hronne@pp.sbbs.se