The blocky miney creative sandbox type thing. You know. Like Lego or something.
Wednesday, 30 July 2014
Smoother landscape
I am contemplating adding triangular blocks to the landscape generation to create a smoother landscape. Maybe just as an option in the settings.
I don't know if it adds much to the actual game play. But it looks nice!
Tuesday, 29 July 2014
Out now on Windows 8
Ruby Miner World is now available on Windows 8. It's still in the experimental stages so that's why it's free! Have fun! Suggestions welcome!
Monday, 28 July 2014
Idea - Power Cubes
I was thinking about different ways one could add scripting functionality into Ruby Miner World.
Turing Machines.
First I thought about a Turing-like machine where a pointer would move along the grid of blocks. It could be made Turing complete if there were 6 colours of blocks and the pointer could sample blocks either side of the one it was on. The pointer would decide which direction to go next and what colour to turn the block underneath it depending on the surrounding block colours. You would be able to write a program just by setting the colours of the blocks different colours in a kind of binary code. I thought it might be fun to model this as a little train going backwards and forwards over the blocks.
But this idea is a bit obtuse and it would be extremely difficult to write anything sensible.
Power Blocks
A second idea I had was to use power blocks. These would have a floating point value strictly between 0 and 1. Then other blocks would be connected to these power blocks by wires. For example the "x" power block would have two input wires (A and B) and it's energy would be determined by the product of the two input power blocks E=AxB. Note that if the input energies are 0 or 1 this is equivalent to the logic gate AND. Another power block "+" would be E=A+B but with the result capped at 1. E=Min(A+B,1).
Perhaps I would limit power blocks to be energies of multiples of 0.1. Then their energy could be stored as an integer 0..10.
Neural networks
One could use these blocks to model neural networks. Or one could make have a neuron block which is a bit more complicated. A neuron block connected to two inputs A and B would have an energy of 1 only if (u.A+v.B+w>0) for some 3 numbers u, v and w. Or for a more "quadratic" neuron which can model more complicated behaviour it would be (u.A.A+v.A.B+w.B.B+x.A+y.B+z>0) for 6 numbers (u,v,w,x,y,z). But then we have to deal with things like back-propagation which alters the internal numbers of the neurons. Also, neurons are more complicated than this, for example they are thought to have a residual memory. i.e. after being activated they continue to remain activated for a short period. (So called short-term memory, which is connected but believed to be separate from working memory, the 7 or so things you can focus on at once). However, we know that neurons can model logic gates and vice versa.
Order of execution and time delay
In a computer instructions are implemented in order, each step dictated by a electronic pulse from the internal clock. In Ruby Miner World we have to make certain the steps are implemented in the right order. For example if one input of an AND gate were to change before the other it would have unwanted consequences! Just like an Excel spreadsheet, self references would cause problems. And yet we need these to write program loops. Hence we would have to store the states of all the energy boxes and use these stored states as the inputs for the next cycle. We should also pause the whole system when building it.
Spawning
As well as changing blocks and maybe moving blocks we should also like to have triggers when characters come within range of a block and spawning of enemies.
Pulsating Energy Block
This would be useful to use as a timing device.
Alternatives to Energy Paradigm
We have said floating point is represented by the energy (brightness) of a block. But we might use other representations. For example the rotation of a block, the size, the height, the colour, could all be used instead. Or the number 0..10 could simply be written on the side of a block. Perhaps the energy block could have 10 textures which could be user defined.
A cube might have many properties in which case we would need a conversion block, for example taking the rotation of a cube and converting it to an energy value. These would correspond to functions such as getXPosition(), getRotation(), getRColor() and so on. But each must give a value between 0..1.
Therefor distance between two blocks might not be allowed but the reciprocal distance would be 1/R^2. Which is, incidentally, the "gravitational force" strength between two blocks.
Example
In this example we multiply two numbers under 10 to get an answer just using numbers between 0..1.
Say you wanted to multiply 3 and 4. If you input the energies as 0.03 and 0.04 then multiplied them to get 0.0012, then divide by 0.01 to get 0.12 which is the energy representing 12.
Combing the two ideas
I guess the best thing to do is have energy cube logic gates. And also be able to control characters. Characters would behave like a roaming cube. i.e. Whichever cube the character is on/in would be it's surrogate cube. From that surrogate cube you could query the cube below, left/right/above. Therefor you would require a "cubeToTheLeft" cube which behaves like a cube to the left of the input cube. You could chain these together to get cubes further away.
Build and Dig cubes
Two more cubes that would be useful would be the build and dig cubes. Which would basically build a cube (perhaps on the topmost layer) or dig.
Work in Progress
This is still in the ideas stage. Feel free to add your own ideas!
Turing Machines.
First I thought about a Turing-like machine where a pointer would move along the grid of blocks. It could be made Turing complete if there were 6 colours of blocks and the pointer could sample blocks either side of the one it was on. The pointer would decide which direction to go next and what colour to turn the block underneath it depending on the surrounding block colours. You would be able to write a program just by setting the colours of the blocks different colours in a kind of binary code. I thought it might be fun to model this as a little train going backwards and forwards over the blocks.
But this idea is a bit obtuse and it would be extremely difficult to write anything sensible.
Power Blocks
A second idea I had was to use power blocks. These would have a floating point value strictly between 0 and 1. Then other blocks would be connected to these power blocks by wires. For example the "x" power block would have two input wires (A and B) and it's energy would be determined by the product of the two input power blocks E=AxB. Note that if the input energies are 0 or 1 this is equivalent to the logic gate AND. Another power block "+" would be E=A+B but with the result capped at 1. E=Min(A+B,1).
Perhaps I would limit power blocks to be energies of multiples of 0.1. Then their energy could be stored as an integer 0..10.
Neural networks
One could use these blocks to model neural networks. Or one could make have a neuron block which is a bit more complicated. A neuron block connected to two inputs A and B would have an energy of 1 only if (u.A+v.B+w>0) for some 3 numbers u, v and w. Or for a more "quadratic" neuron which can model more complicated behaviour it would be (u.A.A+v.A.B+w.B.B+x.A+y.B+z>0) for 6 numbers (u,v,w,x,y,z). But then we have to deal with things like back-propagation which alters the internal numbers of the neurons. Also, neurons are more complicated than this, for example they are thought to have a residual memory. i.e. after being activated they continue to remain activated for a short period. (So called short-term memory, which is connected but believed to be separate from working memory, the 7 or so things you can focus on at once). However, we know that neurons can model logic gates and vice versa.
Order of execution and time delay
In a computer instructions are implemented in order, each step dictated by a electronic pulse from the internal clock. In Ruby Miner World we have to make certain the steps are implemented in the right order. For example if one input of an AND gate were to change before the other it would have unwanted consequences! Just like an Excel spreadsheet, self references would cause problems. And yet we need these to write program loops. Hence we would have to store the states of all the energy boxes and use these stored states as the inputs for the next cycle. We should also pause the whole system when building it.
Spawning
As well as changing blocks and maybe moving blocks we should also like to have triggers when characters come within range of a block and spawning of enemies.
Pulsating Energy Block
This would be useful to use as a timing device.
Alternatives to Energy Paradigm
We have said floating point is represented by the energy (brightness) of a block. But we might use other representations. For example the rotation of a block, the size, the height, the colour, could all be used instead. Or the number 0..10 could simply be written on the side of a block. Perhaps the energy block could have 10 textures which could be user defined.
A cube might have many properties in which case we would need a conversion block, for example taking the rotation of a cube and converting it to an energy value. These would correspond to functions such as getXPosition(), getRotation(), getRColor() and so on. But each must give a value between 0..1.
Therefor distance between two blocks might not be allowed but the reciprocal distance would be 1/R^2. Which is, incidentally, the "gravitational force" strength between two blocks.
Example
In this example we multiply two numbers under 10 to get an answer just using numbers between 0..1.
Say you wanted to multiply 3 and 4. If you input the energies as 0.03 and 0.04 then multiplied them to get 0.0012, then divide by 0.01 to get 0.12 which is the energy representing 12.
Combing the two ideas
I guess the best thing to do is have energy cube logic gates. And also be able to control characters. Characters would behave like a roaming cube. i.e. Whichever cube the character is on/in would be it's surrogate cube. From that surrogate cube you could query the cube below, left/right/above. Therefor you would require a "cubeToTheLeft" cube which behaves like a cube to the left of the input cube. You could chain these together to get cubes further away.
Build and Dig cubes
Two more cubes that would be useful would be the build and dig cubes. Which would basically build a cube (perhaps on the topmost layer) or dig.
Work in Progress
This is still in the ideas stage. Feel free to add your own ideas!
Subscribe to:
Posts (Atom)