Find a file
Markus Armbruster 494ab8dc07 fairland: Fix island growth and correct its bias
grow_one_sector() picks a coastal start sector, then moves along the
coast trying to add an adjacent sector to the island.

It operates in spiking mode with a chance of @sp percent.

When spiking, the neighbors with sea on both sides are preferred.  For
instance, when the area around the sector being considered looks like
this

     - .
    - - .
     - .

then the neighbor in direction j is preferred, because it has sea in
directions u and n.  No other neighbor is preferred.

The start sector is the first coastal sector found in a linear search
in growth order, starting at the last sector grown when spiking, or
else at a random sector.  This is new_try().

grow_one_sector() tries adding a neighbor in clockwise order, starting
with a random direction.  When spiking, it goes around the clock two
times, trying only preferred sectors in the first round.

When it can't add a neighbor, it moves to the next coastal sector with
next_coast().

Taken together, this randomly picks one element from the set of
pairs (S, D) where the sector in direction D off base sector S can be
added to the island.  How does the probability distribution look like?

Bias: a sector's probability to be added to the island land increases
with the number of base sectors it is adjacent to.  This tends to fill
in bays and lakes, which is fine.

Bias: coastal sectors following runs of non-coastal ones are more
likely to be picked as start sector.  Perhaps less of an issue when
spiking, where the pick is not intended to be random.

Bias: a pair (S, D) is more likely to be picked when base sector S
follows a run of coastal sectors that aren't base sectors, or
direction D follows a a run of directions that don't permit growth.

The impact of these two biases is not obvious.  I suspect they are the
reason behind the tendency of large islands to curve around obstacles
in a counterclockwise direction.  This can result in multiple islands
wrapping around a central one like layers of an onion.

Bug: the move along the coast is broken.  next_coast() searches for
the first adjacent sea in clockwise order, starting in direction g,
then from there clockwise for a sector belonging to the island.
Amazingly, this does move along the coast in a clockwise direction.
It can get caught in a loop, though.  Consider this island:

        -
     - - -
      -

If we start at the central sector (marked 0), the search along the
coast progresses like this:

        1
     - 0 2
      -

It reaches the central sector again after three moves (to 1, to 2,
back to 0), and stops without having reached the two sectors on the
left.

If we start with the leftmost sector, the search loops: 0, 1, 2, 3, 1,
...

        2
     0 1 3
      -

grow_one_sector() ensures termination by giving up after 200 moves.
Nuts!

Because of this, grow_one_sector() can fail when it shouldn't, either
because the search along the coast stops early, or goes into a loop,
or simply because there's too much coast.  The latter should not
happen in common usage, where island sizes are in the tens, not the
hundreds.

Clean up this hot mess by rewriting grow_one_sector() to pick a sector
adjacent to the island with a clearly defined probability, as follows.

Use weighted random sampling to pick one sector from the set of
possible adjacent sectors.

When spiking, a sector's weight increases with number of adjacent sea
sectors.  This directs the growth away from land, resulting in spikes.

When not spiking, the weight increases with the number of adjacent
land sectors.  This makes the island more rounded.

To visit the adjacent sectors, grow_one_sector() iterates over the
neighbors of all island sectors, skipping neighbors that have been
visited already.

This produces comparable results for low spike percentages.  The weird
onions are gone, though.

Noticeable differences emerge as the spike percentage grows.  Whereas
the old one produces long snakes that tend to curve into themselves,
the new one produces shorter spikes extending from a core, a bit like
tentacles.  Moreover, islands are more centered on their first sector
now.  The probability for coastal capitals is lower, in particular for
moderate spike percentages.

I consider this improvements.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
2021-01-19 08:21:02 +01:00
build-aux Update copyright notice 2018-04-29 10:33:19 +02:00
doc doc/contributing: Fix a greengrocers' apostrophe 2021-01-05 07:25:18 +01:00
include Update copyright notice 2021-01-05 10:41:28 +01:00
info Update copyright notice 2021-01-05 10:41:28 +01:00
m4 m4: Make MY_WITH_TERMINFO consistent with MY_WITH_READLINE 2017-08-06 11:22:29 +02:00
man fairland: Fix island growth and correct its bias 2021-01-19 08:21:02 +01:00
scripts Update copyright notice 2021-01-05 10:41:28 +01:00
src fairland: Fix island growth and correct its bias 2021-01-19 08:21:02 +01:00
tests fairland: Fix island growth and correct its bias 2021-01-19 08:21:02 +01:00
.gitignore Make: Fix configure generated for dist-client 2017-08-13 14:31:07 +02:00
.travis.yml Bind Travis notifications to main mirror 2017-09-02 15:37:01 +02:00
bootstrap Replace other occurences of git-FOO by git FOO 2008-12-03 07:57:14 -05:00
configure.ac Update copyright notice 2021-01-05 10:41:28 +01:00
COPYING License upgrade to GPL version 3 or later 2011-04-12 21:20:58 +02:00
CREDITS Put URIs and e-mail addresses in <angle brackets> 2013-05-26 09:48:16 +02:00
GNUmakefile.in Update copyright notice 2021-01-05 10:41:28 +01:00
INSTALL INSTALL: Refresh from automake 1.13 2015-03-08 18:23:33 +01:00
Make.mk Update copyright notice 2021-01-05 10:41:28 +01:00
README Update copyright notice 2021-01-05 10:41:28 +01:00

Welcome to Empire 4, code-named Wolfpack.

Empire is a multi-player, client/server Internet based war game.
Copyright (C) 1986-2020, Dave Pare, Jeff Bailey, Thomas Ruschak,
Ken Stevens, Steve McClure, Markus Armbruster

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License (in file
`COPYING'), or (at your option) any later version.

See file `CREDITS' for a list of contributors.

Directory `doc' has additional information.  File `doc/README'
describes the files there and what they talk about.

To build the server and set up a game, follow the steps below.

(1) Unpacking the source tree

    If you downloaded a tarball, unpack it.

    If you cloned a git repository, run bootstrap.  This requires
    recent versions of Autoconf and Automake to be installed.  See
    also doc/contributing.

(2) Building a server

    Prerequisites: IEEE Std 1003.1-2001 (POSIX.1-2001), GNU make, a
    curses library, Perl, and either nroff or GNU troff (`groff').

    See file `INSTALL' for detailed compilation and installation
    instructions.  Quick guide for the impatient: run configure; make;
    make install.  The last step is optional; everything runs fine
    right from the build tree.

    If configure reports "readline: no" in its configuration summary,
    fancy line editing doesn't work in the client.  Commonly caused by
    not having development libraries installed.  On Linux, try
    installing readline-devel.

    If configure reports "terminfo: no" in its configuration summary,
    highlighting doesn't work in the client.  Commonly caused by not
    having development libraries installed.  On Linux, try installing
    ncurses-devel.

    If make fails without doing anything, you're probably not using
    GNU make.  Some systems have it installed as `gmake'.

    Solaris supports POSIX.1-2001, but you need to set up your
    environment for that.  Try passing
        SHELL=/usr/xpg4/bin/sh PATH=/usr/xpg6/bin:/usr/xpg4/bin:$PATH
    to make.  See standards(5) for details.

(3) Creating a game

    * Create a configuration for your game.  make install installs one
      in $prefix/etc/empire/econfig ($prefix is /usr/local unless you
      chose something else with configure).  You can use pconfig to
      create another one.

    * Edit your configuration file.  See doc/econfig for more
      information.

      Unless you put your configuration file in the default location
      (where make install installs it), you have to use -e with all
      programs to make them use your configuration.

    * Run files to set up your data directory.

    * Run fairland to create a world.  For a sample world, try
      `fairland 10 30'.  This creates file ./newcap_script, which will
      be used below.  You can edit it to change country names and
      passwords.

      Check out fairland's manual page for more information.

    * Start the server.  For development, you want to run it with -d
      in a debugger, see doc/debugging.  Do not use -d for a real
      game!

    * Log in as deity POGO with password peter.  This guide assumes
      you use the included client `empire', but other clients should
      work as well.

      For help, try `info'.

      To change the deity password, use `change re <password>'.

    * Create countries with `exec newcap_script'.

    Your game is now up!

Naturally, there's more to running a real game than that, but that's
beyond the scope of this file.

Please report bugs to <wolfpack@wolfpackempire.com> or via SourceForge
<http://sourceforge.net/projects/empserver/> (registration required).

For more information or help, try rec.games.empire on Usenet, or send
e-mail to <wolfpack@wolfpackempire.com> and we'll try to answer if we
can.  Also check out our web site at <http://www.wolfpackempire.com/>.

Have fun!

Wolfpack!