@ApochPiQ: Hmm.. why would you recommend against that? Why shouldn't I parse the codes during the game play?
I was actually planning to do lexical scans in the game loading, then parse the tokens during the game play whenever needed...
Game Logic: Creating a Scripting Language
There is obviously a performance penalty in parsing tokens, grammar, etc. in real-time.
Script code is usually parsed once and byte-code is generated, which reduces parsing to a matter of reading sequential instructions.
L. Spiro
Author
I'm guessing there won't be any noticeable performance difference if I'm using multiple threading and parsing on a separate thread
I have also been thinking about creating a vector like the following:
vector<CL> c;
- Index 0: DECLARE_VARIABLE string strVar
- Index 1: ASSIGN_VARIABLE strVar "Test"
etc...
Not sure my idea is efficient
I can understand the desire to make a scripting language. I guess I can be a bit nerdy, but designing the language, building the compiler, and writing the byte code interpreter can be a lot of fun. I decided against it though because of my lack of time. Developing a good 3D game is hard enough and takes a great deal of time. I did make a simple AI script though. The language itself is simple enough to parse with a library string tokenizer. It just sends basic commands with some parameters to the AI.
It's your decision if you want to make a scripting language for your engine. My suggestion is, if you want to finish the engine/game in a reasonable amount of time, make something simple. Focus solely on your games needs and what you need to script. You can expand it later.
It's your decision if you want to make a scripting language for your engine. My suggestion is, if you want to finish the engine/game in a reasonable amount of time, make something simple. Focus solely on your games needs and what you need to script. You can expand it later.
I'm guessing there won't be any noticeable performance difference if I'm using multiple threading and parsing on a separate threadI have also been thinking about creating a vector like the following:vector<CL> c;- Index 0: DECLARE_VARIABLE string strVar- Index 1: ASSIGN_VARIABLE strVar "Test"etc...Not sure my idea is efficient
A fine example of over-engineering.
Unless you have a strategy for determining what to pre-compile and how to wait for the results to finish compiling, you’ve just dug your hole deeper. I wouldn’t even go this route even though I have a solid grasp of multi-threading principles and have written 4 scripting languages.
Your best bet at reducing run-time overhead is to compile to a form of proprietary byte-code that can be parsed sequentially instruction-per-instruction. Or use LLVM.
L. Spiro
If you want a game mechanism entierely based on scripting, like unity does... you need a very powerful virtual machine, like mono c#
If you just want to make a very basic "ia" actions on a few variables (select a target, impulse vector, increase/decrease energy variable, change animation index...) well... i think the easiest syntax to compile would be a very specific asm-like, and for each class make separate scripts for each events (maybe ia event is enough, i'd not add a collide event, just a distance test in the ia event)
let's say it's the script of the "ia" routine of a "zombi" class, stupidly following slowly the player, and going into close-attack behavior when near:
start:
readObjectPosition 0, %v1 ;let's say player has index 0, copy its position vector in a vector register
readObjectPosition C_ME, %v2 ;local object index is stored in constant C_ME, copy position in other vector register
subtractVectors %v1, %v2 ;vector substraction stored in the second register
getVectorMagnitude %v2, %f1 ;get distance and store in a float register
Cmp %f1,5 ;jump to label 2 if distance to player is greater than 5
JG label_2
label_1:
setBehavior 1 ;request behavior 1, the zombi stands up and attacks
JMP label_end
label_2:
setBehavior 0 ;request behavior 0, the zombi walks with an impulse speed
normalizeVector %v2, 0.1 ;set vector magnitude to 0.1 unit/second
impulse %v3 ;update the impulsion vector
label_end:the idea is to make something easy to compile and easy to read
if you keep very simple behaviors i'ts ok, so all complex stuff like pathfinder, physics, bone animation, state machines, object generation and culling, will be natively managed by your engine. Scripting is just used for behavior appointments.
I also have my own scripting language.
My raccomandation is: give up.
Differently from others, I had extra requirements which made pre-existing scripting languages difficult to use (if possible at all). It's currently core for my game and yes, I trust it well enough.
It appears to me however this thread is considering the goal with a technical mindset only. Besides the technical, I don't see discussion about the why OP shall embark on this project. It seems OP is considering the language in a vacuum and that's not what's going to give good results.
The ancestors of game engine scripts were just parameter files used to create bonus or characters class without recompiling the engine.
Stuff like:
skin_id=645
energy=78
speed=11
weapon_id=47
fly=true
etc...Can be stored in XML files or other ascii encoding method.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
