10.19.2011

manage your living!

I've made a final game engine draft for the ASCII raytracer I've started so long ago and merged with my scripting language. I didn't post it, did I? I've made a realistic draft about how it's bytecode and it's syntax would work as well as some API design more making common things and so on. It uses only fifo and lifo stacks available as arrays and linked lists. The bytecode is also extremely minimalistic with so far only three commands, mostly making everything into "parameter-less" function call of interpreter-executed and external functions as well as pushing constant binary data to the stack. I've added some really stack-structuring functions that should come in handy for all later stuff. I'll use it as my scripting language due it's minimal and theoretically high execution speed as it simply doesn't require and any complex bytecode unpacking except and more lengthy binding mechanic. It plays nicely with my current game engine draft and I never felt my whole goal in programming more clearly. The engine has a fixed feature set and everything else is controlled via the scripting engine. All interactions are event-triggered and the engine itself does only provide physics simulation (triggering such events) for gravity, bouncing, map deformation, water, electricity etc (yes, this be a part of the combat system - think about lighting spells on armored knights!) and map streaming as well using a map graph. Every interaction, camera movement, HUD control and so on will be made available to the scripting engine. Even if the performance is too critical for certain parts like path finding or so, I can still utilize a wrapper to an external C function working with exactly the game engine's structures. One thing that is not a strength of this scripting language is that there are no structure at all. There is a loose typing system used to process batches of different input parameters, but no real type system behind. I don't want to waste any time with trying to integrate structure concepts because the language should emphasize the use of batch processing and random input values to get away from too declaration-heavy programming that doesn't provide any code but interfaces (take this, Java - ha!). I don't call this optimal, but concept is concept. I like pure concepts. They motivate myself to focus on problem solution in a restricted environment. In case I'll program something personal the next days, I'll program on this game engine. A demo with a test level should be enough to demonstrate that I actually can be a game programmer and not just a metatechnical weirdo.

No comments: