This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, 2002-05-10 at 13:53, Hans Ronne wrote:
> >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 was afraid of that.

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

Maybe I should make it so that engineers can build a terraforming
station that has about 1,000 CP's, and then the terraforming station
could alter the terrain in one turn.  Of course, I'd need to prevent it
from performing another terrain alteration in the next turn.

> 
> 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'll send it in another e-mail.

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

At least it's nice to have that cleared up.

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

Interestingly enough, when food is not sharable but everything else is,
and I make sure not to over-tax any particular resource, this game seems
playable without any noticeable problems.  There are a few quirks, such
as that starships won't automatically share fuel with space shuttles
even though they don't themselves run on fuel (they use
matter/antimatter), but for that, I can just use 'T' and 'G' as needed. 
Of course, I seem to recall that aircraft carriers have the same sharing
problem in the standard game.

> >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 didn't like the idea of nebulae as cell terrain because it forces
nebulae to be unchanging over time, which is clearly not the case in
real life.  Maybe it'll work if the game is short enough that one
wouldn't expect stars to be born or die during the game.

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

No.  It just disappeared.  And the target's number of hitpoints didn't
change either.

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

I could, but how would they share materials with non-independent units?

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

For now, I'll just leave it as it is (stars produce 100 solar per turn,
vacuum produces 2 solar per turn).

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

Now that's something that I don't think is documented, but it seems to
work.

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

All advanced units require 50 food to grow.  It just seems like food is
the only thing that they care about.

> 
> I'll send you a screenshot separately. Don't want to spam this list with
> big attachments.

Looks pretty nice.  You're right, the X11 version needs something like
this.  I need to learn tcltk.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]