Archive for the ‘Game’ Category

The Game: computing growth

Posted by Vitalie Ciubotaru

Previous posts on this topic:

* * *

1. Plant size

Under normal conditions, plant size increases over time. Plant growth depends on:

  • Plant’s current size (S_{t}) — the larger the plant is, the more it adds every day.
  • Growth rate (g) — a general concept, which will be discussed in more detail below.
  • Cell size (S_{max}) — i.e. there is an upper limit for growth.

Thus, \frac{\mathrm{d}S_t}{\mathrm{d}t} = f(S_{t}, g, S_{max}) = S_{t} \cdot g \cdot \frac{S_{max} - S_{t}}{S_{max}}. When the plant is small, the upper limit is not important and the limiting factor is current size, so initially the plant grows [almost] exponentially. When the plant grows large, the upper limit becomes more binding and growth decelerates again. Let me solve this equation for t.

\frac{\mathrm{d}S_{t}}{S_{t} \cdot (S_{max} - S_{t})} = \frac{g \mathrm{d}t}{S_{max}}
\int \!\frac{1}{S_{t} \cdot (S_{max} - S_{t})} \, \mathrm{d}S_{t}  = \int \! \frac{g}{S_{max}} \, \mathrm{d}t + C
Solving the left side integral:
\frac{1}{S_{t} \cdot (S_{max} - S_{t})}  = \frac{S_{max}}{S_{max} S_{t} (S_{max} - S_{t})} = \frac{S_{max} - S_{t} + S_{t}}{S_{max} S_{t} (S_{max} - S_{t})} = \frac{S_{max} - S_{t}}{S_{max} S_{t} (S_{max} - S_{t})} + \frac{S_{t}}{S_{max} S_{t} (S_{max} - S_{t})} = \frac{1}{S_{max} S_{t}} + \frac{1}{S_{max} (S_{max} - S_{t})}
So \int \!\frac{1}{S_{t} \cdot (S_{max} - S_{t})} \, \mathrm{d}S_{t}  = \int \!\frac{1}{S_{max} S_{t}} \, \mathrm{d}S_{t}  + \int \!\frac{1}{S_{max} (S_{max} - S_{t})} \, \mathrm{d}S_{t}  = \frac{1}{S_{max}} [\ln (S_{t}) - \ln (S_{max} - S_{t})] = \frac{\ln (\frac{S_{t}}{S_{max} - S_{t}})}{S_{max}}
Solving the right side integral:
\int \! \frac{g}{S_{max}} \, \mathrm{d}t = \frac{g t}{S_{max}}
Now putting it all together:
\frac{\ln (\frac{S_{t}}{S_{max} - S_{t}})}{S_{max}} = \frac{g t}{S_{max}} + C
Simplify and redefine the constant:
\ln (\frac{S_{t}}{S_{max} - S_{t}}) = g t + C
(\frac{S_{t}}{S_{max} - S_{t}}) = e^{g t + C} = e^C + e^{g t} = S_{0} e^{g t}
S_{t} = \frac{S_0 S_{max} e^{g t}}{1 + S_0 e^{g t}}
Finally, making it discrete:
S_1 = \frac{S_0 S_{max} e^g}{1 + S_0 e^g}

2. Growth rate

Time to discuss g. The growth rate depends on:

  • (mis)match between the “climate requirements” of a particular species and “climate” or “resource endowment” of a particular cell
  • capacity to acquire resources — roots and leaves

For example, insufficient sunlight can be partly compensated by large leaves and insufficient minerals/water — by longer roots. Excessive resources will represent a small saving in roots/leaves, but will still be limiting the growth rate. As a possible way to make the impact of deficit and excess of resources to be symmetric, developing roots and leaves can cost no resources, just a mouse click and some waiting time. Have to think a bit on this.

The Game: plant types and species

Posted by Vitalie Ciubotaru

Previous posts on this topic:

* * *

In all games, player “races” have names and these names are somehow suggestive of the race traits (strength, aggressiveness etc.). Thus my plants should have names and these names should reflect their traits.

Plants have too many features, so making up a full set of real plants which would reflect all possible combinations of these features is way too much for now. I will start with a couple of traits and match them with broad groups of plans.

Features:
* Longevity — annuals, biennials and perennials (a plant “year” or “season” will correspond to a real-life week or two).
* Speed of propagation — low (shoots/runners/rhyzomes/bulbs, with high resistance and high survival rates), high (seeds/spores, with low protection and low survival rates)
* ?

Plants:
* Palms (Arecaceae or Palmae) family — perennial, high temp/sunlight, high humidity, any soil, evergreen, seeds (few, high survival), no shoots.
* Bamboo — kinda perennial, lots of shoots, all plantation blooms once and dies out.
* Araceae —

* * *

Followup posts on the game progress:

The Game: life and death

Posted by Vitalie Ciubotaru

Previous posts on this topic:

* * *

