Ok, so here are some thoughts for developing a numerical model, such as for population growth.
Start from a simple idea. Numbers grow over time. They should not grow too slow, nor blow up too quickly. For population, you'll probably want a bit of an accelerating growth as the game goes on. Think of a gently upward curving graph, with time along the x-axis, and population along the y-axis. There are many formulas that will produce such an upward (concave up) curve. Two types of equations that immediately come to mind are quadratics (such as x^2), and exponentials (such as e^x). Exponentials are often used to model population growth, so they make for an obvious choice here. We have yet to specify a property that requires exponentials though, and much of this discussion will be generic to other numerical models beyond just population. For the sake of the initial discussion it really doesn't matter, the only requirement so far is a gently upward curving graph, so we'll consider both the quadratics and exponentials. We'll even expand on this a little and consider higher order polynomials, and non-integer powers of x.
Some examples would help at this point. Try looking at a few formulas in an
online graphing calculator. We can start by looking at some base formulas. Try entering the following (you can graph them all on the same graph):
e^x (exponential)
x^2 (quadratic = polynomial of order 2)
x^2 +x+1 (quadratic = polynomial of order 2)
x^3 (cubic = polynomial of order 3) (this one has an inflection point = a change in concavity)
x^3 -x^2 = x^2 (x-1) (cubic = polynomial of order 3) (this one has a dip, which would be a bit weird for population growth)
x^1.1 (any fixed exponent strictly greater than 1 will produce an upward curving graph)
x^0.5 (square root function, concave down, just for fun)
x^10000 (very sharp bend, concave up, resembling the bottom and right sides of a box)
x^0.0001 (very sharp bend, concave down, resembling the left and top sides of a box)
Aside concerning x^n:
If n was 1, there would be no curvature. You'd have a diagonal line. It n was stricly geater than 1, including non-integer values, the curve will be concave up. If n was between 0 and 1 it would be concave down. Such a concave down curve will still always be increasing, just at ever slower rates as x gets large. Higher exponents produce more dramatic changes in the steepness of curves. As the exponent increases to approach infinity, the bend approaches a sharp corner, looking like the bottom and right edges of a box. As the exponent decreases towards 0, the bend again approaches a sharp corner, looking like the left and top edges of a box. Note that 0^n = 0 for any n, and 1^n = 1 for any n. All the simple powers of x will pass through the points (0, 0), and (1, 1). The curve will start out slow near 0, and start getting quite steep by 1.
You'll notice all these graphs get very steep very quickly. Remember, we want gradual controlled population growth, not babies exploding out of airlocks. Zoom in on the graphs where they are still gently curving up. What we'll want to do is transform this small zoomed in area and expand it to match the time frame and expected population levels of the game.
For simple fixed powers of x, the area between 0.0 and 1.0 will be of most interest. Already by the time x = 1, the curve will be quite steep. Perhaps uncomfortably so for a population curve, making it difficult to manage. For x^2, the part up to about 0.5, or perhaps even as low as 0.3 looks much better.
For the exponential equation, the area where x is negative will be of most interest. The point when x = 0 looks to be about the point where managing a growing population starts to be difficult and will soon be vexing and tiresome. For e^x, we can take the graph from about -3 to 0.
Next we need to define some sort of target area for time and population. Some thought needs to be given to the unit of time. In Outpost 2 for example, there are game ticks, game marks (100 ticks), and the time period during which population adjustments run (every 256 ticks, or 2.56 marks). You might also use a real time measure, such as seconds, minutes, or hours. Perhaps the most natural unit of time is how often the population algorithm runs, or 2.56 marks. Let's say an average game should last 2560 marks, then there are 2560/2.56 = 1000 population increase intervals during an average game. (Not all of them will produce new people). Our desired time scale for the population graph is then 1000 time units (calls to the population algorithm). To win a game, you need at least 200 colonists. There may have been some setbacks though, and the player doesn't always launch the spaceship right away, so to account for this, let's say population = 220 at that point. We'll then want to transform the equation for the graph to match up the origins, scale the x range (time) so it ends at 1000, and scale the y range so it ends at 220.
For a turn based game like Outpost 1, the natural unit of time would be 1 turn, which is also how often you should call the population growth code.
This is getting a bit long, so this is probably a good place to cut it. Join us next time for graph transformations. We'll discuss the math behind matching up the origins, scaling in both the x and y, and identifying a starting population level.
The topic after that, will be some Calculus. We'll talk about the pesky time aspect of the equations, a bit about derivatives, numerical integration, and build a case for using an exponential function.
