4.04.2011

Against minecrafting

The title might sound a bit false, but I need to do something against this Minecraft addiction. I played more than three days with only pauses for food, sleep and pee. It has to stop RIGHT NOW. I can't believe how hilarious this must look. A grown man sitting infront of a screen and trying to build monster traps, Zen gardens, gold towers, land mines, sugar farms and whatever not in the end senseless stuff he can't just stop building. It's for sure the same thing I had with Diablo, Stalker and Fallout before - only that this game will always give you a new setup, making it incredibly addictive and tabula rasa at once. You can always start building, the possible things to do never stops. And even worse, the internet does add so much more information about how stuff works and so on. I still need to build a cannon, I still have no railroad system, didn't test a portal fast traveling system etc and so on. SO. MUCH. STUFF.

No, I need to do something against that! Today I was able to unchain myself from it for some hours and pixelated. Has been a long time since I did that with something deserving the "abstract art" category. Anyway, after this my head was clean from minecraftian thoughts and collected whatever stuff was floating in my head. And I found something interesting I might incorporate into my programming language. As the language will be translated to C and will have a build-int bytecode interpreter, everything program should, in theory, be able to execute bytecode if it uses those features. So why not extend this and do put the interpreter in, too? This is an interesting idea: A program that is able to a) generate and execute code in the language/bytecode it was written, b) parse it's own syntax due to recursion and a minimal tree structure in memory and c) supports combination of both to enable a build-in console-like functionality where you could thereoretically parse and execute user-written code during runtime. And a program that will be executed from a bytecode format will also completely know it's own code, making it effectively possible to create a program that improves or enhances itself over time... I like the idea of combining compiler, interpreter and resulting program. My current bytecode concept is very minimal, consisting of only a few things easily to include inside the a normal program with overhead I think. As long as I can keep the macros system up and running, it should be possible to continue with no further complications. The idea is getting better and better and the concept begins to take shape of a design document. And to implement a minimal but versatile parser/compiler inside the program is quite an interesting challenge - something I longed for a long time. Rendering and computer game technology is so boring cause everything's known and only takes time to test and implement. Earning your bread and butter this way is only interesting to me if there's a team you can work with, a set of people who know what the final result will be, so that you can focus and getting the stuff to work and feel that you really earned your money this time. But I don't want to generalize this - it get's interesting if you have tools and technology for experimenting on a higher, more abstract level. That's why it must be more fun to work an existing engine and already done concept to make it real with what have and what you can use.

However, I'm confident with this one.

No comments: