fazo96/Alrium
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fixes and interface info

Browse Source
This commit is contained in:
Enrico Fasoli 2015-09-30 20:53:43 +02:00
parent a686a60f3e
commit c587028a7e
1 changed files with 23 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
README.md
View File

@ -27,16 +27,11 @@ There are four kinds of blocks:
- sensor blocks
- resource blocks
TODO: energy system
### Connection
- Each block can be connected to every other adiacent block (diagonals too), so each block has 8 connection weights.
`source block output ->>>- * weight ->>>- destination block`
- A connection _is_ a weight, which is a floating point number.
- The connection outputs its source block's current stored signal multiplied by the weight.
- 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
@ -53,7 +48,7 @@ A signal is a floating point value. Each block stores a signal.
Their signal is the sum of all the values provided by their input connections.
### Action (Input) blocks
### Action (Output) blocks
They take an input signal and act by doing something, for example:
@ -84,11 +79,15 @@ 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 "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 input connections.
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.
@ -121,10 +120,13 @@ 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
@ -140,7 +142,7 @@ Even better, there should be structures generating energy and shipping it off in
### Primordial creature
Since we can't expect that interesting machines pop up in our simulation, we need to design one.
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:
@ -155,4 +157,14 @@ even early in an implementation. We __don't__ want to lose good machines!
## Interface
Good luck coming up with a good one...
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.