There should be some limit as to the plant size:

  • Plant growth depends on resources aquired (production function :-) — better roots and leaves mean quicker growth
  • Resources depend on resource endowment in each particular cell
  • Plant growth is limited by cell size — the larger the plant is (relative to the cell size), the slower it can grow, other things equal

There should be some limit on the age:

  • Death is not immediate, it’s the last phase in the plant life and it takes some time (more or less fixed), after which plant disappears
  • Death phase is triggered randomly after age t1. The probability of “death” linearly increases with age and reaches 100% at age t2. Well, death should be predetermined (so as not to roll the dice every time), but should be kept secret from the player.
  • Mmm … can attacks trigger death or they just hinder growth and proliferation?

* * *

Followup posts on the game progress:

Previous posts on this topic:

* * *

The game is more interesting to play if specialization (in whatever sense) is more profitable than universality. Not sure how to implement it.

Lakes and hydroponics? Mountains and terraces? Mutations?

* * *

Followup posts on the game progress:

The Game: progress (5)

Posted by Vitalie Ciubotaru

Previous posts on this topic:

* * *

Time to start creating MySQL tables.

Table “grid_layouts” contains grid parameters, like maximal X-, Y- and Z-coordinates, maybe a grid name and frequencies of different cells. This way we can have several grid templates. The columns are:

  • id
  • layout_name — a dozen of characters
  • max_x — number
  • max_y — number
  • max_z — number
  • description — many characters
  • what else?

Table “hex_layouts” contains all possible types of hexes that can be encountered on a grid, information on whether they are inhabitable, fertility, sunlight/temperature, and water/humidity:

  • id
  • inhabitable — boolean
  • fertility — percent from 0 to 100
  • humidity — percent from 0 to 100
  • sunlight — percent from 0 to 100

OK, that was it so far. What hex types do we need here?
Uninhabitable:

  • desert — fertility 0 (or maybe 10), humidity 0, sunlight 100
  • lake — fertility 0, humidity 100, sunlight 0 (or maybe 10)
  • house — fertility 100 (roots under the house), humidity 0 (or maybe 10), sunlight 0

Inhabitable:

  • basic type, equally fit for all types of plants — say 100:100:100
  • fertile (should give it a name) — 140:80:80
  • humid — 80:140:80
  • sunny — 80:80:140
  • fertile-humid — 110:110:80 (or maybe I should make it even more imbalanced, comparing to the previous three)
  • fertile-sunny — 110:80:110
  • humid-sunny — 80:110:110

So, there are 10 types of hexes. I need to decide on the distribution (like a hex of basic type should have no more than two uninhabitable hexes adjacent to it) and frequencies of each type. Exact frequencies are not very-very important, but it would be interesting to make a mechanism to adjust frequencies after the distribution rules were met. Say, if while populating the grid (hex by hex, row by row, checking for rules in the previous row), uninhabitable hexes turned out to be too few, the probability of the next hex being uninhabitable should be larger than average. Mmm … that still does not guarantee that the number of outcomes is strictly equal to the probabilities/frequencies…

Hopefully, next time I’ll be able to populate the grid!

* * *

Followup posts on the game progress:

The Game: progress (4)

Posted by Vitalie Ciubotaru

Previous posts on this topic:

* * *

It took me a while of contemplating a Robik’s cube and thinking about 3D coordinates before I came across a system of cell/tile notation that would fit my purposes. So, here is the story.

Two orthogonal axes are not good for hexagonal cells, because cell coordinates will not be integer numbers (look at figure 1).

Figure 1. Orthogonal coordinates

Two non-orthogonal axes can have integer number coordinates, like in figure 2, but calculating distances between cells is not straight-forward, so they are not good either.

Figure 2. Two non-orthogonal coordinates

If two coordinates don’t do, then what? Three coordinates???

First consideration. A square belongs to a vertical file and a horizontal file, which is exactly why Cartesian coordinates perfectly fit for both easy numbering and easy distance calculation. A hexagon belongs to three files at the same time: a horizontal file (from “West” to “East”), a file going from NNE to SSW, and a file going from NNW to SSE. Thus, one could pick a cell, number it (0;0;0), and number all other cells depending on how many files to, say, South, ENE and WNW they are with respect to the origin.

Figure 3. Three coordinates

I’ll try to add a better illustration and a bit of explanation later. So far, I want to mention two important things:

  • Somehow the values of all three coordinates always sum up to 0. This sounds strange and irrelevant, but it has an explanation and it has important implications.
  • There are both positive and negative values. Negative values are a bit annoying and look unnatural.
  • The distance between any two cells is calculated by formula \sqrt{(x_1 - x_0)^2 + (y_1-y_0)^2 + (z_1-z_0)^2}. The distance between two adjacent cells is equal to \sqrt{2}, but we can always normalise it by dividing to formula above by this number.

So far, we obtained a nice system of coordinates where (1) all cells are numbered using three integers, and (2) all distances are calculated by the same formula irrespective of the direction. The last thing I wanted to do was to get rid of negative numbers.

