Jump to content

  • Log In with Google      Sign In   
  • Create Account


Game Logic: Creating a Scripting Language


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
19 replies to this topic

#1 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 19 September 2013 - 12:29 AM

I'm creating my own scripting language for my 3D Game Engine, at first I'm doing lexical scan, then parsing the tokens.

 

What is your suggestions for creating a powerful scripting language for 3D Game Engines?

 

For methods, should I create bunches of methods linked to a callback?

 

I thought I could do something similar to the following:

parser.declareFunction("FunctionName", callback);

So when I execute parser.parse("bool b = true; if (b) { FunctionName(); }"); the callback should be called



Sponsor:

#2 LorenzoGatti   Crossbones+   -  Reputation: 2511

Like
6Likes
Like

Posted 19 September 2013 - 03:54 AM

 

I'm creating my own scripting language for my 3D Game Engine, at first I'm doing lexical scan, then parsing the tokens.
 
What is your suggestions for creating a powerful scripting language for 3D Game Engines?

Why do you feel the need to invent a new programming language instead of using an existing one? Being busy "parsing the tokens", a long distance from useful scripting, should be a hint that designing and implementing a new language is probably too much effort (or that an acceptable effort can give you only a mediocre and immature language).
Produci, consuma, crepa

#3 morbik   Members   -  Reputation: 363

Like
0Likes
Like

Posted 19 September 2013 - 07:11 AM

What Lorenzo said.  I would only recommend designing a new scripting language if it was truly a desire to learn the intricacies of designing a language.  If you're hoping to use it for anything like production, even of a hobby product, you're going to be spending way too many resources getting it to work rather than actually coding your game.  The other thing is, the widely available scripting languages will be way more robust and much faster than what you'd be able to accomplish without a large, really large effort.



#4 L. Spiro   Crossbones+   -  Reputation: 12216

Like
5Likes
Like

Posted 19 September 2013 - 09:26 AM

I won’t get into syntax because there is just so much to discuss and in the end it will be up to you to figure out what you need and don’t need.

I won’t go into using existing languages because too many others already will.

 

Instead, if you need to make one from scratch, you should (virtually “must”) look into Flex/Bison in order to create a fast, stable, and maintainable set of tokens and grammar rules.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#5 SiCrane   Moderators   -  Reputation: 9387

Like
4Likes
Like

Posted 19 September 2013 - 09:45 AM

I wouldn't say specifically Flex/Bison. There are any number of lexer and parser generators that can be used. Many of the new-ish tools, especially those using recursive descent, combine lexer and parser generation.

#6 ApochPiQ   Moderators   -  Reputation: 14256

Like
2Likes
Like

Posted 19 September 2013 - 11:24 AM

I'm going to jump on the "don't create your own language" wagon.


Yes, I realize that it's a bit ironic for me to say that, but here's my reasoning: creating a language that is rich enough to save you time is a ton of work. You also give up good debugging tools, good profiling tools, and good compiler diagnostics. In general you lose more than you gain when you roll your own. You will probably spend more time and effort maintaining your language than actually getting things done, which is kind of contrary to the purpose of using a scripting language in the first place.

Note that this primarily applies to general-purpose languages. If you want to create a highly tailored DSL for some specific task, that's one thing; but a general scripting language is almost certainly biting off more than you want to chew.

I also advocate not using a "real" syntax for DSLs, but rather something you can trivially parse with string splitting library functions, or maybe a JSON library or something similar.


TL;DR: don't do that :-P

#7 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 19 September 2013 - 12:12 PM

Oops...

 

I have done a lot already including declaring variables, calling methods, arguments, assigning variables, declaring methods...

 

I think I have done many of what I want already, I don't think I will need a large scripting language for scripting inside the game mission design, the scripting will ONLY be used in the game design, so I think the most important is using "if" statements, declaring variables, calling methods

 

But, my question is: What should I focus on my own scripting language to create something powerful for mission scripting? What are the general uses of scripting in FPS games?

 

Example of what I think of scripting:

 

If the player collided with a trigger box (invisible) then I know that the player reached some point in the game so I can do something like: onTriggerEnter event script: object1.completed();

 

For game win check scripting I could do something like:

if (objects.allCompleted)

    mission_completed();



#8 BGB   Crossbones+   -  Reputation: 1545

Like
0Likes
Like

Posted 19 September 2013 - 02:28 PM

I wouldn't say specifically Flex/Bison. There are any number of lexer and parser generators that can be used. Many of the new-ish tools, especially those using recursive descent, combine lexer and parser generation.

 

agreed, though personally I have typically used hand-written recursive descent.

 

usually IME, the logic that comes after parsing is a lot more work than the parser itself.

 

 

my experience here (implementing/using a custom script language):

a lot of work over a lot of years, and all these years later, what I have is, at-best, mediocre...

 

though, granted, it does basically what I want out of it, so is "mostly good enough".

it does light duty scripting stuff basically ok, but isn't really solid enough to seriously consider as an implementation language.

 

 

one sad thing in life is that pretty much anything a person can do, someone else has likely already done better, so it is a choice whether to reuse what others' have done (and try to figure out ultimately what they can do for themselves, *1), or sit around and basically play catch-up.

 

what merit there is then is mostly in terms of customization or control, or aiming for unconventional use-cases (competing on unconventional metrics, ...).

 

 

*1: while pretty much everything has already been done, unless a person does something, they effectively still have nothing.

like, if a person goes and downloads some FOSS game off the internet, everything has already been written, assets created, ... but the person has, themselves, not created anything (and has no natural ownership or control over any of it).



#9 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 19 September 2013 - 04:55 PM

@ApochPiQ: I don't really need to have any debugging tools or compiler, the game is FPS and I'm planning to parse the scripts directly during the game play.

 

So, what I have is only syntax checking.


Edited by Medo3337, 19 September 2013 - 04:56 PM.


#10 ApochPiQ   Moderators   -  Reputation: 14256

Like
2Likes
Like

Posted 19 September 2013 - 06:08 PM

It's obviously up to you, but I'd recommend against that, actually. You're in for a lot more pain than you think, unless your scripts are so bone-trivial that they may as well just be code in the first place.

#11 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 19 September 2013 - 09:15 PM

@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...



#12 L. Spiro   Crossbones+   -  Reputation: 12216

Like
2Likes
Like

Posted 19 September 2013 - 09:40 PM

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


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#13 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 20 September 2013 - 01:41 PM

How do I convert tokens to byte-code?



#14 SiCrane   Moderators   -  Reputation: 9387

Like
0Likes
Like

Posted 20 September 2013 - 01:59 PM

You write a compiler, or use a language that already has a byte code compiler.



#15 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 21 September 2013 - 01:49 AM

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


#16 Squared'D   Members   -  Reputation: 2217

Like
1Likes
Like

Posted 21 September 2013 - 02:09 AM

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.

Learn all about my current projects and watch some of the game development videos that I've made.

Squared Programming Home

New Personal Journal

 


#17 L. Spiro   Crossbones+   -  Reputation: 12216

Like
0Likes
Like

Posted 21 September 2013 - 03:39 AM

 

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

 

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


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#18 punkcoders   Members   -  Reputation: 137

Like
2Likes
Like

Posted 22 September 2013 - 11:30 AM

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.


Edited by punkcoders, 22 September 2013 - 07:45 PM.


#19 Krohm   Crossbones+   -  Reputation: 2960

Like
1Likes
Like

Posted 23 September 2013 - 12:32 AM

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.



#20 punkcoders   Members   -  Reputation: 137

Like
1Likes
Like

Posted 23 September 2013 - 03:05 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS