171 lines
6.1 KiB
Markdown
171 lines
6.1 KiB
Markdown
# AIrium 2
|
|
|
|
AIrium is an artificial life simulation environment. The second iteration of the project
|
|
focuses on solving the problems of the first:
|
|
|
|
- variety in creature body and mind structure
|
|
- removing evolution limits (such as brain size)
|
|
- allowing different species to mate and produce possibly stable children
|
|
- speed: trying to get the simulation to be as fast as possible on consumer grade hardware
|
|
|
|
### World
|
|
|
|
The world is a matrix where each cell is either empty or occupied by a structure.
|
|
Every structure occupies only one cell.
|
|
|
|
### Creatures and other structures
|
|
|
|
A structure is a matrix where each cell is either empty or occupied by a Block.
|
|
Each adiacent Block can be connected.
|
|
The blocks make up both the body and, if the blocks are connected, the mind.
|
|
|
|
A structure with an operational mind governing the body is called a creature or machine.
|
|
|
|
There are four kinds of blocks:
|
|
- neuron blocks
|
|
- action blocks
|
|
- sensor blocks
|
|
- resource blocks
|
|
|
|
### Connection
|
|
|
|
- Each block can be connected to every other adiacent block (diagonals too), so each block has 8 connection weights.
|
|
- A connection _is_ a weight, which is a floating point number.
|
|
- A neuron block's output is its adiacent blocks's current stored signals multiplied by the appropriate weight.
|
|
- If the connection is `0`, then there's no connection
|
|
- if the connection is `not 0` then there is a connection
|
|
- the highest `abs(val) where val is the connection/weight` is, the stronger the connection
|
|
- the weight (or connection) is a floating point number between -1 and 1 included.
|
|
|
|
### Signals
|
|
|
|
A signal is a floating point value. Each block stores a signal.
|
|
|
|
- new blocks contain the `0` signal (null signal).
|
|
- blocks store a signal forever or until it is changed.
|
|
|
|
### Neuron (Processing) Blocks
|
|
|
|
Their signal is the sum of all the values provided by their input connections.
|
|
|
|
### Action (Output) blocks
|
|
|
|
They take an input signal and act by doing something, for example:
|
|
|
|
- they move the body in space
|
|
- they eject something
|
|
- they change color
|
|
- they interact with other structures
|
|
- they "eat" a block
|
|
- nothing (can be useful to stop signals from passing through)
|
|
|
|
### Sensor (Input) blocks
|
|
|
|
They give adiacent blocks a signal.
|
|
|
|
Some examples:
|
|
|
|
- they communicate how far is the first structure in a straight line
|
|
- they communicate the amount of structures in relation to blank spaces in an area (popularity in an area)
|
|
- they communicate the color/type/activity of the first block in a straight line
|
|
- they communicate information about the presence of a particular kind of structure in a direction
|
|
- they communicate information about the structure itself, like integrity of adiacent blocks
|
|
|
|
Generated signals are floating point numbers ranging from -1 to 1 included.
|
|
|
|
### Combined (Input+Output) blocks
|
|
|
|
They act as Sensor blocks and Action blocks at the same time.
|
|
|
|
Examples:
|
|
|
|
- a "mouth" block that can communicate wether food is available to eat and can receive eat
|
|
commands at the same time
|
|
- a memory block, which has a connection that when activated enables writing the value from
|
|
another connection in the block, then it just outputs its stored value.
|
|
|
|
|
|
### Evaluating a machine's mind's iteration
|
|
|
|
for each iteration, the `stored signal` of each block is calculated using its connection with adiacent blocks.
|
|
|
|
This `new stored signal` is stored in a special variable without overwriting the `current stored signal`
|
|
so that the process can be easily accomplished in multithreading execution environments.
|
|
|
|
After all the `new stored signals` have been calculated, their value is applied to the `current stored signal`
|
|
and the calculation process is repeated. This is done to encourage parallel computing.
|
|
|
|
__Note:__ the bigger a machine, the slower it reacts to signals because they need more time to travel through the body
|
|
|
|
### Reproduction and evolution
|
|
|
|
This requires two action blocks:
|
|
|
|
- the egg block
|
|
- the fertilizer block
|
|
|
|
machines can of course have both blocks, or even multiples of them.
|
|
|
|
- the egg block leaves a structure behind, an egg. This egg will either be fertilized or deplete energy and die.
|
|
- the fertilizer block can be used on egg structure to fertilize them
|
|
|
|
#### Hatching
|
|
|
|
When the egg hatches, a structure is born. The structure is built using a combination of the father's and the mother's blocks, then a mutation is applied to the result.
|
|
|
|
## Energy
|
|
|
|
This requires some new blocks:
|
|
|
|
- the battery block
|
|
- the energy drain block
|
|
- the generator block
|
|
- the stomach block
|
|
|
|
- the energy drain block sucks energy from a structure's batteries.
|
|
- the battery block stores energy and emits the current level to its connections
|
|
- the generator block uses up a lot of energy, then gives back slightly more
|
|
- the stomach block can be used to eat blocks from another structure. It then uses some energy to digest
|
|
the blocks, providing it back with an extra amount after it's done.
|
|
|
|
#### Consumption
|
|
|
|
- each action block uses up a moderate amount of energy when activated
|
|
- each sensor block uses up a small amount of energy when activated
|
|
|
|
## Primordial world
|
|
|
|
The world should be composed of a variety of huge, small and anything in between energy farming or storage
|
|
structures.
|
|
|
|
Even better, there should be structures generating energy and shipping it off in space.
|
|
|
|
### Primordial creature
|
|
|
|
Since we can't expect that interesting machines pop up from nothing in our simulation, we need to design one.
|
|
On Earth, it took billions of years for something to show up, but we want to speed things up a little bit.
|
|
|
|
This machine needs:
|
|
|
|
- to search for energy sources
|
|
- to find energy sources and get there
|
|
- to use energy sources to fill up batteries
|
|
- to successfully create fertilized eggs
|
|
|
|
From there, maybe something smarter can show up. It is __essential__ that the user can save a machine at any time,
|
|
even early in an implementation. We __don't__ want to lose good machines!
|
|
|
|
## Interface
|
|
|
|
Different modes:
|
|
|
|
- navigate world
|
|
- has a small _selected structure_ sidebar with additional information
|
|
- navigate structure
|
|
- ability to save the structure to file
|
|
- has a small _selected block_ sidebar with block informaton
|
|
- view block
|
|
- provides all info about the block and maybe signal activity monitoring
|
|
|
|
controls to handle simulation speed and pausing.
|