Wolfpack Empire - mirror of https://git.pond.sub.org/empserver
http://wolfpackempire.com/
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> |
||
---|---|---|
build-aux | ||
doc | ||
include | ||
info | ||
m4 | ||
man | ||
scripts | ||
src | ||
tests | ||
.gitignore | ||
.travis.yml | ||
bootstrap | ||
configure.ac | ||
COPYING | ||
CREDITS | ||
GNUmakefile.in | ||
INSTALL | ||
Make.mk | ||
README |
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!