I suspect not very far at all, maybe I could build a house, a water wheel - though it would probably be a poorly crafted water hexagon. But what about computers, gene therapy, material for clothes, engines, aeroplanes, space travel, dynamos these things would be lost. Perhaps with a lot of help I could manage a crude steam engine.
Maybe this would be good for a game but I cannot imagine how you'd program it so it was real and pleasant to play. (I can imagine a number of cheap ways to do it but they miss the point - of having the worlds technology level rely on your knowledge)
Recently I've been working on a texture management system. Why would I need a system to manage textures? Surely it's all quite straight forward, make an enemy load his texture, slap it on, when the enemy dies, unload the texture - easy.
Putting it like that it does sound easy but I have a rule.
1. I only wanted to load a given texture into memory once.
Okay fair enough makes sense. Create a database where the textures are loaded. Each time some object wants a texure either increase the reference count in the database or if it's not in the database - load it. Simple.
And that is pretty simple and it's what's currently in my main project. The only problem I have with it - is it becomes very vast very quickly. There are 100's of references and I have no idea if they're being deferenced properly. Worse than that when I know somethings gone wrong - I have no idea how to track the problem down efficently.
Enter the thing I'm working on now. I keep getting the feeling I'm making something overly complex and it's probably not worth it. Though this does nothing to stop me.
My game worlds are divided into chunks, each chunk manages it's own textures. Textures are modified at run-time, chunks are often swapped in and out of memory. Of course I still stick to my rule 1 - I don't want to load a texture more than once.
Therefore I still have a global texture repository but instead of reference counting every texture instance it references how many chunks use it. This has a few follows ons -
Error checking becomes a little easier:
- there should never be more references to a texture than there are chunks loaded
- it's not too hard to verify that the reference data about the chunks local data is correct.
In theory, sounds quite good - in programming terms - I think my code could be easier to follow.