I recalled reading somewhere that a hexagon can be thought of as a projection of a cube on a plane. This way, we can think of hex grid as a Rubik’s cube made of many little cubes. Because the tiles of our grid do not overlap we need to take only those small cubes that lay in the same plane, i.e. laying edge to edge to each other. This plane crosses the faces of the big cube (Rubik’s cube, the grid in 3D) at 45 degrees and thus can be described by a simple equation x + y + z = a, where ‘a’ is some constant. If a = 0 we have the system of coordinates described above. We need to take ‘a’ large enough to make all values within our grid positive, but not unnecessarily too large. ‘a’ is deternimed very simply: count all files (1) from N to S, (2) from ENE to WSW, and (3) from WNW to ESE, then pick up the largest of the three. Done.

Preliminarily, the grid itself will represent a large hexagon, with one side equal to 32 cells. This means there will be 63 files in any direction. So all values of coordinates will be comprised between 0 and 63.

* * *

Followup posts on the game progress:

The Game: progress (3)

Posted by Vitalie Ciubotaru

Previous posts on this topic:

* * *

Another strange turn on the road of game development. I was thinking about hex grid and looking for possible ways to display it. There are several problems about it:

  • cell/tile notation, or basically the system of coordinates
  • conversion between the internal system of coordinates and the cartesian coordinates of the screen
  • adjacency of the fifth and sixth cells

I came across a number of useful resources about hex coordinates:

The main problem is that almost all resources look at hex grids with adjacent upper and lower cell, while I want a grid with adjacent cells located to the right and to the left. So I will learn conversion between coordinates and the math behind it, by implementing the same examples to “my” grid orientation.

To start with, I took Tim Holt’s hex map example, read about a game called Lights Out, and implemented a hex version of it in JavaScript and plain HTML, using no PHP for grid rendering (in contrast to Tim’s example). The result is here. It has a fairly easy solution, the design is wanting and the code is surely buggy, but it’s fully functional and playable.

* * *

Followup posts on the game progress:

The Game: progress (2)

Posted by Vitalie Ciubotaru

Previous posts on this topic:

* * *

Today game development took a bit unexpected path. Instead of creating and populating the grid and continuing with initialization stuff, I went into automation of what I already can do. So I started to create an “admin panel” for the game.

At this point, it can create and delete the database. Besides it reports the result in AJAX manner, without reloading the page. It took me a while to understand AJAX and implement it.

* * *

Followup posts on the game progress:

The Game: progress (1)

Posted by Vitalie Ciubotaru

Previous post about the browser game:
A[nother] strange idea: browser game

* * *

I learnt how to create MySQL databases from within php scripts and started the game initialization module. Next I want to create a table for grid cells and randomly populate the game map.

Plan:

  1. Populate the table based on hex coordinates
  2. Create a formula to convert from hex to Cartesian coordinates (e.g. for distance calculations).
  3. Create a script to plot them on the screen.

Ideas here:

  1. Cells might be divided into inhabitable (with different humidity, sunlight and minerals) and non-inhabitable.
  2. “Desert” would correspond to zero humidity or zero minerals, and be good only for sunlight. “swamp/river/lake/sea” would be good for water and/or minerals only. Non-inhabitable cells will be exploitable by a player, if they are adjacent to the player’s plantation.
  3. Possible types of cells, ranges of parameters and frequencies of appearance are to be stored in “constants.php” and used by “init.php”.

Another problem is security. Who will run init.php? How to protect it?

* * *

Followup posts on the game progress:

A[nother] strange idea: browser game

Posted by Vitalie Ciubotaru

I know that it takes time and skills and patience to create a browser game, so this “project” will probably stop long before I get anything to present, but… Well, who knows.

General description: A browser-based, real-time economic, political and military game emulating … plants.

Player types: Human and probably computer (bots). Human characters will have human-managed and autopilot regimes.

Grid: I want it fancy, so let it be hex. One cell is owned by one player and inhabited by one plant.

Players: A player is associated with one species of plants, with several features like speed of propagation, sunlight/temperature, humidity and soil requirements, resistance to attacks, strength in attack. The players species will grow within the cell, and propagate by occupying other cells. One player can own many plants (thus controlling many cells), all belonging to the same species.

Propagation:

  • shoots/runners/rhyzomes/bulbs (the basic method) — few, only adjacent cells (that’s why I want hex), high probability of success
  • seeds/spores — many, random location (?) possibly far from original plant, low probability of germination
  • others — maybe division of the mother plant, or parasitism, or?

Units and associations:

  • one plant
  • plantation (another term?) — all plants of one player
  • symbiosis — several plants of different species (adjacent cells only?)
  • biocenosis — several plantations (regardless of specie)

Attack on other plants:

  • steeling water/minerals — developing long roots and spreading them under neighbouring plants; slows or stops development of the drained plant
  • shadowing — developing large leaves and placing them over neighbouring plants, harms and destroys the shadowed plant

Defense:

  • large bulbs
  • think trunk
  • etc.

Finally, game objective (victory criteria): err … I donno :-)

* * *

Followup posts on the game progress: