# Dynamic cubes for cube engine [closed]

I had an idea for a cube world (i'm writing in C#) that would make creating new types of cubes simple and dynamic. Here is how I imagine it:

1.Text file stores everything including block name, texture path, 'hp',light output, and simple scripting for events. Here's an example:

BlockName=<block name>

Texture=<Texture Image Path>
SeeThrough=<True/False>

Element=<Normal/Fire/Ice/Water/Light/Dark/Earth/Quintessence/Void>
State=<Solid/Liquid/Gas>

Inventory=<slots for inventory>

MaxHP=<0 = Infinite>
Armor=<armor level>

EnergyIn=<amount of energy required>
EnergyInDirection=<[Top/Bottom/Front/Back/Left/Right/All]
EnergyStorage=<amount of energy that can be stored>

EnergyOut=<amount of energy given>
EnergyOutDirection=<[Top/Bottom/Front/Back/Left/Right/All]

LightIntensity=<level of light output>
LightDirection=[Top/Bottom/Front/Back/Left/Right/All]

[Events]

onTouch{
Damage.Give(10);
}

onClick{
}

onBreak{
}

onTimer(Time-in-ms){
}

switchOn{
}

switchOff{
}

1. An internal class would read all valid block files from the folder and create a list of block types, internally assigning ID numbers for each type of block. The specific world would store a dictionary of ID values and block names so that no matter how the block files are read, the saved world will always attribute the same ID number to the same block.

2. A look-ahead system in the CubeCaching service would identify all block types in existing chunks and in cached chunks and store only those cubes in memory. When a new chunk enters the cache, it will run through the types of blocks in its structure and the world class would then push all chunk blocktype amounts to the cache, where it would determine if a new type of block needed to be cached or not. Likewise, at that point the cubecache would also determine if all currently stored blocktypes still exist, and erase from memory any that no longer exist.

My goal is to chew as little memory as possible on block information and only make available the information that is necessary.

Here's my question: am I worrying about memory use too much? Is step 3 a good idea, or should I go ahead and just load and store all block types found without worrying about its memory use?

To clarify, i'm trying to figure out if it makes more sense to either load all block information and store it in a block-type list, or if I should include logic to only load the block information that exists?

Also to be clear: I am not storing all of this information for every single block. The information is only stored for the block TYPE, and would then be referenced for action based on an integer array in the chunk.

• This question is asking for a discussion. That's not what this site is about. Please see the FAQ to learn what types of question to ask here and where you can ask discussion questions like this. And yes you're worrying too much about memory, just make it already and see how it works. You'll never get it done worrying about these kinds of details. – MichaelHouse Dec 30 '12 at 7:41
• Since you tagged minecraft, i guess your goal will be at some point to render your block world, i would highly recommend you give the marching cubes algorythm a shot, it can be executed on the graphics card in a geometry shader and all you work with is a set of i[,,,,] where int density = intarray[x,y,z]; some links: http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html paulbourke.net/geometry/polygonise if you want more infos about marching cubes or help with a C# implementation just contact me. – Vengarioth Dec 30 '12 at 11:55
• your comment doesnt make sense because technically any question asked opens a discussion. further, it didn't ask for open discussion, it asks very specifically whether it makes more sense to load all or some of the resources. That's pretty specific if you ask me. Yet you are ok with extremely open ended questions such as "how does a single person make a game"? please be a little more constructive with your criticism next time. – David Torrey Dec 30 '12 at 15:56
• I say that because it would take a discussion to decide what's better. There's no correct answer. And I voted to close the other question you mention too. – MichaelHouse Dec 30 '12 at 16:01
• I think it's a valid question to wonder at what point memory concerns for games should be considered. I'm not sure what the other question you're talking about was. either way, thanks for the advice on 'get it down and see how it works'. – David Torrey Dec 30 '12 at 16:02

## 1 Answer

It depends on how many block types you will have. But yea, no need to load a block type that you are not using.

I would not generate the ids inside your internal class, I would have the id stored in your block type file. This will make sure that a block type will always have the same id.

Also, I suggest you look at the Flyweight Pattern.

• thanks for the advice, that helps and confirms a couple of suspicions. The flyweight is good reading too. After glancing over it, I think my idea was similar. basically the blocktype would hold all shared information, then the chunk would hold specifics of changeable information such as hp – David Torrey Dec 30 '12 at 15:34